从 RPA 到 Agentic Automation：UiPath 2026 路线图与企业采购的四笔账

UiPath 2027 财年二季度财报里有一组不太协调的数字。这一季度营收 4.103 亿美元，同比增长 13%；同一份披露给出的下一季度指引是 4.40 到 4.45 亿美元，隐含同比增速掉到 8% 上下（数据来源为 UiPath 公开季报与业绩沟通材料，具体以公司官方披露为准）。

管理层说的是执行纪律和平台动能，资本市场的反应是先涨后跌。这两件事对做采购的人来说都不重要。真正重要的是另一件：这份财报把一件事摆到了台面上，这家供应商的增长来源正在换轨，从"新客户首单"转向"存量客户加钱包"。

下面把这件事拆开讲。不做投资分析，只把它当成判断供应商可持续性和路线图可信度的输入。如果你手上管着 UiPath 的预算、续约或者一个正在 PoC 的 agentic 项目，这篇是按你的视角写的。

一、财报里的两组数字，其实在讲同一件事

先看这一季度的关键数据：

指标（截至 2026 年 7 月 31 日）	数值	同比
季度营收	4.103 亿美元	+13%
年度经常性收入（ARR）	19.38 亿美元	+12%
净新增 ARR	3,700 万美元	—
美元口径净留存率	109%	上年同期 108%
GAAP 经营利润	3,200 万美元	上年同期亏损 2,000 万美元
现金、受限资金与有价证券	14.05 亿美元	—
三季度营收指引	4.40–4.45 亿美元	约 +8%

再看客户分层：ARR 超过 100 万美元的客户 374 家，同比增加 18%；超过 10 万美元的客户 2,624 家，同比增加 11%（口径见公司季报，各季度披露项目可能调整）。

把两组数字放在一起读，画面很清楚：大额客户扩容的速度，明显快于整体 ARR 增速，也快于中小客户层级。109% 的净留存说明存量客户的总和还在上升，但这个上升里有相当一部分来自同一批大客户的扩张。

这对买家意味着两条相反的结论。已经是 UiPath 大客户的企业，明后两年的商务谈判里，涨价和扩容套餐的压力会比过去几年更明显，厂商的销售动作会集中在"你们还能再上多少 agents"这件事上。反过来，处在首单谈判阶段的企业，现在是有空间的阶段：厂商需要新增logo，价格和保护条款更容易谈。

还有一层不那么好量化但绕不开的东西：本季度公司同时宣布了几项管理层调整，首席财务官、首席法务兼行政官换人，董事会新进一位成员。一次两次调整说明不了什么，密集调整出现在增速换挡的季度里，值得在尽责调查清单上占一行。

二、阻挡 RPA 规模化的从来不是"能不能做"

要理解 UiPath 为什么急着往 agentic automation 转，得先看老问题出在哪。

不少第三方测算把 RPA 项目全生命周期里的维护投入估到总投入的四到五成，口径各有出入，不同机构的统计方式差异很大。这个量级其实和很多甲方团队的体感对得上：机器人做出来了，然后每隔几个月就要回去改一次。

原因不复杂。流程本身没变，界面变了。一个字段换了个位置，一次门户改版，一个新证书，都能让脚本停在那儿不动。这类失效不会触发告警，也不会报错到你手机上，它安静地排空队列，第二天早上业务部门才发现单子没人处理。

我们在《UiPath 自动化工程化实战》那篇里拆过具体的技术细节：选择器怎么做才抗震、REFramework 的四状态机怎么用、业务异常和系统异常怎么分流。那篇解决的是"把维护量从 50% 压到 20%"这类问题。这一篇要解决的是另一个层面的问题：当厂商把产品重心从机器人移到 agent 上，你的采购和预算逻辑要跟着改什么。

顺手说一下 Maintenance 这个词的错觉。很多人以为维护就是改选择器，实际账单上更大的是三块：业务系统变更后的一次性返工、季度性的合规与权限复核、以及为了维持那些"还能跑但没人敢动"的流程付出的隐性人力。第三部分几乎不出现在任何预算表里，它躲在业务部门的加班时间里。

三、2026 年 UiPath 在改的三件事

把 2026 年的公开动作摊开看，主线其实只有三条，产品名变了几次，方向没怎么晃：

时间	动作	对企业买家的影响
2026 年 1 月	Agent Builder 的可视化编排画布正式可用：属性、工具、护栏、评测都能在画布里定义	agent 的构建不再必须依赖 Studio 的开发者传统路径
2026 年 2 月	收购 WorkFusion，获得反洗钱、客户身份识别、欺诈调查等垂直场景 agent	金融合规类场景可能不必从零自建，但要看具体可用范围与授权方式
2026 年 3 月	统一 Python 运行时，低代码 agent 与代码化 agent 共用同一套运行环境	自建 script 与平台原生流程的边界变模糊，运维规范要重写
2026 年 5 月	UiPath for Coding Agents，把外部的编码 agent 纳入统一的测试、部署与生命周期治理	已经买了 Cursor、Copilot 之类工具的团队，多了一层治理选择
2026 年 8 月	Automation Cloud 推出面向统一计费的社区版方案，向个人开发者开放一定额度的零成本使用，具体范围与额度以官方方案为准	个人与小团队的入门门槛降低；企业级采购要注意零成本版与企业版之间的能力边界
2026 年 9 月	Maestro 拆成两条产品线：Orchestrate 面向跨团队长周期流程，Automate 正式可用，面向短时间高并行的 agent 与 API 工作流	选型之前要先问清楚：这条流程属于哪一类，对应的产品线和授权怎么算

