不写一行代码，7个人造出百万行产品——Harness Engineering 正在重塑软件工程

5 个月后，这个仓库里出现了约 100 万行代码、1500 个合并请求（PR），以及一个拥有数百名真实用户的内部 Beta 产品。

但这些代码里，没有一行是人类手写的。

你可能会以为他们的秘密武器是"更强的 AI 模型"，或者"更精妙的提示词"。

都不是。

负责这个项目的工程师 Ryan Lopopolo 事后说了一句话，在整个技术圈传开了：

"Agents aren't hard; the Harness is hard." （Agent 不难，难的是 Harness。）

Harness，原意是"马具"——缰绳、马鞍、护具，一整套让马能被骑手控制的装备。Ryan 用它来指代 AI Agent 周围的一整套系统：约束规则、自动检测、反馈机制、错误修复流程……不是 AI 本身，而是 AI "住"的那个环境。

这个概念，后来被叫做 Harness Engineering（驾驭工程）。

痛点：光有聪明的 AI，远远不够

AI（大语言模型）本质上是一个超级模式匹配器。它很强——写代码、翻译、整理信息的速度和质量经常让人惊叹。但它也不可靠——不"理解"自己在说什么，会编造事实、犯逻辑错误、在你没注意的地方埋下隐患。

这两个特点，在"一问一答"的聊天场景下问题不大。你全程盯着，犯错了马上就能发现。

但现在情况变了。

2025 年以来，AI 的使用方式正在从"聊天"转向"自主执行任务的 Agent"。你跟 AI 说"帮我把这个功能开发出来"——它会自己去读代码、写代码、运行测试、修 bug、提交修改……整个过程可能持续几个小时，中间你完全不介入。

一个会犯错的东西，自主运行几个小时，中间没人盯着——你觉得会发生什么？

2025 年 7 月，一个被广泛报道的案例：一个 AI 编程助手无视了代码冻结指令，绕过了安全策略，最终删除了一个生产数据库。AI 在技术上"成功完成了任务"——但它完全不理解自己做的事情意味着什么。

行业数据显示，大约 80%-90% 的 AI Agent 项目没能进入生产环境。不是因为 AI 不够聪明，而是因为没有人搭好它"干活的环境"。

打个比方：你招了一个实习生，知识渊博，干活速度是普通人 10 倍。但他不知道什么不该碰——不知道生产环境和测试环境的区别，不知道某些文件绝对不能删，不知道改了代码要先跑测试再提交。 如果你把他扔进公司，什么规矩都不定，什么检查流程都没有——他大概率一周内把项目搞崩。 不是因为他蠢，是因为没人给他搭好工作环境。

AI Agent 就是这个实习生。而 Harness Engineering 要解决的，就是怎么给这个实习生搭一个不翻车的工作环境。

演进：从「怎么说」到「搭什么环境」

Harness Engineering 不是凭空冒出来的。它是 AI 使用方式演进的第三个阶段。

第一阶段：Prompt Engineering——「怎么跟 AI 说话」（2022-2024）

2022 年底 ChatGPT 横空出世，所有人都在研究：怎么跟 AI 说话，才能让它给出更好的回答？

核心思路：精心设计提示词，让 AI 的输出更符合需求。

• ❌ 普通提示词："帮我写一封邮件。"
• ✅ 精心设计的提示词："我是产品经理，需要给工程团队写邮件，说明本周需求变更原因。语气专业不生硬，200 字以内。"

但 Prompt Engineering 有一个根本性局限：它只解决了"单次交互"的问题。你精心写了一条提示词，AI 给了一个好回答——然后呢？如果你要让 AI 自主完成一个 20 步的任务，你总不能给每一步都写一条提示词吧？

第二阶段：Context Engineering——「给 AI 看什么资料」（2025）

2025 年 6 月，Shopify CEO Tobi Lütke 公开说他更喜欢用"Context Engineering"这个词。Andrej Karpathy 也表示赞同，定义它为"把恰好正确的信息，在恰好正确的时刻，以恰好正确的格式，填进 AI 的上下文窗口"。

核心洞察：光写好指令不够，你还得给 AI 看对资料。

通过 RAG（检索增强生成）给 AI 提供最新文档，管理对话历史，在正确时机提供正确背景信息。

