RPA 技術基礎與現況

RPA（Robotic Process Automation，機器人流程自動化）是一種透過軟體機器人模仿人類操作電腦介面的自動化技術。RPA 機器人能夠錄製並重複執行固定的操作流程——例如登入系統、複製貼上資料、填寫表格、下載報表——完全不需要修改後端系統或開發 API 接口。市場上常見的 RPA 平台包括 UiPath、Automation Anywhere、SS&C Blue Prism 和 Microsoft Power Automate。

RPA 的核心優勢在於「非侵入性」：它在 UI 層面操作現有系統，不需要後端開發資源，導入門檻相對較低，且能夠在短時間內自動化大量重複性工作。過去十年間，RPA 是企業流程自動化最常被採用的工具類型之一，在財務、人資、共用服務中心等以表單與報表為主的單位普及度較高；不過各家企業的實際採用比例差異很大，建議以自身產業的公開調查或同業訪談為準，而不要套用單一的市場採用率數字。

然而，RPA 也有其明確的局限性。RPA 機器人是「規則驅動」的：它只能執行預先設定好的固定流程，一旦應用系統介面稍有變化（例如按鈕位置移動、欄位名稱修改、彈出視窗多了一個確認鍵），RPA 機器人就可能失敗，需要人工重新設定。更重要的是，RPA 本身不具備「理解能力」——它無法判讀非結構化文件的內容、無法在面對例外情況時做出彈性決策、也無法處理需要語境理解的任務。實務上，RPA 專案最常見的困擾就是維護負擔：業務流程與系統介面的變更頻率，往往決定了機器人需要被重新調整的次數，而這部分成本在導入評估階段經常被低估。

AI Agent 的核心差異點

AI Agent 的設計理念與 RPA 從根本上不同。RPA 是「規則執行者」，而 AI Agent 是「目標達成者」。給 RPA 的指令是「點擊 A 按鈕，複製 B 欄位，貼到 C 系統」；給 AI Agent 的指令是「幫我處理今天所有待審批的費用申請」。Agent 會自主理解任務目標、規劃執行步驟、在過程中處理各種例外情況，並在任務完成後彙報結果。

AI Agent 的核心技術突破體現在三個層面。第一是理解非結構化資料：AI Agent 能夠讀懂 PDF、掃描文件、電子郵件內文、合約條款等非結構化資訊，這是 RPA 幾乎無法處理的領域。第二是語境理解與例外處理：當流程中出現預期之外的情況（例如客戶的詢問涉及多個部門、合約中有特殊條款），AI Agent 能夠理解情境並做出合理判斷，而 RPA 只能停止等待人工介入。第三是自然語言互動：使用者可以用自然語言向 AI Agent 下達任務，無需按照固定格式輸入，大幅降低使用門檻。

功能與能力對比表

註：上表為技術特性的方向性比較，並非固定規格。實際的建置工時、維護負擔與成功率會依流程複雜度、系統是否具備 API、資料品質與治理成熟度而有明顯差異，建議以自身流程試作後的實測結果為準。

哪些流程適合 RPA、哪些適合 AI Agent

選型的第一個判準不是技術新舊，而是流程本身的「決策密度」。如果一個流程從頭到尾的每一步都能寫成明確的規則、輸入格式固定、例外極少，那它就是 RPA 的甜蜜點：每日定時下載報表並轉檔、把固定欄位的資料從 A 系統搬到 B 系統、批次建立帳號、對帳單格式轉換。這類任務用 Agent 反而是浪費——增加了不確定性，卻沒有換到任何判斷力。

反過來，如果流程中有一段需要「讀懂內容才知道下一步怎麼走」，那就是 AI Agent 的用武之地：從郵件與附件中判斷客訴類別與急迫性、閱讀合約找出與標準條款不同的地方、彙整多份格式不一的供應商報價、把非結構化的申請說明轉成結構化欄位。判斷方式很簡單：如果你要寫一份給新人的 SOP，發現裡面充滿「視情況」「若客戶提到…則…」這類條件，這段流程通常就超出 RPA 的能力範圍。

中間地帶則適合切開處理。多數企業流程不是純規則也不是純判斷，而是「規則—判斷—規則」的三明治結構。務實的做法是把需要判斷的那一段交給 Agent，前後的取件與寫入交給 RPA 或直接的 API 呼叫，並在交界處定義清楚的資料格式（例如要求 Agent 輸出固定 schema 的 JSON），讓後段仍然是可預測的機械操作。

兩種技術的失敗模式也完全不同，這點在評估時比功能清單更值得關注。RPA 的典型失敗是「脆斷」：系統改版、瀏覽器更新、彈出視窗多了一步，機器人就整個停住——好處是失敗很明顯，你會馬上知道。AI Agent 的典型失敗是「悄悄地錯」：它照樣產出看起來合理的結果，但引用了錯的段落、把金額看錯一位、或在多步驟任務中偏離原本目標；加上同樣輸入未必得到同樣輸出，事後稽核與重現都比 RPA 困難。因此導入 Agent 時，必須同步建立輸出格式驗證、關鍵欄位的規則檢查、完整的執行與推理紀錄，以及高風險動作（付款、對外發送、資料刪除）的人工確認關卡。

評估供應商時，建議把問題聚焦在可驗證的項目：這個流程的成功判準如何定義、由誰驗收？失敗時系統怎麼知道自己失敗了，會停下來還是繼續？每一次執行是否有可查的完整軌跡（呼叫了哪些工具、讀了哪些資料、依據什麼做出判斷）？模型或平台版本更新時，既有流程如何回歸測試？權限如何切分，Agent 能碰到的資料範圍是否受最小權限限制？以及當流程需要修改時，是由 IT、業務單位還是供應商負責、需要多久？這些問題的答案，比任何比較表都更能預測導入後的實際體驗。

