聊到企业微信自动化圈子里分两派API 派觉得 RPA 是上古时代的产物又慢又脆RPA 派觉得 API 受限太多能调的接口就那么几个做不了复杂业务流程。真实情况是两者各有边界结合用反而能解决很多单家搞不定的事。这篇聊聊 Eyun 企业微信 API 与 RPA 怎么配合把企业业务自动化推到一个新水位。一、先理清楚 API 和 RPA 各自的边界不是所有事都适合 API也不是所有事都该用 RPA。先做边界判断维度API 路径RPA 路径速度接口调用毫秒级模拟点击秒级稳定性协议稳定不易因 UI 改版失效依赖界面元素改版即崩覆盖范围仅平台开放的能力只要有界面就能操作实现成本调用简单文档清晰流程开发复杂、维护重合规风险走官方协议合规模拟人操作边界模糊判断准则就一条能调 API 的别用 RPA必须用 RPA 的别硬调 API。具体到企业微信场景收发消息、管群、管联系人 → 走 API在企微客户端里点击发起审批、查看报表 → 走 RPA把企微消息同步到自建 CRM → 走 API把企微里的客户标签同步到第三方 SaaS CRM没有 API → 走 RPA 登录 SaaS 操作二、API 与 RPA 的协同架构两者结合的标准架构长这样┌─────────────┐ │ 业务流程编排 │ └──────┬──────┘ │ ┌──────┴──────┐ │ │ ┌────▼────┐ ┌────▼────┐ │ API 网关 │ │ RPA 引擎│ └────┬────┘ └────┬────┘ │ │ ┌────▼────┐ ┌────▼────┐ │ Eyun API│ │ 各业务 │ │ 平台 │ │ 系统界面│ └─────────┘ └─────────┘业务流程编排层决定每一步走 API 还是 RPA把两者的能力组合成一个完整的业务流。比如新客户加好友后自动在 CRM 建客户档案 在 ERP 建对应账户 给该客户发欢迎消息——前两步走 RPACRM/ERP 没 API第三步走 Eyun 企业微信 API。三、典型协同场景场景一跨系统客户档案同步客户在企微加了好友联系人模块 的friend.added回调触发后要做的不只是更新企微侧备注还要在 CRM 里建客户档案、在 ERP 里建账户档案。CRM 和 ERP 都没有开放 API只能靠 RPA 登录操作。编排流程API 接收friend.added回调提取客户信息。调 APIupdateExternalContactInfo更新企微侧备注和标签。推消息到 RPA 队列RPA worker 拿到任务后登录 CRM按规则录入客户档案。RPA worker 接着登录 ERP建账户档案。RPA 完成后回调 APIAPI 调sendText给客户发欢迎消息。整个流程跨 API 和 RPA靠消息队列解耦RPA 慢一点都不影响 API 侧的快速响应。场景二报表自动汇总与推送每天早上要给销售总监推送昨日业绩汇总数据来自三个系统企微侧的客户互动数据走 API 拉ERP 侧的订单数据走 RPA 登录拉BI 里的转化漏斗走 RPA 导出 Excel。最后 RPA 把三块数据拼到一张表里再调 API 通过sendFile把 Excel 发到总监的企微会话。步骤路径来源拉客户互动统计API企微侧拉订单数据RPAERP导出转化漏斗RPABI数据汇总拼表RPA本地发送结果文件API企微API 和 RPA 各做擅长的部分谁都不越界。场景三审批流程跨系统打通企微里有审批应用但审批结果要同步到 OA 系统走流程OA 又没 API。这时 RPA 可以监听企微审批回调拿到审批通过事件后RPA 登录 OA 系统点击对应按钮推进流程。四、协同的关键工程问题1. 任务编排API 和 RPA 怎么接力不能让 API 同步等 RPA 完成RPA 慢且容易失败。一定要靠异步消息队列解耦API 层产出任务写入队列后立即返回。RPA worker 从队列消费任务完成后产出结果事件写回另一个队列。API 层监听结果事件队列拿到结果后继续后续流程。中间状态要持久化避免任何一侧重启丢任务。2. 失败重试与降级RPA 失败率天然比 API 高UI 改版、网络抖动、登录态失效。要设计重试机制单步失败立即重试 1 次。仍失败则延迟重试最多 3 次。3 次都失败则进死信队列人工介入同时通知运维。降级策略如果 RPA 这一步持续失败看能否临时改走 API 或人工兜底。比如 CRM 没 API但管理员账号可以批量导入 CSV那 RPA 失败时降级为人工导 CSV业务先继续。3. 幂等性API 侧的幂等靠msgIdRPA 侧的幂等要自己设计。每条 RPA 任务带唯一taskIdRPA worker 处理前先查这个 taskId 处理过没处理过直接跳过。这步不做严重试一次就把客户档案建两份。4. 凭证管理RPA 要登录各种系统凭证管理是大坑不能把账号密码硬编码进 RPA 脚本。用统一的凭证保险柜RPA worker 运行时去取。凭证定期轮转轮转后自动更新保险柜。操作日志要记录哪个 worker 用哪个凭证做了什么满足审计。五、什么时候不该用 RPARPA 看起来万能但有几种场景强烈不推荐高并发场景RPA worker 是单线程模拟人QPS 上不去。强一致性场景RPA 失败重试之间可能产生数据不一致。长链路业务十几个 RPA 步骤串起来任何一步崩全流程崩。合规要求高的场景模拟人操作可能违反部分系统使用条款。这些场景宁可推动业务系统开放 API也不要硬上 RPA。六、监控要分两边API 侧监控看接口调用量、错误率、延迟这些 Eyun 企业微信 API 平台都有指标。RPA 侧监控要看不一样的维度流程成功率每个 RPA 流程端到端跑通的比例步骤级失败率具体卡在哪一步方便定位平均执行时长突然变长说明可能 UI 改版了凭证失效次数频繁失效说明密码轮转机制有问题RPA 监控做不好问题排查会非常痛苦。一个流程跑挂了可能要回放录像才能定位。写在最后Eyun 企业微信 API 平台 和 RPA 不是替代关系是协同关系。API 做高并发、强一致、合规敏感的部分RPA 兜没有 API 的存量系统。两者用消息队列解耦、用任务编排串起来、用统一监控管起来这套架构能解决单家方案都搞不定的复杂业务自动化。重点是把边界划清楚、把工程基建做扎实别指望一套方案包打天下。
