0 - 背景与合规边界

核心发现：个人微信第三方接入在技术上从未被”允许”过——《微信软件许可及服务协议》第 8.2.1.6 条明文禁止”通过非腾讯开发、授权的第三方软件登录或使用微信及服务，或进行自动化操作”。腾讯已用民事 260 万判赔（聚客通案，2019 浙 8601 民初 1987 号）和刑事定罪（盛央群控案，2020 粤 0703 刑初 597 号 “非法控制计算机信息系统程序罪”）双管齐下证明执法意愿。

信息源：微信官方协议原文、中国裁判文书网、ciplawyer.cn、055110.com、news.qq.com

为什么需要先看合规，再看技术

任何”个人微信自动化”的技术讨论都必须建立在一个事实之上：这是一条腾讯官方明确禁止、司法已有判例、且执法持续收紧的灰色路径。 不理解合规边界就谈 SDK 选型，等于不看刑法就谈盗窃工具选型。

这篇文件回答三个问题：

1. 腾讯的禁令具体写在哪？
2. 违反禁令的真实代价是什么（判例）？
3. 2024-2025 年的环境为什么比以往更严峻？

一、官方禁令条款原文

《微信软件许可及服务协议》

来源：https://weixin.qq.com/agreement?lang=zh_CN

条款 8.2.1.6 — 这是整个调研的核心红线：

不得通过非腾讯开发、授权的第三方软件、插件、外挂、系统，登录或使用微信及服务，或者进行自动化操作，或者制作、发布、传播上述工具、方法等。

条款 8.2.1.7：

不得自行或授权他人、第三方软件或系统等对微信软件及其组件、模块、数据进行控制、访问、读取或干扰，或规避、破坏微信软件设置的安全保护等技术措施。

一句话翻译：登录、读取、自动化——三件事都禁。 本调研涉及的所有技术方案（Web / iPad / Hook / RPA）全部落在这两条禁令范围内，没有例外。

《微信个人账号使用规范》

来源：https://weixin.qq.com/cgi-bin/readtemplate?t=page/agreement/personal_account

补充了行为层的细节：

• 1.2.4 / 1.2.8：禁止使用外挂/插件复制修改内存数据、禁止”一键转发、多开、抢红包”插件
• 3.4：禁止频繁添加好友、频繁加群等高频异常操作
• 12.3：禁止直接给他人发布营销信息造成骚扰
• 12.7：禁止头像中使用二维码引流

对技术方案的映射：

• PC Hook（wcferry / wxhelper）违反 1.2.4（内存数据修改）
• iPad 协议（PadLocal）违反 8.2.1.6（非授权第三方登录）
• UI 自动化（pywinauto）违反 8.2.1.6（自动化操作）
• 群控系统同时违反 3.4 和 12.3

二、判例：罚款 + 刑事，都真实发生过

判例 1：聚客通群控软件案（民事，判赔 260 万）

• 案号：(2019) 浙 8601 民初 1987 号
• 审理法院：杭州铁路运输法院
• 原告：腾讯计算机系统有限公司 & 腾讯科技（深圳）有限公司
• 被告：浙江搜道网络技术有限公司 & 杭州聚客通科技有限公司
• 判决：违反《反不正当竞争法》，判赔 260 万元，立即停止侵权
• 里程碑意义：首例全国性认可”微信数据权” —— 法院认定群控软件未经授权批量提取微信用户数据即属侵权，即使这些数据原本就在用户自己的账号里
• 来源：https://www.ciplawyer.cn/articles/147076.html

对项目方的启示：不是”帮用户操作自己的微信就没事”。只要你的工具让用户做了 Tencent 不允许的事（批量提取、群控），腾讯就有胜诉先例。

判例 2：盛央群聊管理软件案（刑事，非法控制计算机罪）

• 案号：(2020) 粤 0703 刑初 597 号
• 罪名：提供侵入、非法控制计算机信息系统程序罪（刑法第 285 条第 3 款）
• 涉及工具：群聊管理外挂软件
• 来源：https://www.055110.com/xs/3/18698.html

对项目方的启示：这已经不是”民事赔钱”的问题了，是刑法 285 条有期徒刑。开发销售 Hook 类工具可能直接构成刑事犯罪，不是”大不了关站”。

判例 3：PyWxDump 作者收到律师函（2024）

• 事件：xaoyaoo/PyWxDump 项目（微信数据库解密工具）作者收到律师函后主动删库
• 意义：工具类项目即使不做群控、不做营销、只做本地数据解密，一样被腾讯法务盯上。这是”个人开发者开源项目”层级被打击的最新案例
• 当前状态：原仓库 https://github.com/xaoyaoo/PyWxDump 已 404，社区 fork（如 wo1261931780/fork-PyWxDump）仍在流传

三、2024-2025 年环境为什么更严峻

三件事同时发生，叠加起来让旧方案大面积失效：

1. 2024 年 3 月 腾讯”外挂”专项打击公告

• 官方公告：https://news.qq.com/rain/a/20240327A063WC00
• 执行：限制朋友圈、加好友、群聊功能
• 检测手段：自动识别 Xposed 框架、自动化脚本特征

2. 2024 年 12 月 微信 PC 4.0 架构升级

• 从 WebView → Qt + C++ 原生跨平台架构
• 直接后果：基于 3.9.x 版本的 Hook 方案（wxhelper v3.9.8.25 等）全部失效。新版本 Hook 需要重新逆向，成本极高。详见 https://blog.csdn.net/ctips/article/details/144935367

3. 2024-2025 封号潮

• 企业微信违规封禁量同比 +47%
• 异常登录检测阈值：120 次请求/分钟即触发
• AI 质检覆盖率：预计 2025 年达到 90%
• 新注册企业账号首月限流概率：68%（2024 年为 40%）
• 典型失败案例：20 个子账号因每分钟 120 次异常登录全部被封
• 来源：https://blog.csdn.net/nanchena/article/details/155351111

四、PIPL / GDPR 叠加约束

即使不被腾讯起诉，还有数据合规法要管：

《个人信息保护法》（PIPL，2021-11-01 生效）：

• 爬取微信聊天记录、通讯录需有明确法律依据和用户同意——PIPL 不承认欧盟 GDPR 意义上的”合法利益”例外，几乎只能靠明示同意
• 违反后果：罚款可达年收入 5% 或最高 5000 万元

GDPR（欧盟用户）：

• 最高年营业额 4% 罚款
• 微信 2018-05-28 已发布过 GDPR 合规通知

这两部法律是”二次打击面”：就算你成功绕过腾讯风控，只要面向有营销或数据留存场景，合规部门就能把整个业务叫停。

五、使用场景风险分层（唯一实用的合规地图）

关键结论：如果你的业务能用企业微信 API 解决，就别碰个人号。 如果必须用个人号，把使用场景死死限制在”服务于账号持有人自己、不做任何对外营销”的范围内，把风险从”刑事”降到”账号被封”。

信息源

核心参考：

• 微信软件许可及服务协议：https://weixin.qq.com/agreement?lang=zh_CN
• 微信个人账号使用规范：https://weixin.qq.com/cgi-bin/readtemplate?t=page/agreement/personal_account
• 聚客通案判决解读：https://www.ciplawyer.cn/articles/147076.html
• 盛央群控刑案：https://www.055110.com/xs/3/18698.html
• 腾讯 2024-03 外挂打击公告：https://news.qq.com/rain/a/20240327A063WC00

补充参考：

• 微信 PC 4.0 架构分析：https://blog.csdn.net/ctips/article/details/144935367
• 2024 企业微信封号数据：https://blog.csdn.net/nanchena/article/details/155351111
• 中国裁判文书网（判例检索）：https://wenshu.court.gov.cn/

1 - 协议层方案全景

核心发现：个人微信的接入技术从 2014 年至今收敛为 6 个技术流派，但 2026 年真正还能用的只剩 3 个半——iPad 协议（PadLocal 为代表，付费）、Windows PC Hook（wcferry 为代表，高封号风险）、UI 自动化（pywinauto 类，慢但安全），以及 gRPC 中间层（本质是上述方案的代理层）。Web 协议已于 2019-07 彻底死亡，Android Xposed 门槛越来越高，Mac Hook 生态尚未成熟。

信息源：wechaty.js.org、GitHub 项目元数据、CSDN 技术方案对比、知乎 76180564/396682840

