什么时候该把子代理折回主循环？Anthropic 给企业代理的减法答案

过去两年，「多代理」几乎成了 AI 应用的默认想象力：一个协调者居中调度，专家子代理各管一摊。2026 年 10 月 22 日，Anthropic Applied AI 团队却在 claude.com 发表了一篇唱反调的长文《Building agents: When to fold subagents into your main agent loop》：大多数企业代理系统应该做减法——把路由器、规划器和领域子代理折回一个主循环，用按需加载的 skills 与 tools 补位。随文发布的迁移套件 single-agent-loop-kit 把「怎么减」做成了可执行清单。这篇文章值得精读的不只是结论，更是它的判断方法：什么时候折、按什么次序折、折坏了怎么发现。

一、结论先说：单循环经常「三赢」

文章的核心经验来自跨部署对比。Anthropic 的 Applied AI 团队常年进出各家企业做落地，他们的原话是：一个带 skills 的单代理，在质量上经常同时打赢「一个提示词包打天下」和「子代理舰队」两种设计，而且常常伴随着更低的成本与延迟。延迟差距不是小数：一家客户从多代理 harness 换成单代理循环后，运行时间约快了一倍。

一个真实案例被点名：某家公司的客服代理里塞了十几个领域专家子代理，结果是品牌口径难以统一、响应延迟层层累加。听起来很反直觉——分工越细怎么反而越乱？文章把病因归纳成一句话：这套架构在照搬组织结构图，文章称之为「Conway 定律在工作」。每个团队交付自己的代理，再配一个中央协调者，人怎么分工，代理就怎么分工。

这不是 Anthropic 第一次谈简单性。2024 年 12 月的《Building effective agents》就把「找最简单的方案，确有必要再加复杂度」放在第一原则；2025 年 6 月的多代理研究系统文章在给出 90.2% 提升的同时，也明说了 15 倍 token 代价与「编码类任务不适合多代理」的边界。真正的变化发生在现在：模型能力变强、skills 渐进披露成熟之后，「简单方案够用」的覆盖范围大幅扩大了，于是 Anthropic 把这条旧原则落成了针对企业多代理系统的新处方。

二、大组织代理架构的五种病

为什么子代理舰队在企业里经常失灵？文章列的失败模式高度像一个「组织病」清单，几乎每一种都能在软件工程史上找到对应：

病名	症状	文章开的处方
有损交接	子代理输出被压缩成摘要再传给下一个代理，前因后果丢失	让上下文留在主循环里共享
子代理蔓延	数百个子代理职责重叠，没有标准、没有归属人	中央团队牵头审计清理
Frankenprompt	各团队的规则都往系统提示词里塞，互相打架	规则拆进各自的 skills
注水的本地评测	各队评测越调越好看，拿去支撑高层决策	中央统一的端到端评测
延迟翻倍	逐级路由、逐级交接，串行放大	单循环加并行工具调用

五种病共享同一个根因：多代理把「信息的边界」切在了「组织的边界」上。子代理之间的每次交接都是一次压缩——把丰富的工作痕迹压成一段摘要，而决策需要的细节恰恰藏在被压缩掉的部分里。等这类系统养到几百个子代理的规模，没人能说清谁依赖谁，治理成本反过来吃掉分工收益。

三、单循环为什么赢：三个理由

文章给出了三层递进的解释，一层比一层根本。

第一，共享上下文产出更好的答案。 主循环里的代理能直接引用自己前面步骤的原始结果，把线索串起来；而多代理架构里，子代理拿到的是上一棒的摘要。摘要天生有损，模型只能基于残缺信息做决策。这与 Cognition 在《Don't Build Multi-Agents》里的第一原则完全一致：要共享就共享完整的代理轨迹，而不只是单条消息。

第二，渐进披露防住了上下文膨胀。 单循环的常见反驳是「所有东西塞一个窗口会爆炸」。文章的答案是 skills 机制：每个技能在系统提示词里只占一行描述，用到时才全文加载；工具同理，先给名称与简介，需要时再展开完整定义。Anthropic 自己先做了示范：为更新的模型，Claude Code 的系统提示词砍掉了 80% 以上，第三方报道补充说编码评测没有可测量的损失。提示词不再需要前置 everything，按需加载就够了。

第三，模型变强了，一部分 harness 成了冗余。 文章观察到，从 Opus 4.5 开始，模型在一个循环里能扛住的复杂度超出预期；到 Opus 5.5 与 Fable 5.1，扩展思考已无法关闭——模型天然就在边想边验。新一代模型会自我校验，很多为「防模型犯错」设计的流程约束（独立的校验代理、多级规划器）因此变得多余。

由此推出治理结论：系统提示词与端到端质量应当由一个小型中央团队统一拥有，所有工具与评测都要过它的门。确实要拆多代理时，按上下文边界拆，而不是按问题类型拆——后者制造的是「传话游戏」，每传一棒损一分真意。

