agent进行的操作会被节点修改吗

好，我们一起来看一下 codex 呢，在五月八号进行了一次最近的更新，增加了一个昆姆扩展的插件，那这一次呢，我们一起来看一下这个插件和相比于其他的方式去操控昆姆有什么区别？好，我们直接点击这个电脑操控这里呢，大家可以看到这个会有存在一个 啊昆姆插件这么一个选项，就是我们点击管理可以看到增加了非常多的配置，比如说像权限历史记录下载上传，那这里呢提供了非常丰富的这种权限控制。嗯，我们可以通过 安装这个插件和 codex 呢进行建立关联，这时候可以看到我们的这个 codex 呢就连接上了当前这个浏览器，那出现了这一个绿色的图标，就说明我们的 codex 呢已经可以完全的托管这个浏览器了。那我觉得这是 codex 呢像全自动操控浏览器迈出的一步哦， 我就挺有趣的，所以今天给大家做一个分享。那如果你把这个开关打开之后呢，接下来呢我们就可以直接去操控了，但是你会发现一个小细节，就是如果你是在国内的环境下，你就直接点击这边去打开呃，安装插件的界面，你会发现这个商品并不能够安装，所以大家呃可以通过我提供的这么一个压缩包去进行补充这个 啊插件，好吧，呃，我们来往来看啊，首先我们来看一个很容易被大家混淆的东西就是，嗯，目前 codex 本身来说是有浏览器，那他操控浏览器和我们的这个插件有什么区别呢？比如说我们在这个 codex 中使用软件到一般是这边新建一个窗口，在侧边会有一个浏览器的选项，那其实这也是我们的第一步，就是我们的这个呃， in app browser， 这是我们的一种内置浏览器，它本身来说是用来调试的，用来开发的，所以和我们 这个插件更新是没有任何关系的，所以大家不要搞混了。那第二种呢？叫做 browse user， 这个是用来操控类似浏览器的，这是相当于前面的这个 in app browse 呢，又往前走了一步，比如说我们在这个设置这边呢，哎，去又往前走一步，这有一个，这个什么有一个啊？ browse user， 它可以让呃我们 的 codex 呢去操控这个类似浏览器，去完成一些操作。好，那也就是第三种呢，就是我们刚刚现在讲这种叫 chrome browser， 它可以帮助我们进入真实浏览器状态，去操控我们整个浏览器。 那有小伙伴说了，那其实我的这个 pry white mcp 也可以操控浏览器，或者说我这种外置这个 computer user 也可以操控浏览器，那和这个有什么区别吗？而且区别很全面，对吧？呃，区别的话，呃 computer user 呢？它本身来说它并不是浏览器的插件，对吧？它是一个操控电脑的 g y 能力的 这种插件，比如说它可以通过你屏幕去操控你调出那些图形应用，就比如说我们现在常见的这种，呃剪辑应用，对吧？微信，对吧？它都可以操控，但是你如果单独的话去操控这个浏览器的话，显得并不那么智能，所以 codex 提供了一个新的能力，就是这个 codex com， 那 我们可以通过这个 codex com 去完整的操控我们整个浏览器。举个例子，比如说我现在想让他看到我们整个这个浏览器上有多少个标签页页，对吧？我们就问他，我说，哎，现在当前浏览器上有哪一些 这个标签页？比如说你看是吧？他可以告诉我们现在到底有哪些标签页，我又让他在第一个标签页输入 a， 第二个标签页输入 b， 也可以，我再让他把某一个标签页固定也可以，就能够做到很多之前做不到的一些事情 啊，分的更加的细了。那如果说你细心的话，你会发现，呃，这个插件它其实包含了很多细节的功能，比如说他通过这个插件和 codex 进行关联之后呢，就可以直接在 codex 里面去操控浏览器的所有权限，比如说审批，对吧？ 比如说历史记录，你可以让他看到你今天到底有哪一些详细的记录，包括你上传哪些文件都可以使用它，比如说你允许上传哪些，允许下载哪些，都进行了完美的这种配置啊，对吧？非常的清晰。好，那接下来在最后我们想跟大家聊一下，就是为什么要使用这个呃，这个酷路亚 插件呢，对吧？为什么不直接使用 pro white 的 能力呢？其实很清晰啊， pro white 的 本身更像是一个外部的这种工具，而这个呃 这个 com 插件呢，是一个内置能力，如果说你使用这个的话，你会发现其实很多东西它都需要一步一步的去哎，去跟他讲，去分析，那它通过这些 m、 c、 p 的 能力去一个一个去提供。那如果浏览器更新了呢？它并不啊 同步更新，但如果是 codex 呢？它就同步更新的，它更像是一个完整的产品，对吧？也是 codex 官方提供的真实浏览器的一个执行通道。 而 pro y m c p 呢？它只是一套通用的浏览器自动化引擎，对吧？所以呢，你可以相当于它是一个小缩放。而这个，呃， codex 捆绑插件呢？还是更像是一个完整的企业级的真实软件的一个执行通道？它也可以通过现成去控制，并且呢，能够降低了很多我们调试的成本， 比如说我可以让它去帮助我去做一些自动化的事情，对吧？是吧？非常的方便。好了，那以上就是这几个的区别，我是小刘，那我们下期再见。

hello， 大家好，我是南希，我最近在用多 agent web coding 的 过程中，设计了一套 github 和 codex 齐做的代码管理系统，今天跟大家分享一下为什么要设计一条系统，以及这个系统到底是怎么流转的。 我相信很多不懂代码的朋友们，在 web coding 的 过程中一定遇到过这些问题。因为不懂代码，所以不知道 ai 到底改了哪里，有没有破坏，主线出问题了没办法定位是哪个 a， 帧出错了也没办法做数据的回滚。于是我研究了一套能实现每次改动可追踪、 自动检查代码问题、主线稳定可回滚的管理系统。这里我打一个比方，就好像几个人同时改一次 word， 每个人的改动都能直接覆盖原来的版本，所以这个 word 最终肯定会乱成一锅粥。而我设计的这套 github 代码管理系统，就能保证每个人先在自己的副本里改，改完再提交申请， 系统先自动检查，我再人工确认，没有问题的话再合并到正式版本。所以可以理解为我需要一个地方帮我把多 agent 分 工。 ai 写作、自动检查、版本记录、上线、回滚，这几件事通通管理起来。 而 github 就是 这个项目的总调度台，多身份 agent 写作中心、自动验收器、主线的守门员和发布的记录者。这就是我这套代码管理系统的流程图。 第一，它是代码仓库，所有前端后端文案 q a 的 改动最后都要汇总到这里，不然东西都散落在本地，项目会越来越乱。第二，它是协助中心，这个项目不是一个人手搓到底，而是多个 agent 分 工作室，每个 agent 做完一块就提一个 pr， pr 你 可以理解，提交作业， 这样我就知道他改了什么，为什么这么改，风险是什么，有没有影响。第三，他是自动验收器，我在微博上接了 c i， 也就是自动检查，只要有人提交了 p r， 这个系统就会自动帮我检查文档有没有乱改，代码有没有报错，类型有没有问题， 测试有没有惯，关键的约束有没有被破坏，这一步是非常重要的，因为 ai 很 会看起来写完了，但不一定真的能用。第四，它是主线的控制器，我不会让 agent 直接改主分支 mark， 必须先提 pr， 检查通过了我再默认，这样主线才干净，项目不会被一堆的半成品污染。第五个， 它是版本的记录器，每次到了一个阶段，我会打 tag， edit log， 以后如果线上有问题，我就很快能知道哪个版本是好的，哪一次改动出了问题要回滚到哪里。如果没有这套系统的约束，会出现几个非常典型的问题。 第一， agent 各做各的，我根本不知道谁改了什么。第二，看起来就完成了，其实前端掉了接口，但后端根本没挂上。第三，某次改动把主线弄坏了，结果找不到是谁弄坏的。第四，文档代码测试，三边开始打架。第五，到上线前才发现一堆隐患，根本来不及收口。 好了，今天内容就到这里了，如果这条视频对你有帮助的话，可以点个关注收藏赞下一条视频，你想看什么可以打在评论区。

ai agent 是 一个小程序，它负责在用户 ai 模型和功能函数之间进行传化。比如说我们想要让 ai 帮忙管理文件， 但模型本身没有办法直接捕取咱们的硬盘，所以我们需要提前写好一系列的文件管理函数，再把这些函数注册到 agent 里面， agent 就 会把这些函数的信息啊，通过 system prompt 或者繁星 call 的 方式啊告诉 ai 模型， 于是模型就可以返回指令，引导 agent 去调用相应的函数啊，去完成用户的请求。现在我们回到代码，今天我们要开发的是一个简单的 ai agent， 它负责管理 text 的 文件夹下面的文件内容。在当前文件夹下，我们目前一共实现了五个文件，那么它们分别使用不同的编程语言实现了一部分代码， 其中包括像 python， java， c 语言，还有 gs 等等。那我们要实现的 ai agent 能够啊通过代码的内容啊，去识别到它对应的编程语言， 然后再修改对应的文件，给他添加上对应的编程语言的后缀。那这个就涉及到本地啊文件资源的这样一个修改和读取， 那到底应该如何去实现？接下来我们先给大家去分享我们的第一个代码，也就是我们的 tools， 咱们的这个工具。 那我们前面讲到过 ai 模型，它本身是不具备修改我们本地文件的这样一个能力的，所以我们需要把这样的能力啊通过工具来实现。 所以在这里我们现在已经实现了三个功能函数，第一个就是 read file， 然后第二个 delete file， 然后第三个是 relive file。 那么对于这三个功能函数啊，它们的作用，首先第一个 read file， 那 么它接收一个参数啊，叫 name， 也就是我们的文件名，然后它会去打开这个文件，然后去读取它里面的这样一个内容， 然后 list files， 那 么它会来到指定的这个文件夹，然后去循环地去读取啊这个文件夹下面所有的文件， 然后 rename file， 那 么它的作用的话是有两个参数啊，一个是 name 啊，就是我们原原文件的这个名字，然后是一个 new name， 那 是我们一个新的这样一个名字啊，所以它能够去完成这样一个名字的这样一个修改， 那么这个代码啊，就是我们通过排序语言来实现的。那么在这里我们需要去注意的是，对于不同的功能函数，那么对于我们的参数的名字，我们应该要尽可能的啊，符合我们的这样一个功能的这样一个含义，包括 name， 那 么它指向的是什么， 对吧？ read file， 它指的是什么？以及我们在功能函数当中啊，我们所编写的这一个什么 description， 那 我们的这样一个功能函数的描述，那也要尽量的清晰简洁，那这样的话能够方便让我们的大语言模型啊，能够去进行这样一个识别。 好，所以我们在了解完这一个 twos 这个工具文件之后啊，接下来我们来到咱们的主文件，也就是问文件当中啊，那么在问文件当中的话，那么我们是通过这个 piect 啊，那么通过这样的一个 工具啊来实现呢，我们的模型的初使化啊，以及我们整个 a 镜头的这样一个创建。那么在这里的话，我们首先来看第一个，也就是我们这个模型的初使化，那么我们采用的是这个呃， deepsea 啊，就我们用的是 deepsea 的 这个模型 啊，大家可以看到啊，这个地方是我们的一个接口，然后那我们的 api k 的 话，我们是把它放到这个，因为这个文件当中的，所以大家的话可以自行去添加啊，然后模块的话就按照这个一样的去进行使用就 ok 了啊，那我们在创建好咱们的这个 大别模型这个 model 之后啊，接下来我们就来创建咱们的 a g 的， 那么在 a g 的 当中啊，我们一共给到了三个参数， 第一个参数就是我们的模型本身 model， 然后第二个是我们的 system promise， 是 我们给的一个系统的一个提示词，就是告诉我们的 a 检测，那么你是怎么样的一个身份？ 然后接下来我们把我们的整个的这样一个工具啊 tools 哎传进去了，那么在这个工具的列表当中啊，咱们一共是有三个工具啊，就是我们前面已经实现的 read file， 然后 list files， 还有这个 rename file 啊，一共是这三个。好，然后接下来那么我们的主函数的话是这个 m 函数啊，那么在这里的话，我们是实现了一个 while 循环啊，就是我们可以通过不断循环的方式啊，去反复的和我们的这个模型啊，来进行沟通啊，或者叫咱们的 agent 来进行这样一个沟通啊，那它的这个调用的方式啊，就是这个 agent 点 recent 啊，那么这个就是 实际啊，执行的这样一个方法，那么它接收的参数就是咱们的这个 user input， 就是 我们的用户的一个输入啊，咱们接收到了， 好，接收到之后啊，那么我们的这个结果啊，是在这个 out put 当中，那么在这里的话，大家可以发现我们写了一个列表啊，叫 history， 那 么用来记录什么？用来记录我们的 历史的交流信息啊？那么这个数据的话，我们是用来完成我们的多轮对话，那否则的话，如果没有这个这个历史对话的话，那么你每一次执行这个功能，它 或者说你每一次需求他都要去重复的去执行一些功能，比如说文件我前面读过了，后面我又还要再去读啊，所以他就会有反复啊，所以我们那张把历史的这个对话也给他加进去了啊。 好，那么接下来的话，我们就来运行咱们整个程序啊，我们看一下那么他的一个实现的一个效果。那首先我们运行咱们的代码。好，那么第一个就是列出所有的文件啊，我们先让执行第一步。 好，那么我们可以清楚的看到，那么现在他自己啊去调用的一个方法，叫什么叫 list file 啊？也就是列目录啊，但是这个地方我们看一下有没有问题了，好像有点问题，因为我们地方应该是 list file， 好 像是少写了一个 s。 来，我们看一下。 好，当然我们这边打印的话，是啊，没有手写啊，那这个是他自己去执行的一个结果啊。好，然后我们可以看到，那么他在这里我们列出来的这样一个文件列表有没有问题？没有问题啊，是正常的。 ok， 好， 那么接下来我们让他读取啊，分别 读取文件中的内容，好，那么文件内容我们其实前面已经讲到过了，就是通过不同的编程语言啊来实现的。好，那么我们可以看到，那么他一共啊调用了五次这个 read file 的 这样一个方法，分别去读取了 a、 b、 c、 d 啊，这个几个文件啊， 好，然后每个文件它的这个内容如下，当然我们可以看到，那么它针对于什么？它针对于我们的每一个文件啊，它的这个输出啊，它其实有把对应的编程语言有给我们做一个输出，比如说 a 它是用 python 写的，然后这个 b 它是用 java 写的， 然后这一个 c 的 话，它是用 c 语言写的，对吧？还有这个 d 呢，是用 go 语言写的，还有这个 javascript， 哎，都已经念出来了。然后接下来那么它既然已经识别到它对应的这个编程语言了，然后我们再让它根据 啊对应的编程语言啊去修改文件的后缀名， ok， 好， 那我们同样的再把这个需求提交给我们的一个 a 级的，那我们其实通过现在啊，这几次的这样一个啊执行，我们其实可以发现啊，那么对于我们的 ai 来讲， 如果说他在不具备部署这个工具的能力的情况下啊，那么他是没有什么，他是无法去读取咱们本地的文件，也没有办法去修改咱们本地的文件的。但是现在， 哎，我们会发现啊，他可不可以了？他其实已经可以了，包括在这里我们可以看到，对吧？已经修改好了，那我们现在把这个暂停掉啊，退出掉，好，退出掉之后来，我们现在看咱们这个一个文件来，各位 能看得到吗？好，那么现在啊，我们所有的这个文件啊，都已经自动的加上咱们这个后退，也就是说啊，他已经具备去修改咱们本地文件的这样一个能力了，所以这就是，哎，我们的 ai agent， 他 不光啊能够去 告诉我们应该怎么做，那他还能帮你去做啊，比如一个很简单的需求，对吧？我不知道这个代码是用什么写的， 对吧？那以往你去问这个模型，他只能告诉你，对吧？这个是用 java 写的，那如果说你要改户对，你要自己去改，但是现在他可以自己去改啊，这就是我们通过 tools 工具的能力啊，去增强了啊，这个模型啊，他的这样一个 可以去完善的这样一个功能啊，所以这就是一个最基础的 ai agent 的 架构啊，逻辑并不复杂，但背后的机制啊，却很有意思啊。那所以希望这个视频啊，也能够帮助到你啊，更加清楚的去理解整个流程。

大家好，今天给大家分享一个我改造的仓库啊，我是基于之前分享的 trading agents 这个六十五 k star 的 仓库进行了改造啊，改造完之后它就能够适配我们大 a 的 投研的分析， 这个是全称 trading agents a stock， 有 七位分析师，有多空的辩论，还有风控的决策。开始之前我再说一下，本内容仅为 ai 编程技术分享，不构成任何投资建议，不是有风险，投资需谨慎。 呃，原版的框架有三个不太适合的问题，首先是数据是不通的，他走的是雅虎 finance， a 股的数据是拿不到的。第二个是规则，呃，他还是 t 加零，没有我们大 a 的 规则。 然后第三个是角色的缺失，就是他只有四个角色，他缺乏我们，呃，大 a 对 这个政策面，还有这个油资啊之类的这些解读， 所以我对这三个维度进行了呃，深入的改造。首先是角色层面，就是它原版的这个 agent， 呃，确定 agents， 它有四个角色，技术与情，呃，与情分析，新闻还有基本面 啊，我增加了政策分析，就是我们大 a 的 一些产业政策，监管政策，然后还有油资的追踪，就是龙虎榜大单这些，然后还有解禁的监控，就大股东解禁，就是做了一些 a 股特色化的一些 a 卷的新增，增加了这三个， 然后决策的炼炉，我没有进行改造啊，就是还是七个分析师，呃，出报告， 然后但是我加了一个要质量门控的自动检查，就是对其一个分析师的报告进行一个质量的检查，因为他原版的这个产品，他出了四个报告之后就没有人检查的，然后就直接就到辩论了，但我觉得报告的质量是下面辩论的这个基础， 所以我就加了一个质量门控，会有一个这个质量检查的环节，如果质量不过关，要打回去让他们重新写。呃，第一层是分析报告，第二层是投研的辩论，第三个是风控的一个辩论，最后是最终的决策 啊。我对这个数据源也进行了更新，大家都知道我的那个 a stock data 啊的数据源，我都把它给接进去了，就是数据都是直连的，包括这个 k 线啊，这个适应率这些，还有新闻、现场，财经这些都连进去了。 呃，能力方面就是开开箱即用，大家把这个确定 ags stock 给到你的 ag， 他 就会用了啊。七个分析师，有七个数据员，还有五档的评分，然后我还加了一个外部 ui， 就是 原版式的 ui， 可能比 较简陋一些吧。我也给自己做了一个 ui 给大家用啊，有输入代码之后，它就能进行十二个阶段的进度的推演，然后最后导出一个 pdf 模型，都是支持的，接 api 就 可以了。 ok， 最后做个总结，就是这个仓库就叫这个名字啊，大家去记下来就好了。然后分析师有七个分析师 啊，数据员有这么多，就我都整合完了，都是指点 a p i 的， 然后辩论环节有这个，多空有这个，最终这个激进保守中立的风控啊。第三角色这个就不说了，特色呢是全开源的，全免费的。呃， tapp 上有个 cn 版本，他们这个前端那些不是全开源的，然后我这个，我这个改造的版本是基于原版改造，而且是全开源全免费的啊，也是没有 apikey 的 啊。这个写错了，这个可能跑不了，但大家去把那个仓库交给你的 a 卷就可以了。 ok， 今天的分享到这，谢谢大家。

挑战只用抠代码上班办公的一天，比如像这样全自动生成出数据报表这样的 ppt， 还可以把写好的文件做成这种视频演示动画， 同时还可以接入飞书，实现自动做表格修改内容总结，群聊消息，还可以用手机端一键部署任务，发文件等等操作。最后我还打造了一个网站，并且成功上线。以上的几个实际案例呢， 看似没有关联，实际这是模拟真实工作的一天，并且全部用 q 代码完成。故事是这样的， 早上你接到老板发给你的一堆数据报表，老板让你做成直观大气的数据报表，然后又让你把这些报告结合企业情况做成一个 ppt， 最后还要求你把这些内容做成网页，并且今天就要做完，你听到后立马就开干 了。那我们现在先完成第一项任务，就是让 codex 帮我们把这个数据表格转化为更加好看的格式化数据报表。这里我写好要求后， 把权限设置为自动审查，这样在他执行任务的时候，我们几乎不需要操作，只需要等待他完成就可以。模型思考程度我们可以选择中或者高， 如果选择高，他的运行时间会更长，而且消耗的额度会更大。如果是简单一些的任务，我一般推荐使用中等就可以。现在他已经为我们生成好了这个网页，我们看到这里他一共用时了六分钟零三秒。 现在我们打开这个网页看一下，我们可以选择这里，点击直接打开扣代码中直接内置了浏览器，我们打开后就可以预览， 我们可以看到这里它已经把我们的数据做成一个详细的网页了，并且这些按钮是可以点击的，因为我们后续是要做 ppt 的， 我们想把这些表格数据呢插入到 ppt 当中，那我现在让 codex 重新修改一下，把每一个数据报表做成一页 ppt 的 形式。现在我们看到 codex 已经帮我生成好了，并且他告诉我他已经生成好了五个报表的独立网页。我们可以打开我们的项目文件夹来看一下这五个文件。现在他把每个报表都做成了一个独立网页。 考虑到那个万恶的资本家观看的便捷性，我们可以让 ai 把这五个报表都转化为 pdf 文件。我们看到 现在 codex 正在帮我们把网页转换成 pdf， 他 在努力的工作下载各种插件。那现在我们可以不用等他，我们可以继续工作来创建 ppt。 我 们点击这里的创建新对话，这时就会重新打开一个对话窗口，而且之前的任务还会继续运行。 在制作 ppt 之前，我们可以问 codex， 我 想做一个 ppt， 有 哪些 skill 或者插件可以帮助我们提高 ppt 制作的美观和专业度。这时我们可以看到两个任务在同时运行， 也就是你的工作效率现在就是翻倍了。如果你还有其他工作任务，可以继续添加，如果十个任务一起执行，相当于你的工作效率就翻了十倍。我们可以点击这个设置，再点击这个剩余额度， 可以看到当前我们剩余的额度有多少。我个人使用下来基本上 plus 额度就够用了。现在我们看到这个网页报表任务右侧已经变为了蓝色，代表它已经执行完成， 我们点击看一下，这时我们看到这个 pdf 已经完全编辑完成了，如果哪里需要略微调整， 我们可以用其他的软件来手动调整一下。现在我们看到这个安装 ppt 插件的对话也已经显示任务完成，我们点击查看，它告诉我们 已经安装好了五个 skill， 然后它提示我们需要重启 codex 后才能被识别重启。打开 codex 后，我们还是点击这个对话，现在让它帮我们 继续完成这个 ppt 制作。在对话框中我们可以艾特我们想编辑的文件，输入文件名后，它会自动提示我们，然后我告诉他 根据这几个文件内容和刚才你安装的 skill 来帮我制作一个 ppt。 当然我们有其他针对性的要求，也可以直接告诉他。现在我们看到他经历了十三分钟后， 终于生成出来了这个 ppt， 那 我们现在打开看一下，我们点击这个打开按钮， 然后可以选择用哪个程序来打开，现在就可以看到他为我们制作的 ppt。 我 们看后面这几页制作的比较单调，而且格式不太统一， 那我们现在再让它修改一下。又经过了十三分钟的调整后，现在 codex 帮我们调整好了， 我们再打开看一下，现在看到虽然排版还有一些问题，但是已经比刚才好很多了。那这个视频我们不是主要讲如何优化 ppt 的， 我们先忽略掉 目前的一些小瑕疵，如果想调整局部呢？我们可以用这个 office 软件进行细节调整。经过了 codex 一小时的工作，我们现在得到了 ppt 和 pdf 这两个制作好的文件，那我们现在就利用 codex 让它直接把这个 ppt 还有制作好的 pdf 数据表格 发到非输的群聊当中。我们先安装非输的 c l i 终端命令，这个插件的好处就是可以让 agent 在 终端 直接调用飞书的各种功能，比如写表格，上传文件，下载文件。 我们打开飞书的 c l i 网站，我们可以通过手动安装和 agent 安装，如果想要 codex 安装，我们就复制这个提示词。打开 codex 后，我们可以点这个对话， 新建对话，然后将提示词粘贴到对话框，这时它提示我们配置命令已经生成授权入口，我们点击这个链接，在这里我们点击创建，创建好后返回 codex， 这时它提醒我们还需要打开这个网址进行授权， 我们复制这个网址，这里会提示一些权限，我们选择授权。现在它提示我们飞出 c l i 已经安装并配置完成，我们返回到刚才的这个项目，点击创建新对话。现在我让 codex 把刚才制作好的 ppt 和五个 pdf 图标一起发到飞书的工作群聊中，现在 codex 告诉我们他已经找到了这个群聊，让我们确认一下就可以，我们回复确认， 如果在这个过程中，他需要我们授权，我们按照他的提示操作就可以。 现在我们看了一下时间，完成上面两个任务仅仅花了一小时，那我们现在可以潇洒的到公司楼下点咖啡摸鱼了。不一会群里万恶的资本家给了一些反馈意见，但这对咱们来说是小意思， 为了以防万一，我们早就通过手机连通了 codex， 现在根本就不用回公司喝着咖啡，简单一条指令， codex 将继续为我们干活。那如何在 codex 中连接手机端呢？点击左上角的设置， 在这里点击 codex， 然后我们点击连接，在这里提示我们登录的话，我们点击登录就可以， 我们点击授权，这时我们在手机上就可以看到电脑上的项目，点击对应的项目后，我们就可以让 codex 在 电脑端帮我们工作。我现在让 codex 直接把这份 ppt 变为一个网站，我们可以看到在手机端它已经开始执行任务了，并且在电脑端我们也可以看到这个任务。 为了方便演示，我之后还是在电脑端给大家演示功能。如果在执行任务的过程中，我们突然想起来还有一些指令当时没有写完，这时也不需要终止指令， 这时我们提出修改意见后，正常新的命令是需要等上一个命令执行完成后他才开始执行的，这时如果我们点击引导，他就会把这条新的指令注入正在执行的任务中，来，参考你新的指令，重新思考。经过了十二分钟， 这个网页已经制作完成了，我们打开看一下，我们看到整体的排版布局 和色调还是非常不错的， codex 软件内置了一个简易版的浏览器，并且如果我们想修改这个网页，可以给这个网页添加注视， 我们点击注视，如果想修改哪里就在鼠标点击哪里，比如我想修改这个区域，点击后输入想修改的具体内容，我们可以点击发送直接修改， 也可以按住 ctrl 加回车继续添加注视，点击直接发送后，它就会立刻给我们修改。修改好后我们再点击看一下，这时的历史记录已经按照我们的提示修改为时间线的形式。如果我们还想修改其他内容， 也用这种添加注式修改的方法会比较便捷。那现在我感觉这个页面整体都是静态的，比较单调，我想做成一个有动画演示的效果。现在我们开始使用 codex 中的插件，借助插件来达到我们想要的效果。 那我们今天就用 remote 这个插件来演示，这里我已经安装了，如果没安装呢？这里会显示一个加号，这样我们在跟 ai 对 话的时候，可以直接让它调用这个插件。比如现在我新建一个对话，这里我输入斜杠， 再输入插件的名称。现在我让 codex 用 remotion 这个插件来给我们的网页中增加一些视频，让它在合适的地方插入，增加整体网页的动态效果。 现在它已经生成好了，我们来看一下效果。我们可以点击这里，直接使用电脑中的默认浏览器打开我们看它在这里给我们加了一个视频。这种制作视频的方法 不需要任何的剪辑，只需要提供文案和你的想法。这个 remote 插件完全是由代码生成的，那现在我们的这个网站 已经全部制作好了，现在我们只剩下把网站上传发布，任何人都可以访问。那具体需要怎么操作？如果我们不会，还是先问 codex。 在 使用 codex 时，我们要养成一个习惯，每一个新的任务 我们都需要新建一个对话框，如果把所有的任务都集中在一个对话框内处理，随着对话越来越多，他的上下文会逐渐累积，模型的执行能力会下降非常多。比如在当前这个我让他制作动画视频的界面， 我们看对话框中这个圆圈，我们把鼠标移动到这里，它就会显示当前上下文已经使用了百分之二十。那日常使用中， 我建议只要上下文达到百分之五十，我们就需要重新新建一个对话框了，或者我们还可以使用斜杠压缩的命令，这样也可以进行上下文压缩。那我们现在新建一个对话框，那我们现在就问 codex 如何能让所有人都访问到这个网页，并且告诉他如何能免费的部署。我是小白用户，他就会在网上给我们搜索符合我们要求的一些解决方案，现在他给了我们一个解决方案，我们按照他的步骤来执行。 经过简单的几个拖拽之后，我们可以看到网站现在已经可以被任何人访问到了，任何人打开这个网址都可以看到我的网页。 我们现在一看时间才下午两点，现在就把整个项目发给那个万恶的资本家，他肯定还会改改改。那我们再用 codex 的 另一个功能就是自动化，我们可以设置一个定时任务，我们还是在这个项目下新建一个对话框，我们让 codex 帮我们设置一个定时任务，让他在今晚的四点五十九分给我的飞书工作群发一条消息，内容是告诉这个万恶的资本家网站已经上线了， 如果有修改可以给我留言。创建好定时任务后，我们看在自动化这里有一个数字，一代表已经有一个出发任务，我们点开这个任务后，会看到具体的执行命令和出发时间，我们还可以点立即运行， 他就会立刻执行这个任务。在以上的五个实践案例中，已经包含了大多数 codex 的 使用功能，并且我们把这五个案例串成了一条主线。我们总结一下以上几个案例中的知识点。我们把表格数据做成网页， 在对话框以艾特的形式添加文件，设置思考强度，建立项目文件夹。第二， 制作 ppt。 我 们使用了添加 skills， 帮助我们制作出更好看的 ppt， 同时让 agent 调用生成功能插入到 ppt 当中。第三个是安装飞书的 c l i 命令，然后把飞书的 skills 安装到 codex 中，让 codex 可以 调用飞书，实现上传、下载、发消息、回复等操作。 第四个，我们构建了网页使用批注功能，对网页进行了修改，并且使用 remote 插件在网页中添加视频。第五个，我们询问 codex， 让它帮助我们把网页上线，让所有人都能访问。 如果你对这期视频的形式满意，请给一个一键三连，我将继续分享更多 ai 领域的落地实操。我是留言，我们下个视频见。

