Agentic AI 平台契約：上線前必須接上的控制面

若你已讀過 平台工程篇 與 治理篇，會發現還缺一頁：別的團隊拿著 PoC 走進來時，平台到底看什麼。

038 回答 runtime 怎麼穩定跑。039 回答控制面怎麼治理、複用、稽核。本文不重講六個模組，只交出一份可複製的 平台契約：提供什麼、必須接什麼、什麼不准繞過、數字停在哪裡。

九十秒地圖

問題	治理觀念聽得懂，但專案仍用「現場問幾題」當上線標準
核心做法	把 E·P·J·T 收成一頁契約：平台提供、專案義務、禁制、題庫口徑
最硬的證據	同一套 Agentic RAG，100 題 IT／流程任務：加權 98%、嚴格 96%、錯誤或不安全 0、完整流程 P95 6.19 秒（見 038 與 案例 ）
主張停在哪	這些數字是 runtime 在低風險、高頻、流程明確任務上的可信度。不是理專建議、授信或法遵已可全自動

準確度是整條工作流的屬性，不是模型功能。換更大的模型，不能拿來抵銷缺證據、缺政策、缺評測或缺留痕。

為什麼需要「契約」，而不是再一篇架構文

請先看一個低風險、範圍明確的 IT 知識問答案例，而不是直接跳到理專、授信或法遵等高風險場景。

另一個團隊做完 RAG demo，來問：「能不能上線？」回答看起來合理，主管也點頭。平台如果這時只丟 039 的模組圖，對方會說「我們有接 LLM、也有搜尋」。你擋不住。

PoC 卡在三個斷點，038 已經寫過：系統孤島、線性 RAG、黑盒 AI。契約要做的，是把這三個斷點變成 上線評審可以勾的條件。

所以這份文件不是 Agentic OS 的概念介紹。它服務的是必須在這個 sprint 決定某個 Agent 能否進入正式環境的評審者。

平台提供什麼，以及故意不提供什麼

你拿到	你沒有拿到
受控入口：Web／Teams／語音都先過 Gateway 與 Auth	沒有身分的模型聊天窗
Runtime：狀態機編排、分支、重試、失敗處理	單一 prompt 包辦路由、檢索與拒答
知識層：權限內、可引用、可驗證的證據	「搜得到就當證據」
MCP 工具匯流排：授權範圍內的企業工具，每次呼叫留 Tool Trace	每個專案自己串一堆 API
評測與回歸：凍結題庫、四級評分、對齊人工標準的 Judge	現場問幾題當驗收
Trace：意圖、路徑、證據、工具、政策、評分、延遲、拒答原因可回放	只存最終答案

場景可以換：IT 支援、營運知識、理專輔助整理證據。換的是任務分解，不是另做一個 bot。真正複用的是下一節四項能力，這點與 039 相同，契約只是把它變成必須全接的介面。

專案必須接上：E·P·J·T

任何要上線的 Agent，四項都要接到平台。只接檢索、或只接 Trace，仍是 demo。

E — Evidence。 回答只能引用知識層核發的證據：有來源、有權限範圍、有可信度。解析錯、切塊錯、檢索錯，後面模型再強也算平台不合格，不能寫成「模型幻覺」帶過。證據不足就改寫再查；仍不足則拒答或澄清。禁止看起來相關就答。

P — Policy。 角色權限、個資過濾、拒答、人工升級，在檢索與生成之前生效。三層邊界都要顯式：證據、政策、人工。高風險場景（法遵、授信、內控、客訴、銷售適合性）AI 可整理證據，不可當最終決策者。該拒答的題不准進檢索；該澄清的題不准硬搜。

J — Judge。 上線前通過凍結題庫回歸。Judge 必須對齊人工標準。換模型、換路由、換檢索、改 prompt，都要回歸同一題庫。沒回歸視同沒改完。

T — Trace。 每次回答至少留下意圖、路徑、引用證據、工具呼叫、政策判斷、品質評分、延遲、拒答或升級原因。稽核問「為何這樣答」時，系統能回放，而不是事後補敘。

治理的是責任地圖，不是 Agent 數量。意圖分類、查詢路由、證據驗證、政策把關必須能單獨測試、替換、觀測。不必等於 N 個微服務，但邊界必須清楚。答錯時要能指出是找錯文件、規則沒擋住、證據不足仍回答，還是 Judge 沒抓到。不能只說「模型不準」。

七條不准繞過

這七條是契約的牙齒。違反任一一條，PoC 不進入上線評審。

1. 不准為單一場景客製一套檢索／工具／權限，避開 MCP 與知識層。
2. 不准線性 RAG 上線：Retrieve 完直接 Generate，中間沒有「證據是否充分」。
3. 不准黑盒上線：沒有來源、沒有工具紀錄、無法回放。
4. 不准用 demo 答對或「換更大模型」替代凍結題庫回歸。
5. 不准把高風險決策做成全自動。IT 場景的 0 unsafe 只說明該題庫沒有錯誤或不安全回答。
6. 不准每一步都呼叫 LLM。高頻 FAQ、明確拒答、規則可判斷的路由走 deterministic fast path。Agentic 的價值是可控決策，不是每個節點都用模型。
7. 不准未授權 client 預設打到內部知識庫。預設 public；internal 必須顯式授權。

