Anthropic：何时该把 Subagent 折回主 Agent Loop · 干货攻略

  • 链接: https://x.com/omarsar0/status/2114057736363352127
  • 分类: x-tips
  • 来源: X @omarsar0（elvis）
  • 作者: Jay
  • 更新: 2026-10-26
  • 仓库: https://github.com/anthropics/single-agent-loop-kit
  • 官方原文: https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

这是什么

一条 X 帖子（@omarsar0，2026-10-24）推荐 Anthropic 官方新文 《Building agents: When to fold subagents into your main agent loop》（发布于 claude.com，主题为“什么时候该考虑少用 subagent”），配图是该文 “Reducing subagents over time” 一节的示意图。

这不是“又一篇多智能体框架文”，而是 Anthropic Applied AI 团队主动劝退一部分企业把 subagent 拆出去的官方指南：他们比较了多个企业部署后得出结论——“一个带 skills 的单 agent”往往在质量上胜过 subagent 架构，且单任务的成本与延迟更低。

原帖作者本人的立场与官方一致：他说 frontier 模型在上下文管理上进步后，subagent 仍有用，但主要用在复杂研究任务的并行化（各自独立上下文窗口），自己则主要通过动态工作流跑研究。

核验来源

官方来源（已读全文）： - 官方文章：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop（读取完整正文，非摘要） - 官方仓库：https://github.com/anthropics/single-agent-loop-kit（HTTP 200，Anthropic 官方组织 anthropics 下的 single-agent-loop-kit，即文中所称 migration kit） - 原帖：https://x.com/omarsar0/status/2114057736363352127（经 X syndication 接口核对正文与图片资源）

关键数字的出处（全部出自上述官方文章正文）： - 单 agent loop 相对多 agent harness 约 2 倍更快（“One customer that evaluated their multi-agent harness against a single agent loop saw a roughly 2x faster runtime”） - Claude Code 系统提示词对高级模型削减超过 80%，原因之一就是渐进式披露 skills 与工具 - 工具定义超过 30–50 个后，工具选择准确率会退化，建议按用户意图分组并配合 tool search 延迟加载 - 任务完成度 eval 10 条 golden example 即可起步 - “一条清晰的系统提示 + 4–5 个薄数据工具 + 硬性输出护栏”可覆盖多数用例

核心内容

什么时候 subagent 仍然该留

官方明确列出三条保留条件： 1. 单 agent loop 因上下文膨胀出现可测量的性能退化； 2. 多个任务需要并行处理，且各自需要用完即弃的干净上下文窗口； 3. 单 agent 难以选择合适工具，或系统提示里存在互相冲突的指令。

原帖作者的第 2 条（并行化研究任务）正落在这一条上。

大组织做 agent 的五种典型失败模式

  • 上下文管理：多 agent 之间传递什么上下文需要人肉设计，来回传递丢失细节；
  • subagent 蔓延：每个团队各交付一个 subagent，最后几百个功能重叠、无标准无归属；
  • Frankenprompt：每个团队往系统提示里塞一句，规则互相打架、语气不一致；
  • eval 局部化：各自只优化自己子任务的 eval，没人负责端到端；
  • 延迟：多 agent 的结构复杂度直接转化为延迟（客户实测约 2x）。

推荐的“单 loop”目标形态

  • 一个模型、一个上下文窗口，跑开放式工具循环，限制（turn/成本预算、写入门禁）由 harness 承担；
  • 每轮模型发出一批工具调用，harness 并行执行后把原始结果交回同一模型，由它决定下一批 / 追问用户 / 收尾；
  • 循环在模型作答或触达 budget 时结束，之后可选跑 goal/verifier 检查；
  • 写计划和执行计划的是同一个模型，因此可以中途改计划；
  • 领域流程与顺序规则下沉到 skills，硬性限制（校验、审批）与中途才需要的东西（记忆查询）下沉到 tools，机械活（payload 构造、流解析、恢复澄清）留在工具里用代码做。

分阶段迁移路径（官方给出的四步）

  1. 先建任务完成度 eval：一个中心团队拥有的端到端 eval 集，加上每个 skill 随附的小 eval；有 orchestrator 时先量“路由准确率”，折进来后改看“是否加载了正确的 skill / 调用了正确的工具”。
  2. 合并领域 subagent：合并那些输出首尾相接、碰同一批数据、或经常被连续调用的 specialist。
  3. 把 subagent 当工具调用：主 agent 以工具方式调子 agent 并继续持有对话，可共享响应 schema、用主 agent 拿真实数据复核结论；只有当子 agent 必须直接跟用户对话时才做完整 handoff。残留问题：每个专家仍有自己的 prompt/owner/eval、每次调用仍回传有损摘要、每次调用仍是嵌套模型循环（加延迟）。
  4. 折成 skills + MCP tools：一次只折一个，把 prompt 变成 skill、把 API 调用变成 MCP tool，对比有无该 subagent 的 eval 分数，并看哪些任务发生了翻转。