一上来先放个狠话，认为 agent 等于工作流加应用大模型的基本上都是初学者。现在 a 群有一个特别离谱的现象，只要能拖几个节点，调一下 gpt， 接个数据库，很多立马就敢说，看我做了一个 agent， 结果你仔细一看，好家伙，这不就是一个自动化的工作流吗？ 换皮版的 activity 都快吹成 agi 了。真的就有些这种用户输入计划大模型分析一下，然后调几个工具再输出结果的。这种流程连 agent 的 边都沾不上。你这玩意跟十年前的 btm 工作流、审批流、自动化脚本本质上没有任何区别。 自动执行真的不等于自主决策。工作流是什么？工作流的本质上是流程提前写死， a 后面一定是 b， b 后面一定是 c。 就 像地铁路线一样，你只能按照轨道跑。而真正的 a 着呢， 更像是一个真人司机，会自己判断前面堵不堵车，要不要绕路，现在应该调动哪个工具，任务失败之后要不要重新规划。这里面最核心的东西叫做自主性。举个例子，你现在做一个自动化汇总数据，调大模型生成总结发企业微信， 这个其实更偏不 flow， 因为整个列录是你提前设计好的，大模型只是其中的一个节点。但如果换成真正的 agent 呢？他可能会先分析用户意图，然后自己决定需不需要查机着需不需要独辟的提交，需不需要总结聊天记录，甚至发现信息不够后，还会主动追问用户。这时候他开始具备任务拆解和动态规划能力了。 里还有一个特别大的误区，很多人以为调用了 tocolin 就 算是 agent 了，其实 tocolin 只是 agent 的 基础能力之一。真正复杂的 agent 往往还会涉及到 memory planning， repression， 多轮推理，状态管理，多 agent 的 协调这些东西。 为什么现在 long graph 这么火？因为很多人慢慢发现，真正难的根本不是掉一下 g p t， 而是复杂状态流转和常电路任务控制。而且你会发现，现在很多平台其实也在故意的 agent 化营销，本来只是一个工作流平台，接了个大模型之后立马开始宣传自己是一个 agent 平台，比如像 devorce n 八 n 其实都偏 workflow， 只不过 a 味儿越来越浓了而已。 真正算得上 agent 的 其实是 long graph or ai 这些。当然我们不是说那些东西没价值，相反它们非常有价值。但问题是 world flow 不 等于 agent 能调大模型，也不等于 agi。 最后留个问题，你觉得市面上的那些所谓的 ai agent 的 平台有多少算是真正的 agent？ 又有多少只是套路过大模型的工作流呢？

操作系统级 ai 助手终于来了，它就是 marvis， 一个更懂你的 ai 助手。今天这期视频就带大家一起实测一下 marvis 究竟好不好用。首先需要来到官网，按照流程指引将 marvis 装进你的电脑。完成后第一步，先登录自己的账号， 当前是支持微信以 qq 两种登录方式。上来以后，我们先来询问一下他会做些什么？可以看到本地电脑的文件整理，系统的一些基础操作，包括应用的安装和卸载通通都可以实现。 我们先给他下达一个卸载指令，看看他能不能去执行这个操作。首先他会判断这是一个什么类型的操作，然后再去派发给对应的 a 证，同时也可以在旁边的办公室去观察当前 a 证的执行状况，在执行操作前也会进行二次确认是否需要卸载当前应用。 ok， 可以 看到已完成卸载操作。那如果我们让他自己再安装一个最新版的应用，能不能安装？答案是，当然可以。 这里他会询问是需要安装 windows 版本还是手机 app 版本，如果和手机 marvis 已经连接，也可以选择手机版， 安装完成后就可以正常登录。我们再来让他帮忙检查一下电脑 c 盘的文件占用情况，可以看到他依然会先判断这是一个什么操作类型，再去将执行任务派发给对应的 agent， 最终输出执行结果。除此之外呢， 还可以在 mars 里面看到我们电脑本地的应用以及文档、图片文件，授权读取本地文件以后就可以进行体验。不愧是操作系统级 ai 助手，谁能拒绝这么能干的呢？

