Harness Engineering学习

• 引言
• 内容一
• 内容二
• 参考资料

引言

Harness Engineering 是什么和提示词工程和上下文工程有什么关系？

内容一

2026年OpenAI在一篇博客文章提到了 AI engineering（驾驭工程） 之后，它就快速在AI圈里火了起来。很多人根本不知道它到底是什么，就开始各种跟风吹爆。

在三天一重磅、五天一炸裂的AI圈里，虽然离谱，但也合理。那它到底是什么？和这两年很火的 提示词工程（Prompt Engineering）、上下文工程（Context Engineering） 又是什么关系？

全网资料参差不齐，如有差异以我为准。今天就把这些概念串起来讲透，看完你就会知道 AI Agent 的开发本质上是在做什么。

• 为什么同样的模型换个 AI Agent 效果会差这么多？
• 有了AI，程序员就不写代码是真的吗？
• 怎么做到的？

Prompt Engineering（提示词工程）

把 ChatGPT 的外壳剥开，里面的大模型也就是 LLM，本质就是一个磁盘上的超大参数文件。将它加载到显卡内存里，配上 HTTP 接口，就成了大模型 API 服务。给它加个聊天界面，就变成了聊天AI；加个代码编辑器，就成了 AI IDE。

AI大模型做的事情很简单，就是基于当前输入的内容，预测下一个字词大概率会是什么。它本质上只是在猜你想要什么，所以如果你给它输入的指令太宽泛，那它预测的答案就会非常发散。

比如你丢给它一段代码说”加个排序”，它可能只回你排序的那部分怎么写。你得补一句”给我完整函数代码，不要乱改我的代码”，它给的结果才会更符合要求。

能加的内容有很多，比如角色设定、背景、历史对话、参考文档、限制、输出格式，这些约束构成了所谓的 提示词（Prompt）。而这种有意识的调整和设计提示词，让模型稳定地朝着你预期的内容和格式输出的技术手段，就是所谓的 提示词工程。它解决的是大模型无引导乱说话的问题。

Context Engineering（上下文工程）

提示词写得越长越仔细，模型知道的就越多，回答就越准。反过来同理，大模型回答不准，那大概率是因为知道的不够。于是大家很自然会不断往大模型里塞各种资料。

这些打包到一起发给大模型的所有信息就叫 上下文（Context）。提示词只是上下文的一部分。但大模型再强，一次性能处理的上下文也有最大限制，这个限制叫 上下文窗口（Context Window）。

在AI大模型应用里多对话几轮，就很容易将上下文窗口打满，于是就需要通过一些策略去压缩或丢弃部分信息。在这个过程中不可避免会丢失关键信息，从而破坏上下文的完整性和准确性，这类问题被统称为 上下文腐化（Context Corruption）。效果上就是模型开始记不住，回答前后不一致。

上下文窗口就这么大，于是问题就变成了：怎么才能在合适的时候将合适的内容塞入到有限的上下文中？于是衍生了一套负责动态管理大模型上下文的技术，也就是所谓的 上下文工程。

提示词是上下文的一部分，那自然提示词工程其实也是上下文工程的一部分。它一般通过外部程序来实现，比如 Cursor、Claude Code、Cline 这类 Coding Agent。

每一家的技术实现都有差异，但总的来说可以总结为三个步骤：召回、压缩、组装。

第1步 召回：说白了就是找什么信息。这些信息可以来自外部新闻，也可以来自过去聊天记录、当前代码环境以及程序运行报错等。总之就是从里面找出最相关的内容。这里面涉及到一些 RAG、Memory 等技术。

第2步 压缩：很多上下文窗口有限，所以需要将信息变小。比如将信息分开发给大模型做总结。

第3步 组装：因为信息放置的位置和顺序会直接影响模型的理解和输出，比如越靠后越容易被模型关注。所以我们需要通过一定的结构重新组装内容，这样进入模型的上下文更精简更相关，输出也会更稳定更准。

不同 AI 工具的上下文工程策略不同，所以你会发现就算用的是同一个模型，不同 AI 工具的执行效果也会有差异。

AI Engineering（驾驭工程）

提示词工程解决了大模型无引导乱说话的问题，上下文工程解决的是上下文的组织问题。模型是更聪明了，但它只能聊天，没法帮我们干活。

于是我们可以给大模型加入 Bash 沙箱、文件系统、MCP 这些能力，让它能像人一样操作外部工具：读写代码文件、执行命令、做测试。它们共同构成了 执行层（Execution Layer）。

将它们串成一个流程，在外部套一层循环。于是我们就可以通过提示词工程和上下文工程组装上下文发给大模型，大模型负责思考，外部程序负责执行。过程中得到的报错等信息，再加到上下文里继续推理和执行。

这套一边思考一边行动的循环，就是所谓的 ReAct。而这个能通过聊天帮你执行任务的程序，就是所谓的 AI Agent。

Agent 的本质就是一个 for 循环。只要这个循环一长，上下文就一定会膨胀，上下文工程做再好也可能会 腐化。随着它看过的文件越来越多，拿到的信息越来越杂，前面定好的目标和约束，后面可能慢慢就被冲淡了，理解也会越来越偏。

怎么办呢？很简单。只要我们可以保证每次给大模型的上下文中都包含一些可复用的核心信息，比如项目目标、技术栈、需求背景、代码风格、禁止事项等。只要保证这部分一直在那，大模型就能在大框架约束下减少理解偏移。

这些核心信息可以单独写成文件，固定在代码仓库里。比如 Claude Code 用 CLAUDE.md，Cursor 或 Cline 也会有各自的 rules 文件。它们暂时没有统一的名字，我暂且称为 规则文件。规则文件会在调用大模型的时候，作为系统提示词自动注入上下文。

