最近 ai 圈子非常火爆的哈尼斯到底是什么?它要怎么用?为什么它变得这么重要?今天就一条视频给大家讲透,保证新手也能听得懂。首先它是什么?哈尼斯是今年二月份 由 open ai 提出的一个全新的概念,全称叫做哈尼斯 engineering, 也就是驾驭工程,说白了就是一整套管理 ai 的 操作系统。哈尼斯这个单词啊,有马鞍子江省的意思, 那我就来打个比方,假如 ai 是 一匹野马,优点是力气超级大,能跑,能帮我们干很多活儿。但是缺点啊,就是不听话, 要么一动不动,要么一触即发。那么哈尼斯呢,就是要给这匹马套上江绳马鞍,再设计好围栏,圈定马场。核心呢,就是约束好这匹野马,让它在圈定的范围 内活动,不要乱跑。所以啊,当哈尼斯这个架构搭建好以后, ai 不 仅能够跑得飞快,还能够做到服从指令,不会乱写垃圾代码,浪费。托肯。接下来啊,我们就讲一讲哈尼斯这个架构,它到底包含了哪些内容。这套架构的核心啊,一共有四个层次,其中第三层啊,是 灵魂,第一层呢,就是上下文层,说白了就是要把前因后果,架构规矩要做成什么样,一次性的给 ai 讲透,不要让他瞎猜,不让他乱写,先把背景信息给全了,这是打底子。第二是执行层,就是给 ai 啊,装上手和脚,让他自己能够新建文档,写代码, 删文档,调命令,不用你人工执行, ai 自己动手干活。第三层啊,就是反馈灵魂,这层啊,才是灵魂,代码跑失败了,报错了,先别着急上手去改,让 ai 啊,自己看报错,自己定位问题,自己改代码,再重新跑一遍不行两遍,两遍不行三遍,直到跑通为止, 完全不用人插手改 bug, 真正实现自动化。第四层啊,就是可观测性,就是给人啊,开一个监控视角, ai 每一步干了啥,写了啥,卡在哪,出了什么问题,你看哪,一清二楚,全程监控,想看哪里看哪里,想点哪里点哪里, 完全不用自己下场。那我们了解完哈尼斯之后,再来看看哈尼斯它到底有多强。根据 openai 的 文章显示啊,它们只用了三个工程师,花了五个月的时间用 kodex, 哈尼斯就完成了一百万行的生产级代码。更夸张的是,这一百万行代码, 这三个工程师自己是一行也没写,全都是指挥 ai 去生成的。现在有一个流行的词啊,叫做古法编程,也就是手缩代码。那在手缩代码的时代啊,三个工程师完成一百万行生产级代码,至少也得需要十年的时间吧。现在来看, ai 只需要 五个月。 lanchen 在 上个月仅仅是给同一个大元模型换上了 hines 的 架构,其他部分呢,都没有改变。它在聪明人奔驰上的通过率排行啊,从三十几名一路飙升到第五名, 这样惊人的战绩啊,使得哈尼斯这个全新的概念啊,火爆出圈。看到这里啊,就有人要问了,哈尼斯到底在哪啊?咋用啊?如果你的任务是一次性的,也比较简单和清晰,用不用哈尼斯啊,都行,其实基础的 对话和工作流啊,也都能搞定。但是如果你要处理的是一个复杂的系统工程,比如任务需要跨越多个阶段状态,需要跨回合延续,涉及到大量的上下文记忆,基本上绝大多数的 企业级的需求啊,今后都会涉及到。 hans 阶阶段的大模型有个短板就是记忆能力有限,你的任务越复杂,就越容易暴露大模型的这个短板,这个时候啊,就越需要 hans 帮你约束和管理好你的 ai。 当 hans 良性运转之后,就会建立起 数据飞轮,当它积累了越来越多的知识和数据之后,它就从一个工具开始,慢慢变得越来越像人,变得越来越好用,变得越来越懂你。其实现在的小龙虾就是哈尼斯思想的一个非常好的实践。有不少评论者说啊,现在 prom 的 时代已经结束了,哈尼斯时代 已经到来啦。那为什么哈尼斯这么重要呢?因为它代表着从 ai 到 a g i 已经进化到了第三个阶段。那第一个阶段就是大家比较熟悉的 prompt engineering 的 阶段,这个时候重点是你跟 ai 说些什么, 所以啊,大家都在学提示词怎么写。第二个阶段啊,就是进化到了 context engineering 的 阶段,也就是说上下文工程的阶段。 这个阶段的重点是给 ai 为哪些信息作为决策依据,需要系统性的编排上下文窗口之间的内容,不是展示的信息量越大越好,而是信息的相关性越强越好。第三阶段就是轮到现在异常火爆的 harness engineering 的 阶段,重点啊就是对 ai 实行系统管控。其实 prompt, context, harness 这三者之间的关系啊,并不是相互替代的关系, 而是构成了 ai 工程化的三层递进。一开始,不同的大模型之间产出质量的差距是比较大的,现在呢,各个大模型之间的差距在逐渐缩小。光靠大模型本身啊,已经很难有质的提升。所以啊,哈尼斯就 变得很重要。如果你想更深入地了解 hines engineering, 仔细阅读这两篇核心文档吧。 openai 二零二六年的新文章,还有 astropica 公司的那篇关于 agent 的 必读经典。需要这两份文档的朋友可在评论区扣 hines, 我 来安排。
粉丝4464获赞3.1万

