第 34 章 · 分层模型策略

Harness 锚点｜判别清单第 10 项「动态切换」——多 provider 与按任务分层选模。

一张吓人的月度账单

那个卖家上个月给运营团队上了套竞品研究 Agent，跑得挺顺。月底收到 API 账单，他愣住了：比预估贵了三倍多。

拉明细一看，问题不在那些真正难的活——写竞品分析报告、综合多份数据出结论，这些花钱他认。烧钱烧在别处：每天几千次“把这段抓来的页面正文总结成一句话”“判断这条用户消息是问价格还是问物流”——这些又简单又海量的小步骤，全用了最贵、最强的旗舰模型。就像雇了个博士去帮你数信封。

这就是 Agent 成本失控最常见的隐形大头：用最贵的模型做所有事。而破解它的办法，叫分层模型策略（Model Tiering）。

模式：按任务难度选模型

分层模型策略的核心一句话：用便宜的模型做简单的事，把贵模型省给真正难的事。

因为一个 Agent 任务里，子步骤的难度天差地别：

“把这段工具输出总结成一句话”——很简单。
“判断用户意图属于哪一类”——简单。
“综合五份研究报告写出有深度的结论”——很难。
“在复杂代码库里定位一个隐蔽的并发 bug”——非常难。

典型的分三层：

小 / 快 / 便宜模型：分类、路由、格式化、简单总结、意图识别——量大但简单。
中等模型：一般的工具调用、常规对话、中等复杂度推理。
大 / 强 / 贵模型：关键决策、复杂推理、最终综合、难题攻坚——少而重要。

关键在匹配：让每个步骤用“刚好够用”的那档模型。这往往能在几乎不损失质量的前提下把成本砍掉一大截——因为省钱恰恰省在了“占大多数的简单步骤”上。那张吓人的账单，问题不是难任务太贵，而是简单任务太多、却用了最贵的模型。

三种进阶手法：路由、升级、推理分层

匹配模型不只是“手动指定”，还有三种更聪明的做法，术语值得记牢：

路由（Routing）：先用一个便宜模型给任务“看诊”——判断它有多难、属于哪类——再据此路由到合适的模型档位。相当于门诊分诊台。
升级（Escalation）：先用便宜模型试着做，做不好、或置信度不够，再升级到贵模型重做（天然连到第 14 章反思——用反馈判断要不要升级）。相当于“先门诊，看不了再转专家”。
推理分层（reasoning tiering）：需要深度思考的步骤，用推理模型并调高推理强度（第 15 章的 Chain-of-Thought / reasoning effort）；其余步骤用普通模型，不为不需要思考的活付“思考税”。

路由是“先分诊再派”，升级是“不行再往上转”，推理分层是“该动脑的才动脑”——三者可以叠加使用。

用 pi 实现：pi-ai 的统一多 provider

这正是 pi 的 pi-ai 层（第 23 章）的用武之地。它统一了多个 provider 的接口（OpenAI、Anthropic、Google，还有 fork 里加的 Agnes provider），意味着：切换模型只是换个配置，业务代码一行不用改。

这个统一接口是分层的前提——你可以在同一个 Agent 里，为不同步骤自由指定不同档位的模型：

// 同一个 Agent，不同步骤用不同层级的模型
// 1. 路由：便宜模型做意图分类（量大、简单）
const intent = await ai.complete({
  model: "provider/small-fast",       // 小快便宜档
  messages: [{ role: "user", content: userInput }],
});

if (intent.category === "complex_research") {
  // 2. 只有难任务才动用贵模型 + 深度推理
  return ai.complete({
    model: "provider/large-strong",   // 大强贵档
    messages: session.messages,
    reasoningEffort: "high",          // 推理分层（第 15 章）
  });
}
// 其余简单类别，继续用便宜档处理，不升级

