AIAgent任务拆解步骤

刚刚刷到了一个博主，他的图片都非常的有创意，给大家看一下他把各种食材去变成一些植物， 那我就想做出一样的视频，那我怎么做？其实只需要掌握一个创造技能的技能，就可以把任何的图片风格都给他还原出来。 ok， 第一步要做的就是把你所需要模仿的这些图片都放到一个文件夹里面去， 这是整个大任务的背景，后面我们就让他执行四个步骤，我们现在的 ai 已经在按照我们的要求，把每一张图片的提示词都印像出来， 点一下这个图片，就能看到他是如何去逆向的，把一个真实的食材通过重新的排列变成另一种自然物的轮廓，用单一的视觉隐喻制造惊喜感。哇，这一句话就把这个图片为什么能有一百万赞 给总结出来，整个其实分为几个部分，一个是说他的目标，他的创意的逻辑在哪里， 以及他的统一的视觉的主干。多张套图必须要统一的看宽幅比例、光线的逻辑，还有背景，以及他们下面分别举了几个例子，或者几种创意的形式，告诉大家可以怎么去做。 ok， 现在我们其实要去测一下这个技能，我们去创建一个技能， 把它落地出来，它只要三个部分，一个是名字，一个技能描述，还有一个技能的提示词。 ok， 这个时候我们这个就创建好了，叫超现实创意组图， 我们在这里去测一下这个技能，选刚刚创建好的技能，春天的风景，看它能做什么样的改变，这样它其实这次已经不局限于我刚刚提供的这几个素材了，它已经把一些新的食材带进了，这个是 ai 的 一个泛化， 那你给他一个 a， 他 就自然能联想到 b、 c、 d， 这个其实就是在这个技能的指导下， ai 拥有了一些创意的能力，大家可以看一下这个和原来的图片是不是异曲同工。我们来看第二张是对绿叶，他是一个枝条变成晶莹剔透的那种感觉。 第三张是抹茶，第四张他是在用珍珠去下雨，所以说其实他把春天的几种元素都融入进来了。这四张图我觉得都非常美观，而且色系很稳。 本来如果他一次效果不太行，我可以在这里进行修改，但是我觉得这次已经非常 ok 了，那我就可以直接上架就用了，现在就可以把它发布出去，给他再来一个封面图就可以了。如果你想要这样的一些技能，就可以在这里直接就能拿到跟我一样的效果。

跟 clock code 学顶级 harness， 大家好，我是老崔，今天我们继续扒开 clock code， 来看一下它是怎么做上下文管理。像 clock code 的 这种编程智能题，其实它本身上就是一个跟大模型多轮交互的循环， 但只要涉及到多轮对话，就有一个非常麻烦的问题，因为每一轮对话产生的中间结果都会进入下一轮的上下文，这就会导致我们的上下文不断的膨胀。 而半维形的上下文窗口，我们知道它是有一个固定的限值，比如说二十万 token 或者一百万 token， 所以 它是没法应对上下文这种无限膨胀的问题。那这个问题的解法就是我们今天要讨论的主题，上下文管理。 上下文管理它直接影响到 a 诊做任务的效果，尤其是做长任务效果。 alphabet 内部就做个测试， 一个好的上下文管理，它能使智能体的性能提升百分之二十九，而 pop 的 消耗能够减少百分之八十四。那怎么做上下文管理呢？它通过动态的调整模型能够看到的信息，从而让模型能够更好的完成指定的任务。 大模型在一轮对话中能够看到的信息可以分为这三个部分，第一部分是系统提示词，这个在之前的分享里边，老杰跟大家系统的拆解过，感兴趣的可以翻一下我前面的视频。 第二部分是多轮消息，也就是每一轮和大模型的交互过程中，我用户发的信息，模型的回复产生的中间结果，全部编成了一个多轮消息的簇组， 它在源码里边就是以 message 的 序组来存储的，那每和大模型完成一轮对话，这个序组就会多加一些元素。第三类是工具信息，是告诉大模型我有哪些工具可以供你使用。 在大模型看到的这三种类型的消息中，我们主要管理的是中间这一种多轮消息 bug 的，是怎么管理的呢？ 总结下来就是这五级上下纹压缩，你上下纹在不断的膨胀，那我就通过各种各样的压缩来缩短你的上下纹长度，同时我又保证重要的信息能够保留下来，这就是上下纹管理的关键所在。 他获得的这五级压缩，从左到右也是他执行的顺序，依次会压缩的越来越重，保留的信息也会越来越少。他分别是上下纹的裁剪操作， 然后第二步有一个尽量的压缩，第三步有一个中等压缩，第四步重度压缩，最后还有一个补救的压缩。下面我们一个一个来看一下。第一集是裁剪，这个最简单粗暴，他就是直接把一段旧历史给裁掉，比如我现在消息列表里边有六条消息， 通过裁剪之后，我把三条没用的消息直接裁掉，最后就剩下三条，这个非常好理解。第二步是一个轻量的压缩，他针对的对象只有一种，就是工具调用的结果。 举个例子，我用查看工具查看了本地一段非常长的时间代码，比如几千行甚至上万行，几千上万行的代码就会进入消失列表。 短期看它很重要，因为模型要根据代码来定位问题，解决问题，但是任务往后面推进之后，这一大段代码就已经没什么价值了，而且它占用的 token 又非常多，很容易污染上下文，所以克拉扣的会优先处理这类臃肿的工具输出。 在具体的实现层面，克拉扣的分了两类，第一类是对于冷绘画，就是我六十分钟已经没有任何操作了，那我在这一步只保留最新的五条工具执行的结果， 其他的全部替换成一段默认的自辅传。那对于热绘化，就是我一直不停地在跟 colocod 进行交互，那这个时候 colocod 不 会直接改本地的 message 这个序组，而是在请求模型的时候，告诉他模型哪些工具的结果是需要剔除的，在模型层面做一个删除。 这样分冷热两种情况，其实是为了在热绘化的时候做一个缓存的优化，因为我们知道大模型会有一定的命中缓存的几率， 那我请求的消息数值不变的话，那就更容易命中缓存，从而节省计算成本。接下来第三种压缩类型叫折叠式图。折叠式图这个名称可能比较抽象，比较难理解一点，但其实我举个例子说明一下就很清楚了。比如 我用户发了一个提示词，修一个 bug， 那 在这个 bug 修完之后，其实我们就可以把中间大量的消息折叠起来。比如这里折叠后的信息就是已经读取了文件定位到了问题，并且通过了测试，已经完成修改了，并且给出了一个关键结论。 这里要注意还有一个关键点，他叫折叠仕途，仕途的意思就是他没有直接去改那个消息列表，而是在调用模型的时候，只给模型看这一条信息，但是我完整的消息还是存在我原来的那份消息列表里面，这样既减小了模型的输入， 也保留了完整的上下文。接下来第四步重度压缩。这一步就要直接改变我的消息数值了，我们还是举例来说明，比如说在压缩之前，我有很多轮的历史消息，有大量的工具调用的结果 token 已经逼进上下文窗口的预值了， 那这个时候就会执行一次重度压缩。压缩之后他会生成一条边界信息，以及一到数条的对前面的历史消息进行了总结信息，同时他也会原样保留最近几轮的信息， 最近的上下文细节还在，这样任务就还能继续往下跑。最后是一次补救压缩，如果通过前面四步的处理，在最后调用大模型的时候，还是出现了上下文过长的错误，这个时候克拉扣不会马上报错，而是会再进行一次压缩，然后重试之后 再决定是否把错误报出来。这次补救压缩的逻辑和上一步重度压缩的逻辑是一模一样的，只是他们在运行的时机上有所差别， 可以理解为前面的重度压缩是常规操作，而最后的补救压缩是用于失败之后的重试。好了，以上就是克拉蔻的上下文管理的全部内容。

