别急着加 agent：Anthropic 为什么劝你先把 subagent 折回主循环
Anthropic 应用 AI 团队建议：先建 eval，再把 subagent 一个一个折回主循环，并盯住通过/失败的翻转；配套开源 single-agent-loop-kit。
公司长什么样，系统就长什么样。
这是软件行业一条很有名的观察，叫康威定律。
10 月 22 日，Anthropic 应用 AI 团队在 claude.com 上发了一篇文章，把这条定律用到了 agent 身上。
大意是：很多多 agent 系统，长得很像设计它的那张组织架构图。
一个 router 在上面，下面挂着订单专员、物流专员、退款专员……
看起来分工明确，职责清晰。
但是，真的更好吗？
不一定。
为什么？
一、传话游戏
我们先来看一个公式：
传话次数 × 每次损耗 = 信息失真
传话游戏，很多人小时候都玩过。
第一个人说一句话，一个接一个传下去，传到最后，常常已经面目全非。
多 agent 系统，也有类似的问题。
router 把任务拆开，交给子 agent。
子 agent 只看得到自己那一份上下文。
做完了，再把结果压缩成一段话，交回去。
每一次交接，都是一次压缩。
每一次压缩，都可能丢东西。
Anthropic 在文章里，就用了“传话游戏”（telephone game）这个说法。
那怎么办？
把传话的环节去掉。
二、推荐的终态，长什么样
Anthropic 给出的推荐终态，可以用一个公式概括：
一个模型 + 一个上下文窗口 + 开放式工具循环
听起来很简单。
关键在细节。我拆成四点来说。
第一，harness 负责设边界。
轮数预算，成本预算，写入闸门。
模型可以自由地调用工具，但不能无限地转下去，也不能随便写东西。
自由，是在边界里的自由。
第二，工具调用批量发、并行跑。
每一轮，模型一次发出一批工具调用。
harness 并行执行，再把结果原样交回给同一个模型。
请注意两个词：“原样”和“同一个”。
没有中间商。
没有转述。
第三，计划写在上下文里。
模型在第一轮，就把计划写进上下文，然后随着结果不断修订。
为什么这很重要？
因为，写计划的，就是执行计划的。
在多 agent 架构里，往往是 router 写计划，子 agent 执行。执行中发现计划不对，得一层一层往回报。
在单循环里，它发现不对，当场就能改。
第四，东西各归其位。
流程、领域步骤 → skills
硬约束（校验、审批）、记忆查询 → tools
这个分法，很有讲究。
skills 讲的是“怎么做”，可以按需加载。
tools 讲的是“必须这么做”，由代码来保证，不靠模型自觉。
把审批写在提示词里，叫“希望它遵守”。
把审批写进工具里，叫“它绕不过去”。
一个靠自觉，一个靠机制。
三、怎么迁移：不是一刀切
那是不是把所有 subagent 一口气都合并掉，就好了？
不是。
Anthropic 给的方法，是一个很朴素的工程顺序：
先测 → 一次折一个 → 前后对比 → 看翻转
先测。
做一套任务完成度的 eval。
文章说，10 个 golden 例子，就能起步。
不用等到有一个完美的评测集，才开始动手。
一次折一个。
每次只合并一个 subagent。
它原来的 prompt，变成一个 skill。
它原来调用的 API，变成一个 MCP tool。
前后对比。
不只看总分。
看翻转。
看哪些任务“翻转”了：原来通过的，现在失败了；原来失败的，现在通过了。
为什么不能只看总分？
因为，总分可能纹丝不动，底下却是一个任务坏了，另一个任务好了。
平均数，会掩盖很多事情。
四、一个真实的翻转
文章里给了一个例子，非常值得细读。
在一个示例客服 agent 上，他们把一个 subagent 折进另一个之后，延迟降了。
这是好事。
但是，一个原本能通过的流程，坏了。
怎么坏的？
主 agent 手里有订单查询工具，就拿着它自己回答了，没有去问物流专员要送达日期。
更麻烦的是，这个问题，在两次运行里，只出现了一次。
这说明什么？
说明如果只跑一次 eval，你可能根本看不见它。
所以，Anthropic 的建议是：每个任务，要跑多次。
这个例子告诉我们一件事：
合并 ≠ 免费
延迟的收益，是看得见的。
行为的变化，是藏起来的。
当然，收益也是真实的。
据 Anthropic 文章，有一家客户把自己的多 agent harness 和单 agent 循环放在一起评估，后者跑得快了大约一倍（原文是 roughly 2x faster）。
请注意，这是 Anthropic 转述的单个客户的结果，而且是两种架构放在一起对比，不是一个普遍规律。
你的系统能不能得到同样的结果，只有你自己的 eval 能回答。
五、subagent，没有过时
读到这里，你可能会想：那 subagent，是不是该淘汰了？
不是。
文章并没有这么说。
它说的是：别默认就用多 agent。
但有几种情况，subagent 仍然合适。
验证。 让一个独立的 agent 检查结果，它不会被主循环的思路带偏。
并行。 几件真正互不相关的事，可以分头去做。
权限隔离。 有些工具，只该让某一个 agent 碰。
文章原话是，subagent 擅长验证、并行和模块化的权限划分。它还点了三种情况：单循环因为上下文膨胀，出现了可以测出来的性能下降；几件并行的事，各自需要一个干净的新上下文；单个 agent 选不对工具，或者系统提示里的指令互相打架。
文章最后给的规则也很干脆：折进去一个，只有折进去之后分数更差，才把它留作 subagent。
所以，正确的问题，不是“要不要 subagent”。
而是：这个 subagent，存在的理由是什么？
如果理由是“组织架构图上有这个岗位”，那就该考虑折回来。
如果理由是验证、并行、权限隔离，那就留着。
六、工具箱：single-agent-loop-kit
道理讲完了，怎么动手？
Anthropic 在 GitHub 上放了一个配套仓库：anthropics/single-agent-loop-kit。
先说清楚：它是参考实现，官方写明不维护，也不收 PR。
它把迁移拆成了几步：
audit → baseline → merge → fold → as-tool → upkeep
第一步 audit，审计。
对每一个 subagent，判定它该折回（fold）、合并（merge）、作为工具调用（as-tool），还是保留。
然后建 baseline。
再依次做 merge、fold、as-tool。
最后是日常维护，upkeep。
仓库里有几个脚本：
- coupling_map.py：从 trace 导出里看，哪些 subagent 承担了流量，哪些总是一起跑
- compare.py：对比完成度、延迟、调用次数、token、成本
- chain_coverage.py：确保 eval 覆盖生产里的每一条 agent 链
- estimate.py：估算下一次 eval 运行要花多少 token
还有一个小型的单循环参考实现，reference_loop/loop.py。
仓库里带了一个示例 support-desk：一个 router 加 6 个 subagent，19 个 eval 任务，200 条合成的生产 trace。
设 KIT_MODEL=fake，可以零成本先做一遍连通性检查（KIT_MODEL=fake python3 evals/run_eval.py --variant smoke）。
用法也简单。
把仓库里的 skill 目录复制到你项目的 .claude/skills/single-agent-loop，在 Claude Code 里说一句：“Run the single-agent-loop skill.”
它会在这些节点停下来，等你确认：审计之后，付费运行之前，baseline 之后，每次改动之后。
我最喜欢的，是这个设计。
在花钱之前，停一下。
最后的话
回到开头。
公司长什么样，系统就长什么样。
但是，agent 不是员工。
人需要分工，很大程度上是因为一个人的精力有限、记忆有限、能看到的信息有限。
把人的组织架构，直接搬给模型，可能把人的限制，也一起搬了过去。
所以，下次想再加一个 agent 之前，先问自己一句：
我是在解决问题，还是在画组织架构图？
来源：Anthropic 原文（2026-10-22）；single-agent-loop-kit（Apache-2.0，官方不维护）。“快了大约一倍”是文章转述的单个客户对比两种架构的结果，不是普遍规律；客服示例与脚本用途据原文和仓库 README；“传话次数 × 每次损耗”等公式为作者概括。