Harness社区分享实录：AI Agent的操作系统

5月23号在“东京生成式AI社区”分享了一个关于Harness的内容，这里总结成一篇文章，分享给大家！
一、从Chat到Agent的演进
我们知道，AI从2022年出来以后，是以一个聊天框的形式出现的。所以当它出现两三年以后，大家都在努力地学这个提示词怎么写好，才能让它给我们更精准的回答。我们也知道,基于chat这种AI,它是一问一答,状态就丢了。为什么两次问答之间它能有连续呢?是因为我们每一次问答的时候都把历史给他带进去了,就是个”前情提要”。

当AI各大语言模型能力提高,一直发展到2025年的时候,Agent成为一个火热的话题,业内把2025年定性为Agent元年。

而2026年年初,就提出了Harness这个东西,或者说是思想。Harness究竟是个什么东西呢?它其实不是一个具体的平台,也不是具体的一个技术,它是一组组合,是个理念,是个思想。

它会干什么呢?第一,它会调用工具,当然不是它自己调用,它是指挥模型去调用;并且它能长期运行,这是大语言模型不具备的能力。它可以让大语言模型长期运行,包括数据的持久化记忆、长期记忆、短期记忆等等。以及在现实的生产中,我们知道当一个任务执行的时候,断点恢复这种能力是必须具有的,它也具有。

如果再细分一下,就是两个大阶段——从Chat走向Agent。从工程学角度上,最开始是Prompt Engineering,后来提出了Context Engineering,这都是大家比较熟的,包括到现在2026年3月份左右,大家又提出了Harness Engineering。它不同的Engineering,是一个上台阶的过程,它解决的事情是越来越复杂的。

如果用简单的话说,Prompt是干嘛的?它就是让AI听懂任务。Context Engineering干什么呢?它是让AI接收内容的时候有所依据,不是乱给的,也不是海量能力来给他他就都接受了。那Harness就更高级了,它是让AI精准可控地完成一个复杂的操作。所以我的标题就叫做”AI的操作系统”,其实就是用Harness这个内核开始搭建起来的。

二、形象的比喻:马具与马

举个形象的例子。这个图大家应该看过吧,经常刷X或者公众号可能刷到——所有大语言模型都是一匹马,Harness就是给这匹马用脚蹬、马鞍、缰绳等等,只有给它配了这套东西的时候,你才能有效地控制一匹马。

我们想啊,如果这个马没有这些东西,那个马的作用是什么?一,可以用来吃,对吧?中国人讲究吃,马肉可以吃。二,如果它没有缰绳,在野外跑,风景比较好。基本上除了这两个功能就没有了。但是一旦给它装上这些马具以后,它可以干嘛?第一,可以当作交通工具;还可以当战争工具;还可以用它去得奥运金牌,做马术表演。有了马具以后,它能干的事儿就越来越多了。

现在的Agent,Harness和大语言模型就是典型的这种关系。如果你不给这个大语言模型套上一个Harness的马具的话,它可能就乱七八糟瞎发挥,瞎花你的钱,并且回答的效果很差。一旦我们给它套上这个马具,它就在我们的掌握之中了。

三、生产级Agent与消费级Agent的区别

生产级的Agent,它并不是OpenAI、Claude或者其他Agent的Harness——它们只是一个自主式Agent的平台,就是说你不会打字拿过来也不熟就能玩了,你干什么不知道,可以什么都干。它并不是说是在生产中的,它是消费级的一个自主式Agent。

我们更多的场景,其实在现实中,更多的场景是在垂直领域。生产级别的Agent是需要我们这种专业的做Agent的,或者做代码的人转型以后去构建的。你始终相信哈,你是程序员,你不会被淘汰的。淘汰的是什么?你要是不去学,光守着原先那套Java、.NET或者Python,就是代码级别的,这些人会被淘汰,因为我们知道Claude Code分分钟秒杀你。但你要是守着这儿不变,你会被淘汰。但是我们学Agent的开发,在升完级以后,未来的企业级Agent肯定是由这帮人去构建的。如果你不会写代码,一行代码不会写,你构建一个复杂的系统,它的难度是极高的。

