同一个需求，两个方案，差别不在技术栈

「帮我们把每天收到的订单邮件自动录进系统」——这句话放在三年前，答案基本是 RPA；放在今天，很多人第一反应是上 AI 智能体。两个方案都能跑通演示，报价能差三倍，上线半年后的状态却可能完全反过来：便宜的方案天天要人盯着修，贵的方案因为调用成本太高被限制使用次数。

差别不在用了什么技术，而在对「意外」的处理方式。RPA 的思路是：把人的操作路径录下来，遇到不符合预期的界面就报错等人。智能体的思路是：给它目标和工具，让它自己判断下一步，遇到不确定就猜一个最可能的答案。前者怕变化，后者怕不确定。而企业流程的真实情况是，既会变，也不确定——所以这个选择从来不是二选一，而是分层。

先把三个概念摆清楚，后面所有判断都建立在这上面。脚本是最基础的一层：按固定规则处理结构化数据，接口稳定就一直跑。RPA 是中间层：在没有接口的老系统上模拟人点击录入，靠界面吃饭，界面一改就坏。智能体是上面一层：能读非结构化内容、能做多步判断、能调用多个工具，但输出有随机性，且每次调用都有成本。

三层自动化：能力边界在哪

选型的第一步不是看厂商演示，而是把自己的流程拆开，看它落在哪一层的能力范围里。下面这张表是判断的基本盘，多数争议都能在这里找到答案。

这张表里最值得注意的一行是单次成本。RPA 的许可费用是固定的，跑一次和跑一万次成本差不多；智能体是按调用量计费的，跑一万次的费用可能是跑一次的几千倍。所以高频批量的活，用智能体在经济上就不成立。反过来，一天只有二十封的复杂邮件，用 RPA 去做解析，开发成本高得离谱，还没法处理格式变化。

再补一句容易被忽略的判断：如果一个流程规则完全可枚举、接口也齐全，那么最优解往往既不是 RPA 也不是智能体，而是最朴素的脚本或系统对接。这句话在项目会上不好说，但它是真话——用贵的方案替代已经稳定的便宜方案，是这两年最常见的浪费。

五个问题，定位该用哪一层

与其争论技术路线，不如按顺序回答五个问题。回答完，方案基本就定了。

第 4 问和第 5 问是最容易跳过、也最容易出事的。处理量决定成本能不能扛住，复核机制决定错误会不会流到下游。很多项目在演示阶段效果惊艳，上线后没人敢用，就是因为这两问没有答案：错误一旦进了财务系统，清理成本远高于人工重做一遍。

还有一个实操建议：把流程按「频次 × 复杂度」画一张四象限图。高频低复杂度放左下，交给脚本；高频高复杂度放左上，用混合编排；低频低复杂度放右下，人工做最划算；低频高复杂度放右上，是智能体最舒服的位置。这张图画出来，往往能发现三分之一的流程根本不该自动化。

为什么七成项目最后是混合编排

真实项目里，纯 RPA 和纯智能体都少。多数稳定跑起来的是混合编排：智能体负责「读懂和判断」，RPA 或接口负责「稳定执行」，规则引擎负责「校验」，人工负责「兜底」。这四段的分工，比选哪家厂商重要得多。

混合编排的关键设计是「置信度门槛」。智能体抽取每个字段时都要给一个置信度，高于高阈值直接过，低于低阈值直接转人工，中间区间走二次校验（比如金额与订单号做交叉验证）。这个门槛不是拍脑袋定的，要用历史数据跑出来：取 300 份真实样本，看不同阈值下的人工干预率和错误率，选一个人工干预率可接受、错误率足够低的点。

另一个关键设计是「幂等」。自动流程最怕重跑：消息重投、任务重试、人工补跑，都可能导致同一张单建两次。解决办法是给每笔业务一个唯一键，写入前先查，查不到才写。这条规则听着简单，但它是自动流程能不能长期无人值守的分水岭。

成本结构：一次性投入与长期维护

报价单上的数字通常只包含开发，而真正决定总成本的是维护。把两类成本摊开看，选型会理性很多。

很多企业比价时只比第一年的开发费，结果第三年发现维护费超过开发费。合理的做法是让供应商按三年总成本报价，把许可、调用量预估、维护响应、异常处理人力都列进去。同一份需求，三年总成本算下来排名经常和首年报价排名不一样。

