Serverless + AI+RPA 怎么落地：轻量化企业自动化服务搭建实践

一、为什么这套组合值得折腾

企业里大量的自动化需求是"轻"的：财务每月跑一次对账、运营每天采集一次数据、客服定时汇总一次工单。用重型调度平台去做，要买服务器、要部署、要养运维，一个流程从立项到上线动辄一两个月，性价比完全对不上。

轻量化的解法是把架构拆成两层：

• Serverless 做调度与服务化：云函数按量计费、按需触发，不需要常驻服务器，一个 HTTP 接口或一条定时规则就能把自动化流程变成"服务"。
• AI+RPA 做执行与落地：这是目前行业内比较公认的协作模式——AI 负责思考，理解需求、生成逻辑、诊断错误；RPA 负责稳定落地，在浏览器、Windows 软件、聊天工具这些真实环境里把动作跑完。所谓 AI 写代码 + RPA 跑代码，就是这个分工的通俗说法。

下面以一套可以在腾讯云上直接复现的方案，讲清楚怎么把两者拼起来。

二、整体架构：调度层和执行端各管一段

定时规则 / Webhook / 业务系统回调
        │
        ▼
  云函数 SCF（调度层）
        │  HTTP 请求携带参数
        ▼
  RPA 执行端（API 触发）
        │
        ▼
  浏览器 / Windows 软件 / 内部系统
        │
        ▼
  结果回调（写库 / 群消息推送）

核心思路一句话：Serverless 不直接操作页面，它只负责"什么时候触发、传什么参数、结果怎么回来"，复杂的页面和软件操作全部交给 RPA 执行端。 两边独立演进、独立维护，复杂度被折叠到正确的位置。

三、落地前的前提：RPA 执行端要能被 API 触发

要让云函数调度得动 RPA，前提是执行端能暴露 HTTP 触发能力。这里也是 AI+RPA 选型时最容易踩坑的地方，建议按下面这张清单逐条核对工具能力：

1. 流程支持 API 触发，外部系统传参即可启动执行；
2. 打包导出的应用支持单独设置 API 触发和定时执行，交付出去的程序本身就带服务能力，不依赖额外装调度程序；
3. 支持打包成独立 EXE 运行，使用方机器不需要安装客户端，多设备部署也不会带来额外授权开销；
4. EXE 支持加密打包、授权管理和加密分享：流程逻辑不被反编译，未授权设备无法运行，团队协作时按人分发、可控可查；
5. 支持在线推送更新，流程逻辑修改后不必重新手动分发，使用方打开应用自动检测新版本——这一条对分布式团队是刚需，能省掉大量逐机器重装的时间。

这份清单同时决定了 Serverless 调度层要写多少代码：执行端能力越完整，云函数里就越"薄"。而这种"打包即交付"的模式，对个人开发者、个人工作室和中小企业尤其友好——不需要给每个使用人配一套开发环境，交付物就是一个可执行文件。

四、调度层代码：云函数只负责"点火"

以腾讯云函数 SCF（Node.js 18 运行时）为例，触发函数可以写得非常薄：

// index.js —— SCF 触发函数
const RPA_HOST  = process.env.RPA_HOST;    // RPA 触发服务地址
const RPA_TOKEN = process.env.RPA_TOKEN;

