Agent 系列（三）：Harness Engineering

Harness Engineering

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering，AI 工程的重心，正在从 “怎么把话说对”，转向 “怎么把系统搭对”。

过去两年，AI 行业最热的词几乎一直在变。先是 Prompt Engineering，后来是 RAG、Agent、Context Engineering。每一次新概念出现，大家都会很自然地把注意力放在模型本身：怎么提问、怎么喂数据、怎么让模型更聪明。

但到了今天，真正成熟的团队，已经开始把目光转向模型外部，原因并不复杂，模型确实越来越强了，可一旦它开始承担 长链路任务、调用工具、连续执行、反复验证并最终交付结果 ，问题就不再只是它会不会，而变成了系统能不能托得住它。这也是 Harness Engineering 开始被频繁提起的背景。

2026 年 2 月，OpenAI 连续发布关于 Codex 的几篇技术文章，明确把 “harness” 放到了 Agent 工程的中心位置：他们关注的重点，已经不只是模型怎么写代码，而是如何围绕 Agent 设计环境、接口、知识结构和反馈回路，让它能够长期、稳定、可靠地完成真实工程任务。

当 AI 开始真正 “干活”，我们需要的不再是更好的 “鞭子”，而是一套可靠的 “缰绳”。

一、Harness Engineering 是怎么来的

这个概念最早由 HashiCorp 联合创始人、Terraform 作者 Mitchell Hashimoto 在 2025 年底的博客中率先提出。他提到：

Agent 在实际任务中总会反复犯同一类错误，于是建议 “每当 Agent 犯错，就花时间工程化一个机制，确保它永远不再犯同样错误“

这就是 “Engineer the harness” 的核心想法。

2026 年 2 月，OpenAI 把这一理念推向高潮。他们发布 《Harness engineering: leveraging Codex in an agent-first world》 ，并分享了一个极具代表性的真实案例：

一个最初只有 3 人、后来扩展到 7 人的小团队，从空 Git 仓库起步，完全禁止人工手写一行代码，用 Codex Agent 在大约 5 个月内构建出一个供数百内部用户使用的 Beta 产品，生成近 100 万行代码、约 1500 个 PR，人均日处理 3.5 个 PR，整体效率提升约 10 倍。

这件事像一记重锤，彻底点燃了行业讨论：AI 工程正在从 “调模型” 走向 “搭系统”。

二、Harness Engineering 到底是什么

通俗来说，Harness Engineering 就是围绕 AI Agent 搭建一整套 “可执行、可验证、可约束、可迭代” 的外层运行系统。

这里的 “Harness” 可以理解为驾驭/缰绳，它不是一段 Prompt，也不是单个工作流，而是给 Agent 量身定制的 “工作轨道”：

• • 模型负责思考和决策；
• • Harness 负责把思考变成稳定执行，它决定 Agent 能访问什么、能调用什么、能走到哪一步、什么时候停下、出了错怎么回退、结果如何校验。

一句话总结：Prompt 解决 说什么，Context 解决看什么，Harness 解决怎么干。它把模型偶尔爆发的能力，变成可以 持续复用、规模化交付 的生产力。

模型是 CPU，Harness 才是真正的操作系统。

三、Harness Engineering 与其他 Engineering 的核心区别

为了更好理解，我把三者放在一起对比：

• • Prompt Engineering（2022-2024 主流）主要优化单次交互的质量，重点是 “一句提示词该怎么写，模型才更容易给出想要的结果”
• • Context Engineering（2025 年前后兴起）则动态构建知识、记忆、RAG，解决 “模型看什么” 的问题，减少幻觉、提高检索命中率
• • Harness Engineering（当前阶段）重点构建整个运行环境，解决 “模型怎么把长链路任务稳定做完” 的系统级问题。

前两者主要关注模型的输入，而 Harness 关注模型的生存环境。当任务从 “一次生成” 变成 “长期自主执行” 时，Prompt 和 Context 就明显不够用了；这正是 Harness 诞生的根本原因。

四、Harness Engineering 的核心原理与落地实践

