上个月帮一个朋友做了个AI聊天机器人，本地跑得挺溜，答问也还算靠谱，做个demo、演示演示都没问题。结果上线没两天，客户一句话给我整不会了："这玩意儿能不能直接接到微信上？我们客户都在微信群里问问题，懒得再开个网页。"

我当时的第一反应是——微信又不开放机器人API，这咋整？总不能让客户去申请公众号、再走认证流程吧，那周期太长。硬着头皮去查资料，翻了不少帖子，发现还真有路子，而且不止一条。折腾了大半个月，把三种方案都跑了一遍，这里把踩的坑和最后选的方案写出来，给后来人省点时间。

先说结论：没有最优方案，只有最合适的方案。下面三种各自有各自的命门，看你项目卡在哪个约束上。我最后选的不是听起来最高级的那个，而是最适合朋友那个项目体量的。

方案一：轮询模式（定时拉消息）

原理

最笨但最容易理解的玩法。写个定时任务，每隔几秒调一次消息接口，看有没有新消息进来。有就取回来交给AI处理，处理完再调发送接口把回复推回去。

我一开始就是用这个方案跑的，因为不需要公网IP，本地起个服务就能测，特别适合刚上手验证想法。第一版我甚至直接在自家电脑上跑，插着网线、挂着脚本就出门吃饭了，回来一看，消息都回上了，当时还挺有成就感。

优点

• 实现极简，一个循环加个sleep就搞定

• 不需要公网IP和域名，本地就能跑

• 调试方便，出问题一眼能看出来，加个日志啥都清楚

缺点

• 延迟大，我设的5秒轮询，用户发完消息平均要等5秒才回，体验拉胯，群里有人还以为机器人掉线了

• 频繁拉取容易触发限流，有几次直接被接口封了一阵，那阵子消息全堵着

• 没消息也在拉，纯属浪费资源，服务器和带宽都在空转

适用场景

个人玩具项目、内部小工具、消息量很低的场景。我后来给一个内部反馈群用过，一天也就几十条消息，轮询完全够用，也懒得折腾服务器。

方案二：Webhook回调模式（微信主动推）

原理

这个就反过来了。你在公网部署一个服务，把URL配置到那边，用户一发消息，微信会主动POST到你这个地址，你接到请求立刻处理、立刻回。整个过程是事件驱动的，没有轮询的空转，有点像点外卖和定时去厨房看的区别。

接入的时候我参考了 Eyun开发文档 里关于回调验签和消息加解密的部分，少走了点弯路。这块文档讲得挺细，尤其是签名校验那个地方，我第一版写错了字段顺序，调了一晚上才发现问题，文档里其实写得很明白，是我自己没细看。

优点

• 实时性好，用户发消息基本秒回，体验上一个档次

• 不浪费资源，有消息才处理，没消息服务器就闲着

• 是官方支持的玩法，稳定性有保障，不用怕哪天突然封了

缺点

• 必须有公网IP和域名，本地调试得用内网穿透，穿透工具有时不稳，调试时被坑过几次

• 服务必须能被外网访问，安全性要额外注意，端口别乱开

• 要求5秒内返回，AI处理慢了直接超时，用户那边显示服务异常

适用场景

正式上线的产品、对响应速度有要求的项目。后来正式环境我们就用这个，配合 Eyun平台 的消息通道整体跑下来挺稳，没出过什么大幺蛾子。

方案三：长连接模式（WebSocket保持连接）

原理

这种方式不是直接对接微信官方，而是借助一些第三方协议或者企业微信的能力，跟服务端保持一条长连接。消息来了解析、处理、回写都在同一条连接上完成，不用反复建连。

说实话这个我研究的时间最长，因为涉及到的协议细节多，而且坑也藏得深——光是断线重连的退避策略我就调了两三天。但跑通之后体验是真的好，延迟低、资源占用小，高并发下也不容易崩。

优点

• 实时性最好，几乎零延迟，发出去对方那边立刻有反应

