企业微信之前有群机器人，是可以接受消息然后回调至服务器，做出对应的回复，也可以通过主动发消息的方式进行通知。我之前还开发了一个群机器人的回调服务框架，有176🌟。

今年年初随着 OpenClaw 的流行，企微的智能机器人流行起来，并且在最新的企微版本中，老版的群机器人虽然还能被@，但从列表中被隐藏起来，新添加的机器人也无法配置回调地址。以后再使用机器人就只能通过添加「智能机器人」来实现了。

智能机器人可以像一个正式成员一样出现在群成员列表中，并带有 BOT 标识：

近期恰好做一个老机器人的迁移，就顺便让 AI 写了智能机器人的服务框架，如此一来，开发仍然只需要填写 msg_handler 之类的实现即可。

智能机器人如果使用 API 有使用长连接和回调两种方式：

刚开始迁移的时候，觉着跟回调方式比较像，但发现这个回调模式非常局限，后来又改成了长连接方式。

本文就简单对三种方式做一个比较。

部署位置

只有长连接模式的智能机器人既可以部署在本地，又可以部署在公网。这个原理比较简单：长连接模式下，我们的程序不是等企业微信来访问一个 HTTP 回调地址，而是主动作为客户端去连接企业微信的 WebSocket 网关。

也就是说链路从：

企业微信 -> 开发者公网 HTTP 服务

变成了：

本地进程 / 内网服务 / 云服务器 -> 企业微信 WebSocket 网关

只要机器能访问外网，能连上 wss://openws.work.weixin.qq.com，再用 bot_id 和 secret 完成订阅，就可以收到消息并回复。因此开发阶段可以直接在笔记本上跑，线上使用时也可以部署到 CVM、容器、办公室内网机器或者任何一个常驻进程里。

相比之下，群机器人回调和智能机器人回调都要求企业微信能访问到你的服务地址，所以一般需要公网域名、HTTPS、回调 URL、Token / EncodingAESKey 之类的配置。对于只是想快速做一个 AI 助手的人来说，这个门槛就高不少。

消息类型

长连接模式的智能机器人是兼容消息类型最多的，比如它可以接收文件而群机器人不行；它可以返回文件，而回调类型的智能机器人不行。

具体的，接收消息的类型的比较：

而返回消息类型的比较：

这里尤其要注意智能机器人回调的限制。按照官方「主动回复消息」文档，它能回复的消息类型只有 markdown 和 template_card 两种，所以它更适合做基础文本/卡片回复，而不适合做文件型、多媒体型 AI 助手。

长连接模式则明显完整得多。官方「智能机器人长连接」文档里，接收侧覆盖文本、图片、图文混排、语音、文件、视频等类型；回复侧也提供 Markdown、模板卡片、文件、图片、语音、视频等格式，并且有流式消息回复机制。

这就是我后来从回调方式改成长连接方式的主要原因：只要进入真实办公场景，很快就会遇到文件、图片、语音、流式输出这些需求。

消息推送

消息推送可以分成两类：一种是用户说话后机器人被动回复，另一种是业务系统主动给某个群或会话发消息。

群机器人最早就是为主动推送设计的。它有一个 Webhook 地址，业务系统拿到地址后就可以直接调用，特别适合告警、通知、发布结果、日报周报这类场景：

业务系统 -> 群机器人 Webhook -> 企业微信群

智能机器人回调更偏「收到用户消息后立即响应」。企业微信把消息推到你的公网服务，你在回调里处理，然后通过 response_code 主动回复 Markdown 或模板卡片。这个模型适合传统服务端应用，但如果 AI 生成时间比较长，或者需要边生成边展示，就会显得不够自然。

长连接模式下，被动回复和主动发送都可以通过同一条 WebSocket 连接完成。收到用户消息后，可以用 stream 持续返回内容；业务侧如果拿到了 chat_id，也可以主动发送 Markdown、图片、语音、视频、文件等消息。

不过长连接也有一个现实约束：进程必须一直活着。终端关掉、机器休眠、网络断开，机器人就会离线；如果同一个 Bot 在多个地方同时启动，还可能互相抢连接。因此如果只是做群通知，群机器人依然简单直接；如果是做 AI 助手，尤其是需要流式回复和多模态消息，长连接会更顺手。

身份标识差异

智能机器人消息里返回的发送人标识，并不是传统企业微信通讯录里的 userid，而是智能机器人体系下的 staff ID。

尽管智能机器人可以在配置页面设置可以使用成员。但是如果要做更细致的角色管理和鉴权，就需要额外调用内部接口，把智能机器人返回的 staff ID 转换成可识别的用户信息，例如姓名、企业微信 userid、内部账号、部门等信息。

小结

如果你原来用的是群机器人回调能力，也就是希望机器人能接收用户消息、处理业务逻辑、再返回结果，那么更推荐迁移到长连接方式的智能机器人。它不需要公网回调地址，而且消息类型、文件处理、流式回复这些能力都更完整，更符合现在 AI 助手的使用方式。

如果只是做简单的群通知，比如告警、发布结果、日报周报、CI/CD 状态推送，继续使用群消息机器人的 Webhook 就很方便。

而回调方式的智能机器人就比较鸡肋，除非团队已经有现成公网回调且需求刚好非常简单，否则不太推荐把它作为新的接入方式。