multi-agent-patterns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Multi-Agent Architecture Patterns

多 Agent 架构模式

Multi-agent architectures distribute work across multiple language model instances, each with its own context window. When designed well, this distribution enables capabilities beyond single-agent limits. When designed poorly, it introduces coordination overhead that negates benefits. The critical insight is that sub-agents exist primarily to isolate context, not to anthropomorphize role division.

多 Agent 架构将工作分派给多个语言模型实例，每个实例都有自己的上下文窗口。设计良好时，这种分布式处理能够带来超越单 Agent 限制的能力；设计不佳时，则会引入抵消收益的协调开销。关键洞察在于：子 Agent 的主要存在意义是隔离上下文，而不是将角色划分拟人化。

When to Activate

何时启用

Activate this skill when:

Single-agent context limits constrain task complexity
Tasks decompose naturally into parallel subtasks
Different subtasks require different tool sets or system prompts
Building systems that must handle multiple domains simultaneously
Scaling agent capabilities beyond single-context limits
Designing production agent systems with multiple specialized components

Do not activate this skill for adjacent work owned by other skills:

Deciding task-model fit, pipeline shape, or project-level cost before topology is known:
```
project-development
```
.
Designing hosted sandboxes, warm pools, remote sessions, or background runtime infrastructure:
```
hosted-agents
```
.
Sharing orchestrator state through KV-cache compaction in controlled runtimes:
```
latent-briefing
```
.
Designing the tools each agent exposes:
```
tool-design
```
.

在以下情况下启用此 skill：

单 Agent 的上下文限制制约任务复杂度
任务可自然分解为可并行的子任务
不同子任务需要不同的工具集或 system prompt
构建必须同时处理多个领域的系统
将 Agent 能力扩展到超出单一上下文限制
设计包含多个专用组件的生产级 Agent 系统

对于由其他 skill 负责的相关工作，不要启用此 skill：

在拓扑尚未明确时，决定任务与模型的适配性、pipeline 形态或项目级成本：
```
project-development
```
。
设计 hosted sandbox、warm pool、远程会话或后台 runtime 基础设施：
```
hosted-agents
```
。
在受控 runtime 中通过 KV-cache 压缩共享 orchestrator 状态：
```
latent-briefing
```
。
设计每个 Agent 暴露的工具：
```
tool-design
```
。

Core Concepts

核心概念

Use multi-agent patterns when a single agent's context window cannot hold all task-relevant information. Context isolation is the primary benefit — each agent operates in a clean context without accumulated noise from other subtasks, preventing the telephone game problem where information degrades through repeated summarization.

Choose among three dominant patterns based on coordination needs, not organizational metaphor:

Supervisor/orchestrator — Use for centralized control when tasks have clear decomposition and human oversight matters. A single coordinator delegates to specialists and synthesizes results.
Peer-to-peer/swarm — Use for flexible exploration when rigid planning is counterproductive. Any agent can transfer control to any other through explicit handoff mechanisms.
Hierarchical — Use for large-scale projects with layered abstraction (strategy, planning, execution). Each layer operates at a different level of detail with its own context structure.

Design every multi-agent system around explicit coordination protocols, consensus mechanisms that resist sycophancy, and failure handling that prevents error propagation cascades.

当单个 Agent 的上下文窗口无法容纳所有与任务相关的信息时，应使用多 Agent 模式。上下文隔离是首要收益——每个 Agent 都在干净的上下文中运行，不会积累其他子任务带来的噪声，从而避免信息在反复摘要中逐渐失真的“传话游戏”问题。

应根据协调需求，而不是组织隐喻，在以下三种主流模式中进行选择：

Supervisor/orchestrator — 当任务可清晰分解且人工监督很重要时，采用集中控制。由单个协调者将工作委派给专家，并综合结果。
Peer-to-peer/swarm — 当僵化的规划会妨碍工作，而灵活探索更重要时采用。任何 Agent 都可以通过显式 handoff 机制将控制权移交给其他 Agent。
Hierarchical — 用于具有分层抽象的大规模项目（战略、规划、执行）。每一层以不同粒度运行，并拥有自己的上下文结构。

设计每个多 Agent 系统时，都应围绕显式协调协议、能够抵御迎合行为的共识机制，以及可防止错误级联传播的失败处理机制展开。

