Harness Engineering（驾驭工程）到底是什么
2026 年如果你还在聊 Prompt Engineering，基本等于 2023 年聊"AI 能写诗"。不是 Prompt Engineering 过时了，而是行业已经往前走了两步。第三步叫 Harness Engineering。
这篇文章用我能找到的资料，把这个概念讲清楚。
这个词怎么来的
Harness Engineering 的引爆点是两件事：
-
Mitchell Hashimoto（HashiCorp 联合创始人，Terraform 之父）在 2026 年 2 月发了一篇博客，第一次系统性地提出这个概念。他的原话很朴素：
"每次发现 AI Agent 犯了一个错误，你就花时间设计一个方案，让 Agent 再也不会犯同样的错误。"
-
OpenAI Codex 团队 在同月发表了技术博客《Harness Engineering: Leveraging Codex in an Agent-First World》，披露了一个实验：7 个工程师，5 个月，用 AI Agent 生成超过 100 万行生产级代码------整个过程中没有人直接写代码。他们做的事不是"写提示词"，而是设计了一套让 Agent 可靠工作的系统。
此后这个概念迅速在硅谷和中国 AI 工程圈扩散开。腾讯、字节、百度都在 2026 年上半年的技术分享中提到了 Harness Engineering。
Harness 的字面意思，恰好说明了一切
Harness 英文原意是"马具"------缰绳、马鞍、护具。
这个比喻非常精准：
- 大模型 = 马：强大、有潜力，但不可控、会跑偏
- Harness = 马具：约束方向、提供反馈、保护人和马
- 人类工程师 = 骑手：明确意图、设定边界、调节缰绳的松紧
你不是在"驯服"模型（那叫 fine-tuning），而是在给它配上一套好用的马具。这套马具的设计和迭代，就是 Harness Engineering。
核心公式
智能体 = 大模型 + Harness这个公式来自 OpenAI 的 Viv Trivedi。他用一个实验证明了它的力量：同一个模型，只换 Harness，在 Terminal Bench 2.0 上从 Top 30 直接跳到 Top 5。
这意味着什么？选对模型当然重要，但在 Agent 工程化阶段，Harness 的优劣造成的差距，可能比模型本身的差距更大。
一个平庸模型配上精良的 Harness，可能比一个顶级模型配上糟糕的 Harness 好用得多。
Prompt Engineering → Context Engineering → Harness Engineering
很多人问 Harness Engineering 是不是就是"高级提示词工程"？不是，它和 Prompt Engineering 是不同层级的问题：
| 阶段 | 核心问题 | 角色 |
|---|---|---|
| Prompt Engineering | 怎么跟模型说话？ | 用户精心措辞 |
| Context Engineering | 模型应该看到什么？ | Builder 管理知识库、记忆、工具 |
| Harness Engineering | 整个环境应该如何运作？ | 设计约束、反馈回路、验证、治理 |
Harness Engineering 不关心你怎么写 prompt，它关心的是：prompt 写错了之后，系统怎么发现并纠正？Agent 拿到错误指令时，能不能被安全地拦下来？Agent 重复犯错时，怎么确保它不会再犯？
这是工程问题，不是语言问题。
四大支柱
根据 OpenAI Codex 团队的实践，Harness Engineering 有四个核心维度：
1. 约束（Constrain）------ 画红线
Agent 能做什么、不能做什么，必须明确。包括：
- 文件系统访问权限（哪些目录只读、哪些可写）
- 命令执行权限（能否装包、能否查生产库）
- 架构边界（不能把业务逻辑写在基础设施层）
- 操作上限（同时改多少个文件需要人工确认）
约束不是为了限制 Agent，而是为了让 Agent 在安全范围内获得最大自由度。
2. 告知（Inform）------ 喂对资料
Agent 需要知道它工作的上下文。这不是塞一个 prompt 就完事，而是一套分层文档体系：
CLAUDE.md/AGENTS.md：项目全局规则- 模块级 README：技术选型和设计决策
- API 文档和 Schema：接口契约
- 架构决策记录（ADR）：为什么这么设计
好的告知策略 = 让 Agent 不需要靠猜测来写代码。
3. 验证（Verify）------ 自动检查
Agent 写的代码必须经过自动验证管道：
- Linter（ESLint、 Ruff）
- 类型检查（TypeScript strict mode、mypy）
- 单元测试、集成测试
- 结构测试：Harness Engineering 特有的概念------不是测逻辑，而是测"文件结构是否符合团队约定"
OpenAI 的实验里，每条 Agent 提交的代码都会经过 200+ 条自动检查规则。通不过的代码不允许合入。
4. 纠正（Correct）------ 错误闭环
这是 Harness Engineering 最核心的部分。当 Agent 犯错时，不是简单 fix bug，而是：
- 分析根本原因（是上下文缺失？约束不足？验证遗漏？）
- 补充规则到 Harness 体系
- 确保该错误不会再次发生
Mitchell Hashimoto 的原话值得再引用一次："每次发现 Agent 犯了一个错误，你就花时间设计一个方案，让 Agent 再也不会犯同样的错误。"
成熟度模型：H0 → H3
Harness Engineering 有成熟度分级，方便团队评估自己的水平：
| 级别 | 描述 | 特征 |
|---|---|---|
| H0 | 原始模型 | 没有 Harness，直接把任务 prompt 塞给模型 |
| H1 | 基础约束 | 有规则文件（AGENTS.md）、基础 prompt 模板 |
| H2 | 结构化治理 | 持久化上下文、确定性检查（lint/test）、人工审批门禁 |
| H3 | 自适应闭环 | 自主学习回路、对抗性 review、自动检测知识偏移 |
大部分团队在 H1→H2 的过渡期。能做到 H3 的团队目前极少，但这是目标方向。
真实案例：OpenAI 的 100 万行实验
前面提到的 OpenAI 实验是了解 Harness Engineering 最好的窗口：
- 7 个人，5 个月 ，生成 100 万+ 行生产级代码
- 全程无人工直接编写
- 核心工作不是写代码，而是设计 Harness ：
- 写规则文件告诉 Agent 架构规范
- 配验证管道自动检查质量
- 设计反馈机制让 Agent 从错误中学习
- 生成的代码包含完整的前后端、数据库迁移、测试、CI/CD 配置
他们说了一句话很有冲击力："我们的工作不是写代码，是设计一个系统，让写代码这件事变成这个系统的副产品。"
对于普通开发者意味着什么
如果你还没接触 Harness Engineering，可以从最简单的事情开始：
- 写一份项目规则文件 （
CLAUDE.md或AGENTS.md），告诉 AI 你的技术栈、编码规范、架构约定 - 配好验证管道，让 AI 写的代码跑不过 lint 就合不进来
- 记录 Agent 犯过的错，每次犯错就往规则文件里加一条约束
- 不要完全信任 AI 的输出，信任你的验证系统
Harness Engineering 的本质，是把"信任"从模型转向系统。你不需要相信一个黑盒每次都能做对，你只需要相信------如果它做错了，系统会拦住它。
写在最后
Harness Engineering 的火爆，反映了一个行业的共识转移：AI 工程化的瓶颈不再是模型能力，而是围绕模型的基础设施。
三年前大家都在问"哪个模型最强"；现在更值得问的问题是"我该怎么给这个模型配一套好用的 Harness"。
工具迭代很快，这个领域三个月后可能又有新概念。但"人类掌舵，智能体执行"这个方向，大概率不会变。
参考资料：Mitchell Hashimoto 博客、OpenAI Codex Engineering Blog、arXiv 2605.13357、O'Reilly / Addy Osmani Agent Harness Engineering、腾讯云/阿里云开发者社区 Harness 专题。
------ 小饼干