一虾多吃,微信插件该怎么玩,还差什么?

OpenClaw 接了好几个渠道，我觉得discord已经很好用了，奈何还得科学上网，肯定不是大众的选择，咱们一直用的“小而美”却一直没有官方接入渠道。这两天微信官方插件终于发布了，赶紧把我的openclaw接入了我的微信，消息收发、语音、图片都能玩转了。

今天先聊聊怎么安装、怎么多开，顺便说说踩了哪些坑，扒一扒有待优化的地方。

安装与登录

前提：iOS 微信需要更新到 8.0.70 或以上版本，安卓目前暂不支持。在已经部署了 OpenClaw 的机器上，一行命令搞定（插件文档在这[1]）：

npx -y @tencent-weixin/openclaw-weixin-cli@latest install

它会自动把插件装到 ~/.openclaw/extensions/openclaw-weixin/ 下面，依赖也一并处理好。Gateway 启动时会自动发现这个目录，扫到 openclaw.plugin.json 就知道是个插件，自动加载。

接下来登录：

openclaw channels login --channel openclaw-weixin

终端会弹出一个二维码，用微信扫一下就行。登录成功后凭证文件会存到 ~/.openclaw/openclaw-weixin/accounts/ 下面。然后启动 gateway：

openclaw gateway

日志里出现 starting weixin webhook 就说明插件跑起来了。有人给这个微信号发消息，AI 就会回复。

一虾多吃——连接多个微信账号

装完一个号，自然就想问：第二个号怎么搞？

答案很简单——再跑一次 openclaw channels login --channel openclaw-weixin，用另一个微信扫码就行。每个微信号登录后会自动生成一个 Account ID，凭证文件各自存在 accounts/ 目录下。你在 openclaw channels list 里能看到所有已登录的账号。

每个账号有独立的消息轮询循环，收发互不影响。加第三个、第四个号也是同样的操作。

举个实际的例子：我跟我老婆都连了我部署的 OpenClaw，相当于分工合作——她负责安排酒店，我负责安排景点，各自在微信里跟 AI 聊完之后让它更新到同一个 Notion 页面上。不用互相转发、不用手动汇总，打开 Notion 就是最新的完整计划。

不过要注意，多个号虽然消息通道是分开的，但默认情况下 AI 的对话上下文是共享的——这就涉及到下面要说的会话隔离。

会话隔离

号是分开了，但默认所有人进的是同一个会话。

什么意思呢？我和我老婆分别给微信 ClawBot 发消息，我们聊的是同一个上下文。自己用的话无所谓，但如果有多个人在用，对话就会串。

隔离也不复杂，一条命令：

openclaw config set agents.mode per-channel-per-peer

这个命令实际控制的是 session.dmScope 配置项，它决定了会话 key 的生成规则。翻译一下，OpenClaw 支持4个隔离级别：

• main
  
  （默认）：所有渠道、所有用户共用一个会话。自己玩够用，多人用就串。
• per-peer
  
  ：按用户隔离，不区分渠道。张三和李四各有各的上下文，但张三在微信和 Telegram 的对话是同一个。
• per-channel-peer
  
  ：按渠道+用户隔离。张三在微信和 Telegram 的对话也分开了。大多数场景用这个就够。
• per-account-channel-peer
  
  ：按账号+渠道+用户完全隔离。连同一个渠道下不同账号的对话也隔开。

会话 key 直接映射成文件路径，比如 per-channel-peer 模式下，微信用户的会话文件大概长这样：

~/.openclaw/agents/main/sessions/agent-main-openclaw-weixin-direct-{userId}.jsonl

有一点要注意：这里隔离的是对话历史，也就是短期上下文。长期记忆（memory）目前还是 agent 级别共享的，想隔离 memory 得配多个独立 agent。

定时任务踩坑

会话隔开了，接下来搞点自动化。我在微信里跟 AI 说”帮我设个 Hacker News 每日 Top 5 的定时推送”，AI 确实创建了 cron 任务。然后就翻车了。

翻了一圈日志，发现两个独立的问题。

第一个坑：contextToken 丢失。微信的 ilink bot API 有个机制——每次收到消息时会带一个 context_token，后续往这个用户发消息必须带上这个 token，不带就拒绝发送。问题是，这个 token 原来只存在内存里的一个 Map 中。Gateway 一重启，Map 清空，定时任务到点想发消息，报错 contextToken is required，直接挂了。

用户发消息 → getUpdates 返回 context_token → 存入内存 Map → 回复时读取 ✅Gateway 重启 → 内存 Map 清空 → 定时任务触发 → 读取为空 → "contextToken is required" ❌

第二个坑：delivery target 缺失。通过微信聊天创建的 cron 任务，AI 生成了内容，但投递失败——报错 Delivering to openclaw-weixin requires target。说白了就是 AI 创建 cron 时没有正确设置 delivery.channel、delivery.to 和 delivery.accountId，cron 系统不知道该把结果发到哪里。

用 openclaw cron runs --id <job-id> 查看运行历史可以确认：内容已经生成了（Hacker News Top 5 的摘要都有），但投递失败。

顺便说一下整个投递链路，比我预想的复杂一些：cron 触发 → isolated-agent 运行 AI 生成内容 → dispatchCronDelivery → 文本内容走 deliverViaAnnounce 路径 → 注入到 main session → main session 转发到目标 channel → weixin 插件 outbound 调用 sendMessage → 需要 contextToken。两个坑分别卡在链条的头和尾。

另外 announce 模式的投递有一定延迟，实测从 cron 触发到微信收到消息大约4分钟。如果 announce 失败会自动 fallback 到 direct 投递。

修复思路

第一个问题，contextToken 持久化。思路很直接：参考插件里已有的 sync-buf.ts（持久化轮询 buffer 到文件的模式），给 contextToken 加上磁盘读写。改的文件是 src/messaging/inbound.ts：

• 启动时从 JSON 文件加载已有 token 到内存 Map
• 每次收到新 token 写入 Map 的同时同步写盘
• 存储路径：~/.openclaw/openclaw-weixin/context-tokens.json

第二个问题，用 CLI 手动补上投递目标：

openclaw cron edit <job-id> \  --channel openclaw-weixin \  --to "<userId>"\  --account "<accountId>"

验证步骤：先给 bot 发条微信消息触发 token 缓存和持久化，然后检查 ~/.openclaw/openclaw-weixin/context-tokens.json 确认文件已生成，最后手动触发 cron：

openclaw cron run <job-id>

返回 ok: true，微信端收到 Hacker News Top 5 推送，端到端走通了。

还差什么

目前的状态：能跑、能多开、会话能隔离、定时任务的坑也填上了。

还差什么？contextToken 的有效期是个未知数——过期时间由微信服务端控制，API 文档里没说明，如果 token 过期了就得靠用户再发条消息刷新。多用户场景下所有 token 存同一个 JSON 文件，量大了可能要考虑分文件或清理机制。另外通过聊天创建 cron 时 delivery target 可能缺失这事，创建后最好用 openclaw cron list 检查一下配置。

我想去官方 repo 提个 issue，结果发现压根没有关联的 GitHub 仓库——这很微信。希望早点出新版本把这些问题修了吧。

引用链接

[1] 插件文档在这: https://www.npmjs.com/package/@tencent-weixin/openclaw-weixin?activeTab=readme