企业微信 RPA 和 API 自动化怎么选

先把两个词的边界划清楚

RPA 指的是在客户端界面这一层做操作模拟：让程序去点按钮、填输入框、读屏幕上的文字，本质是「替人操作一个正常运行的客户端」。它不改动客户端本身，也不涉及任何私有通信的解析 —— 这点要先说清楚，因为这个词在讨论里常和另外一些灰色说法混在一起，但它们不是一回事，工程特性也完全不同。

API 自动化是程序对程序：你的服务发一个 HTTP 请求，拿一个结构化响应回来。中间没有界面、没有坐标、没有渲染等待。

这条边界决定了后面所有差异。界面层方案的接口契约是「界面长什么样」，接口层方案的契约是「请求和响应的字段」。界面是给人看的，随时会因为一次版本更新改掉，改了也不会有人通知你；字段是给程序用的，有文档、有版本、有兼容承诺。稳定性和维护成本上的所有差距，都是从这一句话里长出来的。

两者也不在同一个抽象层上，这会直接影响排期准不准。界面层脚本的工作量和「这个操作要点几下」成正比，可以按操作数估，看着很准 —— 但估的只是第一版，异常分支的工作量一点没进去。接口对接的工作量和「要理解多少个字段」成正比，第一版估不准，之后每加一个功能反而越估越准。

稳定性：比的不是成功率，是失败可发现时间

两种方案在正常路径上都能工作，差别全在异常路径。而异常路径的关键指标不是「有没有失败」，是「失败多久之后被发现」。

接口调用失败时，你会拿到一个明确的东西：HTTP 状态码、业务错误码、一条可以检索的记录。参数错了、权限不够、被限流了，这三类在返回里是分开的，监控可以直接按错误码分桶告警。从失败到你知道，通常是秒级。

界面层失败时，你拿到的可能什么都不是。弹窗挡住了按钮，脚本点在了弹窗上，流程「成功」结束；页面慢了半秒，输入框还没出现，文字打进了别的地方；列表多了一行，本该点第三个的点成了第四个。这些都不抛异常，脚本日志显示一切正常。从失败到被发现，取决于什么时候有人去看结果 —— 现实里往往是客户先发现。

还有一个少被提到的差别：界面层没有「部分成功」这个概念。批量处理一百条，接口层会告诉你哪三十条失败、各自什么原因，你只补那三十条；界面层脚本断在第三十一条，你只知道它断了，重跑就重复、不重跑就漏，除非你自己在脚本里维护一份进度 —— 而那份进度没有任何东西可以跟它对账。

有人会说界面层也能加校验：点完之后截图比对、读一遍列表确认。可以，但校验本身也跑在界面层，用的是同一套会失效的假设 —— 弹窗能挡住按钮，同样能挡住你要比对的那块区域。检测手段和被检测对象共享失败模式，这是界面层方案最本质的短板，加多少层校验都补不平。

成本：一条随账号数发散，一条收敛

界面层方案的成本曲线是这样的：起点很低，不用做接口对接、不用理解字段；然后随账号数线性增长 —— 每个账号要一个常开的客户端会话，就意味着一台机器或一个虚拟桌面、一份环境维护、一次登录态失效就要有人去处理。到十个账号的时候，你会开始写调度器来管这些机器，那说明你已经在造一套自己的基础设施了。

界面改版是另一条成本线，而且它是阶跃的：平时为零，某次更新之后所有脚本一起失效，你要在业务停摆的压力下重录一遍。这笔钱没法摊进每个月的预算，只能在它发生的那天一次性付。

接口一侧的成本结构正相反：前期要花时间对接和联调，之后边际成本很低。像 wecomapi 这种按账号订阅、订阅内不限调用次数的形态，扩到十个账号是订阅项变多，不是运维负担变多，也不需要为每个账号准备一台常开的机器 —— 省下来的这部分通常比订阅费本身还大，但它不会自己出现在选型表上，得你主动去算。

成本项            界面层（RPA）              接口层
----------------  -------------------------  --------------------------
起步成本          低，录制即可跑             中，要对接与联调
每增加一个账号    +1 份运行环境与登录维护    +1 个订阅项
并发能力          受限于机器数量             受限于接口频控，可排队削峰
版本 / 界面变更   脚本集体失效，需重做       字段有文档与兼容承诺
无人值守          需要人盯，失败静默         可监控，失败显式返回
排障依据          截图与录屏                 请求标识与结构化日志

