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

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

一句话定位：子代理不是默认配置。先让一个循环把任务跑完，再用 Eval 证明哪里真的需要拆。

一家公司做了一款面向客户的 Agent，底下挂了十几个专家子代理，各自负责一块业务。分工图看起来很清楚。上线后却是另一回事：用户的问题一旦跨领域，答案就要在几个子代理之间转手；每个子代理只交回一段摘要；品牌语气取决于最后是哪个专家接的话；延迟也随着层数一起涨。

这是 Anthropic 应用 AI（Applied AI）团队在 2026 年 10 月 22 日一篇企业实践复盘里提到的案例。他们没有主张"子代理没用"，而是点破了一个常见误区：很多企业 Agent 的复杂度来自组织架构，任务本身并不需要这么多层。

在不少企业里，多代理一度是 Agent 的默认答案。这篇复盘值得单独拆解，原因不在新架构：它来自一个在多个企业生产环境里踩过坑的团队，并且把问题问反了------过去我们问的是"这个 Agent 该怎么拆成几个子代理"，它问的是"你凭什么拆"。

本文顺着这个问题往下拆三件事：什么时候真该保留子代理、已经拆散的子代理怎么安全收回主循环，以及收回之后多团队怎么分工。具体框架的底层实现交给文末延伸阅读。

子代理买的是隔离，付的是交接

先把概念摆正。子代理不是"更强的 Agent"，它是一个有独立上下文窗口、独立工具和独立指令的模型实例，由外面的协调器调度。它买到三样东西：

• 上下文隔离：子代理看不到主对话的历史，适合独立研究、黑盒验证。
• 并行：多个子任务可以同时跑，各自用新的上下文窗口。
• 权限边界：不同子代理可以拿不同的工具和权限。

代价也很明确：每次交接都要把结果压成一段摘要，细节在压缩中丢失；每个子代理都有自己的提示、模型调用和生命周期，层数一多，延迟跟着涨；每个团队维护自己的提示和 Eval，最后没人对端到端体验负责。

主循环是另一种形态：一个模型、一个上下文窗口，跑一个开放式的工具循环（只靠一个主循环跑完任务的架构，就是后文说的单循环）。每一轮模型发一批工具调用，Harness（模型外面的运行时）并行执行，把原始结果放回同一个窗口，模型再决定下一步：继续调工具、问用户，还是给出答案。Harness 负责设边界：轮次预算、成本预算、写入闸门。

维度	子代理	主循环（单循环）
上下文	独立窗口，适合隔离；交接有损	共享窗口，前后步骤能互相引用
并行	天然适合多任务独立窗口并行	靠单轮批量工具调用并发，共享同一窗口
延迟/成本	嵌套循环、多次交接，通常更高	单循环，通常更低
治理	每个子代理有自己的提示、owner、Eval	系统提示和端到端质量集中
主要风险	上下文丢失、子代理泛滥、语气不一致	上下文膨胀、提示和工具设计不到位

一句话：子代理是用交接损耗与调用延迟，去换上下文隔离、并行和权限边界的交易。 交易划不划算，取决于任务，不取决于架构图好不好看。

为什么 Agent 会长成组织架构图

企业级 Agent 的起点通常很朴素：想让一个 Agent 覆盖多个产品、多种能力。问题是这些能力分属不同团队。于是每个团队先做自己的 Agent，中央平台团队再加一个编排器，或者把每个 Agent 包成 MCP（Model Context Protocol）工具暴露给主 Agent。

这个做法在组织上很顺，在技术上却会带出五类问题：

1. 上下文管理：子代理之间交换什么、怎么交换，往返几次之后细节就丢了。
2. 子代理泛滥：几百个功能重叠的子代理，没有统一标准，也没有明确 owner。
3. Frankenprompt（缝合怪提示词）：每个团队都往系统提示里加一句，规则互相冲突，品牌声音不一致。
4. 局部 Eval：每个团队只优化自己的子任务，局部高分掩盖了交接处的断裂，汇总到管理层手里的指标并不能反映真实的端到端质量。
5. 延迟：多代理的嵌套循环和交接拉高了耗时。Anthropic 提到一个客户将多代理 Harness 与单循环做对比，单循环的运行时间约为前者的一半（约 2 倍提速）。