• 资源消耗低，一条连接搞定收发，不用频繁握手

• 适合高并发场景，扛得住消息洪峰

缺点

• 实现复杂，连接管理、断线重连、心跳保活都要自己写，代码量大

• 依赖第三方能力，稳定性看对方脸色，对方一抖你跟着抖

• 调试难度高，出问题排查费劲，连接状态不好看

适用场景

消息量大、对实时性要求极高的场景。一般小项目用不上，我也就是为了对比才跑了一遍，跑完就把代码封存了，维护成本扛不住，没必要。

三种方案横向对比

光说不直观，我做了张表，把几个关键维度摆一起看：

我自己最后的结论是：验证想法用轮询，正式上线用Webhook，长连接留给对极致实时有要求的场景。大部分中小项目，Webhook足够了，没必要上来就搞复杂的，越复杂的东西越容易出问题。

一段能跑的Webhook对接代码

下面这段是我最后定稿用的Webhook接收+AI处理+回复的完整流程，Python写的，去掉了业务相关的部分，保留主干逻辑。新手拿来改改就能跑，别被网上那些东拼西凑的教程绕晕。

from flask import Flask, request import hashlib import requests app = Flask(__name__) TOKEN = "你的token" AI_URL = "替换成你自己的AI服务地址" def verify_signature(signature, timestamp, nonce): # 回调签名校验，校验不过的直接拒 params = sorted([TOKEN, timestamp, nonce]) sign = hashlib.sha1("".join(params).encode()).hexdigest() return sign == signature def call_ai(user_msg): # 调AI接口生成回复，这里换成你自己的机器人 resp = requests.post( AI_URL, json={"message": user_msg}, timeout=4 ) return resp.json().get("reply", "我这边没想明白，稍等转人工") @app.route("/wx/callback", methods=["GET", "POST"]) def callback(): if request.method == "GET": # 首次配置URL时的验证 return request.args.get("echostr", "") # POST是真实消息推送 signature = request.args.get("msg_signature", "") timestamp = request.args.get("timestamp", "") nonce = request.args.get("nonce", "") if not verify_signature(signature, timestamp, nonce): return "fail" # 这里简化了XML解析，实际用XML库解析 user_msg = extract_text(request.data) reply = call_ai(user_msg) # 组装回复，要求5秒内返回 return build_reply_xml(reply) if __name__ == "__main__": app.run(host="0.0.0.0", port=80)

几个踩坑提醒，都是血泪：

• call_ai的 timeout 一定要设，而且要小于5秒。我有一次AI接口卡了8秒，那边直接报超时，用户收不到回复，来回投诉。

• 签名校验那段字段顺序不能错，sorted是关键。第一版我手写顺序写反了，调到半夜才反应过来。

• 生产环境务必加业务鉴权和频控，光靠平台那层验签不够。有人拿你的回调地址刷，服务器扛不住。

• 首次配置URL那个GET验证很多人漏掉，没它配置根本过不去，别问我怎么知道的。

• XML解析别用字符串切割，老老实实上XML库，否则遇到转义字符就崩。

选型建议

再啰嗦一句选型。如果你的情况符合下面任一条，直接上Webhook：

• 有公网服务器或者能搞到内网穿透

• 用户量超过几百，对响应速度有要求

• 需要稳定长期运行，不想半夜被叫起来重启

只有一种情况建议用轮询：就是你自己玩、客户群就几个人、不想折腾服务器。长连接除非有明确的实时性诉求，否则不建议上来就用，光维护成本就够喝一壶。

我朋友的机器人最后就是Webhook方案上的线，又把 Eyun开发文档 里讲的消息加解密规范过了一遍做加固，跑了一个月没出大问题。整体来说方案不复杂，难的是把细节抠明白，文档读细点能省一半调试时间。

希望这篇能帮到正在折腾对接的朋友，少踩点我踩过的坑。有问题评论区聊，能答的我都会回。