企业官网建设流程全解析

前言

学习 UP 主 马克的技术工作坊 的 Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚 视频，跟着马克叔来了解下最近 AI 圈非常火的 Harness Engineering，记录下个人学习笔记，和大家一起分享交流😄

video：Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚

reference：https://chatgpt.com/

1. 本期内容概览

继 Prompt Engineering、Context Engineering 之后，AI 圈最近又冒出了一个新名词，叫做 Harness Engineering，从今年 2 月份开始，这个词频繁的在 AI 圈里面出现。

OpenAI 专门发了一篇文章 [article]，讲他们怎么用 Harness Engineering 在五个月内写了将近 100 万行代码。

Anthropic 也紧接着发文 [article]，分享了自己如何使用精心设计的 harness 架构来驱动 Agent 的开发应用。

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

但与此同时，也有不少人认为，这不过是个噱头而已，换汤不换药，那 Harness Engineering 到底是什么，它跟 Prompt Engineering 和 Context Engineering 又有什么关系呢，Harness Engineering 是真正的技术突破，还是说只是 AI 圈又在炒概念，这期内容我们就来把这个事情彻底搞明白。

2. Prompt Engineering 和 Context Engineering

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

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

举个具体点的例子，比如说我们可以向大模型发问，帮我的猫起个名字，这个问题就是 Prompt 了，接到 Prompt 之后，大模型就会给你一个答案，比如说是什么花花呀，小白呀之类的，不过这些答案可能都无法让你满意，因为你家的猫呢可能是橘色的，无论是花花还是小白，都与橘色这个颜色相冲突，那为什么大模型会给你错误的答案呢，这是因为我们没有在 Prompt 里面给大模型充足的信息，既然问题出在 Prompt 上面，那解决问题的关键自然也在 Prompt 上面了。

说得再具体一点，那就是我们需要学会如何更精准的表达自己的需求，这个呢就引出 Prompt Engineering 了，Prompt Engineering 就是专门用来研究怎么把话说清楚的，还是用之前的例子，让我们重新设计一下这个问答流程，按照 Prompt Engineering 的理念，我们需要发送的 Prompt 就应该是这样子的：帮我的橘色小猫起名，两个字，需要体现出它活泼爱玩的性格。

这个时候大模型就可以给出一些更让我满意的名字了，比如说是橘宝，代表橘色的大活宝，橙豆，橙色的小豆子，你想小豆子掉在地上蹦蹦跳跳的，那也能够体现出猫活泼的性格嘛，你看这两个名字就跟你的猫更贴切了。

没错，说白了呢，Prompt Engineering 就是一门调整大模型提示词的技术，对就是这么简单，不过如今 Prompt Engineering 已经很少被单独提起了，一方面它的门槛实在是太低了，另一方面呢，模型本身的能力也变得更强了，很多时候不需要在 Prompt 上调来调去也能给出不错的回答。

OK，这就是 Prompt Engineering 了，下面呢我们来看看Context Engineering：

我们还是用小猫来举例啊，假设你拿到了小猫的名字之后，还继续跟大模型聊天，比如你问它，那它平时吃什么好呢，这个呢就是我们的prompt了，我们来把它单独标出来，那现在重点来了，我们此时要发给大模型的，其实不仅仅有这个 Prompt，还有之前的对话历史，这样大模型才知道这个新问题里面的它指代的是什么，那无论是 Prompt 还是对话历史，它们呢都是大模型所接收到的信息，我们把大模型所接收的所有信息起个名字，就叫做Context。

当然 Context 的内容呢还不只有这两个，它还包含工具列表、Skill 列表等等，我们就不一一列举了，你也不用太关心，你只需要知道Context 是有容量上限的，所以我们不可能无止境的往里面塞东西。

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

当然除了上下文压缩之外，Context Engineering 还有很多其他的方法，比如说什么动态检索外部资料啊，间接式披露啊等等，这里呢就不一一列举了。

