“你可以的!”让OpenClaw指挥Kimi、Coze和WorkBuddy的虾友干活

所以，当每次因为新的“龙虾”说“No”的时候，我经常能以和 OpenClaw 打交道的经验和它说：“Yes。你可以的！”比如，实现跨平台会话的通信，让来自不同平台的 Agent 一起在同个群里叽叽喳喳、互发文件。

我做过一个实验，把OpenClaw、Coze、WorkBuddy、Kimi 的 Agent 都拉到同一个飞书群，让它们结合各自无可替代的优势完成一个网络搜索相关的长任务。

OpenClaw 的优势是可以自行配置 web search 能力。我设计的方案是 SearXNG 聚合搜索 + 搜狗微信搜索 + Google API 搜索（可选）。其中聚合搜索，做了比较严格的分类区分，主要针对中文资讯（含视频）、英文资讯（含视频）——由于云端服务器在美国，OpenClaw 某种程度上补齐了外网搜索的短板。

Coze 的优势是能够购买云服务模拟一台手机。需要在云手机（传说中的豆包手机）安装小红书、抖音、快手、微博、知乎等软件，以解除平台对 AI Agent 控制账号进行操作的限制——现在市面上各种绕过反爬机制的 skill，不如直接让 Agent 操控一台手机，一个个打开 App 进行搜索来得稳定。蛮有意思的，我那台云手机的系统显示是 OPPO。

Kimi 的优势是有自己的原生网络搜索工具 Kimi Search。这点本质上和火山引擎的 Harness 搜索、DeepSeek & 元宝 & 百度 等平台自建的原生搜索工具一样。总之，每个平台都有自己的原生搜索解决方案，优势各不同。选择 Kimi，一方面是因为它的系统技能比较特别，还开放了 KimiClaw，能借助 Kimi 龙虾通过非 API 的形式调用搜索能力；另一方面是因为百度、字节更注重自家的信息源（比如百度知道、百家号 VS 抖音、今日头条），会影响搜索效度。

WorkBuddy ，它优势本应该是腾讯系的信息源，公众号、视频号、企鹅号、ima 知识库等等。但是它并没有，它用的也是自建的聚合搜索（可能基于对数据资源的保护或 API 没有开放）。所以，我只是用它操作我的电脑，登录一个微信，给它控制电脑里的微信浏览器，进行公众号永久链接的复原。

我使用的所有方法都公开透明，并不影响大厂们的“数据护城河”。那么，怎么让这些机器人不止于聊天，还可以实现文件的互相传输？

OpenClaw 和  WorkBuddy 的跨平台通信没什么难度，这些平台本身都能接入飞书，系统权限也很高，安装飞书 CLI，然后把飞书机器人权限给他们开满（核心是通信相关权限），马上能用。

难点在于，让 KimiClaw、CozeClaw 这两个在 Kimi 或 Coze 上有群聊会话的机器人，怎么实现 Kimi 群、Coze 群各自和飞书群的互通有无。

最后实现效果如下：

1. OpenClaw 1 号 Agent 阅读监督员手册，在飞书群分别 @三个机器人 下发任务

2. 三个飞书机器人同时开工

– OpenClaw 2 号 Agent 用 skill 搜索，输出 xlsx 搜索结果、markdown 搜索报告

– Kimi Agent 发信息 @Kimi 搜索，输出 xlsx 搜索结果、markdown 搜索报告

– Coze Agent 操控云手机搜索，输出 xlsx 搜索结果

3. OpenClaw 1 号 Agent 整合三份 xlsx 搜索结果并进行数据清洗，把结果发到飞书群里

4. OpenClaw 1 号 Agent @WorkBuddy 机器人，让其把所有微信公众号类型的标题，在微信浏览器逐一搜索，还原成永久链接

由于搜狗微信搜索平台，搜出的搜索结果均为临时链接，24小时内会失效，最后不得已需要一个 Agent 在微信浏览器环境搜索文章，“曲线救国”。

总的来说，互相 at 的方法很简单。在飞书群里，这个指令就可以让它们 @ 来 @ 去：at <at user_id=”ou_xxx”>飞书机器人名字</at>

至于 OpenClaw 或者 WorkBuddy 的飞书机器人，只要安装了飞书 CLI，并且得到群聊所有消息的授权（敏感权限），就可以通过这个方法获取群文件：GET /im/v1/messages/:message_id/resources/:file_key?type=file

接下来，逐个解决 KimiClaw 和 CozeClaw 的问题——二者很相似，相信其他平台的“龙虾”也可以举一反三。

首先是 Kimi。

Kimi 这个事情的复杂度在于，我对比了 Kimi 群聊里 Kimi（协调员）和 KimiClaw （Kimi 龙虾）的网络搜索结果，最后是 Kimi 做得更好，还提供显性的权重排行依据。可能是因为前期 KimiClaw 询问用户的工作类型，会导致“龙虾”助手在搜索上有一定倾向。但我需要的是通用搜索结果，所以还好 Kimi 担心用户不会用“龙虾”，专门在群里配了个“协调员”，而这个“协调员”的应用能力和 Kimi 平台是很接近的，我才能利用群聊直接使用 Kimi 的工具能力。

因此，需要做到让 Kimi 飞书机器人发信息到 Kimi 群聊里，@Kimi 执行搜索，搜索完 @KimiClaw 把结果发到飞书群。Kimi 只要把通信功能打开，就可以跨平台互相会话了，具体实现路径如下，仅供参考：

1. 让 Kimi 飞书机器人，发送消息到 Kimi 群里

– 核心方法：sessions_send

