Harness企业部署教程
粉丝4.0万获赞20.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 者，那这个时候我们该怎么评估这个流程能否上线呢？这个流程上线了之后又该怎么办呢？下一期我们来聊一下，记得点个关注哦，我们下次见。
331AI练习屋
00:55查看AI文稿AI文稿很多老板为什么不敢把 agent 接入真实业务？因为他们怕大模型发神经，瞎操作。现在很多 agent 都在追求全自动自主决策，但是在企业级系统里，底线不是模型聪明听话，而是模型不能犯错。很多兄弟在刚接触 agent 的 时候，都会试图从 prompt 和 context 下手，反复叮嘱大模型要小心，三思而后行。 其实这根本没用。举个例子，给 hr agent 的 指令是，候选人面试通过发 offer， 大 模型如果认为自己判断没有问题，就直接去发了。但直属 lee 的 没确认，法务没签字，薪资还没定稿，这份 offer 发出去，公司会很被动。来看 hans 是 怎么做的，在模型和执行器之间加一道硬拦截，只要 agent 想发邮件， hans 立刻把任务挂起，等你来确认。如果你不确认，这份邮件绝对发不出， 我们点 n 取消。哈尼斯会把拒绝原因回传给大模型。模型知道自己被拦住了，就停下来认个错，把每一个高危动作的最终确认权留在自己手里。这是哈尼斯的核心，你学会了吗？
191Alex的AI进化论
06:23查看AI文稿AI文稿探索型的工作会污染上下文，随着 agent 越来越有用，每多一样新的东西，系统的提示就会放大一倍。上下文窗口的填满是不可避免的， 我们来设想一个场景，你让 agent 检查账目里面用了什么测试的光卡。为了回答这个问题，他可能要读五个配置文件，每一个文件有几百行，这些文件的内容会留在消息的历史之中，永久地占据上下文空间。但实际上，这个问题只需要一个词来回答， pytest， 这就是上下文污染的问题。为了完成一个子任务呢，积累了大量对于主任务的无用的信息，所以就引入了我们第四节课程的概念，子智能体，让子智能体拥有干净的上下文，然后去做干净的事情。 子智能体叫 sub agent， 是 一个独立的 agent 的 实力，它有自己全新的消息的历史，那做完一件事情，把结论告诉副 agent， 然后整个历史直接去丢弃。 那副 agent 和子 agent 到底是一个什么样的关系呢？它其实特别像公司里面，比如说主管是副 agent， 它负责整个任务，把具体的调查的工作分配给专员，也就是子智能体。那专员其实是在独立工作的，得出结论之后，只要把结论汇报给主管就可以了，它不需要把所 所有的工作过程的细节都摊在主管的办公室里面，那主管的办公桌，也就是上下文是保持整洁的。而子智能体呢，他可能执行了三十次的工具调用，读了大量的文件。但是对于负 a 症特来说，他收到的只是一句简短的摘药，这就是用计算代价换上下文清洁度的一个权衡， 而且往往是非常值得的。那第四节课子智能体解决了探索性的工作污染上下文的问题，让子智能体去干脏活累活，主 a 症，拿结论保持整体的清洁。但是随 一个 agent 才越来越有用，那另一个问题就是，你希望它懂得东西越来越多，但是每多一样新的东西，系统的提示就会放大一倍。那我们现在来到第五节按需知识，也就是技能加载 skill。 那 一个全能的 agent， 它可能要懂 get 的 工作流，以及代码的审查的规范，或者是测试的最佳时间，以及项目特定的一些约定等等。但如果把这些全部的都塞到我们的系统提示词里面，会消耗大量的 token， 而且大部分内容跟当前的任务是毫无关系的。 假设我们每一个技能或者是每一个功能要两千个 token， 那 有十个技能的话，那就是有两万个 token。 而这些内容在模型处理每一次请求的时候，它都需要重新计算一遍。所以这里设计了一个很好的技能加载机制。 按需加载什么意思呢？就是每次给 ai 发请求的时候，不是把所有技能的所有信息都给 ai， 而是让它根据任务的需求先判断是否需要某个技能，确认之后再去实时读取这个技能的详细说明。技能的加载机制我们分成两层， 第一层，系统提示始终是存在的。系统提示呢，是在对话开始之前就给 ai 的 一段角色设定和行为的规则，你可以把它理解为上岗的培训资料。 在 ai 开始工作之前，你要告诉他你是谁，你能做什么？你应该怎么做？那系统提示呢？它会占用上下文窗口的空间，而且是从第一条消息开始就存在的，永远占据着那块位置。 所以系统提示里面放的东西要非常的精挑细选，会只放技能的名称和简介，大约每个技能有一百个头看。那第二层呢，是工具的调用结果，也就是叫按需加载， 当模型决定需要某个技能的时候，才去调用这个技能，完整的内容才会出现在上下文窗口之中。这是一种很聪明的设计，也是模型知道有哪些工具同时呢，在需要的时候 才打开。那这一套技能加载流程，把知识预加载变成了按需加载，也就是对于上下文的起点来说，它更干净了。但是呢，这个流程也会有一个问题，你会发现所有的优化，比如说此智能体技能加载专用工具，都只是在延续一个根本性的问题的到来， 就是上下文窗口的填满是不可避免的，比如说让他读一个一千行的文件就要四千个 token， 跑一条命令可能就反悔几百行的日制，那做一个稍微复杂的任务，二三十四的工具的调用，轻松就会超过十万 token。 这是物理限制，不是设计的缺陷。 所以我们需要来到第六节课上下文压缩，也就是绕开记忆上线的工程解决方案。 我们刚才提到，上下文最终还是会被耗尽的，无论你怎么设计，随着 hr 工作的时间增长，消息历史会越来越长，这是一个无法回避的物理限制， 现在呢，处理它的方式不是说假装它不存在，而是设计了三层的压缩机制。这个压缩机制也是我认为 cloud code 跟其他的编程工具来说整体效果更好的地方。我们看第一层微压缩，也就是每轮禁默执行， 每一次大模型调用之前，都把三轮以前的工具返回，结果替换成一行占位符。这样做的好处是把原来几 千 token 的 文件内容变成了一行五个词，而且模型还能够看到它做过什么，但是呢，就不再去重复处理那些文件的具体的内容。这一层压缩本质上是无感的， agent 其实也并不知道发生了什么，但是它确实是在持续的节省着空间。接着我们进入到第二层自动压缩， 当 token 超域值时会触发，也就是当 token 数量超过设定的域值的时候，系统会把完整的对话历史保存到 磁盘，防止信息真正的丢失。然后呢，让另外一个大模型把这一段历史摘要成一段简短的文字，接着把这一段摘要替换为全部的历史，然后重新开始。这相当于给 a 层一个记忆的摘要，他知道发生过什么，但是他不再记住每一个细节。第三层主动压缩， 就是模型按需调用，那模型可以自己根据 compact 工具，在感觉上下文快要满之前，主动去触发这个压缩，在 cloud code 里面执行的时候，直接斜杠 compact 就 可以去操作。这里有一个提示啊，这三层压缩都是有代价的， 因为信息会损失。压缩完之后， a 证他可能不记得某一个细节，可能会忘记自己做过什么，这个本质上也不是一个 bug， 而是权衡的结果。一个设计良好的 a 证，他会把关键的状态写到磁盘上，包括任务的文件代码，而不是说去依赖上下文的记忆。 第六节课的上下文压缩让 a 证能够持续的工作了，但是呢，压缩本质上是一种选择性的遗忘，它保留了摘药，但丢失了细节。 这里就带来了一个新的问题，如果目标本身也在上下纹理压缩之后， agent 可能就忘记了他的目标，也就是他连他自己在做什么都不清楚了。那我们应该怎么解决呢？现在让我们来到第七节，让 agent 记住要做什么。
114江江AI一线
01:20查看AI文稿AI文稿很多团队一上来就想做完整平台，但第一版 agent 最怕的不是能力少，而是边界不清。原文强调的是 start simple scale intelligently， 简单系统更便宜，更容易调试，也更容易知道下一步该扩展哪里。 single agent 的 核心不是一个聊天入口，而是一个 agent， 围绕明确目标、观察计划、调用工具，再根据结果继续推进。窄任务不是降低价值，而是让输入工具、输出和成功标准都能被检查。 没有边界， agent 的 失败也很难定位。原文提醒，在跳到 multi agent 之前，先看一个 single agent 加上领域 skills 能不能解决问题。 skill 是 模块化能力包，不是另一个 agent。 第一版 agent 不 一定要用最强模型处理所有步骤，把高价值判断留给强模型，把固定动作交给工具或便宜模型。 如果不知道 agent 是 否真的节省时间，减少错误、提高转化，就不要急着扩展成多智能体，先把指标和日制打通。第二集的结论是，先做一个窄而稳的 agent， 用真实反馈决定要加 skill、 加工具，还是以后再加多智能体。
2AI老兵
06:04查看AI文稿AI文稿其实我们大家可以看到啊，就是整个的过程，从需求的 p、 r、 d 的 开始，到 spec 的 生成，再到任务的拆解，到呃代码的生成、测试验证到最终的部署，其实整个的过程是全自动化的，然后 开发者呢，在这个过程当中其实就扮演了一个需求的澄清者，最终结果的验证者，而不是再去做实际的操作。 接下来我会详细的去拆解一下这个整个的实践过程，那其实整个实践的里边最重要的核心的基础就是这个知识库，我们现在呢，其实经过实践来看的话，知识库更多的是用这种三层的结构来组织我们内部的知识。 首先呢是这个项目层，项目层它主要就包括我们当前的一些核心应用的项目概述啊，技术选型，这个是 ai 去理解这个上下文的一个基础。然后根据这种， 呃，我们后面还会介绍到啊，我们会根据按需加载的这个思想，维护一个顶层的 readme 的 这样的一个文件，作为扣字的一个单一的事实来源。 然后之后就是技术层，技术层主要是一些通用的技术知识编码的一些规范啊，包括还有就是一些三方库的文档，最佳的一些实践，呃一些问题的解决方案等等，然后这些知识可以跨项目附用的。 呃，之后呢就是这个资产层，资产层呢主要就是一些可附用的代码的片段组建，包括一些历史需求的 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 其实就相当于有了一个明确的呃施工的图纸，就不再是一种氛围编程的模式。 之后呢，就是进入到这个执行的阶段。执行阶段我们为什么使用 coder 的 这个专家团的这样的一个模式呢？就是因为我们其实在思考我们当前所有的人类的这个组织， 组织的呃设计我们分成了有前端工程师、测试工程师，呃后端工程师等等这样的一个角色。而专家团的这个核心思想呢，其实也是不同的任务交给不同角色的这个 agent 来完成，然后像一个真实的这个开发团队一样， 那 ai 就 会根据这个 spike 去生成具体的这个执行的计划，然后把一个大型的任务拆解成一些可管理的小任务，然后每一个小任务呢，都有明确的这个输入的输入和输出，包括验收标准。然后之后呢，再把这些任务分配给不同角色的 agent 来执行， 然后这个里边像它的这个专接呃专家团呢，其实是内置了很多 agent， 比方说调研的专家、编码专家、 q a 评审，还有浏览器专家。 然后这个里边其实除了专家，我们说一下呃用户在使用这些专家的时候，呃其实不仅仅是一个观察者，更多的是我们也能够参与进去。 比方说在专家团，他在执行的过程当中，我们发现有一些问题，我们可以随时的去介入，然后和这个专家团有一个 leader 的 这样的一个角色，跟他去让他去调整任务的方向，或者是取消不再需要的这样的呃一些任务。那 基于这样的话，其实我们角色就变了，就不再是这个一个观察者或者是一个执行者，而是能够和 leader 去澄清意图，对齐方向，审核计划，验收结果，就像我们带了一个有经验的这样的一个研发小组一样。 然后之后就是到了这个部署阶段，其实我们是打通了通过这种 m c p， 打通了整个的这个呃阿里的内部的这个 a 一 的 呃 c i c d 的 平台。然后我们通过这种 m c p 可以 让粤维的 agent 帮我们去触发 c i c d 的 流水线执行部署的脚本，然后去看部署的状态，查询一些这个部署的异常，然后帮我们把这些异常给处理掉。那其实这样的话就相当于把整个的从需求的 p r d 到部署全流程就打通了。 然后这个里边其实也可以通过一些 skills 的 方式去扩展。比方说其实我们在真正的实践过程当中，我们会发现的除了工程代码啊，我们还要去操作一些底层的数据库，那么可以通过这个呃数据库查呃操作的这个 skills， 直接的让 ai 帮我们查询修改这个数据库，这样的话其实整个的呃端到端的开发，然后测试验证，这样的流程就完全的可以自动化掉。
254Qoder_ai
05:52查看AI文稿AI文稿大家好，欢迎来到本期视频，这一期我们会深入理解 expert ai 提供的 harness 工程。在正式讲解之前，我们先看另一款产品。 在二零二六年四月， astonropica 推出了面向企业的产品 cloud manage agents。 这个产品提供了一套托管运行方案， 把工具执行、沙箱、状态、 memory 和权限治理等封装起来，让企业把开放式任务交给云端 agent， 直接产出代码、报告表格或业务结果。 它的目标是为企业降低 agent 生产落地的工程门槛，让团队更快把 agent 接入真实业务，并稳定产出可追踪的结果。 这是 antropic 官方给出的架构图。 harness 是 围绕 cloud 的 agent loop， 负责规划工具、调用上下文，管理错误恢复和结果迭代。 tools 是 agent 连接外部能力的接口，包括文件读写、代码执行、网页访问、 m c p server 和业务系统调用。 sandbox 为工具执行提供隔离环境，让 agent 可以 安全运行命令处理文件和访问受控资源。 session 承载一次长时程任务的状态、事件和输出，使任务可以一步运行，断点恢复并持续追踪。 workstation 负责把模型、工具、沙箱、 memory、 权限和事件流编排起来，形成可托管、可观测、可审计的生产运行层。 但 managed agents 最大的问题也正来自它的封闭式托管，企业把最关键的控制权交给了外部平台。第一个问题， harness 黑盒化。如果这一层藏在 interfictive api 后面，企业就只能使用结果，很难检查和改造 agent 本身。 第二个问题，记忆锁定。真正的锁定不只是模型，还有记忆。记忆包括历史对话、长期记忆等，但企业却无法管理和使用这些记忆。 第三个问题，模型选择受限。 managed agents 只能使用 twalt 模型。第四个问题，可观测性边界。企业只能看到平台愿意暴露的事件，很难做自己的审计、复盘、评估和合规检查。 而 expert 平台天然就是为企业打造的智能体搭建平台，平台部署在企业自己的环境里，以后所有资源都可以进入企业自己的控制边界。对于 harness 黑盒问题，企业能够在 expert 平台中根据自己不同的业务需求搭建和管理自己的智能体。 对于记忆锁定问题， expert 平台会把记忆信息、知识库、日制信息等资源都进行持久化存储，这些资源跟随企业部署环境存在，方便企业随时审查和管理。 对于模型选择受限问题， expert 平台支持选择不同模型，企业完全可以根据业务复杂度选择合适的模型供应商。 对于可观测性问题， expert 平台没有做任何限制，企业可以根据自己的需求审计或检查历史日制信息，也可以追踪智能体的运行过程，评估智能体效果。 所以， expert 平台不仅提供了 harness 工程，更是把这套强大的能力交给企业自己的安全管理。 这是 expert 平台中的 harness 工程架构，架构中心是 expert 的 专家，每一个专家内部都包含两层核心能力， l l m 和 harness 大 模型负责推理和行动， harness 负责控制。 在执行层提供沙箱机制，沙箱具备隔离的文件系统和 best 环境，让专家可以安全地读写文件、运行命令和处理任务产物。 在能力扩展层，提供工具和 m c p 工具，它们把外部系统、业务接口和专业工具封装成标准能力，供专家按需调用。 在运行增强层，提供各种中间件、短期记忆、长期记忆、技能机制等能力都通过中间件进入专家运行过程。这样一套 harness 架构为企业提供了一整个基础设施，企业能够方便地搭建、部署和管理智能体。 接下来介绍 smart 平台的沙箱机制。第一层是智能体，智能体本身不直接操作 docker， 而是通过两类工具进入沙箱 文件工具和 sandbox shell。 第二层是 docker sandbox back down， 它提供统一的沙箱能力，包括文件读写、命令执行和服务代理。第三层 docker sandbox private， 它对 docker 资源进行管理，负责创建和附用容器，并管理镜像、网络圈以及容器生命周期。所以 spark 沙箱机制的核心是三层隔离。 智能体指调用标准工具、中间件、统一拦截和路由。 private 统一管理 docker 运行环境，这样可以避免智能体直接接触底层 docker 资源。 还有一些细节，一、 cospart 平台的智能体并不运行在沙箱环境中，两者解口后即使沙箱异常也不会影响智能体本身。二、 spurt 平台的沙箱机制对沙箱文件路径和宿主机路径做了映射，即使沙箱异常，所有文件依然存在，重启后仍可正常运行。三、 crypto 对 文件路径做了多租户隔离，从而保证企业中不同组织、不同员工之间的安全隔离。 至此， expert 平台的沙箱机制就介绍完了下一个视频我们会继续讲解工具中间件、技能机制等内容。同时我们会用一个 dan agent 加 harness 来制作一份 ppt 作为具体案例。
30XpertAI
04:24查看AI文稿AI文稿如果目标本身也在上下文里压缩之后， agent 可能就忘记了他的目标。 agent 的 循环是单线成主色的，意味着每一个操作它必须等待着上一个操作完成才能继续。 我们来对比看一下在内层里面的清单和在词盘上的任务图。第三节课里面提到， to do right 是 内存里面的清单，也就是上下文一压缩，清单就没了。 现实中的大任务往往需要去跨越多个绘画，比如说我今天做一部分，明天再继续，甚至可能中间暂停，然后再过几天再回来，整体的绘画历史早就消失了。那我们靠什么来指导做到下一步了？以及下一步该做什么呢？对于跨越多个绘画的长期目标，我们需要更可靠的东西。 我们来看一下内存和显卡的对比。内存的 memory 是 计算机运行时临时的存储程序，关了就没了，而词 盘的持久记忆文件写进去关机重启也是存在的，就像你电脑上的文档，不会主动去删除，而是一直存在。这里面一个非常关键的 agent 系统设计的核心原则是，任何很 重要的状态都要写在磁盘上，而不要存在内存或者对话历史之中。这种持久化的任务系统会把每一个任务保存成一个独立的推送的文件。那这个任务图能回答三个关键的问题，第一，什么可以做状态是判定且没有任何前置依赖的任务。 第二，什么会被卡住，也就是在等别人完成的任务。第三，什么做完了，也就是 completed 的 任务完成的时候，会自动解锁后续的任务。无论是上下文怎么样去压缩，绘画怎么样重启，任务图都在磁盘上安全的保存着，绘画记忆是很容易丢失的，但是磁盘的状态是 十九的，这是 agent 系统设计的一个非常黄金的法则。四零七的十九划任务的系统解决了跨会议记录目标的问题，也就是任务状态存在词盘上，无论规划怎么重启都能找到。那现在 agent 能技术做到哪了，也能一步步地推进任务了。这里又出现了下一个教育的平， 也就是 ag 的 循环，是单线成堵塞的，意味着每一个操作他必须等待着上一个操作完成才能继续。所以接下来我们要进入第八个板块的学习，叫并行执行，核心目标是不让慢的任务拖累整体目标。 我们知道有一些任务或是有一些命令，他是需要几分钟才能完成的，如果 agent 他 只能同步去等待的话，那等命令跑完才继续，那这一段时间其实是被浪费掉的。那我们还会看到一些更常见的场景啊，就比如说用户他跟你说要先装依赖，顺便再写一个配置文件， 顺序来的话，简单的配置文件写作要等依赖完成。但其实这根本是没有必要的。所以方案是说后台任务让慢操作不阻赛主循环，也就是后台任务机制用独立的线程来运行，让主 a 政策的循环继续在工作。所以当后台命令完成的时候， 结果通过一个通知的队列返回。这里又有一个新的概念，什么是线程？那线程是计算机并发执行任务的一个方式， 可以把它理解为同时开了两个工人，比如说主县城是 agent 的 大佬继续推进主任务，那后台县城是有一个助手，专门去等待一些慢操作完成。当助手完成了，他把结果放回一个通知的盒子里，大脑在下一次 休闲的时候去提取它，意味着这里有两个工人在同时干活，一个人排队等着去干活，要快很多。我们来看一下刚才我们提到的整个流程。第一，主县城是 agent 继续工作。第二，每一轮的大模型调用之前检查通知队列。第三，后台县城 它有命令在运行。第四，完成结果后，把结果推到通知队列里面。整个设计的精妙之处就在于循环，始终保持着单线程，只有一些后台的操作被并行化，所以 agent 的 推理是顺序的，但是等待外部命令的时间被充分利用。到了 这一个章节，也就是后台任务让单个 agent 可以 并行处理，多个，耗时的操作效率有了一个明显的提升。但这里面呢，它又有一个非常根本性的上限，因为单个 agent 的 上下文窗口是固定的，当需要同时推进多个独立的大任务的时候， 比如同时开发一个新的认证的板块，重构数据库或者优化前端的性能。单个 agent 要在这些任务之中来回切换，每一个任务的上下文都会相互污染，没有一个任务能够得到相对清洁的思考空间。而且在第四节子 agent 里面也讲过，虽然有干净的上下文，但是它是一次性的深层干活返回，炸药销亡，没有身份，没有持续性，无法接收新的任务，无法主动汇报进展，所以接下来要进入第九个板块，多智能体团队，从一个人到一群人。
116江江AI一线
08:58查看AI文稿AI文稿看这段代码，这是 ai 刚刚写的权限管理模块四张表的建表语句，四个数据对象，六个试图对象，三个业务接口加实线，三个控制器缓存层对象转换器，数据权限拦截器，还有单元测试，全部符合企业级规范，可以直接跑。 我是怎么做到的？十步配置，今天全拆给你看。 百分之九十的人让 ai 写权限模块，写出来的东西，角色写死在代码里，菜单没有层级数据权限压根没做。 上线后老板问为什么销售能看到全公司数据，你才发现来不及了。不是 ai 写不了权限管理，是你没给他看过生产级的权限系统长什么样。我把今天这套完整的权限管理配置全部打包好了， 十步配置，六份规则，二个生成器，安全检查脚本全放在粉丝群里了，进群直接拿链接在评论区置顶，给你看个真实对比。没配规则的时候，角色判断写死在代码里，没有数据权限，谁都能看全公司数据，每次查库叫验，没有缓存菜单全是平铺霉，层级 删角色望删关联表，幽灵权限到处飘。配好之后呢？标准的角色权限模型，权限标识注解式校验，五种数据权限范围自动拦截， 三级缓存命中率超过百分之九十九。菜单支持目录菜单按钮三级结构，删除时自动即联清理。核心区别就一句话，从能登录就能看所有页面， 到按钮级权限控制，加行级数据隔离，按钮级权限覆盖率百分之百，缓存命中率超过百分之九十九。极连清理全自动配置前后就是这个差距， 和系列二的认证授权一样，权限管理也是十步，因为权限是系统的命脉，每一层防护都不能少。第一步，项目首特定方向。第二步，六份规则管架构安全表设计接口，数据权限测试。 第三步，两个生成器一键出代码，再加上安全钩子流程测试脚本代码模板炼录解析最佳实践清单，权限白名单架构图，我们一步步来。第一步，项目手册告诉 ai， 这是一个权限管理项目，先在项目跟目录创建。项目手册核心要写清楚三件事， 第一是架构定位，经典的用户角色菜单，三层模型菜单支持目录菜单按钮，三级结构，数据权限绑定在角色上，支持五种范围。 第二是包结构，五层架构控制器，业务层、数据访问层分成数据库操作和缓存两块转换器，试图对象和数据对象严格分离。 第三是命名规范，数据对象用什么后缀，试图对象待用途，缓存层怎么命名，错误码段用哪个范围全部写清楚，有个坑要强调，包结构是地基文件放错包，后面所有规则全部失效。第二步，规则文件，这次的重点在安全红线和数据权限， 六份规则里最核心的就是安全红线，七条绝对禁止，违反了直接不通过审查。硬编码角色判断必须用全线标识，前端做了校验，后端不做，前端校验可以绕过，后端必须再校验一次。普通角色修改删除，超级管理员禁止越权操作，内置角色被删除， 系统类型的角色不可删菜单权限标识重复必须全局为一，数据权限被绕过，所有列表查询必须经过数据范围过滤，日制打印完整权限列表数据量大，还有泄露风险。 再看七条必须实现的，超级管理员直接放行。角色禁用后权限立即失效。要清缓存菜单删除角色删除、用户删除都要即联。清理关联表权限变更菜单时要校验菜单存在且起用。再看表设计和数据权限。 四张核心表，角色表，存角色名、角色标识状态类型，还有数据范围和数据范围。指定部门菜单表是全局共享的，存菜单名、权限标识菜单类型分目录菜单、按钮三种。还有副级菜单，用来构建层级 角色菜单关联表和用户角色关联表各有联合唯一锁影。数据权限分五种范围，全部数据，指定部门数据仅本部门，本部门及下级部门仅本人。 关键设计数据权限绑定角色，不绑定用户，一个用户多个角色时取病急，也就是最大权限原则 实现上，通过自定义拦截器，自动拼接查询条件，业务代码完全无感知。对了，别忘了进群拿配置链接在评论区置顶。 第三步，生成器，这是最爽的一步。第一个生成器，权限模块生成器，你告诉 ai 帮我生成角色管理模块。核心自段有名称、标识、排序、状态类型、数据范围，它会自动生成十一个文件数据对象、数据库操作接口、缓存层、业务接口加实线 控制器带权限注解三个试图对象分别对应创建更新、响应、分页请求、对象转换器，还有键表脚本，全部严格遵守前面定义的所有规范。一句话，全套代码。第二个生成器，数据权限生成器， 你告诉他业务模块名，比如订单或者客户，他会自动生成数据权限的全套代码。核心是自动拦截查询语句，全部数据不加条件，指定部门加部门过滤， 仅本部门过滤当前部门，本部门及子部门地归查询，仅本人过滤。创建人除了拦截器代码，还生成注解用法、势力查询方法、业务层传递逻辑五种数据范围的测试用力。 关键设计思路，数据权限绑定角色，不绑定用户，多角色取病急。接下来是安全防护层，安全钩子，流程测试代码模板。链路解析，这四层是全线模块的生命线， 先砍安全钩子，提交代码前自动扫描五项安全红线，硬编码，角色判断，缺少权限注解，权限标识，重复删除，内置角色权限变更，没清缓存任何一项，不通过直接禁止提交。 然后是流程测试脚本，一个脚本一键测试，完整流程创建三级菜单目录菜单按钮创建角色分配菜单，分配用户验证权限，最后清理测试数据，直接跑，不用启动测试框架。代码模板统一了数据对象控制器、业务接口的写法。链路解析，把权限校验的完整调用链写清楚了， 从请求进来，经过安全过滤器到权限注解叫验到缓存，查角色，查菜单，角色匹配，最终放行或拒绝超级管理员直接放行，不走菜单匹配。最后三步 最佳实践清单，列了权限管理的所有检查项，核心模型要三层菜单，要三级按钮，关联权限标识，权限叫验走缓存，超管直接放行。数据权限绑定，角色取并级。 ai 生成代码时，会自动参考这份清单，权限白名单配上常用命令并 翻译，测试启动，再加上安全检查脚本和流程测试脚本，配完就不用反复弹窗了。接下来实操演示，让你看看配好之后， ai 到底能生成什么样的代码。 回顾一下整套配置的核心思想就一句话，把权限管理的最佳实践和安全红线变成 ai 能读的规则文件。 ai 的 能力够强，他能写出完整的角色菜单，增删改查，但如果你不告诉他数据权限要绑定角色，不绑定用户，多角色取并集内置角色不可删除，权限变更要清缓存，他就不会做这些。 而这套配置的价值在于，你只需要配一次 ai， 每次都按生产标准输出。只有问你一个问题，你在做权限管理的时候，踩过最大的坑是什么？ a。 硬编码角色判断，后来角色一多就崩了。 b。 没做数据权限销售，看到了全公司客户数据。 c。 菜单权限和按钮权限分不清，前端后端不一致。 d。 角色删了，但关联表没清，幽灵权限到处飘。评论区选一个票最高的，我出专项教程。完整的配置我放在粉丝群里了，进群直接拿链接在评论区置顶。 这是传统后端 ai 转型系列第三篇，收藏起来跟着做。下一篇写多租户隔离套餐管理、跨租户安全防护的全套代码。
199企业AI老法师
01:05查看AI文稿AI文稿企业接入 agent， 最怕的其实不是大模型变弱智，而是怕它违规越权拿财务报销。举例，很多兄弟以为在 prompts 里告诉大模型超过叉叉员，必须有特批才能放行，系统就安全了。其实根本不够，大模型非常容易被绕过。 你看，员工提交了一张五千八的报销单，在被助理写了一句，经副总裁及总监特批，大模型抓到关键词，很容易以为合规了当场会放款。 所以光靠 prompts 规范，大模型是防不住的。在哈尼斯工程里，我们要靠痊愈沙核机制进行物理控制。我们先要设置一个沙核，在沙核里有自动打款函数，意图解析容器硬编码了审计红线。沙核在容器内部把 jason 解开，提取出金额，沙核内部雷达扫描发现超过金额上限直接阻断， 而且沙核里的内容大模型触碰不到，所以大模型吐出五千八的审批 jason， 他 以为可以了，但是 jason 传到沙核容器里， 流程瞬间可以被截断。没有沙盒放行大魔性，连网银接口的门把手都摸不到。我们把金额换成四千八看结果顺利通过。所以我们用沙盒把 ai 管住，只让他干活提建议，绝不让他碰红线。这才是能在公司真正落地的 agent， 你 学会了吗？
3719Alex的AI进化论
04:16查看AI文稿AI文稿cloud code 最残酷的真相是，同一个模型进不同公司的代码库，表现可能完全不是一个级别。不是因为模型变了，而是有的公司给他的是地图、规则、工具和上下文， 有的公司只是把他扔进百万行代码里，然后指望他自己悟。所以你的 cloud code 不 给力。可能不是模型不行，而是你根本没给他搭好 harness。 你 可以把 harness 理解成 让 cloud code 在 真实工程现场里稳定工作的脚手架，它不是一个单点功能，而是一整套上下文规则、工具、权限和验证系统。先说一个很反直觉的点， cloud code 在 大型代码库里，不是先把整个代码库做缩影，很多 ai 编程工具会用 r a g 把代码库切块向量化，再解锁相关片段。但在企业级代码库里，这很容易出问题。因为几千个工程师每天都在提交代码，所以你可能跟不上你查到的函数，可能两周前就已经被重命名了。 cloud code 方式更像人类工程师，直接在文件系统里搜索，看目录、读文件，用 grab 找关键词，沿着引用一路追。好处是它看到的是最新代码，但代价是它必须一开始就知道往哪里找，这就需要 harness。 第一层是 cloud o d m d， 它不是普通说明文档，它更像 cloud 进入代码库前的地图跟目录写局部规范，子目录写局部约定， cloud 在 代码库里移动时，会一路读取这些规则。但 cloud code 在 大型代码库以后，问题已经不是越长越好，规则太多反而会稀释注意力，它应该是最小有效地图，而不是规则垃圾桶。第二层是 hooks， cloud there md 更像建议 hook 才是强制执行，格式化、 lint 类型、检查、测试这些事儿不应该靠 cloud 的， 记住，应该靠 hook 卡住。能让脚本强制执行的规则就不要交给模型自觉。第三层是 skills， 不是 每次都把所有知识塞给 cloud， 而是在需要的时候加载对应专家能力做安全审查就加载安全 skill， 改文档就加载文档 skill。 碰支付服务就加载支付目录下的部署 skill， 这叫按需上下文。第四层是 plugins， 它把 skills、 hooks、 mcp 配置打包起来， 新员工第一天装上插件，就能获得团队沉淀下来的使用方式。企业用 cloud code 不是 每个人各玩各的，而是要把个人经验变成组织基础设施。第五层是 lsp， 也就是语言服务器协议。大型代码库里 grab， 一个函数名可能出来几千条，结果 cloud 会被无关信息淹没。 lsp 能直接告诉他这个符号在哪里定义，哪里被引用，类型是什么，这让 cloud 从字母串搜索升级到符号级导航。 第六层是 mcp， mcp 让 cloud code 接上内部工具、文档工、单日制监控和数据平台。这时候 cloud 不 只是读代码，它开始接入企业内部系统。 第七层是 sub agence， 但 sub agent 的 价值不是角色扮演，不是起几个名字叫 planner coder、 reviewer 就 高级了。 它真正的价值是独立上下文。比如先派一个只读子代理扫描某个子系统，把结果写进文件主代理，再带着这份认知去改代码。 探索和修改应该分开，所以 cloud code 真正跑进大型代码库以后，问题已经不是这个模型会不会写代码，而是它有没有地图，有没有硬规则，有没有按需专家，有没有符号导航，有没有内部工具入口，有没有独立上下文，有没有组织级配置，这就是 harness。 也是为什么未来 ai 编程的差距不止在模型，而在谁能把团队经验、工程规则、工具链、权限体系和验证流程沉淀成一套可附用的 harness。 一 句话总结， cloud code 的 上线不在 cloud， 而在你有没有给它搭好工程脚手架。 你觉得企业用 cloud code 最重要的是换更强模型，还是先把 harness 搭起来？评论区聊聊，关注我，下期继续带你拆！