ai agent 领域出了一个现象级的新项目，叫 hermes agent。 一 开始很多人不以为然，觉得这不就是又一个能调工具的聊天壳子吗？没什么新鲜的，但很快，几乎所有人都被打脸了。因为 hermes agent 压根就不是一个聊天壳子，它更像是一个自带净化能力、拥有超强记忆，而且还能全天候稳定运行的 ai 操作系统。 今天我们就来拆解一下，这个项目到底凭什么在短短两个月内就火遍了全网，甚至被认为有能力挑战之前的霸主 open call。 首先得搞明白这波热度的本质是什么。过去大家评判一个 agent， 主要看他聪明不聪明，能不能听懂人话、调工具。但现在风向变了，开发者们发现，一个 agent 就 算再聪明，如果跑几个小时就崩溃，或者换个平台就没法用，那他永远只能是个玩具。 大家开始集体下沉，关注更底层的工程问题。 hermes agent 正式抓住了这个转变。他在 get up 上的 star 数从一万飙升到快三万，靠的不是模型本身，而是他提供了一套完整的运行时设计，把工具都打包成系统。统一系统 就是他把命令行、消息网关，像 chrome 那 样的定时任务，还有安全沙箱，所有这些都打包成了一个统一的系统。换句话说， hermes 不 仅仅能陪你聊天，它更像一个可以七乘二十四小时在后台稳定运行的数字员工。 这解决的是 ai 从 demo 走向实际生产的最后一公里。所以说，到了二零二四年，我们可能已经不太关心 ai 聊得好不好，我们更关心的是它能不能像一个操作系统一样稳定地挂机干活。当然，如果一个 agent 只是稳定运行，那它本质上还是个高级脚本。 hermes 真正的杀手锏在于它能像人一样复盘，然后自我净化。 这就不得不提它内置的一套叫 k e p a 的 自我净化闭环系统。传统的 agent 要想学新技能，得靠开发者手动给他写 插件。但 hermes 不 一样，当他遇到一个没见过的复杂任务，哪怕失败了，他也不会简单地结束对话。他会启动一个反思，体验再深层的流程，一旦最后成功解决了问题，他会自动把这次的操作路径总结成一个结构化的技能文档，存进自己的技能库里。下次再遇到类似的问题， 它就不用从零开始推理了，直接加载这个经验包就行。这是一个从授人以鱼到授人以渔的根本转变。开发者不再需要像保姆一样提前预测 agent 会遇到什么坑，然后给他准备好所有工具， agent 自己就成了自己的架构师。这种能力生产的迁移，意味着企业如果想构建自己的私有化 agent， 成本会大大降低。 因为这个 agent 在 被使用的过程中，它的技能库是会自动扩容的。可以说， hermes 不 只是在使用工具，它是在通过卷自己来发明新工具。 而这种自我进化的能力，也直接导致了他和他的主要竞争对手 open club 在 底层逻辑上走向了完全不同的道路。这就引出了 agent 的 设计的另一个核心痛点，健忘和越权。记不住 n 胡乱操作等于可怕 一个 agent 如果记不住之前的对话，或者拿到权限后胡乱操作，那是非常可怕的。针对这点， henry 做了两手准备。首先是他的记忆系统，被很多人称为搜索引擎式大脑， 它用 sqlite 的 全网解锁功能，可以秒级调用几周前的对话记录，解决了 ai 短暂记忆的问题。而且它的记忆接口还是可插拔的，你可以接入像 hongq、 密姆林这些主流的记忆框架，非常灵活。 其次是安全，它设计了一套五层纵深防御体系，任何高风险的操作，比如删除文件、执行终端命令默认，都需要人工审批才能执行，这就给 a 政的行为上了一道锁。 这种设计其实就反映了专业级 a 证和玩具级 a 证的分水岭。对于企业用户来说，安全和持久记忆是绝对的刚需。你看 open klo 的 路线，更像是搞一个庞大的插件大杂烩，生态什么都有，但质量和安全参差不齐。而 hermes 选择了另一条路，它追求极致的架构、透明度和安全可控性。 也正因为如此，很多在金融、运维这些对稳定性要求极高的领域的团队，已经开始把系统从 open klo 迁移到 hermes。 毕竟一个好的 agent 应该像一个有记性而且守规矩的管家，而不是一个随时可能把房子烧掉的天才。好了，聊到这，我们来总结一下今天关于 hermes agent 的 几个核心要点。首先是定义上的眼镜，标志着 ai agent 正在进入操作系统阶段， 它的核心竞争力不再是单一的模型能力，而是通过命令行、消息网关和定时任务，构建了一套完整的工程化运行环境。 第二是它的核心竞争力，也就是 k e p a 系统，它具备自动生成技能的能力，通过反思生成存储的闭环， a 诊能把成功经验沉淀下来，实现能力的自我迭代，大大降低了人工维护成本。第三是记忆与安全，它引入了基于权威权威锁的记忆系统和五层安全防御， 解决了 a 诊健忘和跃权两大痛点，让它成为目前最适合企业自托管的智能体方案之一。最后一点是它的数据战略价值，它能和强化学习框架集成自动记录任务执行的完整轨迹， 这些包含了真实业务场景的数据是训练下一代更强大的工具。调用模型的宝贵原材料对于想自研模型的团队来说，这具有重要的战略意义。

ai 只是工具，搞钱才是最终目的，别再拿国内大模型当普通的聊天机器用了。今天直接揭秘高级 agent 的 核心底牌， skill！ 什么是 skill？ 它本质上就是一个 markdown 格式的文本文件，但它不是普通的提示词，它必须遵循严格的底层结构，分为配置区和指令区。重点来了，配置区的名称必须是全英文，为什么？因为这个文件必须放在你本地 agent 的 专属 skills 目录下。如果你用中文命名， 一旦路径包含中文，大模型在自动调用时极容易爆错崩溃。记不住路径逻辑的赶紧去补补基础。另外一个必须写好的叫 description 描述，它是告诉 ai 什么时候该触发这个技能。为什么要这么折腾？为了省钱和精准， 把几万字的标准 sop 全塞给大模型，不仅极其消耗 token， 还容易让它产生幻觉。 skill 能做到按需加载，没活的时候不占内存，触发任务了瞬间变身专家，怎么让大模型乖乖听话干活？ 国内开源社区早就有写好的 skill 生成器模板，你把它下载解压，直接丢进你本地 a 证的框架的指定目录里，启动你的终端或界面，直接输入指令，呼出这个生成器。专家，接下来就是大白话沟通，我想建一个帮我管理短视频矩阵的技能， 你需求描述的越细，它给你生成的 skill 文件就越精准。哪怕你完全不懂代码，也能靠它构建出逻辑极其严密、可扩展的自动化工具。这玩意用起来简直降维打击。 那这东西到底能干嘛？盘三个实战场景，第一个解决繁琐的脏活，比如你要拆解同行的爆款视频， 传统做法是自己听、自己抄，自己总结。现在你做一个爆款拆解 skill， 把工作流锁死。第一步，调动插件，把视频转文字。第二步，洗掉口语废话。第三步，提取黄金前三秒钩子。第四步，按固定格式存入你电脑的地盘， 以后你只要把视频链接往里一扔，它自己调兵遣将走完流程，爽感拉满。第二个场景项目统计，我手里目前有多个 ai 变现项目， 绝对不只是盯着某一两个赛道，为了全自动承接这些流量，我给每个赛道都定制了专属的生产线。 skill 不 用在各种国内大模型网页之间切来切去，一套底层逻辑全部跑通。 第三个，高级玩法，同步协助。在内容生产时，我们同时挂载三个 skill， 一 号负责爬取全网热搜找选择题，二号按我固定的爆款逻辑写脚本，三号负责审核违禁词。你只需要下达一个出师口令， agent 呢？就会像老板一样，自动按顺序指挥这三个 skill 干活。 这种模块化拆分，能极大降低国内大模型处理涨任务时的逻辑偏移。最后一句话讲透 skill 和最近很火的 m c p 的 区别。 skill 是 大脑 sop， 它是提示词，是指令，是工作流程。 m c p 是 手和脚，它是外部工具，是接口。 skill 负责调用 m c p 去执行动作，但 m c p 永远只能在 skill 划好的规矩里干活，懂了吗？干货都在这儿，马上行动起来，别再做技能内耗下课！