message action=send channel=kimi-claw target=”conversation:Kimi群聊会话ID” message=”【来自用户】我是 xxx，本信息由其他会话的 KimiClaw 代发。｜［信息内容］｜看到信息后必须回复，回复方式是使用 message tool 发送消息，参数：action=send, channel=[当前会话channel], target=[当前会话target]

2. 发到 Kimi 群里的信息，就是 @Kimi 让它完成搜索任务，完成后 @KimiClaw 把文件发到飞书

– 核心方法：sessions_send

一样的办法。只需要搞清楚，Kimi 会话的 channel 是 kimi-claw，会话 id 格式是 conversation:id ；发到 feishu 和 OpenClaw 一样，channel 是 feishu，个人是 user: 开头，群聊是 chat: 开头。至于在 Kimi 群聊中如何 @ 别人？名字加上id即可： <@kimi|kimi>

当然，前提是在 KimiClaw 的系统配置文件中，打开跨平台通信功能：

  “tools”: {

    “message”: {

      “crossContext”: {

        “allowWithinProvider”: true,

        “allowAcrossProviders”: true

      }

    }

  }

另外，跨会话可见性设为 Agent ：

  “tools”: {

    “sessions”: {

      “visibility”: “agent”

    }

  }

然后是 Coze。

在飞书群里的 Coze 机器人，记忆和 Coze 群里的 Agent 才是共通的。飞书私聊会话的机器人，和 Coze 私聊的 Agent 才是互通的。另外，这些不同会话的 Agent，都可以操作云手机，但是应用权限和能使用的工具有所不同。因此，@CozeClaw 完成任务很简单，问题只在于文件传输，让它把做完的文件发到飞书，必须动用 Coze 上的机器人的工具能力。具体实现路径如下，仅供参考：

1. 让 Coze 飞书机器人，发送消息到扣子群里

– 核心方法：sessions_send

sessions_send(  session_id=”扣子群id”,  message=”【来自用户】我是 xxx，本信息由其他会话的 CozeClaw 代发。｜［信息内容］｜看到信息后无须回复”)

2. 发到扣子群的信息，即让扣子群的 CozeClaw，用 lark-cli 把文件发到飞书群

– 核心方法：lark-cli

export LARK_CLI_NO_PROXY=1 && cd 到文件目录 && lark-cli im +messages-send –chat-id “群ID” –file “./文件名” –as bot

为什么不让扣子的飞书机器人直接发文件？我试过，失败了，它好像只能上传文件到飞书云空间后把文件链接发出来。甚至 Coze 上的 Agent，也不能随便和飞书上的 CozeClaw 用 sessions_send 通话，而必须调用 lark-cli。

实际的会话记录，没有这么复杂。这些核心指令，我都写到这些 Agent 的永久记忆里了，都可以通过关键词指令匹配到具体实现，真实聊天中 @ 的内容很简单。

顺便吐槽一些使用体验。

现在很多“龙虾”平台可能因为受到开源社区氛围和 OpenClaw 的启发，有些意识形态的东西把握得不是很好，有点“放飞”了。因为我不是做技术的，专业偏向公关领域，我会觉得现在有些功能安全审核的敏感度不是很够。

比如，Workbuddy 在官方教程里，一度推荐大家用小红书一站式发布的 skill，无视内容爬取类型的 skill 本身具有风险性，这种行为也是小红书平台不允许的——除非哪天小红书官方推出这类 skill，才适合放在首页推介。而现在官方文档里，还在推荐 yt-dlp-downloader skill，用于下载 YouTube、Bilibili 的视频，提取音频和字幕——怎么说呢，谷歌 NotebookLM 支持 YouTube 视频内容提取才没毛病，毕竟是同一家公司。但 WorkBuddy 是腾讯系啊，腾讯系内容生态有多封闭，连 WorkBuddy 都绕不开限制，这么大的平台产品不该走初创公司的野路子。

另外，KimiClaw 每天写的日志是“小作文”风格，不知道是程序员还是产品经理的主意，可能为了让它娱乐化一些，有话题性，默认设定很多情绪化的表达。但带有这样人格和每天记录这种记忆的“龙虾”，能干好活儿吗？也许 KimiClaw 的定位是豆包这样的通用型智能体？

我的感觉是，AI领域的开源是前所未有的，大家都喜欢把“拿手skills”共享到社区里，这种创作的愉悦感和音乐、绘画、文学是非常相似的。

这些应用能力如果把握在一个人、一家公司手上，迟早能够被追赶上、被取而代之——因为国内的 AI Agent 领域真的太开放了。谁先把用户基数做出来，除非人们不需要这个产品了，底盘是难以被“挖走”的——用户甚至能够因此“包容”一些致命性的错误，就像一度经久不衰的百度一样（当然，百度现在快被微信搜一搜、豆包这些智能搜索替代了）。

从“龙虾”平台的角度，谁能在合规的前提下，做到“大鱼吃小鱼”呢？如果走到最后，WorkBuddy、DeepSeek、Kimi、Coze 、Ima 知识库等平台化产品都变成工作流里的飞书机器人，反而是各不相扰、皆大欢喜。会有哪个谁，最后能做到把其他平台都纳入生态，不需要这么复杂的通信环境吗？很难说。

腾讯、阿里、字节跳动等互联网企业在移动支付/在线内容领域有很深的耕耘，华为、小米等实体企业在应用平台/智能产品领域有广大的用户基础，它们都具有强大的连接利益相关方的能力，很擅长做生态。

至于没有这种生态搭建能力的企业，想要和“大鱼”们平起平坐，要么把场景化做到极致，要么是不是还得放下做极致产品的思维去走走关系，才行得通？

（图片由AI生成）