那真正的生产级Agent干什么呢?它是要让Agent在真实的世界稳定地运行。第一,它必须真,不能糊弄事;第二,它必须稳定。在日本要求更稳定了,是不是日本要求这个小细节比较多?

要做到稳定,现实中会有很多问题。比如说Function Calling调用工具失败,特别是好多人自己写这种Function Calling,可能就会导致失败,失败有多种多样。还有长期任务,原来一个任务跑两个小时五个小时怎么办?还有提示词注入——把原先的提示词改掉,”以我这个为主,他那个是假的,我这个是真的,一定要听我的”,可能就那个越狱了。像这些问题,在生产中如果黑客去攻击你的话,分分钟就给你搞定了。如果你不做Harness的处理,分分钟就被搞定。如果这些东西搞不定,你在生产中怎么稳定呢?客户可能就翻了天了。

基于这一点,Harness才会被提升到一定的高度。它真正解决的是什么呢?稳定可靠、安全可控、可观测、可恢复、可协作、可审计。特别是给一些大手做东西的时候,你每一个蛛丝马迹都要留下来,一旦出问题,要去复盘找责任。

四、Harness的12个模块概述

基于Harness思想的AI编程,就提上了日程。因为Harness现在不是一个标准组织的标准,业内没有说Harness就是什么什么的准确定义。这12个模块,只是我根据工作经验结合学习的一些东西,把它抽象成了12个模块。分为控制层、认知层、可靠层和运营/支撑层。我们从支撑层面一一道来。

五、模块一:编排循环

我们知道大语言模型,前面说了,它是一问一答,并且无状态,问完就结束了。但你做一个具体的工作的时候,不可能是一锤子买卖。所以我们首先第一步,要让我们的Harness这个项目循环起来,去调度我们的大语言模型。

循环有多种多样的方式。大家知道Claude Code是怎么循环的吗?前一段时间Claude Code的源码不是泄露了吗,它就是写了个while循环,结束了——就是最傻的那种循环方式。当然业内还有很多高明的循环,根据你的业务场景不一样而不一样。

最流行的就是ReAct这种,强调”思考-行动-观察”,再”思考-行动-观察”三个步骤循环。还有的是基于计划的循环方式,就是让大语言模型先给我个计划,有几个代理讨论讨论这个计划没问题,确定出来给你显示出来,接下来它就按着计划,第一步第二步第三步第四步第五步,当然每一步它又有一个小循环套着。所以说同样一个问题,深度思考模式下时间有时候相差很大,就是因为它给的计划可能不一样,每个计划执行的时间也不一样。

不管你Claude Code、Codex或者ChatGPT,它都是自主式的代理,还不是生产级别的,它是消费级的。我们在生产级别中常见的循环有什么呢?一种是一个一直的循环,就像Claude Code的while循环;还有就是基于工作流方式的循环,因为在企业级是一个等级一个等级的,有些东西是需要层层审批、转交等等,就需要类似工作流这种循环。还有就是基于Actor模式的,一个Actor就是一个行动,比如AutoGen,微软的一个Agent框架,就是基于这种方式去做循环的。至于哪种循环,是根据你业务决定的,不是说有一个循环放之四海皆准,要根据你业务去定义。

在做循环的时候需要注意几点:第一,你一定要设定一个最大循环数,因为我们知道AI是有幻觉的,它是不确定的;不用说AI了,我们一会儿讲到人也不确定。包括Token的上限、最大的尝试次数,包括在我们开发界内有并行运算,起多个多线程并行,该串行串行、该并行并行;包括有的时候转给人的时候一定要转给人,关键环节一定要转接给人。这些都是循环中应该注意的几个点。

六、模块二:工具系统

第二个模块是工具系统。AI的能力很有限,一旦训练完它,这个时间就截止了,你要问它今天是几月几号,大部分AI就给你出来训练截止的那一天。它不会知道当前的天气等等,所有知道的都是加了工具的。现在的ChatGPT是有这种能力的——今天几号、天气怎么样,它有这种能力,是因为它有工具在后台调用。

生产级一定有工具。为什么?一定有企业的内部私有数据,我们也会把内部的私有数据做成各种各样的工具来使用。

