微信官宣支持 OpenClaw，但我回不去了
最初听说 OpenClaw 的时候，我的第一反应是：这东西要是能在微信上用就好了。
微信是我用得最多的聊天工具，打开频率最高，消息都在那里。如果 AI 助手能住在微信里，岂不是随时都能用？
但当时微信并不支持。没有官方的 Bot API，社区方案要么不稳定，要么有封号风险。所以我退而求其次，把 OpenClaw 接入了飞书。
然后，事情开始变了。
用了一段时间飞书之后，我慢慢发现，这不是”退而求其次”，而是”误打误撞找对了地方”。飞书给 OpenClaw 提供的不是一个聊天窗口，而是一整套工作环境——文档、表格、日历、任务、消息，全部打通。
2026 年 3 月 22 日，腾讯正式官宣微信支持 OpenClaw（通过 WeChat ClawBot 插件）。按理说，我应该欢呼雀跃。
但我发现，我不想回去了。
三个让我回不去的细节
不是什么宏大叙事，就是三个日常使用中的细节，让我确定了飞书才是 OpenClaw 的主场。
1. 已读回执：我知道它在不在
飞书的消息有已读状态。我给 AI 助手发了一条指令，能看到它是否收到、是否正在处理。这在调试和日常使用中非常重要——我知道它”在线”，而不是消息发出去石沉大海。
微信的设计哲学是”不给社交压力”，所以刻意不做已读回执。这在熟人社交里是对的，但在人机协作场景下，你需要知道你的助手收到了指令。
2. 消息渲染：不只是纯文本
让 OpenClaw 输出一份结构化的分析报告，在飞书里可以渲染成带格式的富文本卡片——标题、列表、表格、代码块，一目了然。
同样的内容在微信聊天窗里？大概率会塌成一堆纯文本。表格变成错位的字符，代码块没有高亮，列表挤成一团。AI 输出的信息密度越高，微信的呈现能力就越显不足。
3. 聊天记录即长期记忆
这是最让我惊喜的一点。
飞书支持以用户身份搜索聊天记录——按关键词、按时间、按发送者、跨会话搜索。这意味着我和 AI 助手之间所有的对话历史，都可以被检索和回溯。
我直接把飞书的聊天记录当成了 AI 助手的”无限记忆”。需要回忆之前的讨论？搜一下就出来了。不受单次会话长度限制，也不怕上下文被截断。
微信的聊天记录搜索能力相对有限，据我所知，目前也不太支持通过 API 让 AI 助手主动检索历史消息。在微信里，AI 助手的记忆大概率是断裂的；在飞书里，记忆是连续的。
不只是聊天工具
这三个细节背后是一个更本质的差异：飞书不只是一个 IM 工具，它是一个完整的工作空间。
OpenClaw 中文教程里有一句评价：
飞书的开放能力更强，能获取更多工作中必要的上下文，是国内接入 OpenClaw 的最佳选择。
这不是空话。飞书官方插件开源在 GitHub 上，通过它，OpenClaw 可以：
- 读写云文档：创建、编辑、获取文档内容
- 操作多维表格：增删改查记录、管理字段、筛选数据
- 管理日历日程：创建会议、查询忙闲、发送邀请
- 处理任务待办：创建任务、设截止日期、分配负责人
- 搜索历史消息：跨群聊、跨单聊检索对话记录
这些不只是”能用”的 API，而是已经被打通成一个完整的工作链。AI 助手不再是一个”只能聊天的对象”，而是一个”能干活的同事”。
虾住在哪里，比虾本身重要
最近看到宝玉老师的一篇微博，标题叫《企业养虾，虾住在哪里比虾本身重要》，里面有一个观点说得很好：
再聪明的虾，哪怕学会了屠龙术，如果生活在鱼缸里，也做不了什么事。
这和我的个人感受完全吻合。模型可以越来越强，但如果 AI 助手只有一个聊天窗口，它的能力上限就被限死了。
飞书给 OpenClaw 提供的是一个”养虾场”——有数据（文档、表格、消息历史），有操作能力（创建、修改、搜索），有组织关系（谁是谁、什么权限），有技能生态（官方插件 + 社区 Skill）。
微信给 OpenClaw 提供的，可能更像是一个”鱼缸”——能聊天，但也主要只能聊天。
不是微信不好
写这篇文章不是为了踩微信。微信是一个优秀的产品，在熟人社交领域无可替代。
但场景不同，主场不同。
微信适合聊天、社交、朋友圈、公众号——它的设计哲学是”连接人与人”。飞书适合协作、文档、日程、任务——它的设计哲学是”连接人与工作”。
OpenClaw 需要的是后者。它需要一个有数据、有工具、有上下文的工作环境，而不是一个只有聊天气泡的社交窗口。
让微信归微信，飞书归飞书。OpenClaw 在飞书里，才能发挥最大的价值。
参考资料：