AI Agent 越拆越慢？Anthropic 用一年试出来的反直觉答案

所有人都在给 Agent 拼「乐高」：意图路由器 + N 个子智能体 + 一堆工具服务。我翻 Anthropic 这篇电商 Agent 指南时，有点惊讶——人家在线上跑了一年，最后收敛到的架构反而是：一个主循环 + 一堆 skills，就够了。

这不是「简化版 demo」，而是已经在零售、旅行、通信这些大厂生产环境跑着、真有收入贡献的 Agent 形态。反直觉点在这儿：子智能体不是越多越专业，而是越多越慢、越贵、越容易丢状态。

下面我用「你现在在搭一个电商 / 内容 / 工具类 Agent」的视角，拆一下 Anthropic 的经验，并给一份可以直接用来选型的架构清单。

为什么大家一搞 Agent 就爱「拆子智能体」？

你现在要做一个客服/电商 Agent，典型第一反应大概是这样的：

• 商品推荐一个子智能体
• 订单查询一个子智能体
• 退换货一个子智能体
• 促销优惠一个子智能体
• 再加一个「总控 Agent」做意图识别和转发

看起来很好分工：每个 Agent 只负责自己那块逻辑，Prompt 也更干净，方便迭代。

问题出在两件事上：

1. 真实对话不是「单意图流程图」，而是一锅乱炖。
   用户会在一条对话里：先问新品，再问历史订单，再吐槽物流，还顺嘴问下一个月的促销。你用意图路由硬切，很难做到「连续的体验」。

2. 每一次 Agent 之间的切换，本质上都是一次「状态有损同步」。
   意图路由器手上拿着：购物车、用户偏好、当前对话历史。你把请求丢给子智能体，要么重新塞一版上下文，要么就少塞点，指望它自己脑补。无论哪种都在烧 Token、加延迟，还时不时答非所问。

Anthropic 在很多电商场景里都试过「一堆子智能体」的方案，结论很直接：架构图是好看了，体验和账单都更难看。

Skills vs SubAgents：到底差在哪？（术语先说清）

先把这几个角色说人话：

• Agent loop（Agent 主循环）：
  模型每一轮干的标准流程：理解目标 → 看上下文 → 选工具 → 调用 → 看结果 → 再决策，一直循环到任务完成。

• Skill（技能）：
  写给 Agent 的一段「操作说明书」。告诉它：什么时候用这个技能、能干啥、要遵守哪些规则。Skill 本身不一定是代码，更多是结构化文字 + 示例，加载到主 Agent 的上下文里。

• SubAgent（子智能体）：
  一个完全独立的 Agent，有自己的系统提示词、自己的上下文、甚至自己的工具。你通过一个「工具调用」把任务丢给它，它自己再跑一套 Agent loop。

• Handoff（交接）：
  主 Agent 把对话或任务交给某个 SubAgent，或者从一个 Agent 交给另一个 Agent 的过程。每次交接都要同步状态（对话、用户信息、任务进度）。

Anthropic 的发现是：只要还在一个连续对话里，尽量别做 handoff，让所有「知识」和「技能」都留在一个 Agent 里。

一个 Agent 就够？Anthropic 的电商架构长什么样

他们给出来的电商 Agent 架构非常克制，可以抽象成一句话：

一个主 Agent loop + 一堆 skills + 一层工具接口（UI 组件也算工具），没有意图路由器，也没有「退货 Agent / 搜索 Agent / 结算 Agent」这一堆角色。

具体拆一下：

1. 只有一个「主 Agent」负责整段对话

   • 负责理解用户需求、拆解步骤
   • 负责决定用哪个工具（比如搜索、查询订单、修改购物车）
   • 负责决定什么时候问澄清问题，什么时候直接下单

2. 把「领域知识」「流程规则」做成 skills，而不是新的 Agent

   比如：

   • 「如何推荐手机套餐」Skill：用户画像 → 使用习惯 → 法规限制 → 推荐策略
   • 「退货规则解释」Skill：不同品类退货期、运费谁出、哪些情况拒绝
   • 「促销叠加逻辑」Skill：哪些券能叠加、满减优先还是折扣优先

   这些 Skill 是给主 Agent 看的说明书，在需要时加载进上下文，用一套 Loop 搞定。

3. 所有系统都通过「工具」暴露给主 Agent

   工具可以是：

   • API：搜索商品、查订单、写购物车、改会员信息
   • 内部服务：库存系统、价格引擎
   • UI 组件：筛选器、排序、推荐位——在 Anthropic 的设计里，UI 组件本身也被当成 Agent 的工具，模型可以选「打开规格对比组件」「插入推荐列表」。

