# 驭缰工程的隐秘叙事：15 篇文章不会告诉你的那个故事

> 基于 15 篇核心文章、11 篇翻译、5 篇独立思考的跨文章综合分析
> 日期：2026-04-14
> 作者：Rainman
> 注：文中所有数量均为写作时点（2026-04-14）快照，此后文库持续扩容；现况见 [references/articles.md](../references/articles.md)

---

## 开场：一个不该被忽略的细节

2026 年 2 月，OpenAI 发布了一篇博文：3 个工程师，5 个月，从空仓库到 100 万行代码，零手写。人均每天合并 3.5 个 PR，单次运行 6 小时以上，效率是手工编码的十分之一时间。

这个故事被当作 Harness Engineering 的起源反复引用。它太完美了——完美到我们可能忽略了一个细节：

**如果 AI 写代码已经这么可靠，为什么在接下来两个月里，又出现了 14 篇文章讨论它的不可靠？**

Fowler 的控制论升级、Anthropic 的三智能体架构、LangChain 的评估清单、Stanford 的自动搜索论文、Huawei 的源代码分类法、一个人的坦诚复盘——每一篇都在 OpenAI 的乐观叙事上添加了一块拼图。当你把这些拼图拼在一起，浮现的全貌和起点的故事有显著不同。

本文基于对 15 篇核心文章的深度阅读、11 篇翻译和 5 篇独立思考的跨文章分析。它不是摘要集——你不会在这里找到"文章 1 说了什么，文章 2 说了什么"。它讲的是**这些文章拼在一起之后才能看到的那个故事**——一个从"约束模型"到"与模型共演化"的范式转移叙事，以及这场转移中暴露出的结构性裂缝。

这个故事有五个主题：Harness 的定义如何从直觉演化为控制论系统；四个学派如何对"瓶颈在哪"给出截然不同的回答；Harness 为什么有生命周期并与模型循环依赖；行为验证为什么是整个体系的阿喀琉斯之踵；以及人类角色在七篇文章中如何渐次消解。理解这些张力，比掌握任何一个具体技术方案都更重要——因为它们决定了你在什么条件下可以信任这个范式，在什么条件下必须保持警觉。

要理解这个故事，先要知道故事的主角到底是什么。

---

## 一、主角登场：Harness 到底是什么

Harness（驭缰）不是一个稳定的概念。在两个月内，它的定义经历了三次进化：

| 阶段 | 来源 | 定义 | 本质 |
|------|------|------|------|
| 比喻期 | OpenAI（2026.02） | 六大概念：仓库即记录系统、地图而非手册、机械化执行…… | 工程直觉 |
| 解剖期 | LangChain（2026.03） | Agent = Model + Harness；Harness = 模型之外的一切代码、配置和执行逻辑 | 精确边界 |
| 系统期 | Fowler/Böckeler（2026.04） | Guides × Sensors + 计算性/推理性 2×2 矩阵 + Ashby 必要多样性定律 | 控制论框架 |

理解这个演化过程，比记住任何一个定义都更有价值。

**OpenAI 给了直觉。** 他们说：工程师不再写代码，而是设计约束。AGENTS.md 是导航地图，linter 是不变量守护者，仓库是唯一的真相来源。这些概念好用，但模糊——"怎么设计好的约束？"没有系统性回答。

**LangChain 给了解剖刀。** 他们把 Harness 拆成组件清单：System Prompts、Tools、Skills、MCP、沙箱、编排逻辑、Hooks。更重要的是，他们发现了一个不安的事实：模型会 **overfit 到特定 Harness**——Terminal Bench 2.0 的数据显示，纯 Harness 优化可以把排名从 Top 30 拉到 Top 5。这意味着 Harness 不是可选的外挂，而是智能体能力的一部分。

**Böckeler 给了系统框架。** 她用控制论重新组织了这些零件：引导器（Guides）在行动前引导，传感器（Sensors）在行动后反馈；计算性控制确定、便宜、每次提交都跑，推理性控制概率、昂贵、选择性运行。单独用任何一种都不行——只有反馈意味着反复犯同样的错误，只有前馈意味着不知道规则是否在生效。

