RAG、AI 智能体与 RPA：如何选择合适的自动化方式

从实际工作出发，而非技术标签

人员需要从经过审核和管理的知识中获取答案时，使用 RAG；稳定的系统操作使用 API；旧界面是唯一可行路径时使用 RPA。只有流程确实需要上下文判断或动态路径时，才加入 AI 智能体。

这些方法不能互相替代，也并不互斥。实用生产流程往往将它们组合，同时明确各自责任。

在需要理解和判断的环节使用 AI；验证及影响重大的系统操作，则应按明确、可重复的规则执行。

哪种方法适合哪种场景？

用 RAG 检索受控知识，答案仍需核实

当员工需要以自然语言访问政策、流程、产品记录、项目文档或技术手册等私有或变化中的资料时，RAG 很有用。它让答案更易查找与核实，无需每次文档变化都重新训练模型。

应做

• 为源文档指定负责人，并定义生效日期、元数据、版本及移除规则。
• 检索时保留文档权限，让用户只能获得有权查看的证据。
• 分别测试检索与回答质量：先确认是否找到正确证据，再确认答案是否有据可依。
• 展示引用，并在证据不足时安全地说明无法作答。

避免

• 上传未经管理的文件夹，就把数据摄取当作完成。
• 让搜索索引绕过源系统访问规则。
• 只按文字流畅度评估质量；引用错误段落的漂亮答案仍然是错的。
• 仅靠 RAG 计算、审批或更新业务记录。

流程需要判断时，才使用智能体

如果任务的输入不明确、处理路径不固定、上下文不断变化，或无法安全地用固定步骤决定调用哪些工具，才值得引入更复杂的智能体。先从一个职责范围明确、只配备少量工具的智能体开始，再考虑多智能体设计。

限定工具职责，例如读取个案、验证标识、计算金额、创建草稿或提交获批更新。只给予智能体所需的最少数据与权限。分离读写工具、验证工具输入、限制交易范围，并由负责人审批敏感或不可逆操作。

提示注入无法仅靠过滤解决，应以限制影响范围来设计：即使恶意文本影响模型，智能体也不应有足够权限泄露敏感数据或执行未授权操作。

通过 API 与 RPA 保持执行可预测

受支持 API 通常是重复系统操作的清晰基础，因为它提供可验证、记录、重试及监控的明确约定。确保重试安全，拒绝无效输入，使用关联标识，并与权威记录系统核对结果。

业务操作只能通过旧界面或虚拟桌面完成时，RPA 仍有价值。隔离界面步骤，使用稳定选择器，记录业务及应用异常，并保留人工接手方案。已有可靠受控 API 提供相同操作时，不应模拟人工点击，除非有文档说明的限制。

示例：处理邮件服务请求

1. RAG 在权限筛选下检索现行政策及相关协议。
2. 智能体解释非结构化请求并识别缺失资料。
3. API 按预先定义的规则读取账户信息，判断是否符合条件。
4. 价值或风险超过设定阈值时，由人员批准建议。
5. API 工作流执行更新；仅对剩余的界面专属步骤使用 RPA。
6. 流程记录证据、决策、审批、操作、结果、耗时及异常状态。

这样分工，既能在需要判断的地方使用模型推理，也能在要求准确、授权和可审计的环节，采用明确、可重复的规则控制。

在工作流层面衡量效益

构建前，建立交易量、周期、人工处理、错误与返工、异常率、审核投入、服务水平及运营成本基线。上线后衡量合格成果，而非对话、词元、工具调用或机器人运行次数。

• 每个期间完成的合格成果；
• 端到端周期与节省的人工时间；
• 全自动完成与人工辅助完成；
• 错误、返工、异常及升级处理率；
• 目标用户的实际使用情况；
• 每项合格成果成本，包括基础设施、模型使用、重试及人工审核；
• 被阻止操作、权限失败及其他风险指标。

五步选择测试

1. 只需从获批内容获取答案时，从受控检索开始。
2. 如果工作遵循固定流程，就通过 API 或工作流按明确规则自动执行。
3. 所需操作只能经界面完成时，对该有限步骤使用 RPA。
4. 上下文判断会改变路径时，评估配备限定工具与明确退出条件的智能体。
5. 操作影响重大时，在执行前安排基于明确规则的检查及人工审批。

一手参考资料

• Microsoft：RAG 方案设计与评估
• OpenAI：构建智能体实用指南
• UiPath：API 自动化 与 界面自动化