但规则文件写多了也会变长，所以上下文也会很长。那就拆——把它拆成几份更短的文件，再加一个简单的路由。比如背景就读 BG.md，技术栈就看 STACK.md。一般情况下只需要加载文件地址路径，真正需要的时候再加载文件的全部内容。

将它们跟提示词工程和上下文工程配合在一起，形成 记忆层（Memory Layer）。

有了记忆层和执行层的配合，Agent 就能不停写代码、跑 Lint 和单元测试。过程中发现执行有问题，还可以将测试输出和报错加入到 上下文里，这样就可以驱动 Agent 在下一轮循环中自动做修复。这套通过校验结果回传错误来实现自动修复问题的能力，形成了 反馈层（Feedback Layer）。

但 Agent 的循环如果缺乏全局规划和清晰的结束目标，依然很容易跑偏，甚至陷入无效死循环。所以我们还可以将大任务拆解为有明确执行标准的多个子任务，按规划驱动 Agent 分步执行。这种以全局规划为核心，对任务做拆解与全流程管控的能力，形成了 编排层（Orchestration Layer）。

总结

编排层 + 执行层 + 反馈层 + 记忆层，这些能力共同组成了一套包裹着大模型的工程外壳，它就是 AI Engineering（驾驭工程）。

大模型越强，外壳就可以做得越薄。但无论怎么样，这层外壳都得有。

公式：Agent = 大模型 + AI Engineering 只要不是大模型的那部分，都属于 AI Engineering 的范畴。

AI Engineering 怎么落地？

概念理解了，那最重要的问题来了：怎么落地？以 Claude Code 为例。

Claude Code 软件本身已经原生支持 Agent 的4层能力，所以最轻量的做法就是在 CLAUDE.md 文件里写清楚：项目背景是什么，你希望大模型做什么别做什么，做完之后要跑哪些 Lint、单元测试、执行哪些 Skill 就行。

如果不想自己写这么累，那就引入一些插件，比如 Spec Kit 这类扩展。它会根据项目将需求拆成多个阶段。做的事情也很简单：先生成对应的规则文件，明确需求；再制定具体开发计划，拆解任务；最后才是实际修改加测试。每个阶段都可能会更新一次 CLAUDE.md，这样每一阶段注入上下文的尽可能都是核心信息。

这套开发方式也叫 Spec-Driven Development，简称 SDD。本质上做的事情就是 AI Engineering 的落地。但 Spec Kit 整体还是不够强，我相信很快会有更加全面的替代方案出现。

有了 AI Engineering 之后，程序员的工作内容就从写代码慢慢改为写规则和 Skill。

一句话总结：

内容二

有一个名词叫做 Harness Engineering。从今年2月份开始，这个词频繁地在AI圈里面出现。OpenAI专门发了一篇文章，讲他们怎么用 Harness Engineering 在5个月内写了将近100万行代码。Anthropic也紧接着发文分享了自己如何使用精心设计的 Harness 架构来驱动 Agent 的开发应用。

不仅如此，就连技术大牛 Martin Fowler 创立的技术网站 martinfowler.com 也开始公开讨论起了 Harness Engineering。

但与此同时也有不少人认为这不过是个噱头而已，换汤不换药。

那 Harness Engineering 到底是什么？它跟 Prompt Engineering 和 Context Engineering 又有什么关系呢？Harness Engineering 是真正的技术突破，还是说只是AI圈又在炒概念？这期视频我们就来把这个事情彻底搞明白。

在讲 Harness Engineering 之前，我们不妨先来讲讲它的两个”前任”，分别是 Prompt Engineering 和 Context Engineering。对这两个概念比较熟悉的同学呢可以直接跳到下一个章节。

首先是 Prompt Engineering。这里的 Prompt 呢你可以简单理解成用户发给大模型的话，而 Prompt Engineering 呢就是一门研究怎么把这句话说清楚的技术。

举个具体的例子，比如说我们可以向大模型发问：”帮我的猫起个名字。”这个问题呢就是 Prompt 了。接到 Prompt 之后大模型就会给你一个答案，比如说是什么”花花”呀”小白”之类的。不过这些答案可能都无法让你满意，因为你家的猫呢可能是橘色的，无论是”花花”还是”小白”都与橘色这个颜色相冲突。

那为什么大模型会给你错误的答案呢？这是因为我们没有在 Prompt 里面给大模型充足的信息。既然问题出在 Prompt 上面，那解决问题的关键自然也在 Prompt 上面了。

说得再具体一点，那就是我们需要学会如何更精准地表达自己的需求。这个呢就引出 Prompt Engineering 了。Prompt Engineering 就是专门用来研究怎么把话说清楚的。还是用之前的例子，让我们重新设计一下这个问答流程。按照 Prompt Engineering 的理念，我们需要发送的 Prompt 就应该是这样子的：”帮我的橘色小猫起名，两个字，需要体现出它活泼爱玩的性格。”这个时候大模型就可以给出一些更让你满意的名字了，比如说是”橘宝”——代表橘色的大活宝；”橙豆”——橙色的小豆子。你想小豆子掉在地上蹦蹦跳跳的，那也能够体现出猫活泼的性格嘛。你看这两个名字就跟你的猫更贴切了。

没错，说白了呢就是一门调整大模型提示词的技术。对，就是这么简单。

不过如今 Prompt Engineer 已经很少被单独提起了。一方面它的门槛实在是太低了，另一方面模型本身的能力呢也变得更强了，很多时候不需要在 Prompt 上调来调去就能给出不错的回答。

好，这就是 Prompt Engineering。

下面呢我们来看看 Context Engineering。暂时呢我们还是用小猫来举例。假设你拿到了小猫的名字之后，还继续跟大模型聊天，比如你问它：”那它平时吃什么好呢？”这个呢就是我们的 Prompt 了，我们来把它当作 Prompt 标出来。

