RPA 大概是被 AI 行业说得最没出息的工种：流程僵、界面脆、维护靠玄学。所以"拿 Agent 重写 RPA"成了一种政治正确，仿佛不这么干就落后了。这个礼拜素材里正好有两起事故适合拿来泼冷水，外加一摞 Agent 评估的论文。我想说的其实一句话：流程固定的活给 RPA/工作流，Agent 只处理需要判断的分支，二者是串在一条流水线上的，不是投票二选一。
多数"Agent 替代 RPA"的项目，稳定性是倒退的
很多团队做这件事的动机不是业务痛，是技术时髦。本来一个定时任务跑得好好的，每天凌晨从 SFTP 拉文件、改名、入库、失败了重试三次——判断密度为零——非换成 Agent"智能化"一下。结果呢？Agent 每次跑都是模型采样，输出结构今天这样明天那样，你还得在前面加一层 schema 校验、后面加一层人工兜底。等于把确定性问题硬生生改成了非确定性问题，再把复杂度赚回来。
真要出事，就不是"任务失败发个告警"那么简单。本周 Reuters 报道的 OpenAI agents 劫持德国网站事件，本质就是在自主性给足之后，Agent 会沿着攻击面自己"发挥"。Meta 安全研究员那个AI agent 误删邮件的新闻也是同一个病：模型一旦有权执行，就会在不该执行的地方执行。定时任务要的是可预测，Agent 天生不提供这个。
但别急着给 RPA 唱赞歌
反过来，RPA 的死穴我也认：界面一改，全崩。选择器绑死 XPath，前端换个 class 名就断，这种维护成本真实存在，而且每次上游发版你都提心吊胆。但这不能推出"所以要用 Agent"——界面变了，Agent 大概率也死，只是死得更体面：它能读懂新页面，然后做出一个你没想到的、看起来合理的错误操作。RPA 挂了是显性的，Agent 挂了往往是隐性的。哪个更可怕？
这里引一篇这周的论文：SWE-Gate 讨论的是Agent 编程评估只看功能测试过不过，但真实世界的代码评审还包含大量隐性约束。换成 RPA 场景一个意思：流程跑通不等于流程可接受——半夜三点 Agent 把供应商对账单"聪明地"修好了，第二天财务来问谁动的，答不上来。
我的分工标准：按判断密度切
规则很简单。走查一遍流程，把每个步骤标成"是否有可能输入变体"。日期格式固定、字段枚举固定、分支条件写死在业务规则里的，RPA 或工作流引擎；需要读一段话、理解上下文、在规则没覆盖的地方做估计的，留给 Agent。判断密度越高，越值得上 Agent；密度为零的，别折腾。
一个具体场景，比如应付账款核销：
- RPA/脚本：定时抓取邮件附件和 ERP 导出的账单文件，完成格式归一化——这步没有判断空间，只有脏活。
- Agent：只处理三件事——识别哪些发票缺扫描页需要向供应商补材料；金额误差超过阈值时判断是汇率问题还是录入错误；合同条款跟账单不一致时做初步归类。这三步全是"规则说不清但人看一眼就懂"的。
- 回到流程引擎：Agent 吐出结构化结果（不缺件、补件、异常），下游由 RPA 执行补件邮件的发送、系统里的状态更新。Agent 的结果进的是队列，不是直连 ERP。
关键在第 3 步：Agent 有建议权，没有执行权。判断完交回给确定性的管道去落地。
有趣的是，Agent 自己的工具选择也在验证这点——Grep beats LSP 那篇文章说编码 Agent 往往不用更"智能"的 IDE 工具，而是用最糙的 grep，因为 LLM 的输出是概率性的，工具链越简单，容错越高。这就对了：Agent 不该硬撑自己不适合的确定性角色，RPA 也不必在自己扛不住的模糊地带装懂。
本周还看到 DoltLite，一个靠 2k 个 Agent PR 攒出来的 SQLite fork。有人会说：这不就是 Agent 干流水线活的正面案例吗？注意它的前提：所有 PR 都有编译、单测、lint 这类机器可验证的闸门，Agent 被关在笼子里干活。笼子才是关键，不是 Agent。RPA 正是这个笼子的物理形态。
所以别问"Agent 什么时候干掉 RPA"。该问的是：这条流水线上，哪些环节的输入足够随机、需要真正的判断——那是 Agent 的地盘；剩下的，老老实实写脚本、用 RPA、用工作流。你不需要每行代码都带脑子。