一筆 PoC 怎麼穿過契約

下面用 已公開的 Agentic RAG IT 案例 重建一次上線評審。數字、失敗模式與 ablation 皆來自 038 及案例頁；這不是新實驗，組織名與內部系統名也已打碼或省略。

1. 誰進來、要上什麼

一個應用團隊帶著「內部 IT／流程知識問答」PoC 進評審：OTP 異常、帳號鎖定（金控 vs 區網混淆）、Wi-Fi SSID、入口網與 VPN 等——題型與案例頁舉例一致。入口可經 REST、MCP 或 n8n 工作流，部署於 Cloud Run；這些介面已在案例頁公開。PoC 目標是讓一線同仁用口語問流程，拿到有來源的步驟，不是理專適合度、授信或法遵決策。

2. 平台用契約看什麼

評審不看現場十題答對幾題，也不看 demo 漂不漂亮。看的是：E·P·J·T 是否全接、七條禁制有無被繞過、能否交出凍結題庫與 Judge 校準紀錄。契約把「會答」和「能上線」拆開。

3. 四道關怎麼過

E — Evidence

混合檢索（向量＋BM25＋RRF）完成後，文件必須再經評分與 context validation，才會進入生成。證據不足時，系統會改寫查詢或拒答。

這道關曾把「金控帳號鎖定」與「區網帳號鎖定」混進同一段 context。生成內容看似合理，步驟卻指向錯誤系統。契約將它歸類為 Evidence 失敗，而不是籠統稱為「模型幻覺」；修正方式包括 document grading、focus context 與 cross-topic trimming。

P — Policy

路由採 rule-first：高信心 FAQ 直接回答，應拒答的問題不進檢索，缺少系統範圍時先要求澄清。例如使用者只說「帳號鎖定」，系統必須先確認是金控、區網或 VPN。

這批 100 題屬於低風險 IT／流程任務，不是高風險決策題庫。因此 P 只能證明本案例的拒答與分流有效，不能證明理專或授信流程可以自動化。

J — Judge

案例使用凍結的 100 題、四級評分與經人工校準的 Judge。v22 加權準確率為 98.0%，嚴格正確率為 96.0%，錯誤或不安全為 0 題；其中 96 題完全正確，4 題部分正確。

Ablation 中，Naive RAG 為 87%，Hybrid-only 為 83.5%，完整 Agentic 工作流為 98%。這裡確認的是有回歸、有 ablation，而且沒有 unsafe 結果，不是現場展示後的印象分；詳細門檻留到下一節說明。

T — Trace

公開案例展示 LangGraph 狀態機、query_analysis_source = rule | llm、Prometheus metrics，以及保留治理流程時的 P95 6.19 秒。這些證據支持系統具備可觀測設計。

但公開頁面沒有 Trace 欄位 dump 或樣本 log，因此尚未證明每個必要欄位都完整。正式上線評審仍須抽查意圖、路徑、證據、工具、政策、評分、延遲與拒答原因的回放紀錄。

4. 什麼交付會被擋

對照七條禁制，這筆 PoC 若改成下面任一種，就不進上線評審：

• 線性 RAG（Retrieve → Generate，中間沒有「證據是否充分」）——對應第 2 條；ablation 已證明 Naive 87%、Hybrid-only 83.5%，低於完整 Agentic 98%
• 只交 demo 十題、交不出凍結題庫與拒答題——對應第 4 條
• 每步都呼叫 LLM、沒有 rule-first fast path——對應第 6 條；案例後續 rule-first 平均 2.606 秒、P95 5.636 秒，證明不必每節點都用模型
• Trace 只存最終答案、無法回放路徑與證據——對應第 3 條

5. 這筆 PoC 證明到哪

它支持的是：在這組 低風險、高頻、流程明確的 IT 題庫 上，完整 Agentic 工作流的加權準確率為 98%，高於 Naive RAG 的 87%，且沒有題目被評為錯誤或不安全。

它沒有證明理專適合度、授信、KYC 或法遵可全自動。那些場景仍須人工邊界；把 98% 貼進高風險上線報告，本身就不符合契約。

上線門檻：目前公開的驗證口徑

以下來自 100 題低風險 IT／流程任務 的凍結題庫，已寫在 038 與案例頁。這不是全公司 SLA。新場景必須自備同等口徑的題庫，或先擴充平台題庫。

四級評分：正確／部分正確／拒答正確（安全行為，不算失敗）／錯誤或不安全（零容忍）。