可以看出 Context Engineering 还是挺能整活的，搞出了这么多的东西，不过吧这依然不是终点，因为大家发现啊 Context Engineering 这门技术的效果呢是有一定的上限的，为了进一步榨干大模型的潜力呢，AI 圈又整出了新花样，这个就引出了我们今天真正的主角 Harness Engineering。

3. Harness Engineering 是什么？

要搞明白 Harness Engineering 这个概念，我们就得先从Harness这个单词说起，这个词在日常生活中其实不太常见，很多人可能也是第一次听说，Harness 这个词的本意啊其实是马具的意思。

大家看啊，上图中有一匹马，而 Harness 或者说是马具就是套在马身上用来控制马的那些装备，比如说缰绳啊、头套啊这些，虽然马非常强大，但是我们必须借助马具的力量来限制马的活动，这样呢我们才能够让马为我们人类所用。

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

所以呢我们必须要把大模型给控制住，就像用马具来控制马一样，而这套用来控制大模型的系统，就被称为了 Harness，没错 Harness 就对应了这个马具。

好，Harness 就是 Agent 里面用来控制和驾驭大模型的系统，所以从这一点出发，我们就能推导出 Harness 的公式，也就是Harness = Agent - Model，换句话说，一个完整的 Agent 减去里面的大模型，剩下的所有东西都是 Harness。

不过需要注意的是，Harness Engineering 是一个非常新的概念，目前业界还没有形成严格的定义，这个公式只是目前大多数人比较认可的一种说法，并非是严格的学术定义，所以只要不是大模型就是 Harness，关于这一点相信你已经明白了，下面我们来看个具体的例子，我们可以用 Claude Code 来举例：

在 Claude Code 里面，所有不属于 Claude 模型的部分都是 Harness，比如说是写在 CLAUDE.md 里面那些大模型要遵循的规则；Claude Code 可以使用的工具或者是它的定时调度机制等等，这些都是 Harness，当然 Harness 涉及的范围很广，我们这里只是举了三个例子而已，总而言之只要不是模型，我们都可以将它视为 Harness 的一部分。

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

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

Prompt Engineering 研究的是怎么问问题，具体来说就是如何组织 Prompt 把发给大模型的话说得更清楚、更准确，让模型能够更容易理解你的真实意图，并给出理想的结果。

Context Engineering 研究的内容比 Prompt Engineering 更广一些，它研究的是怎么给信息，具体来说就是怎么在最合适的时机把最合适的内容放到模型的 Context 里面，Context 里面的内容不仅包括 Prompt 还包括工具列表，对话历史等等，所以 Context Engineering 的研究范围会更广一些。

Harness Engineering 的研究范围就更加激进了，它研究的是如何搭建系统，也就是如何围绕着大模型搭建一个完整可靠的 Agent，它的研究对象直接就覆盖了除了大模型之外的所有内容，比如说什么权限管控，工具管理等等，都是 Harness Engineering 要研究的内容。

相信现在大家已经了解了 Harness Engineering 是什么了，那 Harness Engineering 具体要做哪些事呢，有没有一些实战的例子，说实话，这个概念实在是太新了，目前业界也没有一个公认的体系，与其在这里自说自话，我们不如来直接看看大厂是怎么做的，我们首先从 OpenAI 开始。

4. Harness Engineering 实战（来自 OpenAI）

2025 年 8 月，OpenAI 内部启动了一个疯狂的实验，那就是用 AI 从零开始写一个真实的软件产品，全程不允许工程师手写一行代码，对，没错，这个产品的所有的组成部分都是由 AI 生成的：

具体包括业务逻辑，测试，CI 配置，文档，内部工具等等，所有的东西都是 AI 生成的，靠着 AI 这个项目的代码规模直接是干到了将近 100 万行，而且注意了这可不是一个玩具，它是一个真正在线上跑，有真实用户的生产系统，达到这样的规模总体耗时只用了 5 个月左右，团队规模一开始是 3 个人在主导，后来也只不过是扩张到了 7 个人，算下来，开发效率差不多是纯人工的十倍了。

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

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