至于工具有哪些,简单列举一下:

第一个是Function Calling,这个是早期各大模型公司在写自己的模型时就具有的能力。悲剧的是,各家模型公司这个调用方式不一样,不统一。Anthropic比较精,达里奥比较”鸡贼”,但这个人是很聪明的,他的公司就推出MCP——既然要调工具,我让全球的AI都有一个规范,这样对开发者特别友好。所以开发者就说,你退出这个协议太好了,我写代码写一次就行了,你们模型把底层的东西抹平。所以大家都说Anthropic不错,就是因为它推了这个工具。接下来谷歌又推出了A2A,看见Anthropic推出工具协议,我要推一个A2A协议,就是代理之间的交流协议。这些协议都在发展,不要说我今天看了它就定型了,不是的,因为我们知道AI现在是早期阶段,它一直在发展。

最后一个是Skill。我在网上分享的时候我也在思考,它本质上并不是一个外部的工具,Skill最终会转化成一组提示词喂给大语言模型。但是我们知道Skill是具有专业能力的,你用起来像一个工具,所以我把它单独抽到工具这里。当然你也可以把它放在上下文提示组装那里,都是可以的。

MCP我刚才说到了,它真正解决了一些什么事呢?就是从每个框架单独对接工具,转成一个开放互联协议。它是客户端调用大模型时给它的一个能力。

在做工具系统的时候,我们知道权限是很重要的,权限这块历来是被利用的一个漏洞。所以做这个工具,特别是我做了一个系统,不同的角色可能使用工具的权限就不一样。比如你去用AI产品的时候,有些东西你就看不见,可能财务的人就能看见——每个人的工资你就看不见。所以调用工具的时候,每个角色权限要落到这里进行统一管理,包括一些审批方法,有些方法没权限调用,要审批要扩;最严格的这种,要做沙箱隔离。包括各个工具调用的入参出参、调用时长等等都要跟踪。

跟踪监控这块是一个生命线,你但凡做系统的话,这是最基础的一个生命线。特别是做AI产品,因为AI对大语言模型就像一个人一样,它不知道它怎么想的,所以做好跟踪在做AI项目的时候是特别特别重要的。

七、模块三:结构化输出

大语言模型有幻觉,即使你问它同一个问题,同一个模型只隔了三秒,它的结果可能都不一样。因为它是根据人类的语言去训练的,典型的是接龙,指不定后面接什么。

但是我们写代码或者企业级应用,你输出的结果如果具有不确定性,谁都接受不了。今天存钱了,存一百块,结果只有五十到账,在银行卡上只有五十,可能吗?或者你基于MCP去做支付,你支付了十块钱,对方收到二十块钱,也不可能。所以说这种结构化的输出,是我们Agent给Agent或者我们给大语言模型交流时的一个核心。

所以一定要把你的输入输出结构化,结构化就意味着确定性。当然我们不只是结构化,还有一系列手段,包括Pydantic这种Python的验证库,回来的结果我们要验证。还有更高级的做法,如果你要微调模型了,可以在微调的时候就让大语言模型给我吐出我想要的结构化的东西,都是可以的。前两个是放之四海皆准的。

我们在调用工具的时候一定要去验证,验证完以后如果不对,你要追加重试。大语言模型越好,成功率就越高,可能一次失败了,你重试一次,成功率就大增了。包括如果有上下文能把它修复、自动修复,就不用去回退;包括最后不行扔给人,让人去决策,AI或者系统会替它做决策。

八、模块四:记忆系统

接下来是记忆系统,这是一个比较重要的系统。我们知道大语言模型是无状态的,所以它什么事都记不住,但是也不能说所有事都记住。因为我们知道再好的大语言模型,它也是有Token窗口的。就是说你家非常有钱,比尔盖茨,其实咱也得注意这个窗口,否则的话钱都没了。

让Agent不要每一轮都从零开始,说白了就是”你给我记住,你必须给我记住这件事”。它怎么去做呢?其实就是分长记忆和短记忆。长记忆是什么呢?就是你这个任务、这个工程是干什么的、产出是什么,比较宏观的一些数据要放在长记忆里;短记忆就是本次会话或者最近若干分钟的东西要放到短记忆里。

