多Agent协作为什么必须有主控角色
把多 Agent 协作中的主控角色讲成一个可落地的控制面：它负责定义目标、规划任务图、分派上下文、控制工具权限、仲裁冲突、保存状态和收口结果。主控可以是主 Agent、工作流引擎、代码调度器和人工 owner 的组合，而不是一个万能 LLM 总管。
多 Agent 协作听起来很诱人：一个 Agent 做调研，一个 Agent 写代码，一个 Agent 审稿，一个 Agent 画图，一个 Agent 发报告。每个 Agent 都像一个专业同事，大家并行工作，看起来就能把等待时间压缩。
但实际做过多 Agent 系统的人，很快会遇到一个朴素问题：谁说了算？
如果没有主控角色，多个 Agent 往往会出现几类典型混乱：重复搜索同一个问题，遗漏关键分支，对同一份状态做相互冲突的修改，用不同口径解释同一个目标，把低风险任务做得过度复杂，把高风险动作当成普通步骤继续推进。最后看起来是“多 Agent 协作”，实际变成“多个模型同时制造不确定性”。
这里说的主控角色，不一定是一个会聊天的“总管 Agent”。它可以是一个主 Agent，可以是工作流引擎，可以是代码里的调度器，可以是人工 owner，也可以是几者组合。关键不在名称，而在它承担六件事：定义目标、拆分任务、分派上下文、控制工具权限、仲裁冲突、收口结果。
主控不是多一层管理，而是多一层确定性
很多人反感“主控”，是因为听起来像把灵活的 Agent 团队又变成层级官僚。这个理解不准确。多 Agent 系统里的主控，不是为了让每个 Agent 少思考，而是为了让系统整体更可预测。
OpenAI Agents SDK 的 orchestration 文档把两种模式讲得很清楚：handoff 适合让专家 Agent 接管某个分支；agents-as-tools 适合 manager-style 工作流，主 Agent 保持最终回答责任，把专家当成有边界的能力来调用。也就是说，主控层可以选择“谁接管”和“谁只是帮忙”，这两件事本身就需要判断。
Anthropic 在介绍多 Agent research system 时也提到，lead agent 会把查询拆成子任务并描述给 subagents；每个 subagent 需要目标、输出格式、工具和来源指导、清晰任务边界。没有详细任务说明，Agent 容易重复工作、留下缺口或找不到必要信息。
这两个资料指向同一个结论：多 Agent 协作不是把多个模型扔进同一个房间。它需要一个能设计任务边界、控制上下文流动、判断何时结束的主控层。
主控带来的确定性，主要体现在四个方面。
第一，任务边界确定。谁负责调研，谁负责写作，谁负责验证，谁负责生图，谁不能碰发布动作，要写清楚。
第二，上下文边界确定。不是所有 Agent 都需要看到全部聊天记录、全部源文件和全部工具。上下文越乱，越容易跑偏。
第三，输出边界确定。每个子 Agent 交付的是证据、代码、草稿、审查意见，还是最终答复？格式不同，质量门槛也不同。
第四，责任边界确定。最终结果错了，系统要能知道是哪一步出错，而不是把问题归咎于“多 Agent 集体行为”。
没有主控时，最常见的五种失败
第一种失败是重复劳动。三个研究 Agent 同时搜同一个关键词，打开同一批页面，最后各自写一段相似摘要。用户看到的是“好多 Agent 都参与了”，实际得到的只是重复 token 消耗。
第二种失败是分工空洞。主控没有把任务切细，只说“你们分别调研一下市场、技术和风险”。于是市场 Agent 也讲技术，技术 Agent 也讲风险，风险 Agent 也讲市场。最后每份结果都宽泛，但没有一份足够深。
第三种失败是状态冲突。一个 Agent 认为目标已经改成 A，另一个 Agent 仍按 B 执行；一个 Agent 更新了文件，另一个 Agent 基于旧版本继续写；一个 Agent 说某步骤已完成，另一个 Agent 没有验证就继续依赖它。
第四种失败是权限漂移。原本只让某个 Agent 读资料，后来它为了完成任务开始调用写操作；原本只让 Agent 生成草稿，后来它顺手触发发布、发送邮件或修改生产配置。没有主控层，工具权限很容易从“完成任务”滑向“做过头”。
第五种失败是收口失败。多个 Agent 各自给出结论，没人合并冲突，没人检查引用，没人删掉重复，没人对最终版本负责。最后系统把几段结果拼起来，看似完整，实际上没有一个清晰口径。
这些失败不是模型不够聪明造成的，而是协作结构没有设计好。人类团队也一样：如果没有项目负责人、接口约定、状态同步和验收标准，再优秀的人也会互相踩线。
主控角色到底做什么
一个成熟的主控角色，至少要做七件事。
第一，解释目标。用户说“帮我做一个竞品调研”，主控要把目标改写成可执行任务：比较哪些竞品，输出给谁看，时间范围是什么，哪些问题不回答，哪些来源优先。
第二，规划任务图。主控要判断任务是顺序执行、并行执行、循环修正，还是需要人工审批。Google ADK 的 workflow 文档提到，随着 agentic application 变复杂，把它做成单一 monolithic agent 会更难开发、评估和维护；把多个 agent 和可执行节点组合成 workflow，可以带来 predictability、reliability 和 structure。主控层更像这种结构的入口。
第三，分派子任务。每个子 Agent 不该只收到一句“你去研究这个”。它需要明确目标、输入材料、可用工具、禁止动作、输出格式、截止条件。Anthropic 提到，早期简单短指令会让 subagents 误解任务或做重复搜索，这正是分派质量的问题。
第四，控制上下文。主控要决定每个 Agent 看到什么，不看到什么。写作者不一定需要原始密钥，审稿 Agent 不一定需要全部聊天，生图 Agent 不一定需要内部发布 token。上下文不是越多越好，而是足够完成任务且不污染判断。
第五，管理工具权限。OpenAI 的 guardrails 和 human review 文档把控制点分成 input/output/tool guardrails 和 human-in-the-loop approvals。主控要知道哪些工具可以自动执行，哪些工具需要暂停等待人批准，哪些工具根本不该给某个 Agent。
第六，仲裁冲突。多个 Agent 给出不同结论时，主控不能简单投票。它要看证据等级、时间新旧、来源可靠性、任务范围和风险级别。必要时让 Agent 补证据、让 verifier 复核，或者把不确定写进最终报告。
第七，收口结果。主控要把子任务产物变成一个面向用户的最终输出：删重复、合并结构、保留证据、标注风险、确认下一步。OpenAI 的 manager-style workflow 里，主 Agent 保持最终回答责任，正是这个含义。
主控可以是四种形态
第一种是主 Agent。它用自然语言理解目标，动态拆任务，调用 specialist agents，最后生成用户可读结果。OpenAI 的 agents-as-tools 就适合这种 manager-style 工作流：专家帮忙，但主 Agent 负责最终回答。
第二种是工作流引擎。它不一定靠模型判断每一步，而是用图、状态机、队列和门禁控制流程。比如先调研，再写稿，再校验，再生图，再 dry-run。Google ADK 提到 graph-based workflows、dynamic workflows、collaborative workflows；LangGraph 也常用 supervisor、swarm、graph 等结构来处理多 Agent 流程。工作流引擎的好处是可预测，坏处是灵活性需要通过代码设计。
第三种是代码调度器。它把 Agent 当成函数或工具，显式控制输入、输出、重试、并发、日志和状态。Microsoft Research 的 AutoGen 论文把多 Agent 应用描述为由多个可对话、可定制、可结合 LLM、人类输入和工具的 Agent 组成，并允许开发者用自然语言和代码定义灵活 conversation patterns。这里的“代码定义”很重要，因为生产系统不能只靠临场对话。
第四种是人工主控。对高风险任务，人仍然是 owner。人决定目标、批准敏感动作、判断冲突、承担最终发布责任。Agent 可以做大量工作，但不代表可以取消人类责任。
现实系统常常是混合形态：一个主 Agent 做任务理解，workflow engine 控制阶段，代码调度器保存状态，人类 owner 审批高风险动作。主控不是某个单点神经中枢，而是一套控制结构。
什么时候该 handoff，什么时候该 agents-as-tools
多 Agent 系统里，一个关键设计问题是：让专家接管，还是让专家只提供结果？
handoff 适合“接下来这一段确实应该由专家直接面对用户”。例如客服系统里，账单问题交给账单 Agent，退款问题交给退款 Agent。OpenAI 文档说，handoff 适合 specialist should take over conversation 的分支，控制权会转移给 specialist agent。
agents-as-tools 适合“专家只做有边界的子任务，最终口径仍由主 Agent 负责”。例如研究报告里，文献 Agent 负责找论文，代码 Agent 负责看仓库，审稿 Agent 负责挑错，但最终报告由主 Agent 汇总。OpenAI 文档明确说，agent.asTool() 用于主 Agent 应继续负责最终回答、把专家当作 helper 的场景。
很多任务失败，是因为把这两种模式混用了。明明需要统一口径，却让多个 Agent 轮流接管用户；明明只需要某个专家查一个事实，却让它开始重写整体计划。
一个简单判断是：如果用户需要的是一个统一结果，就优先 agents-as-tools 或 supervisor；如果用户需要进入某个专业流程，就 handoff；如果任务有固定阶段，就用 workflow；如果动作高风险，就加人工审批。
主控不是越强越好
虽然本文强调“必须有主控”，但主控也会带来问题。最常见的问题是信息转述损失。
LangChain 在 multi-agent architecture benchmark 中描述过 supervisor 架构：单个 supervisor 接收用户输入，委派给 sub-agents，sub-agent 返回后控制权回到 supervisor，只有 supervisor 可以回复用户。这个结构很通用，但他们的实验也指出，supervisor 在转述 sub-agent 回答时可能出现“telephone”问题，也就是信息在转述中损失或变形。
这提醒我们：主控不能变成“所有信息都由我重新说一遍”的瓶颈。
改进办法有几个。
第一，让子 Agent 输出结构化结果，而不是长篇自由文本。主控只合并字段，不随意改写事实。
第二，保留原始证据和引用。主控可以摘要，但不能吞掉来源。
第三，允许转发高质量子结果。LangChain 提到 forward message 可以减少 supervisor 错误转述 sub-agent 内容的问题。这个思想很实用：有些内容不需要主控重写，只需要主控确认和转发。
第四，给主控做验收门禁。主控自己也会错，所以最终输出前要有校验器、测试、事实检查或人工审阅。
第五，不要让主控看到无关噪声。主控上下文过载时，会误判任务状态，也会把子 Agent 的中间草稿当成事实。
主控的目标不是“永远亲自解释一切”，而是让系统里的信息流、责任流和决策流有秩序。
一个可落地的主控设计模板
如果你正在设计一个多 Agent 系统，可以从一个五层模板开始。
第一层是任务入口。它负责解析用户意图、确认目标、识别风险、给任务编号。入口不急着分派，而是先把“完成定义”写清楚。
第二层是计划层。它决定任务图：哪些步骤顺序执行，哪些并行执行，哪些需要循环，哪些需要审批。计划层还要估算成本，避免简单问题开十个 Agent。
第三层是执行层。它包含各类 specialist agents：研究、代码、数据、文案、审稿、图像、发布检查。每个 Agent 都有明确工具、上下文和输出格式。
第四层是仲裁层。它处理冲突、失败、重试、证据不足和状态不一致。仲裁层可以调用 verifier，也可以暂停等待人。
第五层是收口层。它负责最终报告、文件包、发布 dry-run、状态更新和审计记录。收口层必须知道“未完成的东西不能写成已完成”。
这个模板不要求所有系统都复杂化。小任务可以把五层都放在一个主 Agent 提示词里；大任务则应该用代码、队列、数据库和审计日志明确分层。
主控要保存哪些状态
多 Agent 协作最怕“大家都以为自己知道当前状态”。主控必须保存状态，而且状态要比聊天记录更结构化。
至少需要保存：
- 任务目标和完成定义。
- 子任务列表、责任 Agent、状态、依赖关系。
- 每个 Agent 的输入、输出、工具调用摘要。
- 文件或数据版本。
- 冲突和待确认问题。
- 人工审批记录。
- 验证结果和失败原因。
- 最终交付物路径。
这些状态不一定都展示给用户，但必须存在。没有状态，系统就不能恢复；不能恢复，就不能承担长任务；不能承担长任务，多 Agent 只是一次性演示。
OpenAI sandbox agents 文档也提到，当任务依赖工作区文件、命令、脚本、产物、预览服务，或者需要人工复核后在同一 workspace 恢复时，sandbox 会更合适。这说明长任务协作不能只靠一段 prompt，它需要可检查的工作区和可恢复状态。
多 Agent 什么时候值得用
不是所有任务都需要多 Agent。一个简单问答、一个短摘要、一个小脚本修改，单 Agent 往往更便宜、更稳。
多 Agent 值得用，通常有四个条件。
第一，任务可以自然拆成独立子问题。比如研究不同市场、检查不同代码模块、生成不同媒体资产。
第二，子任务需要不同工具或不同专业上下文。比如一个 Agent 看论文，一个 Agent 查 GitHub，一个 Agent 跑测试，一个 Agent 写面向用户的总结。
第三，结果需要交叉验证。一个 Agent 生产，另一个 Agent 审查，第三个 Agent 做事实或测试门禁。
第四，任务足够长，值得用并行和状态管理换效率。
如果任务不满足这些条件，多 Agent 可能只是增加噪声。主控角色的第一职责之一，就是判断“这次到底要不要多 Agent”。
人类主控仍然不可替代
多 Agent 系统可以自动拆任务、自动调用工具、自动合并结果，但它不应该自动承担组织责任。
涉及客户承诺、正式发布、财务、医疗、法律、安全、生产系统、隐私数据时，人类主控必须在环。OpenAI 的 guardrails 和 human review 文档也把 side effects、sensitive MCP actions、shell commands 等场景列为适合 human-in-the-loop approvals 的控制点。
人类主控不需要手工做所有事，但需要决定边界：哪些动作可以自动做，哪些必须审，哪些永远不让 Agent 做。成熟的自动化，不是把人拿掉，而是让人只在关键决策点出现。
这也是为什么本文说“主控角色”而不是“主控 Agent”。如果把主控完全交给一个模型，系统仍然可能在高风险节点失控。最稳的架构，是模型主控负责规划和汇总，代码主控负责状态和权限，人类主控负责价值判断和最终责任。
上线前的主控检查清单
一个多 Agent 系统上线前，可以用这份清单自查：
第一，是否有唯一任务 owner？如果最终结果出错，谁负责判断和修复？
第二，是否有明确完成定义？每个 Agent 是否知道自己交付什么？
第三，是否区分 handoff、agents-as-tools、workflow 和人工审批？
第四，是否限制每个 Agent 的工具、文件和上下文范围？
第五，是否保存结构化状态，而不是只保存聊天记录？
第六，是否有冲突仲裁规则？来源冲突、文件冲突、结论冲突怎么处理？
第七，是否有验证门禁？代码要测试，事实要来源，图片要 manifest，发布要 dry-run。
第八，是否有失败恢复路径？某个 Agent 失败后，能否重跑单个子任务，而不是整个任务重来？
第九，是否有审计留痕？能否回看谁调用了什么工具、改了哪些文件、为什么继续下一步？
第十，是否明确哪些动作需要人批准？尤其是写操作、外部发送、正式发布、生产系统变更和敏感数据访问。
结论：多 Agent 的重点不是更多 Agent，而是更好的控制面
多 Agent 协作的价值，不在于“数量多”。它有价值的地方，是让复杂任务被拆到合适的人、合适的工具、合适的上下文里执行，然后再被可靠地合并回来。
没有主控，多 Agent 会把复杂性扩散到每个角落：谁都在行动，谁都不完全负责。有效的主控，则把复杂性收束成可以检查的任务图、状态表、权限边界、冲突记录和最终交付。
最好的多 Agent 系统，看起来不一定热闹。它可能只有少数几个专业 Agent，一条清晰工作流，一个严格的状态记录，再加上必要的人类审批。但它能做到一件朴素而重要的事：让每一步都知道自己为什么存在，完成后交给谁，失败时怎么恢复，最终结果由谁负责。
这就是主控角色的意义。它不是给 Agent 团队套上枷锁，而是让 Agent 团队能进入生产工作流。