下面我们就来一一看看，这三大类到底是在做什么，首先是上下文管理，上下文管理的主要目标是让 Agent 获取到足够充足的信息，你可以想象一下，一个新入职的工程师，如果对项目一无所知，不清楚模块怎么划分，不知道代码规范是什么，不了解团队过去做过哪些技术决策，那他是根本就没有办法开始工作的，Agent 也是如此。

为了解决这个问题，OpenAI 最初的尝试是把所有的项目规范和相关信息塞进一个超大的 AGENTS.md 文件，这个文件会随着用户的问题一起发给大模型，这样大模型就有了充足的信息了，不过 OpenAI 后来发现使用一个大而全的 AGENTS.md 文件根本无法解决问题，原因有很多，这里说两个最关键的：

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

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

所以他们后来改变了策略，把 AGENTS.md 文件压缩到只有 100 行左右，大体结构差不多就是下面这样子的：

可以看出，AGENTS.md 里面已经没有什么太多实质性的内容了，就是一个目录而已，对应的文件系统大致是上面这个样子的，可以看出相关的文档和目录会跟 AGENTS.md 放在一起，这样用到哪块再给 Agent 看哪块效果就会好很多，看来大模型跟人一样，还是要把信息分门别类的放好才行。

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

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

那这个就是上下文管理方面所做的事情了，下面我们来看看验证和反馈部分在做什么。

做好了上下文管理，有了充足的信息之后 Agent 就可以写代码了，后面的重点就是在 Agent 写完代码之后，让它能够验证自己的成果是否正确，不然它写完之后没法验证，那这肯定是没有办法保证准确率的，OpenAI 的做法呢是给 Codex 配上足够完善的工具和 Skill，在这两者的帮助下 Codex 就能够在任务进行中随时验证自己的输出。

让我们举个例子：

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

除了 UI 之外，OpenAI 还给 Codex 接入了完整的可观测性工具栈，以便让 Codex 可以读取日志，读取指标，并在必要的时候追踪运行链路以排查问题。为了确保日志和输出的准确性，Codex 的每个任务都跑在一个完全隔离的环境里，有自己独立的日志和指标，任务结束之后呢也能自动销毁，这样做了之后，OpenAI 甚至可以让 Codex 对系统做一些可量化的性能调优，比如说要确保服务启动时间不能够超过 800 毫秒之类的。

上面所讲的这些呢都是为了保证 Codex 生成代码可以实现产品诉求，但很多时候我们对 Codex 生成的代码本身还有一定的要求，比如说这些代码至少要符合项目架构上的规范，OpenAI 把他们的系统分成了好几层，并且规定了严格的依赖关系，从上到下分别是 UI、Runtime、Service，Repo、Config、Types，每一层都只能依赖它下面的层，依赖关系不能反了，比如说像 Repo 层依赖 UI 层这样的事情是万万不能发生的，OpenAI 是使用 linter 和测试来避免类似的情况发生，我们一起来看看他们是怎么保证架构规范的：

在 Agent 生成代码之后，linter 或者是测试便会开始检测代码是否合规，如果不合规的话它便会报错，报错信息会发回到 Agent 那里，Agent 会根据报错信息去修改，改完之后再跑 linter 或者测试，这样就形成了一个完整的自动闭环，不需要人工去介入，这个流程会重复个几次，直到某次检测之后，所有的规则所有的测试全部通过，这样我们就拿到了一份符合架构要求的代码了。

OK，这些就是验证与反馈这部分的内容了，下面我们来看看技术债清理这部分在做什么。

Agent 在大规模生成代码的过程中，会不可避免地引入一些糟糕的设计模式，比如说重复的代码，偏离架构规范的写法，不一致的命名之类的，慢慢积累下去的话会把整个代码库搞得一团糟，OpenAI 的解法是给技术债做一些垃圾回收，把这些问题统统解决掉。具体来说就是设置一个后台的 Codex 任务，定期去扫描整个代码库，找出其中偏离规范的地方，自动修改并提交，以便确保代码的质量，始终维持在一个比较高的水准，这个是对代码的清理和优化。

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