最近产品同学问了一个问题,到底什么是 harness? 很多同学听过这个词,也知道它和 ai, ai 有 关,但并不清楚它在工程上到底指什么。要回答这个问题,单独定义 harness 是 不够的,它必须和它周围的几层概念放在一起看边界才会清楚。 所以这期我们换一个视角,不是孤立的解释哈尼斯,而是看一次 agent 跑一次任务,到底有哪几层工程在协助。从这个视角出发,再回头看哈尼斯是什么就清楚多了。先看 prompt engineering, 它的本质不是写一句更聪明的话,而是设计模型的输入协议。它解决的是怎么把任务告诉模型、 角色、任务输入、输出格式、视力约束这几块都要说清楚。这个思路的背景是 gpt 三之后大模型展现出的 in context learning 能力,也就是模型参数不变,只要在输入里放任务说明和少量视力,就能完成新任务。后来 change of thought 还证明 prompt 可以 作为推理脚手架。所以 prompt 不 只是自然语言,它开始变成一种工程接口。所以工程上 prompt 会被模板化、版本化、结构化。页面上这个例子里的 role task constraints, input output, scheme examples 就是一个典型的输入协议。但它的边界也很清楚, prompt 只能组织已经在输入里的信息,如果模型看不到项目文件、历史状态、工具、结果提示词写得再好,它还是只能凭空生成。这就是为什么下一层抽象会出现 context engineering。 context engineering 的 本质不是把更多东西塞进上下文,而是为模型当前这一步推理构造最合适的信息状态。也就是说,模型不是一次性看到整个世界,而是在每一部由外部系统组织它该看到的信息。这个概念很容易被简化成上下文,越多越好。 但这其实是误解,上下文窗口可以越来越长,但越长注意力越散,推理越贵,响应越慢,缓存越容易失效。 所以工程上 context engineer 要做的是筛选、排序、压缩、加载、缓存、附用和渐近式。譬如哪些文件该进来,历史记录保留,哪几轮工具返回要不要加载,这些都在影响模型下一步的判断质量。具体来源可以拆成六类, system proc files、 memory reg 二、 results 和 cash。 常听到的 rich prompt、 catching 乃至 cloud code 里的代码。上下文选择都是 context engineering 的 具体形态,但它也有边界。 context 决定模型当前能看到什么,却不决定系统什么时候调用工具怎么执行,动作失败后怎么恢复。 这就是为什么下一层抽象会出现 harness engineering。 把刚才两个概念放在一张图上对比,这张图改编自 anthropic 二零二五年那篇 effective context engineering for ai agents。 左半边是单轮 context, window 里就 system prompt 和 user message 模型,读完给一个回复,一锤子买卖。右半边是多轮 agent, 外面多了一个 possible context 文件工具,记忆解锁历史远远超过上下文窗口能装下的量。 所以中间要有一步 curation 筛选压缩缓存,把这一步真正需要的部分送进窗口,模型推理后产生突抗,结果再回流到 possible context, 进入下一轮核心差异就一句话, prompt 是 一次性输入, context 是 循环 curate。 但这就引出一个问题, 这个循环到底是谁在驱动? anthropic 在 scaling managed agents 里给了答案, context management in the harness 上下文管理在 harness 里,这就是下一页要讲的。 harness engineering 的 本质是把思考、执行和记录分开,再由 harness 串成一个可恢复的循环。 antropics 在 scaling managed a 金词里有一个很好的说法叫 decouple the brain from the hands, 意思是把大脑和双手解偶,页面上这三张卡就是 brain hands session。 我 们一张张看,先说 brain, 就是 quad 这样的模型 基于上下文推理生成下一步意图。这里要补一句, in graphic 原文里的 brain 其实是 cloud 加 hannis, 本期为了讲清边界,把 hannis 的 单拿出来讲。 hands 是 执行动作的部分。 三 box m c p 终端浏览器外部工具比较稳的做法是把它们抽象成统一接口,而不是和某个具体容器绑死。三申则是事件日制,它不是跨的 the context window, 而是持久化在外部的事件流。 hannis 可以 通过事件接口读取历史事件, 筛选切片将要之后再决定哪些内容进入下一轮上下文上一页说的 context management in the harness 在 这个架构里就落地了。 harness 从筛选和工具结果中筛选、裁剪、回放信息,再送给 brain, 进入下一轮推理。而这个从 brain 到 hands 再到筛选,最后回到 brain 的 外部循环, 其实就是 react 耐克思考动作观察循环的工程版本,放到 ai 参与软件开发里看,模型不会主动读文件,跑测试,维护任务状态,把这些能力组织成可受控、可验证、可恢复的工程闭环的就是 harness。 但哈尼斯也有边界,哈尼斯决定做什么,怎么做,沙箱与全线决定动作在哪里发生,能影响什么。这一块在工程实践里通常被合并进哈尼斯作为其 sandbox primitives。 这就是为什么最后要把三层重新摆在一起。看看这张图, prompt engineering, context engineering, harness engineering 不是 一条时间线,而是欠套的关系。举个例子,上网搜一下最新的 antropics 博克, prompt 决定怎么把任务说给模型, context 决定这一步,模型看到哪些已有信息, harnis 决定调哪个工具走哪个沙箱,搜回来的结果怎么进入下一轮 context 三层各管一段,缺一层都跑不起来。回到开头的问题, harnis 在 工程上做了什么?我的答案就是这一层,把模型、工具和状态串成可恢复的执行循环。本期反复提到的 context engineering, 我 有一个专门的系列在讲, 感兴趣的同学可以去翻翻,感觉有所收获的同学可以点赞收藏加关注,我们下期见!

这就是最近爆火的新名词, harness, 几分钟的视频,以我的一人公司官网为例,带你走进 harness 的 世界。 harness 并非一个定义充分的东西,它呢,更多是一种思想,起源于 matechat, 它的最初形态是开发过程中把修改的经验统一为方法论。在接入开发过程中, 其实可以以我的官网举例,这里面有一个功能,用户支付后会自动唤醒飞书,自动的授权,把用户拉入群聊。我不懂代码,也没有注册公司,用邪乎的办法搞定了这个功能,但发现哈,隔天起来, agent 会重新看一遍所有的架构,思考为什么这么设计。 因为办法高度的定制化,非传统,超出了 agent 知识库的范畴,他可能还会修改错误。那么这个时候, hans 的 第一层上下文就体现关键性的作用了。 那么你一定能够想到,每一个项目都有对应的 agent 点。 m d, 这是项目的工程指南,它包含了项目架构、技术选型、核心坑点等等的所有内容。每次执行任务, agent 都会先阅读这个文件,读完后自然会一目了然,只需定位到要修改的文件,便大大提高了开发的效率。 你要做的很简单,每个模块和功能都存储到对应的开发逻辑,最终合并就是一份完整的开发文档。 bug 定的朋友一定知道,让 ai 调整字间距是一种巨大的折磨。你和 ai 明确表达,让它预览后再交付,它知道要预览,但它呢?没有预览的工具,它就会思考一番后,直接跳过预览的需求,然后直接交付掉。 这其实并不是它不想,而是它不能,这就是工具系统的含义,给他配备预览的工具,并告诉他什么时候用,这时候你就会发现它的准确性大幅的提高。 刚刚讲的是现成的工具,其实我们也有很多工具是属于自己的项目的,你可以在开发过程中把脚本分装为一个工具。 依然以支付系统举例,我希望在支付弹窗内边写一个倒计时的组建 ai, 可能会把支付的一个时长定义为十分钟,但是后台的订单可能五分钟就过期了。这是因为同一个功能模块的修改,很多时候并不在同一个窗口内完成, 用户会看到,明明系统还存在,怎么我就没有办法扫码了?这么一个完整的任务至少需要这么几步,对于信息不足的部分,需要搜查信息,进一步制定方案,然后再去解决问题。直接把需求给他,他会拿到代码,直接开始操刀,忽略了你项目的特定情形,从而出错。 而这就是编排的作用。简单复盘一下上下文就是 ai 的 大脑,工具就是 ai 的 手脚,而编排就是 ai 做事的方法论。这么看, harness 是 不是也就没那么糊人了? harness 的 深入内容,我们下期继续讨论,关注我,我们一起探索 ai 的 世界。

什么是 harness engineering? open ai 的 三位工程师用了五个月的时间指挥 codax, 写了一百万行代码,完成了一个完整的软件产品的开发。整个过程呢,是零行手写代码。他们是怎么做到的呢?因为他们使用了一个开发范式,叫做 harness engineering hannahs, 中文呢,叫做江绳 hannah's engineer, 也叫驾驭工程。在传统的 ai coding 中, ai 写一段,程序员确认一下,对的就继续,不对的呢就重来,这是胡拥门营的 loop。 人在还中,人永远不能被解放出来, 而 harness 的 目的呢,是将人彻底解放出来。工程师只负责定义需求,确定架构,设置规则、验收结果,剩下的事呢,就全都交给 ai 自己去跑。过去两年, ai 的 工程一直在进化,从 prompt 提示词工程,到 context 上下文工程,再到今年的 harness 驾驭工程,很多人呢,误以为是 hannah 取代了前两者,其实呢,他只是站在更高的维度,把前面两者都包含了进来。比如,你需要 ai 帮你做一份低卡路里的午餐,那么提示词工程呢,会负责把任务说清楚,你是一个智能烹饪助手,请帮我做一份低卡路里午餐。 上下文工程呢,会负责补充背景资料和参考素材。 ai 打开冰箱,找到了鸡胸肉和生菜,查看你的健康档案,知道你对花生过敏。连接你的运动手表,了解到你今天的运动量比较大,需要补充蛋白质。这些信息呢,就是上下文。 而 hannahs 呢,则负责把控整个流程,确保任务可以持续顺利地进行。任务开始后, hannahs 会 自主地去组装提示词,自动地启动上下文的查找,然后根据查找的结果生成购物清单,如果缺少食材,还可以自动下单。整个过程在 hannah 的 控制下一路跑到终点,不需要人来参与。

