过去两年，AI Agent 的进步看起来主要来自两个方向：

一个是模型越来越强，另一个是 Prompt 越写越复杂。

开发者会给 Agent 设定角色、拆解步骤、补充示例，甚至写出几千字的 System Prompt，试图把模型“调教”成一个完美执行任务的员工。

但只要任务稍微复杂一点，问题就会迅速出现：

它可能忘记最开始的要求；

可能执行到第四步时偏离目标；

可能反复修改已经完成的内容；

可能声称“任务已完成”，却根本没有运行测试；

甚至可能为了满足用户，编造一个看起来合理、实际上并不存在的结果。

于是，开发者只能继续给 Prompt 打补丁：

不要修改无关文件。 必须先阅读文档。 必须执行测试。 不要跳过任何步骤。 请严格遵守以上要求。

最后，Prompt 越来越像一本写给 AI 的《员工手册》。

但是，Agent 依然可能不听话。

这说明问题并不只是 Prompt 写得不够好。

更根本的问题是：

我们试图用一段自然语言，承担原本应该由一整套工程系统承担的责任。

当 Agent 从一次性问答，开始进入软件开发、数据分析、自动运维和企业流程时，仅靠 Prompt 已经不够了。

它需要一套更坚固的外部系统。

这就是最近被越来越多团队讨论的：

Harness Engineering

01 Harness Engineering 到底是什么？

Harness 这个词原本指马具、挽具和驾驭系统。

如果把 AI Agent 比作一匹能力很强、但行为存在不确定性的马，那么：

• 模型决定这匹马有多强；
• Prompt 告诉它应该往哪里走；
• Context 告诉它周围有什么；
• Harness 则提供缰绳、车架、道路和护栏。

因此，Harness Engineering 不只是“给 Agent 加限制”。

它更准确的含义是：

围绕模型构建一套执行环境，通过工具、状态、权限、验证和反馈机制，把模型的概率性能力转化为相对可靠的系统行为。

一个 Harness 通常会决定：

• Agent 当前能够看到什么；
• Agent 可以调用哪些工具；
• 哪些文件或系统允许修改；
• 任务现在进行到了哪一步；
• 什么条件才算真正完成；
• 出现错误后如何重试或回退；
• 上下文被压缩或清空后，如何继续任务；
• 什么时候必须交给人类审批。

所以，Harness Engineering 真正关心的，不是：

如何把一句 Prompt 写得更加漂亮？

而是：

如何设计一套系统，让 Agent 在长时间、多步骤、真实环境中稳定工作？

一句话概括：

Prompt 是对 Agent 提要求，Harness 是让系统执行要求。

02 Prompt 是“劝说”，Harness 是“制度”

假设我们希望 Agent 重构一个支付模块。

最常见的 Prompt 可能是：

请优雅地重构支付模块，不要修改无关代码，保证系统稳定，并执行必要的测试。

这句话没有问题。

但其中的“优雅”“无关”“稳定”和“必要”，都需要模型自行理解。

模型可能认为某个文件与任务相关，也可能认为运行一个简单测试就已经足够。

Harness 的做法则完全不同。它会把自然语言要求，转化为可以执行和检查的工程规则。

例如：

这背后有一个非常重要的原则：

凡是能够由程序检查的要求，就不应该只依赖模型自觉。

不要只告诉 Agent“不能操作生产数据库”，而是默认不给它生产权限。

不要只告诉 Agent“必须执行测试”，而是让测试不通过的代码无法被合并。

不要只告诉 Agent“遵守架构规范”，而是通过静态检查禁止错误的依赖关系。

这被称为 Mechanical Enforcement，机械化约束。

它不是要求模型永远不犯错。

而是让错误更容易被发现、拦截、回滚和复盘。

03从 Prompt 到 Context，再到 Harness

Agent 工程的发展，可以大致分成三个层次。

Agent 工程的三层演进

第一层：Prompt Engineering

Prompt Engineering 解决的是：

我应该怎样向模型表达任务？

它关注角色设定、任务说明、示例、格式和输出要求。