这就是康威定律（Conway's law）在 Agent 时代的翻版：Agent 架构不知不觉长成了组织架构图的副本。

康威定律原本说的是软件结构会复制组织的沟通结构。放到 Agent 上，这个现象更直观：每个团队拥有一个子代理，用户拿到的体验就继承了团队之间的缝。 比如退款专家不知道物流专家的上下文，物流专家不知道账户专家的判断，最后用户在一个请求里撞上三次交接。

这不是说团队分工错了。分工是组织效率的来源；问题在于，组织边界不该直接变成产品的运行时边界。用户不关心你的团队怎么分工，只关心一个请求有没有被完整地回答。

单循环为什么突然够用了

替代方案不复杂：一个主循环，加上两种渐进披露。

• skill 渐进披露上下文：Agent 先看到 skill 的简短描述，真正需要时才加载完整内容。
• tool search 渐进披露工具：Agent 先看到工具的名称和一句话说明，需要时才加载完整定义。

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

这背后有三个理由，一个比一个根本。

第一，共享上下文能产出更好的答案。长任务里，前面步骤的结果留在主窗口，模型后面可以回头引用、对比、修正。子代理交回来的是一段摘要，摘要里没写的东西，主循环就永远看不到了。共享上下文让模型能把信息连接起来，比子代理交回的摘要更有洞察。

第二，渐进披露解决了上下文膨胀。过去拆子代理，很大一部分理由是"东西太多，一个提示装不下"。现在可以把"装不下"拆成两层：常驻的只有短描述，完整内容按需加载。Anthropic 为更高级的模型把 Claude Code 的系统提示缩减了 80% 以上，其中就包括通过 skill 和 tool 渐进披露做出的削减。

第三，模型本身变强了。从 Opus 4.5 开始，模型能在单循环里消化的复杂度远超多数团队的预期；更晚近的模型默认自带推理过程，会在执行中主动交代进展、复核中间结果，这让一部分原本靠外部 Harness 硬编码的编排变得多余。

第三点最值得留意。它意味着：很多子代理不是为了今天的任务存在的，而是为了补昨天的模型。 模型一升级，这些补丁就可能从"必要"变成"碍事"。

但单循环不是免费的。它同样需要工程纪律：系统提示要精心管理，skill 和 tool 的描述要在正确时机触发，上下文窗口、记忆和笔记都要有意识地处理。很多外部结构其实在替模型做它已经能做的事------一个清晰的系统提示、四五个轻量工具、严格的输出护栏，通常就够了。这套配置听起来简单，落地时全是细节：它要求把提示、工具和护栏打磨到位，而不是用一层子代理把问题盖住。

什么时候还该保留子代理

前面提到子代理能买到"上下文隔离、并行、权限边界"，但权限边界完全可以下沉到工具内部（下一节详述）。因此，真正值得在运行时保留子代理的条件只有三个；一个都不满足时，就该把子代理收回主循环，也就是原文说的"折叠"（fold）：

1. 单循环因为上下文膨胀出现了可测量的性能下降。
2. 多个任务需要并行，并且可以用完即弃的新上下文窗口。
3. 单代理难以选对工具，或者系统提示里存在互相冲突的指令。

注意第一条里的"可测量"。不是"感觉上下文有点满"，而是有 Eval 数据证明折叠后质量掉了。第三条也不是"工具很多"，而是工具多到模型选不对，或者提示里的规则互相打架。

如果确实要保留子代理，建议从生成---校验（generator-verifier）、编排器---子代理（orchestrator-subagent）这类最简单的模式开始，不要一上来就画一张大图。拆分时有一个核心原则：按上下文边界拆，不要按问题类型拆。

按上下文拆，意思是每个子代理的工作尽量少依赖系统其余部分，交回来的结果尽量紧凑。适合拆的是独立研究路径、接口清晰的组件、黑盒验证。按问题类型拆（退款一个、物流一个、账户一个）看起来最符合直觉，实际上最容易出问题：每次交接都是一次"传话游戏"（telephone game），传的次数越多，保真度越低。