时间表里有几条需要注意的细节。

编排层被重新切开

9 月这次更新把 Maestro 拆成了两个产品，这件事对落地的影响比看上去大。过去的 Maestro 是一个统一的编排层，什么流程都往里堆；拆开之后，Orchestrate 管的是跨团队、长周期、需要人工审批和会签流转的过程，Automate 管的是短平快、可以成批并行跑的 agent 和 API 工作流。

同一批更新里还带来可复用的 BPMN 模块，人工审核、审批链、故障处理这些反复出现的结构可以沉淀成模板。对已经跑了大量流程的企业来说，这是个值得去看的东西，它有可能把"每做一个新流程就把审批重新搭一遍"的成本降下来。

不要指望升级自动生效。标准 RPA 流程的环境变量和密钥资产引用需要 Robot 25.10 及以上版本，凭据存储限定文件夹的功能同样对版本有要求。升级排期要先和这两个功能对 Robot 版本的要求对齐。

agent 从"附加功能"变成了主体

Agent Builder 这一年的变化，是从一个边上的实验台变成了主体工位：1 月的可视化画布让属性、工具、护栏、评测都能在界面上定下来；3 月的统一运行时让代码化 agent 和低代码 agent 跑在同一套环境里。再到 9 月，出现了 Cartographer 与工作地图这类从文档、系统和人当中抽取"实际怎么干活"的东西，配一本还在预览阶段的决策账本，记录谁在什么证据下做了什么决定。

后一条对大型组织意义更大。多数企业说不清自己某个流程到底怎么跑，只记得文档里写的版本。Cartographer 这类能力能不能真的把"实际版本"抽出来，要看它在你的系统和分析师身上的表现，不要相信任何 demo。

治理开始往后退一步站

UiPath for Coding Agents 是个不太起眼但很说明方向的产品：它默认你的团队已经在用别人的编码 agent，它要做的是给那些生成出来的东西加上企业级的治理、安全和生命周期管理，而不是要求你只用它的东西。

管理层在业绩沟通里举过几个客户例子，比如某电子企业把一个四周的工作压到三小时，某芯片厂商把两个月的工作压到几天。这类个案听听就好，样本选择也好、实施条件也好都不具备可比性。可以拿走的信息是：这个方向要压缩的是交付周期，而不是把工程师换掉。

四、真正影响预算的是计价口径，不是技术名词

这一段值得采购同事细读。

机器人时代的计价逻辑很朴素：一个机器人一份授权，跑不完就加机器人。看得见，也算得出来。agent 时代这套逻辑失效了，因为 agent 消耗的是模型推理、工具调用和运行时长，这些东西按次计费更自然。于是 AI Unit、统一计费这些口径就出现了，然后在 2026 年被推进得很快。

对企业来说风险不在"贵不贵"，而在"边界含糊"。按量计费的合同里，真正会让人吃亏的从来不是单价，是结算口径：哪些动作算一次消耗，失败的调用计不计，人工介入的那几次算不算，超了这一档之后是暂停还是先跑后结算。这些条款不写清楚，明年的预算表就没法做。

条款	建议写进合同的内容
单元单价与锁定期	明确 AI Unit（或对应计量单位）的单价，锁定至少一个续约周期；写明产品改版或计量口径调整时不追溯历史用量
计费边界	写清失败调用、重试、人工复核环节、评测与调试阶段的用量是否计费
超量处理	约定阈值、超量后的阶梯单价，以及是先预警还是先停机
退出与迁移	约定到期后流程资产、配置项与日志的导出格式和协助义务，避免被锁在只能整体续费的局面里

还有一条经常被漏掉：扩容采购的时候，用什么东西向内部立项。传统 RPA 立项容易，"替代 2 个 FTE"这种话管理层听得懂。agent 项目不好算：它不一定省人，它提升的是处理速度和覆盖的场景宽度。所以 PoC 立项阶段就要把度量方案定好，别等到验收时临时找数字。

五、中国企业要多问的三个问题

同一套产品，在不同监管和数据环境下能用起来的部分不一样。下面这三条，建议直接接触前就准备成书面问题清单。

1. 私有化部署的能力边界

Automation Suite 支持自托管部署，也有自托管模型的能力，数据不出内网这条底线是可以守住的。但要注意：公有云版本往往是新能力的首发地，自托管版本的功能点通常会滞后一段时间。厂商 agent 相关的新能力尤其如此。