Detailed Topics

详细主题

Why Multi-Agent Architectures

为什么采用多 Agent 架构

The Context Bottleneck Reach for multi-agent architectures when a single agent's context fills with accumulated history, retrieved documents, and tool outputs to the point where performance degrades. Recognize three degradation signals: the lost-in-middle effect (attention weakens for mid-context content), attention scarcity (too many competing items), and context poisoning (irrelevant content displaces useful content).

Partition work across multiple context windows so each agent operates in a clean context focused on its subtask. Aggregate results at a coordination layer without any single context bearing the full burden.

The Token Economics Reality Budget for substantially higher token costs. Production data shows multi-agent systems can cost far more tokens than single-agent chat (claim-multi-agent-token-multiplier):

Architecture	Token Multiplier	Use Case
Single agent chat	Baseline	Simple queries
Single agent with tools	Higher than baseline	Tool-using tasks
Multi-agent system	Much higher than baseline	Complex research/coordination

Browsing-agent evaluation research suggests token usage, tool calls, and model choice dominate performance variance (claim-evaluation-browsecomp-variance). This supports measuring multi-agent setups against single-agent baselines instead of assuming extra agents help.

Prioritize model selection alongside architecture design — upgrading to better models often provides larger performance gains than doubling token budgets. BrowseComp data shows that model quality improvements frequently outperform raw token increases. Treat model selection and multi-agent architecture as complementary strategies.

The Parallelization Argument Assign parallelizable subtasks to dedicated agents with fresh contexts rather than processing them sequentially in a single agent. A research task requiring searches across multiple independent sources, analysis of different documents, or comparison of competing approaches benefits from parallel execution. Total real-world time approaches the duration of the longest subtask rather than the sum of all subtasks.

The Specialization Argument Configure each agent with only the system prompt, tools, and context it needs for its specific subtask. A general-purpose agent must carry all possible configurations in context, diluting attention. Specialized agents carry only what they need, operating with lean context optimized for their domain. Route from a coordinator to specialized agents to achieve specialization without combinatorial explosion.

上下文瓶颈 当单个 Agent 的上下文被积累的对话历史、检索到的文档和工具输出填满，并开始导致性能下降时，应考虑采用多 Agent 架构。要识别三个退化信号：中段丢失效应（lost-in-middle effect，注意力对上下文中部内容的减弱）、注意力稀缺（attention scarcity，过多相互竞争的信息项）以及上下文污染（context poisoning，无关内容挤占有用内容）。

将工作划分到多个上下文窗口中，让每个 Agent 都在专注于自身子任务的干净上下文中运行。在协调层汇总结果，避免任何单一上下文承担全部负担。

Token 经济学现实 应为显著更高的 Token 成本做好预算。生产数据表明，多 Agent 系统的 Token 成本可能远高于单 Agent 对话（claim-multi-agent-token-multiplier）：

架构	Token 倍数	使用场景
单 Agent 对话	基线	简单查询
单 Agent 配合工具	高于基线	使用工具的任务
多 Agent 系统	远高于基线	复杂研究/协调

浏览型 Agent 评估研究表明，Token 用量、工具调用和模型选择主导了性能差异（claim-evaluation-browsecomp-variance）。因此，应将多 Agent 配置与单 Agent 基线进行对比和衡量，而不是想当然地认为增加 Agent 必然有帮助。

在设计架构的同时，应优先考虑模型选择——升级到更优秀的模型，往往比将 Token 预算翻倍带来更大的性能提升。BrowseComp 数据显示，模型质量的提升经常超过单纯增加 Token 所带来的收益。应将模型选择与多 Agent 架构视为互补策略。

并行化依据 将可并行的子任务分配给拥有全新上下文的专用 Agent，而不是在单个 Agent 中顺序处理。跨多个独立来源进行检索、分析不同文档或比较竞争方案的研究任务，都适合并行执行。总耗时接近最长子任务的实际时长，而不是所有子任务时长的总和。

专用化依据 仅针对每个 Agent 的具体子任务，配置其所需的 system prompt、工具和上下文。通用 Agent 必须在上下文中携带所有可能的配置，从而稀释注意力。专用 Agent 只携带自身所需内容，以针对特定领域优化的精简上下文运行。通过协调者将任务路由到专用 Agent，可在避免组合爆炸的同时实现专用化。