那现在重点来了，我们此时要发给大模型的，其实不仅仅有这个 Prompt，还有之前的对话历史。这样大模型才知道这个新问题里面的”它”指代的是什么。

那无论是 Prompt 还是对话历史，它们呢都是大模型所接收到的信息。我们把大模型所接收的所有信息起个名字，就叫做 Context。当然 Context 的内容呢还不只有这两个，它还包含工具列表、Skill 列表等等，我们就不一一列举了，你也不用太关心。你只需要知道 Context 是有容量上限的，所以我们不可能无止境地往里面塞东西。

我们需要精心设计 Context 里面的内容，这个呢就叫做 Context Engineering。Context Engineering 有很多具体的方法，比如说其中一个非常经典的技术就是上下文压缩。之前不是说我们会把对话历史放在 Context 里面吗？我们跟模型越聊越多，对话历史呢也会越来越多。当超过某个阈值的时候，我们就可以使用上下文压缩技术，把之前的对话历史做个总结，以防止 Context 里面的内容过多影响回答效果。

当然除了上下文压缩之外，Context Engineering 还有很多其他的方法，比如说什么动态解锁外部资料、前提是披露等等，这里呢就不一一列举了。可以看出 Context Engineering 还是挺能整活的，搞出了这么多个东西。

不过吧这依然不是终点，因为大家发现 Context Engineering 这门技术的效果呢是有一定的上限的。为了进一步榨干大模型的潜力呢，AI 却又整出了新花样，这个就引出了我们今天真正的主角——Harness Engineering。

要搞明白 Harness Engineering 这个概念，我们就得先从 Harness 这个单词说起。这个词在日常生活中其实不太常见，很多人可能也是第1次听说。Harness 这个词的本意其实是马具的意思。大家看这是一匹马，而 Harness 或者说是马具，就是套在马身上用来控制马的那些装备，比如说是缰绳、笼头。

好，这些马虽然非常强大，但是我们必须借助马具的力量来限制马的活动，这样呢我们才能够让马为我们人类所用。

好，现在呢我们把马具从马身上单独拆下来做一个类比。左边这匹脱掉马具的马，对应的就是AI领域里面的大模型。你想大模型是不是特别强？尤其是像 GPT-4o 这样顶级模型，能干的事情可太多了。但大模型就像马一样，如果我们不对它加以干预，任由大模型自己去运行和发挥，那它就会像脱缰的野马一样发散思维，甚至产生严重的幻觉，最终根本无法稳定地给我们想要的结果。

所以呢我们必须要把大模型给控制住，就像用马具来控制马一样。

下面这套用来控制大模型的系统就被称为了 Harness。

没错，Harness 就对应了这个马具。

好，Harness 呢就是 Agent 里面用来控制和驾驭大模型的系统。所以呢从这一点出发，我们就能推导出 Harness 的公式，也就是 Harness = Agent − Model。换句话说，一个完整的 Agent 减去里面的大模型，剩下的所有东西都是 Harness。不过需要注意的是，Harness Engineering 是一个非常新的概念，目前业界呢还没有形成严格的定义，这个公式只是目前大多数人比较认可的一种说法，并非是严格的学术定义。所以只要不是大模型就是 Harness，关于这点呢我相信你已经明白了。

下面呢我们来看个具体的例子。我们可以用 Claude Code 来举例。在 Claude Code 里面，所有不属于 Claude 模型的部分都是 Harness。比如说是写在 CLAUDE.md 里面那些大模型要遵循的规则、Claude 可以使用的工具，或者是它的定时调度机制等等，这些呢都是 Harness。当然 Harness 设计的范围很广，我这里只是举了三个例子而已。

总而言之，只要不是模型，我们都可以将它视为 Harness 的一部分。

Harness 了解了，顺理成章地，Harness Engineering 的概念也就呼之欲出了。

Harness Engineering 呢就是一门专门研究如何构建与设计 Harness 的技术。换句话说就是除了大模型本身不研究，别的什么都研究。它不再是仅仅盯着模型输出的那点提示词或者是上下文，而是站在更高的系统层面上，研究怎么给大模型设计一套可以稳定运行的系统，让大模型能够踏踏实实地为我们人类做事。

所以从这里可以看出，Prompt Engineering、Context Engineering 和 Harness Engineering 更像是一种层层递进、研究范围不断向外扩展的关系。它们关注的问题呢是越来越大、越来越广。

• Prompt Engineering 研究的是怎么问问题。具体来说呢就是如何组织 Prompt，把发给大模型的话说得更清楚更准确，让模型能够更容易理解你的真实意图，并给出理想的结果。
• Context Engineering 呢研究的内容比 Prompt Engineering 更广一些，它研究的是怎么给信息。具体来说呢就是怎么在最合适的时机把最合适的内容放到模型的 Context 里面。Context 里面的内容呢不仅包括 Prompts，还包括工具列表、对话历史等等，所以呢 Context Engineering 的研究范围会更广一些。
• Harness Engineering 的研究范围呢就更加激进了，它研究的是如何搭建系统，也就是如何围绕着大模型搭建一个完整可靠的 Agent。它的研究对象呢直接就覆盖了除了大模型之外的所有内容，比如说什么权限管控、工具管理等等，都是 Harness Engineering 要研究的内容。

相信现在你已经了解了 Harness Engineering 是什么了，那 Harness Engineering 具体要做哪些事呢？有没有一些实战的例子？

说实话这个概念实在是太新了，目前业界呢也没有一个公认体系。与其我在这里自说自话，我们不如来直接看看大厂是怎么做的。

首先从 OpenAI 开始

