Harness Engineering 读后感：AI工程的第三次范式转移
一句话总结
Harness Engineering = 为 Agent 构建「办公室」，而不是继续优化「邮件措辞」
背景：从三代工程范式看演变
| 时代 | 核心问题 | 关注点 | 类比 |
|---|---|---|---|
| Prompt Engineering (2022-2024) | 怎么跟模型说话 | 措辞、格式、few-shot、CoT | 写一封完美的邮件 |
| Context Engineering (2025) | 怎么把关键信息摆到模型眼前 | RAG、对话历史、工具定义 | 给邮件附上所有需要的附件 |
| Harness Engineering (2026) | 怎么让模型在真实环境里稳定做事 | 工作流、约束、反馈循环、工具链 | 架构整个办公室 |
三代并不是取代关系，而是抽象层次一层层向外扩展。任务越接近真实生产，后两者的重要性就越高。
核心论点：Agents aren’t hard; the Harness is hard
这是 OpenAI Codex 团队 Ryan Lopopolo 在用 GPT-5 agent 构建了 100 万行代码、1500 个 PR 之后的真实总结。
实验数据：
- 同一模型、同一数据、同一 prompt，仅改变运行时环境（shell），编程 benchmark 成功率从 42% 跳到 78%
- Anthropic 的实验：简单 prompt-and-run 方案产出 broken product（$9），结构化的迭代管理环境产出可用游戏（$200）
Cost difference is irrelevant. Capability difference is everything.
作为 Agent 开发工程师的感悟
1. 我们以前在优化错误的层级
花了大量时间在 prompt 模板、few-shot 示例、角色扮演上。但真正决定成败的，是** agent 运行环境的设计**。
做过 agent 开发的人都有类似经历：demo 惊艳，production 崩盘。原因是 demo 是「完美条件的单次交互」，而生产是「真实环境的持续运转」。
2. 约束 paradoxically 增加生产力
Cursor 团队在推进 “Self-Driving Codebases” 时发现：当模型能力足够强时，它会在死胡同和 nonsense 方案上浪费大量 token。一个设计良好的 Harness 通过提供清晰的边界和有限的高质量工具，强制 agent 更快收敛到正确答案。
你不是在限制 agent，你是在给它一条通往成功的窄路。
3. 架构约束必须用 linter 强制，而不是用 prompt 请求
OpenAI 团队学到的硬规则之一：** Architectural constraints are enforced by linters, not prompts.**
不要跟 agent 说「请遵循单例模式」，而是构建一个 linter 来强制单例模式。不要请求，请约束。
4. Agent 失败时，Harness 才是问题所在
OpenAI 团队有一条原则：If a PR requires significant human intervention, the agent is not the problem — the Harness is.
这是思维模式的核心转变。当 agent 犯错时，我们不是去批评它，而是去改进它的运行环境，让这个错误再也不可能发生。这正是 Mitchell Hashimoto 对 Harness Engineering 的定义：
“Every time you discover an agent has made a mistake, you take the time to engineer a solution so that it can never make that mistake again.”
5. Anthropic 的关键发现：模型无法可靠评估自己的输出
这直接指向了 GAN 式的架构：分离的 Generator 和 Evaluator agent。这也是为什么可靠的 Harness 需要独立的验证层。
实践要点：Harness 的五大支柱（来自 OpenAI + Stripe）
- 单一真实来源：repository 是 agent 唯一的信息源，不假设任何外部知识
- Agent-readable 代码：不仅是人类可读，还需要能被 agent 理解（清晰的注释、结构）
- Linter 强制架构约束：规则不是 prompt，是代码
- 增量授权：Harness 必须有阶段和关卡，agent 不能一上来就拥有全部权限
- Two-strike 规则（Stripe）：agent 第一次修复失败，立即 escalation 给人类，不浪费循环
对我当前项目的启发
结合我们的 iUX 迪元健康项目：
- 工具调用层：需要更严格的 tool definition 和 error handling harness
- 多步骤工作流：需要引入阶段性 gate 和反馈循环
- 代码生成场景：agent 输出的代码需要有 linter 强制约束，而不是靠 prompt 提醒
Harness Engineering 不是一个工具，是一种工程哲学的升级——从「调教模型」到「构建系统」。