告别工单：预构建解决方案能做而静态软件做不到的事

UiPath 接触的几乎每一家企业，都面临同一个难题：明明知道某个流程需要改变，却难以真正落地执行。支付方更新了医疗政策，或者监管机构修订了筛查阈值，负责该流程的人员往往在一天内就清楚该改什么。然后他们提交工单。变更可能在三周或三个季度后才落地；如果应用管理员团队无法完成，它就会进入供应商的路线图，最终石沉大海。

这一痛点在上个月 UiPath FUSION 大会的几乎每一场客户会议中都反复出现。客户很少追问智能体或模型本身，而是更关心：谁来决定适用哪个版本的政策？异常规则存放在哪里？系统如何从这些异常中学习？这些并不是 AI 问题，而是关于软件能否跟上不断演进的业务这一务实问题。

解决方案与可购买软件有何不同？

预构建 ≠ 模板，而是完整的工作地图

以一家制造企业为例。有些流程是企业独有的：涉及多个团队、十几个系统，异常分支依赖有争议的覆盖范围，还需要外人难以识别的判断决策。没有供应商能预先打包这样的流程，因此流程地图必须与企业共同绘制。而企业的采购到付款（source-to-pay）流程则不同——制造商通常遵循相同的购买与支付步骤，尽管每家公司都有自己的政策和规则。正因为流程是标准化的，其地图的大部分可以预先构建。

后一种情况正是 UiPath 解决方案（UiPath Solution）的定位，它并非模板或入门套件。完整的工作地图（Map of Work）已经预先绘制完成，并包含三层：

01 结构化知识

流程的本体、规则与政策、异常分类体系。

02 运营知识

先例、实操案例以及资深人员所掌握的判断经验。这部分知识通常会随人员离职而流失。

03 决策账本（Decision Ledger）

已在 FUSION 上预览，将在工作运行过程中记录每项决策背后的推理。

在工作地图之上，还随附运行该工作所需的组件。相关组件均由 UiPath 预构建、维护并持续改进，不设独立构建阶段，定价与成果挂钩，而非按投入计费。

为什么 SaaS 无法跟上节奏

静态应用等待操作，动态系统持续进化

静态应用配置一次后便等待用户操作。基于工作地图构建的解决方案则不同，需要四项要素协同运作：

业务本体

为每个智能体、机器人和人员提供一致的企业业务对象描述及其关联关系。

UiPath 策略引擎（Policy Engine）

将书面政策转化为结构化、版本化的规则：模型读取企业政策，策略引擎作出判定。

UiPath Maestro

负责端到端编排工作，并在数天或数周内保持案例状态。

决策账本

在运行过程中记录每项决策和每次纠正背后的推理。

策略引擎是整套体系运转的关键。它会显示哪些标准已通过、未通过或需要补充材料。相同政策版本下的同类案例会得到一致结果，且判定可在作出当日解释，而非事后重建。成本保持可预测，因为企业不必为每笔交易支付模型推理费用。

这一闭环的设计目标如下：账本天然会保留完整记录，包括每项决策、每次覆盖以及运行中随口给出的每条反馈。智能体会持续读取这些历史并提出改进建议，每项建议都会先在测试数据上评估，然后才呈现给人员。业务团队收到的是附带证据的建议，可接受或拒绝。整个过程不需要提交工单，也不需要等待管理员。

这些改进并不都属于同一类型：有些把非正式知识——即经验丰富的人员处理复杂异常时所运用的判断——转化为任何人都能查看的结构化规则；有些优化智能体的指令；还有些改变流程本身的形态，绕过只有在工作实际运行后才显现的瓶颈。这些改进都在流程运行过程中完成，而不是在发布窗口内完成。这才是动态系统与静态系统的真正区别：区别不在于系统可配置，而在于系统会在生产环境中持续自我评估，并把需要决策的事项交给流程负责人，而不是让他们排队等待。

一个合理的质疑

如果工单机制消失，什么来取代它？工单虽然缓慢，但也是一种控制手段；不能从受监管的工作中移除控制机制，然后寄希望于结果不出问题。因此，控制能力被内置到系统中：每次变更都经过责任人审批；涉及政策的任何事项可要求第二位审核人；权限按规则的重要程度分级。每个版本都会保留，当审计人员要求解释八个月前的决策时，企业可以提供依据。

这也回应了交易后期才会有人提出的异议：预构建产品不可能真正属于企业。每家公司的审批层级都具有相同结构——分级、升级、授权——真正属于企业的，是其中的数值和背后的判断。因此，企业可以设定自己的层级，导入政策文档并生成规则，并决定机器决策的边界；随着信心提升，这一边界可以调整。配置可在一下午完成，而不是投入一个季度编写代码。共通部分已预先构建，属于企业的部分仍然属于企业。

构建已变得容易，信任才是关键

从”能不能建”到”十八个月后谁维护”

今年 4 月，UiPath 曾撰文讨论何时自建智能体解决方案、何时购买。此后，这一论证中的一个部分发生了变化：UiPath for Coding Agents 已于上个月正式可用。企业团队现在可以快速搭建一个读取索赔并起草申诉的智能体。构建智能体不再是难点，更难的问题是如何在生产环境中运行它，并在工作变化时保持其可信。

如今，重点需要放在信任上。生产系统的信任取决于七个因素：

智能体

自动化

集成

人员使用的应用

治理

评估

学习

企业团队可以构建前五项，但需要时间。在受监管的工作中，不能止步于 80%，而将水平提升到 80% 以上的成本会以不可持续的方式累积。话虽如此，只要有足够时间和投入，这些能力都具备构建可行性，工具也在不断进步。然而，后两项不同，因为它们是先例积累的结果，而非单纯投入的产物。

评估与学习的质量取决于其背后的数据。在自建系统中，企业的样本从空白开始；而 UiPath 的样本经过跨部署调优，并会随着每次运行持续改进。这是一个已经运转一段时间的飞轮，并会在 UiPath 部署时再次转动。另一个问题是信任会衰减：每次系统变更、每次政策修订和每个新模型都会重置部分信任。因此，问题不在于企业团队能否构建这些能力，而在于十八个月后由谁保持其可信。

生产环境中的实证

以下部署展示了 UiPath 客户在生产环境中取得的结果

-76%

医疗健康：一家美国收入周期管理服务商降低的拒赔索赔单位成本

97h → <5h

金融服务：一家拉美零售银行缩短的争议解决时间

10% → 80-90%

制造业：一家全球性家电制造商提升的发票自动化率

91%

财务与会计：一家全球性消费品制造商的采购到付款智能体成功率

接下来会发生什么

每张地图都是一个等待构建的解决方案

这些结果指向一个机会：将更多此类工作纳入预构建解决方案。当同一流程在多家公司反复出现，且步骤相同、所需判断同样来之不易时，它就具备成为完整解决方案的条件。在 FUSION 上，一家银行提出愿意成为 UiPath 尚未构建的某一解决方案的早期客户：与 UiPath 共同构建，然后将其通用化。每张地图都是一个等待构建的解决方案，而每张地图下的账本将帮助 UiPath 判断下一步应构建哪一个。

这也改变了主导权的归属。索赔总监、利用管理护士和应付账款经理不再针对他人的软件提交工单，而是开始设定其流程运行所依据的规则。这一点在 FUSION 上反复被提及，并将在静态 SaaS 塑造业务流程的场景中持续出现。

1.本内容作为作者独立观点，不代表RPA学习天地立场，RPA学习天地仅提供信息存储空间服务。

2.如果对本稿件有异议或投诉，请联系客服微信号。