Harness Engineering 深度解析：给 AI 装上"操作系统"的时代来了

2026 年，继 Prompt Engineering 和 Context Engineering 之后，AI 工程领域迎来了第三次范式跃迁——Harness Engineering（驾驭工程）。这不仅仅是一个新 buzzword，而是一场从根本上重新定义"人与 AI 如何协作"的工程革命。

---

一、从一个震撼的实验说起

2025 年 8 月，OpenAI 内部启动了一个近乎疯狂的项目：3 名工程师，5 个月时间，全程不许手写一行代码，仅通过引导 AI Agent（Codex），构建一个百万行代码级别的生产级应用。

结果令人震惊：

• 累计合并约 1500 个 Pull Request

• 产出超过 100 万行可运行代码

• 效率达到传统手动开发的 10 倍

• 产品已有数百名真实用户在内测使用

这不是科幻。这是 OpenAI 在 2026 年 2 月发布的官方报告《Harness Engineering: Leveraging Codex in an Agent-First World》中记录的真实案例。报告的核心结论只有一个：

"Early progress was slower than we expected, not because Codex was incapable, but because the environment was underspecified."

早期进展比预期慢，不是因为 AI 不够聪明，而是因为我们没有把"环境"定义好。

这个结论，引出了一个 2026 年 AI 工程界绕不开的公式：

Agent = Model + Harness

模型提供智能，Harness 让智能变得可用。

---

二、什么是 Harness Engineering？

2.1 从"马具"说起

"Harness"这个词，本意是马具——缰绳、鞍具、辔头那一整套让骑手能够驾驭和控制马匹的装备。

这个比喻极其精准：

比喻对象	AI 领域对应	说明
野马	AI 模型（LLM）	拥有强大的原始能力，但方向不定、行为不可预测
马具（Harness）	驾驭系统	约束、引导、纠正——让能力朝正确的方向释放
骑手	工程师	不再亲自"跑"，而是通过 Harness 来驾驭
千里马	AI Agent	模型 + Harness = 可控、可靠的生产力工具

Harness Engineering 不是去改变"马"的基因（模型本身），而是为它设计一套专业的驾驭体系。

2.2 正式定义

Harness Engineering 是设计、构建和维护 AI Agent 运行环境（scaffolding）的工程学科。它涵盖工具、约束、评估、内存管理、权限控制、可观测性和编排等一切"模型之外"的基础设施。

用程序员熟悉的语言类比：

计算机组件	AI 系统对应物
CPU	AI 模型（提供原始算力/推理能力）
RAM	上下文窗口（有限、易失的工作内存）
操作系统	Harness（管理调度资源、提供驱动和环境）
应用程序	AI Agent（运行在 Harness 之上的具体业务逻辑）

谁会拿一颗裸 CPU 跑生产服务？同理，拿一个裸模型跑生产级 Agent，就是把一台没装操作系统的电脑推上了生产线。

---

三、AI 工程范式的三次进化

Harness Engineering 不是凭空冒出来的，它是 AI 工程化走到第三阶段的必然产物。

第一阶段：Prompt Engineering（2023-2024）—— 教 AI 说话

大多数人最熟悉的阶段。写更精确的指令、给示例（few-shot）、Chain-of-Thought 推理链……核心目标是让模型的输出格式和内容符合预期。

解决了什么：让 AI 从"随机输出"变为"按指令输出"。

天花板在哪：提示词太脆了。换个模型版本可能就废了，同一个 prompt 今天好使明天翻车，复杂任务靠堆提示词根本兜不住。

第二阶段：Context Engineering（2024-2025）—— 给 AI 补课

提示词到了极限之后，工程师开始往模型的"视野"里塞信息。RAG（检索增强生成）是代表作——不改模型，让它在回答前先翻一遍你的文档库。

解决了什么：打破模型的知识围墙，让 AI 能获取外部知识。

天花板在哪：光补知识不补纪律。模型拿到了更多信息，照样可能编造事实、越权操作、做到一半就丢了进度、同一个任务给出截然不同的结果。

第三阶段：Harness Engineering（2026-）—— 给 AI 建操作系统

2026 年 2 月 5 日，HashiCorp 联合创始人、Terraform 之父 Mitchell Hashimoto 写了一篇博文，第一次给这个东西正了名：Harness Engineering。

6 天后，OpenAI 发布了那篇刷屏的报告，拿 100 万行代码的实验结果给这个概念盖了章。

三代范式的区别，一张表看明白：