cloud code 架构解读，这个其实会稍微有一点点的这个小小的这个难度啊，但是我们会尽量的在今天晚上这个讲解过程当中呢，把这个难度降一下来进行一个讲解的介绍啊。因为 cloud code 它作为目前可以说全球最顶尖的 agent 架构，它底层的原理其实非常非常复杂，内部的这个架构呢，也非常非常复杂， 对吧？源码出来之后总共又是五十一万行啊，这样的一个很大的这个项目，虽然里面其实会有一些这个技术债在里边啊，但是其实不是很多 啊，整个源码的这个结构还是非常的这个紧凑，然后效率也是非常高的啊，所以我们才有说围绕他这个内容来进行解读的这个必要。我们今天晚上在课间里边有一个百度网盘，网盘里面就包括包含完整的 cloud code 这个项目的这个源码啊，然后呢我是给大家准备了两个 啊，一个叫 beautiful 杠 folk 的 一个原码，还有个 collection， 这两个原码像这个 beautiful folk 啊，直接打包运行，就可以直接去在本地运行一个 cloud code 啊这样的一整套原码。然后这个 collection 呢，实际上是一些更加零散的啊，一些这个原码，下面有非常非常完整的这个原码参考说明哈。大家这个领取原码之后呢，可以自己去看一下啊，这个呢是 它的这个完整这个原码，但是呢它因为它这个原码有五十一万行啊，所以呢，如果你想呃自己从头去进行这个开发啊，或者是自己来进行打包的话啊，也可以试着来进行一些这个运行啊，当然我们说如果你只是去用 clock code 的 话，那么拿它的原码或许没太大用啊，但如果你是想 去参考 clock code 的 这样的架构，然后来进行二次开发啊，那这个原码可能就很有用了。对于 clock code 来说，它总共是五十一万多行的这个代码，其实它的这个项目体量呃是非常大的一个这个项目哈， 那么在五十一万多代码里边，我相信可能很多同学就会比较感兴趣啊，那他什么这个代码会比较多呢？对不对啊？那个是不是调用模型代码会比较多呢？啊？构建一个 a 政策让他能够顺利调用工具代码比较多呢？还是用于去构建上下文的啊？这个代码比较多呢？还是要内置工具的 使用代码会比较多呢？还是他的这个内部的 skype 代码会比较多呢？那么同学其实会有这方面的这样的这个想法，但实际上啊，我们如果去看 clock 它完整的这个代码体系的话，那么你会发现它里边啊，只有不到百分之五的这个代码 是用于去给你构建一个完整的这样的一个 agent 啊，就是啊，大模型啊，这个调用某些工具啊，然后呢给它写成是一个 look， 对 不对？对不对啊？这个 agent 运行时嘛，一个这个循环，它会不断地调用这工具来完成对应的这样的一个这个工作，它里边啊，总共是只有不到百分之五代码是去写这些东西的， 剩下所有的这个代码，其实基本上全部都是 harness engineering 啊，就是我们呃上一场公开课讨论的这个内容啊，所谓这 harness engineering 要指的是它这里面基本上很多很多代码都是为了 如何让一个 agent 更加稳定，长期稳定啊，这个并且能够非常好的理解用户意图来进行一个这个运行好的，但这个其实对于现在我们在进行 agent 开发的很多同学啊，甚至是对于比如说啊，像 long chain agent school 啊，这些 agent 的 开发框架来说，都有非常好的这个借鉴意义啊，因为其实啊， 现就是呃大模型技术发展到现在，你会发现让一个模型会调用工具啊，会多用调部工，呃，会多部调用工具对不对？会一边思考一边调用工具等等等等啊，这个事情其实已经不是什么特别难的这个事情了啊， 包括现在大魔仙本身上下纹也很长啊，然后呢，工具识别能力也很强啊，在这样的情况下呢，你要去定义一个 agent 的 loop 啊，一个运行的这个循环啊，其实非常简单，你让它调用各式各样的工具，其实它也都也能够也都能够来进行很好的调用，但是呢，难就难在 很多复杂的工作，你怎么让 agent 去做呢啊？很多需要长时间啊，来进行运行的这个事务怎么样让 agent 去完成呢？很多需要非常非常长的上下文，长期持续专注去解决某些问题啊，怎么去交给 agent 来进行运行呢？这个其实才是现在我们在去使用 agent 的 一个非常大的一个难题。 那所以哈，我们前段时间公开课讲的 harness engineering 啊，这个驾驭工程啊，就指的是，哎，我们现在呢是要需要给当前的 agent 更好的一些 约束对不对啊？约束好了之后，他才能够长期稳定的去完成某一些这个工作，这其实是一个架构的这个理念。而在 cloud code 他 这次泄露的这个原码里边，我们就能够非常好的看出啊，他的这个驾驭工程是怎么做的啊？所以啊，我们 这次的 cloud code 这个原码的个泄露啊，也有很多技术人觉得说啊，这就是一个非常好的一次这个驾驭工程的落地实践的这样的样板啊，值得好好学习。 我们都知道在 a 证的运行的过程当中，其实需要他如果需要长期运行的话，会有很多很多很多问题的啊，比如说什么上下文越来越大， a 证的越迟钝，然后关掉就失忆啊，然后这个重开的 之之前的这个所有的这个记忆全全部都没有了啊，然后呢，比如说他的安全性的这个问题，对不对？然后比如说他的在伴随着运行的过程当中啊，他的这个实际的运行成本是限性增长啊，并且呢他其实会有个海量的啊，这个知识方面的这个商增啊，非常迅速的这个知识方面商增的这样的过程啊， 那么这些结都是会去影响一个 agent 的 长期稳定来进行运行的这样的一些这个不利的影响因素啊，那么其实从 code 完整的架构里面我们就能看得出来，哎，他呢是怎么去考虑解决的啊？解决这个问题，那么其中呢，既有一些 我们现在通用的啊，知道的一些这个解法的代码层面上的实现啊，同时呢他也会有一些啊，这个我们可能之前不太了解啊，甚至都没有听到过的 一些这个方法啊，来进行这个实现，等等等等啊，那么我们接下来在接下来的课程里面都会来进行一个这个介绍，那么这部分工作之所以会非常有价值的一个原因啊，其实也是因为大冒险本身啊，他的这个模型或者这个算法 导致的他本身运行的这个不确定性。那么我们在使用大模型的时候啊，其实经常啊，大家会觉得说啊，我们运行一个同一个任务，运行多次，他的结果不一样，我们在使用大模型的时候，很多时候都是在类似于像绝经的这样的过程，哎，他这次运行效果好了， 说不定啊，我们就有很大的这个用处，那这次运行效果不好，我们可能很可能很多时候甚至希望他多运行几遍，那至于这样的场景，我们当然是希望大冒险每次运行都能够长期稳定的，对不对啊？运行的这个很好啊，所以这才是所谓的这个驾驭工程的这样的一个啊，他的核心的这个出发点啊，跟现在这套技术最有价值的这个地方啊， 当然如果类比，比如说现在很多的一些这个啊，视频啊， ai 生成的这个视频的这个领域，它现在不仅仅是说啊，在在在什么这个提示方面会有些优化啊，甚至还出现了类似于这个抽卡这样的个流程啊，就同一个 场景啊，同一段故事啊，他可能会生成很多遍啊，然后你去找那些生成效果最好的那样的一些这个内容啊。当然我们想，如果你可以通过驾驭工程啊，假设类似这样的场景能够让当前这个 a 阵子长期稳定的去生产对应的这个结果的话，那么其实这个过程中间你要省去的成本或者提高效率就非常的可观了。 所以这就是我们接下来啊，需要去看现在的 cloud code， 它的这整个架构，或者我们通过今天晚上这样的一个学习啊，最后能够收获到的啊，最可贵的这样的这个知识和内容。哈哈，好，那么接下来我们就来看看啊，现在的这 cloud code 的 整个的这个架构啊，长什么样啊？以及呢，我们怎么样去啊，它，它是怎么样 很好的去引导当前这个 agent 长期稳定高效的就产出基金的这个内容的，对不对啊？ ok， 好， 那么首先哈，我们会先，我们会先从一个 很简单的一个这个代码，呃，一个这个 demo 入手啊，跟大家来进行一个讲解的介绍啊，这也是考虑到我咱们今天晚上可能有一些呃，之前零基础的这个同学啊来听课， 那证明我们学上是借助了一个项目啊，叫 learn cloud code 啊，这个项目啊，这个项目其实是一个大家如果想要去深入学习 cloud code 的 每一个技术细节的话，一个非常不错的一个，呃，之前是一个逆向 去拆解 clock code 的 一个这个项目啊，然后现在呢， clock code 的 原码卸灭了之后呢，这个项目也火了啊，因为他很多之前对 clock code 的 一些这个猜想是对的啊，呃，大概猜对了三四层吧，啊哈哈，剩下的都都 不太对啊。然后呢，在这个项目里边其实有很多的一些围绕 cloud code 的 一些基本的底层功能的一些 demo 级的这样的实现啊，所以呢，我们接下来呢，在进行运行的时候呢，也会采用啊这个项目里边的一些这个代码给大家来进行演示啊，就是出于一个教学或者零基础理解这样的场景下，哎，我们看看 agent 是 怎么运行的，它会有什么样的问题，以及如何来进行解决 好，那么首先哈，我们需要知道当代 agent 在 进行运行的时候，其实它的这个呃整体的这个运行逻辑或者核心股价其实非常非常简单啊，就是一个呃能调用工具的这个大模型啊，加上这个 c m d 命令行工具啊，基本上就构成了我们现在看能看到的所有的 agent 最核心的这个股价。 那么所谓的这个 cmd 命令行这工具哈，它呢，实际上啊，就是一个这个 tour， 对 不对啊？这就是一个工具啊，然后呢，这个工具呢，它可以操作你当前的环境这个命令行，然后你只需要给它输入命令，然后它就可以自动来进行执行，你可以这么来进行理解就可以了。那这个工具之所以会成为当代 a 阵的最为核心的这工具， 大家想一想嘛，啊，你用这个 openclo 是 不是你动不动让它什么生成个文件啊，这个整理个桌面啊，啊，做这个事，做那个事啊，阅读下自己的这个记忆啊，修改自己的记忆啊，它背后怎么来进行的，基本上都是靠 这个命令行来进行实现啊，命令行就是操作你当前这个电脑最为核心的这样的工具啊，那么呃这个呢，是第一个，那么命令行工具在上面这个项目里边啊，回大家可以自己 在我们的课程的课间里面能找到哈这样的这个项目，然后里面有这个代码啊，让大家看一下啊，命令行工具，一个典型的命令行工具定义长什么样？然后同时呢啊，关于这个核心的 agent 在 运行的过程当中，它的核心功能其实都是通过一个叫做 agent loop 的 这样的工具来啊这样的一个形式来实现的啊，稍等 大家课间放大一点。然后呢，所谓啊这个 agent loop 呢，它呢实际上就指的是我们在进行调用的时候啊，啊，在大模型的工具的这个时候啊，基本上它就是属于一个啊 循环的这样的状态啊，那么这个循环它循环的是啊，我这次在进行工具调用啊，在这个看它能不能成功啊，如果成功了的话，我们就退出这个循环啊，给用户一个答案啊，如果成功了的话，我们就退出这个循环啊，给用户一个这个循环啊， 当然我们一会去看 cloud code， 它其实也是哈，那这个它里面这个源码其实也是一个这个 loop 啊，也是一个循环这样的概念。那么现在为什么啊？这个 agent 运行的这个核心本质上就是个 loop 啊，也非常重要的原因是因为现在的大模型性能都非常强 啊，如果是早几年的这个大模型啊，比如说二四年的那个大模型啊，那个时候呢，大模型这个不说调用工具稳定不稳定吧，如果你是把它放到一个 loop 里面来进行这个循环的话，那它就完蛋了哈，因为它根本不知道自己什么时候该停下来， 但是呢，对于现在当代大冒险来说，他其实都会有个非常清楚的这样的一个认识啊，一个呢是对用户的意图更加深刻的这个把控啊，那么除此之外呢，他也有一套自己啊非常清晰的去判断，关于说，哎，我现在运行到这个什么程度，或许需要停下来啊， 这样的一个这个状态啊，所以呢，基本上核心的这个 a 阵，它都是在一个 log 里面来进行运行啊，就是不断不断不断的尝试这样用各式各样的工具啊，去完成当前用户的提出这样的问题啊，完成了之后呢，就跳出这个循环啊，或者失败了很多次之后，觉得自己没必要再试了，也可以跳出这个这样的个循环啊，否则就一直在循环里面来进行。 那么有了这个 log 啊，然后呢又有了这个命令行工具之后啊，那么接下来啊，我们说你的这个 agent 啊，就属于一个基本成型的这样的一个这个状态啊，因为它可以持续不断地调用命令行，去完成各式各样这个操作啊，当然这个其实也是 cloud code 啊，里边核心源码的这个部分啊，这里面大家如果感兴趣的话，可以在这个 呃， beautiful s r c 的 那个文件里边能够去找到它完整这个源码啊，然后呢，这部分的它的内部的 agent 运行的这个源码核心代码呢，是在这 q r 点 t s 里边啊，大家可以去看一下， 发现啊，它其实也是一个也是一个 loop， 对 吧啊，它其实就是在不断的调用当前的 cloud cloud 这样的模型，在进行一个这个循环啊，差不多是这样的一个这个情况， 所以啊，你会发现，呃，整个的啊，我们当代的 ag 的 核心呢，就是要需要构建好这样的个 loop 啊，当然我们这一期讲的会比较简单哈，真正在构建 loop 的 时候，你可能好歹得用些这个工具啊，得用些这个框架啊，然后呢辅助你更好的去完成这样的这个 loop 啊， 这里大家可以自己去试一试啊，我们上面给大家给出的这个原码啊，就是上面呃，我们这个教学视力的这个代码啊， 就 learn cloud code 啊，这里面这个代码，大家可以自己去尝试着去用用，看一看啊，感受一下啊，他现在整个的这个核心的这个路谱呢，大概长什么样啊？你现在呢，让他呃这个执行简单的任务，他就是一步啊，这样工具结束了啊，如果让他执行复杂任务，他可能会 多部啊来调用这工具啊，但总之呢，有了这个命令，行啊，有了能够啊，有了这个能够调用工具的这个大模型啊，再加上一个路谱啊，基本上我们的 agent 的 核心呢，就这么构成了啊，是这样的这个情况， 当然哈，我们去构建这样的 agent 的 这个核心啊，大家肯定会想啊，那呃，他肯定会有些不太够的地方，对不对啊？你好歹给他多整一点这个工具啊，给他搞一点这个复杂的上下文啊，等等等等， 那我们说所有的啊，其他的这个 agent 的 这个架构，基本上都是以这个为核心去进行那些功能的这个拓展，我们这也就不展开了来说了，但是大家需要知道的是一个基于 look 啊和啊基于这个命令行为核心工具的这样的 agent 的 体系，它其实会面临很多问题的啊，我们接下来主要是看它会有什么样这个问题，以及呢 cloud code 到底是如何来进行解决的？ 那么他会有哪一些问题呢啊？首先第一个就是上下文会不断的增加，对不对啊？这其实是非常明显的一个这个问题啊，也是我们在实际对话过程当中迅速就会遇到的这样的这个问题啊，上下文会越来越长， 越来越长，并且呢伴随着像现在啊，我们很多比较复杂的这工具在进行调用的时候啊，他这个上下文呢，实际上是会呈现这个指数级的这个上涨这样的情况， 上下文一长啊，其实就会带来很多的非常致命的一些这个问题哈，就比如说一个呢，是模型的啊，他会有个上下文的这样的窗口啊，超过这窗口他就没法来进行运运行了，必须要去裁剪一下之前这样的记忆啊。那么第二个呢，是 伴随上下文越长啊，其实模型的注意力呢也会被稀释掉啊，这就是所谓的现在我们在去使用，比如说 color code 呀，或者是大家去用很多的一些大模型，你会发现前半段啊，运行的还很好啊，愿意去生成一些很长的这个结果。到后半段 啊，尤其是这个模型快到自己的上下文窗口的时候，他就开始疯狂的输出啊，对不对啊？也不管这个输出对不对啊，或者质量好不好啊，甚至是这个给你乱输出一通啊，总之就是会迅速在短时间内把这任务给结束掉啊，这就是所谓的当代大模型的上下文焦虑，哈哈，会存在这样的这个问题。 那么第二个就是对于每一个 a 阵在这运行的过程当中啊，他其实会存在关掉就失忆啊，重开全部知道啊，这样的这个情况啊，但是这个情况 大家都能理解，对不对啊？因为上下文没了嘛啊？但是呢，我们说在当代的 agent 的 这样运行体系里面，为什么这点会变得非常重要啊？其实是因为我们现在的很多 agent 在 运行的时候，它往往不是一个 agent， 它是很多个 agent 啊，这个时候呢，它我们在实际执行任务的时候，就需要非常合理的给不同的 agent 啊，给他来进行非常精密的上下文，这样的匹配才能够迅速的带入到自己的这个角色里面来啊，来完成运行啊。所以呢，对于现在的 agent 运行过程当中来说啊，我们说合理的给他匹配上下文也是非常重要的一个方面。 第三个就是安全方面这样的问题，对不对啊？那安全方面问题呢？呃，之前我们在讲 cloud code 啊，讲 open cloud， 其实有讲到过啊，就是由于你现在啊 这个 a 智能很厉害啊，对不对？他自个又很聪明哈，然后呢，他又有智慧啊，又可以操作命令行者工具啊，对你各种环境的一通操作哈，那么这个时候呢，呃，他这个安全问题就会变得非常重要啊，因为他一不小心把你什么关键文件给删了哈，对不对？那这个事情就很尴尬了啊，所以呢，对于现在的这个 a 智能运行来说，安全其实是一个很大的 一个这个需要考虑的一个方面。那么 agent 的 安全哈，跟传统的软件安全还不太一样啊，传统的软件安全，它其实是可以通过一系列这个测试给它测试下来的哈，就去看啊，关于啊，你在各个场景下你的所有功能是怎么样来进行运行的，一个一个来进行安全测试，测试完了之后就可以上线。 但是对于大模型来说啊，它呢是一个有智慧的工具啊，那么呃，你引导它去工作啊，那么也可能会它呢也可能会被别的一些信息给忽悠瘸了啊，这个时候呢，你就得这个想办法，对不对啊？这个用魔法，对方用魔法对抗魔法啊，才能够解决大模型的安全性的这样的问题。 我们现在说 open cloud 啊，这个很多的安全性问题，非常的这个显著，有很多隐患需要来进行修复。但实际上呢， cloud code 啊，它作为目前非常通用的这个智能体， 他的安全的这个级别是非常高的，他也是之前经历了很长一段时间安全啊，踩坑啊，甚至被竞争对手殃流啊，这样的这个情况之后啊，现在他才这个逐渐逐渐逐渐提升了啊，他的安全性，这样的这个啊，提升他的安全性的一些这个措施，那么现在啊卡扣的的安全的很多措施我们会看啊，其实还是非常精彩的。 那不管怎么样，我们说对于安全性这个问题，哎，它其实也是属于，对吧？啊，整个 agent 在 进行运行的过程当中啊，这个我们是要时刻关注的啊，就比如说这里面我们现在给大家的这个视力代码里边啊，这个不是呃，这个不是 clock code 的 这个原码哈，这是我们给大家视力代码里，比如说 一些就包含了一些非常基础的安全性啊，这样的一个解决这个问题，比如说啊不让他去使用什么 r m 杠 r f 这样的这个命令啊，还有这个什么 s u d u 啊，这个全部权限这个命令啊，还有这个杀档啊，关闭某些东西这个命令等等等等啊，会有这样的这个提示啊，等等等等。 当然啊，还有一个非常重要的一个这个问题啊，就是他其实 a 阵的运行的过程当中啊，尤其是一些长效长期这样的问题，会带来巨量的知识的，这个 商真啊哈，那么你运行的越多啊，关联的文档就越多啊，他你现在需要处理的这个局面就越就更加的这个复杂啊，他其实是会出现一个非常巨量的、非常快速的这个商真这样的状态， 这个商真这个状态哈，其实会很大程度上啊影响你未来 a 智能是否能长期稳定运行的一个这个点啊，这个其实并不是在于说我现在啊，这个每次带货量我就越多了，然后我付的钱就越多，并不是这样，而是他整个的运行的稳定性 就会遭到巨大的啊，这个呃影响啊，那么就比如说啊，我们这个 agent 的 look 对 不对？在运行的过程当中呢，你会发现啊，这个运行的运行的，运行的每一轮 talk 就 越来越多啊，当然浅层次的呢，是你的费用越来越多啊，但是这个深层次的呢，是伴随着你当前 agent 的 这个商增啊，你其实你的稳定性会受到很大的影响。好， 那这问题怎么解决呢啊？我们接下来其实哈整，如果你去纵观整个 cloud code 啊，它的这些原码，基本上它就是围绕着这 四个问题啊来进行的这个展开啊。我们其实今天晚上的公开课并不会啊，直接去贴一个啊，比如说 clock code 完整的啊，这个什么几十个这个，呃，几十个不同的核心的这个主类啊，还有上百个啊，这个子类它的功能对比的这个表啊，这个其实意义不大啊，我们更多的希望大家能够通 过我们接下来这个解读啊，能够看得出来这个 clock code 是 怎么样啊，去实现这个 harness engineering 的 啊，以及呢我们现在这个 clock code 到底是啊作用于它的核心架构，对我们开发人员来说，它到底是能够解决哪些问题？ 那么接下来啊，这个原码这个层面，其实就，呃基本上啊整个扣的这个原码层面都是围绕的我们刚才所说的这四个方面啊来展开的啊。当然大家如果想去看他完整这个原码的话，那么其实呃上面有原码，上面完整这个原码大家可以自己去拿，自己荡下来之后去可以去看一下啊，那么总之呢，现在他总共呢是 五十一万多行的这个代码里代码文件啊，然后总共呢是一千九百多个这个，呃五十一万行的代码啊，主要是 t s 的 这个代码，然后呢差不多是一千九百多个这个代码的这个文件，那么它总共的各式各样的分类呢？差不多是这样的这个情况啊，与它 模型 api 交互的核心代码，差不多是八千行啊，然后呢？这 curry engine 啊，推理引擎啊，差不多是这个 四万六千行啊，然后呢？工具系统啊，还有四十多个工具这个模块啊，差不多三万行代码啊，然后呢？什么这个终端 ui 渲染啊，差不多是两万五千行，剩下的这所有的哈，尤其是这个什么工程基础设施啊，总共有三十六万行代码，剩下这些所有的基本上都是为了啊，让当前这个 agent 给它约束，好 让它更好的去呃，这围绕长期这个问题来进行解决啊，所以呢，你会发现对不对啊？差不多这个百分之九十八啊，都是这个 harness engineering 啊里面相关的这个内容啊，这个呢，就是它完整的项目的这个代码，大家可以自己当下来去看一下，然后下面呢也有关于它的这个代码的 一个基本的这个分布物啊。好，那不管怎么样，我们接下来就来看看到底是怎么去解决这样的一些这个问题的啊，就是怎么去借助这个 harness engineering 这个架构呢，去解决它现在的这个啊，现在 a 证的长期稳定运行的这样的一些这个问题的 啊。当然其实讨论到这 harness engineering 这个的话，其实我们之前是呃有单独讲到过哈，这个 harness engineering 的 这个内容 哎，稍等，我们这个图它裂了啊，我们其实之前有一期公开课专门是讲到过啊，它内部的这个整个的这个 harness engineering 的 这样的一个这个呃基础理论，那么 对于 android big 来说啊，他会觉得整个的啊，这个按整个去构建它的这样高性能这个智能体，我们基本上是需要做好以下这么四个方面的这个工作啊。这个是它的第一版的这个想法。第一个呢是 context engineering 啊，就它上下文工程啊。第二个呢是 啊，我们如何协调内部的 agent 工作流和他的这个决策流程啊？第三个呢是提供高质量的工具接口跟工具描述啊。第四个呢是做好他的安全行为边界这样的个约束啊，差不多是他最开始啊是有这样的一套这个理论体系，这个是他自己的这个博课里面，这个呃博课里面来进行的这个介绍哈啊，当然这个理论其实说起来会比较 呃枯燥，我们接下来直接去看它到底是怎么做的，对不对？我们直接去看它这四个方面啊，到底是如何去解决的啊？那么它整个的 harness engineering 基本上就是集中在这四个方面的工程的实践。一个呢是所谓这个约束工作台啊，专门去进行上下文管理啊。第二个呢是它的这个记忆方面的这个管理啊，它呢是分成了三层来进行记忆管理， 这个记忆管理不仅仅记忆存储哈，还涉及到非常复杂的这个记忆处理的相关的这个内容。然后同时呢还有很多众生防众生的这个防御啊，和它如何来进行成本啊？这是 talking 消耗方面的这个成本的这个约束，我们先来看一下啊，是如何来进行实现的， 当然我们说对于整个的卡扣的来说啊，它的这个整体的这个架构啊，这个我们简单提一句啊，这个我们这个大家感兴趣可以自己去看一下，它的整个架架构其实分为五层的，分别是入口层啊，是是运行层、引擎层、工具能力层、技术设施层啊，差不多是分为这么五层的 啊，这个内容啊，但是入口就指的是它的所有的可以调用的啊，给它来进行信息传递的这样的这个接口，有一点像 opencloud 的 这个 getaway 啊，这样的一个这个系统啊，因为其实对于现在的 cloudcode 来说啊，它呢是可以 在，就比如说这个啊， kelly 啊，对不对啊？命令行里面来进行调用，可以在 id 里面调用，也可以使用这 sdk 啊，也就是这个 opencloud 啊， cloudcode， 不好意思啊， cloudcode 官方他们推出这个 sdk 对 不对啊？来进行调用等等等等。 然后同时啊还有这个运行十层啊，这个运行十层其实主要就是我们之前所说的啊，它的这 agent look 啊，这样的一个这个环节啊，只不过呢它的运行十层里面还包括啊，比如说这 r e p 啊，交互式的这样环境，还包括啊这个后壳的一些这个钩子，还包括它当时运行的过程当中状态的管理等等啊，这个呢是所谓的运行十层，那 再往下啊，就是这个推理的这个引擎层，对不对啊？主要是 q r n g 呢的管理以及呢 compact 非常非常重要的关于上下文压缩的 这样的一个工作的啊，这个实现，然后再往下啊，就是关于工具和能力层啊，内部工具怎么样进行实现，怎么通过啊？插件来进能力拓展啊，还有 m、 c、 p 跟 skill 如何来进行接入， 多 agent 啊，如何来进行复制和分发啊等等等等啊，相关这个内容啊，再往下还有更加基础的一些基础设施啊，什么什么的存储的格式啊，还有这个缓存的这个内容啊等等等等啊，这怎么一系列的这个总共啊，是这么五层啊，来进行的一个架构，当然我们这里啊，接下来重点是来探讨关于它的引擎层和工具能力层啊， 这两层呢，就是主要去解决我们上面所看到的这四个方面核心问题的啊，这两层的这个基本的架构 ok， 行啊，那么首先啊，第一个我们先来看啊，他的上下文是如何来进行管理的， 这个呢，其实是涉及到我们上面啊，关于这四层里边第一个啊，关于约束工作台啊，他的上下文管理的第一个模块的一些扣扣的一些这个措施。那么首先啊，这张图其实非常形象哈，就是它的适用于来去描述啊，关于你现在的 a 证在进行运行的过程当中啊，可能最开始 运行的还不错，对不对啊，是一个非常整洁干净的这个宽敞的这个桌面啊，运行了一段时间之后呢啊，这边乱七八糟啊，你就根本不知道如何进管理它整个的 a 阵呢，进行运行的过程呢，它的这个性能也会下降啊，这是一个非常形象的这样的比喻， 当然我们这里是以以两百两百 k talk 为例来进行的这个说明哈，实际上最新的这 cloud code open 啊， cloud open 四点六，实际上已经是全面升级到一兆风向文了啊，相当于是拓展了这个五倍， 那么这对于这个上下文来说哈，首先啊，两百 k 肯定是一个这个硬的这个极限，然后同时呢，大家也需要知道是他的这个整个 agent 啊，在进行运行的过程当中，他只要啊超过了差不多百分六十之后，他的整 个模型的这个注意力啊，实际上就会被稀释掉啊，也就是他的这个呃呃，他去进行长段内容的输出的意愿就会下降啊，然后同时呢，他对于之前的很多内容的记忆呢，也会下降啊，是那么一回事， 所以哈，也是因为他存在这两方面硬的杠杆啊，一个呢是他两百 k 只有那么长，或者一照他只有那么长哈，那么第二个呢，是你伴随增加的越多，哪怕你没有突破他的这个呃，最大上下纹的这样的限制啊，实际上他也会系的越来越模糊啊，也是因为这有这两层的这个限制，所以呢，我们才需要非常谨慎的啊，给每次的 运行啊，去构建一下上下文，对不对啊？那么在我们现在这个视力项目里面，就是这个 learn cloud code 啊，这个项目里面呢，它呢实际上是提供了一个叫三层压缩的这个策略的一个简单的代码的这个实现，具 体代码实现啊，上面有这个对应实现的这样的脚本啊，大家有感兴趣可以自己去这个运行一下。那么总的来说呢啊，我们说在一个简单的环境下啊，注意哈，一会我们会说哈，这 cloud code 实际上是这个五层实现啊，在简单的环境下啊，实际上大家需要知道是，首先呢是有这么三层的 这个压缩的这个策略是可以来进行选举的，第一个呢叫做微压缩 micro compact 这一点啊， cloud code 也有，那所谓这个 micro compact 它呢实际上指的是我运行很多轮之后，我就把之前的工具调用这个结果给它删了啊，是这样的这个情况， 那么呃，这一点其实也可以理解哈，因为很多时候我们在进行工具调用的时候啊，工具返回的信息其实是非常非常多的啊，就比如说我们查询的天气对不对啊？使用什么 api 查询天气，那么这个时候呢，那他在这个实际工具返回回来这个信息会很多，但 但是呢在当时那一次的绘画过程里面啊，你就必须得包含这一个工具返回的这个信息的这个内容啊，因为它需要依据这个内容呢给用户来进行回复，但是呢伴随着运行的时间越长啊，那么之前的工具 加载这个这个加载的这个内容呢，可能就不是那么重要啊，所以呢我们就可以把它删掉。一般来说呢，是在三到五轮对话之后，那么之前的工具调用这个结果就可以直接把它删了啊，这个呢是指的是这个微压缩，那微压缩基本上是一种无损的一种压缩这样的方法哈，因为毕竟那些工具调用这个信息可能也会不变的，不是特别重要，但这里有一点其实是需要这个， 那这需要说明的一点就在于说我们现在去使用一些 agent 的 skill 啊，大家都知道啊，这个这个 agent 的 skill 啊，它呢是一个灵活自动加载加载的这个上下文，它是一种提示增强了这个策略啊，有了这个 skill 之后呢，这个模型啊，它就它就具有某方面这个能力了。但是这里呢，需要知道的是这个 skill 的 这个加持啊，它呢实际上 也是通过外部工具这样调用啊，通过这个 function response message 的 方式加载到当前的上下文里面来的啊，所以你的这个 skill 啊，它也是会伴随着我多对话几轮之后，它之前你加载调用过的那个 skill 就 忘了啊，会存在这样的这个 情况啊，所以呢，这也是提醒我们在使用 cloud code 的 过程当中啊，你如果你总是需要某一个 skill 啊，你下一次再进行运行的时候，那还需要再把这个 skill 加载加载进来啊，因为它运行两轮之后，就会把之前加载进来这个 skill 给它删了，以维持上下文的，这个对不对啊，不要太长了这样的状态，这是第一个， 第二个呢就是关于自动压缩啊，第三个是手动压缩啊，当然这两种压缩呢，其实呃，都是这个压，都是呃这个同一套流程啊，只不过他们各自压缩的这个方式不一样啊，这种压缩往往是采用这个摘药这样的个形式对之前内容来进行个总结啊，你可以 这么来进行这个理解啊，只不过呢，一个呢是到达预知之后自动来进行处罚，一个呢是手动来进行处罚啊，但是总的来说它都是 compact 这样的过程， 那么这三种压缩策略可以说是非常典型的啊，也非常呃，这个非常通用的啊，这么个压缩策略啊， cologold 是 这样啊，我们现在这个势力项目是这样啊，然后这个 open cologold 也是这样啊，基本上都是这样的一些这个压缩这个策略啊，这种其实属于 一个非常通用的啊，压缩这样的方法。当然啊，下面其实还有啊，具体的代码实现的这个过程啊，大家感兴趣啊，可以自己去运行一下，我们课程就不展开讲啊，因为 cologold 它这个架构内容很多啊，很多手动实践的内容，大家可以去进行实践一下， 然后具体它的 compact 啊，这部分的这个内容，尤其比如说我们刚刚说不是说这个 micro compact， 对 不对啊？这个运行几轮之后，把之前的这个工具栏给它删了哈，这个，呃部分这个源码呢，是在这个 service， 在 s r c 啊，然后呢 services 啊，下面 compact 啊里面这部分这个内容啊，你看它这个 compact 啊，光是这 compact 就 有这么多 哈哈的这个内容啊，这个其实这段原码非常精彩哈，因为之前很多同学一直在问啊，说 cloud code 它是怎么样来进行压缩的，为什么感觉我们会感觉 cloud code 压缩了之后呢，效果性能非常不错啊，跟这个普通的比如说 open code 压缩之后，他基本上记不得之前的这样的信息了。那么其实，呃，大家如果对这种感兴趣的话，就可以看一下啊，它这个 compact 的 这部分原码里面到底怎么写？ 这部源码其实非常复杂，它还包括一些康啊，一些这 compact 过程当中的一些这个 prompt 啊，它内部的这个 prompt 是 怎么写？因为它在进行压缩的时候，其实并不是一个机械的压缩的过程啊，由于它需要涉及到这个 summary 嘛，所以呢，它是内部会调用这个 sanate 那 个模型，就中杯那个模型啊，来围绕你之前的这个信息内容来进行一个提取，来进行一个格式化的这个提取， 同时呢，他还会留下你最近那几几次对话的这个 to do list 啊，就是没有完成这个事项，所以呢，你才会觉得说啊，一方面他好像也记得之前这样的事情，一方面又帮我腾空上下文啊，同时呢还能够顺着你这 compact 的 之前的这个事项来进行运行，哎，感觉非常不错啊。其实这样的一个这个原因在里面啊， 这里面大家看的清楚的话，可以自己去看一下啊，这部分，这个原版啊，这部分其实还还是非常精彩的哈，当然就对于 o o cloud code 来说啊，它会啊，什么最近三个工具这个结果不压缩啊，之前都压缩啊，是不是这个 读文件的这个结果永远不压缩啊，然后呢，这个因为这个读取进来这个内容嘛，所以不能压缩，等等等等啊，有很多这个具体压缩规则啊，这个呢是第一个 micro compact， 这个呢叫做自动压缩啊，自动压缩就是指的到达预值之后呢，哎，自动给它来进行压缩啊，当然这个 auto compact 啊，在这 compact 里面啊，在 cloud code 里面也有对应的这个原码，对不对啊？到达预值之后呢？哎，自动的啊，来进行一个这个 来进行一个压缩啊，这里面有非常多的啊，它这个什么预值的这样的一个设计啊，然后呢啊，到多少的时候就来进行触发，等等等等啊，一般来说啊，差不多在百分之八十 到九十左右，它就会触发自动的这个 auto compact 的 这样的过程啊，它是不会到百分之百才进行触发的啊，因为它在它在进行，在在进行最后的 compact 过程当中，它还需要腾出一部分上下文来围绕之前内容来进行一个总结啊，所以一般来说是百分之八十，百分之九十啊，当然我记得最新的这个呃 cloud code 也是呃 二点一点九零这个版本啊，应该是百分之九十二啊，作为预值啊，这个大家感可以感兴趣的话自己去看一下啊，然后呢来进行一个这个压缩啊，差不多这么样的情况，然后除此之外呢，还可以手动压缩，对对，手动压缩跟这个自动压缩跟这个 autocap 的是有一样的这个过程啊，只不过的手动手动压缩呢，是通过 这个斜杠命令来进行的这个触发哎，然后呢它这个手动压缩呢，跟这个 auto compact 啊，基本上是完全一样的这个流程啊，只不过它是允许你在任何时候啊都来进行一个啊 compact 这样的一个操作啊。当然其实如果你不需要这 compact 的 话，你可以直接杠 clear 就 把它删了啊， 这个也是可以的。好，那上面呢是关于这个 open cloud 啊，关于 cloud code 啊，它的一些基本的一些实现方法啊，就我们刚刚所说的 micro compact 啊，然后呢 auto compact 啊，还有这个 menu compact。 那么除了这几种 compact 之外啊，我们说其实 oppo 还有很多的非常精彩的关于它来进行压缩过程当中啊，一些这个啊，所谓的这个防御策略啊，或者说它在压缩过程中可能出现的问题，如何来进行解决啊？你可以这么来进行理解 啊，这里也有四层压缩防御策略。首先啊，第一个肯定是 oppo compact 啊，它会临临临临近上下文的时候呢，自动啊来进行触发。然后呢， oppo 这个 micro compact 当然也是啊，全自动的来进行一个这个触发啊，但是呢，我们说你 compact 可能会 存在一些这个问题，对不对啊？所以呢，当它当它你的 compact 没有办法来进行这个 summary 总结的时候啊，它还会有一个叫这个 reactive compact 啊，这样的这个流程啊，指的是 api 调用，呃， api 调用这个 sunny 的 这个模型 api 来进行 summary 的 过程当中，如果报错了啊，它呢就会啊，这个触发叫所谓的啊，这个 reactive 啊，叫呃 reactive compact 这样的这个流程。 而 reactive compact 这样的这个流程啊，它呢，实际上一旦出发了之后，它就会使用这个 snip 的 这样的方法啊，直接呢大刀阔斧的啊，来进行一些这个压缩啊，或者直接删除上下文啊，这个呢，是有可能来进来这么来进行操作的。 它一般来说哈，这个 reactive compact 其实并不会特别常见啊，因为其实对于现在的这个 sna 的 这个模型的调用来说，相对来说还是比较保险啊，但如果确实是没法出现的话，它就会使用这个 snip， 对 不对啊？来进行一个简单粗暴的啊，这个 完整的呃，大段大段的原始内容的这样的一个这个删除啊，当然在 compact 过程当中呢，它还会出现这个啊，出现一些这个循环啊，因为 compact 的 内容呢，很有可能再次被 compact 啊，这个呢也是有可能的啊，然后呢 它对于啊这个地规呢，还有一些地规的这个防护啊，所谓地规防护指的是我上一次 compact 的 这个内容，这次呢如果按照正常 compact 的 这个过程来说的话，它呢可能会被 大幅的这个降低权重啊，但是呢之前 compact 的 内容往往它可能是比较重要的这个内容啊，所以呢它在下一次 compact 过程当中啊，会尽量的保存你上一次已经 summary 之后的啊，这样的一些这个内容啊，是 这么样的一个这个情况，但是这么样的个情况大家也能够感受到，对不对啊？它迟早有一天会 compact 不 下来啊，就是我们的 compact 之后呢，你的上下文并没有压缩特别多啊，这个时候呢可能就会触发我们上面所说的啊，叫做这个 reactive compact 这样的这个流程啊，它就可以开始给你直接删了啊，是 什么样的这个过程啊？所以呢这个 reactive compact， 它不仅这种是 api 要用调用错误的时候可能会触发啊，你这个 compact 不 下来的时候，它也可能会进行触发， 对不对啊？然后呢这里面啊 compact 这个代码大家可以自己去看一下啊，总之呢这都是在这个原始文件里边啊，然后同时呢除了啊它的 compact 这个策略之外呢，它还有啊叫五步流水线的这样的一个这个处理策略啊，这个呢实际上是它的每一次消息在进行构建的时候，它还会走一遍这样的这个流程啊， 这个流程呢跟上面这个流程其实很多是重复的哈，只不过上面这个流程呢是呃跟着你现在到达某一个预值或者手动输入一些斜杠命令来进行触发啊，来进上下文字压缩。然后下面这个流程呢，实际上是你每次在 在构建这个 system 啊，在构建你的这个 message 的 过程当中呢，会这么样啊，来进行一个这个处理啊，这个呢，大家可以啊自己来去看一下啊，那么其中呢 compact 也是一样的啊，因为你 compact 不 仅仅是在到达预值的时候会会这么来进行一个处理啊，你每次构建构建上下文的时候，它也会啊来进行一个啊简单的一个 compact 的 这样的过程。 然后同时呢啊这里有一些非常有趣的一些地方在于说对于当前的 cloud code 来说，在某些情况下啊，它呢实际上是会把你输入的问题来进行一些重写，可以进行一些优化的啊，这个呢其实是一些 非常细节的一些这个点啊，然后呢他会觉得你这样的这表述其实是会存在一些问题的啊，所以他会对你当你的这个原始这个问题呢啊，来进行一些这个优化啊，当然他也会有这个 prompt catch 啊，对吧？啊，提示词缓存的这样的个策略啊，提示词缓存我们会放在后面统一来讲啊。那总之呢，大家需要知道的是啊，它的这个 compact 啊是 怎么做的啊？然后呢啊，它这个整个的啊，是如何来进行上下文的啊这个压缩的啊？当然其实啊，不管怎么样啊，我们说 compact， 它呢肯定是进行有损的啊，肯定是这个有损类啊，肯定也是这个不可逆的啊，因为之前其实经常有同学会问到啊，说这 cloud code 啊，这 compact 跟是不是这个无损这个压缩啊，但其实只要是压缩它就是有损啊，这个其实 啊不用考虑啊，它肯定是这个无损啊，只不过呢，对于现在的啊这个 cloud code 来说啊，它呢其实并没有采用像 openclock 啊这个 rack 解锁这样的一个这个方式啊，它呢实际上就是单纯的压缩，压缩完了之后呢，把所有上下文带入来进行压缩 啊，代入呢来进行一个这个问答。而啊，就比如说像，呃，这个，呃 open clock 啊，它呢实际上是先它是，它呢实际上是超过了预值之后呢会对它的这个 memory 啊，来进行这个 red 的 这个解锁啊，是这么样的一个这个这么样的这个情况，这 两者他们的技术方案呢，实际上是有区别的啊。当然其实就目前的实践情况来看，如果是普通用户在进行使用的话，肯定会觉得这个 clock code 其实会更加的这个友好一些， ok 啊，怎么样这个情况？ 那当然下面还有一些具体的这个细节方面的这个展开的这个说明哈，我们就不继续来进行讲解了啊，大家感兴趣的话自己看一下里面的这个文字。好，然后呢，有一个非常有趣的地方，我们刚刚不是说到 这个 cloud code 啊，它呢实际上是会对用户输入这个内容啊，你在构建上下文的时候，它就会来进行一轮感知，甚至是来进行一些这个修改啊，甚至是把一些重要或者不重要上下文的来进行加载和这个删除，去构建你当前这一次绘画的这个 message 这个列表，这里面操作非常多哈，我举一个小例子啊，大家能感受到它是怎么样 去啊，做到这个非常细节的这一点的这个优化的，就比如说如果你对 cloud code 骂街了，哈哈哈啊，就比如说你说啊，这不不是，就比如说 啊，那就用户的这个情绪啊，上头了啊，对不对啊？用户觉得说啊，你这个做的简直是垃圾啊。那个你这个完全不懂我的这个意思，跟你说了多少次，然后晚上你还是做不对啊，对不对啊？就是如果用户骂街了啊，那这个时候呢，扣扣的就会自动的去检测你上下文，会发现，哎，这个时候呢就触发了啊，所谓叫做这个 沮丧检测的这个机制啊，之后呢啊，他呢实际上就会迅速的啊，来进行一个这个 经典上下文，然后围绕当前这个问题来进行快速的响应啊，他会做这样的一个这个事情啊，并且这个过程他是使用 这个呃正则呃观正正则表达式来进行的剪辑和这个匹配啊，他会有这样的一个啊响应的这个方式啊，这个呢，其实是一个小这个小彩蛋啊，这个大家发现了之后呢，发现啊，这个有这个技术人员发现这个细节之后呢，会觉得很有意思啊，这个 open club club 呢，它其实进行了非常非常多细节方面这个优化， 这个呢是第一方面这个优化啊，总共四个方面优化哈，我们讲完第二个方面，我们再啊中场休息，然后再来进行一个这个啊，再来进行答疑，然后第二方面这个优化呢，实际上啊，是更好的去每一次去 folk 啊，或者说或者说去实力化多个 agent 啊。那么这个呢，也是呃， cloud code 的 一个非常核心的 一个架构方面这样的一个亮点吧，那比如说啊，我们现在呢，每次开启这个 agent 啊，由于呢他其实并没有上下文啊，所以呢他其实什么都不知道啊，这个时候呢，你可能就需要按需呢，对他对这个上下，对当前这个 agent 来进行一个知识的这样的这个贯注，对不对？ 那么呃，我们之前在讲 opencll 的 时候啊，其实当时讲过 opencll 的 内部有非常复杂的提示词模板，然后呢我们需要去组建非常复杂的内部这个提示词，然后才能够去开启一个又一个的这个一个又一个 opencll。 那么对于 cloud code 其实来说其实也是类似的啊，然后呢 cloud code 它内部呢，也是啊，每次在运行之前呢，会有非常多的啊，一些这个扫描，我们下面应该会有一个完整的一个这个层级记忆的这个层级的这个图啊，那么 cloud code 呢，是按照这样的个记忆层级来进行剪辑跟架构的。 上面哈，其实有一些啊，上面我们讲的它什么自动加载 system prompt 啊，自动加载这个 skills 啊，然后呢是如果有需求的时候才会去加载对应的这个 skill 啊，这个呢是属于所有的 agent 呢，基本上都是这么通用来进行的。这个执行我们直接看它，像它 对于 cloud code 来说，它的这个整个的新开启的这个 a 阵的记忆架构差不多是这么三层啊，第一个呢叫做 memory 点 m d 永久记忆。第二个呢叫 topic files， 按需加载啊。第三个呢叫 transcripts 啊，只只搜不加啊，差不多是这么三个不同类型的层级的这个记忆。 那么 memory 点 md 这个很明显对不对啊？每次呢它都会啊这个来进行一个加载，那么一般来说哈，呃，当然我们我觉得现在可能很多大家在使用在 cloud code 的 时候，可能压根就不知道啊，它有 memory 点 md 这样的文件，是的，这个文件不对用户开放啊，这个文件呢，是纯粹的，它内部会通过一个非常精妙的过程来去维护的一个高质量的这个记忆文件， 它不是简单的啊，你要记住什么，它就把它写到哪啊，不是这样的，它内部有一个记忆的加载、清洗、分门别类存储，然后记忆的优化，一整个非常复杂流程，共同去维护这个 memory 点 md， 所以 这个 memory md 呢，对用户是不开放的啊，你就去改了，很容易把它改毁了啊，你也不能够去改它这样的文件 下面啊，这个所谓的 topic files， 它呢指的是针对不同的这个事项啊，它呢其实是会有对应的这个存储的文件的，然后这个存储的文件是可以通过 memory md 来进行锁影的，比如说你哈记住一百件事情啊，那一百件事情可能都没有办法全部给它放到这个 memory md 里面，它就需要分门别的来进行存储，然后呢按需来进行锁影， 那么再往下啊，这个 scripts 啊，那么 scripts 呢，实际上就是关于历史的这个绘画了，那么历史绘画其实大家都知道啊，一旦我们现在在 carco 进行 compact 之后呢，历史绘画就不会再再进行加载了，但是呢，历史绘画它是会在本地来进行一个永久的这个存储的啊，所以呢，如果有需要啊，它呢实际上是会通过这个 啊， grab 这个非常简单的这个匹配解锁这样的方式呢，去找啊，你之前的历史对话啊，这也是通过命令行工具啊，直接使用这 grab 的 这样的脚本啊，就可以去匹配啊，去寻找你的一些历史对话。差不多是这么样的这个情况啊，这个呢，就是整个的啊，关于 cloud code， 它的一个永久记忆的这样的一个基本的这个架构啊，当然其实 除此之外啊，这个我们刚刚也说啊，它的什么啊， system prompt 呀，它的这个 skill 啊，也是按区加载的呀，那块其实我们刚刚跳过了啊，大家如果感兴趣可以翻到前面来去看一下啊，那我只觉得这段呢会非常精彩啊，所以呢，给大家来进行一个分享。 ok， 好， 那我们先看啊，这个 memory 点 md 啊， memory 点 md 呢，实际上都是通过啊这个 memory 的 direction 点 ts 啊，这样代码来进行的这个维护啊，它里面呢，实际上是有一套啊，非常精妙的这个维护的这个过程哈， 那么它在记忆的过程当中呢，它会不断地去识别 user 啊，不断地去啊，记住你的行为偏好啊，不断地记住你当前的这个 project 啊项目这样的信息啊，然后呢会去记住资源的位置，这个呢是它构建它当前的这个记忆最为核心的四个要素啊，当然这个四要素它实际上是会伴随着这个运行不断不断来进行加深的。 举个例子啊，就比如说我们在使用 cloud code 的 时候，其实你会有这样的感受哈，就比如说你最开始没有跟他讲过你叫什么名字啊？但是呢，如果在某一个项目里边，哎，你透露了你叫什么名字，你是在干什么的啊？那么其实哪怕你没有让他记住这个信息呢，也会啊，在他的这个漏斗状的这个筛选的过程当中，不断不断的啊被筛到这个 memory 点 md 里边 这么样的这个情况，然后呢在这样的一个啊，这个 memory 的 这个记忆的过程当中啊，它不仅仅是说会围绕这四个非常核心的记忆类型的，有针对性的啊来进行一个这个记忆，然后同时呢 它有很多的啊，一些写入记忆的一些这个纪律，对不对啊？比如说它这个这个很多时候啊是先 先进行缩影啊，再去先创建这个缩影，就是创建这个 topic 的 这样的文件，然后呢再写入到这个 memory 里边。再比如说对于 memory 来说，它呢只会解锁前两百行啊，超过前两百行之后呢，就需要啊给它进行一个这个归类，就需要来进行一个精简，就需要把它放到比如说某一个 topic 里边去， 不断不断的啊来进行一个这个精简跟迭代，然后这个呢是它的这个 memory 啊，部分的这个文件的啊，文件的修改这个流程， 当然下面其实有一段哈，就是关于它的 auto dream 啊，这个 auto dream 呢，实际上是呃整个的 cloud code 非常精彩的一个这个设计啊， 当然上面还有一个关于 cloud cloud 点 md 这个文件，这个加载啊，这个我们就不说了啊，因为这个文这个呃记忆文档，其实是我相信大家其实用 cloud code 其实都会用到过，对不对？你需要在根目录里面创建一个 cloud md 这样的文件，然后它呢其实就是你的 system prompt 啊，的一个最核心的加载的这样的这个文档。 那么呃我们现在来看啊，惯常的 auto dream 啊，这样的一个这个自动的去清洗啊和沉淀记忆的这样的一个流程。 哎呀，说是这个流程，其实上非常的这个魔幻哈，就是我们在实际上呃 cloud code 的 时候，如果它是在你当前进程持续运行啊，但是呢某一些间隙的时候，实际上这 cloud cloud 呢，它是会开始做梦的啊， 它是会有叫睡睡眠记忆巩固的这个时间的，它会在内部悄悄咪咪的 fok 一个 agent 啊，然后呢去审查自己的这个记忆，再根据我们当前白天对话的核心内容去选择性的巩固或者删除一些记忆 啊，这个呢叫做 oto dream 啊，在这个做梦哈，那在利用睡眠来进行记忆巩固啊的这样的一个非常神奇的这个流程， 这东西其实确实这个说起来非常的这个魔幻啊，但是呢它确实是会这么做的啊，首先呢在它空闲的时候啊，就会自动的来进行这个触发啊，然后呢呃它呢？这个呃会单独的 fork 啊，单独创建一个 agent 来去做这样的事情啊，不影响主程序的来进行这个运行。 然后呢，接下来啊，它会去看啊，你当前对话所有这个时间戳对不对？就我们刚刚所说的啊，你越近的这个对话呢，它的这个权重就会更重一些，然后来进行一些这方面这个梳理啊，然后最后呢，单独的啊 for 可以 一个这个 agent， 然后呢通过当前这个 agent 去整理你的 memory 点 md 这样的文档啊， 所以呢，它的这个 memory 点 md 呢，是一个非常非常复杂而且精妙的这个设计的过程啊，不像 openclo 一 样啊，你让它写入它就写入，写入完成之后呢，这个 memory 太长了，就直接来进行 rec 解锁啊，并不这样啊，对于 cloud 来说啊，由于它是通过这样的一个可是非常神奇的这个维护 memory d m d 这样的一个文档的方式啊，所以它其实并不需要啊，所谓的这个 rap 这个流程来进行解锁啊，因为它的上下文呢，其实它的这个上下文其实能够被能够来进行非常好的这样的控制的， 而且 cloud code 本身它对用户的要求也会非常高啊，就比如说我们上面所看到的 cloud 点 m d 这个文件，对不对？那么这个文件呢，其实是所有的 cloud agent 每次在进行运行之前，它都会加载的这样的这个文件。那么只不过啊，大家可能之前不知道的是，对于 cloud 点 m d 这样的文件呢，它和其他的 skype 一 样，只会最多加载五百行， 更多它不会加载了，哈哈，所以呢，你对于 cloud md 来说，你写的再多啊，这个这个意义也不是特别大啊，所以呢，它呢， cloud 它是会盗弊用户，我们在进行实际使用过程当中呢，你得想办法啊，去 主动地去精简这样的一些这个记忆，主动去精简你希望主动让他记住的这样的些这个东西。而它自己维护的这个 memory md 啊，这个呢，是它自己维护的，他们共同构成每次对话这个上下文，那它呢，实际上就会， 对不对啊？这个什么 auto dream 啊，然后呢，它又什么这个啊，会呃，创建一些这个 topic files， 对 不对啊？分门别类的去存储记忆等等等等啊，这个呢，是它自己会去做的这个事情。而对于像 cloud 的 md 啊，需要用户去做的啊，它就没有太多的这个要求啊，跟你说，反正我只读前五百行， 那你自己看着办哈，对不对啊，你自己想办法来对它来进行优化啊。当然其实 cloud 它也有一些 skills， 能够去帮助你的 cloud 点 m d 来进行一些上下文章的优化啊，这个呢就属于应用层面上这个东西了啊，但不管怎么样， 对吧？啊，我们通过这样的一些这个流程啊，还有上面的源码的一些这个实现啊，大家能发现整个的 cloud 啊，它在构建每次对话啊，每个新的这个 agent 的 这个时候啊，它的上下文呢，是如何来进行的创建啊？这里面呢有呃呃，大家如果想看更加详细的源码的话，可以 去找到啊，我们的这 auto dream 啊，点 t s 的 这个文件里边啊，里面呢有非常详细的关于它是如何引导如何 fork 一个当前的 agent 去整理自己的记忆的啊，包括什么审查呀，强化一些东西啊，删除一些东西啊，如果存在矛盾应该如何来进行处理啊？然后如何啊？把 这个什么模糊洞察转化为确定事实啊，如何去重组当前这个记忆啊？哎呀，这个流程其实非常复杂啊，如果有机会的话，我其实还是非常 电影展开跟大家说的啊，因为这个其实还是非常精彩啊，去整理他这个记忆比简单的啊，什么寄到本地文档，再通过 red 来进行剪辑，要好的多啊，要好的多， ok， 当然下面还有一些这个安全的这个措施啊，当然他这个也会有一些这个啊，也会有些这个局限啊，因为他的记忆组装好坏，其实会跟他当前这个模型呢，会有直接的这个 啊，直接很大的这个影响啊，当前模型如果指令跟随能力强的话，那么他记忆组装的其实就会更好。但下面还有啊，什么分层的知识注入啊，然后呢，还有下面的什么提示词啊，什么六层动态组装啊，这些东西呢，其实都是属于怎么去更好的去维护他当前这个上下文的，那这部分其实并不会特别复杂啊，这个大家可以 自己回头去看一下。好，那么到这啊，我们就觉得基本上对于像 cloud code 啊，它的一些架构，就我个人觉得比较精彩啊，两个方面的这个内容啊，一个呢是如何来进行 compact， 对 不对啊？去压缩上下文，够压缩上下文啊，去构建更好上下文工程啊。第二个呢是如何修改它的这个像整个 agent 这样的个记忆， 这两方面的核心的我觉得比较亮眼，功能呢，都就都跟大家讲清楚了啊，那么接下来呢，还有两个方面， cloud code， 它的这个项目架构的优化，一个呢，是 啊，关于他是如何做这个安全检查的啊，第二个呢是他是如何去抵抗啊，一些这个知识的商增的啊，这两部分的这个工作啊，那么接下来啊，我们先稍作休息一下啊，然后呢，我们再来讨论啊，这两部分的这个内容。 ok， 那 我们说了这么多 啊，原理层面的这个，呃呃，原原，原理层面这个问题啊，我觉得很多同学可能都已经有点晕了啊，对于 cloud code 来说啊，它这个，呃，确实。嘿，我们接下来是讲 antispac 的 cloud code 的 最后两个非常核心的架构，一个呢是它的安全防御策略， 一个呢是他的对抗知识商商增的一个这个策略 pdf 里面图是，好，那我们就对着 pdf 来讲，大家看到这个 pdf 里面图应该也是也都是应该，应该也都是 ok 的， 我们是从安全， 其实这个安全呢，不仅仅是啊，它会被有害，而且很多时候指的是对他行为的一些这个约束。 ok， 好，从这啊开始继续好，那么了解啊，关于 cloud code 的 一些很精彩的一些这个架构，对不对啊？上下文怎么管理的呀？这些记忆是怎么约束啊？记忆是怎么优化的呀？之后接下来我们再来看非常重要的一个问题啊，就是 cloud code 啊，它的安全性啊，是怎么做的啊？ 这也是我们现在很多在运行 agent 的 时候啊，开发者经常会非常头疼的一个这个事情啊，对不对啊？怎么确保这个我的 agent 它不会做一些有害的这个事情呢啊？那么其实 cloud code 开源之后呢， 泄密了之后，哈哈啊，是给大家有一个非常直观的一个这个感受啊，或者提出了一个非常通用的这样的一个范式啊。当然，其实我们 说伴随着你 a 证本身的应用面越来越广啊，你可能会面临的啊，什么投毒啊，或者其他的些恶劣的情况肯定会越来越多啊，这个属于魔高一，这个魔高一尺，道高一丈的这个事情啊，但是呢， cloud code 确实给你提出了一套作为基础的啊，所有的 a 证都可以上来就可以用的啊，这一套安全的这样的措施，我们看他是如何进行实现的。 首先哈，我们其实呃都知道啊，对大模型来说，他他他有智能啊，所以呢，他的这个安全措施跟跟普通的安全的这个软件啊，可能会不太一样啊，我们其实更多的是需要去约束好当前的 a 阵的这样的行为，才能够防止他作恶。 那么对于像 cloud code 来说啊，他是怎么样啊，来进行的这个思考呢？或者他整个架构是什么样的，基本上是按照这样的架构来去走啊，这个架构应该还是非常清晰的一个这个一个架构哈， 首先第一层啊，自我穿匹配啊，然后第二层呢，正则匹配啊，第三层呢是白名单分类啊，第四层呢，是独立的大模型的对抗审查啊，第五层呢，是人类来进兜底啊，差不多就这么五层的，这个五层的这个措施啊，但这五层措施呢，从上往下啊，这个难度一次增加，然后同时呢它的工程实现的这个复杂度也是在逐渐增加的。 首先啊，第一层啊，关于这个自产匹配，这个其实非常简单啊，就比如下面有个，有一个这个代码啊，基本上就是类似于类似类似像这个代码就可以，就可以就可以能够来进行实现了啊，就比如说无论如何都不能出现在你命令行里面的啊，这样的一些这个 呃这个命令的关键词对不对啊？什么 rf 啊， r m 啊等等等等啊，类似这种啊，然后呢直接把它过滤掉啊，这个呢是第一层啊，直接呢通过自传的自创的这个黑名单啊来进行匹配。那么除此之外，我们还可以更加复杂，通过正则来进行匹配啊，对不对啊？这个正则呢，就比自创表达式来进行匹配啊，它的本质呢仍然还是来进行的匹配。 那么第再往下一层啊，就是关于白名单啊和这个命令分类器啊，就它呢会我们会给出一个接下来啊，或许某一些这个命令呢，是 可以直接啊来进行这个执行的，然后同时呢会对所有这个命令来进行一个这个分类啊，如果你分类呢，最后呢是落到白名单这里，我们接下来就可以直接的来进行一个放行来进行运行。 那么再往下啊，就独立大冒险来进行审查啊，这个其实也会非常关键啊，因为大冒险他就会呃，从一个独立的这个角度啊，就不带入你当前上下文的这样的这个角度，他是一个独立的一个这个 sub agent， 然后呢去审查你当前这样的命令，是不是可以来进行执行的啊？这是第四层，然后第五层啊，就是关于人工来进行判断啊，差不多是这么五层的这样的这个架构， 那么在这五层架构里面啊，刚刚我们也说了这个审查的这个 a 证呢，其实审查大模型呢，跟你执行大模型，实际上它是完全隔离的啊，这两个大模型，一般来说审查大模型是不会带上下文来进行一个这个运行的。 那么最后啊，还有一层啊，关于这个人人类的这个兜底啊，所谓这个人类兜底，就指的是如果有确实不知道啊，这样的这个情况，不管怎么样，最后我们都会有一层啊，让人类来进行审核的这样的一个这个，呃，这样的一个空间啊，或者这样的一个通道。 这个呢，其实我们在平时使用 cloud code 的 时候，我相信大家应该也会遇到过类似这样的情况哈，就比如说哪怕啊，我们给他输入了一些这个指令啊，跟他说，他启动的时候跟他说这个， 呃，这个，呃， skip dangerous 啊，类似这样的这个命令啊，跟他说啊，我们这个他可以直接跳过人类审查这样的环节，直接自动来进行运行，但是你会发现他遇到很多他吃不准的这个东西哈，或者遇到一些比较高权限的这样的问题， 他还是会啊，来进行这个啊，就他还是会来进找人来进行审查啊。所以呢，其实关于这个人类兜底啊，实际上是他的一个不管怎么样都绕不开的一个。最后的这层的这个策略 ok 啊，是这样的一个基本的分类，这样的方式，然后他直接进行审核的时候呢，也都是啊，先看规则啊，再看这个有没有风险啊，再看白名单啊，再看这个大模型分类啊，通过一层一层来进行筛选啊，然后呢，如果规则没问题就直接走了啊，如果规则有问题，我们再来看啊，是不是有 风险啊？有风险我们再看看它是不是白名单啊，白名单就可以放行嘛，对不对？如果还不行啊，就大模型对抗啊，来审查一下啊，然后最后呢啊，还再不行，交给人类来进行审查啊，就这样的一个逐层的啊，来进行审查的，这样的，这管线， 这个实际上是一个非常通用的哈，基本上所有 agent 你 如果要考虑这个啊，考虑安全性的话，都可以这么来做哈，然后呢，对于 cloud code 来说，它的这个 security 点 gs 这样的一个呃，点 ts， 这个呃 代码里边哈，这个大家可以自己去看一下，里面它有非常非常多的啊，一系列的这个安全审查的一些这个事项。然后呢，这些安全安全审查的这个事项啊，其实是我相信对于很多现在做 a 证安全的同学来说，是个巨大的数字资产，因为它这里面很多的 这个安全审查的这个事项哈，都是之前长期的被攻击过之后积累下来的这些规矩或者经验哈，这个其实我们很难一条条跟他讲清楚哈，但是这里面确实有非常非常多安全审查的这个事项，也就是他第一层啊，这个规则啊，他就积累了很多之前踩坑的被攻击的这样一个经验啊，你想想这些经验对于很多的 a 证的开发者来说，当然是这个 这个这个无价之宝这样的一个东西啊，当然这里面大家可以在这呃原码里面能够看到哈，它里面到底是 啊怎么样去进行的这个审查啊？然后同时呢，呃，他还有很多的啊，他真的是这个属于这这被攻击久了就攻击出来这个经验啊，什么临宽制服与控制制服的啊，这样的一个这个防御啊，什么这个什么这个制服里面啊，由于由于我不是做安全的，所以我不是特别了解 啊，这里面到底是什么什么个这个情况啊，但是大概能够明白啊，是说一些非常特殊的攻击的这个指令啊，他其实会通过啊，里面去加入一些什么临宽制服啊，或者控制制服啊， 能够去规避掉啊，它的一些基于规则或者基于准则的这样的检测啊，从而绕过它的这样的防御，然后呢去攻击当前这样的系统啊，所以呢才会基于这样的个问题啊，再来增加对应的啊，这个防御的这个措施等等等等啊，总之呢，其实都是在 这个啊， best security， 点 g s 的， 点 t s 的 这个文件里边啊，这个大家可以自己去看一下，然后呢在这个文件啊，然后呢现在其实对于像 cloud code 来说，它的核心的 c m d 啊，防御它的这个 best 命令行相关的这样的攻击啊，其实其他方面的 攻击并不会涉及到你本质电脑上的这样的一些数据的这样的损坏啊，或者他直接盗取你一些这个文件等等等等啊，这个其实做不到的，其实它最核心的攻击的这个点啊，或者是 它的这个最大的风险这个点啊，所以主要还是要命令行工具的这样的一个使用啊，所以你会发现它基本上所有的这个 security 呢，都是围绕着命令行的这个 best tour 展开的啊，其他的一些这个 tour 呃问题不大啊，其实它往往没有被攻击的这样的一个这个价值。 然后同时呢对于 cloud 呃扣子来说，他的实现这样的这个方式，当然我们刚刚说了，对不对啊？这个总共是这个五层啊来进行的对抗，那么除呃五层来进行的这个审核分别是规则啊，然后呢是这个 啊，正则啊，然后呢是这个白名单，然后呢是大模型，最后呢是这个人工来进兜底，通过这五层来进行的一个这个搭建的一个基本的安全的防护网络。 那么除此之外哈，其实对于 klopp 来说，由于他现在还提供了很多那些企业或者团队内部的这个定制这个版本啊，所以呢他还有很多的围绕的一些给企业提供定制款版本的时候啊，他的些企业的一些特定的啊，一些这个呃安全的这个措施，他其实也会 写在 club code 现在的这个圆码的这个项目里边啊，这个的话就如果是大家去开发企业级定制的，并且是允许啊，企业里边我们去单独的给企业内部的这个企业内部的 a 政设置一些防御测试的话，那么这部分啊，是非常值得大家来进行一个这个学习跟观看的啊，就是什么呃企业内部有统一的什么策略呀？然后呢？有什么 这个呃规范的命令行参数的书写格式啊，还有个人默认的啊，这个纸等等等等，会有这么个五层的 这样的一个这个权限的这样的一个设计啊，这个其实更多的是一些定制化开发这个场景啊，这个大家如果感兴趣的话，可以在这下面能够看到啊，但总之呢他的这套这个防御的这个措施还是非常完善的， 那么除了可以提供一些定制化的防御措施之外，还有什么？这个三三个平台啊，各自有各自平台的这个沙河环境啊，可以来进行一个这个运行啊，沙河环境这个我们之前讲过很多次了，对不对啊？ 沙河环境呢，相当于是提供提供一个隔离的独立的一个虚拟环境啊，来进行运行，那么你在这个环境里面进行运行的话，任何的一些有害的指令都影响不到你当前的这个主命令啊，主系统啊，这样的一个这个情况啊，这个呢是他的沙河环境啊里面来进行运行，然后同时呢他还有啊这个默认的一些安全检查啊，这个安全检查呢，实际上是每次启 动过程当中啊，他其实都会默认来进行一轮的这个执行，那么这个安全检查啊，实际上也都是他之前啊这个积累下来的这些坑，对不对出现的这样的这个问题， 然后同时呢它还会有一个啊断路器这样的机制啊，所谓断路器这个机制指的是如果我的 a 证在进行运行过程当中连续撞墙啊，就是他反复去尝试一些这个问题呢，他始终没办法得到解决啊，那么他就会判断，哎，你当前的这样的一次这个尝试或许是有毒有害的，那么之后呢，就会尽量避免出现类似这样的情况， 那这个断路器这个设置和安全这样的问题呢，因为他可能会存在一个暴力破解的这样的情况 啊，所以呢，它的这个所谓断路器这样的设置哈，其实它是一个强硬的这个规定啊，就出现连续三次被拒绝啊，或者连或者累积二十次被拒绝啊，那么它呢就会自动降级你当前的这样的一个这个命令的这个权重啊，换而言就是它会更加倾向于去拒绝执行当前这样的一个这个命令啊，是这样的这个情况， 这呢是一个断路器的一个设置，会在实际运行过程当中不断的来进行积累，当然它的这个氧氣的防御措施，还有一个还有一个方面的这个防御啊，确实是这个久经沙场 积累他的经验啊，就是他还有一个反蒸馏的这个防御啊，这个其实出来之后也非常精彩啊，这个因为安萨佩前段时间还说啊，他的这个模型啊，这个很多被被别人的壳扣子反复吊用来进行蒸馏，对不对？蒸馏别人家的别人家这样的模型啊，然后呢，呃，这个这个大家这个网友就批判批判他啊，说你的这个模型难道不是蒸馏来的吗？对不对？ 嗯，这个也不太好说啊，那但是呢，现在对于 cloud code 来说，他确实有一个反真流防御的这样的这个措施啊，就是他呢实际上会去判断你现在在进行调用的过程当中到底是真工具还是假工具啊？如果呢，你是一些假的工具啊？来接。如果呢？呃， sorry， 不是 判断真工具假工具哈， 他是会判断你现在的调用工具这样的一个模式，那么他如果识别到啊，说你现在呢是一个真实的用户在使用 cloud code 的 话，那么他呢就会以真实的用工具这样的流程来进行响应。 如果他现在去判断啊，你现在这个调用工具这个流程呢，是一个蒸馏的这样的过程，你会围绕很多场景会去穷举他的可能性啊，然后呢会围绕一个问题的反复来进行这个运行， 那么这个时候啊，他其实内部会有一套识别这样的一个流程哈，这个我没有展开讲啊，但这个识别流程实际上是个比较精妙的一个这个识别的过程，他既会有一些基于规则的这样的判断啊，他也会 有这个 sanit 这个模型，主观的这个模型的这个识别啊，两层的这样的识别。那不管怎么样识别了之后呢，他会觉得啊，你现在呢就是一个机器人啊，在操作你的 cloud code 啊，然后呢就是为了去获取一些这个数据啊，然后用你这个用这个数据去接下来训练我的呃，去训练别的模型，这个时候他就会 非常激贼的啊，在你在他实际运行的过程当中呢，给他给你手动给你自动的去注入一些假工具的流程啊，就是这工具根本就不存在啊，或者说就直接就给你去 这个创建很多的一些工具调用失败啊的这样的一些这个这样的一些这个数据啊，从而呢他会生成一个这个有毒的这个训练数据啊，防止别人家去进行蒸馏啊，就这么一回事 啊，哈，这个其实还是很有意思的一个这个点哈啊，但如果这个大家确实面临的类似于这个蒸馏或者反蒸馏这个场景的话啊，这块确实是值得学习。 最后呢，就是关于他的这个对抗的这样的一个问题啊，这个点呢，其实是非常值得拎出来来进行单独的这个探讨哈，就是因为其实现在关于双 ai 对 抗的这样的场景，我目前其实在很多地方其实都会有用到过啊，比如说像这个 啊，像我们啊编程的时候对不对啊？有在编程的啊，有在进行审核的啊，包括我们在解决些问题的时候啊，是比如说你做些科研的工作啊，有提出结论的，包括比如说我们现在啊，如果使用 ai 去生成一些这个内容啊，那么有生成内容的，有去批判内容的， 那么现在呢，对于 ans 来 pick 来说，你会发现它的这个双 ai 对 抗这个策略基本上是贯，基本上是贯穿它整个 cloud code 的 各个方面的啊，如果遇到一些你当前大模型它自己不太好判断是不是有问题的这个点的话，那么它就会其实就会启动啊，双 ai 对 抗的这个策略。那么 比如说上面我们说这个安全方面的这个双 ai 对 抗这个策略，这一点我觉得还是比较好理解啊，因为其实一方面提出啊，一个 agent 来负责来进行审核， 那么除此之外呢，其实像 cloud code 里边儿啊，我们之前就有谈到过它的这个命令啊，它的这个压缩呀过程，其实也都会啊，有这个双 ai 双 ai 对 抗的这个影子啊，就一方提出主张啊，一方面提出质疑啊，然后呢，最后综合出一个结论，差不多会有这样的一个这个过程。 而这个双 ai 对 抗啊，实际上也是现在的关于 harness engineering 啊，他的这套体系里面提出来的一个非常有价值的一个观点啊，就是他会觉得啊，在这个多个 ai 从不同角度啊来进行，呃，那他们分别带有不同上下文啊，然后呢，去协助去完成一个事项的时候，往往有助于啊，提升你最后这个作品的这个质量。 举个例子，比如说啊，我们现在经常会使用 ai 去生成一些这个内容，那么生成内容之后呢，如果你让自己让他自己去 去对自己东西来进行审核的话，其实往往就审核的就很一般啊，但如果你有多个 ai 来进行对抗的话，来进行对抗审核的话，他就往往啊就能够提出很多很正确的意见啊，帮你的内容呢朝向更好更更好的方向去发展啊，差不多就这样的一个过程。 总之呢，其实在 cloud code 的 内部，它其实也是广泛应用啊，一些双 a 对 抗这个策略呢，去约束它内部的这个行为啊，这点确实是，呃，很有意思的一点啊，也是我觉得是一个性价比很高的一个策略啊，因为它其实并不会特别复杂啊，但是它能够显著提升你当前 agent 的 这样的一个这个效果，哈哈，是这样的一个情况， ok， 好， 这个呢啊，是关于安全是怎么做的， 那么紧接着还有最后一个问题啊，就是关于他的这个知识商增怎么去解决？哎呀，这个知识商增呢，其实是个非常呃困扰大家的一个这个问题哈，就比如说， 那我们现在啊，假设开发一个项目，呃，这个开发这个项目使用 qq 的 开发一个项目啊，那么呃，前一两千行代码写的可能还是比较顺利的啊，也不会出现什么知识商增的这样的个问题啊，反正就是代码也不是特别多啊，大家一看也能明白是什么样的东西做的呢，可以说是又好又快。好，那接下来 这个两千一两千行代码到一两万行代码的时候，哎，你会发现管理就会很混乱啊，一会我这个 a a 阵子就记不得之前的这个信息了啊，一会这 a 阵子 忽略了某些信息啊，给我堆出一个十三代码，然后呢一会啊，这个呃，这部分修改了之后，关联的那部分也没有修改，等等等等啊，就会出现很多很多这样的问题。而如果进一步的到十万行，到这个一两万行，到这个一二十万行代码，这就更加复杂了。 所以呢，其实现在啊，我们在使用这个 agent 在 进行这个开发的过程当中啊，其实很多时候都会遇到啊，他这个知识双增的这样的个情况，那么对于 cloud code 来说也是类似的啊，那么用户在使用 cloud code， 当然他自己其实是个工具啊，他并不是这个项目本身啊，对 cloud code 来说他是个工具，但是呢，这个这样的工具必须要给用户提供 应对，非常复杂，大规模知识商增这样的情况怎么样？很好的去控制你接下来未来 agent 的 长期这样的运行，就比如说我项目可以很复杂啊，对吧？你可以是一个一二十万行代码这个项目，但是对于 agent 来说，你得有能力去解决这个项目啊， 你不，你不能说这个，我，我上来这个上手这个项目就是一团糟啊，乱七八糟啊，然后呢？这个，呃，也也搞不清楚上下文什么啊，然后呢？也写不明白啊，这可能就不行，那么要做到一个围绕着巨大的这个知识体系来进行管理哈，来进行内容输出啊，代码也可以把它理解成是内容生产的一个缓解嘛， 来进行有效的啊，这个内容输出的话，那么其实对于你当前 a 阵的架构就会提出很高的要求啊，这个其实不仅仅是说我需要有更强的这个模型，有更强的模型只是一方面啊，除之外呢，还需要有 harness engineering， 对 不对？约束好他，好让他好好的哎，去做这些事情啊。所以接下来呢，我们需要解决解决第四个问题啊，就是去看如何通过啊，这个 color code 内部如何通过这 harness engineering 呢？去更好的去实现面对知识商增这样的情况，他如何分文别类的来进行很好的这样的处理。 那么首先哈，我们说对于现在的这个比较复杂的任何比较复杂的任务啊，基本上肯定都不是一个 agent 来进行处理了啊，肯定是很多个 agent 来进行协调的这样的一个处理啊。所以呢，对于 carco 来说啊，他去应对啊，这个知识商增这样的个情况，应对比较复杂，大型代码的或知识类的这样的项目，那么他肯定也是会考虑啊，使用多个 agent 来进行运行。 那么在 cloudco 内部，它的 agent 的 运行模式，其实现在啊，总共是有两种模式啊，一种呢叫做 sub agents 模式模式啊，一种呢叫做这个 agent teams 模式啊，这两种模式其实是不一样的。那么所谓 这个 sub agents 这样的个模式呢，在 cloudco 的 内部，它的这个运行的逻辑是，它会把这些 agents 把它看成是呃这个主 agent 的 一个可以调用的工具啊，它它它它 agent 当然是可以是一个工具了啊，对不对？ 那么它如果我的 sub agent 作为主 agent 一个可以被调用的工具的话啊，那么接下来我在运行的过程当中啊，这个过程其实就会呃非常的简单，对不对？我需要它， ok， 我 调用它，然后给它，给它输入上下文，然后它就进行运行就可以了， 那么这个时候 sub agent 跟主 agent 是 不会共享上下文的，那么 sub agent 它不管运行了多少，它最后呢就会把它最终运行这个结果提交给原来的主 agent。 举个例子啊，比如说 大家都知道，对于现在的 cloud code 来说啊，它有这个非常强的呃这个 deep research 这样的能力，对不对啊？非常强的这个呃深度调研的啊，广泛来进行一些搜索这样这个能力。但是其实在呃这个 呃 cloud code 的 内部，这个 deep research 是 由一个单独的 agent 来完成的啊，只不过呢，这个 agent 是 一个 sub agent 啊，它呢是能够被工具呢，能够被各个不同的 cloud code 来进行调用啊， 么样的一个这个情况，也就是说当你如果你需要围绕一个东西来进行深度调研的话，那么这个时候呢，主 agent 啊，实际上是会给一个 sub agent 啊，去发布这样的命令，让他呢去调用自己的网络工具来进行海量调研，调研完了之后呢， ok， 把信息在汇总给你。原来的 agent 是 这么样的一个过程， 当然除了啊这个，呃 sub agent 啊，呃，除了这个 deep research 这样的 agent 之外呢，其实对于 cloud code 来说，它还有很多内置的一些这个 agent 啊，还有这个 plan 啊，它也是一个 agent， 等等等等。 那么不同的这个 agent 啊，它和你现在用的这 cloud code 之间唯一的区别就在于说不同的 agent 呢，它可能它的这个上下文哎，就是 agent agents 点 md 呢，这个东西呢，是不一样的啊，你可以这么来进理解啊，只要它的 agent 点 md 是 不一样的啊，或者它的这个 cloud md 是 不一样，那么它呢在运行的过程当中所调用的上下文，其实就跟你是不一样的啊，你可以这么来进理解，那这个时候呢，这个 agent 啊，就是个全新的一个这个 agent， 这个呢是第一种模式叫 sub agent 的 模式，那么说实话还有种模式啊，是呃，在呃这个今年年初啊，伴随着 cloud 四点六啊，这这个这一系列模型发布的时候呢， anselp 一个主推的一种新的这个模式啊，叫做 agents team 这个模式， 当然哈，这个 agent teams 这个模式呢，其实现在也被称为叫做这个呃，这个 agent swarm 啊，这样的个模式啊，对不对啊？这个 a， 呃，刚刚我们说了，这个子 agent 呢，跟父 agent 呢，它之间没有上下文共享啊，这个我们刚刚也说过了， 那么第二种模式呢，叫做这个 agent 子 agent teams 这个模式啊， agent teams 这个模式呢，它呢其实就不再是这个副 agent 的 调用子 agent 的 这样的一个这个这样的一个这个过程啊，那子 agent 也不是说以工具这样的形式被副 agent 的 调用 它的所谓 agent team 四个模式呢，实际上所有的 agent 呢，都是平等的啊，都是有一个自己维护的独立的上下文的啊，然后呢会有一个主 agent 啊，通过对话啊，去调用不同的这个子 agent 来完成对应的这个事项。然后呢这个子 agent 呢，跟跟主 agent 的 之间这样通近呢啊，实际上是只会发送结论啊，但不会发送上下文。 那么通过这样的个方式其实也是能够很好的去进行不同 agent 的 分门别类的上下文的这样的管理啊，以免上下文交叉啊，所带来的这个呃知识的商增啊，或者这个这个行为轨迹的这个爆炸呀，类似这样的情况。并且呢，目前来说对于 cloud code 来说，它 只有啊一个呃，它它的这个 multi agent 的 这样的模式啊，觉得 agent teams 这个模式啊，只有一种架构的方式，就是一个主 agent， 然后连接一系列一系列的这个 agent 啊，一系连接一系列的这个 team mate agent 啊，就一系列的队长啊，剩下全部都是队员，队员， 然后呢队员跟队员之间啊，是不能够相互通信的啊，然后呢队员跟队长之间啊，是可以相互通信的，所有的工作或者所有的结果都是由主 agent 啊，去给各个不同的子 agent 来进行分发啊，它目前呢是这么两种模式，那么为什么会有这两种模式出现哈，其实也是基于现在的 cloud code 啊，他们可能长期的这个实践 啊，之后最后得出来的这个结论啊，就是会发现我们刚才的啊所说的这两种模式啊，这个是我们刚刚所说的第二种模式 发现。哎，这两种模式呢，其实是最呃能够结在这个确保稳定性的这个情况下去节省 talkin。 而其他啊，大家也知道有很多的一些这个，比如说现在这个 multi agent 呢，有很多的这样的架构，对不对啊？刚才这个架构呢，是一种指挥官式的这样的架构，一个 agent 连接多个 agent 的 这个架构啊， 除此外还有啊，类似于这个蜂巢这种架构，很多 agent 呢之间呢都可以彼此相互通信的啊，这样架构像这些架构呢，目前还没有去集成啊，他也可能也是觉得说这些架构呢，可能运行起来目前来说还不是很稳定。 那么通过啊，我们现在的啊这两种基本的这个模式呢，可以说 cloud code 啊，就能够解决在不同场景下使用不同的 agent 的 一个基本的这样的一个流程，但是呢这个流程还不够啊，我们这个流程，其实所有的咱们的用户啊，只要你使用了这个 cloud code， 都能够感受到 有这样的一个这个流程，那么除了啊有这个流程之外啊，我们说对于 cloud code 来说呢，它还有非常强的一个 talkin 的 一个管理的这样的一个机制啊，哈哈，这里其实就涉及到啊，非常有趣的一个点啊，就在于说有很多同学经常说啊使用 cloud code 啊，这个 talkin 爆炸啊，是吧啊，这个这个动不动这个 talkin 就 不够用了， 哎呀，但实际上 talkin 已经尽力了啊，因为它在它的这个系统里面其实已经有非常非常多啊，这个关于如何去 啊，如何去节省，你当哎，不好意思啊，如何去节省你当前的这个呃 token 的 一些这个措施啊，但是呢仍然啊还是会面临着啊，大家经常会使用这个 token 的 时候感觉 token 包大这样的这个情况啊，当然这个其实也不是很重要啊，重要的是我们需要去看啊这个 anselpik， 那 他们的 cloud code 是 怎么去尽力去节省你的这个 token 啊？那么懂了我们刚刚所说的他们这两种 cloud code 啊，这样的 agent 分 配机制之后，我们接下来看啊，它是怎么样去很好的去啊，把控你现在整体的这个 agent 消耗的。 那么首先哈，我们说刚才的这个副 a 证跟子 a 证的上下文隔离啊，这个呢，其实呃就能够很好的去这个呃避免啊它上下文交叉感染，然后同时也能够去避免单个 a 证过长上下文的这样的一个问题。当然最最最最精彩的实际上是这款就是 关于它的共享 talkin 经济学，哈哈哈。啊，什么叫共享 talkin 经济学啊？这个是什么样的一个意思？那么我们都知道啊，现在对于一个 agent team 的 这样的一个系统啊，实际上你的 这个 agent 呀啊它长什么样的都有啊，对不对啊，我各式各样的这功能的 agent 都有啊，那呃， agent 一 号啊，一号跟 agent 二号啊，它们呢，或许有一些内容是一样的啊，那么或许有些内容呢也是不一样的啊，有的时候呢，这个啊，它有一部分啊是重叠，有一部分也是不重叠的， 那么在这样的一个基本的的这个形态下啊，其实呢， cloud 内部，它会有一个非常巧妙的一个这个分辨啊，它呢会把所有的 agent 稳定的缓存的一些指令区都是共享一套存储策略，你可以这么来理解， 就相当于是一个模型，它运行的时候呢，它有一个快照啊，然后呢从这个快照的时间节点开始啊，那么接下来或许会分呃，或许会分化为很多不同的这个 agent， 那么在这个快照内部，它们的记忆是完全一样的，只不过呢是基于这个快照这个点哎，有的 agent 输入了 a 指令，有的 agent 呢输入了 b 指令啊，然后有的 agent 呢输入了 c 指令， 那么在这快照之前，它们其实保存了同一个这个模型，那么它们通过输入不同指令之后呢，才演化出不同的模型去维护不同的线来进行服务啊，你可以这么来进行理解啊，所以呢，它会在里面，它会在整整个 agent 运行内部去构建一个啊，所谓叫稳定区 的一个全局缓存的这样的一个东西啊，这里面就是会保存所有的 agent 啊，大家共有的相同的这样的一些这个内容啊，然后同时呢， 每一个 agent 都是在全局缓存的稳定区基础上啊，加上一些自己动态的一些这个指令啊，或者自己不一样的这样的一些这个东西啊，然后呢再构成它的上下文啊，咱俩进行不同的这个响应啊，以此呢去构成啊，它的一个提示词这样的一个缓，类似于像提示词缓存的这样的一个机制，去节省它整体的这样的 talk， 其实哈所谓提示词缓存也是这样的过程，对不对啊？就是我们在调模型的这个时候呢啊，你有的时候输入的后面这个提示词呢，跟之前提示词一样的，有些提示词呢，是已经加载到你当前上下文里面之后啊，已经加载到当前上下文里边了，你接下来就不用重复来进行加载啊，这个这个过程其实跟 cloud code 的 内部所建立的啊，所谓这个稳定区跟动态区呢，基本上是 啊差不多的这样的一个这个状态，然后对不对啊？他他有很多的啊，这个这个稳定区指的是什么啊？什么基础指令啊，工具定义啊，全局规划呀，这个都他他不会在绘画中这个反复的变化的啊，都是稳稳定区内容啊，然后动态区指的是绘画特定上下文呐，这个环境状态啊，用户的不一样，这样的个指令啊，等等等等啊， 会有这样的一个这个方式，那么通过这样的一个啊， fork 共享这样的一个方式哈，它呢其实比普通的啊，这个 agent 如果我们在进行多 agent 运行的时候呢，它的这样的状态呢，其实会节省非常非常多的这个成本啊，这个呢，其实是它开源了之后有很多人在进行计算啊，计算它现在内部的多 agent 的 协助过程当中所消耗的 talk 的 这个成本 差不多啊，五个子 agent 约等于一个额外的 agent 的 这个成本，呃，这个五个子 agent 约等于一个一个额外的 agent 的 这个成本，它并不是说我增加了五个 agent， 然后呢就跟一个 agent 的 成本是一样的，不是这样的啊，它指的是如果我额外增加五个 agent 啊，那么就跟，我，那么就跟啊这个呃，在我们现在的这个共享缓存的这样的个 之下啊，那么呢这五个 agent 这个成本差不多能够降低百分之八十啊，你就这么来进行理解就可以了啊，那么这个呢是关于现在的 cloud code 啊，它的内部提示内部的啊，这个提示缓存的这样的一个这个技术啊，那么这个这项这个技术呢，实际上在它内部的这个实现，实际上非常的这个巧妙哈， 完整的这个实现的内容在啊，我们的这个呃题日词缓存的啊，这样的个 t s 文档里边啊，这个大家回头可以自己去看一下啊。总之呢，现在面对着多 agent 里边的非常复杂的啊，系统题日词，它也是采用类似题日词缓存这样的个技术啊，然后呢来进行一个 呃费用上啊，或者 talkin 上的这样的一个这个优化，那这个呢？好，我觉得也是。呃，这个这个功能其实属于一个非常进阶的一个功能哈，我们现在很多大家的这个普通的一些 a 智能在进行架构的过程当中，可能暂时都还用不到啊，这么复杂的一些这个功能啊，但但这功能确实也是我就觉得非常精彩，然后值得大家来进行一个学习的 这样的功能， ok， 好， 那么最后呢，还有关于啊，它的各种子 agent 运行这样的个模式啊，什么在呃县城内来进行运行啊，翼步后台来进行运行啊，远程执行啊，都是可以的啊，然后呢，这个进城内和翼步后台都是你可以操作的啊，远程执行呢，是需要放在 i s r t。 的 服务器上来进行运行啊，这个呢， 也都是 ok 的 啊，总之它的很多的 agent 呢，是支持不同类型的这样的个运行的模式的啊，然后呢，下面还有这个 mailbox 啊，关于它点对点通信的这样的格式。呃，这个的话大家可以自己去看一下哈，这个的话，它主要是些工程上的一些这个说明啊，我们就不展开说了。 那总之呢啊，其实它现在啊有非常多的一些对于当前 agent 的 一些提示词缓存的这样的一个这个技术，然后呢去减少你整个的在面对知识爆炸的这样的情况下，对不对啊，深层非常复杂，多 agent 的 写作体系的过程当中啊，减少整体的 talk 的 这个消耗，这个呢也是呃，我会觉得啊，非常精彩的一个这个实现， 当然最后我们还有一个啊，非常有趣的一个，哈哈。啊，也是最近啊很多同学这个热议的一个这个话题啊，就是关于说你的这个 apple pick 现在一不小心开源了自己的 cloud code 啊，那你的这之前发的那么多技术报告对不对啊，个个看起来都很厉害啊，你的技术报告在你的 cloud code 里面实现了吗？哈哈，这里其实是非常有趣的一个这个啊，有趣的一个 东西哈，首先啊，对 antalfa pig 来说，他的这次开源还是能看得出来他还是非常实诚的啊，因为绝大多数的他之前自己提的这些技术方案啊，在 cloud code 里面都有非常非常好的这个实现啊，教科书般的这个实现。比如说他 最开始讲的啊，这个 context engineering 啊，这个呢，是他去年十月份发的一个这个技术博课啊，然后讲他自己内部他自己的 context engineering 怎么做的，这个是对应的我们的整个的。呃 呃，这个 cloud code 的 架构解读第一部分啊，当时我们去讲的那部分的这个内容，对不对啊？这个呢，他技术报告里面提的内容哎， cloud code 里面都实现了，然后同时呢，他的安全与成本控制，就是我们三四部分讲这个内容啊，他在里面也实现了， 然后呢，多 a 证的对抗啊，他其实也有一部分的这个实现啊，只不过呢，他现在这个多 a 证的对抗没有他现在这个博克里面这个讲 那么强就是了啊，他博客里面说这个，呃，这个 g n 对 吧啊，生成对抗网络的三 a 阵的这个对抗的这样的一个这个形式，目前这个形式呢，在卡扣的内部还没有实现啊，但是未来呢，应该是会逐渐来进行这个实现的啊，这个大家若感兴趣的话可以去 看一下啊。然后同时呢，对于当前的 color code 来说，还有些同学会比较关注于说他现在啊，勇于他，其实，呃，尽管他这个泄密的是二点一点八八这个版本哈，但实际上这个版本里面其实有很多未来的功能，这规划啊，也能看得出来未来 color code 他 会朝哪方向去进行发展啊？就比如说像主要的啊，这个最为核心，也是大家最 看好的一个方向啊，是叫做主动式的这个 agent 啊，什么叫主动式的这个 agent？ 这个说起来啊，这个这个说简单一点啊，感觉就像这个定时任务一样啊，就是他呢会这个定时来进行响应啊，但实际上主动式的 agent 呢，没有那么简单啊，他呢实际上是会主动发现问题啊，然后再来 主动的来进行处理啊和这个解决啊。那比如说我们现在去构建很多的开发很多项目，或者做很多的这个事情，你要用这个 agent 做很多事情啊，你往往是 先跟他说怎么做，做完了之后你跟他说你再检查一遍啊，他再检查一遍，检查一遍之后呢，你运行了一下，发现出问题，你跟他说， ok， 你 再写几个测试这个视力，然后他测试视力，测试完了啊，发现有问题去解决问题啊，然后呢你再不断跟他说啊，然后他就不断去解决各种各样的问题啊， 这个呢，其实是属于你问我答的这样的一个状态。而主动式的这个 a 阵呢，他呢其实会发现当前运行过程当中所存在的问题啊，或者他觉得他现在需要去解决的一些这个问题啊，会主动的向你啊来发起这个请求啊，会主动的去完成一下这个事项啊，这个呢，是所谓的这个主动模式啊， carras 的 这样的个模式 啊，这个模式呢，现在还属于规划的过程当中啊，这个呢，其实未来啊，应该会这个上健啊，应该又是一轮不一样的啊，这个 a 政策的使用范式的 这样的一个调整，那么除此之外啊，还有啊，这个什么循环的这个引擎啊，循环这个引擎应该很快就会上线啊，这个其实就跟这个 heartbeat 啊，或者是 crm 定时任务其实是比较类似的啊，就是这个，呃，以这个持续不断的啊，来进行一个运行啊，还有呢，关于这个，这这什么成本 感知让步等等等等啊，这个呢，其实是关于他的一个成本优化的这样的这个策略啊，指的是我提示词换成，如果换成特别久，但是始终没有用到啊，他可能就考虑把这个提示词换成给删了啊，这样的一些这个小的优化，这个点啊等等等等。 然后同时啊，它还有一些啊，这个呃，这个呢，其实主要是它的这个云端的啊，就是服务器上的这个 cloud code 的 一些优化的这个工作啊，这个呢，我们就呃不不 展开来进行讨论了啊。然后呢，这个 skills 的 这个显见的这个显示，这个其实是一个非常非常有效的一个功能哈，这个功能我相信之后上线之后呢，肯定也会对我们现在开发工作会有很大的这个很大的一个促进作用。那么对于多 呃工具啊，或者多 skill 的 管理啊，实际上是现在所有的 agent 都会面临的很大的一个这个问题啊，那么对于像多 skill 的 管理，之前有很多的不同的厂商些提出不同的这个方案啊，然后呢？呃，那么现在啊，对 anfropack 的 他们其实集成了一个更加前沿，他们也会觉得很有用的方案，叫做 skill 渐近显示， 就是在未来啊， clock code 在 运行的过程当中，你甭管你给它绑定了多少个 skill 啊，你给它绑定了一百个也好，它在运行的过程当中，它会根据我当前这个项目推进的情况有选择掉一些这个 啊，然后呢让他每次运行的过程当中去选择那样的这个 skill 这个时机啊，或者选择这样的一个 skill 的 这个时间点来进行一个缩短。好，这个呢是所谓的 skill 渐近渐近的这样的一个显示啊，它呢是能够去进一步的优化你当前每一个 agent 的 上下文啊，同时也能够提升 agent 的 响应速度啊。这个刚刚有同学问到说 cloud 为什么响应速度这么快啊？他代码这么多，为什么响应速度还这么快啊？这个，这个对吧？还有很多这方面优化这个措施啊，所以他响应的速度 啊，是这样的一个这个情况。 ok， 好 啊，这个呢是关于啊他现在的很多未来功能的一些规划啊，当然还有一些这个有趣的功能，对不对啊？赛博宠物啊，赛博宠物呢，这个我们刚刚看过了啊，这个赛博宠物大概就长这样啊，大家可以自己看一下啊，这个呢就是 cloud code 的 一个这个页面啊，然后呢就输入这个呃，八底之后， 然后他就会给你整出一个呃，这个出来一个这个小宠物啊，差不多这样的一些功能等等等等， ok， 行，那这个呢就是关于整个的啊 cloud code， 我 们在今天有限的这个时间点时间里边啊给大家去讲解的 cloud code， 就 我个人认为非常精彩的一些这个架构啊和我觉得啊会对我们后边的啊，这个主要是非常进阶，非常顶尖的，大家来进行 the agent 开发的时候啊，一些这个启发，但是下面啊还有一些可以附用的一些 ai agent 开发的这个模式的一些这个表格啊，大家如可以去看一下，如果你们现在进行开发的时候有类似的一些需求的话，那么你可以考虑参照 cloud code 啊来进行实现。然后同时呢关于 cloud code 啊，其实我们之前没有讲过的一个点呢，暂时说有很多同学会呃比较 关注于说，哎，我现在有拿到克拉扣的这个原码，之后怎么样来接在在本地来进行一个这个部署，对吧？啊，那么首先好，我们说克拉扣的你是可以在本地来进行一个这个呃 build 来进行一个部署的，那么我们再给大家参考资料里面其实有啊，这个是没有什么问题的，但是呢，你的实际的运行过程当中仍然还是需要访问远程的 ansore pick 的 这个模型的这个服务啊，才能够来完成响应和完成认证啊。当然如果你是使用国内的模型的话，可能就没有这样的一个问题，这是起的这是一个， 第二个呢是呃这个东西哈，你最好用的话还是这个呃低调一点啊，因为他确实不是一个 呃完完全全的符合版权的这样的一个这个事情啊，这是为什么？我公开课可能没有去讲啊，拿着原码怎么去进行这个部署，跟本地运行的非常核心的一个这个原因不太适合啊， 这么公开这个场合啊，大唐起鼓的，我们来讨论这样的问题啊，但是呢，我们出于学习的目的，对不对啊，好好的研究一下内部的这个架构啊，给予我们未来开发的一些这个启发啊，以及呢积累一些这个经验。哎，这个还是非常不错的啊，这是没有什么问题的。所以啊，这里啊他有这个八个架构模式啊，如果大家感兴趣的话啊，可以考虑啊，去进行一些 啊，进行一些这个选举啊，或进行一些这个实现这八个架构模式基本上也就是啊，我觉得我们在读完啊 cloud code 的 这个架构之后哈啊整个的这个原码之后，最核心的一些这个启发啊，首先第一个分层降级防御策略啊，第二个呢，分层知识注啊，第三个知识商的这样的一个管理啊，认知商的管理，对不对啊？这个后台做梦啊，整理记忆 啊，还有什么众生防御啊，这个双 ai 对 抗啊，还有感知缓存架构啊，还有这个编排者模式啊，编排者模式，我们刚刚说的这个 multi agent 啊，一个主 agent 分 配多个 agent 来干活这样的个模式。 然后呢还有这个能力边界啊，既架构边界啊，等等等等这样的一些这个模式模式啊，这模式下面都有对应的他的一些这个啊使用的方法和对应的这个方案啊，大家如果感兴趣的话，可以自己去看 下。然后呢我在我们前文里面也都给大家指明了对应的不同的这个方案里边啊，他对应的这个原码的位置啊，大家可以去看一下。总之呢其实对于这个原码来说，你是很难 这个啊，通读的啊，这个其实非常非常困难啊，你只能够根据说 ok， 我 们现在啊，可能大家提炼出了一些比较好这样的模式呢，顺藤摸瓜啊，然后呢来进行一个读取啊，来进行学习，来进行借鉴， 好，那么到这啊，关于 cloud code 啊，它的一个源码的一个这个解读啊，我们这里是拎出了一些这个亮点，对不对啊的这样的这个解读呢啊，就差不多啊，告一段落了啊，我们就打一波广告， 那么也欢迎大家啊，报名由我跟沐雨老师啊，还有啊，还有志杰老师，我们共同来主讲的啊，二零二六大模型 agent 开智能体开发实战课啊，这样的一门付费课程 课程啊，是我们三位老师共同来主讲啊，是一门一百个小时以上的完整体系大课，那么今天我们其实讨论了非常非常多啊，关于大模型 a 智能开发相关的一些这个内容啊，当然我们今天讨论的呃，可以说非常难啊，非常复杂，而且很多都是行而上啊，都是一些理论层面上的啊，这样的一个这个东西， 那么啊，大家如果接下来想进一步的来进行深度的时间落地啊，或者你是想从零开始来学习大模型 agent 开发，就未来想要去参与到啊这个大模型 agent 技术岗位当中去的话，那么那么也非常欢迎大家啊，报名这样的一门啊，由我们三位老师共同来主讲的大模型 agent 的 开发实战课， 那么课程是一百个小时以上的完整体系大课，能够帮大家零基础入门，然后直达目前顶尖大厂大模型 agent 的 开发中高级岗位能力要求的这样的一门课程， 那么这门课程啊，其实我们现在已经开设到第二十四期了哈，这今年的这个春季班啊，已经是第二十四期了，我们从二三年的这个五月份啊开设第一期到现在啊，已经 这已经是将近三年的啊这个时间了啊，三年的时间里面已经也是有两万多名的学员报名了我们这样的一门课程，也有非常非常多的学员啊，现在是已经是加入到啊我们大魔仙 a 智能开发的这样的一个技术岗位当中来了，那么这门课程呢，是可以帮他零基础入门来进行的学习，然后呢可以全方位淬炼大家 大模型 a 证的开发的啊能力的技术体系啊，那么这本课程是可以帮大家零基础入门，然后直达目前顶尖大厂的五十万年薪的大模型 a 证的开发岗位能力要求的 这个五十万年薪啊，这个我们不是随便说说啊，我们也不是随便糊口的个周了一个这个数字出来啊，是因为我们团队其实也是在进行大模型 a 证岗位这样的招聘啊，我们 课程里边讲解的内容就是我们团队的岗位的要求啊，那么那其实我们今年金三银四的内容就是我们团队的要求啊，那么那其实我们今年金三银四的学员群里先 已经进行了很多轮的这个招聘啊，我们招聘要求非常简单啊，大家只要是学了我们的课程啊，学了百分之六十到百分之七十以上啊，就可以啊加入到我们公司团队里面啊，来进行一个这个工作了啊，就可以顺利的拿到大模型 a 证的开发的岗位的这个 offer 了啊，所以呢，我们这样的一门课程是完完全全严格按照目前顶尖的 大厂的技术岗位的要求呢，进行的内容的设计。那么这门课程啊，总共呢是六个模块，我们先给大家看一下啊，现在这门课程完整的课程介绍。 首先啊，第一个模块呢，是来会讲解啊，关于现在顶尖的大模型的一些基本的技术入门啊，包括顶尖的在线大模型的 a p i 的 接入使用，本地开源模型的部署和使用。然后呢，智能体 a 证的开发的理论基础和基本开发工具，然后呢， rack 解锁增强技术啊，开发入门等等等等啊，这是第一阶段，然后第二阶段我们会进一步的来探讨啊，关于热门的 a 证的开发框架的上手实战啊，包括一些零代码啊， d 代码的开发工具啊，像这 codes， define， 还有 n 八 n 呐，也包括那一些顶尖的 rack reg 框架啊，主要是拉玛 index 啊，在开发时代也包括新兴的 agent 开发框架时代啊，像这 agent sdk 啊，还有 agent school 啊，还有 adk 等等等等。然后同时啊，还包括工业级的 agent 开发框架啊，这主要是 long chain and long graph， 那 么这个当然是我们会准备主讲啊，这样的开发框架，那么刚刚啊，我其实 弹幕上啊，有同学在问到啊，说啊，我们能不能够使用 long chain 来复现一版的 cloud code 呀等等等等啊，其实我们课程里面已经使用 long chain 就 复现了一版 open cloud 了啊，然后呢，我们课程里面也有啊， cloud code 的 这个复现啊，只不过呢，使用 agent sdk 去进行的这个开发。 然后呢，当然底层开发思思路其实是一样的。好在我们课程里面啊，我们会从头跟大家去讲啊，关于最新版 long chain 应该做出来进行使用啊，然后呢，如何啊？去复刻这些顶尖的这个，呃， agent 啊，就是这一些像 open cloud 呀，还有 cloud code 呀，这一系列 agent 复刻的这个核心的思路啊和方法 啊，同时第三个第三个板块，我们会进一步来讲解啊，关于工业级的 agent 开发境界的这个技术，包括智能体的内部的啊，多工具的管理呀， m c p 工具的这样的一个使用啊，包括啊，这个 agent， 呃， reg 进阶的这个技术实战呢，包括纯文本的解锁优化啊，包括图文混排的 pdf 解锁啊，多多多模型的 pdf 解锁，结构化数据的解锁和 graph reg 基于知识图谱的解锁啊，还有视频信息解锁等等等等。 那刚刚啊，就有同学问到啊，说我上下文特别特别长啊，然后呢，呃，我们怎么样啊，去这更好的去读取啊，或者是去获取上下文这样的信息啊，那么要么你就是进行 compact 啊，压缩对不对？要不的话，你可能就是采用 reg 技术啊，来进行更高精度的这样的这个解锁。 好，那么再往下啊，还有关于智能体长短期记忆的这样的管理啊，和智能体上下文工程，这都是构建我们智能体直观重要的相关的这样的技术。再往下啊，还有关于多智能，多智能啊，记忆多智能 某体 agent 的 系统开发啊，对不对？然后呢，像对于现在的啊，这个 cloud code 来说啊，它呢其实只有一种啊，这个某体 agent 的 系统就是所谓的 supervisor 这样的架构，一个主 agent 不 负责干活，负责分配活啊，剩下很多的啊，这些 agent 负责来进行干活。 那么除此之外啊，我们说其实还有啊，像这 handoff 的 这个架构，还有这个 router 架构啊，还有 network 架构等等等等啊，有这四种主流这个架构，那么这些架构呢，都会在我们正科里面啊，来进行讲解介绍。那么 再往下啊，还会包括啊，会讲解关于大冒险高效微调啊相关的这样的内容啊和呃，紧接着啊，我们这这个呢，就是我们第三个模块内容啊，第四个模块呢，我们进一步来讲解关于工业级的大冒险 a 阵的部署上线啊相关的一些这个内容，包括 啊，像智能体项目部署上线的这个基本理论啊，包括智能体开发部署上线全部的这个流程对不对？好，从最开始的前后段功能设计啊，到这个接口的这开发啊，到前后段的连调，到最后的项目上线，一整个完整这个流程啊，然后也会来讲解关于两大的 容器啊，交啊，两大容器化啊，这个交付工具这样的实战啊，主要是刀口跟 kbs 的 这样的使用，同时也会来介绍关于智能体的追踪和优化相关的这样的内容。 同时这门课程我们呢现在总共呢还有啊，总共呢是十大项啊，工业级的这个实战的这个案例啊，分别是长文档啊，定制化文档编辑 agent 啊，然后文档审核 agent 啊，图文视频 agent， 语音交互 agent 啊， deep research agent 啊，然后呢数据分析 agent， 然后啊数据分析格式化 agent 啊，垂玉的 agenta reg 系统啊，多模态 reg 本地知识库解锁系统啊， nintendo pro ppt 生成系统啊等等等等，然后同时还会有四大项， 这个百万用户级别的啊，这个商业化的项目，工业级项目实战啊，分别是企业级多模态啊， rek 支付解锁实战项目，然后全新一代智能客服 a 智能开发项目啊，其实我们所有项目都有对应的演示视频啊， 这这这演视频可能会比较长啊，我们这个啊就不展开给大家看了啊，大家可以自己登录我们的主页来进行观看，然后啊包括一比一复刻 mana 通用智能体的啊，这样的项目和啊这个 ai 编程啊跟数据分析 a 阵的开发项目。当然在我们的春季版里面，我们还新增了啊丛林去赴县 open club 啊这样的个项目，完整的相关的内容啊，那么在我们的这个春节班里面，我们是完整的大家去复现了一个啊，这个复翻 openclo 啊，这样的一个这个项目啊，然后呢所有功能呢，都会从零来进行实现啊，这个项目其实就是 呃使用 long chain 啊来进行的开发啊，在开发过程当中呢，我们就跟大家详细去介绍啊，它背后的核心的啊这样的一个理论知识体系。 那么除了啊这样的一门呃大冒险 a 型开发实战课之外呢啊，我们说还有两门课程啊，一门课程呢是 open core 啊，这个技术实战课啊，这门课程呢是由我来主讲的一门啊，这个总共呢是二二二十到三十个小时的啊，这样的 open core 智能 体的应用实战课啊，这门课程是目前是呃，我正在讲解啊，这样的一门联赛更新这样的课程啊，但这门课程其实主要就是来讲解关于 open core 啊，这样的 这个技术应用啊，实战相关的一些这个内容啊，那么 openclaw 这个定位呢，其实和呃 cloud code 还是有些区别哈， openclaw 其实是更加通用的一个智能体啊，它呢其实是更呃有更低的这个使用这样的个门槛，对不对？然后同时呢也能够覆盖更多的啊，一些实际应用的这样的岗位。 那么这个 openclaw 啊，实战课里面我们会给大家介绍各式各样不同类型的这个应用范式啊，和基本上所有工作的各个不同类型的应用范式啊，和基本上所有的课程呢。最后我们还会介绍目前四个 核心的啊，这 open 可捞商业变现的啊，一些这个流程啊，包括全自动的 ai 内容工厂啊，包括这个全自动的啊，公司网站运维和建设啊，包括这什么呃艺人公司的啊， ai ai 员工团队啊，如何进搭建啊，以及呢，包括垂雨 ai 自动化的啊，这个服务开发等等等等啊，这个呢是属于 open cologne 啊，相关的这个技术内容啊，但是 open cologne 其实是一家更加通用的一项啊，技术开发这样的工具啊，或者说一项通用这个智能题使用的这样的个指南，那么和我们刚刚大家所看到的啊，这个 agent 开发实战课其实完全不一样的方向哈，因为 agent 开发实战课其实是更加硬核的 这样的一门啊，这个主要是面向技术人啊，大家如果未来是想做 a 证的开发啊，来去量身定制的这样的课程。但是除此之外，我们还有第三门课程啊，是由木鱼老师来主讲的 web coding ai 编程实战课啊，这个课程，这个啊，重要性就不言而喻了，对不对？这个 web coding 嘛， 哎，这个，这个，去年我们这个时候啊，大家说 ai 编程可能会还会觉得比较早，早啊，时间还比较早，那么到现在啊，大家如果说自己不会 web coding 啊，这个，这个属于是古法编程啊，是不是啊，人类手工编程啊，这是属于非遗传承的这个技术 啊，所以现在我们基本上所有场景里面啊，我们很都会呃，会用到啊，这个 web coding 这样的这个技术啊，都会来进行 ai 编程啊，那这门课程呢，是沐浴老师来主讲的啊，一门可以说啊，已经是开设第二期的 完整的 web coding 的 体系大课啊，然后呢，能够帮大家零基础啊，零门槛啊，上手 web coding 这样的工具，然后呢，开始啊，你的 ai 编程之旅啊，这可以说是现在所有程序员必备的这样的技能了，我们 可以讲解啊，像 course code code 啊，这一系列 ai 编程工具这样的使用啊，然后我们也会来讲解啊，关于像 open code， 对 不对啊，这样的开源的 ai 编程工具，这样的这个使用啊，然后呢来介绍啊，关于 ai 的 skill m c p 啊，这样使用啊，和 像 figma 啊， pencil 来进行前端设计的一些工具啊，然后呢，像以及啊，像这个 openstack， 还有 superpowers 啊，一些非常有用的，非常实用的，能够提升你的 ai 编程的水准的啊，一些这个 skill 的 这个使用啊，也包括像现在 cloud code 啊，它的 agent teams 啊，多智能体协调来进行开发的一些这个方法等等等等。 那么这门课程啊，是由沐雨老师来去主讲的啊，一门课程啊，这个对不对啊？关于 ai 编程的这个重要性啊，这个其实呃已经是非常非常重要的哈，因为其实呃这个不仅仅是现在啊，像 anthonpick 啊，像在国外顶尖的大厂啊，大家是在使用 ai 编程，国内大厂也在用 ai 编程哈， 不仅国国内大厂在用 ai 编程啊，基本上所有的岗位大家都是在用 ai 编程啊，很就是除非一些特特定的这个情况啊，这可能还需要手工编程之外啊，剩下的 ai 编程呢，它已经是属于大模型 a 智能应用的啊，一个非常成熟的这样的一个领域了。 那么在这个课程里面，我们不仅会教大家啊，怎么样从零开始去使用这 ai 编程工具上手来进行 ai 的 编程外部口令啊，同时呢，我们也会 从头啊开始教大家啊，怎么样从最开始能写高质量代码，到做出 demo 啊，到精准的输出啊，到完成一整个完整的应用啊，到推送产品上线啊，到产品二十四小时的这个运行， 到最后啊，对不对啊，全站的开发啊，到运维的完整的这个技能体系啊，写在这么课程里面，我都会来进行详细的这个介绍， 那么刚刚我们给大家看到的啊，像这样的一个复饭，呃呃呃， cloud code 啊， web 这样的一个这个程序啊，其实就是我们当前这门课程里面给大家提供的一个应用的一个工具啊，这是其中一个工具啊，我们这门课程里面其实还很多其他的工具 啊，当然其实这门课程里面我们重点是来讲啊，像 cloud code 怎么样去用好它，去完成一系列的啊，这个开发的这样的一个项目。而啊这是我们的 agent 开发实战课，那门课程里面主要是会讲它底层的原理，一个呢是 进行使用啊，一个呢是底层原理的这个介绍啊，这个呢其实是各不相同，有所侧重的这样的点。当然对于 ai 编程来说，我相信很多同学可能也会有这样的误解，大家会觉得 ai 编程吗？有嘴就行啊，对吧？只要跟他说我要开发什么，他就能完成开发，其实并不是这样，哈哈，现在其实对于很多的 a 证的使用来说，还是有不小的这个门槛的话， 你可能还是需要掌握很多的一些这个技术，然后同时也得积累一些这个经验，然后才能够完成一些很好的产品这样开发。 大家现在看到的都是我们当前课程里边会给大家讲解的啊，一系列这个产品的这样的一个这个开发，那么这门课程啊，我们就会好好的跟大家来介绍啊，关于从工具的使用啊，到我们现在前沿的实践经验的沉淀和总结啊，一整套完整的 web coding 相关这样的内容。好，那么以上啊，就是我们这三门啊，付费课程的内容介绍啊。