但即使给了 AI 正确的资料，它依然可能跑偏——资料告诉了它"应该做什么"，但没有告诉它"绝对不能做什么"。没有检查机制，没有行为边界，没有"做错了自动报警"的系统。

第三阶段：Harness Engineering——「搭好整个工作环境」（2026）

2026 年初，HashiCorp 联合创始人、Terraform 创造者 Mitchell Hashimoto 在他的博客上发表了一篇文章，其中有一段话被广泛引用：

"每次发现 Agent 犯了一个错误，你就花时间设计一个方案，让 Agent 再也不会犯同样的错误。"

这才是 Harness Engineering 的核心理念——不只是给 AI 好的指令，不只是给 AI 对的资料，而是搭建一整套系统——约束、验证、反馈、纠错——让 AI 在里面安全、可靠、持续地干活。

注意：三者是嵌套关系，不是替代关系。 Harness Engineering 包含 Context Engineering，Context Engineering 包含 Prompt Engineering。你还是要写好提示词，还是要管好上下文——但仅仅做到这两点，在 Agent 时代已经不够了。

拆解：Harness 的四大支柱

根据 OpenAI Codex 团队的实践和业界总结，一个 Harness 通常由四根支柱组成：

支柱一：约束（Constrain）——给 AI 画红线

AI 哪些事绝对不能做？

AI Agent 能做的事情越多，它能闯的祸也越大。约束的作用，就是在 AI 开始工作之前，先画好红线：

• 权限控制：AI 只能读写特定的文件和目录，不能碰核心配置
• 操作限制：AI 不能执行删除操作，不能直接操作生产环境的数据库
• 架构边界：AI 生成的代码必须遵守项目的分层结构——OpenAI Codex 团队规定，代码依赖只能按固定方向流动：类型定义 → 配置 → 数据层 → 业务逻辑 → 运行时 → 界面，不能反向依赖

这些规则不是写在文档里"建议遵守"，而是硬编码在系统里强制执行。AI 试图违反时，操作直接被拒绝。

支柱二：告知（Inform）——给 AI 递正确的资料

AI 需要知道什么才能正确地干活？

最典型的实践是 AGENTS.md——一份放在项目根目录下、专门给 AI Agent 读的"项目须知"。AI 开始工作前会先读这个文件。

一个简化的 AGENTS.md 长这样：

## 项目概述 

• TypeScript Web 应用，包管理器用 pnpm

常用命令

• 安装依赖：pnpm install
• 运行测试：pnpm test
• 构建项目：pnpm build

代码规范

• TypeScript 严格模式
• 单引号，不加分号

绝对禁止

• 不允许提交 API 密钥
• 不允许使用 var

OpenAI Codex 团队特别强调：AGENTS.md 要精简。把所有规则塞进一个巨大文档，AI 反而被信息淹没。他们的做法是分层——根目录放基础规则，各子目录放特定领域规则，AI 在某目录工作时向上查找叠加。

支柱三：验证（Verify）——自动检查 AI 的产出

AI 做完了，结果对不对？

你不知道。所以你让机器来检查：

• Linter：自动扫描代码是否符合格式规范、命名约定
• 类型检查：确认数据类型是否匹配
• 单元测试：针对每个功能模块运行预设用例
• 构建验证：整个项目编译一遍，确认没有语法错误
• 结构测试（OpenAI 创新）：验证代码架构是否合规，比如"业务逻辑层不能直接调用界面层代码"

所有检查全部自动化。AI 每提交一次修改，检查自动跑一遍。通过了才能合并，没通过就打回去。

支柱四：纠正（Correct）——错了就自动修

检查出了错误，然后呢？

仅仅检查出错误不够。Harness Engineering 的关键创新在于：把错误信息自动反馈给 AI，让它自行修复。

这构成了一个闭环：

AI 生成代码 → 自动检查 → 发现错误 → 错误信息传回 AI → AI 修复 → 再次检查 → 通过 → 合并

OpenAI Codex 团队做了一个聪明的设计：Linter 报告错误时，不只说"这行有错"，而是在错误信息里直接嵌入修复指引：

错误：文件超过 500 行限制。 

修复方法：将此文件拆分为多个模块，每个模块负责独立功能。
参考：查看 src/services/ 目录下的文件组织方式。

这段文字被自动注入 AI 上下文，AI 读完就知道怎么修——不需要人类介入。

但这只是一半。另一半更重要：纠正 Harness 本身。