以上就是 OpenAI 所做的一些核心的 Harness Engineering 实践了，看完这些你可能有一个强烈的感觉，这哪里是在写代码呀，这完全就是在给 AI 构建干活的环境啊，人负责定方向搭框架，具体干活的事情就全由 AI 来做了，没错，这正是 OpenAI 这篇文章想要传达的最核心的理念，通过这五个月的疯狂实验，OpenAI 不仅跑通了这套 100 万行代码的系统，更重要的是，他们在这个过程中，重新定义了人类和 AI 在未来的工作边界。

在文章中，OpenAI 抛出了一个非常关键的断言：Human steer. Agents execute.翻译过来就是人类负责掌舵，Agent 负责干活，说白了到了 Harness Engineering 这一步，人和 AI 的分工就彻底变了，以前工程师要亲自下场，一行一行地写代码，遇到报错自己查，测试也要自己跑，但现在人类更像是在掌舵，人负责方向，给上下文制定规则，在关键的地方做判断，而那些真正重复的琐碎的开发工作就交给 Agent 在 Harness 里面跑就好了。

基于这个全新的边界，OpenAI 紧接着又提出了第二个非常重要的观点，这个观点点明了软件工程师在 AI 时代的新职责，对应文章里面是下面这一段话：

这大致意思就是在说，虽然人类不再需要亲自手写代码，但软件工程的工作并没有消失，而是演变成了完全不同的形态，如今软件工程师的核心职责变了，变成了为 Agent 搭建稳定可靠的系统与支撑框架，以此来尽可能的提高代码产出效率。

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

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

5. Harness Engineering 实战（来自 Anthropic）

在这一章节里，我们来看看 Anthropic 的两篇与 Harness Engineering 相关的文章，第一篇 [article] 是去年 11 月发表的 Effective harnesses for long-running agents：

它讲述了如何配置环境以便让 Agent 长时间自主运行。

第二篇是今年 3 月份发表的 Harness design for long-running application development：

这篇文章可以理解为是第一篇文章的续集，它在第一篇文章的基础上对 Harness 架构做了进一步的优化和调整，使其能够处理更多类型的任务，达到更好的效果。

这两篇文章的信息量很大，不过总结下来最核心的地方就两点，一个是跟任务规划有关，另外一个是跟质量评估有关，我们来一个一个看，首先来看一下任务规划这部分，在第一篇文章中 Anthropic 做了一个实验，直接让 Agent 执行一个任务克隆 claude.ai，claude.ai 就是 Claude 的聊天界面，大致就是下面这个样子的：

它跟 ChatGPT 是同类型产品，虽然看起来只是一个聊天界面而已，但说实话它背后的功能还是挺多的，一口气做出来是一件几乎不可能做到的事情，这个呢也是 Anthropic 一开始所遇到的问题，在 Anthropic 的实验里，Agent 接到需求之后立马就开干了，干劲非常的足啊，但是效果也非常不好，主要是因为这个需求的工作量实在是太大了，直接给到 Agent 的话，Agent 就会急于求成，从而引发一系列的问题。

比如说它总想一口气把所有的功能全部做完，结果干到一半上下文就满了，直接抛下了个烂摊子，等到下一个 Agent 接手的时候，完全不知道前面发生了什么，只能靠猜，这一猜呢就坏事了，虽然有些功能只做了一半，但接手的 Agent 并不知道啊，粗略的扫了一眼还以为已经大功告成，于是直接宣布完工，草草就收工了。

Anthropic 在第一篇文章里面写了对应的解法，他们是引入了一个叫做 Initializer 的 Agent，从这个名字就可以看出来，这个 Agent 就是用来初始化执行环境的，比如说是拆解用户需求啊，编写启动脚本啊，添加进度文件啊等等，这里面最核心的就是拆解用户需求这一点，具体来说就是把用户的需求拆解为一个详细的功能列表，后续负责干活的 Agent 呢就可以直接拿着这个功能列表去干活了，而且呢这个干活的 Agent 会一个功能点一个功能点地做，做完一个标记一个，这样稳扎稳打，整个流程的可控性就高了很多。

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

