AI-Wiki

文档概览

原文讨论的重点不是哪种多智能体架构“更高级”，也不是先决定要拆几个 Agent、谁主谁副、是否还要单独加一个 lead，而是先问：子任务之间是否共享同一段上下文。

作者给出的总判断是：

多智能体架构里，最先该判断的不是“要拆几个”，而是这些子任务之间是否共享同一段上下文。能干净切开的用 Sub-Agent，必须共享状态的才上 Agent Team。

这意味着，架构决策的起点不是组织学上的“岗位分工”，而是信息流设计，即上下文如何被切分、保留、传播、压缩与同步。作者反复强调一句原则：Design around context boundaries, not roles，也就是“围绕上下文边界设计，而不是围绕角色设计”。

全文可归纳为三层判断：

默认先考虑单 Agent：如果同一个 Agent 一次性完成更省心，就不要为了“看起来更高级”而提前拆分。
上下文可切分时用 Sub-Agent：适合独立子任务，目标是隔离父上下文、把探索过程压缩成结论，并支持并行。
必须共享状态时用 Agent Team：适合持续协作任务，成员之间需要直接通信，且一方动作会即时影响另一方下一步。

关键事实

1. 核心判断标准：先问是否共享同一段上下文，而不是先问要不要多 Agent

原文最关键的判断标准不是“任务复杂不复杂”，而是：

子任务之间是否需要看到彼此的中间过程；
一个子任务的执行结果是否会立刻改变另一个子任务的下一步动作；
把这些事交给同一个 Agent 一次性做完，是否反而更省心。

如果这些问题的答案大多偏向“是”，那说明任务本质上共享同一上下文，强行拆开只是在沟通层制造额外成本。作者的明确结论是：不是先问要不要多 Agent，而是先问这些子任务到底是否共享同一段上下文。

2. 对“按岗位角色拆 Agent”的批评

作者批评了一类很常见但很容易搭歪的设计：面对复杂任务，先按 planner、developer、tester、reviewer 这类岗位角色拆 Agent。

这种方案在叙事上很顺，PPT 上也很漂亮，但真正接到 LLM 上跑，会出现一个核心问题：每一次 handoff 都会让信息变薄。

原文给出的具体丢失路径包括：

Planner 知道“这块代码之前刚被重构过，所以某个看似奇怪的判断其实是有原因的”，但这条上下文没有传给 Developer；
Developer 在修改中做了临时取舍，例如“这次先不改 token 校验顺序，因为会影响下游的 SSO”，这些取舍也没有沉淀下来；
到 Tester 时，能拿到的往往只剩一份相对干净的代码和简化后的说明，已经无法判断这次改动是否踩到了原有限制条件；
Reviewer 最终看到的是“看起来都过了”的结果，但真正的背景、原因、约束和折衷已经在交接中漏掉了。

作者认为，这不是模型智力问题，而是组织方式错了。岗位分工来自人类公司的人际协作模式，但 LLM 没有共享的非正式记忆，也不能靠“上次开会说过”来补足上下文缺口。LLM 能做出的判断，严格受限于它实际拿到的上下文。

因此，原文明确反对把“按角色拆 Agent”当成默认套路，指出质量不是被一次性砸坏的，而是在每一次交接中慢慢漏光的。

3. Sub-Agent 的定义与约束

原文将 Sub-Agent 定义为一种父子式编排结构：父 Agent 把一段定义清楚的工作派发出去，子 Agent 在自己的独立上下文中执行，执行完成后把结论返回给父 Agent。

作者特别强调返回的是“结论”，不是中间推理过程。

文中列出的 Sub-Agent 硬约束有四条：

子 Agent 之间不能直接通信；
子 Agent 不能再生新 Agent；
所有流量都必须经过父 Agent；
执行结束后只返回最终输出，不带中间思考。

作者指出，这些限制表面上像是在削弱能力，本质上是在保证系统的可控性。因为一旦允许子 Agent 任意互相交流、再扩展层级或持续传播中间思路，系统的信息流、成本和调试边界都会迅速失控。

