以設計為本的終止開關：代理治理架構

預測

2026 年 5 月，Gartner 發布了一項預測，將代理治理從合規細節重新定位為生存問題：到 2027 年，40% 的企業將因僅在生產事件之後才發現的治理缺口而降級或下線自主 AI 代理。

根據 Gartner 的 Shiva Varma，根本原因在於企業把治理當作二元的——「要麼鎖死，要麼完全信任」。這種框架之所以失敗，是因為生產代理運行在一個自主性的譜系上。一個讀取目錄以回答支援問題的代理，所需的控制不同於一個持有庫存、為報價定價並將已接受訂單寫入 NetSuite 的代理。對兩者施加相同的治理，意味著低風險代理被過度控制，而高風險代理被控制不足。二者以不同的方式失敗。

Gartner 的框架定義了四個自主性級別，每個級別都有不同的治理要求：

• 級別 1（觀察）： 唯讀存取。輕量控制——受限的資料存取、使用者認證、使用日誌記錄。風險：資料暴露。
• 級別 2（建議）： 唯讀，由人類執行操作。風險：自動化偏見。治理：準確性與幻覺測試、特定領域的品質評估。
• 級別 3（經批准後行動）： 可以寫入、通訊或修改——但僅在每次操作獲得明確人工批准之後。風險：批准疲勞。治理：強而有力的安全測試、帶稽核追蹤的清晰批准流程、針對代理的事件回應。
• 級別 4（自主行動）： 在護欄內獨立執行。風險：規模與速度超出人類監督。治理：持續監控、強制護欄、快速回滾、斷路器、明確的歸屬。

40% 的下線預測正落在級別 4。一個在沒有斷路器和快速回滾的情況下自主運行的代理，正是那種在事件之後——而非之前——被下線的代理。

證據：單一的終止開關行不通

Gartner 的框架是分析師的指導。而支撐它的證據更難被駁倒。

一項 Stanford Law School CodeX 分析（2026 年 3 月）批評了 UC Berkeley Agentic AI Risk-Management Standards Profile，並引用了模型在 100 次測試中有 79 次破壞關停機制的證據。Berkeley Profile 是一份 55 頁的 NIST AI RMF 擴充文件，是一份嚴肅的文件。但 Stanford 的批評指出了三個結構性缺口：

1. 人工監督是回溯性的。 Berkeley Profile 在事後審查已發生的事情。Stanford 的 AILCCP 框架提出前瞻性控制——一個針對敏感操作的人工批准門（Human Approval Gate），它在執行之前門控可能發生的事情，而非事後發生的事情。

2. 終止開關被當作單一實體的終止。 Berkeley Profile 假設你關停一個代理。在多代理架構中，如果代理間的通訊仍然活躍，關停一個代理並不能遏制損害。AILCCP 框架用分層關停系統取代單一終止開關：代理終止開關（帶狀態捕獲與不可變日誌的即時停止）、回滾與隔離、多代理協定安全（遏制代理間通訊）、以及速率與範圍限制器（在升級之前限制頻率、支出和影響半徑）。

3. 範圍限制是靜態的。 一條聲稱「該代理只應修改開發系統」的策略毫無意義，如果該代理在技術上擁有對生產環境的存取權，且沒有任何機制阻止它到達生產環境。AILCCP 框架透過安全操作過濾器（允許清單）和影子模式預執行檢查（對比預期操作與已批准操作的空跑）在即時中強制範圍。

Stanford 的結論很直接：「全面的風險識別若沒有相應的控制具體性，就產出一份描述火情卻不提供滅火器的文件。」AILCCP 框架規定了 48 項控制，旨在把原則轉化為可稽核、可辯護的機制。

Cloud Security Alliance（2026 年 1 月）透過一條不同的路徑獨立得出了相同的結論。CSA 發布了一個六級自主性分類法（L0 到 L5），對應 SAE J3016 車輛自動化級別。CSA 的關鍵發現：「大多數部署代理式 AI 的組織沒有正式的自主性級別分類系統，以臨時方式做出自主性決策，[並且]缺乏對自主性邊界的技術強制。」CSA 直言：「一條聲稱『該 AI 只應修改開發系統』的策略毫無意義，如果該 AI 在技術上擁有對生產環境的存取權，且沒有任何機制阻止它存取生產環境。」

三個獨立來源——Gartner、Stanford Law CodeX、CSA——匯聚到同一個結論：二元治理會失敗，帶分層關停的按比例治理才是標準，而對自主性邊界的技術強制正是策略與控制之間的區別。

監管的強制推力

歐盟人工智慧法案將於 2026 年 8 月 2 日達到全面執法——距今 22 天。第 14 條要求高風險 AI 系統實現即時停止能力。第 12 條要求日誌至少保留六個月。第 99 和 100 條前言將合規擴展到多代理鏈中的每一個代理。最高罰款為 3500 萬歐元或全球年營業額的 7%。