面试官问， line graph 里的节点编状态到底分别解决什么问题？很多人上来就说节点是步骤，编是流程，状态是数据。 这句话没错，但太浅了。真正面试的时候，你要讲清楚的是，它们分别解决 agent 的 落地里的哪一类工程问题。 我是悟空，点赞收藏加关注，我们马上开始。先说节点，节点解决的是一个复杂 a 证的任务，如何拆成可维护的执行单元。 比如一个 reg agent， 你 不该把所有逻辑塞进一个大函数里。你可以拆成意图识别节点、解锁节点、重排节点、生成节点、 工具调用节点、结果校验节点，每个节点只负责一件事。这样做的好处，逻辑清晰，方便调试，方便替换。今天你想把向量剪索换成混合剪索，只需要改剪索节点， 不用重写整个 a 证。所以节点的核心价值是把 a 证只拆成一个个可附用、可观测、可替换的工作单元。再说边边解决的是 a 证的执行路径，如何控制。 常见的问题是流程太死，一步接一步。但真实业务里， agent 经常不是限行流程，下一步该去拿就是边要解决的问题。在 line graph 里，边可以是普通边固定流程，如解锁之后一定生成， 也可以是条件边分居流程，如根据模型判断是继续调用工具还是结束。回答最后说状态， 状态解决的是多记点之间如何共享上下文，以及如何记录 agent 当前执行到了哪里。 agent 不是 一次函数调用就结束，它可能要多轮对话，多次工具调用，多次反思修正 每个节点，读取一部分状态，处理完以后再更新状态，这样整个 a 证的执行过程就不是黑盒，而是可以被追踪恢复和调试的。比如工具调用失败了，从状态里看到失败原因，用户断线了，根据状态恢复到之前的执行位置， 需要人工介入，直接查看当前状态再继续推进。所以状态的核心价值是 让 agent 具备记忆现场和可恢复执行的能力。如果一句话概括 line graph， 不是 简单帮你串几个 l l m 调用， 而是把 agent 抽象成一个可控的图结构。应用节点拆分能力，边控制路径状态保留现场。谢谢观看。

