Agent 每一步都用旗舰模型？先搞清哪一步的钱不能省

2026-07-29

数据截至 2026-07，各产品的额度与报错口径以官方最新说明为准。

多数人把 Agent 成本高归因于「模型太贵」或「跑得太多」，于是全局降档、全局砍上下文，结果是账单降了一点、返工翻了一倍。真正的问题通常在分配上：钱花在了错了也无所谓的步骤上，却在错一次就要全链重跑的步骤上省。这是一个可以被验证的判断——只要你能把花费按步骤拆开看，答案往往一眼可见。

先说清这篇和站内两篇相邻文章的分工，免得你重复读：Agent 跑着跑着账单失控：几个常见原因解决的是「钱从哪个口子漏出去」，处理循环不收敛、上下文滚雪球这类漏洞；Token 成本优化：比换便宜模型更有效的几招解决的是「同一件事怎么用更少的 token 做完」，是单位成本的压缩。本篇假设你那两件事都做过了、总量已经不再离谱，要回答的是剩下那笔预算怎么在步骤之间摆——同样的总花费，摆法不同，产出质量差得很远。

一、先判断：你面对的是总量问题还是分配问题

这两类问题的动作完全相反，判错了会越修越糟。

总量问题的典型特征是：单次任务的花费随任务规模线性甚至超线性增长，而且失败重跑不多。你看日志会发现每一步的输入都很长，同一段内容反复出现。这类问题不该看分配，该回去做上下文瘦身和缓存。

分配问题的典型特征是：总花费不算离谱，但任务成功率不稳定，同一类任务有时一遍过、有时来回三四轮。你把这几轮的花费加起来，会发现绝大部分钱花在了「重做」上，而不是「第一次做对」上。这时候再全局降档，只会让重做的轮数更多。

最快的判别方法是给每一步打点。不需要什么复杂设施，Agent 每次调用模型时往一个 jsonl 里追加一行就够：步骤名、模型标识、输入 token、输出 token、这一步是否触发了下游返工。然后聚合：

import json, collections

agg = collections.defaultdict(lambda: {"calls": 0, "in": 0, "out": 0, "redo": 0})
with open("agent_steps.jsonl", encoding="utf-8") as f:
    for line in f:
        r = json.loads(line)
        a = agg[r["step"]]
        a["calls"] += 1
        a["in"] += r.get("input_tokens", 0)
        a["out"] += r.get("output_tokens", 0)
        a["redo"] += 1 if r.get("caused_redo") else 0

# OUT_RATIO：输出 token 单价 ÷ 输入 token 单价，填你实际用的那家的公开价目
OUT_RATIO = 1.0

def weight(a):
    return a["in"] + a["out"] * OUT_RATIO

for step, a in sorted(agg.items(), key=lambda kv: -weight(kv[1])):
    print(f'{step:<24} calls={a["calls"]:<5} in={a["in"]:<9} out={a["out"]:<7} '
          f'w={weight(a):<10.0f} redo={a["redo"]}')

这里有个容易踩的细节：别直接拿输入 token 数排名当成本排名。绝大多数服务商对输出 token 的计价高于输入 token，倍数各家不同、也会调整，以官方价目页为准。所以上面留了 OUT_RATIO，把它填成你那家的输入输出单价比之后再排序，一个「输入不长但输出很长」的生成步才不会被漏掉。缓存命中的输入通常还另有折价，如果你开了提示缓存，最好在打点时把命中与未命中的输入分成两个字段记。

看两列就够：w 最大的步骤是你的成本重心，redo 最大的步骤是你的风险重心。这两个重心不重合，就是分配失衡的直接证据。打点这件事越早做越好，等到账单出问题再补，你连对比基线都没有。

二、判别表：现象对应哪种分配病

打完点，对照下表定位。

现象	大概率成因	怎么验证	处置动作
总花费不高但任务经常返工重来	前置的意图澄清和任务拆解用了低档模型或直接跳过	看 redo 列，返工是否集中在某一步之后；抽查三条失败链，看第一次跑偏发生在哪一步	把拆解步单独提出来，用高档模型 + 结构化输出，产物先落盘再往下走
花费的大头在「读文件/检索/汇总」这类步骤	工具返回体原样喂给了高档模型	打点日志里比较该步骤的 input 与其它步骤的量级差	返回体先用规则截取或小模型压缩成结构化摘要，再进主链
每一步都不贵，但步数很多且大部分是格式转换	该用代码做的事交给了模型	逐步骤问一句：这一步的输出是否可以由确定性程序算出	能写成脚本的一律写成脚本，模型只做判断不做搬运
改动做完了才发现方向错，代价极大	决策点（改动范围、是否落盘、是否执行破坏性命令）没有单独设步	看回滚记录：一次回滚平均丢掉几步的产出	决策点独立成步，用高档模型 + 人工确认，这一步的钱最值
同一任务两次跑的花费差好几倍	上下文按会话累积，没有按步骤重建	对比两次跑的 input 曲线，看是否单调上升	每步只带该步需要的上下文，见下文第四节
成本正常但结果质量忽高忽低	路由规则按会话固定，没按步骤类型分	打点日志里按会话分组，看每条会话的成功/失败与该会话选中的模型标识是否相关；相关就说明质量是被「这次抽到哪个模型」决定的，而不是被步骤难度决定的	路由粒度下沉到步骤级