官方给了一个反直觉的实测：在一个客服 agent 样本上，把某个 subagent 折进另一个，延迟降了，但破坏了原本通过的流程——主 agent 拿着订单查询工具自己作答，没有去问发货专家要预计送达日期。官方因此要求：每条链上会一起跑的 agent 组合、每条不能破的规则都要有 eval 任务，且每条任务跑不止一次（该次断裂在两次里只出现一次）。

多个团队如何共同喂一个 agent

  • MCP tools：适合执行动作、读实时数据、返回固定结构；按用户意图分组，用 tool search 延迟加载；工具内部做硬前置校验和按用户权限返回可读拒绝。
  • Skills：适合承载“这一行怎么做”的步骤、规则与判断；每个团队设 DRI 拥有自己的 skill，并用 /skill-creator 编写、/skill-doctor 审计成本与使用率、删除死重。
  • 知识库：适合只是偶尔需要的事实与参考材料，放在检索/查询工具后，或作为 skill 内的参考文件——官方明确反对“让代码把上下文捞出来粘进 prompt”。

配套工具

官方发布了 Claude API skills 组成的 migration kit（仓库即 anthropics/single-agent-loop-kit），可先在 mock 系统上演示再上真实系统： - /claude-api build-eval：搭第一套端到端 eval 或每个 skill 的小 eval； - /claude-api prompt-audit：标记为旧模型写的指令并给出 diff 修正； - /claude-api hillclimb：对已有 eval 迭代改进，正好用于“折进来 vs 保留”的对比； - /claude-api cost-optimize：profile 调用开销，从 prompt 缓存、裁剪 token、effort、模型选择逐项省成本与延迟。

上手步骤（面向想动手的团队）

  1. 别先改架构，先建 eval：抓 10 条真实用户请求当 golden example，用 rubric 给最终回复打分。
  2. 量现状：如果你有多 agent harness，量端到端延迟和单任务成本，和单 loop 的数字对比（官方案例约 2x）。
  3. 画依赖图：标出哪些 specialist 经常被连续调用/碰同一数据/输出首尾相接 —— 这些是首批合并候选。
  4. 一次折一个：prompt → skill，API 调用 → MCP tool；折完跑同一个 eval，并逐条比对翻转的任务。
  5. 别信平均值：每条 eval 任务跑多次，官方案例里的回归就只在两次中出现过一次。
  6. 收缩工具面：工具定义控制在 30–50 个以内，超了就按意图分组 + tool search 延迟加载。
  7. 多团队协作：每团队把自己的 subagent 交成 skill + tool，由一个小的中心团队持有系统提示词与端到端质量，对新 skill/tool/eval 统一准入。

适用边界

  • 面向 Claude Platform 上的企业级多 agent 系统（Anthropic 自家部署与客户部署的观察），不是面向普通终端用户的“Claude Code 使用技巧”。原文里的数字（2x、80%、30–50、10 条）都是原文举例与经验值，不是通用基准。
  • 官方明确没有否定 subagent：并行研究、独立验证、模块化权限仍是它的强项，并给出上面三条保留条件。不要读成“subagent 过时”。
  • 结论随模型能力变化。原文点名：自 Opus 4.5 起模型在单 loop 里能管理的事远超多数团队预期；提到 Opus 5.5 无法关闭 thinking、Fable 5.1，以及新模型会自述进度、自查结果，使部分 harness 元素冗余。模型换代后需要重新评估，官方原话是“measure, change one thing at a time, and keep what holds up”。
  • 文章面向有多个团队、多产品的组织；单人或小团队照抄“中心团队持有系统提示词”这类组织设计没有意义。
  • 单 loop 设计对工程纪律要求更高：系统提示词要精心维护、skill/工具描述要能在正确时机触发、上下文窗口/记忆/笔记要显式管理。文章不提供可直接复制的 prompt 模板。

不确定处

  • 原帖正文只是推荐 + 一张图，没有给出 Anthropic 原文链接；官方文章链接是通过原帖图片对应的引文推文（@cherry_mx_reds 的链接卡片）解析得到，卡片标题为“Building agents: When to fold subagents into your main agent loop”、域名 claude.com，与本文正文一致。
  • 原帖图片是官方文章中的“Reducing subagents over time”示意图（合并 subagent / 把 subagent 当工具 / 折成 skills 与 tools 三步），图片本身不含数字。
  • 文中 Claude Code 子命令（/skill-creator、/skill-doctor、/claude-api *）来自官方文章与官方文档入口（https://code.claude.com/docs/en/commands），本次未逐条打开命令文档核验其参数与安装方式。
  • 官方仓库 anthropics/single-agent-loop-kit 仅确认存在与归属（HTTP 200、owner=anthropics），未运行其 demo。