Appearance
Harness Engineering — The Evaluation Problem
房间里的大象： Harness Engineering 的整个体系缺少一个关键环节——如何可靠地验证智能体生成的代码是否真的做了正确的事。
The Core Problem
所有 harness engineering 文章都在讨论如何引导和约束智能体——更好的 AGENTS.md、更严的 linter、更巧的架构。但它们集体回避了一个根本问题：
你怎么知道智能体做的事情是对的？
不是"代码能编译"，不是"测试通过了"，而是——它真的解决了用户的问题吗？
Böckeler 在 Fowler 正式版中最诚实地命名了这个问题：行为 Harness 是房间里的大象。但命名问题不等于解决问题。
现有评估方案对比
跨 15 篇核心文章分析，每一篇都尝试了不同的评估方案，没有一篇给出了令人信服的答案：
| # | 来源 | 评估方案 | 能验证什么 | 不能验证什么 |
|---|---|---|---|---|
| 1 | OpenAI | linter + 结构测试 | 代码结构、风格一致性 | 功能正确性 |
| 2 | Böckeler/Fowler | Guides×Sensors 三维度分类 | 可维护性（强）、架构适应度（中） | 行为正确性（弱） |
| 3 | LangChain | Context Rot 感知 | 上下文退化 | 输出质量 |
| 4 | Anthropic | 分离 Evaluator + Sprint 合同 | 多维度评分 | Self-eval 倾向过度称赞 |
| 5 | HumanLayer | Back-pressure（测试/构建/类型检查） | 可测试的回归错误 | 需求理解偏差 |
| 6 | Encoding Team Standards | 三层编码路径 | 团队约定的遵守 | 约定本身是否正确 |
| 7 | Feedback Flywheel | 观察失败→根因→修复→验证 | 已知的失败模式 | 未知的失败模式 |
| 8 | Meta-Harness | 自动搜索最优 Harness | Harness 性能 | 依赖可靠的评估函数为前提 |
三个层次的验证
第一层：可维护性验证（最成熟）
工具链已经很完善：linter、类型检查、代码覆盖率、ArchUnit、OpenRewrite。这些是计算性传感器——确定性的、每次提交都跑、结果可信。
问题不大。OpenAI 的机械化执行和 HumanLayer 的背压杠杆都在这一层运作良好。
第二层：架构适应度验证（中等）
Fitness Functions 可以检测架构漂移：依赖方向、模块边界、性能 SLO。但这里开始出现裂缝：
- 上下文压缩有 7 种策略、状态管理有多种模式——哪种在什么场景下更好，没有共识
- Meta-Harness 能自动搜索最优 Harness，但前提是有可靠的评估函数——评估函数本身怎么评估？
第三层：行为正确性验证（最弱——大象所在）
这是整个体系的软肋。核心矛盾：
背压机制只能捕获结构性和回归性错误。 对于"代码能编译和通过测试，但做错了事"的情况，整个体系没有可靠答案。
具体表现：
测试不等于正确性。 lalitm 的教训最痛：500 多个测试全部通过，但组件设计是完全错误的，需要彻底重做。
Self-evaluation 会失败。 Anthropic 发现智能体评估自己的工作时倾向于过度称赞，"即使质量平庸"。即使使用分离的 Evaluator，Evaluator 本身也是 LLM，也有同样的倾向。
需求理解偏差无法被机械化检测。 如果智能体对需求的理解本身就是错的，所有 lint、所有测试、所有架构检查都会通过——因为它们验证的是"智能体认为的正确"，而不是"用户需要的正确"。
LLM-as-judge 需要校准锚点。 评估体系本身的质量上限受人类投入的制约——但 harness engineering 的目标恰恰是减少人类投入。
为什么这个问题这么难
借用 Böckeler 引用的 Ashby 必要多样性定律：
调节器必须至少拥有与被调节系统同等的多样性。
LLM 能生成几乎任何东西——它的输出多样性极高。要可靠地验证这个输出，验证器的能力至少要和生成器一样强。
这就是循环论证： 你需要一个和 LLM 一样聪明的系统来验证 LLM 的输出。如果你有这样的系统，为什么不直接用它来生成？
Anthropic 的分离 Evaluator 本质上是用另一个 LLM 来评估一个 LLM。这在边界情况下有帮助（两个 LLM 犯同样错误的概率低于一个），但不是根本解法。
对 Harness Engineering 适用范围的推论
如果行为验证问题没有通用解法，那 harness engineering 的适用范围是有条件的：
| 条件 | Harness Engineering 可靠度 | 例子 |
|---|---|---|
| 需求明确 + 可测试 | 高 | API 实现、数据管道、CRUD |
| 需求明确 + 不可测试 | 中 | UI 设计、用户体验 |
| 需求模糊 + 可测试 | 中 | 探索性原型 |
| 需求模糊 + 不可测试 | 低 | 架构设计、产品决策、安全审计 |
经验验证：AI 在 well-constrained 的任务上卓越（测试编写、重构、API 实现），在需要判断力的任务上失败（架构决策、API 设计、性能优化）。
Three Paths Forward
评估问题不会被某个技术突破一次性解决。它更可能沿着三条路径渐进改善：
- 工具链的纵深：从 lint → 变异测试 → 属性测试 → 形式化片段——不断扩大计算性传感器的覆盖范围
- 对抗性架构：从单智能体 → Evaluator 分离 → 红蓝对抗 → 多模型交叉验证——通过冗余降低系统性偏差
- 人类的精准介入：从全量审查 → 抽检 → 关键节点审查 → 基于异常检测的定向审查——让人类只在最需要的地方出现
"好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方。" —— Birgitta Böckeler
评估，就是那个"最重要的地方"。
Related Concepts
- Harness Engineering — Harness Engineering 方法论概述
- LLM Evaluation — LLM 评测体系
- AI Agents — AI Agent 系统形态
Open Questions
- 评估的评估问题： Meta-Harness 自动搜索依赖评估函数，评估函数本身的质量谁来评估？
- 人类抽检的可扩展性： 如果最终答案是人类审查，那"吞吐量优先"理念就受到人类注意力的硬约束。
- 对抗性评估： 能否用专门来找错的 LLM（红队）来评估另一个 LLM 的输出？
- 形式化验证的边界： 对某些领域（密码学、协议、数学证明）可行，但软件工程多数场景不适用。
- "足够好"的标准： 什么程度的评估对什么类型的任务足够好？