方案定位：按”操作在哪一端”分类

所有第三方接入方案，本质差异在于”你让谁去跟腾讯服务器通信”。这是唯一能理清所有方案的框架：

微信客户端生态：
  ├─ Web 版（已关闭）                 → Web 协议流派 ❌
  ├─ iPad 客户端                       → iPad 协议流派 ⭐
  ├─ Android 客户端                    → Android Xposed 流派
  ├─ iOS 客户端                        → 基本无方案（沙盒太严）
  ├─ Windows PC 客户端                 → PC Hook / RPA 流派 ⭐
  └─ Mac 客户端                        → Mac Hook 流派（萌芽）

上层（跨协议代理）：
  └─ gRPC/HTTP Bridge                  → Wechaty Puppet Service

选型的第一个问题不是”用哪个项目”，而是”你希望模拟哪一端”。模拟 iPad → 付费 PadLocal；模拟 Windows → 自己搞 Hook 或用 wcferry；模拟人类操作 → RPA。这个决定下面再选项目，否则项目卡片看不出差异。

A. Web 协议流派（已死）

代表项目：itchat（26.7k ⭐）、wxpy（14.1k ⭐）

技术原理：逆向 wx.qq.com 网页版的 HTTP 长轮询 + XML 协议。优点是轻量、无需客户端。

死亡时间线：

• 2017-09：腾讯限制新注册账户登录网页版微信
• 2019-07：腾讯彻底关闭网页版微信登录入口，全部账户失效

wxpy 官方在 2020-08-05 归档仓库，一字没留。itchat 虽未归档但已多年停更。这两个项目今天还有 40k+ star，但没有任何 2026 年可用的部署方式——连封不封号都谈不上，登录入口根本不存在了。

为什么值得提：itchat/wxpy 时代的兴起与死亡是后续所有方案的定价锚点——从那之后”Web 轻量方案”的空位一直没被填上，这是 PC Hook 和 iPad 协议能各自占据半壁江山的根本原因。

证据：https://zhuanlan.zhihu.com/p/76180564、https://www.zhihu.com/question/396682840

B. iPad 协议流派（2026 年最稳的商业方案）

代表项目：wechaty-puppet-padlocal、PadLocal（商业服务）、若干地下 iPad 协议商

技术原理：不 Hook 本地客户端，也不跑 Web——直接在服务器端模拟 iPad 客户端与腾讯服务器的通信协议（gRPC 双向流），账号状态存在协议商的云端。这是最”纯粹”的协议层方案，对本地环境零依赖。

关键优势（相对 Hook 方案）：

1. 每账号独立 IP：PadLocal 承诺每个账号走不同出口 IP，避开”一人 IP 多账号”的最强风控信号（来源：PadLocal 设计文档）
2. 云端状态，无本地客户端：Hook 方案一旦微信升级就全部失效，iPad 协议只要 iPad 协议本身不变就能继续跑
3. 官方收费有 SLA 意味：PadLocal 作为 Wechaty 官方推荐 puppet 自 2020-10 推出以来持续运营至今，比任何单个开源 Hook 项目的寿命都长
4. 能力最全：支持文本/图片/文件/语音/视频/朋友圈/群管理/@/引用回复全套能力

代价：

• 必须付费。PadLocal 采用 token 制，具体价格官网未公开，需要向 pad-local.com 询价。Wechaty 贡献者可获 1 年免费 token（来源：Wechaty 官方博客）
• 协议商即单点。如果 PadLocal 运营方停止服务，你的业务直接断电。地下 iPad 协议商（如 Gitee 上 JoeyGitee/wechat-protocol-api 等）价格便宜（SDK 3000-5000 CNY 一次性，租号 10 CNY/天），但无 SLA、无法律主体、交付普遍走飞书群/Telegram，跑路风险极高

2026 年判断：对于”必须现在就能用、预算允许、不想管客户端版本”的场景，PadLocal 是目前唯一官方出身、明面运营、能签商务合同的 iPad 协议方案。地下协议商只推荐给”短期实验 + 可接受突然失效”的场景。

证据：

• https://wechaty.js.org/2020/10/12/puppet-padlocal-intro/
• https://github.com/wechaty/puppet-padlocal
• https://wechaty.js.org/docs/puppet-services/compatibility/
• https://gitee.com/JoeyGitee/wechat-protocol-api（地下协议商样本）

C. Windows PC 客户端 Hook 流派（2026 年开源主力，封号风险最高）

代表项目：

• WeChatFerry (lich0821/WeChatFerry) — 6.5k ⭐，最后更新 2026-03-28 (v39.5.2)，1080+ commits，是整个 Hook 流派里唯一还在快速跟进微信版本的项目
• wxhelper (ttttupup/wxhelper) — 3k ⭐，但已停在 2023-12 的 v3.9.8.25 版本，不支持微信 4.x
• ComWeChatRobot (ljc545w/ComWeChatRobot) — 1.8k ⭐，停更于 2022-10
• ntchat — 2022 停更，原仓库 404

技术原理：DLL 注入到 WeChat.exe 进程，逆向内部函数（主要是 WXSendMsg 系列和消息回调），用 Hook 接管这些函数，对外暴露 HTTP（wxhelper 默认端口 19088）或 gRPC（wcferry）接口。一句话：你在本机跑着一个被劫持的真实 PC 微信，第三方程序通过本地 RPC 指挥它。

能力：wcferry 支持文本/图片/文件/语音/视频/群管理/拉人/@/引用回复/朋友圈——能力上与 iPad 协议持平。客户端语言覆盖 Python / Rust / Go / Java / Node.js / C#，是所有流派里最通用的。

三个致命问题：

问题 1：微信版本绑定地狱。 Hook 方案依赖对特定 WeChat.exe 版本的二进制偏移。微信升级一次，整个 Hook 就得重新逆向。2024-12 微信 PC 从 WebView 架构升级到 Qt + C++ 原生跨平台架构（4.x），所有停留在 3.9.x 的项目（wxhelper、ComWeChat、ntchat）一次性全部报废。只有 wcferry 因为作者持续跟进才活到了 2026-04。

问题 2：封号风险最高的流派。 一条被反复引用的数据：PC Hook 方案封号率超过 80%（来源：CSDN-146997227）。需要注意这是单一中文博客来源，没有多来源交叉验证，应作为”信号”而非”共识”看待。但触发机制是明确的——反作弊系统会检测进程注入特征（DLL 名、导入表异常），加上账号级行为风控（登录 IP 异常、消息频率异常），Hook 方案在两个检测面上都更容易被抓。

问题 3：刑事风险最高。 盛央群控案（2020 粤 0703 刑初 597）以**“提供侵入、非法控制计算机信息系统程序罪”**定罪。Hook 方案在”是否构成非法控制计算机信息系统”上的法律定性比 iPad 协议（模拟协议）和 RPA（UI 操作）更接近刑事红线。见 0-背景与合规边界.md。

2026 年判断：开源、免费、能力完整、更新快——wcferry 在纯技术层面对个人开发者极有吸引力。但封号率和刑事风险叠加起来让它只适合”小号实验 + 个人使用场景 + 不做任何群控和营销”。任何商业化部署都是拿账号和开发者自由赌运气。

证据：

• https://github.com/lich0821/WeChatFerry
• https://pypi.org/project/wcferry/
• https://github.com/ttttupup/wxhelper
• https://github.com/ljc545w/ComWeChatRobot
• https://blog.csdn.net/weixin_38861218/article/details/146997227（封号率 80%+ 数据点）
• https://blog.csdn.net/ctips/article/details/144935367（PC 4.0 架构变化）

D. Android Xposed / 虚拟机容器流派（门槛升高）

代表项目：wechatbot-xposed、WechatHook、LSPosed（现代 Xposed 框架）、LSPatch（无 Root LSPosed）、SandVXosed（VirtualApp + SandHook）

技术原理：在 Android 系统层面，通过 LSPosed/Xposed 在 Zygote 进程注入，之后所有 fork 出的 App 都可以被 hook，包括微信。或者用 VirtualApp 类容器在用户空间跑一个”假系统”，在其中运行改造过的微信 APK。

优势：移动端才是微信的主场，iOS 版虽然封闭但 Android 版一直是协议更新的首发端。理论上 Android Hook 能抓到最新协议。

劣势：