2025年2月，OpenAI 内部启动了一个疯狂的实验，那就是用 AI 从0开始写一个真实的软件产品，全程不允许工程师手写一行代码。对没错，这个产品的所有组成部分都是由 AI 生成的，具体包括业务逻辑、测试、CI/CD、配置文档、内部工具等等，所有的东西都是 AI 生成的。靠着 AI，这个项目的代码规模直接是干到了将近100万行。而且注意了，这可不是一个玩具，它是一个真正在线上跑、有真实用户的生产系统。达到这样的规模呢，总体耗时只用了5个月左右。团队规模一开始呢是三个人在主导，后来呢也只不过是扩张到了7个人，算下来呢开发效率差不多是纯人工的10倍了。

但有意思的是，这个实验一开始的进展并不顺利。这并不是因为大模型不够聪明，而是因为 Harness 没有搭建好。工程师们发现 Agent 经常走错方向，甚至重复犯同一个错误。于是他们意识到，要想让 Agent 可靠地工作，真正的功夫呢在于把 Harness 设计好。为此呢他们做了大量的优化，并且写了一篇文章详细记录了这个过程。

这篇文章呢我反复读了好几遍，它的信息量非常大，涉及到很多 Harness Engineering 的优化点。所以呢这期视频我们就来重点聊一聊 OpenAI 在 Harness Engineering 上面到底做了什么。原文呢是从多个具体的优化点里面展开的，信息密度非常高。所以呢这里我尝试给这些优化点大致分了个类，分别是：上下文管理、验证与反馈和技术债清理。当然需要强调的是，这只是我个人所做的一个分类，主要是为了帮助大家理解。

下面呢我们就来一一看看这三大类到底是在做什么。

一、上下文管理

上下文管理的主要目标呢是让 Agent 获取到足够充足的信息。

你可以想象一下一个新入职的工程师，如果对项目一无所知，不清楚模块怎么划分，不知道代码规范是什么，不了解团队过去做过哪些技术决策，那他是根本就没有办法开始工作的。Agent 呢也是如此。

为了解决这个问题，OpenAI 最初的尝试是把所有的项目规范和相关信息塞进一个超大的 Agent.md 文件。这个文件呢会随着用户的问题一起发给大模型，这样大模型就有了充足的信息了。

不过 OpenAI 后来发现呢，使用一个大而全的 Agent.md 文件根本无法解决问题，原因呢是有很多。这里呢说两个最关键的：

第1个是内容太多，使得模型的效果变差。设想一下你第1天去新公司报到，HR 直接丢给你一个巨厚的员工手册，说”规矩全在这里，你自己看吧”。那我猜你肯定是一脸懵的，完全不知道该从哪里看起，也完全搞不清楚重点在哪。AI 呢也是一样，一股脑地把所有的信息全部都喂给它，那它就迷失了，只能抓到一些碎片，真正关键的内容反而被淹没在了废话里。

第2点呢是这个文件会逐步地固化。项目是在不断演进的，文件里面的内容却没有人及时更新，时间一长呢就变成了一堆过时信息的垃圾堆。更糟糕的是这个文件乱到连人都懒得去整理，那 AI 呢也就没有办法判断哪些内容还有效了。

所以呢他们后来改变了策略，把 Agent.md 文件压缩到只有100行左右，大体结构呢差不多就是这样子的。可以看出 Agent.md 里面呢已经没有什么太多实质性的内容了，就是一个目录而已。对应的文件系统呢大致是这个样子的。可以看出相关的文档和目录呢会跟 Agent.md 放在一起，这样呢效果就会好很多。看来大模型跟人一样，还是要把信息分门别类地摆好才行。

除此之外，OpenAI 还发现了一个问题：项目里面有很多重要的信息，其实并不在代码仓库里面。它们可能是散落在 Slack 的聊天记录里，可能是躺在某个 Google Doc 的文档里，甚至呢是只存在于某个老员工的脑子里面。这点呢我相信大家也深有体会，只不过可能用的是国内的软件生态，而不是说什么 Slack、Google Doc。

AI 只能看见仓库里面有什么，仓库外面的一切对它来说都跟不存在没有什么区别。所以 OpenAI 是怎么做的呢？他们是强制要求把所有重要的决策和约定都搬进代码仓库，让仓库成为唯一的事实来源（Single Source of Truth）。这样的 Agent 呢就可以了解到这些外部的信息了。

那这个呢就是上下文管理方面所做的事情了。

二、验证与反馈

做好了上下文管理，有了充足的信息之后，Agent 呢就可以写代码了。后面的重点呢就是在 Agent 写好代码之后，让它能够验证自己的成果是否正确。不然呢它写完之后没法验证，那这肯定是没有办法保证准确率的。

OpenAI 的做法呢是给 Codex 配上足够完善的工具和 Skill。在这些工具的帮助下，Codex 就能够在任务进行中随时验证自己的输出。

让我们举个例子。比如说他们把 Chrome DevTools 接入到了 Codex 的运行环境里面，这样呢 Codex 就可以自己截图、自己查看 DOM 结构，并且自己模拟用户操作，从而去验证 UI 是否符合用户的要求。如果发现这边有问题，那 Codex 就可以原地修复，整个过程呢就不需要人去介入了。

除了以外，OpenAI 还给 Codex 接入了完整的可观测性工具栈，以便让 Codex 可以读取日志、读取指标，并在必要的时候追踪运行链路以排查问题。为了确保日志和输出的准确性，Codex 的每个任务都跑在一个完全隔离的环境里，有自己独立的日志和指标，任务结束之后呢也能自动销毁。

这样做了之后，OpenAI 甚至可以让 Codex 对系统做一些可量化的性能调优，比如说是要确保服务启动时间不能够超过800毫秒之类的。

