文章深入探讨了 Moltbot 的核心定位及其与传统 AI 聊天工具的区别，强调其作为“本地执行助手”而非单纯对话工具的属性。作者详细记录了在 macOS 环境下的实战步骤：从基础环境搭建、CLI 安装、模型授权（ChatGPT OAuth），到飞书侧的应用创建、权限配置（提供关键 JSON 脚本）及长连接订阅。文章重点演示了如何通过飞书指令唤起本地应用（如 ToDesk），并总结了该方案在替代重复点击、触发固定流程及个人习惯自动化方面的应用场景。最后，作者也提醒了此类高权限工具在安全性和 Token 消耗方面的潜在风险。
简单认识一下 Clawdbot
大家好，我是卡卡。最近 AI 圈被一款名为 Clawdbot 的产品刷屏了，这几天不管是在国内技术社区，还是我晚上没事刷 TG、X 的时候，几乎都能看到有人在讨论它。
看了一下官方文档，Clawdbot 本质上就是一个偏“个人智能助手”的东西，只不过它不是单独开一个网页给我们用，而是可以直接接入我们平时常用的聊天软件，比如 WhatsApp、Telegram、Discord、Slack、Signal，甚至 iMessage，都可以当作它的交互入口。
真正让技术圈开始认真看待它的，其实是这种使用方式：AI 不跑在某个平台上，而是跑在我们自己的环境里，可以是本地电脑，也可以是个人服务器；我们和它的交互，还是通过熟悉的聊天工具，就像跟一个同事发消息一样；在权限允许的情况下，它可以直接操作文件、执行命令，长期记住上下文，变成一个真正属于我们的 AI 助手；而相关数据也都掌握在我们自己手里，不需要交给第三方平台托管。
Clawdbot 和我们常用的 AI 聊天工具有什么不一样？
我第一次安装后在CLI工具里面用 Clawdbot 的时候，其实很容易产生一种错觉：
感觉这不就是换了个聊天框在用 Claude / GPT 吗？
不管是在终端里，还是后面接到飞书、Telegram，输入一句话、等 AI 回复，体验上和 Claude、ChatGPT、豆包、DeepSeek 这些聊天工具确实很像啊。
但真正用下来会发现，两者的定位其实不一样。我们平时用的这些 AI，更像是对话型工具，比如我们问问题、写文案、查资料，用完这一轮基本就结束了；而 Clawdbot 更像是把 AI 变成了一个长期在线、能干活的助手。它不是跑在某个平台的聊天页面里，而是直接跑在我们自己的环境中，可以在权限允许的情况下操作文件、执行命令、记住长期上下文，再通过聊天软件把结果反馈给我们。
所以表面上看是在聊天，本质上其实是在通过聊天工具远程指挥一个跑在自己环境里的 AI，这也是它和 Claude、GPT 这类纯聊天产品最大的区别。
Clawdbot 和 Moltbot 是什么关系
还有一个很多人一开始都会困惑的点：
为什么有的地方叫 Clawdbot，有的地方又变成了 Moltbot？
实际上简单了解一下就会知道这并不是两个项目，也不是重写了一套代码，而是同一个项目在近期做了一次命名调整。最早项目对外叫 Clawdbot，后来改成了 Moltbot，主要是出于品牌和命名上的原因；但在具体使用时，我们会发现核心 CLI、运行时以及很多命令里，仍然保留着 Clawdbot 这个名字。
所以在安装和配置过程中，同时看到 Moltbot 和 Clawdbot 是一件很正常的事情，可以简单理解为：Moltbot 是现在对外的项目名称，Clawdbot 仍然是内部和工具层面的实际名字。这一点如果不提前说明，第一次上手时确实很容易让人产生困惑。
关于 Clawdbot 的一些风险考虑
在继续往下折腾之前，我还是简单考虑了一下 Clawdbot 这类工具本身带来的风险。
Clawdbot 需要运行在本地电脑或服务器上，并且在实际使用中会涉及文件读写、命令执行等操作，这决定了它并不是一个只聊天、不碰系统的工具。
从工程角度来看，只要涉及到较高权限，就不可避免会有安全层面的顾虑，比如配置是否足够隔离、代码是否完全可控，以及长期运行在一台机器上的影响等问题。这些点目前我自己也还在了解过程中，并没有形成特别成熟的判断。
基于这些考虑，我目前的使用方式还是比较保守：只在个人环境中搭建，用来体验功能和验证流程；在工程实践或生产环境中，暂时不打算直接引入这一套方案。这个使用角度方面大家结合自己的情况自行考虑哈。
安装环境说明
接下来就开始安装了。因为我平时一直用的是 Mac，所以这次的安装过程也是基于 macOS 来记录的。
至于 Windows 或者直接在云服务器上的安装方式，我这边没有逐一去测试，整体思路是一样的，细节差异大家可以参考其他文章，已经有不少写得很详细了。
在正式安装之前，需要先准备好运行环境。Clawdbot / Moltbot 是基于 Node.js 的工具，所以本地需要提前安装好 Node 环境，版本不要太老即可，正常使用官方的 Node LTS 基本都没问题。如果这一步没装，后面执行安装脚本时会直接报错。
另外再强调一次哈，如果有些同学只是想体验功能、熟悉流程，其实不一定非要在我们自己主力电脑上折腾的。更稳妥的方式是单独买一台测试用的 VPS 或轻量服务器来跑，当作一个隔离的实验环境，用起来也会更安心一些。
可选方案说明
如果有同学觉得从环境准备到一步步执行命令还是有点麻烦，其实也可以试试阿里云这边提供的 Clawdbot 一键安装方案。
阿里云已经把基础环境和安装流程打包好了，整体更偏向“开箱即用”，适合只是想快速体验一下的同学。相关入口在这里： 一键部署
不过这篇文章里，我还是选择手动安装的方式来记录，一方面流程更清楚，另一方面也方便后面自己排查问题。如果只是图省事，一键安装也是一个可以考虑的选择。
安装 Moltbot
环境准备好之后，安装过程本身反而很简单，直接使用官方提供的安装脚本即可，一条命令就能完成基础安 装：
curl -fsSL https://molt.bot/install.sh | bash
这个脚本会自动完成 CLI 的下载和基础配置，安装完成后就可以使用
clawdbot相关命令继续后面的初始化和配置流程。
如果是第一次安装，过程会稍微慢一点，中间看起来像是卡住了，其实是在下载和初始化依赖，等它跑完就行。 当脚本执行完成后，终端里会自动进入 Clawdbot（现在也叫 Moltbot）的初始化引导界面: 
首先出现的就是这个安全确认提示。大概意思是：Clawdbot 属于权限比较高的 AI Agent，后面可能会涉及本地命令、文件读写等操作，官方在这里提前提醒存在一定风险，需要我们确认是否继续。
如果只是像本文一样做本地测试、体验功能、后面接入飞书聊天，这里直接选择 Yes 即可，继续后面的配置流程。
接下来是初始化方式的选择，这里有 QuickStart 和 Manual 两种模式。
QuickStart 相当于帮我们先用一套默认、安全的配置把 Clawdbot 跑起来，后面的模型、渠道、权限等都可以再单独调整；Manual 则是从一开始就自己一项一项配置，步骤会多一些。
为了先把流程跑通，这里我们直接选择 QuickStart 即可。 
接下来会进入模型和鉴权方式的选择，这里可以看到支持的模型非常多，包括 OpenAI、Qwen、MiniMax、Google、Copilot 等。
因为 Clawdbot 是一个常驻的 AI 助手，随时可能被调用，实际使用过程中对 token 的消耗会比较明显，所以如果只是长期挂着用，选择一些 免费或成本较低的模型（比如通义千问这一类）其实也完全没问题。
我这边本身有 ChatGPT Plus，主要也是为了体验 OpenAI 这条链路，所以这里直接选择了 OpenAI 作为模型来源。 
这里我选择OpenAI后 我选择OpenAI Codex 来进行ChatGPT OAuth授权
选中后会弹出提示使用ChatGPT 登录到Codex确认页面。
我们点击继续后 会弹出授权成功，然后我们复制地址栏回调地址到我们的命令窗口
这里我们在命令窗口黏贴我们上面授权成功的回调地址后就成了，然后就是选择使用哪个模型，这里我是保持使用gpt-5.2
接下来是聊天渠道的选择，Clawdbot 默认支持的渠道非常多，包括 Telegram、WhatsApp、Discord、Slack 等。
因为本文后面会单独介绍 飞书（Lark） 的配置方式，而飞书并不在这个 QuickStart 列表里，所以这里我们先不选择任何聊天渠道，直接选最下面的 Skip for now，先把基础环境跑起来，后续再手动配置飞书即可。 
接下来会询问是否要现在配置 Skills（技能）。这里可以理解为一些额外的自动化能力和扩展功能，但并不是安装和基础聊天所必需的内容。
为了先把整体流程跑通、减少干扰，这里我们直接选择 No，后面如果有需要，再单独开启和配置即可。 
接下来是 Hooks 的配置，这里主要是一些用于自动化的小钩子，比如在特定指令触发时自动记录会话、保存上下文之类的功能。
这些能力对后续深度使用会比较有帮助，但并不是基础聊天或接入飞书所必需的内容。为了先把主流程走完，这里我们同样选择 Skip for now，然后按空格键确认。后面有需要再单独开启即可。 
最后会询问以哪种方式启动（hatch）这个 bot，这里提供了终端交互（TUI）、Web 界面以及稍后再说三种方式。
因为我们接下来还要继续做飞书相关的配置，不急着马上启动交互界面，所以这里直接选择 Do this later，先完成初始化流程，后续需要用的时候再手动启动即可。 
安装完成后，可以通过下面这个命令查看 Clawdbot 当前的运行状态：
clawdbot status
执行后会看到一份状态汇总信息，主要用来确认几件事：
服务是否已经正常启动、本地 Gateway 有没有跑起来、Dashboard 是否可以访问，以及当前使用的模型和会话状态。
如果像我这样能看到本地 127.0.0.1 的 Dashboard 地址，并且状态显示为 running，基本就说明安装和初始化都是正常的，可以继续往下折腾了。
接下来我们简单测试一下 Clawdbot 是否真的已经跑起来了。
直接在终端里执行：
clawdbot tui
会进入一个类似聊天窗口的界面，随便输入一句话或者一个简单指令。如果像上图这样能够正常收到回复，说明 Clawdbot 已经可以正常工作了，整个安装和基础配置也算完成。 
到这里为止，其实我们已经有了一个能对话、能响应的本地 AI 助手，后面要做的事情，就是把它接入到飞书里，用聊天的方式来用它。
飞书侧准备：创建企业自建应用
接下来我们开始配置飞书相关流程。
第一步，先到飞书开放平台创建一个应用。
打开飞书开放平台：open.feishu.cn/app
进入后，切换到 「企业自建应用」 页面，点击 「创建企业自建应用」。
这里创建的是企业内部使用的应用，刚好符合我们把 Clawdbot 接入飞书做个人/团队助手的场景。 
创建好企业自建应用后，进入应用详情页，在 「凭证与基础信息」 页面中，就可以看到应用的 AppID 和 AppSecret。
这两个值是后面 Clawdbot 接入飞书时必须用到的身份凭证，记得先复制保存好，不要泄露给其他人。
接下来我们会把这两个参数配置到 Clawdbot 中，用来完成飞书侧的身份校验。
安装并配置 Clawdbot 飞书插件
前面飞书应用已经创建好，也拿到了 AppID 和 AppSecret，接下来我们就可以开始配置 Clawdbot 这边了。
安装飞书插件
首先安装 Clawdbot 的飞书插件，直接执行下面这条命令即可：
clawdbot plugins install @m1heng-clawd/feishu
安装过程如果没有报错，基本就说明插件已经就位了。 
配置飞书应用信息
接下来把刚才在飞书后台拿到的 AppID 和 AppSecret 配置到 Clawdbot 中：
clawdbot config set channels.feishu.appId "你的AppID"
clawdbot config set channels.feishu.appSecret "你的AppSecret"
然后启用飞书这个 channel：
clawdbot config set channels.feishu.enabled true
上面的配置修改完成后，需要重启一次 Gateway 才会真正生效：
clawdbot gateway restart
到这里，Clawdbot 这一侧的飞书插件就算配置完成了，后面只需要在飞书里验证消息是否能正常收发即可。
如何确认飞书已经配置成功？
飞书插件配置完成并重启 Gateway 之后，我们需要确认 Clawdbot 这边是否已经成功连上飞书。
最直接的方式就是查看实时日志。
在终端执行下面这条命令：
clawdbot logs --follow
如果日志中能看到类似下面这样的内容（如图所示）： 
说明 Clawdbot 已经成功启动了飞书通道，并且通过 WebSocket 长连接 等待飞书事件回调。
这一步出现这些日志，就可以基本确认：
Clawdbot 这一侧的飞书配置是 OK 的
接下来要做的，就是回到 飞书开放平台，继续配置应用权限、事件订阅等内容，让飞书真正把消息推送过来。
在飞书开放平台配置应用权限
前面 Clawdbot 和飞书插件我们已经跑起来了，但这一步非常关键：
不配置权限，机器人是收不到消息、也发不了消息的。
下面我们回到 飞书开放平台 → 当前应用 → 权限管理。 
使用 JSON 批量导入权限
在权限管理页面，点击 「批量导入/导出权限」，选择 JSON 导入，把下面这段配置完整粘贴进去：
{
"scopes": {
"tenant": [
"im:message.group_msg",
"im:message.p2p_msg:readonly",
"im:message.reactions:read",
"im:message:readonly",
"im:message:recall",
"im:message:send_as_bot",
"im:message:update",
"im:resource",
"contact:user.base:readonly",
"contact:contact.base:readonly"
],
"user": [
"docx:document:readonly"
]
}
}
这些权限是干什么用的
简单说一下我们这些到底给了机器人什么能力：
-
消息相关
- 读取群聊和单聊消息
- 以机器人的身份发送消息
- 更新、撤回消息
- 读取消息里的表情、图片、文件等资源
-
事件相关
- 接收群聊中 @ 机器人的事件（这是机器人能被“叫醒”的关键）
-
通讯录相关
- 获取用户和通讯录的基础信息
-
文档相关
- 读取用户的飞书文档（后面做文章流、内容处理会用到）
这些权限基本是「能正常做一个飞书机器人」的最低配置。
确认并导入权限配置
前面把权限 JSON 粘贴进去之后，点击 「下一步，确认新增权限」 就可以了。
我们会看到一个确认页，如图所示，列出了这次新增的权限列表。这里主要确认两点就行：
- 应用身份权限里，消息、通讯录、资源相关的权限都在
- 用户身份权限里，有文档只读权限
如果这些都在，直接点 「申请开通」。
这时候页面顶部一般会提示一句话：
应用发布后，当前配置方可生效
这个不用慌，是飞书的正常流程。意思是：
- 权限已经配置成功
- 但还没有真正生效
- 需要后面 创建版本并发布应用，权限才会下发给这个应用
所以到这里为止，权限配置这一步就算完成了。
配置飞书事件（接收消息）
接下来需要配置飞书的事件回调。
在飞书开放平台里，进入左侧的「事件与回调」页面，先做事件配置。
订阅方式这里选择 使用长连接接收事件，这个方式不需要额外配置回调地址，和 Clawdbot 的工作方式是匹配的。选好之后直接点击保存。 
保存完成后，点击下面的「添加事件」按钮，在事件列表里找到 接收消息，勾选这一项，然后确认添加。
做到这一步，飞书在有人给机器人发消息时，就会把事件通过长连接推送给 Clawdbot，后面我们才能正常接收和处理消息。
发布应用
前面的权限和事件都配置完成后，最后一步就是发布应用。
在左侧进入「版本管理与发布」，点击创建版本，填写版本号和更新说明。
移动端和桌面端的默认能力都选择「机器人」，保持默认即可。 
确认信息无误后，直接提交并发布。
如果页面提示“本次发布免审核，提交发布后即可上线使用”，说明这是企业自建应用，发布完成后权限和事件会立刻生效。
到这里，飞书侧的配置就全部完成了，机器人已经可以正常接收和回复消息了。
测试飞书聊天是否正常
应用发布完成后，我们回到飞书客户端，直接和刚创建的机器人私聊即可。 
像图里这样，给机器人发一条普通消息，如果机器人能够正常回复，说明三件事都已经生效了：
- 飞书应用已经成功发布
- 事件订阅（接收消息）配置正确
- Clawdbot 本地服务和飞书通道已经连通
只要能正常对话，说明整个飞书接入流程已经跑通，后面就可以开始接具体的自动化流程或业务逻辑了。
如果把这一步拆开来看，其实就是一条很简单的链路： 消息从飞书进来，交给 Clawdbot，再由 Clawdbot 去操作本地环境。 我们用一张简单的示意图会更直观一些：
测试 Clawdbot 的本地自动化能力
前面只是确认机器人能不能聊天，这一步我们来真正测一下 Clawdbot 能干什么。
在飞书聊天窗口里，直接对机器人输入一条指令，比如：
帮我打开 ToDesk 远程工具
如果配置正常，Clawdbot 会在本地自动执行这个动作，我们会看到 Mac 上的 ToDesk 应用被直接唤起，就像我们自己点开了一样。 
这个测试主要是为了确认两件事：
- 飞书消息已经能正确传到本地的 Clawdbot
- Clawdbot 已经具备执行本地指令、控制电脑的能力
只要这一步能跑通，后面不管是打开应用、执行脚本，还是做更复杂的自动化流程，本质上都是在这个基础上往上叠功能。
那这个东西到底能干什么？
前面我们已经试过了，一句话就能把本地的 ToDesk 打开。
看到这里，其实就能大概明白 Clawdbot 的定位了。
它不是用来聊天的，而是用来接管一些日常操作的。
从使用场景上看，我觉得大概可以分成几类。
第一类，是替代重复点击。
像打开某个软件、进入固定网站、启动一套常用工具，这些每天都会做，但又不值得专门写脚本的事情，都可以直接用一句话完成。
第二类，是固定流程的触发器。
平时有一整套顺序操作，比如连远程、起服务、看状态，不需要一步一步点，只要一句指令，剩下的交给它执行。
第三类，是个人习惯型操作。
有些动作只有自己知道，比如写东西前、下班前、排查问题时的一套固定操作，这些不通用，但很适合交给 Clawdbot记住。
整体来看，它更像是一个听得懂人话、又能真的去做事的工具。
不是回答问题，而是接收指令、执行动作。
也正因为这样，前面才需要配置插件、权限和事件。
这些都准备好之后，Clawdbot 才真正“进到系统里”。
写在最后
到这里，Clawdbot 加飞书的整个流程我们基本就跑通了。
从下载安装到权限、事件配置，再到能在飞书里发消息、在本地执行操作，整体体验还是比较顺的。
需要注意的一点是，这种常驻型的 AI 助手，对模型调用是持续发生的，不像平时在网页里偶尔问几句。
如果接入的是按量计费的模型，实际使用时还是要留意一下 token 消耗，避免后台一直跑着却没注意到费用变化。
目前我这边更多还是把它当成个人助手来用，在自己可控的环境里慢慢试，先摸清楚边界和成本，再决定要不要接到更正式的场景里。
整体来看，这套东西更适合愿意折腾、也清楚自己在干什么的人。
至于值不值得上，还是看自己的使用习惯和场景哈。