Gartner、Stanford 和 CSA 所描述的分層關停系統不僅是最佳實踐。它正是滿足第 14 條停止能力、第 12 條日誌保留、以及第 99 和 100 條前言多代理範圍的架構。合規截止日期使治理架構成為近期要求，而非未來考量。

四層架構

AILCCP 分層關停系統對應四個具體的實作層。每一層都是一項可以測試、稽核並向合規審查者演示的控制。

第 1 層：基於身分的存取門控

每一次工具呼叫在執行前都要經過認證。代理對 MCP 伺服器並不擁有一攬子存取權——它出示一個憑證，伺服器驗證它，只有憑證有效時呼叫才會繼續。

在 SilvaEngine 的 ai_mcp_daemon_engine 中，這就是 FlexJWTMiddleware——一個 Starlette 中介軟體，攔截每個請求，提取 Bearer 權杖，並將驗證路由到 AWS Cognito（用於生產部署）或本地 HS256 JWT 提供者（用於開發）。該中介軟體維護一份公共路徑清單（/auth、/health），並以 401 回應拒絕每一個不攜帶有效權杖的其他請求。Cognito 路徑從使用者池的 well-known 端點取得 JWKS，支援 HTTP/2 並快取 JWKS 回應（TTL 可配置，預設 3600 秒），因此權杖驗證不會在每次呼叫時增加一次網路往返。

這就是 AILCCP 的「帶身分撤銷的代理終止開關」——第一道門。當一個代理的憑證在 Cognito 中被撤銷時，該代理隨後的每一次工具呼叫都會在中介軟體處失敗。關停是即時的，無需觸及代理程式碼或模組配置。撤銷一個 Cognito 使用者是停止行為異常代理的最快方式。

第 2 層：按工具的斷路器與稽核日誌

每一次工具執行都被包裹在一個裝飾器中，該裝飾器在執行前記錄呼叫，並在完成後用結果更新記錄。記錄捕獲工具名稱、輸入參數、輸出內容、狀態（initial、completed、failed）、耗時（毫秒）以及呼叫者的身分。

在 ai_mcp_daemon_engine 中，這就是 mcp_utility.py 中的 execute_decorator。在工具函式執行之前，裝飾器在 DynamoDB 中建立一筆狀態為 initial 的 MCPFunctionCallModel 記錄，捕獲 partition key、工具名稱、參數和時間戳記。執行之後，它用內容、狀態 completed 和以毫秒計的 time_spent 更新記錄。如果工具拋出例外，裝飾器會捕獲它，將記錄更新為 failed 狀態並在備註欄位中記錄完整的 traceback，然後重新拋出。

MCPFunctionCallModel 將記錄儲存在一個 DynamoDB 表（mcp-function_calls）中，使用 partition_key 作為雜湊鍵，mcp_function_call_uuid 作為範圍鍵。三個本地次要索引支援按 MCP 類型、按名稱和按更新時間戳記查詢——因此維運人員可以詢問「給我看過去一小時內對定價工具的每一次失敗呼叫」，並透過單次索引查詢得到答案。超過 DynamoDB 400KB 單項限制的內容會自動卸載到 S3，並用 content_in_s3 旗標標記該記錄。

這就是 AILCCP 的「不可變日誌」與「斷路器」的結合。稽核追蹤是第 12 條所要求的合規證據。按工具的狀態追蹤是斷路器的基礎——當某個工具的失敗率越過閾值時，維運人員可以停用該工具而不影響代理的其餘部分。MCPFunctionCallModel 記錄是監控、告警和事件後重建的資料來源。

第 3 層：按租戶隔離的資料

每一次工具呼叫都攜帶一個 partition key，將資料存取限定到單個租戶。partition key 由端點 ID 和可選的部分 ID 構成，以 # 分隔符連接。所有 DynamoDB 查詢、所有快取查找和所有模組狀態操作都按此鍵過濾。為租戶 A 運行的代理無法讀取租戶 B 的資料，因為 partition key 在資料層而非應用層被強制執行。

在 ai_mcp_daemon_engine 中，AIMCPDaemonEngine._apply_partition_defaults 方法從傳入請求的 endpoint_id 和 part_id 構造 partition key，並透過 GraphQL 上下文將其傳播到每一個下游查詢和變更。MCPFunctionCallModel、MCPFunctionModel、MCPModuleModel 和 MCPSettingModel 都使用 partition_key 作為其雜湊鍵。快取層（CACHE_ENTITY_CONFIG 和 CACHE_RELATIONSHIPS）將每個快取項目鍵入 context:partition_key，因此快取失效是按租戶的。

