Anthropic新指南：默认不要拆子代理；有开发者称6个子代理更快

2024年10月22日，Anthropic发布了一份18分钟的指南，叫“When to fold subagents into your main agent loop”，意思是“什么时候该把子代理并进主循环”。它面向企业级agent构建者，立场很直接：默认不要拆子代理。

子代理就是把任务拆给多个独立小agent，各自带上下文窗口。指南推荐的主架构正相反：一个模型、一个上下文窗口、一个开放式工具循环。领域流程放进技能，硬限制和查找写进工具，让模型自己起草、修改计划。只有在三种情况下才保留子代理：测到上下文膨胀拖累性能；需要并行处理且上下文可以丢弃；agent因为工具太多或指令冲突卡住。

Anthropic给了两组观察。一位客户的单循环跑起来比它自己的多agent框架大约快2倍；多个部署看到更高质量、更低成本和更低延迟。

还有一个工具选择的边界：系统提示里塞进30到50个工具定义后，模型选工具的能力会退化。做法是按用户意图把工具分组，再用工具搜索和延迟加载，让工具按需取用，而不是一开始全堆进主提示词。

这套思路Anthropic自己先用过。Claude Code针对较新模型的系统提示被砍了超过80%。做法是先搭评估再重构，10个黄金示例就够起步。每个任务多跑几遍，因为他们观察到一次回归只在两次运行中的一次出现，跑一遍容易漏。

大型组织的常见失败模式也被列了出来：agent之间上下文丢失、子代理越加越多、Frankenprompt（每个团队都往上加规则，提示词变成东一块西一块的拼凑物）、只做局部评估、延迟上升。

迁移有现成工具。Anthropic放出了一组新的 /claude-api 技能：build-eval、prompt-audit、hillclimb、cost-optimize，还有 /skill-creator 和 /skill-doctor。GitHub上的工具包仓库叫 anthropics/single-agent-loop-kit。

指南发布后，社区两边都有人站。一位使用者说，他最多时挂了约六个子代理，最后只留两个；在他看来，大多数子代理本质上是给技能套了一个独立上下文窗口。另一条评论说，80%的提示词削减让他很有共鸣——他一半子代理只是换了个新上下文窗口的一行程序。

有人给了判断标准：子代理值不值，看是不是只读任务。搜索大型代码库、翻日志、带着一双新眼睛审查diff，这类任务只回传一个总结就行。需要跟主循环共享状态的，写成技能更好。他通常一次只开一两个，不是六个。

实测结果差异不小。一个使用者让审查子代理检查每次提交，两周86次运行只拦下一回，为了一条评论里的过期链接。另一个使用者让Opus派Sonnet做耗时长但合理的构建，让Haiku读长文件省token；又配了对抗性审查子代理和Haiku子代理复核重大决定，抓出不少明显错误，而Haiku子代理便宜到几乎不花成本。一条高票回复说，让不同提供商的模型参与审查和协作，结果明显更好，只是更慢。

反对的人理由也具体。有人说，Anthropic挑“让大模型处理一切”的例子，本身就有自利立场；他继续派子代理，因为想留在决策循环里，而且Haiku太便宜，就算不必要也花不了几个钱。有人纠正概念：子代理不等于编排，Anthropic专门建一个仓库来处理这层，不是没原因。有人算token成本：一个主agent拖着不断膨胀的上下文，凭什么好过让子代理在干净上下文里grep、编辑、找引用，再把总结交回来？agent和子代理之间的通信，未必比塞满无关token的大上下文更贵。

子代理更必要的场景也有人提。跨agent通信在Claude Code里已经是一等公民；一批并发agent共享同一份物理依赖，比如只能在一台机器的浏览器里测试时，分层监督就有意义。这类受硬件限制的任务，需要一个了解大致状况、又不烧太多token的外部调度者。

最干脆的反驳来自一位使用者：在他那里，6个子代理加一个编排者做完一件事，比所有事情同一个agent跑完更快。