一个被讲歪了的类比
“既然一个AI像一个人，那多个AI放在一起，是不是就像一家公司？”
这个直觉太自然了。PM Agent 写需求，架构师 Agent 出方案，开发 Agent 写代码，QA Agent 测试——画成流程图堪称完美。跟任何人解释都能秒懂。
但有一个事实很扎心：Anthropic、OpenAI、Google 三家在生产级 Agent 系统里，没有一家采用"虚拟公司"模式。
- Anthropic：orchestrator-worker 并行探索
- OpenAI Codex：spec 文件 + skills + compaction
- Google Gemini CLI：Conductor 扩展 + 持久化 Markdown
没有"PM 交给 Dev 再交给 QA"的流水线。这不是巧合。
LLM 真正怕的不是"岗位职责不清"
人类按岗位分工，因为一个人注意力有限、专业切换成本高、需要文档和会议来协作。
LLM 的限制完全不同。同一个模型能写 PRD 也能写代码也能跑测试。它真正怕的是：
- 关键上下文没带进来
- 推理被压缩成结论后失真
- 目标在多轮传递里漂移
- 验证标准太抽象，系统只是在假装质检
- 多个 Agent 互相响应，持续烧 token 但不收敛
这些问题的根因不是"分工不够细"，而是信息架构设计有问题。
Anthropic 的五种模式：从简单到复杂
1. 生成-验证（Generator-Verifier）
一个生成，一个检查，不通过就打回去重做。
关键洞察：值钱的不是验证角色，是验证标准。“帮我看看好不好"这种标准不可执行。正确的写法是：代码是否通过指定测试集？是否修改了范围外的文件？是否覆盖了每条验收标准？
必须装的安全阀：最大迭代次数 + 兜底策略。
2. 编排-子 Agent（Orchestrator-Subagent）
一个主 Agent 理解目标、拆任务、汇总结果。Claude Code 的 subagent 就是这个模式。
核心价值：保留主 Agent 对整体目标的连续掌控，子任务可以并行探索但最终统一综合。
瓶颈：信息必须经过主 Agent 中转。子 Agent 之间需要频繁共享中间发现时，编排模式开始吃力。
3. Agent 团队（Agent Teams）
和编排模式的区别：worker 是持久化的，跨多轮任务积累上下文。
典型场景：大代码库迁移，每个 worker 负责一个服务。
硬前提：任务必须能稳定分区。否则多个 Agent 同时操作同一代码库，抢同一块资源。
4. 消息总线（Message Bus）
引入共享通信层，Agent 通过发布和订阅事件协作。
升级信号：orchestrator 里的 if-else 开始膨胀，各种特殊情况堆条件分支。
代价：调试变难，静默失败的风险更高——路由器把事件分错了，系统不崩溃也不报错，只是什么都没处理。
5. 共享状态（Shared State）
多个 Agent 共同读写持久化存储，适合协作研究。
最大陷阱：行为层面的循环。Agent A 写发现 → B 补充 → A 再回应……系统在烧 token 但不收敛。
必须设计：时间预算、token 预算、连续 N 轮无新增发现就停止。
一张选型表解决问题
| 你遇到的信号 | 该用哪种模式 | 先检查什么 |
|---|---|---|
| 输出错一次代价高，标准能写清 | 生成-验证 | 验收标准、最大迭代 |
| 子任务短、边界清楚、需统一综合 | 编排-子 Agent | 子任务定义、摘要损耗 |
| 长期独立任务，需积累上下文 | Agent 团队 | 任务分区、资源冲突 |
| 事件驱动，类型不断增加 | 消息总线 | 路由准确性、trace 机制 |
| 需实时共享中间发现 | 共享状态 | 版本控制、终止条件 |
角色提示（Persona）的正确位置
角色提示确实能让模型更有"那个味儿”——写给管理者和写给工程师的语气本来就不一样。
但角色提示的收益和代价绑在一起：在生成型任务里帮找语气，在判别型任务里可能把模型带进表演状态。
Persona 管的是音色，不是推理深度。 把它放在控制面外面。
Codex 官方 skills 的命名就很说明问题：不是"架构师"“测试负责人”，而是 test-triage、render-debug、packaging-notarization——指向的是"一类可反复处理的问题"，不是"一个人"。
80% 的性能提升来自 token 消耗
Anthropic 在自己的 Research 系统里验证了一个结论：
多 Agent 带来的性能提升，80% 可以用 token 消耗量来解释。
这意味着多 Agent 更适合广度优先的并行探索，而不是模拟人类组织里的职能接力。
Claude Code 的 subagent 本质上是一个受控的上下文隔离工具，不是一个虚拟同事。主 Agent 不需要背下整个搜索过程，只需要拿到压缩后的结论。
上多 Agent 之前，先回答这 7 个问题
- 这个任务是否真的超过了单 Agent 的上下文或搜索能力？
- 子任务之间是独立的，还是强依赖的？
- 每个 Agent 需要看到的上下文边界是什么？
- 中间发现是只回到主 Agent，还是要实时共享？
- 什么算完成，能不能写成可检查标准？
- 如果 Agent 之间产生循环，系统怎么停？
- 失败时是回滚、重试、降级，还是交给人？
如果这 7 个问题还没想清楚就堆 Agent 数量，大概率只是把复杂度提前引入系统。
一句话总结
多 Agent 的演进，不是从"一个人"升级到"一家公司"，更像是从"单一上下文"逐步拆出更多边界和通信机制。
真正能沉淀下来的不是角色设定，而是能力节点、工作流、验证标准、状态文件、停止条件——这些才是系统真正的结构资产，不会因为模型换了就作废。
基于架构师（若飞）微信公众号文章《多 Agent 不是虚拟公司：从 Anthropic 五种模式看信息流怎么设计》整理分析。 原文：https://mp.weixin.qq.com/s/fMPSK00Lxb0uv90sun_BYQ