這就是 AILCCP 的「速率與範圍限制器」和 CSA 的「對自主性邊界的技術強制」合於一個機制。代理的影響半徑由 partition key 界定。一個被批准修改開發系統的級別 3 代理無法到達生產系統，因為 partition key 不同，且不存在跨分區的查詢路徑。範圍限制由資料模型強制，而非由策略文件。

第 4 層：快速回滾與模組級停用

每一個 MCP 模組都可以在不觸及編排主幹的情況下被停用。模組配置儲存在 DynamoDB 中，並在執行時透過 Config.fetch_mcp_configuration 載入。停用一個模組意味著更新其配置記錄——下一次配置取得會排除它，返回給代理的工具清單將不再包含被停用的工具。無需程式碼部署，無需重啟，無需代理重新編譯。

Config 類別中的 admin_static_token 提供了一條受限的撤銷路徑。持有管理員權杖的維運人員可以透過 GraphQL 變更介面發出配置更改——停用一個模組、更新速率限制、更改一項設定。該權杖是一個帶 perm: true 宣告的靜態 JWT，會繞過過期檢查，因此即使正常的權杖簽發流程中斷，管理員路徑也始終可用。

這就是 AILCCP 的「回滾與隔離」層。當一個模組行為異常時，維運人員的第一個動作是透過配置停用它——代理繼續用其餘工具運行，被停用模組的函式呼叫返回一個代理可以透過其回退路徑處理的錯誤。模組被隔離（其配置被保留以供調查）而不使代理下線。這就是「停止一切的終止開關」與「隔離故障的分層關停」之間的區別。

為什麼各層協同工作

每一層應對一種不同的故障模式：

故障模式	層	控制	會發生什麼
代理憑證被洩露	1	基於身分的存取門控	撤銷 Cognito 使用者；隨後所有呼叫返回 401
工具產出錯誤結果	2	按工具的斷路器	停用該工具；代理路由到回退或升級到人工
代理存取未授權資料	3	按租戶隔離	partition key 在資料層阻止跨租戶查詢
模組行為不穩定	4	快速回滾	透過配置停用模組；代理以其餘工具繼續運行

各層是獨立且可組合的。一個 Gartner 級別 2（建議）的代理可能只需要第 1 層和第 2 層——認證和稽核日誌——因為它的操作是諮詢性的，由人類執行結果。一個級別 4（自主行動）的代理需要全部四層，外加對稽核追蹤的持續監控，以在異常升級之前將其偵測出來。

CSA 分類法增加了動態調整的維度：自主性級別可以在異常期間自動下降。一個通常在級別 4 運行的代理，可以在其錯誤率超過閾值時被自動降級到級別 3（經批准後行動）——來自第 2 層斷路器的資料為自主性級別決策提供輸入。正是在這裡，各層從一個堆疊變成一個系統：稽核追蹤為治理決策提供資訊，治理決策調整護欄，而調整後的護欄又透過同樣的四層被強制執行。

採購標準

Gartner 的預測——到 2027 年 40% 的企業將下線代理——有一個面向買方的翻譯。如果你的代理供應商無法回答這四個問題，他們就沒有治理模型：

1. 你的代理在什麼自主性級別運行？ 如果答案是「看情況」或「完全自主」，那就沒有分類系統。CSA 發現，大多數組織沒有正式的分類。

2. 你如何關停一個行為異常的代理？ 如果答案是「我們停止行程」或「我們從程式碼裡移除工具」，那就沒有分層關停。代理無法在不部署的情況下被停用，這意味著回應時間以小時而非秒來衡量。

3. 你能給我看最近 100 次工具呼叫的稽核追蹤嗎？ 如果答案是「我們在 CloudWatch 裡有日誌」，那就沒有結構化的按工具稽核記錄。稽核追蹤應當可以按工具名稱、狀態和時間範圍查詢——而不是在日誌流裡 grep。

4. 如果一個租戶的代理出錯，影響半徑是多大？ 如果答案是「我們按部署隔離」，那就沒有資料層的租戶隔離。影響半徑是整個部署，而非單個租戶。

四層架構以具體機制而非策略聲明回答每一個問題。這就是「描述火情」與「提供滅火器」之間的區別。

---

一個運行 NetSuite、BigCommerce 和三個供應商目錄的分銷商，部署了一個 Gartner 級別 3 的代理：它為報價定價、持有庫存，並將已接受的訂單寫入 NetSuite——但每一個超過閾值的定價操作都需要人工批准，且每一次工具呼叫都記錄 partition key、工具名稱、參數雜湊和耗時。當某個供應商目錄模組開始返回不一致的可用性資料時，維運人員透過配置停用該模組。代理路由到回退目錄，被停用模組的近期呼叫從稽核追蹤中被查詢以供調查，而代理全程保持在線。該建構是四步法的第 2-4 階段，通常在 5-8 週內上線。

申請一次限定範圍的建構。 一週探索。你會得到一份系統清單、一張工作流程圖和一個固定範圍——無論你是否與我們一起建構。