• 必须 Root 或用 LSPatch。主流手机（小米、华为、OPPO、vivo）系统级对 Root 的限制越来越严，2024 年后消费级设备很难稳定维持 Root
• 生态散乱。没有像 wcferry 那样”一家独大”的开源项目，代表项目 star 数都在 1-3k 徘徊，维护强度普遍弱
• 虚拟机容器方案（LSPatch、SandVXosed）的长期稳定性未验证：容器的设备指纹容易被腾讯识别，2024-2025 没看到大规模部署案例

2026 年判断：这个流派现在的处境很像 2017 年的 Web 协议——技术上还活着，但变成了极客玩具，无法支撑生产。除非你本身就有 Android 逆向团队，否则不建议作为首选。

E. Mac 客户端 Hook 流派（萌芽期）

代表项目：WeChatTweak（知名的”撤回拦截/多开”工具）、wechat_chatter、ReverseWechat

技术原理：利用 Objective-C Runtime 的动态特性或 Frida 框架 hook macOS 版 WeChat 的关键函数。

当前状态：

• WeChatTweak 主要做的是”撤回拦截 + 多开”这类本地功能增强，不是完整的接收-发送机器人
• wechat_chatter / ReverseWechat 都是零散的逆向项目，没有成熟的对外 API
• 2025-08 Wechaty 官方博客发布《AI-powered Reverse Engineering concept》，提出用 LLM + Frida 自动化逆向 Mac 客户端的方向，但还是 “concept” 阶段，没有可用产出

2026 年判断：这个流派有潜力但不成熟。Mac 客户端的逆向门槛介于 Windows 和 iOS 之间，如果 Frida + LLM 的方向能跑通，未来可能成为”既避开 Windows 版本绑定地狱、又不需要 Android Root”的第三条路。但现在不能用。

证据：

• https://github.com/sunnyyoung/WeChatTweak
• https://wechaty.js.org/2025/08/12/ai-powered-reverse-engineering-concept/

F. UI 自动化 / RPA 流派（最慢但最安全）

代表项目：

• pywechat (Hello-Mr-Crab/pywechat) — 基于 pywinauto 的 Windows 自动化库，支持 WeChat 4.0+（这是它相对 PC Hook 的关键优势）
• wechat-automation-api (LAVARONG/wechat-automation-api) — Flask + UIAutomation HTTP API 服务
• wechat_rpa (yfboot/wechat_rpa)

技术原理：完全不 Hook。用 Windows 的 UI Automation 框架 / pywinauto / 图像识别，像真人一样点击 PC 微信的按钮、在输入框里敲字、读屏幕上的消息列表。

关键优势：

1. 不 Hook 就不被检测进程注入特征。反作弊系统检测”WeChat.exe 是否被注入”对 RPA 无效
2. 不依赖微信版本偏移。只要 UI 结构没大变，微信从 3.9 升到 4.0 RPA 脚本基本能继续跑，甚至连代码都不用改
3. 封号率显著低于 Hook。一条公开数据：操作间隔 ≥5 秒时封号率”很低”（来源：CSDN-146997227，单一来源信号）

代价：

1. 慢。pywinauto 操作一次 UI 至少需要几百毫秒，无法支持高频消息收发
2. 必须前台可见。微信窗口必须保持在前台或可见状态（某些 UIAutomation 实现需要），无法像 Hook 那样后台静默
3. 脆弱。UI 一改动脚本就挂，需要维护 selector
4. 仍然违反 8.2.1.6。RPA 也算”自动化操作”，合规上不比 Hook 清白，只是检测更难

2026 年判断：对于”功能简单 + 对实时性要求低 + 自用场景”——比如”每天早上 9 点把一个公众号的内容转发到固定的 5 个群”这种——RPA 是 2026 年最实际可行的方案。它完美避开了 PC Hook 的封号率和刑事风险，代价只是”慢”。不要用它做群控，但用它做个人助理足够。

证据：

• https://github.com/Hello-Mr-Crab/pywechat
• https://github.com/LAVARONG/wechat-automation-api
• https://blog.csdn.net/weixin_38861218/article/details/146997227

G. HTTP Bridge / gRPC 中间层流派（本质是代理）

代表项目：wechaty-puppet-service、wechaty-grpc、matrix-appservice、OpenAPI for Wechaty Puppet

技术原理：把上述任何一个流派（Web/iPad/PC Hook/Android）统一封装成 gRPC 或 RESTful HTTP 接口，让上层应用不用关心具体协议实现。Wechaty 框架本身就是这种”puppet 抽象层”的代表——你换个 puppet（wechaty-puppet-padlocal ↔ wechaty-puppet-wxwork ↔ wechaty-puppet-xp），上层代码不需要改动。

本质：这不是一个新的协议层方案，而是跨协议的代理层。 风险继承自下游。上层用了 PadLocal puppet，风险就是 PadLocal 的中等风险；下层换成某个 PC Hook puppet，风险就变回极高。

为什么值得单独列：

• 如果你写一个项目，最合理的架构是把业务逻辑写在 Wechaty 之上，这样未来可以在不同 puppet 之间切换，避免被某一个协议绑死
• Wechaty 社区有完整的多语言 SDK（TS/Python/Go/Java），gRPC + TLS + Token 认证是工程化就绪的

2026 年判断：如果你决定做这件事，默认就应该用 Wechaty 作为上层抽象。具体 puppet 选 PadLocal（付费、稳）还是 puppet-xp（开源社区 Windows Hook 类）再按预算和风险偏好定。

跨流派对比矩阵

给 2026 年决策者的三条路径

路径 1：合规第一，能用企业微信就用企业微信。 如果业务场景允许用企业微信官方 OpenAPI，这是唯一真正合规的路径，放弃个人号纠结。跳出本调研范围。

路径 2：预算充足、需要稳定、可商务合作 → Wechaty + PadLocal。 这是目前个人微信接入里的”商业正规军”。会付钱，但能换到 2020 年至今 5 年持续运营的单点可靠性，以及能力完整的 SDK 和多语言生态。适合做产品。

路径 3：预算为零、可承受账号风险、自用场景 → RPA 或 wcferry。 其中：

• 自用助理/记忆备份/被动接收：选 pywechat（RPA），合规风险和封号风险都最低
• 需要主动发送、能接受封号赌博：选 wcferry，但只用小号、消息间隔 ≥5 秒、日消息数 ≤200、不碰群发营销

信息源

核心参考：

• Wechaty 官方文档与博客：https://wechaty.js.org/
• Wechaty puppet 兼容性矩阵：https://wechaty.js.org/docs/puppet-services/compatibility/
• WeChatFerry GitHub：https://github.com/lich0821/WeChatFerry
• 技术方案对比（封号率数据来源）：https://blog.csdn.net/weixin_38861218/article/details/146997227
• 微信 PC 4.0 架构分析：https://blog.csdn.net/ctips/article/details/144935367

补充参考：

• Web 协议关闭时间线：https://zhuanlan.zhihu.com/p/76180564、https://www.zhihu.com/question/396682840
• PadLocal 设计理念：https://wechaty.js.org/2020/10/12/puppet-padlocal-intro/
• Mac Hook 最新进展：https://wechaty.js.org/2025/08/12/ai-powered-reverse-engineering-concept/
• pywechat（RPA 代表项目）：https://github.com/Hello-Mr-Crab/pywechat

2 - 开源项目深度对比

核心发现：2026 年值得考虑的开源项目只有两个半——Wechaty 生态（22.7k ⭐，TypeScript 抽象层 + 多 puppet）和 WeChatFerry（6.5k ⭐，2026-03-28 更新到 v39.5.2，唯一还在跟进微信 4.x 的 Hook 项目），加上半个”pywechat 类 RPA 项目”。其余曾经有名的项目（ntchat、wxhelper、ComWeChatRobot）全部卡在微信 3.9.x 时代，无法支持 2024-12 之后的 PC 4.0 新架构。

信息源：GitHub 仓库元数据（stars、commits、issues、last-update）、PyPI 发布记录、项目 README

读这份对比之前

不要把”star 数高”当成”今天能用”。itchat 26.7k ⭐、wxpy 14.1k ⭐，这两个项目名气最大但 2019 年就跟着 Web 协议一起死了。今天活着的开源项目只能按”最后一次 commit 时间 + 是否支持微信 4.x”来筛，其他指标都是次要。

下面的对比严格按”2026 年能不能拿来做项目”这一个问题展开。

一线候选：两个还在动的项目

