Agent Composition：拆掉你的单体 Agent
你的 Agent 是不是越做越烂？
你一定经历过这个过程：第一版 Agent 只用一段 System Prompt 加几个工具，效果惊艳。然后需求来了——要处理更多类型的输入、要调用更多 API、要记住更长的上下文。你往 prompt 里塞更多指令，注册更多工具，上下文窗口开始吃紧，偶尔吞掉关键信息，调试变成在几千 token 的日志里大海捞针。
这不是你的问题。单体 Agent 的架构天花板就在那里。 一个模型、一段 prompt、一个循环，处理从接收到交付的全部流程——这种结构在任务复杂度超过某个临界点后必然崩溃。
Agent Composition 就是对这件事的回应：别让一个 Agent 干所有的活，把它拆开。
这个想法是怎么长出来的
"组合优于继承"在软件工程里是老生常谈，但 AI Agent 领域直到 2024 年底才认真对待这件事。
转折点是 Anthropic 在 2024 年 12 月发的一篇博客：Building Effective Agents。这篇文章没有推销任何框架，而是说了一句让整个行业冷静下来的话：
"The most successful implementations weren't using complex frameworks or specialized libraries—they were building with simple, composable patterns."
翻译一下：那些真正跑在生产环境里的 Agent，用的不是什么花哨框架，而是 简单的、可组合的模式。
Anthropic 在文中画了一条清晰的线：Workflow（你写代码来编排 LLM）和 Agent（LLM 自己决定下一步干什么）是两回事。前者可预测、成本可控；后者灵活但难以调试。大多数任务应该用 Workflow，只有真正开放性的问题才需要让模型自主驾驶。
这篇文章定义了五种 Workflow 模式。后来发生的一切——LangGraph 的状态图、CrewAI 的角色团队、OpenAI 的 Handoff 机制——本质上都是在用不同的工程方式实现这五种模式。
时间线上的其他关键节点：
- 2025 年中，LangGraph 加入 checkpoint（可回滚的状态快照）和分布式追踪，CrewAI 推出 Flows 做状态管理，AutoGen 完成 v0.4 大重写转向 actor 模型。多 Agent 框架从"能跑 demo"走向"能上生产"。
- 2025 年 11 月，Anthropic 把 MCP 协议捐给 Linux 基金会。Google、Microsoft、OpenAI 全部加入。从此 Agent 连接工具有了统一接口，不用再为每个框架写一套适配器。
- 2026 年 4 月（就是现在），Anthropic 发布 Managed Agents，OpenAI 更新 Agents SDK。两家同时在做一件事：把 Agent 的"脑"和"手"分开部署。 Agent Composition 从设计模式变成了基础设施。
六种模式，一棵决策树
Anthropic 定义的这套模式已经成了行业通用语言。不用背，用的时候对着选就行。
① Prompt Chaining——流水线
最简单的组合：A 的输出喂给 B，B 的输出喂给 C。中间可以插代码做校验。
什么时候用： 任务能拆成固定的线性步骤。比如"写文案 → 翻译 → 格式检查"。
② Routing——分拣
先判断输入属于哪一类，再把它扔给对应的专家处理。
什么时候用： 输入类型多样，处理逻辑完全不同。典型的客服场景：退款走退款 Agent，技术问题走技术 Agent，闲聊走兜底。
③ Parallelization——并行
同一时间让多个 LLM 各干各的，最后由程序把结果拼起来。两种玩法：分片（把任务切成不重叠的块）和 投票（同一个任务交给多个模型，取多数结果）。
什么时候用： 子任务之间没有依赖，或者你需要用"多数决"来提高判断可靠性。内容审核就是经典场景——一个模型看暴力、一个看色情、一个看政治敏感，各自独立打分。
④ Orchestrator-Workers——指挥官 + 士兵
一个中央 Agent 拿到任务后，动态地决定要拆成几个子任务、分别交给谁做，收到结果后综合出最终答案。
它和并行化长得像，但有本质区别：并行化的子任务是你提前定好的，Orchestrator-Worker 的子任务是模型临时规划的。
什么时候用： 你事先不知道任务会分解成什么样。写代码就是典型——要改哪些文件、改多少，完全取决于 issue 的内容。
Anthropic 自己的 Research 功能就用这个模式。Lead Agent 分析用户查询后 spawn 多个 Subagent 并行搜索不同方向，最后综合。他们的工程博客把这个过程写得很透：
"Multi-agent systems work mainly because they help spend enough tokens to solve the problem."
多 Agent 有效，本质上是因为让系统花了足够多的 token。架构的价值不在于"更聪明"，而在于让 token 花到了对的地方。
⑤ Evaluator-Optimizer——生成-评审循环
一个 LLM 负责生成，另一个负责挑毛病，来回迭代直到质量达标。
什么时候用： 你有明确的好坏标准，而且一次生成很难直接达到。代码生成（写 → 跑测试 → 修 → 再跑）、翻译润色都是典型场景。
⑥ 自主 Agent——放手让模型自己来
LLM 在循环里自主决定下一步：调工具、看结果、决定继续还是停。最灵活，也最不可控。
什么时候用： 问题完全开放，你没办法提前画流程图。但要注意——Anthropic 和 OpenAI 都反复警告：大多数任务不需要走到这一步。
怎么选？
任务能拆成固定的线性步骤？
├── 能 → ① Prompt Chaining
└── 不能 → 输入类型多样、需要不同处理？
├── 是 → ② Routing
└── 否 → 子任务独立且数量已知？
├── 是 → ③ Parallelization
└── 否 → 子任务结构取决于输入？
├── 是 → ④ Orchestrator-Workers
└── 否 → 有明确评估标准？
├── 是 → ⑤ Evaluator-Optimizer
└── 否 → ⑥ 自主 Agent一条最重要的原则：从上往下选，能用简单的就别用复杂的。 每多一层编排，就多一层可能出错的地方。
Anthropic 和 OpenAI 各自押注了什么
Anthropic：把 Agent 当操作系统来设计
Anthropic 走得最远。他们不只是发了一篇博客定义模式，还在自己的产品里验证了这些模式，然后把验证结论也公开了。
他们的 Research 功能用 Orchestrator-Worker 架构：Claude Opus 4 当 Lead，Sonnet 4 当 Subagent。跑了大量数据后发现三件事：
- 多 Agent 有效主要是因为花了更多 token——不是架构更聪明，而是让系统有预算去探索更多方向。
- 升级模型比加 token 预算更划算——从 Sonnet 3.7 换到 Sonnet 4 的提升，比在同一模型上翻倍 token 还大。
- 不是所有任务都适合多 Agent——广度搜索（多方向并行探索）效果好，编码任务效果一般，因为后者很少有真正可并行的方向。
2026 年 4 月，他们更进一步，发布了 Managed Agents 服务，提出 Brain / Hands / Session 三层解耦：
- Brain（脑）：Claude + 编排逻辑。无状态，可随时替换。
- Hands（手）：沙箱容器，执行工具调用。与 Brain 隔离，崩了不影响状态。
- Session（记忆）：只追加的事件日志。Brain 崩了换一个接着跑，因为记忆在外面。
这套架构让 p50 首 token 延迟降了 ~60%，p95 降了超过 90%。思路和操作系统把进程、文件系统、I/O 分层一样——做过系统编程的人会觉得似曾相识。
OpenAI：两种委托哲学
OpenAI 的 Agents SDK 实现了两种编排原语，分别对应两种管理哲学：
Handoff（交接）：控制权完全移交给专家 Agent。适合专家应该直接面对用户的场景，比如客服分流——退款问题交给退款 Agent 后，它全权负责。
Agent-as-Tool（专家当工具用）：Manager Agent 保持控制权，把专家当函数调用。适合 Manager 需要综合多个专家结论的场景。
OpenAI 文档里反复出现一句话值得记住："Add specialists only when the contract changes." 只有当一个新 Agent 确实需要不同的 prompt、不同的工具或不同的权限时，才值得拆出来。过早拆分只会制造更多 prompt、更多 trace、更多调试界面。
框架选型：LangGraph vs CrewAI vs AutoGen
如果你不用 Anthropic 或 OpenAI 的一站式方案，而是自己搭，三个框架各代表一种思路：
| LangGraph | CrewAI | AutoGen | |
|---|---|---|---|
| 一句话 | 把 Agent 编排当状态机问题 | 把 Agent 编排当团队管理问题 | 把 Agent 编排当群聊问题 |
| 核心抽象 | 节点 + 边 + checkpoint | 角色 + 任务 + 团队 | Actor + GroupChat + 消息总线 |
| 最强项 | 复杂分支、长运行、故障恢复 | 快速出原型、角色清晰 | 开放式协作、人机对话 |
| 最弱项 | 学习曲线陡、样板代码多 | 循环和条件分支难表达 | 生产治理能力弱 |
选型经验法则： 默认 LangGraph。如果工作流天然是线性的、角色分工明确，用 CrewAI 出活更快。如果核心场景是多 Agent 之间的开放讨论或人机协同，用 AutoGen。
这三个框架最深层的区别其实就一个问题：状态存在哪里？ LangGraph 存在外部 checkpoint（容器崩了能恢复），CrewAI 存在 Flow 事件流里（事件驱动但粒度粗），AutoGen 存在对话历史里（内存没了就没了）。你对故障恢复的要求有多高，就决定了你该选谁。
这件事对行业意味着什么
第一，"Prompt Engineer"这个角色正在被重新定义。 2025 年之前，核心技能是写好 prompt。2026 年的核心技能变成了设计 Agent 的组合结构——哪些部分用 Workflow、哪些用自主 Agent、状态怎么流转、出错了怎么恢复。Anthropic 给这个新学科取了个名字：Context Engineering。因为他们发现，Agent 的大多数失败不是模型不行，而是上下文没给对。
第二，企业需要 Agent 平台团队。 当你从"一个 Agent 解决一个问题"走向"十几个 Agent 协同处理业务流程"，编排层、观测层、治理层就不再是可选项——它们变成基础设施。Bain 的 2026 年报告直接把这三层定义为 Agentic AI 平台的核心架构。
第三，安全攻击面在扩大。 Anthropic 在 2026 年 4 月的 Trustworthy Agents in Practice 中提了一个重要观点：Agent 的行为不只取决于模型，而是 Model + Tools + Harness + Environment 四层共同决定的。Agent Composition 让每一层都可以独立审计，但也意味着攻击面从"一段 prompt"扩展到了"一个分布式系统"。
接下来会发生什么
Harness 标准化正在发生。 Anthropic 的 Brain/Hands/Session 和 OpenAI 的 Manifest 抽象长得越来越像。2026-2027 年可能出现跨厂商的 Agent 运行时标准——就像容器世界的 OCI。
Agent 之间的通信还没标准化。 MCP 解决了 Agent 连接工具的问题，但 Agent 跟 Agent 之间怎么对话？Google 的 A2A 协议在推，但还没到 MCP 的共识程度。这是下一个待收敛的碎片化问题。
组合本身会变得可学习。 现在的 Agent Composition 是人手动设计的。但如果每次组合的效果都有评分记录（GitHub 上的 Agency 框架已经在做这件事），系统就可以自动学习"哪些组合在什么任务上效果最好"。从手动设计走向自适应组合，这可能是最值得期待的方向。
一句话收尾
Agent Composition 的本质不是"让更多 Agent 一起工作"，而是为不确定性分配结构——让每个 Agent 只面对自己能处理的复杂度，让编排层承担协调的代价，让状态层兜底失败后的恢复。
留给你的问题只有一个：你现在那个越做越烂的单体 Agent，哪一刀最该先切？
参考资料
- Anthropic. Building Effective Agents. 2024-12. 链接
- Anthropic. How We Built Our Multi-Agent Research System. 2026-04. 链接
- Anthropic. Scaling Managed Agents: Decoupling the Brain from the Hands. 2026-04-10. 链接
- Anthropic. Trustworthy Agents in Practice. 2026-04-09. 链接
- OpenAI. Orchestration and Handoffs. 2026. 链接
- OpenAI. The Next Evolution of the Agents SDK. 2026-04-15. 链接
- Zhang et al. AgentOrchestra: A Hierarchical Multi-Agent Framework. arXiv:2506.12508. 2025-06.
- Bain & Company. The Three Layers of an Agentic AI Platform. 2026-04-02. 链接
- Tao An. AI Agent Landscape 2025–2026: A Technical Deep Dive. Medium, 2026-01-05.
- Arize AI. Orchestrator-Worker Agents: A Practical Comparison. 2025-09-09. 链接
- Hieu Tran. The Agent Stack in 2026. DEV Community, 2026-04.
- agentbureau/agency. GitHub, 2026-03. 链接