answer pick 今天这篇工程文章不是在讲一个新功能，它更像是在回答一个问题， ai agent 到底怎么才能长期稳定地跑下去？真正难的可能不是让 ai 动手写代码， 而是让它在任务变长、环境变多、系统会出故障的情况下，依然能接着干。 anthropic 这篇 managed agents 讲的就是这件事。这篇文章最重要的出发点是， agent 的 很多设计其实都带着模型，现在还做不到什么的假设。可问题是，模型在变强，这些假设也会过时。 anthropic 举了一个很典型的例子，之前它们为了处理上下文快满时的提前收尾，专门在 harness 里做了 reset， 但同样的逻辑到了更强的模型上，反而变成了多余负担。 所以他们想做的不是某一个最优 harness， 而是一套没那么容易过时的 agent 基础设施。他们最早的方案其实很直觉，把 session、 harness、 sandbox 全塞进一个容器里，这样做简单，文件操作也直接，没有那么多边界要设计。但问题也很快出现了， 容器一挂，状态就没了，容器一卡，工程师就得手动抢救，想排查问题，还经常得钻进带着用户数据的环境里看。说白了，这套设计像一台不能坏也不好修的老机器。后来 osmropic 把这件事拆开了，第一层是 session， 负责记住发生过什么。第二层是 harness， 负责调用 cloud 调度工具。 第三层是 sandbox 和各种 tools， 负责真正去执行动作。这一步看起来只是拆模块，但本质上是在重化 agent 系统的边界， 边界一旦划清楚，恢复能力和安全性就都上来了。比如 container 挂了，不需要抢救原地复活， cloud 可以 把它当成一次工具报错，再决定要不要重试，如果重试，就重新起一个新的执行环境。再比如 hanse 挂了也不用怕，因为真正的历史不在 hanse 里，而是在 session log 里。重启以后可以直接接着读。 安全上也一样。以前如果 cloud 生成的代码和凭证在同一个地方一次 prompt injection， 就 可能把 token 直接读出来。 anthropomorphic 的 解法是更结构性的，不是把权限再缩一点，而是尽量让 token 根本不出现在 sandbox 里。这套架构不是只有理论好看，性能上也有明显收益。 文章里给了两个很关键的数据， p 五十的首， token 延迟下降了大约百分之六十， p 九十五下降超过百分之九十。原因其实很朴素， 不是每个任务一开始都需要容器，那就别让所有 session 先把容器成本付一遍，让脑子先推理手，在需要的时候再创建，速度自然就上来了。我觉得这篇文章最值得反复看的地方其实是这一句， session 不是 cloud 的 context window， 因为长任务一定会撞上下文上线，而常见做法往往都是删一点，压一点，总结一点，但这些动作本质上都在做不可逆选择。 entropy 的 思路是把历史存储放到 prompt 外面，做成可回看、可切片、可重读的 session log。 至于哪些内容要重新喂给 cloud， 那 是 harness 的 职责。换句话说，存得住和喂得好，本来就不该混成一件事。 再往上看，这篇文章讲的其实不是一个 agent 怎么跑，而是一套 agent 系统怎么扩。 entropic 说的是 many brains many hands， 一个 brain 可以 接很多 hand， 这些 hand 也不一定是容器，还可以是 m c p， 手机甚至别的执行环境。这意味着未来的 agent 不 一定只有一个 shell， 一个工作区，一个执行点。 如果你最近也在关注 agent， 这里最有启发的一点就是，真正的分水岭可能不是 prompt 写的更花，而是系统边界画的更对。所以回头看 answerkey 这篇文章，真正想讲的不是他们又发布了一个更强的 agent 服务，而是如果你想让 agent 长期运行出错，可恢复还能接不同环境，那就必须把状态调度和执行环境拆开看， 这也是我觉得它最值得学的地方。如果这条内容对你有帮助，记得点赞收藏关注，我们下期见！

今天要分享的内容来自 antropic 黑客马拉松获胜者公开出来的一整套 cloud code 配置集合，对应的 github 仓库就是 everything cloud code， 也就是 e c c。 为了讲得更清楚，这次我会分成上下两集。第一集先把总图搭起来，主要看项目概述、核心原则、 skills 系统和 agents 系统。第二集再往下展开， hux 系统、 rules 治理层安装系统、 token 优化、持续学习、并行化和实践指南。如果你已经用过 cloud code code x cursor 这类工具，里面的几个痛点应该都很熟。 同样的提示词，反复写上下文，跑一阵就开始发散，质量检查全靠自己记着补，不同平台还得重复配一遍任务一旦拆给子代理， 新的问题又来了，他知道要搜什么词，却不一定知道这次搜索服务的到底是哪件事。 e c c。 就是 顺着这些摩擦点往下做的。 他把提示词、流程规则、自动检查和跨平台安装拆成了几个独立层次，目的很直接，让常用方法沉淀下来，让分工更清楚，让检查动作尽量自动发生。先看那张分层图，会比较容易进入状态。最上面是 skills 和 commands， 负责把常用工作流组织起来。往下一层是 agents， 负责接手具体任务。旁边两条支撑线是 hox 和 rules， 一个管出发时机，一个管质量边界。最下面的 manifests 则负责安装和分发， 保证同一套能力能落到不同平台。这样一拆，工作流，执行者、自动化、规范和部署就各自归位了，原来缠在一起的问题也更容易。顺着层次往下看。 e c c。 用五条原则把整套方法压缩了下来， agent 优先测试，驱动安全优先不可变性，先规划后执行。读这一页时，别把它看成价值观海报， 最好把它当成工作现场的五条默认操作新功能，先让合适的 agent 介入，避免主会话什么都抗。改动之前先补测试，省得回头追。回归安全检查放在默认流程里，不留给临时想起 状态变化尽量走，显示转换，方便追踪复杂改动，先出计划，再开始动手。这五条加在一起，约束的其实是想到哪做到哪的习惯。 skill 说白了就是一个带边界的工作，刘邦什么时候激活核心规则，写什么步骤、按什么顺序走，里面都会交代清楚。他服务的是主会话，所以执行方式是同步的， 拿到的是同一份上下文，它特别适合沉淀高频动作，比如 t、 d、 d 验证循环、安全审查、数据库迁移、语言专项规范，都可以写成 skill。 这样主绘画不是每次靠临场发挥，而是沿着一套已经试过很多次的流程往前走。 e、 c、 c 给 skill 规定了比较清楚的格式， yammo from matter 负责标识和触发信息，正文部分再把激活条件、核心规则、步骤和例子铺开。 这样的结构有个直接收益经验，能以比较稳定的方式赋用，不会每次都散在不同对话里。再往前走一步就是 code map， 项目里会把关键目录、主要入口、测试位置、配置文件这些信息直接写进 skill 模型。接到任务后， 先拿到的是一张代码地图，省去了大段试探式搜索，原笔记给出的判断也很实在，探索性投肯消耗会明显下降，定位速度也会更快。 agent 这一层就是明确分工后的执行者，他有自己的职责描述工具、白名单和模型偏好， 通常还会在检测到某类任务时主动介入。规划架构、代码审查、安全扫描、构建修复、文档更新。这些角色在 d、 c、 c 里都被拆开了，关键在于权限控制。比如 planner 只给 read grab， 这样他就能专心做分析和计划，不会顺手改文件。工具极越克制，责任边界越清楚，委托出去的动作就越稳定。观看定义很容易把这两层看成两个近义词， 实际用起来，它们处理的是两类问题， skill 负责方法，告诉主绘画这件事按什么流程推进。 agent 负责分工，把某一段任务交给更适合的角色去完成。所以常见的组合会是这样，先让 planner 把阶段和风险拆出来， 再由主会话带着某个 skill 往下执行。代码改完以后， reviewer 和 security reviewer 再依次接上，前一层把路走稳，后一层把活分开。 e c c 没有把所有任务都塞给同一个强模型，而是给不同工作配了不同档位。 搜索文档整理简单改动可以交给 sonit。 架构安全复杂 bug 再上 opus。 工具访问也跟着角色走，谁需要写，谁需要跑， buff 都会单独控制。这么分下来，至少有两个直接好处， 第一，成本更好管，简单事情不用总开最高配。第二，任务更容易收口，执行者知道自己该做什么，也知道自己不该做什么。 这一部分最后落在两件事上，第一件是顺序阶段编排，研究规划，实现审查验证，一段一段接起来，中间结果尽量落到文件里，而不是只留在聊天上下文里，这样每个阶段都有输入和输出， 回看时也能知道问题卡在哪一环。第二件是子代理的上下文问题，笔记里特别强调，编排器发给子代理的不能只有查询词， 还要把这次任务的目标一并带过去。只有把要找什么和为什么要找放在一起，子弹里返回的结果才更接近真正需要的答案。把这两件事放在一起看。这一集搭出来的 其实就是一套工作现场的骨架，后面的 hooks rules 记忆和并行策略都会继续往这副骨架上加稳定性。

