https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop 解读一下这个链接的内容，之前有群友讨论过的话就直接复用。

回复 贝尔 这篇 Anthropic 应用 AI 团队写的文章，群里的 Joye 昨天就让我讲过一遍，我直接在原文要点上再补一些更具体的内容。 核心结论：企业 agent 里的 router、planner、领域 subagent 合回主循环反而更好，质量不降，成本和延迟还更低。他们对多个企业部署做过对比：一个 agent 加上 skills，经常优于“所有需求一个 prompt”和 subagent 架构这两种做法。 问题出在组织结构上。每个团队各交一个 subagent，最后架构就成了组织架构的复刻（Conway's law，康威定律）：几百个重叠 subagent、没人负责；每个团队的 prompt 往系统提示里加一句，凑成互斥规则的“Frankenprompt”（缝合提示）；eval 各为自己子任务过度优化，领导层看到的分数是稀释过的；多层嵌套调用让延迟翻倍。有客户把多 agent harness 换成单 loop，运行时间约快一倍。 为什么现在能合：渐进披露解决了当初拆分的主要理由。skill 和 tool 只暴露简短描述，用到才完整加载。他们说 Claude Code 对更强模型把系统提示砍了 80% 以上，靠的就是渐进披露；模型本身也强了，从 Opus 4.5 起单循环能承担的事远超预期，新模型还能边做边复述进度、自查结果，很多 harness 部件就变得多余。 subagent 仍然该用的三种情况，原文写得很明确：单 loop 因上下文膨胀出现可测的性能退化；多个任务需要并行，且用独立的上下文窗口、做完就丢弃；单 agent 选不准工具，或系统提示里有互相冲突的指令。 迁移路径分三步，一步一步来：先建小型端到端 eval，十条黄金样例就够，不能只看总分，要看哪些任务发生了翻转；然后把 subagent 当工具调用，这不需要重写，但摘要损失、嵌套延迟、各自维护 prompt 的问题还在；最后逐个把 subagent 转成 skill 和 MCP 工具。 原文警告了一个容易忽略的坑：他们在一个客服 agent 上试过，合进去降低了延迟，却打破了一个原本通过流程——主 agent 手里有订单查询工具，就自己回答了，没去问物流 subagent 交付日期。这种问题两跑只在一跑出现，所以每个任务要跑多次。 工具方面它给了几个实用界限：工具按用户意图分组，不按 API 各给一个；系统提示里工具定义超过 30 到 50 个，选择准确率会下降；权限校验放进工具内部，让它自己返回可读的拒绝，而不是按权限等级拆 agent；知识库则用检索工具按需查，不要让代码把内容拼进 prompt。 它最后那句态度我比较认同：没有哪个架构是终局，方法是测一下、一次只改一处、留下仍然站得住的。