金融級 Enterprise Agentic AI 架構設計：從 Demo 到 Agentic Operating System

若你已讀過 金融業生成式 AI 平台工程，那篇談的是 Agentic AI 如何穩定運行——Cloud Native Runtime、部署、擴展、監控，以及在 IT 入口驗證的可信 RAG 工作流。

本文往 上一層 談：平台穩定運行後，金融業關心的是這套能力能否被 治理、驗證、稽核，並 跨場景複用？能否從單點應用演進為企業 AI 中樞？

我的核心觀點是：金融業 AI 的下一階段，不在模型競爭，而在作業系統的競爭。

此處的 Agentic Operating System，指的是企業管理 AI 如何查證證據、調用工具、受政策約束、接受品質評測、留下稽核軌跡的一層 控制面（Control Plane）——並非傳統 OS，也無意取代既有 IT 系統。

系列閱讀順序建議：先讀 平台工程篇（Runtime 與營運），再讀本篇（治理與 OS 化）。

投影片 PDF

• 下載 PDF：金融級 Enterprise Agentic AI 架構設計

理專現場：這不是聊天機器人測試題

請想像一個更接近金融業務現場的場景。

理專在客戶現場，客戶剛談完風險承受度，理專進一步確認：「這位客戶是 RR3，能不能推薦這檔高收益債基金？」

這不是聊天機器人測試題。AI 不應直接給投資建議，而要查產品風險等級、適合度規則與內規；資訊不足則追問或拒答；涉及銷售適合性則升級人工覆核。

AI 的回答不能僅止於看似合理，而必須 能被信任。

在 IT 入口我們已驗證平台能跑；今天要談的是，同一套治理能力如何進入理專、法遵與內控現場。

能被信任，不是靠更大的模型，而是靠可查證、可拒答、可追蹤的治理能力。

從 PoC 到正式上線：往上問一層

平台工程篇 已從營運角度談過：PoC 只需讓人相信系統「會答」；正式上線則須同時滿足真實使用者、企業流程、權限與稽核。常見斷點是系統孤島、線性 RAG 與黑盒 AI。

本篇不再重述 runtime 怎麼建起來，而是往上問：

平台能跑之後，企業如何把這套能力治理成可跨場景複用、可稽核的中樞？

答案在 架構控制面 的設計。

Enterprise Agentic AI Control Plane

企業級 Agentic AI，不是寫好 prompt、接上幾個函式就夠。金融級 AI 要真正上線，需要一層可治理的控制面——把推理、工具、知識、政策、評測與留痕，全部納入同一套治理範圍。

中間是 runtime：用狀態機管流程，搭配條件分支、重試與失敗處理，讓推理可控、不自由發散。

外圍六個模組，可分三組理解：

第一組：角色與工具

模組	職責
代理註冊表（Agent Registry）	定義每個代理的責任——做什麼、能被替換、能被測試
工具註冊表（Tool Registry）	用權限與留痕要求，規範企業工具怎麼被調用

第二組：證據與政策

模組	職責
知識層（Knowledge Layer）	提供可靠、可引用、權限內的證據
政策引擎（Policy Engine）	把關角色權限、個資過濾、拒答與人工覆核

第三組：品質與留痕

模組	職責
評測模組（Evaluation）	品質評分與回歸測試
追蹤儲存（Trace Store）	每次回答都能回放、可稽核

收束成一句話：runtime，加上工具、知識、政策、評測與留痕——缺一不可。 少一塊還能 demo，但很難成為金融級正式上線系統。

從單點助手到可複用的 Enterprise Pattern

同一套控制面，可以對應不同場景：

場景	任務分解模式
資訊摘要	多來源抓取 → 理解 → 整理
深度研究	拆解查詢 → 搜尋 → 驗證證據是否充分 → 不足則再搜 → 最後才回答
理專支援	查產品條款與適合度規則 → 政策把關 → 拒答或升級人工 → 全程留痕

表面功能不同，底層都是把問題拆成節點、工具與治理邊界。

真正值得複用的，不是某一個聊天機器人，而是 「從問題到架構、再到產品」的任務分解方法。金融業需要的，是將這些做法沉澱為企業可反覆運用的能力。

15+ Agents：治理的是責任地圖，不是代理數量

十五個以上的 Agent，不是十五個微服務，也不是為了架構圖好看。我們是把一筆 AI 請求，拆成十多個可以 獨立檢查的責任——每一項都說得清：輸入是什麼、輸出是什麼、什麼情況算失敗。

為什麼不能全塞給一個大模型？

