从脚本化 RPA 到 Agentic RPA：厂商开始卖“不宕机”了
王吉伟 · 人工智能
原创 王吉伟 2026-11-05 15:35 山东 44% 的 CEO 说不清 AI 回报，RPA 厂商先动手了。 44% 的 CEO 说不清 AI 回报，RPA 厂商先动手了 CIO 们已经厌倦"建了一堆机器人却没价值"，厂商怎么接 Gartner 说 13% 的 CIO 拿到了 AI 价值，RPA 厂商开始卖"不宕机"了 从脚本化 RPA 到 Agentic RPA：厂商开始卖“不宕机”了 2026 年 10 月，Appian 在 26.10 版本里把 Agentic RPA 做成了 GA，Release Notes 里既没有 Preview 也没有 Beta 的标记。往前推一年多，UiPath 的 Healing Agent 在 2025 年 5 月就已经 GA（正式发布）。 两家头部 RPA 厂商在一年之内先后把“运行时自愈”和“Agent 接管”做成正式产品，这个节奏放到过去十年的 RPA 行业里都算快的。 快，是被逼的。 Gartner 10 月的一份调研里，只有 13% 的 CIO 表示自己的企业从 AI 中拿到了显著或者转型性的价值。 EY 和 Forrester 更早的调研问的是另一件事，RPA 项目本身成不成，30% 到 50% 没有达到预期，超过一半连 10 个机器人都扩不出去。客户不是不满意，是已经疲了。 在王吉伟频道长期跟踪的这条赛道里，RPA 的脆弱性从来不算秘密。问题在于，厂商现在终于承认，继续卖“会罢工的机器人”，已经卖不动了。 机器人最常见的死法，是界面变了 RPA 机器人死得最多的一种方式，跟算法没关系，跟按钮有关系。一个按钮改了名字，一个对话框挪了位置，一个弹窗毫无预兆地冒出来，写死了 selector 的脚本当场卡在原地，然后傻等运维来救。 UiPath 自己的技术博客也承认，UI 变更是机器人失败的首要原因。 这个问题存在了将近 20 年，大家可能觉得是技术上解决不了，实际不是。之所以拖了这么久，得从传统 RPA 的收费结构说起。 它的收入分三层：开发许可、运行许可、维护服务。前两层是一次性的，第三层按年收，而维护服务恰恰是厂商收入里最稳的那一块。脚本越脆，客户越需要厂商的人来修，年度服务合同也就越值钱。 这倒不是说厂商故意卖脆弱的产品，没有哪家公司会把产品主动做差。是商业激励结构决定了，在“彻底消除脆弱性”和“持续提供修复服务”之间，后者更赚钱。 于是行业进入一个很诡异的均衡。客户为自动化付费，也为自动化失败之后的救火付费；厂商卖机器人，也卖机器人的维修费。这个均衡维持了很多年，一直很稳，大家也就习惯了。 客户还愿意一直为失败买单吗？两个变量同时变了之后，这个问题开始有了新答案。 第一，客户醒了。CIO 和 CEO 对“建了很多机器人但拿不到价值”已经厌倦，另一份 Gartner 调研里，44% 的 CEO 难以向利益相关方证明 AI 的财务回报。 第二，技术到了。大模型的 computer use 能力让“用自然语言驱动一个 Agent 在屏幕上干活”变得可行，厂商终于有了一条不靠写死 selector 的路。 把“技术做不到”这个因素排除掉之后，问题就落到了商业激励上。修脚本不再是唯一的解法，收费结构就必须跟着改。 Appian 的解法：把整段活交给 Agent Appian 在 26.10 里给出的东西，比“失败了让 Agent 救场”走得更远。 这个能力的正式名称是 RUN AGENTIC RPA。它是 RPA actions 面板里的一个独立 action，不是某个传统步骤的失败回调。 用法是，你用自然语言写一段描述目标的 prompt，选一个模型，这个 action 就会自己截屏、理解屏幕上的内容、决定下一步做什么，一直做到你描述的那个目标达成为止。 Appian 文档里的说法是，传统 RPA action 需要你把每一步都规划好、配置好，agentic automation 不需要，它会先抓取屏幕，理解自己看到的东西，再决定下一步最优的动作。 这意味着两件事，而这两件事经常被混成一件。 第一，它可以整段替代传统脚本。那些界面不稳定、步骤难以穷举的任务，比如操作一个老旧的 ERP 终端，或者处理一个经常改版的网页，你不再需要把每一步配置出来，写清楚目标就行。 第二，它也可以配合 Try-Catch 使用。把传统 action 放在 Try 里，失败之后在 Catch 里调用 RUN AGENTIC RPA 接管，让 Agent 绕过障碍，再交回脚本继续跑。 所以“失败接管”只是 Agentic RPA 的一种用法，不是它的全部。把 Appian 这个能力简化成“脚本崩了 Agent 来救”，会低估这个产品想干什么。它要做的不是给脚本打补丁，是用 Agent 替掉脚本本身