# 评估是房间里的大象：Harness Engineering 的阿喀琉斯之踵

> 跨 15 篇核心文章的评估方案对比分析
> 日期：2026-04-14

---

## 核心论点

所有 harness engineering 文章都在讨论如何**引导**和**约束**智能体——更好的 AGENTS.md、更严的 linter、更巧的架构。但它们集体回避了一个根本问题：

**你怎么知道智能体做的事情是对的？**

不是"代码能编译"，不是"测试通过了"，而是——它真的解决了用户的问题吗？

Böckeler 在 Fowler 正式版中最诚实地命名了这个问题：行为 Harness 是**房间里的大象**。但命名问题不等于解决问题。写作时点已收录的 15 篇文章读下来，每一篇都尝试了不同的评估方案，没有一篇给出了令人信服的答案。

---

## 各文章的评估方案对比

| # | 文章 | 评估方案 | 能验证什么 | 不能验证什么 |
|---|------|---------|----------|------------|
| 1 | OpenAI | linter + 结构测试 | 代码结构、风格一致性 | 功能正确性 |
| 2 | Fowler/Böckeler | Guides×Sensors 三维度分类 | 可维护性（强）、架构适应度（中） | **行为正确性（弱）** |
| 3 | LangChain | Context Rot 感知 | 上下文退化 | 输出质量 |
| 4 | Anthropic #4 | 分离 Evaluator + Sprint 合同 | 多维度评分（设计/原创/工艺/功能） | Self-eval 倾向过度称赞 |
| 5 | HumanLayer | Back-pressure（测试/构建/类型检查） | 可测试的回归错误 | 需求理解偏差 |
| 8 | Encoding Team Standards | 三层编码路径（口头→示例→自动化） | 团队约定的遵守 | 约定本身是否正确 |
| 9 | Feedback Flywheel | 观察失败→根因→修复→验证 | 已知的失败模式 | 未知的失败模式 |
| 10 | LangChain Evaluation Checklist | 五阶段评估体系 | 可度量的成功标准 | 标准本身的完整性 |
| 11 | Meta-Harness | 自动搜索最优 Harness | Harness 层面的性能 | 依赖可靠的评估函数作为前提 |
| 13 | Inside the Scaffold | 13 个脚手架的架构分类 | 架构选择的多样性 | 哪种选择在什么场景下更好 |
| 14 | ⭐ lalitm | 人类审查 + 持续重构 | 设计品味、API 质量 | 不可扩展 |

---

## 三个层次的验证，成熟度递减

Böckeler 的三维度分类是目前最清晰的框架：

### 第一层：可维护性验证（最成熟）

工具链已经很完善：linter、类型检查、代码覆盖率、ArchUnit、OpenRewrite。这些是**计算性传感器**——确定性的、每次提交都跑、结果可信。

问题不大。OpenAI 的[机械化执行](../concepts/02-mechanical-enforcement.md)（概念 3）和 HumanLayer 的背压杠杆都在这一层运作良好。

### 第二层：架构适应度验证（中等）

Fitness Functions 可以检测架构漂移：依赖方向、模块边界、性能 SLO。但这里开始出现裂缝：

- Inside the Scaffold 发现 13 个脚手架中，上下文压缩有 7 种策略、状态管理有多种模式——**哪种在什么场景下更好，没有共识**
- Meta-Harness 论文能自动搜索最优 Harness，但前提是有可靠的评估函数——**评估函数本身怎么评估？**

### 第三层：行为正确性验证（最弱——大象所在）

这是整个体系的软肋。核心矛盾：

**背压机制只能捕获结构性和回归性错误。** 对于"代码能编译和通过测试，但做错了事"的情况，整个体系没有可靠答案。

具体表现：

1. **测试不等于正确性。** lalitm 的教训最痛：500 多个测试让人觉得安心，但"无论是人还是 AI，都没有创造力去预见未来会遇到的所有边界情况"。他在 vibe-coding 阶段多次发现某个组件的设计是完全错误的，需要彻底重做——**而测试全部通过了**。

2. **Self-evaluation 会失败。** Anthropic #4 发现智能体评估自己的工作时倾向于过度称赞，"即使质量平庸"。所以他们引入了分离的 Evaluator——但 Evaluator 本身也是 LLM，也有同样的倾向。

3. **需求理解偏差无法被机械化检测。** 如果智能体对需求的理解本身就是错的，那所有 lint、所有测试、所有架构检查都会通过——因为它们验证的是"智能体认为的正确"，而不是"用户需要的正确"。

4. **LLM-as-judge 需要校准锚点。** LangChain 评估清单承认：LLM 做评判需要人类标注作为锚点，需要定期重新校准。这意味着评估体系本身的质量上限受人类投入的制约——**但 harness engineering 的目标恰恰是减少人类投入**。

---

## 现有解决方案的局限

### Anthropic 的分离 Evaluator（最接近的尝试）

