你给 AI 安排工作时，有没有一种冲动：写代码找一个 Agent，查资料再找一个，最后再安排一个专门检查？看起来像团队搭好了，活儿也应该更快。

但每多一个 Agent，就多一次任务交接。前一个要把自己看到的东西总结给下一个；下一个再根据这份摘要继续做。原始上下文少了一层，等待和调用也多了一层。

Anthropic 10 月 22 日发布了一篇文章，讨论什么时候该把 subagent 合回主 Agent。它不是在说“多 Agent 过时了”。它说的是：有些系统把每个部门、每种问题都做成一个 subagent，复杂度长得比能力快。

文章提到，在他们比较的几种企业部署里，带 Skills 的单 Agent 经常在质量上胜过“一个提示词管所有事”和 subagent 方案，单任务成本和延迟也常常更低。还有一位客户比较自己的多 Agent 系统和单 Agent 循环，后者运行速度约快一倍。这个数字是一家客户的结果，不是所有任务都能快一倍。

另一家公司把十多个专业 subagent 放进面向客户的系统，发现要维持一致的品牌表达不容易，响应也变慢。注意，这和“约快一倍”是原文里的两个例子，不能拼成同一家公司、同一个实验。

Agent不是越多越能干；先看任务之间是否真的需要分开。

那什么时候值得拆？Anthropic 给了三个信号。

第一，单个 Agent 的上下文越积越多，表现已经能测出下降。不是“感觉它好像记不住”，而是拿一组真实任务对比，质量确实掉了。

第二，几件事可以同时做，而且各自需要独立的新上下文。比如同时查三份互不依赖的材料，再把结果汇总。并行能省等待，彼此也不用继承一长串过程。

第三，一个 Agent 总选错工具，或者系统指令互相打架。此时把权限和职责分开，可能更清楚。

反过来，如果任务前后相关、需要共享刚刚发现的信息，频繁交接反而可能让线索变薄。原文举了一个客服例子：合并一个 subagent 后，延迟下降了，但主 Agent 直接查订单就回答，没有再向物流专家确认送达时间，原本能通过的流程因此出了错。省下来的时间，不一定抵得上漏掉的那一步。

如果你现在正用多个 Agent，可以这样做一次小检查：

1. 先挑一组平时真的会遇到的任务，记下当前的完成质量、耗时和成本。十个代表性样例就能开始；同一组任务要重复跑几次。
2. 每次只合并一个 subagent。它的流程知识整理成 Skill，需要读取或执行的动作留给工具。
3. 对照合并前后，不只看总分，还要看哪些任务从成功变成失败。质量、成本、延迟都没变差，再考虑保留简化方案；有关键步骤漏掉，就恢复这个 subagent。

别先比“我有几个 Agent”，先比“同一件活儿，哪种安排更可靠”。

Agent 投喂胶囊

角色

你是 Agent 工作流评估顾问。

目标

帮我判断一个现有任务，适合单 Agent、Agent + Skill，还是多个 Agent。

输入

任务说明：［贴上实际任务］

当前 Agent 分工：［每个 Agent 做什么；没有就写“无”］

可观察结果：［完成质量、耗时、成本或失败记录；没有的数据写“未知”］

边界

1. 不要因为“多 Agent 看起来专业”就建议拆分。
2. 只有发现上下文负担导致可测的质量下降、需要并行处理独立任务，或单 Agent 反复选错工具/遇到冲突指令时，才建议保留或新增 subagent。
3. 区分已知数据、推断和未知；不能编造耗时、成本或成功率。
4. 如果证据不足，先给一个小规模对照测试方案，不宣布哪种架构更快。

输出

建议架构；判断依据；最小对照测试；需要观察的质量、耗时和成本；可能漏掉的失败情况。

我用一个简单样例试跑了这段胶囊：输入“把一场会议录音整理成纪要、行动项和待确认问题”，当前没有独立并行的资料源，也没有可测的上下文瓶颈，因此建议先用单 Agent；只有当录音分段能独立处理、并且汇总时仍能核对原文，才试拆并行任务。这只是一个样例的判断，不是架构效果测试。

写 Agent 工作流，先从一个能完成任务的版本开始。要不要拆，让实际结果来回答。

来源：Anthropic《Building agents: When to fold subagents into your main agent loop：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop》，2026-10-22。

配图为 AI 生成概念示意，不代表真实产品界面或实验数据。本文由 AI 协助起草，发布前需作者审核。