表里最该盯的是「每增加一个账号」那一行，它决定这套方案从第几个账号开始不划算。经验值是三到五个：超过之后，界面层的运维投入会明显超过接口对接的一次性投入，而且这笔投入每个月都要再付一遍。

可维护性：改一次要动多少东西

维护成本的本质是契约的稳定性。把同一个动作的两种写法摆在一起看最清楚。

// 示意代码，只表达契约差异，不代表任何一方的真实调用方式

// 界面层：依赖控件位置、渲染时机与文案，任何一项变了都会静默走偏
await ui.click({ x: 820, y: 344 });
await ui.waitForText("发送");
await ui.type(content);
await ui.click({ selector: "button.send" });

// 接口层：依赖了哪些字段可以直接搜出来，失败有明确返回
await http.post("https://manager.wecomapi.com/message/sendText", {
  guid:    accountId,
  toId:    conversationId,
  content,
});

上半段依赖的每一个控件位置、每一段文案、每一次页面跳转，都是一个隐式依赖，散在脚本各处，没有任何地方能列出「我依赖了什么」。下半段依赖的是三个字段名，能从代码里搜出来，能在文档里查到，变更有记录。

差别不只在改动量，更在于改动的代价能不能估。能估的成本可以排期，不能估的成本只能扛 —— 这一点在做年度规划时比技术差异重要得多。另一个容易被忽略的维度是谁能维护：界面层脚本通常由一两个「会录这个」的人维护，人一走就没人敢动；接口对接的代码是普通业务代码，团队里任何人都能接手。

如果短期内非用界面层不可，至少把它当成一个「只有界面、没有接口」的下游系统来治理：给它一条健康检查（定期跑一个已知结果的操作，比对输出）、一个整体超时、一个必须由人显式续期的到期时间。这三样能把静默失败的窗口从「客户告诉你」压到「一小时内告警」，投入不大，是目前性价比最高的补救。

界面层仍然是正确答案的三种场景

这不是一篇劝退的文章。有三种情况下界面层方案确实更优：

1. 1一次性或极低频的操作。要把三百条历史数据搬一遍、之后再也不做了 —— 录个脚本半小时，做接口对接两天，选前者。
2. 2有人值守的辅助操作。人在旁边看着，脚本负责重复劳动、人负责判断和兜底。此时「失败静默」这个最大的缺点正好被人补上了。
3. 3接口确实不覆盖、业务上又必须做的边角操作。这时它是补丁，前提是你清楚自己在打补丁，并且给它单独配了人工检查环节。

反过来明确不该用的是：多账号、常驻运行、需要 SLA、失败会被客户感知。这四个条件占了两个，就该走接口。

最贵的一种混用，是拿界面层脚本去补接口的能力缺口、然后把它挂进常驻主链路。这样你同时承担了两套失败模式，而其中一套没有告警。正确的顺序是先确认缺口真的存在 —— 对着 wecomapi 的接口文档逐项核一遍，很多所谓的缺口只是没找到对应能力，或者能力在另一个名字底下。核完还在的缺口，再决定是打补丁还是改需求。

已经在跑，怎么迁

1. 1先列清单，别先写代码。把现有脚本做的每件事写成一行「谁、对谁、做了什么」，你会发现其中相当一部分根本不需要迁，是历史遗留。
2. 2按「失败影响面」排序，不按「实现难度」排序。影响客户的先迁，内部对账类的留到最后。
3. 3双轨期只跑读取，不跑双写。迁移期间让接口那一路先只读、和界面层的结果比对，一致了再切写入。两边同时写会产生对不上的状态，排查这种不一致比迁移本身贵。

切换点要放在动作层，不要放在脚本层：业务代码调用的是你自己定义的动作，接口那一路按 wecomapi 的统一调用形态封成其中一个实现，底下走哪一条由一个按账号维度的开关决定。有这个开关，灰度和回滚都是改一行配置，不需要重新发版 —— 迁移期间你一定会用到它，而且多半是在深夜。