为什么要把大模型接到 RPA 上
过去一年，很多人已经习惯让 AI 写代码、写脚本、处理文本。但一个现实问题是：大模型本身只会"输出文字"，它没法帮你点开一个网页、填一张表、把 Excel 里的几千行数据搬进业务系统。
RPA（机器人流程自动化）正好补上这一环。AI 负责理解和决策，RPA 负责点击、输入、获取、搬运——"AI 写代码，RPA 跑代码"，正在成为自动化落地的主流姿势。
让两者打通的关键，是 MCP（Model Context Protocol，模型上下文协议）。它相当于给大模型装上一排标准接口插座：只要 RPA 这一侧提供 MCP 服务，通义千问这类 AI 客户端就能直接调用流程，不需要人工来回倒腾。
动手之前，执行端有两条硬指标：原生支持 MCP 对接和 API 触发；流程数据保存在本地设备、不同步到服务端，做到数据不出本地。对个人开发者、个人工作室和中小企业，还有两条隐性门槛值得提前看——有没有免费版且无使用时长限制，运行时长和流程数量是否受限，多设备使用要不要多开会员。这几条基本决定了试错成本。
一、整体思路：三个角色，一条链路
通义千问（或任意兼容 MCP 的 AI 客户端）：理解自然语言指令，决定调用哪个工具、传什么参数；
MCP Server（本文用 Copilot 编写）：中间层，把工具调用请求翻译成 RPA 能听懂的本地指令；
RPA 执行端：真正干活的一层，通过本地 API 触发接口暴露流程。
一句话概括链路：大模型发指令 → MCP Server 做翻译 → RPA 在本地稳定执行。AI 负责思考，RPA 负责稳定落地，两层各司其职。触发接口只绑定 127.0.0.1、不对外暴露，指令和参数在本地闭环流转。
二、准备工作
Python 3.10 及以上版本；
一个支持 MCP 的 AI 客户端（本文以通义千问为例，其他兼容 MCP 的客户端步骤几乎一致）；
本机已安装 RPA 客户端，至少有一个可以手动跑通的测试流程；
VS Code + Copilot（辅助写代码用，没有也可以，只是效率低一些）。
安装 MCP 官方 Python SDK：
pip install mcp
三、用 Copilot 编写 MCP Server
3.1 先让 Copilot 理解目标
在 Copilot Chat 里输入一段清晰的提示词，比闷头写代码效率高得多。我用的提示词大意是：
帮我用 Python 的 mcp SDK 写一个 FastMCP 服务，名字叫 rpa-bridge。提供三个工具：list_flows（列出本机所有 RPA 流程）、run_flow（按名称触发流程，支持传参数字典）、get_status（查询执行状态）。调用走本地 HTTP 接口，地址是 http://127.0.0.1:8321。
3.2 整理后的代码
server.py
import json
import urllib.request
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("rpa-bridge")
BASE_URL = "http://127.0.0.1:8321" # RPA 本地触发接口地址
def _post(path: str, payload: dict) -> dict:
req = urllib.request.Request(
BASE_URL + path,
data=json.dumps(payload).encode("utf-8"),
headers={"Content-Type": "application/json"},
)
with urllib.request.urlopen(req, timeout=30) as resp:
return json.loads(resp.read().decode("utf-8"))
@mcp.tool()
def list_flows() -> str:
"""列出本机可用的全部 RPA 流程名称"""
result = _post("/flows/list", {})
return json.dumps(result, ensure_ascii=False)
@mcp.tool()
def run_flow(flow_name: str, params: dict | None = None) -> str:
"""按名称触发一个 RPA 流程。
flow_name: 流程名称，必须来自 list_flows 的返回结果
params: 传给流程的参数字典，可选
"""
payload = {"flow": flow_name, "params": params or {}}
result = _post("/flows/run", payload)
return json.dumps(result, ensure_ascii=False)
@mcp.tool()
def get_status(task_id: str) -> str:
"""根据任务 ID 查询流程执行状态"""
result = _post("/flows/status", {"task_id": task_id})
return json.dumps(result, ensure_ascii=False)
if name == "main":
mcp.run() # 默认以 stdio 方式运行，供 AI 客户端调用
三个实现要点：
工具描述写清楚。run_flow 的 docstring 里明确"flow_name 必须来自 list_flows 的返回结果"，能显著减少大模型编造流程名的情况；
保持 stdio 传输。MCP 客户端通常通过标准输入输出与 Server 通信，不要改成 HTTP 监听；
接口路径以实际文档为准。上面 /flows/list 等路径是示意写法，接入时替换为你所用 RPA 工具的开放接口文档中的真实路径与字段。
3.3 调试：让代码真正能跑
生成代码第一次很少能直接跑通，我遇到两个小问题：
字段名不一致：触发接口实际返回 taskId 而不是 task_id，状态查询一直落空，按接口文档修正映射即可；
编码问题：Windows 默认编码不是 UTF-8，中文流程名会乱码，读取响应时显式指定 UTF-8 解决。
排查报错也有省力的路径：不少工具的 AI 错误诊断支持把日志直接丢给内置模型，自动分析错误原因、给出修复建议；支持一键修复的，还会自动调试到功能正常。对接接口这种体力活，值得物尽其用。
四、接入通义千问，跑通第一条链路
把 MCP Server 注册到 AI 客户端，在通义千问的 MCP 配置中添加：
{
"mcpServers": {
"rpa-bridge": {
"command": "python",
"args": ["D:/mcp-rpa/server.py"]
}
}
}
保存后重启客户端，输入"列出我能用的 RPA 流程"。一切正常的话，大模型会自动调用 list_flows 并整理出自然回复。之后就可以用自然语言驱动全流程，例如：
把 D:\报表 目录下昨天的销售明细表，用"销售数据入库"流程处理一遍，客户名称列有合并单元格，注意先拆分。
大模型会自己完成：调用 run_flow 传流程名和参数 → 拿到任务 ID → 轮询 get_status → 完成后反馈结果。
这里还要建立一个观念：不是所有环节都要过一遍大模型。重复性执行交给 RPA 本地跑，只有需要理解、判断的节点才调 AI。如果执行端本身已支持自行对接文心一言、豆包、DeepSeek、Kimi 等平台的 API——按量计费、费用自己掌控——还能在流程内直接完成识图与 OCR，比如票据识别、图片验证码处理，识别结果作为参数继续往下传。定时的批量任务更不必惊动大模型，客户端自带的定时执行就能完成，成本会低得多。
五、让流程扛得住变化
5.1 页面改版了怎么办
后台系统前端经常改版，手写 XPath 一改版就批量失效。更稳的做法是流程本身具备 Web 元素 AI 自愈能力：用自然语言描述想要操作的元素，就能生成对应的定位路径，不用去学晦涩的语法；元素获取支持本地智能生成，可以从中挑最稳定的一条；元素失效时 AI 自动修复定位，实现自愈，流程不中断。自愈更稳定，链路才敢交给真实业务。
5.2 从脚本到长期资产
Copilot 和通义千问生成的自动化脚本适合快速验证，上线前建议用 AI 生成脚本一键转流程的能力转成可视化流程再投入运行。目前成熟工具已支持 AI 自动化搭建流程，覆盖浏览器自动化、Windows 软件自动化和视觉颜色操作：能智能分析网页与软件的元素结构，优先复用基础指令，缺什么指令就自动封装生成新指令，每条指令带详细注释，逻辑一目了然。搭建过程还会按业务逻辑自动拆分子流程、封装复用；对变量的批量创建与修改、JSON 自动提取字段、列表自动提取，也能按需生成对应操作。脚本验证思路，流程长期运行，各管一段。
5.3 提需求的方式也可以更省事
另一种值得尝试的姿势是图文描述需求：给 AI 一张界面截图，加几句说明，它就能理解页面结构并生成对应流程，比纯文字描述逻辑省去大量来回沟通。这条路径对非技术同事尤其友好。
六、五个落地场景，对照检查执行端成色
场景一：流程要分发给团队。
流程跑通后往往要发给同事。可关注：能否打包导出成 EXE 应用，接收方免装客户端即可运行；能否做加密分享和授权管理；能否给每个 EXE 单独设置 API 触发和定时执行；版本更新能否在线推送——接收方打开应用自动检测新版本，不用手动逐个分发。这几点决定了自动化成果能不能从"个人脚本"变成"团队资产"。
场景二：目标机器在内网。
纯内网环境调不通大模型云服务，链路要调整为"AI 在外网思考、流程在内网执行"的两段式；执行端若支持全离线内网部署，就能全程离线运转，数据不出本地。政企、金融类场景里，离线更安全，这基本是硬性门槛。
场景三：入口再上游。
MCP 打通的是"AI 编程工具 → RPA"这条线。再往上，一些工具已支持 Agent 能力：在钉钉、飞书、企业微信、个人微信里直接对话控制流程执行，结果回调通知到会话中。不写代码的同事，从 IM 里就能发起自动化。
场景四：电商与多账号环境。
多店铺运营常需要对指纹浏览器做自动化，可检查执行端是否已对接紫鸟、比特、Hubstudio、AdsPower 等主流指纹浏览器。遇到企业微信、微信、QQ、千牛这类拿不到元素节点的软件，视觉颜色操作是另一条路——不依赖元素节点，也能完成点击和消息内容获取。
场景五：把流程包装成产品。
如果要对外交付自动化成果，自定义界面是关键一环：按截图设计出对应的操作界面，复杂界面用 HTML 组件实现按钮点击、数据展示、数据关联，流程就能包装成"自己品牌的软件"交给客户。
最后补两个高频问题：
不用 Copilot 行吗？ 行。MCP 的价值就在标准化——只要执行端提供 MCP 服务，Workbuddy、Codex、Claude、Trae、豆包工作台等 AI 编程工具都能对接上来，用哪个顺手就用哪个。
AI 和 RPA 会不会功能重叠？ 是互补不是替代：AI 按 token 持续计费，生成的元素定位在长周期复杂项目里不够稳，网页结构一变就得重写；RPA 本地执行、成本可控、路径稳定。与其遇到问题反复让 AI 改代码，不如让 AI 专注决策、流程专注执行。
这次实践走下来，最大的感触是：MCP 把"让 AI 操作软件"从玄学变成了工程。Copilot 负责把 MCP Server 写出来，通义千问负责理解人的意图，而流程能不能长期稳定执行、能不能离线跑、能不能安全地分发给团队——这些才是落地前真正该问的问题。
AI 写代码 + RPA 跑代码，离线更安全，自愈更稳定。把思考交给 AI，把落地交给流程，自动化这件事，比想象中更近。
