Xiyang・Liu
返回上一页

微信 AI 助手

没人会否认，当你遇到一个难题或者完成一个项目时，要去LLM页面询问或上Coding Agent解决。但如果只是在聊天的时候，一个突然蹦出来的小疑惑呢？切换App，输入问题，等待结果，这个繁琐的流程本身就会消耗掉我们的好奇心，浪费掉一个可能的有趣灵感。

于是我想做一个更直接的东西：

如果 AI 本身就是我的一个微信联系人呢？

不需要打开额外的软件，也不需要改变原来的聊天习惯。私聊它，或者在微信群里 @ 它，它就能直接理解问题、调用需要的模型与工具，然后把答案重新发回微信。

微信 AI 助手就是在这个想法下做出来的一个 Windows 微信个人 AI 助手。

是什么

微信 AI 助手运行在 Windows 微信客户端旁边，通过桌面 UI Automation 观察微信中的新消息。

目前支持两种主要触发方式：

  • 私聊机器人账号
  • 在微信群中明确 @ 机器人

收到符合条件的新消息后，程序会先进行消息身份与安全检查，再根据问题类型决定使用哪个模型以及是否调用外部工具。

最终生成的回答会重新写入微信输入框并发送出去。

因此从使用者的角度来看，它和普通微信联系人没有太大区别：

发消息 → 等待几秒 → 收到 AI 回复。

整个模型调用、工具检索和微信操作过程都在后台完成。

为什么不是只接一个大模型 API

这个项目后来逐渐变成了一套双模型协作架构。

我没有让所有问题都固定交给同一个模型，而是根据问题类型自动路由。

OpenAI ChatGPT 5.6 Luna

OpenAI ChatGPT 5.6 Luna 是默认模型，主要负责：

  • 普通聊天
  • 工作与学习
  • 写作与翻译
  • 编程
  • 一般专业问题
  • 天气、资讯与 Web 信息

DeepSeek V4 Pro Thinking

对于更需要推理或专业判断的领域，则自动切换到 DeepSeek V4 Pro Thinking，目前主要包括：

  • 金融
  • 医疗与健康
  • 健身、营养与运动
  • 其他需要给出详细建议的领域

例如普通聊天会直接进入 Luna，而股票分析会自动进入 DeepSeek Pro。

微信用户主动选择用什么模型回答问题，程序会根据问题自动选择对应的模型。

Tools

模型并不只能依靠自身已有知识回答。

我另外做了一层统一的 Skill / Tool 系统。

  • 实时市场报价
  • 历史 K 线数据
  • 基本面数据
  • Web Search

例如在微信里询问某只股票最近的走势时，系统可以先识别证券代码，再获取真实行情数据，并让 DeepSeek 根据这些数据完成分析。

用户问题 → Agent 判断需要什么数据 → 调用工具 → 获取结果 → 模型分析 → 微信回复

而不是简单地把一句话转发给模型。

微信桌面自动化

这个项目比较麻烦的部分其实不在模型，而在微信本身。

我使用的是普通 Windows 微信客户端，而不是专门为机器人设计的消息接口。

因此程序需要真正处理桌面 UI：

  1. 识别

    1. 识别当前微信会话
    2. 判断新消息还是历史消息
    3. 识别群聊中的 @SELF
    4. 防止机器人回复自己的消息

  2. 定位与写入

    1. 切换到正确会话
    2. 找到输入区域
    3. 写入回答

  3. 发送与校验

    1. 找到发送按钮
    2. 执行发送
    3. 再确认消息是否真正发送成功

实际开发过程中甚至遇到过一个很典型的 UI Automation 问题：

微信发送按钮内部的文字子控件覆盖了原本的点击命中区域，导致程序已经生成回答、甚至已经把文字写入输入框，却无法安全确认发送按钮的实际点击面。

最后通过重新设计发送按钮 hit-test 和 transaction 机制才把整条真实发送链路跑通。

这类问题也是这个项目和普通“调用一次 LLM API”的 Demo 最大的区别。

SEND_VERIFIED

我没有让程序采用“按一下发送键就默认成功”的方式。

