对照他们交付的模式校验，而不是对照你期望的模式
来源：dev.to — 2026-09-06
📋 概述
作者的测试 harness 标记模型发了错误参数，比对了模型实际发送与运行前预先冻结的对象，两者不符。失配是真的，但他从中得出的结论是错的，而比较器无法告诉他这一点。根因是模型被塞了两个相互矛盾的权威：provider 的 exec schema 要求 intent 与 command 两个字段（cwd、env 可选），而他的指令只给一个键。模型遵循了 provider 的模式、满足必填字段 schema，却漏了他「完全一致」的指令——因为他要的正是 schema 禁止的东西。结论不是「模型对了」，而是失配只能证明有差异，不能指出哪一端是权威。
🔑 核心要点
关键发现——失配确立差异，而非哪一端权威：模型被同时给了两个矛盾的契约，它跟了 provider 的 schema、满足必填字段，却漏了作者「完全一致」的指令，因为那条指令要的正是 schema 不允许的 正确修复不是「放宽比较」：只比 command、忽略多余键会让失败消失、也让控制随之一同消失——agent 之后可以随意多传参数仍然通过 真正的修复是修正期望本身：intent 值由 harness 写死为常量而非从模型发送里复制（复制等于让模型与自己比较），并把参数集合收紧为恰好 command+intent 三件事里只有一件变了：期望被修正（一键变两键）、期望对象闸门变严（新代码块）、实际对期望的比较保持原样——并未靠弱化比较器来掩盖误报，这正是全文主旨 会烂掉的部分：argumentKeys.length!==2 同时硬编码了 provider 当前必填集合与作者禁用可选字段的决策——若 TrueForge 明天新增第三个必填字段，harness 会拒绝一个合规的模型，除非同步改 harness
💡 金句
A control that fires wrongly is not evidence the control is too strict. It is evidence that something on one of its two sides is wrong, and you have to find out which before you touch it.
👍 0
❤️ 点赞
👎 0
沉底
← 返回 dev.to 首页