她还引入了 Ashby 必要多样性定律：**调节器必须至少拥有与被调节系统同等的多样性。** 直觉版本是：一家餐厅如果给你一本 1000 页的菜单，你不知道怎么选。但如果主厨帮你精选了 10 道菜——他用自己的多样性（品味、经验、食材判断）削减了你面对的多样性。

对 Harness Engineering 来说，LLM 能生成几乎任何东西——多样性极高。选定拓扑结构（API 服务？事件处理器？数据仪表板？）就是在削减多样性。**约束越严，多样性越低，Harness 越可行。** 这不是限制自由，而是让自由成为可能。

定义清楚了。但谁在设计这些 Harness？他们对"瓶颈在哪"的回答完全不同。

---

## 二、四个学派：同一个问题，四种答案

15 篇文章表面上在讨论同一件事，实际上分属四个学派。它们不是互相竞争——它们作用在不同层次上，但这个层次结构此前没有人讲清楚。

| 学派 | 代表文章 | 核心主张 | 瓶颈在哪 | 作用层次 |
|------|---------|---------|---------|---------|
| **约束派** | OpenAI、HumanLayer | 更多约束 = 更多自主性 | 解空间太大 | 战术（当前模型） |
| **控制论派** | Fowler/Böckeler | 前馈-反馈闭环设计 | 控制回路失衡 | 方法论 |
| **架构派** | Anthropic #4、#7 | 更好的架构 = 可扩展 | 单体设计 | 战略（跨代际） |
| **怀疑派** | YDD | 也许在解错问题 | 瓶颈不在编码 | 元层（值不值得） |

**约束派怎么看？** OpenAI 说多加 linter，HumanLayer 说调好六个杠杆。金句是："The model is probably fine. It's just a skill issue."——模型没问题，是你不会用。他们的哲学是战术性的：在当前模型能力范围内，用约束把智能体的行为空间缩小到可接受的范围。

场景：你让智能体实现一个 REST API，它生成了一个能用的实现但没有遵守团队的分层约定。约束派的解法：添加一条 lint 规则检查依赖方向 + 在 AGENTS.md 中写明分层约定。问题解决了——至少对这类错误来说。

**控制论派怎么看？** Böckeler 说不是加多加少的问题，而是前馈和反馈是否形成了闭环。她用 Ashby 定律论证：调节器的多样性必须匹配被调节系统。光有 linter（反馈）没用，你还需要 AGENTS.md（前馈）；光有 AGENTS.md 也没用，你还需要传感器验证它是否生效。**控制论派实际上是约束派的升级——从"加约束"升级到"设计控制回路"。**

场景：同一个 REST API 任务。控制论派不只添加 lint 规则，还会追问：你的 AGENTS.md（前馈引导器）和 lint 规则（反馈传感器）是否对齐？有没有引导器承诺的东西传感器检测不到？有没有传感器检查的东西引导器没有提过？闭环的完整性比单个规则的正确性更重要。

**架构派怎么看？** Anthropic 不满足于设计一个好 Harness。他们追问：如果 Harness 编码的假设会随模型升级而过时，那为什么不把 Harness 本身变成可替换的基础设施？他们的三智能体架构（Planner + Generator + Evaluator）不是一个 Harness，而是一个**生产 Harness 的系统**。到了 Managed Agents 阶段，他们更进一步：Session、Harness、Sandbox 三个虚拟化组件独立部署，Harness 是牲畜而非宠物——随时可以替换。

场景：同一个 REST API 任务，但规模是 50 个微服务。架构派不为每个服务设计 Harness，而是设计一个 API 服务的 Harness 模板——引导器和传感器的标准套件——所有 API 服务继承同一套约束。新模型发布后，只更新模板，而非 50 个独立 Harness。

**怀疑派怎么看？** YDD 用约束理论（TOC）分析了效率悖论：AI 编码速度 +98%，但交付周期没有改善。为什么？因为编码可能根本不是瓶颈。PR 体积 +154%，评审时间 +91%——上游加速被下游吃掉了。怀疑派不否认 Harness Engineering 的价值，但它追问一个更根本的问题：**你确定在解对问题吗？**