今天在使用大模型的过程中，发现了一个大模型天然本能的缺陷，起因是我今天在和他讨论项目的时候，其实呃先让他生成一个项目文件，然后我就发现了一点问题，让他去修改，结果他修改之后他就直接告诉我他修改了哪些内容，然后直接就给我生成了一个新的文件， 这并不是我想要的结果，我想要的是他修改了内容之后，告诉我他修改的内容修改成什么样的内容，修改成什么样的格式，然后我确认这个项目的整体结构之后再输出内容，然后这样才是最完整的。像他刚才那样做的话，既浪费了我的时间，又浪费了我的 token， 导致我很痛苦。然后思了一下最近一使用大拇指的经验，发现大拇指他其实就是天然有这个本能的缺陷，他就倾向于替人类多做一点东西，然后矛盾的时候就是悄悄的去执行修改，然后一些问题的时候也不会去找到我们提出的矛盾来给我们指正， 就遇到另外当我们提出复杂的方案的时候，他也不会去纠正我们复杂方案的倾向，给我们提出一个更简单的方案，他经过人类的训练之后，他可能 更倾向于像是一个呃执行者，就缺少了一点自主思考。然后总结了我最近一直使用大模型的经验，就把它总结了，像卡帕西之前写的那个卡拉 d m d 文档一样，总结了也写成了一个 a 电台 m d 文档。这个 m d 文档中 首先第一个角色就是把它假设成了我使用我所在领域的最强大脑或最强专家，但是他是一个咨询者的角色，而不是一个执行者的角色，他需要向我汇报他的内容，然后几次就有有大概有五六块内容，第一块就是他要先思考，先确认，然后再动手 就输出内容之前要跟我确认他修改什么样的内容，修改成什么样格式再输出，然后遇到问题之后，大家他要他不清楚，他要让我选择最优方案， 以及我提出复杂的方案的时候，他如果有最简单的方案，要及时的提醒我，然后在输出格式呀以及防止他遗忘遗忘的机制上面都给他输出了一个完整的像 plsd 文档那样，大概是六五六十行的文档吧，这个文档 经过我下午一下午的体验，用下来就非常的顺畅，就我们可以很高效的沟通，就遇到问题他去解决，解决完反馈给我，他说出了什么内容，然后我真正确认之后，再完整的落盘成一个真正的文档，这样其实才是效率最高的。然后如果有需要的话，把文档分享给大家。

