省钱指南：廉价模型足以胜任大多数Agent任务

Part 1 论证了大多数企业级 Agent 失败本质上是架构问题。本篇将剖析其中最常见的架构错误：为一份工作支付前沿模型的价格，而更便宜的模型完全可以胜任。

团队默认选择最大最强的模型，因为这样感觉更安全。然后他们用这个模型运行数十亿次从邮件中提取日期这样的任务，最后看着 AI 支出条目像工资单一样惊人。

对比当前市场的两个极端（2026 年 8 月的官方定价）：

这意味着在各项独立智能评测中都位居前列的模型，其每 Token 成本比前者低了约 20 倍到 70 倍，尽管它在每个能力维度上都落后于 Fable。

现在来正视一下注意事项，因为这些很重要：

Flash 的输出比较冗长。相比中等水平的模型，它每个任务输出的 Token 数量要多得多，所以实际单任务成本差距比 Token 单价差距要小一些。不过即便打了折扣，差距仍然相当可观。

Benchmark 数据大多由厂商自行报告，尚待独立验证。

它确实落后于前沿模型。在高难度的 Agent 编码、大型代码库、优化问题、真正模糊的工作任务上，前沿模型确实物有所值。

但问题的关键在于：你的工作负载可能根本不是这些场景。Gmail 风格的日历提取不需要前沿智能。分类、路由、结构化提取、大多数 RAG 问答任务也一样。一个目标明确、Schema 严格、有验证机制的工作流，可以把"排行榜低 10%"变成"生产环境中毫无差别"。

陷阱在于：用通用排行榜来评估狭窄任务。通用 benchmark 的差距不会直接转化。排行榜低 10% 的模型，在提取发票总额上可能毫无差异，也可能在你那些奇怪的领域术语上差 50%。不实际测量，你就无从得知。

这就是为什么 Eval 驱动的开发应该是第一步，而不是最后一步：

  Define task
      │
      ▼
  Build eval set (20+ real examples)
      │
      ▼
  Score candidate models (include the cheap ones)
      │
      ▼
  Does a cheap model pass? ──yes──► Ship it. Save 20-70x.
      │no
      ▼
  Try the next tier up

Eval 还有一层更微妙的作用。编写它们迫使你尽早枚举边界情况，并精确地界定你实际要构建的东西。跳过这一步的团队不仅仅是选错了模型——他们构建了错误的产品。

有两件事必须停止：一是先选模型后评估，二是还没验证一个便宜模型加 Schema 是否够用就去做多 Agent 架构。

找出生产环境中成本最高的那个 LLM 调用。为它构建一个 20 条样本的 Eval。用中等档次的模型跑一遍，和你现有的模型对比。无论结果如何，把差距发布给团队看。

下一篇：Part 3，The Agent With Credentials。当攻击者不再攻击你的应用，转而开始和你的 Agent 对话时，会发生什么。