别把 Agent 架构画成组织架构图——子代理该不该拆，用任务级 Eval 说话

别把 Agent 架构画成组织架构图

别一上来就把 Agent 拆成一堆子代理。先让一个模型在同一个窗口里把活干完；哪块真顶不住了，再拿测试数据说话。

一家公司做了一个客服 Agent，底下按业务挂了十几个“专家子代理”：管订单的、管物流的、管退款的、管账户的，分工图画得明明白白。

一上线就露馅了。用户的提问从来不会老老实实只占一个格子——问一句跨领域的，请求就得在几个子代理之间来回转手。每次转手，前一个子代理只交出一段压缩过的摘要；对外说话的语气，全看最后接话的是哪个专家；层数一多，用户光等它们内部“开会交接”就要等半天。

这是 Anthropic 应用 AI 团队在 2026 年 10 月 22 日一篇企业实践复盘里讲的真实案例。他们没有说“子代理没用”，而是捅破了一层窗户纸：很多公司把 Agent 越做越复杂，只是在照抄自家的部门架构图，任务本身根本不需要拆这么多层。

过去大家拿到需求，第一反应往往是：“这个 Agent 该拆成几个子代理？”这篇复盘把问题倒了过来： “你凭什么拆？”

下面顺着这个问题聊透三件事：什么时候真该留着子代理、已经拆散的子代理怎么安全收回来，以及收回之后多个团队怎么一起干活。具体框架的底层源码交给文末延伸阅读。

子代理买的是隔离，付的是传话费

先把“子代理”到底是什么说成大白话。

子代理不是什么“更懂业务的模型”，它其实就是单开了一个新聊天窗口的模型。它有自己独立的一套提示词和工具，看不到外面主对话之前聊了什么，全靠外面的总管（协调器）派活、传话。拆出子代理，能换来三样东西：

• 窗口干净（上下文隔离） ：子代理看不到主对话的杂音，适合去做独立调研或黑盒验收。
• 能同时跑（并行） ：几个互不相干的子任务可以各自开新窗口同时跑。
• 好管权限（权限边界） ：不同子代理只发不同的工具，互不越权。

但账不是只算一面。你每拆一个子代理，都在付三笔“传话费”：每次交接都要把过程压成一段二手摘要，细节全在压缩里丢了；每个子代理都要单走一轮提示词和模型调用，层数一多耗时就翻倍；每个团队各管各的提示词和测试，最后没人对用户拿到的最终结果负责。

主循环（后文也叫单循环） 走的是另一条路：不搞分身，从头到尾只有一个模型、守着同一个上下文窗口干活。每一轮模型决定要调哪些工具，外面的运行框架（Harness）帮它并发执行完，把原汁原味的原始结果塞回同一个窗口；模型看一眼结果，自己决定下一步是继续查、问用户，还是直接给答案。运行框架只负责在外面管住轮次上限、预算和写入确认。

维度	拆子代理	单循环（只跑一个主循环）
记忆与上下文	各自独立窗口；交接靠传摘要，容易丢细节	同一个窗口，前面查出的原始数据后面随时看
并行能力	天然适合多开窗口各跑各的	靠单轮同时发多个工具调用并发，结果回同一窗口
耗时与成本	循环套循环、来回传话，通常更慢更贵	少掉中间交接轮次，通常更快更省
团队维护	各管各的提示词和局部测试，容易扯皮	主提示词和端到端体验有人兜底
最大风险	传话失真、子代理满天飞、说话口气割裂	窗口塞太满、提示词和工具没设计好

一句话：拆子代理，本质上是拿“传话丢信息”和“变慢”，去换“窗口隔离、并发和权限隔离”。 这笔买卖划不划算，看任务本身，不看架构图画得漂不漂亮。

为什么 Agent 会长成部门架构图

大公司做 Agent，最容易踩的坑就是按部门分地盘。

起点通常很朴素：公司想做一个统一入口的超级 Agent，把所有产品能力串起来。但订单归 A 组、物流归 B 组、账户归 C 组。怎么推进最不得罪人？各组先闭门造自己的子代理，平台组最后在头顶加个“总调度”（编排器），或者把各组的 Agent 包装成 MCP 工具挂给主 Agent。

这么干在组织管理上最省事，落到系统里却会炸出五个毛病：