场景：你花了两周设计 Harness，智能体的 API 实现质量大幅提升。但 PR 从发起到合并仍然需要三天——因为评审跟不上。怀疑派指出：你优化的是工厂产能，但瓶颈在物流。也许应该先投资评审自动化。

**这四个学派的价值不在选哪个，而在同时持有四个视角。** 约束派告诉你今天该做什么，控制论派告诉你怎么系统地做，架构派告诉你怎么让做的东西跨代际存活，怀疑派告诉你什么时候该停下来想想。一个成熟的实践者应该同时问四个问题：约束够不够？闭环通不通？架构能不能演化？方向对不对？

四个学派都在优化 Harness 的设计。但 Harness 不是静态的——它有生命周期。

---

## 三、生老病死：Harness 的生命周期

所有文章都把 Harness 当作一个设计产物来讨论——怎么设计好它。但证据链显示，Harness 有完整的生老病死，保质期大约是**一个模型代际**（3-6 个月）。

| 阶段 | 证据来源 | 描述 |
|------|---------|------|
| 诞生 | OpenAI | 从零设计 AGENTS.md + linter |
| 成长 | Anthropic #4 V1 | 三智能体 + Sprint 合同（$200, 6 小时） |
| 瘦身 | Anthropic #4 V2 | Opus 4.6 上线后去掉 Sprint（$125, 4 小时） |
| 过时 | Anthropic #6 | 为 Sonnet 4.5 设计的 context reset 在 Opus 上变成死重 |
| 被替换 | Anthropic #7 | "Harness 是牲畜，可随时换掉" |

Anthropic 的经验最有说服力。他们在 #4 中发现：**每个 Harness 组件都编码了一个假设**——"模型不能独立做 X"。当 Sonnet 4.5 需要 Sprint 合同来协调 Generator 和 Evaluator 时，这个假设是对的。当 Opus 4.6 发布后，模型自己能做得更好了，Sprint 合同就变成了性能瓶颈。

另一个例子更直观：Anthropic #6 发现，为 Sonnet 4.5 设计的 context reset 机制——补偿模型接近上下文极限时的"提前收尾"倾向——在 Opus 4.5 上完全没有必要，因为新模型天然消除了这种行为。但如果你不去清理这个机制，它就会继续消耗推理预算和延迟，从补偿措施变成性能负担。

这意味着 Harness Engineering 不是一次性设计，而是**持续的园艺工作**——我称之为 **Harness Gardening**。你需要像修剪花园一样维护 Harness：每次模型升级后，压测每个组件是否仍在承重，去掉死重，添加新能力。OpenAI 提出的"垃圾回收智能体"应该也扫描 Harness 本身——这是一个目前没有人做到的延伸。

Rahul Garg 的反馈飞轮提供了园艺的方法论：观察失败 → 诊断根因 → 系统性修复 → 衡量改善 → 迭代。这不是一次性的设计评审，而是持续运转的学习闭环。Harrison Chase 的三层学习框架则指出了维护的焦点：模型层的学习（微调）你管不了，但 Harness 层的学习（提示词和工具演进）和上下文层的学习（运行时记忆）是你的责任。

**"有趣的 Harness 组合空间不会随模型改进而缩小——它会移动。"** Anthropic 的这句话最精准地描述了 Harness 的生命周期本质。新模型不是让 Harness 变得不需要，而是让旧 Harness 过时、新 Harness 成为可能。

Harness 有生命周期，是因为它和模型之间存在一个更深层的纠缠。

---

## 四、共演化陷阱：模型和 Harness 的循环依赖

LangChain 说：模型在 post-training 阶段 overfit 到特定 Harness。Anthropic 说：Harness 编码了对特定模型能力的假设。合在一起，这构成一个**循环依赖**：

```
模型训练时适配 Harness → Harness 为模型量身设计
         ↑                              ↓
         └── 重新设计 Harness ←── 模型升级 → Harness 过时
```

这不是实现细节，而是**结构性的**。

Terminal Bench 2.0 的数据最有冲击力：纯 Harness 优化——不换模型，只调 Harness——可以把排名从 Top 30 拉到 Top 5。反过来说，一个在 Top 5 的系统，换一个不适配的 Harness，可能直接掉到 Top 30。**Harness 不是锦上添花，它是智能体能力的有机组成部分。**

