随着大模型应用从对话生成走向任务执行，围绕模型外部工程体系的讨论正在迅速升温。2026年2月，OpenAI在官方文章《Harness engineering: leveraging Codex in an agent-first world》中使用了 Harness Engineering 这一表述，此后这一概念迅速在 AI 工程实践领域受到关注。作为近来频繁出现的新提法，Harness Engineering 究竟是什么？它与提示词工程、上下文工程之间分别是什么关系？本文围绕这些相互关联的概念展开系统梳理，以呈现其内在逻辑与相互关系。

Prompt、Context和Harness

AI工程的重心变化经历了从Prompt Engineering→Context Engineering→Harness Engineering的变化，分别对应了AI发展过程中遇到的三个阶段性问题。

第一阶段 Prompt Engineering：模型有没有听懂你在说什么，关注语言

这个阶段解决的是表达问题：模型有没有听懂你到底要什么。你怎么设定角色、怎么给示例、怎么约束格式，都会显著影响输出。

这是因为大模型本质上是一个对上下文非常敏感的概率生成系统，更容易沿着你给的身份去回答、沿着你给的样例范式去补全、将你强调的约束当成重点。所以提示词工程的本质，不是命令模型，而是在塑造一个局部概率空间。

提示词工程擅长澄清任务、约束输出、激发模型已有能力，而并不擅长凭空补全缺失知识、管理大量动态信息、处理长链路状态变化等。
第二阶段 Context Engineering：模型有没有拿到足够且正确的信息，关注信息

然而大家很快发现，很多任务不是“说清楚”就够了，而是模型需要知道事实、规范、历史记录和当前状态。于是问题从“怎么把话说清楚”变成“怎么在正确的时机，把正确的信息送进去”。

这里的 context，不只是几段背景资料，而是所有影响当前决策的信息总和：用户输入、历史对话、检索结果、工具返回、任务状态、中间产物、系统规则、安全约束等等。

比较典型Context Engineering实践有RAG、Agent Skills等。
第三阶段 Harness Engineering：模型在真实的场景下执行时，能不能正确且持续运行，关注执行

即便信息给对了，模型也不一定能持续做对。它会在长链路里慢慢偏航，会错误理解工具返回，会在局部步骤上做出看起来合理、全局上却有问题的动作。于是系统需要的不再只是“会说”和“知道”，而是会执行、能被监督、出了错能被拉回来。

以带新人见客户为例：Prompt Engineering 像是把任务说清楚；Context Engineering 像是把客户背景、历史沟通、报价和会议目标都准备好；而 Harness 则更像是整套带教和督导机制——关键节点汇报、会后核对纪要、发现偏差及时纠正、最后按标准验收结果。

什么是Harness

Harness Engineering（驾驭工程）是一种由OpenAI提出的新型软件开发模式，出自文章《Harness engineering: leveraging Codex in an agent-first world》。具体表现为：为AI智能体搭一整套靠谱的工作环境和工作流程，如设计和构建约束机制、反馈回路、工作流控制和持续改进循环等运行时和基础设施。它不优化模型本身，而是优化模型运行的环境。

Agent = Model + Harness

所以，Harness 的重点从来不是单点技巧，而是一整套过程治理能力：

它要知道任务边界在哪里；
它要知道什么时候该查工具，什么时候该直接推理；
它要知道流程如何拆、每一步如何验收；
它要知道哪些状态该短存，哪些知识该长存；
它要知道系统出了问题时，怎么观测、怎么归因、怎么恢复

Harness六层架构

一个成熟的Harness系统可以分成六层架构：

上下文边界层

功能：让 AI 知道自己是谁、该做什么、不该做什么。

关键环节

1）角色与目标定义

给AI一个明确的"身份卡"——你是谁、任务是什么、成功标准是什么。

作用：避免AI自由发挥超出范围。

2）信息选择和裁剪

上下文不是越多越好，而是越相关越好。

作用：噪音会稀释关键信号，上下文污染严重容易产生幻觉

3）结构化组织

固定规则、当前任务、运行状态、外部证据，要进行分层管理

层级	职责	内容示例
规则层	不可逾越的硬边界	技术红线、安全约束、架构原则
状态层	当前任务的进度追踪	完成了什么、阻塞是什么、下一步
证据层	支撑结论的外部依据	文档、测试结果、日志、用户反馈

作用

一旦边界模糊，后面所有层都会被污染
- 防止幻觉：边界外的任务，AI可能瞎编
- 提升质量：聚焦上下文 = 聚焦答案
- 节省Token：少花钱、速度快
- 可控性：出了错容易定位是谁的问题

工具系统层

功能：连接模型与现实世界
关键环节

1）工具选择

提供给AI的工具太少，系统能力不够；给的太多，模型则会乱用。

因此，需要平衡能力覆盖与使用复杂度。