Harness Engineering 的底层逻辑并不复杂，它的关键不在于继续优化提示词，也不在于单纯扩展上下文，而是在模型之外搭建一套能够支撑 Agent 持续执行的运行体系。OpenAI 与 Anthropic 的实践都表明，随着 AI 从单轮生成走向长链路执行，工程重点已经从 **“让模型回答得更好” ** 转向 “让 Agent 在明确目标、真实反馈和稳定约束下持续完成任务” 。在这套体系中，人承担目标定义、边界设定、结果审查与最终负责的职责，Agent 负责具体执行与迭代修正，系统则提供知识承载、状态反馈与运行约束，三者共同构成稳定交付的基础。

这套方法成立的前提，是将知识、反馈与约束全面系统化。仓库不再只是代码存放位置，而是 Agent 的主要知识来源；代码、文档、规范、架构说明和历史经验，需要以结构化、可引用、可维护的方式沉淀下来，AGENTS.md 正是在这一背景下发挥入口作用。与此同时，自动测试、CI/CD、日志、监控和可观测性不再只是辅助工程手段，而是 Agent 判断结果、修正路径和形成闭环的必要条件。真正关键的规则，也不能停留在提示层面，而应写入 Lint、CI 检查、权限控制和回滚机制之中，使系统具备刚性约束能力，避免执行过程过度依赖模型的“记住”与“自觉”。

在实际落地中，Harness 的建设通常围绕几项核心工作展开：

• • 任务边界和终止条件需要预先定义清楚，避免 Agent 在模糊目标下持续试错；
• • 知识应从临时上下文中抽离出来，沉淀为版本化、可追踪的仓库资产；
• • 工具接口需要面向模型设计，使参数、返回结果与异常信息足够清晰；
• • 运行环境也应尽可能对 Agent 可见，让日志、测试结果与界面状态能够被读取和利用

对小团队而言，更可行的方式不是一次性搭建庞大平台，而是从最小闭环起步，先生成初始脚手架与 AGENTS.md，再补齐测试、CI 与规则约束，在持续清理冗余代码和过期上下文的过程中，逐步把 Harness 生长出来。

`Agent Harness` 系统架构示意图

`Observation、Context、Memory、Actions` 等核心层级闭环

五、Harness Engineering 真正改变的是什么？

Harness Engineering 真正改变的，是人和 AI 在工程系统里的分工。

过去，工程师的主要价值体现在直接产出上：写代码、改 Bug、调接口、补文档、查日志。而在 Agent 逐渐进入执行链路之后，人的价值开始明显上移。人不再亲手完成所有动作，而是负责更高杠杆的部分：定义目标、设计边界、组织知识、制定规范、安排工具、设置检查点、处理例外情况，并最终对结果负责。

这其实和软件工程历史上的很多变化很像。真正拉开差距的，往往不是谁能更快写出一个功能，而是谁更早把测试、发布、监控、规范和平台能力做成系统。今天，AI 工程也正在进入同样的阶段。未来团队之间的差距，会越来越多地体现在 Harness 上。

底层模型能力会越来越趋同，大家都能用强模型、做 RAG、搭 Agent。最后拼的，只能是外层系统谁更扎实：知识组织是否清晰、接口是否适合模型、验证链路是否完整、治理机制是否成熟 。谁先完成从 “调模型” 到 “搭系统” 的转变，谁就能把 Agent 从 “演示玩具” 变成真实生产力。

总结

过去大家总爱问：这个模型强不强？接下来，更值得问的问题是：这套系统，能不能让模型稳定把事做完？前一个问题决定能力上限，后一个问题决定交付下限。

Harness Engineering 的真正价值，就在于把模型偶尔爆发的能力，变成一种可重复、可验证、可规模化的交付能力。它不是在教 AI 怎么更会回答，而是给 AI 铺一条能把事情做完的轨道。当 AI 开始从“会说”走向“会做”，真正决定结果的，往往已经不是模型本身，而是你给它搭了一套什么样的外部系统。AI 开始真正干活了，工程方法也该升级了。当 AI 开始真正干活，决定成败的，往往是我们给它准备的 “缰绳” 够不够结实。