多 Agent 架构设计专题总览
提出问题
很多团队第一次讨论多 Agent，问题会被简化成一句话：能不能让几个模型一起干活。
这个说法太粗。多 Agent 的关键不是“多调用几个模型”，而是把一个复杂任务拆成多个有边界的认知单元、执行单元和校验单元，再通过编排器把它们组织成可控流程。
单个 Agent 已经很难管：它有目标、上下文、工具、执行循环、预算和恢复问题。多 Agent 又多了几层复杂度：谁拆任务，谁拥有最终决定权，多个 Agent 是否共享上下文，冲突怎么处理，重复劳动怎么避免，成本怎么控制，结果如何合并，失败后如何回放。
所以多 Agent 架构设计的核心问题不是：
能不能让 Agent 互相聊天？
而是：
这个任务是否真的需要多个角色或多个执行流？如果需要，应该用什么协作协议把它们约束起来？
场景
看一个 AI 开发工作台。
用户输入：
帮我把这个老项目的用户权限模块重构掉，保留现有行为，补上测试，并检查是否影响前端页面。
这不是一个简单生成任务。它至少包含这些子任务：
如果只让一个 Agent 从头做到尾，它会同时承担“架构师、实现者、测试者、审查者”的角色。模型可以这样做，但风险是：上下文越来越混乱，自己写的方案自己很难严格质疑，执行中容易忘记原始目标。
多 Agent 的价值在这里出现：不是为了热闹，而是为了把不同责任拆开。
但这也带来新的工程问题：
- Backend Agent 和 Frontend Agent 会不会改同一个文件？
- Reviewer 是审查最终补丁，还是审查每个子 Agent 的计划？
- Architect 的结论是否强制约束后续 Agent？
- 如果两个 Agent 给出相反建议，系统听谁的？
- 子 Agent 是否能调用工具，还是只能回答问题？
- 每个 Agent 能看到完整仓库上下文，还是只看到任务切片？
这些问题回答不清，多 Agent 只会把单 Agent 的不确定性放大。
分析问题
多 Agent 不是什么
多 Agent 不是把同一个 prompt 发给多个模型，然后投票。那只是 ensemble。
多 Agent 也不是让多个角色无限聊天。没有协议的讨论很容易重复、发散、互相迎合，最后仍然需要人类重新整理。
多 Agent 更不是 Tool Calling 的同义词。Tool Calling 是模型调用外部能力的机制；多 Agent 是多个具备目标、上下文和能力边界的执行单元被组织起来。Agent 可以被封装成工具，但这只是实现方式之一。
更准确地说：
一个 Agent 可以没有复杂工具，只负责评审；一个工具也可以不是 Agent，只是普通函数。多 Agent 架构要先分清这些层次。
多 Agent 的分层架构（推荐基线）
有，而且在生产系统里非常有必要。一个实用的多 Agent 系统，通常可以按四层拆分：
- Orchestrator 主控层：负责任务理解与拆解、计划制定、任务分发、进度协调、结果聚合与最终决策。
- Agent 通信层：负责 Agent 间协作协议（A2A）、任务/消息分发、状态同步、事件发布订阅与异步队列。
- Context / Blackboard 状态层：负责共享上下文、任务状态、知识记忆、产物管理、事件日志与审计追踪。
- Tool / MCP 执行层：负责能力接入与执行，包括 MCP tools、内部工具、外部 API、权限控制与执行监控。
这个分层的核心价值是把“决策、协作、状态、执行”四类复杂度解耦，避免 Orchestrator 直接耦合所有工具与状态细节。
进一步落地时，可以在四层之外增加横切保障：安全与权限、监控告警、日志审计、性能与成本治理、配置与版本管理。
什么时候值得多 Agent
多 Agent 适合的不是“所有复杂任务”，而是具备明显角色边界、并行空间或审查需求的任务。
如果任务不能拆，或者最终只是一次短回答，多 Agent 往往只会增加成本和延迟。
任务类型拆解
多 Agent 系统通常包含四类角色。它们不一定都是真 Agent，也可以由程序、规则或普通模型调用承担。
很多失败来自角色混用：让 Worker 自己决定范围，让 Reviewer 自己修改代码，让 Planner 自己执行高风险动作。角色越多，边界越要清楚。
收益和成本判断
多 Agent 的收益主要来自四点：
- 分工：每个 Agent 只处理更小、更明确的上下文。
- 并行：独立任务可以同时推进。
- 制衡：评审 Agent 可以从不同角度挑战方案。
- 复用：同一个专家 Agent 可以被多个流程调用。
成本也很真实：
- 调用次数增加，token 成本和延迟上升。
- 需要任务状态、消息协议、产物格式和合并逻辑。
- 需要处理重复劳动、冲突结果和职责漂移。
- 需要更细的权限、工具范围和上下文隔离。
- Eval 不能只看最终答案，还要评估协作过程。
多 Agent 的工程目标不是让系统“更像团队”，而是让复杂任务更可拆、更可控、更可验证。
列举方案
多 Agent 常见实现方式可以拆成四类。本专题建议按顺序阅读。
方式一：Supervisor 调度多个 Agent
有一个主控 Agent 或程序化 Orchestrator 负责任务拆分、分配、汇总和最终决策。子 Agent 接收明确任务，返回结构化结果。
适合：开发任务、运营分析、复杂客服、企业流程自动化。
重点文章：Supervisor 调度式多 Agent。
方式二：Agent-as-Tool
把某个 Agent 封装成工具，由主 Agent 在需要时调用。主 Agent 不关心内部执行细节，只接收结果、证据和状态。
适合：让 Claude Code、Codex、内部知识助手、数据分析助手等作为可调度能力接入。
重点文章：Agent-as-Tool：把 Agent 封装成工具。
方式三：流水线式多 Agent
多个 Agent 按固定阶段依次工作，例如“研究 -> 方案 -> 实现 -> 测试 -> Review”。控制流稳定，每个阶段有输入输出契约。
适合：内容生产、代码迁移、报表分析、合规审核、上线流程。
重点文章：流水线式多 Agent 协作。
方式四：多角色评审和辩论
多个 Agent 不一定执行工具，而是从不同角色审查同一问题，输出反对意见、风险清单或改进建议，再由仲裁者收束。
适合：方案评审、PR Review、产品决策、安全审查、复杂取舍。
重点文章：多角色评审与辩论式 Agent。
这些方式不是互斥的。生产系统经常组合使用：Supervisor 负责调度，Worker 以 Agent-as-Tool 接入，主流程按流水线推进，关键节点加入 Reviewer。
决策判断
方案选型表
反模式
第一种反模式：为了“智能”把所有角色都做成 Agent。
很多角色应该由程序承担，例如状态流转、权限校验、预算控制、最终写入。模型适合判断和生成，不适合独自承担系统控制权。
第二种反模式：没有任务契约，只让 Agent 自由聊天。
自由聊天适合头脑风暴，不适合生产任务。生产多 Agent 至少要有输入、输出、完成条件、失败条件和责任边界。
第三种反模式：所有 Agent 共享完整上下文。
共享上下文看似方便，实际会带来上下文污染、权限扩大和成本上升。子 Agent 应该看到完成任务所需的最小上下文。
第四种反模式：没有最终仲裁者。
多个 Agent 产生冲突时，不能靠它们继续讨论到自然收敛。系统必须有仲裁策略：规则优先、证据优先、Reviewer 阻断、人类确认或主控 Agent 决策。
第五种反模式：只评估最终结果。
多 Agent 的问题常发生在协作过程里：重复调用工具、互相覆盖结果、忽略上游约束、评审未被采纳。Eval 要覆盖任务分解、子结果、冲突处理和最终合并。
结论收束
多 Agent 架构不是 Agent 能力的自然升级，而是一种复杂任务的组织方式。
当任务能被清晰拆分、需要并行、需要独立评审或需要复用专家 Agent 时，多 Agent 才有价值。否则，单 Agent、Workflow、Tool Calling 或普通模型调用往往更便宜、更稳定。
最低可上线的多 Agent 系统，至少要把五件事设计清楚：谁拆任务、谁执行、谁审查、谁仲裁、谁对副作用负责。
工程清单
- 场景边界：任务是否真的需要多个角色或多个执行流。
- 任务拆分：每个子任务是否有明确输入、输出、完成条件和失败条件。
- 编排器：任务分配、状态管理、预算和最终决策由谁负责。
- 上下文隔离：每个 Agent 是否只看到完成任务所需的最小信息。
- 工具权限：每个 Agent 能调用哪些工具，是否按读写和风险分级。
- 协作协议：Agent 之间通过消息、文件、任务队列还是工具结果通信。
- 产物格式：子 Agent 输出是否结构化，是否包含证据、置信度和风险。
- 冲突处理：多个结论不一致时如何仲裁。
- 并发控制：哪些任务可以并行，哪些必须串行等待。
- 成本预算：模型调用次数、token、工具调用、耗时是否有限制。
- 失败恢复：子 Agent 失败后是重试、降级、换 Agent 还是转人工。
- Eval：是否评估任务拆分、子结果质量、评审命中率和最终结果。
- 审计回放：是否能复盘每个 Agent 看到了什么、做了什么、产出了什么。