若所有事情都塞給一個大模型——理解問題、找文件、調系統、判斷能不能答、留下紀錄——全部混在一起。一旦答錯，你只能說「模型不準」，沒辦法改。

拆開以後就不一樣：

責任	只管什麼
意圖分類	這是哪一類問題
查詢路由	去哪個資料源
證據驗證	文件夠不夠支撐回答
政策把關	這題能不能答、要不要交給人

每一步都可以單獨測試、替換、觀測、回放。

這些責任不必等於十五個獨立程式——它可以是平台元件、流程節點，形式可以靈活，但 邊界必須清楚。

金融業為什麼需要這樣拆？

稽核與除錯不能只寫「模型答錯」。客戶問基金適合度答錯了，我們要能判斷：是找錯文件、規則沒擋住、證據不足卻仍回答，還是品質評分沒抓到問題。責任拆清楚了，才能改對的地方。

重點只有一句：我們治理的是責任地圖，不是代理數量。

一筆理專請求如何穿過 Agentic Runtime

理專在客戶現場問：「這位客戶風險屬性是 RR3，能不能推薦這檔高收益債基金？」

這筆請求進來後，實際會發生什麼事？我分 四段 說明：

第一段：聽懂問題

判斷這是 銷售適合性問題，不是一般產品介紹——得查客戶風險屬性、產品風險等級與內規，不能直接用模型常識作答。理專在客戶面前，系統得即時理解與規劃下一步——這裡由 Realtime GPT 負責聽懂與編排。

第二段：找證據、驗證夠不夠

到知識庫查產品說明與適合度規則，必要時調產品系統或 CRM 確認這檔基金的風險等級。文件找齊後，證據驗證模組檢查：資料是否充分、能不能支撐「能不能推薦」這個判斷。

第三段：產生回答並把關

AI 不直接給投資建議，而是依證據說明限制條件；政策把關檢查銷售適合性規則、理專有沒有越權查詢、這題能不能自動答、要不要升級人工覆核；品質評分再確認回答達不達上線標準。

第四段：全程留痕

事後可回放稽核。

即時聽懂與編排 歸 Realtime GPT；查證、把關、評分、留痕 歸平台——不是一個模型包到底。

每一次回答，都是一條可以回放、可以除錯、可以持續改善的路徑。

Knowledge Layer：證據治理，而非搜尋技術

平台工程篇 已詳細討論混合檢索與資料工程；本篇只談 證據治理 角度。

解析錯、切塊錯、檢索錯，後續模型再強，也只是在錯誤資料上推理。

知識層負責三件事：

1. 正確解析文件
2. 切塊保留足夠語意
3. 每段證據帶有來源編號、權限範圍與可信度

這是後續政策、評分與留痕能運作的基礎。金融級 RAG 的第一步不是生成，而是讓 Agent 取得 權限內、可引用、可驗證的證據。

Agentic RAG：可自我校正的工作流

傳統 RAG：先檢索，再生成。

金融場景不能僅依賴此模式——理專那筆請求，如果只是「找到資料就答」，根本不夠。

Agentic RAG 的差異，在於把前述 四段流程 變成可自我校正的工作流；每一步都可以退回重查、拒答或升級人工。

記住一個觀念（與平台篇呼應）：

準確性並非模型的功能，而是整條流程的屬性。

三層安全邊界：不是每題都回答

金融業不能設計一個永遠回答的 AI。真正可上線的 AI，必須判斷何時回答、何時重查、何時拒答、何時交由人工處理。

層級	檢查什麼
證據邊界	證據是否充分？來源是否一致？不足則改寫查詢或拒答
政策邊界	是否允許回答？能否調用工具？角色權限、個資過濾、拒答政策、工具風險等級
人工邊界	法遵、授信、內控、客訴等高風險場景——AI 可輔助整理證據，但不取代最終決策者

改寫、拒答、升級人工——代表金融級 Agentic AI 的價值：不在於完全自主，而在於在可控邊界內自主運作。

LLM-as-a-Judge：讓品質可量測、可回歸

品質不是測一次就結束，每次改版都須能被量測、驗證與回歸。

評測以 平台篇 所述的 100 題低風險 IT 與流程任務 為基礎——數字代表 runtime 的可信度，不代表高風險理專決策已可全自動。題型涵蓋 FAQ、同義改寫、應拒答題與邊界題。

Agent 走完整流程產生回答，再由 品質評分模組 依固定標準四級評分：

指標	結果
加權準確率	98%
嚴格正確率	96%
錯誤或不安全回答	0 題
完整流程 P95 延遲	6.19 秒

為什麼評分不是黑盒？