范式	核心问题	做什么	类比
Prompt Engineering	AI 怎么说	写指令、给示例	教野马听口令
Context Engineering	AI 知道什么	RAG、记忆管理	给野马发地图和干粮
Harness Engineering	AI 在什么环境做事	工具、约束、闭环	装缰绳、上马鞍、修赛道

---

四、为什么需要 Harness Engineering？

4.1 数据不会说谎

LangChain 在 Terminal Bench 2.0 上做了一个控制实验：不换底层模型，只改模型之外的部分——更好的上下文文件、结构化输出约束、自验证闭环、工具优化——AI 编程准确率从 52.8% 跳到 66.5%，涨幅达 26 个百分点。部分任务场景更夸张，从 42% 跳到 78%，几乎翻倍。

同一匹马，换一副缰绳，成绩差了一倍。

4.2 R.E.S.T 模型：Agent 系统的四个核心目标

要让 Agent 从"有趣的玩具"变为"可靠的工具"，它必须满足四个核心目标：

4.3 AI 的"七秒记忆"问题

基于 Transformer 架构的 LLM，本质上操作的是一个有限的、线性的 Token 序列。Agent 跑久了上下文越堆越多，性能持续下滑——业内称为 Context Rot（上下文腐化）。就像一个同时处理 50 件事的人，每件都记个大概但没一件记清楚。

Harness Engineering 的核心挑战之一，就是在这个"无限"的外部世界状态与"有限"的 LLM 上下文 Token 之间，建立高效、可靠的双向映射和转化机制。

---

五、Harness Engineering 的三层递进

jimo.studio 将 Mitchell Hashimoto、OpenAI 和 Anthropic 三家的实践拆成了三个递进层次。大多数人卡在第一层，真正的战斗力藏在后两层。

第一层：写规则（被动防御）

Mitchell Hashimoto 对 Harness 有一句经典定义：

"Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."

每次 AI 犯错，就花时间搞一个机制，让它永远不再犯同样的错。

他的开源项目 Ghostty 是这个原则的活标本。打开它的 AGENTS.md，每一行规则背后都是一次真实的翻车记录：AI 编了一个不存在的经历？加一条"禁止编造困境"。AI 乱改不该动的文件？加一条"只改指定文件"。

简单，直接，今天就能动手。但天花板也很明显：规则是被动防御——AI 读到了才管用，读不到就白搭。规则堆到几百行，AI 反而更容易走神。OpenAI 团队对此有句大实话：

"Give Codex a map, not a 1,000-page instruction manual."

给它一张地图就行了，别给一千页说明书。

第二层：造工具（自动化约束）

第一层是"跟 AI 说一声别犯错"。第二层是"造一个工具让机器自动抓它犯没犯错"。

OpenAI 的 Codex 团队把这一层做到了极致。他们发现早期进展慢不是 AI 能力问题，是环境太简陋——AI 缺少完成任务的工具和验证手段。于是他们做了一个决定：给 AI 造工具。

• 让 AI 能启动应用、截屏、驱动浏览器来验证自己写的东西能不能用

• 让 AI 能查日志、看监控指标来判断性能有没有达标

• 让 AI 有一整套本地可观测性栈来自己排查问题

工程师的活儿从"写代码"变成了"让 AI 有能力验证自己的代码"。他们管这叫角色重定义：Human codes → Human steers, Agent executes。人不再写代码，人掌方向盘，Agent 踩油门。

这一层还包括一个关键动作：把架构约束机械化。不靠"跟 AI 说我们用分层架构"，而是造一个 linter，违反分层规则的代码直接报错——连商量的余地都不给。

第二层是投入产出比最高的一步。大多数团队花 3-5 天配好 linter、CI 约束和基本的自动化测试，就能感受到 Agent 输出质量的质变。

第三层：分离评估（结构性分离）

Anthropic 的工程师 Prithvi Rajasekaran 捅破了一层窗户纸：让 AI 自己检查自己的活儿，它永远觉得自己干得不错。

"Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work."

让一个独立裁判变得苛刻，远比让选手自我批评容易得多。

这是结构性偏差。哪怕任务有客观标准（代码能不能跑通），AI 自我打分时依然倾向于放自己一马。

Anthropic 的解法借鉴了"生成-评估分离"的思路：生成和评估必须由不同角色完成。一个 AI 干活（Generator），另一个独立 AI 打分（Evaluator）。Evaluator 不是看 Generator 的"自我报告"，而是拿 Playwright 去实际操作产品——点按钮、截屏、查功能——然后给出评分和具体改进意见。Generator 根据反馈迭代。