Sprint 合同机制是目前最精巧的设计：Generator 和 Evaluator 协商"done 长什么样"，然后 Evaluator 用 Playwright MCP 实际操作运行中的应用来验证。

**但它的边界很明确：**
- 只适用于**可交互验证**的场景（前端 UI、API 端点）
- 对于内部逻辑、数据处理管道、算法正确性——Evaluator 能检测到什么？
- 成本不低：V1 Harness 6 小时 $200，其中 Evaluator 占相当比例
- Anthropic 自己承认，Evaluator 的价值取决于任务是否处于模型能力边界——边界内是浪费，边界外才有帮助

### Böckeler 的变异测试建议

Böckeler 提出用变异测试（mutation testing）来检验测试本身的质量——如果随机修改代码后测试仍然通过，说明测试太弱。

方向对，但她自己标注为"昂贵选项"。而且变异测试验证的是**测试覆盖的逻辑是否被真正测试**，它仍然无法回答"测试覆盖的逻辑是否是用户需要的逻辑"。

### Feedback Flywheel（最务实的方向）

Rahul Garg 的反馈飞轮也许是目前最务实的答案：不追求一次性解决，而是建立持续学习的闭环——观察失败 → 诊断根因 → 系统性修复 → 衡量改善 → 迭代。

这承认了一个事实：**完美的前置评估可能不存在，但持续的后置修正可以逐步收敛**。

但飞轮的前提是**失败可以被观察到**。对于那些"看起来成功了但其实做错了"的情况（lalitm 的设计决策拖延、Anthropic 的 self-eval 过度称赞），失败可能在很久之后才浮出水面。

---

## 为什么这个问题这么难

从控制论视角看（借用 Böckeler 的 Ashby 定律）：

> 调节器必须至少拥有与被调节系统同等的多样性。

LLM 能生成几乎任何东西——它的输出多样性极高。要可靠地验证这个输出，验证器的能力至少要和生成器一样强。

**这就是循环论证：** 你需要一个和 LLM 一样聪明的系统来验证 LLM 的输出。如果你有这样的系统，为什么不直接用它来生成？

Anthropic 的分离 Evaluator 本质上是用另一个 LLM 来评估一个 LLM。这在边界情况下有帮助（两个 LLM 犯同样错误的概率低于一个），但不是根本解法。

---

## 对 Harness Engineering 适用范围的推论

如果行为验证问题没有通用解法，那 harness engineering 的适用范围就不是"所有软件开发"，而是有条件的：

| 条件 | Harness Engineering 可靠度 | 例子 |
|------|--------------------------|------|
| 需求明确 + 可测试 | **高** | API 实现、数据管道、CRUD |
| 需求明确 + 不可测试 | **中** | UI 设计、用户体验 |
| 需求模糊 + 可测试 | **中** | 探索性原型 |
| 需求模糊 + 不可测试 | **低** | 架构设计、产品决策、安全审计 |

lalitm 的经验完美验证了这个分类：AI 在 well-constrained 的任务上卓越（测试编写、重构、API 实现），在需要判断力的任务上失败（架构决策、API 设计、性能优化）。

---

## 开放问题

1. **评估的评估问题：** Meta-Harness 自动搜索依赖评估函数，但评估函数本身的质量谁来评估？这是一个无限回归。

2. **人类抽检的可扩展性：** 如果最终答案是人类审查，那 harness engineering 的["吞吐量优先"理念](../concepts/05-throughput-changes-merge.md)（概念 5）就受到人类注意力的硬约束。Ralph 实验中的 Critic Hat 是一个折中——但它仍然是 LLM。

3. **对抗性评估：** 能否用一个专门设计来找错的 LLM（红队）来评估另一个 LLM 的输出？这接近 Anthropic 的 GAN 启发架构，但系统性的对抗性评估框架还没有人提出。

4. **形式化验证的边界：** 对于某些领域（密码学、协议、数学证明），形式化验证可以提供确定性保证。但软件工程的绝大多数场景不适用形式化方法。

5. **"足够好"的标准：** 也许问题不是"如何完美评估"，而是"什么程度的评估对什么类型的任务足够好"。但这个标准本身就需要判断力——又回到了人类。

---

## 我的判断

评估问题不会被某个技术突破一次性解决。它更可能沿着三条路径渐进改善：

1. **工具链的纵深**：从 lint → 变异测试 → 属性测试 → 形式化片段——不断扩大计算性传感器的覆盖范围
2. **对抗性架构**：从单智能体 → Evaluator 分离 → 红蓝对抗 → 多模型交叉验证——通过冗余降低系统性偏差
3. **人类的精准介入**：从全量审查 → 抽检 → 关键节点审查 → 基于异常检测的定向审查——让人类只在最需要的地方出现

Böckeler 说得对："好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方。"

**评估，就是那个"最重要的地方"。**