夜雨聆风引子：一个让 42% 变成 78% 的实验
2025 年，有一个工程师做了一个看似无聊的实验。
他找了同一个模型，给了同一份数据，写了同一套提示词——只换了一个"运行环境"。结果，AI 的编程成功率从 42% 飙升到 78%。没有换显卡。没有升级模型。没有熬夜调参。只是给 AI 换了一个"壳"。这个"壳"，现在有了一个正式的名字：Harness。围绕它展开的一整套工程实践，正在 2026 年的 AI 圈，掀起一场最静默、却最深远的革命。
第一章：人类是怎么一步步"教不会"AI 写代码的
1.1 第一阶段：我们以为把话说清楚就行了
大模型出来后，所有人面对的第一个问题是：怎么让它听明白我在说什么？
于是 Prompt Engineering 火了。Few-shot、思维链、角色扮演……全是在研究怎么"说话"。本质上是优化一个接口——人类意图到模型输入之间的那一段。工程师的核心工作，就是把指令写得更漂亮、更精准。
这个阶段持续了大约两年。但很快，所有认真用过 AI 写代码的人都发现了一个天花板：Prompt 再好，也无法让 AI 完成需要调用工具、追踪状态、多轮协作的任务。
给你一道题：让 AI 去修复 orders.py 第 47 行的 bug，你可以把提示词写到完美——但如果 AI 根本读不到这个文件、无法运行测试套件、无法验证修复是否有效，它就只能瞎猜。
Prompt 能解决"说清楚"的问题，解决不了"AI 在什么条件下能工作"的问题。
1.2 第二阶段：我们以为给它足够的信息就行了
2025 年，行业进入了一个新的认识层次。
Andrej Karpathy、Shopify CEO Tobi Lütke 等人几乎同时意识到：单条 Prompt 不够用了。模型要可靠地工作，不能只靠一条指令——它需要的是一个持续运转的上下文环境。
相关文件要能读取，历史对话要能记住，工具定义要能随时调用，知识库要能动态检索。模型做出每个决策时所能感知到的全部信息，共同构成了它的"工作现场"。这就是 Context Engineering——上下文工程。工程师的工作从"说清楚"变成了"喂对信息"：RAG 检索让 AI 知道项目内部知识，工具接入让 AI 能操作真实环境，记忆管理让跨会话的连续性成为可能。这个阶段又往前走了一步。但 Context Engineering 依然有盲区。
它能解决"AI 看到什么"的问题，但解决不了"AI 出错了怎么办"和"什么不该让 AI 做"的问题。
1.3 第三阶段：真正的答案是——换系统，不是换模型
到了 2026 年，一批在最前线使用 AI 写代码的工程师得出了一个让行业震动的结论：AI 编码失败，十次有九次，不是 Prompt 的问题，不是上下文的问题，是 AI 运行所在的"系统"本身有问题。
HumanLayer 团队花了一年多时间追踪 AI Agent 的失败模式，观察到了这些共同特征：
AI 忽略人类指令，不经确认就执行危险命令 AI 在简单任务上陷入死循环，自己把自己卡住 AI 进入了错误状态，却没有任何自我纠正的机制 AI 在长任务的中后期，输出质量断崖式下滑 AI 静默失败——代码已经错了，但没有任何信号提示
他们的最终结论是：这不是模型的问题，这是配置的问题。给 AI 换一个更聪明的模型，同样的失败模式照样出现。真正的问题在于：AI 是一个概率系统，它的输出在给定输入下按概率分布变化——这是它强大的根源，也是它不可靠的根源。
要让这个概率系统稳定工作，需要在它周围构建一套确定性系统：约束它的行动空间，验证它的输出质量，在它偏离时及时纠正。
这套确定性系统的设计，就是 Harness Engineering——驾驭工程。
第二章：一个词如何震动整个硅谷
2.1 Mitchell Hashimoto 的一次命名
2026 年 2 月 5 日，HashiCorp 联合创始人、Terraform 之父 Mitchell Hashimoto 在自己的博客里首次正式使用了"harness engineering"这个词。
他的定义很短，但每一个字都值得记住：
每当发现 AI 犯了一个错误，就投入时间设计一个方案，让它永远不再犯同样的错。
这句话背后的思维是反常识的：AI 犯错，大多数人的第一反应是"换个模型试试"或"再调调 Prompt"。Mitchell Hashimoto 的判断是：AI 的每一次失败，都是环境设计不完善的信号。正确的应对不是换模型，而是重新设计它运行的环境本身。
六天后——2 月 11 日——OpenAI 发布官方报告，标题直接用了这个词：《Harness Engineering: Leveraging Codex in an Agent-First World》。再过了几天，软件工程领域最具影响力的思想家之一 Martin Fowler 也加入讨论。
一个月之内，"Harness Engineering"从一篇博客文章变成了整个硅谷开发者社区里被提及最多的词。
2.2 三个实验，把一个道理钉死在所有人心里
实验一：OpenAI，零行手写代码，造出百万行系统
2026 年 2 月，OpenAI 披露了一个数据：
3 名工程师，5 个月，零行手写代码，用 AI Agent（Codex）生成了约 100 万行代码，合并了 1500 个 Pull Request。
项目后来扩展到 7 人，效率不降反升——因为更多人把时间投入到了 Harness 的设计和迭代中。
OpenAI 工程师 Ryan Lopopolo 的总结流传很广：“Agent 不难，Harness 才难。”
模型能力够用了，真正的瓶颈在于：怎么设计一套控制系统，让 Agent 不跑偏、不死循环、不在关键决策上犯傻。
实验二：LangChain，不换模型，分数从第 30 名冲到前 5
LangChain 在编码 Agent 权威基准测试 Terminal Bench 2.0 上，排名原本在 30 名开外。
他们只做了一件事：没有更换底层模型，没有微调——仅仅优化了 Agent 运行的外部环境。
具体是四件事：加了任务前的自我检查清单，加了启动时的目录结构扫描，加了循环编辑检测，加了一套"规划用强模型、执行用弱模型"的推理预算策略。
结果：得分从 52.8% 飙升至 66.5%，排名跃升至前 5。
一个模型的分数提升幅度，相当于十几轮模型升级的效果之和。
实验三：一个格式改变，得分翻十倍
安全研究员 Can Boluk 更绝。他只做了一件事——把 AI 写代码时的"编辑格式"从传统 patch 改为自己设计的 Hashline 格式。
一个格式的改变，换来基准得分从 6.7% 到 68.3%——等于十个模型升级。
三个实验指向同一个结论：AI 编码效果的好坏，最大变量不是模型有多强，而是 AI 被放在了什么样的系统环境里。
第三章：Harness 是什么——一个操作系统式的类比
如果要用一句话解释 Harness Engineering：
Agent = Model + Harness。模型是大脑，Harness 是操作系统。
没有操作系统的 CPU，再强也跑不起来。没有 Harness 的 AI 模型，再强也只能算一匹野马——有力气，没方向，闯进瓷器店就是灾难。
用计算机系统做个类比：
过去两年，整个行业一直在升级"CPU"——更大的模型、更长的上下文、更强的推理能力。但操作系统呢？大多数人的实践，还停留在 DOS 时代。
第四章：驾驭 AI 的六根支柱
4.1 支柱一：给它正确的上下文，而不是塞给它一本书
问题在哪：
很多团队会给 AI 一个巨大的 AGENTS.md 文件，把所有项目规范一股脑写进去，以为"给得越多，AI 越懂"。
错了。苏黎世联邦理工学院测试了 138 个类似文件后发现：AI 生成的详细规范反而让 AI 表现变差，成本增加 20%，消耗的推理资源增加 15%，问题解决率没有任何提升。
上下文是稀缺资源，塞得太满，AI 的注意力会被稀释，过时的规则还会误导它。
真正的做法：
每个工作区接独立的日志和链路追踪，AI 能自查报错，不需要人工翻译日志 AI 能直接连浏览器，看真实的 UI 渲染效果，自主判断页面是否正确 规范分层：顶层文件只是目录，详细内容分散在对应模块里，用到时才出现 文档总量控制在 60 行以内，只写最普适的规则，不堆清单
简单说：少即是多。 好的上下文架构，是让 AI 自己找到它需要的信息，而不是把所有信息都塞进它眼前。
4.2 支柱二：用规则约束它，而不是放任它自由发挥
问题在哪：
AI 有时会生成与项目整体风格不一致的代码，或者在不同模块之间建立隐式的依赖关系——这些对人类来说是"常识"，对 AI 来说可能是盲区。
真正的做法：
OpenAI Codex 团队设计了一套严格的分层架构规则：Types → Config → Repo → Service → Runtime → UI，每一层只能依赖下层。
看起来像"过度设计"，但对 AI 来说恰恰是救命稻草——AI 依赖结构化的线索来理解代码，强制的分层规则比隐式的团队默契更可靠。约束解决方案的空间，换取可预期的输出质量。
4.3 支柱三：让它自己发现错误，而不是等你去 review
问题在哪：
AI 写完一段代码后，没有内置的验证机制。它可能写了看似正确但跑不通的代码，可能改了 A 模块却影响了 B 模块——这些错误不会被自动发现，直到人类 review 时才暴露。
真正的做法：
在 AI 每次停止后，自动运行类型检查和代码格式化工具。如果成功，什么都不输出，不污染上下文窗口；如果失败，只把错误信息反馈给 AI，让它自己修复。HumanLayer 在生产环境中的经验是：这是对 Harness 质量回报最高的单项投入。 它把"大概能用"变成了"可证明能用"。
4.4 支柱四：用子代理隔离它，而不是让它在混乱里工作
问题在哪：
AI 的上下文窗口就像计算机内存——塞得越满，推理质量下降越快。研究证明，上下文越长、干扰信号越多，AI 的实际表现反而越差。
真正的做法：
引入子代理（Sub-agent）架构。把复杂任务拆解成多个独立的子任务，每个子代理在全新的、高相关性的、小规模的上下文中运行，执行完后只向主代理汇报压缩后的结论。中间的所有操作——文件读取、工具调用、搜索输出——全部隔离在子代理内部，不污染主代理的思考空间。主代理负责规划和协调，用强模型；子代理负责执行具体任务，用弱模型——效率更高，成本更低。
4.5 支柱五：持续清理混乱，而不是等问题爆发
问题在哪：
AI 长期运行后，系统会积累"熵"——文档过时、约定被打破、上下文窗口越来越偏离真实状态。AI 的行为开始漂移，出错概率越来越高。
真正的做法：
三个手段同时用：
垃圾回收代理。 OpenAI 部署了一个定期运行的 AI，专门扫描那些已经过时、不再反映真实代码的文档，主动发起修复 Pull Request——持续小额偿还技术债务，而不是等债务爆发。
做梦机制。 Claude Code 引入了类似人类睡眠中记忆巩固的机制：当系统闲置超过 24 小时且积累了 5 个以上会话时，触发离线 AI，扫描近期对话日志，将碎片化的交互信息蒸馏为结构化知识，写入长期记忆文件。
工具膨胀治理。 不要给 AI 接太多工具——MCP 服务器接太多，上下文窗口会被工具描述填满，AI 反而会"降智"。只保留最常用的两三个，关闭其余的。
4.6 支柱六：让 Harness 可以拆卸，而不是和模型绑定
问题在哪：如果 Harness 和底层模型深度耦合，一旦出现更好的新模型，整个系统就要推倒重建。
真正的做法：从设计之初就做到模型无关。Model 可以替换，Harness 必须持久。 这样无论哪家模型更强，都可以直接切换，不需要重新设计整套控制系统。
第五章：三个故事告诉你 Harness 落地长什么样
故事一：医疗器械公司的遗留系统改造
Stryker 是一家医疗器械公司，有一个 15 年历史、数百万行的遗留代码库，没人敢动——改一行可能引发监管合规问题。
引入 Harness Engineering 后，AI Agent 在 3 个月内完成了一个核心财务模块的现代化重构。所有代码由 AI 生成，人类工程师只负责设计 Harness、审批结果、监控质量。
故事二：Stripe 的千人 PR 工厂
Stripe 内部有一套叫 Minions 的系统，每周自动合并超过 1000 个 Pull Request——从任务创建到代码审查，全程不需要工程师介入。Harness 接管了测试执行、CI 验证、代码风格合规和文档更新。人类工程师只需要批准最终变更。
故事三：LangChain 的排名逆袭
这个故事前面说过，但值得再说一遍：一个排名第 30 的产品，不换模型，只换 Harness，5 周后冲到前 5。
第六章：这不是工具的革命，是职业的革命
6.1 工程师这个职业，正在被重新定义
过去，工程师的价值在于"写代码"。代码是产出单元，能力高低看"能写多少行好代码"。未来，工程师的核心价值转向四个方向：
- 设计规则
：AI 什么能做、什么不能做 - 设计系统
：搭建让 AI 在约束下稳定工作的环境 - 设计验证
：建立可证明 AI 输出正确性的反馈机制 - 设计干预
：当 AI 行为超出边界时，如何介入和纠偏
这不是一个微小的调整。这是一次职业范式的彻底转移。
6.2 历史不会重复，但会押韵
18 世纪，瓦特发明离心调速器时，没有让蒸汽机"更像人"——而是让它更可靠。
2010 年代，Kubernetes 让容器化应用大规模协同运行时，没有让容器"更智能"——而是让它更可管理。Harness Engineering，没有试图让 AI “更像人”——而是让它更可预期。三次技术革命背后，是同一个底层逻辑：
人类用确定性的系统，驾驭不确定性的工具。
6.3 当所有人都在追逐模型，我们选择研究环境
2023 年，所有人在比较：GPT-4 和 Claude 3 谁更强？
2026 年，一批真正在一线使用 AI 的工程师给出了另一个答案：
模型只是引擎，Harness 才是整车。
Prompt Engineering 优化的是提问方式，Context Engineering 优化的是信息供给，而 Harness Engineering 给出的是一个真正可以被信任去做实际工作的系统。
未来的 AI 工程，属于那些懂得设计 Harness 的人。
他们不再写代码，而是写规则；不再调试函数，而是调试系统；不再追求单次输出的完美，而是追求可持续、可预期的稳定表现。
这或许是软件工程史上最深刻的一次范式转移——从"人写代码"到"人设计让 AI 写代码的系统"。