一个真正做事的小龙虾是什么样的?今天不聊大模型,也不聊 skill, 聊一个最近很火的概念叫 harness 系统,你其实可以把它理解成是可以让大模型真正干活的一整套系统。举个例子来说, 原始的大模型就像一台电脑的 cpu, 但是如果没有硬盘,没有内存,没有操作系统,它就什么都干不了。 harness 系统就是让大模型变成真正有用的生产力。 harness 系统它具体包括什么呢?第一就是一个循环系统, 它可以让 ai 从思考到行动到观察,变成一个完整的循环。它决定 ai 先想再做,看了结果再调整, 循环往复地直到把这个事情做成。第二,提供一整套工具,就像人的双手,让 ai 能够实际操作文件、搜索网络、执行代码,甚至调用别的软件。第三就是记忆系统, 分短期记忆和长期记忆,短期记住这一轮绘画说了什么,长期就能记住跨绘画积累的用户偏好和知识。小龙虾里的 memory 也是干这个的。第四就是上下文的管理, 这是很多人踩坑的地方,如果一个上下文很长,但是重要信息在中间的位置,那 ai 的 表现就会下降很多。但是哈尼斯系统它解决的就是把就是怎么把有用的信息 放在 ai 真正会看到的位置。第五是错误的处理,一个十步的流程,如果每一步有百分之九十九的成功率,这已经很高了,但是它沉在一起,它的成功率可能只剩下了百分之九十。 错误会快速的复合,所以哈尼斯必须能捕获错误,自己去重试,让 ai 自己去纠错。第六是关于安全的,它有一套防护栏的系统,决定 ai 能做什么,不能做什么。比如它可以读文件,但是它不可以随便去删文件,这些边界都是哈尼斯来控制。小龙虾欧本克劳其实就是在 帮人搭建这样的一套系统,它把记忆工具、错误处理、上下文管理全部分装好,然后让你直接操作来执行任务。 但是它确实还是有很多需要改进的地方,比如编排循环这个它就有很大的优化空间,这也是 hermes 那 个 agent 做的比较好的一个地方。最后总结一下核心就是三个,第一, hermes 系统的六要素,每一个都是值得去调试去改进的,它相当于一个厨师 要不断地去提升自己的厨艺以及厨房的设备。第二,你的 agent 强不强,说到底就是你的 hines 系统厉不厉害。第三,我们在用小龙虾去做工作流,去真正地去做事的时候,实际上就是在 完善这个 harness 系统,或者说是在某个业务场景下去打造它的 harness 系统。当你真正了解了 harness 的 意思,框架的含义以及它的六要素,你就可以针对你的小龙虾或者你用的其他的 agent 去真正的搭建一个帮你省时间、提效率的智能题。

最近 ai 圈有两个带 h 的 技术比较火哈,一个叫 harness, 一个叫 hermes。 很多人逛技术社区的时候,一会儿看到 harness engineering 是 agent 落地的关键,一会儿又看到 hermes agent 两个月拿到了十万新,不少人下意识以为是同一个东西,其实是错的, 一个是建筑设计规范,一个是按规范盖出来的大楼,其实这个图片就可以很好的表达出这两者之间的概念和关系。那我们先说 harness, 它其实本意就是马具那么大模型,那匹有力量且难以驾驭的马 啊。 harness 它其实就是将神,是马鞍,它可以让人更安全的去驾驭这个马,这个其实就是目前针对的这种智能体和 agent 它的一个技术规范,它的最终目的也是想让 agent 能够有更好的表现,说白了就是有一个比较好的工程化设计能力。 因为从二三年大家开始玩提示词工程,琢磨怎么跟模型说话,然后二五年升级到了上下文工程,开始关注给 age 的 看什么比怎么说更重要。那到了现在二六年,现在这个概念 引爆到了整个 harnis 工程,那其实它不再是针对于优化单词的话,而是说能够设计跨越多个绘画以及多个 agent, 其实总结出来就是四个字,约束先行。那么现在整个 harnis 做的最好的默认是 code code, 因为确实 这个工具它现在是智能体里面呃生成质量最高,也且是调用各类顶尖的模型表现能力最好的一个呃,智能体。那么我们再说回 hermes agent, 这是 news research 今年二月份发布的一个 开源智能体框架,它两个月也在 github 上突破了十万新。它定位其实是很独特,它不是聊天机器人,而是常驻运行在你电脑的数字员工。那么它跟 open globe 小 龙虾其实是有一定的区别,因为小龙虾需要我们去养,需要我们不断地去给它喂更多的上下文存储记忆。那么 hermes 的 话,更多的就是它可以根据我们的一些任务指令去进行自我进化, 把一些复杂的任务场景自行地去生成一些技能。所以 hermes agent 它的核心技术是学习闭环,完成了一个复杂任务之后,它会得到一个结构化的 skill m d 的 技能文件,并且这个技能文件在后续的过程中还会自我的迭代。那么这里就用一句话去分清楚它们俩的区别。其实 hermes 它是怎么造好 agent 的 规范?那 hermes agent 它是按照规范造出来的一个优秀的 agent。 我 们就好比 hermes, 就 好像厨房的操作规范, hermes 像是按规范训练出来的一个顶尖的厨师,它会根据自己总结的经验,然后改进菜谱,炒的越来越好。 那么我们总结一下,当 ai 圈开始同时热议规范和产品的同时,你会觉得哪个更重要?其实我的看法是短期看产品,长期看规范。比如说像 hermes, 它会让你 立刻尝到这个 agent 的 甜头,但是技术规范 hermes 它并不知道你的甜头从哪里来。你只有通过持续的整个迭代和优化设计更好的规范,才能让整个 agent 的 产品变得更好。

企业接入 agent, 最怕的其实不是大模型变弱智,而是怕它违规越权拿财务报销。举例,很多兄弟以为在 prompts 里告诉大模型超过叉叉员,必须有特批才能放行,系统就安全了。其实根本不够,大模型非常容易被绕过。 你看,员工提交了一张五千八的报销单,在被助理写了一句,经副总裁及总监特批,大模型抓到关键词,很容易以为合规了当场会放款。 所以光靠 prompts 规范,大模型是防不住的。在哈尼斯工程里,我们要靠痊愈沙核机制进行物理控制。我们先要设置一个沙核,在沙核里有自动打款函数,意图解析容器硬编码了审计红线。沙核在容器内部把 jason 解开,提取出金额,沙核内部雷达扫描发现超过金额上限直接阻断, 而且沙核里的内容大模型触碰不到,所以大模型吐出五千八的审批 jason, 他 以为可以了,但是 jason 传到沙核容器里, 流程瞬间可以被截断。没有沙盒放行大魔性,连网银接口的门把手都摸不到。我们把金额换成四千八看结果顺利通过。所以我们用沙盒把 ai 管住,只让他干活提建议,绝不让他碰红线。这才是能在公司真正落地的 agent, 你 学会了吗?

今天上期,今天我们继续深入看看 hannis 的 核心思想到底是什么。如果只是前三步,他能干活,能修 bug, 也可以跑流程,但是一个工程并不是一口气做完的。 a 阵呢,可能今天修支付,明天改飞书,最后呢,再去弄授权,中 间会切换到很多的窗口模型。最大的问题就是,他可能不知道上一轮改到了哪里。就像你入职一个公司,你需要和原来的岗位负责人交接一些基本的情况, 这就是状态与记忆层的作用,他并非记住你所有的东西,而是记住某些任务的进度,关键的决策以及失败的现场,然后用 a 证的可以理解的方式去保存下来。相信 web 扣件的朋友一定知道,很多时候呢,你提出了一个需求,他明明没有完成,但是他却交付了。这是因为 a 证呢?写完后觉得自己完成 页面能不能打开,他没有看付款能不能成功,他不会去跑,所以哈,依旧有支付系统。举例子, 确认订单后要真的打开订单的状态,模拟付款后要真的回看回调的日记。瘦身成功后,要真的确认用户的权限。备注拉群之后,要真的看用户有没有进群。这就是测评的意义,不是 a 证他一句完成,而是给他仪表盘日制和截图,让他知道是否真的完成了。 不知道有人是否经历过被 a 证的删除重要文件以后的烦恼。你不能指望 a 证的很听话,我们必须让他物理上去不犯错,比如说,哈,不能修改无关的文件,不能凭感觉去重写代码,不能绕过测试等等,需要明确的告诉他规则、脚本、测试权限以及审批。 即使我们已经做了很好的约束限定,他依然有可能会犯错。所以呢,我们需要修复 agent 呢?改坏了,需要知道是哪一步坏的方案失败了,是否可以回到前一个 commit, 这就是约束与恢复。而我们前两期视频提到的六个层面就是一个完整的 harness 范式。 harness 最初希望解决的问题就是我们应该如何和 ai 更高效的协助,这是一种思维习惯,每当 a 阵能犯一次错,你要把这个错误转换为一个可附用的知识资产,而这样它就可以真正地跟随着时间的推进,愈发地变得高效。而这才是 harness 厉害的地方, 它不是让 ai 更吓人,而是让系统去改善交互的范式。希望本期视频可以帮助到你,我是逍遥,我们下期再见。