问法要具体：这一版本的自托管环境支持哪些 agent 能力，模型层可以接什么，上下文数据在哪里处理，日志回传到哪里。答案要求书面给，并且附版本号和发布时间，不要接受口头的"后续会支持"。

2. 中文单据的处理能力，只能用自己的样本测

IXP 这类文档理解产品在缺乏行业训练集的时候，表现取决于你的版式。中文场景的特殊性比多数人想的麻烦：印章覆盖关键字段、多层套打的发票、手写批注混排、单张纸跨页承载多个订单号，这些都是常见的坑。

PoC 要用自己的样本，建议带上过去半年里最容易出错的那批单据。验收指标别用"整体准确率"这种含糊口径，用字段级召回和字符准确率，并且按单据类型分开统计。厂商 demo 集上的数字不具备参考意义。

3. agent 每一步都要能追溯

确定性流程好处是每一步都有日志，审计看得懂。加了 agent 之后多了一层不确定性：同一个输入两次跑的路径可能不一样。所以审计方案要先准备好。

需要覆盖的东西：AI Trust Layer 的启用范围、PII 脱敏在什么环节生效、模型是否可以由客户自管理、以及最关键的一条：agent 每一次调用、每一次工具使用、每一次人工接管，能不能串成一条链并在事后回放。这条链如果缺环，合规评审那一关会卡很久。

六、ROI 这笔账要换个算法

最后是把度量的事讲清楚。传统 RPA 的 ROI 模型和 agent 时代的模型差别很大，继续用旧账算新东西，会得出完全错的结论。

维度	旧算法（机器人时代）	新算法（agent 时代）
核心指标	替代了多少工时、收回几个 FTE	闭环率：多少工单从进入到结案没有被人工接管
质量指标	脚本报错次数	首过率与人工复核率
成本单位	每机器人年授权 + 运维人力	单笔处理成本（含模型调用与工具调用）
失效代价	队列堆积、单据积压	错误被当成了成功，进入下游环节
观测对象	Job 是否跑完	每一步调用是否可回放、可归因

最后一行那个"错误被当成成功"要单独说。机器人出错会卡住，人能看到。agent 出错可能输出一个形式上完整的处理结果，然后往前走，等到有人在下游发现异常，已经过了一大圈。所以评估体系里必须有一个抽检环节，用人工抽样去兜底。

这四个指标里，我建议把闭环率当作主指标。它同时反映了能力边界和治理水平：率低要么说明场景选错了，要么说明护栏设得太松或者太紧。单笔处理成本放在第二位，因为它决定了这个方案能不能规模推广。

七、十二个月里可以做的六件事

1. 把现有流程分两类。一类是规则稳定、量大、要审计的，留在确定性流程（传统 RPA）上；一类是非结构化输入、需要判断的，放到 agent 侧试点。这两类的投资逻辑不同。
2. 把维护成本算明白。把过去 12 个月里花在"改机器人"上的人力折算出来，这是和厂商谈折扣、谈弹性席位时最有说服力的材料。
3. 先给 PoC 定验收口径。不要从"能不能做"开始，从"用什么指标验收"开始。先把度量方式定下来，再动手。
4. 合同条款提前介入。单价锁定、计费边界、超量处理、退出迁移，这四条在首次采购就要谈，别等到首年的用量账单出来再补。
5. 自托管能力清单早点要。要求厂商以书面形式给出当前版本自托管环境支持的能力清单，并写进技术要求附件。
6. 找个下游业务方做验收人。IT 部门自己验收项目，很容易把"上线了"当成"成功了"。真正能判断价值的是业务部门的人。

八、三个反复出现的误区

误区一：把策略调整当成产品升级。这轮变化的核心是商业模式和产品架构同时变，不只是功能变多。只盯着新功能清单的人，会在续约的时候被打个措手不及。

误区二：以为 agent 能让 RPA 的维护消失。不能。它降低的是"小改动引发的救火"，替代不了工程规范和版本管理。选择器该做规范还是要做，异常该分流还是要分流。

误区三：把厂商的 case study 当基线。"四周变三小时"这类故事有特定的实施条件。做预算的时候，按自己团队的实际能力和现有系统复杂度推，不要按 demo。

结语

UiPath 这一年做的事，本质上是把自家的生意从"卖机器人"往"卖 orchestration 与治理"上迁。财报上的增速换挡是这个过程的一部分反映，不是结局。

对企业买家来说，这段时间反而宜操作：厂商需要证明新平台的商业价值，新客户的条件相对好谈，同时对存量客户的服务投入通常不会下降。把合同、计价口径和验收指标在这段时间里谈清楚，比在产品成熟之后再谈要主动得多。

最后提醒一句：文中引用的财务数据、产品时间表与客户案例均来自 UiPath 公开披露与第三方报道，版本、计价与功能范围变化较快，实际决策请以厂商官方文档、合同条款与自有环境的测试结果为准。