molili多agent设置教程

先说结论，我创建了一个可以自动添加 agent 的 skill， 一 句话就能添加 agent 并且绑定飞书机器人，有需要的小伙伴请点赞关注视频，后面我会提供下载链接和操作方法。大家好，今天这期视频的内容 主要介绍如何让 openclaw 接入飞书，如何申请飞书机器人，然后创建特定的 agent 与之绑定， 如何通过主 agent 调动多个 agent 的 共同写作。这个是我在飞书上建立的 open core 使用文档，以后我会定期在这里分享一些实际操作资料和学习资料，可以方便大家学习。 这篇文档是手动接入飞书并实现多自媒体写作，和接入微信的流程是一样的。首先需要安装飞书插件，即在终端执行这行命令，安装完成后选择新建飞书机器人， 然后使用飞书 app 扫描二维码就绑定成功了。然后可以使用飞书机器人来跟 openclock 进行对话。这里有一些高级配置指令，比如切换到流式输出、设置多任务运行及独立上下文， 这些是常用的诊断命令和问题修复方法。可以在聊天窗口发出飞书 start 指令， 确认是否安装成功，发出飞书 off 指令来批量完成用户的授权。接入飞书以后，可以直接通过跟机器人聊天来完成很多飞书中的操作，比如整理群聊内容、 查看创建日程、读取修改云文档、创建会议机要。又或者把数据账单发送给飞出机器人，让他帮你创建多维表格进行记录。现在说一下当 a 检测的利弊，优点是架构简单，调试容易，适合早期阶段，但随着使用轮次的增加，其能力 也会越来越臃肿，上下文会越来越长，核心系统的题词会不断增加，调用的工具也会越来越多，逻辑越来越复杂，最后就变成 什么都能干，但什么都不精。所有的绘画记录，所有的工具调用 skills 都会加载到一个 agent 的 上下文，就会导致 token 消耗太多，任务执行缓慢且容易失败。什么是多 agent 呢？ 你可以理解为把一个当 agent 变成一个团队，团队里面有项目经理、数据爬取专家、文案编辑专家、全案全站工程师等等，每个 agent 只做好一件事，这样带来的第一个优点就是专业化，每个 agent 配置独立的工作空间，有不同的访问策略，独立的职责描述、性格特点，可以使用不同的模型绑定不同的工具，历史绘画隔离，这样可以大大提升工作效率。第二个优点 是可扩展，你可以随时添加新的 agent， 比如添加一个财务分析 agent， 添加一个图像生成 agent 并不会影响其他 agent， 并且可以规划不同 agent 之间的协助。实际应用当中， 我们可以采用一个飞书机器人绑定一个 openclock agent 策略，每个飞书机器人独立管理，互不干扰，使用独立的路由， 独立的绘画，可以灵活控制，并且也可以让主 agent 来调用其他 agent 完成多个 agent 之间的协助。现在来介绍一下整个流程主要分为两步，第一步创建一个飞书机器人，需要访问这个链接，得到 app id 和 app secret。 接下来就是配置 opencloud 的 接收文件，配置路径如下，主要配置的有下面几个部分，一个是 agent list 的 部分，这是主 agent， 这是我添加的数据抓取 agent、 项目经理 agent、 全站工程师 agent。 每个 agent 都有独立的工作空间，并且可以设置不同的模型，这一块呢是工具权限的配置， agent 和 agent 之间可以进行通信， 这个是多账号绘画隔离设置，这个是飞猪的 channel 配置，需要在这里配置 app id 和 app secret 以及 agent 的 名称。这个是飞猪机器人的 open id， 这里是路由绑定 设置，这里是 cloud 中 agent id， 现在是一一对应，可以将如下规则写写入到你的记忆文档中去。为了让主 agent 可以 调度下面三个 agent， 这里需要配备这样一个设置。第 sub agent 允许的 agent 的 id 有 如下几个，这里主要是为了实现主 agent 调动其他 agent。 下面是一个数据抓取 agent 的 一个 through， 参考 主要包括身份、性格、工作原则、表达方式、用户关系边界和目标。这是一个 demo， 其他的 agent 都可以按照这个结构来编辑它的售。 下面我来实际操作一下，这个是我的主 agent， 然后我又分别创建了文案编辑、项目经理、数据抓取和全站工程师这四个 agent。 然后我们还可以继续添加 agent， 我 来实际操作一下， 可以看出手动去配置这些节省文件还是挺复杂的，因此我自己创建了一个可以自动添加 agent 的 skill， 然后通过这个 skill， 我 们可以快速的让 ai 来帮我们配置这些文件。那么我来操作一下。首先第一步创建飞速机器人， 我们可以点击这个网站，比如说我想创建一个财务经理啊，财务分析， 财务分析的机器人，这时候它就会帮你创建一个飞出机器人，然后生成这个 app id 和 app secret， 我 们可以把这个复制过来，先复制这块，这是我写的 skill。 好， 我们已经明白了，这个叫财务飞行的 agent 需要我们添加 app id 和 app secret， 就 把刚才这里申请到的飞出机器人的 app id 拷贝给它。 啊，还需要进行职责描述。 现在 ai 就 可以自动按照我编写的 skill 来帮我们创建这个 agent， 并绑定飞出机器人，它会自动重启 openclock， 所以 有时候你会提醒一下它，这里需要打开私聊跟这个机器人 说一声，发送一个消息，就可以获取这个机器人下面的 open id 了。我们这里打开，打开应用财务分析，打开应用，你好，已经发送消息。 好，现在他应应该是更新配置更新成功了，再检查一下， 他已经接收到了我的消息了，然后他就会回复了。好，说明这个机器人跟这个新的 agent 已经绑定。 新的财务分析的机器人已经跟 openclock 中的新的 agent 已经绑定了，并且可以进行消息的回复。现在我们来测试一下，让主 agent 来调用这几个啊子 agent， 现在，好，现在主 agent 已经可以跟财务分析的绘画已经生成了，得到了筛选 key， 这样的话主 agent 就 可以以后调用这个 财务分析的 agent， 并且它已经把小财这个筛选 key 更新到记忆里面，现在我们来测试一下。 好，这就完成了，由主 a 检测通知财务分析，这个 a 检测去做一个工资表，然后我们看一下是不是做出来了。好，这做出来了，这我们还可以做的更复杂一些，比如啊，我们可以让让项目经理， 然后让权杖工程师编写单。 好，现在让我们来弄一个更复杂一点的，让多 a 级的协助，让项目经理来规划一个前端页面项目，用来显示这个工资表格，然后让全站工程师来编辑代码，看一看他能不能完成 好。项目经理的方案已经完成，全站工程师正在编码中。好，可以看到这个工资页面也已经开发完成了，然后我们远程看一下这个前端的页面员工工资表，员工工资明细说明这个全站工程师已经完成页面的开发。 好的，我们总结一下今天的内容啊，今天主要就介绍这个接入飞书并实现多次人体的协助。然后我这边是在编写了一个 skill， 可以 直接通过这个 skill 来 创建一个 a 卷的，并绑定这个飞书机器人，我会把这个资料放在这个评论区啊，有需要的小伙伴可以自己来取。好的，今天的内容就到这里，我们下期见，关注我 ai， 分享时尚技巧，我们下期见。

