UseChat：让 AI 读写微信
你已经有一个能总结、写作和处理任务的 AI。让它帮你读微信、草拟回复，再把确认过的内容发出去，还需要一座连接桌面应用的桥。我们把这部分能力独立开源为 UseChat。
UseChat 是本地优先的微信 Computer Use 运行时。它通过用户已登录的可见微信窗口读取指定对话、轮询观察新消息，并发送文本、文件、图片和视频。第一条连接器支持 macOS 和 Windows；代码采用 MIT 许可证。
查看 UseChat 开源项目 →把微信操作变成 Agent 工具
上层 Agent 决定读哪个对话、如何理解消息、回复什么；UseChat 提供 read、write 和 watch，将窗口操作和消息状态封装起来。任何能执行命令的 Agent 都能调用 CLI，也可以通过 TypeScript SDK 或本地 stdio JSONL 工具服务集成。
usechat read --app wechat --chat "ABC" --limit 20 --format json
usechat write --app wechat --chat "ABC" --text "收到，我稍后回复"
usechat watch --app wechat --chat "ABC" --emit jsonl发送默认要求确认；已明确授权的非交互流程可以显式使用 --yes。读取和监听返回的是工具数据，消息总结和回复内容由你接入的 Agent 完成。
底层模型与识别成本
仓库推荐阿里云百炼 qwen3.5-flash，它是支持图片输入的视觉语言模型。UseChat 没有把模型写死，也没有在空白配置中预填它；用户需要自行配置，并可替换为兼容接口的其他视觉模型。它负责把截图与 OCR 提示转成消息 JSON；消息总结和回复内容由上层 Agent 完成。
当前千问调用显式设置 enable_thinking: false、temperature: 0 和 JSON 输出格式，让识别任务直接返回结构化结果，避免生成长篇思考内容。
一次读取大约多少钱
按 2026 年 10 月 14 日核对的百炼华北 2（北京）标准原价，qwen3.5-flash 单次输入不超过 128K Token 时，输入每百万 Token 为 0.20 元，输出每百万 Token 为 2.00 元。图片会折算为输入 Token；不应只按 OCR 字数计算。其他地区、长输入档位和未来调价可能不同。
核对阿里云官方模型价格 →以下是估算示例，不是实测账单：假设一次识别消耗 5,000 输入 Token（含图片、提示词与 OCR）和 1,000 输出 Token，费用为 5,000 ÷ 1,000,000 × 0.20 + 1,000 ÷ 1,000,000 × 2.00 = 0.003 元，即 0.3 分钱。
按相同假设，1,000 次识别约 3 元；每分钟识别一次、持续 8 小时，共 480 次，约 1.44 元。这些数字只计算识别层，不含上层 Agent 总结、生成回复、额外布局识别或失败重试。截图尺寸、消息数量和实际 usage 会改变结果，不能将此估算当作每条微信消息的固定价格。
成本优势来自调用方式
本机执行重复操作
输入、粘贴与提交交给原生 Helper，减少通用 Computer Use 反复截图、逐步规划按键的模型调用。切换对话时仍可能调用视觉模型，所以不是所有发送都零 Token。
OCR 在本机完成
本机 OCR 不产生云端模型调用费，并提供文字与位置线索。但截图仍交给视觉模型，不能直接声称 OCR 把图片 Token 减少了多少。
去重减少重复处理
ledger 降低上层 Agent 重复总结或回复的可能性；当前 watch 每轮仍读取并调用视觉模型，去重发生在识别之后。即使没有新消息，也可能产生识别费，轮询越频繁，总成本通常越高。
因此，可以说 UseChat 将低单价模型、本机执行和消息状态管理结合起来，减少对逐步模型决策的依赖。具体比其他方案便宜多少倍，需要同一任务下的实际调用量、识别效果和账单对照。上述估算没有计入缓存或 Batch 折扣，也没有假定当前代码已接入这些优惠机制。
相较通用 Computer Use，优势在哪
UseChat 本身也使用视觉大模型。这里比较的是主要靠模型反复看截图、规划点击和输入的通用方案：UseChat 把微信中的重复操作与状态处理交给专用代码，模型集中处理视觉理解。
减少逐步操作的模型负担
窗口定位、输入框聚焦、剪贴板粘贴和提交由原生 Helper 执行。常规输入和提交不需要模型逐个决定按键；但切换对话时可能调用视觉模型识别布局，不能把所有发送都说成零模型成本。
让持续观察有明确状态
专用 ledger 记录已经看过的消息，首轮建立基线，后续比较新增内容。这样上层 Agent 不必每轮自行判断哪些消息已经处理，也降低了重复触发回复的可能性。
让失败能够被定位
权限不足、微信未运行、需要登录、输入框定位或模型请求失败，会返回可诊断错误。分阶段 trace 帮助区分识别、窗口操作和发送问题，便于维护与接入。
这是架构与实现带来的优势方向。目前没有公开的统一对照基准，不能据此给出成功率、速度或成本提升的具体倍数；实际表现取决于模型、微信版本、窗口状态和设备。
核心技术如何组合
1. 截图 + 本机 OCR + 视觉结构化
Helper 采集窗口截图、OCR 文本与布局提示；视觉模型输出发送者、消息类型、文本和位置等结构化字段。Core 再归一化、校验和排序，把可见界面转成 Agent 可消费的消息数据。
2. TypeScript 业务层与原生 Helper 分层
业务状态留在 TypeScript；macOS 使用 Swift，Windows 使用 C#/.NET。系统截图、OCR、鼠标键盘、剪贴板和本机文件操作由 Helper 提供，两层通过 JSON-RPC 通信。Windows OCR 包含 RapidOcrNet、ONNX Runtime 与 PP-OCRv5 资产。
3. 无官方消息 ID 时的消息标识与去重
界面截图不提供官方消息 ID。UseChat 综合发送者、类型、归一化文本、位置区间、媒体特征和邻近上下文生成消息标识，再用本地 ledger 比较观察窗口。watch 首轮只建基线，不回放所有历史可见消息。
4. 分阶段发送与结果状态
发送流程管理目标对话、输入框聚焦、剪贴板快照与恢复、文本或附件提交。返回 sent-unconfirmed 表示提交动作完成，仍没有确认收件人收到；调用者应根据实际状态处理后续动作，避免盲目重发。
5. 用户活动与接管机制
核心发送器包含用户活动门禁、自动化租约、接管中断与人工复核状态。当前直接 write 路径关闭了活动等待与接管检查，所以它们是核心代码中的协作机制，并非所有命令默认启用的保护。
6. 可替换模型与脱敏诊断
视觉模型使用 OpenAI-compatible 接口，由用户配置服务地址、模型和密钥环境变量。reasonCode、traceSummary 和 JSONL trace 帮助排查问题，诊断默认省略或脱敏截图、长文本、剪贴板全文和密钥类字段。
使用范围与神念的关系
UseChat 通过可见桌面操作微信，不读取聊天数据库、不注入客户端，也不逆向协议。读取与监听依赖当前可见内容，watch 使用轮询，不能当作完整历史同步、即时推送或保证无遗漏的消息通道。Windows 需要已登录的可见桌面会话。
“本地优先”指桌面执行、配置和消息状态主要在本机。使用远程视觉模型时，截图和 OCR 提示仍会发送到你配置的模型服务，应按自己的数据要求选择 Provider。
UseChat 是从神念历史微信 RPA 能力独立开源的项目，独立模式不需要神念账号或 Relay。神念当前的微信 RPA 与 Desktop 已退役；本文介绍独立 UseChat 项目，不代表恢复神念主产品中的微信入口。
从开源项目开始
先阅读仓库的安装说明：安装 CLI、配置视觉模型，再显式安装对应平台的 Helper 并授予系统权限。运行 doctor 检查环境后，从自己指定的对话读取开始；确认发送目标和内容后再使用 write。
npm install -g @shennian/usechat
usechat init
usechat doctor安装 CLI 不会静默安装 GUI Helper。具体模型配置、Helper 构建和安装步骤以仓库文档为准。
前往 UseChat 仓库 →