上面所讲的这些呢都是为了保证 Codex 生成代码可以实现产品诉求。但很多时候我们对 Codex 生成代码本身还有一定的要求，比如说呢这些代码至少要符合项目架构上的规范。

OpenAI 把他们的系统分成好几层，并且规定了严格的依赖关系。从上到下分别是：UI → Runtime → Service → Report → Config Types。每一层都只能依赖它下面的层，依赖关系不能反了。比如说像 Report 层依赖 UI 层这样的事情是万万不能发生的。

OpenAI 呢是使用 Lint 和测试来避免类似的情况发生。我们一起来看看他们是怎么保证架构规范的。在 Agent 生成代码之后，Lint 或者测试便会开始检测代码是否合规。如果不合规的话，它便会报错，信息呢会发回到 Agent 那里。Agent 呢会根据报错信息去修改，改完之后再跑 Lint 或者测试。这样呢就形成了一个完整的自动闭环，不需要人工去介入。这个流程会重复个几次，直到某次检测之后，所有的规则、所有的测试全部通过。这样呢我们就拿到了一份符合架构要求的代码了。

好，这些呢就是验证与反馈这一部分的内容了。

三、技术债清理

Agent 在大规模生成代码的过程中，会不可避免地引入一些糟糕的设计模式，比如重复的代码、偏离架构规范的写法、不一致的命名之类的。慢慢积累下去的话呢，会把整个代码库搞得一团糟。

OpenAI 的解法呢是给技术债做一些垃圾回收，把这些问题通通解决掉。具体来说呢就是设置一个后台的 Codex 任务，定期去扫描整个代码库，找出其中偏离规范的地方，自动修改并提交，以便确保代码的质量始终维持在一个比较高的水准。

这个呢是对代码的清理和优化。除了代码之外，他们还对文档做了同样的事情。具体来说呢是他们设置了一个后台任务，定期扫描整个文档库，找出那些过时的、和实际代码对不上的文档，自动提交修复。所以你看，无论是代码还是文档，OpenAI 都有着一套对应的维护方案，两边呢都不会放任自流。

以上呢就是 OpenAI 所做的一些核心的 Harness Engineering 实践了。看完这些你可能有一个强烈的感觉：这哪里是在写代码呀，这完全就是在给 AI 构建干活的环境。人负责定方向、搭框架，具体干活的事情就全由 AI 来做了。

没错，这正是 OpenAI 这篇文章想要传达的最核心的理念。通过这5个月的疯狂实验，OpenAI 不仅跑通了这套100万行代码的系统，更重要的是他们在这个过程中重新定义了人类和 AI 在未来的工作边界。

在文章中 OpenAI 抛出了一个非常关键的断言：Humans steer, Agents execute。翻译过来就是：人类负责掌舵，Agent 负责干活。说白了，到了 Harness Engineering 这一步，人和 AI 的分工就彻底变了。

以前工程师要亲自下场，一行一行地写代码，遇到报错自己查，测试呢也要自己跑。但现在呢，人类更像是在掌舵——人负责定方向，给上下文制定规则，在关键的地方做判断。而那些真正重复的、琐碎的开发工作就交给 Agent 在 Harness 里面跑就好了。

基于这个全新的边界，OpenAI 紧接着就提出了第2个非常重要的观点。这个观点呢点明了软件工程师在 AI 时代的新职责。对应文章里面呢是这一段话，大致意思就是在说：虽然人类不再需要亲自手写代码，但软件工程的工作并没有消失，而是演变成了完全不同的形态。如今软件工程师的核心职责变了，变成了为 Agent 搭建稳定可靠的系统与框架，以此来尽可能地提高代码产出效率。

这两个观点呢可以说是 OpenAI 那篇文章的灵魂。它直接告诉我们，Harness Engineering 不仅仅是如何写好 Prompt 或者是如何管理上下文这么简单，它是在重塑整个软件工程的开发流程。

那以上就是 OpenAI 这场 Harness Engineering 实战的核心精髓了。

最后呢我想跟大家说明一下，为了帮助大家快速理清脉络、抓住核心思路，这篇文章呢我是做了一定的提炼和简化的。但必须要说，OpenAI 的这篇文章写得非常精彩，如果你对里面的技术细节感兴趣，强烈建议亲自去读一遍原文，相信一定会让你大受启发。

再来看看 Anthropic 的两篇相关文章

第1篇呢是去年11月发表的《Effective Harnesses for Long-Running Agents》，它讲述了如何配置环境，以便让 Agents 长时间自主运行。

第2篇呢是今年3月份发表的《Harness Design for Long-Running Application Development》，这篇文章呢可以理解为是第1篇文章的续集。它在第1篇文章的基础上对 Harness 架构做了进一步的优化和调整，使其能够处理更多类型的任务，达到更好的效果。

这两篇文章的信息量很大，不过总结下来最核心的地方呢就两点：一个呢是跟任务规划有关，另外一个呢是跟质量评估有关。我们来一个一个看。

任务规划

首先来看一下任务规划这部分。在第1篇文章中，Anthropic 做了一个实验：直接让 Agent 执行一个任务——克隆 claude.ai（就是 Claude 的聊天界面，大致呢就是这个样子的，它跟 ChatGPT 是同类型产品）。虽然看起来只是一个聊天界面而已，但说实话它背后的功能还是挺多的，一口气做出来是一件几乎不可能做到的事情。这个呢也是 Anthropic 一开始所遇到的问题。

