立正反对只凭 benchmark 或个例就断定模型 A 强于 B，更该问的是哪个模型适合哪类任务、怎样发挥它的潜力⁠1。放到 agent 交付上，基座这一层要测的是“在你这批真实任务上，模型本身能稳定做到什么”：同一任务换几种输入、跑多轮，看它是否在关键约束上反复出错，还是只是偶发波动。这一步的作用是划出模型能力边界——如果错误集中在任务本身超出模型稳定能力，换 prompt 收效有限，该换模型、换工具或降低任务复杂度，而不是继续调指令⁠2。

立正把 harness 比作马具：模型是马，缰绳、马鞍、行业上下文和合规这些才是 harness，模型公司做通用，纵深要靠 harness 补⁠3。他讲 L6 时列出的正是这一层要具备的东西：重试、降级、结构化输出校验、工具结果校验、错误恢复、人工升级、可观测、版本控制、模型路由、回归测试⁠4。所以测 harness 不是看 demo 跑通一次，而是看模型不稳定、工具失败、环境变化时系统还能不能交付⁠4。具体做法：故意让工具返回异常、让输入越界，看它是报错、静默给出错误结果，还是走降级或转人工；再看工具调用轨迹和中间产物是否可见，黑盒输出几乎无法调试⁠2。

立正强调每个任务都该有明确、可执行的验收标准：是否满足某条件、是否避免了某类错误、是否覆盖关键边界、是否符合格式与约束⁠2。测 agent 交付时，这套标准应同时挂在两层上：基座层看单次生成是否达标，harness 层看系统能否在输出前自检、在失败后修正并留下记录。诊断也要分类，context 缺失、上下文窗口饱和、指令歧义、模型能力边界是不同问题，用同一套动作去修只会靠运气⁠2。