我花了一个月的时间，终于开发完成，跑通了多 agent 的 长城任务协助流程这套东西叫 team manager。 今天我把核心机制一次性讲清楚。二零二六年硅谷有个词特别火， harness engineering， 说白了就是给 ai 搭环境。有人把 ai 当聊天工具，聊完就散。有人给 ai 配上工作台工具反馈机制，让它真正干活，差距就在这个环境上。 team manager 就是 给多 agent 协助搭的一套专业 harness。 传统方案是单 a 镇扛，所有任务越做越乱。我们设计了四种角色，总助理理解、需求管理者拆解任务执行者、产出成果审核者把关质量角色分工明确，协助流程自动流转，你只跟总助理说话，剩下的全部自动运转。长城任务最大的问题是什么？上下轮爆炸， ai 记不住那么多东西， 走着走着就忘了。我们用了一个很直接的办法，成果务流转，每个节点产出的东西全部文件化，需求文档、执行计划阶段、成果审核记录。 ai 不 依赖模糊的记忆，而是聚焦当前任务和明确的问题。这是 harness 里最关键的一环，把重要的东西写下来，存到文件系统，需要的时候再读取。 搭建 agent 团队很简单，拖一界面，上下回车就能创建角色，指定角色类型、所属部门、绑定岗位，不用写代码， 不用改配置文件，跟着提示一步步选就行。想加一个游戏开发 agent， 十秒钟搞定。每个 agent 可以 一键绑定飞书 bot， 任务分配、审核请求完成通知，全部自动推送到群聊，你在群里就能看到每个 agent 的 进度，不用到处找消息。渠道配置也是一行命令， 每个执行者可以绑定专属技能包，教育规划 agent 调用搜索能力调研学习方案设计 agent 调用浏览器和动画开发 agent 调用代码执行， 让每个 agent 在 他的领域里更专业。单点任务有专长，整体协助不堆叠。举个例子，我想给两岁半的女儿做一个 ai 学习小游戏，这是一个真正的长城复杂任务，从学习方案设计到素材制作、动画特效需求文档产品原型代码开发、部署上线，整个链条跨了好几个专业领域，我以前一个人搞不了， 现在交给 team manager。 我 跟总助理说需求，他把这个任务拆成七个阶段，教育顾问 agent 先调研幼儿认知发展规律，输出一份学习方案。需求 agent 把方案转成产品需求文档产品 agent 设计游戏交互原型素材 agent 生成卡通角色和场景图， 动画 agent 制作交互动效开发 agent 实现游戏逻辑并部署。最后审核 agent 验收功能完整性，每个阶段产出成果文件。下一阶段 agent 读取上一阶段的成果继续干活。四个小时后，一个真正能玩的幼儿学习游戏上线了。我只说了一句话，全程自动流转， 成果全程可追溯。这就是 harness engineering 在 多 agent 协助里的落地。复杂任务以前是 ai 的 软肋，记不住，干不完，质量飘。现在用 team manager， 角色分工清晰， 成果文件流转，技能精准绑定 harness 搭好了，多一阵才能真正干活。这就是我花一个月打磨的东西，希望能帮你搭出自己的 ai 团队。

