评估是房间里的大象：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 的机械化执行（概念 3）和 HumanLayer 的背压杠杆都在这一层运作良好。
第二层：架构适应度验证（中等）
Fitness Functions 可以检测架构漂移：依赖方向、模块边界、性能 SLO。但这里开始出现裂缝：
- Inside the Scaffold 发现 13 个脚手架中，上下文压缩有 7 种策略、状态管理有多种模式——哪种在什么场景下更好，没有共识
- Meta-Harness 论文能自动搜索最优 Harness，但前提是有可靠的评估函数——评估函数本身怎么评估？
第三层：行为正确性验证（最弱——大象所在）
这是整个体系的软肋。核心矛盾：
背压机制只能捕获结构性和回归性错误。 对于”代码能编译和通过测试，但做错了事”的情况，整个体系没有可靠答案。
具体表现：
-
测试不等于正确性。 lalitm 的教训最痛：500 多个测试让人觉得安心，但”无论是人还是 AI，都没有创造力去预见未来会遇到的所有边界情况”。他在 vibe-coding 阶段多次发现某个组件的设计是完全错误的，需要彻底重做——而测试全部通过了。
-
Self-evaluation 会失败。 Anthropic #4 发现智能体评估自己的工作时倾向于过度称赞，“即使质量平庸”。所以他们引入了分离的 Evaluator——但 Evaluator 本身也是 LLM，也有同样的倾向。
-
需求理解偏差无法被机械化检测。 如果智能体对需求的理解本身就是错的，那所有 lint、所有测试、所有架构检查都会通过——因为它们验证的是”智能体认为的正确”，而不是”用户需要的正确”。
-
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 设计、性能优化）。
开放问题
-
评估的评估问题： Meta-Harness 自动搜索依赖评估函数，但评估函数本身的质量谁来评估？这是一个无限回归。
-
人类抽检的可扩展性： 如果最终答案是人类审查，那 harness engineering 的”吞吐量优先”理念（概念 5）就受到人类注意力的硬约束。Ralph 实验中的 Critic Hat 是一个折中——但它仍然是 LLM。
-
对抗性评估： 能否用一个专门设计来找错的 LLM（红队）来评估另一个 LLM 的输出？这接近 Anthropic 的 GAN 启发架构，但系统性的对抗性评估框架还没有人提出。
-
形式化验证的边界： 对于某些领域（密码学、协议、数学证明），形式化验证可以提供确定性保证。但软件工程的绝大多数场景不适用形式化方法。
-
“足够好”的标准： 也许问题不是”如何完美评估”，而是”什么程度的评估对什么类型的任务足够好”。但这个标准本身就需要判断力——又回到了人类。
我的判断
评估问题不会被某个技术突破一次性解决。它更可能沿着三条路径渐进改善：
- 工具链的纵深：从 lint → 变异测试 → 属性测试 → 形式化片段——不断扩大计算性传感器的覆盖范围
- 对抗性架构：从单智能体 → Evaluator 分离 → 红蓝对抗 → 多模型交叉验证——通过冗余降低系统性偏差
- 人类的精准介入：从全量审查 → 抽检 → 关键节点审查 → 基于异常检测的定向审查——让人类只在最需要的地方出现
Böckeler 说得对：“好的 harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方。”
评估，就是那个”最重要的地方”。