在 Anthropic 的实验里，Agent 呢接到需求之后立马就开干了，干劲非常的足，但是效果也非常不好。主要是因为这个需求的工作量实在是太大了，直接给到 Agent 的话，Agent 就会急于求成，从而引发一系列的问题。比如说它总想一口气把所有的功能全部做完，结果干到一半上下文就满了，直接抛下了烂摊子。等到下一个 Agent 接手的时候，完全不知道前面发生了什么，只能靠猜。这猜呢就坏事了——虽然有些功能只做了一半，但接手的 Agent 并不知道，粗略地扫了一眼还以为已经大功告成，于是直接宣布完工、草草收工了。

Anthropic 在第1篇文章里面写了对应的解法。他们呢是引入了一个叫做 Initializer Agent。从这个名字就可以看出来，这个 Agent 就是用来初始化执行环境的，比如说是拆解用户需求、编写启动脚本、添加进度文件等等。这里面最核心的就是拆解用户需求这一点。

具体来说就是把用户的需求拆解为一个详细的功能列表。后续负责干活的 Agent 呢就可以直接拿着这个功能列表去干活了。而且呢这个干活的 Agent 会一个功能点一个功能点地做，做完一个标记一个，这样稳扎稳打，整个流程的可控性就高了很多。

后来在写第2篇文章的时候，Anthropic 对这个思路做了一些演进。他们把 Initializer 里面最核心的一件事情，也就是拆解用户需求这个事情，单独给拿了出来，做成了一个新的 Agent 叫做 Planner。它负责把用户一句模糊的需求扩展成一份完整清晰的功能列表。这样后面的 Agent 在写代码的时候就不用对着用户的需求猜了，照着功能点一个个做就行。

好，那规划的问题解决了，这一部分的产物呢就是 Planner。

质量评估

下面呢我们再来看第2点——质量评估。

一般来说，光是让 Agent 生成代码是不够的，我们还需要对它生成的代码做一些质量评估，看看产出的东西到底行不行。如果产出质量不行的话，我们需要把对应的问题列表发回给 Agent，以便让它做相应的修改。这个呢才是一个比较合理的流程。

现在我们来看看具体是怎么做质量评估的。这里面呢有两种评估方案：

第1种是人工评估。这个就不太行了，效率太低了。都 AI 时代了，能交给 AI 的就都交给 AI 吧。

那这就引出了第2个方案——让 Agent 自评，也就是自己评估自己的产出，有问题就修，完再评，循环往复，直到合格为止。听起来挺合理的是吧？

但 Anthropic 发现这个方案根本不好用。原因很简单，Agent 自评这件事情本质上就是王婆卖瓜自卖自夸，它对自己做的东西天然就有滤镜。所以呢即使产出里面有明显的 Bug，它也能做到视而不见，给你打个高分之后就草草收工了。

所以呢 Anthropic 就直接把前面两种方案都给废弃了，搞出了第3个方案——那就是做一个专门的评估 Agent 来评估产出质量。由于这个评估 Agent 是一个独立的第三方，它自然就没有理由去替别的 Agent 的产出护短，评估结果呢也就客观多了。而且把评估 Agent 单独拎出来，还有一个好处，那就是我们可以单独去优化、去训练这个评估 Agent，让它的评估效果达到最好。

对，这个呢就是 Anthropic 最终方案了。换句话说，我们最终需要把生成代码和质量评估这两件事情给拆开，分别交给两个不同的 Agent 来做。其中负责生成代码的那个叫做 Generator，负责质量评估的那个叫做 Evaluator。这个呢就是最终的质量评估流程了。

所以质量评估这一环节，我们提到了两个 Agent：一个是评估用的 Evaluator，一个是生成代码用的 Generator。再加上之前说过的 Planner，我们就有三个 Agent 了。

时序图

下面呢我们来画一下时序图，看看这三个 Agent 是怎么分工合作完成用户需求的。

首先是 Planner，它会把用户的需求呢拆解为具体的功能列表，然后发送给 Generator。接收到功能列表之后，Generator 会从中挑选出一个功能点，然后呢它就着这个功能点去跟 Evaluator 讨论一下交付标准，也就是讨论下到底做到什么程度才算是完成了这个功能点。

Generator 呢首先会把它的想法发过去给 Evaluator。Evaluator 一开始可能会对这个提议提出一些修改意见，然后再发回给 Generator。Generator 呢会根据意见再次提交新的交付标准。所以呢这个过程会重复个几次，直到 Evaluator 确认 Generator 的提议没问题为止。

确认好交付标准之后，Generator 便开始生成代码来实现这个功能点了。实现完毕之后呢，Generator 会把它的实现结果提交给 Evaluator。Evaluator 会对结果做出评估反馈。比如说一开始可能评估不通过，但如果不通过的话呢，Generator 就要修改代码了。所以呢这个提交结果、评估反馈的过程也会重复个几次，直到 Evaluator 评估通过为止。

到这里一个功能点就算是开发完了。但是我们不只有一个功能点，所以呢我们就需要再次重复之前的这个流程，把后面的功能点全部都逐步做完。

这个呢就是大致的流程了。Anthropic 把这个包含了三个 Agent 的方案叫做 For Harness 方案。相比之下，那种只靠一个 Generator 独立完成所有需求的传统单 Agent 的模式，被 Anthropic 称为 Solo 方案。

Anthropic 拿了一个具体的任务来验证这两个方案的差距，这个任务呢就是做一个游戏制作工具。

从效果上来看，Solo 和 For Harness 这两个方案的差距还是很明显的。Solo 方案的问题呢很多，比如说是布局不合理、产品逻辑难以理解、Bug 到处都是，基本上呢是没有办法用的。

而 For Harness 方案呢就有了明显的改善。无论是布局还是整体的产品逻辑，都达到了可用的水准。虽然还是存在一些问题，但比起 Solo 方案来说，For Harness 的效果呢是明显好不少的。

当然这样做也不是没有代价的。For Harness 方案的耗时和花费都要明显地高于 Solo 方案。Anthropic 给出了一个对比表格，大家可以感受一下：

