一个越来越常见的念头

模型分层定价之后，很多人动过同一个心思：既然 Flash 级模型这么便宜，干脆全用它跑 Agent 得了。

算账确实诱人。但裸用弱模型干活，出来的东西隐患巨大——这不是体感，是结构性的问题。而那张流传很广的 Harness 工作环图，恰好把解法画清楚了：commodity 模型扛起整条弧，frontier 模型只在它值回票价的地方出手，全程大约能省下 75% 的 frontier 用量。

关键在于，这个"省"字背后站着一整套防护和验证机制。没有它们，省钱就是省出了事故。

隐患不在"错"，在"错得自信且连贯"

弱模型真正可怕的地方，不是它会犯错——强模型也会——而是它的错误分布不可预测。

它不会在你预期的地方犯错，而是以一种流畅、完整、看起来非常合理的方式犯错。代码能跑但逻辑是歪的，文档通顺但结论是假的。裸用它，等于把全部验证成本推给下游、推给用户、推给生产环境。

Harness 的本质，就是把这个成本内化：critique 阶段、commit 门禁，都是在把"默认信任"改成"默认怀疑"。模型可以犯错，但错误过不了门禁。

Critique 的有效性，取决于校验器，而不是另一个模型

这是那张图最容易被误读的地方。

让同一个 Flash 模型既当 worker 又当 critic，收益很有限——同源错误很难自我检出。一个觉得某种写法没问题的模型，换个身份再看一遍，大概率还是觉得没问题。

真正有效的 critique，锚点是非模型的东西：

• 可执行的验证：测试、类型检查、编译、lint——跑不过就是跑不过，没有辩论空间；
• 结构约束：schema 校验、JSON-LD 的 framing / slicing 这种形状约束——输出的"形状"先被框死；
• 领域不变量：这是 DDD 能进场的地方。聚合的不变条件、领域事件的合法性，都可以形式化成机器可检查的契约。

换句话说：领域建模做得越硬，harness 的 critique 阶段就越便宜、越可靠。 模型负责生成候选，本体和不变量负责枪毙候选。生成的归模型，审判的归工程。

"-75% frontier usage" 的真正含义

这个数字不是"省了 75% 的钱"这么简单，它承认了一个很多人不愿承认的事实：Agent 工作流里的大多数 token 消耗，是平庸劳动。

真正决策密度高的，只有几个点：

• 规划与拆解——方向错了，后面全是白干；
• 首个任务的冷启动——没有上下文时最考验判断力；
• 最终 promote 的交接——这一步决定东西能不能出门。

这些值得 frontier 模型。而中间大段的执行、填充、格式化，是 commodity 劳动——用便宜模型加一道门禁，完全够格。

这不就是那条弧的含义：commodity floor 承担维护和简单任务，frontier 只覆盖规划期、首个任务和交接瞬间。

一个不能回避的边界

但也要泼一盆冷水：harness 有补偿极限。

如果底层模型连"被约束后的输出空间"都够不到——比如需要长链推理的任务，弱模型在中间步骤就漂移了——那么再多 critique 也只是反复枪毙、反复重来。延迟和 token 成本反而爆炸，还不如一开始就用强模型。

所以 harness 里最难、也最值得精细设计的，是 routing 逻辑本身：什么任务升级、什么任务留在 commodity floor。

这件事同样可以建模：把工作流画成一张技能 DAG，每个节点声明自己的能力需求，路由按标注调度。DAG 就是那条弧，调度策略就是 frontier 的使用纪律。

结语：模型可以换，纪律沉淀下来

Harness 不是给弱模型贴的创可贴。

它是把工程纪律——验证、门禁、不变量、路由——变成架构里一等公民的方式。模型每半年换一代，今天省钱的 Flash 明天可能就过时了，但那套"默认怀疑、机器校验、按决策密度调度"的流程会留下来，并且越跑越值钱。

弱模型不能裸奔。给它穿上 harness，便宜才真正是便宜。