还有一项隐性成本值得单独提：流程知识的所有权。自动化流程里沉淀了大量业务规则，如果这些规则只存在于某个厂商的机器人脚本里，企业换供应商时等于从零开始。签约时应该约定交付物包含流程说明文档、规则清单和可运行的配置，而不是只交一个打包好的机器人。

五种常见误判与后果

误判一：用智能体替代已经稳定的脚本。动机通常是「想用 AI」，后果是成本涨五到十倍，稳定性反而下降。已经有接口、规则清楚的活，交给脚本跑三年不出问题，没有必要换。

误判二：用 RPA 硬啃扫描件和非结构化文本。RPA 本质是模拟点击，对图像内容无能为力。硬做的话，只能靠外挂识别工具，识别率一低，异常就堆成山。这类输入应该由智能体处理，RPA 只负责写入。

误判三：忽略异常队列。一个流程跑通 80% 不难，难的是剩下 20%。异常如果没有队列、没有责任人、没有超时提醒，就会静默堆积，直到某天业务发现「这个月的单少了两百张」。异常队列必须和主流程一起上线。

误判四：没有权限与审计。自动化程序往往用一个「超级账号」登录所有系统，一旦泄露或被误用，影响面极大。正确做法是给自动化单独建账号，按最小权限授权，所有写操作留审计日志，关键动作（如付款、删单）设人工确认。

误判五：只做演示不做运维。演示环境网络稳定、数据干净、界面没变。生产环境有超时、有锁表、有并发冲突。定时任务失败没人知道，是自动化项目最常见的死法。上线时必须配监控：任务是否按时启动、成功率、积压量，异常自动通知到责任人。

这五条都不是技术难题，而是工程纪律。安徽好牛软件有限公司在合肥做企业流程自动化项目时，通常会在方案阶段就把「哪些交给脚本、哪些交给 RPA、哪些交给智能体」写成一页纸，让业务方签字确认——因为选型争议一旦延到开发阶段，改起来就是成倍的成本。

常见问题解答

Q1：我们已经在用 RPA 了，还需要上智能体吗？

看现有 RPA 卡在哪里。如果机器人本身跑得稳，只是上游的输入需要人工整理（比如把邮件里的订单手工录成 Excel 再喂给机器人），那么加一个智能体做抽取和分流，投入产出比很高。如果 RPA 已经覆盖了主要流程且运行良好，没有必要为了「用上 AI」而重构。

Q2：智能体的准确率一般能做到多少？

取决于任务类型。字段抽取类（单号、金额、日期）在清晰文本上通常能到 95% 以上，扫描件会降到 85% 到 90%；分类判断类（订单类型、紧急程度）在标注清楚的前提下能到 90% 左右。但更该关注的是「错了会怎样」：如果错了能靠校验拦住，90% 就够用；如果错了直接进财务系统，那就要做到 99% 以上，而这通常需要人工复核兜底。

Q3：调用成本会不会失控？

会，如果没有限额。务实做法有三条：一是设日调用上限，超限转人工；二是做缓存，相同输入不重复调用；三是把简单任务降级到规则或小模型，只有复杂个案才走大模型。按经验，这样能把成本压到全量调用的一半以下。

Q4：老系统没有接口，只能用 RPA 吗？

短期是，长期不一定。如果老系统有数据库访问权限，直接读库往往比模拟界面稳定得多（只读不写，写操作仍需谨慎）。如果有厂商支持，推动对方开一个最小接口，一次性成本可能低于三年 RPA 维护费。RPA 是过渡方案，不该是终局方案。

Q5：怎么验收一个自动化项目？

别用「跑通了」当验收标准。建议定四个指标：无人值守运行天数、异常率（异常笔数 ÷ 总笔数）、平均处理时长、人工干预率。再加一条硬要求：交付流程说明文档和规则清单。指标达标、文档齐全，才算交付完成。

自动化这件事，技术从来不是瓶颈，判断才是。把流程拆对、把层次分清、把异常和成本算进去，剩下的就是工程实现。安徽好牛软件有限公司在合肥承接这类项目时，最常做的工作不是写代码，而是帮企业把「这个活到底该不该自动、该由哪一层来干」这个问题回答清楚。

更多资料可访问官网：www.niuniuchuantu.com