一个 4 分钟直出的网页，跟一个经过 15 轮生成-评估迭代的网页，视觉上就不像同一个物种。

---

六、深入理解：Harness Engineering 的七个核心组件

一个成熟的 Harness 不是七件东西简单堆在一起，而是有优先级、有层次的系统工程。

组件 1：Context Engineering（地基）

所有 Harness 的起点。用 CLAUDE.md 或 AGENTS.md 给 Agent 画一张项目地图：架构概览、编码规范、硬性规则。

关键原则：少就是好。 OpenAI 建议核心规则文件控制在 60-100 行。把它当导航表（"想做 X，去看 Y 文件"），不要当百科全书。详细规范丢到 docs/ 目录里按需加载。

一份最小可用的 AGENTS.md 示例：

# MyProject

## 技术栈
Next.js 14 + TypeScript + PostgreSQL + Prisma

## 目录导航
| 想做什么 | 去哪里 |
|---------|--------|
| 改页面 | src/app/ (App Router) |
| 改组件 | src/components/ |
| 改 API | src/lib/api.ts |
| 看规范 | docs/conventions/ |

## 硬性规则（CI 会检查）
- 组件中禁止直接导入 node_modules
- 所有 API 调用走 src/lib/api.ts
- 新功能必须有对应测试文件
- 提交信息格式: feat|fix|refactor: 简要描述

## 运行命令
- 测试: npm test
- 类型检查: tsc --noEmit
- lint: npm run lint

不到 30 行，够了。

组件 2：Architectural Constraints（承重墙）

不指望 Agent 自觉守规矩，用 linter 和结构性测试强制执行。ESLint 的 no-restricted-imports 能禁止组件直接导入数据库模块，自定义脚本能验证分层架构没被破坏。

思路很简单：缩小解空间。 可选方案越少，翻车概率越低。

组件 3：Tools & MCP Servers（工具箱）

Agent 得有趁手的工具。好的 Harness 通过 CLI 封装和 MCP（Model Context Protocol）服务器向 Agent 开放能力。

一个值得记住的数据：Harness.io 的 MCP v2 把工具从 130 多个砍到 11 个，上下文占用从 token 窗口的 26% 降到 1.6%。工具不是多多益善，是精才管用。 优先挑 Agent 有海量训练数据的标准工具——git、npm、docker——别指望它用好你那个没文档的内部 CLI。

组件 4：Sub-agents & Context Firewalls（隔离舱）

Agent 跑久了上下文越堆越多，性能持续下滑——行话叫 Context Rot（上下文腐化）。

处方是拆任务、建防火墙：每个子任务在独立会话中执行，只传结构化结果不传原始对话。Anthropic 的做法是 Initializer Agent 负责规划，Coding Agent 负责执行，中间传的是 feature list 而不是对话记录——这样 Coding Agent 每次启动都是带着清晰指令的"干净大脑"。

组件 5：Hooks & Back-Pressure（哨兵）

在错误扩散前拦住它。pre-commit hooks 做类型检查和 linting，测试运行器每次改动后自动跑，构建验证在部署前兜底。

设计原则只有一条：成功时安静，失败时尖叫。 别把冗长的成功日志灌进 Agent 的上下文——成功只需要一句"PASS"，失败要大声喊出来并且带够调试信息。

组件 6：Self-verification Loops（验收关）

强制 Agent 在说"我做完了"之前验证：跑测试、查构建、对比输出和规格、UI 任务截个屏看看。OpenAI 的做法是在完成度校验环节使用干净的上下文窗口重新注入原始目标——防止 Agent 在长对话中"忘了自己要干什么"然后随便交差。

组件 7：Progress Documentation（黑匣子）

任务超过 30 分钟就得有进度记录：维护一个 progress.md、频繁 commit、用结构化列表而不是随手笔记。Agent 会话崩了、上下文耗尽了，下一个会话看到进度文件就能从断点接上——没有这个，就得从头来。对于跨天的长任务，这是救命的组件。

---

七、Agent 系统如何运作：PPAF 循环

一个完备的 Agent 系统，其核心运行机制可抽象为一个持续循环的四阶段过程：

Harness 在每个环节都扮演着关键角色：

• 感知阶段：Harness 通过上下文管理器，将外部世界和内部记忆"翻译"成 LLM 可理解的结构化 Prompt