Inside the Scaffold 的 13 个开源智能体分析提供了另一个视角。这些智能体的架构高度多样——工具数量从 0 到 37，上下文压缩有 7 种策略，循环原语有 5 种可组合模式。但底层**能力类别趋同**：读取、搜索、编辑、执行。多样性在表层（实现），不在深层（需求）。这意味着 Harness 的设计空间虽然大，但解空间的结构是收敛的。

这引出了一个令人不安的推论：**跨模型可移植的 Harness 可能是一个幻觉。** 如果 model-harness 耦合是不可避免的，那 Anthropic 的 meta-harness（Session/Harness/Sandbox 解耦）也许不是在"让 Harness 可替换"，而是在**锁定用户到 Anthropic 的接口标准上**。`execute(name, input) → string` 看起来通用，但 session 格式、事件结构、工具调用协议都是 Anthropic 特定的。

更大的图景是：如果一个主流模型导向一个主流 Harness，一个主流 Harness 导向一个主流技术栈，那我们面对的是一个**数字单一栽培**风险。全球 80% 的香蕉是 Cavendish 品种，一种真菌就能威胁整个产业。如果所有人都在 Claude + Claude Code + TypeScript 上构建，一个模型回归就能影响所有人。

共演化意味着 Harness 的设计者需要持续跟踪模型能力的边界。但有一个能力维度，所有模型都做不好。

---

## 五、房间里的大象：行为验证的不可能

这是 15 篇文章共同指向却没有人解决的核心问题。

每一篇都尝试了不同的评估方案：

| 文章 | 评估方案 | 能验证什么 | 不能验证什么 |
|------|---------|----------|------------|
| OpenAI | linter + 结构测试 | 代码结构、风格一致性 | 功能正确性 |
| Fowler/Böckeler | 三维度分类 | 可维护性（强）、架构适应度（中） | **行为正确性（弱）** |
| Anthropic #4 | 分离 Evaluator + Sprint 合同 | 多维度评分 | Self-eval 倾向于过度称赞 |
| LangChain #10 | 五阶段评估体系 | 可度量的成功标准 | 标准本身的完整性 |
| Meta-Harness (Stanford) | 自动搜索最优 Harness | Harness 层面的性能 | 依赖可靠评估函数作为前提 |
| lalitm | 人类审查 + 持续重构 | 设计品味、API 质量 | 不可扩展 |

没有一篇给出了令人信服的答案。Böckeler 最诚实地命名了这个问题：**行为 Harness 是房间里的大象。**

### 三层验证，成熟度递减

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

**第一层：可维护性验证——最成熟。** linter、类型检查、代码覆盖率、ArchUnit。这些是计算性传感器：确定性的、便宜的、每次提交都跑。OpenAI 的机械化执行和 HumanLayer 的背压杠杆都在这一层运作良好。

**第二层：架构适应度验证——中等。** Fitness Functions 可以检测架构漂移。但这里开始出现裂缝：Meta-Harness 论文能自动搜索最优 Harness，但前提是有可靠的评估函数——评估函数本身怎么评估？

**第三层：行为正确性验证——最弱。** 这是整个体系的软肋。核心矛盾可以用四个观察来刻画：

1. **测试不等于正确性。** lalitm 的教训最痛：500 个测试全部通过，但设计是完全错误的。他在 vibe-coding 阶段多次发现组件需要彻底重做——**而测试全部通过了**。测试验证的是"智能体认为的正确"，不是"用户需要的正确"。

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

3. **需求理解偏差无法被机械化检测。** 如果智能体对需求的理解本身就是错的，那所有 lint、所有测试、所有架构检查都会通过。

4. **LLM-as-judge 需要校准锚点。** LangChain 的评估清单承认：LLM 做评判需要人类标注作为锚点。但 Harness Engineering 的目标是减少人类投入——这是一个张力。

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

回到 Ashby 定律：调节器必须至少拥有与被调节系统同等的多样性。LLM 能生成几乎任何东西——输出多样性极高。要可靠验证，验证器的能力至少要和生成器一样强。