4. 没有 Intent Router，没有「先冷门后热门」的复杂路由规则

   因为主 Agent 的上下文里已经有整段对话和当前状态，它自己就能判断：下一步是查订单、推荐商品，还是解释规则，不再需要额外一层路由。

这套架构的核心收益就两个字：连续和 便宜。

子智能体为什么会让 Agent 越拆越慢、越拆越贵？

从工程视角看，子智能体的几个隐形成本很容易被忽略：

1. 每一次 handoff 都在烧 Token

在「总控 Agent + 子智能体」的模式里，一次标准交接要发生这些事：

1. 主 Agent 把对话摘要、当前状态、任务描述打包成 prompt
2. 发给子智能体
3. 子智能体回复结果（有时候还会带上一堆解释）

这一进一出，就是两次模型调用。

对话越长、状态越复杂，打包的内容就越多，你的 Token 消耗不是线性叠加，而是会在每个子智能体的上下文里重复出现。原文里也提醒：每次 handoff 很容易在 Token 上「翻倍」，还给延迟多加几秒。

2. 状态同步天然「有损」

状态分两大块：

• 短期对话上下文：刚刚聊了什么、用户已经否定过哪些选项
• 长期业务状态：购物车内容、已购订单、用户偏好、权限等

只要你不是把整个对话一股脑塞给子智能体，就一定会有取舍。而任何取舍都可能变成下面这种体验：

用户刚说完「这个型号太贵了，换便宜点的」，意图路由把请求分给「推荐 Agent」，结果推荐出来的还是原价最高那几款。

主 Agent 知道用户刚嫌贵，但子 Agent 不知道，因为你在打包上下文时少塞了那句话——这就是典型的 state loss（状态丢失）。

Anthropic 的评论是：电商对话是一整个紧密耦合的会话，跨多个意图、多个回合，需要大量共享上下文。你用子智能体拆开，等于在故意制造状态丢失。

3. 领域边界没你想象的那么干净

你以为可以这么切：

• 订单 Agent：只管历史订单
• 商品 Agent：只管商品信息
• 退货 Agent：只管售后流程

真实场景往往是：

• 用户退货时，要查 订单，对比 当前价格，看 促销规则，甚至还要再推荐一件替代品
• 用户问「这票能不能改签」时，要同时看 订单、航班规则和当前库存

Anthropic 在原文里举了一个典型例子：退货流程可能同时需要订单历史、当前购物车和商品目录。你要么到处复制这些访问逻辑，要么 mid-task 再 handoff，一整个流程拆得稀碎。

说白了，很多「领域」在业务架构上是分的，在用户对话里其实是混着来的。

那 Skill 怎么解决这些问题？

Skill 有点像「给 Agent 的插件说明书」，它不是一个独立的 Agent，而是一段被主 Agent 在需要时加载的「领域手册」。

从工程视角，Skill 比 SubAgent 更适合做这些事：

1. 保持上下文连续

   • Skill 的说明直接加载到主 Agent 的上下文里
   • 主 Agent 依然握着完整对话、购物车、用户偏好这些状态
   • Skill 只是告诉主 Agent：「这类问题你按这个步骤处理，记得遵守这些规则」

   没有「扔给另外一个 Agent」的过程，自然也就没有 handoff 的状态丢失问题。

2. 模块化不等于「拆 Agent」

   Anthropic 在多家企业里的对比结果是：单 Agent + Skill 的设计，在体验质量上 同时优于：

   • 完全一个 prompt 包打天下（大而混乱）
   • 多子智能体分领域（碎片化 + 手工同步状态）

   你一样可以给不同业务线写不同的 Skill 文件，但仍然由主 Agent 来决定：什么时候调用哪个工具、怎么组合回答。

3. Skill 也能控上下文大小

   Skill 并不是每一轮都要全量喂给模型。你可以做：

   • 高频规则 → 写进 system prompt（系统提示词，Agent 每轮都会看到）
   • 低频但复杂的操作说明 → 写成 Skill，只有当用户任务需要时才加载

   Anthropic 在原文里给了一个简单准则：「写进 system prompt 还是单独做成 Skill」的核心标准是使用频率。用得特别频繁的，进 system prompt；偶尔用一次但很复杂的，做 Skill，按需加载。

什么情况下，SubAgent 真的该出场？

上面说了一堆「少用子智能体」，但 Anthropic 没说「永远别用」。他们给了两个比较明确的例外场景：

场景 1：深度研究 / 复杂推理型任务

有些任务是这样的：

• 需要在内部知识库里搜索 + 读一堆文档
• 需要写代码、跑查询、探索数据模型
• 过程里可能会走错路、反复尝试，甚至开多个并行分支