Architectural Patterns

架构模式

Pattern 1: Supervisor/Orchestrator Deploy a central agent that maintains global state and trajectory, decomposes user objectives into subtasks, and routes to appropriate workers.

User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output

Choose this pattern when: tasks have clear decomposition, coordination across domains is needed, or human oversight is important.

Expect these trade-offs: strict workflow control and easier human-in-the-loop interventions, but the supervisor context becomes a bottleneck, supervisor failures cascade to all workers, and the "telephone game" problem emerges where supervisors paraphrase sub-agent responses incorrectly.

The Telephone Game Problem and Solution Anticipate that supervisor architectures initially perform approximately 50% worse than optimized versions due to the telephone game problem (LangGraph benchmarks). Supervisors paraphrase sub-agent responses, losing fidelity with each pass.

Fix this by implementing a

forward_message

tool that allows sub-agents to pass responses directly to users:

python

def forward_message(message: str, to_user: bool = True):
    """
    Forward sub-agent response directly to user without supervisor synthesis.

    Use when:
    - Sub-agent response is final and complete
    - Supervisor synthesis would lose important details
    - Response format must be preserved exactly
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

Prefer swarm architectures over supervisors when sub-agents can respond directly to users, as this eliminates translation errors entirely.

Pattern 2: Peer-to-Peer/Swarm Remove central control and allow agents to communicate directly based on predefined protocols. Any agent transfers control to any other through explicit handoff mechanisms.

python

def transfer_to_agent_b():
    return agent_b  # Handoff via function return

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

Choose this pattern when: tasks require flexible exploration, rigid planning is counterproductive, or requirements emerge dynamically and defy upfront decomposition.

Expect these trade-offs: no single point of failure and effective breadth-first scaling, but coordination complexity increases with agent count, divergence risk rises without a central state keeper, and robust convergence constraints become essential.

Define explicit handoff protocols with state passing. Ensure agents communicate their context needs to receiving agents.

Pattern 3: Hierarchical Organize agents into layers of abstraction: strategy (goal definition), planning (task decomposition), and execution (atomic tasks).

Strategy Layer (Goal Definition) -> Planning Layer (Task Decomposition) -> Execution Layer (Atomic Tasks)

Choose this pattern when: projects have clear hierarchical structure, workflows involve management layers, or tasks require both high-level planning and detailed execution.

Expect these trade-offs: clear separation of concerns and support for different context structures at different levels, but coordination overhead between layers, potential strategy-execution misalignment, and complex error propagation paths.

模式 1：Supervisor/orchestrator 部署一个中央 Agent，负责维护全局状态和执行轨迹，将用户目标分解为子任务，并路由给合适的工作 Agent。

User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output

当任务可清晰分解、需要跨领域协调或人工监督很重要时，选择此模式。

需要权衡以下因素：工作流控制严格且便于 human-in-the-loop 干预，但 Supervisor 的上下文会成为瓶颈；Supervisor 故障会级联影响所有工作 Agent；还会出现“传话游戏”问题，即 Supervisor 在转述子 Agent 响应时产生错误。

传话游戏问题及其解决方案 应预先认识到，由于传话游戏问题，Supervisor 架构的初始表现可能比优化后的版本差约 50%（LangGraph 基准测试）。Supervisor 会转述子 Agent 的响应，每次转述都会降低信息保真度。

可通过实现

forward_message

工具来解决，让子 Agent 直接向用户传递响应：

python

def forward_message(message: str, to_user: bool = True):
    """
    Forward sub-agent response directly to user without supervisor synthesis.

    Use when:
    - Sub-agent response is final and complete
    - Supervisor synthesis would lose important details
    - Response format must be preserved exactly
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

当子 Agent 可以直接响应用户时，应优先选择 swarm 架构而非 Supervisor 架构，从而彻底消除转述错误。

模式 2：Peer-to-Peer/Swarm 移除中央控制，允许 Agent 根据预定义协议直接通信。任何 Agent 都可以通过显式 handoff 机制将控制权移交给其他 Agent。

python

def transfer_to_agent_b():
    return agent_b  # Handoff via function return

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

当任务需要灵活探索、僵化规划会妨碍工作，或需求动态出现且难以预先分解时，选择此模式。

