前段时间，Harness Engineering 这个词在技术圈里刷了屏。
我看到它时，第一反应是，又来一个新词？
Prompt Engineering 还没完全弄明白，Context Engineering 刚摸到一点门道，现在又多了个 Harness Engineering。
我把 OpenAI 和 Anthropic 最近几篇相关文章找来读了一遍。读完以后，这个词倒没有先前那么讨嫌了。它确实说中了一件事，而且很多人已经做了很久，只是一直缺一个方便交流的名字。
你大概经历过这个过程
刚开始用 AI 写代码时，事情很简单。丢过去一句 prompt，它吐出一段代码，复制，粘贴，结束。
很快，麻烦就来了。
它改了不该碰的文件。代码看着没问题，一运行就报错。上次刚踩过的坑，换个任务又踩一遍。
你只好一点点给它补条件。
- 写一份项目规则，告诉它技术栈、代码规范，以及哪些目录不能碰
- 把常用的调试流程做成 Skill，下次直接调用
- 接上终端、文件读写和测试工具，让它自己执行命令、检查结果
- 碰到复杂任务，先写计划，确认方向后再动手
- 任务结束后留下文档和记录，下一次可以接着做
折腾到这里，你会发现，大部分时间早已不再花在 prompt 本身。你在整理环境、补规则、接工具，也在设计流程和反馈方式。
这些工作合在一起，就是 Harness Engineering。
从一句话，走到一套工作环境
Prompt Engineering 处理的是一句话怎么写。Harness Engineering 处理的是 AI 在什么样的环境里工作。
两者之间还有一层 Context Engineering。把这三个概念放在一起，会更容易看清它们各自管什么。
Prompt Engineering 主要处理输入措辞。
"你是一名资深前端工程师，请优化这个组件"和"优化这个组件"，得到的结果往往会有差别。这是最直接的一层。
Context Engineering 主要处理模型在当前任务里能拿到哪些信息。
项目规则、技术栈、目录结构、业务背景、历史文档，都属于上下文。它关心的是模型此刻知道什么，以及这些信息该在什么时候出现。
Harness Engineering 继续往外扩了一圈，把模型的整个工作过程纳入设计。
任务怎样拆分，上下文怎样交接，工具怎样调用，结果怎样验收，失败信息怎样返回，做过的事情怎样留下记录，都属于这一层。它关心的是模型能够按什么方式工作。
Prompt 和 Context 主要影响模型拿到的输入。Harness 还会约束执行过程，并决定模型能否形成可靠的反馈循环。
只调 prompt 为什么不够
真实开发是一段持续推进的工作流，很少停在一次问答里。
让 AI 改一个功能，它得先找到相关文件，也得知道哪些地方不能动。写完以后，它要运行测试；测试失败，还要读日志、定位问题、继续修改。任务一长，它还得保存进度，把必要的信息交给下一轮上下文。
任何一环缺失，最后那段代码写得再漂亮，也可能无法交付。
这就解释了为什么很多团队开始把精力放到模型周围。代码仓库要让 Agent 看得懂，工具要让它用得上，检查结果还得及时回到它手里。
OpenAI 在 Codex 的实践里，把简短的 AGENTS.md 当成目录和地图，具体知识放进结构化文档。这样做有个很现实的原因。上下文空间有限，一份大而全的说明书会挤掉眼前任务需要的信息。仓库里的文档、计划、测试和检查规则，也就不再只是给人看的附件，它们会直接影响 Agent 能否继续工作。
Anthropic 的几次实验则把验收放到了更靠前的位置。Planner 先展开需求，Generator 负责实现，Evaluator 在真实环境里检查；每一轮开始前，生成者和评估者还会先约定完成标准。测试发现的问题会重新交给生成者，直到结果达到要求。
这类系统的价值很具体。它把"怎样算做完"写进了工作过程。
很多人早就在做
如果你给项目写过 CLAUDE.md 或 AGENTS.md，你已经碰到了 Harness Engineering。
把重复流程做成 Cursor Skill 或 Agent 指令，让 AI 写完代码后自动跑测试，为 Agent 设置文件和命令权限，建立可检索的项目知识库，这些工作也属于同一范围。
多 Agent 分工也是如此。一个负责实现，一个负责测试，另一个负责审查。你设计的已经是一套协作和验收机制。
这也能解释一个常见误会。很多人觉得 AI 编程效果不好，第一反应是 prompt 写得不够高明。问题往往出在更具体的地方。模型缺少必要资料，拿不到合适工具，或者做完以后没有可靠的检查方式。继续改措辞，帮助不会太大。
Harness 也会过时
Anthropic 提过一个很值得记住的判断。Harness 里的每个组件，都隐含着一个假设，也就是模型暂时无法独立完成这件事。
模型能力变化以后，这些假设也要重新检查。
Sonnet 4.5 做长任务时，Anthropic 曾用上下文重置来缓解模型过早收尾的问题。到了 Opus 4.5，这个现象明显减弱，他们便从新的 Harness 里去掉了这套机制。后来升级到 Opus 4.6，原先用于拆分工作的 sprint 结构也可以继续精简。
所以，Harness 越复杂，维护成本往往越高。合适的做法是补上模型眼下的短板，同时定期拆掉已经失去作用的部分。
今天必须显式写出的规则，下一代模型也许已经能够自行判断。今天需要单独安排的验证步骤，过一阵也可能合并进模型自己的工作流程。
Harness Engineering 因此更像一种持续调整的工程习惯。模型变了，周围的环境也要跟着变。
回到最初的问题
Prompt、Context、Harness 之间的区别，可以记成三句话。
- Prompt Engineering 决定你怎样提出要求
- Context Engineering 决定模型此刻知道什么
- Harness Engineering 决定模型怎样把事情做完
如果你已经在用 AI 做真实项目，多半早就做过其中一些工作。
现在，我们终于有了一个可以拿来交流的名字。
参考资料
- OpenAI 关于 Harness Engineering 的实践，2026 年 2 月 11 日
- Anthropic 关于长时间运行 Agent 的 Harness 实践，2025 年 11 月 26 日
- Anthropic 关于长时间应用开发的 Harness 设计，2026 年 3 月 24 日
- Anthropic 关于 Managed Agents 的架构思路，2026 年 4 月 8 日
- Anthropic 关于 Agent 上下文工程的实践，2025 年 9 月 29 日