UiPath 账单自动化：10 万件/周，验收看方差

拉斯维加斯的一场厂商活动上，Coronis Health 的 CTO Doug Marcey 给了一个不太像宣传的数字：IDP 上线之后，一条医疗记录的处理时间平均只缩短了约 30 秒。按这个数字，这笔投资看着并不成立。他紧接着说的后半句才是重点：耗时的标准差大幅收紧，那些偶尔出现、比平均慢十倍的案件不见了。

这家公司每周处理约 10 万件医疗账单案件，其中麻醉业务线约 6 万份文档。把它的做法拆开，有三层东西可以搬走：按输入复杂度分层路由、用方差而不是均值做验收、以及一次与上云相反的成本决策。三层都指向同一个问题——单位成本的分母到底该怎么选。

一、它面对的真实约束：154 套 EMR，没有统一格式

先看规模。这家公司服务 700 家客户，对接 154 套 EMR 系统、25 套以上的 practice management 系统，每周处理约 10 万件案件；麻醉业务线每周约 6 万份文档，是难度最高、价值也最高的一条线。

再看约束。按 CTO 的说法，医疗账单里本该有 50% 到 75% 走直路，真正的难点在付款方而不在录入；与此同时，麻醉线有 14% 到 20% 的记录至今仍是手写，IDP 完全处理不了。

这两组数字合起来说明，这不是一个文档量大的故事，而是一个输入分布极宽的故事。154 套 EMR 意味着没有统一的数据结构，同一份病历在不同系统里的字段、编码和排版都可能不同。任何「一套模型打通全部」的方案，在这种分布面前都会撞上同一堵墙：模型能力够不够是次要问题，输入脏乱度的方差才是主要的。

二、四档路由：确定性路径优先，token 只在最难处打开

他们的做法是先用一个自研判别模型看单条记录，再按复杂度与脏乱度路由到四个档位。第一档是 Apple 内置 OCR 跑在 Mac Studio 硬件上，该公司自测约 30 页/秒（对照 Poppler 约 3 页/秒）；第二档是标准 IDP 加 Tesseract；第三档用开源 OCR 模型；第四档才把最难的记录交给商用视觉语言模型，跑在自有硬件上。整条链用 UiPath 的 IDP 与 Action Center 做人审纠错。

这套架构的机制值得单独说明。它的成本函数是分层的：前三档跑在固定成本的硬件上，按页计价、不消耗 token；只有第四档进入按量计费的计价方式。换句话说，把大部分记录挡在 token 计量之外，账单的斜率才会真正改变。只优化模型单价、不改变流量的分布，得到的是一条斜率不变的账单。

这也解释了为什么第四档要跑在自己的硬件上。一旦单位成本可预测，浮动计费就失去了它的主要卖点。反过来说，如果最难的那一档流量占比很高，分层路由的收益会被吃掉大半，这是这套做法适用的边界条件。

引用上要交代清楚：这些数字来自客户在厂商活动上的自述，diginomica 在报道中明确披露 UiPath 与 Oracle 是该媒体的 premier partner，并且承担了记者参加本次活动的差旅住宿。因此凡是「平台带来 X」的表述，都应读作受访者在赞助关系下的自述，不是第三方评测。30 页/秒与 3 页/秒是该公司自测，未披露测试条件，不能作为横向基准使用。

阈值不是越高越好，两个方向的错判都有代价。把一条本该走第一档的干净记录送进第四档，代价是单位成本上升、收益为零；把一条脏记录放进确定性路径，代价是错误字段进入下游，账单被付款方退回，返工工时比省下的那点处理时间贵得多。所以分档器要按两类错误分别定价，再定阈值——这比调模型参数重要得多。

这套做法适用的条件可以写清楚：输入分布宽、单量足够大、且其中有相当比例的处理不需要认知能力。医疗账单之外，保险理赔单据、供应链的报关与收货凭证、跨境贸易的随附文件都属于这一类。反过来，两种场景不适合照搬：一种是输入分布本身很窄的批量转换，直接走确定性路径即可，不需要四档；另一种是单量小、每份都极难的文件，分层省不下钱，直接用最强的模型反而更划算。

还有一处容易被忽略：人审不是兜底，而是架构的一部分。Action Center 在链条里承担纠错与低置信记录的处置，它的容量决定了系统在高峰期的实际吞吐。把人力当成异常时才叫的旁路，人就会变成新的瓶颈，这在单量按周波动明显的业务里尤其明显。

三、为什么「平均快 30 秒」是一种误读

平均耗时只回答了一个问题：平均每条快了多少。而排班、SLA 和对客报价吃的是另一件事：这个月要多排几个人。决定后者的不是均值，是分布。

这也是这篇案例里最容易读反的地方。如果只引平均 30 秒，结论会是「IDP 几乎没用」；把后半句补上——标准差显著收紧、极端慢案消失——结论翻转成「产能第一次可以被承诺」。两者必须成对出现，单独任何一半都会把案例读成广告或者读成反面教材。

可迁移的方法论只有一句：流程自动化的验收指标要成对写，平均加标准差，或者在合同里直接写 P95。这项改动成本极低，但它决定了项目第二年能不能拿到预算——因为业务方需要的是一个可以排班的数字，而不是一个更好看的平均值。

边界：这是一个单案例，指标由公司自述；它不覆盖那些价值主要体现在人力减少的自动化场景，那类场景的验收语言本来就不同。

四、「AI 把我们拽回了自建机房」

为了绕开按 token 计费的浮动成本，这家公司做了一次与行业叙事相反的决定：从全云迁回 colocation，自己买硬件，把单位成本变成固定成本。CTO 的原话是，AI 把他们拽回了 colocation。