今天跟大家分享一下如何使用 open core 去设定一个多 agent 的 一个模式。首先呢，我们会通过这条命令去添加一个新的 agent， 那 这个名字是根据我们实际需要进行填写的，像我这边需要去 专门弄一个编程专家，那我就会给他起一个叫 call 点。执行这条命令之后，我们会给这个 agent 单独配一个工作空间，就是每个 agent 的 它的工作空间是独立的，它是互不干扰的。 那接下来会给他配一个模型，我这边先用的一个模型进行一个测试，然后接下来就会给它配一个通道，那我这边是采用飞速的方式进行接入的，配置完之后，他在一整台这边就会多了一个叫 call 点了，那除了主规划之外，就是我们这个 call 点就是我们新增的一个 a 整台， 然后在 open curl 的 这个配置文件里面，它这边也会新增相关的配置，然后在这边那 agent 它这边有个，它这边有个 list， 那 这边有个主绘画的一个 agent， 那 这个 call 点是我们新增的一个 agent， 那 配置完之后我们就要去设定这个 agent， agent 一个人格，那我我这边会通过 ai 的 方式来进行一个输出，这个这部分就不用我们自己去设定了，我们就提出我们需求，让它进行一个修改就可以了。 那我这边的提示词是这样写的，我会让他去艾特这篇文章，然后让他了解就是每个 agent 需要 包含的有哪些内容。那这篇文章是在这个网站这边去的，就是每个 agent 它有包含了几个文件，像 agent 点 md， 其实一些操作指令告诉 ai 应该怎么做，那 so 点 md 就是 ai 的 一个 灵魂。告诉 ai 他 是谁？ user 就是 我们用户，我们自己用户是谁？ i don't care 是 ai 的 一些基本身份， toos 是 一些工具，就是 ai 使用的一些 skill。 那 may may 点 d 是 一些长期需要记忆的，那然后下面有一篇的目录，这个是用来做短期记忆的，每天都会做一个总结。 那这边都有介绍每部分需要编辑的规则是怎样的。那我们看一下我们这边 ai 帮我们实现怎么样呢？ 那他就会给出这个基本身份是名字叫 cloud code， 资深前端的软件工程师， ai 助手。前端啊，即 open core， 它的一个定位是把需求变成可维护、可测试的交互。一个软件部分都是 ai 帮我们生成的。那我们来看下一个文件，这个是 ai 的 灵魂， 那现在我们看下一个就是它的 agent， 我 们继续 那用户的画像，说的就是我，我看一下，这个可能比较重要，这是为了更好的写作，不是为了收集隐私，不要记入敏感信息。那基本信息，我叫 oliver， 那 时间就是北京时间， 这是心跳的一个轨迹，周期性的一个工作，我们不需要心跳检查，把本电流空气的起动时保持最小，以免脱口干纹。我们先这样弄，然后要在人格里想画出来，就主要要记住这样 看一下，然后这个 让他再调整一个版本，我们采用飞书测试一下，我们来问一下他，你好，你是谁？我这个需要授权一下。 好像没起来哦，我们重启一下服务，我刚开始可能忘记重启了，再重启一下。 ok， 我 们再测试一下 哦，感受到配置完那个 agent 之后，需要那个重启一下服务。 那另外关于这几个这几个文件的一个介绍，我们在这个网站这边是有个详细的介绍，就是打造 ai 的 一个人格，它有介绍工工作空间一些文件的作用，大家有需要的话可以私信我，我分享给大家，今天分享到这边，谢谢大家。

看看我的 agent 团队们，有写图文的、网站运营的、监控金价的、记账的，还有提供情绪价值的，后面还要增加一个视频剪辑的 open cloud 小 龙虾 用上多 agent 的 模式了吗？但像我这样每个 agent 对 应一个机器人的配置是有点广泛。在飞书上其实有一种更简单的方式，就是通过拉群，实现一个机器人多个 agent 多个群聊分别管理的模式。我们来以选择题、写作和神稿三个事情为例，完整的配置一遍， 一共三个步骤。首先用这样的命令创建多个 agent， 分 别负责不同的工作，然后给每个 agent 的 职责拉一个飞书群，并且把我们的唯一的这一个 飞书机器人添加到群里面。接着把每一个群聊和 agent 绑定起来，在这里查看群的 id， 通过这样的 bindings 配置把两者映设起来。最后不要忘记给飞书 channel 增加这两张配置，开放群聊和群聊中，不需要艾特机器人也能回复。 配置完成之后，在各个群里和 agent 对 话，给他们安排好职责和身份，让他们记录下来，你就可以在不同的群里指挥不同的员工工作了。像这样的流程，先选择题再写作，审稿，审完再改， 最后得到一篇完整的内容就可以发布了。这样做配置简单，效果强大，快来把你的 agent 军团也安排起来吧！关注我，带你玩转 open club！

今天又写了一个项目啊，就是可以可量化的啊，管理我们的 agent， 大家看一下 啊，我们可以在这里设置进行设置啊，然后它的一个看板，有什么 agent 啊，然后有什么流程啊，分工啊， 都能看清楚。然后这个是一个组织架构啊，你可以看到你这一个，你看我们下面有不同的啊，一些 agent 的 这个协助的组别，可以看一下，对吧？这两个，然后这七个啊， agent 的 协助，然后这个也是这个关系一列的比较清楚。 ok， 然后我们再看， ok， 然后这里，然后你可以用自然语言去描述啊，去创建一个团队，对吧？大家觉得觉得这个喜欢吗？这个功能，然后最后就是这个任务编排啊，最终 这个大体上是可以运转起来了，就还有一些小的啊，需要修复一下。来大家大家持续关注我吧，到时候会把这个系统啊开源出来给大家使用的。

自从我 cloud code 被封了以后，我基本上就用 codex 作为我的主力了。最近 codex 出的这个多 agent 方式 我觉得还挺好的。你看现在我就让他有五个 agent 一 起在并行地开发。那你需要在提示词当中明确地告诉他，请用多 agent 的 方式去开发。 我觉得紫 a 证的可以这么去使用，比如说我现在要改一个产品的 landing page， 就是 它的首页，我告诉他说我要跟竞品拉开差距，然后你去调研一下竞品怎么设计的， reddit 上面去看一下用户的真实反馈，同时 你再去看一下我现在怎么设计的，那他就会给我创建三个子 a 阵的，分别做这三件事情。他把结果汇总之后，给我一个最终的结论，怎么去改，让他们各自并行的处理不同的任务，最后汇总在一块。