表里的「高档/低档」是相对说法，具体选哪个模型取决于你手上有什么、各家规则不同且会调整，以官方最新说明为准。分层路由怎么搭，模型路由策略里有更细的实现。

三、哪几步值得多花：看返工放大系数

判断一步该不该多花钱，只需要一个粗略量：这一步出错后，下游需要重跑的步骤数 × 单步平均成本 + 人工介入的时间成本。这个数越大，越应该在这一步上花钱买确定性。

按这个尺子，下面这几类步骤基本都值得用你手上最好的配置。

任务理解与拆解。 它的输出是后面所有步骤的地基。这一步偏一度，末端偏十度，而且偏得很隐蔽——生成的代码语法正确、测试也能跑，只是做的不是你要的事。这类错误往往要到人工验收才暴露，返工放大系数是全链最高的。多花的那点钱，一次避免的返工就赚回来了。

破坏性动作的决策点。 删文件、改数据库结构、动 CI 配置、执行会覆盖工作区的命令。这一步的失败成本不是 token，是你的时间和数据。这里不但要用好模型，还应该直接卡人工确认，让这一步永远不会在无人值守的情况下自动通过。

改动范围的边界判定。 就是「这次只准动这三个文件」这类判断。范围失控是 Agent 最常见的翻车方式之一，一旦越界，review 成本会暴涨到没人愿意看，最后只能整批丢弃。

最终自检与验收。 链条末端的一次高质量检查，能拦住前面所有环节漏下来的问题。这一步省钱最不划算——错误漏到线上，成本已经不在这个账本里算了。

长链条中的中途校准点。 步骤多的任务，每隔几步做一次「当前进展是否还对得上原始目标」的判断。这一步单独用好模型，能把可能的返工范围从整条链缩到几步之内。

四、哪几步该用便宜做法：先问能不能不用模型

省钱的第一顺位不是换便宜模型，而是把这一步从模型手里拿走。

能用确定性程序算出的，一律不给模型。 语法检查交给编译器和类型检查器，风格交给 formatter，正确性交给单测，依赖问题交给包管理器的解析结果。模型在这些事上既不比工具准，也比工具贵。一个常见的浪费是让模型「审阅」一段它刚生成的代码是否有语法错误——跑一次 lint 就有确定答案。

检索、过滤、分类、抽取这类步骤用小模型或规则。 它们的共同特点是判断维度少、错了容易发现、纠正代价低。这类步骤即便偶尔出错，下游也会很快把它顶回来，返工放大系数低，正是该省的地方。

工具返回体必须先压缩再进主链。 目录列表、日志、接口响应这些东西原样塞回去，是最没有性价比的花费之一——你为大量与决策无关的字符付了钱。做法是在工具层就裁剪：只保留字段子集，长文本先截断再交给小模型摘要，产出固定结构。这条和上下文管理是同一件事的两面，细节见 Agent 上下文管理。

重复模式的产出用模板。 同一种结构写第五遍时，就该把它变成脚本或代码生成器，模型只负责填变化的那部分。

按步骤类型选配置，而不是按会话。 很多实现是在会话开始时定一个模型然后一路用到底，这等于放弃了分配这件事。把选择下沉到步骤级，用环境变量或配置文件描述分层，运行时按步骤名查表：

export AGENT_MODEL_PLAN="<你的高档模型标识>"
export AGENT_MODEL_WORK="<你的常规模型标识>"
export AGENT_MODEL_UTIL="<你的小模型标识>"

模型标识用你实际接入的那家的官方名称，不要写别名或简称，别名指向哪个具体版本可能被服务方调整，错配之后表现是「结果悄悄变差」，很难查。另外，如果你考虑接海外厂商的模型来做高档层，需要先确认可用性：多家海外 AI 服务的官方条款对中国大陆地区有区域限制、不支持直连，具体覆盖范围以各家官方条款为准。这类限制属于服务条款和合规范畴，本文不讨论任何绕开它的做法；能不能用、用哪条正规接入路径，请按你所在组织的合规要求确认。把架构押在一个自己无法确认可用性的层上，是比省不省钱更大的风险，务实的做法是在路由表里给高档层准备一个国内可稳定获取的备选标识。

五、什么情况下别再折腾：止损点和回滚点

分配调优是有收益天花板的，撞到下面这些信号就该停，换条路走。

同一个任务连续三轮没有实质进展。 判断标准不是「模型说它改好了」，而是客观信号：测试通过数、编译错误数、diff 行数是否在收敛。如果三轮下来这些数字原地打转甚至变差，继续跑只是在为同一段上下文反复付钱。这时候正确的动作是中止、回到干净状态、把任务拆小重来。识别信号很朴素：它开始来回改同几行、或者把上一轮的改动又改了回去。