所以可以看出 For Harness 方案，无论是耗时还是花费，都要远高于 Solo 方案。虽然如此，但不得不承认 For Harness 的方案效果确实是好了不少。毕竟精雕细琢是有代价的呀。这对我们人类来说也是一样，考了60分可能只需要复习三天，但是想考到90分，那可能就得复习一个月了。这个大家多少都会有些体会吧。

最后再提一个事。后来做了优化点，让我们重新看一下这个流程图。注意其中的这一部分——这一部分说明了 Generator 每次只会选取一个功能点，做完这个功能点再做下一个，循环往复，直到完成所有的功能点为止。

这个逻辑呢是 Anthropic 在提示词里面强制指定这么处理的。否则让 Generator 自行发挥的话，它还是会急于求成，最后留下一个烂摊子。

不过在 Opus 4.6 发布了之后，这个约束就不怎么需要了。Anthropic 后面就把这一部分给去掉了，最后呢就简化成了这个样子。

那为什么后面就可以这么做了呢？因为基于 Opus 4.6，Generator 变得更强了。它可以一次把所有的功能点全部都拿过来，自己决定先做哪个再做哪个，稳步地向前推进，不需要别人再对它的执行流程指指点点。而在这种情况下，Evaluator 也直接评估最终产出就可以了，不需要再分功能点评估了。关于这一部分我们在下一章节还会提到，这里你有个大概的概念就行。

Harness Engineering 到底是不是噱头？

在这一章节里我们来聊聊目前争议最大的一个问题：Harness Engineering 到底是不是一个噱头？

要回答这个问题，我们不妨先来扒一扒这个词到底是怎么火起来的。

首先单就 Harness 这个词来说，它其实并不算是一个彻头彻尾的新词。一般大家用它来指代为了支持某个功能所做的一套框架。让我们来举几个具体的例子：

比如在传统的软件测试领域就有一个概念叫做 Test Harness，它代表为了支持测试代码运行而做的一套框架，这个框架里面可能会包含测试运行器、测试环境等等。而在 AI 领域，很多开发者其实也早就用到 Harness 这个词了，比如有开源的项目叫做 LM Evaluation Harness，它呢就是为了支持模型效果评估而做的一套框架。

不仅如此，我们刚才重点讲过 Anthropic 去年11月发表的一篇文章叫做《Effective Harnesses for Long-Running Agents》，这里的 Harness 就代表为了支持 Agent 的长时间运行而做的一套框架。

所以你看，Harness 这个词一直都在那，大家呢也都在默默地用，谁也没有觉得这是一个需要大吹特吹的新概念。可以说 Harness 这个词本身并不是重点，是 Harness Engineering——把这两个词组合在一起，其实是最近才发生的事情。

目前比较公认的起点就是我现在屏幕上所展示的这篇文章《My AI Adoption Journey》。这篇文章在今年2月5号的时候发表，作者是 Matt Harborn（可能国内有些同学对这个人不太熟悉，但在海外技术圈他绝对是响当当的人物，很多大公司的底层工具都是他做的）。在这篇博客里他写了这么一段话，这段话的大意就是说：”我也不知道业界有没有公认的叫法，我就姑且叫它是 Harness Engineering 吧。它的核心理念就是，只要 Agent 犯了错，你就去改造系统，让它绝不再犯同样的错误。要是有更好的词我随时改口。”

你看大佬呢还是很实诚的。所以呢这个词的起点其实非常朴素，甚至带着点随意，跟后来大家讨论的宏大概念还是有所区别的。

从传播情况来看，这篇文章的讨论热度其实并不算很高。那 Harness Engineering 这个词到底是怎么火起来的呢？

在很多人的认知里，真正引爆这个概念的是几天后，也就是2月11号 OpenAI 发的那篇 Harness Engineering 文章，就是我们之前讲过的那个。这个文章的信息量极大，迅速就在业界引起了巨大的反响。

紧接着整个 AI 圈就像触发了连锁反应。仅仅6天后，也就是2月17号，软件工程界鼎鼎大名的 Martin Fowler 网站就发表了一篇文章，作者是 ThoughtWorks 里面一个非常资深的工程师。文章的标题呢是叫做《Harness Engineering: First Thoughts》，讲的就是他读完了 OpenAI 那篇文章之后的第一反应。作为顶级技术博客，这篇文章一发出来自然就在圈内引发了广泛讨论。

但抛开技术观点不谈，它在文章里面还点出了一个很耐人寻味的细节：虽然 OpenAI 的这篇文章的标题有 Harness Engineering 这个概念，但如果你仔细区分 OpenAI 的文章，你会发现这篇文章的正文里面其实只提了一次 Harness 这个词。因此他就推测，OpenAI 搞不好就是受到了 Matt Harborn 的启发，事后呢才临时把 Harness Engineering 这个词放到了标题里面。

虽然这只是个猜测，但也给人带来了很大的联想空间。

随后到3月10号的时候，Anthropic 发表了一篇文章叫做《The Anatomy of an Agent Harness》。这篇文章第1次明确给出了关于 Harness 的公式，就是这个 Agent = Model + Harness。这个公式呢其实就是我们前面所聊过的那个等式的变体。当时呢我们是把 Harness 移到了等号的左边，我们讲的是 Harness = Agent − Model。这两个等式呢其实本质上就是一回事。公式一出，概念呢就算是定调了。

随后在3月24号的时候，Anthropic 发表了那篇 Harness 的文章，拿出了 Planner、Generator 和 Evaluator 的经典架构——这个我们之前也讲过。虽然 Anthropic 自己比较克制，通篇只用了 Harness 这个名词，并没有生搬硬套 Harness Engineering 这个刚刚炒热的新词，但在当时那个氛围下，整个 AI 圈可以说是心照不宣，直接就把这套三个 Agent 的架构当成了 Harness Engineering 的教科书级案例。