1. 传话丢细节（上下文管理） ：子代理之间不共享完整记录，来回倒手两三次，用户的原始诉求和前置条件就漏光了。
2. 子代理满天飞（子代理泛滥） ：每个组都发自己的子代理，最后攒出几百个功能撞车的 Agent，没统一标准，出了问题也找不到人。
3. 缝合怪提示词（Frankenprompt） ：每个团队都往主提示词里塞两句“必须遵守某某规定”，规则前后打架，Agent 说话像换了好几个人。
4. 各自刷分，没人管总结果（局部 Eval） ：每个组只拿自己那一亩三分地的测试集刷分。单看每个子代理都是 95 分，串起来用户还是办不成事——汇报给管理层的是一堆注水的局部高分。
5. 慢（延迟） ：一层套一层地调模型、等摘要。Anthropic 提到一个客户把多代理架构改成单循环之后，运行时间直接砍半（快了约 2 倍）。

这就是康威定律（Conway's law）在 Agent 时代的翻版：你公司的部门墙长什么样，做出来的 Agent 架构就长什么样。

每个团队守着一个子代理，用户体验到的就是部门之间的那条缝：退款专家不知道物流专家刚查过什么，物流专家不知道账户专家是怎么判的，用户问一句话，在后台撞上三次转接。

团队分工本身没错，错的是把“谁负责维护代码”直接画成了“请求在运行时要跨几个模型”。用户不关心你们公司分几个部门，只关心一句话问出去能不能办成事。

单循环为什么突然够用了

不拆子代理，那几十上百个业务规则和工具怎么塞进一个模型里？答案很简单：一个主循环，加上“先看目录、用到再翻书” （也就是原文说的渐进披露，progressive disclosure）。

• skill（做事方法按需翻阅） ：平时上下文里只放几行“技能目录”（每个 skill 的名字和一句话简介），模型判断当前任务用得上，再去加载那份完整的操作说明。
• tool search（工具定义按需搜索） ：不用一上来把所有工具的参数格式全塞进系统提示词；平时只留工具名和简介，真要调哪个工具，再临时拉取它的完整定义。

图 1：按组织架构拆子代理与「主循环 + 渐进披露」的运行时对比。前者在跨代理交接中丢失细节、叠加延迟；后者把上下文留在同一窗口，靠按需加载控制膨胀。

为什么现在这么干反而效果更好？背后有三个原因，一个比一个实在。

第一，不传二手话，答案才完整。 长任务里，前面几步查出来的原始数据全留在主窗口里，模型后面能随时回头核对、串联线索。子代理交回来的只是一段摘要，摘要里漏掉的一句话，主模型就永远看不到了。

第二，“窗口塞不下”的顾虑被按需加载解掉了。 以前大家爱拆子代理，最常见的理由是“业务规则和工具太多，一个提示词装不下”。现在平时只挂目录、用时再加载正文，系统提示词一下就瘦下来了——Anthropic 用这套办法，在更强的模型上把 Claude Code 的系统提示词砍掉了 80% 以上。

第三，模型自己变聪明了。 从 Opus 4.5 开始，模型在一个循环里能稳住的复杂度远超很多团队的预期；更晚出的新模型干脆关不掉推理（thinking），自己会边干活边记进度、边回头检查。

第三条最值得画重点：你们系统里很多子代理，根本不是为了今天的任务建的，而是为了给昨天的老模型打补丁。 老模型记不住长指令、不会自己复查，才要人用外部框架扶着它一步步走；模型一升级，以前搭的拐杖就从“帮忙”变成了“挡路”。

Anthropic 在帮企业看方案时，经常看到一种“五层套娃”设计（见图 2 左）：请求进来，先过总调度，再过意图分类器，再走写死的五步推理流水线，接着按用户分群分桶，最后才进推荐分支。看着极其严密，其实大部分框框都是在替老模型操心。换成今天的做法：1 份清楚的系统提示词 + 4 到 5 个查数据的轻量工具 + 一道严格的输出护栏，一个循环就能把绝大多数场景跑通。

图 2：Anthropic 原文动图——围绕模型叠 5 层固定编排结构（左），不如收敛成 1 个循环：1 份清晰系统提示 + 4–5 个轻量数据工具 + 严格输出护栏（右）。

当然，单循环不是写几句提示词就能躺赢。它要求你把功夫花在刀刃上：系统提示词要保持干净，skill 和工具的简介要写得准（否则模型不知道什么时候翻开它），窗口里的历史记录也要及时清理。说得直白点，它是把原本花在“画编排图、调子代理交接”上的精力，收回来打磨提示词、工具和护栏。

什么时候还该保留子代理

前面说子代理能换来“窗口隔离、并发、权限边界”，但这里面有一个是伪需求：只为了管权限，不需要拆子代理（权限校验直接写进工具代码里就行，下一节细讲）。