比如说”三分钟以后干什么”,你的记忆系统就要把这个记起来,当前时间是多会儿,三分钟以后是多会儿,肯定放在短期记忆里。但是短期记忆,在三分钟以后,这句话还有意义吗?是不是就没意义了?所以三分钟以后,短期记忆也可以把它去除掉。

类似这种东西,你要构建一套系统让它来控制短期长期记忆,只存放有效的记忆。

它的难点不是存不存,是你存下来的东西要有用——这是做记忆系统的核心。你不能都记,也不能都不记。但有时候你要防止内容腐烂,其实没用了,你还一直存着它,每次交互的时候带上都是浪费Token的。

九、模块五:上下文管理

上下文管理决定了模型这次交互看到了什么。大家觉得记忆系统就有了,我还要上下文管理干什么?其实上下文管理和记忆是有所区别的。我们可以这样想:记忆是一个仓库,或者处理这个仓库进出的一些手段;而提示词是当前这个会话窗口的一个调度器。它和你整个记忆仓库是两码事。所以它只负责一次提示的上下文窗口的组装。

在上下文组装的时候,它可能去查记忆长短记忆库里的数据,也可能去查你的RAG库或者关系型数据库。

做的时候有这四个动作要做到:第一是裁剪,也叫压缩;还有检索,就是我们做RAG常常用的——其实RAG整个放在Harness中,就是这样有用,只是检索用的;包括筛选;包括重排。在整个组织上下文的时候有这种需求,要用这四个动作来提升你提示词的价值。

这里有两个灾难需要注意。第一个灾难是:我觉得什么都有用,我都扔进去——不是说不可以,但是研究表明,如果一次会话窗口内容太多的话,大语言模型会关注前面的内容和后面的内容,中间的内容容易被扔掉。所以你要是内容越多,可能你的大语言模型会失真跑偏,产生不确定的输出。所以不要越多越好。如果从软件工程的角度,我们应该讲究极致的少,结果就会非常准确,一定要极致的少,越少越好,达到目的就行了。我建议——中国不是有文言文吗?能把好几百字缩减成很短的字,你可以试试文言文提示词效果怎么样。

第二个灾难就是腐烂坍塌。把一些无效的信息扔进去,大语言模型都跑偏了,整个效果就非常差。

所以一定要区分Memory和Context:一个是仓库,一个是当前会话的窗口。

十、模块六:提示词

提示词又出来了,很奇怪。其实在Harness中的提示词,它就不简单是一段文本。我们知道程序运行之前,特别是高级语言,它要经过编译。其实这里一样,我要把这种文本编译一下喂给大语言模型。就像刚才说的,我把这种大白话做成一个精准的文言文喂给大语言模型,道理是一样,我要编译它一下。

怎么编译呢?有几种方式:

我们知道提示词最早学的有系统提示词。系统提示词是指挥着模型基础能力的一个地方,所以它一定要组装好。第二就是,特别是基于工作中的Agent,它的目标一定要明确,它任务干什么一定要明确。再有,我们在编译提示词的时候,本次对话它可以使用哪些工具——我们知道现实中的工具是非常多的,但是这次对话它使用的工具肯定是有限的。如果我们给它扔一千个工具、一百个工具、十个工具,肯定十个工具是更准确的。所以每次运行一小时交流了一千次,一千次中每次给大语言模型交流的时候,可能带的工具都不一样,因为我们每次对话的目的性不一样。接下来就是上下文,要从上下文包括记忆系统里检索数据,就相当于RAG了。最后就是结果输出的结构是什么。

提示词组装更是聚焦于这个维度的事:进去是什么,出来是什么,提示词是什么,调用工具是什么,这个维度卡要卡好。

提示词设计完不是没有玩,你还要注意它的可测试性,比如说这次的启动提示词进去是什么样的,效果怎么样,我都要记录下来。还有缓存——系统提示词一般在同一个代理中是不变的,这样大语言模型就会把它缓存起来,这样花钱的时候我们就少花点儿,因为大语言模型在调用缓存的金额和调用普通输入输出的金额是不一样的。所以如果系统提示词大的话,最好都有,便于让它缓存起来。还有可解释,就是为了让这个系统更优化。