你给他一个任务，他自己拆开，派出一群 ai 分 头去做，最后交回你手里。这就是 dear flow， 十天 github 热榜登顶四万七千颗 star。 国内工程师团队开源。传统 ai 工具是串行的任务，一个跑完，下一个才开始， 它是并行的，一百个 ai 同时跑和跑一个，耗时几乎一样。这不是夸大，这是架构决定的。主 agent 接到你的任务，不是一个人干，是拆开，派出去，主 agent 各自独立上下文，分头执行。最后主 agent 汇总，你只管提需求，收结果。它能跑代码，写文件，执行办事命令， 但全在 dk 容器里，删了也没事，零污染，完全可审计。它记得你偏后技术站风格，跨绘画持久化， 越用越懂你。但记忆是本地的，你说删就删。传统框架，任务越多越慢，这是常识。他打破了这个常识，一个任务十秒，一百个任务还是十秒，因为他根本不排队，主流模型全兼容，换模型就改一行配置，不用动代码，还有个彩蛋，可以直接在编程助手的终端里 给他布置任务。 ai 指挥， ai 套娃写作，真的有人在用。说句实话，他不替你做决策，提烂需求给他，他会很认真的帮你做出烂结果。 但有意思的地方在这儿，大多数人卡住，不是执行力不够，是不知道怎么拆任务，而这恰好是它的强项。如果你也在用 ai 提效，这个工具值得收藏，而且它不会失忆。

你有没有觉得小龙虾用着也没那么聪明？你昨天刚教会他一个技能，今天教他干活，他又跟没学过一样。大概率是因为你们的所有对话一直都挤在同一个聊天窗口里，你一会让他写文档，一会让他查新闻，一会又聊理台。小龙虾引以为傲的记忆系统还没有强大到把你们所有的对话都分门别类的记住， 并且随时的精准调取。为什么会这样呢？通常就是三个问题，第一，上下文污染，前面聊的内容很容易被带入后面的任务里。第二，记忆会变乱，信息一多，真正关键的内容反而不容易被准确的调取 出来。第三， skill 调用不稳定，装的 skill 越多，话题越杂，他越难判断现在该调取哪一个。你觉得龙虾变笨了，其实不是他的问题，而是你养的问题。 更好的方式是养多只各司其职的龙虾。养多只龙虾不是要安装很多次 open claw， 比如养虾大神傅盛说自己养了八只龙虾，不是在八台电脑上装了八次，而是在一个龙虾里分身八只独立的 agent， 这才是更专业的养法。我自己养了几只龙虾，这个是上期讲的拆解短视频的，自动帮我扒取文案，提评论、拆机制和仿写的。 这个是调用大神 skill 帮我梳理商业思路的，这个是主 agent 做统计的，每个 agent 都是独立的，你跟他聊得越深入，他的上下文清晰，记忆也就越准确，这样才是贾维斯般的助手。 龙虾分身的实现方式有几种，我测试过，最成熟稳定、最容易上手的方式就是单 agent， 单 boat 模式，也就是每个 agent 都有独立的对话窗口，有独立的工作区、配置文件，甚至可以配置独立的模型。就像富盛那八只龙虾，每一只其实都是一个独立的 boat。 如果你也想分身出多只龙虾， 是不用手动折腾一堆配置。这里我不讲技术，我梳理了一套简单的方法，就两步。以飞书为例，第一步，你只需要再申请一个新的机器人。第二步，把申请的 app id 和 app secret 以及对这个 agent 的 功能描述 填进这个提示词模板里，它就能帮你完成配置和生成必要的文档。最后再运行一下配对命令，一只新的龙虾就创建好了。如果你想再进阶一些，你可以像我一样，专门配置一个创建 agent 的 agent， 让他去学习一些专业的方法和技能。然后每次想创建新的 agent， 你 只需要把需求跟他说清楚，他就能够自动创建出来更专业的 agent。 甚至在这个 agent 里面，我还可以继续拆分 sub agent， 这样就能把一个技能越做越深。而如果没有拆出独立的 agent， 这件事其实是很难做到的。这就是让龙虾分身的方法，赶紧试试吧。如果你想看多 agent 的 团队怎么协同做事，请留言告诉我，想看的人多，我就专门做一期。

多智能体最容易翻车的地方不是模型不够强，而是协助链路是乱的，你让多个 ai 同时开工，看起来很热闹，最后常常会互相打架，消息乱飞，结果没有人兜底。 opencloud 有 一个帮顶的模式，我觉得它最有价值的一点就是它不是让多个智能体自由地发挥，而是先定角色，再定路由，再定回传规则。 今天这条视频我不讲飞书怎么揭露，我就专门讲清楚一件事情， opencloud 是 怎么把多智能体协助从看起来很高级变成真的能交互结果。那目前这个界面是，我是默认大家都是已经安装好 opencloud 的， 那如果说是不知道怎么接这个飞书的话，其实官方的这个文档里面就是这个地方，我们其实可以去看 opencloud， 它是怎么知道我们去做这个 飞书的这个记录，那点击这个圈漏的标签，有一个飞书，然后他这边其实是讲的非常非常详细，基本上是没有门槛的。 如果说啊对英文这块有阅读障碍，其实可以我们可以把这个链接就是发给那个，比如说像下面 gpt， 让他去去帮我们分析解释一下这个文章的内容， 然后我们借助这个啊解读之后的结果，一步步的去做非书记录。 那这个这个文件是我自己是整理出来的一个 opencloud， 在 opencloud 上通过飞书 进行多智能体协助的一个搭建步骤，那正常我们加这个智能体的话，那 一般它是有通通过这种命令去安装，那其实我更推荐大家通过这个 opencloud 的 这个配置文件去添加， 那怎么去添加这个 opencloud 的？ 后面我们会讲到，那现在这边先接下去的步骤，就是说我们要通过这个飞速的这个群群的这种轱辘的 id 去怎么去建立一个，建立一个这样的一个飞速群，然后通过飞速群 我们把这个自己的需求发送给这个 opencloud 的 这个呃智能体，让他们去帮我们去拆分需求，最后得到一个我们想要的一个输出结果， 那这边都是一些呃我们的一个搭建步骤，那这边我就不去说了。 然后主要就是讲的一个，呃我们这个配置文件是怎么配置的？像像这个三个就是我们需要在配置文件里面去添加的一个智能体的配置。 正常来说我们这个配置其实就是啊配置文件其实就是在这个我们的用户目录下面的 open cloud 的 下面这个啊这个文件其实这个大家应该都懂。 然后接下去就是这个邦鼎，邦鼎这个没什么好说，就是一个啊通过这个 飞速群，然后对接这个 channel， 然后那个啊通过 app 的 这个呃系统，这个系系统架构师这样的一个呃方式去把我们的需求传递给他。那正常我们的开发 一般会涉及到很多角色，像产品经理，然后项目主管或者说前后端工程师。那我们这边这个文档我们主要就是把它浓缩成三个这样的一个 a 种角色，一个是前后端前端工程师，一个后端工程师，还有一个是系统架构师。 我们用户对通过跟系统架构师去对话，然后让系统架构师去做这个 啊需求的拆分跟这个嗯任务的分发，最后把每一个角色每一个 a 卷的这个呃工作的这个进度上报到，这个通过这个信用架构师上报到用户，上报给用户。 那这块都是我们一些配置游戏重要比较重要的一点就是像呃这一块配置，我大家一呃不是这块，是这里这块配置一定要这个这个 profile 一定要选 for 的， 不然的话后面就是说这个 呃系统价格是没办法是把这个他分发给其他智能体的这个任务的这个进度上报到啊飞速群，所以这块配置是比较重要的。而其他的配置像像这个 tos 这块也是也是必须需要配置的。 然后智能体如果配置完之后，然后我们就需要去配置这个智能体的这个 agent 的 文件跟这个哨的文件，那核心的配置文件就是哨的文件。 那因为我们如果说加了这个智能体之后，其实我们在在每个智能体的这个工作目录下面其实都有关于他们的这个 啊配置文件。那比如说我们现在以我们目前是说已经有这三个三个 a 卷的，那我们以这个啊 c、 c 的 r 的 这个 a 卷的为例，那它其实正常它都会有这么几个文件。那 a 卷的这个目录的话啊，这个文件它主要的作用就是说它想解决的就是说这个多个 a 卷怎么配合，流程怎么跑，规矩怎么定。但哨的 m、 d 这个文件 那就是比较可能说是最重要的，它就相当于是一个每个每个 a 卷的一个使用说明书。 那么这下面还有一个呃这个文件其实是标用来标记每个 agent 的 身份角色，这一块其实大家也蛮蛮可以去去写一下也没问题。 那我们以这个呃系统架构式的这个哨的目的文件为例，它其实最重要的就是说它去怎么去，比如说这边的这边的那个 啊提示时要怎么去写，比如说他的核心职责是什么东西，收到这个需求之后怎么去派发，怎么去接收，以及需要注意的一些呃事项，或者说一些那些工具使用的一些规范。 那这块东西如果我们按照这边的文档配置完之后呢？那其实啊接下去像这种后端工程师的这个上的也要， 然后前端的都配置完。但但当然我们比如说像这个后端工程师这个他的啊 data 文件里面我们就可以说呃怎么去配配置他的提示时让他使用什么样的一个技术站， 然后以及它我们需要让它输出一个 api 文档，然后到时候前端这个 a 卷的，然后借助这个 api 文档来做这个前端的开发。 那如果这一块都配置完之后，我们就可以通过这个呃 opencloud 的 这个重启它的网管服务，或者说如果说大家有注册到这个呃系统服务，那就是通过这个是啊斯顿 control 来里斯拉的这个命令去把这个 opencloud 重启，那就生效了。 当这个 opencloud 的 这个多智能体配置完之后，那么我们现在就可以在飞速群里面 啊 at 这个系统架构师，然后把我们的需求发给他，然后他就能够去裁缝我们的需求，最后生成相应的这个我们所需要的文档， 那这块就是目前目前我这个配置的三个 agent， 然后在这个系统设计群，比如说那我，我是先艾特他， 我先艾特这个这个飞书的啊这个机器人，然后我说我要做一个系统，然后我简单一点就是说我要有一个用户系统，我要注册登录个人信息管理， 那好，那他就会去帮我去拆分这些各一每一个的这个任务需求，最后一直一直他会帮我这种怎么去规划，然后会深深相印的这种功能说明文档后端架构设计，前端架构设计， 然后他就会把这些东西通过呃任务的派发给，派发到那个先派派发给这个后端工程师，后端工程师 完成了这个代码开发之后，然后生成一个这个文档，然后然后那通过这个呃系统架构师把 已经生成的文档通过这个文件发送的形式，我们可以在这边可以看得到啊，收到他生成的文件， 然后如果说前后端前段已经开发完之后，那那个系统架构师就会 啊，接下去就会把这个任务交给这个前端工程师，那么他也会啊收到这个需求之后，然后再加上后端提供的这个 这个文档，那就会去，嗯去开发他自己相应的功能，最后他会把这个功能的每一个阶段的产出产物都会在这边一个个罗列出来。那开发完之后，那么我们就可以在在这些，在这些木他这上面的这个， 呃每一个，每一个这个目录下面去找到我们想要的这个输出文档，那么就相当于我们的前后端都已经开发完成了， 那之后大家如果说呃需要去拆分更多的系统角色，那你就多建几个 a 卷的，然后这把这个每个 a 卷的他所需要的，他所 需要负责的这一个角色任务要给他定义清楚。然后呃必须有一个 a 准的来作为一个协调跟中转的这样的一个角色， 那么你就这个多 agent 的 就能够把能够很好的去运转起来了。那其实除了这个 open cloud 之外，其实还有一个就是 codex 其实也能够做这个多 agent 的 协助，这个下一期我们可以 举一个例子来演示这个 codex 怎么去做多 agent 的 协助。好，谢谢大家。