成本與導入複雜度

成本比較需要區分「初始建置成本」與「總持有成本（TCO）」。RPA 的初始建置成本通常低於 AI Agent，因為 UI 錄製不需要後端 API 開發，導入速度快；然而，RPA 的長期維護成本往往被低估。維護工時主要來自目標系統的介面與流程變更：每次 ERP 改版、網頁前端調整或表單欄位增修，都可能讓機器人需要重新錄製與回歸測試。這個數字沒有通用值，取決於機器人數量、涉及幾套系統、以及那些系統一年改幾次版；要估算就得回頭查自己的變更紀錄與工單，而不是套用他人的平均值。

AI Agent 的初始建置成本主要來自 API 整合工程、提示詞與工具設計，以及常被忽略的評測與稽核機制建置。對於已有良好 API 生態的企業，整合成本可以控制在合理範圍；對於系統老舊、缺乏 API 的企業，前期投資會較高。Agent 的維運成本則移到別的地方：模型推論費用會隨用量成長，模型或平台版本更新後需要重新驗證輸出品質，知識庫與提示詞也需要有人持續維護。換句話說，它未必更便宜，而是把成本從「修介面」換成「顧品質」。

與其引用他人的回收期，不如自己做一份簡單的三年試算。建議至少列入這幾項：兩種方案的建置人月與外部費用；每年預估的變更次數乘以每次的處理工時；Agent 的推論用量與單價；例外案件仍需人工處理的比例與人力成本；以及稽核、回歸測試與教育訓練的固定投入。把這些填進去之後，通常會發現轉折點高度取決於兩個變數——目標系統一年改幾次版，以及流程中真正需要判斷的比例。前者高就對 RPA 不利，後者低就對 Agent 不划算。先用一到兩個代表性流程試作，再把結果外推到其他流程，會比一開始就做全公司規劃務實得多。

RPA 升級 AI Agent 的路徑

對於已有 RPA 投資的企業，升級至 AI Agent 不需要「推倒重來」。一個務實的遷移策略是分三個階段進行。第一階段是「識別痛點」：審視現有 RPA 機器人的維護日誌，找出維護成本最高、故障最頻繁、或因無法處理例外而需要大量人工介入的流程，這些就是 AI Agent 最優先的替換目標。

第二階段是「平行建構」：對選定的流程同時保留 RPA 機器人和建構 AI Agent，先讓 AI Agent 在「輔助模式」下運行（即 Agent 提出建議，人工確認後執行），累積一至三個月的效能數據，確認 Agent 的準確率和穩定性達標後，再切換為全自動模式並關閉 RPA 機器人。

第三階段是「拓展應用」：AI Agent 成功替換高維護成本的 RPA 流程後，進一步探索 RPA 從未能覆蓋的場景——例如需要理解非結構化文件的採購合約審查、需要跨系統彙整資料的業績分析，或需要自然語言互動的員工 HR 自助服務。這些場景的自動化將為企業帶來遠超 RPA 時代的生產力提升。

混合架構的最佳實踐

在很多企業場景中，RPA 和 AI Agent 並非非此即彼的關係，而是可以協同運作的互補技術。一個典型的混合架構是：AI Agent 作為「大腦」負責理解、規劃和決策，RPA 機器人作為「手腳」負責操作無法開放 API 的遺留系統。例如，AI Agent 分析收到的採購申請、判斷是否符合採購政策、計算最佳供應商，然後呼叫 RPA 機器人去舊版 ERP 系統（無 API 支援）中完成採購單的錄入操作。

這種混合架構在製造業場景中常被提出，因為部分企業的生產管理系統（MES）或 ERP 仍是較早期的版本，或雖有 API 但只開放有限功能，全面升級的成本與停機風險都不低。在這類情況下，AI Agent 結合 RPA 的做法，讓企業能夠在不替換核心系統的前提下先取得部分自動化效益；但是否適用，仍須先確認該系統的介面穩定度與變更頻率，否則只是把脆弱點往後移。

選擇混合架構時，建議企業建立清晰的任務分工原則：API 可達的系統一律由 AI Agent 直接整合；只能透過 UI 操作的遺留系統則保留 RPA 負責執行。同時，確保 AI Agent 能夠監控 RPA 機器人的執行狀態，在 RPA 失敗時能夠自動升級告警或切換備用流程，維持整體自動化流程的可靠性。

設計交界處是混合架構成敗的關鍵。實務上建議把 Agent 與 RPA 之間定義成一份明確的資料契約：Agent 只負責輸出結構化欄位（例如供應商代號、金額、會計科目、信心分數），RPA 只負責照著欄位把資料填進去，兩邊都不臆測對方的行為。契約中應包含必填欄位檢查與數值範圍檢查，任何不通過驗證的輸出一律不進入寫入階段，而是轉入人工佇列。另外建議加上信心門檻與金額門檻的雙重規則——低信心或高金額的案件一律送人工確認，讓自動化的比例可以隨著實測結果逐步放寬，而不是一次全開。

可觀測性同樣要一併設計。至少應記錄每次執行的輸入來源、Agent 呼叫過哪些工具與參數、產生的結構化輸出、驗證是否通過、最終由誰核准，並保留足以重現該次決策的紀錄。這些軌跡在流程出錯時是唯一能追根究柢的依據，也是內部稽核與資訊安全單位最常提出的要求；若等到上線後才補，成本通常高出許多。