Wechaty 生态（wechaty/wechaty）

基础面：

• GitHub：https://github.com/wechaty/wechaty
• Stars：22.7k
• 状态：2026 年持续活跃，177 open issues，17 open PRs，未 archived
• 语言：TypeScript/JavaScript 主力，多语言 SDK（Python、Go、Java）

定位：不是一个单一 Hook 项目，而是”微信接入的抽象层框架”。Wechaty 本身不实现任何协议，它定义一套 Puppet 接口，让不同协议实现方作为插件接入。这是它能活 5 年以上的根本原因——协议失效时换个 puppet 就行，框架本身不死。

2026 年还在官方支持的 Puppet：

能力：文本、图片、文件、语音、视频、朋友圈、群管理、拉人、@、引用回复——全套支持，通过 puppet 差异化实现。

商业化：Wechaty 框架本身 Apache-2.0 开源免费。PadLocal puppet 的 token 需向 pad-local.com 购买（价格未公开），Wechaty 贡献者可获 1 年免费 token。

选它的理由：

1. 抽象层设计让协议切换成本低。今天用 PadLocal，未来如果 PadLocal 涨价或失效，可以换成 puppet-xp 或 Paimon，上层业务代码基本不动
2. 多语言 SDK。TypeScript/Python/Go/Java 全有，可以用任何技术栈对接
3. 5 年持续运营。对比任何单一 Hook 项目，Wechaty 是唯一一个从 2018 年活到 2026 年都没断的

不选它的理由：

1. 真正稳定的 puppet 是付费的 PadLocal。免费的社区 puppet 稳定性和能力参差不齐
2. 架构较重。如果只是要一个 Python 脚本发几条消息，Wechaty 全家桶偏重

证据：

• https://github.com/wechaty/wechaty
• https://wechaty.js.org/docs/specs/puppet
• https://wechaty.js.org/docs/puppet-services/compatibility/
• https://github.com/wechaty/puppet-padlocal

WeChatFerry (lich0821/WeChatFerry)

基础面：

• GitHub：https://github.com/lich0821/WeChatFerry
• Stars：6.5k
• 最后更新：2026-03-28 (v39.5.2)
• 1080+ commits，Open Issues 仅 2，Open PRs 0——维护跟得很紧
• 状态：未 archived，高度活跃

定位：Windows PC 客户端的 DLL Hook 方案。C++ 核心注入 WeChat.exe，通过 NanoRPC 暴露接口，客户端 SDK 支持 Python / Rust / Go / Java / Node.js / C#——客户端语言覆盖是开源项目里最广的。

支持的微信版本：严格版本绑定。官方 Releases 按微信客户端版本分别打包（v3.9.12.17、v4.0.x、v4.1.x 等），每次微信升级都要等 wcferry 作者适配。2026-03 的 v39.5.2 已经跟上了最新的微信 4.1.x。

能力：文本/图片/文件/语音/视频/群管理/拉人/@/引用回复/朋友圈——全套。能力上与 Wechaty+PadLocal 持平。

选它的理由：

1. 唯一跟上微信 4.x 的开源 Hook 项目。wxhelper、ComWeChat、ntchat 全部掉队，只剩它
2. 完全免费开源。没有付费 token 环节
3. 客户端语言选择最多。用 Python 写业务 + Rust 写核心数据处理都能组合
4. 作者 lich0821 维护很积极。Open issues 只有 2 个，响应速度在开源界算非常快

不选它的理由 —— 这是关键：

1. 封号风险是所有方案里最高的。单一来源数据点称 Hook 方案封号率 >80%（CSDN-146997227）。即使打折看，Hook 的进程注入特征也是最容易被反作弊系统抓的
2. 刑事风险面最广。盛央群控案的定罪依据”非法控制计算机信息系统程序罪”，在法律定性上最接近 Hook 类工具
3. 微信版本绑定地狱。微信 2026 年接下来的任何一次大版本升级，都可能让 wcferry 失效几天到几周
4. 只有 Windows。需要长期维护一台 Windows 机器跑 WeChat.exe + wcferry 核心

证据：

• https://github.com/lich0821/WeChatFerry
• https://github.com/lich0821/WeChatFerry/releases
• https://pypi.org/project/wcferry/
• https://wcferry.netlify.app/

二线候选：特殊用途，不是完整方案

pywechat (Hello-Mr-Crab/pywechat) 及 RPA 类项目

定位：不是 Hook、不是协议——是 pywinauto 包装层。核心优势是”支持微信 4.0+“，因为它通过 Windows UI Automation 操作界面，不依赖二进制偏移。

为什么值得列：所有 Hook 项目都在微信 4.0 面前摔倒，RPA 项目却毫发无损，因为 UI 变了几个按钮对 UIAutomation 脚本来说不过是更新几个 selector。

能力限制：

• 速度慢（UI 操作几百毫秒起步）
• 无法抓取历史消息
• 对朋友圈、复杂群操作支持弱
• 必须保持微信窗口前台可见

选它的场景：个人自用助理、定时任务、低频消息处理。不要用它做任何需要高频响应或大规模群操作的场景。

证据：https://github.com/Hello-Mr-Crab/pywechat、https://github.com/LAVARONG/wechat-automation-api

墓地：这些名字还在但不要碰

共同特征：全部停在微信 3.9.x 时代。2024-12 微信 PC 升级到 4.0（Qt + C++ 架构）是一个大屠杀——一次架构升级让整个中间层 Hook 生态报废。这是整个调研最关键的”外部事件 → 方案存亡”映射。

PyWxDump 的特殊意义：它被打击的时候不是一个自动化/机器人项目，只是一个本地数据库解密工具。收到律师函仍然删库。这是”即使不做违规业务、只是做灰色工具就可能被法务盯上”的最新案例。见 0-背景与合规边界.md。

对比矩阵

给选型决策者的一句话

如果要做产品 → Wechaty + PadLocal（预算充足）或 Wechaty + puppet-xp（预算为零但接受 Hook 风险） 如果要写个人脚本 → pywechat（RPA）优先，wcferry 作为性能升级选项但必须用小号 如果在对比 wxhelper / ComWeChat / ntchat → 统统不要选，这些项目在微信 4.0 面前已经报废

信息源

核心参考：

• Wechaty GitHub：https://github.com/wechaty/wechaty
• WeChatFerry GitHub：https://github.com/lich0821/WeChatFerry
• WeChatFerry PyPI：https://pypi.org/project/wcferry/
• Wechaty Puppet 兼容矩阵：https://wechaty.js.org/docs/puppet-services/compatibility/
• pywechat GitHub：https://github.com/Hello-Mr-Crab/pywechat

墓地参考（验证停更时间用）：

• itchat: https://github.com/littlecodersh/ItChat
• wxpy: https://github.com/youfou/wxpy
• ntchat: https://github.com/smallevilbeast/ntchat
• ComWeChatRobot: https://github.com/ljc545w/ComWeChatRobot
• wxhelper: https://github.com/ttttupup/wxhelper

对比类文章：

• 微信 AI 机器人方案对比：https://blog.csdn.net/weixin_38861218/article/details/146997227
• 知乎微信机器人全系列：https://zhuanlan.zhihu.com/p/1891472259190862807
• 掘金微信机器人搭建：https://juejin.cn/post/7179140844073680954

3 - 商业方案与 Puppet 服务

核心发现：商业化的个人微信接入市场分成”正规军（Wechaty + PadLocal，明面运营、可签合同、5 年持续服务）“和”地下协议商（飞书群/QQ 群/Telegram 交付，SDK 3000-5000 CNY 一次性或 10-100 CNY/月租号，无 SLA、随时跑路）“两极。PadLocal 是目前唯一值得进入商业评估流程的商业方案，因为它背靠 Wechaty 官方生态、有公开的技术文档和运营主体。地下协议商只在”短期实验 + 可接受随时失效”的场景下才能用。

信息源：pad-local.com、wechaty.js.org、Gitee 协议商样本、GitHub 商业化项目

商业方案的三个层级

个人微信接入的”商业方案”一词含义混乱，先区分清楚：

Level 1: 官方出身的商业 Puppet
  └─ PadLocal (Wechaty 官方推荐，付费 token)

Level 2: 地下 iPad 协议商
  ├─ Gitee 上的半开源样本（如 JoeyGitee/wechat-protocol-api）
  ├─ 飞书/QQ 群交付的闭源 SDK
  └─ 租号服务

