朋友们，马年 ai 圈杀出三头热马，能取代龙虾的 hermes， 独榜视频模型的 happy horse， 以及今天分享的能驾驭所有 ai 的 harness。 我 们一步一步来。什么叫驾驭 ai 呢？我们常说的 ai agent， 就 像是一匹力量极强的猎马，脾气不稳，力量还大，人们没办法安全稳定地驾驭它去做想做的事情。 而 harness 就是 专为这匹猎马打造的全套马具，确保人们能空方向，传指令。简单说，马是 agent， 马具是 harness， 那 一整套驾驭马的工程系统就是 harness engineering 了。 为什么说这驾驭系统必须得有？是因为 agent 天生就存在缺陷，模型本身没有稳定性，输入同样的内容，每次输出来的内容却是随机的，又无法主动与外部互动，对话结束即失忆。而驾驭系统的核心价值， 就是基于 agent 的 这些特性，在外部建立一套环境架构和治理框架，让 agent 稳定完成之前无法独立完成的工程化任务。这套驾驭系统就包含三件事， 第一，给 ai 定规矩，定义 ai 能干什么，不能干什么，高风险操作必须人工确认。第二，给 ai 配装备加记忆，不让 ai 失忆，加工具让 ai 能跑代码掉接口 加质检让 ai 自动跑，测试错了就重来。第三，让 ai 能稳定量产干活，把大目标拆成小阶段，每部有验收标准，完成稳定工程化任务。 这下工程师以后的核心能力不再是写代码，而是给 ai 理环境、定规矩了。有人说，哪有那么夸张？还记得前段时间， cloud code 近五十一点二万行元码意外泄露，引起全网狂欢，而那次泄露有百分之九十八都是 harness 工程代码。由此可见， ai 的 军备竞赛已经从谁的码更快变成谁的码距更好了。
粉丝1.1万获赞8.8万
相关视频
08:43查看AI文稿AI文稿hello， 大家好，欢迎来到 agent 这系列的第十九期，到今天为止啊，我们用了整整五期的实战拜爱马仕工程，也就是所谓的 harness and nero 的 实战，那从头到尾的讲清楚了，并且搭建了一个有 harness 的 agent， 那 如果你一路跟过来了，想必你应该知道了， ai 圈目前为止没有什么新东西啊，所谓的新概念都是换汤不换药啊。那所谓的 harness 所谓的驾驭工程到底是什么呢？它本质上就是让 ai 不 乱说话的一套 对应的企业级的安全生产指南。怎么理解呢？驾驭工程啊，它就是给 ai 装上桅绳和围栏，来约束 ai 在 我们约束的限定的范围之内进行稳定安全的干活，仅此而已了。 那么这整个 harness 驾驭工程大概有哪些东西呢？那整个 harness engineering 啊，大概有以下三个东西，那分别是分层上下，架构因素和主动垃圾回收，而异度分流和 skill 分 装啊，它是 agent 城里面的核心模块，不属于驾驭系统。 但是呢，如果我们要搭建一个有 harness 的 agent， 那 么这五个模块都是其中的重中之重，怎么理解呢？我们先看第一个模块，而第一个模块呢，就是所谓的分层上下文。怎么理解对应的分层上下文 呢？分层上下文啊，其实本质上就是让 ai 啊，一定要看到对应的实时信息，为什么呢？因为 ai 啊，它可以参考对应的你给他的信息来进行回答的，但是呢，也可以不参考，它也能够回答。而 分层上下文，它的升级是什么呢？它的升级是必须让 ai 强制性的参考我们查到的信息，且强制性的参考一些查到的是信息，如果不参考的话，则 ai 不 能够进行相关的回答，并且呢它把上下文进行了分成相关的优先级。如果是一些重要的人物，则需要去看到一些实时的信息， 如果是一些相对简单的任务，那么可能去看对应的常规知识库，或者是 ai 自主判断进行回答则就好了。那么第二个核心能力是什么呢？第二核心能力是架构应约束，这个怎么理解呢？ 本质上其实就是在管控 ai 的 权限，也就是说建立一个对应的防火墙，它本质上是用来约束什么呢？它既是用来约束 ai 的， 也是用来约束我们的，为什么说它也是用来约束我们的呢？它本质上是去做一个对应的 sop 的 流程，那就是说把怎么搭建一个 agent， 怎么让这个 agent 不 闯祸等等一个相关的系统和相关的流程给全部的写清楚， 写好，那写出来一个对应的权限手册，风控手册和对应的流程手册。而这个风控和权限和流程手册是用来约束什么呢？本质上是用来约束我们的，那我们参考这整个的流程，把整个的模型的 ai 的 权限给约束住，那这就是所谓的价格样 约束，而这个主动垃圾回收又是什么呢？主动垃圾回收的话，其实说白了就是要去清理这种长对话的溶液和垃圾，因为对话异常的话，模型可能就会忘记你之前的一个问题，或者说是模型回答的质量就会下降，那 这个时候怎么办呢？这个时候应该要主动清理这些相关的信息，而意图分流又是一个什么东西呢？意图分流啊，它本质上是所谓的路由器，它是负责来进行相关的分类，对应用户的问题，并且规划接下来该怎么样相关的处理呢？这个是整个 a j 城里面最核心的一个模块，但只不过有一些团队和老板并不是特别的在乎这件事情，但是没有关系啊，从整个 a j 城系统里面， 他还是最重要的，他的目标啊，是要去识别出用户的一个精准的问题，并且确保每个问题啊都能进入到一个正确的处理的炼炉。可以想象啊，如果说他进入错了以后，那我们显然连路径都走错了，那后面的处理自然就错了，所以这是最基础也是最重要的。 那所谓的 skill 封装又是什么呢？所谓的 skill 封装啊，它本质上就是把一些常规的，高频的，复杂的业务逻辑啊，可以进行模块化的封装啊，来实现标准化的调用，也就是说把它做成一个所谓的微型的，可调用的，可附用的对应的工作流就可以理解了，我们可以粗浅地把 skill 理解为一个微型的工作流。 那么好，我们讲完了以上五点之后啊，那么大家可能会问一个问题啊，就这些东西我都听懂了，但它们拼在一起，那到底是什么呢？拼在一起之后，一个不翻车的能上线的 agent 有 harness agent， 到底长什么样呢？我们来演示一下。 如果大家有跟前面的流程啊，想必大家对这个工作流，或者说对这个 agent 并不陌生，没错，这个 agent 啊，我们反复的演示过很多次了，我们就以淘宝客服为例啊，那它是一个整个的客服流程的 agent， 这个流程啊，大家可能不能直接拿来急用啊，但是用来理解什么是 agent， 以及是有 harlan's agent 到底什么样子的已经绰绰有余了。在真正的工作之中啊，我们肯定要根据自己的各自的业务场景来进行微调的。那么好，我们叠完 buff， 叠完甲之后啊，我们来正式开始吧。这工作流从用户的问题进来了之后呢，那比 说用户会问很多不同的问题啊，这个手机有什么参数，以及是我的快递到了哪里和我要退货等等的，那我们首先肯定是要去做一个所谓的意图识别和分流，那这就是我们刚才讲的第四个模块，那这个意图分流怎么理解呢？也就是说不同的用户问题肯定是进不同的流程。 如果说用户的问题是查物流啊，那这个时候怎么办呢？我们肯定是进行相关的调用物流进接口，然后去查询用户的物流情况，看一下到了哪里， 如果查到了以后，哎，则进行相关的回复，用户如果没有查到怎么办呢？则进行转人工。而这个流程是什么呢？这个流程我们就可以把它理解为是一个 skill 的 封装，而如果用户的问题他不是对应的查物流，而是商品咨询，那这个时候怎么办呢？那显然他如果是只咨询这个商品本身的一些相关的信息，比如说这个手机的参数等等， 或者说这个咖喱酸我到底能不能吃？那显然我们是需要去查一些常规的知识，而查到了知识之后，则返回给大模型进行相关的回复。那大家可以发现啊，这一块其实本质上就是在做一个东西，叫做分层上下文。用户的问题啊，有一些呢是可以用知识库来进行解的，比如说商品咨询，而有一些的话，则必须要去查一些实时的信息，比如说 物流的信息，那这个时候的话，那显然不同的问题要用不同的知识来进行相关的回答，那这也就是所谓的分层上下文。那分层上下文我们把所有的信息假设啊，那都已经返回给了大模型，大模型这个时候要进行相关的回复了，那怎么办呢？模型生成了一些相关的回答了之后，我们这个时候做了一个对应的所谓的质检， 而质检如果通过了呢，那我们进行相关的回复，如果不通过呢，则进行相关的转人工。我们假设整个的质检是通过了的，那这个质检到底怎么理解？ 那本质上其实就是来进行向下纹的压缩的，那也就是说模型的回复可能会很长啊。亲，我查到你的物流了吧吧吧，物流是什么样子的？或者说这个商品的参数是怎样怎样的？他可能会回复 很长很长的内容，但这个很长的内容呢，确实可以返回给用户，但不是我们需要存下来的，我们存下来的其实只是一些关键的信息就行了，比如说用户的问题是什么？我们回复了一个怎样的答案，那这个答案最精简的情况是什么？比如说用户问物流，那我们可以存的信息是用户的问题是查物流，那我们查到了物流，物流在途中， 那只要存这些信息，这就可以了。那大家可以发现啊，这个质检和所谓的招标模块，也就是我们刚才演示的对应的园丁系统。 那怎么理解这个园丁系统呢？这个园丁系统也就是说是把我们每一轮对应的回复进行相关的压缩，这个压缩呢就是对应的招标而进行相关的质检呢，也就说园丁系统也需要去检查用户的，或者说是我们大模型的回复的。那这个时候怎么办呢？那也就是所谓的质检模块，看啊，所谓的园丁系统，其实就是把它拆解成一个质检模块和一个对应的 燃料模块。那么好，讲完了这些之后啊，我们发现我们刚才讲的以上五个能力，分别是一坨分流、分层、上下稳 skill 和主动的垃圾回收，也就是园丁系统，其实都讲到了，但还有一点没有讲到是什么呢？是所谓的架构应约束。这个架构应约束是什么呢？哦，这个押应约束其实可以理解为就是这个整体， 怎么理解呢？这个架构应约束本质上就是来最初设计的时候，我们去设计出来模型能做什么，不能做什么，哪些权限要开放，哪些权限不开放，以及对应的不同的流程该走什么样的路。所以大家可以发现，所谓的架构应约束，本质上是用来指导我们来去把这四个能力给进行相关的实现的。 那么这个演示完了之后，我们就已经知道了这整个的流程了，那这整个的流程我们再回过头来创一遍，如果用户的问题是咨询这个商品的参数，则进行调用对应的知识库，然后大模型进行回， 如果通过质检的话，那我们则进行进一步的摘药，然后返回给模型，再进一步的相关的回答用户。而如果他没有通过对应的质检，或者说是不是对应的这个商品，咨询的问题该怎么办呢？我们通通的进行转人工治理，比如说如果用户问的是物流，那查到了物流信息之后，然后再进一步的相关的答案聚合返回给用户 就可以了，所以整个 harness 的 agent 大 概就是这样的，那么演示完了之后，想必大家就已经知道了哦，整个 harness agent 大 概是什么样子的？最后呢，我们来做一个简单的总结，那所谓的 harness agent， 它没有所谓的前言学和黑科技的，也没有什么新东西， 它本质上就是把我们过往的时间给全部的串在了一起而已。那过往的时间里面，比如说那该用实施信息的肯定是用实施信息，那不该用实施信息的肯定用普通知识库或者模型自主的处理。分层上下文， 我们要有一些相关的规则和流程来约束我们搭建对应的 agent 架构，并约束以及是相关的垃圾进行相关的处理，那主动垃圾回收和做相关的招标和质检，同时要做好对应的意图分流和 skill 的 封装。那大家可以看到啊，真正让 ai 落地的，其实并不是所谓的让 ai 无所不能，而是让 ai 听你的话进行稳定的干活， 那讲到这里，我们整个 hines agent 的 实战核心内容就基本上已经结束了，从原理到实战到风控到全面路的打通已经基本上全部讲完了。但还有一个问题非常的重要， 经百里者办酒席了，我们确实是把这个流程给全部的搭出来了，我们确实是已经有了一个 harnessed agent 者，那这个时候我们该怎么评估这个流程能否上线呢？这个流程上线了之后又该怎么办呢？下一期我们来聊一下，记得点个关注哦，我们下次见。
330AI练习屋
01:06查看AI文稿AI文稿这个新开源项目想把浏览器框架整个删掉，它叫 browser harness， 四天不到， github 已经两千八百多星。 browser user 团队给他的定义很狂， 最薄、最自由还能自修复的 browser harness， 核心代码量大概五百九十二行。 python 底层直接连 chrome 的 c d p。 它没有那套预设好的 click feel weight 剧本，只有一个 webshop 连到浏览器 l i o n。 自己决定下一步，真正狠的地方是 help us p y。 可以 被 agent 当场改写， 发现去 ablofeil 就 暂停任务，自己把函数补进去再继续跑。 rippole 里还有 domain gen skills， 专门记住 github， linkedin， amazon 这些站点的有效流程。而且 reddy 命名说 skill 最好别手写， 让 agent 在 任务里自己长出来。这套思路是把浏览器自动化，重新拉回最小。 harness 对 cloud code 和 codex， 它的吸引力很直接，接上真实 chrome 就 能干活儿。但第一次上手也不算轻，得开远程调试，还得接管真实浏览器状态。如果这条路跑通， 未来拼的可能不是谁封装更多 a p i， 而是谁的 agent 能在浏览器里自己长技能。
212夜蝶
05:17查看AI文稿AI文稿大家好，今天再给大家分享一个好用的工具叫 browser honeys， 它是目前 ai 操控浏览器最省 token 的 一种方式，它非常的简洁，只有五百九十二行的 python 代码，然后上线三周已经突破了一万的 star， 呃， token 是 比以前的方式能省很多的 呃，目前我们 ai 操控浏览器一共有五条路径，一个是呃 cloud in chrome， 就是 我们平时用的比较多的一个 cloud 的 插件。然后第二个是 computer use， 就是 相当于你把 cloud 交给了呃的电脑，交给了 cloud， 让它去控制这个整整个电脑，但这种方式非常消耗托管，因为它需要截屏确定位置在哪 啊？第三种是 zenium， 这种是传统的方式我就不说了啊。第四个是 pre write mcp， 这是目前像那个 brother u， 呃，那个 use 啊，用的这个框架， 然后 brothers use 他 们现在开发出的 brother hannis， 这个是 c d p 直连的啊，为 ai 造的工具，这个是我们今天要重点介绍的，就前四个呢，它有各自的局限性。然后第五个就是专门给 ai 量身定做的啊，下面我给大家拆解一下。就是它的呃，架构呢，是 quad code 的 呃， 通过 c i 命令行，然后把这个命令发给了 d m， 然后 d m 再通过 c d p 的 web socket， 然后再到你的框，就就非常的简单简洁。它一共就四个核心文件，目前迭代了几个版本，它的命令的代码还是小于九百行的 啊，非常的非常的少，非常的简洁动，不像那些几万行的比起来还是简洁很多的。而且它是直接附用你的 cookies， 还有登录状态，所以能直接操控你的浏览器 啊，他本身还设计了一个叫自愈架构的，他有个 agent helps 啊，他开箱呢，就是你刚装完是空白的，你的 agent 通过各种各样的浏览器执行之后，碰到了一些问题他会解决，解决完之后他就会记录进去，相当于是一个自我迭代跟循环的。 然后仓库本身呢，就是你下下来之后，他已经有了几十个网站的这个操作的经验，就是你的 agent 用的时候就能直接去读取这些经验， 然后这样你一直用下去，它就有一个啊， feedback， feedback， loop， 然后正反馈的循环啊，就形成一个经验的，就是操作浏览器的一个经验的自动沉淀，因为每个网站的它的这个操作的方式可能有些细微的差别， 你怎么怎么去决策用不用这个软件呢？是，首先要看是这么判断的，首先要看你这个网站有没有专用的 m c p。 呃，你像 github， notion， slake 这些是有直接专用的 m c m c p 的， 就相当于它有 ipad 接口，你就根本就不要碰浏览器，你就去找他们接就好了， 通过那 mini 上去接就好了，这个就浏览器根本就用不着。那如果说你要开浏览器，那传统的现在用的可能多一点的就是 playwrite 的 mcp 啊。然后现在我建议你们大家都转成这个 bardeen， 因为它真的很省头，肯啊，非常的好用。 呃，反正大部分场景下 broderhanys 是 性价比最高的路线。呃，然后我我通过这个方式啊，我封装了一个技能，它这个技能的用处是什么呢？就是我们平时用这个追美版 a p i 不是 很贵吗？然后我用这个浏览器的技能接了呃追美版的订阅版， 就是它通过控制浏览器，然后打开 jimmy 订阅版的 jimmy， 然后输入这个提示词，然后就会自动把这个图片生成了，然后下载到呃项目的文件夹里，就这一套下来，你升图片相当于你就可以把额度用呃 jimmy 的 额度用满，就不用花这个 api 的 投肯了， 从投肯的消耗相比的话，大概比 content 柚子能省很多省省个八八倍左右。 呃，我的分享就到这里，然后我接下来会放一下我用这个呃 opus 四点六，然后控制我命令它，然后去生成图片，它自动调取我的技能 去呃生成那张图片并保存下来的过程。大家有兴趣可以接着往下看一看啊，欢迎大家关注今天我的介绍，先到这里，谢谢大家。
3747Simon林的日常
06:08查看AI文稿AI文稿最近产品同学问了一个问题，到底什么是 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， 我 有一个专门的系列在讲， 感兴趣的同学可以去翻翻，感觉有所收获的同学可以点赞收藏加关注，我们下期见！
223新
17:11查看AI文稿AI文稿就在今年的二月五日啊，在 gigahub 上广受欢迎，拥有五点二万四大的开源中端 ghosting 开发者米奇尔乔本，他发表了一篇叫 my ai adoption journey 的 博文啊，讲他自己使用 ai 的 心路历程。你可能没听过乔本这个人，但你一定知道，现在不少人使用 cologne 呢，都是在 ghosting 这个终端模拟器上用的。 主要原因呢，是因为界面酷美好看，比如这个彩虹桥，还有就是 cloud code， 完成任务后能主动发出通知，而不用你时不时打开查看镜果。 构思的作者描述了自己用 ai 工具的六个阶段，从最开始的放弃聊天界面，到自己用 agent 付钱手头的工作，到每天工作结束前都会去跑一个 agent， 让他利用下班时间去做点事，再到能把外包的任务呢，就全部都外包给 ai， 写的非常的坦诚啊，包括他自己一开始也觉得 agent 没什么用， 也觉得不如自己做。然后在第五阶段，他说他开始搞一件事，他把它叫做 engineer the harness。 他的原话大致是这样，每次当你发现 ai 犯了一个错误， 你就花时间设计一个解决方案，让他永远不再犯那个错误。我不知道业界是不是已经有一个统一的术语了，但我开始管这件事，叫 harness engineering， 就是 这篇看似朴素的文章，第一次扔出了 harness engineering 这个说法。 然后 harness engineering 呢，在技术圈里就流传开了。五天后啊，二月十一日， openai 前沿技术研究团队的负责人 瑞安洛波波洛发表了一篇关于 harness engineering 的 文章，讲他们团队呢，如何落地 harness engineering 的 文中有一句话揭示了 harness 的 观念， human steel agents execute， 也就是人类驾驭 agent 执行。接下来两个月， 全球技术咨询公司斯特沃克的首席工程师比尔基塔伯克勒，在重构这本书的作者，也就是被誉为软件开发教父的马丁福勒的扑克上，发表了正式定义 harness engineering 的 文章，叫 harness engineering for coding agent users。 这里面有三个直接 harley's， 本质却很简单的概念，我们等会儿都会提到。接着呢，是全球企业级开源软件公司啊， redhead， 也就是红帽的首席软件工程师马可里奇。 他写了一篇关于 harley's engineering 的 文章，介绍在 a f 辅助的开发场景下面，如何使用结构化的工作流来提升 agent 的 效果。他在文章里提了一个让我印象很深的观念，用一句话概括就是 wake in wake out， structure in structure out。 也就是输入越模糊，输出就越不可控。而给的结构越清晰呢，出来的东西就越靠谱。比如你让 agent 呢，给你装修一套房子， 不能只说帮我装修，至少得先给他一个结构和风格背景。比如我有三室一厅，主卧、次卧、厨房、厕所、客厅，分别偏好什么样的风格。就这样，一个新的 agent 的 工程观念诞生了， agent 等于 model 加 harness， 那 harness 到底指什么呢？ harness 这个词啊，原来的意思是婉拒，就是马干活时身上套的那个东西，用来控制马跟泥、跟车之间的写作关系的装备，确保马能高效、稳定、安全地完成任务。 这个比喻呢，真的是很妙。很多人一提 ai agent， 脑子里想的还是怎么把提示词写漂亮。比如，呃， prop engineering 啊，怎么给模型更好上下文，比如 context engineering。 但 harley's engineering 讨论的是怎么给模型配环境、配工具、配约束、配反馈，配一整套能让它稳定干活的 工作台。所以， agent 等于 model 这匹马，加上 harness 这套玩具这句公式，是不是感觉一下就出来了？ model 呢，是那个会推、你会深沉、会瞎编，也会灵光一现的大脑。而 harness， 是 模型以外的一切 系统题词， skill、 m c p 约定、 memory 测试、 link 验收标准、任务拆分方式，甚至你决定在 cloud code 的 一个窗口里应承半小时，还是做完一轮就开一个新的窗口，这些都算。那 harness 为什么突然重要起来了呢？ 因为 ai 写代码的速度啊，已经快到人类肉眼审察跟不上了。根据谷歌 devops 团队的观察报告显示， ai 渗透率越高，软件吞吐量和交付不稳定性往往一起上升。 而应用安全太水管理公司的 piro 在 二零二五年九月给出的数据也很惊人，截至二零二五年六月， ai 生成代码每月新增的安全风险已经超过了一万项，这比二零二四年十二月提高了十倍。 我当时看到这个数字的时候有点愣住，但想想也合理，以前的工程瓶颈是任务做的太慢，现在呢，越来越是做的太快了，快到你根本看不过来。在 ai 产出速度方面，人类平整速度硬追是追不上的，看不过来，所以经常就不看了。但 bug 率、安全风险不断增高，也不能不管。怎么办呢？ 是的，这才是 harley's 被正式提出来引起广泛重视的本质原因。我们必须通过预判 agent 的 预判，来提升 agent 一 次执行成功的概率，从而弥补人工审查不足导致的产品问题。 这就要提到 harley's 两个目标，一个是提高首次正确率，就是他第一次出手就别那么离谱。第二个是建立反馈回路，让很多问题呢，在抛到你眼前之前啊，先被 agent 自己揪出来，自己去修复一轮。 这两件事听起来平平无奇，但是我是真的觉得，几乎所有用过 agent 的 人的烦恼到头来都能落回到这两个点上，要么他第一次就偏了，要么他错了以后没有一个像样的机制把他拉回来，导致还得扣人工。为了实现这两个目标呢， 斯特沃克的首席工程师啊，比尔基塔伯克勒在正式定义哈里斯三零零零年的那篇文章里啊，把对 agent 的 驾驭分成了两类，盖子和 censor 斯。 guess 呢，是 agent 的 引导器，又叫前馈控制器。而 sensors 呢，是 agent 的 传感器，又叫反馈控制器。 guess 呢，在任务开始前就介入，告诉 agent 应该怎么思考，哪些东西别碰。像 agent 点 m d 啊， clock 点 m d 啊，这些都属于盖子。 而 sensors 呢，则是在 agent 做完之后开始审查，告诉 agent 什么算成功，什么不算，像单元测试啊， int 啊，这些都算 sensors。 接着，伯克勒还提出了 steering loop 的 概念， 用来表达在发现 agent 犯错后更新 guides 和 sensors， 从而让 agent 下次不再犯同样的错误的这个回路，因此叫引导回路。我是真的觉得这些我好像平时也或多或少这么做过，但是讲不出来自己是在做一件什么样的事情。 而 harness engineering 呢，一下就把很多零碎的技巧装进了一个体系里。你以前可能觉得自己只是在写一个 cloud 点 m d， 或者是让 cloud code 呢？每次先列计划再写代码，或者是每次把 agent 成功完成任务后，你会让他把过程中犯的错记录到 memory 呃，避免下次再犯。 现在你会发现，这些动作全都属于 harness engineering， 只是落在不同的时机而已。然后呢，伯克勒把盖子和 sensors 这两类控制器横切一刀， 又分出了推理型和计算型。计算型很好理解啊，就是用脚本代码去做预处理和判断，它的确定性很强，快不花 token， 像格式清理啊，单元测试啊， int 这些都属于计算型。而推理型呢，是交给模型去做于理解 和判断。像原则啊，风格啊，规范啊这类更灵活，需要模型参与，但也更慢更贵更不稳定的方式呢，就属于推理型。有些要求啊，与其在 prop 里面耳听面面八百遍，不如让 agent 写一个代码，脚本每次直接运行脚本来处理，或者做检查，又快又稳定，还不骄傲 toker。 所以伯克勒对这个问题的态度呢，很直接。能用计算型就别用推理型，比如让模型检查一百万字的文章里是不是有不符合标点规范的地方，可能要等几十分钟啊，还不稳定。而让脚本来检查呢，可能只要几秒钟，又快又稳定。 说到这个，还有一个我以前没太意识到，但是看完 harley s 之后觉得很重要的一个词叫 harley s ability， 也就是可 harley s 信。什么意思呢？你可以把它理解成我们给 agent 选的技术站，在驾驭 agent 的 方面构不起来。 如果你做个 web coding 呢，一定深有感触。同一个大模型，写 type script 往往比写 javascript 稳得多。写 next 连 js 这种约定化的框架呢，远比裸写一堆零散的前端脚本来就顺畅。写 supreme 这类强范式的框架呢，也比随手去拼凑一些松散的 javascript 项目靠谱很多。 大家通常只会归结为，呃，框架和静态语言的训练数据更充足。这当然是一部分原因啊。但从 harness ability 的 这个视角来看，还有一个更核心的底层逻辑。这些成熟的技术栈呢，本身就自带一套完美的类制软件 强类型系统，是软件标准化陈述框架，是软件约定俗成的目录结构与工程规范，是软件完善的 int 生态 skill 教育统一编码范式，通通都是软件。 我越发觉得，从这个视角来看，就能解释绝大多数的 code 项目为什么写到后面越写越失控的原因。很多时候，不是你的 prop 写的不好，也不是模型突然抽风了，而是从一开始你就给 agent 这匹马配了一套 过于松散、不确定性极高的晚句。所以啊，选择凡事越严谨，约束越完备、架构越固化的圆和框架， hardest ability 就 会越强， agent 发挥呢，就会越稳定， web 的 落地效果自然就越好。 redhead， 也就是红帽的首席软件工程师马克里基的那句 wake in wake out， structure in structure out 说的也是这个意思。那 harness engineering 这东西它能做到什么程度？它目前的上限在哪里呢？ openai 前沿技术研究团队负责人瑞安洛博部落说，他们在五个月的时间里，靠三个工程师做出了一个大约一百万行代码的内部 bug 产品。 人工编解代码呢，是零，人工评选也几乎是零 p r， 也就是 per request， 大 约是一千五百个，日均 token 消耗大约在十个亿左右。 我第一次看到这组数字的时候，老师讲，我不想继续再看了，日均十亿的投款，别说个人，就是大部分企业也承担不了。这个就先不谈不谈了。不过文中有一个对我们普通人有借鉴价值的理念值得提一下。 ovi 的 团队啊，发现搞一个巨无霸型的 agent 点 m t 呢，根本不行，信息太密，太容易腐烂，模型也抓不住重点。后来呢，改成一个大概一百行的入口文件，像目录一样，把 agent 引导到真正的 dos 目录下的知识库里，按需获取信息， 先给地图，再给分支路线，这叫渐进式批录。他们不将 agent 点 m d 视为百科全书，而是将其视为内容目录。这让我想到前 openai 创始人团队成员安德烈卡哈西提出的 l m wiki 的 个人知识库的理念，把 wiki 的 目录呢作为知识库的入口文件， agent 需要什么知识呢？就看目录去按需获取。 看我那期视频呢，应该能秒懂。我现在再回头看 prop engineering， context engineering， harness engineering 这几个词啊，感觉层级一下清楚了很多。 professor engineering 呢，更多是在研究怎么跟大模型这匹马把话讲清楚，而 context engineering 呢，更多是在研究怎么给大模型这匹马提供准确的背景信息。 harness engineering 呢，则更上一层，他关心的是这匹马怎么干活，怎么使用工具，怎么不罢工，怎么自我改正错误，怎么给跑着跑着 掉到悬崖下面去了，怎么不两次踏入同一条河流？所以这三个概念呢？它是层层递进的，从局部的单点控制到整体的一个系统控制。所以，如果你是一个工程师，不妨回头看看你平时的工作，自己更注重的是哪一层。 越靠近 harley s， 你 的竞争力就越强。没错， harley s 就是 agent 时代的软件工程。虽然说软件工程，但是我觉得这件事对我们普通人也很重要。 你可能不是软件工程师啊，只是用 cloud code 啊， code x 啊， cursor 去 web coding 自己的业务项目，或者做一点自动化研究啊，写作啊，梳理整点事情。我非常理解那种感觉，你并不想打造一个什么未来工厂，你只是想让这个 a 证呢，少出点风，少反几次工，少在关键地方给你整出一些幺蛾子。好消息是， harvest 这东西啊，完全可以从很小的地方开始。 说实话，我自己还是在摸索以下这五件事情呢，都不是什么惊天动地的操作。第一次看可能还觉得有点麻烦，但我现在是真的感觉这几件事情值得养成习惯。再说这个之前呢，有些人可能有些疑惑，为什么 pro engineering， context engineering， harness and these 这些概念都起源于国外的文章，为什么不是国内提出的呢？ 说实话，这个问题呢，很复杂，一两句话说不清楚也不好说。我掌握国内关于 harley s 还是六二零文章，基本都是后来研究学习国外的文章的解读，包括我这篇，也是带有神奇的事情。就在二零二六年二月，几乎是和国外第一篇提出 harley s 的 文章同一时期，一本叫 agent 的 设计模式的中文书悄悄出版。 我是看到有人推荐，才翻开来看，看了有点震撼，因为这本书整个在讲的事情，就是怎么在一个不确定的 ai 上构建出一个你能信任的系统， 而且写的不只是面向工程师，是面向所有想用 age 能稳定干活的普通人。这不就是 harley s engineering 吗？一本全书都在讲 harley s engineering， 却没提到一次 harley s 的 书，作者可能压根不知道有这个词，但他把这件事情呢，想清楚了，而且提前想清楚了 很多的手绘图啊，经典故事啊和案例啊，就是对着你讲 agent 这匹野马到底该怎么去驾驭中文书能把这件事认真想清楚，再写成普通人能读进去的文字，有点难得。这种心思我是真的有点感动了。就算你暂时没空翻这本书呢，接下来我要讲的这五件事，你也可以直接拿去用。 思路啊，是一脉相承的。第一件，认真写一个 cloud 点 md 或是 agent 的 点 md， 别写空话，别写愿景，专门写那些 agent 真的 会犯错的地方，哪些事情始终去做，哪些事情先问我，哪些事情绝对别做，越去提越好。如果你想做完 q 点，但实在不知道这些 md 该写些什么，你可以到这个地址去下载这份 cloud 点 md。 这个 md 文件呢，是由一位国外小哥从前 open 创始人团队成员安德烈卡西的推文里整理出来的，目前已经超过十万颗 star， 硅谷的很多工程师都在用，你可以放到你的项目跟目录直接去使用，它能提升你的 agent 首次完成任务成功率，减少你人工审查和代码返工的次数，帮你降低使用 agent 的 时间和投肯成本。第二点，给 agent 提要求的时候，不要直接说让他实现，而是让他先出 plan 再动手。包括哪几个文件会改，验收标准是什么，测试怎么跑，失败了怎么回退，这些让 agent 在 前面讲清楚，后面呢，会少掉很多莫名其妙的错误。 如果你不知道怎么写，就把上面这段话复制给 agent， 让他自己把这个要求写下来。第三件，让 agent 帮你准备计算型的 sensor， 比如你在让 agent 帮你润色文章之后呢，为了避免出现敏感词或者你不喜欢的措辞，可以先用一个词库脚本来检查，发现问题直接输出有问题的词， 提示 agent 自动修正。这比每次让大模型帮你检查要快十倍，也更稳定。这个做法呢，也很简单，你把敏感词库准备好，让 agent 帮你检查要快十倍，也更稳定。这个做法呢，也很简单，你把 m d 或者 agent 点 m d 里增加一句话， 每次写完文章后，运行敏感词库检查脚本，直到通过。第四件，每当 agent 重复犯错，不要只修输出，要回头去修你的 harness。 把经验写进规则文件，从坑里提炼出测试脚本。因为为了避免同一个坑里掉两次啊，这个经验呢，就应该固化到系统里面，而不是只活在你的记忆。第五件是拉尔夫循环，不要等到一个窗口聊到上下文都发嗖了才开心的窗口。 二维循环的理念就是每次做一件事持续做，直到它成功。做法呢，也很简单，比如你要 whitaker 一个视频字母翻译的 skill， 那 么你先写好这个 skill。 开发任务需要的上下文背景信息，包括把任务分解成下载视频，生成 s r t 字幕，翻译 s r t 字幕 这些内容呢，放到一个 cloud md， 然后从这个 md 文件的同一目打开 cloud code 的 窗口。关键在这里，这个窗口你只要求 a 着它做一件事，就是实现下载视频这个子任务， 把产出的成果呢保存下来，完成之后重开一个新的窗口，基于上一步的成果去实现，生成 s r t 字幕，然后再重新开新的窗口，实现翻译 s r t 字幕。 纳尔夫循环的理念已经被 cloud code 的 借鉴，做成了官方插件，所以更简单的方式呢，是安装这个纳尔夫循环插件来使用。安装方法也很简单，直接和 cloud code 说，帮我安装这个插件，然后把这个插件的 github 地址直接粘贴进去就可以了。使用方法呢，也很简单，直接输入这段内容， 比如 prop 呢，可以这样写，然后这个命令呢，就变成了这样。纳尔夫循环就是一个简单的 hardest 工程，包含了乾坤引导， prop， 也包含了反馈控制， test， completion， promise。 比如这几个东西啊，可以提升 agent 首次执行就成功的概率。上面这五件事听起来可能并不酷，甚至呢，让人觉得有些烦。说实话，我也不确定所有人上来都会喜欢这套做法，因为它确实会让你在前街做不少准备。写规则、补测试、拆任务、收拾文档，有时花的时间比你自己撸一把还要久， 尤其是项目刚开始的时候，这种感觉特别明显。我自己呢，也在这个阶段经历过，觉得写这些干什么，直接让他做不就好。但反过来想，这恰恰就是工程。 工程很多时候呢，都不炫，他只是把本来会一次次返工、一次次踩坑、一次次靠经验救火的东西，默默变成一个可以重复、可以扩展、可以交给别人，也能跑起来的系统。 harness and loren 打动我的地方也在这里。他没有把人降格成审查机器了，反而把人的位置抬高了。人不再需要盯着每一行代码去当质检员，而是去决定方向，决定边界，决定哪些错误值得被永久消灭，决定哪些规范要变成系统的硬性约束。人类驾驭 agent 的 执行， 我觉得这可能是在很长一段时间里，人和 ai 之间最合理的分工模式。我们再看这个公式， agent 对 model 加 harness 模型给了 agent 的 上限， harris 决定了 agent 能多大程度接近他的上限。越接近这个上限，终端交付物的编辑成本就越趋近于零。而那些定义规则、搭建系统设计流程的 harris， 能力会慢慢变成真正稀缺的东西。说真的，就在不久的将来，那些你觉得值钱的结果会很快变得廉价。 而那些你平时觉得无聊的过程呢，会悄悄替代，结果变得值钱起来。代码会廉价，架构文档和编码流水线会变得值钱。 文章会廉价产出文章的方法论和工作流会变得值钱。你想想看，是车贵，还是车的图纸、模具和整车的制造产线贵？ ok， 这就是我想要和你分享的 harley s 的 全部思想和使用技巧。能看到这里，你对 harley s 的 理解已经超过了百分之九十的。 如果你想试试 harley s， 我 的建议是从一个很小的地方开始，比如先试试卡帕西的 color 点 m d code code 的 拉尔夫循环插件。甚至呢，只是在 a 卷的完成任务后加一句，记住你犯过的错，以免下次再犯。用用用，找找题感，看看效果，如果觉得有用，再慢慢扩展 好了，就这样，你的 hardest 看呢？欢迎来评论区分享你的看法，让更多人看见人与人之间的交流互动啊，永远是 ai 无法代替的体验。我是邓秋水，用技术生存，用哲学生活。我们下期再见。
231再临秋水
02:30查看AI文稿AI文稿harness engineering 最近这个词儿真的被提到很多，今天我从 ai 学习者的角度，结合我自己这段时间的实践，聊聊我对它的理解，怎么驾驭 ai 工具，输出稳定可靠的结果。作为一个研三学生，我深受查找参考文献之苦， 于是萌生了做一个参考文献查找工具的想法。核心需求很简单，向用户展示文献标题、作者 g b t 七七一四、引用格式 以及可验证的真实文献链接。这一点最关键。初期做出来的成品非常粗糙，本质就是写一段提示词，通过 a p i 向大模型发请求，再把返回结果解析到网页上。我做了两个版本，一个用 mini max， 一个用 cloud。 最初用 web 抠定的时候， cloud 直接指出 mini max 没有 web search 工具，无法保证信息真实性。我不信邪，先去 mini max。 没有 web search 工具，无法保证信息真实性。我不信邪，先去 mini max 自家的对话产品里验证了一下，结果返回了一堆四零四，确实不行。 而 cloud 因为配置了搜索工具，准确度很高，但代价是调用一次 api 就 要花六七块钱，成本实在太高。为了让国内没有 vpn 的 同学也能用上，我开始寻找替代方案。先试了有 web search 工具的质谱，但由于多种原因，加上黑箱困境，始终没能跑通。 接着试了 openclaw， 给他配了 brave search api， 返回的信息倒是真实，但引用格式里不加作者，我提醒后开始瞎编作者了，显然不满足需求。至于他是否有学术搜索的 skill， 由于对其工作机制的未知，我放弃了这条路。放弃的另一个原因 是，我想起了之前看吴恩达在 deep learning ai 课程里讲到的一个观点，对于复杂且随机性高的任务，应该配置自主性高的 ai， 而对于要求输出稳定可靠的任务，并不需要给 ai 很 高的自主性去自己调用工具。这让我转变了思路，既然我需要的是真实的学术刊链接，那为什么不直接给工具配一个 只会返回真实刊链接的 api 呢？于是，我找到了 open、 alex 和万方这样的学术检测 api， 并设计了如下框架，用户输入 deep sec 生成解锁 query、 外部工具解锁 deep sec 筛选相关性弱、不足三篇大模型反思并重新生成 query 循环执行输出。结果，经过测试，这套方案已经基本满足了我的需求。 总结，当单一提示词解决不了问题时，就该考虑用工作流去约束大模型的输出了。这里不是科普，这是我的 ai 学习日记第三期。
14延林W
02:17查看AI文稿AI文稿最近 harness engineering 这个东西也特别火，其实它跟 prompter engineering 和 context engineering 是 有一定联系的，这三个词几乎完美地标记了你跟 ai 写作方式的三次进化。第一阶段， prompter engineering， 也就是体式工程，大约是二零二三年提出来的。 当时的时代背景就是以 xpt 为代表的大模型，初期其输出不稳定，对指令形式比较敏感，所以就进行设计单词对话的一个题词，通过优化问法、提供角色的设定、格式约束等，从 ai 去榨取更高质量、更稳定的一个回答。此时这个 ai 类似于需要玩家精确操作每个动作的遥控机器人， 虽然在当时能显著提升输出质量，但随着模型智能度快速提升，其编辑的效益也会迅速下降。第二阶段就是 context and memory， 也就是上下文工程，大约是二零二五年提出来的。当时的时代背景是，比如一些模型虽然很聪明，理解自然指令的能力虽然增强了，但是上下文的一个窗口有限，成为了一个新瓶颈， 所以需要从雕琢单句题词转向经设计与工程化填充上下文窗口的一个信息。这涉及了如何为特定的任务去选择并高效提供最相关、最精准的背景信息，用填充上下文窗口的精妙艺术与科学。所以呢， 此次 ai 境界为自主行动的助手，人类的工作类似于配置阵容与规则的一个策略家。最后就到了第三阶段，也就是 harness engineering， 也就是驾驭工程，是二零二六年才提起来的。那时代背景就是 ai 进化为更高度自主的一个智能体， 能够长期自主的去执行复杂的任务，人类无法实时监控每一个步骤。核心任务就是构建一套名为 harness 的 一个系统化约束与控制机制，以更加安全、高效可控的去引导 ai 智能体。 所以智能体呢，这个时候就是等于模型加上 harness。 harness 的 构成它主要包含了两大类的一个控制机制，一个是前馈控制行动前的一个规则，比如一些架构规范呀，依赖规则呀，权限的一个系统，就像一个高速公路的一个护栏，防卫与未然。一个是反馈控制行动后的一些检查， 比如自动化测试啊，代码检查，持续集成流水线，用于事后的一个验证与纠正。其实这三者并非一个替代，而是一个深为欠讨关系。像 harness engineering 呢，需要通过 context engineering 来鞠躬有效信息，而 context engineering 呢，最终也是通过设计一些 promet 来与模型进行一个有效的沟通，这就是 harness engineering。
48Ning好
06:53查看AI文稿AI文稿大家好，我是 luke。 之前做 cloud code 源码拆解的时候，我在第二期提过一嘴，说 cloud code 里的那些精巧设计，其实指向一个更大的概念， 今天就来兑现这个承诺。 ai 圈最近在追一个新词，叫 harness 驾驭工程，它正在取代提示词工程，成为下一个热门话题。没看过之前源码拆解系列的，建议先去看一下，看完再回来，会有完全不一样的体感。 事情是这样的，今年二月，一篇博客在 ai 圈引发了连锁反应，作者是 mitchell hashimoto， hashimorp 的 联合创始人就是做 terraform 那 位大佬。他回顾了自己用 ai 编程的历程，分了六个阶段。 到了第五阶段，他造了一个新词，意思很直白，每次发现 ai 犯了错，不是改提示词，是改 ai 的 运行环境，让他以后不再犯同样的错。几周之内， open ai、 antropic 都在技术文章里用上了这个词。提示词工程的时代正在被一个新东西取代。 要理解这个概念，得先看 ai 的 用法发生了什么变化。二零二三到二零二四年， ai 是 个听话的助手， 你说一句，他做一句，核心能力就是把话说清楚，这就是提示词工程。但到了二零二五， 二零二六年， ai 变成了自己干活的员工，你给个目标，他自己规划，自己调工具，自己执行，一跑就是好几个小时。问题来了，管助手靠的是把话说清楚，管员工靠的是建制度，助手做错了，改一下指令就好。 但一个自己跑了几小时的 agent 做错了呢？你不可能全程盯着，你需要一套机制流程，检查点、反馈、闭环、权限、边界，让它在你不看着的时候也别搞砸。这套机制就是 harness。 还有一个更好懂的说法，如果 ai 模型是 cpu， 那 harness 就是 操作系统。 cpu 再强，没有操作系统，调度管理也就是一块芯片。这个概念能突然火起来不是偶然。 二零二六年初，三个变化刚好撞在了一起。第一，模型越来越像了， cloud、 gpt、 gemini， 再加上各种开源模型，在标准测试上的差距越来越小，光靠我用的模型更好，已经拉不开差距了，真正的差距在模型之外。 第二， agent 开始上生产了。 ai 不 再只是帮你写封邮件，改个 bug。 企业开始把 agent 放进真实业务里，自主写代码，管基础设施，跑财务分析， 一个任务跑几个小时，中间没人干预。可能性的标准从演示能跑通变成了线上不能崩。第三，一个扎心的发现， antropic 在 实践中发现， ai 评价自己的工作时，倾向于给自己打高分， 哪怕产出明显有问题，他也觉得自己做的不错。也就是说，你不能让同一个 agent 又干活又检查，必须把执行和评估拆开， 三件事凑到一起，指向同一个结论。 ai 的 瓶颈已经不是模型够不够聪明，而是围绕模型的那套运行环境够不够靠谱。 回头看脉络其实很清楚。提示词，工程叫 ai 听懂你的话，上下文工程给 ai 足够的背景信息来判断、驾驭。工程给 ai 建一套完整的运行制度，一步步地把人盯着 ai 变成了系统。管着 ai 概念讲了不少， harness 到底长什么样？我们拿 open ai 的 codex 来举个例子，你看这张图， codex 写完代码之后，不是直接交给你，它会自动启动浏览器，用 chrome devtools 去真实地操作界面，截屏，对比检查控制台日期，发现问题就自己修，修完再验，循环往复，直到所有检查都通过，这就是一个完整的 harness。 你 看，这就是 harness， 不是一句提示词，而是一整套自动化的检查和修复机制。写代码只是第一步，验证和修复的循环才是关键。 anthropic 也有自己的一套方案， 它们的思路不太一样，是把一个任务拆给三个不同的 agent， 分 工协助。它们借鉴了对抗网络的思路，把一个任务拆给三个 agent， 协助。 规划者负责把用户的简短描述展开成完整的产品规格，生成者按规格一步五写代码，每做完一个功能，先自查。评估者不写代码，只做测试，逐项检查界面、接口、数据库。说白了就一句话，干活的人不能当自己的裁判， 这不是纸上谈兵。 antropic 做了对比实验，同一个任务开发一个游戏编辑器， 单个 agent 跑了二十分钟，花了九美元，结果核心功能是坏的，游戏根本没法玩。换成完整的三 agent， harness 跑了六个小时，花了二百美元。但交出来的是一个完整可用的产品，成本差了二十倍，质量却是能用和不能用的区别。 放在生产环境里，这不是省钱的问题，是东西能不能上线的问题。看到这里，如果你看过我之前做的 cloud code 原码拆解系列，应该会有一种恍然大悟的感觉。 我们当时拆解的那些系统权限分级、安全漏斗、上下文、压缩、记忆分层，现在回头看，它们合在一起，就是一套完整的 harness cloud code， 能比很多 ai 编程工具更稳。不光是因为模型更强，它的 harness 工程也做得更完善。 所以呢，如果你是 ai 从业者，方向已经很清楚了，下一步拼的不是谁 prompt 写得好，是谁能把 agent 的 运行环境设计好。 模型会继续进步，但怎么让更强的模型稳定交付这件事不会因为模型变强就自动解决。如果你是普通用户，下次挑 ai 产品的时候可以多留个心眼，别只看它底层用的哪家模型，得看它整个产品架构做的怎么样。 同一个模型，不同的产品，套壳体验可以天差地别。那些用着就是比较稳的 ai 产品，多半不是模型更好，是 harness 做得更好。最后总结一下， harness 这个概念的核心就一句话， ai 变聪明不是最难的， 让聪明的 ai 变靠谱才是。从提示词工程到上下文工程，再到现在的驾驭工程行业终于开始认真对待这件事了。 harness engineering， 记住这个词，未来 ai 产品的竞争就是 harness 的 竞争，这就是今天的全部内容。我是 luke， 一 起探寻 ai 原理，看见生活与工作的新可能。如果觉得有收获，帮忙点个赞，转发一下，我们下期见！
112Luke的AI沙盒
00:36查看AI文稿AI文稿仅用五百多行代码实现，让大模型控制浏览器的最轻量级 harness ai 浏览器自动化黑码 browser use 今天又开源了一个神级项目， 无需预设，不用框架， ai 看到网页缺什么功能，能自己现场写代码补上。简单说，这是一个能自我修复的浏览器智能体框架。最大的亮点是 ai 遇到不会的操作，可以动态编辑代码库，自己加函数进去。它彻底抛弃了传统浏览器自动化框架的限制，只用一个 web socket 直连 chrome， 给 agent 最大程度的操作自由，作者甚至发起挑战，目前还没找到他完不成的网页任务。他代表 agent 的 一个主流方向，从按照预设指令执行，变成看到问题现场编码解决。
847阿博粒
04:52查看AI文稿AI文稿最近 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， 我 来安排。
1483刘涛Todd
04:41查看AI文稿AI文稿如果你最近在做 agent， 或者你关注 ai 的 落地呢？你可能会被一个问题困扰，就是为什么同样的模型，别人家的 agent， 它能稳定地去跑出复杂的任务，而自己的系统呢？总是走一步歇两步。很多人第一反应就是说这个模型是不是不够强，但其实模型它只是一个智商，或者是一个脑子，而真正能决定这个 ai 能不能落地，能不能挣钱的，其实是 这个脑子之外的这一层约束装置，也就是 harness engineering 约束装置工程。那为什么就是这个词突然现在变得极其敏感呢？前段时间 open call 的 创始人呢，在炮轰 aerobic， 他 说真有意思，大厂总是先精准地去复制开元社区的热门功能到自己的这个封闭的 harness 里， 然后再反手把开元社区锁在门外。那这句话翻译过来就是说未来的大厂之争呢？表面上可能是在拼这个模型的参数，但背地里其实就是哈尼斯的护城河之战，因为现在模型的这种能力已经就 逐渐平替化了。可能大家之间的差距并不是很明显，那谁能把外面这层壳做的更稳、更安全、更闭环？谁有绝对的定价权？那要理解这场战争，我们就必须要看清 ai 进化的三个阶段， 也就是提日思工程、上下文工程和约束装置工程。那第一阶段提日思工程，它其实是在做这个语言的设计，因为大模型它是一个概率系统，你写提日思就是在创造一个局部的概率分布那。但很快大家发现了很多事情，它其实好像说清楚，它也不能解决，因为大家要理解，要知道这个事情， 那其实自在好，它也代替不了信息的本身。于是就进入第二个阶段，上下文工程，也就是前段时间我们讲到的 r e g， 它的核心逻辑是 ai 在 决策这个瞬间的时候，给到它刚好并且够用的信息。因为上下文窗口它其实是一个稀缺的资源，不是越多越好，而是要越精准越好， 让模型的所有回答它是要有所依，然后就进入当下第三个阶段， harness engineering， 你 可以把它理解为就是除模型之外所有影响这个系统的稳定性的机制。它的总和就是这个 harness， 提示词也好，上下文也好，它其实是解决这个输入的问题， 但是 harness 它解决了，就是整个执行的过程，希望模型能够持续地做对，主要它其实是一套用来管理、约束、监控、纠偏的一个执行的机制。如果把 ai 比作一个非常厉害的实习生，提置词就是入职培训，上下文呢，就是这个项目的资料，那 harness 呢？就是 checklist， 然后汇报制度、实时优盘以及最终验收，它其实是一个整套的机制，所以整个 ai 工程化的成熟度模型，就是由这三个阶段进行一个进化演变的。一个商业级的 harness 架构呢，它必须要包含六个模块儿， 首先就是上下文管理层，他来去控制信息的边界，在正确的范围内进行一个思考。第二个就是工具，系统层，他不只是给工具，他还要具备处理异常问题的能力，核实、调用如何处理返回，然后具备真正做事的能力。第三个阶段就是执行循环层， 他把这个整个任务呢进行一个闭环，然后理解执行、验证、修正，缺一步算一步的这种情况。第四个模块就是这个记忆与状态层， 它杜绝了让 ai 变得像老年痴呆一样，走一步就失忆了。第五个模块就是评估与观察层，它其实是系统的眼睛，让它自己知道自己有没有做对。第六个模块就是控制与恢复层，它就是最后一道防线， 当这个 ai 彻底跑偏的时候，系统能不能自动的重试回滚，或者是允许人工的介入，这就是这个约束与恢复。所以整个执行的这个机制呢，它是要有一个闭环的，对吧？让任务闭环你的这个长链路执行的时候，它就是不容易跑偏了。 那在实战的过程当中呢，有三个非常重要的 harness 思路。首先呢是生产与验证的一个分离，干活的 agent 和这个验证的 agent 它其实要分开的，你自己给自己打分的话，那那岂不是你这个 分数就没有任何的参考价值了吗？那第二个和第三个呢，就是这个按需加载和状态迁移，也就是进程重启。那按需加载呢，就是永远不要把所有的规则一次性塞给模型，要把整个环境设计呢设计成这种按需索取。 第三个呢就是进程的重启，也就是这个状态迁移。在长任务过程中呢，上下文会不断进行一个膨胀，那导致可能这个模型也就是降质了。最有效的办法就是在合适的节点重启这个 agent， 然后并且只迁移必要的状态，就要像这个管理系统进程一样去管理这个 agent 的 内存，不要再去神话这个模型有多么多么厉害。一个 agent， 它是由这个模型和 harness 组成的， 那模型只能决定了这个能力的上限，而 harness 呢，决定了这个商业落地的下限。所以我们去开发 agent 的 过程当中呢，我们这个角色要开始发生转变了，传 统的 ai 开发者呢，我们就去驻航写代码，调用这个提示词，那 agent 出了问题，就会希望让模型再努力一点，然后能让模型自己看能不能解决这个问题。但是现在我们要转变成一个 harness 架构师，我们应该去设计任务的结构和运行环境。 agent 出问题了，我们应该去看的是执行环境里缺了什么能力，到底什么机制 出现了问题。我们应该从调教模型转向一个构建系统的过程。所以当 asteroid 开始封杀第三方的 harness 的 时候呢，你就应该意识到这个 ai 核心的战场已经开始转移了，对吧？如果你在做 agent， 那 harness 的 系统架构你可能要越早向成熟越好。
115八荒的Ai
06:34查看AI文稿AI文稿今天跟大家分享 harness 安全护栏 ai agent 越权操作如何彻底杜绝。先问大家一个最关键的问题，如果一个 agent 突然说我要执行 r m 杠、 r f 斜杠一键格式化系统，我们到底是靠它自觉，还是靠系统根本不给他机会？ 其实答案很简单，真正的安全不是教育模型别做坏事，而是把危险动作从结构上封死，让他想做也做不到。 更多 ai 大 模型学习物料可在这儿拿走。大家好，我是彭宇，你先看首页，这里核心就是一句话， harness 要把能想和能做彻底分开。上面这些小标签，最小权限、沙箱隔离策略、网关审批、拦截、全链路审计。听起来很多，但本质上就一件事儿， 把 agent 关进一个只能安全活动的空间里，它可以思考，可以提建议，可以生成方案，但它不能直接碰触主机，不能直接拿根权限，不能直接外联，不能直接拿到长期密钥。也就是说， agent 负责提议， harness 负责裁决。好，那我们顺着图往下讲，先看第一层任务入口与意图收敛。这里我想先反问一句，用户给你的到底是什么？是一个具体的系统命令吗？不是， 用户给的是一个业务目标，比如说改代码、跑测试、部署服务，表面上像是一个任务，但真正危险的是， agent 很 容易把这些目标翻译成更低层的操作，然后直接往执行器里塞。所以 harness 的 第一步不是让它马上干活，而是先收边界。 这个任务在哪个仓库、哪个目录、哪个环境、哪些资源能动，哪些资源绝对不能碰。接着就是意图识别。也就是说， harness 不 会把原始自然语言直接当成命令，而是先把它翻译成可治理的能力请求。这一步特别关键，因为你要把我想部署一个服务和我想删掉整个系统这种东西在结构上区分开， 然后再做风险分类，什么是止读，什么是修改，什么是外乎，什么是删除，什么是部署？这些风险等级完全不同，不能混在一起。你看这一步，其实就是把混乱的自然语言变成一套能被系统理解的安全请求。然后我们进入第二层能力目录与最小权限 harness。 这里我先问大家一个问题，为什么很多 agent 一 旦接上工具就容易出事？因为他拿到的不是能力，而是万能入口。而 harness 的 思路正好相反，他先定义能力注册表，只暴露可控能力，比如读文件，改局部代码，跑测试，生成补丁。 换句话说，系统里先有能做什么，再有怎么做。这里还有一个很重要的动作，叫命令抽象化，不要直接给他任意 shell， 不要让他自由拼命令，而是把操作变成受限动作接口， 比如修改某个文件，运行某个测试，提交某个补丁，这些都是受控动作。这样一来， agent 就 算想表达危险意图，也很难找到可以直接落地的表达方式。再往下就是权限最小化，这个大家应该都熟，没有根权限，没有宿主写权限， 没有长期密要，没有默认外网通行证。最后是作用域限定，只能访问指定工作区、指定仓库、指定分支、指定资源清单。简单讲就是能看什么，能改什么，能连什么，全部提前限定，死 好。接下来到第三层策略裁决与审批网关。这里要解决一个问题， agent 已经提出动作了， harness 怎么判断到底让不让座？第一步是动作解析器，把这个请求拆成对象、动作范围、环境、风险这五个部分。比如他说我要删除某个东西， 那你就得知道删的是谁，删在哪，在什么环境里删，风险有多大。第二步，交给策略引擎，白名单优先，黑名单兜底。不同环境可以有不同策略，但最终都有 harness 统一执行。也就是说，策略不是模型说了算， 而是系统说了算。那遇到高危动作怎么办？比如删除外发布、暑提权，这些动作不能默认通过，而是必须进入审批闸门，要二次确认 或者人工签合。这个地方你可以理解成 harness 在 关键位置放了一个闸口，平时可以通行，但只要是危险动作，就一定要停下来，再往后还有实时熔断。这个也很重要，只要发现异常链路、异常频率、异常目标， 不管前面走到哪一步，马上终止，不继续执行。这个设计的意义就是，宁可少做一点，也不能把风险放大哦。然后看第四层安全执行环境。 很多人会问，前面都做了策略控制，那真执行的时候是不是还是有风险？有，而且非常有？所以 harness 不 能只管决定，还得管落地。落地怎么管？答案就是沙箱运行时， agent 即便要执行任务，也是在隔离环境里执行，不直接操作宿主机。 这个隔离特别关键，因为一旦执行，环境和宿主系统是连着的，危险动作就可能穿透边界哦。再往下是只读跟文件系统。这个设计很简单，但很有效，关键路径不可写，所以系统级删除这种操作天然失效。 你看这里不是靠提醒，而是靠物理约束。然后是临时凭证代理权限按次签发，短时有效范围受限，用完就失效。 这个地方特别适合讲厨房刀具所在安全柜里的比喻，刀在，但拿不到，权限有，但只给一小段时间一个小范围。最后是出战白名单。网络也不是想连哪就连哪，只能访问允许的目标，这样既防外联，也防数据外泄。好，那我们把最典型的危险命令拿出来， r m 杠 r f 斜杠这个格系统跑路的命令， 他在 harness 里到底是怎么失败的？第一，能力层先失败，因为 agent 拿到的不是任意删除整个系统的能力，他只有受限能力接口。第二，策略层直接拒绝，因为系统级删除跟路径删除递归破坏这类动作 本身就是禁止，向第三，审批层不会放行。这种破坏性动作默认必须额外授权，不能自动通过。第四，就算他侥幸走到运行时，执行环境也不绑定宿主跟目录。关键文件系统是只读的，而且他没有高权限身份。第五， 审计和融断会同步出发，危险请求会被留痕告警阻断，必要时直接终止绘画并回收凭证。所以你会发现， harness 不是 单点防御，它是多层防御，不是某一个环节很强，而是每个环节都在兜底。 就像你家门口不只是有一把锁，还有门禁、摄像头、报警器、管理员、应急开关，每一层都在降低风险。然后我们看第五层，可追责、可回放、可恢复。 这个层很多人容易忽略。先说全链路审计，他要记录谁发起谁批准，执行了什么，访问了什么，结果是什么，也就是说整个过程不能黑盒化。然后是执行回放，你可以把决策链和执行链完整重现，方便复盘，尤其适合做事故分析。 再就是回滚恢复，给可变更资源留后路，避免一次误操作造成永久损伤。最后是紧急停机，这个很直白，一键断开绘画、吊销凭证、冻结工具链，快速控制风险扩散。 最后我们回到这五个原则，基本上你讲完整张图以后，听众脑子里应该能留下这个结构。第一， agent 只提议不直接执行。第二，能力限于命令，先给安全能力，不给万能入口。第三，最小权限默认，不该给的绝对别给。第四，沙箱强隔离，让他碰不到核心资产。第五，审计可追责，让每一次越界尝试都能被看见。 所以总结一句话， harness 安全护栏的本质不是告诉 a 阵别乱来，而是把危险行为的成立条件一层层拆掉，不是给一个万能终端，而是只给白名单能力接口，不是相信模型会自律，而是用策略网关审批闸门运行时隔离一起兜底。 不是出事以后再补救，而是提前把宿主权限跟目录长期密，要任意外联这些路全锁死。最终要实现的不是尽量安全，而是让危险行为从不可接受变成不可到达。
68AI大模型鹏宇
09:58查看AI文稿AI文稿二零二六年 ai 圈最火的概念莫过于 harness engineering 了，但从二月份 open ai 发文到现在，我翻遍了全网的讲解，发现几乎都是在讲概念， 怎么落地，怎么实操，竟然没有人说。所以今天我就从原理到代码实践给大家讲明白 harness 是 什么。并且你听完后啊，可能会发现自己的智能体已经在往 harness 这个方向发展了。 先说一个你很有可能的误解，很多人看到 harness engineering， 第一反应就会把它和题日词工程还有上下文工程挂上关系。 这个理解不能说是错，但并不是 harness 的 本意。题日词工程解决的是你对模型说什么，指定写的有多精准，角色设的有多么的清晰。上下文工程解决的呢，是模型能看到什么，记忆怎么存，长，文档怎么切，历史怎么压缩。 而哈尼斯工程解决的是模型在什么环境里工作，去调用哪些工具，怎么调度，权限怎么控制，出了异常怎么兜底，三件事情，三个层面同步引进，不存在谁取代谁。就好像写程序，你需要好的算法，好的数据结构，好的内存管理，少了哪个，你的程序都跑不通。 那 harness 到底是什么最直接的公式啊？ agent 等于 model， 加上 harness， 模型是大脑， harness 是 它的工作环境。打个比方， java 代码是跑在 j b m 上面的， python 呢，是跑在解释器里面，模型呢是跑在 harness 上面， 那 harness 就 决定了模型能调用哪些工具，调用怎么被安排和调度，上下文快满了，怎么压缩用户没授权的操作，怎么拦截这些东西啊，模型自己不会负责，也不应该负责，这是基础设施该干的事。 还有一个很常见的误区，很多人啊，会把 longchain、 spring ai 这类框架直接当成 harness， 这是不对的。这些框架呢，是脚手架， 它帮你把工具调用、模型接入这些东西，封装好，让你少写很多的代码。但它本身不是 harness， 它只是让你更容易的去搭出一个 harness。 真正的 harness 呢，是跟着业务走的，不同场景长得完全不一样。拿两个极端的例子来对比， cloud code codex 这类 agent， 面向的是 c 端，用户，跑在操作系统上，工具呢，基本是文件的读写，终端命令，这些场景很开放。 而你自己做的业务 agent 呢，面向的可能是 b 端，跑在数据库和内部的服务上，场景是有边界的，对权限的控制和稳定性的要求完全不在一个量级。同一套模型，哈密斯不同，能干的事啊，和能信任的边界就完全不一样。那接下来我就从 cloud code 的 源码中带你了解什么是哈密斯。 我们先看一下 c c 的 主流程编排层，也就是 query engine 这个类，里面有一个叫 submit message 的 函数，所有你跟 c c 的 对话都是从这里进和出的。阅读这段代码后啊，你会发现，前面的三百多行代码全是在准备工作，没有任何大模型的调用， 那里面包含了环境的准备处理，用户的输入、落盘、系统出式化消息等操作。其中我挑选了两处最能体现 harvest 这个函数， 他把 kusu 啊包装了一层，做了一件事，每当一次工具的调用被拒绝，不管是用户手动拒的，不可拦截的，还是 classify 判定不安全的，这个包装啊，都会把记录压入一个叫 permission denies 的 数据库， 记录下来。哪个工具哪一次调用的 id 传了什么参数，那模型在整个执行过程中啊，使用者对此是无感的。那记录这些的意义是什么呢？为什么能体现出 harsh？ 其实这份记录是给 sdk 调用方用的，像审计 a 技能的行为调优，权限策略啊，都靠它。 每次任务跑完，你就有一份清单， agent 在 这次绘画里面总共碰壁了多少次？异常的点在哪里？如果某个工具被高频的拒绝，说明 agent 的 行为啊，和你的权限配置之间有异常，你得回来调。 但最关键的一点是啊，模型知道这次被拒绝，但不知道自己这次绘画总共被拒绝了多少次。而 harness 帮他统计了这份清单，并且汇总专门给外部系统用不进模型的上下文。所以 harness 不 只是在控制 agent， 他 同时也在观测 agent。 第二个是 record transcript 的 这个函数。这个啊，在模型调用之前，他做的事就先把你这条消息落盘注示解释了。为什么 如果说进程在 api 响应回来之前被强制终止，比如说机器断电，用户按了 stop， 那 绘画可以从这个断点恢复。如果等模型回来再存，中途断掉，那这条消息就丢了， resume 就 找不到记录了。 用户几乎感知不到这件事情正在发生，但他一直在保护用户。那这一点我相信很多大模型开发的同学都会这么去做，不可能傻傻的等到大模型的结果回来之后，再把用户的消息去进行持久化。所以这两个位置合起来说明一件事情，模型在开口之前， paris 已经在旁边做了很多用户看不见的事情。 接着我们看一下 cc 的 指定装配层。这边我要对比的是两处都在构建系统提示词这个函数里面。 第一处没错，就是这三行代码。在这个判断中，如果 override 存在函数，直接 return 后面所有的 prompt， 不 管你是在 cloud 的 md 里面写的规则，还是你定义的 agent 的 指令，全部都跳过一行都不跑。 那什么场景会触发这个呢？当 cloud code 被当成一个子 agent 嵌进自动化的流水线，副 agent 开这个子实体的时候，就会通过 override system prompt 给它指定一个完全受控的身份。 比如说你只做代码审查，只输出 jason， 那 cloud code 就 会把所有的默认配置全部架空，你可以认为是 sub agent 的 概念。 注意啊，这里的替换是什么力度？不是优先级更高，是其他的根本不跑。三行代码中，模型对自己是谁的认知完全被替换，这给刁永芳一个干净的白板，没有任何底层默认值泄露进来。 第二处， proactive 模式同样是 agent 的 定义，普通模式下， agent prompt 直接切换 default prompt 模型变成了个 agent。 但在 proactive 模式下，它是这样做的。 在这段代码中的注示中有说明， proactive 啊，不是换了一个人，而是给这个人增加了新的技能。同一个 agent 的 定义文件会有两种执行模式，模型的身份啊，完全不同，普通模式是换人， proactive 模式是加技能。当然了，这个决策也不会在你的 prompt 里面体现，而是 harness 自己帮你做的。 然后我们再看一下 c c 的 工具调度层。这边啊，我选了同一个文件中的两处代码。第一处，我们先看一下 is currency safe 这个函数， 在 c c 中啊，每个工具会自己声明并发安不安全，那 harness 则会调用这个函数来进行提问。那如果这个方法本身抛了异常，不管是什么原因，比如说解析 share 参数失败啊，工具里面有 bug 啊，那捕获了这个异常之后啊，就会直接 return false。 按照常规的软件工程来说，捕获异常我们会向上抛，抛到上层，进行统一的管理，但这边的报错，它并不会抛给上层，而是降级到串行。那为什么会这么做呢？ c c 认为啊，病发出错付出的代价，比如说数据损坏，文件冲突要远大于花一点时间进行串行。 harness 的 默认哲学是，不确定的时候选安全的那条路。 第二处， run to 函数里面对病发败局的处理，当一批工具都是病发安全的，它们是同时跑的，但是注意里面有个 map 结构， key 是 工具调用的 id， 工具跑完之后啊，它对执行环境的状态修改。 比如说我刚才写了哪个文件，但这个操作并不是立刻应用的，先是被压入这个 map， 等整个并发的半局完全完成之后，再按照顺序一个一个的把修改应用上去。 也就是说，工具的执行是并发的，但状态的更新是串行的，有顺序的。那听到这里，如果有开发同学应该会比较熟悉，其实跟我们平时使用的现成池差不多的原理。 所以说如果不这样做，两个并发工具同时改同一份上下文，谁厚写谁覆盖谁状态就乱了。这个问题啊，被 harness 在 基础设施层解决掉了，模型那边发出工具调用，收到结果，完全不需要关心这件事情。 接着我们再看一下上下文。治理层在 to use context 这个文件中有两个字段， set app stat 和 set app stat for tasks。 普通的 set app stat 在 sub agent 里面是一个空的操作，不做任何的事情，这是有意设计的。此 agent 不 应该直接改副 agent 的 全剧状态，否则嵌套会越深越乱。但是第二个字段就不一样，注示里面写得很清楚， 不管 agent 嵌套了多少层，它都能写到最外层的绘画状态，而且专门用于比单次绘画活的时间更长的东西，比如说 background， task， clean up， hook， session 级别的注册等等。 那实际的含义是什么呢？一个嵌套了三层的 sub agent， 可以 通过这个接口在最外层注册一个清理任务，在整个绘画结束时执行。这个能力啊，不在模型身上。在 harness 上第二处 agent id 字段，这个字段只有 sub agent 才会被赋值，主线称没有，这个字段是 undefined。 注示里面说，你可以在户客的逻辑里面这样判断，如果 agent 的 id 存在，说明这次工具调用来自某个子 agent， 如果不存在，说明是主线程。根据这个啊，你可以给子 agent 的 工具调用，增加额外的审批步骤，或者完全不同的权限规则， 同一个工具，主线程来的直接放行， seven agent 来的要多问一句，那这条逻辑不在模型里，也不在工具里，而是在 harness 里。 如果说你想对谁发出的调用有不同的应对方式，那不用改模型，也不用改工具，改的是 harness 对 不同调度来源的响应。 好了，关于源码，我们先分享到这，现在把四段源码串起来，你就能看到 harness 的 真实面貌。模型调用之前，有一层系统在为他准备好一切认知框架、工具、权限、调度策略。这些东西啊，不在提示词里，也不在上下文里，但没有它，提示词写的再好，上下文管的再精， a j 呢？还是跑不稳。 所以记住这一句，模型决定了 agent 的 上限，但 harness 决定了 agent 的 下限。最后我想说的是， ai 时代下，做好智能体往往不是选对了什么框架，而是你要把智能体想要成人的大脑去模仿，大脑会做什么事，哪些地方需要记下来，哪些地方可以忽略， 哪些地方需要较验，那又有哪些地方需要被约束？这些判断才是真正决定智能体上线和下线的关键。所以，正如我前几期视频所说的一样，产品思维和架构思维在智能体时代显得尤为重要。 ok， 那 以上就是本期关于 honeyse engineering 的 全部分享。不得不说啊，在 ai 浪潮下，保持清醒的认知最重要，不要人云亦云，我是布鲁，你的 ai 好 搭子，我们下期再见！
2372布鲁404
24:33查看AI文稿AI文稿呃，各位好，我是来自高德大模型平台的开发工程师，我叫王树新。然后大家可以看到，其实我今天分享的主题主要是围绕 harness 和 s d d， 然后我们是如何集于 coder 在 我们团队进行这个呃实践的。那呃， 其实这个在开始之前吧，我想先说一下，就是去年九月份，我当时呢受邀在云溪大会呃 koder 的 分论坛上，然后分享了我们团队在呃基于 koder 进行研发提效的这样的一些实践经验。 其实当时我们的分享都是基于像 propt， 然后上下文工程在技术方案的环节和研发环节进行的一些呃，这个提效，然后我们当时对外暴露的一个出码率是百分之五十三， 然后其实在当时我们能看到这个数字啊，它背后可能说对于 ai 在 编程这个方面会有巨大的潜力。 呃，我先回顾一下当时我在云集大会上分享的一些核心内容。首先呢，是在当时那个场景下，我们识别出了 ai coding 存在的三个主要的问题。 第一个就是自由发挥的问题， ai 胜任代码常常是种天马行空的啊，原因就是因为他业务理解不足，或者是说规范很缺失，然后你让他写一个功能，他可能给你三种不同的实现方式，每一种都能跑，但每一种都跟我们现有的架构是格格不入的。 第二个原因，第二个呢，就是这个效率低下的这个问题。我们听起来好像很矛盾， ai 我 们用了 ai 难道不应该是提效吗？为什么啊？我们这里边反而会说到这个效率低下的问题， 其实在实际的使用过程当中，如果我们的指令不够清晰，你会在多轮对话的过程当中呢，需要反复的去和 ai 进行拉扯，你说改一下，他改了，然后你说不对，还要再改，他又改了，经过这么来回几次，很多人就说还不如他自己写， 那第三呢，就是这个关键信息丢失的问题。我们在这种多轮对话过程当中， ai 呢，它常常会忘记之前的一些重要的约束，在任务的这种颗粒度非常大的时候啊，开头说的一些架构的要求，到后面它就完全忘记了。 所以针对这些问题，我们当时是使用 coder 进行了一些系统化的一些实践方案，比方说通过这种 reprieve memory 和 roles 来约束 ai 的 这个自由度， 然后通过这个提示词工程来改善它的效率问题，我们通过这种上线工程快速模式，避免一些关键信息的丢失， 那当时其实在分享，最后我还表达了对于 ai 编程的未来充满了期待。未来呢，开发者只需要去做定义需求验验证结果这样的事，像文档编码测试这种体力活，我们完全可以交给 ai 来干。 ai 呢，可以从一个生产工具转变为新的研发的基础设施，开发者呢，也能够从编码者转变为一个 ai 的 架构师，但 这是半年前的一个愿景。但其实这个半年多过去了，情况是什么样呢？刚才有一位 cto 啊，他说的这些我很有共情，因为我觉得我们当时暴露的数字是百分之五十三。 然后现在啊，我们经过很多的访谈，包括 pmo 的 一些数据告诉我们说，我们现在整个团队的出马率百分之八十到百分之九十都是由 ai 来生成的，并且都能采纳了。 但实际上其实我们会发现呢，即使呃我们的 ai 写了非常多代码，但是开发者的工作量并没有减少， 出码率提升了，但是整个项目的交付周期并没有明显的缩短。所以说呢，我们基于这样的一个现象，我们就不得不停下来认真思考一下这个背后的问题是什么。 所以为什么出码率的提升他没有带来真正的这个提效呢？那我其实呃花了很长时间去思考这个事情，然后并且团队做了大量的实践，最终我们是归纳了三个核心的原因。 第一个，研发是一个全链路的过程，它不仅仅是写代码，我们其实来看一个需求，从提出到上线，但这是我们在呃高德内部要经过产品的提需，然后缜严的去做对需求的审，然后方案的设计，开发代码的审，测试连条上线， 每一个环节都有沟通成本，都等待时间，都有可能犯错。其实在人月神话里边有一个这样的一个理论，叫做没有银弹，为什么没有银弹呢？就是因为软件开发过程，它其实不仅仅是编码， 更多的呢？他还要涉及到沟通、协助决策，你把编码环节优化了百分之五十，但是他其实整个的在整个链路当中编码可能只占百分之三十，那我们来看全链路的话，其实他整体提效就只有百分之十五。所以说我们呃 用 ai 在 生成代码的时候，可能还会再去引入更多的 code review 的 时间，更多的调试时间，然后更多的对话，更多的返工的时间。所以这让我意识到，如果说我们要真正提效的话，必须要打通从需求 p r d 的 生成到部署这样的一个全链路， 而不仅仅是优化一个单个的这个环节。所以啊，接下来我可能会跟大家去交流一下，就是怎么让 ai 啊跨越这种环节的边界，从需求到部署形成闭环。 第二个原因呢，就是存量的应用进行 web 抠定风险非常高。呃，其实刚才我听到同学们很多问题，还更多的是一个新的应用啊，从零到一的去实践，去生成。但其实在阿里内部，我们大多数的都是存量的大型的项目， 那对于这种存量的大型项目，我们用 web web 定这种方式呢？其实风险非常高。什么是 web 定？就是氛围编程，我们随口给 ai 几句提示词，然后让它几秒钟就生成几千行代码。 那这种方式呢？其实在新项目或者是一些小的脚本小需求上可能还行，但是在这种存量的应用当中，风险非常高。 存量应用的特点呢，就是有历史包袱，有隐性的依赖，还有很多的这种隐性的业务知识沉淀在代码里边。你让 ai 去氛围编程，那他可能给你一个呃，看起来很完美，但是和现有的系统完全不兼容的方案。更可怕的是这些问题他可能等到上线之后我们才会发现。 我们曾经就遇到过一个案例，就是说在我们用 ai 生成了一个代码，他修改了一个核心接口的这个参数的顺序，然后我们去跑单测，发现单测全通过了，然后上线之后 很多下游的服务就找过来告诉我们，下游服务啊，三个下游服务都哐哐的报错了，然后我们排查了一整天。其实这就让我们深刻意识到，在存量的应用当中， ai 的 去编程必须要从氛围走向规范， 必须要有明确的一个验收标准。那其实这个也正是我们去引入了 sdd 的 这样的一个原因。 sdd 呢，它其实核心思想就是说在 ai 去写代码之前，将人类的这种模糊的想法 转化为清晰的、没有歧义的这种结构化的规范，让 ai 呢能够在可控的这种轨道上去运行。 第三个原因就是大型项目复杂的这种轨道上去运行。第三个原因就是超出了 ai 单次的这种对话的能力边界。 我们曾经呃有这样的一个需求，就是它涉及到前后端，然后十几个模块的这种重构的任务，那不可能在一次对话里边就让 ai 去完成，因为 ai 的 上下文是窗口，是有限的，注意力呢，也可能分散， 所以说对于任务这么大的任务来说， ai 它在生成的过程当中可能顾此失彼。那我们其实看 这三个原因，它其实都指向了同一个结论，就是 ai 编程要想从个人技能转化为团队级的这种工程能力，必须要让它从氛围编程走向规范驱动工程治理的这种研发方式。 那明确了问题，所以我们就开始寻找解法。我们目标呢就是让 ai 不 仅在研发写代码这个环节去提效，更多的是要打通从需求的 p、 r、 d 到直接部署的全流程，然后我们就把这个视角放到了 s， d， d 和 harness 的 啊这个核心的思想上。 我这里快速的讲一下这个 s， d， d 和哈尼斯啊， s， d， d 呢，其实它的核心思想是很颠覆的，呃，最早其实在软件工程里边有 at d， d 的 这种思想，那 s， d， d 呢？其实呃，我理解它本质上呃这个思想是差不多的， 就是 s， d， d 呢，就是说规范不再是给人看的，而是结构化的，给 ai 来看的，能够让 agent 去精确理解和执行的这种意图的代码。 在传统开发当中呢，我们说 prd 或者设计文档，它更多的可能就是一个指导书，代码呢，才是呃真正的这种真理之源， 这会导致文档我们沉淀出了很多的文档，但是在这个迭代的过程当中啊，会经常的这种出现过期啊，和代码脱节这样的一个问题。而 sdd 呢，它颠覆了这样的一个结构，规范是唯一的这个真实的来源。 需求变更的时候，那我们开发者首先修改的是这个规范，然后让 ai 的 工具根据这个规范呢重新生成验证并更新这个底层代码 s， d， d。 它的工作流呢，主要就包括，呃四个阶段，我们能看到像第一阶段就是这个 specify， 就是 去做规范的定义， 开发者和 ai 去探讨，然后输出一份这个结构化的规范，定义好用户的故事，然后验收的标准，系统的一些约束，这就是一个原始的需求阶段。 之后呢，我们要开始制定计划， ai 呢，就会去像这个编辑器一样，把规范编一成详细的技术方案和这个任务的拆解的列表，这就是一个技术文档的呃这个阶段。 然后呢，第三步呢，就是 ai 智能去逐个地执行这个任务列表，然后自动地去生成高质量代码，它会去进入到这个软件开发的阶段。 最后呢就是呃 sdd 的 一个核心思想就是验证，它会根据这个规范自动化的去生成，测试、用力并执行，保证我们最终生成代码呢，能够和规范完全的契合。 那 sdd 其实它解决的是做什么的问题？那哈里斯其实它解决的是如何让 ai 能够可控的去做这样的一个问题。 harness， 其实这个词呢，它比较形象。呃，我们可以把这个大模型比作一匹野马啊， ai 大 模型它其实是拥有无穷的这个力量的， 但是呢，没有马具你根本骑不上去啊，甚至可能会被这匹野马给甩下来。 harness engineering 呢，它的核心的思想就是不是去改变这个呃模型本身的能力，而是给这个模型去设计一套精密的控制系统， 它包括这四个核心的支柱。首先呢就是这个上下文工程，不再是简单的刚才我们提到的 ig 啊解锁增强生成，而是通过这种结构化的信息的投喂，维护一个单一的事实来源，然后让 agent 它能够知道当前项目的目录结构，当前的执行计划是什么，以及呢哪些文档是最新的。 第二个就是哈尼斯，一个非常硬核的部分，就是这个架构的约束，通过这种物理的手段来强制 ai 去遵守规则，比方说我们规定 ui 层的代码绝对禁止去访问数据库层的这个呃，代码，那 ai 试图去违反这个架构分层的时候，代码呢，就无法通过这种语法的检查，在这个提交之前啊，就被拦截。 第三呢，就是这个反馈的回路和商管理，就是 ai 一定会犯错，那关键就在于我们如何去提前发现并修正，建立这样的一个呃，自动化的一个测试沙箱， 让 agent 去写代码，之后呢，自动地去跑测试，跑完测试我们发现测试失败了啊，把这个错误的日制给 agent， agent 呢去读这个错误日制，它进行自我的修正。呃，然后呢，之后呢，再不断地去重试，把这个代码给提交，同时呢，它会把这些人类去修复错误的这个经验 沉淀为这种可以服用的规则，保证呢 ai 它不会相同的错误犯两次。最后就是人类的监督。其实人类呢，从写代码的这样的一个角色就转变成了审核员和环境的一个设计师， 职责就是定义复杂的这个业务边界，然后处理那个百分之五 ai 没有办法去判断的一些复杂的业务逻辑，以及优化这个 harness 本身的一些规则。 那其实，呃，我们可以看到，从最早的，从去年我们一直在强调提十四工程，然后再到这个上下文工程，再到我们今天去提哈尼斯工程，其实它是一个范式的转移， 就是说我们其实是一直在思考我们怎么去和 ai 说话，然后到现在 ai 应该看到什么啊？最后再到今天就是 ai 如何在这种受控的环境下去运行。 那基于上述这两个思想呢，其实我们就开始在这个 coder 上进行了一个实践，接下来我先请大家看一段视频吧，这个视频是我最近用 coder 呃端到端的去完成了一个比较大的一个需求。 首先呢其实我们是把这个需求它会涉及到大概三个核心的项目，然后我会把它放到一个工作区里，之后会用这个 quest 的 这个模式，呃，然后这个 quest 里边它有一个 spec 驱动这样的一个能力，然后我们会把这个需求的 prd 贴到这个文本框当中， 然后当然如果说这个需求会涉及到一些这个多模态的一些图片啊，或者是呃 prd 里边会有一些图片，我们也可以直接粘啊粘贴给它，然后这个时候啊快速模式它就会开始启动这个任务， 它会不断地去探索这个需求的 prd， 然后仓代码仓库，然后一些知识库，这过程用了一个十倍的加速，大家可以快速看一下。 然后其实这个就是 spike 一个非常核心的一个能力，就是它分析完之后呢，它会让人工去澄清一些我们 prd 里边没有说清楚的一些问题， 之后，我们把这个问题澄清之后，它就会开始呃去做这个执行，然后它会生成一份呃完整的这个技术方案 啊，这个技术方案其实就有点类似于我们说 openspec 里边那个 design 点 md 的 这样的一个设计文档， 可以看一下它生成完成之后，其实它这个里边是包含比较详细的数据的模型，然后接口的规范， 然后最重要的是它最下边最下面是有这个 sdd 的 一个验收标准，就相当于是呃我们这个需求，最终呃如何让 agent 去自我验收这个他完成这个任务，他的这个验收的标准是什么？ 会包含这种详细的这个前后端的一个验收的标准。然后我们拿到了这份 spec 之后，我就会切换到 coder 的 一个专家团的这样的一个模式，把需求生成的这个 spec 文档呢给导入到这个 规划框里边，然后告诉他基于这份 spec 去进行呃这个开发。然后最后呢你要完成这个测试，并且帮我自动化的部署到我们的这个日常环境，而这也是因为我们现在这个生产环境的要求不能直接去做生产的上限，所以我们现在打通全流程是到日常 然后这个专家团模式，大家可以看到其实他会呃去委派啊，并行的去委派不同的这个子 agent， 他 开始比方说去做任务的调研，调研完成之后他会制定这个实施的呃这个计划，然后之后会有前后端的这个工程师的 agent 来编辑这个代码， 这个中间过程就不给大家看了。然后到部署的时候，阿里内部其实它后端是用的那个 a one 平台，前端是用的 o two， 然后这个里边我们会把它这个官方平台提供的 m c p 工具给接入进来，然后这个 agent 呢，它就会自动的去调这 m c p， 自动去打通这样的一个部署的全流程， 然后它会调起一个运维的 agent， 帮我们创建新的迭代，把代码推送到远程的分支， 然后它部署完成会给我们一个部署的一个详情的链接，我们点开这个链接之后，其实就能看到它，呃，在触发了一个这个部署的一个流水线啊，然后部署完成，其实整个的端到端流流程就被打通了啊， 那视频就看到这里，其实我们大家可以看到啊，就是整个的过程，从需求的 p、 r、 d 的 开始，到 spec 的 生成， 再到任务的拆解，到呃代码的生成、测试、验证，到最终的部署，其实整个的过程是全自动化的。然后开发者呢，在这个过程当中其实就扮演了一个需求的澄清者，最终结果的验证者，而不是再去做实际的操作。 接下来我会详细的去拆解一下这个整个的实践过程，那其实整个实践的里边最重要的核心的基础就是这个知识库，我们现在呢，其实经过实践来看的话，知识库更多的是用这种三层的结构来组织我们内部的知识。 首先呢是这个项目层，项目层它主要就包括我们当前的一些核心应用的项目概述啊，技术选型，这个是 ai 去理解这个上下文的一个基础。然后根据这种， 呃，我们后面还会介绍到啊，我们会根据按需加载的这个思想，维护一个顶层的 readme 的 这样的一个文件，作为 code 的 一个单一的事实来源。 然后之后就是技术层，技术层主要是一些通用的技术知识，编码的一些规范啊，包括还有就是一些三方库的文档，最佳的一些实践，呃一些问题的解决方案等等，然后这些知识可以跨项目附用的。 呃，之后呢就是这个资产层，资产层呢主要就是一些可附用的代码的片段组建，包括一些历史需求的 prd 基础方案，还有一些规党的测试 case， 这些是团队多年积累的一些这个最底层的砖块，然后 ai 就 可以利用它去构建新的功能。 然后在实际的项目当中，我们文档是就是按照刚才看到的这三层的这个结构去进行这个分层的设计的。然后其实我们用到了一个 skill 里面的一个思想就是按需加载，我们可以看到在 呃最下边我们是有一个 readme 的 这样一个文件，我们会在这个 readme 里边呢把所有的文档做一个锁引，然后这种锁引的机制呢，就能够保证我们知识的一个结构化的组织，然后同时也能够让 a 阵的去做这种按需的。呃，加载，按需的去获取， 那这个里边其实提到知识的这个体系，肯定还不能离开这个 memory 的 这个概念，其实 memory 呢是 coder 的 一个内置的一个能力。呃，它就是把我们的一些这个知识做结构化的组织和存储。嗯， 然后执行的这个过程，其实我们有了知识库之后，下一步就开始处理这个需求的 p r d。 那 我们其实是使用的呃 design point markdown 的 这样的一个文档， 那这个过程其实不是自动化的，而是需要人工干预，就是我们现在经常提的 human in the loop， 其实为什么还需要人工干预呢？就是因为当前的这个需求文档当中其实是有很多隐性知识的， 很多产品经理提了一个 p r d 啊，它里边会有很多的知识会认为是研发同学理所当然的啊，应该知道的。但其实是需要我们使用 ai 开发的过程当中，需要 ai 去澄给 ai 澄清的。 比方说我们想做一个用户登录的这样的一个功能，那它背后其实啊需要去告诉 ai 啊支持哪些登录方式， 然后要是否要记住这个登录态密码的强度是怎么设置的，登录失败怎么处理等等。那么通过 spec 的 这种模式呢， ai 就 会主动主动地去提问，然后引导开发者去澄清这些隐性的知识，逐步地去补齐一个完整的这个呃 spec。 那有了这个 spike 之后呢， ai 其实就相当于有了一个明确的呃施工的图纸，就不再是一种氛围编程的模式 之后呢，就是进入到这个执行的阶段，执行阶段我们为什么使用 code 的 这个专家团的这样的一个模式呢？就是因为我们其实呃在思考我们当前所有的人类的这个组织，组织的呃设计我们分成了有前端工程师、测试工程师、后端工程师等等这样的一个角色。 而专家团的这个核心思想呢，其实也是不同的任务交给不同角色的这个 agent 来完成，然后像一个真实的这个开发团队一样， 那 ai 就 会根据这个 spike 去生成具体的这个执行的计划，然后把一个大型的任务拆解成一些可管理的小任务，然后每一个小任务呢，都有明确的这个输入的输入和输出，包括验收标准。然后之后呢，再把这些任务分配给不同角色的 agent 来执行， 然后这个里边像他的这个专接团，呃专家团呢？其实是内置了很多 a 阵的，比方说调研的专家、编码专家、 q a 评审，还有浏览器专家， 然后这个里边其实除了专家，我们说一下呃，用户在使用这些专家的时候，呃其实不仅仅是一个观察者，更多的是我们也能够参与进去。 比方说在专家团他在执行的过程当中，我们发现有一些问题，我们可以随时地去介入，然后和这个专家团有一个 leader 的 这样的一个角色，跟他去让他去调整任务的方向，或者是取消不再需要的这样的呃一些任务。那 基于这样的话，其实我们角色就变了，就不再是这个一个观察者或者是一个执行者，而是能够和 leader 去澄清意图，对齐方向，审核计划、验收结果，就像我们带了一个有经验的这样的一个研发小组一样。 然后之后就是到了这个部署阶段，其实我们是打通了通过这种 m c p， 打通了整个的这个呃阿里的内部的这个 a one 的 呃 c i c d 的 平台，然后我们通过这种 m c p 可以 让粤维的 agent 帮我们去触发 c i c d 的 流水线，执行部署的脚本，然后去看部署的状态，查询一些这个部署的异常，然后帮我们把这些异常给处理掉。那其实这样的话就相当于把整个的从需求的 p r d 到部署全流程就打通了。 然后这个里面其实也可以通过一些 skills 的 方式去扩展。比方说其实我们在真正的实践过程当中，我们会发现的除了工程代码啊，我们还要去操作一些底层的数据库，那么可以通过这个呃数据库查呃操作的这个 skills， 直接的让 ai 帮我们查询修改这个数据库，这样的话其实整个的呃端到端的开发，然后测试验证，这样的流程就完全的可以自动化掉。 最后呢就是回顾一下今天的分享吧，就是我们从我从最早的这个云溪大会出发，然后去发现了出马率提升，但是提效不明显的这样的一个问题，然后分析了三个核心的原因，并且基于这些原因呢给出了一些具体的解法。 那其实我们能够看到整个的这个过程，其实我们是实现了从这个呃氛围编程到规范驱动工程治理这样的一个范式的转变，然后我们通过种 harness 呃去让 ai 在 约束下变成了一个可靠的工具。 那在未来呢，我认为我们其实有三个方向可以去探索，首先就是更智能的这个 spike 的 生成，其实当前 spike 生成还需要更多的人类的去干预，呃，我们其实希希望呢这个未来能通过更智能的对话的方式啊去做需求的澄清。 第二呢就是更强大的这种 agent teams， 我 们当前这 agent teams 的 协助模式，呃还可以去更多的啊去探索，比方说一些更复杂的一些场景。 然后还有就是最底层的这个基础就是知识管理，我们如何去做整个知识库的啊？这个体系如何去构建？然后知识如何去更新，如何去复用？其实这些东西我觉得我们都可以在未来去呃实践，去探索。那以上就是我要分享的全部内容了，谢谢大家。
1.1万Qoder