**这就是循环论证：** 你需要一个和 LLM 一样聪明的系统来验证 LLM 的输出。如果你有这样的系统，为什么不直接用它来生成？Anthropic 的分离 Evaluator 本质上是用另一个 LLM 来评估一个 LLM——在边界情况下有帮助（两个 LLM 犯同样错误的概率低于一个），但不是根本解法。

### 适用范围矩阵

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

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

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

### 现有解决方案中最接近的尝试

值得单独说说 Anthropic 的分离 Evaluator，因为它是目前最精巧的设计。Sprint 合同机制让 Generator 和 Evaluator 在开始编码前协商"done 长什么样"，然后 Evaluator 用 Playwright MCP 实际操作运行中的应用来验证。

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

Rahul Garg 的反馈飞轮也许是最务实的答案。它不追求一次性解决，而是承认：**完美的前置评估可能不存在，但持续的后置修正可以逐步收敛。** 飞轮的前提是失败可以被观察到——但对于"看起来成功了但其实做错了"的情况（lalitm 的设计决策拖延、Anthropic 的 self-eval 过度称赞），失败可能在很久之后才浮出水面。

如果完美的前置评估不存在，那人类还需要在哪里出现？

---

## 六、消失的人类：从掌舵者到 API 客户

人类的角色在 15 篇文章中渐次消解：

| 文章 | 人类做什么 |
|------|---------|
| OpenAI 原文 | 设计环境 + 拆解任务 + 验证结果 |
| LangChain | 写 AGENTS.md + 配置组件 |
| HumanLayer | 调 6 个杠杆 |
| Anthropic #4 | 写 1-4 句提示词 |
| Anthropic #7 | （文章没提人类） |

趋势很清晰：从"人类设计整个环境"到"人类写几行提示词"再到"人类不出现在叙事中"。Managed Agents 的文章中，"人类掌舵"这个概念**一次都没出现**。

这像极了管理学中从"微观管理"到"OKR 管理"的转变。早期经理盯着每个任务，后来经理只定目标。但 OKR 的前提是下属有自主判断力——**对智能体来说，这个前提是否成立？**

前一节的分析给出了答案：**在行为验证层面，不成立。**

lalitm 的故事是最有力的证据。他经历了两种截然不同的 AI 使用模式：

**模式一：Vibe-coding（一月份）。** 把设计和实现都委派给 AI，自己当管理者。结果是代码库变成了意大利面，测试全过但设计全错，不得不全部推倒重来。这是人类退场的后果。

**模式二：Harness 模式（二月份起）。** 自己做设计、AI 做实现、持续审查和重构。项目成功发布。这是人类回归设计角色的结果。

他的顿悟是：**"AI 是力量倍增器，但倍增的是你的判断力——如果你没有判断力，它倍增的是你的错误。"**

Böckeler 提出了一个更健康的方向："好的 Harness 不应以完全消除人类输入为目标，而应将人类输入引导到最重要的地方。"结合第五节的分析，那个"最重要的地方"就是：**评估**。

"人类掌舵"不应该变成像"客户至上"一样的空洞口号。它应该被具体化为：人类在需求理解、设计审查和行为验证这三个智能体最弱的环节保持在场。不是微观管理每一行代码，而是守住关键判断节点。

那么，效率数据说了什么？人类掌舵真的能带来效率提升吗？

---

## 七、矛盾的数据：精英神话与大规模现实

OpenAI 的数据和大规模遥测数据直接矛盾。

| 数据源 | 个体效率 | 组织效率 |
|--------|---------|---------|
| OpenAI | 3 人 → 100 万行，人均 3.5 PR/天 | 正向 |
| METR RCT 实验 | 客观慢 19%，主观快 20% | 未测 |
| Faros 万人遥测 | PR +98% | DORA 四指标无一改善 |
| lalitm | 250 小时/3 个月完成 | N/A（个人项目） |

注意 METR 数据的诡异之处：**客观慢 19%，主观快 20%**。偏差达 39 个百分点。开发者觉得自己变快了，但实际上变慢了。这和 Anthropic 发现的 self-evaluation 过度称赞异曲同工——不只是 LLM 会自我欺骗，使用 LLM 的人也会。