为什么你用不好 agent？ 核心的问题藏在底层的架构里，今天我们用最简单的大白话去拆解什么是 agent。 大家好，欢迎收听四十岁老头学 ai 的 播课，是你们的 ai 私教，我会用大白话和生活话的类比帮你理解。今天咱们把 agent 架构的九个核心考点讲透，每个考点都结合配图里的类比来讲解，帮你轻松记忆。 先给大家梳理一下整体的知识框架，这九个考点按照从基础到高级的逻辑排列，首先是 agent 的 定义，然后是三个决策与通信机制， react 模式、 function、 calling m c p 协议。接下来是三个能力支撑体系、记忆类型、工作流节点、工具描述。 最后是两个架构对比与优化、两类 agent 对 比和 reflection 反思机制。这九个考点构成了理解现代 ai 系统的完整知识图谱。好，我们先从第一个考点开始 agent 的 定义。 这个考点用了一个非常形象的游戏类米，普通大元模型就像一个游戏攻略指南，你问他怎么找钻石，他会给你列出步骤，但他只告诉你方法，你得自己动手操作。而 agent 就 像一个自动化的游戏脚本，它能自己控制角色移动、采集资源、合成工具、连续完成找钻石、挖矿、打造装备。这一系列动作不需要你一次次手动操作， 这就是最核心的区别，一个只动嘴，一个真动手。普通大语言模型是一问一答的单次响应，对话结束就忘了刚才在干嘛。而 agent 具备反馈循环，知道自己做到哪一步了。它有工具调用能力，能真实和外部系统交互。它是目标导向的，有持续的决策系统，知道最终要达成什么目标。简单说， agent 不 只是生成文字，而是能自主行动。 好理解了什么是 agent。 接下来第二个考点， react 模式。这个考点用了一个新手，做菜的新手站在厨房里，面前放着菜谱和食材， 你首先看菜谱，想想要先切菜再炒，这就是思考 salt， 然后你拿起刀开始切菜，这就是行动。 action 切完了，你看看土豆丝粗细，发现切得太粗了，这就是观察 observation。 于是你调整刀法，把土豆丝切细一点再炒， 想做看，然后再想，再做再看，这就是完整的 react 循环。 react 是 reasoning 推理加 acting 行动，把推理和行动交织成不断迭代的循环。 react 的 优势很明显，第一，思考过程透明，可追溯，能看到 agent 每一步怎么想的。第二，每步行动基于实际观察，而非猜测，不会凭空产生幻觉。第三，出错时可以从错误步骤重新开始，不用推倒重来。 这里有几个考试常见的概念，判断陷阱一定要记清楚。第一个 react 是 thought 到 action 到 observation 的 串行循环，这个是对的。第二个，同时并行调用多个工具，就是 react， 这个不对。 react 必须有外部工具返回的 observation。 四个 react 中的 observation 来自 agent 自身的推断，这个也不对， observation 必须来自真实的工具调用结果把做菜的类比记住，就不会搞混了。好，接下来第三个考点， function calling 函数调用。 这个考点用了一个全智能餐厅的类比，想象你去一家未来的全智能餐厅，你作为管理者，提前告诉服务员有点餐、上菜、结账、打包这些功能，这一步就叫声明函数，把能做的事情列出来，说明每个功能需要什么参数。 然后来了一个顾客，顾客说我要结账。这时候服务员不是在复述你要结账，也不是问确定要结账吗？而是直接执行结账操作，问你现金还是扫码，然后打印账单。你看，整个过程中，服务员听懂了顾客的自然语言需求，然后自己判断该调用哪个功能，自己把参数填好， 这就是方声拎的核心价值。他把大语言模型的自然语言理解能力和程序端的任意接口结合起来，让 ai 从只会生成文字的聊天机器人升级成行动导向的服务集成者。他不再只是说答案，而是真的帮你做事情。 具体来说，开发者调用大语言模型时，预先声明可供调用的函数列表，包括每个函数的名字，做什么用，参数有哪些。然后用户输入自然语言模型，自动判断需不需要调用函数，如果需要调用哪个函数，传入什么参数。开发者拿到函数调用信息，去执行真实的接口调用，再把结果返回给模型，模型整理成自然语言，回答用户。 好。接下来第四个考点， m c p 协议。这个考点用了一个统一充电口的类比，想象几年前的手机充电线，苹果用 lightning， 安卓用 type c， 还有的用 micro usb， 换个不同品牌的手机，之前的充电器就用不了了，家里每个人用不同手机，就有一大堆不同的充电线，非常麻烦。后来 usb c 慢慢统一了，现在大部分新手机都是 type c， 一个充电器全家用。 m c p 就是 ai 界的统一充电口，全称是 model context protocol， 也就是模型上下文协议。这是 antropica 在 二零二四年提出的开放协议标准。在 m c p 出现之前，每家 ai 公司的 function calling 实现方式都不一样，同一个工具要支持多个平台，需要为每个平台单独开发适配层，维护成本非常高。 有了 m c p 这个统一标准之后，开发者按照 m c p 的 ai 模型上使用，比如在 cloud 上开发的数据格式化工具，也能直接给 g p t 用，不用重复造轮子。 这个考点还打了另一个比方，就像酒店门卡方盛 call 令时代，就像每家酒店有自己的门卡系统，万豪的卡刷不开，希尔顿每次住新酒店都要重新登记拿新卡。 m c p 就 像统一的门卡协议，只要在联盟里登记一次，拿到一张统一的门卡，全程所有加入协议的酒店房门都能开，省时省力。 这里有个对比表，大家要记住 function coing 和 m c p 的 关键区别。从定义方来说， function coing 是 各 ai 平台各自定义的， m c p 是 开放标准。从兼容性来说， function coing 是 平台专属，不可附用。 m c p 是 任何支持的模型都可以调用。从开发方式来说， function coing 需要为每个平台单独适配， m c p 是 开发一次多平台通用。从使用场景来说， 方身拎适合单一平台的工具集成， m c p 适合跨平台工具生态建设好。接下来第五个考点，记忆类型。这个考点用了一个备考的类比，非常贴切我们现在 c i e 备考的场景，想象你正在准备考试，有三种不同的记忆方式在同时工作。 第一种是短期记忆，就是你考试的时候临时记住的公式，或者刚看到的题目条件，这些信息考完就忘，下一场可能就记不清了。对应到 agent 短期记忆，就是存储在大语言模型上下文窗口里的信息，特点是临时的，有容量上限，对话结束就消失。典型用途是当轮对话历史工具调用的返回结果。 第二种是长期记忆，就是你之前学过的知识点，比如数学里的勾股定律，可能几年前学的，但现在还能记得，存在大脑深处，随时可以调取。对应到 agent 长期记忆，就是存储在外部数据库里的信息，比如向量数据库或者关系型数据库，特点是持久化的，跨对话的，可以解锁。典型用途是用户的偏好设置积累的知识库。 第三种是结构化记忆，就像是你整理的错题本，你把每次考试错的题都抄下来，每一道都有编号分类，错误原因、正确解法，方便考前快速复习。对应到 agent 结构化记忆，就是存储在程序变量或者状态机里的信息，特点是精确的，可以程序化读写。典型用途是任务状态跟踪，比如任务完成了多少，当前做到哪一步了。 这三种记忆各司其职，互相配合， agent 才能持续跟踪。复杂的任务，不会做着做着就忘了自己在干嘛，不会重复做已经做过的事情，也不会丢失之前积累的知识。好，接下来第六个考点，工作流节点类型， 这个考点用了一个乐高机器人的类比，想象你在玩乐高机器人套装，盒子里有各种各样的积木块，每个积木有不同的功能。传感器积木是输入节点，用来感知外界环境。控制器积木是 l l m 节点，也就是大脑用来处理信息，做决策。 你想要组装一个遇到障碍就后退的机器人，你就把传感器检测距离，判断距离是不是小于预值，如果是墙就后退。这几个积木按照逻辑顺序拼起来，拼好之后机器人就能自主运行了，遇到墙就自动后退，不用你手动控制。 基于格式化工作流平台构建 a 阵的时候，整个工作流就是由这样一个个标准节点组成的。主要有这么几种节点类型，开始节点，也就是工作流入口定义触发条件和输入参数。 l m 节点调用大语言模型，配置系统提示词，连接知识库工具节点调用外部接口，比如搜索代码、执行数据库查询 fels 节点条件分支，根据变量值或者模型输出，走不同路径循环节点迭代处理，对列表中的每项重复执行同一流程。 问询节点也叫 human in the loop 人机协助节点，高风险步骤前中断，等待人工确认后再继续结束节点工作流出口定义最终输出格式和返回内容。 这里特别要讲一下 human in the loop 人机协助节点的重要性，这个也是考试常考的。在企业级自动化工作流中，对于一些场景必须设置人机协助节点，不能让 ai 完全自主运行。比如向客户发送大额报价或者合同前必须有人审核执行。数据删除或者不可逆操作前，必须有人确认。 ai 生成的内容涉及法律或者合规风险时，必须有人把关。这不是技术做不到，而是确保 ai 自动化，在真实商业场景中可信可控的工程保障机制。好，接下来第七个考点，工具描述的重要性。 这个考点用了一个医院给药的类比，想象，你在医院药房工作，要把药发给护士给病人用，错误的做法是什么呢？你只告诉护士一句，一般情况下不要给错药。然后你把药装在空白盒子里给护士，药盒上什么都不写，这样风险多大？护士根本不知道这个药治什么，有什么禁忌，一次吃多少很容易出医疗事故。 正确的做法是什么呢？每个药盒上都清清楚楚写着详细的服药说明和禁忌。比如这个药治高血压，饭后服用禁止与酒精同服，一天三次一片，肾功能不全者慎用。护士拿到药一看说明就知道该怎么用了，出错概率大大降低。 工具描述也是一样的道理。这里有一个核心认知，对于 agent 来说，工具描述本身就是高优先级的提示词模型，在规划应该调用哪个工具，什么时候调用的时候，工具描述的文本是最直接的参考依据。 在生产级工程中，有一个重要的原则，对于高风险工具，比如退款、操作、数据删除这些有不可逆后果的行为约束条件必须写在工具描述中，不能只依赖系统提示词。举个例子，错误的做法是把约束写在系统提示词里，比如只有查询退款政策后确认符合条件才能退款。而工具描述就简单写，向用户退款 有风险。模型可能在特定对话轨迹下，忽视系统提示词的要求，直接调用退款工具，造成损失。正确的做法是把约束直接写在工具描述里。工具描述要写清楚，向用户退款重要提示 仅在以调用退款政策查询接口确认符合退款条件后方可调用。本工具未经政策确认直接调用，视为操作为规，因为工具描述会随着工具选择时刻一起被模型提取，和工具本身绑定在一起，约束效果比写在系统提示词里可靠得多。这就是我们常说的约束。跟着工具走好。接下来第八个考点， workflow based 和 prompt based agent 的 对比。 这个考点用了一个组装家具的类比，想象你买了一套需要组装的书架， workflow based 的 方式就是严格按照说明书，一步步来，说明书写得清清楚楚。第一步，找 a 螺丝和 b 板子拧紧。第二步，装侧板，第三步，装层板，最后固定背板。每一步都有图示，你不需要动脑子，也不需要懂家具设计，按顺序做就能成功。这种方式的好处是可控，不会出大错， 坏处是不够灵活。如果说明书没写的情况，你就不知道怎么处理了。而 prompt base 的 方式是什么呢？就像你不看说明书，把所有零件摊在地上，让一个经验丰富的老木匠自己看图纸，自己决定先装什么后装什么。老木匠经验丰富，能理解整体结构， 可能会用更高效的方式组装，最后效果可能更好，但风险是，如果木匠状态不好，或者理解错了图纸，也可能装错，甚至装不起来。 这就是两类 agent 构建方式的核心区别。这个区别不是有没有工具调用，而是决策路径如何确定。我们来看对比表。从决策路径来说， workflow based 是 预定义的固定工作流，每一步怎么走都划好了。 prompt based 的 决策路径由大语言模型自主规划，走一步看一步，模型自己决定下一步做什么。 从可控性来说， workflow based 高，可以审计每个节点的输入输出，每一步发生了什么都清清楚楚。 prompt based 低，路径不确定，可能不知道模型为什么选了这条路。从灵活性来说， workflow based 低，有新需求就要改流程图。 prompt based 高，可以适应从来没见过的任务。从适用场景来说， workflow based 适合金融操作、合规流程这些对准确性要求高、不能出错的场景。 camp based 适合多跳解锁、开放式研究这些需要探索和创造力的场景。所以工程选型有一个原则，后果越不可逆的，比如涉及资金流、数据删除，越应该优先选择 workflow based 按固定流程来稳字当头，任务越开放，探索性的越适合用 prompt based 给模型更大的自由度，发挥创造力。 打个比方， workflow based 如同航班标准操作手册，每一步按程序来安全第一。 prompt based 如同让优秀飞行员自主判断，更灵活，但需要高致信度的能力保障。好，终于到了第九个考点，也是最后一个 reflection 反思机制， 这个考点用了一个改数学作业的类比想象你是一个学生，数学作业发下来，你发现错了三道题，错误的做法是什么呢？你把答案随便改改就交上去了，老师再改可能还是错的，因为你根本没搞懂为什么错，只是碰运气。还有的同学说我多做几次，三次取最高分，这也没用，问题的根源没解决， 正确的做法是什么呢？第一步，看老师的批注，哦，原来第三步计算的时候符号错了。第二步，回顾自己当时的思路，我当时怎么想的，为什么会犯这个错误？是粗心了还是概念没搞懂？第三步，制定修改计划。下次遇到这类题，做完第三步之后，专门检查一下符号对不对。你看，这整个过程就是反思，不是简单重复，而是分析问题，找根音，制定改进方案，然后执行的闭环。 reflection 反思机制就是这样用来解决 agent 死循环问题的。我们先讲一下问题场景，在工作流行 agent 中通常会设有质量检查节点，评分不足就重写的循环。如果模型没有从失败中获取到差异化的信息，就会反复生成相同质量的内容，形成无效死循环，转来转去出不来。 很多人有一个错误认知，以为调高 temperature 温度参数就能解决死循环，其实不对，调高 temperature 只是增加了随机性，让模型输出更多样，但不保证方向正确，可能还是在错误范围内瞎转。 正确的方案是使用 reflection 机制，加上失败记忆。 reflection 机制有三步工程实现，大家要记住，第一步，收集上轮失败信息，包括上一轮的输出内容是什么，质检节点的具体反馈，哪里扣分了，为什么扣分？还有历次失败记录，防止已经改过的错误重复犯。 第二步，强制输出修改计划。根据失败记录先输出一个明确的修改方案，列清楚上次哪里错了，这次具体改什么，不允许直接输出内容，必须先输出计划。第三步，按修改计划执行重写，基于前面制定的计划生成新版本，再次送入质检节点。 这里的关键原理是 reflection， 让模型在本轮经验的基础上迭代，而不是每次都从同一起点出发，每一次循环都比上一次有进步，这才是真正从错误中学习的工程基础。 我们再对比一下三种方案，仅调高 temperature 不 能解决死循环，因为只是增加随机性，不保证方向正确，设置最大循环次数上限只是治标，只是强制停止，不解决问题根源，只有 reflection 加上修改计划才能根治，让模型在差异化信息的基础上迭代，每一次循环都有明确的改进方向。 好，以上就是智能体 agent 架构九个核心考点的全部内容，我们今天从定义结构讲到决策机制，从记忆管理讲到工作流设计，从工具工程讲到架构选型，再到反思优化，整个知识体系就完整了。大家把这些生活化的类比记住，考试的时候概念就不会搞混了，我们下期再见！