还有一个中间形态值得单独说：把子代理当工具调用。 主 Agent 继续和用户对话，需要某个专家时，把子代理当成一个工具来调，拿回结果后继续主循环。只有子代理必须直接和用户交谈时，才做完整交接。

这个形态的好处是迁移成本低：不用立刻重写子代理，先给它定义统一的响应 schema（除了结论，把关键依据字段一并返回），放到真实流量和 Eval 里跑通，再决定要不要彻底折进主循环。坏处是它保留了子代理的失败模式：每个专家仍然有自己的提示、上下文、owner 和 Eval；每次调用仍然交回有损摘要；每次调用仍然是一个嵌套的模型循环，延迟不会消失。

折叠的正确顺序：Eval 先行，一次一个

最实用的一部分，是这套方法没有停在"应该折叠"，而是给出了可回滚的迁移顺序。

第一步，先建 Eval。 中央团队维护一套共享的端到端 Eval；每个团队在交付 skill 时，附带一个小的专项 Eval。哪怕只有 10 个黄金样例，也足以起步。

起步时可以先用评分标准（rubric）给最终回复打分。如果还有编排器，跟踪路由准确率：有没有选对子代理。折叠之后，检查有没有加载正确的 skill、调用正确的 tool。长期看，应该转向端到端的任务完成 Eval------比较架构时，最重要的不是"路由准不准"，而是"任务有没有做完"。

第二步，从调用最频繁、和其他子代理共享上下文最多的开始合并。 优先合并那些上下游输出首尾相接、读写同一份数据、经常在同一次请求里先后出场的专家。一个很实用的信号是：如果生产流量里有很大比例是"专家 A 之后紧接着调专家 B"，这就是一对紧耦合，适合先合并成一个领域 Agent。

第三步，一次只折一个。 把子代理的提示变成 skill，把它的 API 调用变成 MCP 工具；跑折叠前后的同一套 Eval；比较的不只是总分，还要看哪些具体任务发生了"翻转"（原本通过的挂了，或原本挂了的通过了）。

原文里有一个很典型的回归案例。在一个客服 Agent 上，把一个子代理折进另一个之后，延迟下降了，但一个原本通过的流程坏了：主 Agent 手里有订单查询工具，查完订单就自己回答了用户，漏掉了原本会向物流专家确认交付日期这一步。更麻烦的是，这个失败只在两次运行中的一次出现。

这个案例说明两件事：

• 延迟下降不等于质量提升。折叠减少了交接，也可能顺手漏掉了一个隐含的检查步骤。
• 每个任务要跑不止一次。只跑一遍，很容易把一次偶然的通过当成稳定结果。

所以每次折叠前，确保 Eval 覆盖线上真实流量里经常串在一起调用的代理链路，以及 Agent 不得违反的每条红线规则；每个任务至少跑两次。

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

多团队怎么共建一个 Agent

折叠不是把权力收回中央，而是把"拥有一个 Agent"换成"拥有一种能力"。三种承载方式的边界很清楚：

能力放哪	适合什么	注意
MCP 工具	需要行动、读实时数据、返回固定形状结果	按用户意图分组，不要一个 API 一个工具；系统提示里的工具定义超过 30--50 个后，工具选择会退化
skill	团队做事的方法、步骤、规则、判断	每个团队设 DRI（直接负责人）；统一创建规范，并定期巡检上下文成本与调用频率
知识库	偶尔查阅的参考资料，如政策、指标定义、产品规格	通过搜索/查询工具按需检索，或作为 skill 的参考文件；不要在代码层预检索后硬塞进系统提示

工具那条尤其具体：一旦系统提示里的常驻工具定义超过 30--50 个，模型的工具选择准确率就会开始下降。这给了"工具太多"一个可操作的阈值------超过这个量级，就不该继续往系统提示里堆定义，而应该用 tool search 按需加载，或者把细碎的 API 按用户意图合并。

