驭缰工程的隐秘叙事：15 篇文章不会告诉你的那个故事
基于 15 篇核心文章、11 篇翻译、5 篇独立思考的跨文章综合分析 日期：2026-04-14 作者：Rainman
开场：一个不该被忽略的细节
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，但前提是有可靠的评估函数——评估函数本身怎么评估？
第三层：行为正确性验证——最弱。 这是整个体系的软肋。核心矛盾可以用四个观察来刻画：
-
测试不等于正确性。 lalitm 的教训最痛：500 个测试全部通过，但设计是完全错误的。他在 vibe-coding 阶段多次发现组件需要彻底重做——而测试全部通过了。测试验证的是”智能体认为的正确”，不是”用户需要的正确”。
-
Self-evaluation 会失败。 Anthropic 发现智能体评估自己的工作时倾向于过度称赞，“即使质量平庸”。所以他们引入了分离的 Evaluator——但 Evaluator 本身也是 LLM。
-
需求理解偏差无法被机械化检测。 如果智能体对需求的理解本身就是错的，那所有 lint、所有测试、所有架构检查都会通过。
-
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 的团队能做到个体和组织效率都提升，而大规模数据显示相反？可能的解释有四个：
- OpenAI 团队是 outlier。 他们有最好的模型（内部 Codex）、最好的 Harness（自己设计的）、最好的工程师（3-7 人精英团队）。这不可复制。
- 零手写代码是关键约束。 强制所有工作走 Harness，消除了”AI 写一半人改一半”的低效模式。
- 从空仓库开始。 没有遗留代码的认知负担。Böckeler 的假说——给遗留代码补 Harness 可能不经济——暗示了这一点。
- 生存者偏差。 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 是从实际失败中生长出来的，不是从理论中推演出来的。
三条行动总结
- 审视你今天的 Harness 是什么。 即使你没有 AGENTS.md，你也有 Harness——你的开发环境配置、IDE 设置、脑子里”我们这里不这么做”的直觉。Böckeler 说人类开发者携带”隐性 Harness”：社会问责感、对复杂性的审美痛感、组织记忆。把它们显式化，写下来，放进仓库。
- 用反馈飞轮代替完美计划。 先记录 AI 犯的错，再写规则阻止它。持续迭代比一次性设计更有价值。
- 在能力边界处保留人类判断。 用第五节的适用范围矩阵评估你的任务。需求明确 + 可测试的任务放心让 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，会是什么样的？