为什么 OpenAI 的团队能做到个体和组织效率都提升，而大规模数据显示相反？可能的解释有四个：

1. **OpenAI 团队是 outlier。** 他们有最好的模型（内部 Codex）、最好的 Harness（自己设计的）、最好的工程师（3-7 人精英团队）。这不可复制。
2. **零手写代码是关键约束。** 强制所有工作走 Harness，消除了"AI 写一半人改一半"的低效模式。
3. **从空仓库开始。** 没有遗留代码的认知负担。Böckeler 的假说——给遗留代码补 Harness 可能不经济——暗示了这一点。
4. **生存者偏差。** OpenAI 发布的是成功案例。那些用了 Codex 但失败的团队不会写博文。

YDD 用约束理论给出了最深刻的解释：**编码不是瓶颈。** AI 让编码速度飙升，但 PR 体积 +154%、评审时间 +91%——上游加速被下游吃掉了。这就像工厂产能翻倍，但仓库和物流没跟上，货堆在工厂门口。

YDD 的金句一针见血：**"AI 就是今天的 NCX-10"**——约束理论中那台加速了非瓶颈工序的机器，产能提升全部被库存吞噬。

如果把 AI 编码看作一条供应链，情况更清晰：

```
制造业供应链                    AI 代码供应链
─────────                    ──────────
工厂 = 模型                    生产代码
质检 = 背压（lint/测试）         拦截坏代码
仓库 = Session                持久化中间产物
物流 = Harness                编排和路由
零售 = 交付（合并/部署）          最终价值产出
```

**Harness Engineering 目前主要在优化"工厂"和"质检"。** 但 YDD 的数据暗示瓶颈可能在"物流"（PR 评审）和"零售"（交付整合）。Anthropic #7 的 meta-harness 和 OpenAI 的"智能体审查智能体"在试图解决这个问题——方向对了，但解决方案的成熟度还不够。

**我的判断：** 在评估 Harness Engineering 的价值时，不应该拿 OpenAI 做基准，应该拿 YDD 做底线。OpenAI 的数据告诉你天花板在哪，YDD 的数据告诉你没做好会怎样。一个诚实的期望管理是：Harness Engineering 不会自动让你变成 10 倍工程师，但它可以让你在使用 AI 编码时**不变慢**——这在 METR 数据面前已经是一个有意义的成就。而 YDD 的另一个金句更值得记住：**"洗衣机洗衣服，你去读书"**——真正的红利不是速度，而是你省出时间后做了什么。

如果效率提升不是自动的，那什么时候 Harness Engineering 真正有效？

---

## 八、实践者的地图：从理论到你的第一个 Harness

综合前七节的分析，一个分层的实践框架浮出水面。不同规模的团队、不同类型的项目，需要不同级别的 Harness。

### 三级最小可行 Harness

| 级别 | 适用场景 | 必须有 | 建议有 | 不需要 |
|------|---------|--------|--------|--------|
| **L1 个人** | 业余项目、个人开发者 | AGENTS.md（≤60 行）+ lint + 设计先行 + 重构纪律 | 决策日志、术语表 | 多智能体、meta-harness |
| **L2 小团队** | 3-10 人 | L1 + Encoding Team Standards + Feedback Flywheel + CI 集成 | 评估清单、Skills 体系 | 自动化 Harness 搜索 |
| **L3 平台** | 大型组织 | L2 + Harness 模板 + 多环境编排 + meta-harness | 自动化 Harness 优化 | — |

**L1 的核心是 lalitm 的教训：** 有主见的设计 + AI 执行 + 持续审查 + 重构纪律。他说"在脑子里没有代码的脉络时，就不可能和智能体进行有效沟通"——这是个人开发者的最小 Harness 的心理基础。

**L2 的核心是反馈飞轮：** Rahul Garg 的四步闭环（发现模式 → 诊断根因 → 系统性修复 → 衡量改善）把 Harness 从静态文件变成活系统。配合 Encoding Team Standards 的三层渐进路径（口头约定 → 自然语言描述 → 自动化检查），团队可以逐步把隐性知识编码为显性约束。