什么是 agent 的 henzhen engineering? 总结, henzhen engineering 就是 为 ai agent 设计的一整套工作环境、工具、权限、状态、记忆、验证、反馈和治理规则, 让大模型可以持续、可靠、安全地完成真实任务。你有没有发现,让 cloud code 或者 context 写代码的时候,经常出现做到一半忘记了自己在干什么,修了一个 bug, 又引入了三个 bug, 明明项目没有过去完成,他却跟你说已经完成了。 但是为什么我们看到其他的大神在 rap 扣点时都能用的很好呢?并且都没有遇到这样的问题呢?这时候问题可能不在于模型不够聪明,而在于你只是给他了一个任务,却没有给他一个真正能工作的系统。 那么这个系统就是我们今天要了解的 he news in the new year。 我 们现在来讲解一下 he news 这个词旨意有约束、牵引装备的意思, 那么放在 agent 里,他指的是模型外面那一套让模型能够干活的框架设计和工具之类的东西。模型本身主要负责推理和决策,但但他不能天然访问你的文件运行代码,以及知道任务有没有真的完成。 所以 and 这个词在 html 中的意思就是给 ai html 搭建一个可执行、可观察、可验证以及可持续改进的工作系统,不是让模型更努力,而是把模型放在一个更适合完成任务的环境里面。简单的举一个例子, 同样一个 ai, 只发给他一句帮我做一个 ppt, 他 可能就给你一堆文字,但是如果你给他模板、品牌 规范、过往案例、素材库等等这些信息,它就能够给你交付一套更加接近可用层比的 ppt, 或者八到九成可用的 ppt 文件,那么我们给他提供的这一套内容就是个人版的 html。 为什么有了 permit, contest, mcp skill 还要和 news? 很多人问,我们不是已经有了 permit engineering, contest engineering, mcp, aids skill 了吗? 为什么还要再来一个 henness in the new year? 答案是,它们不是互相替代的关系,而是处于不同的层级。我们可以来简单讲一下每一个层级所解决的问题, prompt in the new year 解决的是怎么说, context in the new year 解决的是给他看什么,这里的他就是大模型。 m c p 解决的是怎么连接工具和外部系统。 skill 是 解决了怎么按需加载一套技能,而 harness in the new year 解决的是更大的问题。怎么样上述这些工具或者技能组成一个闭环,让 agent 能持续工作,遇到问题回退, 做完问题会验证经验,还能沉淀下来。你完全可以简单地把 hunnews 理解成 ai 的 操作系统, prompt, context, mcp skill 都是里面的重要组建或者技术。 hunnews 就是 在系统运行的时候负责把它们组织起来,什么时候加载上下文,什么时候调用工具, 在哪个沙箱里面运行失败后怎么从事,什么情况下要人类进行审批,哪些经验要写回知识库里面?我们在这里用一个循环来概括 her news and new in 这项技术的底层原理,目标、上下文、计划、行动、观察、验证、记忆、治理。 我们在这里把这八点拆成四个步骤来看,每一步到底是在干什么事情。第一步,目标和上下文我们平常在 cloud code 或者 open curl 来写代码时,经常会把一个复杂的需求使使用简单的语言描述出来,往往这样子, ai 对 我们需求的理解会 非常的费解,并且经常出现你描述的是 a, 但 ai 理解成了 c 或者 d, 那 么我们究竟要给他 什么内容呢?答案就在这里。 ai 需要明确的验收标准,也需要能找到相关知识,比如 agents, md 文档,项目文档、资库、历史决策、业务规则。但这些并不是越多越好,而是要像一个地图一样, 随着开发的进度按需展开。第二步,行动环境。在 agent 的 执行任务时,要能读文件,写文件,跑命令,开浏览器,查日记, 调接口,但这些动作最好在沙箱里面完成,并且有权限边界,免得 ai 哪一天抽风把我们电脑上面的数据给全部给删掉。在这里, m c p 和 skill 就 很重要了,因为 m c p 负责连接外部工具, skill 负责按需加载方法、规则和资源。他们让 agent 可以 在沙箱环境中 标准化的连接浏览器,数据库, of stand, 飞书,还有 github 等外部工具。第三步,验证反馈。 即使一个好的 html 框架不会只让 html 输出结果,还会让它去验证生成出来的结果是否正确,这一步可以称之为验证反馈。我们来举个例子,比如跑测试,看类型检查,打开真实网页,点一遍截图,对比,查询日历指标。在 mountainfall 的 那篇文章中,把 这些叫做 sensors, 也就是传感器,他们告诉 agent 你 现在做的对不对。第四步,记忆和治理。可以简单来讲,每次错误都不应该只是被修掉,而是应该变成规则文档,测试 skill 或知识目录。真正厉害的 harness 并不是快速修复了一个 bug, 而是在下一次代码生成或者软件迭代时,不再写同样类型的错误。那么普通人要不要系统学习这项技术呢?屏幕前的你,如果是普通用户或者新手小白,平常也 就是用用豆包或者 kimi、 dipstick 这些 ai 工具的话,我的建议是不要着急学复杂框架,而是学一些 hnu si, 也就是给 ai 搭建工作台的思维。 简单来讲,就是懂得把问题描述给大家听,给多一些参考资料,再让他按标准自检。那么怎么做呢?其实你可以从以下这三个动作开始,第一,把常做的任务写成 s o p, 而不是每次重新解释。第二,把你的知识沉淀到一个 a n 浓度的地方,比如 overstand orson markdown 文件夹。第三,给每个任务设计验收标准,让 ai 做完后自检。我们以自媒体人员举例,平常不要只说帮我写脚本,你应该构建出你自己一个选 题库,然后把爆款结构、口播风格、禁用词分进脚本,或者说分进模板,包括检查清单,这几个内容都变成 skill, 写到 agent 的 技能包中,然后 agent 就 能够利用这些内容来给你写出你的视频脚本, 学习你的创作风格,让 agent 变得越来越懂你的一个创作系统。那么这样技术,什么样的人最需要学呢?简单来讲,真正需要系统学习和 news engineering 的是四类人,第一类,正在用 ai code 的 开发者和架构师。第二类,想把 ai 接近真实业务流程的产品、运营、数据和自动化团队。第三类,做企业落地的人。第四类是想构建自己长期知识财产的创作者或者研究者。因为这些人都存在一个共同问题, 不是 ai 会不会为他,而是 ai 能不能接住复杂上下文,按流程执行失败后修正,并且把经验留下来。这就是亨利斯 in the new york 的 主场。这项技术带来什么样的影响?我们分两点来看。 短期来看, pro news in the new year 会让 ai 从聊天效率工具变成工作流程员,他帮你跨绘画、推进任务、夜里跑验证、自动整理知识,让多个 agent 分 工协助一起推进整个项目。在 open ai 的 content 实践里, 人类工程师的重点已经从手写代码转为如何设计环境约束和反馈回路。长期来看,真正稀缺的能力会从我会不会写提示词变成我能不能把我的工作方法、领域知识和判断标准变成 ai 可以 读取、执行、验证和改进的系统。一个人在未来的竞争优势,很很可能不只是指挥 ai 写代码的能力,而是谁的思维知识更干净,谁的 反馈壁还更强,谁能把工作内容转成一套工作框架,让 agent 在 里面跑。所以, and the new york 最重要的启发是,不要只把 ai 当成一个更聪明的回答器, 你要开始思考怎么给他一个可持续工作的环境。最后用一段话说呗, permit 让 ai 听懂你, context 让 ai 了解你 m c p skill 让 ai 调用能力 啊和 news in the new year 让 ai 真正进入你的工作系统。以后我们评价一个 agent, 不 能只看他用了什么摩羯,更要看他被放进了什么和 news 中,这或许也是未来一个 ai 领域从业者的一个重要考核指标。如果你是新手,从今天开始最值得做的一件事 不是追下一个模型,而是把你经常做的一个任务整理成一套 ai 可执行的检查流程,这样你就拥有了自己第一个和你。

