龙虾openclaw如何开放api

ok， 接下来我们来从零到一的实操下 openclaw 的 安装、部署和使用。那装之前一定要问自己一句，你想让他帮你做什么？不要盲目跟风。 目前的 openclaw 不 太适合用于生产环境，所以只能算是一个有意思的玩具。如果你有闲置的 mac mini 或者任意一台闲置的 macos 系统电脑，那他们一定是最好的选择。 如果你是 windows 电脑，那也可以，只不过 openclaw 的 生态对 macos 系统支持比较好。那如果你都没有，不建议大家为了使用 openclaw 去买一台电脑， 也一定不要在你日常使用的电脑安装，包括国内各个公司基于 openclaw 推出的一键安装的客户端，都不要在自己日常使用的电脑安装。 如果你实在想体验一把，我们可以花二三十刀，也就是一百来块钱购买一台两合两 g 的 vps 就 可以了。如果你觉得你会长期使用，从而装很多东西，那就买一台四合四 g 的 vps， 大概是四十刀到六十刀左右。哦，对，我说的是一年的价格，非常便宜。那我目前这台 v p s 应该是一个三合四 g 加一百 g 的 硬盘配置，使用的是无斑图二四系统，不是它必须得这个配置，而是我目前只有这样一台闲置的 v p s。 来做演示了。那我之前一直在使用的 oppo cloud 服务，其实是部署在一台两合两 g 的 v p s 上， 没有问题，基本够用的，也装了很多额外的扩展，那目前这台机器的内存占用是百分之四十，此盘大约用了有十五个 g。 ok， 我 们来到官方文档，复制一下安装命令，然后回到终端直接执行， 这里由于要安装一些东西，所以比较慢，大家要等一下安装完成之后，我们就进入了一个引导配置，那这个提示简单来讲就是问此安装是不是你一个人在用？如果是个人用，选 yes， 那 如果你这台机器还会给别人登录，或者是放在公司服务器上，以及要对外公开访问，那就选 no， 我 们选择 yes， 然后选择快速入门。接下来是选择模型厂商这块，根据自己的需求来，他特别需要注意的是，如果使用国产的 mini， max， kimi， 智谱这些厂商，他们分国内版和国外版，那我们这里先选一个自定义的 provider， 也就是自定义厂商，输入我们的 base ul， 大家根据自己使用的平台写就好，但一定要注意，因为我们平常使用可乐扣的扣的 x 去配置自定义厂商，背四幺 l 的 时候一般不用写后面的 v 一， 但 open colle 这里要写。然后回车，我们选择直接粘贴 api k， 把我们的 api k 粘进来，回车短点兼容性，这个看我们自定义厂商的平台支持啥，一般都会支持 opa 这种格式，所以我们直接选 opa 就 可以。接着是模型 id， 如果你是选择自定义厂商呢？模型 id 需要你自己填，那我们这里用 gpt 五点四 回车， ok， 刚我们回车之后，它自己做了验证，那如果你的填写有误，这块会验证失败，那接下来是填的自定义厂商名字， 接下来是模型别名，我们直接回车即可，不用填。然后就开始配置聊天频道了，就是你要在哪个应用上跟你的瞎子聊天就选哪个。那我的建议是能用 telegram， discard 就 用它们，用不了的话，国内最合适的就是飞书，那飞书国内版目前也已经内置在 opencloud 包里边了。既然配置麻烦了点， 目前最简单的消息频道配置是 qq， 但他最多只支持五个机器人，还容易被屏蔽一些消息。那微信的话想要接入就只能走起微了，那更麻烦。 最近腾讯出的比较让人期待的 qq 了，最终走的也是客服消息，而不是给了个人微信机器人号，所以也不推荐。那后面我会使用飞书做演示，其他几个消息频道的接入教程就不在视频里讲了，看视频的附属文档就可以。这里我们先选择跳过 一会再来配置聊天频道。接下来是选择联网搜索的供应商，那如果你有这几家的 api k， 那 就填，如果没有的话就跳过。 然后是配置技能，也就是 skills， 我 们选择否后面再按需安装就可以。其实 skill 为啥出来比 mcp 晚，但是却能盖过 mcp？ 我 们在玩瞎子的过程中会有深刻体会， 这一步是在问你要不要起用一些附加小功能。自动钩子，通俗点讲就是当瞎子触发了某个事件时，自动帮你做一些事情，不开也能用。开了只是多一些自动化或者是增强功能。看到的这几项大概可以这样理解， bot md 就是 在 get 位启动的时候自动运行 bot， 点 md 文件，也就是 open cloud， 一 启动就先把你写在 bot 点 md 里面的启动说明，输入法规划 及预设内容读进去可以理解为开机自启动的说明书，那接下来这个是在 agent bootstrap 阶段额外注入一些工作区文件，那官方说明是，当你的工作区里面有多个上下文跟目录，比如 monroe ripple 多模块项目，想要把额外的 agent 点 md tools 点 md 这类文件一起带入上下文，但是又不想改工作器跟目录，那就用它。然后是 command log， 它是记录你执行过的命令，方便排查问题，把所有的命令事件记录到一个统一的日期文件里。 section memory 保存绘画记忆， 就是让他记住这次运行中的一些上下文。当你发出斜杠 new 指令的时候，他会把当前绘画的上下文保存进 memory。 通俗点说，当你打开一个新的绘画时，会把旧的绘画存档，那这些都是一些基础的户客，大家可以根据自己的需求去选，不选也可以，我们这里可以选都勾选上回车， ok， 这就已经就绪了。这一步是在你想用什么方式把下子启动起来。第一个 t u i 就是 在 v p s 部署，所以它是推荐方式，也就是直接在命令行里和它交互，不用开浏览器。 第二个是 web ui， 这是个网页界面，就是启动后用浏览器来操作，看起来更直观。第三个就是不启动之后再说，我们直接选择 web ui， ok， 它让我们运行 dashboard 的 命令来查看这个 web ui 的 服务，我们直接跑一下这个命令， 那由于我们是在服务器上跑 opencloud， 没有 g u i 页面，所以你会看到它让我们在本地使用 s s h 连接服务器内部的一个服务端口，通过这样的方式就可以在我们自己的电脑上访问这个 web ui 控制界面了。我们直接把这一行复制一下， micro s 就 打开 bash item， windows 就 打开 powershell， 然后把这个命令粘贴回车一下，是否继续连接输入 yes， 然后我们输入服务器的密码，回车 密码输入时啥也看不见是正常的，大家只管输入完回车即可，输错了就重新来一遍，只要回车没有报错，那就是成功了。也就在本地电脑和服务器的 opencloud web 服务之间建立了一个隧道连接，然后我们回到服务器终端，我们复制一下这个链接， 打开浏览器，那这样我们在本地电脑浏览器就可以看这个外部 ui 界面了。那需要说明一下，之所以使用隧道的连接方式，是因为这是默认且 opencloud 推荐的方式。当然我们也可以直接将服务器的 opencloud 外部服务暴露在公网上，通过服务器的 ip 或者是绑定域名来访问， 但这样很不安全，如果你需要暴露到公网，那么 opencloud 的 配置力度需要在细上一些，以应对一些安全风险。进入外部 ui 之后，默认就是聊天面板，我们直接发送一个消息， 那如果你的模型配置没有问题，就会收到回复。 ok， 到这里快捷的引导设置就完成了，夹子也算基础部署成功了，后面就是定制化了，接下来我们来配置一下飞书机器人的接入。那首先我们要打开一下飞书开放平台， 这个不需要使用企业飞书，个人飞书也可以点击创建企业自建应用，我们给个名字和描述，然后选一个图标吧。 ok， 创建完了之后，我们就可以看左侧的侧边栏，选中凭证信息，这里的 app id 和 app secret 我 们要复制下来保存好。 ok， 我 们回到服务器的终端面板，输入添加频道的命令，问我们是否配置。是，然后我们选择飞书， 那上面这个是让你重新下载飞出这个插件，但是现在它内部集成了，所以我们直接使用插件路径就可以。 ok， 它让我们填 app secret， 我 们回到飞出平台，复制一下这个 app secret， 回来粘贴回车，然后设 app id， 再复制一下 粘贴回车。连接方式，我们选择默认的 web socket 就 可以，然后非输的域名，那国内的就是 c n 的 后缀。群组的安全配置， 第一个是白名单，只有在白名单内的群组机器人才会回复。第二个是全部打开，机器人被拉进任何一个群组它都可以回复。第三个是直接在群组中借用机器人，那我们选择白名单就可以，由于我们还没有创建群组，我们直接回车就可以，后面有了再添加。 ok， 这样就基本上配置完了，然后我们选择 finish 完成，让我们配置飞书的 dm 策略，选择 yes， 这个策略我们直接全部打开就行，这样最简单。给账户添加显示的名字，然后我们选择 no 就 行，然后给这个账户绑定 agent。 yes， 那 选择 agent 的 时候，它只有一个默认的 man， 我 们回车。 ok， 这样就配置好了，然后再回到飞出控制台，点击权限管理，然后点击批量导入权限，然后粘贴所有权限的 jason， 那 这个大家直接粘贴我提供的这份就好，因为官方文档上面的那份， jason 缺少一个权限，点击下一步确认申请开通，确认 确认， ok， 权限开通好了，我们点击机器人，然后配置一下它的名字， 然后在左侧点击事件与回调，点击这里的订阅方式，然后选择长链接保存。注意这里保存时， opencloud 的 应用程序必须已经配置好了，并且正在运行中才能保存成功。然后我们点击添加事件，直接搜索接收消息，勾选它添加， 然后我们直接点击上方的创建版本，给一个版本号更新说明，也填一下，滑到最底部，点击保存确认， ok， 这个时候我们打开飞书， 那在飞书里面就可以看到一个应用创建成功的推送，我们直接点击打开应用，然后给他发个消息， 当我们收到了回复之后，飞书的渠道配置就已经完成了。 ok， 接下来先不着急，我们先来了解一下 openclaw 的 目录结构。首先你一定要知道一个目录，点 openclaw， 我们使用 cd 命令来进入到 opencloud 的 根目录，然后输入 ls， 看一下根目录下都有什么文件。 opencloud 点 jason， 这是 opencloud 的 主要配置文件，相当于总控面板，大多数的核心设置都在这里，以后也少不了和他打交道。我们刚刚在引导配置中的绝大多数内容最终都落到了这个文件里，那这个文件还有一些，后面带 back， 然后 back 一， 这是配置文件的备份，当我们执行一些修改操作时， opencloud 就 会帮我们把之前的内容存一个备份，避免我们改坏了回不去。 workspace， 它是默认 agent 的 工作区目录，放的是你希望这个 agent 的 长期记住遵守的东西，比如项目文件、说明书、长期规则、人设等等。那 agent 目录， 这是每个 agent 自己的后台数据目录，用来存放这个 agent 的 运行状态、认证配置、绘画记录等内容。官方会把一个 agent 分 成三部分， workspace 用来存放 agent 的 人格以及规则，还有记忆文件。 agent d i r 存放每个 agent 的 状态配置。 session 存的是 agent 的 绘画记录，其中 agent d i r 和 session 最终都会落在这个 agent 下面。那这个目录下面现在只有一个 man， 它是我们在程序安装时的默认 agent， 那 这个名字叫 man 的 agent 对 应的工作区目录就是这个 workspace log 文件夹存的是各类的运行日制，那出问题的时候第一时间看的其实就是这里，尤其是 getaway， skills， hux 相关的错误。 converse， 它是用来规划和编排的临时目录，很多 a 正的框架会把计划任务分解，临时中间产物放在类似的区域，用来支撑一个提示来触发多个模型调用的链路。 on， 它是定时任务与自动化触发的文件夹。 devices， 它是设备与执行环境的抽象层。飞书目录，它存放的就是飞书机器人适配与凭证的相关信息。有这个文件夹是因为我们装了飞书机器人 identity， 它是存放身份与认证的相关目录。 update check， 这是 opencloud 的 更新状态与相关原书记检查的文件。 我们再来看一下 workspace 里面都有啥 agent 点。 md， 这个里面存储的是有哪些代理各自负责什么？相当于岗位的说明书，一个工作规范，也是最重要的一个文件。四五 md， 这里面存放的是瞎子的灵魂设定 u 字。 md， 它存的是你是谁，你的偏好和禁忌，相当于用户画像 tosh。 md， 存放的是它能用哪些工具，怎么用？边界是什么？相当于工具清单。 heartbeat， 这里面存放的是一个自检和状态汇报规则，俗称心跳机制文件，比如启动后该检查什么，多久报一次状态。 bloodstream， 它是冷启动时先读的初步化说明，那我们现在还是一个空的 agent， 还没有产生记忆，如果产生了绘画记忆，这个下面还会有一个 memory 文件夹，文件夹下存放的是年月日点。 md 文件，作为我们每天聊天的记忆存放，那还会有一个 memory 点 md， 存放的是稳定的长期记忆， ok。 在 了解了 opencloud 的 目录结构之后，我们想一个问题，你需要几个 agent 帮你处理事情？一个够吗？可以这么说，如果你觉得够，那 opencloud 对 你来说可能未必是最合适的选择。 用 opencloud 的 可玩性建立在多个 agent 的 分工和协助上。如果只有一个 agent， 你 又希望他同时处理很多不同类型的事情，问题很快就会出现，他的上下文会不断被污染，人设会越来越混乱，记忆也会越积越多，滔滔消耗更是会不断飙升。 更麻烦的是，旧任务留下来的对话和上下文，还会持续干扰他对新任务的判断。所以接下来我们要处理的是多个机器人，多个 agent， 一个 agent 只专注一类事，那既然我们要做多 agent， 每个机器人都是不同的打工人， 所以接下来我们要新创建一个 agent， 我 们输入命令来添加一个新的 agent， 后面的 bot 一 agent 就是 我们给这个新的 agent 的 命名，我这个命名比较随意，如果大家有明确的想法，比如这个 agent 是 做什么的，最好语义化命名，不要用中文回车。 然后它让我们输入这个 agent 的 工作区目录，这里它会给一个默认的，当然我们也可以直接把它设置成 workspace， 这样的话和之前那个工作区就在一个目录下，那两个 agent 就 会共用一个工作区。但是我不太建议这样做， 直接回车就好，你会发现它默认在点 opencloud 目录下给了 workspace bot 一 agent 这样一个目录当工作区。结合我们之前介绍过跟目录下还有一个 workspace 工作区。 现在你回过头来理解， workspace 目录其实就是名字为 man 的 这个默认的 agent 工作区目录。那我们现在新创建了一个 agent， 这个目录就是我们新创建这个 agent 工作区目录，然后我们配置模型选择 yes， 那这个大家应该就比较熟悉了，之前引导配置中第一个机器人瞎子我们已经配置了自定义的 provider， 那 这次就换一个官方的吧，具体看你买了哪家。 我其实哪家都有，但是这里选中 mini max 的 速度比较快，所以这里选中 mini max。 mini max 前两天更新了一部，如果使用它官方渠道作为提供商时， opencloud 以内置工具会自动连接到 mini max 的 vl m api 端点，不需要额外配置。 当我们向机器人发送图片的时候，他就会使用这个工具来理解图片内容，也就是自动连接 v r m api 端点来做图片多模态处理，这点还挺方便的。我们选中 office 授权登录，然后选择 c n， 复制一下这个链接，在浏览器打开，然后授 权好了，然后他问我们还没有创建第二个机器人，所以这里先选择 no， 一会创建完第二个机器人，再把它和这个 agent 绑定， ok， 这样就创建好了一个新的 agent。 我 们再来看一下 agent 目录下面都有啥，可以看到多了一个 bot 一 agent， 然后我们也可以跑一下命令，看一下 agent 列表， 看到有两个 agent， 工作区路径也没问题，这就 ok 了。接下来我们来创建第二个飞书机器人，之前我们已经添加了一个机器人，它挂载的是默认账户，默认 agent， 也就是问这个 agent。 我 们回到飞书开放平台，创建第二个机器人，还是同样的操作， 点击创建企业自建应用名字，我们叫瞎子一号， 然后点到应用凭证，再次回到服务器面板，我们需要来配置第二个飞书机器人账号，那这个配置有点特殊，目前需要单独来改配置文件，没有办法通过命令集成，不过这个官方 e c u 已经提到了，估计很快就会得到优化。我们来看一下配置文件中目前的飞书配置是啥样。输入 cat， 这个就是目前的飞书机器人配置，它只配置了一个账号，我们可以直接在服务器上改这个配置文件。当然也可以简单一点，我们回到它这个 web ui 里面， 直接发送给 opencloud 一 段提示词，我让它根据官方的飞书配置文档帮我配置第二个飞书机器人，然后把 app id， app secret 填进去回车。 ok， 他 说配置好了，让我们重启一下，我们复制命令重启一下，再来看一下这个配置文件。 ok， 这就配置好了。那这里需要注意的是，我敢让他动配置文件，是因为我知道官方文档有这么个配置参考， 也知道他要改的是什么东西，我才会放手让他改。如果你不知道怎么改，直接让瞎子给你改配置，那就把你的 open class 系统生杀大权交给了大模型，你的大模型优质的话，能解锁到相关的信息去修改还好，如果大模型不太行，一旦出现了幻觉，那记记你会更难受，所以还是要尽量避免这种行为。接下来我们回到飞出开放平台，继续之前的操作， 点击权限管理，批量导入，粘贴一下，这个跟之前还是一样的，确认申请开通确认确认，然后点击机器人配置名称， 点击事件已回调订阅方式保存。哎，怎么不对？我们来看一下这个配置哦，这怎么写了两份？这个也是写了两份，我们回过头来看一下给他发的消息， 哦，这里发错了，再来复制一下，这里 app id 和 app security 写错了，给你修改一下。 ok， 这回改对了，刚刚那个给他发的提示词里面的 app id 和 apprecate 写错了，我们再回来点下保存。嗯，这次就可以了，刚好演示了一下，如果配错了，这里保存保存不成功，然后点击添加事件接收消息，勾选添加 创建版本，给一个版本号保存发布。 ok， 看一下有没有推送，打开应用，让我们给他发个消息。 ok， 收到回复之后我们就配置完成了，但是这个时候其实我们还没有给这个机器人绑定之前新建的 agent， 我 们可以通过命令来看一下当前 agent 的 绑定关系。 哎，你看我们新创建的瞎子一账号，其实默认绑定在了 man 这个 agent 下面，那目前这两个机器人其实用的是一个 agent， 我 们可以直接修改这个 agent id 的 名字，那这次我们在 yui 里面修改， 我们在这个 dashboard 里面找到 config， 然后点击 ro， 那 现在这份文件其实就是我们的配置文件，我们拖到最底下，找到这个飞书的配置，这是我们刚刚看的飞书的配置，我们找一下 b 的， 对，就这里我们把虾子一这个 agent id 改成我们刚刚创建的新的 agent 名字。 bot 一 agent 修改好了之后，我们直接点击保存更新， ok， 当它断掉，那就是证明已经重启了， 那等它恢复了之后就重启好了。我们直接回到飞书这里，给虾子一号发送一下，问他一下是哪个 agent， ok， 它已经切换到新的 agent 上了，那到这里我们的多 agent 多机器人账户就配置好了。接下来我们来创建一个飞书群组， 填上名字，飞书群组一个人也可以创建群聊，我们直接点击创建，必须得群组创建好了之后，我们才能邀请机器人进来，点击右上角选择设置，点击群，机器人添加， 选中瞎字添加， ok， 这样群组就创建好了。那由于我们之前设置了白名单，只有在白名单内的群组机器人才会回复，我们现在在群组里面给他发消息，他是不会回的，所以我们要先获取飞书群的 id， 那 获取的方法也很简单，我们回到服务器这里 输入 openclogs 转杠 follow 回车。这个命令是实时查看服务器网址，我们打开网址之后，在飞书群里面圈一下机器人，发一个消息。 ok， 这就可以看到这有一个 group， 后面这个 o c 开头的就是它的群组 id， 我 们复制一下， ctrl c 关掉它，还是直接在外部 ui 里面直接给它发消息，让它去改回车。当然我们也可以直接在飞书给机器人发消息也行。 ok， 已经改好了，我们直接让它重启，当看到它断了，那就是开始重启了。 ok， 恢复了，那就重启好了，我们再回到飞出这里再圈一下它，因为我们设置的是只有圈它，它才会回复 这个图标，代表它已经在输入了。 ok， 这就好了，那这样的话群组就搞好了。这里要特别提醒一下，不要轻易被网上那种一个群里面塞满不同角色机器人组成一个所谓的 team， 大家自己讨论自己工作的演示带偏了，那都是博眼球。绝大多数情况下并不是一个合理的生产实践， 因为在多 a 阵的多角色的设定下，每个机器人本质上都对应一个明确的角色和职责边界。如果你把多个角色的机器人同时拉进一个群里面，让他们同时面对同一批消息，那系统很快就会变得混乱。相对还算勉强可控的一种方式是通过艾特提及的方式来明确指定某个机器人角色回应， 也就是说，只有你明确艾特到哪个机器人，哪个机器人再出来处理。如果不是通过艾特提及，而是群里随便发一条消息，多个机器人都可能响应，那就必须额外做非常严格的路由控制。比如你至少要配置成只有某个特定用户 id 发出的消息，才有某个对应的机器人处理。 但即便如此，我仍然不建议让多个 a 证的机器人同时处理同一条消息并分别回应。因为你一旦这样做，整个系统基本上就会进入一种自由混战的状态，看起来好像很智能、很热闹，实际上很多时候只是无意义的多轮响应和无休止的 talk 消耗。更关键的是，这种模式并不真正符合大多数真实的工作组织方式。 现实里的工作流往往不是让一群角色同时对一个输入各说各话，而是有明确分工、明确入口以及明确的责任边界。哪怕你已经做了限制，比如让机器人只回复某个特定 id 的 消息，这种方案本身也不算理想， 因为很多人类的工作流并不是完全串行的，消息和任务经常会交错出现。一旦多个角色长期混在同一个上下文里，非常容易出现上下文混淆、职责边界模糊、记忆污染等问题。所以更合适也更常见的做法其实是下面这几种，一个机器人对应一个 agent， 一个群组对应一个专用的 agent 机器人， 或者一个主机器人作为一个统一入口，背后有多个专职的 a 政在后台分工协助。这几种方案虽然没有多机器人同群互聊那么有观赏性，但从稳定性、可维护性、上下文控制以及 top 成本来看都会更合理。 当然再往后走，如果你真的想做成多 a 政的协同，那就已经不是简单把几个机器人拉进同一个群里面这么粗暴了，而是需要更高级的路由编排和协助策略。这个话题可以单独展开讲，后面有时间的话可以再开一下 a 政的协同的内容，这里我们就先不展开了。 那到这里，我们其实已经有了两个彼此独立的 agent， 也分别绑好了对应的机器人频道，但目前为止我们还没有给他们做任何的功能增强，也没有给每个 agent 配置各自的身份信息、角色设定 和风格。所以现在这两个 agent 还是两个空壳子，虽然他们已经能独立运行，但是还没有真正形成差异化。那接下来我们就要先给这两个 agent 分 别配置不同的信息和性格， 他们真正区分开来。其实我们前面已经讲过，工作区里的那些文件分别对应着什么作用，我们完全可以直接手动去修改这些文件，给 agent 写入不同的设定，但是这种一方面比较繁琐，另一方面不太直观，所以这里我们换一种方便的方式来做。我们直接打开外部 ui， 那 这个是闷塞审，也就是瞎子那个机器人， 我们直接给他发送一个提示词，你是瞎子，一个赛博打工人，巴拉巴拉一堆，然后我们让他自行优化，并且拆分提示词，将这些提示信息分别写入下面的文件里面。回车， ok， 可以 看到它已经帮我们修改好了，这里它问我们要不要把 bootstrap 删掉，这个文件我们之前有介绍过，它只有在输入话的时候会读，删不删都无所谓。那我们直接在面板里面来看一下这几个文件，点击 agent， 然后点击 men， 然后点到 feel 看一下。哎，你看这里面它的灵魂设定已经帮我们写进去了。再来看一下 user， 可以 看到我的名字也写进去了， agents 点 md 这个文件大家有空的时候可以好好看一下，因为整个 agent 的 运行机制其实大概就写在这里， tools 身份 memory ok， 我 们回到飞书给瞎子发一下你是谁， ok， 这就已经配置好了。那现在我们就给瞎子配置了一些基础信息，我是谁，他是谁，他的性格等等等等， 都是些基础信息，也比较简单，大家可以顺着这个思路自由配置。那另外一个 agent 配置起来就简单很多了，也是一样的流程，这里就不赘述了，大家可以给不同的信息自己玩一下。那接下来我们给 agent 做一些基础能力扩展。首先是浏览器操作，那如果我们有 g y 面板 这块就会简单很多，但是由于我们使用的是无 g y 面板的无斑图系统，所以要稍微麻烦一点，我们需要先手动安装一下浏览器，虽然也可以让 opencloud agent 帮我们安装，但不建议这样做，因为需要给它开额外的高级权限才行。那首先我们需要安装一个 chromeem， chromeem 是 谷歌自己家的正式浏览器， 而 chromeem 是 chromeem 浏览器的上游开源版本。那这里需要注意的是， nipp 版本的自身的沙箱机制会产生冲突，导致 c d p 无法正常启动， 所以官方推荐使用 chrome 的 d e b 包，这是专门给得遍或者是无斑图这类 linux 系统用的安装包。首先我们来执行安装 c d p 连接，就是程序通过 chrome 的 devtools protocol 去远程控制浏览器的连接。 playrite 是 python 的 一个浏览器自动化框架，当我们安装浏览器后， open color 会负责浏览器的接入配置和路由， playrite 负责执行很多具体的自动化动作，而底层的浏览器通信协议走的是 c d p， 这样就形成了 linux 系统上的浏览器自动化。 ok， 下载好之后，我们还需要执行安装 那由于我们使用的是 d e b 的 方式安装的浏览器，这种方式还会缺少一些依赖，所以我们还需要让 app 自动把上一步安装 chrome 时缺失的依赖补齐，并且把包的状态修复到正常状态。我们输入命令回车， ok， 一 切就绪之后，我们输入命令来验证一下浏览器的安装路径，然后检查一下它的版本， 这里输出了目录，并且成功输出了版本号，就安装成功了。然后我们输入命令来验证一下无沙箱无头模式下的 c d p 连接。 ok， 只要出现这个幺二七的监听链接就可以了。下面无关紧要的一些报错，比如 g u i 内部的一些注册服务错误可以忽略， ctrl c 退出， ok， 我 们开始配置 openclaw 使用浏览器。这里我们选择的是命令行配置，那最终也会落在配置文件里，我们直接改配置文件也行。首先我们需要启用浏览器能力， 然后配置一下浏览器的路径，那由于我们用的 vps 没有图形界面，所以我们还需要开启无头模式，还需要关闭沙箱来规避 linux 类服务器或者是容器环境下的权限与隔离限制问题。 最后我们还需要指定一下浏览器的 profile。 ok， 这些都执行完，重启一下 get 位， 重启完成之后，我们打开 web ui， 我 们来看一下这个配置落到配置文件里面是什么样子，就是这段配置。 ok， 我 们来测试一下浏览器输入命令，启动一个浏览器实力， 启动成功之后，我们让它打开一个网页，打开之后我们来抓一下这个页面的快照， ok， 拿到结果就没问题了，我们也可以尝试抓一下这个页面的截图， ok， 如果能拿到快照或者是成功截图，说明整个浏览器的渲染页面打开控制链路基本上都是正常的。那现在就可以在飞书里面给机器人发消息，让他截个图试试了。让虾子一号处理吧，虾子一号用的 mini max， 速度比较快， ok， 给了我们截图，那就是成功了。接下来我们来处理联网搜索。 openclaw 有 两个内置的搜索和爬取的 tools， 分 别是 websearch 和 webflash， webflash 负责实时搜索网络内容， webflash 负责爬取某个网站的信息， 这两个 tools 组合起来就构建了一个实时网络剪索的能力。但是由于 openclaw 内置的 websearch rely brave， 这是一个三方的搜索引擎，如果我们要使用的话，需要额外配置 brave 的 api， 这个是收费的，所以目前联网搜索是用不了的，那我们的代替方案就是使用其他的 search 服务来代替内置的 web search。 这里推荐两个 skills 来配合完成这件事。首先是 tabule 这个 skill， tabule 同样是一个三方的商业搜索引擎，但好在它每个月有免费搜索一千次的额度，所以我们可以放心使用。我们可以直接打开 tabule 的 官网， 然后注册就可以拿到一个 api k 复制下来就可以了。还有一个是 multi search， 这是一个集成了多个搜索引擎的免费搜索服务， 如果它 webster search 的 服务不够用，或者搜索结果少的情况下，我们可以使用 multi search n 这个搜索服务来都抵。这两个 skill 组合起来代替内置的 webster， 安装方式也比较简单，我们可以直接发送提示词给瞎子， 我们让它根据文档自己去安装，安装完成之后在 toast 文件里面明确声明 webster 能力的 skill 使用，最后把内置的 webster 能力给禁用掉。 ok， 我 们来看一下 toast 文件， 哎，可以看到它帮我们把这个搜索策略写到了这个 tos 文件里。装好之后我们测试一下，可以看到这里它已经调用了它为设置这个 skill。 那 如果你不想装两个 skill， 并且想要在企业里部署无限使用 web 搜索能力的话，还有一种方案是在一个服务器上自己部署一个 z r x n g 服务，这是一个开源的原搜索引擎服务，聚合了多个搜索引擎的搜索结果。 安装好之后就可以在 opencloud 安装一个 c r x n g skill 来进行搜索服务的本地调用，可以返回结构化的搜索结果，那 像一些三方的收费搜索引擎，会随着你的搜索偏好提供一个个性化的搜索结果。但 c r x n g 这种则是不关心你搜什么，只通过你的搜索内容拿到各个搜索引擎的结果，打分排序，完全隐私，是一个不错的免费搜索方案。如果你想做任何 agent 缺乏 web search 的 能力，都可以使用它。 ok skills 技能，这是 openclaw 能力的核心。通过上一爬联网搜索，我们可以看出，我们需要通过一个个 skill 来扩展 openclaw 的 能力。 那社区上有上万个开源的 skill 让我们集成。我们可以通过 openclaw 官方的 cloudhub 平台去查找对应的 skills， 也可以通过 github 的 awesome openclaw skill 仓库去查找想要使用的技能。 比如你在做一个企业级的 open class 系统，并且企业委托于飞书办公，那么你就可以搜索飞书相关的 skills， 读写飞书文档，操作多余表格，以及处理一系列飞书的自动化功能。你要是想赛博炒股，就搜索金融相关的 skill 去装。要是想让虾子去写代码，那就搜 coding 相关的 skill， 根据自己的需求去装就可以。我给大家推荐一个比较核心也比较通用的技能， self improving agent。 这个 skill 翻译过来叫自我提升，它的核心不是让模型自己训练自己，而是让 agent 在 运行过程中把错误纠正、知识缺口、功能需求结构化写入 markdown， 再把那些反复验证有效的经验进一步提炼成长期可付用的工作规则。它主要解决的是一个非常现实的问题，很多 agent 在 使用过程中都会不断犯错，有的是命令执行失败，有的是工具调用翻车，有的是知识过时了， 还有的是被用户指出你这种做法不对。如果这些问题每次都是当场改正一下就结束了，那这个 agent 本质上没有真正成长，下一次遇到类似的情况，他大概率还会踩一遍同样的坑。而这个 skill 做的事情就是把这些当场修正变成长期记忆。他的 skill 点 m d 里面写的非常明确，典型的触发场景包括命令或操作失败。用户纠正 agent， 用户提出当前做不到的新能力。外部 a p i 或工具调用失败。 agent 呢？发现自己的知识已经过时，或者在重复性工作里发现了更好的做法，所以它本质上不是在增强模型参数，而是在给 agent 增加一层失败记录，加上经验累积，加上晋升规则的机制。 会先在工作区里面建立一个 learnings 目录，把经验分别记录到三个文件里。 learnings md 记录更正知识缺口和最佳实践。 arrows 记录命令失败和异常。 future request 记录用户请求的功能。他会先把这些经验沉淀成可追踪、可复查、可累积的外部记忆， 然后再进一步把那些已经反复验证确实有效的经验提升到更长期的工作区规划文件里。比如行为模式可以提升到 so 点 md 里，工作流经验可以提升到 agents 点 md 里， 工具使用规则则可以提升到 twos 点 m d 里。写进 linux 目录只是临时记录下来，而提升到这些长期文件之后，才意味着这些经验会在后续的绘画中真正参与上下文变成 agent 的 稳定行为规则。那为什么我会觉得它很核心？因为它其实已经碰到了一件更庞大的事情，那就是怎么管理 agent 的 记忆 memory。 不管你是做个人助手、做工作流 a 证的，还是做多 a 证的协助，如何把错误纠正经验沉淀下来几乎是绕不过去的一件事情。而这个 skill 恰好提供了一套非常朴素但却非常实用的解决思路，它可以为我们后续的记忆治理埋下影子。那安装方式和之前一样，是复制一下这个链接，让 openclaw 自己安装即可，我们就不做演示了。 我们前面提到过， open klo 官方的 memory 记忆整体是偏轻量化的，真正的记忆载体始终是工作区里面的 markdown 文件。也就是说，不管你后续接不接数据库，开不开向量剪索， memory 最终落地的地方依旧是这些文件本身。 默认情况下， open klo 会把这些记忆写到工作区的 memory 目录下面，以年月日这样的方式去存储长期记忆则是沉淀在 memory 点 m d 里。 那官方其实也支持接入 sqlite、 list db 以及像 qmd 这样的增强型解锁后端，但这里一定要注意，它们都不是用来代替 markdown 的， 更多的是承担锁影、解锁、召回这一层的工作。所以你可以简单地把它们理解成三类角色， sqlite 更偏默认的清量级锁影以及状态存储。 list db 更偏向量解锁和羽翼召回。 q m d 则是在解锁层更进一步增强的一种混合解锁方案，它会把 b m 二五向量搜索和 ranking 组合起来，尽可能地把记忆找得更准。所以 markdown 是 记忆本质， circle、 拉斯 d b q m d 这些本质上都是解锁层能力。 也正是因为如此， opencloud 官方的方案优点非常明显，简单、透明、可控。但它的短板也同样清晰，那就是它更像一个基础可用的记忆底座，而不是一套完善成熟的记忆治理系统。在默认方案下，记忆的长期维护更多依赖于 markdown 的 持续写入。 而向量解锁、自动召回、 embedding 配置，这些能力需要额外配置之后才能真正发挥作用。并且就目前来说， opencloud 内置的向量解锁能力本身也有一定的限制，比如它依赖外部大模型 api 提供的 embedding 能力，目前只能配置 openai 和 jimmy。 很多国内用户其实并没有把这条链路真正接起来，而一旦没有接起来， memory 虽然还能工作，但就会退回到最基础的文件读写模式，那这个时候，系统依然会把内容写进 memory 文件夹下的年月日文件作为日常记忆， memory 点 m d 作为长期记忆， 这些文件照样存在，照样可写。只是因为没有 byte 模型，系统无法进行基于向量的语义剪辑和相似召回，更多只能依赖内置的 memory get 这类定向读取具体文件或指定范围内容的方式来获取记忆。换句话说，系统这时仍然能记，但不太会找。 而一旦没有比较强的剪辑能力，问题就会慢慢出现。记忆文件会越积越长，历史内容会越来越多，上下文 tock 消耗也会越来越快，用得越久，你越觉得 agent 变笨了。 因为大模型本身的上下文窗口是固定的，而 memory 如果只是不断累积，没有智力，最终就会从资产变成负的。而关键的是，在这种基础方向里，我们通常没有真正意义上的清洗、压缩、分层、失效和冲突消解机制。记忆会不断累积，但缺乏有效智力。时间一长，优化 memory 几乎成为一个必然需求。 但这件事情也不能一概而论， memory 策略没有绝对最优，只有是否适合当前场景。本地部署更关注隐私可控和低成本， 那云部署更看重接入速度和跨端统一。个人助手则更强调个性化与长期偏好。记忆团队 agent 或者是多 agent 协助，他会更看重权限隔离。项目级上下文既污染控制以及整体的可维护性。也正因为侧重点不同，不同场景下适合的 memory 方案往往也并不相同， 所以到目前为止，这个方向其实并没有一个统一稳定、所有人都认可的标准答案。大多数时候，大家还是需要根据自己的需求、资源条件和技术能力去做适合自己的取舍。 homecloud 的 记忆增强大体可以分成两层，第一层是剪缩增强，也就是让 agent 更容易找到相关的记忆。这部分典型代表就是官方默认的 sqlite 剪缩、可选的 sqlite 向量剪缩以及进一步增强的 qmd 混合剪缩。 那这其中 sqlite 更适合轻量级默认可用的本地锁影场景。 sql 更适合做 in binding、 向量存储和域域召回。 qmd 则是更强的混合剪缩方案，它通常以本地 start 进程执行，再把结果交给大模型做 ranking， 也就是二次重排。这里的大模型 random 可以 把它理解成前面，尽量多召回一些可能相关的内容，后面再让大模型重新判断哪几条和当前问题最相关，把它们排到更前面。 所以 qmd 的 价值主要体现在，当记忆很多，认知很多、表述又不统一的时候，它能明显提升召回精度和解锁质量。但也要明确一点， qmd 解决的是怎么找的更准的问题，不是怎么把记忆管理的更好的问题， 也就说它的强化是剪缩层，而不是记忆治理层。如果底层还是无组织的 markdown 文件，那么事实变了，依然可能直接覆盖知识写进去了，也未必经过结构化整理。那长期下来，知识是否真正能沉淀成稳定可赋用的 memory 资产， 是取决于你上层怎么治理。第二层才是记忆治理增强，也就是在能找到的基础上，进一步解决怎么记记什么、怎么压缩、怎么氧化、怎么避免污染这些问题。这部分常见的思路大体可以分成几类，第一类，单文件增强。最直观的方式就是通过各种策略，把重要的信息都不断追加到 memory 点 m d 里。 这种方案的优点非常明显，简单直接，几乎没有额外的系统复杂度。你不需要引入新的数据库、解锁服务或者是后台进程，只需要让模型持续地往 memory 点 m d 里面写就行。但问题也同样明显，随着时间的推移， memory 点 m d 会越来越长，文件不断膨胀，信息密度也越来越低，查找的效率也会越来越差。 第二类，自动记忆管理。那第二种思路是做一套自动记忆管理机制，比如通过定时任务，每隔一次 session transcript 自动提取大模型认为重要的记忆内容， 然后按天进行定时压缩归档，持续维护到 memory 点 m d， 减少人工的干预。那这种方案比起单纯追加文件更进一步，因为它开始尝试怎么解决记忆越来越多怎么办的问题，而不是让系统能记住，还开始试图让系统自动整理记忆。但 这套方案的问题在于，我们其实很难知道它到底记住了什么，以及为什么记住这些内容。因为重要这件事本身是由大模型来判断的，而大模型判断的重要性未必和人真正关心的重要性一致， 哪些该保留，哪些该忽略，很多时候并不好对齐。那另外，这类方案常见的时间线压缩方式，比如按天、按周去归等，虽然可以控制体积，但也会带来另外一个问题，事实变化的历史容易被抹平。 举个例子，一个项目原本是进行中，后来变成已完成，在压缩归档之后，旧的状态可能直接被覆盖掉。最后你看到的是一个更新后的结论，但中间是怎么变化过来的？这段过程信息可能已经丢了。第三类是日制流加上剪索增强。那第三种思路是依赖每日的日制，再加上 memory search， 然后再配合更强的剪索后端来工作。 这种做法的核心很简单，每天持续的写日制，把记忆沉淀在日制流里，真正需要的时候，再通过 memory search 去做剪索，把相关内容找出来。 如果只是默认解锁，这更像一种可搜索的流水账。但如果配上 l s d b 或 q m d， 体验会好很多，因为搜索会更准，召回也会更稳定。它的优点是实现简单，维护成本低，几乎不需要额外的治理策略。 你只需要保证日制的持续写入解锁链路就能跑起来，整个系统就能工作。但它的问题在于，这依然不是一个真正结构化的埋木尔系统。随着日制的不断累积，搜索结果里的噪音会越来越多，相关性也会越来越不稳定。 同一个事实可能分散在几十个不同日期的日制文件中，模型每次都要从这些零散的片段里面重新拼装上下文，这样既浪费 talkin， 也难以形成稳定的知识沉淀。所以这种方案虽然能用，但更适合清亮场景，不太适合长期高密度、需要持续服用的知识系统。 那第四类是外接完整的记忆系统，那再往上走，就是把 open cloud memory 增强做成一个独立的系统，或者直接接入第三方平台。最省事的一类做法就是直接集成第三方平台提供的商业 memory 方案，比如 my machine、 open cloud super memory 这类项目， 本质上就是把 memory 的 存储、召回、管理这些能力外包出去。他们的优点是接入快，上手简单，但代价通常是依赖外部平台，灵活性和口控性相对有限。而如果不走商业平台路线，社区里也有一些重型的增强方案， 比如结构化抽取、分层记忆、长期生命周期管理，甚至是主动式记忆系统。这类方案的能力更强，但接入和维护成本也更高，更适合那些已经明确要把 openclaw 做成长期运行的 a 政策系统的人。比如 memory labs db pro 这个项目就很不错，大家有兴趣的话可以去尝试一下。那如果有更好的方案，也可以评论去分享一下。 ok？ 在 了解了概念之后，我们应该怎么处理自己的 openclaw 的 时候，其实并不清楚自己真正需要的是什么， 你是想做一个本地的个人助手，还是想做一个长期运行的 agent？ 你 更在意隐私成本还是召回效果进行上线？这些问题如果一开始都没有想清楚，那你过早的去折腾 memory， 最后大概率只是在增加记忆系统的复杂度。 所以在这个阶段，你只需要先意识到 memory 确实是个问题，但不用着急，现在就把它彻底解决。对大多数人来说，先用 opencloud 默认的 markdown 策略做基础处理其实就已经够了，先跑起来，先用起来， 先观察自己的实际使用过程中到底会遇到什么样的问题，这是比一上来就追求高级记忆架构更重要的事情。等到什么时候，你真正开始觉得你的瞎子变傻了，记不住了，照回不准了，上下文越来越贵了，那时候再回来处理这个问题反而是更合理的。 因为这个阶段你已经不是在想象问题，而是在面对真实问题。你会更清楚自己到底缺的是更强的解锁能力，更好的记忆治理，更低的 top 肯消耗，还是多 agent 多场景下的隔离能力。 到了那个时候，你再根据自己的需求，参考前面提到的几类思路，去找到对应的开源项目，逐步尝试优化和治理自己的 memory 系统，会更具针对性。这其实是一个很正常的学习路径，先用默认方案建立认知，再在真实问题里逐步升级，而不是一开始就试图设计出一个完美的记忆系统。 而且说实话，现在这个阶段想一开始就把 open cloud memory 做的非常完善，本身也不太现实。因为目前不管是官方方案还是社区里的各种增强路线，都谈不上稳定统一，没有明显的缺陷。 到目前为止，我还没有看到一个真正能够让所有场景都满意的通用优质方案。很多方案都能解决一部分问题，但同时也会带来新的成本和新的复杂度。所以与其一开始就幻想把这件事一次做对，不如接受一个更现实的结论，慢慢也是一个随着使用过程逐步治理的问题，而不是安装 open class 就 能彻底定型的问题。 当然，从更底层的角度来讲，哪怕你把 mac 策略设计的再漂亮，也依然避不开一个根本限制。大模型的上下文长度始终是硬约束。也就是说，很多所谓的记忆增强，本质上都是在有限的上下文窗口里，尽量让系统记得更准一点，找的更快一点，浪费的更少一点。它能改善体验，但是很难彻底消灭限制本身。 ok？ 朋友们，如果你看到这里还没有放弃，那么看起来你是想认真玩一下 opencloud， 那 这种情况下，每个工作区的备份将必不可少。这是为了防止你悉心呵护的瞎子突然发疯干掉了自己，或者是某些改动不想要了，你想回滚？ ok， 备份的方案也很简单，走 github 备份。首先为了安全，无论你有没有 github 账号，我都建议大家注册一个新的 github 账号。我们直接打开 github， 点 com， 然后点击注册一个新的账号，这个流程比较简单，我就不说了。那账号注册好之后，我们就可以回到这台服务器的终端操作面板，运行一行命令来生成这台机器的 s s h k， 注意这里的邮箱要换成自己 get up 的 邮箱，一路回车就行。 ok， 运行命令，我们查看一下公告内容，我们先把输出的这行公告全部复制下来， 然后回到 gethelp， 点击右上角的头像，点击 settings， 然后在左侧选中 ssh， 点击新增一个 sshk， 粘贴进去，给一个名字创建。 配置好了之后，我们点击 github 导航栏右侧的加号，选择创建一个新的存储库，那这个仓库其实就对应了一个工作区，所以这个名字我们以工作区名命名。那前面的 r n 三是我这台服务器的缩写，因为我在多台服务器部署了 opencloud， 加上服务器代号更清晰一点。后面的 man work space 代表默认的 agent 工作区， 当然你想叫啥都行，但是我建议有意义一点，不然后面工作区搞多了不好找。还需要注意的一点是，我们这里要选择私有， 这样你的这个项目就只有你私人可见了。点击创建，这是一个空的项目，创建完成之后就会自动跳转到项目页面，我们切换到 s s h， 然后把这个仓库地址复制一下，当然下面这个绑定以及推送的命令我们也复制一下，后面会有用。然后我们回到这台服务器的终端控制面板，来配置一下全区的 get 用户名和邮箱。 配置用户名配置邮箱，注意这里的用户名就写 github 注册的账户名，邮箱就写 github 的 账户邮箱即可。配置完成之后，我们输入命令检查一下， 那这样就配置好了，我们直接回到 web ui， 给瞎子发一条消息，让它绑定并且推送。注意一定要选择 men 这个 agent， 因为我们目前配置的是 men 这个 agent 的 工作区备份，直接输入提示词，那这里的命令就是我们刚刚在 gitup 复制的命令。直接回车， ok， 这样就已经推送好了。我们回到 github 刷新一下页面， ok， 可以 看到工作区已经同步过来了，我们还需要给工作区配置一下，让它每轮修改后都提交代码并推送远程。像这样的固定流程，可以直接加到 agent 点 m d 文件中，那如果你不会写，也不知道要加到哪个文件里，你就可以这样问，直接给瞎子发送一段提示词回车， ok， 等它执行完提示词，就帮我们追加到了 agent 点 m d 文件里，那由于改了文件，这次变更它依然会帮我们提交到 git 仓库，到这里我们的工作区备份就做好了。后续如果你的工作区被删除干净了，或者需要迁移， 直接把仓库地址给到 opencloud， 让它恢复就好。 opencloud 的 每个 agent 执行过程中的持久化产物都会放在工作区，所以你可以随时在 github 仓库在线查看你的工作区文件内容， 甚至也可以直接在 github 在 线修改你的工作区文件，然后提交，那提交后给 opencloud 对 应的 agent 发消息，让他拉取一下最新代码，就可以直接应用了。修改工作区文件是不需要重启网关的，那我们有几个工作区就创建几个仓库即可，这里我就不重复了。工作区的这份 agents 的 md 文件建议大家有时间的话，就一定要看看 大家在安装的过程中有什么问题，或者是有什么花里胡哨的报错，可以直接发送给 ai 去问。我们实操的过程中，你会发现，有些是去服务器中的面板自己操作指令，有些时候也会在 opencloud 的 机器人聊天窗口上的操作。那为什么不全都让 opencloud 自己运行安装或者修改配置呢？原因有几点， 第一，有些命令他自己也跑不了，权限太高也不安全。第二，他的系统提示词太长，执行起来有点慢，还不如问外部的 ai， 然后自己去执行，更速度一点。 三、我们在做的是一个高度自制的 a 证的系统，如果我们完全不熟悉，是玩不起来这个 a 证的系统的。所以这个边界在哪儿？我的看法是涉及到一些 skill 安装或者是工作区目录下的内容，编辑可以给到 opencloud 去做，但涉及到系统层面的，哪怕可以让 opencloud 去改， 你也得知道它具体是改了啥，不然挂了你都不知道怎么解决。还有一个操作是直接在服务器上安装一个 cloudcode， 让 cloudcode 作为外部 ai 工具介入去修改配置文件，降低我们的操作复杂度，甚至可以创建一个专门用于编程的 opencloud 机器人， 但让这个机器人操作 cloud code 去完成编程任务，而不是他自己去完成编程任务。因为 cloud code 是 一个干净稳定的 ai 编程 agent， 是 一个非常优秀的 ai 编程产品。 ok， 本期视频到这里就结束了，真的是啰嗦了太多东西，原本我是不想录这期视频的，虽然我也是一直在有用 open cloud， 但由于上不了生产，对我来说它更像是一个学习样本，一个玩具， 互联网真的把它吹的天花乱坠。那最近估计你又会看到大量的第一批跟风体验 open club 的 人的反馈，一定有很多人态度转变，开始吐槽他，真的是很无语。所以大家要理性看待这件事情。 ok， 感谢大家的观看，相关的文档可以在评论区或者是私信找我要。那觉得不错可以参联。谢谢大家，下期再见。