我是安逸 agent， 交接时怎么保留上下文？这题说实话我当年也翻过车，不是不会，是达不到点上。这期我把三个核心方案掰开了讲，依赖注入怎么传数据， workspace 怎么共享状态， p to b 消息怎么协商？搞懂这三个，面试遇到这题，直接背完走人。点个关注，咱们开始。 先说个有意思的事。我之前面试也被问懵过，面试官问多眼诊器，同理，一个 a 诊的交接任务给另一个 a 诊的时，怎么保留上下文？我想都没想就说直接把输出传给下一个，结果他笑了，追问三个问题，我一个都没答上来。 第一种方案叫依赖注入，是最简单的，它的思路就是前序 a 诊的产出结构化，后序 a 诊的直接拿字段举个例子， a 审查完合同，输出一个 j 层，里面有 risk level 和 key hs， b 直接读这个字段做下一步， 实现起来三步， a 结构化输出，边排气注入上下文， b 按字段解析，好处就是简单直击，延迟低，适合线性链式场景。 第二种是 workspace 工作空间，适合更复杂的场景。依赖注入是一条链往下传，但有时候多个 agent 需要并行读同一个数据，或者数据是动态产生的，这时候依赖注入就不够用了。 workspace 的 思路是数据存到共享存储，按主题组织每个 a 阵的暗需读写，好处是支持多消费者和增量读取，用虚列号追踪上次读到哪了，但要注意数据一致性问题， a 写了一条数据， b 还没读到， a 又更新了， b 可能读到不完整的状态。解决方案是所有 record 的 设计呈不可变的新数据，写新 record 的 第三种是 p to p 消息系统，适合需要动态协商的场景。比方说 a 是 个调度 agent， 需要先问问 b 和 c 谁比较空闲，再决定把任务给谁。这就不是单向传数据了，而是来回好几轮对话。 p to p 消息的核心是 mailbox 邮箱和 protocol 协议，每个 a 站才有自己的邮箱收消息。协议定义消息类型和协商流程，流程大概是 a 发请求问 b 能不能接， b 回可以，并给预计时间， a 确认提交， b 确认接收。 坑在哪里呢？消息可能丢失，需要持久化重试，还可能死锁，需要超时检测。好选三种方案怎么选？记住一个原则，从简单开始，按需升级。依赖注入，复杂度低，延迟低，适合现行练式 workspace。 复杂度中，延迟中，适合多消费者和增量数据。 p to p 消息复杂度高，延迟高，只有在确实需要双向协商时才用，不要因为 p to p 听起来高大上就用它。简单场景用 p to p 是 过度工程，是面试中暴露工程判断力的大坑。 接下来说说怎么答。入门版多 a 证的交接保留上下文有三种方案，依赖注入，把前序产出作为 previous results 字段注入后续上下文实现简单延迟低。适合线性练势。 工作空间系统数据存共享存储，多 a 阵塔暗虚读写，适合主题共享和增量数据。 p 二 p 消息通过邮箱协议双向协商，适合动态尾派进阶版加一句，这三种是渐进式选择，从简单到复杂，暗虚升级 高手版，再结合场景讲 schema 约定和关键节点持久化说你有实战经验？面试里通常还会追问三个问题，第一个，前序 agent 还没产出结果，后续 agent 要等吗？可以等，但要用指数退避轮询开始快查，比如一百毫秒，逐渐放慢，比如最长等五秒，不要固定间隔空转。 第二个，上下文太长导致 token 爆炸怎么办？在交接点做上下文压缩，结构化输出，优先提取关键字段，对长文本作摘要，必要时持久化状态到外部存储。第三个，交接时怎么保证数据一致性？ schema 约定格式理解一致，加上不可变 record， 设计新数据写新 record， 而不是修改旧 record。 再讲四个大坑，第一个坑是直接传文本，前序 agent 输出自然语言，后续 agent 自己理解，容易产生歧义，正确做法是结构化输出 jason。 第二个坑是所有场景都用 p to p 消息引入，复杂度远超实际需求， 属于过度工程。第三个坑是交接完就不管了，交接只是开始，不是结束，后续处理失败，前序不知道，前序改数据，后续可能还在用旧的正确做法是双向确认机制和超时告警。第四个坑是觉得 workspace 可以 完全替代依赖注入， 简单练识场景， workspace 的 额外存储和读取延迟反而是负担，根据场景选择，不要追星。说两个我经历过的实际场景， 第一个是电商客服多 agent， 用户进线后意图识别 agent， 分 析想问什么，然后分配给退换或 agent， 投诉 agent 等处理。我们早期意图识别输出自然语言业务 agent 解析准确率只有百分之七十， 后来改成结构化输出，输出 intent reason order id 子段准确率提升到百分之九十五以上。 第二个是金融风控多 agent， 数据采集并行执行规则引擎执行风控，人工审核，处理疑难 case。 最终决策我们用 workspace 解决共享问题， 数据采集 agent 写到 risk data topic， 其他 agent 按区读，所有 record 设计成不可变的。教训就是数据一致性要提前设计，不要等出问题了再改。 最后总结一下， agent 的 交接保留上下文，本质是在信息完整性和系统复杂度之间找平衡。核心原则就三句话， skym 约定优于引事传递。关键节点要持久化，不要过度工程。三种方案基础，渐进式选择依赖注入 work 字 p to p。 消息从简单到复杂，按需升级。 面试时能说出这些，面试官就知道你不是在背八卦，而是真做过。系统主页有更多干货，点个关注，咱们下期见！

今天我要用二十分钟时间从零到一，给你讲透 skill， 让你从小白直接进化到 skill 专家。今天会包括什么内容呢？首先就是 skill， 它和提示词、系统提示词以及 mcp 的 区别。 然后我就说一下 skill 的 标准结构，它的底层原理，从哪里可以下载到好用的 skill， 然后判断 skill 好 还是坏的评价标准，以及 skill 的 编写方法，常见的 skill 的 设计模式。最后我会放上我自己经常用的，并且用过以后感觉非常非常大家都一起使用的 skill 进行一个推荐。 那在深入这些概念之前啊，我想先带你看一看一套真正落地的工作流，是我自己平常也在用的，我给它取名叫 map content factory， 它是一个可以从端到端的内容创作的 skill 工作流， 接管了我很多的创作工作，那它会有专门的 skill 像流水线一样接力完成。主要分四个阶段。第一个阶段是 researcher agent， 它主要负责网络搜索调研。 最后调研的成果呢，会按照固定的格式写进一个文件里面，作为给下一个 skill 的 交接。第二阶段会用 slidecraft 捕取调研的文件，把纯文字转换成美观的 html 形式的换登篇，它只负责一个格式的转换。 那第三个阶段，我会用 hyperframe 把 html 渲染成带动态效果转场和配音的视频文件啊。第四个阶段，我会用 content distribute， 相当于一个内容的分发， 把各个平台的规格自动裁切尺寸，然后生成封面，写不同的文案，然后准备推送。 有这样一个 skill 的 生产流水线的好处就在于它接管了你大部分的内容生产的工作，同时你可以在任意一个节点，比如说如果你对文章不满意，你可以随时回退，对 html 不 满意，你还可以把文章再次放到 photoshop 这个 skill 里面去调整。 那这是一个我用的 skill 的 工作流的一个演示，最左边会有一个写文章的 skill， 他 已经把文章写好了，保存下来了，然后中间是我的幻能片的 skill， 他 把文章读起过来以后，然后我们这里已经生成好了一个幻能片，我们打开看一下，大概是这个样子， 它会有不同的风格，然后按照不同的风格把文章渲染成网页端的缓存篇，然后我会把它交给第三个 skill 这个 skill， 它主要是把这样的网页缓存篇，也就是 html 文件生成成呃，带有动态效果的视频。 这三个 skill 都是紧密相扣，互相联系的，最后生成的效果。我们也可以打开这个文件，然后去预览一下， 这个就是一个完整的 skill 工作流，从文调研到文章，到静态画图片，再到最后的教学类的视频，就是很简单，大概二十分钟就可以深度完成 那么一套整个这样的 skill 流水线。它最核心的就是 skill 之间，它不通过对话记忆传递上下文，而是通过文件系统一直在交接成果。 每一个中间的文件都是明确定义的一个接口，那你上面按格式去写，下面他会按格式去读，哪怕你的 ai 服务突然断了，或者你的对话窗口关了，三天后再打开，只要文件夹里面躺着最新的那一个中间的文件，整个流水线就能没有断点的无缝连接上， 对于很多需要几十轮交互的复杂任务来说，这种设计几乎是必须的。中间的文件它就是一个很好很好的进度条。 那接下来我们来聊一聊 skill 它到底是什么？那在二零二五年底啊， ansapic 正式发布了 agent skill 的 开放标准， 到二零二六年五月，已经有超过二十款主流的 ai 产品接入了 skill， 包括说 cloud code， cursor codex， kimi tree 等等。那其实你花一个小时写好的 skill 呢？可以在所有这些平台上直接去附，用不用被某一款工具锁定住。 从文件形态上看呢，其实简单的，最简单的 skill， 它就是一份 markdown 文档，也就是一个文文本档，里面可以是中文，可以是英文，只要是人的语言都可以。那它开头呢，会用一个 yaml 格式的东西存放源信息， 源信息里面会包括一些名称啊，描述啊，版本啊，出发条件啊等等。当然了，一个生产级的 skill， 它包括的东西永远不止一个 skill 点 md， 一 般来说，它会有一个 skill 点 md 作为核心的指令，然后同时也会配着 reference 和 script， 分 别是参考和脚本。那我们现在打开源信息夹来具体看一下， 那这里我们拿 remote 做 hyperframe 这个 skill 来具体看一下，它是一个把 remote 类型的视频转换成 hyperframe 类型的视频的一个 skill。 那 这里我们可以看到它具备 reference， script， script， md， 同时还多一个 asset a reference 文件夹呢，它主要是放一些参考文件，比如说一些输出的案例啊，一些风格对照啊等等，主要是当做一个辅助资料。那 script 在 这里面，它主要是跑放啊， ai 可以 直接去跑的脚本，这个时候 ai 就 不需要有太多思考了，只要想好用哪个脚本， 它直接去执行就可以，这样可以保证百分之百的执行正确率。然后就是 script， 它其实是一个 ai 的 大脑，它决定了什么场景下应该去唤醒 ai， 以及拿到任务后怎么一步一步执行。这一层必须要精练，因为 ai 它的理解成本能力是有限的，核心指令如果太臃肿了，执行进度就会下降，这一步是整个所有的灵魂。 下面我们来比较一下 skill、 系统提示词以及 mcp 它们三个的关系。首先呢，这三者都涉及到给 ai 先打指令，但是它们定位是完全不一样的。系统提示词呢，它是全局的常规设定，也就是说从绘画开始到结束，它一直都在底层的上下文里面。 它的优点是覆盖面广，缺点是只能是一段扁平的文本，也就是说它装不下案例库，装不下脚本，更没有办法按需加载。项目规模上去以后，它会越来越臃肿。 但 skill 呢，它是一个模块化的三层的工具包，也就是说只在触发条件满足的时候，它才会去加载，执行完呢，也不会长期的占用记忆窗口。你可以在一个项目里面装上十几二十个 skill， 但是 ai 一 次只会加载需要那一两个。而 mcp 呢，它解决的是我能连接什么外部资源的问题。 如果把 mcp 比作是硬件驱动的话，那 skill 它就是跑在驱动之上的应用软件，也就是说两者互补。 没有 m c p 呢？ skill 光有想法，碰不到边界，没有 skill， m c p 它有性能，但是不知道怎么发挥，一个管能不能，一个管怎么做？ system prompt， 它适合放在贯穿所有任务的底层偏好。 而 skill 呢，它适合放特定任务的专业流程， m c p 则适合放一些连接外部世界的具体工具，三者各司其职，合理分工。接下来我们来讲一下 skill 的 底层原理，以及它为什么如此适配大圆模型。 首先就是 skill， 它给大圆模型提供了明确带有约束的指令，而不是模糊的意图。其次， skill 它有一个渐近式批漏的特点， ai 会先扫描是否需要加载，然后会加载中文，中文出发以后加载完整逻辑，然后它会看是不是需要引用 reference。 第三呢， skill 它是可以条件触发的，可以通过直接调用，也可以关键词来匹配。也正是因为这样的特点， skill 它是极其的省 token 的， 一百个 skill， 它大概只占五千个 token。 而一般来说呢，对一个一百万的上下门窗口，一个 skill 大 概也就只占百分之零点二到零点四的一个比例。但这并不是说 skill 就 可以想写多长写多长。一般来说， skill 的 正文控制在五百到两千字是一个最好的甜蜜点，太短的话约束不足，太长的话就会稀释注意力。 那从哪里可以获取高质量的 skill 呢？我推荐三条路径。首先就是去 skill 的 s h 下面下载，它是由 word， excel 出品的， 优点就是标准化程度高，而且支持 npx 一 键安装，非常适合用正规军。第二条就是小红书，因为它上面有大量的中文创作者，沉淀了很多本土场景的 skill， 缺点就是质量会参差不齐，需要你自己甄别。 第三条就是你自己写 skill， 自己用，它其实是最贴合个人实际工作流的，你不需要会编程，只要你能把日复一日的任务用文字表示清楚，你就可以用一个基础的 skill。 那如何去评价一个 skill 的 好坏呢？这里有五条标准，首先就是一个 skill 应该只专注于一项工作。第二 skill 应该有足够的交互性和定制性，关键决策一定是要用户来做主的。然后就是我们刚才提到的 skill 应该控制在五百到两千字之间。 第四就是 skill 他 要有明确的边界条件和注意事项，他应该主动写清楚，这个 skill 应该要比全能 skill 更可靠一些。第五就是可以组合性， 它会把输入接口、输出的格式都定义清楚，你的 skill 应该能像乐高积木一样跟其他 skill 拼接，组成一个 skill 的 工作流，而不只是单打独斗。第八部分我们来讲一下 skill 到底怎么安装。首先 skill 呢？它的安装有三个层级，企业级、用户级以及项目级。 如果你安装在了项目级，这个 skill 它只有在项目里可以用。如果安装在了用户级，它会在每一个项目里面生效。 那一般来说呢，会有三种安装方式，首先就是手动复制到对应的 skill 目录，或者你也可以用 npx 一 键去安装。 还有一种方法就是你把链接直接丢给 ai， 让他去帮你配置，等项目会有一个具体的演示。那如何触发 skill 呢？第一种方法就是打一个斜杠，完整的输入 skill 的 名字，这样就可以强制触发。 第二种方法就是你直接用人话告诉 ai， 我 要用这个这个 skill 去完成什么样的任务。第三种如果你忘了调用 skill， 有 的时候 ai 会判断你这个任务适合用什么样的 skill， 会帮你触发。下面我们来看 skill 的 具体安装方法。这里面是一个 skill， 我 们直接点击 code， 点击 download zip， 这里面展示的是第一种安装方法，也就是我们直接把文件夹创建好，那我们下载完以后呢，我们直接去嗯， 解压缩，然后点开 skill demo， 这是一个你的工作文啊，文件夹在这里面。解压缩以后，我们打开这个文件夹，看到这个 skill 在 这里面了，当然这还不够， 因为呢 skill 它需要在正确的目录结构。什么是正确的目录结构呢？首先我们需要创建一个文件夹，叫做点 cloud， 如果你用 cloud 的 话是点 cloud， 如果你用其他的话就叫点 agent， 那 我们这里面写一个点 cloud， 然后把它移到里面。 玩上这一步还不够，点开脚壳以后，我们还需要再创建一个 skills 的 文件夹， s k i l s， 然后我们把我们的 skill 移到里面， 这样我们的 skill 就 下载完了。现在我们演示第二种下载 skill 的 方式，这是 skill 点 s h 刚刚介绍的下载 skill 的 网站，比如说我们想要这个 skill， 我 们直接复制这个指令， 这个是 npx 的 下载方式，我们点开我们的 vs code 或者其他的，嗯， ai agent 都可以。那我们点开这个终端，然后我们在这里面直接把刚才的指令复制给他， 打一个回车，他就会一步一步引导我们下载，可能会是英文的哈，这里面他已经自动帮我们选好很多了，我们还需要额外的话，可以再勾选额外的你的对应的编程工具， 那我们点 color code， 然后 project 就是 一个是项目层级，一个是个人层级，项目层级是在项目生效，个人层级在所有项目生效。然后我们继续点 yes， yes， 然后他就帮我们安装成功了，这样下载非常非常快。 然后我们就可以看到我们的 skill 已经在对应的文件夹里面了。 skill 下面有 brainstorming 和 slidecraft skill， 那 我们现在看一下第三种安装方式，我们找到这个 skill 的 仓库，然后让 ai 去帮助我们装这个 skill， 这是一个 ppt 的 skill， 我们点击复制，然后同样打开我们的 vs code， 我 们点击右上角的这个克拉的插件，我们直接跟 ai 说话，让他去帮我们安装。 那我们在这个下方把这个链接粘贴过来以后，我们直接跟他说，请你帮我下载一下这个 q， 然后你也可以说清楚，下载在本项目层级的文件夹里面就可以了，不用下载在用户层级。 那我们发给他以后，我们需要一段时间去等待他去下载，这样的方式会稍微慢一些，然后这个时间我们可以正好测试一下刚才的 skill 没有安装成功。我们可以试一下我们的第一种 skill 的 触发的方法，也就是打一个斜杠，我们点击这里面， 然后打一个斜杠。嗯，可以看到 brainstorming 已经在了，再打一个斜杠，输个 s， 可以 看到 photoshop 也在，这两个 skill 就 可以顺利调用了。如果你的 skill 没有顺利调用成功的话，可能是没有发正确文件夹，或者是你需要新开一个窗口，它才能重新加载。 那我们要如何从零到一，自己写一个 skill 呢？这里有一个从零编辑 skill 的 五步法，那好用的 skill 呢？它一定是诞生于一线业务的。那下面这是我的一个编辑路径。第一步，你一定要定位重复率最高的工作， 而不要凭空造一个 skill。 你 可以想想过去一周自己的工作记录，哪件事每天要做，步骤基本不变，而每次都要花费大量的口舌和介绍背景，这就是非常适合 skill 化的任务， 从一个小痛点开始。第二步，你要把隐性的知识显性化，把脑里面的直觉和经验一字一句的写成 ai 可以 理解的步骤，而不是让 ai 自己去猜你在想什么。 第三步，我建议你开 play 模式，携作用优质的案例去做反向裁剪，让 ai 自己读几份你的高质量作品去总结规律。第四步，我建议你跑通实测，写完以后你不要立刻就调整措辞，补充约束，增加负面案例，一般需要三到五轮实测才能稳定。 第五步，就是去测试触发词，确保你的触发词能被准确的识别到。如果你不喜欢这样的方法的话，你也可以每次记住名字，打一个斜杠，但确保不要跟其他 skill 有 冲突。 在你做你自己的 skill 的 时候呢，会给你下面这四个大的原则一定要遵守。首先就是视力的说服力远远大于文字描述， 你可以给多个 ai 一 些参考，让他去反向拆解理解你的意思。然后一个 skill 只专注于干一件事，但你可以把多个 skill 排成一条管道， 这样他们就能实现非常复杂的工作流。然后就是你要让用户成为核心的决策者，而不是 skill 替你决策。最后你要固化真实的工作流，而不是虚功所敌。 最后我想分享六个常见的 skill 的 设计模式。首先就是检查清单型，他会把大任务拆成不可细分的检查点，一个一个核对完成，一个打一个勾。第二就是交互确认型，也让他独立完成分析以后，他会在每个关键的角色点停下来，给出多个备选的方案。比如说像这个 slidecraft skill， 在我完成文章以后调用它，在调用它整个过程中呢，它会在多个关键的节点去询问我的意见，让我深入的参与其中，这样保证它的意思。它的想法跟我的想法是完全对齐的， 而且不仅可以做到和我完全对齐，也可以做到把它放到网上以后，它可以和无数的不同的人完全对齐想法，做出适合每一个人的产品，而不只是只适用于我的 skill。 呃，下一种是文件流水线型，上一个阶段的输出会作为下一个阶段的输入。阶段与阶段之间呢，主要靠一些文件来连接，好处就是它可以防止绘画中断，而且每个阶段其实都是独立的。第四种就是反向拆解型，把高质量产品归给 ai， 那 反向推导出步骤其实永远像那个蒸馏的 skill。 第五个就是模板定制型，他会先定义好输出的框架和章节的结构，再让 ai 去具体填一些内容。第六种就是工作流的固化型， 先手动完整的做一遍任务，等完整做一遍任务，这个流程已经跑通。确定好之后，让 ai 观察你的操作步骤和决策逻辑，再让 ai 它去提炼，抽象成一个 skill。 下面我想说一下 skill 跟 mcp 的 一个配合的关系。如果你把 ai 一 键的整体能力分层的话，最底层的就是模型，层是大脑， 中间就是 mcp， 他 是手脚跟感官，最上面的才是 skill， 他 是经验和肌肉记忆。那你模型再聪明呢？如果没有 mcp， 他 就碰不到外部世界，而没有 skill 呢？他就不知道该怎么去利用，怎么去改造外部世界 未来趋势呢？很可能是 mcp server 跟 skill 成对，出现一个提供标准化的接口，一个提供最佳时间和流程模板。 最后我想分享一下我个人长期在用而且推荐的 skill 的 清单内容。创作方面，你可以用 slidecraft 来生成你的演示文稿，你也可以用 remotion 让你的代码变成视频，或者你也可以用 hyperframe， 这是一个比较新的一个 skill， 它会把 html 变成视频。 开发方面呢，会给你推荐 code review 来检查代码。 skill creator， 它用来创建其他 skill， 房产抵押用来设置美丽的前端界面。 superpower， 它是一个整套的开发效率套件，完全可以试一下。 而当你想用一个 skill 但是不知道在哪的时候，你可以用 find skill 来帮你找到 skill。 其他的包括 grimy， 它可以模拟严苛的问答来检验你的思路。 keepman， 它可以让你的输出 token 直接降百分之五十以上，但是信息无损。 最后我想说，做一个 skill 其实并没有你想象那么难，它其实最适合从最小，最重复，最让你烦那个任务开始，像打磨工具一样，跑一遍，改一版，再跑一遍，再改一版， 一点点积累出来。越早开始积累，最后的复利效果越明显。很多工具也会过时，但沉淀下来的流程不会过时。