pi-ai 还带准确定价（pricing）和 service-tier 支持（第 26 章提过），这一点在分层里格外重要：它让你能真实衡量“分层到底省了多少”，而不是凭感觉。分层策略 + 预算控制（第 26 章）+ 可观测成本（第 25 章），三者合起来才是完整的成本工程——能度量，分层才有意义。

动手看看

翻 pi-ai 里定价和 provider 配置相关的代码，看它是怎么把不同 provider、不同模型的价格统一记账的。理解了这套记账，你才能回答“我这次分层到底省了多少钱”。

再做个小实验：拿你手上一个真实的 Agent 任务，统计一下里面各类步骤的调用次数——你多半会发现“简单总结/分类”这类占了绝大多数。把这些换成便宜档跑一遍，对比前后账单和输出质量，你会对“省在大多数简单步骤上”有直观的体感。

实战中的几个坑

坑一：在关键处也用弱模型，省出了差体验。

现象：为省钱把最终报告、重要决策也交给便宜模型，输出质量明显下滑。
原因：分层分过了头，没区分“用户感知得到”和“感知不到”的步骤。
对策：在用户感知不到差异的地方省，在决定质量的地方花——最终答案、关键决策不吝惜用强模型。

坑二：路由本身的成本被忽略。

现象：为了省钱给每个任务都加一次“模型判断难度”，结果路由调用的开销比直接做还贵。
原因：任务很简单时，路由这一次额外调用反而不划算。
对策：简单/高频路径可用规则或关键词先分流，把模型路由留给真正难判断的情形。

坑三：弱模型的错误往下游传导。

现象：分类步骤用弱模型分错了类，后面整条链路全跟着错，最后结果南辕北辙。
原因：把一个“决定后续走向”的分流点交给了不够可靠的模型。
对策：关键分流点要够可靠，宁可用中等模型；对分类结果做校验或加“兜底类别”。

坑四：省了钱却不知道省在哪。

现象：换了便宜模型，但说不清到底省了多少、值不值得，下次没法优化。
原因：没有准确定价和成本归因，分层全凭感觉。
对策：用 pi-ai 的准确定价 + 可观测成本（第 25 章）按步骤归因，用数据驱动分层决策。

对比：其他框架

分层模型的前提是多 provider 支持：能不能在同一套代码里自由切换模型、按任务难度选便宜或昂贵那档。各家在这点上成熟度不一。

框架	分层模型策略怎么做	特点
LangGraph	基于 LangChain 统一模型接口，可给不同节点指定不同模型，路由用条件边显式表达	路由显式，接入现成
CrewAI	给不同角色 Agent 配不同模型——“主管用强、执行者用便宜”自然落地	以角色为分层单位
PydanticAI	支持多 provider，可按调用指定模型，类型约束让换模型更稳，但不内建自动路由	换模型稳，路由自理
Agno	内置多 provider，可为 Team 里不同角色指定不同模型，升降级由应用层决定	多 provider 现成
pi	`pi-ai` 统一多 provider + 准确定价，换模型只改配置，分层省多少可衡量	定价准确是差异点

共性：几乎所有框架都支持多 provider，分层本身不难；真正的差别在能不能准确度量成本——不能度量，就无从判断分层是否值得。

小结

Agent 里简单步骤占多数，全用贵模型是隐形的成本大头——那张吓人的账单往往烧在海量简单步骤上。
分层模型策略（Model Tiering）：便宜模型做简单事、贵模型省给难题，核心是让每步用“刚好够用”的那档。
三种进阶手法：路由（Routing）先分诊、升级（Escalation）不行再转、推理分层（reasoning tiering）该动脑才动脑，可叠加。
pi 的 pi-ai 统一多 provider + 准确定价，让“换模型只改配置”“分层省了多少可衡量”——能度量，分层才有意义。
原则：用户感知不到的地方省，决定质量的地方花；别让弱模型的错误在关键分流点往下传导。

分层模型是成本工程的收尾。最后一章，我们跳出具体技术，把全书三十一章的模式合起来，看如何真正地在一个成熟宿主之上构建属于自己的 Agent——Building on the Harness。