DAE 和 RPA 该怎么选？
路径固定、界面多年不变的高频搬运，用 RPA 更经济；输入形态会变、需要先判断再动手的工作，用 DAE 更合适。两者不是替代关系，关键动作都由人工确认后生效。
本文为选型判断说明，不构成对现有系统的替换建议；具体方案取决于企业流程与系统条件。
30 秒看懂
DAE 与 RPA 的区别在哪六个维度？
两者都能操作系统完成动作，差别在「靠什么知道该做什么」。
| 对比维度 | RPA | DAE 数智员工 |
|---|---|---|
| 设计前提 | 界面与流程固定不变 | 信息形态与处理路径会变化 |
| 输入 | 结构化字段、确定位置的元素 | 消息、图片、表格、单据等非结构化信息 |
| 判断依据 | 人工预先写死的脚本 | 企业定义的规则，业务人员可查看可修改 |
| 遇到没见过的输入 | 报错停下，等人工改脚本 | 按规则判断，不确定时转人工 |
| 界面或流程改版后 | 需要重新录制或改写脚本 | 不依赖界面位置，通常不受影响 |
| 适合的任务 | 高频、路径完全固定的数据搬运 | 有规则但输入形态多样的执行工作 |
第三行是分界线。RPA 的判断藏在脚本里，改一次要动代码；DAE 的判断以规则形式独立存在。判断依据是否显式，决定了这套东西能不能随业务一起长大。
什么情况下应该保留 RPA？
RPA 没有被淘汰。它和 DAE 解决的不是同一个问题，现实中往往配合使用。
保留 RPA
路径完全固定的高频搬运
界面长期不变、每天执行成千上万次、步骤完全确定的任务，用 RPA 成本低、速度快、行为可预测。这类场景没有必要换成 DAE。
改用 DAE
需要先判断再动手的工作
输入来自聊天消息、图片或多种格式的单据，判断依据有规则但写不成固定路径，还需要跨系统完成一整套动作——这是 RPA 吃力、DAE 顺手的地方。
两者配合
DAE 判断，RPA 执行
常见组合是 DAE 负责看懂输入并作出判断，再把结果交给 RPA 跑完固定动作；或者 RPA 负责采集，把结构化结果交给 DAE 判断。选型看任务。
从 RPA 迁到 DAE，需要补什么？
迁移不是推翻重来，但有五件事必须补齐。
规则要先写下来从代码到条文原先藏在脚本里的判断逻辑，需要显式表达成业务规则与阈值，让业务人员看得懂、改得动
输入要允许变化从定位到语义不再假设字段位置固定，改为按语义识别信息，这一步决定它对格式变化的容忍度
异常要有人接从报错到转人工需要明确哪些情况停下、转给谁、由谁确认，而不是抛出一个只有技术能看懂的错误
系统接口要打通从界面到接口从模拟点击转为接口调用，稳定性与速度都会提升；没有接口的部分仍可保留原有操作路径
验收标准要重定从跑通到准确验收口径从「流程能跑完」改为「结果准确、可追溯、异常有出口」
已经跑顺的 RPA 流程不必推倒。务实的做法是把最容易因格式变化而失效的那一段先换掉，其余保留。
选型时最常见的三个误解
误解DAE 会取代 RPA。
实际两者解决的不是同一个问题。路径固定的高频搬运，RPA 依然是更经济的选择；DAE 补的是输入不规整、需要判断的那一段。企业里通常两段都存在。
误解RPA 加一个大模型就是 DAE。
实际加一层模型只解决了「看懂输入」，没有解决「按企业规则判断」和「出错有人兜底」。判断依据是否显式、异常是否有出口，才是分界线。
误解换了就要把旧的全部停掉。
实际没有这个必要，也没有这个好处。RPA 跑得稳的部分继续跑，DAE 接的是它接不住的那一段。切换按流程分批做，比整站替换风险低得多。
与替代方案的对比
另外三种常见替代路径的逐项对比。
- DAE 与人工作业人工处理的成本结构、差错来源与可校验性，以及哪些环节值得先交给系统。
- DAE 与传统进销存进销存记录「已经发生的事」，DAE 接手「正在发生的事」——两者边界与衔接方式。
- DAE 与通用大模型通用大模型产出内容，DAE 产出已完成的工作；权限、规则与留痕的差别在哪里。
还有一份不针对具体方案的概念说明：Agent 和 RPA 有什么区别，讲的是两类技术本身的边界。
关于 DAE 与 RPA 的选型，还有哪些常被问到的问题？
已经在用 RPA 的企业要不要换成 DAE？
看现有的 RPA 是不是经常坏。如果脚本稳定运行多年、几乎不需要维护，没有换的必要。如果经常因为界面改版或输入格式变化而失效，维护成本已经超过收益，那部分流程适合用 DAE 重做。
RPA 和 DAE 可以同时用吗？
可以，而且这是常见的组合方式。DAE 负责理解输入与作出判断，把结果交给 RPA 执行固定动作；或者 RPA 负责采集数据，把结构化结果交给 DAE 判断。两者通过接口或任务队列衔接。
从 RPA 迁移到 DAE 要多久？
取决于要补齐的规则有多少，而不是代码量。原先藏在脚本里的判断需要被整理成业务人员看得懂的条文，异常出口需要和业务方约定清楚。规则清晰、接口齐备的流程，迁移通常比新建一条 RPA 流程更快。
DAE 一定要调用接口吗？还能不能操作界面？
接口优先，但不是必须。有接口时调用接口，速度和稳定性都更好；没有接口的部分，也可以保留原有的操作路径。区别在于 DAE 的处理逻辑不依赖界面元素的固定位置，因此界面小改版通常不会导致整体失效。
哪种任务用 RPA 更划算？
输入位置与格式固定、处理路径完全确定、执行频次高、出错后果可控的任务。这类任务用 RPA 建设成本低、运行速度快，而且行为可预测，不需要引入判断与确认机制所带来的额外复杂度。
DAE 处理不了的输入会怎么样？
会停下来，而不是猜。规则未覆盖、信息缺失、多个来源互相冲突的情况，会被标记出来转给指定的人处理。这个「停下来」的机制是刻意设计的：宁可多问一句，也不让不确定的判断直接变成业务记录。
没有上过 RPA 的企业能直接上 DAE 吗？
可以。RPA 不是前置条件。直接上 DAE 反而少了一层需要拆掉的旧脚本，但要求企业能把现有的判断依据讲清楚——这一步无论走 RPA 还是 DAE 都绕不过去。
选型时最该先问的问题是什么？
先问这项工作的输入会不会变。输入的位置和格式每次都一样，RPA 就够用；输入来自聊天消息、图片、多种格式的单据，或者需要先判断情况再决定怎么做，那就要考虑 DAE。这个问题回答完，选择基本就定了。
先看这项工作现在怎么做，再决定用什么。
把一项正在用人工或脚本处理的工作讲清楚：输入从哪来、什么情况算异常、出错谁确认。我们先判断它属于路径固定还是需要判断，再谈具体方案。