还有一个设计很值得借鉴：把硬前置条件和权限检查放进工具内部。 如果工具 Y 需要工具 X 的输出，就让 Y 自己检查，缺失时返回一段模型能读懂的下一步提示；权限也一样，每个工具自己校验调用者身份，无权限时返回清晰的拒绝原因。

比如退款工具要求必须先核验物流妥投状态，与其拆一个"退款子代理"和一个"物流子代理"互相传话，不如直接让 create_refund 工具自检并返回引导：

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

这样，一个主循环就能靠工具返回值自己补齐前置步骤，也能服务不同权限等级的用户，不需要为每种流程和权限单独造一个 Agent。

在工具链上，Anthropic 内部配套了一组辅助 skill 来加速这个循环：用 /skill-creator 和 /skill-doctor 管理 skill 的创建与调用成本，用 /claude-api build-eval 搭建首版端到端 Eval，再用 prompt-audit（清理为旧模型写的过时指令）、hillclimb（针对 Eval 迭代提分）和 cost-optimize（分析调用成本）做持续调优。

对应的组织变化是：各团队从"拥有一个子代理"变成"拥有 skill / tool / 知识库"；一个小中央团队维护主系统提示和端到端质量，审核每个新 skill、新 tool 和新 Eval。各团队仍然拥有自己的业务能力，只是不再各自维护一个直接对客说话的独立 Agent。

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

单循环的边界：哪些数字别当定律

需要说清楚：这是一篇厂商实践总结，不是独立第三方 benchmark。客户案例是匿名的；2 倍运行速度来自一个未具名客户的对比，80% 提示缩减是 Anthropic 对 Claude Code 的内部观察，30--50 个工具阈值更像经验区间，而不是定律。这些数字能说明方向，不能当成普遍规律。

单循环也有真实的代价。上下文会膨胀，长任务会顶到窗口上限；系统提示、skill 描述、工具描述都要持续维护；工具一多，选择会退化。单循环需要工程纪律，不是"写个提示词就完事"。

所以更准确的结论不是"子代理没用"，而是：不要把子代理当成默认配置。 先让一个循环跑起来；只有当它撞上可测量的墙，才拆。拆了之后，也要用 Eval 证明它值得留下。

这也解释了为什么全文反复强调 Eval。架构争论最容易变成审美争论：有人喜欢清晰的编排图，有人喜欢简洁的单循环。Eval 把争论拉回任务：同样的输入，哪个版本把任务做完的比例更高，哪个版本延迟更低，哪个版本在边界情况下更稳。

落到项目里：五步迁移与评估卡

如果把这套方法压缩成可执行的动作，就是这五步：

1. 新 Agent 默认单循环。 先写清任务完成标准，不画编排图。一个清晰的系统提示、四五个轻量工具、严格的输出护栏，通常足够起步。
2. 先建 10 条黄金任务 Eval。 覆盖真实用户会走的主路径，以及 Agent 不得违反的规则。每条至少跑两次。
3. 只有三个保留条件之一成立，才拆出子代理。 上下文膨胀导致可测量下降、需要并行且可丢弃的上下文、工具选择退化或指令冲突。三条都不满足，就先别拆。
4. 已有子代理，先当工具调用，再逐个折叠。 一次只改一个，比较任务翻转，不只看总分。
5. 模型升级后重跑 Eval。 旧规则、旧架构可能是为旧模型写的；别让它们锁住新模型的能力。

可以把这张评估卡直接复制到项目里：

# 子代理保留评估卡

- 子代理名：
- 它解决的瓶颈：上下文膨胀 / 并行 / 工具选择退化或指令冲突（三选一，写证据）
- 折叠后的候选形态：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 架构没有标准答案，但有一个可靠的顺序：先让一个循环把任务做完，再让 Eval 告诉你哪里真的不够。

子代理不是原罪，默认拆才是。组织架构图可以决定谁维护什么能力，但不该决定用户的一个请求要在几个模型之间转手。

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

"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...
• 核验说明：本文直接引语均于 2026-10-27 对照原文逐字摘录；客户案例与数据为原文自述，原文未提供具名客户或可复核的原始实验，本文按"厂商实践观察"处理，不作为独立 benchmark。