这条视频我们用五分钟把 open core 多 agent 的 最小可用方案讲透，目标很明确，第一，知道多个 agent 的 怎么隔离部署， 第二，知道消息怎么稳定路由。第三，知道两个 agent 怎么开始协助你第一次上手，别一开始就做三层专家组。最稳的起点就是一个主控 agent 加一个执行 agent。 正式配多 agent 的 之前，先把环境起好，先用 on board 把 gateway 服务装起来， 然后用 gateway status 确认它在运行，再打开 dashboard 看配置是否能正常加载。如果你要把不同账号分给不同 agent， 就 先把频道账号登录好，比如一个 personal， 一个 base， 只有当 get 位正常，面板正常，频道账号也正常的时候，后面写的 bindings 才有意义。 do agent 最关键的第一步不是写 prompt， 而是目录隔离。最少要拆三个东西， workspace 要独立， agent 的 要独立， sessions 也要独立。因为每个 agent 都有自己的身份文件，自己的绘画历史，自己的工作资料。 如果你附用了同一个 agent， 最常见的结果就是认证串调，角色串调，绘画也串调。 agent 创建出来以后，别只停留在名字，至少要给每个 agent 写清楚两类信息， agent 点 md 定义职责边界， so 点 md 定义语气优先级和工作风格。比如 home 负责清亮聊天和提醒， work 负责项目执行， review 只负责复合。这样后面即便三个 agent 同时存在，也不会出现谁都想接手同一件事。接下来是 bindings， 它作用很简单，消息进来以后到底交给哪个 agent？ opencloud 的 路由是确定性的， 而且越具体的规则，优先级越高。如果你写到了单个联系人或者单个群这种 peer 级规则，优先级最高，再往下才是 account channel 通配，最后才是默认 agent。 所以 你想做精准分流，优先写具体匹配， 不要只靠默认。实际落地时，建议你先按账号分流，比如 personal 进 home business 进 work， 然后如果某个群或者某个联系人需要单独处理，再用 p 尔规则覆盖，最后保留一个默认 agent 兜底。这样配的好处是基础分流稳定，重点对象又能单独接到更专业的 agent。 消息已经送对以后才轮到协助。 openclo 的 多 agent 写作本质上是跨 session 工作，最常用的能力有四个， 看绘画、读历史、发消息、启智任务。其中 sessions send 适合主控把任务交给执行， sessions spawn 适合开一个独立子任务去后台跑。 另外要记住， session 可见性和通信权限不是一回事，能看到不代表能互发。第一次做多 agent， 最稳的协助顺序是先单向再双向，也就是先让主控 agent 把任务发给执行 agent， 执行完把结果收回来。如果你一开始就让两个 agent 互相自动回复，最容易出现的是死循环。绘画、串线 或者一个小问题被放大成无限对话。所以最小配置里先把 allow 写清楚，再把 sessions 的 visibility 放到 all， 先跑通 home to work， 再扩。第三个 review。 配置写完以后不要直接上真实业务，先做验证。 第一步，指测 routine 确认， personal 指进 home， 壁纸指进 work。 第二步，再测一次 sessions send， 让主控发一个简单任务给执行 agent， 看结果能不能收回来。 第三步，最后才加 review 或者自动往返，如果出问题，先看 get 尾状态，再看深度状态，再看 house 和日字。日字里重点看消息到底进了谁，以及绘画 key 有 没有串，最后收个尾。 do agent 想跑稳你只要记住六件事， 目录独立，职责清楚，先按账号分流，再按对象覆盖。先单向斜坐，再双向 allow， 只给必要的 agent， 每次只加一个变量，并且用日制验证。 多 agent 的 本质不是模型越多越强，而是路由清除，协助清除，验证清除。做到这一步，你在网上扩散角色，专家组才不会失控。

今天给大家介绍一下 cloud code 里面原生自带的两种多 agent 协同的两种方式啊，一个叫 sub agent， 一个叫 agent team， 然后我也会说明为什么这两种方式在某些业务场景下，它没有办法解决多 agent 的 协同的问题。然后啊，为此我自己做了一套 agent 的 写作流程， 能够很好的解决这两个问题。对，首先首先介绍一下啊， cloud code 自带的两种 agent 写作的方式吧。第一种叫做 sub agent 的 词代理， 子代理，就是当你跟 agent， 当你跟 cloud code 会对话的时候，这个主会话，他在完成你的任务的过程中，可以去派发一个子代理帮他去啊，完成他这个任务里面比较边缘的那一部分事项 啊，然后子代理把这个事项完成之后，得到一个执行的结果和招标，把这个招标返回一个主代理，主代理拿到这个招标之后，就可以把他的工作重心聚焦在你给他的这个任务里面比较核心的那个部分，这就是子代理的实现方式。 那他的启动方式也很简单，就是你直接在绘画里面在跟主代理对话的过程中显示的声明，像这样的声明说 啊，帮我启动一个或者多个子代理，或者具体多少个帮我去做一件什么样的事情，然后它就会自动地去启动子代理，帮帮他去做了啊。然后第二个 cloud code 的 原生自带的就是 agent team， agent team 呢，其实就是你在绘画中也是在跟主代理的这个绘画的过程中显示的声明说你想要拉起一个 agent team， 然后去帮你做一件什么样的事情，解决一个什么问题。比如说你要做一个网站，那这是一个比较大的需求， 你可以让他拉起一个 agent team， 这个 team 里面你去定义成员，有产品经理，有程序员，有 u i 设计师，有测试啊，这几个角色，他们分别的角色定义他们的职责，他们的工作流程， 然后让 cloud code 去组织他们帮你把这个网页做出来。啊，那这两个模式他有什么问题呢？或者说他有什么缺点呢？ 啊？我觉得在业务实现上是有两个比较大的痛点的。第一个就是不管是 sub agent 的 子代理还是 agent team 里面的这个成员代理，他都没有办法，他们的绘画都是无法回溯的， 这就意味着你没有办法去看到他们的推理过程和他们的思考过程，你只能看到他们的一个结果，那当你对这个结果不满意的时候，你很难去 通过绘画，通过 session， 通过这个 agent 的 他的一个思考过程来判断到底是哪里有什么问题，怎么去优化它，我觉得这是在业务上是一个比较大的问题。然后第二个问题就是 不管是 sub agent 还是 agent team， 他 设计的初衷都是为了去解决一个任务，这个任务就是你在主绘画里面给 cloud code 抛出的那个任务，或者让他要解决的那个问题 啊。但是在很多业务场景下啊，我们更多需要的是一个重复性的去执行一个任务的能力， 那比如说我今天要，今天要玩，今天要做这件事情，明天也要做，那这种事情其实就不适合 sub agent 的， 或者 agent team 去合作去去完成。 那为了解决解决这两个问题，我自己设计的这套多 agent 的 协同的方案，我觉得是能够比较好的解决这两个问题的。首先就是你我们可以在这个 agent 里面去定义你需要的这个 agent 的 的角色， 他的身份，他的定义，他的工作流程啊，甚至是说他的 skill 有 哪些。 然后第一个问题怎么解决呢？就是你直接进入到这个 agent 的 文件里面，然后去启动 cloud， 那 你你其实就等于在一个新的绘画里面启动了这个 agent， 那 这个 agent 你 让他做任务的过程，他的思考过程，他的推理过程， 都是通过可以通过 cloud resume 的 方式去啊回溯的。对，那那这样的话你就可以知道 你的他的任务执行过程中有遇到什么问题，那你可以直接的在绘画里面让他去解决，比如说优化他的 skill， 优化他的工作流，优化他的身份设定，优化你的 prompt 等等 啊，来来达到来让这个 agent 的 这个执行的交付质量是更好的，符合你的业务预期的。 然后关于第二个问题，就是当我们的这个工作流程，工作流打磨的比较好了的时候，每个每个 agent 它的输出质量都已经不错了的时候，那你就可以直接通过定时任务的方式 啊，进入这些文件夹，然后驱动这些 a 帧的工作，这样的话你的整个工作流程，整个流水线就是可以一直重复的去产出结果的。 对，这样的话就解决了第二个问题就是啊原啊 cloud code 的 原声自带的两种多 a 帧的写作方式，它 都是为一次性的任务去服务的，那这样的架构其实就可以啊，不停的去驱动每每一个代理为你工作，然后不断的去重复性的产出 结果，并且这些结果因为你已经打磨好了他们的工作流程，他们的 skill， 那 他们产出的结果大概率也是符合你的业务预期的，这样的话就是他的工作结果既是好的，并且他又可以不断的重复的为你工作。