100 題 每一題都經人工對照校準——先建立人工標準，再校準評分模組。前面報的準確率，是與人工標準對齊後的結果，而非未校準的黑盒分數。

Ablation 告訴我們什麼？

設定	準確率
簡單 RAG	87%
僅混合檢索	83.5%
完整 Agentic RAG	98%

品質提升來自 驗證、拒答、邊界路由與評分——而非檢索器本身。

重點不在數字本身，而在工程態度：題庫、評分方法、人工校準、元件貢獻皆須說明清楚，品質才能被治理。

Production Observability：沒有可觀測性，就沒有金融級 AI

在金融業，可觀測性本身就是治理工具，而非僅供工程師除錯。

每次回答不能只儲存最終答案，還須記錄：

• 使用者意圖
• 代理執行路徑
• 引用證據
• 工具調用
• 政策判斷
• 品質評分
• 回應延遲與拒答原因

當主管、稽核或法遵單位詢問時，系統必須能回答：為何如此作答？使用了哪個工具？查閱了哪份文件？政策是否有攔截？品質評分結果為何？

監控指標分四類：

類別	範例
品質	評分通過率、不安全回答數
效能	P50、P95 延遲
治理	拒答率、人工升級率
成本	Token 用量、工具調用成本

檢索控制召回筆數；工具調用則設逾時與熔斷機制。AI 上線後，真正的挑戰在於能否被 持續營運、除錯與改善。

E·P·J·T：可跨場景複用的治理能力底座

回到開場那個 RR3 基金適合度問題——企業真正要複用的是什麼？

不是做一個理專聊天機器人，而是四項可複用的治理能力。我用 E·P·J·T 來記：

字母	能力	理專請求中的對應
E — Evidence	證據	查產品條款與適合度規則
P — Policy	政策	銷售適合性把關、越權檢查
J — Judge	評測	上線前品質評分
T — Trace	留痕	法遵可回放

剛才那筆請求走過的四段，對應的就是這四項。

這四項能力，在 IT 場景完成驗證；今天看到的是它們如何進入理專、KYC、法遵與內控——同一套治理架構，換業務場景而已。

重點不是一個場景做一個 bot，而是把這套底座帶著走。

收束：From AI Demo to Agentic Operating System

層次	平台篇（Runtime）	本篇（Control Plane）
核心問題	Agentic AI 如何穩定運行？	企業如何治理、複用、稽核？
驗證場景	外勤 IT、語音支援	理專、KYC、法遵、內控
交付物	Operational AI Capability	Agentic Operating System

Demo 展示的是模型能力；正式上線要求的是平台能力——能整合、夠準確、管得住、看得見。

• 快，是體驗問題。
• 準，是信任問題。
• 可拒答、可追蹤、可稽核，才是金融業 AI 上線問題。

下一階段金融業的 AI 競爭，不會僅止於誰採用更大的模型，而在於誰能將 AI 工程化為可營運、可治理、可複用的 Agentic Operating System。

常見問題

為什麼用 IT 場景驗證，不直接做法遵或授信？

IT 場景低風險、高頻、流程明確，適合先驗證 runtime 能否穩定上線。本篇主軸雖是理專與法遵，但評測數字仍來自 IT 驗證基礎——證明的是 runtime 可信度，不是高風險理專決策已可全自動。真正複用的是 E·P·J·T 四項能力；待其穩定後，再延伸至 KYC、法遵、內控與高風險業務決策。

15+ Agents 是否過於複雜？

15 個以上的 Agent 並非 15 個微服務，而是 15 個以上 可治理的責任角色。重點不在數量，而在責任邊界清楚，能被測試、觀測、替換與治理。

Realtime GPT 是否取代整個 workflow？

並非如此。Realtime GPT 是即時互動與編排核心，負責理解、規劃與串接流程；檢索、工具、政策、評分與留痕仍由平台元件協同完成。如此才能兼顧即時互動與企業治理。

LLM Judge 是否也是黑盒？

因此我們不只依賴評分模組，而是以固定評分標準、四級評分、全題人工對照校準、回歸儀表板與對照實驗來驗證。評分結果是與人工標準對齊後的產出。

0 unsafe 是否代表完全安全？

不代表。它表示目前 100 題低風險 IT 與流程任務中，沒有錯誤或不安全回答。下一階段應加入高風險金融題型、更多邊界題、人工覆核一致性評估，以及不同業務情境的政策測試。

系列閱讀

• 上一篇：金融業生成式 AI 平台工程 — Cloud Native Runtime、MCP、Hybrid Search、Agentic RAG 工作流與評測數據
• 站內相關：Agentic RAG 專案 · Agentic AI Platform · Realtime Voice AI