大家好，今天来聊 ai agent 设计模式系列第五篇， multi agent。 当单个 agent 不 够用时怎么办？我们从 microsoft 论文 and rapid 工程实践到 quad code 源码三个层面来拆，那什么叫不够用？ 单个 agent 的 哇哦处撞向三个瓶颈，第一，上下文窗口就那么大，几十万行的代码库，一个 agent 根本塞不进去。第二，串行太慢， a 做完才能作弊，明明互不相干的活也得排队。第三，一个 agent 什么都干，搜索、写代码，审查全扛，干着干着就跑偏了， 怎么解？二零二三年 microsoft 的 autogen 论文给了一个系统化的思路，把复杂任务拆给多个可对话的 agent， 让他们通过多轮对话完成写作。论文定义了两类角色， assistant agent 负责生成代码和方案， user proxy agent 负责执行和确认。关键设计是 agent 之间靠对话传递任务和结果，不共享内存，但可以灵活组合成两人对话，或多人群聊。理论有了，工程上怎么落？ andropics 在 building effective agents 里给出了一个很清晰的模式， orchestrator workers。 屏幕上这张图，左边是 ok street， 右边是三个 worker， ok street 接收目标拆成此任务派给 worker， worker 各自跑，结果回留给 ok street。 汇总说了这么多，代码里到底长什么样？来看 cloud code 的 源码 屏幕左边是 ok street 的 query loop， 还是那个 while true。 第一步， code model 模型返回的图楼 use 里带着 agent two。 第二步， run tos。 关键来了，它同时触发了多个 agent two 并行跑，外层循环在这里暂停，等所有子 agent 它跑完才继续下一轮。右边是 worker， 从代码结构可以看到，每个 worker 会创建独立的 agent， 它 id 拿到一份全新的消息，历史和独立状态，然后通过 forwait query 启动自己的 curry loop， 也就是自己的 while 处。说白了就是一句话，每个子 agent 都在跑自己独立的 while 处，上下文隔离，互不干扰，可以并行运行。和单 agent 的 区别不是循环逻辑变了，而是循环的数量变了，一个 while 处变成了多个 while 处同时在跑。 总结一下，从论文层看， auto 键提出把任务拆给多个 agent， 通过对话驱动协助角色分离，组合灵活。从工程层看， antropica orchestrator workers 模式，一个主脑拆任务，多个 worker 并行跑， 结果统一汇总。从源码层看， clockcode 离每个子 agent 拿到独立的 id， 独立的上下文跑自己的 y o 处循环。 说白了， monkey agent 落到代码里就是多个 while 处同时在跑。让 agent 能处理复杂任务的， 不是把一个 agent 变得更万能，而是让合适的 agent 只做合适的事。 while 处一直都在，只是这一期一个循环学会了，生出新的循环。本期内容就到这里了，对单个 agent 的 循环感兴趣的可以从这个系列第一期 react 看起，每个子 agent 内部跑的就是它。 想了解沃克内部的上下文是怎么组装的，推荐我的上下文。工程系列，对 cloud code 内部架构好奇的可以看软件工程系列第五期， cloud code 的 内部就是哈尼斯，点个关注不迷路，我们下期见。