对于文案改写、摘要、翻译和简单分析，Prompt 依然非常重要。

但 Prompt 主要影响模型“准备怎么做”，很难保证系统“实际上怎么做”。

第二层：Context Engineering

Context Engineering 解决的是：

在当前这一步，模型应该看到什么？

这里的 Context 不只是聊天记录，还包括：

• 当前任务目标；
• 检索到的知识；
• 相关代码和文档；
• 历史决策；
• 工具执行结果；
• 当前进度和状态。

Context Engineering 的重点，不是把更多内容塞给模型，而是让模型在正确的时间看到正确的信息。

上下文越长，并不代表 Agent 越聪明。

当上下文中混杂着过期文档、失败日志、重复信息和已经被推翻的结论时，信息越多，反而可能越混乱。

第三层：Harness Engineering

Harness Engineering 进一步解决：

Agent 能做什么？ 每一步如何被验证？ 失败后如何恢复？ 如何让任务持续推进？

它把 Prompt 和 Context 包裹在一个更大的执行系统中，同时加入：

• 工具接口；
• 权限管理；
• 状态存储；
• 工作流和状态机；
• 测试与评测；
• 错误恢复；
• 审计与日志；
• 上下文生命周期管理。

因此，三者并不是互相替代。

更准确的表达是：

Prompt 决定说什么，Context 决定看什么，Harness 决定能做什么，以及如何证明做对了。

04 OpenAI 为什么开始强调 Harness Engineering？

2026 年 2 月，OpenAI 发布了一篇名为《Harness engineering》的工程文章。

文章介绍了一个很有代表性的实验：

一个小型工程团队，让 Codex 完成了一个真实软件产品中的代码、测试、CI、文档、可观测性和内部工具开发。该代码仓库最终达到约百万行代码规模，期间产生约1500个合并请求。OpenAI 估计，这个项目所需时间约为传统手写代码方式的十分之一。

但这项实验真正值得注意的，不是 Codex 写了多少代码。

而是工程师的工作发生了变化。

工程师不再主要负责亲自写代码，而是开始负责：

• 设计 Agent 的工作环境；
• 建立仓库结构；
• 定义验收标准；
• 构建工具和反馈回路；
• 把架构规则变成机械化约束；
• 在 Agent 失败时，寻找缺失的系统能力。

OpenAI 在文章中总结得非常直接：

人类掌舵，Agent 执行。

当 Agent 做不好一项任务时，他们不会简单地继续增加 Prompt：

“请再认真一点。”

他们会反过来检查：

Agent 缺少了什么工具？ 哪些信息无法被发现？ 哪些规则没有被系统执行？ 哪种反馈没有及时返回？

这就是 Harness 思维与 Prompt 思维最大的区别。

Prompt 思维把失败理解为：

模型没有听懂。

Harness 思维则把失败理解为：

系统没有为模型提供足够清晰的环境、边界和反馈。

05 仓库应该成为 Agent 的“唯一真理源”

很多团队为了让 Agent 了解项目，会把所有技术文档、聊天记录和业务规则都塞进一个巨大的 Prompt。

OpenAI 的实践表明，这种“超级说明书”很容易失败。

因为上下文是一种稀缺资源。

当所有内容都被标记为“重要”时，Agent 反而无法判断什么最重要。

OpenAI 因此提出了一个很有传播力的原则：

给 Agent 一张地图，而不是一本一千页的说明书。

他们将代码仓库本身作为系统记录，也就是 System of Record。

让仓库成为 Agent 的真理源

一个为 Agent 设计的仓库，可以包含：

AGENTS.md
ARCHITECTURE.md

docs/
├── design-docs/
├── product-specs/
├── decisions/
└── exec-plans/
    ├── active/
    ├── completed/
    └── tech-debt.md

src/
tests/
scripts/

其中：

AGENTS.md 不需要写成一部百科全书，而应该作为目录，告诉 Agent 去哪里寻找信息。

ARCHITECTURE.md 描述系统边界、模块划分和依赖关系。

exec-plans/ 保存复杂任务的执行计划、进度、决策和技术债务。