• 规划阶段：Harness 通过调用拦截器捕获 LLM 的意图，并将其路由到正确的工具执行器

• 行动阶段：执行过程被严密监控，包括超时、资源配额和错误捕获

• 反思阶段：工具执行结果被反馈汇编器捕获，组装成结构化的"观测结果"，重新注入上下文

---

八、如何开始你的 Harness Engineering 之旅

一篇 Harness Engineering 最佳实践文章给出了一个务实的三阶段路线图：

阶段	投入时间	做什么	预期回报
入门：信息层	1-2 天	写 AGENTS.md + 结构化 docs/ 目录	Agent 输出一致性明显改善
进阶：约束层	3-5 天	配置 linter + CI 架构约束	代码质量可控，减少返工
高阶：自动化层	1-2 周	搭建 Agent 自验证闭环	人工审查量大幅下降

8.1 今天就能做的事

1. 在项目根目录创建 AGENTS.md（或 CLAUDE.md），30 行以内

1. 把架构规范写成 ESLint 规则，而非口头约定

1. 确保每次提交自动跑测试和 lint

1. 让 Agent 在提交 PR 前自己跑一遍测试

8.2 企业视角：警惕 Agent Sprawl

htek.dev 的数据显示，2026 年企业平均跑着 12 个以上 AI Agent，但只有 27% 被正确接入了更大的系统。剩下的 73% 是"影子 Agent"——有工具权限，没人管，没合规，在体系外面野生运行。

这跟 2018-2020 年微服务蔓延一模一样。企业级 Harness 治理需要关注四个维度：

• 注册与准入：新 Agent 上线必须走审批，声明工具权限和资源需求

• 行为审计：跨 Agent 的日志聚合，全链路可追溯

• 成本管控：全局 token 预算分配与实时告警

• 标准化路径：统一的 Harness 模板和护栏策略

---

九、Harness Engineering 的核心设计原则

在构建 Harness 时，需要遵循六大设计原则：

其中 "为删除而建"（Build for Deletion） 是最容易被忽视但至关重要的原则。架构必须高度模块化，因为昨天的智能逻辑明天可能就被一个简单的 Prompt 替代。无法快速移除旧代码的 Harness 将被淘汰。

Rich Sutton 提出的"苦涩的教训"（The Bitter Lesson）在 Harness 领域同样适用：利用通用计算方法的技术，终将击败依赖手工编码人类知识的技术。 不要过度工程化，保持轻量。

---

十、未来展望：Harness Engineer 会是一个新岗位吗？

回头再看 OpenAI 那个实验里的 3 名工程师——他们 5 个月没写过一行产品代码。他们干的是：设计环境、定义约束、搭建反馈闭环、审查合并 Agent 生成的 PR。

这个新角色叫 Harness Engineer。截至 2026 年，这还不是一个被广泛使用的正式头衔——但打开招聘网站搜 "AI infrastructure engineer" 或 "platform engineer + AI agent"，会发现越来越多的岗位描述里出现了这样的要求：设计 Agent 运行环境、构建 AI 工具链和约束体系、建立自动化代码审查流程。

Harness Engineer 需要四样核心能力：

1. 系统工程：分层架构、CI/CD 流水线、容器和沙箱——给 Agent 盖"办公楼"

1. AI 工程化：LLM 的能力边界、Agent 的运行模式、上下文窗口怎么管

1. 系统思维：不是修一个 bug，而是想"怎么让这类 bug 永远消失"

1. 业务翻译：把业务规则变成 Harness 里机器能执行的约束

---

十一、总结

Harness Engineering 标志着 AI 开发从面向模型彻底转向面向系统。未来 AI 应用的竞争，不再是单一模型智能的比拼，而是整个管控体系工程化能力的较量。

三个关键要点值得记住：

1. 模型很重要，但 Harness 往往是决定成败的那一环。 不换模型，只优化 Harness，准确率能从 52.8% 涨到 66.5%。LangChain 通过约束换取自主，排名从第 30 跃升至第 5。

1. 从第一层开始，但不要停在第一层。 写 AGENTS.md 是起点，但真正的战斗力在第二层（自动化约束）和第三层（分离评估）。

1. 为删除而建，保持轻量。 不要过度工程化。模型能力在快速进化，今天的 Harness 组件明天可能就被模型内置能力取代。保持模块化，随时准备替换。

2026 年最厉害的工程师，不是写代码最多的那个，而是给 Agent 造环境造得最好的那个。