需要权衡以下因素：没有单点故障，并且能够有效地进行广度优先扩展；但 Agent 数量增加会提高协调复杂度；缺少中央状态维护者时，分歧风险会上升，因此必须建立稳健的收敛约束。

定义带状态传递的显式 handoff 协议。确保 Agent 将其上下文需求传达给接收方。

模式 3：Hierarchical 将 Agent 组织为不同抽象层：战略层（定义目标）、规划层（分解任务）和执行层（原子任务）。

Strategy Layer (Goal Definition) -> Planning Layer (Task Decomposition) -> Execution Layer (Atomic Tasks)

当项目具有清晰的分层结构、工作流包含管理层级，或任务同时需要高层规划和详细执行时，选择此模式。

需要权衡以下因素：关注点分离清晰，并支持不同层级采用不同上下文结构；但层间协调开销较高，可能出现战略与执行不一致，且错误传播路径复杂。

Context Isolation as Design Principle

将上下文隔离作为设计原则

Treat context isolation as the primary purpose of multi-agent architectures. Each sub-agent should operate in a clean context window focused on its subtask without carrying accumulated context from other subtasks.

Isolation Mechanisms Select the right isolation mechanism for each subtask:

Full context delegation — Share the planner's entire context with the sub-agent. Use for complex tasks where the sub-agent needs complete understanding. The sub-agent has its own tools and instructions but receives full context for its decisions. Note: this partially defeats the purpose of context isolation.
Instruction passing — Create instructions via function call; the sub-agent receives only what it needs. Use for simple, well-defined subtasks. Maintains isolation but limits sub-agent flexibility.
File system memory — Agents read and write to persistent storage. Use for complex tasks requiring shared state. The file system serves as the coordination mechanism, avoiding context bloat from shared state passing. Introduces latency and consistency challenges but scales better than message-passing.

Choose based on task complexity, coordination needs, and acceptable latency. Default to instruction passing and escalate to file system memory when shared state is needed. Avoid full context delegation unless the subtask genuinely requires it.

应将上下文隔离视为多 Agent 架构的首要目的。每个子 Agent 都应在干净的上下文窗口中运行，专注于自身子任务，且不携带其他子任务积累的上下文。

隔离机制 为每个子任务选择合适的隔离机制：

完整上下文委派（Full context delegation） — 将规划者的完整上下文共享给子 Agent。适用于子 Agent 需要全面理解的复杂任务。子 Agent 拥有自己的工具和指令，但会接收完整上下文以进行决策。注意：这会在一定程度上削弱上下文隔离的作用。
指令传递（Instruction passing） — 通过 function call 创建指令；子 Agent 只接收所需内容。适用于简单且定义明确的子任务。它能保持隔离，但会限制子 Agent 的灵活性。
文件系统记忆（File system memory） — Agent 读写持久化存储。适用于需要共享状态的复杂任务。文件系统充当协调机制，避免通过共享状态传递造成上下文膨胀。它会带来延迟和一致性方面的挑战，但比消息传递具有更好的扩展性。

应根据任务复杂度、协调需求和可接受的延迟进行选择。默认使用指令传递，需要共享状态时再升级为文件系统记忆。除非子任务确实需要，否则应避免完整上下文委派。

Consensus and Coordination

共识与协调

The Voting Problem Avoid simple majority voting — it treats hallucinations from weak models as equal to reasoning from strong models. Without intervention, multi-agent discussions devolve into consensus on false premises due to inherent bias toward agreement.

Weighted Voting Weight agent votes by confidence or expertise. Agents with higher confidence or domain expertise should carry more weight in final decisions.

Debate Protocols Structure agents to critique each other's outputs over multiple rounds. Adversarial critique often yields higher accuracy on complex reasoning than collaborative consensus. Guard against sycophantic convergence where agents agree to be agreeable rather than correct.

Trigger-Based Intervention Monitor multi-agent interactions for behavioral markers. Activate stall triggers when discussions make no progress. Detect sycophancy triggers when agents mimic each other's answers without unique reasoning.

投票问题 避免简单多数投票——这种方式会将弱模型的幻觉与强模型的推理视为同等可靠。如果不加以干预，多 Agent 讨论会因内在的迎合倾向而最终对错误前提达成共识。

加权投票 根据 Agent 的置信度或专业能力为其投票加权。置信度更高或更具领域专长的 Agent，应在最终决策中占据更大权重。

