https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop 讲讲这个

回复 群友 1384 这篇是 Anthropic 应用 AI 团队的一篇实战总结，核心观点是：现在很多企业把 router、planner、领域 subagent 折回主 loop，合成一个 agent，再用 progressive disclosure 补上 context 和工具，效果反而更好，每任务成本更低、延迟也更小。 文章里描述的失败演进路径值得注意：一开始，每个团队做各自的 agent，平台团队在上面加 orchestrator，结构看着最省事，但马上会带来几个问题：context 要在 agent 之间来回传，传一轮就会损失一些信息；subagent 数量失控后，上百个互相重叠的 subagent 没有统一标准和负责人；系统提示变成 Frankenprompt，每个团队往里加一句，规则互相冲突；eval 各自为战，都针对自己的小任务过度调优，没人负责整体质量，领导层则按这些被稀释的局部分数做决策。有客户把多 agent harness 和单 loop 做对比，后者的运行时间快了大概一倍。 他们推荐的替代方案是：一个模型、一个 context 窗口、一个开放式工具 loop，并在 harness 里设好轮次预算、成本预算和写入权限限制。每轮模型发出成批工具调用，harness 并行执行，再把原始结果返回给同一个模型，由模型决定下一步接着做、问用户还是作答。计划由执行它的那个模型在首轮自己写、边做边改——这是和 orchestrator 加专家的结构最本质的区别：写计划的和干活的是同一个。context 管理也下放：先后顺序和领域流程放进 skills，硬性限制（校验、审批环节）和对话中途才需要的东西（记忆查询）放进 tools，模型看到的是短描述，需要时才完整加载。 支持这个方向的三条理由都很实用：共享上下文的情况下，答案确实更好，长任务中途每一步的结果都放在同一个窗口里，模型能自己把这些步骤串起来，比一组 subagent 交回来的摘要有价值得多；progressive disclosure 解决了 context 膨胀，也就不再需要靠拆 subagent 来控制上下文，他们说 Claude Code 面向新模型的系统提示砍掉了八成以上；模型本身变强了，从 Opus 4.5 起单个 loop 能承载的任务远超多数团队预期，新模型会边做边报进度、自己回头检查，原先 harness 里不少部件因此变得多余。 subagent 并非不能用。文章给了三条明确适用条件：单 loop 出现可测量的 context bloat 导致的性能下降；多个任务需要并行、且用临时 context 窗口做完即可丢弃；或者单 agent 选不准工具、系统提示内部存在冲突。此外，验证类任务（generator-verifier）、研究前沿的并行探索、模块化权限控制，这些地方 subagent 依然好用。 如果真要拆，文章强调按上下文而不是按问题类型来切分边界：给每个 subagent 一块尽量少依赖其他部分的工作，交回紧凑结果，典型是独立研究路径、接口干净的独立组件、黑盒验证。按问题类型切分会玩起“传话游戏”，每交接一次保真度就下降。 迁移路线写得很克制：先做端到端 eval，哪怕十来个 golden 样例就能起步，并记录关键事件的时间戳，方便后续回放；然后按共享上下文合并使用度最高的专家（互相串着用、碰同一份数据、经常一起被调用的就是紧耦合，优先合并），或者先把 subagent 当工具调用，保留对话的主控权，只在该 subagent 必须直接跟用户说话时才做完整交接；最后再把每个 subagent 的 prompt 转成 skill、API 调用转成 MCP 工具，一个个折进来，比 eval 分数后再决定是否保留未折的版本。 他们踩过的坑也有参考价值：只比较最终分数不够，得看哪些任务的状态发生了翻转。他们测一个客服 agent 时，折叠一个 subagent 后延迟降了，但原本能通过的流程反而断了——主 agent 手里有查订单的工具，自己就把答案回了，没去问物流专家要送达日期。所以每次改动前，eval 里要给生产上会串起来的每个链条、每条不能破的规则都配任务，而且每个任务要跑不止一次，这个断点两次里只出现一次。 工具和 skill 那块有两个数值门槛值得记住：系统提示里工具定义超过 30 到 50 个，工具选择就开始退化，所以按用户意图分组，而不是一个 API 一个工具，超过就用 tool search 延迟加载；权限也不该靠给每个权限级别单开 agent，让每个工具自己检查调用者能看什么、然后返回一句模型能读懂的拒绝即可。skill 库为了防止失控，要每组有 DRI、配 eval，用 /skill-creator 和 /skill-doctor 修剪和清点，让写 skill 的人自己承担维护工作。 我自己的看法是，这篇的价值不在于“subagent 过时了”，而在于给了一个可操作的判断标准：先测量，一次只改动一个东西，留下能够站得住的做法。它和 Joye 之前讲 harness 的结论同源——harness 里每一处结构都隐含“模型现在做不到 X”的假设，模型一变，这些假设就可能过期；所以多 agent 的复杂度只有在被测出是必要时才值得付，其余大部分是给人看的组织结构图，不是给模型需要的推理结构。