你的 agent 架构，是不是照抄了公司的组织架构图

这两年搭 agent，圈子里有种默契，subagent 越多，架构越高级。

路由 agent、规划 agent、各领域专家 agent，上面再罩一个编排器。图画出来方框套方框，特别有安全感。

10 月 22 日，Anthropic 的 Applied AI 团队发了篇长文，核心意思就一句。很多时候，这些 subagent 该折回主循环了。

说这话的恰恰是圈内最懂多 agent 的一群人，他们自己的 multi-agent research system 就是 subagent 架构的标杆。这就有意思了。

一个反直觉的劝告

他们在好几个企业级部署里做过对比。单个 agent 配上 skills，质量上经常同时赢过「一个 prompt 包打天下」和「subagent 军团」两种设计，成本和延迟还更低。

有客户把多 agent 的壳和单循环放在一起实测，单循环跑完任务快了大约 2 倍。另一家公司发现，客服 agent 里那十几个专家 subagent，让统一的品牌语气没法维持，延迟还伤了用户体验。

左边是常见姿势，五层结构把模型围在中间。右边是他们常给的方案，一条 prompt，四五个工具，加护栏（图源 Claude 官方文章，下同）

他们还反复见到一种标准姿势的过度设计。意图分类器、固定的多步推理管线、用户分群桶、分开的推荐分支，最上面再来个多 agent 编排器。

反馈往往很扎心。这些结构大部分在做模型已经不需要别人替它做的事。一条清晰的 system prompt，四五个薄薄的数据工具，加上硬的输出护栏，就能盖住大多数场景。

你的架构，长得像组织架构图

为什么大家还是忍不住拆。答案很人事。

每个能力归一个团队，每个团队交出自己的 agent，平台团队再在上面搭编排器。康威定律的老朋友，系统架构照抄组织架构。

接下来的剧情可以背下来。上下文在 agent 之间传来传去，细节一路丢失，原文管这叫传话游戏。subagent 泛滥，几百个互相重叠，没人定标准也没人认领。system prompt 每个团队加一句，规则互相打架，凑成弗兰肯斯坦 prompt。eval 各写各的，都对自己的子任务过度优化，领导拿着兑水的分数做决策。

按问题类型拆，每次交接都在丢上下文。按上下文拆，写功能和写测试留在同一个 agent 里，只把跑测试这种不需要实现细节的活分出去

真要拆，拆法也有讲究。按上下文拆，别按问题类型拆。给每个 subagent 一块不太需要系统其他部分的工作，让它带回一个紧凑的结果。独立的研究路径、接口干净的组件、黑盒验证，都是好候选。

单循环的底气

一个循环怎么撑住原来一群 agent 的活。两个关键词，渐进披露。

上下文渐进披露靠 skills，工具渐进披露靠 tool search。agent 平时只看到 skill 和工具的简短描述，真要用的时候才完整加载。

这么做的理由有三层。

共享上下文出更好的答案。亲眼看过每一步中间结果的模型，能把它们连起来，这比 subagent 递回来的一堆摘要强得多。渐进披露治上下文膨胀，Claude Code 给新一代模型砍 system prompt，砍掉了 80% 以上。模型本身变强了，从 Opus 4.5 开始，单个循环能管的事超出多数团队的预期，新模型还会边干边自检，harness 里的一些零件正在变得多余。

单循环长这样。一个模型一个上下文窗口，跑开放式工具循环，预算和写闸门设在 harness 里。模型第一轮就把计划写进上下文，结果回来了随时改。写计划的和执行计划的是同一个模型，这是和编排器架构最本质的区别。

每一代新模型，都让你能把更多决策从 harness 挪回模型本身。

还有个隐性好处。简单的循环更容易迁移到下一代模型。他们帮客户做迁移时发现，最挡新模型发挥的，恰恰是僵硬的多 agent 结构。

什么时候留下，怎么折

文章没把 subagent 一棍子打死。三种情况该留。

单循环被上下文膨胀拖到性能明显下降。一堆任务要并行，且每个用一次性上下文就能干完，干完即弃。单个 agent 在工具选择上犯难，或者 system prompt 里的指令互相冲突。

留下的用法也有讲究。让主 agent 把 subagent 当工具调，对话始终握在主 agent 手里。只有当 subagent 需要直接和用户说话时，才做完整交接。

三条迁移路径。合并共享上下文的 subagent，把它们当工具调，或者彻底折成 skills 加 tools

折的动作要慢。先建任务完成度的 eval，哪怕只有 10 条黄金样本也够起步。编排器时代盯路由准确率，折进来之后改成盯它有没有调对 skill 和工具。

一次折一个。把 subagent 的 prompt 变成 skill，API 调用变成 MCP 工具，然后对比折前折后的 eval。别只看总分，要看哪些任务翻了车。

他们在一个客服 agent 上试过。折掉一个 subagent 之后延迟降了，但也弄坏了一个本来通过的流程。主 agent 拿着订单查询工具自己答了，没去问物流专家要发货日期。这种坏法两次运行里才出现一次，所以每个任务要多跑几遍。

一群团队，共建一个 agent

折完之后，组织的问法也变了。各个团队从「拥有自己的 agent」，变成「拥有自己的 skill 和工具」。

一个很小的中央团队握住 system prompt 和端到端质量，每个新 skill、新工具、新 eval 上线前都要过审。团队小，迭代才快。

工具按用户意图分组，别一个 API 一个工具。system prompt 里堆到 30 到 50 个工具定义之后，模型的工具选择能力就开始退化。

权限也放进工具里。每个工具自己检查调用者能看什么能做什么，返回一句模型读得懂的拒绝。于是同一个循环可以服务不同权限级别的用户，不用给每个等级单开一个 agent。

skill 的维护交还给写 skill 的人。skill-creator 负责把新 skill 生得规整，skill-doctor 负责看每个 skill 花多少 token、多久被用一次。每个团队设 DRI，防止 skill 像当年的 subagent 一样泛滥。

回头看，这篇文章其实在讲一句更朴素的话。架构的复杂度，应该跟着模型的能力走，而不是跟着组织的边界走。

当模型一代代把 harness 的活接回去，最好的架构是给自己留一条退路。

他们顺手开源了一个迁移套件 single-agent-loop-kit，引导式地带你识别哪些 subagent 该折、怎么折、折完怎么验证，可以先在模拟系统上演练再动真格。仓库在 GitHub 的 anthropics 账号下。

原文 Building agents: When to fold subagents into your main agent loop，作者 Diane Sarkis，Claude Platform，2026 年 10 月 22 日发布。