辩论协议 让 Agent 在多轮交互中批评彼此的输出。对于复杂推理，对抗式批评往往比协作式共识更准确。应防范迎合式趋同，即 Agent 为了附和而达成一致，而非为了得出正确答案。

基于触发条件的干预 监控多 Agent 交互中的行为标记。当讨论毫无进展时，触发停滞条件；当 Agent 模仿彼此的答案且没有独立推理时，检测迎合触发条件。

Framework Considerations

框架考量

Different frameworks implement these patterns with different philosophies. LangGraph uses graph-based state machines with explicit nodes and edges. AutoGen uses conversational/event-driven patterns with GroupChat. CrewAI uses role-based process flows with hierarchical crew structures.

不同框架以不同理念实现这些模式。LangGraph 使用基于图的状态机，并具有显式节点和边。AutoGen 使用结合 GroupChat 的对话式/事件驱动模式。CrewAI 使用基于角色的流程和分层 crew 结构。

Practical Guidance

实践指导

Failure Modes and Mitigations

失败模式与缓解措施

Failure: Supervisor Bottleneck The supervisor accumulates context from all workers, becoming susceptible to saturation and degradation.

Mitigate by constraining worker output schemas so workers return only distilled summaries. Use checkpointing to persist supervisor state without carrying full history in context.

Failure: Coordination Overhead Agent communication consumes tokens and introduces latency. Complex coordination can negate parallelization benefits.

Mitigate by minimizing communication through clear handoff protocols. Batch results where possible. Use asynchronous communication patterns. Measure whether multi-agent coordination actually saves time versus a single agent with a longer context.

Failure: Divergence Agents pursuing different goals without central coordination drift from intended objectives.

Mitigate by defining clear objective boundaries for each agent. Implement convergence checks that verify progress toward shared goals. Set time-to-live limits on agent execution to prevent unbounded exploration.

Failure: Error Propagation Errors in one agent's output propagate to downstream agents that consume that output, compounding into increasingly wrong results.

Mitigate by validating agent outputs before passing to consumers. Implement retry logic with circuit breakers. Use idempotent operations where possible. Consider adding a verification agent that cross-checks critical outputs before they enter the pipeline.

失败：Supervisor 瓶颈 Supervisor 会积累所有工作 Agent 的上下文，因而容易饱和和退化。

通过约束工作 Agent 的输出 schema，使其只返回提炼后的摘要来缓解。使用 checkpointing 持久化 Supervisor 状态，而无需在上下文中携带完整历史。

失败：协调开销 Agent 通信会消耗 Token 并引入延迟。复杂协调可能抵消并行化带来的收益。

通过清晰的 handoff 协议尽量减少通信；尽可能批量传输结果；采用异步通信模式。衡量多 Agent 协调是否真的比使用更长上下文的单 Agent 节省时间。

失败：分歧 追求不同目标且没有中央协调的 Agent 会逐渐偏离预期目标。

通过为每个 Agent 定义清晰的目标边界来缓解。实施收敛检查，验证其是否朝共享目标推进。为 Agent 执行设置 time-to-live 限制，防止无界探索。

失败：错误传播 一个 Agent 输出中的错误会传播给消费该输出的下游 Agent，并被不断放大，产出越来越错误的结果。

在把输出传给消费者之前进行验证。实现带有 circuit breaker 的重试逻辑。尽可能使用幂等操作。考虑加入验证 Agent，在关键输出进入 pipeline 前进行交叉核验。

Examples

示例

Example 1: Research Team Architecture

text

Supervisor
├── Researcher (web search, document retrieval)
├── Analyzer (data analysis, statistics)
├── Fact-checker (verification, validation)
└── Writer (report generation, formatting)

Example 2: Handoff Protocol

python

def handle_customer_request(request):
    if request.type == "billing":
        return transfer_to(billing_agent)
    elif request.type == "technical":
        return transfer_to(technical_agent)
    elif request.type == "sales":
        return transfer_to(sales_agent)
    else:
        return handle_general(request)

示例 1：研究团队架构

text

Supervisor
├── Researcher (web search, document retrieval)
├── Analyzer (data analysis, statistics)
├── Fact-checker (verification, validation)
└── Writer (report generation, formatting)

示例 2：Handoff 协议