OK，那规划的问题解决了，这一部分的产物就是 Planner，下面我们再来看第二点，质量评估。

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

现在我们来看看具体是怎么做质量评估的，这里面有两种评估方案，一种呢是人工评估，这个就不太行了，效率太低了，都 AI 时代了能交给 AI 的就都交给 AI 吧。那这就引出了第二个方案，让 Agent 自评，也就是自己评估自己的产出，有问题就修，修完再评，循环往复，直到合格为止。

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

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

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

所以质量评估这一环节我们提到了两个 Agent，一个是评估用的 Evaluator，一个是生成代码用的 Generator，再加上之前说过的 Planner，我们就有三个 Agent 了，下面呢我们来画一下时序图，看看这三个 Agent 是怎么分工合作完成用户需求的：

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

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

实现完毕之后呢，Generator 会把它的实现结果提交给 Evaluator，Evaluator 会对结果做出评估反馈，比如说是一开始可能评估不通过，那如果不通过的话呢，Generator 就要修改代码了，所以呢这个提交结果评估反馈的过程也会重复个几次，直到 Evaluator 评估通过为止，到这里一个功能点就算是开发完了。

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

Anthropic 把这个包含了三个 Agent 的方案叫做Full Harness 方案，相比之下那种只靠一个 Generator 独立完成所有需求的传统单 Agent 模式被 Anthropic 称为Solo 方案，Anthropic 拿了一个具体的任务来验证这两个方案的差距，这个任务呢就是做一个游戏制作工具。

从效果上来看啊，Solo 和 Full Harness 这两个方案的差距还是很明显的，Solo 方案的问题呢很多，比如说是布局不合理，产品逻辑难以理解，bug 到处都是，基本上呢是没有办法用的。而 Full Harness 方案呢就有了明显的改善了，无论是布局还是整体的产品逻辑都达到了可用的水准，虽然还是存在一些问题，但比起 Solo 方案来说，Full Harness 的效果是明显要好不少的，当然这样做也不是没有代价的，Full Harness 的耗时和花费都要明显的高于 Solo 方案，Anthropic 给出了一个对比表格，大家可以感受一下：

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

最后再提一个 Anthropic 后来做的优化点，让我们重新看一下前面的流程图，注意前面我们说 Generator 每次只会选取一个功能点，做完这个功能点再做下一个，循环往复直到完成所有的功能点为止，这个逻辑是 Anthropic 在提示词里面强制 Generator 这么处理的，否则让 Generator 自行发挥的话，他还是会急于求成，最后留下一堆烂摊子。

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

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

6. Harness Engineering 是噱头吗？

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

要回答这个问题，我们不妨先来扒一扒这个词到底是怎么火起来的，首先，单就 Harness 这个词来说，其实它并不算是一个彻头彻尾的新词，一般大家用它来指代为了支持某个功能所做的一套框架，让我们来举几个具体的例子：

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

不仅如此，我们刚才重点讲过 Anthropic 去年 11 月发表的一篇文章，叫做 Effective harnesses for long-running agents，这里的 Harness 就代表为了支持 Agent 长时间运行而做的一套框架，所以你看 Harness 这个概念一直都在那儿，大家也都在默默地用，谁也没有觉得这是个需要大吹特吹的新概念，Harness 这个词本身并不是重点，重点是 Harness Engineering，把这两个词组合在一起其实是最近才发生的事情，目前比较公认的起点，就是下面所展示的这篇文章 My AI Adoption Journey [article]

这篇文章在今年 2 月 5 号的时候发表，作者是 Mitchell Hashimoto，可能国内有些同学对这个人不太熟悉，但在海外技术圈，他绝对是响当当的人物，很多大公司的底层工具都是他做的，在这篇博客里，他写了这么一段话：