用第一性原理看，这不是「云贵还是自建便宜」的问题，而是波动由谁承担的问题。按 token 计费把流量的波动风险留在买方：用得越多付得越多，而且单价不由自己决定。自购硬件把风险换到另一边：闲置也是成本，需求超出预期时扩容也更慢。

哪种更优，取决于负载的可预测性。每周 10 万件、分布已知的稳定负载，天生适合固定成本，因为它的波动可以被提前规划。反过来，量小、增长快、波动无法预测的负载，固定成本会变成沉没成本。所以这条一手证据的意义不在「自建更省」，而在推翻「AI 天然更省」这个默认假设。它同时提示一件采购层面的漏洞：谁承担波动，这个条款在很多合同里根本没有被写出来。

对这一条，采购层面有一个直接可落地的改法：在合同里把两类口径分开写，用量口径（调用次数、页数、token）与结果口径（闭合的案件、处理完的文档）分别报价，并要求供应商标出哪个数字会随流量浮动。多数 AI 合同只写了一个单价，波动风险就以默认方式落在买方身上，而默认条款从来不是谈出来的。

五、被低估的一条收益：154 套系统之间的劳动力流动

整合层上线之前，员工被绑定在特定的 EMR 系统上，无法跨团队调度。通用的适配层上线之后，劳动力可以跨系统流动，CTO 称这是平台带来的最大运营收益。

这条收益值得单独记一笔，因为它不体现在自动化项目常见的验收口径里。按省下多少工时来算，劳动力流动一分都不算；但组织在异构系统上被锁死的人力，本身就是一项隐性成本：一个团队排队，另一个团队空闲，你却没办法把人挪过去。

这也解释了为什么先做适配层比先堆 agent 数量更划算。系统之间没有统一连接时，每加一个 agent 都要多维护一套连接，越加越僵；适配层到位之后，新增自动化只是往同一个池子里添一个执行者。

边界同样要标出：这是 CTO 自己的排序，不是我们的测算，我们也没有这家公司在调度效率上的量化数据。

顺着这条收益往下推，度量的颗粒度也要跟着变。按系统统计只告诉你哪套 EMR 慢；按队列统计才告诉你瓶颈卡在哪一步；按人统计则能看出谁在同一条队列上反复处置同一类异常。三层里第三层最难取数，但只有它能回答这段流程值不值得改——同一类异常反复出现，通常意味着字段定义或规则本身有问题，而不是执行者不够快。

六、我们的判断

第一，单位成本的分母要选对。按 token 记账会奖励「少用模型」，按闭合的案件记账才会促使你去做路由。前者是省钱，后者是产能，两者在预算表上看起来一样，实际走向完全不同。

第二，验收指标必须包含方差。只有均值改善的项目，业务方仍然做不出产能预测，最后会用「感觉不稳定」把它否掉。均值加标准差才是可以承诺的语言。

第三，先做适配层，再谈 agent 数量。在异构系统上并行铺开多个 agent，会让每个 agent 各自维护一套连接，调度弹性反而下降；把它们收在同一个适配层后面，新增自动化才是增量的。

第四，固定成本与浮动成本的取舍是架构决策，不是财务细节。负载可预测且规模足够时，自购硬件能把单位成本压平；负载不可预测时，它会变成沉没成本。这条判断不需要产品支撑，只需要你先回答一个问题：未来一年的负载分布，你能提前画出来吗。

一个具体用法是：同一个队列，连续四周的平均处理时长与标准差同时下降或持平，才算稳定；只有均值下降而标准差没动，通常说明自动化只吃掉了容易的那部分输入，剩下那一半还是老样子。

七、边界与不确定性

• 案例中的全部数字来自 Coronis Health 的 CTO 在 UiPath Fusion 2026 上的自述，经 diginomica 报道；报道方已披露其与 UiPath 的赞助关系。
• 30 页/秒与 3 页/秒为该公司自测，测试条件未披露，不能作为 OCR 基准。
• 本文不含任何美元口径的回报数字，因此不能替代该公司的财务数据。
• 单案例不足以外推为行业基准，分层档位与阈值都需要按自己的输入分布重新标定。
• 劳动力流动的收益排序来自受访者自述，我们没有独立量化。

八、三步可复制的做法

一，列出你的确定性路径清单。哪些步骤不需要认知能力，例如格式转换、字段抽取、规则校验，把它们钉在固定成本的硬件上，不要送进按量计费的模型。

二，定义「最难的那一档」的判据。先跑一个判别器给输入分档，只让高复杂度分档进入按 token 计费的路径。判据要写成可以量化复现的规则，而不是凭经验目测。

三，验收指标成对写：平均值加标准差，或者直接写 P95，并写进试点合同。这条几乎不花钱，但它决定你明年能不能拿出一个可排班的数字。

这三步的共同点是把「省了多少」换成「每条闭合的记录花了多少、波动多大」。前者是感受，后者是可以进预算流程的量。

最后一句关于标定的顺序：先跑一段只观测、不分档的取样期，拿到自己的输入分布与两类错误的价格，再去定阈值和档位。直接照抄别人案例里的四档结构，你会得到一个形状相似、参数全错的系统。

参考来源：diginomica《Accountable intelligence: how a UiPath customer is using agentic automation to process 100,000 medical cases a week》（2026-09-25，记者 Mark Chillingworth 在 UiPath Fusion 2026 现场对 Coronis Health CTO Doug Marcey 的采访；文末披露该媒体与 UiPath 的 premier partner 赞助关系）diginomica.com/accountable-intelligence-how-uipath-customer-using-agentic-automation-process-100000-medical