一、什么是 Harness Engineering？
Harness Engineering（驾驭工程）是围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。
它不优化模型本身，而是优化模型运行的环境。核心哲学八个字：人类掌舵，智能体执行（Human Steer, Agent Execute） 。
这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月 5 日首次提出，六天后 OpenAI 在百万行代码实验报告中正式采用这一术语，随后 Martin Fowler 撰文深度分析，一个月内成为开发者社区的高频词。
这句话的潜台词是：**Agent 的每一次失败，都是环境设计不完善的信号。**正确的回应不是换一个更强的模型，而是重新设计它运行的环境。
二、AI 工程范式的三次跃迁
要理解驾驭工程为何重要，需要先看清楚我们是怎么一步步走到这里的。
当大家还只是做聊天记忆人的时候呢，提示词的作用很大。因为任务短 链路短 状态少很多问题确实靠把话说明白就可以解决了。但后来agent开始火了，模型不只是要回答问题而是要进到真实的环境里面做事情，它要多轮对话 ，调浏览器 剪辑码 输入库，这些工具还要在多个步骤之间传递中间结果，还要根据web的反馈不断修计计划。那这个时候问题就变了，系统面对的已经不是一次回答对不对，而是整条链路的任务能不能跑通。 比如如果你不是简单的问一句，帮我总结一下这篇文章而是让他做一个更真实的任务，比如说帮我分析这份虚拟文档、找出潜在风险、结合客户的意见给出改进建议、再生成一版发给产品经理的返回稿，你会发现这已经完全不是一句提示词就能解决的问题了。 他至少要拿到当前的虚拟文档,历史的评论记录,行为规范,当前目标已经分析出来中间结论,属实的对象是谁,语气应该怎么调,所以模型未必是知道的，系统必须在合适的时机把正确的信息送进去
但是上下文工程其实也不只是终点，因为后来大家又发现了一个更麻烦的问题，就算信息给对了模型也不一定能稳定的执行的正确，它可能计划做的很好但是执行跑偏了，调了工具但理解错了反馈结果在一个很长的链路里已经慢慢偏行了，但是系统却没有发现，当模型开始连续行动的时候谁来监督它约束它和纠偏它呢？
Harness =Agent - Model。
翻译成人话就是在一个Agent的系统里面除了模型本身以外几乎所有能决定它能不能稳定交付的东西都可以算进Harness
| 范式 | 核心问题 | 优化对象 | 交互模式 |
|---|---|---|---|
| 提示词工程 | 怎么把话说清楚 | Prompt 的措辞、格式、示例 | 一问一答 |
| 上下文工程 | 怎么给 AI 喂信息 | 文档、代码片段、历史对话 | 信息注入 → 生成 |
| 驾驭工程 | 怎么让 Agent 可靠工作 | 约束、反馈回路、控制系统 | 人类掌舵，Agent 执行 |
三、Agent 常见失败模式
Anthropic 工程师在长时间运行 Agent 的过程中，总结了三种典型的翻车姿势
失败模式 1：试图一步到位（One-shotting）
Agent 倾向于在一个会话里把所有功能都做完。结果是上下文窗口耗尽，留下一堆没有文档的半成品代码，下一个会话启动时只能花大量时间猜测之前发生了什么。
失败模式 2：过早宣布胜利
在项目后期，当部分功能已经完成后，Agent 会环顾四周，看到已有进展就直接宣布任务完成——即使还有大量功能未实现。
失败模式 3：过早标记功能完成
在没有明确提示的情况下，Agent 写完代码就标记为完成，却没有做端到端测试。单元测试或 curl 命令通过了不代表功能真正可用。
此外，智能体还有一个危险特性：它非常擅长模式复制。代码库里有什么模式，它就忠实地复制并放大——包括坏模式和架构漂移。这意味着不加约束的 Agent 会以惊人的速度积累技术债务。
四、驾驭工程的四大护栏
综合 OpenAI、Anthropic、LangChain 和 Martin Fowler 的实践，Harness 可以归纳为四个核心组件，即四根"护栏"：
护栏一：上下文工程（Context Engineering）——新员工手册
就像给新员工一本详细的工作手册，AGENTS.md 是 AI 智能体进入代码仓库时看到的第一份指南。但这不是一本静态的 1000 页说明书——上下文是稀缺资源，过多的指导反而会挤掉任务、代码和相关文档的空间，变成陈旧规则的坟场。
更好的做法是：提供一个稳定、小巧的入口点，然后教 Agent 根据当前任务按需检索和拉取更多的上下文。
护栏二：架构约束（Architecture Constraints）——缰绳
OpenAI 团队建立了严格的层级依赖模型：
Types → Config → Repo → Service → Runtime → UI
下层不能反向依赖上层。所有架构规则被编码为自定义 Linter 规则，违反即 CI 阻止合并——无论代码是人写的还是 AI 写的。
有个关键细节：Linter 的错误信息本身也是上下文工程。它不只说你违反了规则 X，而是解释为什么这个规则存在、正确做法是什么，这样 Agent 读到错误后就能自我理解并修正，不需要人类介入。
护栏三：反馈循环（Feedback Loop）——智能体审智能体
传统开发中，人类工程师负责代码审查（Code Review）。在驾驭工程中，这个工作变成了智能体对智能体的方式：Codex 在本地审核自身更改，请求额外审查，循环往复直到通过。
反馈循环中的钩子可以运行预定义的测试套件，并在失败时带着错误信息循环回到模型，或者提示模型独立评估其代码。如果 AI 写的测试用例通过了带有 Bug 的代码，Harness 就会判定测试无效，强迫它重新思考测试边界。
护栏四：熵管理（Entropy Management）——垃圾回收
随着时间推移，软件系统会逐渐混乱（熵增），技术债务会积累。OpenAI 采用持续小额偿还的策略，而不是等问题严重时集中处理——他们把这个方法形象地称为垃圾回收，并认为技术债务就像高息贷款。
具体措施：定期运行后台 Codex 任务扫描偏差、更新质量等级、发起针对性重构 PR。此外还有一个专门的 Doc-gardening Agent（文档园丁代理），在后台自动扫描文档与代码之间的不一致，发现过时内容就自动提交 PR 修复——Agent 为 Agent 维护文档。
五、成熟的harness系统的六个层次
第一层：信息边界管理（Context视角）
-
职责：确保模型在正确、相关的信息边界内进行思考，稳定发挥能力。
-
三大核心要素：
- 角色与目标定义：明确模型“是谁”，任务是什么，成功标准是什么。
- 信息裁减与选择：不是上下文越多越好，而是越相关越好，避免信息泛滥导致模型注意力涣散。
- 结构化组织：将规则、任务、状态和外部证据分层分明，避免信息混乱，防止模型漏重点或出现自我污染。
第二层：工具系统管理
-
职责：接入模型外部工具，赋予模型执行现实世界操作的能力，但不仅仅是挂接工具。
-
三大问题解决：
- 工具选择：既不能工具太少导致能力不足，也不能工具太多让模型混乱。
- 调用时机：避免无谓调用，保证工具调用在必要时发生。
- 结果处理：工具返回结果需筛选提炼，保持与任务的相关性，避免直接塞回模型引起干扰。
第三层：执行编排
- 职责：决定模型下一步具体行动，保证多步骤任务的连贯执行。
- 核心问题：很多agent单步能力强，但无法串联成完整流程，最终产出半成品。
- 典型工作流：理解目标→判断信息是否足够→持续抓取信息→结果分析→生成输出→输出质量检查→不满足则修正重试。
- 特点：接近人类工作流程，但依赖harness提供的持续管理和引导。
第四层：记忆与状态管理
-
职责：管理任务状态和记忆，保证agent“有记忆”，能跟踪已完成和未完成的工作。
-
三类状态区分：
- 当前任务状态
- 过程中的中间结果
- 长期记忆及用户偏好
-
重要性：状态混乱会导致系统不稳定，良好的状态管理让agent成为稳定协作者。
第五层：评估与观测
-
职责：独立地评估任务结果和系统表现，避免agent“自我感觉良好”。
-
包含内容：
- 输出验收标准
- 运行环境验证
- 自动测试
- 日志和指标收集
- 错误归因分析
-
意义：系统不仅要会做，还要知道做得对不对，为后续纠偏奠定基础。
第六层：约束、校验与失败恢复
-
职责：处理真实环境中常见的错误与异常，保证系统可持续运行。
-
三大核心机制：
- 约束：定义能做和不能做的边界，防止模型越界操作。
- 校验：在输出前后进行检查，确保结果符合预期。
- 失败恢复：出错时能快速切入、回滚或重试，避免从头再来，提升系统鲁棒性。
-
重要性：这是决定系统能否上线和稳定交付的关键层。
六、六大行业共识
综合 OpenAI、Anthropic、LangChain、Stripe、HashiCorp 等多个独立信息源，业界在以下六个方面已形成明确共识：
| # | 共识 | 核心观点 |
|---|---|---|
| 1 | 瓶颈在基础设施，不在模型智能 | 五个独立团队得出相同结论。仅改变 Harness 工具格式，就能让模型得分从 6.7% 跳到 68.3% |
| 2 | 文档必须是活的反馈循环 | 静态文档是坟场，动态文档才有价值。让后台 Agent 定期清理过时文档并提交 PR |
| 3 | 思考与执行分离 | 复杂任务不可能在单个上下文窗口内完成，需要 Orchestrator + Worker 分层架构，状态持久化到外部存储 |
| 4 | 上下文不是越多越好 | 上下文是稀缺资源。巨大的指令文件会挤掉任务空间，应按需检索、动态注入 |
| 5 | 约束必须自动化 | 人工 Review 是瓶颈。护栏要编码为 Linter、CI、类型系统，让机器来执行而非人 |
| 6 | 工程师角色在转变 | 从代码的编写者变成环境的建筑师。最大的工程挑战是设计让 Agent 可靠工作的控制系统 |
七、Anthropic 的实践
- 时间一长，上下文越来越满，模型就开始丢细节丢重点，甚至还会出现一种很有意思的现象，他好像知道自己快装不下了，于是开始着急的去收尾。
很多系统面对这种问题都会做context complication也就是把前面的历史上下文压缩一下再继续跑 但Athropic发现,对于一些模型来说,这还是不够的因为压缩只是变短了,无代表那种负担感真的消失了所以他们做了一件更激进的事情,叫Context Reset不是在原上下文里面继续压,而是换了一个非常干净的新的agent把工作交接给他那这个思路很像什么呢?特别像工程里面遇到内存泄漏之后不是继续轻缓存,而是直接重启整个进程再恢复状态
- 自评失真。
模型自己干活再让他自己给自己打分往往是会偏乐观的，尤其是在设计体验产品完整度这一类，没有标准答案的问题上偏差是更明显。
思路：把干活的人和验收的人分开
Planner负责把模糊的需求豁展成完整的规格
Generator负责逐步的去实现
Evaluator负责像QA一样去真实的测试，它不只是会看代码而是会真实的操作页面看具体的交互检查实际的结果（背后是一个很明确的工程原则生产验收必须分离）
八、openAI 的实践
重新定义了工程师在agent时代的工作
-
工程师角色的转变
OpenAI重新定义了工程师在agent时代的工作方式：
- 工程师不需要写一行代码，更多是设计环境和任务体系。
- 具体工作包括将产品目标拆解成agent能理解的小任务。
- 当agent失败时，不是简单让它“更努力”，而是分析环境中缺失的能力。
- 建立返回链路，让agent能看到自己的工作结果，实现闭环反馈。
-
渐进式披露（Progressive Disclosure）
- 早期OpenAI团队曾犯过错误：一开始把所有规范和框架全部塞给agent，导致agent混乱。
- 后来将“agents.md”转变为目录页，只保留核心索引，详细内容拆分到子文档中，agent根据需要逐步查阅。
- 这种按需暴露信息的设计理念，类似于前文提到的“skills”思路，避免上下文窗口被过度占用，提升效率和稳定性。
-
agent自我验证和自动化评估
- OpenAI不仅让agent写代码，还让agent“看见”整个应用环境。
- agent接入浏览器模拟用户操作、截图页面、查日志、监控系统指标。
- 每个任务在独立隔离的环境中执行，互不影响。
- agent可以跑起来、发现bug、修复bug，再验证结果，形成完整的自动化闭环。
-
自动治理系统与规则编码
- 由于agent提交代码速度快，人类工程师难以完全覆盖审核。
- OpenAI将资深工程师的经验总结成系统规则，例如模块分层规则、依赖限制、错误拦截和修复策略。
- 这些规则不仅负责报错，还会给agent反馈“如何修复”，并融合进下一轮上下文。
- 形成可持续运行的自动治理系统，确保代码质量和系统稳定。