**L3 的核心是 Böckeler 的 Harness 模板概念：** 企业 80% 的服务可归入几种常见拓扑。为每种拓扑准备好引导器 + 传感器的标准套件，新项目直接继承。这是 Spring Initializr 理念在 AI 时代的延伸。

### 技术选型的隐藏维度：Harnessability

不是所有技术栈都同样适合被 Harness。Java/Spring 在"可驾驭性"上有结构性优势：

- **类型系统 = 免费传感器。** 编译器每次构建都跑，零额外成本。Python 的 mypy 和 TypeScript 是可选的，经常被跳过。
- **ArchUnit = 架构传感器。** 动态语言没有直接等价物。
- **Spring Initializr = 原始 Harness 模板。** 标准化拓扑 + 策划好的依赖 = Ashby 定律所说的多样性削减。
- **约定优于配置 = 解空间压缩。** 智能体面对的不是无限选择，而是框架约束好的有限拓扑。

这不意味着必须用 Java。核心原则是：**在已选的技术栈中，优先使用 AI 训练集覆盖好的惯用法，避免过度 fancy 的写法。** lalitm 发现 AI 的"归一化本能"——总是用"标准方言"——在大多数地方是优点。问题只出在项目核心竞争力所在的部分，那些地方"价值恰恰来自做一些不那么显然的事情"。

### 超越代码：翻译作为 Harness 的验证

如果你觉得 Harness Engineering 只适用于代码，考虑一个反例：翻译。

本仓库在两周内完成了 11 篇翻译（含 2 篇学术论文），总计超过 5 万字。工作流是一个典型的 Harness Engineering 实践：

- **40+ 术语对照表 = Custom Linter。** 不告诉 AI 怎么翻译，而是设置不变量："无论怎么翻，这些术语必须这样处理"——背压而非规定。
- **五轮流水线 = Feedback Flywheel。** 分析 → 翻译 → 审查 → 修订 → 润色——观察失败（审查阶段）→ 诊断根因 → 系统性修复（修订阶段）→ 验证效果。
- **并行分块翻译 = 多智能体协调。** 19K 字论文拆成 5 个 chunk，5 个子智能体并行翻译，通过共享的翻译提示词（包含术语表、语气分析、翻译难点）保持一致性。

**约束 + 反馈 + 分治 + 持久化——核心原理是通用的。** 域可以是代码、文本、设计，任何 AI 智能体需要可靠完成的任务。

### 从反馈飞轮开始，而非从约束开始

很多人读完 OpenAI 的文章后，第一反应是写一个大而全的 AGENTS.md。这是错的。

约束理论告诉我们：先找瓶颈，再投资优化。你的 AI 编码瓶颈在哪，你现在不知道。所以正确的起步姿势是：

**第一周：观察。** 正常使用 AI 编码，但每次发现 AI 犯了一个你不得不手动修复的错误，记录下来。不要修改 Harness，只记录。

**第二周：分类。** 回顾记录，问三个问题：(1) 哪类错误出现频率最高？(2) 哪类错误修复成本最高？(3) 哪类错误可以被 lint 规则或测试自动拦截？频率高 × 成本高 × 可自动化 = 你的第一批 Harness 规则。

**第三周：编码前 3 条规则。** 不是 30 条，是 3 条。写进 AGENTS.md 或者转化为 lint 规则。然后继续观察——反馈飞轮的第一圈就转起来了。

这比一次性设计一个"完美 Harness"有效得多，因为**你的 Harness 是从实际失败中生长出来的**，不是从理论中推演出来的。

### 三条行动总结

1. **审视你今天的 Harness 是什么。** 即使你没有 AGENTS.md，你也有 Harness——你的开发环境配置、IDE 设置、脑子里"我们这里不这么做"的直觉。Böckeler 说人类开发者携带"隐性 Harness"：社会问责感、对复杂性的审美痛感、组织记忆。把它们显式化，写下来，放进仓库。
2. **用反馈飞轮代替完美计划。** 先记录 AI 犯的错，再写规则阻止它。持续迭代比一次性设计更有价值。
3. **在能力边界处保留人类判断。** 用第五节的适用范围矩阵评估你的任务。需求明确 + 可测试的任务放心让 AI 做。需求模糊或不可测试的任务，人类必须守住设计审查。