六十秒教会你为 openclaw 配置多 agent 写作如果你在使用单 agent 时常常遇到以下问题，那么将智能划分能够使问题得到显著改善。为实现多 agent 写作，我们会进行这两步操作。 首先我们来进行第一步，打开终端，运行 openclaw agents add， 跟随你想设定的 agent 名输入指令，然后进入引导配置， 看到这里提示配置完成。第二步，我们来配置 a 卷间的通信能力。在 opencloud 的 主配置文件 choose 下面补上这两段配置， 或者直接将这段提示词发给你的 a 卷，让其帮助配置修改成功。我们重启 get 位，至此配置完成。我们来测试一下 我这里在 a 卷面中，让其将新闻整理工作分发给 a 卷 news。 我 们看到这里提示委托成功。 切换到 aj news， 可以 看到一条来自 aj man 的 消息，并且已经启动了工作。稍等片刻后， aj news 提示我们工作完成。随后打开它的工作区，可以看到工作成果已经整理。在此 至此，你已掌握多维犬之间的协助方式，利用它的强大能力打造专属于你的龙虾集群。

嘿，这里是罐头，几天不见，罐头又来给大家带来新的干货了，之前给大家分享了一期呃用飞书呢，使用群聊的方式，然后连接 opencloud 多 agent， 然后来建一个自己的一个 ai 团队。 这个视频呢得到大家的一些广泛讨论和支持啊，大家都在评论区底下问了好多问题，然后大家也互相的帮忙解决问题，我觉得这种氛围非常好。然后今天的话啊，我给大家带来一期最新的一个玩法，也就是我们不用使用群聊的方式去管理， 我们现在要使用多个机器人的方式，让每一个机器人都对应自己的，让每一个机器人都对应 opencloud 的 一个 agent， 这样的话我们就非常的直白，符合直在做，然后现在我只做了三个机器人，然后你可以看到 我们之前的那种形式，使用群聊的形式是什么样的呢？哎，它这里就是一个群聊， 然后这是群聊的名字，这是头像，然后如果是机器人的话， ok， 它后面有个机器人的标志，所以这就是我们今天要完成的事情，就是把所有的我们之前的一些群聊的一些 agent， 都变成使用机器人的 agent 来完成一对一的效果。 为什么我们不使用群聊去管理多个 agent 呢？因为听大家反馈呃，一是群聊对于呃我们普通人来说的话，它比较有门槛，因为可能有些人反馈，比如说呃不知道该怎么绑定 agent， 使用 hr agent 去做 a agent 创建的时候呢，可能有些问题，这个的话门槛比较高，虽然官头给大家提供了呃官头自己的一个 hr agent 的 那个配置文档，但是还是有 小伙伴会反馈啊，好像还是不太行。嗯，然后另一个就是回复的时候有有可能身份混淆在群聊中，然后你艾特那个 agent， 他 可能觉得自己是主 agent 或者是其他的 agent， 但就不是你认为那个 agent， 随之有时候会有些身份 混淆，这可能是消息路由的时候路由到错的 agent 了。然后还有人问啊，怎么不设置艾特就可以回复呢？ 啊？还有人问就是如何设置不用艾特就可以回复呢？嗯，这个的话也是你需要去做一个配置，然后也比较麻烦， 然后当然罐头也回复了很多句了哈，然后你如果还不知道的话，可以去翻大家的评论，罐头有回复的。然后还有就是有有小伙伴说拿不到群聊的 id， 然后这些都是一些问题哈，也就是群聊对对大家来说的话是一个比较有门槛的东西，然后也不是那么直觉。 所以说今天给大家带来一期机器人和 agent 一 对一的一个方式，并且群聊还有下面这几个局限性， 也就是你的群聊中，哎，机器人的名称都是一样的，比如说我这个招聘 hr， 这个大姐头，嗯，这个群聊邀请的实际上还是关头助手，这个这个机器人，所以它是一个我的一个主 agent， 也就是这个关头助手在不同的群聊中去扮演了不同的角色，来达到 多 agent 的 效果，所以它机器人名称都是一样的。然后就是机器人流逝输出的局限性，因为流逝输出的话，现在只支持和机器人私聊，我们上期视频给大家讲过如何去配置机器人的流逝输出，所以但是在群聊当中的话，它现在是不支持的。 然后另一个是不能配置快捷指令，你可以看到呃，我们使用机器人的话，都可以在这里面哎去加一些快捷指令，然后让他帮我们去直接去执行一些东西，而不用我们自己去 呃给他打字了，这个是可以做到的，只不过是在机器人私聊的界面才行。然后另一个就是你没有办法在一个群聊中邀请多个机器人来同步写作，嗯，这个很很显而易见哈，因为我们只有一个机器人，所以不可能去邀请多个机器人进来的， 所以来说的话，我们今天就要介绍机器人和 agent 一 对一的一个玩法了。首先还是给大家讲一下原理哈，机器人和给 机器人和 agent 一 对一的话，也就是说你用户自己去创建多个机器人，然后每个机器人呢，通过私聊去链接 opencloud 每一个 agent， 也就是说机器人和 agent 呢，是一对一的效果， 然后它优势也很明显，因为你是和机器人私聊，所以你可以给机器人配置独立的菜单和指令来做一些快捷的操作。另一个呢，机器人可以支持卡片流逝输出，然后再一个你可以在一个群里边拉多个机器人啊，这个玩法实际上想象空间非常非常大了，所以这个话 我我决定现在把我所有的群聊方式的机器人管理，群聊方式的 a 阵的管理，全都变成 机器人和 agent 的 一对一。好，我们接下来开始正式来实践了哈，带着大家一步一步来，大家放心，机器人 其实比群聊的方式来管理 agent 要方便了很多，这得益于飞叔官方的大力支持哈。我在文档最上方其实放了官方的一个文档，官方其实有写了一个比较详细的文档呃，去告大家应该怎么去玩， 大家也可以看一下，只不过这个文档实际上太专业了，然后对于普通人来说的话，其实很难去看懂，然后看都看不懂的话，更别说自己去实践了，所以这个其实对于大家来说还是有有门槛的，所以呢，罐头就现在 哎自己去根据这个官方的文档把它做成了一套可附用的 s o p， 然后呢，把它固化成了我们 openclo 的 一个 skill skill 大家应该都知道，也就说你把它给 openclo 装上之后呢， 那他就可以学会这个技能，然后自己去做这些可附用的流程。呃，你用的话，只需要把罐头写的这个 skill 复制一下这个链接，然后使用这句话发给你的 openclaw 就 可以直接安装了。 罐头是实测下来非常好用哈，然后在这里的话就给大家分享支持一下罐头，这样应该三连支持一下罐头应该不过分吧。好好，我们现在开始来实践如何做到机器人和 agent 的 一对一。首先你需要创建一个机器人，那罐头在这里 有一个链接，你直接一点就可以直接跳到创建 openclock 飞速机器人的这个界面，这个界面的话实际上是官方飞速官方自己做的哈， 也就是它为了方便大家使用，它自动帮你去完成了一些权限身份的配置以及一些事件回调，你就不用自己去配了，你你需要做的，只需要你需要做的就是去输入它的名字，选一个头像，点击创建就行。那我们来看一下今天 先让谁去转正呢？我最常用的其实就是这个文案助手，他能帮我去写一些符合不同平台的调性的一些文案，那他现在还是一个群聊的方式吗？对吧？你可以点进来这看一下，这是一个群啊，然后呢 加了一个关头助手这个机器人，那现在咱们就让这个文案助手来转正一下。首先，哎，还是啊机器人的名字，那就叫 真文案助手，也就是他是一个真正机器人了，他不是一个带马甲的了，我们现在还是给他去选一个头像，选一个这个吧。 ok， 我 们现在点创建，在创建过程中。好，现在的话你会在飞书里面收到一个应用的一个审批，我们点进入管理后台审核。 ok， 看到了这个真文案助手，然后点一下审核通过。 ok， 然后我们再回到我们这个刚刚点创建的界面，可以看到它现在有 a p p id 和 p p secret。 现在呢，我们先 记住这个东西哈，因为我们审核发布成功之后，然后需要找到我们刚才安装了罐头的 skill 的 那个 agent， 比如说我之前就是给我们的这个招聘 hr 这个大姐头来安装了这个 skill， 那 现在呢？ 我们往文档往下滑，可以先看一下这个 skill 的 流程哈，使用统一的话术来激活就行。比如说我，比如说我们现在要做的就是把已有的 agent 绑定到飞出机器人，我们直接复制这句话给到我们的这个 招聘 hr 啊，这个招聘 hr 可以 是任何 agent， 只需要安装了这个技能就行，然后把名字改成我们的文案助手，好，等它响应一下， 好，它现在需要你提供一些信息，哎，这些信息的话就是我们刚才已经看到的，在这里先复制一下 app id， 好 把油，好，现在把所有的信息都提供给它。这个路由模式实际上就是专门给机器人去准备的，也就是所有的消息都给 你。刚才创建这个机器人，也就是你跟他私聊的话，你就选这个，如果还是之前那种群聊模式的话，你就选择群聊机就行。 ok， 现在把必要的信息都发给他， 好，在等待一段时间之后呢，他就创建完成了，然后他告诉我们，呃，这个文案助手已经上线了，并且状态也验证通过了。现在呢，我们直接去搜索一下 真文案助手。 ok， 这个就是这个机器人，我从来没跟他聊过，现在我来实测一下他是是不是真的可以回复我，我一般都会用这个来问他，我直接问一下他，哎，立刻就有响应了哈。哎嘿， 还真的是我那个文案助手，并且你可以看到它现在是可以流逝输出的，然后不是像在群里那样子，一大段话写完之后再一次性发给你，那样需要很等很久，它现在是流逝输出，并且呢， 我还可以玩这个什么呢？比如说我可以在管理后台对他进行一个命令的配置，来给大家介绍一下我如何配置命令哈，不用，我们来到开发者后台，然后对于这个真文案助手来到他的这么一个机器人的这个能力这里， 哎，可以直接点这个机器人自定义菜单开启，然后这里就可以你配置很多其他的一些快捷指令之类的，都可以在这配。我的话一般是配一个这个菜单，我比较习惯于让他 每次可以开启，比如说我们现在给他配一个命令，就叫做我先让他列一下所有 skills 吧，我就给大家做一个样例哈， 实际上你可以为为他配任何你想要的东西。 ok， 改完之后呢，你要创建一个版本，好，随便写些东西保存就行了。哎，确认发布一下。好，此时发布成功了，你再回到他这里，就可以看到他已经有一个这个菜单了，点一下 就能执行快捷命令了，是不是非常方便？同理，你还可以给他配各种菜单的命令都行。 ok， 你 看他现在慢慢在列所有的 skills。 好，已经给大家演示完了我如何使用机器人，然后来跟 agent 一 对一进行配置的，然后现在解决什么问题呢？哎，机器人现在名称他都是各式各的了，然后 专门的机器人做专门的事情，然后每个机器人都可以流逝的输出，然后还可以配快捷。接下来我们来测试一下他的群内写作能力。邀请一些机器人进来，比如说把文案助手先邀请进来， 然后再把运维助手邀请进来，再邀请一个天气助手吧，构建一个什么场景呢？我现在想 先让天气助手查一下北京的今日天气，然后他要去查天气了。 ok， 这个天气还是挺好的哈，已已经到春天了，现在我在让文案助手来寄予这个天气，天气很好，帮我写一个春日出游的小作文吧，一千字左右。 哎，现在看一看可不可以让天让文案助手拿到天气助手的消息，然后来做一个处理，哎嘿，你看他已经写好了，然后接下来我们再来一个，我们还是在这里点一下回复，然后再让运维助手 把这个翻译成英文，然后又没助手来做这个事，真的是有些难为他了，看他可不可以吧。好，可以看到他已经把我的这个春日出游记这个中文的这篇小作文 然后翻译成英文了。好，这个就是实际上是可以做到多个机器人，然后连多个 agent 在 一个群里进行协助，比如说先让 a agent 去做一些事情，然后把结果给到 b agent， 然后再这样协助下去，最后统一给你一个结果，这样的话他的想象空间是非常大的， 也就是这种机器人和 agent 的 一对一匹配的方式，是群聊方式的进阶版，所以说大家都可以玩起来吧。 好，这就是关头今天给大家带来的一个飞书多 agent 的 升级版的一个玩法，也就是机器人 agent 的 一对一，不知道大家有没有非常的感兴趣呢？可以大家一起来试一试，还是老规矩，文档的话可以在评论区自取，然后这个 skill 的 话， 罐头也是放在了这里，一个压缩包还是按照这句话发给你的， a 键呢，就可以直接安装了。好的，如果这期视频有帮到你的话，还是希望你能给罐头一个一键三连，罐头会给大家创作更多的干货，我们下期。