4. Sub-Agent 的三类主要价值：隔离、压缩、并行

原文把 Sub-Agent 的价值归纳为三点，而且都直接与上下文管理有关，而不是“多开几个 Agent 就更智能”。

4.1 隔离父上下文，避免中间探索污染

子任务在自己的独立上下文中运行，不会把大量“先看看、再翻翻、又试试”的中间探索过程塞进父 Agent 的上下文窗口。这一点对长任务尤其关键，因为父 Agent 的上下文是稀缺资源，不应该被子任务的搜索噪音占满。

4.2 压缩探索过程为结论

子 Agent 对外返回的是结论，而不是完整过程。这样做相当于把一段乱糟糟的探索压缩成一个干净信号，方便父 Agent 汇总、比较与后续决策。作者认为，真正有复用价值的往往不是过程本身，而是最后沉淀下来的判断。

4.3 支持互不依赖子任务并行执行

因为子 Agent 之间不能直接通信、任务之间也不相互依赖，所以它们可以放心并行运行。原文举的场景是代码审查：一个看安全、一个看性能、一个看测试覆盖率，三者并发跑完再统一汇总，比串行逐个检查更划算。

5. 文中示例代码的关键信息：Claude Agent SDK 中 description 是路由信号

原文给出了一段 Claude Agent SDK 示例代码，用于说明典型的 Sub-Agent 形态。代码中使用 agents 定义了两个子代理：

security-reviewer：职责描述为 Find vulnerabilities and security risks；
performance-optimizer：职责描述为 Identify performance bottlenecks。

两个子代理都配置了：

prompt：分别设定为安全专家、性能工程师语境；
tools：使用 Read、Grep、Glob；
model：都使用 sonnet。

外层 allowed_tools 中包含了 Agent，表示父 Agent 可以调用子代理能力。

作者特别提醒了一个容易被忽略的细节：description 字段看似只是说明文字，实际上承担的是路由信号作用。父 Agent 如何判断某个子任务应该分配给哪个 Sub-Agent，核心依据之一就是这段描述。

因此：

description 写得含糊，路由就会含糊；
description 把边界写清楚，任务分发边界也会清楚。

这也把 Sub-Agent 编排和 LLM工具选择、工具描述设计联系了起来：写给人看的说明与写给 Agent 做分流决策的说明不是一回事，后者必须更强调能力边界、适用条件和排他性线索。

6. Agent Team 的关键特征

与 Sub-Agent 相对，原文把 Agent Team 描述为一个长期协作的小组，而不是一次性外包子任务的结构。

Agent Team 的关键特征包括：

上下文是共享的，而不是各自隔离；
成员之间可以直接对话，不必所有消息都通过父级中转；
存在持续性的状态层，进度、依赖、阻塞点都挂在其上；
某个 Agent 的动作会立刻影响其他 Agent 的下一步。

换句话说，Agent Team 的重点不在“角色更像组织结构”，而在它支持一组任务围绕同一持续状态进行联动。

7. Agent Team 的适用场景与成本

原文认为，Agent Team 适合那种强依赖、持续协作的软件项目类任务，典型特点是“做着做着会发现问题，然后需要互相调头”。

文中给出的典型例子包括：

前端改了接口契约，后端需要立刻知道；
测试发现某个用例挂了，开发要即时拿到失败上下文；
产品发现需求理解错了，整个链路要回退一步。

在这类任务中，如果仍然要求所有信息都通过一个父 Agent 统一中转，信息传播会变慢，协作会严重滞后，因此更适合使用 Agent Team。

但作者同时强调，Agent Team 的成本远高于 Sub-Agent，主要包括：

需要共享状态层，而且不是简单内存共享，而是要处理冲突、可见性、版本化；
需要节点间的通信协议；
需要一个 Lead Agent 来仲裁分歧、推动进度、识别阻塞；
调试链路更长，问题可能不在某个单点，而在节点之间的协作关系上。