2026年2月11日，OpenAI 发布百万行代码实验报告，标题使用”Harness Engineering”，这是一种新的工程范式，标志着最新的agent工程研究方向。

本质上讲，Harness Engineering就是一套为 Agent 构建一套标准化、可自动化运行的测试与运行环境的系统，它的目的是让 Agent 在边界内稳定、可靠、长期地完成复杂任务

在Harness Engineering之前，已经有Prompt Engineering和Context Engineering ，它们标志着以前agent开发中最头疼的问题：提示词（prompt）和上下文（context）。

从Prompt Engineering到Context Engineering

首先来讲讲Prompt Engineering和Context Engineering。

Prompt Engineering（提示词工程）

Prompt Engineering的核心就是在于让llm能听懂你在说什么，在llm最初发展的时候，输入的要求不同，模型的生成会有很大差别。

如果你输入“帮我总结这篇论文”，它大概率只会给你一个很朴素的文本总结；如果你说的复杂一点，比如“你是一个资深研究员”、“请用三段式概括核心内容”、“先提取核心创新点、再说说研究局限性”、“把数据以xml格式输出”等等，llm的回答会更详细、严谨。

因此，Prompt Engineering实际上就是在限定llm回答的概率空间。

llm本质上就是一个对上下文非常敏感的概率生成系统，你给它什么提示词，它就往相应的局部概率空间里面生成答案，你的prompt中约束越多越精确，你得到的答案越具有相应特征

但是Prompt Engineering也有局限性，它只能激发llm已有的最大能力，但它不能为llm补缺不知道的知识、管理大量动态信息、解决长链路问题；因此出现了Context Engineering

Context Engineering（上下文工程）

如果说Prompt Engineering解决的是单个独立的问题（比如帮我总结这篇论文、帮我翻译这段对话），那么Context Engineering解决的就是一个长链路问题（比如分析这篇文档、分析文档内容、描述任务风险、提出解决方案）；这个时候llm就需要面临更复杂、更真实的操作任务。

Context Engineering的核心就是在系统需要时，把正确的信息调用进去。

Context比prompt复杂得多，它不仅仅是用户要求和外部提供的背景资料、文档，还有工具调用、检索结果、安全约束、历史对话、输出格式、系统规则等等

RAG也是属于Context Engineering的一部分，RAG就是负责检索、把检索的东西注入context、让llm基于context生成最终回答。

Context（上下文窗口）是一个非常稀缺的资源，如何更好地利用context非常重要。现在的Context Engineering非常复杂，它要考虑检索信息排序、多agent协作、输出格式规范、长文压缩等等；但是Context Engineering也有缺陷，因为他无法管控llm的行动，llm可能在一段很长的链路中发生了偏移与错误，这个时候没有人能纠正模型的行为。于是产生了Harness Engineering

Harness Engineering

Harness Engineering的核心就是管控、监督、纠正模型的行为，应对模型运行时的不确定性。基本上，在整个agent开发流程中所有除了llm的部分其他都可以叫Harness Engineering

Harness Engineering大致上可以分为上下文管理、工具系统、编排执行、记忆与状态、评估与观测、约束与恢复六个部分

上下文管理

首先，上下文需要让模型对角色定位、输出格式、任务等有清晰的认识以便生成更准确的答案，对于llm来说，context并不是越多越好而是越相关越好，一堆没有相关性的垃圾信息反而会污染模型的输出降低准确度。同时模型需要把相关信息进行结构化组织，输出要求、运行状态、外部需求这些东西放在什么地方模型需要清楚，否则会遗漏对话重点。

工具系统

首先Harness Engineering包括给模型提供工具，工具太少会严重限制模型能力，而工具太多模型可能会乱用；其次需要规定模型什么时候需要调用工具，不需要调用工具的时候去调用工具反而会影响输出和增加token；最后需要规定返回工具的调用结果，工具可能会返回50条检索信息但我们不能把全部内容都塞进context里面，我们需要根据相关性进行打分，对内容进行精简筛选。

编排执行

虽然模型可以编写代码、调用工具、输出文本、分析需求，但是本质上这些都是单独的能力，模型有这些能力但是不知道如何把这么多能力结合起来，因此需要编排一个模型的运行流程，比如从分析需求、理解目标、调用工具、分析内容、生成输出、检查输出、重新修改这就是harness中的一套工作流workflow。

记忆与状态

没有记忆的agent每一轮都只能进行新的对话，所以模型必须具有记忆与状态的功能；首先要记住对话状态，即当前的对话是第几轮；其次要记住中间结果，比如前面的对话中模型已经生成过的内容；最后还有关于用户偏好的长期记忆

评估与观测

在生成完内容之后，模型需要评估自己的生成内容质量，否则模型会长期处于自我感觉良好的状态。需要做的内容主要包括输出验证、自动测试、日志与测试指标、错误归因

anthropic就是用了一个evaluator去专门模拟像用户一样专门检查交互界面、使用结果等

约束与恢复

在实践中，模型往往会出现各种错误，比如api超时、搜索不准、误解任务等等，我们需要模型具有一定的纠错能力，每次犯错过后让模型恢复这些错误。

在Harness工程中，首先我们要约束模型哪些能做，哪些不能做；其次是校验，在输出前后模型对自我进行相应的校验检查；最后是恢复，在出错之后怎么重试，怎么回滚到上一步的稳定状态等等

最后，其实Prompt Engineering、Context Engineering和Harness Engineering并不是独立关系而是包含关系，Context Engineering包含Prompt Engineering，而Harness Engineering包含Context Engineering，因此学习Harness Engineering才是解决agent开发工程的关键。