回滚点要在动手前就设好。 高风险步骤之前先固化一个可回退状态，这件事的成本几乎为零，收益却是让「重来」变成一条命令：

git add -A && git commit -m "wip: checkpoint before agent step"

回滚时用 git reset --hard <checkpoint> 或 git revert，取决于这段历史要不要留。别依赖 Agent 自己「记得改回去」——它对已发生的文件系统变更没有可靠记忆。

换配置不如换切法。 如果一个步骤在高档模型上也反复失败，说明失败原因不在模型能力，而在任务描述、上下文缺失或者环境本身。这时候把模型再换高一档是无效支出。正确的动作是缩小步骤粒度、补齐它读不到的信息，或者干脆这一段手写。

调优本身的成本要计入。 你为省下一部分调用费花掉半天时间重构流程，这笔账未必划算。一个务实的止损线是：如果一轮调整的预期节省不足以覆盖你调它的时间，就先记进待办，等这条链跑得足够多、节省被规模放大之后再动。

判断收益要用可比口径。 改完之后拿同一批任务重跑再比，别拿这周的账单和上周比——任务组成变了，数字没有意义。评测怎么做得可比，见 Agent 评测方法。

六、避坑清单

坑一：全局降档一刀切。 会踩是因为它看起来最省事、账单也立刻降了，反馈很正向。但成本重心和风险重心不重合时，降档会把返工率顶上去，几轮之后总花费反而更高。避法是降档前先跑一批基线任务，降档后用同一批复测成功率，成功率掉了就说明这一档不能降。

坑二：把「省钱」和「省上下文」当成同一件事。 会踩是因为两者在多数情况下确实同向。但在拆解步和校准步上，上下文砍太狠会让模型丢掉关键约束，产出看着合理实际跑偏。避法是给不同步骤设不同的上下文预算，关键决策步允许带更全的信息。

坑三：用会话级路由冒充步骤级路由。 会踩是因为大部分框架的默认写法就是会话开始时选一次模型，改成按步骤选要动结构。代价是你实际上没有做分配，只是在两个极端里挑。避法是把「选模型」抽成一个接受步骤名的函数，哪怕先返回同一个值，接口留出来后面才好改。

坑四：只统计模型调用，不统计返工。 会踩是因为调用日志是现成的，返工需要你自己标。结果是你看到的成本分布严重失真——真正贵的步骤在报表上很便宜，因为它的代价体现在别人身上。避法是打点时带上一个字段，记录这一步是否触发了后续重跑，哪怕靠人工事后补标。

坑五：让模型做本可以查表的事。 会踩是因为写进指令里只要一句话，写成代码要半小时。但这类调用数量大、单调重复，累积起来占比很可观，而且每次结果都可能不一样。避法是定期扫一遍步骤清单，把「输入确定则输出确定」的步骤挑出来改成代码。

坑六：把便宜步骤的失败当成小事。 会踩是因为单次纠正确实便宜。但如果一个廉价步骤的错误会静默传播到下游——比如抽取步漏了一个字段，下游按缺省值继续跑——它的返工放大系数就不低了，不该按廉价步对待。避法是给每个廉价步加一个确定性校验（字段是否齐、格式是否合法），校验不过就地重试，不往下传。

坑七：报错就自动重试。 会踩是因为重试逻辑写起来简单，而且很多故障确实是瞬时的。但 401/403 这类鉴权与权限问题重试多少次都不会好，只是白烧配额；429 需要退避而不是立刻重发；5xx 才是重试的合理场景。避法是按状态码分类处理，鉴权类直接中止并报警，限流类走指数退避，网络层的 ETIMEDOUT、ECONNRESET 限次重试。分类之前先把状态码和响应体原样记到日志里，否则事后连是哪一类都判断不了。

收个尾

分配这件事的本质，是承认 Agent 链条上的步骤价值不均等。有的步骤错了下游会兜住，有的步骤错了整条链白跑。把预算按这个差异重排，通常比换模型、砍上下文更能改善单位成本下的产出质量。

调完之后拿这份清单自查一遍：

每一步的输入输出量和返工次数，是否都有数？
成本重心和风险重心是不是同一步？如果不是，钱是不是摆反了？
拆解步、破坏性动作决策点、范围判定、最终验收，这四类是否用了你手上最稳的配置？
检索、过滤、格式转换这些步骤里，有多少其实可以用代码做掉？
工具返回体进主链之前有没有压缩，压缩规则是否固定？
每个廉价步骤后面有没有确定性校验，防止错误静默传播？
高风险步骤前是否有可回退的固化点，回滚是不是一条命令的事？
止损条件是否写死在流程里（连续几轮无进展就中止），而不是靠人盯着？

这八条里能全部答上来的团队不多，但每答上一条，账单的可预测性都会好一截。