排掉权限之后，真正值得在运行时保留子代理的条件只有三条。占其中一条才拆；一条都不占，就该把子代理收回主循环（原文叫“折叠”，fold）：

1. 单循环因为窗口塞太满，测出来效果真掉了（上下文膨胀导致可测量的性能下降）。
2. 有几个子任务必须同时跑，而且跑完中间过程就能扔（需要并行且窗口用完即弃）。
3. 工具太多模型总选错，或者系统提示词里的规矩互相打架（工具选择退化或指令冲突）。

注意第一条里的“测出来”。不是你看着提示词觉得长，而是手头有 Eval（评测集）数据证明：合在一起之后准确率确实掉了。

如果真满足这三条、必须拆子代理，也别一上来就画大网，先从“一个生成 + 一个检查”（generator-verifier）或简单的一主一从（orchestrator-subagent）开始。拆的时候守住一条铁律：按“要不要看同一份上下文”来拆，别按“业务工种”来拆。

按工种拆（退款一个、物流一个、账户一个）最顺应人的直觉，但全是“传话游戏”（telephone game），多传一次就失真一次。真正适合拆出去的，是不需要知道前因后果、只交回一个简短结论的活——比如去独立搜一条支线资料，或者做黑盒验证。

拿写代码的 Agent 举例最清楚（见图 3）：如果你按工种拆成“1 号写功能 → 2 号写单测 → 3 号审代码”，每次交接都会丢背景，写单测的 2 号根本不知道 1 号写代码时为什么这么取舍；反过来，按上下文边界拆，写功能和写单测明明看的是同一份代码上下文，就该留在同一个 Agent 里一次干完，只把“敲命令跑测试、报通过还是报错”的验证器（Verifier）拆出去——跑测试看报错不需要知道代码当初是怎么想的。

图 3：Anthropic 原文配图——按问题类型拆（上）每次交接都丢上下文；按上下文边界拆（下）由同一个 Agent 写功能与单测，只拆出无需实现上下文的 Verifier 跑测试。

要是线上已经跑着一堆子代理，不敢一下子全删掉重写，还有一个很稳的过渡招：把子代理降级成工具调用。

做法是：从头到尾只让主 Agent 跟用户说话；需要某个子代理时，主 Agent 像调普通接口一样调它，让它按固定格式（schema）把结论和关键依据一起退回来，只有必须由子代理直接跟用户多轮追问时才交接话筒。这么做不用立刻重写子代理，能先拉出一条测试基线；但它只是过渡——底下还是多跑了一轮模型，耗时和摘要损耗都没消掉。

怎么把子代理收回来：先备考卷，一次改一个

这套经验里最实用的部分，是它给出了三步收敛路径（见图 4）和一套不会把线上改崩的操作顺序。

图 4：Anthropic 原文动图——减少子代理的三种路径：① 合并共享上下文的子代理（Merge subagents）；② 主 Agent 把子代理当工具调用（Call them as tools）；③ 提示词转 skill、API 调用转 tool（Fold into skills and tools）。

具体动手时，严格按这三步走：

第一步，未动代码，先备考卷（建 Eval）。 平台组手里握一套测完整流程的端到端 Eval；各业务组交 skill 时，顺手附带几道专项小题。别被 Eval 这个词吓住，哪怕先挑 10 道最典型的真实用户问题（黄金样例），也够开工了。

刚开始可以先拿打分标准（rubric）给最终回复打分。还没拆掉编排器时，顺带看一眼“有没有分对子代理”；收回主循环后，改看“有没有翻开对的 skill、调对的 tool”。但往后走，核心考卷一定要看 “用户的事最后办成了没有”（任务完成 Eval） ——比架构好坏，路由准不准只是过程，把事办完才是硬道理。

第二步，先拿“天天黏在一起”的子代理开刀。 翻一下线上调用日志：如果大批请求都是“刚调完专家 A，紧接着必调专家 B”，说明它俩干的本来就是同一条链上的活、看的也是同一摊数据。先把这种紧耦合的对子合成一个。

第三步，一次只收一个，每道题至少跑两遍。 把这个子代理的提示词抽成 skill，调接口的动作抽成 MCP 工具，然后拿同一份考卷对比改前改后。千万别只看总分，要挨个看哪道题发生了“翻转”（原来能过的突然挂了）。

