技能介绍

问题背景

微信 ClawBot 等渠道的消息到达云端时，往往会被直接塞进大模型上下文，或者被顺手做一轮分类、改写、待办识别。对长期运行的 Agent 来说，这一步很危险：模型一旦误判，原始消息就丢了，后续本地处理也无从回溯。

这个技能把云端职责收窄到一件事：把收到的原始入站消息可靠地写入持久化队列。它不分析、不分类、不总结、不重写、不排程，也不碰知识库文件。消息先落盘，之后由用户本地笔记本上的 Codex 进程再拉取 pending 消息，完成分类、改写和写入 Obsidian 保险库。

核心能力与关键步骤

当一条 WeChat/ClawBot 消息到达时，技能按固定流程处理：

原样保留内容：raw_content 只存收到的原始文本或已有转写，不做任何推断。
构造 JSON payload：尽量补齐可用字段，包括 id、source、sender、message_type、raw_content、voice_url、image_url、created_at。
调用落盘脚本：通过 stdin 把 JSON 交给 scripts/save_message.py。
简要回复结果：成功时返回保存后的 message ID 和状态；重复消息则说明已记录；失败时只报告简短原因。

队列字段中，status 初始为 pending，processed_at 初始为 null，retry_count 初始为 0，error 初始为 null。这些状态字段是为后续本地消费方预留的，云端入口只负责写入和去重。

存储路径按优先级选择：若设置了 WECHAT_QUEUE_FILE，则写入该环境变量指定的位置；否则写入 /data/openclaw/wechat_queue/messages.ndjson；若该路径不可写，再回退到 ./data/wechat_queue/messages.ndjson。服务器上需要换持久化磁盘时，显式配置 WECHAT_QUEUE_FILE 即可。

适用边界与注意点

这个技能不是消息处理器，也不是任务规划器。它不会判断一条消息是待办、已完成工作、计划、提醒还是项目更新，这些判断全部留给本地 Codex 侧。

使用时要接受两个约束：第一，队列文件是核心状态，路径必须可写且可持久化；第二，重复消息依赖脚本返回的 duplicate 标志处理，命中重复时不要再次保存，只需回复已记录。另外，即使平台传入的变量名不同，也要映射到最接近的字段，至少提供 raw_content 或 text、content、message 这类文本字段，否则队列里会缺少可消费的正文。