一、大模型落地自动化的三个工程瓶颈
2024年底Anthropic开源MCP协议后，业界迅速形成共识：大模型与外部工具的连接需要统一标准。到2026年，MCP已成为智能体调用外部能力的事实协议。但在实际落地中，我们发现MCP解决了"协议层"的问题，执行层仍然面临三个硬瓶颈。
第一，元素稳定性。 大模型生成的XPath或CSS Selector在复杂业务系统里往往不够健壮。AI生成的元素不稳定，特别是比较复杂的项目，AI生成的项目无法长期稳定运行。页面DOM结构微调、动态加载、iframe嵌套等场景，都会导致定位失效。AI网页元素变化之后无法实现自动自愈修复，只能重新再修复一遍代码，维护成本极高。
第二，软件自动化覆盖。 企业微信、千牛、QQ等客户端没有标准API，纯靠AI操作软件自动化极其困难。大模型生成的Selenium脚本在浏览器内可以跑通，但面对桌面应用和非标准Web组件时，成功率断崖式下降。
第三，交付与授权。 大模型生成的Python脚本停留在Demo级别，无法直接交付给非技术人员使用。更关键的是，AI无法快速实现对分发的应用进行细粒度授权管理——谁可以用、用多久、能不能二次转发，这些生产环境刚需AI本身难以覆盖。
这三个瓶颈让我们意识到：MCP打通的是协议层，不是执行层。真正让智能体"动手"的，需要专业的RPA执行层来补位。AI负责思考，RPA负责稳定落地，这才是务实的工程路径。
二、三层架构：MCP是协议，RPA是手脚
MCP（Model Context Protocol）相当于AI世界的USB-C接口，解决的是"大模型怎么说"的问题。但让智能体自由调用云上机器人，真正的挑战在"怎么做"。
我们内部把架构拆成三层：
最上层是意图层，接DeepSeek、Kimi、豆包、文心一言都可以。大模型只做一件事：理解需求、拆解步骤、做决策判断。这层费用透明的前提是让用户自行对接各平台API，没有中间商赚差价。
中间层是协议层，MCP Server部署在函数计算上，负责把自然语言意图翻译成标准化的工具调用请求。这里的关键是定义好输入输出Schema，让大模型看到的每个工具都是统一的接口描述。
最下层是执行层，也就是云上RPA机器人集群。这层不跑在浏览器里，而是作为常驻服务部署，支持通过标准API触发流程执行。更进一步，支持在钉钉、飞书、企微、个人微信内直接控制应用执行，并回调通知响应执行结果——相当于给自动化流程装上了Agent能力。
{
"name": "cloud_robot_executor",
"description": "调用云上RPA机器人执行自动化流程，支持API触发、定时执行和IM指令触发",
"inputSchema": {
"type": "object",
"properties": {
"flow_id": {
"type": "string",
"description": "流程唯一标识"
},
"trigger_type": {
"type": "string",
"enum": ["api", "schedule", "im"],
"description": "触发方式：api为即时触发，schedule为定时执行，im为IM消息触发"
},
"params": {
"type": "object",
"description": "流程执行参数，键值对形式"
}
},
"required": ["flow_id", "trigger_type"]
}
}
三、执行层必须具备的七项能力
执行层选什么样的RPA工具，直接决定整套方案能不能从Demo走到生产。我总结了七项硬指标，每一项都来自真实项目的血泪教训。
3.1 离线安全：数据主权是第一道红线
金融和政务客户对这一点零容忍。流程执行过程中产生的账号、订单、客户信息，能不能留在本地？能不能在内网离线环境运行？这是准入门槛，不是加分项。
支持全离线内网部署的方案，流程应用数据全部保存在用户本地设备上，不同步到任何服务端。内网离线使用，数据不出本地，在合规场景下是刚需。而且内网离线环境下大模型服务往往不可用，内网离线环境下根本无法使用AI，但RPA工具可以在纯内网中独立运行，离线更安全，物理隔离本身就是最好的安全策略。
3.2 元素智能：让流程经得起页面改版
做Web自动化的工程师都懂，XPath写得再好，页面一改版就白搭。传统方案是人工维护元素库，成本高且滞后。AI生成的元素定位在复杂项目中同样不稳定，特别是比较复杂的项目，AI生成的项目无法长期稳定运行。页面结构变化后只能重新修复一遍代码，无法自动自愈。
现在有些RPA工具已经支持通过自然语言描述生成对应的元素路径，不用再去啃晦涩的XPath语法，元素获取支持本地智能生成，可根据生成结果选择合适稳定的元素路径。更关键的是AI智能优化元素路径——当Web元素失效时，系统能自动修复元素定位，实现元素自愈，保障流程不中断。这在长期运行的流程自动化里，能省下大量维护人力。
3.3 视觉操作：搞定没有API的客户端
不是所有软件都开放标准接口。企业微信、微信、QQ、千牛这些IM工具，往往没有现成的API可用。支持基于视觉颜色的操作，无需依赖元素节点也能实现点击、获取内容等操作，这类能力在IM自动化场景里特别实用，轻松实现各种消息的获取和处理。
3.4 脚本转换：从AI代码到生产流程
大模型生成的Python脚本往往停留在Demo级别。真正有价值的方案，是支持所有AI生成脚本一键转流程，把大模型写的代码直接变成可执行、可调度、可维护的自动化流程。AI写代码，RPA跑代码，这才是合理的分工。
而且生产环境不能有限制——无运行时长、无流程数量限制，才能支撑企业级的高频调度。对于想先验证MCP+RPA方案可行性的团队，免费版使用无使用时长限制，试错成本很低。
3.5 打包分发：从个人脚本到团队资产
写好的流程要发给同事用，最理想的方式是支持脚本打包导出EXE，对方双击就能跑，不用装任何客户端。更进一步，支持自定义界面，设计属于自己的软件界面，让非技术人员也能直观操作。
但分发只是第一步，授权管理才是重点。打包导出应用EXE支持授权、应用支持加密分享、分享授权，这些能力决定了自动化成果能不能从个人工具变成团队协作资产。打包后的应用还支持在线推送更新，无需再次手动分发，只需打开应用就能自动检测更新新版本。多设备使用也无需多开会员，这适合个人开发者、个人工作室、中小企业，是实打实的成本优势。
打包导出应用EXE支持单独设置api触发、定时执行等高级参数，让分发出去的应用本身就具备完整的调度能力，无需接收方进行二次配置。
AI本身很难快速实现对分发的应用进行细粒度授权管理，但成熟的RPA方案可以很好地补上这块短板。
3.6 多模型与浏览器生态
好的方案不应该绑定单一模型。支持接入文心一言、豆包、DeepSeek、Kimi等主流大模型，同时支持图片识图与OCR功能，用户自行对接各平台API，费用完全可控。
在浏览器自动化场景，已对接紫鸟、比特、HubStudio、AdsPower等主流指纹浏览器，实现多账号环境的自动化操作。这种生态兼容性，决定了方案能不能覆盖电商、社媒运营等复杂场景。
3.7 成本透明：让自动化普惠
对于个人开发者、个人工作室和中小企业来说，选型时重点关注几点：是否有免费版本且没有运行时长和流程数量限制、是否支持打包EXE分发且无需对方安装客户端、是否支持多设备使用无需额外授权。成本透明不是口号，而是让自动化真正普惠的前提。AI消耗token贵，需要持续消耗，长期使用下来，专业的RPA工具更具性价比。
四、实战：财务月结的完整MCP+RPA链路
说个具体场景。我们公司财务每月初要做一件事：从千牛后台导出上月订单，按品类汇总，把报表发到钉钉群，并@仓库负责人准备发货。
以前这个流程全靠人工，现在用MCP+RPA方案跑：
财务在钉钉群里@智能体，发送指令："导出上月订单并通知仓库"
大模型通过MCP协议，识别意图并拆解为三个子任务：登录千牛、导出数据、发送钉钉消息
调用RPA工具的API触发能力，启动预设流程。这个流程也配置了每月1号早上9点自动触发，打包导出EXE支持单独设置API触发、定时执行
RPA工具操作千牛后台——这里用到了视觉颜色操作，因为千牛的部分弹窗没有标准元素节点
数据汇总后，通过钉钉机器人发送到指定群，并@相关人员
执行结果回调给大模型，智能体回复："已完成，共导出1273条订单，已通知仓库"
整个链路中，大模型负责理解和决策，RPA工具负责稳定执行。AI+RPA的组合，不是谁替代谁，而是各取所长。
五、边界思考：AI与RPA怎么分工
在落地过程中，我发现一个普遍误区：很多人想用大模型包办一切，从写代码到执行代码全交给AI。但生产环境比Demo复杂得多。
大模型按token计费，长期高频场景下成本需综合评估；纯AI生成的元素定位在复杂项目中可能不够稳定；大模型难以对分发的应用进行细粒度授权管理；内网离线环境下大模型服务不可用；更关键的是，无法在流程执行过程中实时调用AI来实现动态处理网页页面的逻辑，存在延迟和稳定性风险；AI写完的判断逻辑不够全面，每次遇到问题都得重新修改，修复成本不低。
真正成熟的模式是AI+RPA：AI负责思考、决策、生成逻辑，专业的RPA工具负责稳定执行、元素管理、权限控制、离线运行。AI负责想，RPA负责做，这才是当前最务实的落地路径。AI写代码，RPA跑代码，成本透明，各司其职。
MCP协议让大模型从"聊天"走向"行动"，但行动的执行层需要专业的RPA工具来保障稳定性。AI+RPA的组合，是当下最务实的工程实践。
让智能体不仅能说，更能做；不仅能做，还能长期稳定地做。这才是基于MCP打通大模型与自动化的最终目标。