四、子代理的三条保留判据

文章没有一刀切。以下三种情况，子代理仍然是正确设计：

1. 可测量的上下文膨胀退化：单循环因为上下文太长而出现性能下降，且有数据佐证；
2. 并行的独立任务：需要新鲜、可丢弃的上下文窗口，跑完即弃；
3. 工具选择过载：单代理在几十个工具里挑花眼，或系统提示词里的指令互相冲突。

这三条与 Cognition 一年多前的结论殊途同归：并行化只在「范围清晰的只读调查」里是安全的，决策权必须保持统一。有意思的是 Anthropic 自己的多代理研究系统照常在跑——宽度优先、多路并进、单窗口装不下的研究型任务，正是子代理的主场；而编码任务从来就难以真正并行。

对存量系统，迁移套件的审计环节把每个子代理的处置归为四种，配合判据与代价看更清楚：

处置	判据	代价与注意
保留（keep）	并行研究需新鲜上下文；独立黑盒验证	交接处仍需评测覆盖
合并（merge）	总是连续被调用、读写同一数据、互为上下游	合并后重跑评测
当工具调（as-tool）	需要独立上下文，但主代理应留在对话里	每次调用是嵌套模型循环，加延迟；有损摘要仍在
折叠（fold）	其余大多数	提示词变 skill、API 变 MCP 工具，一次折一个

五、目标架构：一个循环，四层分工

折叠之后长什么样？文章给出的目标设计可以概括为「一个循环，四层分工」：

一个循环：一个模型、一个上下文窗口、开放式工具循环。harness 只负责硬约束——轮次与成本预算、写入闸门；模型可以批量发出工具调用，harness 并行执行后把结果喂回同一个模型；循环在给出答案或撞到预算时结束，可选跑一道目标校验或 verifier。关键一条：规划模型就是执行模型，中途发现计划不对可以直接改，不需要「规划代理 → 执行代理」的交接。

其余要素各归其位，构成四层分工：

• skills 装流程与判断：领域步骤、规则、相机抉择这类团队知识，每个 skill 有明确的 DRI（负责人），用 /skill-creator 编写与审计，用 /skill-doctor 看使用率与成本、删掉死重；
• tools 装动作与硬约束：动作、实时数据、固定形状的返回走 MCP 工具，前置条件与按用户的权限直接写进工具实现里。工具按用户意图分组而不是一个 API 一个工具——文章引用了经验阈值：工具定义超过 30-50 个，模型的选择准确率就开始退化，超了就用工具搜索加延迟加载；
• 代码管机械部分：便宜且总要做的活（如实体解析）由代码在装载环节处理，不劳烦模型；
• 知识库存偶发参考：政策、指标定义这类偶尔翻一眼的资料，放在查找工具或 skill 引用文件后面——不要让代码把上下文直接粘进提示词。

flowchart TD
    U["用户请求"] --> M["主循环：一个模型 · 一个上下文窗口"]
    M -->|"批量工具调用"| H["harness：预算与写闸门 · 并行执行"]
    H -->|"结果回到同一模型"| M
    M -.->|"按需加载"| S["skills：流程 · 规则 · 判断"]
    M -.->|"工具搜索 + 延迟加载"| T["MCP 工具：动作 · 实时数据"]
    M -.->|"查找工具"| K["知识库：政策 · 指标定义"]
    M --> V["可选：目标校验 / verifier"]
    V --> A["最终回答"]

这套架构对多团队协作也友好：中央团队守系统提示词与共享评测，各业务团队以 skill 和 MCP 工具的形式贡献能力——能力可以来自四面八方，决策与上下文只属于一个循环。

六、怎么迁移：评测先行，一次折一个

整篇文章方法论上最扎实的部分是迁移流程，而它的第一步不是动架构，是建评测。

先建一把尺子。 一个中央拥有的端到端评测集，外加每技能的小评测集；文章认为约 10 条黄金样本就够起步——从真实请求里挑，按评分细则给最终回复打分。迁移前记录路由准确率，迁移后记录技能/工具选择准确率；关键事件打上时间戳，评测可回放。套件 README 里那句大实话值得贴在墙上：「没有评分，迁移就只是 opinion」。

然后按次序做减法。 套件把迁移拆成带检查点的阶段：审计（给每个子代理定处置）→ 基线（给现状跑分）→ 合并 → 折叠 → 维护（瘦提示词、剪死技能、落定归属）。每一步停下确认，付费运行前先估 token。合并的判据很具体：如果生产流量里大量请求都是「先跑专家 A 再跑专家 B」，它们就该合并。