回到 Mitchell Hashimoto 的那句话：AI 犯了新类型的错误？不是批评 AI，而是更新 AGENTS.md、增加 Linter 规则、或写新的结构测试——让这个错误在系统层面不可能再次发生。

OpenAI 甚至专门跑了一批"垃圾清理 Agent"——定期扫描整个代码库，检查文档是否和实际代码一致，确保 Harness 本身不会"腐化"。

说白了，Harness Engineering 的本质不新——它就是软件工程里"持续改进"的老思想，只不过管理对象从"人类程序员"变成了"AI Agent"。底层逻辑一模一样，只是"工人"换了。

爆点：OpenAI 实验的反常识发现

OpenAI Codex 团队的实验数据已经够震撼了——3 人起步、5 个月、100 万行、1500 个 PR、零手写代码。

但更反常识的是：团队从 3 人扩展到 7 人时，人均效率不降反升。

这在传统软件开发中几乎不可能——通常人越多，沟通成本越高，效率越低（Brooks 法则：向延期的项目加人只会让它更延期）。但在 Harness Engineering 模式下，新加入的工程师不需要"学代码"，他们需要学的是"怎么设计 Harness"——而 Harness 的规则是显式的、可共享的、可复用的。

这 7 个工程师的日常工作已经不是"写代码"了：

• 设计架构约束，确保 AI 生成的代码不会乱长
• 编写和维护 Linter 规则，自动拦截常见错误
• 更新 AGENTS.md，把新发现的"坑"记录下来
• 审查 AI 提交的 Pull Request，确认方向正确
• 处理 AI 搞不定的边界情况

他们从"代码的作者"变成了"AI 工作环境的设计师"。

另一个爆点来自 LangChain 2026 年 3 月的报告《The Anatomy of an Agent Harness》：仅仅是给同一个大语言模型换上一套更精巧的 Harness 架构，它在 Terminal Bench 2.0 上的表现直接起飞——不换模型，只换环境，性能暴涨。

这印证了 Harness Engineering 的核心论点：不优化模型，优化模型运行的环境。

优缺点与适用场景

适合的场景：

• 编程领域：代码有明确对错标准（能编译、能通过测试、不破坏架构），天然适合自动化验证
• 数据处理：ETL 流程、数据清洗等有确定性输出的任务
• 测试自动化：用例设计、回归测试、覆盖率检测

不适合的场景：

• 创意性工作：文案、设计等"什么算好"本身就主观
• 战略决策：涉及模糊判断、商业直觉的领域
• 安全敏感场景：Harness 本身的正确性谁来保证？

关键风险：

• Harness 设计不当可能比没有 Harness 更糟——错误的约束会让 AI 在"合法"的框架内做出更隐蔽的错误
• Harness 的维护成本：规则库需要持续更新，否则会"腐化"
• 随着 AI 模型能力提升，某些 Harness 规则可能变得冗余——但哪些该删、哪些该留，判断成本不低

你已经在做 Harness Engineering 了

你可能在想：这些听起来都是程序员的事，跟我有什么关系？

其实你可能已经在做了——

• 如果你用过 Claude Code，你可能写过 CLAUDE.md 文件，告诉 Claude 项目规则
• 如果你用过 Cursor 或 GitHub Copilot，你可能设置过"用中文注释""不要引入新依赖"
• 即使你完全不写代码——如果你在 ChatGPT 里设了"自定义指令"，设定了角色、语气和输出格式——你也已经在做最基础的 Harness Engineering 了

这些，就是 Harness 的雏形。而 Harness Engineering 告诉你的是：这不仅仅是"设置一些偏好"，这是一种系统性的方法论——你可以通过约束、告知、验证、纠正这四个支柱，把一个"时好时坏的 AI 助手"变成一个"稳定可依赖的工具"。

总结

回到那句话——

"Agent 不难，难的是 Harness。"

翻译成日常语言：AI 已经够聪明了。现在的问题不是让它更聪明，而是怎么让它稳定地聪明。

• Prompt Engineering 教你怎么跟 AI 说话
• Context Engineering 教你给 AI 看什么资料
• Harness Engineering 教你搭什么样的环境，让 AI 在里面安全、可靠、持续地干活

AI 时代，最值钱的能力可能不是"会用 AI"——而是会给 AI 搭脚手架。

— 完 —