門檻	已公開量測	契約怎麼用
錯誤或不安全	0 題	新場景必須為 0
加權準確率	98.0%（v22）	不得把 partial 算進「完全正確」；須說明題型組成
嚴格正確率	96.0%	單獨揭露
完整流程 P95	6.19 秒（含檢索、驗證、重寫、拒答、Trace）	必須在保留治理下量測；禁止拆掉驗證換速度
Ablation	Naive RAG 87%；只做 Hybrid Search 83.5%；完整 Agentic 98%	須能說明品質來自驗證與拒答，不是只靠召回
Judge	100 題皆經人工對照校準	新 Judge 先校準再當門檻

案例後續的 rule-first 路徑，把高信心 FAQ 移出 LLM 分析，平均延遲降到 2.606 秒、P95 5.636 秒。這組結果支持第 6 條：部分明確路由可交給規則處理，在保留治理流程的同時降低延遲。

營運上線後，SLO 至少涵蓋品質、效能、治理、成本，加上 Trace 完整度。缺一類不算可營運。

場景怎麼進平台

階段	可以做	還不能做
已驗證：IT／流程問答	當 runtime 可信度的基線；複用 E·P·J·T	把 98% 直接寫進高風險業務的上線報告
可延伸：客服知識、營運查詢	換知識範圍與政策表，沿用同一控制面	另起一套 RAG
須人工邊界：理專適合度、KYC、法遵、內控、授信	AI 查證、整理限制條件、升級人工	模型直接給投資建議或核准

申請上線時繳交：責任地圖（每步輸入／輸出／失敗定義）、知識範圍與權限、政策表、凍結題庫與 Judge 校準紀錄、Trace 抽樣回放、SLO 承諾。

別人要複製這份契約時，還要填的欄位

公開文章寫不到各公司內部的人名與系統名。若你要把契約真的掛進自己的平台，下面這些必須有 Owner，不能留白：

• 平台 Owner 與備份
• 誰能批准豁免「七條不准」
• 資料分級與對應知識庫（至少 internal／public）
• 正式環境 SLO（與 benchmark 分開寫）
• 目前「唯一準」的 MCP 工具清單與 Agent Registry 入口
• 高風險場景的指定人工角色
• 題庫保管位置與改題規則（誰能改題、改了要重凍結哪個版本）

這些欄位是契約能被執行的條件，不是可選附錄。

收束

記住三件事。

技術想法：平台契約是控制面的使用界面，E·P·J·T 必須全接。

最硬的證據：同一套工作流在 100 題 IT／流程任務上，加權 98%、0 題錯誤或不安全；拆掉驗證與拒答，準確率掉回 87% 或 83.5%。

採用邊界：這份契約能擋「會答的 demo」，不能授權高風險金融決策自動化。0 unsafe 不是完全安全。

層次	038 Runtime	039 Control Plane	本篇契約
核心問題	怎麼穩定跑	怎麼治理、複用、稽核	這個 PoC 能不能上線
交付物	Operational AI Capability	Agentic Operating System	一頁可勾選的使用界面

• 快，是體驗問題。
• 準，是信任問題。
• 可拒答、可追蹤、可稽核，才是金融業 AI 上線問題。
• 平台把上線條件寫成可勾選、可驗證的標準，其他團隊才知道缺什麼、為何被擋。

常見問題

這跟 039 有什麼不同？

039 說明控制面是什麼、為什麼要拆責任。本篇把同一套東西收成專案團隊必須遵守的界面。讀 039 是為了同意架構；讀本篇是為了決定這週過不過門。

為什麼評測數字還是那 100 題？

因為那是目前公開、口徑清楚、有 ablation 與人工校準的證據。契約如果另報一組沒有規程的「業務準確率」，會把主張和證據混在一起。高風險題型應該擴充題庫，而不是沿用 98% 當通行證。

小團隊沒有 Agent Registry，能用這份嗎？

能。先從四項能力與七條禁制開始。Registry 可以是一張表，不必先做微服務。形式可靈活，邊界必須清楚。

這份契約是不是內部規範外流？

不是。文中沒有組織名、系統清單或未公開 SLO。數字與失敗模式皆已見於 038、039 與案例頁。各公司要把契約落地，仍須自己填上一節的 Owner 欄位。

這筆 PoC 是真的嗎？

是。上一節 walkthrough 用的是已公開的 IT 案例，不是新實驗；數字與失敗模式與 038 及 Agentic RAG 案例頁 相同。

系列閱讀

• Runtime：金融業生成式 AI 平台工程
• Control Plane：金融級 Enterprise Agentic AI 架構設計
• 站內相關：Agentic RAG 專案 · Agentic AI Platform · Realtime Voice AI

契約來源與使用邊界

E·P·J·T 與七條禁制是 Bloss0m 根據公開標準與本站案例整理的上線介面，不是任何外部機構頒布的合規規範。採用者仍須依自身法域、資料分類與風險責任完成正式審查。

• NIST AI 600-1：Generative AI Profile — 生成式 AI 風險與治理背景
• Model Context Protocol：架構規格 — MCP 權限、隔離與能力協商的協定背景
• OpenTelemetry：Generative AI semantic conventions — Trace 欄位設計的互通性參考
• Agentic RAG 案例 — E·P·J·T walkthrough 數字與失敗模式的第一方證據