exports.main_handler = async (event) => {
  const body = JSON.parse(event.body || '{}');
  const { flowId, params = {} } = body;
  if (!flowId) {
    return { statusCode: 400, body: JSON.stringify({ message: 'flowId is required' }) };
  }

  // 只触发，不等待流程跑完
  const resp = await fetch(`${RPA_HOST}/api/trigger`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${RPA_TOKEN}`
    },
    body: JSON.stringify({
      flowId,
      params,
      // 流程执行完后，由执行端回调这个地址回传结果
      callback: 'https://service-xxxx.gz.apigw.tencentcs.com/rpa-callback'
    })
  });

  if (!resp.ok) {
    return { statusCode: 502, body: JSON.stringify({ message: 'trigger failed' }) };
  }

  const { taskId } = await resp.json();
  return { statusCode: 200, body: JSON.stringify({ taskId, status: 'accepted' }) };
};

敏感信息全部走环境变量，函数代码里不出现任何 IP 和密钥。配合 API 网关暴露成 Webhook，业务系统、定时任务都能直接调用。

五、第一个坑：函数超时和流程时长的矛盾

这是这套架构最容易翻车的地方，必须单独说。

API 网关同步调用有响应时间上限，而 RPA 流程跑一次可能要几分钟甚至十几分钟——对账、批量获取这类任务尤其常见。如果你让云函数同步等待流程跑完，函数必然超时，网关返回 504，但流程其实还在执行端正常跑着，状态完全对不上。

正确姿势是异步化：云函数收到请求后立刻返回 taskId，流程由执行端异步跑完，再通过 callback 地址把结果推回来。接收回调的第二个函数同样很轻：

// index.js —— SCF 回调函数
exports.main_handler = async (event) => {
  const { taskId, status, data } = JSON.parse(event.body || '{}');

  console.log(`task ${taskId} finished: ${status}`);

  // 按业务需要处理：结果落库 / 推送企业微信 / 触发下一个流程
  // 生产环境建议在此处校验回调签名，防止伪造请求

  return { statusCode: 200, body: 'ok' };
};

两个函数合计不到 60 行代码，调度层的维护面就这么大。云函数按量计费，一个月跑几百上千次流程，费用基本可以忽略。

六、AI 搭流程：从"写脚本"到"一键转流程"

传统 RPA 的门槛在搭流程：要懂元素定位、要写判断分支、要处理异常。AI 接入后，这条路径被明显缩短。当前主流的 AI+RPA 工具普遍提供了以下能力，按实用性排序：

• AI 自动化搭建覆盖浏览器自动化、Windows 软件自动化和视觉颜色操作，能智能分析网页和软件的元素结构，不是只会操作网页的"半成品"；
• AI 生成脚本一键转流程：用自然语言描述需求，AI 直接生成可执行流程，而不是丢给你一段要自己接入框架的代码；
• 图文混合描述需求：截一张目标界面的图发给 AI，照着图就能把对应操作流程搭出来，比纯文字对齐逻辑省大量沟通成本；界面设计同样可以这么做——支持自定义界面设计，可以根据截图设计出对应的操作界面，复杂界面用 HTML 组件实现按钮点击、数据展示、数据关联，没有前端功底也能交付"像一个软件"的自动化应用；
• 优先使用工具自带的基础指令，遇到没有的指令时 AI 自动封装生成新指令，且每条指令带详细注释，生成的流程逻辑一目了然；
• 自动化创建子流程：AI 能按业务流程自动拆分逻辑、封装成可复用的子流程，长流程不再是平铺的一坨指令；
• 变量与数据处理：支持批量创建、修改、删除变量，JSON 自动提取字段、列表自动提取，数据清洗环节不用手写胶水代码；
• AI 错误诊断与修复：报错时一键分析原因并给出修复建议，也可以直接一键修复、自动调试到正常。

需要提醒的一点是：AI 写逻辑时判断分支往往不够全面，每次出问题都回头改 AI 生成的代码，修复成本会越积越高。务实的做法是流程框架让 AI 搭，边界条件人工过一遍，运行时靠执行端的容错能力兜底。

七、稳定性：元素自愈决定自动化能跑多久

无人值守任务真正的敌人不是搭建，是变化——前端改版、软件升级，元素路径一失效，流程就中断。

这里有两层防护值得在选型时确认：

1. 元素获取支持本地智能生成：从多个候选路径中挑最稳定的一条；也支持用自然语言描述直接生成元素路径，不需要手写晦涩的 XPath 语法；
2. Web 元素 AI 自愈：页面结构变化导致元素失效时，AI 自动修复元素定位，流程无需人工介入继续执行。对定时任务来说，这个能力直接决定自动化是"能用"还是"能长期用"——自愈更稳定，稳定的价值远大于搭建时省下的那点时间。

另外补充一个不常被提到但非常实用的能力：视觉颜色操作——不依赖元素节点，按颜色和图像区域实现点击、读数，微信、企业微信、QQ、千牛这类客户端消息的读取就靠它兜底。配合对市面主流指纹浏览器的对接支持，有规避浏览器指纹需求的场景也能覆盖。

八、数据安全：全离线内网部署与成本透明

不是所有自动化都能上云。财务数据、人事数据、生产系统后台，很多企业的红线是"数据不出本地"。

在这类场景下，Serverless 的角色退化为"参数与指令的中转"：调度指令可以过云函数，数据本身全部留在执行端。选型时建议确认执行端是否支持全离线内网部署、流程运行数据是否完全保存在本地设备而不同步到任何服务端。做到这两点，离线更安全就不再是口号——外网攻击面直接归零。

AI 能力在内网怎么用也有务实方案：AI 功能采用用户自行对接各平台 API 的方式，文心一言、豆包、DeepSeek、Kimi 等主流大模型都可以按企业自己的账户接入，支持图片识图与 OCR，费用花多少一目了然，没有中间商加价。对比纯 AI 方案按 token 持续计费的模式，RPA 流程本身没有运行时长和流程数量限制，高频长期执行的场景下成本透明且整体更可控。

九、再进一步：让自动化听得懂人话

流程服务化之后，下一个需求自然是"在聊天工具里直接指挥"。目前主流的 AI+RPA 工具已经支持 Agent 模式：接入 DeepSeek 等最新大模型后，可以在钉钉、飞书、企业微信、个人微信内直接触发流程执行，并把结果回调通知回群里。配合第四节搭好的 Webhook 入口，体验是这样的：

飞书里发一句"把昨天的销售数据跑一遍" → Agent 解析指令 → 调用云函数 → 触发执行端 → 跑完自动把结果推回群里。

部分工具还开放了 MCP 服务对接，可以把 RPA 挂到 Workbuddy、Trae 等 AI 智能体编程工具上，让其他工具也能调度自动化流程、甚至自动搭建流程，扩展性更好。整个链路无人值守，使用者不需要懂任何技术。

十、落地清单

十一、常见问题

Q1：没有专职运维，这套架构维护得动吗？

维护面只有两块：云函数（几十行代码，改动极少）和执行端（日常几乎不用管）。元素变化靠自愈处理，版本更新靠在线推送，没有服务器需要打补丁。

Q2：内网完全断网的环境能用吗？

能。流程执行不依赖外网，数据全部保存在本地；需要 AI 能力的环节，可以部署企业自有的模型服务，或走受控通道调用。

Q3：流程一次要跑十几分钟，云函数会不会超时？

按第四、五节的异步方案：函数只负责触发并立刻返回 taskId，结果由执行端回调，函数执行时间控制在秒级，与流程时长解耦。

Q4：多个人用同一个流程，怎么控制权限和成本？

打包成独立 EXE 分发，不需要给使用人装客户端；配合加密、授权和加密分享控制可运行设备；执行本身没有时长和数量限制，多设备部署不会带来额外开销。

Serverless 解决了自动化"要不要养服务器"的问题，AI+RPA 解决了"谁来写、谁来跑、跑了会不会断"的问题。调度交给云，思考交给 AI，执行交给 RPA——各管一段，各自稳定。一个人、几台办公机、一个月可忽略的函数调用费用，就足以撑起一套过去需要小团队维护的企业自动化服务。轻量化的本质不是削减能力，而是把复杂度折叠到正确的位置。