我做了个在飞书上养龙虾多 agent 的 技能，只需要先在飞书里建个群，右上角点击设置添加机器人，选择你已经在用的 open cloud 飞书机器人，添加进群组，再打开群聊设置，复制下面的绘画 id， 然后直接跟主 agent 说给这个群新增一个 agent， 就会调用这个技能，引导你一步一步填 agent 叫什么名字，用哪个模型，填完重启 open cloud 就 搞定了。这个 skill 的 思路也很简单，创建 agent 本质上就是调用 open cloud 的 命令，再把配置文件写好，所以他先问你基本信息， agent 叫什么，飞书群绘画 id 是 什么， 用哪个模型，然后自动帮你创建 agent， 关联飞书群，改好配置，最后就是检查确认，整个流程就是这些，并不复杂。这个技能我也放在文档里了，大家可以直接用。期待看到大家都用 agent 做什么，欢迎在评论区讨论，我们下期见。

大家好，这期讲 open call 的 多 agent 模式，简单说就是一个 git 里可以同时跑多个独立的 ai 大 脑，每个大脑有自己的工作区，绘画记录和性格设定，互不干扰。 比如你可以有一个工作 agent， 一个生活 agent， 消息自动路由到对应的那个，非常适合多角色、多场景使用。 搞懂多 agent 要先理解三个核心概念，第一个是 agent id， 就是 每个 agent 的 唯一名字，比如 main work home。 第二个是 account id， 是 渠道账号的名字，比如一个非书账号，一个钉钉账号。 第三个是绑定，就是消息路由，规则决定哪条消息该交给哪个 agent 处理。添加新 agent 只需要一条命令， open call agents add 后面跟你想取的名字，比如 work 或 call 顶。 执行完之后，系统会自动创建独立的工作区目录，初步化搜点 md agents 点 md 等引导文件，还有独立的绘画存储。你可以一次性添加多个 agent， 每个都完全独立。 配置好 agent 之后，还需要告诉 get 位消息该路由到哪里，这就是 bindings 配置。在 open call 点 j s o n 里， bindings 是 一个数组，每条规则指定 agent id 和 match 条件， match 可以 按渠道名、账号 id 甚至具体的群 id 来匹配。匹配规则遵循最具体优先原则，精确到群 id 的 规则比只匹配渠道名的规则优先级更高，没有匹配到任何规则时，消息会回退到默认 agent。 多 agent 有 三种最常见的使用场景，第一种，不同渠道绑不同 agent， 飞书走工作 agent， 钉钉走，个人 agent， 互不干扰。 第二种，单个机器人账号按群路由同一个飞书机器人在技术群里是编程 agent， 在 运营群里是内容 agent， 用户只需要记住一个机器人入口。第三种，多人共用一个 gateway， 每个人对应一个 agent 工作区和对话历史完全隔离。 根据实际需求，有四种配置方案可以选择。方案一是单 agent 多绘画，最简单，适合个人用户。方案二是多 agent 软隔离，每个 agent 有 独立工作区，适合小团队和多角色场景，推荐大多数人用这个 方案三是 docker 沙箱处理敏感数据，使用安全性更高。方案四是多 gateway， 每个 agent 独立进程，适合企业及部署，越往后安全性越高，但复杂度和资源消耗也越大。按需选择， 每个 agent 可以 独立配置沙箱和工具权限。沙箱有三档， off 表示不隔离， none man 指对非主 agent 请沙箱， off 表示所有 agent 都进沙箱。 工具权限通过 allow 和 deny 控制。比如给家庭 agent 的 设置只允许读取工具，禁止执行和写入，这样就算有人恶意构造消息， agent 也没有权限做破坏性操作。 配置完成后，需要重启 gateway， 让改动生效。执行 opencloud gateway restart， 然后用 opencloud agent list 加上 bundins 参数，可以查看所有 agent 和对应的绑定规则是否正确。最后用 opencloud channels status 加 pro， 确认各渠道连接正常， 再对应渠道发一条测试消息，确认路由到了正确的 agent 就 算配置成功了。好了，这期多 agent 模式就讲到这里，记住三个核心， agent， id 是 大脑的名字，绑定是路由规则，最具体的规则优先匹配。 新手从多 agent 软隔离方案开始，用 agents add 命令添加 agent 配置 bundings， 重启 get 维，验证一下就搞定了，下期见。

