区别在于不确定性放在哪里
传统程序根据明确规则处理输入，工作流控制步骤与审批，RPA常用于操作缺少接口的界面。大模型Agent则可以根据语言与上下文选择下一步或工具，但其判断存在不确定性。这些能力可以互补，不能简单理解为新技术全面替代旧技术。
例如，员工用自然语言描述采购需求，模型适合抽取品类、数量和用途；预算校验应使用确定性规则，审批流由业务系统执行，最终下单通过授权接口完成。语言理解与正式执行不必由同一种机制负责。
固定流程为什么未必需要Agent
如果表单字段固定、操作顺序稳定、异常类型明确，工作流通常更容易测试和审计。为了让模型重新判断每一个固定步骤，可能增加响应时间、模型费用和维护负担，却没有带来相应价值。
RPA在老旧系统缺乏API时仍有用途，但界面变化、弹窗和登录状态可能影响稳定性。Agent能够理解页面，不代表可以忽略这些风险；涉及生产写入时仍需结果核验与异常处理。
什么情况下值得引入模型判断
用户表达不固定、资料分散在非结构化文档中，或任务需要在少量授权工具间选择时，可以评估模型参与。例如先判断用户是在查订单还是询问政策，再分别进入接口查询或知识检索路径。
但“可以选择工具”不等于无限自主。应限制工具范围、任务步数和执行时间，明确参数缺失时询问用户。超出范围时停止或转人工，比反复尝试生成一个看似完成的答案更可靠。
组合架构如何划分责任
一种实用方式是让工作流控制主路径，模型完成分类、检索和草稿生成，服务端负责权限、参数校验与业务事务。需要人工批准的节点保持为显式状态，不能只靠提示词要求模型先确认。
如果旧系统只能通过RPA操作，可将其封装为受控工具，返回明确的成功、失败或结果待确认状态。对重复执行建立幂等或对账机制；一次界面点击成功不代表业务已经持久化成功。
用采购申请拆解技术责任
员工输入“为项目购买两台显示器”，模型可以提取物品和数量，但项目编号需从授权范围选择，价格与预算由业务服务核验，审批由工作流决定。旧系统没有API时，可评估受控RPA完成必要操作，但仍应核验正式申请编号。这个流程只有自然语言理解部分需要模型，其余固定逻辑并不因为接入Agent就需要重新规划。
- 规则明确的步骤是否仍由程序执行。
- 无接口操作是否有可靠结果核验。
- 人工节点是否作为正式状态保留。
- 改造是否减少负担而非增加环节。
如何比较整体成本和效果
用同一组正常、边界和失败任务比较规则方案、工作流方案与Agent方案，观察成功率、人工介入、总耗时和维护工作。不要只比较模型调用单价，还要计入页面变化、业务规则调整及回归测试成本。
选择依据应是业务需要多少灵活性、能够承受多少不确定性，以及谁负责错误恢复。先保留已经稳定运行的部分，再为真正困难的语言与知识环节引入AI，通常更便于控制改造范围。