阿里带来了首个 harness 框架,发布了 agent scope java 一 点一点零里程碑版本,完整地实现了 harness engineering, 让它不再停留在概念 agent scope java。 harness 的 设计哲学啊,可以用一句话来概括, 把下一轮怎么办,下一天怎么办,上下文爆了怎么办,状态丢了怎么办的工程答案打包起来,而不是让每个 agent 项目 各自发明一遍。那关于 agent scope java 的 适利代码,我已经发布到了我的 github, 留下 ai 就 行。它主要做了两步重大的设计啊,为每个 agent 引入了一个 workspace 工作空间,你可以理解为一个脚手架,它提供了一个结构化的目录,用于承载 agent 的 运行所需的一切持久化内容,包括人格定义,长期记忆,还有领域知识可附用的 skills 以及 sub agents, 还有历史对话,全部为你封装好了,并且支持分布式场景。如果你的 agent 需要进行分布式极穷部署,每个节点 存储各自的 memory markdown 文件,那这个问题怎么解决的呢?它在底层啊,封装了一套统一的抽象 文件存储层,可以在上层实现不同的分布式存储方案,比如 o s s reddit。 现在我们可以利用 agent scope java 轻松地去构建三个典型的场景,第一种, open curl 类应用,它原生地提供了长期 持续记忆,本地 shell 执行动态加载 skill。 第二种,企业级数据服务,类似于阿里开源的 data agent, 它为这类场景呢,提供了 circle python shell 进行了完整的实现,并且提供了隔离沙箱,所有的代码命令 在隔离环境内里面运行宿主服务进程,不受用户输入影响,安全边界清晰,并且提供多轮对话, 沙箱自动保存恢复以及分布式记忆共享。第三个典型的场景就是交易 agent, 典型的是阿里内部的逃天,这类场景呢,主要通过调用业务 a p i 来完成任务, 像下单啊,查询订单啊,审批啊等等,不需要在服务器上执行 shell, 但需要多实力运行绘画状态,可持久画用户的知识共享。那目前 agent scope java 已经纳入了我的 java ai 应用课程, 除此之外,现在我们可以利用 agent scope java 轻松地去构建三个典型的场景,第一种 open curl 类应用,它原生地提供了长期 持续记忆,本地 shell 执行动态加载 skill。 第二种企业级数据服务,类似于阿里开源的 data agent, 它为这类场景呢,提供了 circle python shell 进行了完整的实现,并且提供了隔离沙箱,所有的代码命令 在隔离环境内里面运行。宿主服务进程不受用户输入影响,安全边界清晰,并且提供多轮对话, 沙箱自动保存恢复以及分布式记忆共享。第三个典型的场景就是交易 agent, 典型的是阿里内部的逃天,这类场景呢,主要通过调用业务 a p i 来完成任务。 你像下单啊,查询订单啊,审批啊等等,不需要在服务器上执行 share, 但需要多实力运行会话状态,可持久跨用户的知识共享。那目前 agent 是 coop java, 已经纳入了我的 java ai 应用课程, 那我这里呢,整理了一套 java 程序员学习 ai 的 路线图,加完整学习视频加代码笔记,从大模型选型到微调,再到 ai 开发 a 整的开发框架,最后到项目实战以及部署,想要学习的小伙伴留下 ai 无偿分享。

小白刚鼓起勇气点进 ai 频道,好不容易才搞懂两个词,结果新概念出来的比吃饭还频繁,像前阵子搞的满城风雨的 harness 工程,千万别被他的名字吓到,其实你早就学过了, 想彻底搞懂这个概念,其实非常简单,只需要从咱们的日常出发,你就能看懂了。一切都得从一个基础特性说起,更好的输入等于更好的输出,想用好 ai, 本质就是想方设法的把更好的内容给到 ai, 大 模型就能打出更好的答案。 我们和 ai 说的话就叫做题诗词,所谓的题诗词工程,就是研究要怎么和 ai 说才能让它回答出好答案的一些技巧。比如你想让 ai 回答的更专业,方案更落地,可以说你是一个拥有二十年线上推广经验的营销专家, 目前需要巴拉巴拉巴拉。再比如你想让 ai 处理复杂的数学题,也可以说你先拆解问题,分析出解析思路,然后再按步骤一步一步解析,题目是巴拉巴拉。而上下文工程也同样是在解决输入的问题。 ai 大 模型本身是没法连续对话的,它只能回答你一次,但为什么豆包能和我们聊这么久,甚至还能记得我是谁呢?原因是因为我们压根就没在和大模型本身聊天, 中间还隔立一个聊天机器人,我们发出去的话是发给聊天机器人的,他负责传话给大模型,大模型回答后也是先发给聊天机器人,然后再传给我们。 到了第二次对话的时候,为了让大模型还能记得我们第一轮的对话,聊天机器人就会把我们这一次发的内容加上之前的聊天对话,一起打包发给大模型,这样大模型就能看到之前我们聊了什么, 就变得所谓的有记忆了。但这就出现了另外一个问题,大模型每次能读的内容数量是有上限的,超过了上限他就记不全了。随着聊天的次数增多,每一次发给大模型的内容就会越来越多,大模型回答的也会越来越慢,消耗的 token 也会越来越多。于是工程师就给聊天机器人升级了一下, 让他学会了给内容瘦身的技能。当内容累积到一定的数量程度后,就会把早期的一些对话进行总结、压缩,删掉一些没有太大用处的杂词,或者把一些占用特别大的对话直接去掉。这也是为什么我们在一个聊天对话框里聊的久了,就会觉得 ai 变笨的原因。 除了直接处理聊天记录中的内容以外,想方设法地让 ai 能更长时间保持更好的状态,让用户能聊得更久,还能保持体验。这套技术就是所谓的上下文工程,像动态解锁、外部的 i a g 数据库、渐近式路由,这些也都是为了让 ai 能答得更好而生的。 而 harness 工程就更是体现了什么叫 ai 圈的造词能力。当聊天机器人被装上了手和脚,真正成为了一个能帮我们做一切的智能体 agent。 特别是到了这个人人都能写代码造软件的时代,很多传统但巧妙的工作流思维就再次给外行的我们提供了很多用好 ai 的 思路。如果我不懂开发一个软件出来最正确的流程是什么,那就只能依靠 agent 或者大魔星本身的能力去猜,到底要怎么做, 往往结果就不如人。就和前面让 ai 解答数学题一样,如果我们能把这套最正确的思路告诉 ai, 让他就根据这个流程去做,那结果就会越来越可控,也越来越能让我们满意。这套给 ai 的 工作流系统就是所谓的 harness 工程, 他是怎么管住 ai 的 呢?本质上还是提示词,当大模型和 agent 自己不具备这个能力的时候,就得靠用户自己去想我要怎么和 ai 说,他才能答得更好,但这样用户就会用起来很麻烦,也会增加 ai 使用的门槛。 如果不想让人反复去说这些技巧,那就得让 agent 替我们去说,也就是把这些提示词、技巧写进了 agent 里面去。用户只需要简单说一句话, agent 传话前就可以把用户的大白话加上优化的内容一起发给大模型,这样也能实现最终的效果。这时候就开始比拼 agent 之间的能力了, 像小龙虾、 opencloe、 爱马仕、 hummer's、 cloud code、 codex 等等一系列 agent 各家的优化方案都不一样,就激起了网上一大堆的测评讨论。 但为什么还是会出现同样使用小龙虾,有的人用起来就非常顺手,有的人用起来就非常难用。除了使用者自身的能力以外,影响最大的一个原因就是大家用的大模型不一样。像咱们前面提到的这些工程,本质上都是解决如何输入的问题, 但有没有办法能直接解决输出的问题呢?当然有,通过对 ai 大 模型的训练,把一些特别朴实好用的优化方案都练进大模型中,让大模型自身的回答能力变得更强,就不需要那么多复杂的提词子技巧了。 所以只要 a 技能中用的 ai 大 脑足够强,使用的体验和回答的效果就会足够好。这也是为什么说这些 ai 概念本质其实都是一样的, 看懂了本质,咱们以后就不会再怕了。所以当大模型和智能体都不具备好能力时,就需要用户自己去优化输入的内容,当智能体具备优化能力后,用户就不用会那么多了。当大模型自己就具备非常好的输出能力时, 甚至智能体都不需要太多优化的技巧,只需要提供更好用、更高效、更便宜的工具方案就行了。所以说,随着大模型的发展,人终将不会需要懂那么多的使用技巧,最终人和人之间比拼的还是对需求的理解,对结果的判断,还有那永远敢学的勇气。

