智能体和 RPA 经常被放在一起比较，但它们处在执行链路的不同位置。本文从依赖条件、失败模式、集成方式三个工程维度拆解，给出一套可落地的选型判断顺序。
把智能体和 RPA 对立起来，本身就问错了问题。
从执行链路看，一个自动化任务可以拆成三段：
意图理解 → 判断决策 → 动作执行所以更准确的关系是：智能体负责想清楚做什么，RPA 或业务接口负责把动作执行下去。
| 维度 | RPA | AI 智能体 |
|---|---|---|
| 依赖条件 | 界面元素 / 固定流程 | 知识、数据、可调用工具（接口） |
| 失败模式 | 界面改版、弹窗、数据格式变化 | 理解偏差、检索错误、生成错误、越权执行 |
| 一致性 | 高，同输入必同输出 | 概率性，同输入可能有不同输出 |
| 适合的任务特征 | 高频、规则固定、要求完全一致 | 低频、规则模糊、需要跨系统综合判断 |
最后一行是核心：RPA 是确定性的，智能体是概率性的。 需要 100% 一致的动作，用概率性系统去做本身就是设计错误；反过来，规则写不完的场景，硬堆规则也是浪费。
工程上第一件事不是选工具，而是看目标系统的集成条件：
if (目标系统提供稳定接口 && 有写入授权):
优先走接口调用
elif (老系统 && 无接口 && 必须自动化):
评估 RPA 做界面自动化
→ 必须设计：界面变化检测、执行失败重试、人工接管入口
else:
AI 只能给建议，动作仍需人执行接口优先这条原则的理由很实际：接口有契约、有版本、有返回值、可做权限校验和审计；界面自动化则依赖 DOM 结构或坐标，上游一改就断，且出了问题难以追溯。
一个常被忽略的坑："数据库连通"不等于"业务集成完成"。 能连上库只说明网络通，业务含义上的字段映射、校验规则、审批流程、幂等控制这些都没解决。
读操作出错，最多是答错了；写操作出错，会直接改坏业务数据。写入类步骤必须单独验证：
演示环境和生产环境的差别，几乎全部集中在异常路径上。上线前至少要把这三类说清楚：
| 场景 | 处理方式 |
|---|---|
| 数据缺失 / 格式异常 | 停止并提示，不要猜测填充 |
| 权限不足 | 明确拒绝，不要把高权限账号作为兜底 |
| 接口超时 / 写入失败 | 重试 → 仍失败则转人工，并留痕 |
特别提醒：不要用一个统一的高权限系统账号去取数。 如果 AI 不继承当前用户身份，权限校验实际上是被绕过的——这在工程上很省事，在合规上是重大缺陷。
现实里两者经常同时存在：
用户发起任务
↓
YonWork 接收并理解意图（智能体）
↓
需要跨系统取数 → 走 YonData / 业务接口
需要判断 → 基于知识（YonKnow）与语义（YonOnto）
↓
执行动作
├─ 有接口 → 直接调用
└─ 无接口的老系统 → 调用 RPA 做界面操作
↓
YonAIG 记录运行日志、审计与评估