tests/ 则提供可以被机器执行的事实验证。

OpenAI 还使用专门的 Lint 和 CI 检查文档是否过期、结构是否正确，并让 Agent 定期扫描陈旧内容。

这意味着，仓库不再只是“存放代码的地方”。

它同时承担了三种角色：

Agent 的外部记忆、任务地图和质量契约。

模型不需要在一个上下文窗口里记住整个项目。

它只需要知道：

• 当前任务在哪个区域；
• 下一步应该读取什么；
• 哪些规则必须遵守；
• 如何判断自己是否完成。

06 长任务真正的敌人，是“上下文熵增”

Agent 完成十分钟的任务，与连续工作几个小时甚至几天，是完全不同的问题。

任务越长，中间状态就越多：

• 看过哪些文件；
• 尝试过哪些方案；
• 哪些假设已经被推翻；
• 哪些测试已经通过；
• 哪些模块已经完成；
• 哪些问题留给下一阶段。

如果这些内容全部留在聊天历史里，上下文会越来越混乱。

早期的错误结论、临时方案和大量日志，依然会占据模型的注意力。

最终，Agent 可能出现一种很典型的现象：

它记得自己做过很多事情，却不再清楚当前真实状态是什么。

这就是所谓的上下文熵增。

OpenAI 在 Harness Engineering 实践中专门讨论了“熵与垃圾回收”。

Agent 会复制仓库中已经存在的模式，包括不好的模式。久而久之，代码库会出现架构漂移、重复工具和质量下降。

他们最初需要固定花时间清理这些“AI 残渣”，后来开始把核心原则编码为机械规则，并让定时任务持续扫描和修复偏差。

Anthropic 在长任务 Agent 的研究中也发现，单纯依靠上下文压缩并不够。

更有效的方法是：

• 把大任务拆成可完成的小任务；
• 每次只推进一个明确阶段；
• 持续把进度写入外部文件；
• 为下一个 Agent 会话留下清晰的交接材料。

Anthropic 将这种方式比喻为工程师轮班：新的 Agent 会话没有上一轮会话的完整记忆，因此上一轮必须留下结构化、可验证的交接记录。

长任务中的状态机和上下文回收

一个可靠的长任务循环应该是：

计划 → 执行 → 观察 → 验证 → 写回状态 → 进入下一阶段

其中有两个非常重要的机制。

上下文垃圾回收

当一个阶段完成后，不再保留几十轮调试过程，而是将其压缩成稳定结论：

• 最终使用了什么方案；
• 修改了哪些文件；
• 通过了哪些测试；
• 还有哪些风险；
• 下一步从哪里开始。

有价值的信息被写回仓库。

已经完成使命的中间信息，则退出当前上下文。

外部传感器

Agent 不能只依靠自己的语言判断任务是否完成。

它需要读取环境中的真实信号：

• 编译是否通过；
• 测试是否成功；
• 服务是否真正运行；
• 性能是否达到要求；
• 是否修改了不允许修改的文件；
• Token、时间和重试次数是否已经失控。

这些测试、日志和规则，就是 Agent 的外部传感器。

它们不断告诉 Agent：

你以为自己做成了什么，以及系统实际上发生了什么。

07 一个生产级 Harness，至少要有什么？

Harness Engineering 并不是某一个具体框架，也不是安装一个 Agent SDK 就自动拥有的能力。

一个比较完整的生产级 Harness，至少需要以下八个部分。

1. 任务契约

明确任务输入、输出、范围、禁止事项和完成标准。

“优化一下系统”不是任务契约。

“将接口 P95 延迟降低至800毫秒以内，并保持所有回归测试通过”才是。

2. 知识地图

让 Agent 知道信息在哪里，而不是一次性把所有信息塞给它。

3. 原子化工具

不要只提供一个“修改整个项目”的巨大工具。

应该拆成读取文件、搜索符号、应用补丁、运行测试和查看差异等小工具。

4. 显式状态

计划、进度、失败原因、测试结果和下一步行动，都不能只存在于聊天历史中。

5. 验证器