honey 到底是个啥啊?是不是又在炒概念?这是最近活跃于各大 ai 社区啊,各大讨论群里的一个全新的名词啊。 honey, 英文名呢,叫马具啊,就是除了马以外的各种配套 啊,像什么马鞍啊,江绳这个,这个踏板,还有什么马鞭啊,各种配套的工具对吧? 那么类比在目前火热的 ai 编程界呢,马呢,它就是大模型了啊,马具呢,哈尼斯呢,就是那些什么 problem 的 模板呀,啊,上下文的管理啊,剪辑策略啊,还有什么多步推理的编排啊,工序调用逻辑等等啊,它是指这些 那么简单来讲呢,是除了大模型以外的一切配套的工具啊,统称为马具,就是这个哈尼斯。 那可能有些伙伴就有疑问了啊,就是我现在实现一个 a 证的对接一个大模型啊,或者搞一个什么智能问答 啊,同样要写朋友们的脚本呀,同样要做上下文工程啊,同样要用这个 a 证的思维链啊,不管是 defi, cos 之类低码的,还是说用这个 luncheon 啊, spring 啊,写的高码啊,反正你说的这些什么啊,汉兰斯配套啊,上下文工程啊,编排等等,我一样不拉都得做。 所以很多伙伴就很疑惑啊,这个哈密斯这玩意是不是又是那些啊,吃饱了撑的没事干的架构师啊,人为造的这个概念。我这两天呢,其实我仔细研究了一下啊,还真不是, 你要是认为是炒概念啊,那可能我们的这格局有点小了,对吧?那他那次真正的价值呢,他不在于说啊,发明了什么新名词新轮子,而是在于把影视的杂乱的啊,这个实线显示化模块化了, 这么说呢,可能还比较拗口,其实大家呢,可以啊,类似我们早期的这个三层架构 m v o u control 了,对吧?啊,这个大家都不陌生啊,尤其是我们做过这个加法开发的伙伴啊, 名优 mvc 啊,命名呢和分层呢,它就一目了然了啊,团队的写作啊,代码的维护啊,它它就会清晰很多。那么哈里斯呢,也一样啊,他把每一个 agent 都要做的上下文的工程编排,监控、剪索,工具调用啊,全部模块化形式化了 啊,让我们可以复用测试替换每一个模块,让多个 a 帧它它可以共用啊,一个汉尼斯股价啊,有统一的可观测性的这个评估的接口 啊,当然没有汉尼斯行不行啊,那当然可以了,就像你没有 mvc 框架,你照样可以写这个 yy 应用一样啊,只是说你整体的工程结构啊,没有那么的清晰啊,仅此而已。 那哈尼斯他怎么管控整个 a 侦探流程的呢啊,第一点呢,他是管上下文和记忆 啊,你直接调 api, 上下文超长了怎么办啊,历史对话怎么存啊?哈尼斯要解决的是长短期记忆的这个管理 啊,什么时候该遗忘啊,什么时候该解锁,什么时候用 re 的, 对吧,什么时候该把关键的信息塞到上下文的窗口, 这不仅仅是代码的逻辑了,这是对整个业务流的理解啊,这个是哈里斯管控的,这个第一个点就是上下文和记忆的管控,那么第二点呢,他是管工具和边界,那么对于同样火热的 still 跟 mcp 呢?那么在哈里斯眼里啊,他只是手脚, 那么哈里斯要解决的呢?他是手脚怎么配合的问题,比如说用户问啊,你帮我订一张这个飞机票对吧?那么哈里斯要决定的是他要先查天气 还是要先查余额,如果说查余额失败了,那么是从事呢?还是说直接报错啊,这种涉及到多步推理的编排啊,这种融错的机制啊,也是哈密斯要着重解决的问题。 那么第三点呢,就是关于工具调用的监控了,你让 agent 调用个删除数据库的工具啊,他手一抖,全伤了怎么办啊?伤口跑路了怎么办对吧?那么 hanley 的 核心价值呢,就在于啊,工具调用的这个健全和垄断。 那么在哈里斯城呢,你要做参数的校验了啊,模型传过来的参数,他到底是合不合法,是恶意的呢?还是就是有意为之啊?他其实呢,充当了啊部分审核员的这个作用, 所以总结下来呢,哈里斯他本身他并不是某个所谓的啊,新创的一个概念,他更像的一种标准 啊,让大模型发挥最大作用的啊,或者说执行啊,比较好的一个标准,或者说他是一种架构的思维,或者说是一种设计模式。好了,本期视频就这些,如果你对本期内容的任何疑问,欢迎大家评论,谢谢大家!