最近跟着教程上守 skills 的 人越来越多了，从最初的编程任务一路扩展到办公、 ppt 创作等各种场景。今天我们通过一个视频理解 skills 的 核心，避免让 skills 和 mcp 一 样成为摆设。 skills 的 出现源于 entropic 团队在开发 cloud code 的 这类 agenetic 系统时察觉到的一个核心痛点。 agent 虽然具备很强的自主执行能力，但面对特定的专业领域时，缺乏必要的经验和标准化流程。单纯靠 prompt 工程针对每个领域调整提示词，或者依赖昂贵的模型微调，都无法很好地满足实际需求。于是他们推出了可扩展、可移植的 skills， 把领域专业知识封装成技能包，让 agent 能够快速获得专业能力。 它的核心就是一个 skill m 文件，哪怕没有其他脚本和资源，仅靠这一个文件也能驱动整个技能流程运转。它相当于一份给 agent 看的标准化技能说明书。 咱们来看它的结构。最上方是一段简短的原数据，用来定义技能的核心信息，比如技能用途、出发条件、适用场景。 agent 在 出场阶段会将这部分原数据全量加载到系统提示中， 当用户需求匹配到原数据里的描述或关键词时，才会进一步加载下方的具体指令模块。这部分指令包含了完整的执行规则、操作流程、领域专业知识以及输出格式规范。这样一来， agent 就 能照着 skill 的 指令调用工具运行脚本，稳稳生成符合规范的输出。 那么同样是 anthropomorphic 出品， skill 和 m c p 有 什么联系呢？我认为两者更像是互补关系。 m c p 更专注于连接，提供了实时数据和工具相，而 skill 则保证能够正确地去使用它们。两者共同解决了 ai 从 chatbox 到 agent 转变过程的难题，希望对你有帮助。那今天就到这啦，感谢大家。

