最近看到一篇文章，核心判断很尖锐：很多社区里流行的 multi-agent 架构，本质上是在把 AI 系统设计成一家“虚拟公司”。

也就是：

  • 一个 agent 扮演 PM
  • 一个 agent 扮演架构师
  • 一个 agent 扮演开发
  • 一个 agent 扮演 QA
  • 任务像部门流转一样一棒接一棒传下去

这个模式很好解释，也很好画图。但问题是，它常常把一个看起来整齐的系统，做成一个信息不断损耗的系统。

而这正是理解 Claude Code Agent Teams 的关键起点：

Claude Code Teams 不是天然等于这种“角色流水线”。

它更像是一个带共享任务和直接通信能力的多实例协作系统。两者都叫 multi-agent，但工程含义并不一样。

一、文章真正批评的，不是“多个 agent”，而是“角色化接力”

这类“虚拟公司式”架构最吸引人的地方，是它很符合人的组织直觉。

人类团队要分工，是因为：

  • 每个人注意力有限
  • 专业知识分布在不同岗位
  • 协作需要接口和流程

但 LLM 并不天然服从这套结构。一个模型既可以写 spec，也可以读代码，也可以做 review。你把它硬分成“测试工程师”或“产品经理”，往往不是在增强能力，而是在制造边界。

更糟的是，这种架构的默认工作方式通常是：A 产出结论，交给 B；B 再基于结论继续；C 再接着做下一段。信息在每一次交接中都会压缩，推理链也会被切断。

于是最后很容易出现一种熟悉的问题：

每个节点看起来都局部正确，但整体目标已经漂了。

所以，文章真正反对的不是“多 agent”，而是下面这种模式：

  • 用角色来限制 agent 的职责
  • 用文档交接来替代连续推理
  • 用流水线来模拟公司部门协作

这是一种 role-based baton passing：角色化接棒。

二、Claude Code Agent Teams 更接近“共享状态协作”

我去看了 Claude Code 官方文档，Agent Teams 的核心描述不是“交接”，而是这些词：

  • shared tasks
  • inter-agent messaging
  • centralized management

官方文档明确写到，Agent Teams 适合的是：

  • 需要讨论的问题
  • 需要协作的问题
  • 需要并行调查的问题
  • 需要不同视角互相 challenge 的问题

这和“PM 写完 PRD 给 Dev，Dev 写完代码给 QA”是两种完全不同的组织方式。

Claude Code Teams 更像这样：

  • 多个独立 Claude session 同时工作
  • 它们共享任务列表
  • 队友之间可以直接发消息
  • 主会话或 team lead 负责协调
  • 结果通过讨论、汇总、收敛形成结论

如果说“虚拟公司式”是接力赛，那么 Claude Code Teams 更像一个协作中的讨论组，或者一个围绕同一任务展开的研究小组。

关键差别是：

信息不是只沿着单向流水线往下传，而是在共享状态里并行展开，再汇总回主线。

三、真正的区别，不是“有没有角色”，而是“角色到底是视角，还是工位”

这里最容易混淆。

Claude Code 官方示例里，也会提到不同 teammate 的定位：

  • 一个做 UX
  • 一个看技术架构
  • 一个扮演 devil’s advocate
  • 一个专门做 security review

这看起来也像“角色分工”。

但这里真正重要的问题不是有没有标签，而是这个标签到底在干什么。

如果标签代表的是“工位”

例如：

  • PM 负责写需求
  • Architect 负责设计
  • Dev 负责实现
  • QA 负责验收

并且任务严格按照这个顺序接力传递，那么它依然会落回文章批评的老问题：

  • 上下文断裂
  • 隐含假设丢失
  • agent 被边界限制
  • 大量 token 花在交接而不是思考上

如果标签代表的是“视角”

例如：

  • 一个 agent 从安全角度审查
  • 一个 agent 从性能角度审查
  • 一个 agent 负责反驳已有假设
  • 一个 agent 并行调查另一条根因线索

那么这其实不是流水线，而是并行探索。

这时这些“角色”不是工位，而是观察问题的不同镜头。它们不会一棒传一棒，而是分别撒网，最后再由主线整合。

这才是更健康的 multi-agent 用法。

四、为什么 Anthropic 自己的实践，更像“分叉再合并”而不是“部门协作”

文章里一个很重要的观察是：Anthropic 在真正做生产级 agent 系统时，采用的不是“公司角色扮演”，而更接近 orchestrator-worker。

也就是：

  • 一个主 agent 持有完整意图
  • 子 agent 去探索不同子问题
  • 结果最终回流主 agent
  • 主 agent 保持整体目标连续性

这是一个非常关键的区别。

前者的核心是：推理链不能断。

如果确实要拆，就应该是：

  • 分叉出去探索
  • 再回到一个统一的主线里综合

而不是：

  • 一个角色做完就下班
  • 下一个角色只接一个压缩过的结论继续

从这个角度看，Claude Code Teams 更接近前一种可能性。它给的是一个协作框架：共享任务、消息互通、集中管理。它允许你做并行调查、争论式验证、交叉 review。

但它并不会自动阻止你把它错误地用成“AI 部门流水线”。

工具本身没有错，错的是组织信息流的方式。

五、判断一个 multi-agent 架构好不好，先别问 agent 有几个

我现在更认同一个简单标准：

不要先问“要几个 agent”，先问“信息怎么流”。

如果一个任务需要的是：

  • 长链条连续推理
  • 高度依赖完整上下文
  • 目标不能漂
  • 中途任何信息断裂都会让质量明显下降

那通常更适合：

  • 一个主 agent 持有完整意图
  • 外部状态文件记录关键进展
  • 必要时用子 agent 做局部探索或验证

如果一个任务需要的是：

  • 多个独立方向并行研究
  • 多种假设同时排查
  • 安全 / 性能 / 测试覆盖等多视角 review
  • 让不同 agent 相互 challenge

那像 Claude Code Teams 这样的机制才会真正体现价值。

所以，多 agent 的收益，很多时候来自：

  • 更大的搜索覆盖
  • 更强的并行调查
  • 更丰富的对抗性验证

而不是来自“这个 AI 扮演 PM、那个 AI 扮演 QA”。

六、最短的结论

如果必须用一句话来概括这两者的区别，我会这样说：

被文章批评的，是把 multi-agent 设计成“角色接棒的虚拟公司”；而 Claude Code Teams 更像“多个独立会话在共享任务和直接通信机制下的协作网络”。

两者都可能出现多个 agent、多个标签、多个任务。

但真正决定系统质量的，不是表面上的人数和分工，而是底层的信息流：

  • 是不是在单向交接中不断丢信息
  • 还是在共享状态里并行展开、最后统一收敛

这才是工程分水岭。

也因此，最值得记住的一句话不是“multi-agent 好不好”，而是：

好的 multi-agent，不像一家公司；更像一个保持主线连续的大脑，在多个方向上同时起草，再把结果合并成一个连贯判断。