Level 3: 基于企业微信的 CRM/SCRM 集成
  ├─ 灵当 CRM
  ├─ 询盘云 CRM
  └─ MoChat SCRM
     ⚠️ 注：这些基于企业微信而非个人微信，不在本调研范围

只有 Level 1 和 Level 2 属于”个人微信接入的商业方案”。Level 3 是走官方开放平台的合规路径。

Level 1：PadLocal（值得评估的唯一选项）

基本面

• 官网：http://pad-local.com/
• 文档：https://wechaty.readthedocs.io/zh-cn/latest/introduction/use-padlocal-protocol/
• 运营主体：Wechaty 社区官方推荐的商业 puppet 供应商
• 首次推出：2020-10（Wechaty 官方博客宣布）
• 2026 年状态：持续运营，社区仍在活跃使用

技术实现

• 协议层：iPad 协议（服务器端模拟 iPad 客户端与腾讯通信）
• 对接方式：gRPC 双向流
• 集成方式：作为 wechaty-puppet-padlocal npm 包集成进 Wechaty 框架
• 独立 IP：承诺每个账号走不同出口 IP（避开”同 IP 多号”最强风控信号）

商业模式

• 计价：按 token 收费
• 具体价格：官网未公开定价，需联系 pad-local.com 询价
• 特别条款：Wechaty 贡献者可获 1 年免费 token
• 试用：曾提供”7 天免费 Token”，当前政策需核实

选它的理由

1. 5 年持续运营。从 2020-10 的首次发布到 2026 年仍在维护，是个人微信商业方案里运营周期最长的
2. 官方出身。Wechaty 官方在自己的文档、博客、兼容性矩阵里明面推荐，有品牌信誉背书
3. 能力最完整。文本/图片/文件/语音/视频/朋友圈/群管理/@/引用回复全套
4. 独立 IP 隔离。这是地下协议商大多做不到的
5. 法律层面相对干净。协议模拟的定性比 PC Hook 的”非法控制计算机”要轻

不选它的理由

1. 必须付费。具体价格不透明是明显的商务缺陷
2. 单点失效风险。PadLocal 一旦停服或涨价，上层业务只能换方案
3. 协议模拟仍违反 8.2.1.6。“干净”只是相对概念，合规层面仍然不合规
4. 性能瓶颈。gRPC 经过中间云服务商，延迟比本地 Hook 高

典型决策场景

• ✅ 要做产品、要签合同、需要技术支持 → PadLocal
• ✅ 希望未来能换 puppet 不改代码 → Wechaty + 任意 puppet（PadLocal 是首选）
• ❌ 只是要做个人助理脚本、预算为零 → 选 pywechat 或 wcferry，见 2-开源项目深度对比.md

证据

• https://wechaty.js.org/2020/10/12/puppet-padlocal-intro/
• https://github.com/wechaty/puppet-padlocal
• https://wechaty.readthedocs.io/zh-cn/latest/introduction/use-padlocal-protocol/
• http://pad-local.com/

Level 2：地下 iPad 协议商（高风险短命方案）

市场结构

• 典型供应商：Gitee 上的 JoeyGitee/wechat-protocol-api、GitHub 上的 wechatsdkfactory/wechat.ipad.api 等半开源样本项目
• 交付渠道：飞书群、QQ 群、Telegram，通常需要签保密协议
• 主体：匿名或小团队运营，无公开运营主体

典型定价（来自 Agent 调研的公开页面）

技术特征

• 基于 iPad 微信 8.0.7 / 安卓 8.0.6 协议开发
• 号称持续更新 3 年
• 号称实现 80% 微信功能（朋友圈、群组、消息、加好友等）
• 接口通常是 HTTP API + Java/Python/Node.js SDK

为什么风险远高于 PadLocal

1. 无 SLA、无法律主体：合同都没法签，业务出问题找不到人
2. 跑路是常态：黑灰产圈的常见模式——收钱、交付、半年后停更、换个号继续卖
3. 账号活率不稳定：没有独立 IP 隔离，批量账号容易被关联封号
4. 合规黑洞：你的业务方一旦被腾讯起诉，地下协议商不会出庭作证
5. 可能涉及黑产产业链：你的 token 可能和薅羊毛、诈骗号混用，被牵连

什么情况下值得用

短期实验且可接受方案随时失效——比如”下周做个 MVP 验证产品假设，跑通就上线企业微信版本”这种。严格不推荐任何长期部署。

证据

• https://gitee.com/JoeyGitee/wechat-protocol-api
• 其他供应商是半地下状态，无稳定链接，此处不列

Level 3：企业微信 CRM/SCRM（不在本调研范围但要提）

为什么在这里提：当用户搜”个人微信接入方案”时，常被引导到这类企业微信 CRM 产品，需要一句话解释为什么它们不是个人微信方案。

代表产品：

• 灵当 CRM (leadscloud.com)：支持企业微信 + 个人微信对接
• 询盘云 CRM：2024 年新增企业微信集成
• MoChat SCRM (mo.chat)：开源 + SaaS 双模式

它们的本质：构建在企业微信的官方 OpenAPI 之上，而不是对个人微信做逆向接入。这是腾讯明面开放、合规合法的路径。

和个人微信的差别：

• ✅ 完全合规，腾讯不会封号不会起诉
• ✅ 有官方文档和技术支持
• ❌ 需要企业资质开通企业微信
• ❌ 用户端看到的是”企业微信”而非”个人微信”，沟通体验不同
• ❌ 功能边界由企业微信 API 划定，不能做所有个人微信能做的事

对”小龙虾”类业务的启示：如果你的业务场景可以在企业微信内跑——客户用企业微信加你的企业号、你用 API 自动回复和管理——应该直接走企业微信方案，完全避开本调研讨论的所有灰色技术。本调研只在”业务必须用个人微信”的前提下才有意义。

对商业方案的总判断

一句话：PadLocal 是唯一一个”值得进入采购流程”的商业方案。地下协议商是短命实验品。企业微信 CRM 是合规路径但不在本调研范围。

如果必须做个人微信的商业化产品：

1. 上层用 Wechaty 框架（TypeScript/Python SDK 都行）
2. 默认 puppet 选 PadLocal
3. 预留”切换 puppet”的架构弹性，避免单点绑死
4. 把使用场景限制在非营销、非群控——这是把刑事风险降到民事风险的唯一办法
5. 准备好”PadLocal 一旦涨价或停服，业务要怎么快速迁移”的应急预案

信息源

核心参考：

• PadLocal 官网：http://pad-local.com/
• PadLocal 文档：https://wechaty.readthedocs.io/zh-cn/latest/introduction/use-padlocal-protocol/
• Wechaty puppet-padlocal GitHub：https://github.com/wechaty/puppet-padlocal
• PadLocal 推出博客（2020-10）：https://wechaty.js.org/2020/10/12/puppet-padlocal-intro/

补充参考：

• 地下协议商样本：https://gitee.com/JoeyGitee/wechat-protocol-api
• 灵当 CRM：https://www.leadscloud.com/
• MoChat SCRM：https://mo.chat/
• WeChatFerry（对照的免费开源方案）：https://wcferry.netlify.app/

4 - 官方通道：WorkBuddy 与 微信 ClawBot 插件

核心发现：2026 年 3 月是个人微信接入历史的分水岭。2026-03-09 腾讯云发布桌面 AI Agent 工作台 WorkBuddy（兼容 OpenClaw），2026-03-12 WorkBuddy 上线”微信直连”能力，2026-03-22 微信 App 内上线官方 ClawBot 插件（微信 → 我 → 设置 → 插件 → 微信 ClawBot，灰测中），底层协议叫 iLink（智联），接入域名 ilinkai.weixin.qq.com。这是微信有史以来第一次为个人账号开放官方的 Bot API——此前开发者只能通过逆向和 Hook，有真实刑事判例。

信息源：news.qq.com、cloud.tencent.com、zhuanlan.zhihu.com、runoob.com、github.com/hao-ji-xing/openclaw-weixin、ithome.com、caixinglobal.com

为什么这件事改变了整个选型逻辑

