起点：规则穷举与目标驱动
RPA 与规则引擎要求人先把分支写完，流程越复杂规则越多；Agent 只给目标与可用工具，由模型决定步骤。前者前期投入大但行为可预测，后者起步快但必须用样本验证；如何取舍，取决于流程本身的稳定程度与留痕要求。
异常：断点与自适应
界面改版或字段变更会让 RPA 直接失败，Agent 则可能换个路径继续，这既是优点也是风险：它可能在错误的方向上把事情做完。因此异常必须被完整记录并定期回放，看看它在什么条件下会走偏，边界要逐条写清。
审计：逐条规则与执行轨迹
规则系统的判断可以逐条解释，审计只需看配置；Agent 的判断依赖上下文与模型，审计要靠完整轨迹日志。对留痕要求高的流程，轨迹不完整就不能上线，这一点无法用任何口头承诺来替代，必须写进验收条款，这也是可审计性的边界。
成本：一次投入与持续运营
RPA 的成本集中在实施与规则维护，Agent 的成本分散在接口、评测、提示词维护与调用量。前者随流程稳定而下降，后者需要持续投入，如何编排预算？应按年度编制，并把评测与维护单独列出，而不是按单个项目一次性核算。
适用与不适用
适合谁
- 流程分支多、规则维护成本高的业务
- 需要处理非结构化文档与自然语言的环节
- 已有稳定接口、能承担评测投入的团队
不适合谁
- 审计要求极高且不允许模型判断的流程
- 界面与系统频繁变动、无法稳定取数的环境
典型场景
某制造企业的订单变更流程原本用 RPA 抓取邮件附件再录入系统，规则维护占了大量工时。改造后由 Agent 读取邮件与附件、提取变更字段并生成待确认草稿，跟单员确认后才写入，RPA 只负责最后的系统录入，两者分工清晰，故障时也容易定位。
可执行步骤
- 先统计现有流程的分支数量与例外类型，标出其中最容易出错的位置
- 逐条标出必须留痕、必须由人判断的节点，并确认每个节点由谁承接
- 让规则或 RPA 继续承接录入、校验与最终提交等确定性动作，不要拆走
- 让 Agent 的任务范围严格限定在读取、比对与草稿生成这三件事上
- 每季度回放一批失败案例，据此调整人员与两类系统之间的任务分工
常见坑
- 把 Agent 当作 RPA 使用，只让它跑固定步骤，既没得到灵活性，又额外引入了不确定性与调用成本，得不偿失。
- 让 Agent 绕过原有校验直接写生产系统，一旦出错既难定位原因，也没有可靠的回滚路径与证据链。
- 只比较自动化率，不比较异常处理、调用成本与长期维护工时，算出来的收益通常偏高不少。
- 没有完整的执行轨迹日志，出了问题只能靠猜，复盘无法开展，责任界定也会落空，改进无从谈起。
自检与验收清单
- 是否已经统计过现有流程的分支数量与例外类型
- 留痕要求高的节点是否仍由确定性系统来承接
- Agent 的任务范围是否只到读取、比对与草稿
- 轨迹日志是否完整，是否支持按单个任务回放
- 是否已经建立按季度复盘失败案例的固定机制
常见问题
引入 Agent 之后还需要 RPA 吗？
多数场景是分工而非取代：确定性动作交给规则与 RPA，读取、理解与草稿交给 Agent。已有 RPA 的企业通常只需在前后加一层调用，不必推翻重建，改造与并存的总体成本通常更低，也更容易在故障时定位问题。
哪种流程不适合 Agent？
判断标准是错误可否撤回、是否必须逐条解释。资金划付、资质申报、对外报送等流程一旦出错代价很高，应保留确定性系统与人工复核环节，不要用试点去赌一个小概率事故。
引入 Agent 后审计怎么做？
以轨迹为单位审计：记录每次调用的输入、工具、返回结果与人工确认点，按任务留档。审计要求高的行业还需约定留存期限与访问权限，避免日志本身变成新的风险点与负担。