夜雨聆风今天腾讯正式推了微信 ClawBot 插件，可以把 OpenClaw 接入微信了。
十几亿人每天在用微信，小龙虾又是目前最接近"私人 AI 助手"的开源方案，这两个一接上，普通人离 AI 的距离一下子就近了。
就像家里老人都会刷抖音一样，当入口变成了微信，门槛就不再是问题，剩下的就是怎么把它用起来、用出花来。
我第一时间上手试了试，微信不愧是产品力代表，一行命令，一次扫码就行了。我最关心的还是多个微信号接入同一个 OpenClaw。
这个全家人一起养虾的模式太有吸引力了。感觉就像是，家里来了个博士学历的管家一样。话不多说，我们开始。
先装好插件
我这边 OpenClaw 已经是装过的（这里吐槽一下某些公司的某些团队，装龙虾还要立项，一行命令的事，搞了半个月......）。
装插件一行命令：
npx -y @tencent-weixin/openclaw-weixin-cli install这里扫码绑定就行。
或者手动装：
openclaw plugins install "@tencent-weixin/openclaw-weixin"openclaw config set plugins.entries.openclaw-weixin.enabled true接入多个微信号
查了下本地openclaw-weixin插件的文档，里面有说明。每跑一次登录命令就多接入一个微信号：
# 让家人/同事扫码openclaw channels login --channel openclaw-weixin# 想接几个就跑几次openclaw channels login --channel openclaw-weixin每次扫码会自动生成一个账号 ID（类似 5xxxxxx-im-bot），多个微信号可以同时在线，互不影响。
接完重启一下网关：
openclaw gateway restart查看已经接入的微信号：
openclaw channels list# 或者直接看插件数据文件cat ~/.openclaw/openclaw-weixin/accounts.json# ["xxxxx-im-bot", "a1bxxd4-im-bot", "eccch8-im-bot"]到这步其实就通了。我让家人试了一下，在微信里给clawbot发消息，直接就有回复。
接下来，我们正式开始配置。
先搞清几层关系
配置过程中我对几个概念一直有点模糊，花了点时间理清楚：
Channel ── openclaw-weixin（微信渠道，装完插件就有了） └─ Account ── 每个扫码登录的微信号（一个 accountId） └─ Binding ── 路由规则：这个微信号的消息发给哪个 Agent └─ Agent ── 一个完整的 AI 大脑（workspace / SOUL / 记忆 / 工具） └─ Session ── 对话上下文（dmScope 控制如何隔离）这里其实还是不准确，agent和workspace绑定，可以与channel、account等绑定，但不是从属关系，这里只是为了好理解。
理清了之后后面就好办了：Channel 是渠道，Account 是谁在用，Agent 是跟哪个 AI 聊，Session 是这段对话的上下文。
玩法一：共享 Agent
我先试的共享模式，全家人的微信号都接到同一只虾上，不用额外创建 Agent。
隔离对话上下文：dmScope
我一开始没改配置，默认所有微信号的会话汇入同一个 session（dmScope: "main"，如果你跑过 openclaw onboard，可能默认已经是 per-channel-peer），本来是为了跨设备聊天时保持上下文连续，一个人用没问题。但多人共用就串台了，妈妈问的菜谱爸爸也能看到。
改成 per-account-channel-peer 就好了，AI 会按微信账号区分对话上下文：
openclaw config set session.dmScope per-account-channel-peer我一开始选了 per-peer，发现不行。因为每个家庭成员的微信号在 OpenClaw 里对应不同的 accountId（如 5722ab94-im-bot），只有 scope 里包含 accountId 才能区分"谁在跟 AI 说话"。
但记忆是共享的
用了一段时间我发现，dmScope 只管 Session（对话上下文）的隔离。同一个 Agent 内，这些东西始终是共享的。
MEMORY.md 的共享我觉得反而是好事。全家人共同养一只虾，它越来越了解每个家庭成员，记住每个人的偏好和习惯，慢慢就成了真正的"家庭管家"。
但 USER.md 的共享是个真实的坑，我自己就踩了。
踩坑：USER.md 互相覆盖
我给两个微信号都绑了同一个 Agent，两个人分别跟虾宝自我介绍。结果：
AA 通过微信号 A 自我介绍 → 虾宝把 USER.md更新为「AA，CC 的妈妈」BB 通过微信号 B 自我介绍 → 虾宝把同一个 USER.md覆盖为「BB，CC 的爸爸」AA 再问"我叫什么" → 虾宝读到被覆盖后的文件，回答"你叫 BB"
IDENTITY.md、memory/ 目录下的文件也有同样的问题。根本原因是：workspace 文件在 Agent 级别共享，没有"per-session workspace"这个概念。dmScope 只管 session（对话历史）的隔离，管不了 workspace 文件的读写。
所以如果你的场景里，每个家庭成员都需要虾宝"认识自己"并维护独立的用户档案，共享 Agent 模式就不够用了，需要切到玩法二。
Agent 知道谁在说话吗？
我测试了一下，不直接知道。
dmScope 隔离了对话上下文，但 Agent 系统提示里注入的 USER.md、SOUL.md、MEMORY.md 都在 workspace 级别，共享 Agent 只有一份。OpenClaw 目前不支持按 accountId 切换不同的 bootstrap 文件。
所以 Agent 不会收到"你现在在跟爸爸聊天"这种信息，它只知道"这是一个独立的 session"。
再加上前面说的 USER.md 覆盖问题，共享 Agent 在多人场景下体验其实不好。虽然 session 对话历史是隔离的，但 Agent 分不清在跟谁聊天，记忆和用户档案又会互相覆盖，用着用着就乱了。
所以我的建议是：多人场景直接上玩法二（独立 Agent）。 共享 Agent 更适合同一个人多设备登录的场景，而不是多人共用。
玩法二：独立 Agent
后来我又试了独立模式。给每人创建一个独立 Agent，用 Binding 做路由，人格、记忆、工作区就完全分开了。
操作步骤
# 1. 给每个家人创建独立 Agentopenclaw agents add dad --workspace ~/.openclaw/workspace-dadopenclaw agents add mom --workspace ~/.openclaw/workspace-momopenclaw agents add kid --workspace ~/.openclaw/workspace-kid# 2. 把微信号绑定到对应 Agentopenclaw agents bind --agent dad --bind openclaw-weixin:5722ab94-im-botopenclaw agents bind --agent mom --bind openclaw-weixin:a1b2c3d4-im-botopenclaw agents bind --agent kid --bind openclaw-weixin:ecccc1h8-im-bot# 3. 查看绑定结果openclaw agents bindings# 4. 重启生效openclaw gateway restart没有被 Binding 匹配到的微信号会自动落到 default: true 的默认 Agent 上。
各自定制人格
然后每个 Agent 的 workspace 里写不同的 SOUL.md。
~/.openclaw/workspace-dad/SOUL.md：
你是一个高效的工作助手。回复简洁直接，擅长日程管理和信息整理。~/.openclaw/workspace-kid/SOUL.md：
你是一个有趣的学习伙伴「虾虾」。说话生动活泼，擅长用故事和比喻解释问题。遇到不适合小朋友的话题，温和地引导到其他方向。隔离在 Agent 层就完成了，每个 Agent 有自己的 workspace、SOUL.md、MEMORY.md 和 session 存储，互不干扰，dmScope 设什么都无所谓。
Agent间通信
独立不代表孤立。OpenClaw 支持 agent-to-agent 通信，开启后两个 Agent 可以互相发消息、委派任务。
还要开 sessions.visibility。光有 agentToAgent 还不够，我试着从 dad 的 Agent 给 mom 的 Agent 发消息，被系统直接拦了：
Session send visibility is restricted. Set tools.sessions.visibility=all to allow cross-agent access.
原因是 sessions.visibility 默认值是 "tree"（只能看当前 session 和它 spawn 出来的子 session），必须改成 "all" 才能跨 Agent 发消息。注意 "all" 意味着所有 Agent 都能访问彼此的 session 历史，家庭场景一般没问题，但如果有隐私需求，可以考虑只在需要时临时开启。
正确的配置长这样：
// 在 openclaw.json 顶层 tools 里配置，不是 per-agent{ tools: { agentToAgent: { enabled: true, allow: ["dad", "mom", "kid"] // 允许互相通信的 Agent 列表 }, sessions: { visibility: "all" // 默认 "tree"，必须改成 "all" 才能跨 agent } }}配好之后，Agent 之间通过 sessions_send（发消息）和 sessions_spawn（委派任务）来协作。比如妈妈问虾宝"爸爸今天日程安排是什么"，妈妈的 Agent 可以去问爸爸的 Agent，拿到答案再回复。
隔离归隔离，需要协作时还是能打通。
主动推送
我还想过一个场景：爸爸的 Agent 主动给妈妈的微信推一条消息，比如"今晚加班，不用等我吃饭"。试了一下，做不到。
翻了 openclaw-weixin 插件的源码，发现微信渠道有个限制：必须先收到用户消息，拿到 context token，才能回复。也就是说 Agent 只能"被动应答"，不能长间隔主动推送。这应该是微信平台侧的限制，插件层面绕不过去。
所以目前的 agent-to-agent 通信更适合实时协作的场景：妈妈问了一个问题 → 妈妈的 Agent 去找爸爸的 Agent 查信息 → 在同一轮对话里把答案带回来。而不是"过两小时主动推一条消息到微信"。
关于群聊
目前微信 ClawBot 插件应该只支持私聊，群里还不行。OpenClaw 在 WhatsApp、Telegram、Discord 上倒是已经支持群聊了（peer.kind: "group" 路由 + mentionPatterns 触发），微信这边等后续吧。
完整配置一览
玩法一：共享 Agent 的配置
// ~/.openclaw/openclaw.json{ session: { dmScope: "per-account-channel-peer", // 按微信号隔离对话上下文 }, agents: { list: [ { id: "main", default: true, workspace: "~/.openclaw/workspace", }, ], },}数据分布。
~/.openclaw/workspace/ ← 全家共享的 workspace ├── AGENTS.md ← 共享操作指令 ├── SOUL.md ← 共享人格 ├── USER.md ← ⚠️ 共享用户档案（多人会互相覆盖！） ├── IDENTITY.md ← 共享 Agent 身份 ├── MEMORY.md ← 共享长期记忆 └── memory/2026-03-22.md ← 共享每日笔记~/.openclaw/agents/main/sessions/ ← 对话上下文按 dmScope 隔离 ├── sessions.json ├── <爸爸 sessionId>.jsonl ├── <妈妈 sessionId>.jsonl └── <孩子 sessionId>.jsonl玩法二：独立 Agent 的配置
// ~/.openclaw/openclaw.json{ agents: { list: [ { id: "dad", default: true, workspace: "~/.openclaw/workspace-dad" }, { id: "mom", workspace: "~/.openclaw/workspace-mom" }, { id: "kid", workspace: "~/.openclaw/workspace-kid", sandbox: { mode: "all", scope: "agent" }, tools: { deny: ["write", "edit", "apply_patch", "browser"] }, }, ], }, bindings: [ { agentId: "dad", match: { channel: "openclaw-weixin", accountId: "5722ab94-im-bot" } }, { agentId: "mom", match: { channel: "openclaw-weixin", accountId: "a1b2c3d4-im-bot" } }, { agentId: "kid", match: { channel: "openclaw-weixin", accountId: "ecccc1h8-im-bot" } }, ], // agentToAgent 和 sessions 是全局配置，不是 per-agent tools: { agentToAgent: { enabled: true, allow: ["dad", "mom", "kid"] }, sessions: { visibility: "all" }, },}每个 Agent 的数据完全独立。
~/.openclaw/workspace-dad/ ← 爸爸的 workspace ├── AGENTS.md ← 爸爸的操作指令 ├── SOUL.md ← 爸爸的 AI 人格 ├── USER.md ← 爸爸的用户档案（不会被覆盖） ├── MEMORY.md ← 爸爸的记忆 └── memory/ ← 爸爸的每日笔记~/.openclaw/workspace-kid/ ← 孩子的 workspace ├── AGENTS.md ← 孩子的操作指令 ├── SOUL.md ← 孩子的 AI 人格 ├── USER.md ← 孩子的用户档案 ├── MEMORY.md ← 孩子的记忆 └── memory/ ← 孩子的每日笔记~/.openclaw/agents/dad/sessions/ ← 爸爸的对话记录~/.openclaw/agents/kid/sessions/ ← 孩子的对话记录回到开头说的，微信能接入小龙虾是个绝对的大事件。普通人离 AI 不再遥远，就像家里老人都会刷抖音一样，当入口变成了微信，事情的性质就变了。
接下来不是"能不能用"的问题，而是"怎么用好"。家庭管家、团队助理、老人陪伴、小孩辅导，基于微信和小龙虾能长出来的场景数不完。
也在关注米家那边的动态，智能家居要是也接上了，那就不是原来的小爱同学能比的了。
最近在开发公司内部的Agent，看看兄弟团队清一色的Langchain，不敢苟同。
我基于rust核心库，手写了Agent框架，接下来计划开一个系列来讲。
从第一个Agent循环开始，到
SKILL、TUI、GUI、记忆管理、A2A等细节，介绍如何搭建一个高性能Agent框架，欢迎关注。