---

## 九、未完成的革命：三个悬而未决的问题

Harness Engineering 是一场正在发生的范式转移。但它是未完成的。三个核心问题的答案将决定这个领域的走向。

### 问题一：评估的评估

Meta-Harness 论文展示了自动搜索最优 Harness 的可能性。但搜索算法的核心是评估函数——给每个 Harness 候选方案打分。

**那评估函数本身的质量谁来评估？**

这是一个无限回归。你需要一个 meta-评估来评估评估，然后一个 meta-meta-评估来评估 meta-评估……在实践中，这个回归通常终止于人类的判断。

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

### 问题二：共演化的终局

两种可能的未来：

**开放生态。** 标准化接口让 Harness 跨模型可移植。不同模型提供商竞争模型质量，Harness 设计独立于模型选择。MCP 协议是这个方向的尝试。

**围墙花园。** 模型-Harness 捆绑销售。每个提供商优化自己的全栈体验：Anthropic 有 Claude Code，OpenAI 有 Codex。用户选择模型 = 选择 Harness = 选择整个工具链。锁定效应越来越强。

Anthropic #7 的 `execute(name, input) → string` 接口看起来是在推动开放生态，但 session 格式和事件结构是特定的。这像极了早期浏览器战争——每家都说支持标准，但"标准"是自己定义的。

### 问题三：人类的最终形态

从 OpenAI 到 Anthropic #7，人类的角色从操作层掌舵逐步退到商业目标层掌舵。**"人类掌舵"会变成像"客户至上"一样的口号，还是被制度化为具体的评估流程？**

我倾向于后者，理由有三：

第一，**评估是整个体系最弱的环节，而人类是目前唯一能弥补这个环节的力量。** 如果你把 LLM 的输出看作一个概率分布，计算性传感器（lint/测试）只能拦截分布尾部的明显错误，推理性传感器（LLM-as-judge）存在系统性偏差。人类判断力的独特价值在于识别那些"看起来对但其实错了"的输出——这种判断目前没有替代品。

第二，**隐性 Harness 无法被完全显式化。** Böckeler 指出人类开发者携带"隐性 Harness"：社会问责感、对复杂性的审美痛感、组织记忆、"我们这里不这么做"的直觉。智能体不知道哪个规范是承重的、哪个只是习惯。这些隐性知识的作用不是执行——而是在执行前判断该不该做。

第三，**lalitm 的经验表明，人类设计能力的缺失是不可补偿的。** 他在 vibe-coding 月的失败不是因为缺少约束，而是因为没有人在做设计审查。500 个测试全过但设计全错——这个失败模式无法被任何已知的 Harness 组件拦截。

人类的角色不会消失。它会被**重新定义**为三个具体的专业化功能：需求理解的守门人、设计决策的仲裁者、行为验证的最终审查者。

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

---

## 结尾：你的 Harness 是什么？

回到 Böckeler 备忘录中最务实的那个问题：**你今天的 Harness 是什么？**

也许你已经有了一个不自知的 Harness——IDE 配置、代码审查习惯、脑子里"我们这里不这么做"的直觉。把它显式化，就是 Harness Engineering 的第一步。

也许你刚读完 OpenAI 的博文，兴奋地想从零搭建一套完美的约束系统。慢一点。先记录 AI 犯的错，再写规则阻止它——反馈飞轮比完美计划更有价值。

也许你已经是经验丰富的 AI 编码实践者，开始感受到评估的焦虑。那你正站在这个领域最前沿的问题面前。没有人有答案，但至少你在问正确的问题。

15 篇文章、11 篇翻译、5 篇独立思考——这个仓库本身就是一个 Harness。它用渐进式披露组织知识（AGENTS.md），用版本控制追踪演化（git），用跨文章交叉验证（thinking/）来对抗理解偏差。

这也许是 Harness Engineering 最深层的洞见：**不管这个领域怎么演化，"用系统性约束驾驭不确定性"这个工程哲学是永恒的。** 变的是约束的形态——从 linter 到控制论到 meta-harness；不变的是人类在不确定性面前建立秩序的冲动。

你的下一个 Harness，会是什么样的？