2017 年 Web 协议关闭之后，个人微信接入陷入了 9 年的无官方 API 状态，所有方案（iPad 协议、PC Hook、Android Xposed、RPA）全部是灰色逆向。2026-03 的两个发布——WorkBuddy 与 ClawBot 插件——第一次把”官方合规”四个字摆到个人微信接入的选项里。对”小龙虾”（OpenClaw）这类 Agent 来说，这相当于从”被腾讯通缉的灰色工具”变成”腾讯合作推广的合法入口”。

但这不是”灰色方案全部死亡”——官方方案有明确的能力边界（见下文），社区开发者已经在 2 周内做出了多个增强版来补齐官方砍掉的能力。官方方案和社区方案一起看才是完整图景。

方案 A：WorkBuddy（桌面 Agent + 微信客服号转发）

发布时间线

• 2026-03-09 腾讯云官宣 WorkBuddy —— “一站式 AI 原生桌面智能体工作台，兼容 OpenClaw”
• 2026-03-12 微信直连上线，全量开放
• 即日起 至 2026-03-31 面向国内版用户，注册赠送 5000 Credits 体验补贴

技术原理

一句话：WorkBuddy 在你的电脑上跑一个桌面 Agent 运行时，同时通过”微信客服号”作为转发跳板——你手机微信发一条消息给绑定的客服号 → WorkBuddy 桌面端收到 → 调 OpenClaw / 本地模型执行任务 → 结果写回微信。执行全程在本机完成，数据不出机器（官方原话）。

关键约束：必须保证电脑开机、WorkBuddy 进程常驻。一关机整条链路就断了。

能力边界

• 支持的模型：内置 MiniMax、GLM、Kimi、DeepSeek 四家国内主流
• 不支持：自定义接入其他模型（含海外 Claude / GPT 等）
• 支持的 IM 入口：微信、企业微信、QQ、飞书、钉钉（2026-03-12 起支持个人微信）
• 任务类型：查资料、写文案、处理文件、自动化办公、VibeCoding 等——本质是 OpenClaw Skills 的能力范围

适用场景

• 个人用户希望有一个”遥控办公电脑的 AI 助手”，场景偏工作/学习
• 预算为零但能接受”电脑必须开机”的约束
• 不需要海外模型、对数据不出本机有要求
• 不想折腾逆向工具和 Hook

不适用场景

• 需要自定义模型（特别是 Claude / GPT-4）
• 没有长期运行的桌面环境
• 需要深度自定义 UI、做产品化封装
• 需要群聊能力（WorkBuddy 当前走的是”微信客服号”路径，不覆盖群）

信息源

• 腾讯新闻 2026-03-12：https://news.qq.com/rain/a/20260312A06AD200
• 腾讯云开发者社区使用指南：https://cloud.tencent.com/developer/article/2638410
• 21 经济网报道：https://www.21jingji.com/article/20260312/herald/1c2a78c155be541c45a6fc655ba2ae0e.html
• Pandaily 英文报道：https://pandaily.com/tencent-s-work-buddy-agent-tool-adds-direct-we-chat-integration
• 实测文章：https://cloud.tencent.cn/developer/article/2639049

方案 B：微信 ClawBot 插件（iLink 协议，真·官方 Bot API）

发布时间线

• 2026-03-22 微信 8.0.70 iOS 版上线 ClawBot 插件入口（灰测）
• 2026-03-24 官方接入指南发布（腾讯新闻、菜鸟教程、阿里云文档同步）
• 安装命令：npx -y @tencent-weixin/openclaw-weixin-cli@latest install
• 底层 NPM 包：@tencent-weixin/openclaw-weixin（41 个 TypeScript 源文件，完整实现 iLink Bot 协议）
• 接入域名：ilinkai.weixin.qq.com

技术原理：iLink（智联）协议

这是一个纯协议层的官方 Bot API，和 WorkBuddy 的”桌面转发跳板”架构完全不同。你的 OpenClaw / AI Agent 直接和腾讯的 iLink 服务器建 HTTP 长轮询，不需要电脑常驻，不需要扫码后挂机维持会话。

iLink 核心能力（基于社区对官方包 @tencent-weixin/openclaw-weixin 的反编译整理，见 hao-ji-xing/openclaw-weixin/weixin-bot-api.md）：

限制（关键）

这是 2026 年 4 月版本的官方限制，也是社区增强版项目存在的根本原因：

1. 仅限本人使用：其他微信用户无法添加你的 Bot 为好友。Bot 只服务 Token 持有者自己
2. 不支持群聊：官方文档明确说明。源码里有 group_id 字段和 ChatType: "direct" 注释，暗示未来可能开放，当前未启用
3. 单向消息通道 / 不做自动化：腾讯明确定义 iLink 为”消息传输通道”，不对用户微信账号做任何自动化操作（对比 Hook 方案的核心差异）
4. 无历史消息 API：只有游标增量机制，不能拉取历史聊天记录
5. 无 Webhook 推送：只支持 pull（长轮询），无 push
6. 只支持文字消息（截至 2026-04-10）：虽然协议定义了图片/语音/文件/视频，但官方 CLI 版本当前实际只开放文本。社区项目 SiverKing/weixin-ClawBot-API 的 README 确认”仅支持文本消息，图片/语音/文件等媒体消息需额外实现 CDN 加密上传流程”。语音和图片支持在排期中但无具体时间
7. 需要 OpenClaw 账号体系：登录流程连接腾讯 iLink 服务器，可能需要通过 OpenClaw 平台审核或注册
8. 系统要求：微信 8.0.70+ iOS 版（安卓开放较少）

安装步骤（标准方法）

# 前置条件：本机已部署 OpenClaw
npx -y @tencent-weixin/openclaw-weixin-cli@latest install
# 终端弹出二维码，用绑定的微信扫码

Windows 专用路径（npx 检测失败时）：

openclaw plugins install "@tencent-weixin/openclaw-weixin"
openclaw config set plugins.entries.openclaw-weixin.enabled true
openclaw channels login --channel openclaw-weixin

如果标准安装失败：在 ~/.openclaw/openclaw.json 里加白名单 "plugins": { "allow": ["openclaw-weixin"] }，或用官方提供的 cli.mjs 备选脚本。

腾讯的官方定性（ClawBot 使用条款）

• 腾讯仅提供消息传输通道，不存储对话内容
• 不对 AI 生成结果负责
• 保留随时终止服务权（条款 7.2）
• 可拦截/限速特定 AI 服务接入

翻译一下：这是”官方默许的合规灰区”，不是”永久保证的开放 API”。腾讯的姿态是”我给你个口子用，你别滥用，滥用我随时关”。这对做商业产品的决策者是一个关键风险提示——基础设施级的依赖应该有 fallback。

信息源

• 官方接入域名：https://ilinkai.weixin.qq.com（API 端点）
• 菜鸟教程接入指南：https://www.runoob.com/ai-agent/openclaw-weixin.html
• IT 之家官方教程：https://www.ithome.com/0/931/431.htm
• 腾讯云开发者社区：https://cloud.tencent.com/developer/article/2644003
• 社区对 iLink 协议的反编译文档：https://github.com/hao-ji-xing/openclaw-weixin/blob/main/weixin-bot-api.md
• 阿里云接入文档：https://help.aliyun.com/zh/simple-application-server/use-cases/openclaw-integrated-wechat
• Caixin 英文报道：https://www.caixinglobal.com/2026-03-10/tencent-moves-to-bring-openclaw-ai-assistant-into-wechat-102421338.html
• 腾讯新闻 2026-03-24：https://news.qq.com/rain/a/20260324A0651I00

WorkBuddy vs ClawBot 插件：选哪个？

两者是不同层次的方案，不是”二选一”：

给决策者的直接建议：

• 你只是个人用户要个”能用的 AI 助手” → WorkBuddy，10 分钟配完
• 你要做产品 / 要用 Claude / GPT / 要自己控制 Agent 逻辑 → 微信 ClawBot 插件（iLink）+ 自己的 OpenClaw 部署
• 你的需求超出官方限制（多号、群聊、完整媒体、Web 管理） → 看 5-社区增强版对比.md

对比历史方案

官方通道上线后，1-协议层方案全景.md 和 2-开源项目深度对比.md 里讨论的那些历史方案并没有消失，但定位发生了根本变化：

核心逻辑：有官方通道之后，继续使用灰色方案的唯一理由只剩”官方通道满足不了你的需求”。而官方通道的限制（仅本人、无群聊、仅文本、需 OpenClaw 账号）恰恰是社区项目的存在理由——见下一个文件。

信息源汇总

核心：

