什么时候需要多 Agent：收益、成本与拆分边界
“一个 Agent 不够，就再加几个 Agent”，是多 Agent 系统最常见、也最昂贵的误解。
多 Agent 并不会凭空增加模型智力。假如几个角色使用相同模型、读取相同上下文、调用相同工具，它们很可能只是用更多 Token 重复同一条思路。真正值得拆分的，不是聊天框里出现了几个名字，而是系统里是否存在清晰的专业边界、上下文边界、权限边界或并行边界。
这一讲先不讨论具体编排语法，只回答更基础的问题：什么情况下，一个 Agent 加工具已经足够；什么情况下，引入多个 Agent 的收益才可能大于组织成本。
一、先分清 Workflow、Agent 与 Multi-Agent
Section titled “一、先分清 Workflow、Agent 与 Multi-Agent”在工程讨论里，这三个词经常混在一起。
- Workflow：控制流主要由代码决定，例如先检索、再总结、最后校验。
- Agent：模型根据当前状态决定下一步动作，可以选择工具、继续思考或停止。
- Multi-Agent：系统存在两个以上具有独立指令、上下文、工具或职责的决策单元，并需要解决它们之间的路由、协作和冲突。
一个程序连续调用三次模型，不一定是三个 Agent。一个“研究员”“写作者”“审核员”共用完整聊天历史、共用所有工具，而且由固定代码顺序调用，也更接近带角色提示词的 Workflow。
反过来，一个系统即使界面上只有一个助手，只要背后把任务交给拥有独立上下文和权限的专业 Agent，再由 Manager 汇总，它就是多 Agent 架构。
判断标准不是角色名称，而是控制权和状态边界。
二、为什么行业总想把 Agent 变成“团队”
Section titled “二、为什么行业总想把 Agent 变成“团队””人类组织通过分工处理复杂工作，于是工程师很自然地把“研究员：工程师：审稿人”映射到模型系统。这个类比有启发，但不能照搬。
人类分工具有三个前提：不同成员长期积累不同能力；沟通成本相对可控；责任可以落到具体的人。模型 Agent 往往使用同一个基础模型，所谓“不同能力”主要来自不同上下文、工具、权限和验证器。如果这些差异不存在，角色扮演只是提示词表演。
Anthropic 在 Building Effective AI Agents 中强调，应从最简单、可行的方案开始，只在确实能改善结果时增加复杂度。[1]
图 1：官方工程指南把 Workflow 与 Agent 放在同一条复杂度谱系上。图片来自 Anthropic 官方页面，来源见文末。
所以，多 Agent 不是“更先进”的默认形态，而是一种用组织复杂度交换特定收益的设计。
三、值得拆分的五类真实收益
Section titled “三、值得拆分的五类真实收益”1. 专业化：工具和知识确实不同
Section titled “1. 专业化：工具和知识确实不同”例如一个企业助手要同时处理合同、数据库和代码仓库。合同 Agent 只读取法务知识库，数据 Agent 只运行只读 SQL，Coding Agent 则进入隔离仓库。三者的工具、权限和成功标准都不同。
此时拆分有实际价值：每个 Agent 的工具列表更短，指令更聚焦，评测集也能按领域建立。
如果只是把“写标题”和“写正文”分给两个同模型 Agent，却给它们相同材料和相同权限，收益通常有限。
2. 上下文隔离：避免所有信息都塞进同一个窗口
Section titled “2. 上下文隔离：避免所有信息都塞进同一个窗口”复杂任务会产生大量中间材料。把网页原文、日志、代码、讨论和验证记录全部共享给所有角色，会带来成本、注意力稀释和敏感信息扩散。
更合理的做法是：每个 Worker 只读取完成子任务所需的私有上下文，再把结构化结论交给 Manager。Manager 不需要看到每个浏览步骤，只需要证据、结论、置信度和未解决问题。
这里的价值不是“多说几轮”，而是形成上下文防火分区。
3. 并行：子任务真正相互独立
Section titled “3. 并行：子任务真正相互独立”研究五个互不依赖的项目、同时检查五个地区的政策、为一个变更运行多组独立测试，都适合扇出并行。
并行能降低墙钟时间，但前提是：
- 子任务之间没有隐含依赖；
- 资源配额允许并发；
- 汇总器能处理冲突和缺失；
- 下游不会被未完成的分支阻塞；
- 并行失败能够单独重试。
如果第二步依赖第一步生成的 Schema，强行并行只会制造返工。
4. 权限隔离：把风险限制在最小 Capability
Section titled “4. 权限隔离：把风险限制在最小 Capability”一个只负责检索的 Agent 不需要退款权限；负责生成补丁的 Agent 不应该自动合并；审核 Agent 最好没有写代码的工具。
多 Agent 可以成为权限架构的一部分：不同身份拿到不同工具和凭据，跨边界动作必须通过明确交接和审批。这样，即使某个上下文被恶意网页污染，风险也被限制在它拥有的最小权限内。
这比在一个“全能 Agent”的 Prompt 里写“请谨慎”更可靠。
5. 独立验证：让执行者不能自证成功
Section titled “5. 独立验证：让执行者不能自证成功”执行 Agent 容易把自己的解释当成证据。独立验证器可以读取环境终态、测试结果或政策规则，却不沿用执行者的完整推理历史。
但“再找一个模型评价”仍然可能形成相关错误。真正有价值的验证应优先连接独立证据：测试、类型检查、数据库约束、业务 API、策略引擎或人工批准。
验证器之所以值得成为单独角色，是因为它拥有不同目标、不同工具，最好还有不同权限。
四、多 Agent 要支付哪些组织成本
Section titled “四、多 Agent 要支付哪些组织成本”每次交接都要决定传什么、用什么格式、怎样表达不确定性。自然语言摘要会丢细节，完整历史又会抵消上下文隔离的收益。
状态一致性成本
Section titled “状态一致性成本”两个 Agent 可能同时修改同一文件、更新同一订单或对“当前版本”有不同理解。系统需要版本号、锁、幂等键或冲突合并规则。
责任归属成本
Section titled “责任归属成本”当结果错误时，是路由错、Worker 错、Manager 汇总错，还是工具返回过期数据？没有 Trace 和明确 Owner，多 Agent 会把故障分散到对话里。
角色越多，模型调用、序列化、重试和等待越多。并行可以降低墙钟时间，却不一定降低总计算量。
Agent 之间传递内容也可能传递 Prompt Injection、敏感数据和未经授权的指令。消息本身必须带来源、作用域和信任级别。
单 Agent 可以按任务终态打分；多 Agent 还要区分路由质量、子任务质量、交接完整性、冲突处理和总体结果。系统可观察面显著扩大。
五、一个实用的拆分判断表
Section titled “五、一个实用的拆分判断表”在增加 Agent 前，可以依次问六个问题。
| 问题 | “是”意味着什么 |
|---|---|
| 子任务是否需要不同工具或知识源？ | 可能需要专业 Agent |
| 是否需要隔离敏感上下文？ | 可能需要独立上下文与身份 |
| 子任务是否能够真正并行？ | 可能适合 Worker 扇出 |
| 是否存在互斥权限？ | 应拆出最小权限角色 |
| 是否需要独立、不可自证的检查？ | 应拆出验证器或审批者 |
| 单 Agent 的失败是否能在评测中稳定复现？ | 有证据支持增加复杂度 |
如果前五项大多为“否”，最后一项也没有稳定失败样本，先优化工具描述、上下文、状态机和验证器通常更划算。
六、四种常见任务怎么判断
Section titled “六、四种常见任务怎么判断”查询订单、解释政策、提交退款存在明显权限差异。可以用一个对话 Agent 加三个受控工具，也可以把政策判断与资金操作拆开。是否多 Agent 不是关键；关键是退款动作不能由模型自行扩大权限。
多个主题可以并行检索，研究 Worker 只返回带来源的证据卡，主编负责去重和叙事。这里多 Agent 的主要收益是并行和上下文隔离。
一个 Agent 通常可以读取 Issue、修改代码、跑测试。只有当仓库很大、调查路径可分离，或高风险变更需要独立审查时，再引入检索 Worker、实现 Worker 和验证器。
“选题 Agent：写作 Agent：润色 Agent”经常只是多轮 Prompt。若三者没有不同数据和评价标准，不必伪装成团队。更有效的方式是建立资料证据层、正文生成层和可执行的事实核查规则。
七、热门框架怎样表达这种选择
Section titled “七、热门框架怎样表达这种选择”OpenAI Agents SDK 提供 Agent、Tool、Handoff、Session 和 Tracing 等较少的原语，允许主 Agent 把其他 Agent 当工具调用，也允许交接控制权。[2][3]
图 2：OpenAI Agents SDK 的重点不是堆角色，而是用少量原语表达工具、交接和 Trace。GitHub 快照日期见文末。
LangGraph 把多 Agent 视为上下文工程与控制流问题，强调每个 Agent 看见什么、谁决定下一步以及状态怎样流动。[4]
CrewAI 用 Crew 表达角色化自治协作，用 Flow 表达事件驱动、较确定的业务过程。[5] CAMEL 的 Societies 和 Workforce 则更系统地研究角色扮演、协调者、Worker 和批评者。[6][7]
图 3：CrewAI 是高关注角色化多 Agent 项目。这里引用它的 Crew/Flow 边界，不把 Star 当作生产效果。来源见文末。
这些项目的共同点不是“越多越好”，而是提供不同的职责和控制结构。框架能让编排更方便，却不会替你证明拆分是必要的。
八、20：40 分钟实践：用数据决定要不要拆
Section titled “八、20：40 分钟实践：用数据决定要不要拆”选择一个你已经做过的单 Agent 任务，准备 10 个历史样本，不要先改架构。
第一步，记录单 Agent 的四项数据：任务成功率、P50/P95 延迟、Token 或费用、人工介入次数。
第二步，把失败按原因分类：缺少领域知识、上下文过载、工具误选、权限过大、无法验证、外部系统失败。
第三步，只针对占比最高且能通过边界解决的一类失败，设计一个额外角色。例如把独立检索支线交给 Worker，或把写权限移到审批 Agent。
第四步，在同一组样本上 A/B 运行。除了最终成功率，还要统计交接失败、总调用量和调试时间。
一个可接受的实验记录表如下：
variant,success,p95_latency,total_calls,human_interventionssingle,7/10,42s,28,3two_agents,8/10,55s,46,2如果成功率只增加一点，却显著提高延迟和故障面，未必值得上线。多 Agent 的收益必须由任务指标证明，而不是由角色数量证明。
九、设计时最容易踩的五个坑
Section titled “九、设计时最容易踩的五个坑”- 按人类职位拆，不按系统边界拆。 “产品经理 Agent”可能既没有专属工具，也没有独立状态。
- 所有 Agent 共享完整上下文。 既浪费成本，也让敏感信息无边界扩散。
- 让 Manager 吞掉所有原始材料。 汇总节点重新成为上下文瓶颈。
- 把讨论轮数当质量。 多角色相互附和不会产生独立证据。
- 没有单 Agent 基线。 最终无法判断复杂度究竟解决了什么。
十、这一讲的结论
Section titled “十、这一讲的结论”多 Agent 的价值来自可验证的边界：专业化、上下文隔离、并行、最小权限和独立检查。它的代价则是通信、状态、延迟、安全和评测复杂度。
因此，正确顺序不是先画组织架构，而是先找到单 Agent 在真实样本上的稳定失败，再判断这个失败能否通过一个明确边界被隔离。边界说不清，就先不要拆。
下一讲进入具体编排模式：Manager、Handoff、并行和群聊分别把控制权放在哪里，又该怎样选择。
[1] Anthropic, Building Effective AI Agents. https://resources.anthropic.com/building-effective-ai-agents
[2] OpenAI, OpenAI Agents SDK. https://openai.github.io/openai-agents-python/
[3] OpenAI, Agent orchestration. https://openai.github.io/openai-agents-python/multi_agent/
[4] LangChain, Multi-agent systems. https://docs.langchain.com/oss/python/langchain/multi-agent
[5] CrewAI, Core Concepts. https://docs.crewai.com/core-concepts/Agents
[6] CAMEL, Societies. https://docs.camel-ai.org/key_modules/societies
[7] CAMEL, Workforce. https://docs.camel-ai.org/key_modules/workforce