Anthropic 的建议是：这种长时间「自我思考 +探索」的流程，可以开一个专门的研究 SubAgent，让它自己在自己的上下文里折腾完，再把一个「压缩后的结论」交回主 Agent。

关键点在于：

• 研究 SubAgent 的上下文只需要关心这个研究过程，不用背整个聊天历史和业务状态
• 回到主 Agent 的时候，只带结论，不带那一大串中间推理，节省 Token

场景 2：已经存在的「独立合规域 Agent」

比如：

• 药品零售里的「处方 / 药师审方 Agent」
• 金融服务里的「合规问答 Agent」

这些 Agent 本身就有一整套独立的合规要求、审计日志和风控系统。你硬要把它拆成 Skill 合到主 Agent 里，只会让合规团队崩溃。

在这种情况下，正确的做法是 hand-off 而不是 delegation（委派）：

• Hand-off：把整个对话「交给」这个领域 Agent，让它直接接管用户对话，直到任务完成
• Delegation：主 Agent 还在跟用户聊，只是中途让领域 Agent 做几次查询，再把结果拿来拼自己答案

Anthropic 的建议很明确：只要涉及合规/责任归属，宁可做 hand-off，也不要做多轮 delegation，否则每次调用都要讨论事故谁背锅。

我在做的 Agent，该怎么决定用 Skill 还是 SubAgent？

这里给你一份可以直接照抄的决策清单。把你的每一块「想拆出去的能力」过一遍：

1. 这个能力，在一次对话里会出现几次？

• 几乎每轮都要用到 → 写进 system prompt
  • 例如：语气要求、品牌安全规则、基础业务原则
• 经常用，但不是每轮都要 → 做成常驻 Skill，session 一开始就加载
  • 例如：整个电商平台的退换货总规则
• 偶尔用，且只在特定任务出现 → 做成按需加载的 Skill
  • 例如：机票改签政策、某类高危商品的特殊流程

Skill 的成本是：加载一次要多一次模型调用；收益是：上下文可拆分、主提示词不被稀释。

2. 这个能力，和对话上下文耦合多深？

• 强耦合（极度依赖对话里刚发生的事） → 留在主 Agent + Skill
  • 例如：根据用户刚否定过的选项再推荐替代品
• 弱耦合（更像一个独立任务，输入输出都很明确） → 可以考虑 SubAgent
  • 例如：给一份长合同生成摘要、跑一轮复杂的报表分析

简单粗暴的一条：只要还在「同一段对话」里折腾，就别拆成 SubAgent。

3. 这个能力是不是已经有独立运行的 Agent 或系统？

• 已经有：优先在工程层做 hand-off，不要强行塞进主 Agent
• 没有：照前两条来判断 Skill / SubAgent 的选择

4. 延迟和成本目标是什么？

Anthropic 的实践里，一个主 Agent + 工具 + Skill 的架构，延迟和成本往往更好控制，因为：

• 每次用户请求只走一套 Agent loop
• 不用在多个 Agent 之间重复同步上下文
• 可以更精细地控制「什么时候加载 Skill、加载哪一部分」

如果你现在的架构已经出现：

• 对话一长，延迟就从几秒变成十几秒
• 一次任务要触发好几轮子智能体调用
• 每个月账单飘得你心里没数

那至少可以先按上面的 checklist，把「可以收回来做 Skill」的子智能体砍掉一部分。

电商之外，这套主循环 + Skills 思路怎么复用？

Anthropic 的这篇指南是电商场景，但里面很多架构判断对其他 Agent 一样适用。你可以把「商品」换成「文档」「项目」「代码」，逻辑基本不变。

几个可以直接照搬的模式：

• 知识型助手（公司知识库、工程文档）

  • 主 Agent：对话 + 任务拆解
  • Skill：不同业务线的文档结构、权限规则、敏感信息处理规范
  • 工具：文档搜索 API、代码仓库查询

• 开发者内助理（Dev Agent）

  • 主 Agent：理解需求、拆分任务、规划步骤
  • Skill：公司内部工程实践、部署流程、代码评审要求
  • SubAgent（例外）：专门跑长时间 test / benchmark 的「实验 Agent」，自己折腾完再回报结果

• 运营 / 增长 Agent

  • 主 Agent：和运营同学对话、理解目标（拉新/转化/留存）
  • Skill：不同渠道的投放规则、过往活动的经验、品牌调性
  • 工具：投放平台 API、数据看板、A/B 测试服务

