harness-engineering是噱头吗？

AI 圈最近又冒出了一个新名词prompt-engineering、context-engineering之后从今年2月份开始这个词频繁的在 AI 圈里面出现。opening AI 专门发了一篇文章(https://openai.com/zh-Hans-CN/index/harness-engineering/)讲他们怎么用 Harness engineering在5个月内写了将近100万行代码。Anthropic 也紧接着发文分享了自己如何使用精心设计的 Harness 架构来驱动(https://www.anthropic.com/engineering/harness-design-long-running-apps)。不仅如此就连技术大牛 Martin Fowler 创立的技术网站 martinfowler.com也开始公开讨论起了 Harness engineering(Harness engineering for coding agent users)。但与此同时也有不少人认为这是一个噱头换汤不换药它跟 Prompt Engineering与context-enginneering又有什么区别Harness Engineering 是真正的技术创新还是AI圈在炒概念这篇文章会做一个详细的解释。在讲 Harness engineering 之前我们不妨先来讲讲它的两个前任分别是 prompt engineering 和 context engineering。对于这两个概念比较熟悉的同学可以直接跳到下一个章节。首先是 Prompt engineering这里的 prompt 你可以简单理解成用户发给大模型的话而 prompt engineering 就是一门研究怎么把这句话说清楚的技术。举个具体点例子比如说我们可以像大模型发问帮我的猫起个名字这个问题就是 prompt 了接到 prompt 之后大模型就会给你一个答案比如说是什么花花呀、小白之类的不过这些答案可能都无法让你满意因为你家的猫可能是橘色的。无论是花。那为什么大模型会给你错误的答案这是因为我们没有在 prompts 里面给大模型充足的信息既然问题出在 prompts 上面那解决问题的关键自然也在 prompts 上面了。说的再具体一点那就是我们需要学会如何更精准的表达自己的需求这个就引出 Prompt engineering 了Prompt engineering 就是专门用来研究怎么把话说清楚的还是用之前的例子让我们重新设计一下这个问答流程按照 prompts engineering 的理念我们需要发送的 prompt 就应该是这样子的。帮我的橘色小猫起名两个字需要体现出它老婆爱玩的性格这个时候大模型就可以给出一些更让我满意的名字了比如说是橘宝代表橘色的大活宝、橙豆橙色的小豆子你想小豆子掉在地上蹦蹦跳跳的也能够体现出猫活泼的性格吗你看这两个名字就跟你猫更贴切了。没错说白了 the prompts engineering 就是一门调整大模型提示词的技术。对就是这么简单。不过如今 prompt engineering 已经很少被单独提起了一方面它的门槛实在是太低了另一方面模型本身的能力也变得更强了很多时候不需要再 prompts 上调来调去能给出不错的回答。好就是 prompts engineering 了下面我们来。看看 context engineering我们还是用小猫来。举例假设你拿到了小猫的名字之后还继续跟大模型聊天比如你问它那它平时吃什么好这个就是我们的 prompt 了我们来把它单独标出来。那现在重点来了我们此时要发给大模型的其实不仅仅有这个 prompt还有之前的对话历史这样的大无情才知道这个新问题里面的他指代的是什么。那无论是 prompts 还是对话历史他们都是大模型所接收到的信息我们把大模型所接收的所有信息起个名字就叫做 context当然 context 的内容还不只有这两个它还包含工具列表、skill 列表等等我们就不一一列举了你也不用太关心你只需要知道 context 是有容量上限的。所以我们不可能无止境地往里面塞东西我们需要精心设计 context 里面的内容这个就叫做 context engineering。context engineering 有很多具体的方法比如说其中一个非常经典的技术就是上下文压缩。之前不是说我们会把对话历史放在 context 里面吗我们跟模型越聊越多对话历史也会越来越多当超过某个阈值的时候我们就可以使用上下文压缩技术把之前的对话历史做个总结以防止 context 里面的内容过多影响回答效果。当然除了上下文压缩之外context engineering 还有很多其他的方法比如说是什么动态检索、外部资料鉴定是纰漏等等这里就不一一列举了。可以看出 context engineering 还是挺能整活的搞出了这么多的东西。不过这依然不是重点因为大家发现 context engineering 是有一定的上限的为了进一步榨干大模型的潜力AI 却又整出了新花样这个就引出了我们今天真正的主角 Harness engineering。要搞明白 Harness engineering 这个概念我们就得先从 Harness 这个单词说起。这个词在日常生活中其实不太常见很多人可能也是第一次听说 Harness 这个词的本意其实是马具的意思大家看这是一匹马而 Harness 或者说是马具就是套在马身上用来控制。头套这些虽然马非常强大但是我们必须借助马具的力量来限制马的活动这样我们才能够让马为我们人类所用。好现在我们把马具从马身上单独拆下来做一个类比左边这匹脱掉马具的马对应的就是 AI 领域里面的大模型你想大模型是不是特别强尤其是像 GPT、Opus 这样顶级模型能干的事情可太多了但大模型就像马一样如果我们不对它加以干预任由大模型自己去运行和发挥那它就会像脱缰的野马一样发散思维甚至产生严重的幻觉最终根本无法稳定的给我们想要的结果。所以我们必须要把大模型给控制住就像用马具来控制马一样而这套用来控制大模型的系统就被称为了 Harness没错Harness 就对应了这个马具。好harness 就是 agent 里面用来控制和驾驭大模型的系统。所以从这一点出发我们就能推导出 Harness 的公式也就是 Harness 就等于 agent 减去 model换句话说一个完整的 agent 减去里面的大模型剩下的所有东西都是 Harness。不过需要注意的是Harness engineering 是一个非常新的概念目前业界还没有形成严格的定义这个公式只是目前大多数人比较认可的一种说法并非是严格的学术定义所以只要不是大模型就是 harness。关于这点我相信你已经明白了下面我们来看个具体的例子我们可以用 cloud code 来举例在 cloud code 里面所有不属于 cloud 模型的部分都是 Harness比如说是在 cloud MD 里面那些大模型要遵循的规则cloudcode可以使用的工具或者是它的定时调度机制等等。这些都是Harness当然 Harness设计的范围很广我这里只是举了三个例子而已。总而言之只要不是模型我们都可以将它视为Harness的一部分。那 Harness 了解了顺理成章的 Harness engineering 的概念也就呼之欲出了。Harness engineering 就是一门专门研究如何构建与设计 Harness 的技术换句话说就是除了大模型本身不研究别的什么都研究它不再是仅仅盯着模型书的那点提示词或者是上下文而是站在更高的系统层面上研究怎么给大模型设计一套可以稳定运行的系统让大模型能够踏踏实实地为我们人类做事。所以从这里可以看出 Prompt engineeringcontext engineering 和 Harness engineering 更像是一种层层递进研究范围不断向外扩展的关系他们关注的问题是越来越大越来越广engineering 研究的是怎么问题具体来说就是如何组织 prompt 把发给大模型的话说得更清楚、更准确让模型能够更容易理解你的真实意图并给出理想的结果。context engineering 研究的内容比 prompt engineering 更广一些它研究的是怎么给信息具体来说那就是怎么在最合适的时机把最合适的内容放到模型的 context 里面。context 里面的内容不仅包括 prompts还包括工具列表对话历史等等。所以 context engineering 的研究范围会更广一些。Harness engineering 的研究范围就更加基建了他研究的是如何搭建系统也就是如何围绕。要是大模型搭建一个完整可靠的 agent它的研究对象直接就覆盖了除了大模型之外的所有内容比如说是什么权限管控、工具管理等等都是 harness 内容。要研究的内容相信现在你已经了解了 Harness 是什么了那 Harness 具体要做哪些事呢有没有一些实战的例子说实话这个概念实在是太新了目前业界也没有一个公认的体系与其我在这里自说自话我们不如来直接看看大厂是怎么做的。我们首先从 Openai 开始。2025年8月Openai 内部启动了一个疯狂的实验那就是用 AI 从零开始写一个真实的软件产品全程不允许工程师手写一行代码。对没错这个产品的所有的组成部分都是由 AI 生成的具体是包括业务逻辑测试、CI 配置文档、内部工具等等所有的东西都是 AI 生成的靠着 AI 这个项目的代码规模直接是干到了将近100万行。而且注意喽这可不是一个玩具它是一个真正在线上跑有真实用户的生产系统达到这样的规模总体耗时只用了5个月左右团队规模一开始是3个人在主导后来也只不过是扩张到了7个人。算下来开发效率差不多是纯人工的10倍了。但有意思的是这个实验一开始的进展并不顺利这并不是因为大模型不够聪明而是因为 harness 没有搭建好。工程师们发现 agent 经常走错方向甚至重复犯同一个错误于是他们意识到要想让 agent 的可靠的工作真正的功夫在于把 Harness 设计好。为此那他们做了大量的优化并且写了一篇文章(https://openai.com/zh-Hans-CN/index/harness-engineering/)详细记录了这个过程这篇文章。我反复读了好几遍他的信息量非常大涉及到很多 Harness engineering 的优化点所以我们就来重点聊一聊 Openai 在 Harness engineering 上面到底做了什么。原文是从多个具体的优化点里面展开的信息密度非常高所以这里我尝试给这些优化点大致分了个类分别是。指上下文管理、验证与反馈和技术再清理。当然需要强调的是这只是我个人所做的一个分类主要是为了帮助大家理解下面我们就来一看看这三大类到底是在做什么。首先是上下文管理的主要目标是让 agent 获取到足够充足的信息你可以想象一下一个新入职的工程师如果对项目一无所知不清楚模块怎么划分不知道代码规范是什么不了解团队过去做过哪些技术决策那他是根本就没有办法开始工作的。agent 也是如此。为了解决这个问题Openai 最初的尝试是把所有的项目规范和相关信息塞进一个超大的 agent.md 文件这个会随之用户的问题一起发给大模型这样的大模型就有了充足的信息了。不过 Openai 后来发现使用一个大而全的 agent.md 文件根本无法解决问题原因是有很多这里说两个最关键的第一个是内容太多使得模型的效果变差。设想一下你第一天去新公司报到HR 直接嫁给你一个巨厚的员工手册说规矩全在这里你自己看吧。那我猜你肯定是一脸懵的完全不知道该从哪里看起也完全搞不清楚重点在哪AI 也是一样一股脑的把所有的信息全部都喂给他那他就迷失了只能抓到一些碎片真正关键的内容反而被淹没在了废话里。第二概念是这个文件会逐步的孵化项目是在不断演进的文件里面的内容却没有人及时更新时间一长就变成了一堆过时信息的垃圾堆。更糟糕的是这个文件乱到连人都懒得去整理那 agent 也就没有办法判断哪些内容还有效了。所以他们后来改变了策略把 agent 文件压缩到只有一大体结构差不多就是这样子的。可以看出 agents.md里面已经没有什么太多实质性的内容了就是一个目录而已大模型跟人一样还是要把信息分门别类的放好才行。除此之外open AI 还发现了一个问题项目里面有很多重要的信息其实。他们可能是散落在 slack 的聊天记录里可能是躺在某个 Google doc 的文档里甚至是只存在于某个老员工的脑子里面这点我相信大家也深有体会只不过可能用的是国内的软件生态而不是说是什么 slackGoogle doc 这些对于 agent 来说。他只能是看见仓库里面有什么仓库外面的一切对他来说都跟不存在没有什么区别。对应的文件系统大致是这个样子的可以看出相关的文档和目录会跟 agent.md 放在一起这样用到哪块再给 agent 看哪块效果就会好很多。看所以 opening ai 是怎么做的他们是强制要求把所有重要的角色和约定都搬进代码仓库让仓库成为唯一的事实来源这样 agent 就可以了解到这些外部的信息了那这个就是上下文管理方面所做的事情。之后 agent 就可以写代码了后面的重点就是在 agent 写完代码之后让它能够验证自己的成果是否正确不然它写完了之后没法验证那这肯定是没有办法保证准确率的。opening AI 的做法是给 Codex 配上足够完善的工具和 skill在这两者的帮助下Codex 就能够在任务进行中是验证自己的输出。让我们举个例子比如说他们把 Chrome Dev TOOLS 接入到了 Codex 的运行环境里面这样 Codex 就可以自己截图自己查看dom结构并且自己模拟用户操作从而去验证 UI 是否符合用户的要求。如果发现这里面有问题那 Codex 就可以原地修复整个过程那就不需要人去介入了。除了 UI 之外Openai 还给 Codex 接入了完整的可观测性工具站以便让 Codex 可以读取日志、读取指标并在必要的时候追踪运行链路以排查问题。为了确保日志和输出的准确性Codex 的每个任务都跑在一个完全隔离的环境里有自己独立的日志和指标任务结束之后也能自动销毁。这样做了之后Openai 甚至可以让 Codex 对系统做一些可量化的性能调优比如说是要确保服务启动时间不能够超过800毫秒之类的。上面所讲的这些都是为了保证 Codex 生成代码可以实现产品诉求但很多时候我们对 Codex 生成代码本身还有一定的要求比如说这些代码至少要符合项目架构。open AI 把他们的系统分成了好几层并且规定了严格的依赖关系从上到下分别是 UI、runtime、service、Wrapper types每一层都只能依赖它下面的层依赖关系不能反了比如说是像 repo 层依赖 UI 层这样的事情是万万不能发生的。opening ai是使用 Linter 和测试来避免类似的情况发生。我们一起来看看它们是怎么保证架构规范的。在 agent 的生成代码之后Linter 或者是测试便会开始检测代码是否合规如果不合规的话它便会报错信息会发回到 agent 那里agent 会根据报错信息去修改改完之后再跑 Linter 或者测试这样就形成了一个完整的自动闭环。不需要人工去介入这个流程会。所有的测试全部通过这样我们就拿到了一份符合架构要求的代码了。好这些就是验证与反馈这部分的内容了下面我们来看看技术栈清理这部分在做什么。agent 在大规模生成代码的过程中会不可避免地引入一些糟糕的设计模式比如说是重复的代码偏离架构规范的写法不一致的命名之类的慢慢积累下去的话会把整个代码库搞得一团糟。Openai 的写法是给技术债做一些垃圾回收把这些问题通通解决掉。具体来说就是设置一个后台的 code 任务定期去扫描整个代码库找出其中偏离规范的地方自动修改并提交以便确保代码的质量始终维持在一个比较高的水准这个是对代码的清理和优化除了代码之外他们还对文档做了同样的事情具体来说是他们设置了一个后台任务。定期扫描整个文档库找出那些过时的和实际代码对不上的文档自动提交修复。所以你看无论是代码还是文档open AI 都有这一套对应的维护方案两边都不会放任自流。以上就是 open AI 所做的一些核心的 Harness engineering 实践了看完这些你可能有一个强烈的感觉这哪里是在写代码呀这完全就是在给 AI 构建干活的环境人负责定方向、搭框架具体干活的事情就全由 AI 来做了。没错这正是 Openai 这篇文章想要传达的最核心的理念。通过这5个月的疯狂实验Openai 不仅跑通了这套100万行代码的系统更重要的是他们在这个过程中重新定义了人类和 AI 在未来的工作边界。在文章中Openai 抛出了一个非常关键的断言human steer agents execute翻译过来就是。人类负责掌舵agent 的负责干活。说白了到了 Harness engineering 这一步人和 AI 的分工就彻底变了以前工程师要亲自下场一行一行地写代码遇到报错自己查测试也要自己跑。但现在人类更像是在掌舵人负责定方向给上下文制定规则在关键的地方做判断而那些重复的、琐碎的开发工作就交给 agent 在 harness 里面跑就好了。基于这个全新的边界opening 紧接着就提出了第二个非常重要的观点这个观点的点明了软件工程师在 AI 时代的新职责对应文章里面是这一话这大致意思就是在说虽然人类不再需要亲自手写代码但软件工程的工作并没有消失而是演变成了完全不同的形。如今软件工程师的核心职责变了变成了为 agent 搭建稳定可靠的系统与支撑框架以此来尽可能的提高代码产出效率。这两个观点可以说是 Openai 那篇文章的灵魂它直接告诉我们 harness engineering 不仅仅是如何写好 prompts或者是如何管理上下文这么简单它是在重塑整个软件工程的开发流程。那以上就是 Openai 这场 Harness engineering 实战的核心精髓了最后我想跟大家说明一下为了帮助大家快速理清脉络抓住核心思路这一篇文章我是做了一定的提炼和简化的。但必须要说Openai 的这篇文章写得非常的精彩如果你对里面的技术细节感兴趣强烈建议亲自去读一遍原文相信一定会让你大受启发。在这一章节里我们来看看 Anthropic 的两篇与 Harness engineering 相关的文章第一篇是去年11月发表的 effective harnesses for long running agents(https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)它讲述了如何配置环境以便让 agent 长时间自主运行。第二篇是今年3月份发表的 Harness design(Harness design for long-running application development \ Anthropic)。第一篇文章的续集。他在。第一篇文章的基础上。对harness架构。做了进一步的优化和调整。使其能够处理更多类型的任务。达到更好的效果。这两篇文章的信息量很大。不过总结。下来。最核心的地方呢就2个。1是跟任务跟规划。另外一个是跟质量评估有关、我们来一个看首先来看一下任务规划这一部分在第一篇文章中Anthropic。给做了一个实验直接让 agent 执行一个任务克隆 Claude AI就是 Claude 的聊天界面大致就是这个样子的它跟 ChatGPT 是同类型产品虽然看起来只是一个聊天界面而已但说实话它背后的功能还是挺多的一口气做出来是一件几乎不可能做到的事情。这个那也是 Anthropic 一开始所遇到的问题。在 anthropic 的实验里agent 接到需求之后立马就开干了干劲非常的足但是效果也非常不好主要是因为这个需求的工作量实在是太大了直接给到 agent 的话agent 就会急于求成从而引发一系列的问题。比如说他总想一口气把所有的功能全部结果干到一半上下文就满了直接抛下了橄榄摊子等到下一个 agent 的接手的时候完全不知道前面发生了什么只能靠猜这猜就坏事了虽然有些功能只做了一半但接手的 agent 并不知道。粗略地扫了一眼还以为已经大功告成于是直接宣布完工草草就收工了。Anthropic 在第一篇文章里面写了对应的解法他们是引入了一个叫做 agent从这个名字就可以看出来这个 agent 就是用来初始化执行环境的比如说是拆解用户需求编写启动脚本、添加进度文件等等。这里面最核心的就是拆机用户需求这一点具体来说就是把用户的需求拆解为一个详细的功能列表后续负责干活的 agent 就可以直接拿着这个功能列表去干活了而且这个干活的 agent 会一个功能点的做完一个标记。一个这样稳扎稳打整个流程的可控性又高了很多。后来再写第二篇文章的时候Anthropic 对这个思路做了一些演进他们把 evaluator 里面最核心的一件事情也就是拆解用户需求这个事情单独给拿了出来做成了一个新的 agent叫做 planner它负责把用户一句模糊的需求扩展成一份完整清晰的功能列表。这样后面的在写代码的时候就不用对着用户的需求猜了照着功能点一个个做就行。好那规划的问题解决了这一部分的产物就是 planner下面我们再来看第二点质量评估一般来说光是让 agent 生成代码是不够的我们还需要对它生成的代码做一些质量评估看看产出的东西到底行不行。如果产出质量不行的话我们需要把对应的问题列表发回给 agent以便让他做相应的修改这个才是一个比较合理的流程现在我们来看看具体是怎么做质量评估的这里面有两种评估方案一种是人工评估这个就不太行了效率太低了都 AI 时代了。能交给 AI 的就都交给 AI。那这就引出了第二个方案让 agent 的自评也就是自己评估自己的产出有问题就修完再评循环往复直到合格为止。听起来挺合理的是吧但 anthropic 发现这个方案根本不好用。原因很简单agent 自评这件事情本质上就是王婆卖瓜自卖自夸他对自己。所以及时产出里面有明显的 bug它也能做到视而不见给自己打个高分之后就草草收工了。所以 Anthropic 就直接把前面两种方案都给废弃了搞出了第三个方案那就是做一个专门的评估 agent 来评估产出质量。由于这个评估 agent 是一个独立的第三方它自然就没有理由去比别的 agent 产出护短评估结果也就客观多了。而且把评估 agent 的单独拎出来还有一个好处那就是我们可以单独去优化去训练这个评估 agent让它的评估效果做到最好。对这个就是 Anthropic 的最终方案了换句话说我们最终需要把生成代码和质量评估这两件事情给拆开分别给两个不同的 agent 来做其中负责生成代码的那个叫做 Generator负责质量评估的那个叫做 Evaluator这个就是最终的质量评估流程了。所以质量评估这一环节我们提到了两个 agent一个是评估用的 evaluator一个是生成代码用的 Generator再加上之前说过的我们就有3个 agent 了。下面我们来画一下时序图看看这三个 agent 是怎么分工合作完成用户需求的。首先是 planner他会把用户的需求拆解为具体的功能列表然后发送给 GeneratorGenerator 接收到功能列表之后他会从中挑选出一个功能点然后他就着这个功能点去跟 evaluate 讨论一下交付标准也就是讨论下到底做到什么程度才算是完成了这个功能点。Generator 首先会把他的想法发过去Evaluator 一开始可能会对这个提议提出一些修改意见然后再发回给 Generator会根据意见再次提交新的交付标准所以这个过程会重复个几次直到 evaluate 确认 generate 提议没问题为止。确认好交付标准之后Generator 便开始生成代码来实现这个功能点了。实现完毕之后Generator 会把它的实现结果提交给 EvaluatorEvaluator 会对结果做出评估反馈比如说是一开始可能评估不通过那如果不通过的话the Generator 就要修改代码了所以这个提交结果评估反馈的过程也会重复个几次直到 Eval 评估通过为止。到这里一个功能点就算是开发完了但是我们不只有一个功能点所以我们就需要再一次重复之前的这个流程把后面的功能点全部都逐步做完这个就是大致的流程了。Anthropic 把这个包含了三个 agent 的方案叫做 full harness方案。相比之下那种只靠一个 generator 独立完成所有需求的传统单 agent 模式被 Anthropic 称为 SOLO 方案。Anthropic 拿了一个具体的任务来验证这两个方案的差距这个任务就是做一个游戏制作工具。从效果上来看solo 和 four Harness 这两个方案的差距还是很明显的。solo 方案的问题很多比如说是布局不合理产品逻辑难以理解bug 到处都是基本上是没有办法用的。而 four harness 方案就有了明显的改善了无论是布局还是整体的产品逻辑都虽然还是存在一些问题但比起 solo 方案来说four Harness 的效果是明显好不少的。当然这样做也不是没有代价的four harness 方案的耗时和花费都要明显的高于 solo 方案。Anthropic 给出了一个对比表格大家可以感受一下。solo 方案耗时20分钟花费9美元而付 Harness fine 是耗时6个小时花费高达200美元。所以可以看出for Harness 的 fine 无论是耗时还是花费都要远高于 solo 方案。虽然如此但不得不承认for harness 的 fine 效果确实是好了不少毕竟精雕细琢是有代价的这对于我们人类来说也是一样。考到60分可能只需要复习三天但是想考到90分那可能就得复习一个月了这个大家多少都会有些体会。最后再提一个 anthropic 后来做的优化点让我们重新看一下这个流程图注意其中的这一部分说明了 Generator 每次只会连续一个功能点做完这个功能点再做下一个循环往复直到完成所有的功能点为止。这个逻辑是 Anthropic 在提示词里面强制 Generator 这么处理的否则让 Generator 自行发挥的话它还是会急于求成最后留下一堆烂摊子。不过在 opus 点六发布了之后这个约束就不怎么需要了。anthropic 后面就把这一部分给去掉了最后就简化成了这个样子那为什么后面就可以这么做了因为基于 Opus 点6做的 Generator 变得更强了它可以一次把所有的功能点全部都拿过来自己决定先做哪个再做哪个稳步地向前推进不需要别人再对它的执行流程指指点点。而在这种情况下Evaluator 也直接评估最终产出就可以了不需要再分功能点评估了。关于这一部分我们在下一章节还会提到这里你有个大体的概念就行。在这一章节里我们来聊聊目前争议最大的一个问题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号的时候发表作者是 Mitchell hash model。可能国内有些同学对这个人不太熟悉但在海外技术圈他绝对是响当当的人物很多大公司的底层工具都是他做的。在这篇博客里他写了这么一段话。这段话的大意就是说我也不知道业界有没有公认的叫法我就姑且叫它是 harness engineering它的核心理念就是只要 agent 犯了错你就去改造系统让它绝不再犯同样的错误。要是有更好的词我随时改口你看大佬还是很实诚的所以这个词的起点其实非常朴素甚至带着点随意跟后来大家讨论的宏大概念还是有所区别的。从传播情况来看这篇文章的讨论热度其实并不算很高那 Harness engineering 这个词到底是怎么火起来的在很多人的认知里真正引爆这个概念的是几天后也就是2月11号 open AI 发的那篇 Harness 文章就是我们之前讲过的那个这个文章的信息量极大迅速就在业界引起了巨大的反响紧接着整个 AI 圈就像触发了连锁反应。仅仅6天后也就是2月17号软件工程界鼎鼎大名的 Martin Baller 网站就发表了一篇文章作者是 Softworks 里面一个非常资深的工程师。文章的标题是叫做 Harness engineering first thoughts讲的就是他读完了 Openai 那篇文章之后的第一反应。作为顶级技术博客这篇文章一发出来自然就在圈内引发了广泛的讨论。但抛开技术观点不谈它在文章里面还点出了一个很耐人寻味的细节。虽然 Openai 的这篇文章的有 Harness engineering 这个概念但如果你仔细去翻 Openai 的文章你会发现这篇文章的正文里面其实只提了一次 Harness 这个词因此它就推测 Openai 搞不好就是受到了 Mitchell Hashimoto 的启发事后才临时把 Harness engineering 这个词放到了标题里面。虽然这只是个猜测但也给人带来了很大的联想空间。随后到3月10号的时候Longin 发表了一篇文章叫做 the anatomy of an engine Harness这篇文章第一次明确给出了关于 Harness 的公式就是这个 agent 等于 model加上 Harness 这个公式其实就是我们前面所聊过的那个等式的变体。当时那我们是把 Harness 移到了等号的左边我们讲的是 harness 等于 agent 减去 model 这两个等式其实本质上就是一回事公式一出概念就算是定掉了。随后在3月24号的时候Anthropic 发表了那篇 Harness 的文章拿出了 plannerGenerator 和 Evaluator 的经典架构这个我们之前也讲过虽然 Anthropic 自己比较克制通篇只用了 Harness 这个名词并没有生搬硬套 Harness engineering 这个刚刚炒热的新词。但在当时那个氛围下整个 AI 圈可以说是心照不宣直接就把这套三个 agent 的架构当成了 Harness engineering 的教科书级案例。就这样一传十by Harness engineering 就从一个私人说法变成了一个大家都在用的词。不过如果你复盘完这段历史再仔细的琢磨一下就会发现一件非常微妙的事情那就是 Harness engineering 里面所用到的所有技术竟然没有一个是新的你看我们前面所讲的代码检查、任务拆解规划、质量评估机制这些东西其实早就有了相信看这个视频的很多观众。甚至都在做相关的工作。Harness engineering 真正做的只不过是把这些技术重新组织了一下统一放到了一个新词的下面。换句话说它提供的是一套新的系统思维架构而不是发明了一批颠覆性的新技术。既然没什么新技术那难怪有些人会觉得 Harness engineering 这个概念被高估了甚至带着点炒作的成分。仔细听听这些人的想法你会发现他们的攻击点主要是有两个一方面正像我们前面所聊过的 Harness engineering根本就没有什么新东西全是新瓶装旧酒在这种情况下特意造个新词到处宣传这不就是噱头吗不仅如此这些人还提出了一个更扎心的观点所有的知名都是迟早要被淘汰的他们认为随着大模型自身能力的持续优化今天看起来必不可少的这些知名的设计未来很有可能会被模型能力本身逐步吸收最终变得不再需要。而这种担忧其实连 Anthropic 自己的文章里都有据可循。前面我们讲过 Anthropic 的 Harness 核心方案但文章里面还有很多细节值得细细品味这里我们仔细研究下其中的两个问题然后分别看看 Anthropic 一开始用 Harness engineering 是怎么解决的以及后来模型强大了之后是如何用模型来解决的。我们第一个要探讨的问题就是上下文焦虑这个是 Sonic 4.5的一个具体来说就是当上下文过长时模型会急于结束任务以更少的 TOKEN 完成交付而这个往往会影响最终质量。Anthropic 一开始是使用了一种叫做上下文重置的 Harness engineering 技术来解决这个问题但后来当模型升级到更强的 Opus 4.5之后这种现象被大幅缓解因为 Opus 4没有明显的上下文焦虑问题了也就不怎么需要这方面的 Harness 设计。第二个相关的问题是场任务的执行效果差这一点其实我们在上一个章节也提过让我们一起来回忆一下 Anthropic 的链路包含了 planner 和 evaluator 三个 agents一开始的设计是逐个功能点执行也就是说 Anthropic 会在提示词里面强制 generator。每次只选取一个功能点做完一个再做下一个以便确保整个产品开发流程稳步向前推进。不过等用到更强的 Opus 点6之后这种强制分布执行的机制就不再需要了因为 Opus 点6的全局统筹能力够强它可以一次把所有的功能点都拿过来自己决定先做哪个再做哪个稳步向前推进不再需要别人对它的执行流程指指点点了。你看这就说明了一个非常现实的趋势模型越强所需要的 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 的能力转化为真正的生产力从而从中受益