Harness Engineering

Harness Engineering 指模型足够强之后，工程重心从「怎么问」（Prompt Engineering）和「给模型看什么」（Context Engineering）转向给 agent 工具和反馈通道，让它自己判断该看什么、该验证什么，同时用 sandbox、权限、测试、CI 轮数、结构约束等边界防止失控。

三圈螺旋的关键不是分类，而是每一圈成熟后变成下一圈的基础设施：prompt 技巧固化进模板与系统提示，context 组装固化进检索与压缩管线，然后 harness 层接管「循环里由谁决定下一步」。

对「模型够强了，harness 还有什么意义」的回答（彭罗德实战复盘）：harness 的工作不是消灭复杂性——复杂性消灭不了——而是分配复杂性，把每条业务真相送回应该为它负责的层。反模式是失控环（benchmark → bad case → Prompt 补丁 → 局部指标改善 → 新回归 → 整体僵化），正模式是归位环（bad case → 定位失败层 → 责任层最小修复 → 端到端回归 → 判断规则去留）。判据句：benchmark 是诊断仪，不是 System Prompt 的自动补全器；bad case 是证据，不是答案——它告诉你某处坏了，不告诉你在哪一层修。

同一来源给出的规则治理观：任何新规则进系统要能回答四问——来自哪个失败、真正属于哪一层、用什么指标判断有效且不伤邻近 case、上游变化后怎样知道它可删。没有这些记录，临时脚手架会永久留在 System Prompt 里，后人不敢删只能绕着加，「脚手架最终变成监狱」。这与 The Bitter Lesson 的工程化读法一致：把人类局部经验固化成规则短期见效、长期压缩模型泛化空间，但结论不是不写规则，而是确定性边界进代码/状态/可测试契约，需要理解、搜索与泛化的部分才交给模型。评测单位相应地不是单个 Prompt、节点或离线分数，而是用户真正要完成的任务（组件与契约 / 端到端链路 / 线上产品结果三尺度，见 agent-runtime-design）。

一手经验的印证见文章 一次 Video Agent 迭代如何长成 Harness 方法：视频风格 agent 的迭代压力自然长出了共享上下文（对比矩阵 + phase trace）、独立评审（三层 review stack）、边界知识库（boundary / exemplar store）和回归保护（golden set + regression gate）——这四件事合起来就是一个 harness。

写作方法论层面的观察记录在 LLM Harness Writing Study。