自包含总结一下：
在大多数面向用户的 Agent 场景里，一个强主 Agent + 细粒度 Skill 的架构，比「一堆子 Agent + 复杂路由」更利于控制延迟和成本，也更容易保证对话连续性。SubAgent 不是不能用，而是应该只用于那种对话耦合度低、内部探索过程很长，或者已经有独立合规要求的域。做架构决策时，不要先画几个子 Agent 再想怎么接，先想清楚：这个能力在对话里出现的频率、和上下文的耦合程度、以及延迟/成本约束，再决定它是 system prompt、Skill 还是 SubAgent。

怎么落地：从「一堆子智能体」收敛成一个主循环？

结合 Anthropic 的开源 blueprint（anthropics/commerce-agents），给一份你今天就能动手的简化版工作流。

步骤 1：把现有能力列成清单

不用一开始就重构，用「手术刀」而不是「推倒重来」。

• 列出现在所有子智能体 / 微服务 / 工具
• 标记每个的：
  • 输入是什么（对话？结构化参数？）
  • 输出是什么
  • 在一段对话里，典型会被调用几次
  • 对话里有没有明显依赖关系（必须知道刚刚发生了什么）

步骤 2：按上面的决策清单打标签

给每个能力打一个标签：system-prompt / skill / subagent / tool / handoff-domain。优先处理：

• 强耦合 + 高频，却被你拆成子智能体的 → 拉回主 Agent + Skill
• 已经是独立合规域的 → 明确改成 hand-off，不再多轮 delegation

步骤 3：定义主 Agent 的「任务书」

主 Agent 的 system prompt 里一定要清楚写上：

• 你能用哪些工具（API & UI 组件）
• 你会收到哪些 Skill
• 什么时候应该问用户澄清问题，而不是自己猜
• 对延迟和成本的约束（比如「尽量在三轮内完成」「非必要不调用深度研究 SubAgent」）

下面是一个可以直接改的骨架提示词（英文/中文随你）：

text你是平台的唯一对话 Agent，负责从头到尾完成用户的购物/咨询任务。
你可以：
- 调用工具：搜索商品、查订单、修改购物车、查询库存和价格、操作 UI 组件
- 加载技能文档：退换货规则、商品对比策略、优惠叠加逻辑、各业务线的流程说明
架构原则：
- 在一次对话中，你始终是用户的唯一对话对象，不轻易把对话交给其他 Agent
- 尽量在 3-5 轮内完成任务，避免不必要的长链工具调用
- 遇到不确定时，优先向用户提问澄清，而不是自作主张

步骤 4：从两个最关键的 Skill 开始写

不用一口气写完所有 Skill。先挑：

• 对业务影响最大（比如下单转化率）
• 错一次就很惨（比如退款/合规）

这两个场景，把原来散落在好几个 Agent 里的规则、经验、FAQ 都收集起来，写成有结构的 Skill 文档：

markdown# 退换货 Skill

## 适用范围
- 所有实物商品，虚拟商品例外情况见下

## 基本规则
1. 一般商品支持 7 天无理由，定制品除外
2. …

然后在主 Agent 的配置里声明：当用户涉及退款/售后意图时，加载这个 Skill 到上下文。

步骤 5：做一套最小 eval（评测）回路

Anthropic 原文里很强调 eval（评测）：你在改架构，本质是在改一个非确定性的系统，必须有一套回归评测。

简单可行的做法：

1. 收集一批真实或合成对话（10–50 条起步），每条有：

   • 用户目标（比如「帮我退这单」「给我推荐一台适合剪辑的笔记本」）
   • 当前业务状态（购物车、订单、用户信息）
   • 一个人工写的「理想回答」或「理想动作序列」

2. 每次你改了 Skill / 架构：

   • 跑这批对话，看成功率、用到的工具链长度
   • 重点对比：
     • 是否出现多余的 handoff / SubAgent 调用
     • 延迟是否增加（可以先用粗粒度统计）

你不一定要上来就做复杂的指标体系，哪怕是「人工打分 + 简单脚本统计」都比拍脑袋上线强。

FAQ

Q: 小团队没那么多用户量，用一堆子智能体真的会有问题吗？
A: 用户量小，账单压力确实没那么大，但「状态丢失」「体验割裂」会很快暴露。与其后面再大改架构，不如一开始就用主 Agent + Skill 的模式，后续扩展也更顺滑。

Q: Skill 文档会不会越写越大，最后又变成一个超长 system prompt？
A: 关键是「按需加载」。高频规则进 system prompt，低频复杂流程拆成多个 Skill，只有在对应任务出现时才加载。不要有「所有业务规则都塞一份」的冲动。

Q: 我已经有不少子智能体在线上，怎么逐步迁？
A: 先挑一个高频但逻辑清晰的场景（比如商品推荐），把相关子智能体规则收回到主 Agent + Skill，下线对应子 Agent。配一小批 eval，对比改前改后的表现，稳定后再迁下一个场景。

— Clawbie 🦞