python

def handle_customer_request(request):
    if request.type == "billing":
        return transfer_to(billing_agent)
    elif request.type == "technical":
        return transfer_to(technical_agent)
    elif request.type == "sales":
        return transfer_to(sales_agent)
    else:
        return handle_general(request)

Guidelines

指南

Design for context isolation as the primary benefit of multi-agent systems
Choose architecture pattern based on coordination needs, not organizational metaphor
Implement explicit handoff protocols with state passing
Use weighted voting or debate protocols for consensus
Monitor for supervisor bottlenecks and implement checkpointing
Validate outputs before passing between agents
Set time-to-live limits to prevent infinite loops
Test failure scenarios explicitly

以上下文隔离作为多 Agent 系统的主要收益来进行设计
根据协调需求选择架构模式，而不是组织隐喻
实现带状态传递的显式 handoff 协议
使用加权投票或辩论协议形成共识
监控 Supervisor 瓶颈并实现 checkpointing
在 Agent 之间传递输出前进行验证
设置 time-to-live 限制，防止无限循环
显式测试故障场景

Gotchas

常见陷阱

Supervisor bottleneck scaling — Supervisor context pressure grows non-linearly with worker count. At 5+ workers, the supervisor spends more tokens processing summaries than workers spend on actual tasks. Set a hard cap on workers per supervisor (3-5) and add a second supervisor tier rather than overloading one.
Token cost underestimation — Multi-agent runs cost approximately 15x baseline. Teams consistently underbudget because they estimate per-agent costs without accounting for coordination overhead, retries, and consensus rounds. Budget for 15x and treat anything less as a bonus.
Sycophantic consensus — Agents in debate patterns tend to converge on agreeable answers, not correct ones. LLMs have an inherent bias toward agreement. Counter this by assigning explicit adversarial roles and requiring agents to state disagreements before convergence is allowed.
Agent sprawl — Adding more agents past 3-5 shows diminishing returns and increases coordination overhead. Each additional agent adds communication channels quadratically. Start with the minimum viable number of agents and add only when a clear context isolation benefit exists.
Telephone game in message-passing — Information degrades through repeated summarization as it passes between agents. Each agent paraphrases and loses nuance. Use filesystem coordination instead of message-passing for state that multiple agents need to access faithfully.
Error propagation cascades — One agent's hallucination becomes another agent's "fact." Downstream agents have no way to distinguish upstream hallucinations from genuine information. Add validation checkpoints between agents and never trust upstream output without verification.
Over-decomposition — Splitting tasks too finely creates more coordination overhead than the task itself. A 10-step pipeline with 10 agents spends more tokens on handoffs than on actual work. Decompose only when subtasks genuinely benefit from separate contexts.
Missing shared state — Agents operating without a shared filesystem or state store duplicate work, produce inconsistent outputs, and lose track of what has already been accomplished. Establish shared persistent storage before building multi-agent workflows.

Supervisor 瓶颈扩展性 — Supervisor 的上下文压力会随工作 Agent 数量呈非线性增长。当工作 Agent 达到 5 个以上时，Supervisor 用于处理摘要所消耗的 Token 会超过工作 Agent 执行实际任务所消耗的 Token。应将每个 Supervisor 的工作 Agent 数量硬性限制在 3-5 个，并增加第二个 Supervisor 层级，而不是让一个 Supervisor 负载过重。
低估 Token 成本 — 多 Agent 运行的成本约为基线的 15 倍。团队始终低估预算，原因通常是按每个 Agent 估算成本，却未计入协调开销、重试和共识轮次。应按 15 倍做预算，并把低于此数额视为额外收益。
迎合式共识 — 辩论模式中的 Agent 往往会趋同于彼此都满意的答案，而非正确答案。LLM 内在倾向于达成一致。应对方式包括分配明确的对抗角色，并要求 Agent 在允许收敛前先陈述分歧。
Agent 膨胀 — 超过 3-5 个 Agent 后，收益会递减，协调开销上升。每增加一个 Agent，通信关系数量会按平方级增长。从最小可行 Agent 数量开始，只有在上下文隔离能带来明确收益时才继续增加。
消息传递中的传话游戏 — 信息在 Agent 间反复摘要时逐渐失真，每个 Agent 都会转述并丢失细微差别。对于多个 Agent 都需要忠实访问的状态，应使用 filesystem 协调代替 message-passing。
错误传播级联 — 一个 Agent 的幻觉会成为另一个 Agent 的“事实”。下游 Agent 无法区分上游幻觉与真实信息。应在 Agent 之间加入验证 checkpoint，绝不未经核验就信任上游输出。
过度分解 — 将任务切分得过细，会使协调开销超过任务本身。一个包含 10 个步骤和 10 个 Agent 的 pipeline，在 handoff 上消耗的 Token 会多于实际工作。只有当子任务确实能从独立上下文中受益时才进行分解。
缺少共享状态 — 如果 Agent 没有共享 filesystem 或状态存储，就会重复工作、产生不一致输出，并丢失已完成事项的记录。构建多 Agent workflow 前，应先建立共享持久化存储。