hello， 大家好，这里是永泽，今天我们来跟我们项目最近更新的一个部分，就是思考办事 react 的 一个处理。嗯，之前我们使用的就是一个链式串行的一个 react， 也就是我常说的一个循环。嗯，简单来说就是三步骤嘛，然后就是 thinking， act 还有 observation， 也就是先思考调研工具，得到结果，经观察之后再进行下一步推理。那么实践是非常简单，就是一个循环。那么问题很明显，整体流程是串起的，一个节点慢，后面都会被堵塞， 那么我们最新的更新呢？哎，通过这 agent 的 workflow 实现了这么一个动态的图结构，而不是固定的一个链路。那么核心思想就是把一个任务拆成很多节点，每个节点代表一次推理工具调用或者数据处理，然后根据依赖关系组成任务图，比如类似 d， a， g 这种， 例如搜索完成之后才能做信息总结，代码生成完之后才能进入测试节点，所以就形成了形成了一个依赖的关系。那么在调度上呢？呃，我会使用拖排序 管理这么一个执行顺序，然后通过这个入度和出度，也就是图嘛，如果大家有了解的话做算法，有了解的话通过这个入度出度，然后控制这么一个节点依赖，当某个节点的入度为零时，那说明他前置的依赖已经没有了，所以他就可以立即执行。所以最大好处就是原本串行等待步骤可以并行运行， 那么像比如这个搜索资料，拉取记忆，拉取网页等等，那么互相没有一代，就没必要一个个执行。那么还有一个竞速机制是我们的一个补充吧，也就是说如果多个节点属于同性质的任务，那么系统会并行执行，谁先返回呢？就优先采用结果。 那么几个原因，一是 ai 系统呢，本身具有不确定性，第二个并行呢，能显著降低整体任务的耗时啊，就类似于我们平常会用一些高病发来解决这么一个串行，对吧？ 第三呢，提供提升这个系统稳定性，也就是说，呃，某个节点失败，其他节点仍然可以返回，结果类似于分布式，对吧？分布式有这个赋载机，好像其中一个节点挂了，另外一个节点还能工作，嗯，也就是它那个 cp 里头那个 ap， 应该是 ap 吧，那那个那个内容吧。 然后第四呢，然后后面更容易拓展这个 a 多 a 阵的闲作啊，我们这个项目现在还是在做单单 a 阵的这么一个，后续可能会更多 a 阵的。那么简单说，就是 react 从链式调用呢，升级成可调度可并且可恢复的任务同步 time， 所以 我们来具体讲一讲， 咳咳，前沿呢，就是说可以就立刻刷一下这个课程表啊，这这里我就不带大家刷，大家私下来可以去刷一刷，简单说就应该就是一道图相关的一道题吧。 那么刚才我们介绍啊，串形列式，也就是传统 react 本质 sort action of observation， 也就是说思考行动，再到观察，那么一步步串形推进，当前步骤完成，才能进行下一步上下文限行，每次只维护一个执行路径， 这是他一些典型的特点嘛，就是单线单列路的这么一个串行，然后单线成思考顺序，调用等等。 那么适合场景呢？就是一个简单的问答，然后单工具的一些任务一次性推理的，比如说用户问北京的天气，他思考就说需要查询天气，然后 action 就 调用了天气查询这么一个工具。 opson 观察到了最后结果，然后汇总回到，呃，回到回答最终的答案，这是最经典的 react 嘛。 那么我们这就采取的是一个动态图的这么一个动态图的任务图，类似于这么一个结构，对吧？ 它本质的是一个 react， 加上 d a g， 就 像无环图 d a g run time， 然后加上 state for scavage， 也就是说一个安排嘛， 核心区别呢？动态图 react 和串行链式呢？有一个核心区别，也就是说执行结构，一个是链表就是串行嘛，另外一个就是通过 d a g 等等，一个是单路径，一个是多路径，然后有，呃，一个是单上行文，另外一个就是节点上行文。其实最 让我们能感受到，其实就是一个可并行嘛，对吧？就是一个人串行，一个人可可并行。那么为什么动态图根现金呢？因为真实的 aj 的 任务不是限行的。 这个怎么理解呢？简单来说，就给到这个例子，呃，帮我分析工资财报，并生成投资意见，那么实际上我们会猜成拉取财报，拉取行业数据，拉取新闻，然后分析风险分析增长汇总生成报告。 那么这里天然就是一个 d a g， 因为最终汇总的时候，我们需要前面了，为呃前面的数据来为我们作为这么一个支撑，所以拉取数据之后呢，风险风险分析和增长分析，我们要同时来为它做一个并行操作，所以它不是一个信链。那么接下来我们来讲一讲动态 react 的 一些关键组件。 第一个就是 planer， 也就是任务规划，也就是说我们呃遇到一个任务之后，先把任务呢拆成这么一个图的结构啊，一个 go go 就是 一个目标嘛，然后拆成一个通过 subtext， 然后生成呃，区分成一个节点。 第二个是 runtime state， 也就说每个节点呢，有一个独立的这么一个状态，然后并不是全部的塞到这个 promont， 全部塞到这么一个提示词里头。第三个也就是我我们说的调度器，然后决定哪些节点可以执行，哪些它的依赖已经完成了，哪些失败重试哪些进行这么一个并行。第四个是 memory graph 记忆，不再是 conversation 呃， history， 也就说不再是绘画历史，而是一些状态，然后一些 working memory， 也就是说一些工作的一些记忆等等。 那么例如啊，就是节点 a 输出啊，那么节点 a 输出之后，那么他的出入度已经完成，那么节点节点 d 的 他那个入度也已经完成，之后就可以进入节点 d 的 这么一个输入，是一个图连接，这是一个直观的串形 串行 react 呢，就像一个流水线的工人。那么动态 react 呢，像一个分布式调度系统，最直观的区别呢，也就是执行速度加快啊，因为运行速度增加了嘛。那么本质呢，串行 react 是 一个 prom 的 驱动，驱动的这么一个推力啊，就是一个循环嘛。动态图 react 呢，是一个 runtime 驱动智能体， 其呢就 l i m 不 再直接控制全部流程，也就是说原本的串行 react， 它这个什什么时候停止，什么时候执行呢？是由 l i m 自己去决定的，根据它们这一个观察到结果自己决定。 那么动态图 react 呢？本质呢？ l i m 负责一个认知， runtime 负责一个执行，那 schedule 也是负责调度，比如说什么时候并行了，什么时候执行那个节点，那原本也负责它记忆的，负责一个状态，所以这是现代 a 阵的一个核心方向。 那么业界的引进趋势呢？叉五，叉五 sort 也是 c o t， 它是一个思维链嘛，再到 react， 然后 plan 的 一个 q 的， 这是我们之前讲过的，先计划，然后再执行，再到我们今天讲的这么一个图，然后再到 stand for， 呃 re- re- time， 呃 re- time- agent 等等， 所以基本上呢，哎，都在 re- re- time- re- time agent 等等，所以基本上呢，哎，都在 re- re- time 划，然后不再做这个提示词链路， 这是一个动态图的一个，再到最后一个动态图的实实现算法。那么本质流程呢，也就是找入度为零的这么一个节点，然后接着我们进行这么个执行，然后编辑，删除编，然后更新其他节点入度，继续调度。 那么真正的这么一个 a j 的 runtime 或者 walkthrough 引擎里头会加上一些状态机了，调度器，优先级，运行池等等啊，重置机制，然后最后形成这么个 d a g 啊， schedule runtime， 然后最基础的第一级执行模型，这是一个呃，小例子吧，然后一些数据结构啊，批判子，也就是他依赖于谁，然后 next， 也就是一些后置的一些节点， indiff， 也就是我们的入度啊，这有需要一些图的一些前置知识啊，大家可以去看一看， 然后再到经典的一些算法，然后他会出示一个吨力，把所有入度为零的节点都放进去，入度为零代表他可以立即执行吗？然后第二个就执行节点，执行节点了之后，然后 c 原本它的入度，呃，是二，那么 a 到 c 有 一个边，那么 a 到 c 这个边就被删除了，那么 c 的 入度也从二变成一，那么再执行 b， 那 么 b 到 c， 它这个边也会被删除，那么 c 的 入度也变成零，所以 c 可执行，那就进入到可执行这么一个队列了。所以为什么很多系统用小顶堆呢？小顶堆就是多个节点可以同时执行，需要一个调度的一个策略，策略，呃， 小底蹲，也就是小底蹲排，呃，排序依据，比如有些 bfs 优先级啊，最早创建最远任务， a a 政策等等， 呃， bfs deep 了等等。所以并不是一个普通的这么一个队列。那么现在的 front 们怎么做呢？也就是说真正复杂了是节点执行，不是同步的一个函数，而是 future， 或者说是一步的这么一个一些任务。所以呢，呃，这个调度调度器呢，会通过这个提交任务，等待完成，然后再继续更新它的依赖，进入下回下激活它的下游节点，也就更新链会删除边了，然后更新入度了，等等。 比如一些经典的框架啊， long， 二 f 等等，那么 a 帧的状态比普通 d a g 多的东西就是普通 d a g 是 节点等于函数，那么但 a 帧呢？节点等于 l m concrete， 呃， step 这个单词不太会念，所以节点呢，会从呃节点状态会变为一个 class agent agent node， 也说一些思考、动作，观察等等。 memory to result 并不是简单的一个呃函数调用 啊，那么真正工业级这么一个 scanners， 也就是真正工业级这么一个调度器啊，会维护所有。首先是一个 ready， ready quit， 也就是所有入度为零的未执行的这么一个节点。 ready set 呢，也就是当前执行中的节点。然后再到 finish the set， 也就是完成的这么一个节点。再到还有一些失败的一些节点， depends map， 也就是它的一些依赖的一些图，依赖的一些地图，这是整体。我们今天讲啊，关于 react， 就是 说动态图 react， 也就是我们最近项目一些更新的一些知识， 然后之后我会给大家更怎么评测，呃，记忆系统，这是下一期这么一些内容嘛？然后关于这个内容的话，呃需要一些前置知识，比如首先你知道 react 是 什么，另外一些关于动态图 react， 你 还你还要了解，比如 d a g 一 些基本的 啊，这是网上一些呃第一季工作流，第一季本，呃工作流的本质是依赖图，告诉编程那些任务可以同时做，我们 a， b， a 等等等啊，这是网上一些开源的一些，大家也可以去学一学啊，这是今天我们的一些基本内容，谢谢大家观看。

今天我们来聊一聊，在设计和实现一个 agent 系统的时候，如何通过分层的方式对代码执行、文件操作和并发控制进行安全防护。没错，这个话题最近真的很火，那我们就直接进入今天的内容吧。首先我们要讨论的是 在搭建 a 阵的系统时会遇到的一些工程挑战，为什么这些问题会成为很多团队难以绕开的障碍呢？其实就是在让 ai 执行代码的时候，会有很多不可控的情况，比如说它会不会删除或者修改一些重要的文件， 嗯，或者说多个 agent 同时去读写一个文件时会产生冲突。还有就是有的时候进程会崩溃，然后所文件就会一直残留，导致整个系统卡住。确实这些问题听起来就让人头疼。这三个问题几乎是所有开发 agent 平台的团队都会遇到的， 很难去规避。那这次我们要聊的这个 cloud code， 它是怎么处理这些问题的？这个工具其实是 aerospace 公司自己家的一个 ai 编程终端。嗯嗯，它每天都在用户的电脑上面执行代码读写、文件管理下发的任务， 但是网上几乎没有什么深入的分析资料，所以我们直接去看了它的源码，看源码确实是最直接有效的方式。是的，我们今天会给大家讲的就是在设计 agent 平台的沙箱和存储系统的时候，可以借鉴的一些思路。好，我们先来看 python 二一 p l 沙箱，它是一个黑名单机制。 对，那这个东西它到底是怎么实现的？又会带来哪些安全的隐患？这个沙箱的实现在 g o s h u 下划线 bridge 点 p y 里面，它其实就是一个黑名单。 嗯嗯，它会去拦截一些比如 os， subprocess， socket， import， loop 这样的危险模块，还有 exact， evo， open 这些内置函数。听起来很严密，但是黑名单是不是会有一些遗漏错， 它只是把最常见的一些风险给拦住了？对，但是它的源码里面也有写这是一个黑名单， 不是安全边界，建议配合操作系统级别的隔离哦，所以它其实是一个安全和可用性之间的一个取舍。明白了，那这种沙箱的设计对于我们自己去开发 a 阵的平台有什么启发呢？首先就是不要去做一个非常死板的沙箱， 可以给用户一个选项，就是它可以选择宽松模式还是严格模式，让用户自己去选择它的信任边界。 对，然后最重要的是一定要在文档里面写清楚，这个沙箱到底可以防什么，不可以防什么，因为安全上面过度的承诺比不承诺还要危险。没错没错，下面我们说一下文件锁 为什么 cloud code 要弃用传统的 flag， 而选用了 o crate 和 o 下划线 exl 来做文件锁？这背后到底有什么考量呢？其实这里的关键就在于， flag 是 一个建议性的锁， 意思是别的进程愿不愿意遵守全凭自觉。对恶意进程或者不配合的进程完全可以无视你的锁，直接去读写文件。所以说用 flag 的 话， 这个锁不是很可靠。对，而 ocreate 和 o 下划线 excl 是 利用了文件系统的存在性语义，操作系统内核会保证只有一个进程可以成功地创建文件，即使对方不配合，不知道你加了锁，它也创建不了同名文件。 如果进程在持有锁的时候崩溃了怎么办？这一点 code code 也有考虑到。它的锁文件里面会记录 pid 和加锁的时间戳，然后系统会定期地去检查，如果发现这个进程已经不存在了，就会自动地把这个锁文件删掉，这样就不会出现死锁了。哦哦， 这种方式确实还挺巧妙的是吧？而且 ocr 和 oe xcl 是 所有主流系统都支持的标准语义，所以这种方式在多语言的环境下会特别有用。 对，就是你，不管是 python、 node js 还是 go， 都可以用这种方式来做，它的兼容性会非常好。哎，那如果我们的系统里面有很多紫禁城，或者说经常会有容器重启，会有什么影响吗？ 在这种情况下，进程崩溃或者说 o o m q 是 很常见的。如果没有自动清理锁的机制，可能就会因为一次异常导致整个系统卡住。 对，所以自动清理机制是非常必要的。明白了，下面我们来说说 session 锁，就是 pid 复用会带来哪些隐患。然后 cloud code 是 怎么解决这些隐患？问题就出在操作系统回收 pid 的 速度其实是很快的， 进程 a 持有锁之后崩溃了，它的 pid 被回收了，然后很快又被分配给了全新的进程 b。 啊，那如果只检查 pid 的 话，系统可能会误以为旧的锁还在生效。 所以 cloud code 用了一个双重验证的方式，就是它不光会检查 pid 是 不是还存在，它还会记录进程启动时的系统时间戳 同一个 pid， 但启动时间不同就判定为不同的进程，认为锁已经过期。懂了，那在不同的操作系统上面，怎么才能获取到进程的启动时间呢？在 linux 上面是通过 ps 命令，在 windows 上面是用 power shell。 嗯嗯，就它是一个非常典型的跨平台工程实践，要针对不同的系统写不同的代码。好的，还有一个问题就是为什么在打开锁文件的时候要使用 o no follow 标志？ 这个其实是为了防止符号链接攻击，就是如果你的锁文件是放在共享目录，比如斜杠 t m p 下面，那攻击者可能会把你的锁文件路径替换成指向你系统敏感配置文件的符号链接。 然后当你的锁清理逻辑去尝试删除这个锁文件时，它就会误删你的关键文件。所以说 o n o follow 就是 用来防止这种情况的。没错没错，只要加上了 o n o follow， 那 系统就会禁止去跟随这个符号链接，就可以保证你的锁文件操作是安全的。好的，我们来总结一下 基于 pid 的 进程存活检测和文件系统操作有哪些通用的安全建议。首先，任何时候你用到了 pid 去做进程的存活检测，你都要考虑到 pid 复用这个问题，尤其是在容器化的环境下，或者说你要频繁地去创建子进程的情况下。 对，然后第二就是如果你的 agent 平台涉及共享目录或者文件系统级别的操作，一定要做好符号链接攻击的防御。 好的，接下来我们要讲的是任务级的并发症，就是在多 worker 的 环境下，怎么保证一个任务只被执行一次？其实在这个场景下，多个 worker 会共享一个任务列表， 那核心就是要保证每个任务只能被一个 worker 抢到并执行。是的，那 cloud code 是 具体怎么做到这一点的？它的做法是分三步， 第一步，他会先乐观地去预检任务的状态，比如说这个任务是不是 pending 状态，是不是应该由当前的 worker 来执行，前置依赖是不是已经完成了等等。如果这些都不满足的话，他会直接跳过，不会进行后面的步骤。对，这样可以减少很多不必要的锁竞争。 确实，先筛选一遍的话，可以减少很多抢锁的次数。错。第二步，他会对通过预检的任务用 o e x c l 去创建一个锁文件来竞争。 这一步是由操作系统内核来保证只有一个 worker 能成功地创建这个文件，那是不是意味着拿到锁就可以直接执行了？还不行，还需要。第三步 就是拿到锁之后，它会再重新检查一遍任务的状态，因为有可能在你刚才检查和枷锁的间隙，这个任务已经被其他的 worker 改过了。对，这一步叫做锁内重读验证， 这一步可以彻底地避免静态条件。懂了，那这个三阶段的做法，在我们自己设计一个 doorker 调度系统的时候，会有哪些借鉴意义？这个就非常有用了，你可以直接把这三步 预检加锁重读这三步直接搬过去用。对，先预检可以减少锁竞争，提升系统的吞吐量，然后用原子锁来保证只有一个 worker 可以 抢到这个任务，最后再用锁内重读来保证这个任务的状态是最新的，这样就可以避免很多错误。 好的，我们接下来看一下 bridge 的 生命周期管理，就是它在建立通信的时候是怎么去做四层验证来保证安全性的。这个 bridge 其实是负责 cloud code 的 lodges 主进程和 python 子进程之间的通信的。对，每次新建一个连接的时候，它都会做四层验证。 第一层会先验证 session id 是 不是匹配，这可以防止绘画数据被篡改。那第二层呢？具体会检查哪些东西？第二层会检查 socket 的 路径是不是预期的路径，这可以防止路径被劫持。 嗯，第三层会去验证 pid 和进程的启动时间，这可以避免 pid 复用带来的一些问题。最后第四层会检查 socket 文件的类型，防止有人用一个普通文件来冒充 socket。 只有这四层都通过了，才会建立通信。明白了，那如果要终止这个 bridge 进程的话，它是怎么保证数据不会损坏的？它采用的是信号逐级升级的方式。 一开始它会先发送一个 sigent 请求优雅地退出，然后会等五秒，如果没有反应，它会再发送一个 sigterm， 再等二点五秒，如果还是没有反应，它才会发送一个 sigil 强行终止。 对，这样可以给晋城足够的时间去做一些清理工作，尽量的避免数据丢失哦。那如果富晋城突然挂掉了， bridget 会怎么处理？ bridget 内部有一个守护县城， 他会定期的去检查富晋城是不是还活着，如果发现富晋城已经不存在了，他会主动的退出，这样就可以避免变成一个孤儿晋城。 好的，我们最后来总结一下在设计 agent 的 系统的时候，有哪些核心的原则是我们应该去遵循的。第一个原则就是默认信任， 但是要允许用户主动地去收紧，就是不要让安全机制影响到用户的体验，而是要让用户自己去选择它的信任等级。 哦，这是一个很有意思的思路。那第二个原则呢？第二个原则就是要诚实的声明你的能力边界，就是在文档里面写清楚你的这个沙箱到底可以防什么，不可以防什么，不要让用户产生误解，确实安全上面的事情是不能有模糊地带。 然后第三个原则就是跨境城的协调，尽量的去使用内核的原子语义，就是不要去依赖于合作方的诚实。 对，最后一个原则是分层防御，就是从 python 的 命名空间，到文件索到 pid 的 验证，再到 socket 的 类型检查，每一层都要在不同的抽象层级上面去堵一个特定的漏洞。好的，我们今天聊了这么多关于 agent 的 系统在安全和病发上面的一些设计思路， 其实核心就是要分层地去防御。对，然后要坦诚地去面对每一层的能力边界。错，那这期内容就到这里了，拜拜拜拜拜。

二五年毕业的学院本求职一项大模型算法工程师，然后呢，他在南京这家公司呢，做的呢，号称就是算法工程师，我们看他这个工作中做了哪些算法吧。首先第一个项目 是一个多智能体医疗决策系统做的呢，是基于 define 叉叉叉叉 a 这个 a 叉，它跟这个算法是不是关系有点差距大？你是不是很了解这个什么叫做算法工程师呢？然后项目成果还是 四个专项， agent 的 独立步数， agent 内部多阶段状态流转，通过验证。总而言之，这个跟算法有关系吗？ agent 是 算法吗？这什么理解啊？第二个 r a g 加多策略检测 ok， r a g 要几个这个 a p i 你 就成算法工程师了，我们不要呢对这个行业这么低认知，好吧，现在都什么年代了，这么低的认知真能够入行吗？啊？你这样说你自己算法工程师，你不觉得可笑吗？真真正的算法工程师， 他至少我跟你讲，他是了解里面那些数学原理的，并且他做的事情呢，基本上都在反听，你都在这个微调这个层面上。而 复杂一点的算法工程师，他干的事情可能要读一些 paper， 那 个 paper 是 全部的英文的 paper， 然后你要迅速在短时间内理解这个 paper 的 backbone， 这就是我们基本的一个考察策略。换句话来讲， 你没有一个硕士学历，没有个九八的硕士学历，你搞什么算法呢？根本连这个什么是 paper 的 backbone 你 都搞不明白啊，自己没有读过 paper， 自己没有发过 paper， 你 怎么可能做的了算法？ 我说句实话，我在大厂，我就在阿里巴巴见过高中学历算法工程师，但是我跟你讲，人家这个算法工程师，人家就是能读那个全英文的 paper， 很 快能读出来，跟你用全英文进行交流。因为在当时那些年代下，对于很多八零后来讲， 这个知识条件非常差，你能理解我意思吧？现在什么时候？现在是二零二六年，你们找工作都是零零后了，你们没有这么差的生活条件了，当时饭都吃不饱，你们先有饭都吃不饱的这个情况吗？没有了对不对？所以说有些八零后他确实这个学历低啊，他学历低是有原因的，他家里太穷了，没有钱供他读书， 而就算这些低学历的人，他后来成长了之后，拿到高 p 的 职位之后，他的英语能力有一样过关，他照样我跟你讲能考很复杂的东西， 但是你这个我跟你讲就是个笑话，二零二六年了，入行入普通的行，我跟你讲都需要工作经验，你想搞这种算法没有九八五的数真的清醒一下好吗？ 不要被那些培训机构去欺骗，人家给你讲什么什么，学个 ai 就 拿个高薪，我们稍微有点认知对不对？现在入行都需要你有工作经验，你不要说培训能当算法岗，培训连个普通岗位都进不去，原因很简单，因为你培训完的时候还是没有工作。 有工作经验和没工作经验差多大？我就这么跟你讲，一个人从阿里跳槽到腾讯，阿里和腾讯基础上完全不同，但是没有人觉得需要重新学一下，他一瞬间就会了。就怎么讲呢？一个知识能力的区别， 换句话说，他是内力的区别，能理解我意思吗？工作经验至少拥有内力，拥有这个内力之后，你学习速度会快很多。你去培训就学这个 ai， 学四个月。我跟你讲，一个大厂入门级的程序员， 学一天就完事了，半天完事就是差距，他从 java 变成 go 半天，一瞬间就变成了不用其他的样。模拟工作二十七关，闯过二十七关，你有这个水平的半天时间学会 a 阵的开发，半天时间学人家四个月的东西，半天时间就能从 java 形成 go。 这是每一个我跟你讲， 通过模拟工作获得这个工作经验的人所有的能够生出的一个神通。所以现在想入行啊，一定要培训，加上模拟工作培训，先学知识，然后模拟工作，学习这个工作技能，工作能力，最后才能成功入行。

codex 的 这波福利实在是太爽了，那些被 cloud 进行 kyc 阻拦的中国开发者可以换阵营了。昨天， openair 发布了 codex 的 重大桌面端更新，这次更新的版本叫做 codex almost everything。 这个版本的 codex， 它说几乎可以完成任何任务，它能够操作 mac 上面所有的应用程序，记住用户的工作习惯和偏好，并且能够跨天跨周期地持续完成任务。 这标志是什么？ ai 的 代理技术已经从简单的 ide 插件的拓展，正式升级到了操作系统的层面。昨天我在朋友圈发了这张照片，有的观众留言说，没看懂， 看了今天的新闻，我觉得你一定会懂。一开始以为不会怎么样，当你真正了用上了 codex， 那 种很爽的感觉就会让你欲罢不能。你就知道，一开始以为只是一次不会怎么样，但是你真正用上之后，你就无法失去它。其实刚刚的那张梗图是来源于这张图。原来大部分开发者是离不开 cloud 的， 哎。现在 opus 四点七刚发，山姆奥特曼就紧跟着把 codix 这个早就准备好的这个更新来推上来，看看谁卷得过谁，都是两百美金的 pro。 codix pro 和 cloud pro 它的使用体验是相差 n 倍的。 codix pro 呢，是量大管饱，而且可以开加速模式。 cloud ops 每次 去开这个模型使用的时候，都要去思考一下这一次任务它的消耗要花多少 token。 我 相信 cloud 刚刚更新的四点七， opus 的 模型是真的强，但是如果希望是使用轻松，不要老是考虑充值的问题。我认为 codex pro 是 一个非常好的选择， 而且再加上对于中国开发者不太友好的 k y c 验证，现在真的可以转移阵营去 codex 了。我们一起看一下 openai 的 官网是怎么说的，你看它怎么说的。 codex for 它为了严谨 almost everything， 它这是一个重大版本的更新啊，它这里说了三个方面的更新，第一个就是将 codex 拓展为 code 之外，它要除了做 ide 之外，未来很可能是想做一个超级应用。它之前向奥特曼在采访的时候就说，希望把 gbt， codex 还有 atlus 三个整合成一个超级的 app， 整合一个应用在这里呢，它增加了一个重大的功能，就是 computer use context， 把 opencloud 的 创始人招进去，绝对不是白招的。 现在 context 可以 协调操作 mac 电脑，配合使用生成图像，生成视频等等操作。而且它有一个内置的浏览器， 它可以在这个内置的浏览器和 web 端进行原声的交互操作。而且它这次也说了，它发布了九十多个新增插件，给大家演示一下怎么打开 context 的 computer use 的 功能。我们点开 context， 在 左边这个位置啊，有一个插件，点击一下 这里啊，选择 open ai 按钮，好，这里就是 computer use， 我 们点击加号安装插件， 点击安装 computer use。 好， 已经安装完成了，现在点击进来我们就可以调用 computer use 进行抽象了。 现在 codex 的 桌面端是最先可以在 mac os 系统上面使用，因为在苹果的系统上面的调试会相对简单和容易的。这也是为什么那个时候我在推荐大家买硬件的时候，大家可以去买一个 mac mini m 四或者是 mac 的 pro 笔记本电脑， 你看优势就在这里。所有大部分功能都会优先在 mac os 上面先推出，因为 windows 的 版本啊，系统啊，确实会比较多，它适配封装啊，事情比较多，一般都会先上 mac os。 除了 computer use 这个功能之外，我觉得这一次更新还有一个非常重要的点， 就是它增加了记忆功能，你看它这里说个性化功能里面增加了 memory 的 记忆功能，这个非常重要。你想有了 computer use， 有 了 memory 的 功能，那未来其他的 agent 还远吗？如果说它再上一个 i m 的 功能， 那我觉得真的可以一定程度上去替代小龙虾了。大家看到我这个 context 的 界面啊，你看这里会弹出一个个性化 context 的 引导，我这里点击 ok， 点击右下角的设置，再点击下设置，点击这里的个性化， 看到下方这个位置有个 memory 的 选项，可以选择这里的 enable memories。 这个功能对于开发者也是非常友好的，它能够记住你的历史篇号，你的纠篇信息，还有你的历史的上下文。第三个我觉得它的重要更新是它的这个自动化能力提升了， 它除了保留之前的上下文，而且它可以自动唤醒，自动续跑去执行这种长期任务。妈呀，我感觉这个 codex 简直是让人有这个恋爱的感觉了，是一个一直成长的陪伴型的伴侣啊， 就是未来啊。如果说它真的把 i m 街上真的是可以替代小龙虾的，现在我是把 openclaw 作为一个总的编排型的 agent 来使用的，它可以去驱动 codex， 驱动爱马仕这样的 agent， 它是可以给我去对话的，而且它的自由度，它的开放度很高。那么如果未来 codex 它的整个的 agent 整个的体验做得很好，而且可以通过 i m 去对话，我远程啊不在电脑边的时候，它也能够帮我去高效地去驱动这种长任务，它的这个未来是真的可以期待的。 而且现在 codex 的 增长数据正在说明这一点，它在今年年初的时候周活用户也就一百六十万左右，现在每周的周活用户是三百万用户，而且山姆奥特曼它的野心是直指我要做到一千万的用户， 不管未来怎么发展，至少这一段时间大家用 context 一定是非常爽的。太多的话我也不想说了，我赶紧去打开，我在 context 去接住这波稳稳的福利。更多的精彩请看玲姐说 ai 的 频道，我们下期再见！拜拜！

我看你简历上做了不少 a 证的项目，在实际应用中， a 证的产生幻觉是不可避免的。如果你负责的项目中 a 证的输出了错误的事实或逻辑，你会采取什么样的策略来处理处理 a 证的幻觉问题？我通常会遵循一个核心闭环， 精准检测、深度定位，实施修正系统及防御。第一步，检测发现问题。首先我们要有感知能力。 我会从三个维度建立监控机制，外部比对，将输出结果与权威知识库或搜索引擎进行实时核查。逻辑检验，检查输出内容的前后一致性。或者利用自我反思机制，让模型通过另一套提示词对当前输出进行逻辑质检。 自信度打分为模型输出，引入可信度预值地域标准的内容直接拦截。第二步，定位，找准病菌发现幻觉后，需要判断它出在哪一环。解锁环节是不是 i v g 解锁回来的参考文档本身就是错的， 或者是没解锁到相关内容。推理环节，模型是否在思维链 call 七中产生了逻辑跳跃？生成环节是否因为产量参数设置过高导致模型为了文采牺牲了事实？ 第三步，修正及时纠篇。确定问题后，我会采取以下手段进行修正，重解锁，优化解锁策略，获取更高质量的上下文。 约束解码，在生成阶段加入应约束，强制要求模型从给定的 contacts 中提取信息。 人工反馈，对于高频出现的业务幻觉，通过人工标注的正确样本进行微调或反馈训练。第四步，防御系统加固。这是最重要的治本环节， 我会从架构级进行防御架构增强，完善 i a g 流程，确保模型言之有序。验证模块 在 agent 架构中增加独立的输出验证层，类似守门员拒绝机制，训练模型学会认怂，当不确定或信息不足时，主动触发拒绝回答机制。数据治理，定期对训练数据和提示词模板进行去照事实标注，并注入对抗样本， 提升模型的抗干扰能力。总的来说，处理幻觉不是单点突破，而是要构建一套从底层数据中间推理到最后输出较量的全链路可信体系。 最后，我也整理了一份某个大厂要求 ai 产品必学的一个文档，里面就包含了整个 ai 产品的研发流程，大模型的未来发展方向，以及 ai 产品当前存在的一些问题，想要的我可以分享给你。