Opus 省钱的关键：不是更便宜，而是少让它干活

Mendral 这次给了一个反常账本：CI 故障分析系统从 Sonnet 4.0 升级到更强的 Opus 4.6，LLM 成本反而降了。

这事容易被误读成“前沿模型也能降本”。我不太买这个说法。真正起作用的不是 Opus 突然便宜，而是 Mendral 没让 Opus 去吞日志、跑重复活、扮演万能客服。它被关在一个更窄的位置上：提出假设，拆任务，调度子代理，综合结果。

钱省在哪：80% 故障没进 Opus

Mendral 上周分析了约 4000 个 CI failure。里面 818 个是新问题，3187 个是已知问题复现。

也就是说，约 80% 的故障不该进入昂贵模型。它们更像“查重题”，不是“侦探题”。

这套分工里，Haiku 承担了约 65% 的输入 token，却只占约 36% 的 LLM 花费。便宜模型负责吞吐，贵模型负责判断。分工不花哨，但很硬。

还有一个关键点：Opus 不读原始日志。

Mendral 没把 20 万行日志硬塞进上下文，而是把 CI 日志放进 ClickHouse，给代理 SQL、物化视图和 GitHub CLI。代理需要失败率、job timing、outcome count，就先查聚合视图；需要细节，再下钻到原始日志。

这省的不只是 token。还省掉一种很隐蔽的误导：上下文锚定。

你把一大段日志塞给模型，其实已经暗示它“答案就在这里”。调试时，人会被带偏，模型也会。工具查询让模型先问问题，再拿证据，而不是抱着一堆文本猜谜。

对 Agent 团队意味着什么

这件事最该看的人，不是普通用户，而是两类人：做 LLM 应用架构的工程团队，以及要管 AI 成本的技术负责人。

对工程团队，动作很具体：别急着把所有任务都迁到最强模型。先把流量拆开，统计重复率、可检索性、误判代价。重复率高、历史样本多、输出能结构化，才值得做 triager 和 sub-agent。

对技术负责人，采购动作也该变慢一点。不要只拿模型价格表做预算。该问的是三件事：

• 昂贵模型每次调用前，有没有便宜模型或规则层拦截？
• 上下文是被动塞进去，还是由工具按需查询？
• 子代理有没有层数、预算、升级条件和责任链？

如果这三件事答不上来，换 Opus、换 Sonnet、换任何 frontier model，都只是把更贵的脑子接到一条漏水的管道上。

这里也有现实限制。Mendral 的案例不能外推成“所有企业升级强模型都会省钱”。它依赖几个条件：CI failure 重复率高，日志可查询，历史问题可匹配，调查结果能被压成结构化摘要。

安全日志、IoT 遥测、金融风控里，类似结构可能成立。但低重复、强主观、责任边界模糊的任务，未必适合这套打法。比如产品策略判断、复杂客户沟通、开放式研究，便宜模型截流很可能会变成便宜模型误导。

宁可多花钱升级，也不要把真实新问题压成“已知复现”。Mendral 的规则里，“有疑问就升级”很重要。省钱不能靠装瞎。

真正该盯的变量，不是模型价格

很多团队谈 LLM 降本，第一反应还是盯单价：每百万 token 多少钱，输入输出怎么计费，缓存有没有优惠。

这些当然要算。但它们不是分水岭。

分水岭在架构：你能不能限制昂贵模型的出场次数、上下文负担和执行范围。

Mendral 的 Opus 更像值班医生，不是化验员。它看症状，开检查单，读报告，做判断。Haiku 像检验科，负责大量、重复、窄范围的检查。ClickHouse、SQL、物化视图，则是医院的信息系统。没有这些地面设施，医生再强也只能翻病历翻到眼花。

“善战者，求之于势。”这句话放在这里很准。势不是模型智商，而是任务结构、工具层、升级路径和刹车机制。

接下来最该观察的，不是 Opus 4.6 本身有多强，而是这几个变量：

扯远一点，这和早期工厂管理很像。不完全一样，但结构相似。机器更强以后，最先被看见的是产能；真正决定利润的，是工序、质检、停机规则和责任划分。

AI Agent 也在走这条老路。模型能力上来以后，管理问题才露出来。谁能定义窄任务，谁能设计升级路径，谁能让模型在该停的地方停下，谁才可能把强模型用成便宜方案。

Mendral 这次少见地把账讲清楚了：智能不是免费劳动力。它要分层，要调度，要边界。贵模型负责脑子，便宜模型负责腿脚，工具层负责记忆和事实。

模型越强，产品越要克制。能让 Opus 少干活，才是真的会用 Opus。