过去几年，RPA 一直是企业自动化的主力工具。财务录入、订单处理、网页填报、系统搬运数据，很多原本需要人工重复点击的工作，都可以通过 RPA 机器人完成。
但随着大模型和 AI Agent 的发展，企业自动化正在发生一次结构性变化：RPA 不会消失，但它的角色正在从“自动化主角”变成“确定性执行器”；AI Agent 也不是简单替代 RPA，而是上升为流程理解、任务规划、异常判断和执行编排的大脑。
更准确地说，未来企业自动化不是：
大模型 → 直接操作所有系统
而是：
业务目标
↓
流程理解 / 文档理解 / 任务识别
↓
AI Agent 规划与判断
↓
编排、权限、审计、人工确认
↓
API / RPA / Browser Agent / OpenCLI / 桌面自动化
↓
业务系统执行
这就是 AI Agent 与 RPA 技术收敛的核心。
一、RPA 解决的是“怎么做”，Agent 解决的是“做什么、为什么做、失败怎么办”
传统 RPA 的强项是稳定、可重复、可审计。比如打开某个网站，点击某个按钮，填写固定字段，提交表单。只要页面结构不变、流程规则不变，它就可以长期稳定运行。
但 RPA 的弱点也很明显：
| 问题 | 影响 |
|---|---|
| 流程变化后容易失效 | 页面按钮、字段位置、弹窗变化都会导致失败 |
| 缺少上下文理解 | 不知道业务含义，只知道执行动作 |
| 异常处理能力弱 | 遇到非标准情况通常需要人工介入 |
| 跨系统决策能力弱 | 不擅长判断下一步应该走哪个系统或流程 |
| 开发维护成本高 | 大量脚本需要人维护 |
AI Agent 补的正是这部分能力。它可以理解自然语言任务，读取邮件、文档、网页、系统返回信息，再决定下一步调用哪个工具、走哪个流程、是否需要人工确认。
所以二者不是互斥关系，而是分工关系：
| 层级 | 更适合的技术 |
|---|---|
| 流程理解 | AI Agent / LLM / 流程挖掘 |
| 任务拆解 | AI Agent |
| 高风险判断 | AI Agent + 规则引擎 + 人工确认 |
| 稳定动作执行 | API / RPA / 脚本 |
| 无 API 页面操作 | Browser Agent / Computer Use / OpenCLI |
| 审计与治理 | 工作流引擎 / 权限系统 / 日志系统 |
这也是 UiPath、Microsoft、ServiceNow、SAP 等企业软件厂商正在靠近的方向：把确定性自动化、Agent 能力、流程编排和治理能力放在同一个企业平台里。UiPath 在 FY2026 财报中也明确把“deterministic automation、agentic AI、enterprise-grade orchestration”放在同一套平台叙事中。
二、为什么现在大家开始谈“Agent + RPA”，而不是单独谈 RPA？
因为企业自动化的对象变了。
过去 RPA 主要处理的是“规则明确、界面固定、动作重复”的流程。比如：
登录系统 → 下载文件 → 复制字段 → 粘贴到另一个系统 → 提交
但现在企业希望自动化的不只是简单搬运，而是更复杂的知识工作：
读一封客户邮件
判断客户要订几票货
识别缺失字段
根据船司、港口、约号、箱型做规则校验
决定是否可以自动订舱
如果没有 API，再去船司网站录入
异常时通知人工处理
这种流程已经不是单纯点击脚本能解决的。它同时包含：
| 能力 | 说明 |
|---|---|
| 文档理解 | 邮件、PDF、Excel、截图、附件 |
| 业务规则判断 | 字段是否缺失、是否高危、是否需要确认 |
| 多系统调用 | CRM、OMS、TMS、船司平台、邮件系统 |
| 异常处理 | 没有舱位、字段冲突、页面变化、接口失败 |
| 人机协同 | 高风险动作需要人工确认 |
| 审计追踪 | 谁触发、Agent 做了什么、结果是什么 |
这就要求自动化系统从“脚本驱动”升级成“智能编排驱动”。
三、目前全球主要研究方向，可以分成十类
1. Agent 驱动编排
这是最核心的方向。它研究的是如何让 Agent 不只是回答问题，而是能管理任务状态、选择工具、调用 API、触发 RPA、等待人工确认、失败后回退。
代表生态包括 Microsoft Agent Framework、AutoGen、LangGraph、CrewAI，以及 UiPath Maestro、ServiceNow AI Agent Orchestrator、Microsoft Copilot Studio 等。Microsoft Agent Framework 的定位就是构建、编排和部署 AI Agent 与多 Agent 工作流。
成熟度判断：早期商用到快速成熟阶段。
企业价值很高，因为它是 Agent-RPA 融合的“控制层”。
2. LLM 任务规划
这个方向研究的是：用户只说一句目标，模型能不能自动拆成步骤。
例如：
帮我处理这票订舱异常
Agent 需要自动拆成：
读取订单
检查缺失字段
查询船司返回
判断是否需要客户补充
生成提醒
必要时触发 RPA 重新提交
这个方向技术进展很快，但企业生产环境不能完全依赖模型自由规划，因为模型可能规划错误、漏掉关键审批、误判业务风险。
成熟度判断：原型到早期商用。
适合做“辅助规划”，不适合无约束地接管核心流程。
3. RPA + 强化学习
传统 RPA 是录制脚本，页面变了就容易失败。RPA + RL 方向希望让系统具备自适应能力：按钮位置变了、弹窗出现了、步骤异常了，Agent 可以自己尝试恢复。
OpenAI 的 Computer-Using Agent 就属于这个大方向。OpenAI 介绍 CUA 时说明，它结合 GPT-4o 的视觉能力和通过强化学习获得的高级推理能力，可以通过屏幕、鼠标、键盘与 GUI 交互，而不依赖系统专用 API。
但这个方向目前最大问题是稳定性。OpenAI 公布的 CUA 在 OSWorld 上成功率为 38.1%，而人类基准为 72.4%，说明距离真正稳定的企业级无人值守还有明显差距。
成熟度判断：研究到试点阶段。
适合高价值、低频、长尾场景，不适合作为企业默认执行路径。
4. 语义流程理解
这是最容易被低估、但最适合企业优先投入的方向。
它不是直接问“怎么自动化”，而是先问：
流程到底怎么跑？
哪些节点最耗时？
哪些异常最多？
哪些动作适合 API？
哪些动作适合 RPA？
哪些必须人工确认？
这类方向包括流程挖掘、任务挖掘、文档理解、事件日志分析。PM4Py、ProM、Apromore、UiPath Task Mining、Microsoft Power Automate Process Mining 都属于相关生态。
成熟度判断：传统流程挖掘已成熟商用，LLM 增强的语义理解处于早期商用阶段。
企业价值非常高，因为它可以避免“为了 Agent 而 Agent”。
5. 端到端 Autonomous Agent
这是最吸引眼球的方向：Agent 直接打开浏览器或桌面软件，像人一样看屏幕、点按钮、输入内容、完成任务。
典型项目包括 OpenAI Operator/CUA、Anthropic computer use、browser-use、OpenCUA、UI-TARS、BrowserGym、OSWorld 等。
WorkArena 是一个很有代表性的企业任务评测基准，它基于 ServiceNow 平台构建了企业知识工作任务，用来测试 Web Agent 能不能完成真实企业软件中的常见操作。其 GitHub 说明中也强调，该 benchmark 尚未被解决，Agent 在一些 UI 操作中仍会失败。
成熟度判断：原型到试点阶段。
它很重要，但不应该被误认为“马上替代所有 RPA”。
6. 安全、权限与验证
一旦 Agent 能操作浏览器、调用 API、执行 shell 命令，它就不再是聊天机器人，而是一个“有操作能力的数字员工”。
所以企业必须解决：
Agent 能访问什么？
能执行什么命令？
是否需要审批？
是否能回放？
是否有审计？
是否能防止越权？
是否能防止 prompt injection？
NIST 在生成式 AI 风险管理框架中强调，组织需要在 AI 产品和系统的设计、开发、使用、评估阶段纳入可信性和风险管理考虑。
成熟度判断：安全框架成熟，Agent 专用治理仍在快速发展。
这是进入生产环境的前提，不是可选项。
7. 低代码 / 无代码 Agent-RPA 平台
这是商业化最快的方向。
UiPath Agent Builder、Microsoft Copilot Studio、Automation Anywhere AI Agent Studio、ServiceNow AI Agent Studio 这些产品，本质上都是希望让企业通过可视化方式构建 Agent、连接业务系统、编排流程、接入人工审批。
Microsoft Copilot Studio 的官方定位就是用于创建和管理 Agent，并连接企业数据，通过自然语言创建和发布 Agent。
成熟度判断：早期商用到成熟商用。
这是大企业最容易采购、最容易试点、也最容易被治理的平台路线。
8. Human-in-the-loop 人机协同
企业级 Agent-RPA 最现实的路线，不是全自动，而是：
低风险自动执行
中风险系统提醒
高风险人工确认
异常进入人工池
例如订舱系统中，箱型箱量、港口、约号、付款方式、收发通长字段等，都可以设定风险等级。低风险字段自动通过，高风险字段要求人工确认。
成熟度判断：非常成熟。
这是当前企业落地 Agent 自动化时最重要的安全阀。
9. Benchmarking 与 Metrics
Agent-RPA 不能只看 demo。demo 能跑通，不代表生产稳定。
企业真正需要看的是：
| 指标 | 说明 |
|---|---|
| 自动完成率 | 不需要人工介入的比例 |
| 任务成功率 | 从开始到结束完整成功的比例 |
| 字段准确率 | 关键字段是否提取正确 |
| 异常识别率 | 是否能识别高风险情况 |
| 人工返工率 | 人工纠错比例 |
| 平均处理时长 | 每票、每单、每任务耗时 |
| 单任务成本 | 模型、RPA、人工综合成本 |
| 失败可回放率 | 出错后是否能复盘 |
WorkArena、BrowserGym、OSWorld 这些基准的意义就在于：它们把 Agent 从“聊天能力评测”推进到“真实软件操作能力评测”。
成熟度判断：研究到早期商用。
未来企业选型时，评测体系会越来越重要。
10. OpenCLI 类项目：Agent 与真实软件之间的“接口胶水层”
OpenCLI 的思路是：把任意网站、Electron 应用或本地工具，变成 Agent 可以调用的 CLI 接口。
OpenCLI 官方介绍中提到，它可以把网站或 Electron App 转成命令行接口，复用 Chrome 登录状态，支持浏览器自动化、桌面应用控制、AI-powered discovery，并且面向 AI Agent 使用。
这类项目的价值在于：很多企业系统没有标准 API，也不一定适合传统 RPA 平台接入，但可以通过 CLI、Browser 控制、MCP、脚本封装等方式暴露为 Agent 工具。
典型方向包括：
| 项目类型 | 代表项目 | 价值 |
|---|---|---|
| 网站转 CLI | OpenCLI | 把无 API 网站封装成可调用命令 |
| 浏览器 Agent | browser-use、agent-browser、open-operator | 让 Agent 操作网页 |
| 终端 Agent | OpenHands CLI、Codex CLI、Gemini CLI、Aider、Goose | 自动执行开发、运维、脚本任务 |
| 安全运行时 | OpenShell | 给 Agent 提供沙箱、策略和运行边界 |
| 软件 Agent-native | CLI-Anything | 尝试让任意软件变成 Agent 可操作对象 |
OpenCLI 类项目不是完整 RPA 平台，也不是流程治理平台。它更像是：
Agent 的手
而不是：
Agent 的大脑
所以它适合做“最后一公里执行层”，不适合单独承担企业级流程编排、权限治理和审计。
四、哪些方向已经商业化？收入情况怎么看？
目前真正形成大规模商业收入的，不是某个单独的“通用 Agent 产品”，而是原有企业软件平台把 Agent 能力嵌入自己的自动化、流程、云服务和业务套件里。
| 公司 | 相关能力 | 收入口径 |
|---|---|---|
| UiPath | Agentic Automation、Agent Builder、Maestro、RPA 平台 | FY2026 全年收入 16.11 亿美元，ARR 18.53 亿美元。 |
| Microsoft | Copilot Studio、Power Automate、Agent Framework、Computer Use | FY2026 Q3 披露 AI 业务年化收入运行率超过 370 亿美元。 |
| ServiceNow | AI Agent Studio、AI Agent Orchestrator、Now Assist | 2025 全年总收入 132.78 亿美元；Now Assist 等 AI 产品线未完全单独披露。 |
| SAP | Joule、Business AI、Build Process Automation | 2025 总收入 368 亿欧元，云收入 210.23 亿欧元。 |
| OpenAI / Anthropic | Operator、CUA、computer use | Agent 产品线收入未单独披露 |
| OpenCLI 类开源项目 | CLI Agent、Browser Agent、DevOps Agent | 多数处于开源、试点或开发者工具阶段，商业收入不明确 |
这里要注意一个判断：目前 Agent-RPA 的商业化收入，大多隐藏在平台收入里，而不是单独披露为“Agent 收入”。
也就是说，市场已经商业化，但商业化形态不是“买一个通用 Agent”，而是：
买 UiPath / Microsoft / ServiceNow / SAP 的平台
里面附带 Agent、RPA、流程编排、文档理解、审批和治理能力
五、考虑成本与不考虑成本，企业应该选哪条路线？
情况一：考虑执行成本
如果企业考虑模型调用成本、RPA 维护成本、人工兜底成本、失败返工成本，那么最佳路线是：
流程理解
+ 低代码编排
+ 有边界的 Agent 判断
+ API 优先
+ RPA / OpenCLI 补洞
+ 人工确认兜底
这条路线最务实。
原因很简单：模型推理贵，失败回放贵，长链路 Agent 不稳定也贵。与其让大模型从头到尾操作所有系统，不如只让它参与“真正需要理解和判断”的环节。
比如自动化订舱场景中，合理路径应该是：
邮件 / 附件 / API 数据
↓
IE 信息抽取
↓
规则校验 + Agent 风险判断
↓
人工确认高危字段
↓
生成标准订舱数据
↓
优先调用船司 API
↓
无 API 时走 RPA / OpenCLI / Browser Agent
↓
结果回写 + 审计 + 异常池
情况二：不考虑执行成本
如果不考虑成本，最强路线是：
语义流程理解
+ Agent 编排
+ 安全验证
+ Human-in-the-loop
+ Computer Use
+ OpenCLI
+ RPA
+ API
也就是所有能力都上，但仍然不能让 Agent 完全自由执行。即使不考虑成本，也必须考虑安全、稳定性和责任边界。
真正企业级可用的系统，不是一个“全能 Agent”，而是一个多层混合架构：
能走 API 的走 API
API 不够走 RPA
RPA 不适合走 OpenCLI / Browser Agent
高风险动作进人工确认
所有动作有审计和回放
失败后能回退到人工或规则流程
六、多维度对比：哪些方向最适合企业优先投入？
评分说明：稳定性、成熟度、可扩展性、安全合规越高越好；执行成本越高表示越贵。
| 方向 | 稳定性 | 成熟度 | 执行成本 | 企业推荐度 | 结论 |
|---|---|---|---|---|---|
| 语义流程理解 | 高 | 高 | 中 | 很高 | 最适合先做，避免盲目自动化 |
| 低代码 Agent-RPA 平台 | 高 | 高 | 中 | 很高 | 最容易商用落地 |
| Human-in-the-loop | 很高 | 很高 | 中 | 很高 | 企业级必备安全阀 |
| Agent 驱动编排 | 中高 | 中高 | 中 | 高 | 未来核心控制层 |
| 安全与验证 | 高 | 中 | 中 | 很高 | 生产环境前提 |
| Benchmarking / Metrics | 中 | 中 | 低中 | 高 | 防止 demo 欺骗 |
| OpenCLI 类接口层 | 中 | 中 | 低中 | 中高 | 适合补无 API 系统 |
| LLM 任务规划 | 中低 | 中 | 中高 | 中 | 适合辅助，不适合完全自治 |
| 端到端 Autonomous Agent | 中低 | 中低 | 高 | 中 | 适合长尾场景，不适合默认路径 |
| RPA + RL 自适应自动化 | 低中 | 低中 | 很高 | 中低 | 潜力大，但生产还早 |
综合来看，最适合企业当前投入的是：
流程理解 + 编排平台 + HITL + 安全治理 + 可回退执行层
而不是：
直接让一个大模型操作所有系统
七、对海运物流自动化的启发
放到海运订舱、提单、放舱、船司平台录入这些场景里，AI Agent 与 RPA 的收敛非常有价值。
因为海运业务天然具备几个特点：
| 特点 | 对自动化的影响 |
|---|---|
| 邮件和附件多 | 需要 IE、LLM、OCR、文档理解 |
| 字段复杂 | 港口、箱型、约号、付款方式、收发通、品名、HS Code 都有行业规则 |
| 船司系统多 | 不同船司 API、网页、流程差异大 |
| 异常多 | 缺字段、舱位变化、约号错误、付款地冲突 |
| 风险高 | 错订、漏订、错填收发通会影响业务 |
| 不可能 100% 自动化 | 必须有人工确认和异常池 |
所以更合理的架构不是“AI 全自动订舱”，而是：
客户邮件 / 附件 / API
↓
字段抽取与标准化
↓
业务规则校验
↓
Agent 判断风险与下一步动作
↓
人工确认高危字段
↓
标准订舱模型
↓
船司 API 优先
↓
无 API 走 RPA / OpenCLI / Browser Agent
↓
结果回写、截图留存、日志审计
这条路线的关键是：Agent 不直接承担全部责任，而是负责理解、判断、调度；真正执行由 API、RPA、OpenCLI 等受控工具完成。
八、最终结论：未来不是 RPA 消失，而是 RPA 被 Agent 编排
AI Agent 与 RPA 的收敛，本质上不是“大模型替代机器人”，而是企业自动化架构从脚本时代进入智能编排时代。
未来的企业自动化会呈现这样的分工：
Agent：理解目标、拆解任务、判断异常、选择工具
RPA：执行稳定、重复、可回放的界面动作
API：执行最可靠、最低成本的系统集成
OpenCLI：补齐无 API、难集成、长尾软件的最后一公里
HITL：处理高风险、不确定、需要责任归属的节点
治理层：负责权限、审计、沙箱、策略和回放
所以真正值得投入的不是单点工具，而是一个企业级混合自动化体系：
流程理解
+ Agent 编排
+ API 优先
+ RPA 执行
+ OpenCLI 补洞
+ 人工确认
+ 安全审计
+ 指标评测
一句话概括：
AI Agent 让自动化从“会点击”升级为“会理解和调度”；RPA、API、OpenCLI 则让 Agent 的决策能够安全、稳定、可审计地落地。