2）工具调用时机

避免不必要调用（不乱查）和错误判断（不硬答）。
- 事实性问题（查文档、查数据）→ 调用工具
- 推理性问题（分析、设计）→ 基于已有上下文
3）工具返回结果处理

提炼、筛选工具返回的结果，保持与任务相关性。
- AI从工具返回中提取与当前任务相关的字段
- 丢弃无关信息，避免上下文污染
- 必要时对结果进行二次加工（格式化、计算）

执行编排层

功能：将任务分解为可执行步骤
典型流程

目标理解 → 信息检查 → 分析处理 → 输出生成 → 结果检查 → 修正迭代

记忆与状态层

功能：解决 Agent “失忆” 问题
关键组成
- 当前任务状态：追踪任务执行过程中的关键节点，便于断点恢复。
- 会话中间结果：避免重新计算、以及溯源
- 长期记忆与偏好：跨会话保留，形成个性化服务，拟合自己的开发习惯。

评估与观测层

功能：很多Agent做完任务后，不知道自己做得好不好，从而长期存在自我感觉良好的认知偏差，因此需要建立质量反馈机制。同时，因为AI的代码生产效率远远高于人类，这时候人的评审反而成了效率的瓶颈，因此最好的方式是AI可以自己发现错误、修复错误、验证修复。

关键环节

1）输出验收：在交付前强制校验输出质量。例如检查单元测试覆盖率>80%、符合项目代码规范等。

2）环境验证：验证仓库能否访问、测试命令能否执行、依赖是否安装完成等。

3）自动化测试：验证代码质量，减少人工检查遗漏。

测试类型	验证内容	自动化程度
单元测试	函数的正确性	完全自动
集成测试	模块间交互	完全自动
端到端测试	完整业务流程	完全自动
回归测试	修改未破坏已有功能	完全自动
性能测试	响应时间、吞吐量	完全自动
安全扫描	SQL注入、XSS等漏洞	完全自动

4）日志与指标监控：保证可观测性

执行指标
- 任务成功率：85%
- 平均执行时间：45秒
- 超时率：5%
- 错误类型分布：输入错误60%、工具错误30%
质量指标
- 输出验收通过率：90%
- 一次修复成功率：70%
- 用户满意度：4.5/5
- 重复任务率：15%
资源指标
- Token消耗：日均500K
- API调用次数：日均200次
- 平均响应时间：1.2秒

5）错误归因：基于日志监控、指标对比、链路追踪等方式找出问题的根本原因。

约束校验与恢复层

功能：真实环境中失败是常态，API超时、模型误解任务、工具权限等问题都有可能出现，如果不存在恢复机制，每次失败就只能从头再来。
关键环节

1）约束机制

明确能力边界（能做什么 / 不能做什么）

2）校验机制

在执行前后进行检查校验
- 执行前校验：防止无效执行浪费资源。输入参数是否合法、所需工具是否可用、执行条件是否满足、是否有权限执行此操作等。
- 执行后校验：确保输出质量，发现问题及时处理。输出格式是否正确、结果是否在预期范围内、是否产生副作用需要回滚等。
3）恢复机制

失败后进行的重试、回滚策略。
- 重试：超时、资源不足、工具调用失败、逻辑错误等
- 回滚：执行失败时恢复到安全状态。如更新数据库前备份当前数据状态为快照，在更新过程中发现格式错误则执行回滚，恢复到执行前状态并返回错误信息。

Harness实践心得

渐进式披露（SKILL）

不要尝试用一个巨大的 AGENTS.md 文件来指导AI来完成代码生成，因为它会挤占上下文、不能体现规则的重要等级、导致规则难以维护……正确做法是将 AGENTS.md 控制在约 100 行，仅作为索引目录，AI需要时再根据目录找到深层知识。
规则要沉淀到仓库中

代码仓库是 AI 唯一能看到的世界，AI没有办法看到人类大脑中的想法，也无法知道编码环境之外的任何内容。因此我们平时所有的设计决策、架构约定、团队共识都必须以版本化的 Markdown、代码或可执行计划的形式提交到仓库。
让AI自动清理垃圾代码

AI生成新代码时会参考已有代码，因此一次坏的实现会被多次复制，架构可能快速漂移。这个如果靠人来手动处理会耗费极大的时间和精力，因此需要将"黄金原则"编码到仓库中，并运行后台 Codex 任务定期扫描偏差、发起重构 PR——持续小步迭代还债远好过等到累积到一个大债务再去解决。
人类的建议要沉淀到仓库中

代码审查中的评论、重构 PR 和用户反馈中体现出了人类对代码实现的要求，这些信息如果只停留在口头或聊天记录中就无法影响未来AI的输出，因此必须将这些信息提取为规则，写到文档中或者编码进工具，才能让人类的要求持续的约束AI，而不是随着时间流逝而消失。