今天啊,我跟大家分享一下 openstack 和 superpose 两个工具的融合的使用。首先我们来看一看,你是不是觉得 ai 写代码不太可供,就像拆盲盒一样,第一次生成代码总是有问题, 要反复跟 ai 沟通好几遍才能达到你想要的一个效果, 那么哈尼斯工程化就是你的救命稻草,而 s d d 就是 业类成熟成问的实践之一,大厂们都在用我之前的视频也有过介绍 s d d 的 常用的一些工具, 之前我有介绍过 spec kit, 还有 open spec, superpowers and lin spec 这种轻量级的。 那么网上有不少对这些工具的介绍的文章啊,我认为啊,大部分都是偏理论的,那么你看完之后啊,在实际的项目中依然可能不知道怎么选择,该怎么用, 那么今天我就用实际的项目跟大家做一个分享,怎么把 openstack 跟 superpose 两者结合起来。 我为什么介绍这两个工具啊?是因为我最近啊,我发现 openspec 跟 superpowers 两个配合起来是一个非常不错的一个组合。 openspec 它擅长于需求的这个定义与功能的一个定义, 通过这种描述这种结构化的项目需求,可以明确迭代目标和边界,同时把这个迭代完成之后,还可以通过文档与文档进行同步,让团队协助, 就不再是硬啃代码。而 superpose 他 比较擅长高质量的执行,就像一个高级的开发工程师,质量非常有保障, 它可以制定详细的这个开发执行计划,而且开发完成代码之后,还可以实现这种自动化的代码的测试与质量的保障。接下来我先跟大家介绍一个我自己用 web coding 做的一个小项目,叫做审批参谋, 这个项目呢,我把它定义为是一个一个初阶版的这个智能体的 demo 啊,用户群体是需要经常审批文件的管理者核心痛点就是 经常审批同一个文件或者同类型的文件,每次都要从头 阅读到尾,看这个文件有没有被改过,或者是条款跟之前的有什么出入啊,每次都要从头开始读,如果一篇文章或者一个文档有 好几十页,那么这个是非常耗时耗力的。我通过这个智能体结合大模型, 可以通过智能判定啊,自动判定是否已审批过这个同意个文件啊,如果审批过就直接同意。 那么第二个是可以差异的分析,如果是同类型的文件已经批过了,可以根据你的审批历史,自动的找到类似的文件的差异点,然后提示我们重点关注不同之处,并且结合大模型给出一些省略的意见。 最后啊,我想通过这个智能体记录这个每个用户的这个审评历史,还有我们平时的这个反馈,通过保持这种记忆,完善用户的画像,实现这个智智能体的自动化。 那目前这个项目还存在一些问题啊,这个项目的问题一是因为当时我是想快速的跑这个 demo, 就是 没有考虑这个存储,就是采用最简单的方式,就是本地的嵌入式的数据库 sqlite 三啊, 但采用这种数据库存在一个问题,就是因为它是本地就一个文件啊,容易进行误操作,删除之后数据就丢失了啊,而且它不利于后期的这个扩展和升级。那么第二是网络请求使用的是 这个 x i o s 啊,是没有得到封装的,这个是 ai 自动使用的这个这个内裤啊, 这问题是不便于对请求的拦截,比如或者是,嗯,服务器返回之后做一些拦截啊,比如超市的一些处理啊,都不便于进行统一的一个处理。 那么针对以上的这两个问题啊,我想通过这个 opensbag 和 superpowers 的 结合来对这个项目做一个小小的重构啊。 重构的两个方向是,第一是我们把数据库改成 my circle 啊,这个 my circle 先在我本地跑啊,然后那个 host 是 吧?然后第二是把这个 x i o s 这个原声的这个呃,请求的库改成封装成一个工具类啊, request js 啊,这样呢,便于后期的做圈权,做这个响应的统一处理,还有做一些重试重复的请求后期的一个升升级啊,比如我更想更换浏览器原生的这种飞起这种请求库都是可以的,不影响我的业务的代码的改造。 好,下面我通过项目的实践跟大家做一个呃,这种重构, 先介绍一下这个步骤啊啊,这个项目的一个整体的一个流程啊啊,如果要使用 openstack 呢,你首先要安装相应的插件,之后 对项目进行初步化啊啊,第二就是把重构的这个需求输入给 openstack 这个插件来来进行 嗯,需求的一个定义,那么第四第三是执行计划,这从执行计划开始的话,我们就会利用到这个 superpowers 的, 那么第四我们把这个计划啊执行好,嗯,编辑之后啊,就通过这个 exact plan 这个执行这个计划, 当然这一步的话也可以不用显示的调用,在前面一步 right bands 的 时候,它会提示你是否要开始执行,也是可以进行演示的这种调用的。 那么第五就是我们把这个代码实现之后,我们测试之后也没问题,之后我们就可以通过又回到 opensback 执行这个,那把相关的文档进行同步更改来通啊,进行归到。 那么最后啊,这些都没问题之后,我们可以把这个代码提交到我们的代码仓库,完成了本次的一个迭代的一个闭环。好,流程 大概就是这样,我先给你介绍完毕之后,我们就看一看通过代码层面是怎么实现的。首先启动 ctrl, 嗯,回到刚才那个介绍的这种流程啊,初步化项目,因为我之前已经初步化这个项目了,所以这部分省略了。然后我们进入第二步定语需求啊, o p s x 这个前缀的命令开始啊,就是调用的是 openstack 的 项目的 skill propose, 我 们把我们的需求描述输入给 cloud code, 为了节约时间,我这提前把这个已经敲好了,直接复制过去, 可以看到 openstack 它识别到了,我是要创建一个新的变更, 刚才我们敲了一个 propose, 把我们的需求输输给他,是吧?输给他,现在他进行了一些分析啊,创建了一个这个 propose 的 md 文件 提示,我是不是要创建啊?我这里写 yes, 因为我这里是做演示啊,所以把数据库账号,密码都写到这个 md 文件里面去了啊,正常情况下或者是深实际的工作中,大家不要这样干哦, 这会存在一个账号的一个泄露,然后现在它又提示我是否创建这个 design md 设计文档,是吧?我们选 yes。

ai 世界不停地有新单词、新概念出来,然后这几天很火的就是 harness, 包括我这几天进人都跟人聊这种 agent authentic 的 东西的 harness, 呃,很多博主都解释用基很基础的方法,我觉得,呃,我可以用一个比较人话听得懂的方法来解释,就比如说 张照牙讲了,人的他的本身是由他自己的价值观来定义的,但是你看,其实这 harness 就是 对标的 ai 世界的这种呃,呃, agent 的 价值观 什么概念呢?你说人,我们是知道该做什么,不该做什么,对吧?然后但是机器不会,所以的话你就要给定义一套规则,呃,让他知道该做什么,不该做什么,对吧?然后人呢,我们的社会里面还有法律,法律的话就是可以规定我们,比如说不能乱穿,乱穿马路, 然后这这些犯事,那叫 harness, 就是 可以定义这 agent, 比如说 agent 我 要定义一个循环,不然的话它的无限套娃,无限的 iteration 会让你的 token 消耗很多,那好,那就是说我们 agent 的 过去的架构中没有这些东西,那现在就要定义这些法律规范。 同样在我们现实生活中还有这种,比如说,呃,法院呐,对吧?还有监狱啊,你干的坏事,或者你只能在特定的地方呃工作啊。那 agent 的 agent 的 harness 的 概念就是说,欸,我把你的 agent 放在一个特殊的环境里面,只能在这个环境里面做东西,包括他们我们写 code 的 时候会有 docker, 对 吧?我把 agent 就 放在 docker 里面,其实这就是某种一张讲一个, 呃创造一个虚拟监狱吧,给这个 agent 让 agent 的 就是呃运行更加规范,所以呢,我认为这样解释的话普通人很很什么?其实我在三月八号的时候, 呃,当时我讲,我也讲了整个的呃就是 agent, 因为我我当时就是自己研究 openclaw, 我 觉得 openclaw 里面的价格一定要套一层。这种, 呃,过去我们叫 ai security, ai 安全,但实际上的话,现在又有个新名词叫做 harness, 那 个我张图也也发出来了,所以很多人当时也看了,呃,我觉得这个,呃,所以大家对于做技术的也好,老板也好, openclaw 大家也不要不要,不要太 hyper, 某种意义上讲你你要深刻理解,呃, openclaw 只是这个 ai 在 演化过程中的过程中的一个中中间态。