就这样一传十、十传百，Harness Engineering 就从一个私人说法变成了一个大家都在用的词。

不过如果你复盘完这段历史再仔细地琢磨一下，就会发现一件非常微妙的事情，那就是 Harness Engineering 里面所用到的所有技术，竟然没有一个是新的。你看我们前面所讲的 Lint、代码检查、任务拆解、规划、质量评估机制，这些东西其实早就有了，相信看这个视频的很多观众甚至都在做相关的工作。

Harness Engineering 真正做的呢，只不过是把这些技术重新组织一下，统一放到了一个新词的下面。换句话说，它提供的是一套新的系统思维架构，而不是发明了一批颠覆性的新技术。

既然没什么新技术，那难怪有些人会觉得 Harness Engineering 这个概念被高估了，甚至带着点炒作的成分。

仔细听听这些人的想法，你会发现他们的攻击点呢主要是有两个：

一方面，正像我们前面所聊过的，Harness Engineering 根本就没有什么新东西，全都是新瓶装旧酒。在这种情况下特意造个新词到处宣传，这不就是噱头吗？

不仅如此，这些人呢还提出了一个更扎心的观点：所有的 Harness Engineering 都是迟早要被淘汰的。

他们认为，随着大模型自身能力的持续优化，今天看起来必不可少的这些 Harness 的设计，未来很有可能会被模型能力本身逐步吸收，最终变得不再需要。而这种担忧其实连 Anthropic 自己的文章里都有迹可循。前面我们讲过 Anthropic Harness 核心方案，但文章里面还有很多细节值得细细品味。

这里我们仔细研究一下其中的两个问题，然后分别看看 Anthropic 一开始用 Harness 是怎么解决的，以及后来模型强大了之后是如何用模型来解决的。

第1个要探讨的问题就是上下文焦虑。 这个呢是 Sonnet 4.5 的一个问题。具体来说就是当上下文过长时，模型会急于结束任务，以更少的 Token 完成交互，而这个呢往往会影响最终质量。Anthropic 一开始是使用了一种叫做”上下文重置”的内在生成技术来解决这个问题。但后来当模型升级到更强的 Opus 4.5 之后，这种现象被大幅缓解，因为 Opus 4.5 没有明显的上下文焦虑问题了，也就不怎么需要这方面的 Harness 设计。

第2个相关的问题呢是长任务的执行效果差。 这一点呢其实我们在上一个章节也提过。让我们一起来回忆一下，Anthropic 的链路呢包含了 Planner、Generator 和 Evaluator 三个 Agent。一开始的设计呢是逐个功能点执行，也就是说 Anthropic 会在提示词里面强制 Generator 每次只选取一个功能点，做完一个再做下一个，以便确保整个产品开发流程稳步向前推进。

不过等用到更强的 Opus 4.6 之后，这种强制分布执行的机制呢就不再需要了。因为 Opus 4.6 的全局统筹能力够强，它可以一次把所有的功能点都拿过来，自己决定先做哪个再做哪个，稳步向前推进，不再需要别人对它的执行流程指指点点了。

你看这就说明了一个非常现实的趋势：模型越强，所需要的 Harness 就越少。 模型能力的提升正在一点点吃掉 Harness Engineering 的生存空间。

当然为了严谨起见，我需要补充一句：Anthropic 官方在文章里面其实并没有这么悲观。他们认为随着模型变强，Harness 的形态也会跟着进化，以便去解锁更复杂的任务。也就是说 Harness 只会变形而不会消失。

但我们不妨大胆推演一下，如果未来的模型真的强到离谱呢？这并不是说未来连读写文件、联网搜索这种基础的工具都不需要了，而是说也许只要给大模型配置上最基础的 Harness，它自己就能够把剩下99%的问题全部都给搞定。真到了那一天，Harness Engineering 可能就不再是一门需要大家专门去钻研的技术了，它会退化成一个单纯的环境配置，一个底层的基础设施。

仔细想想，这件事情发生的概率恐怕没有那么低吧。

那说了这么多，Harness Engineering 到底是不是噱头？

这里我来聊一下我个人的看法，可能有误，仅供参考。

我的观点是：Harness Engineering 不是噱头，但应该也不是终局。

说它不是噱头，是因为它已经实实在在地带来了效果。无论是 OpenAI 还是 Anthropic，都通过 Harness Engineering 把 Agent 的稳定性、自动化程度和生产力往前推了一大步。这些呢都是可以被验证的工程成果，而不是概念炒作。

当然你可以说这只不过是新瓶装旧酒嘛，用的都是一些老技术。但问题在于，工程领域真正的进步往往不在于发明了什么新技术，而在于有没有一套统一的框架，把这些零散的能力组织起来，变成可以系统设计、可以持续优化的工程方法。Harness Engineering 的意义恰恰就在这里。

但我不得不承认，Harness Engineering 大概率也不是终局。随着模型能力继续增强，今天这些用来约束模型、纠正模型、给模型兜底的系统设计方案，很有可能会被模型自身逐步吸收。到那个时候，很多 Harness 可能会变得不再需要，这个词呢也许也会慢慢地淡出大家的视野。

所以呢我更愿意把 Harness Engineering 看成是一个过渡期的关键技术。它呢可能不是未来的终局答案，但它是当下最现实的答案。因为在今天，模型依然会犯错，依然会有幻觉，依然会在复杂的任务中偏离轨道。在这种现实下，Harness Engineering 的重要性就不容忽视。

可以说，谁能够把 Harness 搭得更稳，谁就能够更早地把 AI 的能力转换为真正的生产力，从而从中受益。

参考资料