十一、模块七:状态与检查点

我们说了生产的Agent跑的时间很长,指不定会出什么问题。所以状态就是保存一下它的状态,从哪个状态能恢复起来,这也是我们的能力。如果说你的代理就是一锤子买卖、两锤子买卖,就不需要构建这个了。

Harness工程并不是说但凡你做Agent系统,就必须把12个模块都用上,不是的。它是积木式灵活组合,根据你的情况去选择,用什么不用什么,并不是一定要用上的。这个就是适合于这种长期任务或者数据量比较大的任务,去做进度的保存,一旦掉了它还能跟上。

第一是运行时间长;第二是要人工审核的情况,AI蹦出个界面也好,或者给你发个短信也好,让你来人工审核。那这个人可能就度假了十天,他回来的时候才给你按照审核,那十天你也得把状态保存起来。当然这个保存可以五天,你自己设最高上限都可以。这一点就是只要有人工介入,人工介入之前一定要把状态保存起来。还有后台的一些异步处理,异步处理有个诡异的事:你根本不知道谁先回来谁后回来,所以这个状态也需要去存。还有需要恢复的一些数据也需要去做处理。

基本上状态和恢复点,就是让我们运行中的数据可以随时暂停、随时恢复,并且还能存放回归,包括时间也可以回溯——重放。我以前在市场做交易的时候,做过一个系统就是重放。今天交易了三千万笔,我把它录下来,新系统出来以后,我就重放这三千万笔,看看新的系统上线有没有什么问题,这里也能用到。还有包括时间的模拟回溯等等,都是这样一个道理。

十二、模块八:错误处理

做代码也好,大语言模型也犯错;我们程序员更是犯错。所以错误处理一定是每个系统必须有的。最简单的错误处理就是Try Catch,但是Harness中不是Try Catch,它更多的是让你这个系统能恢复回来。错了,现在已经错了,肯定要恢复回来,它还不是简简单单报警、提醒这类机制,它已经发生错误了。

做Harness的错误处理系统,错误分为很多类:

最最常见的是瞬时错误,比如网络抖动一下,429等等,这种没事,下次试试就好了,但一定要区分开哪次长处、哪次短处,怎么去重试,这样的区分。第二是结构化错误,比方说大语言模型给你返回的结果是错的,那这个结果错,我要重新调度这次问答重新跑一遍;如果还错,我要用指数级的重试——比如一秒错了,一秒试一下还错,我就放到三秒,还错可能就五秒或者七秒。重试的策略一定要有,不同的错误也不一样。还有一些就是业务逻辑的错误,比如下个订单下个负数,你还得给他钱了。像这种错误也在Harness里,因为它是全是Agent的工作。这些边界你要卡不好,错误处理不了的话,有可能人家买了那个东西,你给他打了三百块钱。所以Agent里这块都要具备,业务逻辑的错误都要概括进去。

我相信这一点,只要写过代码都知道这些错误怎么去处理。这里就不展开说了。我现在讲的全是理论,但是这些理论现在不同的AI Agent都有落地的代码。等到具体代码的时候,可以给大家具体举这些例子。

十三、模块九:护栏

接下来是Harness比较特有的东西——护栏。护栏是干什么呢?它是AI Agent系统的一个内核,安全的内核。就像我们做操作系统,每个操作系统都装着一些杀毒软件、网络防护等等,本身就带有一些安全性的东西,或者说我们外部还得装一个杀毒软件去防护。所以护栏是特别重要的。

护栏一般要护哪些东西呢?

第一是输入。有可能你不知道谁输入了,他输入的东西符合不符合你要的数据,我们要发现。第二是上下文组装的时候,你要从一些数据库或者RAG里采取数据,如果这些数据被污染了,你拿给大语言模型,后果也很严重,所以你要去检查。接下来是我们调用一些工具的时候,一些Key有没有权限访问,或者它访问了是不是给了大语言模型,或者给了别的环节存下来,等等,包括滥用这种Key、工具调用时的参数等都要去做防护。包括输出的防护——大面上的暴力、色情这些大语言模型都给你防护了,但是你在垂直领域,你的业务级别的数据大语言模型可不知道,这个数据它都给出来了,不知道这个人有没有权限看,或者这个人提示词给你越狱了一下,他都能看见了,所以这些东西也要防护。所以分为这四层去防护。