每次发送都会作为一个独立 transaction 管理。

如果能够确认发送成功：

SEND_VERIFIED

事务结束。

如果明确知道没有执行发送动作，则可以安全失败并继续处理下一次请求。

但如果已经执行过一次真实 UI 发送动作，却无法判断微信究竟有没有成功发送，则会进入：

SEND_AMBIGUOUS

此时系统不会自动重试。

漏发一条消息通常比把同一条消息重复发送两次更容易接受。

因此遇到不确定发送状态时，我更倾向于停止并等待人工确认，而不是冒险重复操作微信。

单工模式

这个项目没有追求同时处理大量用户。

因为最终输出依赖真实 Windows UI，稳定性比并发吞吐量更重要。

因此后来我加入了一个全局 BUSY 单工机制。

机器人空闲时，只接受第一条符合条件的新请求。

一旦开始处理：

BUSY

期间即使其他用户继续私聊，或者其他微信群再次 @ 它，程序仍然会看到这些新消息并推进消息游标，但不会把它们加入待处理队列。

这些消息会被直接丢弃，也不会在上一条回答结束后重新追溯。

当前请求结束以后：

BUSY → IDLE

机器人再从此后出现的下一条新消息开始工作。

这牺牲了一部分并发能力，但大幅降低了桌面自动化环境下排队、错会话、旧消息补答和 UI 状态变化带来的风险。

安全边界

因为程序拥有操作真实微信客户端的能力，所以我给发送链路保留了比较严格的边界。

  1. 触发边界

    • 群聊必须明确 @ 机器人本身
    • 启动前已存在的历史消息不会被重新回答

  2. 去重与回声隔离

    • 同一条消息不会重复 materialize
    • 机器人自己发送的消息不会再次触发自己

  3. 会话与 UI 控制

    • UI 操作保持串行
    • 发送前重新确认目标会话

  4. 发送事务保护

    • 不确定是否成功发送时禁止盲目重试
    • unresolved transaction 会阻止新的危险发送动作

这些机制会牺牲一些“什么情况都尽量回复”的便利性，但对于一个真正控制微信账号的程序来说，我更在意它：

不要发错人、不要重复发送，也不要因为 UI 状态变化而失控。

当前状态

目前已经完成真实微信环境下的完整链路验证。

实际测试过：

  1. 普通聊天

    微信 → Luna → 回复生成 → 微信发送

  2. 金融问题

    微信 → DeepSeek V4 Pro Thinking → 市场数据 Skills → 分析 → 微信发送

  3. 健身 / 营养问题

    微信 → DeepSeek V4 Pro Thinking → 微信发送

并已经验证：

  1. 消息入口与保护

    • 群聊 @SELF
    • 私聊自动回复
    • 消息去重
    • 历史消息保护

  2. 模型与工具

    • 模型自动路由
    • Tool Calling
    • Web Search
    • 市场行情数据调用

  3. 发送与并发

    • 发送 transaction
    • SEND_VERIFIED
    • 未决事务保护
    • 全局 BUSY 单工处理

仍待解决

  1. Skills 扩展

    现有的 Skill / Tool 体系已经覆盖了一部分常用能力，后续还希望继续增加更多 Skills，让微信端能够处理更多类型的任务，而不只停留在回答问题本身。

  2. 相对日期

    当问题使用“今天”“明天”等相对日期，而不是明确日期时，偶尔会出现无法正常回答的情况。现有排查暂未发现本地程序本身存在对应故障，但目前仍无法确认究竟来自 DeepSeek API 的调度、模型侧对时间语境的处理，还是其他外部因素，问题尚待进一步定位。

  3. 复杂复合指令

    当一次消息同时包含过多互相关联的要求时，也可能出现无法正常回答的情况；如果将同一任务拆成几个步骤，通常又可以正常完成。目前这一问题同样尚未被准确定位，仍需要继续判断它究竟发生在模型、API 调度还是更复杂的上下文与工具调用组合中。

现在的微信 AI 助手已经不是一个只存在于测试代码里的 Demo，而是一个能够实际运行在 Windows 微信客户端旁边、接收问题并完成真实回复的个人 AI Agent。