用 Claude Haiku 5.5 做子智能体路由，把 Agent 成本砍掉六成
做 Agent 系统最容易被账单教做人。我带过一个内部客服 agent，一开始所有请求都丢给旗舰模型，月底一看费用，老板脸都绿了。后来我们做了一层「路由」：轻活给小模型，重活给大模型，整体开销直接腰斩。但腰斩不是白来的。路由写错了比不路由还惨------把本该重推理的请求误判成轻活丢给小模型，用户那边直接看到胡说八道，投诉比省钱更贵。所以路由的核心不是「省」，是「分得对」。我们当时是先离线跑了一周流量做意图标注，确认分布后才上路由，不是拍脑袋切，这一步省不得。
先说清楚成本长什么样。一次 agent 调用，费用 = 输入 token × 输入单价 + 输出 token × 输出单价。输入是系统提示加历史加用户问题，输出是模型真吐出来的字。很多人只盯输出单价，忽略长上下文下输入 token 才是大头------一个带几十轮对话历史的客服 agent，每次调用输入可能几万 token。所以选模型时，输入单价和输出单价得一起看，不能拆开算。我们线上曾有个反例：把一个长文档问答从 Opus 换成 Sonnet，输出单价降了，结果因为 Sonnet 上下文短、得多次回传历史，输入 token 翻了倍，总费用反而涨。所以「换小模型省钱」不是自动成立的，得把输入输出一起建模。token 单价看着小，乘上调用量就是大钱，这点别轻视，很多团队就是在这儿算漏了。
10 月 8 日 Anthropic 发了 Claude Haiku 5.5，官方说平均成本比 Haiku 4.5 低约 75%，还第一次给了可调 effort。对做成本工程的人来说，这玩意儿就是天然的子智能体首选。下面用一个零依赖的 Python 脚本，把「分层路由省多少钱」算清楚。
路由逻辑本身可以很朴素：用关键词或一个小分类器判断意图，轻活进 Haiku、重活进 Sonnet、极少数兜底进 Opus。关键不是路由多聪明，是「别让旗舰干它不配干的活」。很多团队一上来就把所有请求丢旗舰，不是因为重，是因为没统计过意图分布，不知道其实九成都是轻活。下面这段代码就是把这套思路落成可跑的测算，把每种意图跑一万次，算总账。
先放费率表。数字来自 Anthropic 官方 10/8 公告与 Simon Willison 的实测口径（华尔街见闻 10/8 转述）：Haiku 5.5 在 10 万 token 内是 0.10 / 0.50 美元每百万 token；Sonnet 5.5 是 2 / 10；Opus 5.5 是 4 / 20。
python
import sys
# 简化费率表（美元 / 百万 token）。来源：Anthropic 官方 10/8 公告、Simon Willison 实测口径（华尔街见闻 10/8 转述）
RATES = {
"haiku_5_5": {"in": 0.10, "out": 0.50, "note": "10万token内；新分词器隐性多耗token"},
"sonnet_5_5": {"in": 2.00, "out": 10.00},
"opus_5_5": {"in": 4.00, "out": 20.00},
"gpt6_luna": {"in": 0.10, "out": 0.50},
"gpt6_sol": {"in": 2.00, "out": 10.00},
}
def cost(model, in_tok, out_tok):
r = RATES[model]
return (in_tok / 1_000_000) * r["in"] + (out_tok / 1_000_000) * r["out"]
# 子 agent 路由：把轻量意图丢给最便宜能胜任的小模型
def route(intent):
if intent in ("greet", "classify", "summarize"):
return "haiku_5_5"
if intent in ("code", "reason"):
return "sonnet_5_5"
return "opus_5_5"
workload = [("greet", 800, 200), ("classify", 1200, 150),
("summarize", 2000, 400), ("code", 3000, 1200),
("reason", 5000, 2500)]
lines = []
lines.append("模型路由 + 单日成本测算（每种意图 1 万次调用）")
per = {k: 0.0 for k in RATES}
for intent, it, ot in workload:
m = route(intent)
c = cost(m, it * 10_000, ot * 10_000)
per[m] += c
lines.append(f" {intent:9s} -> {m:12s} ${c:,.2f}")
naive = cost("opus_5_5", sum(i for _, i, _ in workload) * 10_000,
sum(o for _, _, o in workload) * 10_000)
routed = sum(per.values())
lines.append("")
lines.append(f"全量 Opus 5.5: ${naive:,.2f}")
lines.append(f"分层路由后: ${routed:,.2f}")
lines.append(f"节省: {(1 - routed / naive) * 100:.1f}%")
out = "\n".join(lines)
with open("_juejin1_out.txt", "w", encoding="utf-8") as f:
f.write(out)
print(out)实跑结果（就是上面那段，我已用 Python 3.13 跑过，rc=0）：
bash
模型路由 + 单日成本测算（每种意图 1 万次调用）
greet -> haiku_5_5 $1.80
classify -> haiku_5_5 $1.95
summarize -> haiku_5_5 $4.00
code -> sonnet_5_5 $180.00
reason -> sonnet_5_5 $350.00
全量 Opus 5.5: $1,370.00
分层路由后: $537.75
节省: 60.7%看到没？同样的工作量，全扔 Opus 是 1370 刀，分层路由后 537.75 刀，省了 60.7%。
这个结果挺说明问题：省钱的关键不在「用不用小模型」，在「对的活分给对的模型」。greet/classify/summarize 这种一眼轻的，Haiku 完全够；code/reason 才值得上 Sonnet。Opus 在我这套路由里基本只兜底极少数的硬骨头。真正难的不是写路由，是把意图分布摸准------摸不准，路由就分错，省下的钱不够赔质量，那才是真坑。我们实测下来，路由稳定后投诉率没涨、账单降了六成，这才是健康状态------省了钱还没伤体验。
踩坑提示，五条都是我真实踩过的：
第一，路由别用大模型自己判断。你为了省钱加个分类器，结果分类器本身调旗舰，那省个寂寞。路由层用规则或最小的模型即可，意图识别这点活 Haiku 完全够。
第二，新分词器的隐性成本。Simon Willison 实测 Haiku 5.5 换分词器后，同样文本 token 数变多。脚本里费率按官方单价，真实账单记得乘上 token 增量。别只盯着 0.10 / 0.50 这两个数。
第三，effort 档位会反向超支。Sonnet 5.5 开 max effort 时单任务可能比 Opus 还贵（这点 AIToolsRecap 的实测里提过）。路由到 Sonnet 干重活时，默认 effort 别拉满，先 low 跑通再说。
第四，监控要分层。别只盯月账单，按意图维度拆日成本。我们曾发现某天 reason 类请求暴涨，是上游一个 bug 在死循环追问模型。没有按意图拆的监控，这种异常要月底才看得见。
第五，路由本身也要评测。路由分错了（把 reason 判成 greet 丢给 Haiku），质量崩了用户骂街，省下的钱不够赔。所以路由层要留一小部分流量做金标准对比，定期看分层决策对不对。
总结一句：Agent 成本不是「选哪个模型」决定的，是「怎么分流」决定的。Haiku 5.5 这种便宜小模型，价值不在它多强，在于它让「90% 的轻活走便宜通道」变得划算。先把意图分布统计出来，再决定分层策略，比盲目换模型有用得多。我们落地后月账单降了差不多六成，但前提是先花两周把意图打标、把路由评测跑通。没这步，直接换模型多半是白忙。另外建议路由先当影子模式跑：真实流量仍走原模型，路由只做决策并记录，对比金标准确认稳了再切真流量，这样就算路由翻车，也只影响离线分析，不伤线上用户。