还有一些高风险操作,我们也需要用护栏去处理。一个是执行Shell终端命令,特别是有时候我们为了偷懒会让大语言模型给你生成Shell,马上调用工具去执行,发现车盘没了。还有SQL注入操作、文件操作和外部的交易,特别是涉及到钱这种交易,也是需要注意的。你像Codex,它其中一个护栏作用就是说,我们在写代码的时候是不是要指定一个文件夹,Codex指定一个文件夹,它都跑不出这个文件夹,在这个文件夹可以翻了天,但是它出不来到别的地方操作哪个文件夹——这就是Codex给它放到一个护栏,其中的一种。

十四、模块十:验证与反馈

验证与反馈这块就相当于闭环了。它说的是,你这个代理,或者你这次回答靠不靠谱,接下来怎么改正,迭代升级让下一步这个系统更好。

基本上是这三个方面:

第一是离线测试。你上线前或者新功能开发完,肯定要有一个离线的测试,不是在生产级别的。比如我做了一个新的Agent或者升级了,我这个提示词还准不准确;我这个模型升级了,把模型ID换了一下,以前什么都没变,那它准不准确——你都要建一个评测系统,让它跑出来去看结果。发现问题肯定要改进,我回归,还是想什么办法切换模型等等都要做相应处理。

第二是在线评测。就像我刚才说的为什么能回放,把所有流量都录下来,这里一样,要把真实的流量——当然它并不是回放用的,它是评测用的——你可以去抽样,三秒以内,或者以时间,或者以数量,每十次请求有一次,等等都可以,把它抽样出来,看它的结果是怎么样的去评测。

还有人工反馈。如果你录下来人工介入进去,就知道哪些”哎呀,这个代理这个提示词效果真好,运行了一百次没问题”,哪些”这个运行了一百次有十次错误,10%,90%成功率比较差”,人要把这些东西都记录下来,塞在评测数据库,这样评测的数据库就会在一定程度上该报警的报警,该调用提示工程优化的优化,该走好的分支避免走差的分支。这就是需要人工去介入反馈,即使在做一个好的验证和反馈系统的时候都有涉及。

它基本上就是在我们平时过程中的跟踪、监控,包括Log,这些都要记录下来,拿着这些东西去分析,分析完以后汇总成一个验证数据库,以备我们后期工程中去使用,基本上是这样一个工程实践。

十五、模块十一:多Agent编排

接下来是多Agent编排。主流的Agent SDK都有,但是每个SDK这个能力或多或少不一样。其实多Agent,我们要让一组Agent工作,本质上就是一个分布式系统,各司其职,干完一个代理就把数据给下一个。

编排的模式有多种,我简单列举一些常用的模型:

比如委派模式:我是老大,有一个开发人员、一个测试人员、一个产品经理,我给他们分配工作,你们去干吧,这就是委派模式。

并行模式:同一个任务,两个角色一样,你俩都去干,谁的结果好我用谁。

辩论讨论模式:特别是有争议性的东西,来个头脑风暴,A、B、C,先A说,A说完以后一定要把它的结果和问题给B,B呢又要根据自己的(他的提示词也不一样,他有自己的主见),拿上A的结合自己的说;C拿上A、B的说;接下来A再拿上B、C的说,这样套套下来。

接下来是交接模式。其实上面也有交接,循环中也是在交接,但这个更强调的是把东西交接给人,一定要交接给人,不管是外部系统、控制台系统还是手机系统,一定要交接给人。其实OpenAI和Anthropic做得比较好,你看你跟它聊天的过程中,关键环节蹦出来”我要把这个控制权交给你,我要干什么,你同意吗”,让你去做决定,Claude Code都有,都要把这个动作拿出来交给人去同意,因为是关键操作。