Anthropic 在改一个客服 Agent 时就抓到过一次典型翻车：把一个子代理合进主 Agent 后，响应速度确实快了，但一道原本通过的题挂了——主 Agent 手里正好有“查订单”工具，它查完订单就直接凭感觉回复了用户，漏掉了原本“找物流专家核对送达日期”那一步。更隐蔽的是，这道题跑两次才挂一次。

这个教训很实在：

• 变快不等于变好。 少了一次交接，可能会顺手漏掉原本藏在交接环节里的一道检查。
• 每道题至少跑两遍。 模型发挥有波动，只跑一遍过关，很可能只是撞上了运气。

所以每次合并前，考卷里必须包含线上常串在一起跑的业务链，以及绝对不能踩的红线规则；每道题至少连跑两次以上。

图 5：子代理保留判定与渐进折叠闭环。先过三条可测量保留条件，再以「一次折一个 + 多轮端到端 Eval」捕获隐性任务翻转。

多团队怎么合写一个 Agent

把子代理收回主循环，不是平台组要“收权”，而是各业务团队交付的东西变了——以前每组交一个“人”（独立子代理），现在每组交“手艺”和“工具” ：

交付物类型	里面放什么	实操铁律
MCP 工具	查实时数据、调接口、改状态等真动作	按“用户想干什么”分组，别一个后端接口对应一个工具；常驻工具定义一旦超过 30–50 个，模型就会开始选错
skill	团队做事的步骤、判断规则、处理方法	每个团队定一个直接负责人（DRI），配专项小测试，定期清理没人用的废规则
知识库	政策条款、指标定义、产品说明等死资料	挂在搜索工具后面或放进 skill 附件里按需查；别在代码里预先搜出来硬塞进系统提示词

工具那条给出了一个很实在的经验水位线：系统提示词里常驻的工具定义超过 30–50 个，模型选工具的准头就会往下掉。 超过这个数，要么把细碎接口按用户意图合拢，要么打开 tool search 让模型按需搜。

这里还有一个非常值得抄的工程技巧：把“必须先做 A 才能做 B”的硬规矩，直接写进工具代码里。

比如前面那个“查完订单漏查物流”的坑，与其在提示词里反复叮嘱模型“退款前一定要查物流！”，不如直接在 create_refund 工具内部加一行检查：没拿到物流核验结果，工具就不执行，直接返回一段模型能看懂的下一步指令：

{
  "ok": false,
  "error_code": "PRECONDITION_REQUIRED",
  "message": "尚未核验物流状态。请先调用 get_shipping_status(order_id) 获取 delivery_date 与签收状态，再携带 shipping_check_id 重新调用本工具。"
}

权限控制也是同一个道理：不用给普通用户和管理员各造一个 Agent，让工具自己在代码里查当前用户的身份，没权限就返回一句清楚的拒绝原因。靠工具返回值现场引导模型，一个主循环就能稳稳接住不同流程和不同权限。

为了少干体力活，Anthropic 内部还顺手做了一套打下手的小工具（已开源在文末的 single-agent-loop-kit）：用 /skill-creator 和 /skill-doctor 写 skill、查哪些 skill 白占成本却没人用；用 /claude-api build-eval 快速拉起第一套考卷；再用 prompt-audit 揪出当年为老模型写的过时指令，配合 hillclimb（自动迭代提分）和 cost-optimize（算账降本）一轮轮跑。

这么一改，团队分工就顺了：各业务组从“养一个独立子代理”变成“维护自家的 skill、工具和知识库”；一个小巧的中央平台组守住主系统提示词和端到端总考卷，谁往里加新 skill、新工具，先过一遍总考卷再上线。

图 6：折叠后的多团队共建模型。各业务团队交付并维护自己的能力模块与专项 Eval，中央团队守住主系统提示与端到端质量。

别把经验数字当成死定律

把丑话说在前面：Anthropic 这篇是自家的企业客户复盘，不是中立的第三方评测报告。文里的客户是匿名的；“快 2 倍”来自某一个客户的对比，“提示词砍掉 80%”是他们修自家 Claude Code 的内部记录，“30–50 个工具”也是经验区间。这些数字拿来看清演进方向就够了，别当成死定律到处套。

单循环也绝不是银弹。所有步骤都在同一个窗口里滚，长任务跑久了照样会顶到上下文上限；skill 和工具的简介一旦写得含糊，模型就会在关键时刻“翻不开说明书”。

所以最稳妥的结论不是“以后都不许用子代理”，而是：别把子代理当成出厂默认配置。 先拿一个循环把事跑通；真撞上了测得出来的瓶颈，再拆；拆完之后，还得隔三差五拿 Eval 考一考它还值不值得留。