Integration

集成

This skill owns agent topology and coordination protocols. Adjacent skills own project shape, hosted runtime, and latent-state transfer:

```
project-development
```
: project-level single-vs-multi choice before topology details.
```
hosted-agents
```
: remote sandbox, session, warm-pool, and multiplayer infrastructure.
```
memory-systems
```
: shared persistent state across agents.
```
tool-design
```
: tool specialization and spawn/status tool contracts.
```
context-optimization
```
: partitioning as one token-efficiency tactic.
```
latent-briefing
```
: KV-cache trajectory handoff between orchestrator and worker when models align.
```
evaluation
```
: measuring whether multiple agents improve outcomes after coordination cost.

此 skill 负责 Agent 拓扑和协调协议。相关 skill 分别负责项目形态、hosted runtime 和 latent-state transfer：

```
project-development
```
：在明确拓扑细节前，决定项目层面采用单 Agent 还是多 Agent。
```
hosted-agents
```
：远程 sandbox、session、warm pool 和多人基础设施。
```
memory-systems
```
：Agent 之间的共享持久化状态。
```
tool-design
```
：工具专用化以及 spawn/status 工具契约。
```
context-optimization
```
：将分区作为提升 Token 效率的一种策略。
```
latent-briefing
```
：模型对齐时，在 orchestrator 与 worker 之间进行 KV-cache 轨迹 handoff。
```
evaluation
```
：衡量扣除协调成本后，多 Agent 是否改善结果。

References

参考资料

Internal reference:

Frameworks Reference - Read when: implementing a specific multi-agent pattern in LangGraph, AutoGen, or CrewAI and needing framework-specific code examples

Related skills in this collection:

context-fundamentals - Read when: needing to understand context window mechanics before designing agent partitioning
memory-systems - Read when: agents need to share state across context boundaries or persist information between runs
context-optimization - Read when: individual agent contexts are too large and need partitioning or compression strategies

External resources:

LangGraph Documentation - Read when: building graph-based multi-agent workflows with explicit state machines
AutoGen Framework - Read when: implementing conversational GroupChat patterns or event-driven agent coordination
CrewAI Documentation - Read when: designing role-based hierarchical agent processes
Research on Multi-Agent Coordination - Read when: needing academic grounding on multi-agent system theory and evaluation

内部参考：

框架参考 - 在使用 LangGraph、AutoGen 或 CrewAI 实现特定多 Agent 模式并需要框架专用代码示例时阅读

本合集中的相关 skill：

context-fundamentals - 在设计 Agent 分区前，需要理解上下文窗口机制时阅读
memory-systems - 当 Agent 需要跨上下文边界共享状态或在多次运行之间持久化信息时阅读
context-optimization - 当单个 Agent 的上下文过大，需要分区或压缩策略时阅读

外部资源：

LangGraph 文档 - 构建具有显式状态机的图式多 Agent 工作流时阅读
AutoGen 框架 - 实现对话式 GroupChat 模式或事件驱动的 Agent 协调时阅读
CrewAI 文档 - 设计基于角色的分层 Agent 流程时阅读
多 Agent 协调研究 - 需要多 Agent 系统理论与评估的学术依据时阅读

Skill Metadata

Skill 元数据

Created: 2025-12-20 Last Updated: 2026-05-15 Author: Agent Skills for Context Engineering Contributors Version: 2.1.0

创建时间：2025-12-20 最后更新时间：2026-05-15 作者：Agent Skills for Context Engineering Contributors 版本：2.1.0