还有,我们可以把一组Agent当做另外一组Agent的一个工具去调用。一定要有这种能力,因为我们要做大型系统的话,不可能一个Agent,可能有三千个Agent,这五十个Agent一组,那五十个Agent一组,那八十个Agent一组,他们之间可能都有互相调用依赖关系。所有功能都可以工具化,这是我们做AI处理的时候一旦工具化,大语言模型就都可以调用了。一旦工具化,大语言模型单次问答就可以调用了。所以工具化是一个不成文的约束。

另外一点,这也是我深有感悟的一点:不要带还没有完的任务,你就想三个微机的完成。因为现在AI的能力很强,有可能你一次问答AI都给你搞定了。所以建议大家每个任务来了以后,你不要一开始就做Agent,你就直接用ChatGPT最好的模型或者Claude Code的模型,你问它一下看一下效果,如果效果离你太远,那你就多做这样解决这个事;如果效果还差不多,我优化优化提示词可能就不需要多个Agent。所以不是Agent越多越好。

大家知道现在的自主式Agent是不是特别耗钱?好Token,就是因为你为我、我为你,你问我、我问你,对话说好多废话,还有总结的一些记忆——刚才那些记忆所有的总结汇总都是Agent总结的,并不是说两个人聊老半天人过来给你总结,放在记忆库里边,是另外一个Agent帮它们总结的。这些东西肯定越少,它消耗的Token是不是越少?所以一定要注意,尽量不用Agent能解决的,能用对话解决的尽量不要用Agent。

十六、模块十二:运行时与生命周期

最后一个模块,功能性都有了,我还需要一个把它们围起来给我干活的一个东西,就叫运行时与生命周期。它就负责你这个系统的启动、运行、托管、隔离、扩缩容等等,就是指挥着那些模块给谁干啥干啥。当然包括它下线、什么时候下线休息、什么时候休息等等一系列事。

举个例子,启动的时候,首先你肯定要加载好多配置参数,哪些参数是属于工具用的,哪些参数是一些系统提示使用的,哪些参数是给记忆系统用的等等,哪些必须现在加载,哪些可以延后加载、异步加载等等,都要在这个地方规划好。

我这个运行时它核心的功能,就是让你的环境可复现——就是关了机还能启动,启动起来行为不差,不已关机完了再起来蓝屏了。如果蓝屏说明你这个Agent的题目是没做好。第二是安全隔离,安全是非常重要的,特别是大语言模型有人的能力,指不定它给你干什么坏事。还有沙箱的复用,但是我们说了状态和恢复点能将沙箱尽量多地去复用,省Token。沙箱就是一个隔离或者存放等等,好多场景能用到这个环境的一个指标。

十七、总结
Harness的本质,回到我最开始的话,它并不是一个平台,也并不是哪个公司出的一个软件产品。你说它是思想也行,或者是设计模式也行,它指导着我们怎么去开发一个具有Agent的系统。但它更像是指导我们用传统的软件开发的思维,和一个类人的系统互相融合的一套框架。它是这样的一套概念,所以才跟上一套生产级AI Agent的操作系统。它方方面面几乎都做到了。

它的最终目的是什么?可控、可恢复、可观测、可治理、可演进。这样,不管你的大语言模型怎么一直升级,你的Harness是不变的。

如果说我们最开始那张图从Chat到Agent,其实我们再把它简化一下,就是从提示词工程,真正要把AI做成运行时的一个工程。它不再是一锤子买卖,它是长期可运行的一个过程。

最后回到大语言模型的比喻——为了让大语言模型跑得好,我们设计了12个模块,像Harness马具一样套在这匹马身上,这匹马的作用就多了。可能现在是这样,明天我给它换一套,或者补充一下马具,它就可以拖货物了;再变一下,它就可以离地了。因为大语言模型能力不变,这个Harness的东西你可以灵活地去组装发展,包括拉车都可以,只要能干的事儿都能干。

所以最终现实的世界就是这样,不同的大语言模型此消彼长,能力此消彼长,但是,我们开发的Harness是不是在每匹马上都一样?你制造了一组工具,你不管换谁,这就是我的价值,我这个平台的价值,它会沉淀下来。