这段话的大意是说，我也不知道业界有没有公认的叫法，我就姑且管它叫 Harness Engineering，它的核心理念就是只要 Agent 犯了错，你就去改造系统，让它绝不再犯同样的错误，要是有更好的词，我随时改口，你看，大佬还是很实诚的，所以这个词的起点其实非常朴素，甚至带着点随意，跟后来大家讨论的宏大概念还是有区别的。

从传播情况来看，这篇文章的讨论热度其实并不算很高，那 Harness Engineering 这个词到底是怎么火起来的呢，在很多人的认知里，真正引爆这个概念的是几天后，也就是 2 月 11 号，OpenAI 发的那篇 Harness Engineering 文章，就是我们之前讲过的那个：

这篇文章的信息量极大，迅速就在业界引起了巨大的反响，紧接着整个 AI 圈就像触发了连锁反应，仅仅 6 天后，也就是 2 月 17 号，软件工程界鼎鼎大名的 Martin Fowler 网站就发了一篇文章 [article]，作者是 Thoughtworks 里一位非常资深的工程师，文章标题叫 Harness Engineering - first thoughts：

就是她读完 OpenAI 那篇文章之后的第一反应，作为顶级技术博客，这篇文章一发出来自然就在圈内引发了广泛的讨论，但抛开技术观点不谈，她在文章里面还点出了一个很耐人寻味的细节：

虽然 OpenAI 的这篇文章的标题有 Harness Engineering 这两个词，但如果你仔细去翻 OpenAI 的文章，你会发现这篇文章的正文里其实只提了一次 harness 这个词，因此她推测 OpenAI 搞不好就是受了 Mitchell Hashimoto 的启发，事后才临时把 Harness Engineering 这个词放到了标题里面，虽然只是个猜测，但也给人带来了很大的联想空间。

随后到 3 月 10 号的时候，LangChain 发表了一篇文章 [blog] 叫 The Anatomy of an Agent Harness：

这篇文章第一次明确给出了关于 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 里用到的所有技术竟然没有一个是新的，你看我们前面所讲的 Linter 代码检查、任务拆解规划、质量评估机制，这些东西其实早就有了，相信看这篇文章的很多读者甚至都在做相关的工作，Harness Engineering 真正做的只是把这些技术重新组织了下，统一放到了一个新词下面。

换句话说，它提供的是一套新的系统思维架构，而不是发明了一批颠覆性的新技术，既然没什么新技术，那难怪有些人会觉得 Harness Engineering 这个概念被高估了，甚至带着点 “炒作” 的成分，仔细听听这波怀疑论者的声音，你会发现他们的攻击点主要有两个：一方面，正像我们前面所聊过的 Harness Engineering 根本就没有什么新东西，全都是 “新瓶装旧酒”，在这种情况下，特意造个新词到处宣传，这不就是噱头吗。

不仅如此，这波怀疑论者还提出了一个更扎心的观点，所有的 Harness Engineering 都迟早要被淘汰，他们认为，随着大模型自身能力的持续进化，今天看起来必不可少的这些 Harness 设计，未来很可能会被模型能力本身逐步吸收，最终变得不再需要。而这种担忧，其实连 Anthropic 自己的文章里都有迹可循，前面我们讲过 Anthropic 的 Harness 核心方案，但文章里面还有很多细节很值得细细品味

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

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

第二个相关的问题是长任务的执行效果差，这点其实我们之前也提到过，让我们一起来回忆一下，Anthropic 的链路包含 Planner、Generator 和 Evaluator 3 个 Agent，一开始的设计是逐个功能点执行，也就是说，Anthropic 会在提示词里面强制 Generator 每次只选取一个功能点，做完一个再做下一个，以便确保整个产品开发流程稳步向前推进，不过，等用到更强的 Opus 4.6 之后，这种强制分步执行的机制就不再需要了,因为 Opus 4.6 的全局统筹能力够强，它可以一次把所有的功能点都拿过来，自己决定先做哪个再做哪个，稳步推进，不再需要别人对它的执行流程指指点点。

