Anthropic新指南：大多数AI Agent不需要堆子代理，单一主循环才是正解

Anthropic 发布了一份名为《When to fold subagents into your main agent loop》的指南，核心主张相当反直觉：大多数 Agent 不应该拆成一堆子代理，而应该收回到一个主循环里。 配套给出的数据也很直接——Claude Code 自身面向新模型的系统提示词被砍掉了超过 80%。

这份指南面向企业级 Agent 构建者，但凡是曾在 Claude Code 里搭过一串子代理的人，读起来都会有共鸣。

默认架构：单模型、单上下文、单个开放式工具循环

Anthropic 给出的推荐起点非常朴素：一个模型、一个上下文窗口、一个开放式工具调用循环。领域性的操作流程放进 skills，硬性约束和查表类的确定性逻辑放进 tools，让模型自己编写和修订执行计划。

这个建议的实质是把复杂度从「架构层」下放到「内容层」。过去很多团队习惯用子代理来切分职责，结果是把业务逻辑变成了多进程编排问题；而单一循环的思路是，职责划分应该体现为 skills 和 tools 的内容差异，而不是上下文窗口的物理隔离。

只有当出现可测量的退化时，才值得拆出子代理。

开放式工具调用循环（open-ended tool loop） 指的是模型在一个持续的推理-行动循环中自主决定何时调用工具、调用哪个工具、以及何时停止，而不是沿着预先编排好的固定步骤执行。与之相对的是工作流式编排：开发者显式定义节点和边，模型只在节点内部做局部决策。开放式循环把「下一步做什么」的控制权交给模型，因而对工具描述的清晰度、上下文的质量更为敏感，但也避免为每一种任务分支硬编码路径。Anthropic 推荐的「单模型、单上下文、单循环」正是这一范式的极简形态，其隐含前提是模型自身具备足够的规划能力，架构的复杂度应当让位于提示词与工具设计的质量。

什么情况下子代理才值得保留

指南列出了三类仍然成立的场景：

• 上下文膨胀导致的质量下降已被测量到。注意「被测量到」这个限定——不是凭感觉判断，而是有 eval 数据支撑。
• 需要并行处理，且子任务的上下文可以丢弃。一次性用完即弃的上下文，是子代理最干净的用法。
• 工具过多或指令相互冲突，单个代理处理不过来。这时拆分是为了降低认知负荷，而不是为了架构美观。

除此之外，很多子代理本质上只是「带独立上下文窗口的 skill」，并不需要进程级隔离。Reddit 上一位用户提到自己一度维护约六个子代理，最后只留下两个，其余都退化成了普通 skill 配置。

上下文窗口膨胀是拆分代理最常见的诱因。当单次任务需要读取大量文件、日志或检索结果时，无关信息会挤占有限窗口，稀释模型对关键线索的注意力，表现为遗漏约束、重复调用工具或前后不一致。判断是否真的发生了膨胀，应看可量化的信号，例如任务成功率随输入长度上升而下降、工具调用轮次异常增加、关键指令被忽略的比例上升。若这些信号只是主观感受而无 eval 数据佐证，拆出子代理往往只是把问题从「上下文太长」转成「上下文传递失真」，反而引入了新的信息损耗点。

性能数据：单循环跑出约 2 倍速度

指南中引用了客户侧的实际结果：某客户的单一循环方案比其多代理编排框架快了约 2 倍。多个部署案例同时报告了更好的质量、更低的成本和更低的延迟。

这些收益并不是来自某个单点优化，而是多重因素叠加——少一层代理调度就少一层 token 开销，少一次上下文传递就少一次信息损耗，少一次跨代理协调就少一段延迟。

工具定义超过 30-50 个，选择质量开始下降

一个值得记住的经验数字：当系统提示词里的工具定义超过 30 到 50 个时，模型选择工具的准确率往往会下滑。

Anthropic 给出的应对方式是按用户意图对工具分组，并配合带延迟加载的 tool search——先把工具目录暴露出来，让模型按需检索具体定义，而不是在一开始就把所有 schema 塞进上下文。这与系统提示词削减 80% 是同一个思路：上下文是稀缺资源，不该用来预加载可能用不上的信息。

tool search 与延迟加载（lazy loading） 是一种把工具发现与工具使用分离的模式：系统提示词中只保留精简的工具目录或检索入口，模型在判断需要某类能力时再主动查询并加载完整的参数 schema。这与传统的「一次性注入全部 schema」形成对比，后者会让提示词的固定开销随工具数量线性增长，并稀释模型对每个工具描述的关注度。延迟加载的代价是增加一次检索往返，因此更适合工具集合庞大且单次任务只涉及其中少数的场景；对于高频核心工具，仍应直接暴露在上下文中，避免不必要的调用开销。

重构之前先建 eval，10 个样本就够起步

指南特别强调顺序：先有 eval，再动架构。起步阶段 10 个黄金用例就足够。

一个容易被忽略的细节是，每个任务应该跑不止一次。指南提到有一个回归问题只在两次运行中的一次里出现——单次运行的 eval 会直接漏掉它。Agent 的非确定性意味着评估必须考虑方差。

eval（评测集） 在这里指的是针对 Agent 端到端行为设计的一组可重复运行的测试用例，通常包含输入任务、期望结果或判定标准。与单元测试不同，Agent 的输出具有非确定性，同一输入可能产生不同路径与结果，因此评测需要关注通过率而非单次成败。黄金用例应覆盖最具代表性的真实任务，并包含已知的失败模式，以便在架构调整后快速发现回归。10 个用例的起步规模强调的是「先建立可观测基线」，而非追求统计完备；随着系统演进，再逐步扩充覆盖面与难度梯度。

大型组织常见的失效模式

指南点名的几类问题在规模化的团队里很典型：

• 代理之间丢失上下文，信息在传递链上层层衰减
• 子代理蔓延（subagent sprawl），数量只增不减
• 「Frankenprompt」——每个团队都往提示词里追加自己的规则，最终无人能理解全貌
• eval 过于局部，只覆盖单个子代理而看不到端到端表现
• 延迟随代理层数线性甚至超线性增长

这些问题有一个共同根源：复杂度被拆分到了组织边界上，而不是收敛到可观测的单一位置。

配套迁移工具

Anthropic 提供了几个新的 /claude-api skills 辅助迁移：build-eval、prompt-audit、hillclimb、cost-optimize，以及 /skill-creator 和 /skill-doctor。GitHub 上还有一套 anthropics/single-agent-loop-kit 工具包。

实践启示

这份指南的价值不在于宣布子代理过时，而在于给出了一个可操作的判据：默认单循环，只有在测量到具体退化时才拆分。 这与常见的「先搭架构再填内容」的工程习惯正好相反。

对已经在多代理架构上投入的团队来说，最现实的路径是先补齐 eval 基础设施，用数据找出哪些子代理真正贡献了价值，哪些只是上下文隔离的副产品。系统提示词砍掉 80% 这件事本身也说明，很多被当作「必要上下文」塞进去的内容，其实并不必要。

值得留意的是，指南中的数据主要来自企业客户部署，具体场景和任务类型并未完全公开，迁移时应以自身 eval 结果为准，而不是直接套用他人的性能倍数。