编排成本心智：子代理(便宜) vs 对话式(贵) vs handoff(居中)

多 Agent 跑起来之后，第一张账单常常让人倒吸一口凉气——明明任务没变，token 烧得比单 Agent 多了好几倍。原因几乎都一样：编排模式选错了，把一件能一次委派搞定的事，搞成了来回几十轮的对话。 这一节我们不讲玄的，就用「调研 + 写报告」这一个具体任务，把三种主流编排模式的成本一笔一笔算给你看，让你以后选模式之前，脑子里先有一杆秤。

这篇适合谁：已经决定要拆多 Agent(没决定的先看 为什么要多 Agent),现在要选「Agent 之间怎么协作」的人。读完你会有一套成本心智：看一眼编排方案，大概就知道它贵不贵、贵在哪。

---

先认清：贵的不是 Agent,是「上下文反复进出模型」

要算成本，先记住一条铁律：你为模型付的钱，主要是每次调用塞进去的输入 token。 而 Agent 的每一步，都把之前的历史重新塞回去。所以编排成本的核心问题是：

同一段上下文，被反复塞进模型多少次?

三种编排模式的差别，本质就是这个「反复次数」差别。把这条记牢，下面的账你自己就能算。

---

三种编排模式，一个任务，分别算账

任务固定：调研三个竞品，然后写一份对比报告。 我们用「模型调用次数」和「上下文量级」两个维度，分别估三种模式。(下面的数字是量级估算，帮你建立直觉，真实数字随任务和模型浮动。)

模式一：子代理委派(subagent)——便宜

主 Agent 把「调研竞品 A」整块委派给一个子 Agent。子 Agent 在自己独立的会话里联网、读资料、汇总，干完只把一段结论交回主 Agent。三个竞品三次委派，然后主 Agent 拿着三段结论写报告。

• 调用结构：一次委派 ≈ 主 Agent 发起一次 + 子 Agent 内部跑它自己的小 loop。但关键是——子 Agent 那一大堆中间上下文(三个网页原文)从不进主 Agent 的上下文。
• 主 Agent 看到的：三段三百字的结论 + 写报告的指令。上下文始终干净。
• 量级：主 Agent 上下文几千 token 封顶;子 Agent 各自烧自己的，但互不污染。
• 一句话：一次委派，一次交付，各管各的上下文。这是最省的结构。

模式二：对话式多 Agent(conversational)——最贵

让「调研员 Agent」和「写手 Agent」像两个人一样在同一个对话里来回讨论：写手问「竞品 A 的定价是多少」，调研员答，写手又问「那它的弱项呢」，调研员再答……一来一回直到报告成型。

• 调用结构：N 个话题 × M 轮来回 = N×M 次调用，而且每一轮都把整段越来越长的对话历史重新塞进去。
• 致命点：对话历史是单调增长的。第 20 轮要带着前 19 轮的全部内容。两个 Agent 的所有发言、所有中间信息，全堆在一个共享上下文里反复进出模型。
• 量级：上下文随轮数线性膨胀，总 token 消耗约等于「平均上下文长度 × 总轮数」，轻松到子代理模式的好几倍甚至一个量级。
• 一句话：最像人协作，也最烧钱。轮数一多，成本失控。 只在「确实需要多方反复磋商」时才用。

模式三：handoff(交接)——居中

handoff 是「接力棒」式：调研员 Agent 干完自己那一棒，把任务连同必要的上下文一次性交接给写手 Agent,然后调研员退场，写手接着干。不是反复对话，而是一次性把活和料交过去。

• 调用结构：每个 Agent 跑完自己的 loop,在交接点把上下文传给下一个。比子代理多一点(交接时要带上一些上下文给下家),但远少于对话式(没有 N×M 的来回)。
• 关键差别：和子代理比，handoff 是平级接力(写手能看到调研员交过来的上下文，继续往下做);和对话式比，handoff 不来回(交接是单向的，交完就退场)。
• 量级：介于两者之间。交接时传的上下文比子代理「只回结论」多，但没有对话式的历史滚雪球。
• 一句话：接力棒，不是乒乓球。一次交接，各跑一段。

---

成本对照表

把三种模式横着摆一起，这张表是你选型时的速查卡：

模式	调用量级	上下文怎么走	适用场景	主要的坑
子代理委派	低(每块一次委派)	子 Agent 上下文不回流，主 Agent 始终干净	任务能切成独立块、某块产生大量中间料但只需交结论(调研/读长文/批量检索)	子 Agent 之间不能共享上下文，需要协作时得显式把料传过去
对话式多 Agent	高(N×M 轮)	共享历史单调增长，每轮全量重塞	确实需要多方反复磋商、来回质疑的创造性/谈判类任务	最贵;轮数失控就烧钱;历史越滚越长还会变笨
handoff 交接	中(每 Agent 一段 + 交接)	单向传递，交接时带必要上下文，交完退场	清晰的流水线、下家需要上家的产出继续做(调研→写作→排版)	交接传多少上下文要拿捏：传太多浪费，传太少下家干不了

读这张表的姿势：默认从子代理开始(最省),需要下家接着上家干就上 handoff,只有真的需要反复磋商才用对话式(并且死死盯住轮数)。

---

一段可读的子代理委派示例

落到代码上，子代理委派长什么样?下面是一段结构正确、思路可跑的骨架，用来传达「主 Agent 派活、子 Agent 独立干、只回结果」这个核心(具体 API 签名/字段名以官方文档为准——不同 SDK 写法不同，这里给的是思路而非可直接复制的真实方法名)。

