主题
对比 JavaGuide《Harness Engineering》 与二哥《什么是 Harness Engineering？》《Cordis 是什么？》。小林无对应专题（最接近的只有「手搓 Agent 还是用框架」的框架选型视角），本篇维持两方对比。
多版对比
定义：两边共识是 Agent = Model + Harness。JavaGuide 的方法论更本质：反推「模型做不到什么」——记忆、执行环境、外部知识、文件系统、验证闭环、上下文管理，缺什么 Harness 补什么，六层架构（信息边界到约束恢复）就是按这个推出来的，并坦承这是分析框架不是业界标准。二哥的马具比喻好记（LLM 是千里马，Harness 是缰绳马鞍围栏），四组件是验证循环、错误恢复、权限控制、状态管理。
最有力的证据，JavaGuide 独有：同一模型只换文件编辑接口，评测得分 6.7% → 68.3%——瓶颈经常不在模型，在 Harness。还有「168K 窗口用到约 40% 后质量下降」的现象，但 JavaGuide 自己标注了勿直接外推。
二哥硬伤：把「每次犯错就工程化一个方案」当成 Harness 的总定义——在 JavaGuide 里这只是某一线团队的个人实践之一；且四组件里没有独立验证/评估层，而那恰是 JavaGuide 认为最难的空白。Cordis 案例（可逆副作用支持热重载、DeepSeek Harness 一切皆插件）只有二哥讲，数字无法核实，当案例素材用。
最优题解
Harness 是模型外面的那层运行时，负责模型做不到或不可信的事：执行工具、维护状态、控制权限、处理失败，以及最关键的——独立验证。方法是用「模型做不到什么」反推：模型没有持久状态，Harness 管；模型会算错、说做完，Harness 用测试和结果比对来验收；模型不该碰危险操作，Harness 用权限挡。
为什么重要？同一个模型只换一层文件编辑接口，代码评测得分能从 6.7% 涨到 68.3%——上限差距往往在 Harness 不在模型。所以做 Agent 项目的顺序是先把 Harness 的验证闭环搭起来，再谈换更强的模型。宽度上也有权衡：Harness 太薄兜不住失败，太厚会把 Agent 锁死成流程，按任务风险定厚薄。
追问链
追问：验证为什么要独立，不能用模型自评吗？ 参考答：模型会顺着上下文说服自己成功了；验收信号必须是外部事实——测试跑没跑过、输出和期望比对、副作用查没查到。模型自评只能当预检，不能当收口。
追问：长上下文用到多少会掉质量？ 参考答：有实测观察到大约四成利用率后质量下降，但阈值跟模型和任务强相关，不能当成通用数字——正确姿势是对自己的任务做长度-质量曲线，再定压缩策略。
我的理解
这道题我记两个东西：一是「反推模型做不到什么」这个生成定义的方法（面试被问到没准备过的细节时可以现场推），二是 6.7%→68.3% 这一个数据点（比任何定义都有说服力）。二哥的马具比喻留给自己理解用，口述时说「底盘/运行时」更专业。二哥四组件缺验证层这个缺口，恰好是答「最难的是什么」的素材。