折叠要一次一个。 把一个子代理的提示词转成 skill、API 调用转成 MCP 工具，折一个，折前折后各跑一遍评测对比，而且要盯着哪些具体任务翻转了，不只看总分。文章给了一个精彩的反面案例：把一个物流子代理折进主代理后，延迟降了，但一条原本通过的流程悄悄坏了——主代理没问物流专家就自己答了配送日期。更麻烦的是，同一任务跑两遍只在其中一遍暴露。所以评测必须覆盖每条代理链、每条规则，且每个任务跑多次。

配套工具链也齐了：/claude-api build-eval 建首批端到端评测，/claude-api prompt-audit 把为旧模型写的指令标出来给 diff，/claude-api hillclimb 对着评测迭代改进，/claude-api cost-optimize 剖析调用账单提省钱建议。

flowchart LR
    A["审计：每个子代理定处置"] --> B["基线：约 10 条黄金样本跑分"]
    B --> C["合并总是连跑的子代理"]
    C --> D["一次折一个：提示词变 skill · API 变 MCP 工具"]
    D --> E{"折后评测对比"}
    E -->|"变差"| F["退回子代理形态"]
    E -->|"持平或更好"| G["维护：瘦提示词 · 剪死技能"]
    F --> B

值得称道的是套件的诚实披露：README 明说真实模型验证有限——示例由一个人、在一个模型上跑了两轮，merge 与 upkeep 环节还没在真模型上验证过。把它当参考实现而非开箱产品看待。

七、反方声音与边界条件

这篇指南在社区引发的讨论里，批评并不激烈，但边界提醒很实在。

最常见的提醒是「先测再拆」：机器学习研究者 Omar Sanseviero（@omarsar0）基本赞同新模型驾驭长上下文的能力变强，但强调撕掉子代理前要先跑成本与效率评测——他自己的并行研究场景仍然依赖子代理的独立上下文窗口。也有社区作者给出反例：把日志与报错的深挖工作交给子代理、只回传摘要，token 用量反而减半——上下文隔离不总是膨胀源，有时是省钱阀。

文章自己列的 as-tool 代价也值得掂量：子代理当工具调，每次调用都是一个嵌套的模型循环，延迟照样累加，有损摘要问题也并未消失——它只是从「架构债」降级成了「调用债」。

还有一条社区观察颇有讽刺意味：这篇讲上下文纪律的指南发布时，Claude Code 的 harness 正在被吐槽每个后台代理的完整对话记录每约 30 秒被重发一次，只为生成一个 3-5 词的状态标签——据 daily.dev 汇总的社区讨论，有开发者自称测得这部分占总花费 16.4%，而官方口径平均约 2%（此为社区单一来源数据，供参考，官方无正式文档）。另一个细节是 Boris Cherny——Claude Code 的创造者——自己也修正过早期建议，转向 Auto Mode 与极简系统提示词。工具作者和工具使用者一样，都在边跑边改立场。

这些声音合起来不构成对文章的反驳，倒是给它补了一条隐藏条款：减法的对象是「未经测量就长出来的复杂度」，而不是复杂度本身。并行研究、独立验证这类真有多上下文收益的场景，子代理依旧是正解。

结语：架构不重要，原则重要

文章的结尾把姿态放得很低：具体架构（单循环还是多代理）远不如底层原则重要——「测量，一次只改一件事，留下经得起测的」。建一个小的端到端评测，折一个子代理，折完分数变差就退回去，如此往复。

对正在搭代理系统的开发者，本文认为可以带走三条：

1. 默认单循环起步：子代理是按需引入的能力，不是默认架构；新增一个子代理前，先问它有没有挣到一个独立的上下文窗口；
2. 评测是一等公民：架构争论没有裁判，端到端评测才有；10 条黄金样本的成本，远低于一次错误的架构押注；
3. 按上下文边界拆分：该拆的时候，切在「信息天然独立」的地方，而不是「部门 chart」的框线上。

多代理没有死——它回到了它该在的位置：为真正并行的、上下文天然隔离的任务准备的特殊工具。而绝大多数代理系统要回答的问题，从「怎么拆」变成了「怎么在一个循环里装得更多」。

参考资料

• Building agents: When to fold subagents into your main agent loop — Anthropic 原文，2026-10-22，本文主要精读对象
• anthropics/single-agent-loop-kit — 配套迁移套件，审计判定与脚本（coupling_map、chain_coverage 等）都在这里
• Building effective agents — 2024-12 的奠基文章，「最简单方案优先」的出处
• How we built our multi-agent research system — 2025-06，多代理 90.2% 提升与 15 倍 token 代价的原始报告
• Don't Build Multi-Agents — Cognition 2025-06 的著名反方，「共享全上下文」「行动即隐含决策」两原则
• Anthropic says your subagents are just Conway's law — daily.dev 对本文的社区反应汇总，反方观点主要来源