用 OpenClaw + wechat-cli 搭建微信群聊情报助手:2小时一次,自动总结100+群聊消息

痛点：微信加了上百个行业群，每天几千条消息。不看怕错过关键信息，逐条看又没那个时间。我花了一个下午，用 OpenClaw 和 wechat-cli 搭了一个自动情报简报系统——每 2 小时自动总结所有活跃群的新消息，推送到飞书。

效果预览

每 2 小时，飞书私聊收到一条情报简报：

不到一分钟读完，群聊动态一目了然。

核心组件

wechat-cli：命令行微信数据查询工具

wechat-cli 是一个基于 Python 的命令行工具，通过读取微信本地数据库实现对微信消息的查询，无需 Hook 微信进程。主要命令：

核心机制：new-messages 维护一个状态文件（~/.wechat-cli/last_check.json），记录上次检查时间，后续只返回增量。这让我们可以实现高效的定时巡检。

OpenClaw：Agent 运行时

OpenClaw 是我的 AI Agent 运行平台。它支持多 Agent 管理、Cron 定时任务、多通道（飞书/Telegram/微信）消息收发。关键能力：

• Agent 定义
  
  ：每个 Agent 拥有独立的 SOUL.md（人设）和 AGENTS.md（工作流程）
• Cron 定时
  
  ：支持 cron 表达式，支持将任务分配至特定 Agent session
• Announce 推送
  
  ：任务结果自动推送到指定通道

架构设计

┌─────────────────────────────────────────┐│              OpenClaw Gateway            ││                                          ││  ┌──────────┐     ┌─────────────────┐    ││  │Cron 定时器│────▶│ 微信群聊助手 Agent │    ││  │每 2 小时    │     │                 │    ││  │07-23 点   │     │① sessions→群列表 │    ││  └──────────┘     │② history→实际消息 │    ││                    │③ LLM 逐群总结    │    ││                    │④ 自动推送飞书    │    ││                    └─────────────────┘    │└─────────────────────────────────────────┘

为什么不用静态群列表？sessions 命令返回的群按最近活跃时间排序，天然覆盖了「最近有人在聊的群」。死群自动沉底，新群自动加入，零维护成本。

为什么逐群拉 history 而不是用 new-messages？new-messages 返回过去所有时间的增量消息（包括凌晨的公众号推送），需要手动过滤。而 history --limit 20 直接返回最新 20 条，天然是最近 2 小时内的群聊消息内容，更适合做「情报简报」。

搭建步骤

1. 安装 wechat-cli

pip install wechat-cliwechat-cli init    # 首次初始化，提取微信密钥

⚠️ 需要微信 PC 端保持登录状态。

2. 创建 Agent 文件

在 OpenClaw 的 agents 目录下创建 Agent：

SOUL.md — 定义 Agent 人设和输出规范：

# SOUL.md - 微信群聊情报助手你是微信群聊情报分析师。每 2 小时运行一次，产出情报简报。## 输出格式📊 **微信群聊简报** | M 月 D 日 HH:00-HH:00### 🟢 [群名] · N 条话题：一句话概括要点：- 关键信息 1- 关键信息 2📌 值得关注：xxx（可选）## 规则- 只关注群聊，忽略公众号/私聊- 基于实际消息内容，不用 unread 数字- 不输出隐私信息

AGENTS.md — 工作流程：

# AGENTS.md - 工作手册## 执行流程1. 获取群列表$env:PYTHONIOENCODING='utf-8'; wechat-cli sessions --limit 50筛选 is_group=true，排除系统占位符2. 逐群拉取消息$env:PYTHONIOENCODING='utf-8'; wechat-cli history 「群名」 --limit 203. 过滤过去 2 小时消息，忽略表情/系统消息4. LLM 按 SOUL.md 格式生成简报5. 直接输出，系统自动推送

⚠️ 两处容易踩坑：

• wechat-cli 所有命令前必须加 $env:PYTHONIOENCODING='utf-8'，否则群名含 emoji 时会 GBK 编码报错
• 不要用 sessions 里的 unread 计数做总结
  
  ——那是累计未读数，不是过去 2 小时的消息量

3. 配置 OpenClaw

在 openclaw.json 中添加 Agent 定义：

{  「id」: 「wechat-group-agent」,  「name」: 「微信群聊助手」,  「workspace」: 「agents/wechat-group-agent/workspace」,  「model」: 「mimo/MiMo-V2.5」,  「identity」: { 「name」: 「微信群聊助手」, 「emoji」: 「📡」 },  「tools」: { 「profile」: 「full」 }}

注册飞书通道（用于推送结果）：

「wechat-group-agent」: {  「allowFrom」: [「ou_xxx」],  「appId」: 「cli_xxx」,  「appSecret」: 「xxx」,  「dmPolicy」: 「allowlist」}

添加绑定（Agent ↔ 飞书通道）：

{  「agentId」: 「wechat-group-agent」,  「match」: { 「channel」: 「feishu」, 「accountId」: 「wechat-group-agent」 }}