• WorkBuddy 发布：https://news.qq.com/rain/a/20260312A06AD200
• ClawBot 插件官方教程：https://www.ithome.com/0/931/431.htm
• iLink 协议反编译文档：https://github.com/hao-ji-xing/openclaw-weixin/blob/main/weixin-bot-api.md
• 官方 NPM 包：@tencent-weixin/openclaw-weixin

补充：

• Caixin Global 英文报道：https://www.caixinglobal.com/2026-03-10/tencent-moves-to-bring-openclaw-ai-assistant-into-wechat-102421338.html
• 知乎 WorkBuddy 教程：https://zhuanlan.zhihu.com/p/2017886644569666895
• 知乎 ClawBot 踩坑：https://zhuanlan.zhihu.com/p/2019077006235554955
• 菜鸟教程接入：https://www.runoob.com/ai-agent/openclaw-weixin.html
• 阿里云文档：https://help.aliyun.com/zh/simple-application-server/use-cases/openclaw-integrated-wechat
• 腾讯新闻 2026-03-23：https://news.qq.com/rain/a/20260323A05YN200
• 36Kr Eu：https://eu.36kr.com/zh/p/3739641264177155
• 证券时报：https://www.stcn.com/article/detail/3690456.html
• TMTPost QClaw：https://en.tmtpost.com/post/7919808

5 - 社区增强版对比（基于官方 iLink / 其他路径）

核心发现：2026-03 官方 ClawBot 插件上线后不到一个月，GitHub 上已经涌现 7 个以上社区项目。它们分两个阵营：真·官方 iLink 增强版（围绕官方协议补齐多号/Web 管理/任意模型/Go SDK 等能力）和 非 iLink 路径的老方案（代理服务、企业微信原生 API、iPad 协议）仍在继续维护。关键区分：名字里有 wechat/weixin 不代表就是官方 ClawBot 路线。

信息源：GitHub 仓库 README 与源码（SiverKing、ImGoodBai、Johnixr、daemon365、freestylefly、dingxiang-me、hao-ji-xing）

阅读指南：先分清路线

社区项目命名非常混乱（几乎全叫 xxx-wechat / xxx-weixin / xxx-clawbot），必须按技术路径分类才能看懂：

路线 1：官方 iLink 协议增强版（= 真·ClawBot 社区版）
  ├─ hao-ji-xing/openclaw-weixin        (协议文档 + 参考实现)
  ├─ SiverKing/weixin-ClawBot-API       (免 OpenClaw + 任意模型)
  ├─ ImGoodBai/WeClawBot-ex (clawbnb-hub) (多号并发 + Web 管理)
  ├─ Johnixr/claude-code-wechat-channel (Claude Code 桥接)
  └─ daemon365/weixin-clawbot           (Go SDK，完整协议)

路线 2：非 iLink 的代理 / 老方案（仍活跃，但不是官方 ClawBot）
  ├─ freestylefly/openclaw-wechat       (走代理 + iPad/Mac 模拟)
  └─ dingxiang-me/OpenClaw-Wechat       (走企业微信原生 API)

这个区分很重要：如果你奔着”官方合规通道”选方案，只能从路线 1 里挑。路线 2 的项目质量也不差，但性质上回到了灰色方案，合规风险继承自 PadLocal / 企业微信各自的定位。

路线 1：官方 iLink 协议增强版

1.1 hao-ji-xing/openclaw-weixin（协议文档）

定位：不是一个工具，是官方协议的社区反编译文档。对官方 NPM 包 @tencent-weixin/openclaw-weixin 的 41 个 TypeScript 源文件做了完整分析，产出了 weixin-bot-api.md——目前最权威的 iLink Bot 协议参考。

价值：

• 谁要自己重写 iLink 客户端（Python / Go / Rust / Java 任意语言），这份文档是起点
• 谁要评估官方协议的未来能力（比如”群聊到底开不开放”），这份文档里有源码级的证据（group_id 字段 + ChatType: "direct" 注释）
• 谁要理解 iLink 的数据流（长轮询、游标、CDN 加密上传、context_token 会话绑定），这里面都有

适用：需要深度协议理解的开发者；不需要直接跑代码的人

1.2 SiverKing/weixin-ClawBot-API — 免部署 + 任意模型

基础面：

• Stars：28
• 最后提交：2026-03-28（V2 版本）
• 语言：Python (62.6%) + JavaScript (37.4%)

核心价值：官方 ClawBot 插件要求你本机部署 OpenClaw，这个项目绕过了这个要求。直接连腾讯的 ilinkai.weixin.qq.com，相当于把 iLink 协议从 OpenClaw 生态里”拆”出来了。

相对官方的增量：

适用场景：

• 你想用 Claude / GPT 而不是国内几家大模型
• 你不想为了接微信先部署整个 OpenClaw
• 你要做一个”iLink → 任意 AI API”的薄桥接

不适用：

• 需要图片/语音/文件消息
• 需要多账号并发

安装：

# Python 方案
pip install aiohttp requests
python bot.py

# Node.js 18+ 方案
node bot.js

# 懒人方案：Releases 里有打包好的 exe

URL：https://github.com/SiverKing/weixin-ClawBot-API

1.3 ImGoodBai/WeClawBot-ex（clawbnb-hub）— 多号并发 + Web 管理

基础面：

• Stars：114
• Forks：41
• 最后提交：2026-03-22（30 次提交）
• 语言：TypeScript 99.7%
• 要求：OpenClaw ≥2026.3.22，Node ≥22.16.0

核心价值：破掉官方”一次只能一个微信扫码”的硬限制。官方 ClawBot 插件的 bot_token 和一个微信号强绑定，做多号运营要么手动切要么换机器。这个项目做了多账号运行时调度，一个 OpenClaw 实例管理多个 iLink 会话，配本地 Web 控制台（默认 127.0.0.1:19120）。

相对官方的增量：

• ✅ 多微信账号同时扫码、同时登录、同时对话
• ✅ 本地 Web 控制台（账号管理 + 扫码入口 + 状态监控）
• ✅ 可选公开档案链接生成
• ✅ 与平台堆栈可选集成（通过 MOLT_APP_BASE_URL 环境变量）
• ✅ 租赁中继 + 代理提供者

核心模块：

• clawbnb-weixin 频道运行时
• 本地 Web 控制台（DemoService，127.0.0.1:19120）

适用场景：

• 你需要同时管理多个微信 Bot（开发测试、多租户、小规模运营）
• 你希望有一个 Web UI 查看每个 Bot 的状态，而不是看终端日志
• 你能接受必须通过 OpenClaw 插件体系安装

不适用：

• 只有单账号需求（官方 CLI 已经够用）
• 不想装 OpenClaw

安装：

# 目前暂未发布到 npm，需从源码安装
cd clawbnb-hub && npm install
openclaw plugins install .

URL：https://github.com/ImGoodBai/WeClawBot-ex

1.4 Johnixr/claude-code-wechat-channel — Claude Code ↔ 微信桥接

基础面：

• Stars：247
• 最后提交：2026-03-22
• 语言：TypeScript 92.1%
• License：MIT

核心价值：把微信变成 Claude Code 的对话前端。通过 MCP Channel Protocol 扩展，让 Claude Code 的一个会话可以从微信收输入、往微信返响应——本质是把手机当 Claude Code 的远程终端。

技术栈：

WeChat (iOS) → ClawBot → iLink API → Plugin → Claude Code Session
                                        ↕
Claude Code ← MCP Channel Protocol ← wechat_reply tool

基于的官方 API：

• ilink/bot/getupdates（长轮询收消息）
• ilink/bot/sendmessage（发消息）
• ilink/bot/get_bot_qrcode（QR 登录）

限制：

• 需要 --dangerously-load-development-channels 标志（research preview 状态）
• iOS 独占
• 单 Agent 实例对单 ClawBot 连接（不支持多会话）
• Session 依赖

前置要求：Node.js ≥18 或 Bun ≥1.0、Claude Code ≥2.1.80、Anthropic API key

适用场景：

• 你是 Claude Code 重度用户，想在手机上继续和它对话
• 你需要离开电脑的时候远程指挥 Claude Code 做事
• 你想要”Claude Code + iLink”这种干净的双栈组合

不适用：

• 不用 Claude Code（就没有意义）
• 需要多会话并行
• 需要 production 稳定性（还在 research preview）