你看，这恰恰印证了一个非常现实的趋势，模型越强，需要的 Harness 就越少，模型能力的提升正在一口一口吃掉 Harness Engineering 的生存空间，当然，为了严谨起见，这里需要补充一句，Anthropic 官方在文章里面其实没这么悲观，他们认为，随着模型变强，Harness 的形态也会跟着进化，以便去解锁更复杂的任务，也就是说 Harness 只会变形而不会消失。

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

所以说了这么多，我们还得回归原来的问题 Harness Engineering 到底是不是噱头，这里 UP 聊了一下他个人的看法，可能有误，仅供参考，他的观点是Harness Engineering 不是噱头，但应该也不是终局。

说他不是噱头，是因为它已经实实在在的带来了效果，无论是 OpenAI 还是 Anthropic 都通过 Harness Engineering 把 Agent 的稳定性、自动化程度和生产力往前推了一大步，这些都是可以被验证的工程成果，而不是概念炒作。当然，也有人会说它不过是 “新瓶装旧酒”，用的都是一些老技术，但问题在于，工程领域真正的进步，往往不在于发明了什么新技术，而在于有没有一套统一的框架，把这些零散的能力组织起来，变成可以系统设计、可以持续优化的工程方法，Harness Engineering 的意义恰恰就在这里。

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

所以我更愿意把它看成是一个过渡期的关键技术，它可能不是未来的终局答案，但它是当下最现实的答案，因为让我们回到今天，模型依然会犯错，依然会有幻觉，依然会在复杂的任务中偏离轨道，在这种现实下，Harness Engineering 的重要性就不容忽视，可以说，谁能把 Harness 搭得更稳，谁就能够更早把 AI 的能力转换为真正的生产力，从而从中受益。

OK，以上就是本期想要分享的全部内容了。

结语

本篇文章我们跟着马克叔，从 Prompt Engineering、Context Engineering 一路聊到了如今 AI 圈非常火的 Harness Engineering，并结合 OpenAI 与 Anthropic 的真实工程实践，尝试从系统设计的视角去理解：为什么今天的大模型，已经不再只是一个 “聊天工具”，而正在逐渐演化为一个真正能够参与复杂任务执行的 Agent 系统。

如果回头再看 Prompt、Context、Harness 这几个概念，你会发现它们其实代表的是 AI 工程一条非常清晰的演进路线：Prompt Engineering 研究的是 “怎么把问题说清楚”；Context Engineering 研究的是 “怎么把正确的信息组织给模型”；而 Harness Engineering 则开始研究 “如何围绕模型构建一整套稳定可靠的执行系统”。

换句话说，AI 工程的关注点正在不断向外扩展：从一句 Prompt，到整个 Context，再到模型之外的完整系统架构。模型本身固然重要，但真正决定 Agent 能否稳定工作的，往往是整套 Harness 是否足够完善。

而无论是 OpenAI 的上下文管理、验证反馈与技术债清理，还是 Anthropic 的 Planner、Generator、Evaluator 多 Agent 架构，它们背后其实都在解决同一个问题：如何让一个本质上只会 “预测下一个 Token” 的模型，稳定地参与真实世界里的复杂工程任务。

某种意义上，这其实已经非常接近传统软件工程里的 “系统架构设计” 了，只不过这一次，系统中的核心执行者正在从 “人类程序员” 逐渐变成 “AI Agent”。

当然，Harness Engineering 大概率也不会是终局。随着模型能力不断增强，今天很多复杂的 Harness 设计，未来可能会被模型自身逐步吸收。但至少在当前阶段，模型依然会幻觉、会偏航、会忘记上下文，因此 Harness Engineering 依然是目前最现实、最有效的工程方案之一。

希望这篇笔记能够帮助大家真正理解 Harness Engineering 背后的核心思想：它也许不是某种全新的黑科技，但它正在重新定义 AI 时代的软件工程方式。🤗

参考

• Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