智能體和 RPA 經(jīng)常被放在一起比較,但它們處在執(zhí)行鏈路的不同位置。本文從依賴條件、失敗模式、集成方式三個工程維度拆解,給出一套可落地的選型判斷順序。
把智能體和 RPA 對立起來,本身就問錯了問題。
從執(zhí)行鏈路看,一個自動化任務(wù)可以拆成三段:
意圖理解 → 判斷決策 → 動作執(zhí)行
所以更準確的關(guān)系是:智能體負責想清楚做什么,RPA 或業(yè)務(wù)接口負責把動作執(zhí)行下去。
| 維度 | RPA | AI 智能體 |
|---|---|---|
| 依賴條件 | 界面元素 / 固定流程 | 知識、數(shù)據(jù)、可調(diào)用工具(接口) |
| 失敗模式 | 界面改版、彈窗、數(shù)據(jù)格式變化 | 理解偏差、檢索錯誤、生成錯誤、越權(quán)執(zhí)行 |
| 一致性 | 高,同輸入必同輸出 | 概率性,同輸入可能有不同輸出 |
| 適合的任務(wù)特征 | 高頻、規(guī)則固定、要求完全一致 | 低頻、規(guī)則模糊、需要跨系統(tǒng)綜合判斷 |
最后一行是核心:RPA 是確定性的,智能體是概率性的。 需要 100% 一致的動作,用概率性系統(tǒng)去做本身就是設(shè)計錯誤;反過來,規(guī)則寫不完的場景,硬堆規(guī)則也是浪費。
工程上第一件事不是選工具,而是看目標系統(tǒng)的集成條件:
if (目標系統(tǒng)提供穩(wěn)定接口 && 有寫入授權(quán)):
優(yōu)先走接口調(diào)用
elif (老系統(tǒng) && 無接口 && 必須自動化):
評估 RPA 做界面自動化
→ 必須設(shè)計:界面變化檢測、執(zhí)行失敗重試、人工接管入口
else:
AI 只能給建議,動作仍需人執(zhí)行
接口優(yōu)先這條原則的理由很實際:接口有契約、有版本、有返回值、可做權(quán)限校驗和審計;界面自動化則依賴 DOM 結(jié)構(gòu)或坐標,上游一改就斷,且出了問題難以追溯。
一個常被忽略的坑:"數(shù)據(jù)庫連通"不等于"業(yè)務(wù)集成完成"。 能連上庫只說明網(wǎng)絡(luò)通,業(yè)務(wù)含義上的字段映射、校驗規(guī)則、審批流程、冪等控制這些都沒解決。
讀操作出錯,最多是答錯了;寫操作出錯,會直接改壞業(yè)務(wù)數(shù)據(jù)。寫入類步驟必須單獨驗證:
演示環(huán)境和生產(chǎn)環(huán)境的差別,幾乎全部集中在異常路徑上。上線前至少要把這三類說清楚:
| 場景 | 處理方式 |
|---|---|
| 數(shù)據(jù)缺失 / 格式異常 | 停止并提示,不要猜測填充 |
| 權(quán)限不足 | 明確拒絕,不要把高權(quán)限賬號作為兜底 |
| 接口超時 / 寫入失敗 | 重試 → 仍失敗則轉(zhuǎn)人工,并留痕 |
特別提醒:不要用一個統(tǒng)一的高權(quán)限系統(tǒng)賬號去取數(shù)。 如果 AI 不繼承當前用戶身份,權(quán)限校驗實際上是被繞過的——這在工程上很省事,在合規(guī)上是重大缺陷。
現(xiàn)實里兩者經(jīng)常同時存在:
用戶發(fā)起任務(wù)
↓
YonWork 接收并理解意圖(智能體)
↓
需要跨系統(tǒng)取數(shù) → 走 YonData / 業(yè)務(wù)接口
需要判斷 → 基于知識(YonKnow)與語義(YonOnto)
↓
執(zhí)行動作
├─ 有接口 → 直接調(diào)用
└─ 無接口的老系統(tǒng) → 調(diào)用 RPA 做界面操作
↓
YonAIG 記錄運行日志、審計與評估