在之前的视频里边，我不是说会测试那个超长程的任务，然后大概三十个节点，然后发现其实创建这个团队绑定分数这些都简单，最难的是他们 scar 的 这个创建非常痛苦，然后我就先创建了一个 scar 技能创作部，可以看一下，嗯，现在他是有六个有实际工作的执行者是六个，然后给他们发布了一个这个测试任务， 然后创建了一个测试任务，然后目标是一个需求分析师，然后给他提了一些要求，然后在之前就给他们创建了六个每个岗位的一个 scares， 这个这个创建这几个 scares 花了大概四五个小时吧，然后他就去开始执行了，然后分发到了这个技能创作部的管理者， 然后任务流程开始，然后创建了任务分配到了部门，然后就开始做了，然后看一下他们这边的一个沟通过程 啊，第一次，然后审核完成，完成完成节点审核通过，完成完成他自己去做的，然后每个节点的审核都有，然后专属技能包做完了，看一下他的这个结果，就这个在这 啊，在这儿看他身身上的这些文件，有一个 scares， 这个是有些格式的问题，有需求分析师，他要做什么事情，目标有核心的工作流，有使用指南， 使用文档，需求分类框架啊，需求澄清清单、快速评估模板，然后他还有很多的这些模板啊，什么用户场景、方法论，这都是他自己生成的，根据之前给他的 skills 自己生成的，要处理需求变更上下游的这个角色的沟通呀，要需求接收分类，你看他有一堆文档，可以看一下，他的文档都在这有很多各式各样的， 有术语、字典，很多东西啊，就现在它这个整个生成的这个结构其实并不是特别完美啊。你看它的这些文档都比较零散，然后还有些文档里边它是没有内容的， 你看像这个它里边就没有内容，它放错地方了，这个是需要优化一下，这个 scares 有 这个，这个很有意思啊，给你们看一下。嗯，在 你看这个节点是这个 scares 工具开发，然后这个节点的作用是什么？就是会有一些需要脚本的，需要调什么工具的，然后这个节点来负责开发，然后他就评估了，分析了以后需求分析工程师以思维沟通文档为主，脚本自动化体现有价值有限，现有技能包以提供完整模板、方法论这些，因此决定不开发， 然后他就提交审核了，有决策依据，四个场景均不决定开发，然后他同意了， 它自己会判断啊，这些都是在之前给它们创建的 scares 里边会写清楚，让它们自动去分辨，然后其实整体看了一下，就实际的 它这些内容，它这些模板其实都还不错啊，然后现在就是调优，然后把那个优化一下。