乐于分享
好东西不私藏

OpenClaw 接管桌面微信:AI Agent 从“会聊天”走向“会操作软件”

OpenClaw 接管桌面微信:AI Agent 从“会聊天”走向“会操作软件”

从私人微信群消息监听、OCR 识别,到调用 refund-ops 智能体,再到自动回复与平台执行入口,这是一套从 0 到可运行的本地自动化闭环。

这次做的是把 在OpenClaw 创建的专用退款智能体 和 Mac 桌面微信 连接起来,保持对桌面微信的持续监听让微信群里的退款请求可以自动进入一套标准化处理流程。

最终实现的效果是:群里有人 @退款助手 发起退款请求,系统自动识别消息内容,交给 OpenClaw 里的 refund-ops agent 判断平台、订单号、退款原因和下一步动作,然后自动生成回复并发送回微信群。

一、最终实现了什么?

已关注

关注

重播 分享

现在这条链路已经可以完整跑通:

微信消息监听 → 截图 OCR → 提取 @退款助手 上下文 → 调用 OpenClaw refund-ops agent → agent 判断退款动作 → 写入任务数据库 → 自动回复微信群 → 确认后进入平台执行入口

举个例子,群里发:

@退款助手 Pa订单号 FAKE-PANDA-99999 退款 原因:客户取消

系统会自动识别并回复:

已识别到退款请求,平台:Pa,订单号:FAKE-PANDA-99999,退款原因:客户取消,请确认是否执行退款

群里继续发:

@退款助手 确认退款

系统会将任务推进到执行队列,并回复:

订单 FAKE-PANDA-99999 已交给退款执行队列处理

二、整体架构:不是单点脚本,而是一条自动化流水线

这套系统被拆成了几层,每一层只做一件事:

1. 微信监听层:监听桌面微信本地 message/session 文件变化。

2. OCR 识别层:对当前微信群窗口截图,识别聊天区内容。

3. 上下文提取层:提取最新一条 @退款助手 相关消息,而不是把整屏内容全部交给模型。

4. Agent 判断层:调用 OpenClaw 的 refund-ops agent,让大模型判断这是新退款、补充原因、确认退款还是取消退款。

5. 任务状态层:用 SQLite 记录退款任务状态,避免重复处理。

6. 回复与执行层:自动生成微信群回复,确认后进入平台执行入口。

微信群消息   ↓ wechat_file_watcher.py   ↓ wechat_probe.py / ocr_latest_crop.py   ↓ agent_context_builder.py   ↓ openclaw agent --agent refund-ops   ↓ apply_openclaw_agent_decision.py   ↓ tasks.db / latest_reply.txt   ↓ wechat_reply_paster.py   ↓ 微信群自动回复

第一步:创建专用退款智能体 refund-ops

我没有把退款逻辑塞进默认主智能体,而是单独创建了一个专用 agent:refund-ops

这个 agent 的职责很明确:

识别多个退款平台,比如 Pa、Su、冰 等;

识别订单号和退款原因;

判断是否缺少信息;

生成追问或确认文案;

在确认后将任务推进到执行阶段。

这样做的好处是:写作、搜索、日常对话都不会干扰退款流程,退款场景也可以有自己的规则、状态机和执行工具。

第二步:不直接读微信消息,而是监听微信文件变化

个人微信没有稳定开放的机器人接口,所以这里没有走官方 API,而是采用桌面自动化方案。

在 Mac 版微信里,消息变化会引起本地数据文件更新。系统监听这些文件变化,一旦发现微信消息数据库发生变化,就触发后续处理。

这一步的目的不是破解微信数据库,而是把“有新消息了”作为触发信号。真正的消息内容仍然通过当前微信窗口截图和 OCR 获取。

这样就避免了持续高频截图,平时只监听文件变化,只有微信真的有新消息时才启动 OCR 流程。

第三步:截图 OCR,只提取最新 @退款助手 上下文

文件变化只能说明“微信有变化”,不能说明具体是什么消息。因此下一步需要自动激活微信窗口,截取聊天区域,再使用 OCR 识别文字。

一开始的问题是:OCR 会识别整屏内容,可能把旧消息、机器人自己回复、示例格式也一起识别进去。后来做了一个上下文提取器,只关注最新的 @退款助手 附近内容。

latest_trigger_text: @退款助手 Pa订单号 FAKE-PANDA-99999 退款 原因:客户取消  context_text: 最近几行聊天上下文  recent_tasks: 最近任务状态,用于判断这是新任务还是补充/确认

这样 agent 拿到的不是杂乱的一整屏文字,而是一个结构化的上下文包。

第四步:通过 OpenClaw CLI 调用 refund-ops agent

最初尝试过通过 Dashboard 对话工具、插件工具、HTTP hook 等方式接入,但这些方式在当前环境下并不稳定。最后采用了更直接可靠的方式:

openclaw agent \   --agent refund-ops \   --session-id desktop-wechat-refund-agent \   --message "退款上下文 JSON" \   --json

这个方式可以直接让 refund-ops agent 参与判断,不依赖 Dashboard 里是否显示工具,也不依赖临时 token。

agent 输出的是结构化 JSON:

{   "action": "preview",   "platform": "pa",   "order_id": "FAKE-PANDA-99999",   "refund_reason": "客户取消",   "target_task_id": null,   "missing_fields": [],   "reply_text": "已识别到退款请求,请确认是否执行退款",   "confidence": 0.95,   "should_execute": false }

这一步非常关键,因为它把“模糊聊天内容”变成了“可执行的业务决策”。

第五步:用任务状态机避免混乱和重复处理

退款自动化最怕的不是识别失败,而是重复处理、错把旧消息当新消息、或者机器人自己回复后再次触发自己。

所以设计了一套任务状态:

NEED_INFO:信息不完整,需要追问。

WAIT_CONFIRM:信息完整,等待用户确认。

CONFIRMED:用户已确认。

EXECUTING:已交给退款执行队列。

NEED_MANUAL:需要人工介入。

EXECUTED:执行完成。

EXECUTE_FAILED:执行失败。

每一条退款请求都会写入 SQLite 数据库,后续补充原因、确认退款、取消退款,都会和已有任务关联,而不是重新创建一条混乱的新任务。

第六步:解决“机器人回复触发机器人”的循环问题

自动发送微信回复后,微信本地文件也会变化,这会再次触发监听。如果不做保护,系统可能会反复识别同一条 @退款助手 消息,导致重复回复。

为了解决这个问题,系统加入了触发消息签名:

同一条 @退款助手 触发消息只允许处理一次。处理过的触发内容会记录 signature,下次再被文件变化触发时直接跳过。

这一步让自动化可以长期运行,不会因为自己发出去的消息而陷入循环。

第七步:从“粘贴回复”升级到“自动发送”

一开始系统只把回复粘贴到微信输入框里,需要人工按 Enter。后来加入了自动发送能力:

python wechat_file_watcher.py --auto-send

自动发送流程是:

读取 latest_reply.txt;

写入 macOS 剪贴板;

激活微信窗口;

点击输入框;

Command + V 粘贴;

自动按 Enter 发送。

这样用户在群里看到的就是一个真正能连续对话的“退款助手”。

第八步:接入平台执行入口

当用户确认退款后,任务会进入 EXECUTING 状态,然后系统会调用 refund-center 的平台执行器。(由于每个平台的后台登录实现方式有区别,所以对不同平台进行不同的处理)

Pa:通过浏览器自动化进入后台处理。

Su:通过浏览器自动化进入后台处理。

:通过 API 执行。

乐 / 友:转人工或转发给对应处理账号。

这一段的价值在于:微信只是入口,真正的执行可以按平台拆分。不同平台可以绑定不同适配器,不需要把所有退款逻辑写死在一个脚本里。

EXECUTING   ↓ execute_bridge_task_with_refund_center.mjs   ↓ refund-center router   ↓ platform adapter   ↓ EXECUTED / NEED_MANUAL / EXECUTE_FAILED

最终怎么启动?

整理成一个启动脚本:

./run_refund_assistant.sh

它会自动做这些事:

检查 OpenClaw Gateway 是否运行;

启动微信文件变化监听器;

启用自动回复发送;

启用平台执行入口。

从这个角度看,桌面微信就变成了 OpenClaw 的一个“本地入口通道”,而 refund-ops agent 则负责对业务做结构化判断。

这套实现的核心价值,不只是“让微信自动回复”,而是把一个原本依赖人工判断的售后流程拆成了可观察、可记录、可扩展的自动化系统。

第一,入口自然。业务人员仍然在微信群里发消息,不需要学习新系统。

第二,判断智能。复杂上下文交给 refund-ops agent,而不是靠死规则硬匹配。

第三,流程可控。每个任务都有状态,不会出现一条订单反复处理。

第四,可继续扩展。后面可以继续加多群监听、自动切群、平台选择器配置、异常告警。

第五,本地化强。整套系统运行在本机,能直接控制桌面微信和浏览器后台。

最终,它让 OpenClaw 不再只是聊天里的智能体,而是变成了可以连接真实桌面软件、真实业务流程、真实执行工具的本地自动化中枢。

后续还可以继续加强什么?

当前主链路已经跑通,下一步可以继续补强:

自动定位指定微信群,避免窗口切错;

多群监听,不同群绑定不同 agent;

平台页面选择器精修,提高真实退款执行成功率;

失败告警,比如登录失败、验证码、页面异常;

用 LaunchAgent 做成 Mac 常驻服务,开机自动启动。

这套系统的核心已经完成,后面更多是稳定性、平台适配和长期运行能力的优化。

从“会聊天”到“会办事”

这次实现证明了一件事:只要把消息入口、智能体判断、状态机和执行器串起来,AI Agent 就不只是回答问题,而是可以真正进入业务流程,成为本地自动化系统的一部分。

关于赛博科技

赛博科技是一家集研发、设计、生产于一体的国家科技型企业,专注于人工智能硬件产品与融合 AI 大模型的端到端 AIoT 一体化解决方案。公司通过 ISO 质量管理体系认证,拥有多项知识产权,研发人员占比高,具备从产品定义、方案设计到量产交付的完整能力。

目前,赛博科技产品与服务已覆盖 AI 玩具、智能家居、工业控制、医疗及消费电子等多个细分领域,服务全球 200+ 企业客户,持续推动 AI 从概念走向设备、从模型走向场景、从能力走向真正可交付的产品价值。