前两天 arsylopia 发布了 manager agent, 这官网上面也发布了一篇相关的技术文章,主要就是他们 manager agent 的 构建逻辑。呃,那我也仔细阅读了这篇文章,然后说一下我浅显的一个,就是浅浅的做一个我的分享,那如果有任何问题的话, 也是各位大佬也可以指点一下,那我们先从它整个的一个起音开始讲起。首先呢,呃, s arabic 发现啊, harness 里面的假设会过时啊,具体的问题是什么呢?索尼四点五这个模型上面,它感知上下文窗口即将用完时会提前结束任务,那这就被称为上下文焦虑。 那工程师呢,就在 harness 里面加入了一个上下文重置的功能,来专门对抗上下文焦虑的这个问题。 随后呢,这个索尼的换到了 opus 四点五之后呢,上下文焦虑就消失了,也就是模型它自己也会解决这个问题,模型的升级会解决这个问题,那也就意味着工程师写的这个重置代码就成了死代码。 oscillip 就 意就意识到,就如果模型在升级的途中,那不可能每一次模型升级都为它写一个系统或者一套逻辑,那就需要把这个整个的逻辑呢给重构框架呢做成一个可以进行更换的一个接口。 有人要问这个 harness 到底是什么?其实可以把 harness 想象成马脖子上的那个牵引绳大模型就是马, harness 就是 想让马朝我们想要的方向进行移动,那 harness 就 担任了两个角色,一个叫控制,一个叫执行。 那控制的话就是模型它有多少的上下文,它什么时候重置,压缩多少,或者怎么样的整,决定了整体的一个任务的走向,那执行呢?就是执行大模型交出来的一个任务 harness, 我 们就简单讲到,这就是我们进入今天的主线, 那这篇文章到底究竟在说的是什么?整个 ai 模型它是在越来越强的,但是给它搭的运行系统呢?是跟不上的,每一次升级都要推到重建,那这样就不是我们想要看到的, 那 arduino 就 想就是在思考这个问题产生的原因,也许问题就出现在这个旧系统上,因为旧系统是把所有的东西塞进了一个容器,一旦这个容器里面某一个部分崩溃,那么就会导致整个容器崩溃,那安全和调试都无法完成, 那怎么去解决它呢? s o p e 就 想了一个办法,把旧系统抛弃,更新为一个新系统。新系统是把容器里面的几个部分呢分别拿出来,然后比如说把大脑和手彻底的分开,设计一套稳定的可接口,可拆换的一个东西。那具体我们可以来看一下, 那旧系统架构呢?它其实就像一个大容器,那里面呢?有大脑, harnis, 还有沙盒,还有工作日制,那如果说这些出现了任何一个有问题,那整个容器呢?就会崩溃, 那容器宕机呢?就会导致绘画记录修丢失,呃,仍无法恢复,用户体验彻底中断等等。那即便是工程师去修复他的时候呢,他也没有办法看到内部到底出了什么问题, 然后就算进去查呢,也是因为用户的数据在那而受到限制,所以排查也没有办法非常的仔细或者完整,因为整个容器里面包含了所有的东西,那么 cloud 直接把密匙发给了一个, 为了解决这个旧架构问题,设计了一个新架构。新架构呢就是把它们三个独立的分开,大脑在一个部分, c 弦在一个部分,然后操作间在一个部分啊,大脑和 harmonys 就是 下达这个指令就 ok 了啊。然后如果说这个大脑崩了,那我们重启大脑 去重新去读外部的日制,或者操作间崩了,然后重新调用一个操作间,拉一个新容器,这样的话我们就可以避免啊一个容器 一荣俱荣,一损俱损的一个情况。那这里的安全问题他是怎么来解决的呢? cloud 现在生成的代码就在这个操作间运行,但是呢,他不像以前一样可以直接访问密室,而是需要通过一个安全代理中间的一个安全代理去 调用密室,然后返回个安全代理,或者说你要去外部环境的话,那么就需要去,就是也是通过这个安全代理,所以代码永远无法接触到密室,这是一个安全的保障。大模型是有记忆限制的,那任务太长就会忘掉早期的记忆,虽然说传统方法都是用的解断或者压缩,比如说 compact, 压缩的时候也有可能会压缩掉一些重要的信息,那就也有可能导致丢失上下文。新架构呢,把日制放在以外,大模型重启之后呢,就可以去外部读取绘画日制,比如说最后一条日制,或者往前推几条日制,然后重塑某一个关键节点, 这样的话就可以按需去截取某一些日式片段,节省上下文的空间。那整个这一套系统下来,它到底有没有什么优势?或者说有没有什么提升?除了我们看到的部分可以单独的进行重接,那其实在 性能或者回复的这个速度上面,其实也是非常快的。因为旧架构它每次任务开启时都要开启整个的一个容器,里面的每一部分都需要运转完了之后呢才能回答你的问题。 但是新架构的话就是大脑和手分离,大脑可以单独回答你的问题,如果说需要调用代码的时候,大脑才会去调用代码,那省下了非常多的时间。 好,那我们来总结一下整个的一个新架构到底是一个怎么回事? isopik 发现了这个 harness, 这个假设随模型升级它会过期,所以系统呢每一次都需要推导重建,那么它们的解法就是把大脑和手和认知三者分开,然后任意一个 崩溃呢?它不会影响到整体的崩溃,同时也有效的去避免了安全问题,代码无法直接触碰密匙,而是需要经过安全代理进行提取,然后性能上面用户体验也是大幅的改善了的。

你有没有这种感觉?现在大家都在讲 ai agent, 但真要到自己下手啊,根本不知道从哪一层开始。 今天跟大家分享一个偷懒的方法,让 ai 带着你用两小时学完 agent 哈尼斯。最近我一直在看哈尼斯,但一上来就要做一个哈尼斯工程,感觉会有点基础不牢,地动山摇。刚好有个开源的 clock code, 哈尼斯项目拆解了,哈尼斯如何从零开始? 看完以后啊,我最大的判断是,这套东西教给你的不只是理论框架,而是怎么从零搭一个真实可用的 agent 软套。 我把这十二节课总结为三个阶段,第一阶段,先做一个最小可用的 agent。 核心呢,有四件事情, agent loop, 除以 use, 除以 right。 subagent 什么意思呢?就是先让他进入思考,调用工具,拿结果继续思考这个循环,他不会只是回答你该怎么做,而是真的去执行,再根据结果继续干。 再往下呢,你要让工具可扩展,今天接一个查天气,明天能接一个查日历。不用每加一个工具啊,就重写核心的逻辑,然后是 to do right。 这步很关键, agent 不 能上来就乱写代码,他得先拆计划,再一项一项的去推进。 最后呢是 sub agent, 复杂任务不要全塞给一个上下文,前端后端测试,拆分给不同的 agent, 各看各的任务,最后再汇总。 subagent 有 自己的上下文,既能保证专注的 context, 同时呢避免荣誉的 token 消耗。那到了第二阶段,重点就变了, 我们要的不是能跑,而是能够长期稳定地跑。这里最重要的呀,是按需加载 skill, 压缩上下文保存呢,任务状态,还有后台的执行任务。因为真实的项目里面,最大的敌人不是不会回答问题,而是随着上下文越来越长,状态越来越乱, 任务一中断呢,就全忘记了。所以啊,你得让他在需要的时候能够重新加载知识。如果对话太长了,要能够压缩任务,做到一半关机重启,还能接着重来,慢测试,强命令这些要能够丢到后台,保证前台不能卡死。 做到这里啊,它才真的像一个真正的 run time, 而不是一个 demo。 那 到了第三阶段,才是真正硬核的那部分。多 agent 协助,加上真实代码隔离执行,一个 agent 写前端,一个写后端,一个写测试。 听起来很完美,但真正麻烦的不是分工,而是怎么合作才不会混乱。所以你需要有一套团队协议,清楚地记录每个任务,包括输入、输出,什么时候交付,这些都得结构化的保存起来。 再往前一步呢, agent 甚至可以自己主动地去领任务,谁先完成了上一个,谁就去接着下一个。最后啊,为了避免 agent 的 病情工作出现冲突,每个任务还需要有独立的 walk to, 让每个 agent 能够在隔离环境里面做自己的事情。 所以你看,十二节课学完,你得到的不会是一个 chart book, 而是一整套让 agent 能够真正交付的 long time。 能调用工具、能管理任务、能后台执行、能团队协助,还能在真实的工作环境里面并行干活。如果你想做的不是 ai 玩具,不是聊天的 demo, 而是真正可用的 ai 准的产品,那这十二节课我觉得是一个非常好的路线图。