架构师（JiaGouX）
我们都是架构师！
架构未来，你来不来？
《四大多 Agent 架构详解（一）》里，我们把 Workflow 放在同一个问题上看：评估一个新模型能不能接入企业在线客服。资料收集、基准测试、安全审查、方案成稿，顺序由代码控制；每个节点有自己的输入、输出和检查点。
但评估真正开始后，下一步未必总是一样。第一轮资料可能先暴露成本问题，也可能先撞到数据合规风险；性能数据如果已经足够，继续搜索反而是在消耗预算。刚拿到的结果会改变后面的工作，路径很难在流程代码里一次列完。
这时，下一步就要跟着当前证据走：该补哪一项数据、该找哪个专家、风险是否已经足以暂停任务，都由一个中央 Agent 先做路由，再把结果收回来。它通常被称为 Supervisor。这里的“中央”说的是控制关系，并不意味着所有判断都只能由模型完成；预算、权限、超时和硬性阻断条件仍应由运行时约束。
Supervisor 的价值在于把动态路由交给模型；它的风险也在同一个地方：主管必须同时承担派工、上下文管理和最终收口。
先把控制关系看清
Supervisor 不是“多放几个 Agent”这么简单。它改变的是谁决定下一步。
用户任务
↓
中央 Supervisor
↙ ↓ ↘
性能 Agent 安全 Agent 业务 Agent
\ ↓ /
结果回到 Supervisor
↓
最终方案中央 Agent 负责理解目标、选择子 Agent、给出子任务边界、判断结果是否足够，并综合出统一交付物。子 Agent 只处理自己的职责，通常不直接知道其他子 Agent 的中间过程。
这是一种中心辐射结构。每次派工都有一个发起者，每份结果都有一个收口点，审计时可以沿着 Supervisor 的调用轨迹回放。对刚开始搭建的系统来说，这个关系很容易查清楚。
图 1：Supervisor 持有控制权，性能、安全和业务 Agent 各自处理局部问题，结果和状态最终回到同一个收口点。
如果把它放回传统软件工程里看，Supervisor 有点像调度器、编排器和控制器叠在一起：调度器决定把工作交给谁，编排器维护任务之间的关系，控制器根据当前状态决定继续、重试还是暂停。区别在于，传统系统更多依赖队列、规则和固定状态机，Supervisor 还会把中间结果交给模型判断。
这个类比能帮我们找到工程抓手，但不能把两者完全画等号。模型判断带来了灵活性，也带来了不稳定；所以预算、权限、超时和硬性阻断条件仍然应该由运行时和工具层兜底。
代价也从这里开始。性能 Agent 发现的事实如果会影响安全 Agent 的判断，必须先回到 Supervisor；Supervisor 还得看懂这条事实的影响，再重新派发。如果转述不完整，信息就会在中间被压缩或丢失，子 Agent 各自完成任务也未必能拼出正确结论。
同一个任务，路径会怎样变化
我们把“评估新模型是否适合接入在线客服”这件事跑一遍，路径可能是这样：
1. Supervisor 读取目标、已有资料和预算
2. 发现缺少延迟与成本数据，调用性能 Agent
3. 性能 Agent 返回测试结果，并标记高峰延迟异常
4. Supervisor 根据异常追加安全 Agent，检查降级链路和数据流向
5. 安全 Agent 发现某个外部接口会接收敏感字段，返回阻断条件
6. Supervisor 要求业务 Agent 评估替代方案，再统一生成技术方案这条轨迹里，第四步不是固定流程里的“下一个节点”，而是被高峰延迟异常触发的。安全 Agent 要检查降级链路，是因为延迟问题可能把更多请求导向备用接口，而备用接口又可能改变数据流向。安全审查如果直接发现阻断风险，业务 Agent 甚至不会被调用，任务会停在人工确认处。
图 2：性能结果改变后续路径；追加安全审查、暂停和人工确认，都由当前证据与终止条件触发。
所以我更在意日志能不能回答四个问题，而不只是记下一次工具调用：
subtask | |
reason | |
input_ref | |
stop_condition |
如果日志里只有“调用了安全 Agent”，没有派工原因和输入版本，后面就很难区分是 Supervisor 判断错了，还是子 Agent 拿到了过期资料。reason 记录的是当时看见的证据，input_ref 记录的是子 Agent 实际读取的版本；两者缺一，回放时就只能靠猜。
派活有两种控制权形态
实现 Supervisor 时，最容易混淆的是“调用子 Agent”和“把控制权交给子 Agent”。它们都可以表现成一次派工，但信息流不同。
把 Agent 当成工具
OpenAI Agents SDK 把这种方式直接称为 agents as tools：中央 Agent 把专家暴露成一个可调用工具，专家运行完后返回结果，中央 Agent 继续持有控制权。
Supervisor ──调用性能工具──> 性能 Agent
Supervisor <──返回结构化结果── 性能 Agent
Supervisor 继续推理和派工这种形态适合 Supervisor 需要连续比较多个结果、控制最终回答格式，或者希望所有路由都留在外层的场景。子 Agent 的职责边界清楚，但它更像一次受控的函数调用。
这和传统系统里的函数调用、服务编排很像：调用方传入明确参数，得到结构化返回值，调用方继续执行。工程上要守住的是输入输出契约，不能因为名字里多了“Agent”就把这层约束放松了。
把控制权转移给子 Agent
另一种形态是 handoff。当前 Agent 调用一个交接工具，把会话和必要上下文交给指定的 Agent；接手者继续运行，是否回到原 Supervisor，要由后续的交接关系明确表达。
OpenAI 文档把 handoff 表示为一种工具调用，并允许为交接记录原因、过滤输入历史、校验结构化参数。判断标准不在工具名字，而在交接之后谁拥有下一步的决定权。
从研发流程看，handoff 更像一次明确的责任转移：问题分诊后交给安全同学，后续由安全负责人推进；如果还要回到总负责人收口，就必须把“回交”写进流程。只要责任归属没有记录，出了问题就很难判断是分诊错了、执行错了，还是收口时漏看了结果。
在 Supervisor 里，handoff 仍然可以服务于中心调度：子 Agent 完成工作后显式交回 Supervisor，中心再决定下一步。若交接后由子 Agent 自己继续选择同级 Agent，就已经靠近 Swarm 的控制关系，不能只因为都叫 handoff 就混为一谈。
收口不是“让主管写一段总结”
Supervisor 最后生成的文字只是交付物，不是系统状态。要判断能不能结束，Supervisor 得把结果放回任务上下文里核对：
证据是否齐全。 例如性能 Agent 必须返回测试环境、样本切片、延迟结果和失败用例，而不是一句“性能良好”。
阻断条件是否处理。 安全 Agent 返回敏感字段外发风险后，Supervisor 不能靠总结语气把风险覆盖掉；它需要重新派工、暂停任务或请求人工确认。
预算是否耗尽。 每次派工都会增加模型调用、上下文和等待成本。子 Agent 数量、工具调用次数、重试轮次和总时限都要有边界，否则“再查一个专家”会变成没有终点的默认动作。
工程上还有个常被忽略的问题：Supervisor 管理的不是一份越来越长的聊天记录，而是上下文窗口里的任务、证据、版本和预算。Andrej Karpathy 把这类工作称为 context engineering，重点在于如何填充上下文，而不只是把提示词写得更漂亮。子 Agent 返回整篇长报告，中心就得反复读取和压缩；返回结构化结论、证据引用和失败原因，中心才有机会把上下文控制在可用范围内。
一个可回放的中心状态，可以至少包含：
task_id
goal
dispatch_history[]
subtask_results[]
evidence_refs[]
budget_remaining
quality_status
termination_reasontermination_reason 尤其重要。它要能说明任务是因为证据满足条件而结束，还是因为预算用尽、风险阻断、子 Agent 超时或人工接管而结束。没有这个字段，成功和放弃很容易在最终文本里长得一样。
安全边界也不能由“中央”两个字自动解决。客服资料可能来自外部文档，同时又涉及用户隐私和写入工单等动作。Meta 提出的 Agents Rule of Two 建议，在 prompt injection 还不能可靠识别时，单次会话不要同时拥有三类能力：处理不可信输入、访问敏感系统或私有数据、改变状态或对外通信。如果业务确实需要三者，至少要把人工审批、独立校验或新的上下文窗口放在中间。Supervisor 可以负责把风险汇总出来，但不能替代权限隔离和工具级校验。
中央节点为什么容易变成瓶颈
Anthropic 对 orchestrator-subagent 模式的描述很接近这个结构：一个 lead agent 规划和派工，子 Agent 在各自上下文中完成职责，再把结果交回中心。它适合子任务边界清楚、相互依赖较少的工作；代码审查就是一个典型例子，安全、测试覆盖、代码风格和架构一致性可以分开检查，再由中心汇总。
但 Anthropic 也指出了这类模式的两个限制。中心先是信息瓶颈：一个子 Agent 发现的新事实，要先经过中心，中心还得意识到这个事实会影响另一个子 Agent，否则依赖关系就不会被重新路由。
默认串行又会限制吞吐。子 Agent 如果一个接一个执行，系统承担了多 Agent 的 Token 成本，却没有获得并行带来的速度收益。Anthropic 的 Research 系统因此让 lead agent 并行启动多个搜索 Agent，同时要求每个子任务写清目标、工具、输出格式和边界；他们也记录过简单问题派出过多 Agent、重复搜索和过度更新等失败模式。
Google Research 的受控评估把架构选择和任务属性放在了一起看。研究评估了 180 种 Agent 配置：在可并行的 Finance-Agent 任务上，centralized 架构相对单 Agent 提升 80.9%；在需要严格顺序推理的 PlanCraft 上，各种多 Agent 方案下降了 39% 到 70%。这不是 Supervisor 的通用收益承诺，只能说明在这组任务里，中心调度要建立在任务确实能拆开的前提上。
同一项研究还报告，独立并行但不互相校验的系统，错误放大达到 17.2 倍；带中心协调的系统为 4.4 倍。中心可以成为验证瓶颈，前提是它真的检查结果，而不是只负责把几段文本拼起来。
Karpathy 在讨论 autoresearch 时也碰到过同一个拐点。他把代码沿着一条同步提交线程推进的做法，视为规模化协作的限制，并设想让 Agent 异步探索不同研究方向。另一条帖子里，他描述 Agent 根据连续实验结果规划下一轮实验，累计做了约 700 次调整，最后把一个指标从 2.02 小时降到 1.80 小时。这段经历更值得借鉴的地方，不是“700 次”这个数字，而是每一轮都有可检查的结果，下一轮派工才有依据。
放回这个例子，Supervisor 适合的是这类动态任务：中间结果能改变路线，但每个分支仍然有清楚的验收指标。只有“多派几个 Agent 看看”而没有评估标准，中心很快就会变成排队点和摘要器。
什么时候适合用 Supervisor
我通常先看任务是否同时满足下面几件事：
子任务边界可以写清楚，且每个子 Agent 都有独立的输入、输出和验收条件； 下一步取决于中间发现，固定顺序会频繁改动； 最终需要一份统一交付物，或者需要一个位置集中做预算、权限和停止判断； 子 Agent 之间不需要持续直接交换大量中间状态。
开放式研究、复杂分析、按领域拆分的评估任务，通常更接近这个形态：需要动态选择专家，也需要一个中心把结果收回来。
图 3：两种架构都能调用多个 Agent，关键差别在路由由代码还是中央 Agent 决定；适用边界和工程代价也随之变化。
下面这些情况，我会先回到 Workflow：顺序稳定、每个节点都能提前定义、失败处理规则固定。此时让模型决定下一步，只会增加延迟和不确定性。
反过来，如果子 Agent 需要长期保留上下文并持续认领任务，中间发现必须直接通知多个协作者，或者任务本身需要平级 Agent 自由接力，Supervisor 可能就不够了。前者可以评估 Agent teams，后两者要进一步看共享状态、消息总线或 Swarm，继续给中央主管堆派工提示词通常解决不了问题。
别只设计一个“主管角色”
Supervisor 的难点不在于给它安排一个“主管”称呼，而在于把中心决策变成可以检查的控制面。放回前面的客服评估任务，我会先看四件事：
派给谁，要能解释。 路由依据应该落在任务状态和证据上，而不是只存在于一次不可追溯的模型输出里。
何时停止，要有条件。 结果满足验收标准、预算耗尽、风险阻断和人工接管，应该是不同状态。
结果怎么回来，要有契约。 子 Agent 返回结构化结果、证据引用、失败原因和版本，而不是一段无法复用的长文本。
中心失效，要能处理。 主管超时、上下文膨胀或重复派工时，系统至少要能暂停、恢复、缩减预算，或把任务交给人工处理。
这样看，Supervisor 不是把“聪明”集中到一个 Agent，而是把动态路由集中到一个可审计的位置。中心能否收口，取决于状态、证据和终止条件是否比最终文案更可靠。
当一个 Supervisor 下面还需要继续管理多个 Supervisor，问题就从“中心如何派工”变成了“多层中心怎样隔离上下文和责任”。下一篇进入 Hierarchical。
参考资料
Anthropic，Multi-agent coordination patterns: Five approaches and when to use them（https://claude.com/blog/multi-agent-coordination-patterns） Anthropic，How we built our multi-agent research system（https://www.anthropic.com/engineering/multi-agent-research-system） Google Research，Towards a science of scaling agent systems: When and why agent systems work（https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/） OpenAI Agents SDK，Tools：Agents as tools（https://openai.github.io/openai-agents-python/tools/） OpenAI Agents SDK，Handoffs（https://openai.github.io/openai-agents-python/handoffs/） Andrej Karpathy，关于异步大规模 Agent 协作的 X 帖子（https://x.com/karpathy/status/2030705271627284816） Andrej Karpathy，关于 autoresearch 实验迭代与 Agent swarm 的 X 帖子（https://x.com/karpathy/status/2031135152349524125） Andrej Karpathy，关于 context engineering 的 X 帖子（https://x.com/karpathy/status/1937902205765607626） Meta AI，Agents Rule of Two: A Practical Approach to AI Agent Security（https://ai.meta.com/blog/practical-ai-agent-security/） Simon Willison，New prompt injection papers: Agents Rule of Two and The Attacker Moves Second（https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/）
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
- 四大多 Agent 架构详解（一）：Workflow 如何把固定流程变成可回放的系统
- 从ReAct到AgentTeam：一个医疗系统研发任务里的信息流与责任边界
- Claude形式化费马大定理，给多Agent协作留下了什么？
- 面试官：讲一讲多 Agent 协作如何保持一致性
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
架构师
我们都是架构师！
关注架构师(JiaGouX)，添加“星标”
获取每天技术干货，一起成为牛逼架构师
技术群请加若飞：1321113940 进架构师群
投稿、合作、版权等邮箱：[email protected]