2025 證券下單前風控檢核：為什麼要把 AI 代理鎖在「證據鏈」而不是「裁決」（Analysis）
前提
排除
先把結論放前面：在「對外服務 + 必須人審 + 內控稽核」的前提下，AI 代理最適合的位置是「證據整理與解釋層」，不適合當「放行裁決器」。
你想做的是「下單前檢核流水線」，不是「自動交易代理」。這個差別，決定你該怎麼選 LangGraph／Semantic Kernel／AutoGen，也決定你能不能把責任鏈交代清楚。
如果你要一個可直接採用的結論清單：請看 Set 版本（同題材）。這篇 Analysis 只負責把推理鏈、邊界條件、失敗模式拆開講清楚。
Premise（本文前提）
- 對外服務：客戶/外部系統會依你的輸出採取行動（不是內部 demo）。
- 任何 AI 輸出必須人審：AI 只能提建議與整理證據，人是責任 owner。
- 內控稽核要過：事後可重放、可追責、可交代版本與依據（模型版本、規則版本、資料快照、批准人）。
- 混合技術棧：Python + Microsoft 生態並存，交付與維運要務實。
Exclusions（本文排除）
- 自動下單 / 自動交易決策：你要的是交易代理，不是交易輔助。這篇會刻意把你卡死。
- 你做不到基本留存：事件/快照/版本/批准紀錄留不住，就別談 multi-agent。
- 你想靠框架補組織漏洞：權責不清、停損線不存在、變更流程沒人管，多代理只會放大混亂。
你以為你在選框架，其實你在選「責任鏈怎麼長出來」
我見過最常見的錯覺是：
「我們只要挑一個 multi-agent framework，把工具串起來，然後讓模型回答『可不可以下單』就好了。」
這種思路一上線，通常會在兩個地方炸開：
- 客訴/爭議：你能不能回答「當時為什麼放行/阻擋」？不是用一段漂亮的解釋，而是用可回放的證據。
- 稽核/內控：你能不能回答「當時用的是哪個資料快照、哪一版規則、誰批准」？你如果只能拿出對話紀錄，通常等於沒交代。
所以在這個題目裡，框架不是「讓代理更像人」的工具；它是「把流程釘死」的工具。
你要先把責任鏈做出來，才有資格談代理。
三層架構：把 AI 代理放在它該待的位置
我會把「下單前檢核」拆成三層，這三層的邊界一旦混在一起，就會變成稽核地獄：
先給你一張圖：一個可稽核的下單前檢核流水線長什麼樣
倉位/額度/限制表版本] Snapshot --> Rules[Deterministic checks
規則引擎裁決] Rules -->|Pass| Bundle[封存 Evidence Bundle
輸入/版本/結果/原因碼] Rules -->|Fail| BundleFail[封存 Evidence Bundle
含 Fail 原因碼] Bundle --> Explain[LLM 摘要與對照
只做說明，不做裁決] BundleFail --> ExplainFail[LLM 摘要與對照
指出缺口/建議補件] Explain --> HITL{人審批准？} ExplainFail --> HITL HITL -->|批准| Allow[放行：送出下單] HITL -->|拒絕| Block[阻擋：回覆原因] Snapshot -.-> Kill{觸發停損線？
缺快照/版本不明/超時} Kill -->|是| Degrade[降級：只跑規則直出
暫停 LLM 解釋] Degrade --> HITL
Layer 1：Deterministic checks（硬規則裁決層）
這層回答的是：規則是否通過。
例如：倉位限制、交易額度、商品黑名單、時間窗、客戶等級、風險等級、合規限制。
這層的核心是：
- 可預測（同樣輸入必須同樣輸出）
- 可版本化（規則版本可查）
- 可重放（事後可以在同快照上重跑）
Layer 2：Evidence bundle（證據鏈封裝層）
這層回答的是：我用什麼資料與依據做出判斷。
我會把它想成「每一次檢核的封存包」，至少包含：
- 請求摘要（客戶/帳號/商品/數量/價格/時間）
- 倉位快照（來源、時間戳、版本）
- 規則版本（策略/門檻/黑白名單版本）
- 檢核結果（每條規則 pass/fail + 原因碼）
- 例外與豁免（是否存在、誰批准、有效期限）
- 人審紀錄（批准人、時間、意見）
- 系統狀態（依賴服務版本、模型版本、prompt 版本）
你會發現：這層幾乎不需要 LLM。它需要的是工程紀律。
Layer 3：LLM explanation（解釋與對照層）
這層回答的是：怎麼讓人審更快、更不容易漏。
LLM 在這裡最有價值的工作通常是：
- 把「規則結果 + 證據」整理成可讀摘要
- 對照客戶歷史（同客戶/同商品/同額度的過往處理）
- 把資料缺口點出來（缺快照、缺版本、缺批准）
重點是：LLM 不能越權。它可以「說明」，但不能「裁決」。
LangGraph / Semantic Kernel / AutoGen：差異不是功能表，是你要把「狀態」放在哪
如果你接受上面的三層，你會很自然地得到一個結論：
你真正需要的是一個能表達狀態、分支與回放的 orchestration。
LangGraph：把 workflow 變成第一級資產
LangGraph 的強項在於：你可以比較直覺地把流程寫成「狀態機/圖」，然後把每一步的輸入輸出變成可保存的狀態。
在稽核語境下，這代表你更容易做到：
- 每一步都有事件紀錄
- 每一步都能重放
- 分支條件是明確的（不是模型「覺得」）
Semantic Kernel：把企業治理接入點先站穩
Semantic Kernel 對我來說更像是「把 agentic workflow 放進企業工程系統」的 SDK。
當你要跟 Microsoft 生態（.NET、部署、身份、平台工具）打通時，它的價值往往在「接入點」而不是「多代理炫技」。
AutoGen：把多代理互動變成可插拔的工程能力
AutoGen 的價值不是讓代理聊天更像人，而是讓你能把「角色分工、攔截、擴展」做得更工程化。
但它也很容易被誤用：如果你拿它去做「自動放行」，你等於在把責任鏈往黑箱裡推。
一個你可以被稽核的量化指標：維護活躍度（release 距今天數）
我不會用主觀打分說「誰成熟」。我更願意拿一個容易核對的指標提醒你：你選的東西是不是還在動。
這張圖不代表「越活躍越好」。它代表的是：在金融內控情境，你如果踩到 bug，你比較像是在跟一個有節奏的專案合作，而不是接手一個你要自己養的 fork。
一段帶假設的算例：你不做 evidence bundle，最後會用更貴的方式補回來
這不是「真實統計」，而是給你做 sizing 的一個 保守算例（你可以把數字換成你的現實）。
- 假設：每天 50,000 筆下單請求，需要留存 2 年
- 假設：每筆 evidence bundle（JSON + 版本 + 原始檢核結果）落盤後約 6 KB（壓縮前）
那麼：
- 每日新增資料量：50,000 × 6 KB ≈ 300,000 KB ≈ 300 MB/天
- 每年新增資料量：300 MB/天 × 365 ≈ 109,500 MB ≈ 110 GB/年
- 2 年留存：≈ 220 GB（還沒算索引、重放快照、審核附件）
你會發現：儲存本身通常不是大頭；真正的大頭是「你沒做 evidence bundle 時的補救成本」——一旦客訴或稽核來了，你會花工程師時間去拼 log、拼 DB、拼當時規則版本，最後還可能拼不出來。
3 個最常見的失敗模式（我會用它們來檢驗你的設計）
失敗模式 1：你存了對話，卻沒存得起「當時的世界」
最容易發生的悲劇是：你以為你有紀錄（聊天紀錄很多），但你其實沒有「當時的世界」。
稽核問你「為什麼放行」，你拿出一段解釋；稽核追問「那個快照呢？那個規則版本呢？那個例外批准呢？」你開始翻資料庫、翻 log、翻 Slack。
我會用一句話判斷你是不是在走向地獄：
你能不能用同一份 evidence bundle，在乾淨環境重跑出同結果？
如果不能，你不是缺框架，你是缺設計。
失敗模式 2：你做了人審，卻沒有 kill switch（停損線）與降級路徑
很多團隊把「人審」當成護身符：有審核就安全。
但真正的風險是：當模型/依賴服務/資料源出現異常時，你有沒有一鍵降級到「純規則直出 + 人工處理」？
沒有 kill switch，你的人審會變成背鍋點：
因為系統的故障會被包裝成「人審也同意了」。
失敗模式 3：你把 PII / 內部資料分級問題留到最後才想
對外服務的資料分級常常不是「能不能用」的問題，而是「能不能上線」的問題。
如果你在一開始就沒有定義：
- 哪些欄位可以進 LLM
- 哪些只能留在 deterministic 層
- 哪些只能在特定環境/特定角色可見
那你最後會被迫把一堆能力砍掉，或更糟：用一堆臨時遮罩把系統變成不可維護的拼圖。
反例與邊界：什麼情況你根本不需要 multi-agent
我反而希望你不要濫用多代理。以下情況，多代理大概率是多餘的：
- 你只是要做固定規則檢核（不需要跨系統證據整理）
- 你沒有任何人審流程（那你更不應該用 LLM 當裁決）
- 你沒有辦法留存 evidence bundle（先把事件模型補起來）
在這些情況下，我會建議你先做：
- 規則引擎 + 事件留存 + 人審 UI
把「可回放」做起來，再談代理增強。
行動建議：把 Analysis 變成可落地的工程決策
如果你現在要在 30 天內交付一個「可稽核的下單前檢核」：
1) 先定義 evidence bundle 的 schema（你要保存什麼、用什麼版本號、怎麼重放）
2) 把 deterministic checks 變成可版本化的規則集合
3) 再選 orchestration（LangGraph 或 SK/AutoGen）把流程釘死
4) 最後才加 LLM 的解釋層（摘要、對照、補缺口，不做裁決）
如果你要一個「直接可採用的清單結論」，請回到同題材的 Set：
FAQ
以下問題是我預期讀者最常拿來搜尋、也最容易誤解的幾個點。
Q1：下單前風控檢核一定要用 multi-agent 嗎？
A：不一定。你如果只是固定規則檢核，先把規則引擎 + 事件留存 + 人審流程做完整，往往比先上多代理更低風險。multi-agent 的價值通常在「跨系統證據整理」與「把流程拆成可治理的步驟」。
Q2：為什麼說 AI 代理不適合做「放行裁決」？
A：因為你要承擔的是責任鏈與可回放性。裁決層需要可預測與可重放；LLM 更適合做解釋、對照、摘要、指出缺口。你把裁決交給 LLM，最後會在稽核時失去「當時的世界」。
Q3：LangGraph 跟 Semantic Kernel／AutoGen 的最大差異是什麼？
A：差異不在「誰功能多」。LangGraph 更強在把流程當成圖/狀態機；SK 更強在企業整合接入點；AutoGen 更像多代理工程層。你要先決定「狀態與回放」要放在哪一層，才知道該從哪個開始。
Q4：我已經有風控規則系統了，這篇還有用嗎？
A：有，但重點會變成「證據鏈與人審」。你可以保留既有 deterministic checks，把 AI 代理用在證據整理與說明，並且把批准紀錄、版本、快照封裝進 evidence bundle，讓既有系統變得可稽核、可回放、可追責。