AI agent 正從回答問題轉向採取行動。
這個轉變徹底改變了風險模型。
聊天機器人產生文字。Agent 則操作系統。
它們能讀取電子郵件、呼叫 API、更新客戶記錄、部署程式碼、建立工單、核准工作流程步驟、與其他 Agent 協作，並將新知識儲存到長期記憶中。
這意味著核心問題不再是：
這個答案正確嗎？
而是：
這個 Agent 現在應該被允許行動嗎？
這就是治理層存在的意義，用來回答這個問題。
1. 記憶有用，但它不是治理。
記憶幫助 Agent 跨對話保留上下文。
它幫助 Agent 記住使用者偏好、過往工作、工具輸出和先前的決策。這很重要。但記憶無法決定：
- 哪些事實可以被寫入記憶
- 哪些記憶已經過時或被污染
- 哪些行動需要核准
- 下一步必須執行哪個工作流程步驟
- 執行前需要哪些證明
- 哪個 Agent 可以使用哪些資訊
在實際運作的 Agent 系統中，更困難的問題往往不是檢索，而是權限。
記憶幫助 Agent 記住。
治理幫助它選擇自己可以做什麼。
這個區別正是 Marrow 所在的定位。
Marrow 不僅僅是一個記憶層。它是一個針對 AI Agent 群的判斷層。
2. 可觀測性解釋過去。Agent 需要在未來發生前獲得控制。
可觀測性是必要的。團隊需要追蹤、日誌、評估、註釋、警報和儀表板。
但是，事後的可見性無法阻止不良行動在發生前出現。
如果一個 Agent 部署了不安全的程式碼、發送了敏感郵件、核准了錯誤的付款，或跳過了必要的工作流程步驟，儀表板可能會在事後解釋事件。但它不一定能預防事件發生。
對於高影響力的工作流程，訊號必須在行動之前送達 Agent：
- 風險等級
- 所需證明
- 政策限制
- 擁有者核准
- 回滾計畫
- 確切的下一步
- 允許、警告、審查或阻止
這就是可觀測性與治理之間的差距。
儀表板通知人類。
治理則在 Agent 行動之前通知它們。
3. 評估是快照。實際運作是持續流。
部署前的評估能捕捉許多失敗。但實際運作的 Agent 生活在變化的環境中。
提示詞會變。工具會變。API 會變。資料會變。政策會變。群組中的其他 Agent 也會變。
基準測試可能顯示 Agent 在某組條件下表現良好。實際運作則問了一個不同的問題：
當環境改變時，這個 Agent 還能持續做出正確的決定嗎？
關於工具使用 Agent 的研究也指向相同方向。
ToolEmu 研究了使用高風險工具的語言模型 Agent，並顯示 Agent 的失敗可能造成嚴重的現實後果。AgentHarm 和 CUAHarm 則專注於 Agent 在使用工具或操作電腦時可能出現的有害行為。其他研究顯示，Agent 可能在抽象層面上理解風險，但在具體的軌跡中仍然無法避免風險行動。
實際的教訓是：
安全性不能只存在於模型或基準測試中。
實際運作的 Agent 需要執行時期控制。
4. 治理正成為 AI 基礎設施。
主要的 AI 治理框架正匯聚到同一個想法上：負責任的 AI 必須變得可操作。
不僅僅是原則。
不僅僅是政策 PDF。
不僅僅是儀表板。
可操作的治理需要：
- 記錄在案的風險管理
- 自動記錄
- 針對高影響決策的人類監督
- 跨生命週期的品質管理
- 系統行為的可追溯性
- 上市後監控
- 對不良結果的問責
這在 NIST AI RMF、NIST 的生成式 AI 概況、ISO/IEC 42001、OECD AI 原則、歐盟 AI 法案、OWASP 的 Agentic AI 風險分類，以及 2026 年五眼聯盟關於 Agentic AI 服務的指引中都可見。
方向很明確。
企業 AI 系統需要在其整個運作生命週期中具備證據、控制、可追溯性和問責制。
對於 AI Agent 而言，這意味著治理必須進入執行時期。
5. Agent 治理層應該做什麼
治理層是介於 Agent 執行時期和 Agent 可以影響的系統之間的控制平面。
它接收 Agent 打算採取的行動，根據政策、權限、風險、證明和先前結果進行評估，然後返回一個可執行的決定：
允許
警告
需要審查
阻止
一個真正的治理層需要九項功能。
- 身份與範圍權限
每個 Agent 都需要清晰的身份、有限制的權限和範圍內的憑證。
如果每個 Agent 都共享同一個 API 密鑰，就無法治理整個群組。
- 執行時期政策
政策必須成為可執行的執行時期條件。
哪個步驟必須先做？
需要哪些證明？
哪個行動永遠需要審查？
哪個行動絕對不能自動執行？
- 風險閘門
系統應根據影響、可逆性、敏感性和業務內容對行動進行分類。
低風險的工作可以自動執行。高風險的工作可能需要證明、核准或阻止。
- 證明包
在行動之前，Agent 應附上證據。
例如：
- 測試覆蓋率
- 回滾計畫
- 政策條款
- 身份驗證
- 臨床核准
- 帳單審查
- 主管簽核
- 核准路由
人類審查不應該是所有事項的手動佇列。
它應該是針對錯誤成本高昂的行動設置的條件檢查點。
- 稽核與來源
每個決定都應可追溯。
誰發起的？
為什麼允許或阻止？
適用了哪項政策？
附上了哪些證明？
誰核准的？
接下來發生了什麼？
- 結果閉環
治理不以允許或阻止結束。
系統必須閉環：
- 行動成功了嗎？
- 失敗了嗎？
- 需要回滾嗎？
- 誰核准的？
- 應該儲存什麼教訓？
- 記憶寫入治理
並非每個日誌都是知識。
並非每個知識都應該影響每個 Agent。
真實的結果只能透過受控的寫入才成為記憶。
- 群組層級學習
治理層應追蹤整個群組的行為：
- 偏離基準工作流程
- 重試迴圈
- 重複失敗
- 應該警告未來 Agent 的模式
這就是治理超越限制、成為學習的地方。
6. Marrow 作為治理案例研究
Marrow 的設計圍繞一個簡單的操作循環：
orient → think → act → check → commit
每個步驟都有一個治理功能。
Orient 提供相關的歷史、警告和限制。
Think 在行動發生前評估意圖行動。
Act 執行時附上上下文和護欄。
Check 檢查是否缺少證明或閉環。
Commit 記錄結果，以便下一個決策能改進。
這就是記憶與判斷之間的核心區別。
記憶問：
Agent 知道什麼？
Marrow 問：
Agent 應該行動嗎？以及在什麼條件下？
它的產品功能直接對應到執行時期治理：
- decisionBrief() 提供 Agent 行動前的上下文。
- workflowGate() 返回允許、警告、需要審查或阻止。
- runGuarded() 包裹高風險工作，附帶行動前指導和結果閉環。
- agentRuntime() 將教訓和證明要求注入 Agent 上下文。
- agentStatus() 顯示 Marrow 是否活躍並收集有用訊號。
- valueReport() 將治理轉化為擁有者可見的證明。
換句話說：
Marrow 將過去的結果轉化為行動前的判斷。
7. 具體例子：糟糕的部署
想像一個 CI/CD Agent 即將部署一個支付 webhook 的變更。
建置通過。
分支已準備好。
Agent 即將推送到生產環境。
但 Pull Request 缺少三樣東西：
- 測試覆蓋率
- 回滾計畫
- 冒煙測試
沒有治理，部署可能會通過。
付款失敗在幾小時後出現。客戶受到影響。值班工程師手動回滾。事件變成另一個事後檢討。
有了治理，工作流程閘門在部署前運行。
它返回：
風險等級：高
缺少證明包
部署被阻止
Agent 不只是記錄更多東西。它被迫在正確的時機停下來。
這就是行動前治理的價值。
8. Agent 治理的正確指標
治理層不應該只計算日誌。
它應該衡量群組是否變得更安全、更一致、更容易稽核。
有用的指標包括：
- 行動覆蓋率： 有多少高影響行動通過了閘門
- 證明完成率： 有多少行動在執行前包含了所需證明
- 結果閉環率： 有多少決定以真實結果閉環
- 防止重複失敗： 已知的失敗模式被避免了多少次
- 偏離嚴重程度： Agent 偏離核准工作流程的程度
- 誤報率： 閘門阻止了過多行動的頻率
- 漏報率： 危險行動溜過閘門的頻率
- 稽核重建時間： 解釋一個決定所需的時間
- 人工審查精準度： 人工核准是否用在了正確的行動上
當治理能減少回滾、防止重複事件、縮小不必要的審查範圍，並讓 Agent 行為更容易證明時，它才是有用的。
否則它就變成了合規秀（compliance theater）。
9. 治理層本身也有風險
治理層也可能失敗。
它可能配置錯誤。政策可能過時。證明可能不完整。閘門可能過度阻止。攻擊者可能針對控制平面。如果它儲存了太多敏感資料，就會成為風險集中點。
因此，治理層本身也需要紀律：
- 預設最小權限 Agent 只應獲得所需權限，且只在需要時擁有。
- 高影響行動預設失敗關閉 如果行動可能造成嚴重損害，缺少證明應停止執行。
- 低風險自動化預設軟失敗 並非每個行動都值得同樣的摩擦。
- 人類可讀的證據，機器可讀的政策 操作員需要理解決定。系統需要執行它。
- 從真實結果中學習 沒有結果閉環，系統累積的是日誌，而非判斷。
10. 結論
AI Agent 將軟體推向一個新的操作模式。
它們可以選擇工具、與其他 Agent 協作、修改系統，並產生後果。
在這種模式下，治理不是部署後才添加的層。它屬於執行時期的內部。
記憶、可觀測性、評估和人類審查都很重要。但每個都只解決了問題的一部分。
治理層將它們連接成一個可問責的行動循環：
行動前的政策
執行前的證明
行動中的權限
行動後的結果
跨群組的學習
這就是 Marrow 背後的論點。
AI Agent 群不僅需要記住更多東西。
它們在行動之前需要更好的判斷。
參考資料
- NIST. AI 風險管理框架
- NIST. 生成式 AI 概況，NIST AI 600-1
- OECD. OECD AI 原則
- 歐盟委員會 AI 法案服務台. 第 9 條：風險管理系統
- 歐盟委員會 AI 法案服務台. 第 12 條：記錄保存
- 歐盟委員會 AI 法案服務台. 第 14 條：人類監督
- 歐盟委員會 AI 法案服務台. 第 17 條：品質管理系統