这也解释了为什么全文三句话不离 Eval。聊架构最容易变成看图审美：有人觉得画满框框和箭头的编排图才叫企业级架构，有人觉得极简才高级。Eval 的作用就是把争论拉回地面：同样的 10 个真实问题丢进去，哪个版本办成的比例高、哪个反应快、哪个在刁钻问法下不翻车，数据说了算。

落到项目里：五步动作与一张评估卡

把整套方法压成明天就能动手的五步：

1. 新项目默认单循环起步。 先别画多代理编排图。写清 1 份系统提示词、配 4–5 个轻量工具、加好输出护栏，先让一个循环跑起来。
2. 先攒 10 道真实考题（Eval）。 覆盖用户最常走的主流程，以及绝对不能破的红线。每道题至少连跑 2 遍。
3. 不满足三条保留条件，一律不拆。 只有“窗口撑爆且测出掉点”、“必须并行且过程可丢”、“工具选错或规则打架”三条之一坐实了，才拆子代理。
4. 存量子代理，先当工具调，再挨个往回收。 一次只收一个，盯紧有没有原本能过的题目发生翻转。
5. 模型一升级，重跑一遍考卷。 很多子代理和死规矩是给上一代老模型垫脚的，新模型上线后，及时把不涨分的旧拐杖撤掉。

下面这张评估卡可以直接复制到项目文档里，决定任何一个子代理的去留前先填一遍：

# 子代理保留评估卡

- 子代理名：
- 它解决的瓶颈：上下文膨胀 / 并行 / 工具选择退化或指令冲突（三选一，写实测证据）
- 折叠后的候选形态：skill / MCP 工具 / 知识库 / 继续保留
- 端到端 Eval：任务数 ≥ 10，每条运行 ≥ 2 次
- 折叠前分数：
- 折叠后分数：
- 翻转的任务：
- 结论：保留 / 折叠 / 再观察

填充示例（按上文客服场景构造的填写示意，非原文实测数据）：

# 子代理保留评估卡

- 子代理名：shipping-specialist（物流查询与催件子代理）
- 它解决的瓶颈：无（原为按部门职责拆分；生产流量中 70% 与订单/退款串行调用，无独立并行需求）
- 折叠后的候选形态：规则提取为 `shipping-policy` skill，接口合并为 `get_shipping_status` MCP 工具
- 端到端 Eval：15 条跨订单/物流/退款黄金用例，每条运行 3 次
- 折叠前分数：13/15 通过（平均耗时 11.4s）
- 折叠后分数：首轮 12/15（平均耗时 5.8s）；补齐退款工具对物流状态的前置校验后为 14/15
- 翻转的任务：首轮在“已发货未签收申请仅退款”用例中出现 1/3 次漏调 `get_shipping_status`，工具内加硬前置条件后修复
- 结论：折叠

留下来的是验证方法，不是架构图

Agent 架构没有一劳永逸的标准答案，但有一个不会错的顺序：先让一个循环把活干完，再让评测数据告诉你哪里真顶不住了。

子代理不是原罪，不问青红皂白默认拆才是。公司的组织架构图可以决定哪个团队维护哪个工具，但绝不该决定用户问一句话要在几个模型之间被踢来踢去。

原文最后那句话，很适合直接贴在团队白板上：

"measure, change one thing at a time, and keep what holds up."

先拿数据量，一次只改一处，只留下真正扛得住测试的东西。模型每隔几个月就会变强一截，今天非拆不可的理由，到了下个季度可能就不成立了；最后能沉淀下来的，永远是那套验证方法，不是那张画满框框的架构图。

参考与核验

• 原文：Diane Sarkis, "Building agents: When to fold subagents into your main agent loop", Claude by Anthropic, 2026-10-22. claude.com/resources/a…
• 迁移套件（Anthropic 官方）：single-agent-loop-kit，github.com/anthropics/…
• 原文配图来源：图 2（a7cb2cf08bfcef461166310c0c55f28b72c33b0d.gif）、图 3（cd4b9c4417d5ba31776e8aa79e204966c08c6a43.png）、图 4（ed6bd97496ffdab88763806d9e14f1ec61ed9255.gif）均归档自 Anthropic 原文 assets.claude.com；图 1、图 5、图 6 为本文配套中文结构图。
• 核验说明：本文直接引语均于 2026-10-27 对照原文逐字摘录；客户案例与数据为原文自述，原文未提供具名客户或可复核的原始实验，本文按“厂商实践观察”处理，不作为独立 benchmark。