目录前言1. 本期内容概览2. Prompt Engineering 和 Context Engineering3. Harness Engineering 是什么4. Harness Engineering 实战来自 OpenAI5. Harness Engineering 实战来自 Anthropic6. Harness Engineering 是噱头吗结语参考前言学习 UP 主 马克的技术工作坊 的 Harness Engineering 到底是什么概念、实战与争议一次全部讲清楚 视频跟着马克叔来了解下最近 AI 圈非常火的 Harness Engineering记录下个人学习笔记和大家一起分享交流videoHarness Engineering 到底是什么概念、实战与争议一次全部讲清楚referencehttps://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 EngineeringContext 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 实战来自 OpenAI2025 年 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 的文档里甚至呢是只存在于某个老员工的脑子里面这点相信大家也深有体会只不过可能用的是国内的软件生态而不是说是什么 SlackGoogle 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、ServiceRepo、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.aiclaude.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它会把用户的需求拆解为具体的功能列表然后发送给 GeneratorGenerator 接收到功能列表之后它会从中挑选出一个功能点然后呢他就就着这个功能点去跟 Evaluator 讨论下交付标准也就是讨论下到底做到什么程度才算是完成了这个功能点。Generator 呢首先会把它的想法发过去Evaluator 呢一开始可能会对这个提议提出一些修改意见然后再发回给 GeneratorGenerator 呢会根据意见再次提交新的交付标准所以呢这个过程会重复个几次直到 Evaluator 确认 Generate 的提议没问题为止确认好交付标准之后 Generator 便开始生成代码来实现这个功能点了。实现完毕之后呢Generator 会把它的实现结果提交给 EvaluatorEvaluator 会对结果做出评估反馈比如说是一开始可能评估不通过那如果不通过的话呢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 到底是什么概念、实战与争议一次全部讲清楚