URL：https://github.com/Johnixr/claude-code-wechat-channel

1.5 daemon365/weixin-clawbot — Go 语言的完整 iLink SDK

基础面：

• 版本：v0.0.2（2026-03-24）
• License：MIT
• 模块：github.com/daemon365/weixin-clawbot
• 中英双语 README

核心价值：唯一一个完整实现 iLink 协议的 Go SDK。不是上层应用，是底层客户端库。对要用 Go 做 WeChat Bot 的团队来说这是唯一选择。

API 覆盖完整度：

核心类型：

type MessageSender interface {
    SendText(ctx, text) (string, error)
    SendImage(ctx, text, uploaded UploadedFileInfo) (string, error)
    SendVideo(ctx, text, uploaded UploadedFileInfo) (string, error)
    SendFile(ctx, text, fileName, uploaded UploadedFileInfo) (string, error)
    SendMediaFile(ctx, filePath, text) (string, error)
}

模块化设计：

• Client — QR 登录编排
• APIClient — iLink bot API 封装（6 个方法）
• Sender + Conversation — 消息组装模式
• MonitorOptions — 长轮询配置
• UploadedFileInfo — CDN 上传结果

安装：

go get github.com/daemon365/weixin-clawbot

sender := weixin.NewSender(weixin.SenderOptions{
    BaseURL: "https://ilinkai.weixin.qq.com",
    Token:   "YOUR_BOT_TOKEN",
    Timeout: 15 * time.Second,
})
conversation := sender.Conversation(weixin.Target{
    ToUserID:     "user@im.wechat",
    ContextToken: token,
})
conversation.SendText(ctx, "hello from bot")

注意事项：

• v0.0.2 预发布，API 稳定性不保证
• 实现了官方 CLI 还没开放的媒体消息发送（文本+图片+视频+文件+语音）——这是它相对 SiverKing 版本的关键优势

适用场景：

• 用 Go 写高并发后端，要自己实现 iLink Bot
• 需要真正的图片/视频/文件发送能力（不是官方 CLI 当前只开放的文本）
• 要在生产系统中嵌入 WeChat Bot 能力

URL：https://pkg.go.dev/github.com/daemon365/weixin-clawbot

路线 2：非 iLink 路径（仍活跃的老方案）

2.1 freestylefly/openclaw-wechat — 代理 + iPad/Mac 模拟

基础面：

• Stars：1.6k
• 最后提交：2024-12-12（注意：早于 ClawBot 发布）
• 安装：openclaw plugins install @canghe/openclaw-wechat

定位澄清：名字有 openclaw-wechat 但它不走官方 iLink。它是传统的 iPad / Mac 协议模拟路线，需要买 API Key + 配置代理服务器（proxyUrl）。本质上和 PadLocal 同一路线，只是不同的供应商。

能力：

• 私聊 + 群聊（相对官方 ClawBot 的优势）
• 文本 + 图片消息
• QR 码登录
• 多账号
• ❌ 无历史消息

关键配置：

• proxyUrl（必须——这暗示它依赖一个上游代理服务）
• Device type：iPad 或 Mac 模拟
• Webhook host/port（云部署场景）

为什么它仍然相关：iLink 当前不支持群聊。如果你需要群聊能力，要么等官方开放，要么用这类代理方案。

为什么它存在风险：

• 代理服务是商业服务，与 PadLocal 同类风险（供应商跑路、被腾讯起诉 API 提供方）
• 1.6k star 主要来自 2024 年，2025-2026 活跃度存疑
• 不在官方合规通道内

URL：https://github.com/freestylefly/openclaw-wechat

2.2 dingxiang-me/OpenClaw-Wechat — 企业微信原生 API 路径

基础面：

• Stars：514
• Forks：66
• 最后提交：2025-01（主分支 e1d885e）
• 语言：Node.js / TypeScript

定位澄清：不是个人微信方案。它是 “首个把 OpenClaw 接入企业微信的插件”，走的全是企业微信官方 API：

• 企业微信自建应用 XML 回调（Agent 模式）
• 企业微信智能机器人 API（Bot 模式）
• WebSocket 长连接（aibot_subscribe / aibot_msg_callback / aibot_respond_msg）

为什么会被放到”个人微信方案”调研里：它宣称”个人微信互通”——具体做法是”个人微信扫码进入企业微信应用对话”，相当于让个人微信用户成为企业微信应用的访客。本质上还是企业微信。

相对官方 ClawBot 的真正增量（如果你走企业微信路径）：

适用：

• 业务是企业场景，能申请企业微信
• 需要群聊、文档、流式输出、可靠投递这些企微特色能力
• 这是真正合规的路径，没有刑事/民事风险

不适用：

• 只有个人身份，没有企业微信资质
• 一定要用”个人微信”这块牌子与用户沟通

URL：https://github.com/dingxiang-me/OpenClaw-Wechat

对比矩阵：7 个项目一张表

给决策者的选型地图

你的需求 → 选什么

“我要用 Claude Code 在手机上继续对话” → Johnixr/claude-code-wechat-channel（iLink + Claude Code MCP，正中靶心）

“我要用 Claude / GPT（非国内模型）做微信 Bot，越薄越好” → SiverKing/weixin-ClawBot-API（免 OpenClaw + Anthropic 格式）

“我要同时管理多个微信号做 Bot，需要 Web 控制台” → ImGoodBai/WeClawBot-ex（多号并发 + 本地 Web UI）

“我用 Go 写后端，需要完整的 iLink SDK，包括发送图片视频文件” → daemon365/weixin-clawbot（唯一完整协议 Go 实现）

“我要自己用其他语言重写 iLink 客户端” → 先读 hao-ji-xing/openclaw-weixin 的协议文档，再写代码

“我必须要群聊” → 当前官方不开放，要么等（源码里有 group_id 伏笔），要么走非 iLink 路径：

• 个人微信场景 → freestylefly/openclaw-wechat（代理方案，有合规风险）
• 企业场景 → dingxiang-me/OpenClaw-Wechat（企业微信，完全合规）

“我要做需要发送图片/语音/文件的个人微信 Bot” → 暂时只有 daemon365/weixin-clawbot (Go) 实现了完整的媒体协议。其他 iLink 项目都卡在纯文本阶段。 → 或者等官方 CLI 开放媒体能力（已在排期）

“我就是个人用，不想装任何东西” → 回 4-官方通道-WorkBuddy与ClawBot.md 直接用 WorkBuddy

对整个社区生态的判断

2026-03 之后 30 天就出了 5 个以上的 iLink 增强版——这个速度说明两件事：

1. 官方 iLink 协议的文档化程度足够好（至少对反编译者而言），社区可以快速上手做衍生项目
2. 官方限制（单号、纯文本、无群聊）是真实痛点，每一个限制都有至少一个社区项目在补齐

潜在风险：

• iLink 是灰测协议，腾讯保留随时更改权。社区项目一夜失效的可能性持续存在
• 官方条款明确”可拦截/限速特定 AI 服务接入”，这意味着 SiverKing/weixin-ClawBot-API 这种”接 Anthropic”的做法理论上可以被官方主动阻断（尤其是海外模型）
• 社区项目的成熟度参差（star 数从 28 到 1.6k），应作为辅助工具而非关键基础设施

近期应该关注的信号：

• 官方 CLI 开放媒体消息的时间点
• 群聊能力是否从”源码伏笔”变成实际开放
• 腾讯是否对 SiverKing 这类”绕过 OpenClaw”的项目有立场表态
• Anthropic / OpenAI 接入是否被限速

信息源汇总

iLink 协议路线：

• https://github.com/hao-ji-xing/openclaw-weixin
• https://github.com/SiverKing/weixin-ClawBot-API
• https://github.com/ImGoodBai/WeClawBot-ex
• https://github.com/Johnixr/claude-code-wechat-channel
• https://pkg.go.dev/github.com/daemon365/weixin-clawbot

非 iLink 路线：

• https://github.com/freestylefly/openclaw-wechat
• https://github.com/dingxiang-me/OpenClaw-Wechat
• https://github.com/BytePioneer-AI/openclaw-china（多平台聚合插件，未深度调研）

官方参考（回链 4-官方通道）：

• https://www.runoob.com/ai-agent/openclaw-weixin.html
• https://www.ithome.com/0/931/431.htm
• https://github.com/hao-ji-xing/openclaw-weixin/blob/main/weixin-bot-api.md