AI工作流怎么接企业微信：四条通道与频率限制避坑

去年有个做设备的客户来找我们，需求听起来简单：车间报工异常时，让 AI 判断要不要升级通知，然后发到企业微信的车间群。真上手，光是「怎么接」就卡了两天——不是难，是路径太多，选错了后面全是返工。

企业微信对外提供了至少四条完全不同的通道，权限模型、能力边界、限制都不一样。选错通道，代码写完才发现「这个场景根本发不出去」，太常见了。

四条通道先分清，别混着做

通道	入口	能做什么	主要限制
自建应用	后台「应用管理-自建」	以应用身份发消息、读组织架构、调各类业务接口	需配可信 IP、需要 access_token、有调用配额
消息收发	应用内「接收消息」配置	接收成员发给应用的消息并回复	回调必须 5 秒内响应
群机器人	群设置「群机器人」	单向推送到指定群	每机器人每分钟约 20 条，收不到群消息
审批接口	「OA-审批」系列接口	提交、查询、接收审批状态回调	模板控件 ID 会变，需动态获取

一、自建应用与权限申请：能力的底座

在管理后台「应用管理-应用-自建」创建应用，拿到 AgentId 和 Secret；企业 ID 在「我的企业」里。真正容易漏的是「企业可信 IP」，服务器出口 IP 必须加进去，否则调接口直接报 60020。南昌不少公司用的是动态宽带，IP 一天一变，这就是常踩的坑——要么拉专线固定 IP，要么把网关放在云上。

权限还有两块要配：通讯录读取范围和应用的可见范围。可见范围决定了谁能收到消息，不配等于白发，而且后台不会有任何提示。Secret 一旦泄露要立刻重置，重置后旧 token 全部失效，线上会短暂中断，安排在业务低峰做。

适用场景：需要以应用身份给指定人发消息、读部门成员、走审批、拿日程。多数企业内部 AI 助手都走这条。

二、消息收发：接收靠回调，发送靠主动推

接收侧在应用里配「接收消息服务器」：填 URL、Token、EncodingAESKey。企业微信会先发一个带 echostr 的 GET 请求，你要做 AES 解密再原样返回，验证才通过。之后成员发的消息以加密 XML/JSON 推到你的地址。

硬约束：5 秒内必须返回，超时企业微信会重试三次。AI 推理动不动几秒到几十秒，不能同步处理，否则用户会收到重复回答。我们的做法是先落库、立刻返回空串，再由 worker 跑模型、调发送接口回推。

发送侧用 message/send，要 access_token，有效期 7200 秒。必须集中缓存。多实例部署时如果各自去取，会互相把对方顶掉，表现成偶发的 40014 invalid access_token，很难查。用 Redis 存，加锁刷新，提前五分钟过期。另外应用消息的文本类型不渲染 markdown，要排版得换 textcard 或 markdown 消息类型，不同接口支持的不一样，接之前先确认。

三、群机器人 webhook：落地较快，也容易被限流打爆

群设置里「群机器人-添加」，拿一串 webhook key，POST JSON 就能发。不用 access_token，不用审核，十分钟能跑通，原型验证阶段我一般先用它。

限制要提前说清：只能发到那个群，发不了个人；每个机器人每分钟大约 20 条；text 消息里可以用 mentioned_list 做提醒。有人想拿群机器人做双向对话，做不到——机器人收不到群里的消息，除非开通会话内容存档，那是另一套接口，付费并且要走合规流程。

适合：告警通知、日报推送、AI 生成结果播报、群里的运营看板。不适合：需要按人分发的场景。

四、审批接口：AI 容易出彩，也容易卡在模板上

审批这块包括拉模板详情（oa/gettemplatedetail）、提交申请（oa/applytemplate/submit）、审批状态变化回调。AI 的价值点在于：从聊天记录、邮件、工单里抽出金额、事由、供应商，自动填单提交，人只做确认。

坑在控件。提交时要按控件 ID 拼 apply_data，而控件 ID 是模板里生成的随机串，管理员改一次模板，ID 就变，硬编码必挂。我们的做法是启动时拉一次模板详情缓存，按控件标题（比如「报销金额」）做映射，再加个每日定时刷新。日期控件要传秒级时间戳，金额控件部分版本要传字符串，附件得先上传临时素材拿 media_id——文档里都有，但很分散，头一次做通常要调半天。

频率限制：所有批量场景的前提

企业微信对每个企业、每个应用都有调用频次上限，超了返回 45009（接口调用超过限制）。它不是单次失败那么简单——触发后这个应用在一段时间内都会被拒，影响面很大。

典型翻车：数据库里躺着两千条待发通知，for 循环里直接调接口。前几十条成功，后面全 45009，脚本还以为发出去了，第二天才发现一半人没收到。

正确姿势是四件事：

• 任务表 + worker：业务侧只写任务记录，不直接调 API，发送和业务解耦。
• 令牌桶限速：按接口配额设置 QPS，宁慢勿炸。
• 失败重试 + 指数退避：遇到 45009 要退避到分钟级，立刻重试只会延长封禁。
• 幂等键：用业务 ID 去重，避免重试导致同一个人收到两条。

如果是每日固定时间的推送，比如早上 8:30 的 AI 日报，把任务打散在 5 到 10 分钟的窗口里，别全挤在整点那一秒。

AI 侧还得想清楚两件事

数据边界。企业微信是公网服务，模型如果放在内网（制造业客户常要求数据不出厂区），中间得有一台网关做转发和脱敏——工号、手机号、供应商名称先替换再出网。AI 智能体私有化部署这类方案一般会把网关、模型、知识库一起打包，比单点接一个 API 稳妥。

回答依据。接入只是管道通了，AI 回什么取决于知识库。我们做过一个售后工单的例子：接企微只花半天，知识库整理花了两周——把历史工单、产品手册、常见故障做成企业知识库，回答准确率才从「看着像」变成「能直接发给客户」。

落地顺序建议

1. 先定场景形态：单向通知还是双向对话。单向优先群机器人，双向必须自建应用。
2. 把可信 IP、可见范围、token 缓存这三处做对，能省掉一半调试时间。
3. 从一条链路开始：一个群、一个场景、一天几十条消息，跑一周看错误码分布。
4. 再上队列和限速，然后横向扩场景。

工作量参考：纯接口对接通常几天到两周；如果包含模型接入、私有化网关和知识库搭建，多数落在数万元到十几万元区间，以实际方案与报价为准。

下一步可以先做件小事：把自己现有流程列一遍，标出哪些环节是「人看到消息→查资料→做判断→回复或填单」，这类环节替掉的性价比高。具体链路设计可以看AI 工作流自动化里的思路，或者直接联系我们，把场景描述发过来，我们帮你判断该走哪条通道；电话 400-873-2750。