# 思路示例:主 Agent 把"调研某竞品"委派给一个专门的子 Agent
# 关键:子 Agent 在独立会话里干活,只把"结论"回传,中间上下文不污染主 Agent

# 1) 定义一个专门的"调研子 Agent"——它有自己的指令和工具集
#    (在 Claude Agent SDK 里,这通常是先建一个 agent,再把它列进
#     主 coordinator 的 multiagent 角色清单;真实字段名以官方文档为准)
research_subagent = create_agent(
    name="研究员",
    system="你只做调研:联网搜索、读资料、提炼要点。只回三百字以内的结论,不要贴原文。",
    tools=["web_search"],           # 子 Agent 只给它该用的工具(隔离)
)

# 2) 主 Agent(协调者)知道自己手下有这个子 Agent 可以委派
coordinator = create_agent(
    name="主控",
    system="你负责调研+写报告。把每个竞品的调研委派给'研究员',拿到结论后自己汇总成报告。",
    subagents=[research_subagent],  # 声明可委派的子 Agent;字段名以官方为准
)

# 3) 跑起来:主 Agent 会自己决定"派研究员去查 A/B/C",
#    每次委派 = 一次独立子会话,子 Agent 干完只回结论
result = coordinator.run("调研竞品 A、B、C,写一份对比报告")

# 你应该看到的:
# - 主 Agent 发起 3 次委派(查 A、查 B、查 C)
# - 每个子 Agent 在自己会话里烧掉一堆 token 读网页,但这些原文不进主 Agent
# - 主 Agent 最终上下文里只有 3 段结论 + 报告指令 → 干净、便宜

注意这段代码的精神而非字面：子 Agent 有自己的指令、自己的工具、自己的会话;它只回结论;主 Agent 的上下文因此不被中间料撑爆。这就是子代理模式省钱的全部秘密。(在 Claude Agent SDK 的托管 Agent 里，多 Agent 是通过给协调者配置 multiagent 角色实现的，每个子 Agent 跑在自己的 thread 里、上下文隔离;subagents= 这种参数名是示意，真实接口以官方文档为准。)

---

决策树：按成本选编排模式

把上面的判断浓缩成一棵树，选型时照着走：

你的多 Agent 任务,各块之间需要怎么协作?
│
├─ 某块产生大量中间料,但下游只需要它的"结论"?
│   (调研、读长文档、批量检索)
│   └─→ ✅ 子代理委派(最省,上下文隔离)
│
├─ 是一条流水线,下家需要上家的"产出"继续做?
│   (调研→写作→排版,前一棒交给后一棒)
│   └─→ ✅ handoff 交接(居中,一次性传上下文)
│
└─ 真的需要多方"反复磋商、来回质疑"才能出结果?
    (创意脑暴、方案辩论、谈判类)
    └─→ ⚠️ 对话式多 Agent(最贵)
        └─ 上之前先问自己:轮数能不能封顶?
           能 → 用,但设硬上限
           不能 → 退回 handoff 或子代理,把"磋商"改成"一次交接"

默认路径永远是从最省的往上爬：先看能不能子代理，不行再 handoff,实在不行才对话式。别从对话式开始——那是成本最高的起点，而大多数任务根本用不到那么重。

---

故障 / 避坑表

现象	原因	怎么破
token 账单暴涨，任务却没变复杂	用了对话式，轮数失控，历史滚雪球	改成 handoff 或子代理;非用对话式不可就给轮数设硬上限
子 Agent 干完了，主 Agent 却说"信息不够"	子 Agent 只回了结论，但下游其实需要中间料	这种场景该用 handoff(传上下文),不是子代理(只回结论)
handoff 后下家"接不住活"	交接时传的上下文太少	在交接点显式带上下家干活必需的关键信息，别指望它自己猜
多 Agent 比单 Agent 还慢还贵	拆得过头，或选了对话式做本该一次委派的事	回到 该不该拆的判断清单,先确认拆得对
重复委派同一块，缓存没生效	每次委派的 prefix 有变动(时间戳/随机 ID 混进了系统提示词)	保持可委派 Agent 的系统提示词/工具集稳定，把易变内容放后面，利用 prompt 缓存省钱

---

动手挑战

1. 拿你手上一个真实的多 Agent 任务，用本文的方法手动估一遍三种模式的调用量级：子代理几次委派?对话式大概几轮?handoff 几段?哪种最省。
2. 如果你现在用的是对话式，试着改成 handoff：把「反复问答」重构成「一次性把料交给下家」，对比改造前后的 token 消耗。
3. 进阶：给你的子代理委派加上 prompt 缓存(保持子 Agent 系统提示词稳定),看缓存命中后成本又降了多少。

---

小结 · 你现在掌握了什么

• 你抓住了编排成本的核心：贵的是同一段上下文反复进出模型的次数。
• 你能用「调用量级 + 上下文怎么走」估算三种模式：子代理便宜(一次委派、上下文隔离)、对话式最贵(N×M 轮、历史滚雪球)、handoff 居中(单向接力)。
• 你拿到了一张成本对照表和一棵决策树，默认从最省的子代理往上爬，别从对话式起步。
• 你知道了几个高频坑：对话式轮数失控、子代理该传料没传、handoff 传太少。

下一节我们把最省的那条路落到实处：裸 SDK 手搓子代理编排,用 Claude Agent SDK 的子代理原语拆活、并行、隔离上下文，给你一段能照着搭的代码骨架。

下一步：算清了成本，接着学怎么把最省的模式手搓出来。看 AI Agent 智能体阶梯 的 L5 后续;想看全貌就对照三支柱路线图。

👉 看看 AI 数字员工落地指南,或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。