弱模型不能裸奔：Agent Harness 凭什么真实有效 - 张善友
内容提要
模型分层定价后，用廉价Flash模型跑Agent看似省钱，但裸用会因错误分布不可预测而引发事故。关键在于Harness机制：通过critique和门禁将默认信任改为默认怀疑，用领域建模等非模型锚点验证，并路由调度——commodity模型承担平庸劳动，frontier模型仅用于高决策密度环节，可省75%用量。但弱模型若无法满足约束，仍需强模型。
延伸解读
“默认怀疑”是 Harness 的核心转变
文章指出，弱模型真正的问题不是犯错，而是错误分布不可预测，常以流畅合理的方式出错。Harness 通过 critique 和 commit 门禁，将“默认信任”改为“默认怀疑”，把验证成本内化到流程中。这意味着，使用弱模型时，必须建立机制来拦截错误，而不是依赖模型自身的可靠性。
同源批评效果有限，锚点应在模型之外
让同一个 Flash 模型既当 worker 又当 critic，收益有限，因为同源错误难以自我检出。有效的 critique 需要非模型锚点，如领域建模、本体和不变量。模型负责生成候选，工程负责审判。领域建模越硬，critique 阶段就越便宜可靠，这强调了工程在 Agent 流程中的关键作用。
75% 节省背后的劳动分工逻辑
文章认为，Agent 工作流中大多数 token 消耗是“平庸劳动”，只有少数高决策密度环节值得使用 frontier 模型。commodity 模型承担执行、填充等任务，frontier 模型仅用于规划、首个任务和交接瞬间。这种分工能节省约 75% 的 frontier 用量，但前提是 harness 机制有效。
Harness 有补偿极限，路由设计是关键
如果弱模型无法满足约束，比如需要长链推理的任务，再多 critique 也会导致反复重试，延迟和成本反而增加。因此，routing 逻辑（什么任务升级、什么留在 commodity floor）是 harness 中最难也最值得设计的部分。将工作流建模为技能 DAG，按能力需求调度，是有效的方法。
Q&A
为什么不能直接用便宜的Flash模型跑Agent？
因为弱模型的错误分布不可预测，它可能以流畅、完整、看似合理的方式犯错，比如代码能跑但逻辑错误，文档通顺但结论虚假。如果裸用，验证成本会推给下游、用户和生产环境，容易引发事故。
Agent Harness机制的核心思想是什么？
核心思想是通过critique阶段和commit门禁，将默认信任改为默认怀疑，用非模型的锚点（如领域建模、本体、不变量）来验证模型输出，从而内化验证成本，防止错误进入生产环境。
为什么让同一个Flash模型既当worker又当critic效果有限？
因为同源错误很难自我检出，一个模型认为某种写法没问题，换个身份再看一遍大概率还是觉得没问题，所以需要非模型的锚点来进行有效批判。
Harness机制如何实现节省75%的frontier模型用量？
通过路由调度，将大多数平庸劳动（如执行、填充、格式化）分配给commodity模型，只在决策密度高的环节（如规划期、首个任务、交接瞬间）使用frontier模型，从而大幅减少frontier模型的使用量。
Harness机制有补偿极限吗？在什么情况下不适用？
有。如果底层模型连被约束后的输出空间都达不到，比如需要长链推理的任务，弱模型在中间步骤就漂移，那么再多critique也只是反复枪毙和重来，延迟和token成本反而爆炸，此时应直接用强模型。
如何设计路由逻辑来分配任务给commodity或frontier模型？
可以将工作流画成技能DAG，每个节点声明能力需求，路由按标注调度。DAG代表工作流结构，调度策略决定何时升级任务到frontier模型，何时留在commodity floor。
Harness机制长期价值体现在哪里？
Harness将工程纪律（验证、门禁、不变量、路由）变成架构的一等公民，即使模型每半年换代，这套流程会保留下来并越来越有价值，因为它不依赖特定模型。
