Transcript of Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚
马克的技术工作坊
0:00继 Prompt Engineering0:01Context Engineering 之后0:03AI圈最近又冒出了一个新名词0:05叫做 Harness Engineering0:08从今年2月份开始0:09这个词频繁地在 AI 圈里面出现0:12OpenAI 专门发了一篇文章0:14讲他们怎么用 Harness Engineering0:16在5个月内写了将近100万行代码0:18Anthropic 也紧接着发文0:20分享了自己如何使用0:21精心设计的 Harness 架构0:23来驱动 Agent 的开发应用0:24不仅如此0:25就连技术大牛 Martin Fowler0:27创立的技术网站 martinfowler.com0:29也开始公开讨论起了 Harness Engineering0:31但与此同时0:33也有不少人认为0:34这不过是个噱头而已0:35换汤不换药0:36那 Harness Engineering 到底是什么0:38它跟 Prompt Engineering0:40和 Context Engineering0:41又有什么关系呢0:42Harness Engineering 是真正的技术突破0:45还是说只是 AI 圈又在炒概念0:48这期视频0:48我们就来把这个事情彻底搞明白0:54在讲 Harness Engineering 之前0:56我们不妨先来讲讲它的两个前任0:58分别是 Prompt Engineering0:59和 Context Engineering1:01对这两个概念比较熟悉的同学1:03可以直接跳到下一个章节1:05首先是 Prompt Engineering1:07这里的Prompt1:08你可以简单理解成1:09用户发给大模型的话1:11而 Prompt Engineering1:12就是一门研究1:13怎么把这句话说清楚的技术1:15举个具体点的例子1:17比如说我们可以向大模型发问1:18帮我的猫起个名字1:21这个问题就是 Prompt 了1:22接到 Prompt 之后1:23大模型就会给你一个答案1:25比如说是什么花花呀1:27小白呀之类的1:28不过这些答案可能都无法让你满意1:31因为你家的猫呢1:32可能是橘色的1:33无论是花花还是小白1:35都与橘色这个颜色相冲突1:37那为什么大模型会给你错误的答案呢1:40这是因为我们没有在 Prompt 里面1:42给大模型充足的信息1:44既然问题出在 Prompt 上面1:46那解决问题的关键1:48自然也在 Prompt 上面了1:50说得再具体一点1:51那就是我们需要学会1:53如何更精准地表达自己的需求1:56这个呢就引出 Prompt Engineering 了1:58Prompt Engineering 就是专门用来2:00研究怎么把话说清楚的2:02还是用之前的例子2:03让我们重新设计一下这个问答流程2:05按照 Prompt Engineering 的理念2:08我们需要发送的 Prompt2:09就应该是这样子的2:11帮我的橘色小猫起名2:12两个字2:13需要体现出它活泼爱玩的性格2:16这个时候大模型就可以给出一些2:18更让我满意的名字了2:19比如说是橘宝2:21代表橘色的大活宝2:23橙豆2:23橙色的小豆子2:25你想小豆子掉在地上蹦蹦跳跳的2:27那也能够体现出猫活泼的性格嘛2:30你看这两个名字就跟你的猫更贴切了2:33没错2:34说白了呢2:35Prompt Engineering 就是一门2:36调整大模型提示词的技术2:38对就是这么简单2:40不过如今 Prompt Engineering2:42已经很少被单独提起了2:44一方面它的门槛实在是太低了2:46另一方面呢2:47模型本身的能力呢也变得更强了2:49很多时候不需要在 Prompt 上2:51调来调去能给出不错的回答2:54好2:54这就是 Prompt Engineering 了2:56下面呢我们来看看 Context Engineering2:59我们还是用小猫来举例啊3:01假设你拿到了小猫的名字之后3:03还继续跟大模型聊天3:05比如你问它3:06那它平时吃什么好呢3:09这个呢就是我们的 Prompt 了3:10我们来把它单独标出来3:12那现在重点来了3:13我们此时要发给大模型的3:16其实不仅仅有这个 Prompt3:18还有之前的对话历史3:19这样的大模型才知道这个新问题里面的它3:22指代的是什么3:24那无论是Prompt还是对话历史3:26它们呢都是大模型所接收到的信息3:29我们把大模型所接收的所有信息起个名字3:32就叫做Context3:34当然 Context 的内容呢还不只有这两个3:37它还包含工具列表3:38Skill列表等等3:39我们就不一一列举了3:41你也不用太关心3:42你只需要知道 Context 是有容量上限的3:45所以我们不可能无止境的往里面塞东西3:47我们需要精心设计 Context 里面的内容3:51这个呢就叫做 Context Engineering3:54Context Engineering 有很多具体的方法3:57比如说其中一个非常经典的技术3:59就是上下文压缩4:01之前不是说我们会把对话历史放在 Context 里面吗4:04我们跟模型越聊越多4:06对话历史呢也会越聊越多4:08当超过某个阈值的时候4:10我们就可以使用上下文压缩技术4:12把之前的对话历史做个总结4:14以防止 Context 里面的内容过多4:16影响回答效果4:18当然除了上下文压缩之外4:20Context Engineering 还有很多其他的方法4:23比如说是什么动态检索外部资料啊4:26渐进式披露啊等等4:27这里呢就不一一列举了4:29可以看出 Context Engineering 还是挺能整活的4:32搞出了这么多的东西4:34不过吧这依然不是终点4:36因为大家发现啊4:38Context Engineering 这门技术的效果呢4:40是有一定的上限的4:41为了进一步榨干大模型的潜力呢4:44AI 圈又整出了新花样4:46这个就引出了我们今天真正的主角4:49Harness Engineering4:53要搞明白 Harness Engineering 这个概念4:56我们就得先从 Harness 这个单词说起4:59这个词在日常生活中其实不太常见5:02很多人可能也是第一次听说5:04Harness 这个词的本意啊5:06其实是马具的意思5:08大家看这是一匹马5:09而 Harness 或者说是马具5:12就是套在马身上5:13用来控制马的那些装备5:15比如说是缰绳啊头套啊这些5:17虽然马非常强大5:19但是我们必须借助马具的力量5:21来限制马的活动5:23这样呢我们才能够让马为我们人类所用5:26好现在呢我们把马具5:28从马身上单独拆下来做一个类比5:31左边这匹脱掉马具的马5:33对应的就是 AI 领域里面的大模型5:36你想大模型是不是特别强5:38尤其是像 GPT, Opus 这样的顶级模型5:41能干的事情可太多了5:43但大模型就像马一样5:45如果我们不对它加以干预5:47任由大模型自己去运行和发挥5:49那它就会像脱缰的野马一样发散思维5:52甚至产生严重的幻觉5:54最终根本无法稳定的给我们想要的结果5:58所以呢我们必须要把大模型给控制住6:00就像用马具来控制马一样6:02而这套用来控制大模型的系统6:04就被称为了 Harness6:06没错 Harness 就对应了这个马具6:09好 Harness 就是 Agent 里面6:11用来控制和驾驭大模型的系统6:14所以从这一点出发6:15我们就能推导出 Harness 的公式6:18也就是 Harness 就等于 Agent 减去 Model6:21换句话说一个完整的 Agent6:24减去里面的大模型6:25剩下的所有东西都是 Harness6:27不过需要注意的是6:29Harness Engineering 是一个非常新的概念6:31目前业界还没有形成严格的定义6:34这个公式只是目前大多数人6:36比较认可的一种说法6:37并非是严格的学术定义6:39所以只要不是大模型就是 Harness6:42关于这一点我相信你已经明白了6:44下面我们来看个具体的例子6:46我们可以用 Claude Code 来举例6:49在 Claude Code 里面6:50所有不属于 Claude 模型的部分都是 Harness6:53比如说是写在 CLAUDE.md 里面6:55那些大模型要遵循的规则6:57Claude Code 可以使用的工具6:59或者是它的定时调度机制等等7:01这些都是 Harness7:03当然 Harness 涉及的范围很广7:05我这里只是举了三个例子而已7:07总而言之只要不是模型7:10我们都可以将它视为 Harness 的一部分7:13那 Harness 了解了7:14顺理成章的 Harness Engineering 的概念7:17也就呼之欲出了7:18Harness Engineering 就是一门专门研究7:20如何构建与设计 Harness 的技术7:23换句话说就是除了大模型本身不研究7:26别的什么都研究7:28它不再是紧紧盯着模型输入的那点提示词7:31或者是上下文7:32而是站在更高的系统层面上7:34研究怎么给大模型设计一套7:36可以稳定运行的系统7:37让大模型能够踏踏实实地为我们人类做事7:41所以从这里可以看出7:42Prompt Engineering, Context Engineering7:45和Harness Engineering7:46更像是一种层层递进7:47研究范围不断向外扩展的关系7:50它们关注的问题是越来越大7:52越来越广7:54Prompt Engineering 研究的是怎么问问题7:56具体来说就是如何组织 Prompt7:59把发给大模型的话说得更清楚8:01更准确8:02让模型能够更容易理解你的真实意图8:05并给出理想的结果8:06Context Engineering 研究的内容8:08比 Prompt Engineering 更广一些8:10它研究的是怎么给信息8:12具体来说就是怎么在最合适的时机8:15把最合适的内容放到模型的 Context 里面8:18Context 里面的内容不仅包括 Prompt8:21还包括工具列表8:22对话的历史等等8:24所以 Context Engineering 的研究范围会更广一些8:27Harness Engineering 的研究范围就更加激进了8:30它研究的是如何搭建系统8:32也就是如何围绕着大模型搭建一个完整可靠的 Agent8:36它的研究对象直接就覆盖了8:38除了大模型之外的所有内容8:40比如说是什么权限管控8:42工具管理等等8:44都是 Harness Engineering 要研究的内容8:47相信现在你已经了解了8:48Harness Engineering 是什么了8:49那 Harness Engineering 具体要做哪些事呢8:52有没有一些实战的例子8:54说实话8:55这个概念实在是太新了8:57目前业界也没有一个公认的体系9:00与其我在这里自说自话9:01我们不如来直接看看大厂是怎么做的9:04我们首先从 OpenAI 开始9:102025年8月9:11OpenAI 内部启动了一个疯狂的实验9:13那就是用 AI 从零开始写一个真实的软件产品9:17全程不允许工程师手写一行代码9:19对 没错9:20这个产品的所有的组成部分9:22都是由 AI 生成的9:24具体是包括业务逻辑9:26测试9:26CI 配置9:27文档9:28内部工具等等9:29所有的东西都是 AI 生成的9:31靠着 AI 这个项目的代码规模9:33直接是干到了将近100万行9:35而且注意了9:36这可不是一个玩具9:37它是一个真正在线上跑9:39有真实用户的生产系统9:41达到这样的规模9:42总体耗时只用了5个月左右9:44团队规模一开始是3个人在主导9:47后来也只不过是扩张到了7个人9:50算下来9:51开发效率差不多是纯人工的10倍了9:53但有意思的是9:54这个实验一开始的进展并不顺利9:56这并不是因为大模型不够聪明9:58而是因为Harness没有搭建好10:00工程师们发现 Agent 经常走错方向10:02甚至重复犯同一个错误10:04于是他们意识到10:05要想让 Agent 可靠的工作10:07真正的功夫在于把 Harness 设计好10:09为此他们做了大量的优化10:12并且写了一篇文章详细记录了这个过程10:14这篇文章我反复读了好几遍10:17它的信息量非常大10:18涉及到很多 Harness Engineering 的优化点10:20所以这期视频我们就来重点聊聊10:23OpenAI 在 Harness Engineering 上面10:25到底做了什么10:26原文是从多个具体的优化点里面展开的10:29信息密度非常高10:30所以这里我尝试给这些优化点10:33大致分了个类10:34分别是上下文管理10:36验证与反馈10:38和技术债清理10:39当然需要强调的是10:40这只是我个人所做的一个分类10:43主要是为了帮助大家理解10:45下面我们就来一一看看10:47这三大类到底是在做什么10:49首先是上下文管理10:50上下文管理的主要目标10:51是让 Agent 获取到足够充足的信息10:54你可以想象一下10:55一个新入职的工程师10:57如果对项目一无所知10:58不清楚模块怎么划分10:59不知道代码规范是什么11:01不了解团队过去做过哪些技术决策11:03那他是根本就没有办法开始工作的11:05Agent 也是如此11:07为了解决这个问题11:08OpenAI 最初的尝试是11:10把所有的项目规范和相关信息11:12塞进一个超大的 AGENTS.md 文件11:15这个文件会随着用户的问题11:16一起发给大模型11:17这样大模型就有了充足的信息11:19不过 OpenAI 后来发现11:21使用一个大而全的 AGENTS.md 文件11:24根本无法解决问题11:25原因是有很多11:26这里说两个最关键的11:29第一个是内容太多11:30使得模型的效果变差11:32设想一下你第一天去新公司报到11:34HR直接砸给你一个巨厚的员工手册11:37说规矩全在这里11:38你自己看吧11:39那我猜你肯定是一脸懵的11:41完全不知道该从哪里看起11:43也完全搞不清楚重点在哪11:45AI 也是一样11:46一股脑地把所有的信息全部都喂给他11:49那他就迷失了11:50只能抓到一些碎片11:51真正关键的内容11:53反而被淹没在了废话里11:55第二点是这个文件会逐步的腐化11:58项目是在不断演进的11:59文件里面的内容12:00却没有人及时更新12:02时间一长就变成了一堆12:03过时信息的垃圾堆12:05更糟糕的是12:05这个文件乱到连人都懒得去整理12:08那 Agent 也就没有办法12:09判断哪些内容还有效了12:11所以他们后来改变了策略12:13把 AGENTS.md 文件压缩到只有 100 行左右12:16大体结构差不多就是这样子的12:18可以看出 AGENTS.md 里面12:19已经没有什么太多实质性的内容了12:21就是一个目录而已12:22对应的文件系统大致是这个样子的12:25可以看出相关的文档和目录12:27会跟 AGENTS.md 放在一起12:29这样用到哪块再给 Agent 看哪块12:31效果就会好很多12:33看来大模型跟人一样12:34还是要把信息分门别类的放好才行12:37除此之外12:38OpenAI 还发现了一个问题12:39项目里面有很多重要的信息12:41其实并不在代码仓库里面12:43它们可能是散落在 Slack 的聊天记录里12:46可能是躺在某个 Google Docs 的文档里12:48甚至是只存在于某个老员工的脑子里面12:51这点我相信大家也深有体会12:53只不过可能用的是国内的软件生态12:56而不是说是什么Slack Google Doc这些12:59对于 Agent 来说13:00他只能是看见仓库里面有什么13:02仓库外面的一切对他来说13:04都跟不存在没有什么区别13:05所以 OpenAI 是怎么做的呢13:07他们是强制要求把所有重要的13:10决策和约定都搬进代码仓库13:12让仓库成为唯一的事实来源13:15这样 Agent 就可以了解到13:17这些外部的信息了13:19那这个就是上下文管理方面13:21所做的事情了13:22下面我们来看看验证和反馈部分在做什么13:25做好了上下文管理13:27有了充足的信息之后13:28Agent 就可以写代码了13:30后面的重点就是在 Agent 写完代码之后13:32让他能够验证自己的成果是否正确13:35不然他写完了之后没法验证13:37那这肯定是没有办法保证准确率的13:40OpenAI 的做法呢13:41是给 Codex 配上足够完善的工具13:43和 Skill13:44在这两者的帮助下13:46Codex 就能够在任务进行中随时验证自己的输出13:50让我们举个例子13:51比如说他们把 Chrome DevTools13:53接入了 Codex 的运行环境里面13:55这样呢 Codex 就可以自己截图13:58自己查看DOM结构13:59并且自己模拟用户操作14:01从而去验证UI是否符合用户的要求14:04如果发现这里面有问题14:06那 Codex 就可以原地修复14:07整个过程呢就不需要人去介入了14:10除了UI之外14:11OpenAI 还给 Codex 接入了完整的可观测性工具栈14:14以便让 Codex 可以读取日志14:16读取指标14:17并在必要的时候追踪运行链路14:20以排查问题14:21为了确保日志和输出的准确性14:23Codex 的每个任务都跑在一个完全隔离的环境里14:26有自己独立的日志和指标14:27任务结束之后呢也能自动销毁14:30这样做了之后14:31OpenAI 甚至可以让 Codex 对系统做一些14:34可量化的性能调优14:35比如说是要确保服务启动时间不能够超过800毫秒之类的14:40上面所讲的这些呢14:41都是为了保证 Codex 生成的代码14:43可以实现产品诉求14:44但很多时候我们对 Codex 生成的代码本身14:47还有一定的要求14:48比如说呢这些代码至少要符合项目架构上的规范14:52OpenAI 把它们的系统分成了好几层14:53并且规定了严格的依赖关系14:56从上到下分别是14:57UI, Runtime, Service, Repo, Config, Types15:00每一层都只能依赖它下面的层15:02依赖关系不能反了15:03比如说是像 Repo 层依赖 UI 层15:06这样的事情是万万不能发生的15:08OpenAI 是使用 linter 和测试15:10来避免类似的情况发生15:12我们一起来看看它们是怎么保证架构规范的15:15在 Agent 生成代码之后15:16linter 或者测试便会开始检测15:18代码是否合规15:19如果不合规的话它便会报错15:21报错信息会发回到 Agent 那里15:23Agent 会根据报错信息去修改15:26改完之后再跑 linter 或者测试15:28这样就形成了一个完整的自动闭环15:30不需要人工去介入15:32这个流程会重复个几次15:34直到某次检测之后15:35所有的规则所有的测试全部通过15:37这样我们就拿到了一份15:39符合架构要求的代码了15:41这些就是验证与反馈这部分的内容了15:44下面我们来看看15:45技术债清理这部分在做什么15:47Agent 在大规模生成代码的过程中15:50会不可避免地引入一些糟糕的设计模式15:52比如说是重复的代码15:54偏离架构规范的写法15:55不一致的命名之类的15:57慢慢积累下去的话会把整个代码库搞得一团糟16:00OpenAI 的解法是给16:01技术债做一些垃圾回收16:03把这些问题通通解决掉16:04具体来说就是设置一个后台的16:07Codex 任务定期去扫描16:09整个代码库找出其中16:11偏离规范的地方自动修改并提交16:13以便确保代码的质量16:15始终维持在一个比较高的水准16:17这个是对代码的清理和优化16:19除了代码之外他们还对文档做了16:21同样的事情具体来说是16:23他们设置了一个后台任务定期16:25扫描整个文档库找出那些16:27过时的和实际代码对不上的文档16:29自动提交修复所以你看16:31无论是代码还是文档 OpenAI16:33都有着一套对应的维护方案16:35两边都不会放任自留16:38以上就是 OpenAI 所做的16:39一些核心的 Harness Engineering 实践了16:41看完这些你可能有一个16:43强烈的感觉这哪里是在写代码啊16:46这完全就是在给 AI16:47构建干活的环境啊16:49人负责定方向搭框架16:51具体干活的事情就全由16:53AI 来做了没错这正是16:55OpenAI 这篇文章想要传达的最核心的16:57理念通过这五个月的疯狂实验16:59OpenAI 不仅跑通了这套17:01100万行代码的系统更重要的是17:03他们在这个过程中重新定义了17:05人类和 AI 在未来的工作边界17:07在文章中 OpenAI 抛出了一个17:09非常关键的断言17:11Humans steer, Agents execute17:13翻译过来就是人类负责掌舵17:15Agent 负责干活说白了17:17到了 Harness Engineering 这一步17:19人和 AI 的分工就彻底变了17:22以前工程师要亲自下场17:23一行一行地写代码遇到爆错17:25自己查测试也要自己跑17:27但现在人类更像是在掌舵17:29人负责定方向给上下文17:31制定规则在关键的地方做判断17:34而那些真正重复的17:35琐碎的开发工作就交给17:37Agent 在 Harness 里面跑就好了17:40基于这个全新的边界17:41OpenAI 紧接着又提出了第二个17:43非常重要的观点17:44这个观点点明了软件工程师在 AI 时代的新职责17:47对应文章里面是这一段话17:50这大致意思就是在说17:51虽然人类不再需要亲自手写代码17:53但软件工程的工作并没有消失17:55而是演变成了完全不同的形态17:58如今软件工程师的核心职责变了18:00变成了为 Agent 搭建18:02稳定可靠的系统与支撑框架18:03以此来尽可能的提高代码产出效率18:06这两个观点可以说是 OpenAI 那篇文章的灵魂18:09它直接告诉我们18:10Harness Engineering 不仅仅是18:12如何写好 Prompt 或者是18:13如何管理上下文这么简单18:15它是在重塑整个软件工程的开发流程18:18那以上就是 OpenAI 这场18:20Harness Engineering 实战的核心精髓了18:22最后我想跟大家说明一下18:24为了帮助大家快速理清脉络18:26抓住核心思路18:27这篇文章我是做了一定的提炼和简化的18:30但必须要说 OpenAI 的这篇文章18:33写得非常的精彩18:35如果你对里面的技术细节感兴趣18:36强烈建议亲自去读一遍原文18:39相信一定会让你大受启发18:45在这一章节里我们来看看18:47Anthropic 的两篇与 Harness Engineering18:49相关的文章18:50第一篇是去年11月发表的18:52Effective Harnesses for Long-Running Agents18:55它讲述了如何配置环境18:57以便让 Agent 长时间自主运行19:00第二篇是19:01今年3月份发表的19:02Harness Design for Long-Running Application Development19:05这篇文章可以理解为19:07是第一篇文章的续集19:08它在第一篇文章的基础上19:10对 Harness 架构做了进一步的优化和调整19:13使其能够处理更多类型的任务19:15达到更好的效果19:16这两篇文章的信息量很大19:18不过总结下来最核心的地方19:21就两点19:21一个是跟任务规划有关19:23另外一个是跟质量评估有关19:26我们来一个一个看19:28首先来看一下任务规划这部分19:30在第一篇文章中19:32Anthropic做了一个实验19:33直接让 Agent 执行一个任务19:35克隆 claude.ai19:37claude.ai 就是 Claude 的聊天界面19:39大致就是这个样子的19:41它跟 ChatGPT 是同类型产品19:43虽然看起来只是一个聊天界面而已19:46但说实话19:47它背后的功能还是挺多的19:49一口气做出来是一件几乎不可能做到的事情19:52这个呢19:53也是Anthropic一开始所遇到的问题19:54在 Anthropic 的实验里19:56Agent 接到需求之后立马就开干了19:58干劲非常的足啊20:00但是效果也非常不好20:01主要是因为这个需求的工作量实在是太大了20:05直接给到 Agent 的话20:06Agent 就会急于求成20:08从而引发一系列的问题20:10比如说他总想一口气把所有的功能全部做完20:13结果干到一半上下文就满了20:15直接抛下了个烂摊子20:16等到下一个 Agent 接手的时候20:18完全不知道前面发生了什么20:20只能靠猜20:21这一猜就坏事了20:23虽然有些功能只做了一半20:25但接手的 Agent 并不知道啊20:27粗略地扫了一眼还以为已经大功告成20:29于是直接宣布完工20:31草草就收工了20:32Anthropic 在第一篇文章里面写了对应的解法20:35他们是引入了一个叫做 Initializer 的 Agent20:39从这个名字就可以看出来20:40这个 Agent 就是用来初始化执行环境的20:43比如说是拆解用户需求啊20:46编写启动脚本啊20:47添加进度文件啊等等20:49这里面最核心的就是拆解用户需求这一点20:52具体来说20:53就是把用户的需求拆解为一个详细的功能列表20:56后续负责干活的 Agent 呢20:58就可以直接拿着这个功能列表去干活了21:01而且呢21:02这个干活的 Agent 会一个功能点一个功能点地做21:05做完一个标记一个21:06这样稳扎稳打21:07整个流程的可控性就高了很多21:10后来在写第二篇文章的时候21:12Anthropic 对这个思路做了一些演进21:14他们把 Initializer 里面21:15最核心的一件事情21:17也就是拆解用户需求这个事情21:19单独给拿了出来21:19做成了一个新的 Agent 叫做 Planner21:22他负责把用户依据模糊的需求21:25扩展成一份完整清晰的功能列表21:28这样后面 Agent 在写代码的时候21:30就不用对着用户的需求猜了21:32照着功能点一个个做就行21:34好那规划的问题解决了21:36这一部分的产物呢就是Planner21:38下面呢我们再来看第二点21:40质量评估21:41一般来说光是让 Agent 生成代码是不够的21:44我们还需要对它生成的代码21:45做一些质量评估21:46看看产出的东西到底行不行21:48如果产出质量不行的话21:50我们需要把对应的问题列表发回给 Agent21:52以便让他做相应的修改21:54这个呢才是一个比较合理的流程21:57现在我们来看看具体是怎么做质量评估的22:00这里面呢有两种评估方案22:02一种呢是人工评估22:03这个就不太行了22:04效率太低了都 AI 时代了22:07能交给 AI 的就都交给 AI 吧22:09那这就引出了第二个方案22:11让 Agent 自评22:12也就是自己评估自己的产出22:14有问题就修,修完再评22:16循环往复制到合格为止22:18听起来挺合理的是吧22:20但Anthropic发现这个方案根本不好用22:23原因很简单22:24Agent 自评这件事情22:25本质上就是王婆卖瓜子买字夸22:28他对自己做的东西天然就有滤镜22:30所以呢即使产出里面有明显的bug22:32他也能做到视而不见22:33给自己打个高分之后就草草收工了22:36所以呢 Anthropic 就直接把前面两种方案都给废弃了22:39搞出了第三个方案22:40那就是做一个专门的评估 Agent22:42来评估产出质量22:44由于这个评估 Agent 是一个独立的第三方22:47他自然就没有理由去替别的 Agent 产出护短22:50评估结果也就客观多了22:52而且把评估 Agent 单独拎出来还有一个好处22:55那就是我们可以单独去优化22:57去训练这个评估 Agent22:58让他的评估效果做到最好23:00对，这个就是 Anthropic 的最终方案了23:03换句话说23:04我们最终需要把生成代码和质量评估23:07这两件事情给拆开23:08分别交给两个不同的 Agent 来做23:10其中负责生成代码的那个23:12叫做 Generator23:13负责质量评估的那个叫做 Evaluator23:16这个呢就是最终的质量评估流程了23:19所以质量评估这一环节23:21我们提到了两个 Agent23:22一个是评估用的 Evaluator23:24一个是生成代码用的 Generator23:27再加上之前说过的 Planner23:29我们就有三个 Agent 了23:30下面呢我们来画一下持续图23:32看看这三个 Agent 是怎么分工合作23:35完成用户需求的23:36首先是 Planner23:37他会把用户的需求拆解为具体的功能列表23:41然后发送给 Generator23:42Generator 接收到功能列表之后23:45他会从中挑选出一个功能点23:47然后呢他就就着这个功能点23:48去跟 Evaluator 讨论下交付标准23:51也就是讨论下23:52到底做到什么程度才算是完成了这个功能点23:55Generator 呢23:56首先会把他的想法发过去23:58Evaluator 呢一开始可能会对这个提议24:00提出一些修改意见24:02然后再发回给 Generator24:04Generator 呢会根据意见再次提交新的交付标准24:07所以呢这个过程会重复个几次24:09直到 Evaluator24:10确认 Generator 的提议没问题为止24:13确认好交付标准之后24:14Generator 便开始生成代码来实现这个功能点了24:17实现完毕之后呢24:19Generator 会把他的实现结果24:21提交给 Evaluator24:22Evaluator 会对结果做出评估反馈24:24比如说是一开始可能评估不通过24:27那如果不通过的话呢24:29Generator 就要修改代码了24:31所以呢这个提交结果评估反馈的过程24:33也会重复个几次24:35直到 Evaluator 评估通过为止24:37到这里一个功能点就算是24:39开发完了24:40但是我们不只有一个功能点啊24:43所以呢我们就需要再一次24:45重复之前的这个流程24:46把后面的功能点全部都逐步做完24:48这个呢就是大致的流程了24:51Anthropic 把这个包含了三个 Agent 的方案24:53叫做 Full Harness 方案24:55相比之下24:56那种只靠一个 Generator24:57独立完成所有需求的传统单 Agent 模式25:00被 Anthropic 称为 Solo 方案25:02Anthropic 拿了一个具体的任务25:04来验证这两个方案的差距25:06这个任务呢就是做一个25:08游戏制作工具25:09从效果上来看啊25:11Solo 和 Full Harness 这两个方案的差距25:13还是很明显的25:14Solo 方案的问题呢很多25:16比如说是布局不合理25:18产品逻辑难以理解25:19bug到处都是25:21基本上呢是没有办法用的25:23而 Full Harness 方案呢就有了明显的改善了25:26无论是布局25:27还是整体的产品逻辑25:28都达到了可用的水准25:30虽然还是存在一些问题25:31但比起 Solo 方案来说25:33Full Harness 的效果呢是明显要好不少的25:36当然这样做也不是没有代价的25:38Full Harness 方案的耗时和花费25:41都要明显的高于 Solo 方案25:43Anthropic 给出了一个对比表格25:45大家可以感受一下25:47Solo 方案耗时 20 分钟25:49花费9美元25:50而 Full Harness 方案呢是耗时25:536个小时25:54花费高达200美元25:56所以可以看出 Full Harness 的方案25:58无论是耗时还是花费都要远高于 Solo 方案26:01虽然如此啊26:02但不得不承认 Full Harness 的方案26:04效果确实是好了不少26:06毕竟精雕细琢是有代价的呀26:08这对我们人类来说也是一样26:11考的60分可能只需要复习三天26:13但是想考的90分26:15那可能就得复习一个月了26:16这个大家多少都会有些体会吧26:20最后再提一个26:21Anthropic 后来做的优化点26:22让我们重新看一下这个流程图26:25注意其中的这一部分26:26这一部分说明了 Generator 每次26:28只会选取一个功能点26:30做完这个功能点再做下一个26:32循环往复直到完成所有的功能点为止26:35这个逻辑呢是 Anthropic 在26:37提示词里面强制 Generator 这么处理的26:39否则让 Generator 自行发挥的话26:41它还是会急于求成26:43最后留下一堆烂摊子26:44不过在 Opus 4.6 发布了之后26:46这个约束就不怎么需要了26:48Anthropic 后面就把这一部分给去掉了26:51最后呢就简化成了26:53这个样子26:53那为什么后面就可以这么做了呢26:56因为基于 Opus 4.6 做的 Generator26:58变得更强了26:59它可以一次把所有的功能点全部都拿过来27:02自己决定先做哪个再做哪个27:05稳步地向前推进27:06不需要别人再对它的执行流程指指点点27:08而在这种情况下27:10Evaluator 也直接评估最终产出就可以了27:12不需要再分功能点评估了27:14关于这一部分27:15我们在下一章节还会提到27:17这里你有个大体的概念就行27:22在这一章节里27:23我们来聊聊目前争议最大的一个问题27:26Harness Engineering 到底是不是一个噱头27:28要回答这个问题27:29我们不妨先来扒一扒27:31这个词到底是怎么火起来的27:33首先，单就 Harness 这个词来说27:36其实它并不算是一个彻头彻尾的新词27:39一般大家用它来指代为了支持某个功能所做的一套框架27:43我们来举几个具体的例子27:46比如在传统的软件测试领域27:48就有一个概念叫做 Test Harness27:50它代表为了支持测试代码运行而做的一套框架27:54这个框架里可能包含测试运行器、测试环境等等27:58而在 AI 领域27:59很多开发者其实也早就默默在用这个概念了28:03比如有个开源的项目叫做 lm-evaluation-harness28:06它就是为了支持模型效果评估而做的一套框架28:10不仅如此28:10我们刚才重点讲过 Anthropic 去年 11 月发的一篇文章28:14叫做 Effective Harnesses for Long-Running Agents28:17这里的 Harness 就代表为了支持 Agent 长时间运行而做的一套框架28:22所以你看28:22Harness 这个概念一直都在那儿28:24大家也都在默默地用28:27谁也没觉得这是个需要大吹特吹的新概念28:30可以说28:30Harness 这个词本身并不是重点28:33重点是 Harness Engineering28:35把这两个词组合在一起28:37其实是最近才发生的事28:39目前比较公认的起点28:41就是我现在屏幕上所展示的这篇文章 My AI Adoption Journey28:46这篇文章在今年 2 月 5 号的时候发表28:48作者是 Mitchell Hashimoto28:51可能国内有些同学对这个人不太熟悉28:53但在海外技术圈28:55他绝对是响当当的人物28:56很多大公司的底层工具都是他做的28:59在这篇博客里，他写了这么一段话29:02这段话的大意是说我也不知道业界有没有公认的叫法29:06我就姑且管它叫 Harness Engineering29:09它的核心理念就是29:10只要 Agent 犯了错，你就去改造系统29:13让它绝不再犯同样的错29:15要是有更好的词，我随时改口29:18你看，大佬还是很实诚的29:20所以这个词的起点其实非常朴素29:23甚至带着点随意29:24跟后来大家讨论的宏大概念还是有区别的29:28从传播情况来看29:29这篇文章的讨论热度其实并不算很高29:32那 Harness Engineering 到底是怎么火起来的呢29:36在很多人的认知里29:37真正引爆这个概念的29:39是几天后，也就是 2 月 11 号29:41OpenAI 发的那篇 Harness Engineering 文章29:44就是我们之前讲过的那个29:46这篇文章信息量极大29:47迅速就在业界引起了巨大反响29:50紧接着29:51整个 AI 圈就像触发了连锁反应29:53仅仅 6 天后，也就是 2 月 17 号29:55软件工程界鼎鼎大名的 Martin Fowler 网站就发了一篇文章29:59作者是 Thoughtworks 里一位非常资深的工程师30:03文章标题叫 Harness Engineering - First Thoughts30:07就是她读完 OpenAI 那篇文章之后的第一反应30:10作为顶级技术博客30:12这篇文章一发出来自然就在圈内引发了广泛的讨论30:16但抛开技术观点不谈30:17她在文章里还点出了一个很耐人寻味的细节：30:21虽然 OpenAI 这篇文章的标题有 Harness Engineering 这两个词30:25但如果你仔细去翻 OpenAI 的文章30:27你会发现这篇文章的正文里其实只提了一次 Harness 这个词30:31因此她推测30:33OpenAI 搞不好就是受了 Mitchell Hashimoto 的启发30:36事后才临时把 Harness Engineering 这个词放到了标题里面30:40虽然只是个猜测30:42但也给人带来了很大的联想空间30:44随后到了 3 月 10 号30:47LangChain 发了一篇文章30:48叫 The Anatomy of an Agent Harness30:51这篇文章第一次明确给出了关于 Harness 的公式30:56就是这个 Agent = Model + Harness30:59这其实就是我们前面聊过的那个公式的变体31:02当时我们把 Harness 移到了等号左边31:05我们讲的是 Harness = Agent - Model31:09这两个等式其实本质上是一回事31:11公式一出，概念就算定调了31:14随后在 3 月 24 号31:16Anthropic 发了那篇 Harness 的文章31:19拿出了 Planner、Generator 和 Evaluator 的经典架构31:22这个我们之前也讲过31:24虽然 Anthropic 自己比较克制31:26通篇依然只用了 Harness 这个名词31:28并没有生搬硬套 Harness Engineering 这个刚刚炒热的新词31:32但在当时那个氛围下31:33整个 AI 圈可以说是心照不宣31:36直接就把这套三 Agent 架构31:38当成了 Harness Engineering 的教科书级案例31:41就这样，一传十，十传百31:43Harness Engineering 从一个人的私人说法31:45变成了大家都在用的词31:48但如果你复盘完这段历史31:51再仔细琢磨一下31:53就会发现一件非常微妙的事情31:56Harness Engineering 里用到的所有技术31:59竟然没有一个是新的32:01你看我们前面讲的 Linter 代码检查32:04任务拆解规划、质量评估机制32:06这些东西其实早就有了32:09相信看这个视频的很多观众甚至都在做相关的工作32:12Harness Engineering 真正做的32:14只是把这些技术重新组织了下32:16统一放到了一个新词下面32:19换句话说32:19它提供的是一套新的系统思维框架32:22而不是发明了一批颠覆性的新技术32:25既然没什么新技术32:26那难怪有些人会觉得 Harness Engineering 这个概念被高估了32:30甚至带着点‘炒作’的成分32:32仔细听听这波怀疑论者的声音32:34你会发现他们的攻击点主要有两个：32:37一方面32:40Harness Engineering 根本没有新东西32:42全都是“新瓶装旧酒”32:44在这种情况下32:45特意造个新词到处宣传32:47可不就是噱头吗32:49不仅如此32:50这波怀疑论者还提出了一个更扎心的观点32:53所有的 Harness Engineering 都迟早要被淘汰32:56他们认为32:57随着大模型自身能力的持续进化32:59今天看起来必不可少的这些 Harness 设计33:02未来很可能会被模型能力本身逐步吸收33:05最终变得不再需要33:07而这种担忧33:07其实连 Anthropic 自己的文章里都有迹可循33:10前面我们讲过 Anthropic 的 Harness 核心方案33:13但文章里还有很多细节33:15很值得细细品味33:16这里我们仔细研究下其中的两个问题33:19然后分别看看 Anthropic33:20一开始用 Harness Engineering 是怎么解决的33:23以及后来模型强大了之后33:25如何用模型解决33:27我们第一个要探讨的问题就是上下文焦虑33:30这个是 Sonnet 4.5 的一个问题33:32具体来说，就是当上下文过长时33:35模型会急于结束任务33:36以更少的 token 完成交付33:38而这往往会影响最终质量33:41Anthropic 一开始是使用了一种33:43叫做上下文重置的 Harness Engineering 技术来解决这个问题33:47但后来33:47当模型升级到更强的 Opus 4.5 后33:50这种现象被大幅缓解33:52因为 Opus 4.5 没有明显的上下文焦虑问题了33:55也就不怎么需要这方面的 Harness Engineering 设计33:57第二个相关的问题是长任务的执行效果差34:01这点其实我们之前也提过34:03让我们一起来回忆一下34:05Anthropic 的链路包含 Planner34:07Generator 和 Evaluator 3 个 Agent34:10一开始的设计是逐个功能点执行34:12也就是说34:13Anthropic 会在提示词里面强制 Generator 每次只选取一个功能点34:17做完一个再做下一个34:19以便确保整个产品开发流程稳步向前推进34:22不过，等用到更强的 Opus 4.6 之后34:25这种强制分步执行的机制就不需要了34:28因为 Opus 4.6 的全局统筹能力够强34:30它可以一次把所有的功能点都拿过来34:33自己决定先做哪个再做哪个34:35稳步推进34:36不需要别人对它的执行流程指指点点34:39你看34:40这恰恰印证了一个非常现实的趋势34:42模型越强，需要的 Harness 就越少34:44大模型自身的进化34:46正在一口一口吃掉 Harness Engineering 的生存空间34:49当然，为了严谨起见34:50我需要补充一句34:51Anthropic 官方在文章里其实没这么悲观34:55他们认为，随着模型变强34:57Harness 的形态也会跟着进化34:59去解锁更复杂的任务35:01也就是说，Harness 只会变形35:03不会消失35:04但我们不妨大胆推演一下35:06如果未来的模型真的强到离谱呢35:09这并不是说未来连读写文件、联网搜索这种基础工具都不需要了35:14而是说35:14也许只要给大模型配置上最基础的 Harness35:18它自己就能把剩下 99% 的问题全搞定35:22真到了那一天35:23Harness Engineering 就不再是一门需要大家专门去钻研的技术了35:27它会退化成一个单纯的环境接口、一个底层基础设施35:31仔细想想，这件事发生的概率35:33恐怕没有那么低吧35:36所以说了这么多35:37我们还得回归原来的问题35:39Harness Engineering 到底是不是噱头35:41这里我来聊下我个人的看法35:43可能有误35:44仅供参考啊35:45我的观点是35:46Harness Engineering 不是噱头35:48但应该也不是终局35:51说它不是噱头35:51是因为它已经实实在在带来了效果35:54无论是 OpenAI 还是 Anthropic35:56都通过 Harness Engineering35:57把 Agent 的稳定性、自动化程度和生产力往前推了一大步36:01这些都是可以被验证的工程成果36:04而不是概念炒作36:05当然，也有人会说36:06它不过是“新瓶装旧酒”36:08用的都是老技术36:10但问题在于，工程领域真正的进步36:13往往不在于发明了什么新技术36:15而在于有没有一套统一的框架36:17把这些零散的能力组织起来36:19变成可以系统设计、可以持续优化的工程方法36:23Harness Engineering 的意义36:24恰恰就在这里36:26但我不得不承认36:27Harness Engineering 大概率不是终局36:30随着模型能力继续增强36:32今天这些用来约束模型、纠正模型、给模型兜底的系统设计36:37很可能会被模型自身逐步吸收36:39到那个时候36:40很多 Harness 可能会变得不再必要36:43这个词也许会慢慢淡出大家的视野36:46所以我更愿意把它看成一个36:50过渡期的关键技术36:52它可能不是未来的终局答案36:55但它是当下最现实的答案36:57因为让我们回到今天36:58模型依然会犯错，依然会幻觉37:00依然会在复杂任务中偏离轨道37:03在这种现实下37:05Harness Engineering 的重要性就不容忽视37:07可以说，谁能把 Harness 搭得更稳37:10谁就能更早把 AI 的能力转化成真正的生产力37:14从而从中受益37:15好了，今天的视频就到此结束了37:18我是马克37:19用最通俗的语言讲最硬核的技术37:21我们下期再见，拜拜
1,823 words · 1071 lines
