Agent Team
定义或身份
Agent Team 不是把任务一次性外包给几个子节点的结构，而更像一个长期共同工作的团队：有 Lead、有成员、有共享任务板，谁改了什么，其他成员可以立刻看见并据此调整动作。
它与 Sub-Agent 的根本区别，不在于“Agent 数量更多”或“名字更高级”，而在于协作方式不同：Agent Team 解决的是持续协作与共享状态，而不是隔离后的独立执行。
在这种结构里，任务不是被切成互不相干的小块后分别完成，而是多个 Agent 围绕同一条持续推进的工作链路共同工作。某个 Agent 的动作、判断、修改或发现，会直接影响其他 Agent 的下一步。
角色职责
Agent Team 的核心职责，是处理那些子任务之间存在强依赖、需要持续反馈、不能只靠一次性交接完成的任务。
它通常承担以下职责：
- 让多个 Agent 在同一任务上下文中持续协作，而不是各自持有割裂的局部信息；
- 让 Agent 之间可以直接对话，不必所有信息都经由单一父节点转发；
- 在共享状态层中持续记录进度、依赖关系、阻塞点和已发生的变更；
- 让一个 Agent 的修改、发现或回退决定，能够即时传播到其他 Agent 的后续动作中；
- 通过 Lead Agent 仲裁分歧、推进节奏、识别阻塞并维持整体任务向前。
其中，Lead Agent 不是可有可无的装饰角色。原文明确指出，Agent Team 需要一个 Lead Agent 来仲裁分歧、推动进度、识别阻塞，否则共享协作很容易演变成无序噪音。
关键信息
四个关键特征
Agent Team 在本文语境中至少有四个关键特征：
- 共享上下文
多个 Agent 不是“各管各的”，而是围绕同一任务共享上下文。这样前一个 Agent 已知的约束、判断、风险和变更，不需要在每次 handoff 时重新压缩转述。
- Agent 间可直接对话
Agent 之间可以直接通信，而不是像 Sub-Agent 那样所有流量必须先回父级再转发。这个能力的意义在于减少信息传递延迟，尤其适合一边执行一边纠偏的任务。
- 存在持续状态层
任务不是靠每个节点各自记住局部结果，而是有一层持续存在的状态层承载进度、依赖、阻塞、变更和阶段性结论。没有这层状态，所谓 team 往往只是多个 Agent 同时说话。
- 一个 Agent 的变更会影响其他 Agent 的后续动作
这是 Agent Team 与 Sub-Agent 的分水岭。某个 Agent 改了接口、调整了实现、发现了错误、修正了需求理解，其他 Agent 后续就必须随之改变，而不是继续按旧前提执行。
典型适用场景
Agent Team 适合那类“做着做着会发现问题，然后需要互相调头”的任务，典型场景集中在软件项目这类强依赖协作链路中，例如：
- 前后端接口契约变更：前端修改了接口契约，后端需要立刻知道并调整实现或兼容方案；
- 测试失败反馈回开发：测试节点发现某个用例挂了，开发需要即时拿到失败上下文，而不是只收到一句抽象的“测试失败”；
- 需求理解修正导致全链路回退：产品或需求分析发现理解有误，前面已推进的设计、实现、测试都可能要回退一步；
- 其他任何“前一个人改完，后面所有人都要立即知道”的持续协作任务。
这类场景里，如果还坚持由单一父 Agent 做统一中转，信息传递会变慢，状态也会滞后。原文的判断很直接：这种情况下只靠“父代理统一中转”是跑不动的，因为等信息一层层传完，时效性已经丢了。
细节与边界
实现成本为什么高
Agent Team 的能力来自更重的系统设计，因此其实现成本明显高于 Sub-Agent。
原文明确给出了三类刚性成本：
- 需要共享状态层
这不是简单的“大家共用一块内存”就够了，而是要能处理：
- 冲突处理；
- 可见性控制；
- 版本化能力。
也就是说，状态层必须回答“谁改了什么”“是否冲突”“谁应该看到”“能否回到旧版本”等问题，否则共享只会制造状态污染。
- 需要节点间通信协议
既然 Agent 之间能直接对话，就必须定义节点之间如何传递消息、同步状态、表达依赖、上报异常和声明完成。没有通信协议，所谓 team 只会退化成多节点互相打断。
- 需要 Lead Agent 做仲裁与推进
当多个 Agent 对下一步路径、优先级或阻塞判断不一致时，需要 Lead Agent 负责：
- 仲裁分歧；
- 推动进度；
- 识别阻塞。
这说明 Agent Team 不是“人人平等自由发挥”就能稳定运行的结构，它需要明确的协调中心。
调试与治理难点
Agent Team 的难点不只在实现，更在调试和治理。
原文特别强调，出问题时，故障点未必在某一个 Agent 本身，而可能在节点之间的协作关系上。比如：
- 状态同步延迟导致某个 Agent 基于旧前提继续工作；
- 可见性配置不当导致该知道的人没看到，不该看到的人反而看到了；
- 多个 Agent 对同一对象做了相互覆盖的修改；
- Lead Agent 的仲裁策略不稳定，导致任务反复来回；
- 某个反馈没有沿依赖链正确传播，结果后续节点都建立在错误状态上。
因此，它的排障链路通常更长，也更复杂。你不能只检查单个节点“有没有答对”，还要检查协作关系“有没有传对、同步对、裁决对”。
从治理角度看，原文虽然是在“什么时候根本不需要多 Agent”的段落里展开，但这些成本同样会在 Agent Team 上被放大，包括：
- 编排逻辑需要编写、维护和监控；
- Agent 之间的契约需要定义和版本化；
- 调试链路变长，定位成本上升；
- 多节点之间需要保持上下文一致，否则会出现因信息差造成的错误动作；
- 审计、回滚、计费等治理成本会继续上升。
选型边界
Agent Team 不是默认更高级的形态，只应在以下条件同时明显成立时使用：
- 任务必须共享状态；
- 任务需要持续协作，而不是一次性交接；
- 各节点会相互影响，某一方的变更必须实时进入另一方的决策。
如果这些条件不成立，就不应该强行 team 化。原文对此的批评非常明确：很多团队把本来适合 Sub-Agent 的简单并行任务，硬套上“team / crew / swarm”等概念，最后得到的不是协作，而是噪音。
文中的判断口诀可以直接作为边界：
任务不互相依赖，就别上 team；任务必须互相依赖，就别用 sub。
这句话的重点不是口号，而是架构约束：
- 不互相依赖的任务，更适合 Sub-Agent、并行执行或其他较轻的编排原语；
- 必须共享状态并持续互相影响的任务，才值得承担 Agent Team 的复杂度。