Agent 负责提出方案，测试和规则负责判断方案是否满足标准。

Anthropic 也强调，Agent 的多轮行动、工具调用和状态变化，使它比普通聊天模型更难评估，因此需要专门的评测和验证体系。

6. 权限边界

包括沙箱、文件白名单、工具权限、速率限制、敏感操作审批和回滚能力。

7. 上下文生命周期

明确什么时候读取、什么时候压缩、什么时候写回、什么时候开启一个新会话。

8. 可观测与审计

记录 Agent 调用了什么工具、修改了什么内容、在哪一步失败，以及不同版本的成功率如何变化。

没有可观测性，Agent 出错后就只能靠猜。

08 Harness 不是越复杂越好

强调 Harness，并不代表所有 AI 功能都需要被设计成复杂的自主 Agent。

对于路径明确、结果固定的任务，确定性工作流往往更加可靠。

Anthropic 在 Agent 工程实践中也建议：优先使用能够解决问题的最简单方案，只有当任务真正需要动态决策时，才增加 Agent 的自主程度。

不同类型的任务，需要不同强度的系统。

成熟的 Agent 架构，不是让模型负责一切。

而是清楚地区分：

• 什么适合由模型判断；
• 什么应该由确定性程序执行；
• 什么必须由人类批准。

模型擅长理解模糊意图、处理非结构化信息和制定策略。

程序擅长执行规则、维护状态和验证结果。

Harness Engineering，就是把模型和确定性系统放在各自最合适的位置。

09 下一代 Agent 工程师，将更像系统架构师

Prompt Engineering 不会消失。

好 Prompt 依然重要，Context Engineering 也依然重要，强大的模型当然更重要。

但随着基础模型能力不断提高，真正拉开 Agent 产品差距的，可能越来越不是某一条“祖传 Prompt”。

而是模型外部的系统能力：

• 信息是否能够被准确发现；
• 工具是否足够清晰和稳定；
• 任务状态是否可以持续保存；
• 错误是否能够被及时发现；
• 系统是否能够恢复和回滚；
• 质量标准是否可以机械执行；
• Agent 的行为是否可以被评测和审计。

Prompt 工程师关心：

我该如何告诉模型完成任务？

Harness 工程师关心：

什么才算完成？ 它能访问什么？ 每一步如何验证？ 失败后如何处理？ 上下文清空后，什么必须留下？

这已经不再只是“调模型”。

它更接近软件架构、操作系统、测试工程、权限控制和生产运维的结合。

未来优秀的 Agent 工程师，不会只是一个擅长写提示词的人。

他需要成为一个真正的系统架构师：

既理解模型的能力，也知道如何用确定性的工程系统，托住模型的不确定性。

结语

过去，我们总希望找到一段完美的 Prompt，让 Agent 像一个永远不会犯错的员工。

但现实是，不存在永远正确的员工，也不存在永远正确的模型。

真正可靠的公司，从来不是依靠每个人“牢记全部规定”。

而是依靠：

• 清晰的流程；
• 合理的权限；
• 及时的反馈；
• 可执行的标准；
• 可追踪的责任体系。

Agent 也是一样。

Prompt 告诉它应该去哪里。

Context 告诉它当前身处何处。

Harness 为它铺设轨道、安装护栏，并在偏离方向时把它拉回来。

所以，当我们再次讨论一个 Agent 能否进入生产环境时，真正应该问的已经不是：

这个 Prompt 写得够不够好？

而是：

我们是否为这个 Agent，建立了一套足够可靠的工作系统？

这可能才是 Agent 从有趣 Demo 走向真正生产力的分水岭。

参考资料

OpenAI，《Harness engineering: leveraging Codex in an agent-first world》，2026年2月。

Anthropic，《Effective harnesses for long-running agents》，2025年11月。

Anthropic，《Harness design for long-running application development》，2026年3月。

Anthropic，《Demystifying evals for AI agents》，2026年1月。

Harness Engineering 学习指南: https://github.com/deusyu/harness-engineering

关注 芯动力AI，我们会继续分享 大模型、Agent 和智能部署方面的相关信息。