今天是 code code 的 原码拆解系列第三期，上期我们拆了上下文工程，看了四层压缩流水线的原码实线，这期聊安全与约束，但我不打算像上期那样逐行拆原码， 因为权限管理这个话题对大多数正在学习构建 a 阵的人来说，离日常工作有点远。上下文工程是从零到一必须解决的问题，而权限管理是 a 阵的已经跑起来之后才需要做的优化。所以今天我换一个角度， 不讲 cloud code 的 权限系统有多复杂，而是讲为什么你的 agent 会乱来，以及 cloud code 是 怎么解决这个问题的。 我相信每一个用过 agent 的 人都遇到过这种情况，你让 agent 帮你改一个配置文件，他改完之后顺手把你的环境变量文件也改了。 你让他跑一个测试命令，他跑完之后自作主张地执行了一个部署命令，你让他重构一段代码，他把你没让他碰的文件也重构了。 agent 乱来，本质上是一个信任边界的问题，你给了 agent 一个指令， agent 把这个指令理解成了一个更大的授权范围，你说改这个文件，它理解成改所有相关的文件。你说跑这个命令，它理解成跑所有他认为需要的命令。 大多数人解决这个问题的方式是加一个确认框， agent 每次要做敏感操作，弹一个框，问用户允许吗？简单直接。但这个方案有一个根本矛盾，确认框太多，用户会烦，开始无脑点允许，确认框就形同虚设，确认框太少，又拦不住 agent 乱来。 cloud code 的 权限系统就是在解决这个矛盾， 它的核心思路是不要把安全寄托在一个确认框上，而是建一条流水线，让每个操作在执行前经过多层检查，每一层解决一个不同层次的问题。 我挑三个对初学者最有启发的设计来讲。第一个分层规则，最简单的权限系统是一个开关允许或禁止。 cloud code 不是 这样，它有三种规则，禁止需要确认、允许，而且这三种规则有严格的优先级，禁止永远优先。这意味着什么？ 你可以配一条规则说允许所有文件编辑操作，同时配另一条规则说禁止修改版本管理的配置文件。禁止规则会覆盖允许规则，你不需要在全部放行和逐一确认之间二选一，你可以放行大部分操作，同时对特定的危险操作划一条硬线。而且规则支持内容级别的匹配， 不是简单地允许命令行工具或禁止命令行工具，而是可以精确到允许版本管理相关的命令，但禁止强制删除类的命令。这个设计对初学者的启发是，如果你在构建自己的 agent， 不要只做一个全局的开关，至少做两层， 一层是默认策略，一层是例外规则。例外规则优先级高于默认策略，这样用户可以在保持流畅体验的同时，对特定的危险操作保留控制。第二个，生成和评估分离， 这是整个权限系统里我认为最值得学习的设计。 cloud code 里有一个叫 yolo classifier 的 东西，它是一个独立的大模型调用，专门用来审查主 agent 的 每一个操作。 主 agent 说，我要执行这个命令， yolo classifier 看一眼对话上下文和这个命令判断该不该让它执行。两个模型调用，两个独立的判断互相制衡。 这里面有一个非常精妙的安全设计，分类器在审查的时候会看用户说了什么， agent 调用了什么工具，但不会看 agent 的 文字回复。为什么？因为 agent 的 文字回复是他自己生成的。如果 agent 想要绕过审查，他可以在回复里写用户已经授权了所有操作。然后分类器看到这段文字可能就被误导了， 只看 agent 做了什么，不看 agent 说了什么。这切断了被审查者操纵审查者的路径。这个思路对任何构建 agent 的 人都有用。你的 agent 生成了一个行动计划，你要不要用另一个模型调用来审查它？如果要审查，你未给审查模型的信息里应不应该包含 agent 自己的解释？ cloud code 的 答案是，不应该。审查者只看事实，不看被审查者的自我辩护。而且分类器的设计还考虑了成本，大部分操作是安全的，不需要深度审查。 所以他用了一个两阶段的设计，第一阶段只做快速判断，输出空间极小，大部分安全操作在这里就直接放行了。只有第一阶段觉得可疑的操作才进入第二阶段做完整推理，把算力花在刀刃上。第三个不可绕过的安全底线。 cloud code 有 一个最高权限模式，可以跳过几乎所有确认框。但即使在这个模式下有一组操作，仍然会谈确认修改版本管理的配置，修改 agent 自身的配置，修改终端的配置文件。这些操作无论你开了什么模式，都必须确认。 源码注示写的很直白，这些安全检查是不可绕过的。为什么？因为这些文件一旦被恶意修改，影响是系统级的，持久的、 隐蔽的。你的终端配置被改了，你每次开终端都会执行恶意代码，而且你可能很长时间都不会发现。 这个设计的启发是，如果你在构建 agent， 不要把所有的安全决策都交给用户，有一些底线应该是系统替用户守住的，用户自己都关不掉。用户可以选择信任 agent， 但系统要确保即使用户完全信任 agent， 最坏的情况也是可控的。 三个设计讲完了，最后说一个有意思的彩蛋。源码里有一个叫卧底模式的东西。 entropig 的 工程师日常用 cloud code 写代码，包括给外部的开源项目贡献代码。 问题是，内部构建里包含大量敏感信息，比如未发布的模型代号，未发布的版本号。如果提交信息里不小心出现了这些内容，就等于向全世界泄露了内部信息。 所以他们建了一个机制，只要检测到当前仓库不是内部仓库，就自动往系统提示词里注入一段指令，告诉 agent 不要再提交信息和合并请求里暴露任何内部信息，没有强制关闭的选项。讽刺的是，这段防泄露的代码本身是通过构建产物里的原码印刷文件泄露的。 anthropic 专门建了一个系统来防止 ai 泄露内部信息，结果内部信息是被人类的构建配置泄露的。回到今天的主题， agent 乱来。这个问题， cloud code 给出的答案不是一个更好的确认框，而是一条多层的检查流水线， 每一层解决一个不同的问题，每一层都假设上一层可能失败。对于正在学习构建 agent 的 你来说，不需要实现这么复杂的系统，但有三个原则值得记住，规则要分层， 不要只做一个开关，生成和评估要分离，不要让 agent 的 自己审查自己。安全底线要硬编码，不要把所有决策都交给用户。这三个原则，不管你的 agent 做到了什么阶段，都用得上。下一期我们拆多 agent 的 协助，看看集群模式协调器，团队记忆同步在原码里到底是怎么配合。

卡拉 ok 源码意外流出，藏着 ai agent 最核心的生产级设计，内行都在偷偷学，我自己花了一个小时好好研究了这套源码，直接说重点，全是生产级的干货，普通 ai agent 根本比不了。 首先狂浪解决了最头疼的上下文问题，不是简单砍了对话，而是做了四层渐进式压缩，老内容直接裁，工具输出精简，历史对话折叠，实在不行，旁路 agent 压缩，彻底杜绝头梗超线崩盘。 再看这个流势执行不等，模型全数处参数已到位，直接并发跑，工具翻译，网络请求的延迟全给你盖住，响应速度直接拉满。 还有动态技能触发文件修改了，层层防护防篡改堵漏洞，同步 id， 连大文件内存溢出都考虑到了。外加一部生成器做生命周期监控，全程稳的一匹，根本不会崩溃。最后跟你们说透， cloud 的 核心根本不在提示词，而是系统级工程能力做自研 ai ai 整的，照着这个思路抄准没错。

