# 一个便宜的模型能搞定 90% 的活 默认做法是把最大、最聪明的模型怼到所有事情上。它在 demo 里跑得很好，然后在规模化时悄悄把你拖垮——因为 agent 做的大部分事情不是推理，而是机械劳动，而你却在花天才的工资让它读一张表单。解法很无聊，但能省下约 90%：让聪明的模型做规划，让便宜的模型干活。下面讲清楚经济账，以及让这一切成为可能的那一条架构准则。 - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, architecture, business - **Source:** https://fedorthinks.com/zh/blog/cheap-model-most-of-the-work --- 人们构建第一个 agent 时，会对所有事情都掏出最好的模型。这当然合情合理——这是 最稳妥的选择，它给出最好的答案，而在 demo 里成本不过是个零头。把最聪明的模型 怼到整个问题上，看着它跑起来。 然后它上了生产环境，调用量翻了好几个数量级，账单就来了。结果发现，"直接用最好 的模型"根本不是一个中性的默认值。它是一个决定：为每一个琐碎的步骤都付最高价 ——而大部分步骤都是琐碎的。 ## 价格差距巨大，却没人去看 这个数字应该能重新定义整件事。在 2026 年，LLM API 的价格 [从小模型的约 **每百万输入 tokens 0.10 美元** 到前沿推理模型的 **每百万 30 美元** 不等](https://www.cloudzero.com/blog/llm-api-pricing-comparison/) ——对于简单任务上产出几乎无法区分的输出来说，差距大约是 **300 倍**。 CloudZero 把它的实际版本说得很直白：在一个不需要前沿推理的工作负载上用前沿模型， 可能 [**贵 16 倍，质量却没有任何有意义的提升**](https://www.cloudzero.com/blog/llm-api-pricing-comparison/)。 同样的答案，付十六倍的价钱。在你技术栈的任何其他地方你都绝不会接受这种事，但对 模型，大多数团队甚至从不检查——他们一次性挑出最好的那个，然后把 _所有东西_ 都 路由过去。 ## agent 做的大部分事情不是思考 这之所以如此浪费，是因为一个 agent 任务并不是一次伟大的天才之举。把一个真实任务 拆开，你会发现几个真正困难的步骤埋在一堆机械步骤里：从这段 JSON 里抽取一个字段、 给这条消息分类、把那个列表重新排版、决定调用哪个工具、总结一个段落、填一个模板。 困难的部分——理解目标、规划方法——可能只是五十步里的一步。 用一个每百万 30 美元的推理模型去跑"从这段文本里把订单 ID 抠出来"，就是花一个资深 工程师的时薪去给抽屉按字母排序。它的错不在于失败——它跑得好好的。它的错在于你 买了一份你用不上的能力，每个任务买五十次，永远买下去。 ## 模式：聪明的模型做规划，便宜的模型干活 这个解法有个名字——**规划-执行（plan-and-execute）**——而它就是字面意思。一个 有能力的（昂贵的）模型审视请求并产出一份计划：推理、拆解、策略。然后便宜、快速 的模型去执行这份计划的每一步，因为一旦思考做完了，这些步骤就是机械的，小模型做 得一样好。 [LangChain 的文章](https://www.langchain.com/blog/planning-agents) 和其他人 把节省幅度定在 [相比凡事都用前沿模型 **高达 90%**](https://www.philschmid.de/agentic-pattern)。 这不是什么旁门左道的小技巧。它和 [Klarna 的做法](https://www.mindstudio.ai/blog/ai-agent-token-cost-optimization-multi-model-routing) 很接近：一个前沿模型分析客户的意图并规划出解决步骤，而较小的模型去做实际的活 ——拉取账户数据、处理退款、生成回复。把天才花一次，花在真正需要它的部分；其余 的批发着买。 还有一点会让人意外：质量通常不会下降。在一个范围窄、定义清晰的步骤上，小模型往 往 _更好_——更快、更可预测，也更不容易对一个只想要一件无聊事情的任务"发挥创意"。 让模型匹配任务并不是一种牺牲。那个过大的模型在那些步骤上本来就没有添加任何东西。 ## 让这一切成为可能的准则：永远不要硬编码模型 这里有个坑，而且是架构层面的。你只有在代码没有焊死在某一个模型上时，才能按任务 路由。如果 `gpt-whatever` 被硬编码在你业务逻辑的中间，你就没法在不动手术的情况下 把一个便宜模型换进那些机械步骤——所以你不换，于是你继续多付钱。 这就是我一再 [回到](/blog/cheap-code-is-expensive)的那条纪律：模型是一个依赖，而依赖应该待在 边界之后，被注入，而不是被烤死在代码里。逻辑里硬编码的模型名是一种代码坏味道， 原因和硬编码的价格或硬编码的 API key 一样——它是一个可替换的细节，却伪装成一个 固定的事实。把它放到一道干净的接缝之后，"这里换个更便宜的模型"就变成了改一行 配置，而不是一次重构。（我曾经只改一个值，就把我某个产品背后的整个提供商换掉了 ——那不是运气，只是没有把那个本来就注定要变的东西硬编码而已。） 一旦模型成为一个可替换的参数，路由就自然而然地出现了：一个轻量的分类器或几条 启发式规则判断每一步的复杂度，并把它送到合适的档位。 [单是路由](https://www.mindstudio.ai/blog/ai-agent-token-cost-optimization-multi-model-routing) ——简单的多数用便宜模型，困难的少数用前沿模型——通常被报告能在保持困难案例质量 的同时削减 **60–80%** 的成本。 ## 为什么浪费的默认做法还是赢了 如果这显然更好，为什么不是每个人都这么做？原因和 [便宜的架构赢下会议](/blog/cheap-code-is-expensive)一样：浪费恰恰在你做决定的 那一刻是隐形的。在 demo 里，"凡事都用最好的模型"最容易构建，成本只有几美分。让 它变成错误的那张账单，要等到你规模化之后才会到来——而那时它已经是一笔五位数或 六位数的开销，挂在一份到处硬编码模型的代码上，所以修复它现在成了一个项目。这个 偷懒的默认做法选起来便宜，活在其中却昂贵。你没有省下力气；你只是推迟了一张账单， 并让它利滚利。 这里还有一个面子问题：掏出最大的模型 _感觉_ 像是那个严肃、稳妥的选择。它不是。 在一个排版步骤上花前沿模型的钱不是严谨——只是没去看过而已。真正的工程是知道你 流水线里的哪 10% 需要那颗昂贵的大脑，并且拥有能只把那 10% 送过去的架构。 前沿模型不是炫耀的资本。知道在哪里你不需要它，才是。