⚠️ 注意：Agent 绑定不要加 「type」: 「route」——那是给 fallback 路由用的。直接用 agentId 绑定即可，和主 Agent 的绑定方式保持一致。

4. 创建 Cron 任务

⚠️ Cron 必须在「微信群聊助手」的飞书窗口中创建——让 Agent 自己建自己的 cron，这样推送才会从它自己的飞书通道发出。如果在主 Agent 窗口创建，推送会走主 Agent 的通道。

直接把这段提示词发给微信群聊助手：

创建微信简报定时任务。忽略你的 AGENTS.md 工作流程，先用 cron 工具创建 9 个定时任务。每个 cron job 参数模板（HH 替换为对应小时）:name: 「微信简报-HH 点」schedule: {「kind」:「cron」,「expr」:「0 HH * * *」,「tz」:「Asia/Shanghai」}payload.kind: 「agentTurn」payload.message: 「执行微信群聊情报简报任务。先读取你的 AGENTS.md 和 SOUL.md，严格按照其中定义的工作流程和输出格式执行：获取群列表→逐群拉取实际消息→过滤过去 2 小时内容→按情报简报格式输出总结。」sessionTarget: 「isolated」delivery: {「mode」:「announce」,「channel」:「feishu」,「to」:「user:ou_xxx」}需要创建：07 点、09 点、11 点、13 点、15 点、17 点、19 点、21 点、23 点

Agent 会逐次调用 cron add 创建 9 个任务。sessionTarget: 「isolated」 让每次执行在独立 session 中运行，避免干扰主会话。

为什么要从 Agent 自己的窗口创建？ Cron job 归属创建它的 session 所在的 agent。如果在 Commander 窗口创建，推送会走 Commander 的飞书通道，而不是微信群聊助手的通道。让 Agent 自己建 cron，才能保证推送从正确的飞书 bot 发出。

5. 测试和调优

踩坑 1：unread vs 实际消息 Agent 第一次用 sessions 返回的 unread 数直接当消息量，结果 626 条未读看着吓人，实际只是累计未读数，完全没有信息量。

修复：改为逐群 history --limit 20 拉取实际消息内容。效果立竿见影：

踩坑 2：Agent 绑定 type: 「route」 导致飞书通道不通 Agent 绑定时加了 「type」: 「route」，导致接收消息和推送都失败。去掉 type 后恢复正常——Agent 绑定和 fallback 路由是两回事。

踩坑 3：Cron 推送走了错误的通道 从 Commander 窗口创建的 cron，推送结果会从 Commander 的飞书 bot 发出，而不是微信群聊助手。解决方案：在微信群聊助手自己的飞书窗口创建 cron，让任务归属于正确的 agent。

模型选择与成本分析

推荐：MiMo V2.5（当前使用）

我用的是小米 MiMo 开放平台的 MiMo V2.5 模型，综合能力强，适合做信息总结。

定价（每百万 tokens）：

好消息是目前可以白嫖——用推荐码注册即送 ¥10 体验金（40 天有效）。按每次运行约 50K tokens 计算，体验金够跑几百次。

注册方式：

通过邀请码注册 MiMo 开放平台，即得 ¥10 API 体验金。邀请码：2HF2AV

注册链接：https://platform.xiaomimimo.com?ref=2HF2AV

（注册后点控制台左下方入口填入邀请码，体验金 40 天有效）

OpenClaw 配置：在 openclaw.json 的 models.providers 中添加：

「mimo」: {  「baseUrl」: 「https://api.xiaomimimo.com/v1」,  「apiKey」: 「你的 API Key」,  「api」: 「openai-completions」,  「models」: [{    「id」: 「MiMo-V2.5」,    「name」: 「MiMo V2.5」,    「reasoning」: true,    「input」: [「text」],    「contextWindow」: 1048576,    「maxTokens」: 65536  }]}

详细配置文档：https://platform.xiaomimimo.com/docs/zh-CN/integration/openclaw

长期备选：DeepSeek V4 Flash

体验金用完后，推荐切到 DeepSeek V4 Flash，性价比极高：

每天 9 次 × 50K tokens ≈ 450K tokens，以 20% 缓存命中率估算，日均成本不到 ¥1。

运行成本一览

| 每次运行 token | ~50K（输入 45K + 输出 5K）

总结与扩展思路

核心收获：这个方案的核心价值不在于技术本身，而在于它把「被动刷群」变成了「主动情报推送」。以前你可能打开微信刷 10 分钟群聊、翻 5 个群才能拼凑出今天的动态，现在 30 秒读完一条简报就够了。

进一步可以做的事情：

1. 关键词监控
   
   ：在 AGENTS.md 中配置「如果出现 X 关键词则标红」，自动告警重要信息
2. 跨群趋势
   
   ：多群同时出现某个话题时自动标注「今日关注」
3. 自动入库
   
   ：把简报输出到飞书多维表格或 Notion，积累成可搜索的群聊情报库
4. Webhook 联动
   
   ：关键信息触发 n8n 工作流，自动通知相关人
5. 多模型切换
   
   ：日常用免费模型省钱，高价值群用更强模型做深度分析