大家好，我是李子毅，又见面了。这次我想讲的不是上个视频中控制电机的那个版本，而是一个更基础的 ai 智能体程序，一个迷你小龙虾。这是一个能在电脑上执行系统命令的 ai 智能体。 比如说我给他一句自然语言任务，帮我在当前目录创建一个文件夹，他不会直接返回一个解释，而是先思考，然后输出一套系统命令，再由 python 程序去真正执行，创建一个文件夹。 下面我给大家演示一下， 下面我将带大家拆解我写的这个基础版小龙虾，别被满屏幕的代码吓到，其实你把它拆开来看，这个智能体的架构很清晰，只由四个部分构成。 第一大脑，它是大模型的接口，我这里调用了 deep 大 模型。第二是规矩，它是一个设定好人设的点 m d 规则文件。 第三是记忆，也就是 python 里的一个 messages 列表。第四，手脚用来帮 ai 敲键盘的执行代码，也就是程序中的 o s 点 p open。 第一个部分呢，咱先看最上面的初步化，这里先 import os， 因为后面要执行系统命令，然后再导入 open ai。 虽然我这里实际调用的是 deep seek， 但是呢，因为它兼容 open ai 的 风格， 所以可以直接写成这样。接着程序创建 client， 把 api key 和 base url 匹配好，这一步就等于把小龙虾的大脑接上了。 然后下面这一段也很关键，程序会读取 agent 点 m d 文件，把整个文件的内容读进 system content， 再用这一句 把它作为第一条 system message 放进 messages 列表里。这一步非常重要，因为智能体不是一启动就天然知道自己是谁，该做什么， 而是程序得先把规则文件塞进他的上下文里，他才知道自己的角角色、任务边界，还有输出格式。 第二部分， agent 点 md 到底在做什么？我们切到 agent 点 md 这个文件， 这个文件可以理解成给 ai 的 一份岗位说明书加操作手册加输出格式规范， 一开头就告诉模型你是一个能够执行系统命令的 ai 助手，你的名字叫 opencall 小 龙虾，你的任务是通过执行命令来帮助用户完成电脑上的操作。 再往下是最核心的两条规则，如果需要执行命令，就必须输出命令冒号需要执行的命令， 如果任务已经完成或者不需要执行命令，就必须输出完成冒号。总结信息，这两条规则其实就是整个 agent 程序跑起来的基础， 因为后面的派送程序根本不懂人类语义，它只会像找暗号一样检查前缀你是不是已命令冒号开头，或者是不是已完成冒号开头。 只有把格式约束住，程序才能稳定地帮 ai 干活。这其实也是提示词工程里很重要的一点，不仅要告诉 ai 做什么，还得教他守规矩。 第三部分， messages 为什么能形成记忆？接下来讲这个程序里最值得讲清楚的地方。记忆机制。 很多人第一次看大模型，都会以为它自动记住向下文，但其实不是。这个程序里的记忆本质上就是一个 python 列表，名字叫做 messages， 你 可以把它想象成一个不断往后写的记事本。第一页是 system prompt， 其实也就是 agent 点 and d。 当用户输入一段话后，程序会用 messages 点 append， 把用户的话记录进去，模型回复以后也会再 append 进去。 如果模型要求执行命令，那么命令执行完以后，程序还会把执行结果再包装成一条反馈，继续 append 回去。 所以 ai 下一轮思考的时候，看到的就不只是最开始的那句任务，还会看到自己刚才说了什么命令有没有执行，执行结果是什么， 所以他才看起来像有记忆，实则不是模型自己在记，而是程序每次都把整本记事本重新发给他，这就是 app 这一串代码的真正作用。 第四部分，为什么会有两个 while true？ 下面再看一个很像 agent 的 地方，两个嵌套的 while true。 外层大循环像一个前台的接待员，负责一直等你输入新的任务， 程序会停在 input 那 里等你发一句新的指令。所以外层循环负责的是接任务， 内层小循环才是真正干活的地方。当用户给了一个任务之后，程序先把任务 append 到记忆里，然后再进入内层循环。在这个循环里，他会不断重复五件事， 第一，把当前所有的记忆发给大模型。第二，拿到模型的回复。 第三，判断回复属于哪一类。第四，执行对应的动作，还有最后第五，把结果再写回记忆，继续下一轮。 所以这个内层循环本质上就是一个思考执行，看结果再思考的闭环。第五部分，最核心的分支判断， 最后看关键的分值判断，也就是 if， else， if 和 else。 如果模型的回复是已完成，开头 程序就认为该任务结束了，打印总结，然后跳出内层循环，回到外层循环，等待下一个任务。如果模型的回复是以命令开头，程序就会把命令的字母串截出来，然后执行最关键的一行， os 点 p open， command 点 read。 这一行就是把 ai 给出的命令真正交给操作系统去执行。也就是说，在这个基础版的小龙虾里， os 点 p open 就 相当于它的手脚。 命令执行完以后，程序还不会停，而是会把执行结果再押回 messages 里，让模型继续下一步思考。 这就是整个程序的灵魂，因为它不是执行一次命令就结束，而是执行完看结果再执行下一步。 这才像一个真正的 ai agent。 如果模型既不是完成冒号，也不是命令冒号，程序就会进入 else， 把内容原样打印出来。其实它没有按规矩输出， 这一段虽小，但也很重要，因为它说明规则文件不是百分之百保险的，程序端还需要兜底。 这份代码的意义不是他执行了多复杂的命令，而是他把 agent 最核心的流程跑通了，用规则文件约束模型，用 messagesign 维护记忆，用循环形成 b 环。 最后通过系统命令，让 ai 真的 能动手做事，以后可以继续扩展成更完整的智能体。 好了，今天就讲到这里，想试一试的朋友，我把代码放到了下面的链接里，喜欢的朋友关注点赞，我们下期再见！

大家好，今天聊 ai agent 设计模式系列第二篇， plan and execute。 从一篇 a c l 论文到 antropics 的 工程文章，再到 cloud code 的 源码，看看先想清楚再动手， 这个思路是怎么一路落地的？上一篇讲了 react， react 跑简单任务没问题，但你让他去重构后端跑测试 tpr， 做着做着就忘了最初要干嘛。你看左边这个 react 的 每一步，嗽特只管下一步怎么走，没有一份写下来的大局计划， 遇到长任务就容易跑偏。 plan and execute 就是 来补这个的。右边是解法，先把所有步骤列出来，写成一份任务清单，再按清单一步一步执行。遇到问题也不是临时换个做法，而是退回来看整个计划，方向不对就改计划文件 规划和执行，拆开来做。这个思路学术界早就有人研究过了。二零二三年的 react 论文， plan and solve prompting 编号，二三零五点零四零九一。你看这三张卡片，第一张是问题，第二张是解法，第三张是实验结果。论文发现 zero shortcut 老是出两个问题，计算错误和遗漏步骤，一查原因就是模型没想清楚全区，就直接开始推理了。所以解法很简单，把提示词拆成两步， 第一步先把问题想清楚，列好计划，第二步再按计划一步步解，结果在五类推理基础上，全面超过了 zero shot cut， plan and sovi 加甚至追上了 few shot cut， 而且不需要任何额外势力。论文解的是推理题，但给出的答案跟 a 帧 t 设计思路完全一样， 也就是先规划再执行。顺便解释一下， zero shortcut 就是 只加一句，让我们一步步想来触发推理，不给任何势力。 few shockcat 则是手动写好几个带推理过程的视力塞进提示词，效果好，但费人工。那工程上怎么落地呢？二零二四年底， andrew pick 出了一篇 building effective agents， 用工程的话把规划于执行分离这件事重新描述了一遍， 叫 orchestrate surveillance 模式。这里还是三张卡片对应三个角色。左边 orchestrate 负责规划，把大目标拆成一个个子任务指出方案不动手，中间撒被枕负责执行，拿到此任务就去用工具干活，只管把眼前这部做完。右边两者之间专门留了一道人工审批 计划出来，先给人看一眼，确认了再开始执行。 antropic mate planet execute 这个名字，但 orchestrator's agency 说的就是这回事。规划归规划，执行归执行，中间加一道门。再来看跨的 code 的 原码，实现方式，有点出乎意料， clove code 没有拆出独立的规划组件和执行组件，整个流程就跑在一个 query loop the well 处循环里，靠一个权限值加一份计划文件， 把三个阶段全撑起来了。你看这段代码按颜色分了五块。紫色是 plan 阶段模型，调用 enter plan mode 系统把权限切到止读，写操作直接被拒。 模型在止读状态下翻代码库，把要做的事写进计划文件。橙色是用户审批模型，调用 x， a， p， m， o， d， 等用户确认，用户点头之后， mode 恢复到原来的状态，写操作重新可以用了。 这一步就是 antropica 强调的那道人工确认门，绿色是 execute 阶段 run to us 跑起来模型，对着计划文件逐步改代码。 红色是 replay， 没有独立的触发机制。计划文件就是词盘上的一个普通文件，执行过程中随时能改。发现计划有问题直接用 file 器 tool 改掉，下一步就按新的来，不需要系统介入。 assistant messages 和 tour results 一 起合并记 messages turncount 加一下一轮继续 mod 的 直，决定这一轮干什么。一个全线直控边界，一份计划文件串流程。以上是基于 cloud code 的 本地源码的观察，不代表官方完整实现。好来总结一下。从三个层面看， planet execute。 从论文层面看， planet solve 提供了先规划 在执行的提示，词范是从工程层面看， andropic 的 orchestrator work 讨论的是如何把这种思想做成可上线的 agent 架构。从 cloud code 的 原码来看， plan mode 则是把先想清楚再动手，落实成了实际工作流。规划和执行是两种不同的认知，任务 只有显示分开，长任务才能跑得远不跑偏。从一句提示词到一篇论文，到一套框架指导，再到 quad code 的 原码， planet x q 特的核心从来没变过， 先想清楚再动手。本期的内容就到这里了，感兴趣的话可以去看原论文与 antropics 的 博客，点个关注不迷路，我们下期见。

这不是一个插件，是一个深度植入 rivet 的 ai 智能助理。告别无休止的菜单，寻找和重复点选，从这一刻起，建模只是一句话的事。 当你下达指令时， ai 会实时分析任务链路，自动拆解步骤。无论是查询特定属性，还是跨类别的批量建模，它都能精准捕捉核心需求，实现从手动操作到意图驱动的质变。 最核心的突破在于主动调用与自我修正。 as two 能够根据上下文环境，在内置工具库中自动匹配最佳方案。它会模拟专家的操作逻辑，从定位元素、判断、约束到执行修改，甚至在任务完成后自动校验执行结果， 确保每一个生成的构建、每一项修改的参数都符合工程逻辑。他还有强大的智能上下文记忆，让沟通不再断层。他记得你上一步的操作，懂你胃镜的语意。 在配置上，我们给予你绝对的自由。你可以使用预设的云端额度实现即装即用，也可以接入自有 a p i t， 在 不同大模型间自由切换。配合持续更新的应用仓库。你可以像添加手机应用一样，按需扩展功能模块。 从常规建筑到市政管网和路桥隧道， as two 正在构建一个不断进化的效率生态， 让剑魔回归设计本质，把复杂留给算法，把时间还给自己。智能剑魔新纪元现已全面开启，欢迎你的加入！

今天聊 agent 的 开发里，一个所有人都想做，但大部分人做错了的东西。记忆系统。如果你在构建 agent， 你 一定想过这个问题，怎么让 agent 在 多次对话之间保持连续性， 怎么让他记住用户的偏好、项目的背景？之前犯过的错误？大部分人的做法是搞一个文件，把所有需要记住的东西往里塞，用户偏好、项目规范、历史决策、代码架构、文件路径全部堆在一起，文件越来越大，偷看成本越来越高，而且大部分内容跟当前对话根本没关系。 cloud code 的 源码泄露之后，我们第一次看到了一个生产级 agent 的 记忆系统到底是怎么设计的？打开源码，你会发现一个反直觉的事实， 整个记忆系统里，工程量最大的部分不是怎么存，也不是怎么取，而是什么该存，什么不该存。 今天我们就来拆这个问题。这是 cloud code 源码系列的第五期，源码里定义了四种记忆类型，同时明确列出了五类绝对不该存的东西。我先讲四种该存的，再讲五种不该存的，你会发现，不该存的那部分，才是整个设计里最有启发性的第一种记忆类型。用户记忆记得是用户是谁， 角色、技术背景、工作习惯、知识水平。比如这个用户是数据科学家，目前在做日制系统的调研，或者这个用户写了十年够，但第一次碰前端。这种记忆的设计意图是让 agent 能调整沟通方式和工作策略。面对一个资身后端工程师， agent 不 需要解释基础概念，可以直接用技术术语。 面对一个初学者， agent 需要更耐心地铺垫。背景元码里对用户记忆有一条约束，不要记录对用户的负面评价，也不要记录跟工作无关的个人信息。记忆的目的是怎么更好地帮这个人，不是给这个人画像。第二种记忆类型，反馈记忆记的是用户纠正过 agent 的 什么，肯定过 agent 的 什么。 这是四种记忆里我认为设计最精细的一种。元码里对它有三个关键要求。第一个要求，每条反馈记忆必须包含三个部分，规则是什么？为什么有这个规则？什么时候该应用这个规则？举个例子，用户说测试不要 mock 数据库。上个季度我们就是因为 mock 测试通过了，但生产环境迁移失败才出的事故。 如果只记不要 mock 数据库， agent 在 所有测试里都不敢 mock， 包括那些跟数据库迁移完全无关的单元测试。但如果他知道原因是 mock 和生产环境行为不一致导致迁移失败，他就能判断集成测试不该 mock。 但纯逻辑的单元测试， mock 是 没问题的。 记原因是为了让 agent 能在新场景下做判断，而不是机械的执行规则。第二个要求，不要只记纠正，也要记肯定源码注示里说得很直白，如果你只记录用户说不要这样做的时刻， agent 会变得越来越保守，他只知道什么是错的，不知道什么是对的。 时间长了，他会回避一切不确定的做法，变得畏手畏脚。但肯定信号比纠正信号更难捕捉，用户说不要这样做。很明显，用户说对就是这样， 或者默默接受了一个不寻常的方案，这些信号很安静， agent 需要主动注意这些肯定信号。比如用户说对这次用一个大 pr 是 对的，拆开反而是无意义的工作量。 这条记忆的价值是下次遇到类似的重构场景， agent 知道这个用户倾向于合并提交，而不是拆成很多小 pr。 这不是纠正，是一个被验证过的判断。第三个要求，反馈记忆要区分个人偏好和个人偏好，只对这个用户有效。 集成测试必须用真实数据库，是项目规范，对所有协作者有效。元码里用 scop 来区分这两种个人偏好存在私有目录，项目规范存在团队共享目录。第三种记忆类型，项目记忆 记得是当前项目里正在发生什么，谁在做什么，为什么要做，截止日期是什么。比如本周四之后冻结所有非关键合并，移动端团队要切发不分支， 或者正在重写认证中建件原因是法务团队指出旧的 token 存储方式不符合合规要求，所以做决策的时候要优先考虑合规性，而不是技术优雅。项目记忆有一个很重要的处理规则，所有相对日期必须转换成绝对日期。 用户说，周四冻结记忆里存的是具体的年月日，因为记忆是跨绘画的，如果存周四，下周再看这条记忆，就不知道是哪个周四了。项目记忆还有一个特点，它衰减得很快， 一个月前的项目状态大概率已经过时了，所以原码要求项目记忆必须记录。为什么这样，即使事实过时了，背后的动机仍然有参考价值。 第四种记忆类型，引用记忆记得是外部资源在哪里， bug 在 哪个系统里追踪监控面板的地址是什么？设计文档在哪个平台，比如流水线相关的 bug 都在 linear 的 某个项目里追踪 或者 api 延迟的监控面板在某个内部地址。值班的时候看这个引用记忆是四种里最简单的，但也是最实用的，它本质上是一个去哪里找信息的缩影。四种记忆类型讲完了，现在讲更重要的部分，什么不该记。 源码里明确列出了五类不该存进记忆的东西。第一类，代码模式、架构、文件路径、项目结构。这是最反直觉的，很多人做记忆系统的第一件事就是让 agent 的 记住项目用了什么框架目录，怎么组织，哪个文件负责什么。 cloud code 说不要存这些， 为什么？因为这些信息可以直接从代码里读出来， agent 随时可以通过读代码和搜索来获取当前的项目结构。把这些存进记忆有两个问题，一是浪费空间，每次对话都要加载一堆本来可以实时查的信息。二是一旦代码改了，但记忆没更新， agent 就 会基于过时的信息做决策，而且你很难发现。 这背后的原则是，如果一个信息可以从当前项目状态推导出来，就不要存进记忆记忆，只存那些看代码看不出来的东西。第二类，版本管理历史，谁改了什么，最近的提交记录，这些用版本管理工具查就行了，是实时的、权威的，不需要记忆来存一份可能过时的副本。 第三类，调试方案和修复方法。修复已经在代码里了，提交信息里有上下文存怎么修的没有意义，因为代码本身就是最好的参考。 第四类，项目说明文件里已经写过的东西。如果你的配置文件里已经定义了编码规范，记忆系统不需要再存一份，重复存储不仅浪费空间，还会在两份内容不一致的时候制造混乱。第五类，临时性的任务细节，当前正在做什么？对话里的中间状态，这些是短期的，属于当前绘画的上下文，不该进入长期记忆 源码里还有一条规则特别值得注意，即使用户明确要求你记住某些东西，如果它属于上面五类，也不该记。如果用户说记住这周的 pr 列表， agent 应该反问，这些 pr 里有什么让你意外的或者不明显的那个部分才值得记。活动日制不是记忆，从活动中提炼出的洞察才是。回过头来看，这套分类体系 四种，该存的用户是谁？用户纠正和肯定过什么项目背后的动机和时间线，外部资源在哪里？ 五种不该存的代码能告诉你的一切，版本历史能告诉你的一切，提交记录能告诉你的一切，配置文件已经说过的一切。临时性的中间状态，你会发现一个清晰的分界线，该存的全部是关于人和上下文的信息，不该存的全部是关于代码和项目状态的信息。 代码是实时的、可查的、权威的人的偏好。纠正动机，外部资源指向这些藏在代码之外，不查记忆就无从得知。 这就是 cloud code 的 记忆系统的核心哲学。记忆是代码的补习，代码能回答的问题不要让记忆来回答，记忆只负责代码回答不了的那部分。如果你在给自己的 agent 做记忆系统，这个分类框架可以直接拿来用。 先问自己这条信息能不能从当前代码或工具里实时获取，如果能不存，如果不能，再看它属于哪种类型，用户反馈项目还是引用按对应的格式存。这样做的好处是，你的记忆文件会非常精简，每一条都是高价值的代码里找不到的信息 模型，每次加载记忆的时候，看到的全是有用的东西，没有噪声。下一期我们继续拆记忆系统的第二个关键设计， active recall， 也就是 cloud code。 怎么在几百条记忆里，每轮对话只挑出最相关的五条，注入上下文，先摘要后全书的两阶段检索，用便宜模型做选择，这个思路你马上就能。