第十一章
受治理的自主性

本章為最終書稿的第十一章。請注意，GitHub 儲存庫將於稍後正式啟用。
若您願意實際參與本草稿的審閱與意見回饋，請與編輯聯繫：jleonard@oreilly.com。

本書在營運上後果最深遠的一章，主張的是同一件事：治理，是自主性的作業系統。沒有治理，自主性只是無人監督的執行；有了治理，自主性就成了團隊能夠隨著證據累積而授予、衡量、收窄與撤回的東西。第 4.6 節那個架構性的「治理平面」，是本章要發展成一套執行期控制系統的基質。第 1.5 節那條「自主性邊界」，是這套系統依設計就會遵守的工程化介面。本章要安裝的，是把架構原語連結到「一位 SRE 每天實際運行一套代理式系統」這件事的營運紀律。

這是本書最「星期一早上」的一章，意思是：一位 SRE 對一套生產環境代理式系統實際會去改動的東西，大部分都住在這裡。第四章那四個平面，是團隊一次性做出的穩定架構承諾。五大旗艦 SLO，被持續追蹤，卻很少調整。第二部的工作流程，運行在這套架構之上，不需要每一輪班重新設定。治理不一樣。授權層級每週調整，動態護欄每小時重新校準，覆寫率訊號每天審查，緊急分流（Emergency Shunt）每月演練。治理層，正是架構與「運行它的團隊的營運現實」相遇的地方，而營運現實改變的速度，比架構快得多。

一開始就值得安裝的框架是：治理，不是自主性原本要移除的那種官僚。一支在沒有治理的情況下採用代理式可靠性的團隊，並沒有移除官僚，他們移除的，是那套官僚（無論多不完美）原本正在提供的安全網。舊制度裡的人工核准關卡、變更審議委員會、人在迴圈中的檢查點之所以存在，是因為某個人在某個地方判斷過：某幾類行動值得明確的人類注意力。在不打造任何替代品的情況下拆掉那些關卡，換來的是更快的決策與更糟的結果。治理，就是那個被工程化的替代品：一個執行期的層，決定哪幾類行動值得哪種注意力，而且以架構能自動強制執行的形式表達。官僚不見了，它原本試圖強制的那份紀律留了下來，如今被表達為架構依設計就會遵守的政策。

另一個值得安裝的框架是：被妥善工程化的治理，會「加速」而不是拖慢自主運作。一支沒有治理的團隊，必須把每一次行動都當成潛在危險的，因為沒有任何結構性承諾能把「安全而例行」和「有風險而新奇」區分開。一支擁有工程化治理的團隊，則有幾個帶：架構自主執行的例行行動帶、架構帶稽核執行的中度風險帶，以及架構只提議、需要人類核准才執行的高風險帶。這些帶本身就是政策，依證據重新校準，而政策，正是讓架構能在例行工作上跑得快、卻不在高風險工作上妥協的原因。本章之所以在營運上後果深遠，不是因為治理增加了摩擦，而是因為「在對的地方擁有對的摩擦」，正是讓這套架構其餘部分變得可行的原因。接下來十一節，要發展的就是產出這種摩擦的基質。

值得先點名的成熟度進程是：本章要發展的治理紀律，正是第 4.9 節成熟度模型裡把 L3 與 L4 區分開的東西。L2 團隊有基本的政策強制執行；L3 團隊有回應當前證據的動態護欄；L4 團隊則有完整的「治理即學習」迴圈持續運行，覆寫率遙測以月為週期餵養政策精煉。L5 團隊在此之上，還有把治理當成產品的結構性承諾：政策介面本身被版本化、被測試、像程式碼變更一樣帶金絲雀階段與驗證地推出。大多數讀這本書的團隊會落在 L2 或 L3 早期，而本章的結構，正是為了讓 L3 到 L4 的轉換變得可處理而設計的。本章很長，是因為這次轉換後果重大；一支帶著 L2 治理習慣運行的 L3 團隊，會發現第三部其餘的機制在營運上很難部署。治理是讓其餘部分變得可行的基質，而基質必須先到位，上層工作才會回本。

11.1　意圖表達與政策介面

第 1.4 節把「意圖」命名為捕捉「團隊想達成什麼」的架構原語。那個層次的意圖，是價值的陳述：這項服務不得遺失資料、這個 SLO 必須在尖峰流量期間被守住、這一類行動絕不能在每週維護窗口期間運行。這些是團隊在對話裡能清楚說出的陳述，卻不是架構能直接據以行動的陳述。在意圖與執行期行動之間，存在一個本節要正式安裝的轉譯層：政策介面（policy surface）。

政策介面，是意圖的結構化表示，其形式是架構在每一次決策時都能讀取的。從意圖到政策介面的轉譯，是團隊的責任（它無法被自動化，因為團隊的價值觀對架構而言是不可見的），而產出的產物是被版本化、可審查、被審慎變更的。政策介面之於意圖，就像服務水準目標之於服務水準協議：底層承諾的營運性表達，其形式是執行期能自動遵守的。一支沒有寫下政策介面的團隊，只是非正式地表達了意圖，而非正式的意圖，撐不過與生產環境決策的接觸。

政策介面有三個值得點名的結構層。「行動限制」：關於哪幾類行動可以在什麼條件下、對照什麼授權層級運行的規則。一條行動限制宣告「對第一級服務的部署，在上班時間需要 T2 授權，在非上班時間需要 T1 授權」；架構在評估時就遵守這條限制，不需要重新推導。「信心門檻」：關於每一類行動需要多少架構信心才能繼續的規則，對照第 9.4 節的校準資料計算。一條信心門檻宣告「這一類行動需要 0.70 以上的信心才能自主觸發，低於此則只建議而不執行」；門檻是按行動類別、按層級設定的，並隨著校準資料累積而持續重新校準。「升級規則」：即使某個行動符合自主資格，仍然要升級給人類的條件，通常是因為行動類別本身沒有捕捉到的情境因素：事故進行中的旗標、事後檢討窗口標記、變更凍結宣告、待命交接期間。

把一個被妥善工程化的政策介面與一個不良的區分開來的紀律，是「可評估性」。每一條政策，都必須能在確定性時間內、對照當前的架構狀態被評估。一條要求架構去推理自己推理的政策，會產出無界的評估循環，在政策審查時就會被駁回。一條依賴外部系統才能評估的政策，會在那些系統不可用時產出脆弱的決策，除非那個依賴本身就是架構訊號基質的一部分，否則同樣被駁回。政策介面被工程化的方式，和任何其他生產環境介面一樣：宣告輸入契約、有界的評估延遲，以及對降級狀態的明確處理。做對這件事的團隊，會發現他們的政策介面在程式碼上很小、在營運影響上很大；做錯的團隊，會發現政策介面要嘛無界成長（每一個新的邊緣案例就加一條新規則），要嘛無法強制它原本要捕捉的意圖。

為了把這件事具體化，以下是第二部各標準情境裡那個支付服務的一段政策介面片段：

policy_band: payment_service.config_changes
intent_provenance: "tier-1 service, regulatory exposure (PCI-DSS),
                    on-call cost of error is high"
action_constraints:
  eligible_action_classes: [retry_policy_update, rate_limit_update,
                            feature_flag_toggle, timeout_adjustment]
  excluded_action_classes: [schema_migration, encryption_key_rotation]
  blast_radius_max: regional
confidence_thresholds:
  autonomous_execution: 0.78
  suggest_only:         0.55
  no_action:            below 0.55
escalation_rules:
  - during_postmortem_window: thresholds × 1.3
  - during_change_freeze:     suggest_only_max
  - if_recent_incident_in_same_class: require_human_approval
audit_requirements:
  why_trace: mandatory
  retention: 18 months
  review_cadence: monthly sample of T2+ decisions

policy_band: payment_service.scale_operations
intent_provenance: "infrastructure operation, low regulatory exposure"
action_constraints:
  eligible_action_classes: [scale_out, scale_in, regional_rebalance]
  blast_radius_max: cross-regional
confidence_thresholds:
  autonomous_execution: 0.70
  suggest_only:         0.50
escalation_rules:
  - if_recent_capacity_incident: confidence_thresholds × 1.2
  - if_cost_impact_above_threshold: require_human_approval

同一項服務的兩個政策帶，有不同的限制、不同的門檻、不同的升級規則。兩者都是架構在每一次相關決策時讀取的政策產物。兩者都不是隱含的；團隊是審慎地把它們寫下來，作為服務擁有者所表達意圖的營運性表達。架構把兩者都當成執行期契約來遵守，而任一政策帶，都能透過治理審查週期（第 11.8 節）依證據調整。

值得點名的、與這套架構其餘部分的連結是：政策介面是治理平面在「每一次」決策時消費的，不只是在高風險決策時。架構在候選行動集正在被評估的那一刻，讀取相關的政策帶；如果沒有任何政策帶匹配被提議的行動類別，這個行動就不會觸發，無論推理平面的信心有多高。這種「預設拒絕」的姿態，正是讓政策介面成為承重元件的原因：一條缺席的政策，不是一條寬容的政策。剛接觸工程化治理的團隊，有時會把政策介面設計成疊在寬容預設之上的一組例外規則；架構上的答案正好相反。預設是「不採取自主行動」；政策，是對自主權限的明確授予，範圍限定在團隊已經主動考慮過的行動類別與條件之內。這正是「團隊掌握控制權」在營運上的意義：這套架構只在團隊明確說可以的地方行動。

11.2　動態護欄

第十一章裡在營運上最重要的單一概念，是「動態護欄」（dynamic guardrail）。動態護欄，是一條嚴格程度會隨架構當前狀態而變化的政策限制：當校準資料暗示應該謹慎時收緊，當同一批資料支持信心時放鬆，並隨著證據累積而持續調整。靜態護欄，是前代理時代繼承下來的基質：那些說「這個行動需要人工核准」的規則，無論過去一季那次核准有多常只是橡皮圖章，都不會有任何彈性。動態護欄，是為代理時代工程化的：那些說「這個行動在這些校準條件成立時需要人工核准，否則就自主運行」的規則。從靜態到動態的轉變，正是讓工程化治理值得那份工程投資的原因。

機制在概念上很直接。一條動態護欄，由架構本來就在維護的訊號參數化：相關分箱裡的校準誤差（9.4）、覆寫率趨勢（11.5）、近期事故旗標、事後檢討窗口旗標、部署新鮮度、待命交接接近度。每一條護欄都宣告自己消費哪些訊號，以及那些訊號如何調節它的嚴格程度。一條典型的護欄規則：「對第一級服務的設定變更，在（70–80% 分箱的 CE > 0.15）或（7 日覆寫率 > 0.20）或（事後檢討窗口啟用中）時需要人工核准；否則在行動契約邊界內自主執行。」這條護欄在每一次相關決策時評估這些條件；評估產出一個執行期嚴格度設定，由治理平面套用。這服務於一項值得點名的架構特質：治理不是一個對特定事故做出反應的事件驅動層，而是一個對照滾動證據調整嚴格度的持續控制迴圈。

把被妥善工程化的動態護欄與不良的區分開的架構特質，是「遲滯」（hysteresis）。一條在麻煩的第一個徵兆就收緊、在復原的第一個徵兆就立刻放鬆的護欄，會隨底層訊號噪音震盪，讓同一類行動在短時間窗口之間承受不一致的摩擦。被工程化的護欄，收緊得快（因為在真正的麻煩期間過度寬容的代價很高），放鬆得慢（因為過早放鬆的代價同樣很高，訊號需要時間確認復原是真的）。遲滯本身就是一個政策參數，由團隊設定，並隨時間依證據調整。剛接觸動態護欄的團隊，有時會把它們實作成當前訊號值的瞬時函數；這套架構跑一季的經驗通常會揭露這會產出太多震盪，團隊於是學會引入明確的遲滯。遲滯，正是把護欄與恆溫器區分開的東西：恆溫器可以震盪，護欄不行。

與動態護欄並列、值得一起點名的相關概念，是「摩擦梯度」。不同類別的行動，即使在同一個授權層級之內，也值得不同程度的摩擦。一次設定回滾，應該幾乎沒有摩擦（回滾慢的代價，是以使用者影響支付的）。一次部署晉升，應該帶中度摩擦（糟糕晉升的代價，是以長尾中斷支付的）。一次結構描述變更，應該帶相當可觀的摩擦（糟糕結構描述變更的代價，是以資料遺失支付的）。摩擦梯度，正是這套架構對這種分級結構的表達：每一類行動都有一個目標摩擦水準，而動態護欄依當前證據在那個目標附近調節。摩擦不是目的；「這一類行動在這些條件下的正確摩擦量」才是目的，而摩擦梯度捕捉的正是這個目標。

guardrail: payment_service.deploy_promotion
static_baseline:
  authority_tier_required: T2 (autonomous within action contract)
  confidence_threshold: 0.70
  blast_radius_max: regional
  contract_review: required for changes with CRS > 60
dynamic_modulators (current values from architecture state):
  ce_in_70_80_bin: 0.13 (within tolerance: < 0.15)
  override_rate_7d: 0.08 (within tolerance: < 0.20)
  postmortem_window_active: TRUE (incident 36h ago)
  postmortem_window_strictness: 1.3x baseline strictness
  deployment_freshness: last_deploy 8h ago (no recent activity)
  on_call_handover_proximity: 3h to next handover (within tolerance)
effective_runtime_strictness:
  authority_tier_required: T2 (unchanged)
  confidence_threshold: 0.70 × 1.3 = 0.91 (raised by postmortem modulator)
  blast_radius_max: regional (unchanged)
  contract_review: required for ALL changes during postmortem window
effect on current candidate action:
  proposed: deploy v2.4.1 to eu-west (CRS = 54)
  architecture confidence: 0.78
  threshold required: 0.91
  decision: ACTION_BLOCKED, escalate to human review
  rationale: postmortem window raised threshold above current confidence
  expected behaviour after window closes (in 12 hours):
    threshold returns to 0.70
    this deploy would proceed autonomously

同一個行動，在正常條件下是自主的，在事後檢討窗口期間則被升級。這條護欄正在做它該做的事：當團隊聲明的風險姿態說應該謹慎時收緊，當證據支持正常運作時放鬆。兩種結果都不是政策的預設值；兩者都是對當前證據的校準回應。

值得安裝的紀律是：動態護欄不是「可以任意工程化政策邏輯」的許可證。一條護欄必須能以團隊的政策 DSL 表達、能在確定性時間內評估，並可追溯回它所源自的意圖。放任動態護欄累積臨時邊緣案例的團隊，會發現政策介面變得無法檢視，架構的行為也變得難以預測。架構上的防禦，是要求每一條新護欄都必須對照與任何其他生產環境變更相同的治理紀律接受審查：宣告、審查、版本化、監控。動態的部分在於護欄在執行期的「評估」，而不在於團隊隨機發明新護欄的自由。

動態護欄的營運節奏值得點名。剛接觸工程化治理的團隊，常期待護欄可以設定完就忘；運行成熟系統的團隊，會發現護欄大約每月調校一次，調校的依據是前一個月的校準資料與覆寫率趨勢。這個月度週期本身就是一項政策決策，不是隨意的。更快的週期（每週）會對照訊號噪音產出太多震盪；更慢的週期（每季）則會讓架構對照過時參數運作太久，在營運變動期間（新服務、新代理、新基質）尤其如此。月度節奏，是大多數團隊在運行第一年內會收斂到的，而這種收斂本身，就是這個週期落在正確範圍的證據。運作在異常波動環境裡的團隊可能每週調校，運作在非常穩定系統上的團隊可能每季調校；團隊第一年的實證經驗，正是把週期校準到自身實際營運脈絡的東西。

值得點名的、與本章其餘部分的連結是：動態護欄是本章在營運上後果最深遠的原語。授權層級（11.4）很少重新校準；緊急分流（11.3）很少被啟動；晉升與降級機制（11.7）偶爾觸發；但動態護欄是持續調節的，在每一次相關決策時，對照架構的當前狀態。第 11.6 節裡團隊的日常治理工作之所以由護欄注意力主導，正是因為護欄是最直接把當前證據轉譯成當前行為的那一層。一支把動態護欄做對的團隊，擁有一套會對即時狀況做出適當回應的治理系統；一支做錯的團隊，則要嘛摩擦太多（過度限制的護欄），要嘛太少（限制不足的護欄），而代價會在接下來幾週裡，顯現在其他治理訊號（OR、SAR、反模式指標）上。

11.3　緊急分流

每一套治理系統都需要一條快速路徑，處理「團隊需要立刻介入」的情況。「緊急分流」（Emergency Shunt），是人類可以在不走一般政策更新流程的情況下，立即把系統降級到較低自主層級（或降到僅建議模式）的執行期機制。它之所以存在，是因為總會有一些情況，團隊對架構當前自主性的信心下降的速度，比政策更新流程能反應的速度更快：一個結構上新奇的事故模式、一次令人意外的校準漂移、一項非架構性的顧慮（法規、資安、業務）。緊急分流，正是「我們需要現在就把控制權拿回來」在架構上的答案。

值得安裝的框架，是緊急分流「不是」什麼。它不是一個中止開關。中止開關讓架構停止；緊急分流讓它降級。這個區別很重要，因為緊急狀況下的架構狀態，很少是「系統必須什麼都不做」，而是「系統只能做人類明確核准的事」。中止開關產出第一種狀態；緊急分流產出第二種。系統繼續觀測、推理，並產出候選行動；改變的是，那些行動都不會自主執行。團隊在直接接管行動選擇的同時，保留了架構全部的情境覺知。這正是「停止自主性」與「在完整可見性下暫停自主性」之間的營運差異，而第二種幾乎總是情況真正需要的。

機制有三個組成部分。「觸發」：緊急分流可由任何具備相關範圍的待命工程師啟動，並在稽核軌跡中記錄一段簡短的理由。理由是必要的，因為分流會在事後被審查；但它要求的最低長度很短，以免在團隊需要行動的那一刻增加摩擦。「效果」：架構在受影響範圍內的有效授權層級，降到 T0（僅建議）或 T1（在收緊邊界內預先授權），目標層級在觸發時指定。原本符合自主執行資格的行動契約，現在需要人類核准；建議仍在流動，架構仍在推理，但執行被閘控了。「復原」：分流有一條明確的復原路徑。觸發它的待命工程師（或指定的接手者）在立即顧慮過去之後重新評估條件，透過一套結構化的復原流程把架構恢復到正常授權層級，稽核軌跡則同時記錄觸發與復原。復原之所以要結構化，是因為一次未被復原的分流本身就是一種失效模式：架構永遠停在 T0，只因為沒有人抽空把它恢復。

值得安裝的紀律是：緊急分流要定期演練。一個從來沒有在真實情況下被啟動過的控制，是一個在時刻來臨時沒人知道怎麼啟動的控制。團隊的營運實務，應該包含排定的分流演練（第一級服務至少每季一次），由待命工程師對照一個指定的測試範圍觸發分流，驗證架構的行為符合政策，並實際操作復原流程。演練會產出團隊可以審查與稽核的結構化證據。一支從未演練過分流的團隊，可能會在真正緊急的那一刻發現，分流被記載的行為與它實際的行為已經漂離。演練很便宜，替代方案很貴。

以下是一次在真實（非演練）情況下觸發的分流實例，來自一支在非預期的定價引擎整合問題期間運行支付平台的團隊：

shunt_id: SHUNT-2026-04-09-08:42:11-001
trigger:
  operator: on_call_engineer_jdoe
  scope: payment_service.all_action_classes
  target_tier: T1
  justification: "External pricing-engine returning unexpected
                  values for the last 20 minutes. The architecture
                  has flagged no anomaly because the pricing-engine
                  is upstream of our signal pipelines. Demoting
                  until we understand the impact."
immediate_effects:
  all_autonomous_actions: paused
  in_flight_actions: completed (5 deploys finished within 90s)
  pending_actions: suggest_only (queued for human dispatch)
  candidate_action_sets: continue to be produced (visibility preserved)
  PRSs: continue to emerge (situational awareness intact)
  Why_Traces: continue to be produced (no audit gap)
duration:
  triggered: 08:42:11
  investigation_window: 08:42:11 to 11:15:00
  restoration_initiated: 11:15:00
  full_restoration: 11:21:00 (graduated re-promotion)
audit_record:
  decisions_during_shunt: 47 total
    - 28 suggested actions, all dispatched by humans
    - 19 candidate action sets surfaced but not acted on
  no actions executed autonomously during window
  restoration evidence: pricing-engine issue resolved upstream,
                        no continuing impact on payment_service signals
  governance_review_scheduled: next Wednesday's standup

分流做到了它被設計要做的事。團隊全程保留了架構的情境覺知：他們依然看得見候選行動、PRS、為何軌跡（Why Trace），但沒有任何行動在沒有人類明確派發的情況下執行。這 2.5 小時的窗口，讓團隊在例行工作上稍微變慢；替代方案（在上游資料可能失準的情況下繼續自主執行）的代價，則會是生產環境事故。

值得點名的架構特質是：分流不會產出稽核缺口。架構在分流窗口期間做的每一個決策都在稽核軌跡裡，包括人類派發的決策，以及人類選擇不派發的決策。這種連續性，正是讓團隊事後能夠審查這段分流期間並從中學習的原因——既學到架構當時在建議什麼（團隊可以拿它對照自己實際做了什麼），也學到團隊自己在緊繃情況下的營運紀律。一段能為架構與團隊雙方都產出教訓的分流窗口，才是完整發揮營運目的的分流。

11.4　授權層級與人類控制迴路

「授權層級」這個詞已經橫跨第五、六、七、八與十一章被引用，卻沒有被正式定義。這套詞彙一直是營運性的、而非嚴謹的：T1、T2、T3，靠上下文讓它們的直覺意義夠清楚。本節要安裝正式的處理。一個授權層級，是一個被標記的行動範圍，這套架構被允許在特定條件下、帶著特定回報與核准要求，對某一類特定操作執行它。標籤在整套架構裡是穩定的（同一個 T2 對事故應變與對交付而言意義相同）；行動類別到層級的「綁定」，則因團隊、因服務、因時間、因當前證據而異。

標準的層級階梯有四個位置。「T0（僅建議）」：架構產出候選行動，附上信心與溯源，把建議呈現給人類，但不執行任何東西。每一個行動都需要人類明確派發。T0 是新代理類別的預設值，是團隊尚未授權自主執行的行動類別的預設值，也是校準退步後那段期間的預設值。「T1（在邊界內預先授權）」：架構可以執行那些契約完全落在團隊定義邊界之內的行動：爆炸半徑低於門檻、行動類別明確列在政策裡、信心高於聲明的最低值。超出邊界的行動升級給人類。「T2（在爆炸半徑內自主）」：架構可以自主執行該行動，只受執行期信心與溯源檢查的約束；人類透過稽核軌跡被告知，但不閘控執行。T2 是成熟代理類別執行例行工作時的典型運作層級。「T3（自主並帶稽核）」：架構可以自主執行該行動，稽核軌跡是唯一對人類可見的產物；T3 保留給那些歷史證明可靠性極高的行動類別，通常需要跨越多個季度的運作、極低的覆寫率，以及校準良好的信心。

值得點名的架構特質是：層級是「按行動類別」的，不是「按代理」的。同一個代理可以在一個行動類別上握有 T3 授權，在另一個上握有 T0 授權。容量代理可能在第一級服務的擴容行動上是 T3（因為該行動類別例行、校準極佳），在遷移行動上是 T0（因為該行動類別罕見，架構尚未累積足夠校準資料來授予更高層級）。這種按行動類別的粒度，正是讓層級系統可運作的原因：團隊在證據支持的帶裡授予自主性，在證據不足的帶裡保留它。一支把層級當成代理層級排名的團隊，會發現層級系統經常與底層證據不匹配，由此產生的授權綁定要嘛太過限制（阻礙代理去做它已經贏得的行動），要嘛太過寬容（在證據不支持的行動上授予權限）。

層級綁定是持續重新校準的。學習代理在滾動窗口上的資料，會告訴團隊綁定是否符合證據；治理平面則週期性地提議綁定調整（典型如：把行動類別 X 從 T1 晉升到 T2，因為校準已連續兩季改善；把行動類別 Y 從 T2 降級到 T1，因為覆寫率在過去一個月上升）。提案由人類審查、接受或修改，並透過政策更新流程套用。第 11.7 節會正式展開晉升與降級機制；就本節而言，重點是：層級「系統」是穩定的，而層級「綁定」是動態的。系統的穩定，給了團隊一套固定的詞彙；綁定的動態，給了團隊對「系統被允許做什麼」的證據驅動控制。

與第 4.7 節「人在迴圈中」模式的連結值得精確點名。4.7 節那四種 HITL 模式（在迴圈中、在迴圈上、在迴圈之上、在迴圈之外），描述的是人類與架構決策之間的關係。本節那四個授權層級，描述的是架構與行動執行之間的關係。這是兩個不同的軸。人類可以對 T1 行動處於「在迴圈上」（看著架構在預先授權邊界內執行，只在例外時介入），對 T3 行動處於「在迴圈之外」（稽核軌跡是唯一產物），對 T0 行動處於「在迴圈中」（每一個行動都等待明確派發）。這兩軸的組合，產出一個第 4.7 節在架構層次命名、而本章在政策層次具體化的豐富運作模型。剛接觸這套框架的團隊，有時會把兩軸混為一談；架構上的答案是把它們當成獨立的，並讓政策介面為每一類行動明確表達這個組合。

以下是一支運作在 L4 成熟度的團隊，其容量代理橫跨各行動類別的授權綁定的具體樣貌：

agent: capacity_agent
service_scope: payment_service
action_class_bindings:
  scale_out (replicas, eu-west):
    tier: T3 (autonomous with audit)
    basis: 18 months of cleanly-calibrated operation, CE = 0.04 in
           relevant bin, override rate 0.02, no incidents
  scale_in (replicas, eu-west):
    tier: T2 (autonomous within blast radius)
    basis: cleaner downside than scale_out but cost-impact requires
           audit attention; team has elected T2 over T3
  cross_region_traffic_shift (<= 20%):
    tier: T2 (autonomous within blast radius)
    basis: pre-approved pattern from Ch 8.4+8.5; tier matches the
           blast-radius tolerance
  cross_region_traffic_shift (20-50%):
    tier: T1 (preauthorised within bounds, requires audit dispatch)
    basis: larger blast radius warrants human dispatch even though
           calibration is comparable
  cross_region_traffic_shift (> 50%):
    tier: T0 (suggest only)
    basis: rare event, low evidence base, high blast radius
  instance_migration (cross-AZ):
    tier: T1 (preauthorised, narrow bounds)
    basis: requires audit dispatch; team has not yet accumulated
           evidence to justify T2
  instance_migration (cross-region):
    tier: T0 (suggest only)
    basis: very rare, never autonomously executed
  pricing_tier_adjustment:
    tier: T0 (suggest only)
    basis: business-rule action class, the team has elected to
           require human dispatch regardless of calibration

同一個容量代理，橫跨七個行動類別握有 T0、T1、T2 與 T3 授權。這些綁定，有些反映證據，有些反映業務偏好，有些則是在證據尚未累積時的保守預設。每一個綁定，都是團隊依自己的節奏審查與調整的政策產物。

11.5　覆寫率、建議接受率與信任遙測

信任不是二元的。團隊並不是「信任架構」或「不信任架構」；團隊是在某些時候、對某些行動類別、在某些證據水準上信任架構。團隊被校準過的信任位置本身是可衡量的，而兩個關鍵訊號是「覆寫率」（Override Rate，OR）與「建議接受率」（Suggestion Acceptance Rate，SAR）。兩者都在第 4.9 節的成熟度模型裡被引用過卻沒有正式定義；本節安裝正式的處理。

「覆寫率（OR）」，是在一個衡量窗口內，被人類覆寫的架構決策所佔的比例，包含執行前（行動是被建議而非自主的情況）與執行後（行動是自主的、人類事後逆轉或修改了結果）。OR 按行動類別、按授權層級計算：OR =（被覆寫的決策）/（做出的決策）。分子同時包含執行前覆寫（人類駁回了建議）與執行後逆轉（人類撤銷了架構所做的事）。分母是該窗口內做出的決策總數。典型目標值：第二級行動類別 OR < 0.05，第一級行動類別 OR < 0.10，OR < 0.20 則是觸發層級審查前的最大容忍值。

「建議接受率（SAR）」，是形狀相反的訊號：架構呈現給人類核准的建議（T0 或 T1 行動）中，人類接受並派發的比例。SAR 按行動類別計算：SAR =（被接受的建議）/（被呈現的建議）。高 SAR（0.90 以上）有時代表校準良好：架構穩定地建議了團隊本來也會選的行動；它也可能代表疲勞：團隊在沒有真正審查的情況下橡皮圖章式地放行建議。低 SAR（0.40 以下）代表架構在建議團隊不同意的行動，要嘛是校準偏了，要嘛是團隊的偏好已經從架構被調校的方向移開。兩個極端都有診斷價值；健康運作的架構目標，通常落在 0.65 到 0.85 之間。

值得點名的架構特質是：OR 與 SAR 在「兩個方向」上都是失效模式。0% 的 OR 是可疑的：要嘛團隊已經停止審查架構的行動（成熟度退步），要嘛團隊對架構的信心已經到達不被正當化的極端（一個團隊沒注意到的校準問題）。50% 的 OR 則因為顯而易見的理由而令人警覺：架構有一半時間是錯的。健康帶落在兩者之間，而健康帶的位置取決於行動類別。例行行動（低風險服務的部署晉升）應該有非常低的 OR；新奇行動（跨區域遷移、結構描述變更）在校準累積期間應該容忍較高的 OR。OR 的「趨勢」，往往比絕對水準更有診斷力：穩定在 0.08 的 OR 是成熟運作的徵兆；一季之內從 0.05 升到 0.12 的 OR，則是漂移的徵兆，可能代表校準退步，或是架構尚未吸收的營運脈絡變化。

與第 9.4 節校準機制的連結值得點名。OR 與 SAR 是結果端的信任訊號；CE 是預測端的信任訊號。一套校準良好的架構，產出的決策其聲明信心與結果相符；一套被信任的架構，產出的決策人類會接受且不覆寫。兩者應該相關，卻可能背離。低 CE 而高 OR 的架構，是校準良好卻決策不符團隊偏好的架構，通常代表政策介面或取捨向量與團隊實際價值觀設定不符。高 CE 而低 OR 的架構，是決策被人類接受、但聲明信心不可靠的架構，通常代表團隊應該調查的橡皮圖章現象。診斷的工作流程，是把三個訊號（CE、OR、SAR）一起監控，並像調查絕對水準一樣積極地調查它們之間的背離。

值得安裝的紀律是：OR 與 SAR 要週期性地對照真實結果重新校準。學習代理的資料會告訴團隊，有多少比例的覆寫最後被證明是正確的（人類覆寫得對），又有多少是令人遺憾的（人類的覆寫結果比架構的提案更糟）。這個二階訊號，正是讓信任遙測本身值得信任的東西：一個高但大多正確的 OR，代表團隊在盡責；一個高但大多令人遺憾的 OR，則代表團隊的審查流程正在產出比自主執行更差的結果。運作在高成熟度的團隊，會把這個二階訊號當成月度治理審查的一部分來追蹤，並依資料所揭露的「架構品質」與「審查流程品質」兩者，調整政策介面。

以下是單一代理在一季結束時的信任儀表板具體樣貌：

trust_telemetry: capacity_agent / payment_service / Q1 2026
CE_aggregate:                   0.061  (target < 0.20) ✓
CE_in_high_confidence_bin:      0.24   (target < 0.10) ✗
Override_Rate_90d:              0.07   (target < 0.10) ✓
SAR_for_T1_suggestions:         0.78   (target 0.65-0.85) ✓
second_order_analysis:
  overrides_evaluated:            134
  overrides_correct (team right): 102 (76%)
  overrides_regrettable:          28 (21%)
  overrides_inconclusive:         4 (3%)
  interpretation: team's review process is generally producing
    better outcomes than autonomous execution would have
divergence_alert:
  high_confidence_CE breach: action_required
  proposed_response: constrain autonomous execution above 0.85
    confidence until upper-bin calibration improves

這份儀表板告訴團隊，他們的信任校準目前在哪裡，以及哪裡需要注意。彙總訊號看起來都健康；分箱層級的分析揭露了一個特定的校準問題；二階分析則確認團隊的審查流程是可靠的。每一行都是營運證據，而被建議的回應，是對照實際落差校準過的，而不是對照抽象的擔憂。

11.6　運行推理控制平面

本節，是本書最「星期一早上」的一章裡最「星期一早上」的一節。「推理控制平面」，是一位運行 ARE 平台的 SRE 在輪班時實際操作的執行期基質。工作是具體的：稽核前一輪班的為何軌跡、審查覆寫事件、對照當前校準資料調校動態護欄、在證據支持時重新校準授權綁定、調查任何已跨越門檻的反模式指標。這些工作，對團隊的前輩而言全都是不可見的：前代理時代的 SRE 輪班，主要是反應式的，回應陸續抵達的警報。代理式的 SRE 輪班，主要是主動式的，維持著讓架構持續運作良好的條件。

值得點名的概念性轉變是：推理控制平面不是一個儀表板。它是架構為營運互動而暴露的執行期層：一個結構化的工作空間，團隊可以在其中檢視架構近期的任何決策、走過它們的為何軌跡、檢查產生其授權綁定的護欄評估、提議對政策介面的調整，並透過審查驗證這些提議。儀表板是唯讀的；推理控制平面是可讀可寫的，而每一次寫入，都經過產出底層決策的同一套治理機制。團隊在這個平面上的日常工作，正是讓架構持續運作在團隊意圖之上的原因，而工作的結構化性質，正是讓它能跨越多位團隊成員、跨越多支團隊擴展的原因。

工作落在四個類別裡。「稽核」，是對為何軌跡的系統性審查，依決策關鍵性與反模式指標排序。典型的一輪班會稽核前 24 小時中 T2 與 T3 決策的抽樣子集，尋找暗示校準漂移或政策不匹配的模式。「調校」，是依稽核發現調整動態護欄，典型作法是提高或降低信心門檻、調整遲滯參數，或修改動態護欄裡的調節器權重。「重新校準」，是依累積證據提議層級綁定變更的較大結構性工作：因為校準持續改善而把行動類別 X 從 T1 晉升到 T2，或因為覆寫率上升而把行動類別 Y 降級。「調查」，是在某個反模式指標（第 10.6 節）跨越門檻、或某個覆寫率趨勢揭露了例行稽核漏掉的東西時，接續進行的深度診斷工作。這四個類別是輪班的結構性節奏，而團隊的生產力，是以這個節奏被維持得多好來衡量的。

09:00 - shift starts
  operator: SRE on-call rotation, payment_service domain
  review_pane: prior 24h decisions, filtered to T2+ with audit flags
09:00-09:15 - AUDITING
  review: 8 sampled Why Traces from T2 incident-response decisions
  finding_1: WT-2026-05-13-22:14:08-003 had grounding chain with
             only one freshness-degraded signal; investigate signal
             pipeline
  finding_2: 7 other traces clean; sampling continues next shift
09:15-09:35 - TUNING
  target: capacity_agent.scale_eu_west guardrail
  current_state: confidence_threshold 0.70, hysteresis 0.05
  evidence: last 30 days show CE in 70-80% bin = 0.06 (better
            than tolerance); SAR for suggestion-mode 0.78 (healthy)
  proposed: lower confidence_threshold to 0.65, keep hysteresis
  review: peer approval from on-call buddy
  applied at 09:34; rolling window check scheduled for 09:35 next day
09:35-09:50 - RECALIBRATING
  target: chaos_agent.shared_pool_experiments tier binding
  current_state: T1 (preauthorised within bounds)
  evidence: 90 days of cleanly-running experiments, override-rate 0.03,
            hypothesis-update ratio 0.94, no anti-pattern indicators
  proposed: promote to T2 (autonomous within blast radius)
  review: requires team review (T1→T2 promotion threshold)
  submitted to governance review queue for tomorrow's standup
09:50-10:00 - INVESTIGATING
  trigger: anti-pattern indicator predict_without_verify_ratio = 0.21
           (above 0.15 attention threshold for payment_service)
  initial_check: which PRSs in last 14 days had no verify record?
  finding: 4 PRSs resolved without structured verify; all 4 happened
           during the night-shift handover window
  hypothesis: handover SOP not consistently capturing verify records
  follow_up: schedule SOP review with night-shift lead
10:00 - shift ends
  audit handover packet: 1 signal pipeline issue, 1 tuning applied,
                         1 recalibration submitted, 1 investigation
                         scheduled

這四個類別的節奏，在一小時內產出了具體、證據驅動的工作。沒有任何一項活動需要反應式救火；全部都在維持讓架構持續運作在團隊意圖之上的條件。這就是代理式 SRE 輪班實際的樣子。

值得安裝的紀律是：推理控制平面是被「運行」的，不是被「消費」的。一支把這個平面當成監控儀表板、只在事故期間查看、其餘時間忽略的團隊，並沒有投資於這個平面的營運角色。平面的價值來自稽核、調校、重新校準與調查的日、週、月節奏。一支運行這個平面的團隊，擁有一套持續改善的架構；一支消費這個平面的團隊，擁有一套漂移的架構。營運實務，正是那個差異點。

這份工作在實務上是什麼感覺，值得為新手團隊點名。前代理時代的 SRE 輪班，特徵是長時間的低活動，被警報觸發時的急性反應期打斷。代理式的 SRE 輪班，剖面正好相反：整輪班持續的中度活動，反應期則被壓縮且罕見，因為架構正在處理過去那些警報會浮上來的大部分情況。操作者的注意力放在二階導數上，不是「現在正在發生什麼」，而是「架構行為裡有哪些趨勢暗示有東西正在改變」。這是智識上不同的工作，往往在專注度上更吃力，即使它在體力上不如舊的待命模式那麼耗人。轉往代理式 SRE 工作的團隊，常低估持續專注稽核的認知負荷；架構不會產出舊的反應式工作那種腎上腺素線索，操作者需要發展出刻意的實務，來在沒有這些線索的情況下維持注意力。番茄鐘式地把稽核工作切成時間盒、護欄調校的同儕審查輪替、結構化的輪班交接協定，都有幫助。這份工作是真的不一樣，團隊的營運實務也需要隨之演化。

另一項值得點名的特質是：推理控制平面本身也是可觀測的。操作者在平面上的工作會產出架構吸收的結構化事件：每一次調校調整、每一項稽核發現、每一個調查假設。這些事件回饋到學習代理的模型裡，這意味著架構會隨時間從團隊的營運實務中學習。一支調校調整與後續校準改善相關的團隊，會在架構的模型裡得到「他們懂得哪些收緊是真正必要的」這份信用；一支調整與任何改善都無關（或更糟，與退步相關）的團隊，則會得到一個結構性訊號：他們的調校直覺可能與底層證據失準。這個平面不只是團隊操作架構的地方，也是架構觀察團隊的地方，而這種雙向學習，正是操作紀律之所以重要的原因之一。

11.7　降級與升級機制

授權會往兩個方向移動。大多數團隊會審慎設計晉升路徑：行動類別從 T0 往 T3 移動的標準；卻把降級路徑設計得很隱含，經常是事後才補上。隱含的降級路徑，是本章最大的營運脆弱來源：一套能被晉升卻不能被降級的架構，是一根單向棘輪，而單向棘輪，正是信任以災難性、而非漸進性方式流失的方式。本節安裝兩個方向的正式機制，並把降級當成一級治理操作，而不是僅限緊急狀況的退路。

晉升是比較容易設計的方向。團隊撰寫一份晉升政策，指明行動類別在什麼條件下符合層級升級資格：最短觀察窗口（典型 60 至 90 天）、當前層級的最低決策量、在容忍範圍內的校準證據、在容忍範圍內的覆寫率、沒有啟用中的反模式指標、沒有牽涉該行動類別的近期事故。治理平面持續評估這些條件；當全部滿足時，架構向團隊提議晉升。提案包含架構據以提議的證據、晉升後預期的行為變化，以及團隊的審查步驟。團隊核准、修改或駁回提案。被核准的晉升在排定的時間（通常是低活動窗口）生效，架構開始在新層級運作，並在晉升後的第一個窗口內帶著提高的稽核注意力。

降級有相同的結構形狀，但觸發條件更緊。「自動降級」在下列條件之一跨越警報門檻時觸發：相關分箱的校準誤差在一個持續窗口內高於容忍值、覆寫率在一個持續窗口內高於容忍值、某個反模式指標跨越警報門檻、該行動類別在近期事後檢討中被牽涉。自動降級恰好往下降一級；架構繼續運作，只是授權較低。「手動降級」在團隊成員或緊急分流操作者宣告時觸發；觸發條件是人類的判斷：該行動類別值得比當前層級所提供的更多注意力，無論自動條件是否已經觸發。手動降級的目標層級由操作者指定，通常是 T0 或 T1。兩條降級路徑都會產出結構化的稽核紀錄，而這些結構化紀錄，正是架構在重新評估晉升資格時使用的證據。

值得放慢腳步的架構特質是：從降級中復原不是自動的。一個被降級的行動類別，不會在警報條件解除時就回到原本的層級。它會在從「新的起始層級」出發、滿足晉升條件時才回來，這意味著架構必須以「新鮮的證據」重新證明較高層級是正當的。這是刻意的不對稱。降級是快的、由警報觸發的；晉升是慢的、由累積證據觸發的。這種不對稱反映了一個營運現實：信任難得而易失，而架構在結構上遵守這份不對稱。設計對稱晉升／降級機制的團隊，常發現自己隨著底層訊號震盪而反覆降級與重新晉升同一個行動類別，這會產出營運噪音而不會產出真正的信任校準。這份不對稱，正是架構對這種震盪的防禦。

與第 11.2 節動態護欄的連結值得點名。動態護欄在「一個層級之內」調節嚴格程度；層級轉換則把行動類別在「層級之間」移動。這兩種機制是互補的。一條動態護欄可以在事後檢討窗口期間把信心門檻從 0.70 提高到 0.91，在 T2 授權之內產出暫時的額外摩擦。一次層級降級則可以把同一個行動類別整個從 T2 移到 T1，在架構如何處理它這件事上產出結構性的改變。前者更快、粒度更細；後者更慢、結構意義更重大。一套被妥善工程化的治理系統會同時使用兩者：用動態護欄調整當前運作，用層級轉換調整運作基準線。

本節值得安裝的紀律是：層級轉換要以結構性變更的規格被稽核。每一次晉升與降級，都會產出一份稽核紀錄，包含正當化它的證據、核准它的操作者、生效的時間戳記、受影響的行動類別，以及預期的行為影響。這些紀錄累積成架構的「授權歷史」，那正是回溯性治理審查（第 11.8 節）的基質，也是跨團隊學習「哪些層級轉換模式與哪些結果相關」的基質。一支沒有授權歷史的團隊，是一支對「這個行動類別為什麼在這個層級」只能回答「因為我們就這樣設的」的團隊。一支擁有結構化授權歷史的團隊，則能把任何當前的層級綁定，追溯回產出它的那一連串證據驅動轉換，而這正是「治理即學習」在營運上的意義。

以下是架構對每一個行動類別持續執行的晉升資格檢查的具體樣貌：

promotion_check: capacity_agent.cross_region_traffic_shift (20-50%)
current_tier: T1
proposed_promotion: T1 → T2
evidence_review:
  observation_window: 90 days (policy minimum)
  decisions_in_window: 47 (above 30 minimum)
  autonomous_execution_eligibility: N/A (currently T1)
  suggestion_dispatch_rate: 0.79 (above 0.65 minimum)
  calibration_error_relevant_bin: 0.08 (below 0.15 max)
  override_rate: 0.04 (below 0.10 max)
  anti_pattern_indicators: all green
  recent_incidents_implicating_class: none in last 60 days
  business_preference_lock: none
promotion_proposal: ELIGIBLE
architecture_recommendation: promote to T2
expected_behavioural_change:
  actions in 20-50% range that previously required dispatch will
  now execute autonomously within action contract bounds
  estimated_human_dispatch_load_reduction: -47% for this class
required_review:
  promotion_approver: service_owner OR governance_council
  review_deadline: next governance review cycle
  rollback_path: tier_demotion via standard demotion machinery

架構在做粗重的工作：持續評估哪些行動類別已累積足夠證據，值得一次層級升級。團隊的角色，是對照架構看不見的情境（即將到來的組織變動、法規考量、策略優先順序）審查被提議的晉升，並核准、修改或駁回提案。晉升與降級之間的不對稱意味著：一次被駁回的晉升會留在當前層級；而一次被拖延的降級，並不會延後降級在其觸發條件成立後生效。

11.8　治理作為一套學習系統

本章更大的論點是：治理本身就是一個封閉的學習迴圈。靜態治理——政策設定一次、無限期強制執行、每年審查一次——正是自主性原本要移除的那種官僚。動態治理（政策依證據更新、對照營運資料調整、與架構自身的學習同步重新校準），才是讓自主性可行的運作基質。第 5.8 節的封閉學習迴圈，適用於治理的程度不亞於它適用於架構的推理：每一個決策都是證據，每一次覆寫都是證據，每一次校準更新都是證據，而治理機制必須吸收全部。

值得點名的結構性承諾是：每一項治理產物都有自己的重新校準週期。第 11.1 節的政策規則每季審查，重新校準由學習代理累積的「這些規則是否產出團隊預期結果」的證據觸發。第 11.2 節的動態護欄參數每月審查，重新校準追蹤校準證據。第 11.4 與 11.7 節的層級綁定持續審查，重新校準由架構自己提議、由人類核准。授權歷史（層級轉換的稽核軌跡）每半年審查一次，作為更廣泛治理健康評估的一部分。每一項產物都有自己的週期，週期本身是一項政策決策，而週期，也會依「目前的週期是否產出夠及時的調整」這件事的證據而調整。

值得點名的、與複利的連結是：治理複利的方式，和架構其餘部分複利的方式一樣。一支已經運行工程化治理兩年的團隊，擁有一份對照八個季度證據重新校準過的政策介面、對照 100 週以上營運資料調校過的動態護欄，以及數百筆已記錄轉換與其結果所支撐的層級綁定。一支從零開始的團隊，什麼都沒有。第 3.0 節的複利曲線，適用於治理的程度不亞於它適用於架構的推理，而一支已經投資兩年的團隊，處在與一支剛起步的團隊結構上完全不同的位置。這正是代理式可靠性獎勵耐心的原因之一：治理層的價值，來自跨越多個季度的持續投資。

本節收尾時值得安裝的框架是：治理是這套架構裡運行時間最長的學習系統。推理平面的模型在單一決策的時間尺度上更新（秒到分鐘）。學習代理的相似性資料庫在事故的時間尺度上更新（天到週）。治理層在政策審查的時間尺度上更新（週到季）。這三個時間尺度會組合：最快的層產出決策，中間的層產出校準資料，最慢的層產出結構性調整。每一層都受惠於它下面的層，也約束它上面的層。治理層那種緩慢而穩定的重新校準，正是把架構其餘部分更快的學習，維持在與團隊意圖對齊狀態的東西。

把週期機制具體化：一支運行工程化治理的團隊，會維護一份重新校準審查的行事曆，每一場都有宣告的範圍、宣告的證據輸入，以及宣告的輸出產物。每月的動態護欄審查，消費上個月的校準資料、覆寫率趨勢，以及任何牽涉治理的事故檢討，產出護欄參數調整的結構化提案。每季的政策介面審查，消費上一季完整的稽核軌跡、架構建議的層級轉換、團隊表達的意圖轉變，以及任何法遵變動，產出一份團隊在生效前核准的更新政策產物。每半年的授權歷史審查，消費兩季的層級轉換及其下游結果，產出一份「哪些轉換模式與哪些結果相關」的結構化評估，回饋成月度與季度審查的證據。審查被排進行事曆，產物被版本化，而重新校準本身是可衡量的：一支發現自己每季審查始終產不出任何調整的團隊，要嘛運作在異常穩定的環境，要嘛審查得太輕。週期就是紀律，而紀律，正是會複利的東西。

收尾時值得點名的架構特質是：「治理即學習」，正是把「被工程化的自主性」與「自動化的執行」區分開的東西。自動化的執行，跑同一套邏輯直到有人重新設定它；被工程化的自主性，運作在一個持續依營運證據更新的政策基質之上。前者在任何當下看起來更快，卻在中期停滯；後者在任何當下看起來稍微更審慎，卻跨越季度複利。團隊在這兩種運作模式之間的選擇，是團隊在第一部那些初始架構承諾之後，所做的最後果深遠的一次選擇。第四部的各章，會發展出讓第二種模式能跨越團隊、服務與組織規模而可行的運作模型。

11.9　治理的失效模式

本章已經安裝了健康治理的機制。本節，要盤點在生產環境代理式系統裡最常被觀察到的四種失效模式，各自附上特徵性的警訊與架構性的防禦。這四種失效模式是：護欄過度限制、護欄限制不足、政策漂移，以及稽核缺口。沒有一種是奇特的；四種都會在代理式治理的第一年裡例行出現，而「治理走向成熟的團隊」與「治理停滯的團隊」之間的差別，就在於這些失效模式是否被系統性地抓出來。

「護欄過度限制」，是護欄嚴格度被設得比證據所支持的更高，讓例行行動承受過多摩擦的失效模式。架構運作安全，吞吐量卻遠低於它的證據所支持的水準；團隊的意圖（在例行工作上跑得快）被設得太緊的護欄違反了。警訊：SAR 橫跨各行動類別持續高於 0.90（團隊幾乎接受每一個建議，代表建議偏保守）；覆寫率低於 0.03（團隊很少介入，暗示架構其實沒有在推進邊界）；人類審查佇列裡「本來應該自主」的候選行動積壓上升。防禦：對照團隊意圖週期性審查護欄，問一個問題：「這條護欄產出的，是對的摩擦，還是可避免的摩擦？」團隊依證據所做的調整，會在資料支持放鬆的地方放鬆護欄。

「護欄限制不足」，是相反的失效模式。護欄被設得對證據而言太寬容，讓架構觸發那些校準並不足以正當化其自主性的行動。警訊：覆寫率上升（團隊在逆轉架構的決策）；執行後逆轉率上升（架構採取了團隊必須撤銷的行動）；高信心分箱的校準誤差升到容忍值之上（架構在其實沒那麼可靠的行動上過度自信）。防禦：收緊相關護欄，若趨勢持續則降級受影響的行動類別。這個失效模式在營運上比過度限制後果更嚴重；過度限制護欄的代價，是以較慢的例行工作支付的，而限制不足護欄的代價，是以生產環境事故支付的。

「政策漂移」，是沉默的失效模式。隨著時間過去，團隊的意圖轉變（優先順序改變、服務成熟、新的法遵要求到來），政策介面卻沒有以同樣的速度更新。架構繼續對照較舊的政策運作，產出團隊如今已不會背書的決策。這種漂移對標準的 SLO 監控是不可見的；架構聲明的指標看起來很健康，但底層意圖已經改變，而政策沒有跟上。警訊：「其實我們並不希望發生那樣的事」這類決策後討論的比率上升；團隊表達的意圖（在設計文件、規劃會議裡）與架構正在遵守的政策產物之間出現落差。防禦：每季對照團隊當前意圖審查政策，明確比對「我們說我們想要什麼」與「政策讓我們做什麼」。

「稽核缺口」，是在營運上最危險的失效模式。架構正在做決策，但為何軌跡沒有被產出，或被產出卻沒有被保存，或被保存卻無法審查。架構的決策在事後變得無法辯護：一支無法重建「某個特定行動為何被採取」的團隊，是一支無法隨時間改善架構推理的團隊，也無法在外部審視（稽核人員、監管機關、管理層）面前為架構辯護。警訊：稽核抽樣中出現缺漏的為何軌跡欄位；稽核保存出現空窗；當被問到特定近期決策時，操作者回答「我不知道」的比率上升。防禦：結構性地要求每一個決策都必須產出完整的為何軌跡；週期性的稽核軌跡健康檢查，驗證保存與可審查性。

值得點名的、與本章其餘部分的連結是：這四種失效模式全都是系統層級的，而不是決策層級的。單一決策不會揭露它們；跨決策的趨勢才會。第 11.0 到 11.8 節的治理機制，產出了失效模式偵測所需要的結構化產物：政策介面供漂移分析、動態護欄供過度／限制不足分析、為何軌跡供稽核缺口分析。沒有這些結構化產物，這些失效模式在產出可見的失敗之前都是不可見的，而到那時代價已經付掉了。架構上的防禦，是對治理層本身的結構化監控，把它當成與架構其餘部分監控並列的一級營運議題。

11.10　從治理到模擬

第十一章已經安裝了讓自主性能在生產環境安全運作的治理基質：政策介面、動態護欄、緊急分流、授權層級、覆寫率遙測、推理控制平面、晉升與降級機制、治理即學習，以及四種失效模式。這套基質，正是讓團隊能夠隨著證據累積而授予、衡量、收窄與撤回自主性的東西。一支運行這套基質的團隊，擁有一套自主性被校準到團隊意圖的生產環境架構，並有對抗漂移、過度限制與限制不足的結構性防禦持續運行。這套架構在真正重要的意義上是營運安全的：每一個決策都可辯護，每一個授權綁定都有它的證據基礎，每一次覆寫都是架構會吸收的訊號。

治理靠自己做不到的，是在授予權限「之前」驗證架構的推理品質。第十一章授予的權限，是建立在透過生產環境決策所累積的營運證據之上。一個新的行動類別、一個新的代理、一次新的基質變更，都還沒有營運證據；團隊手上只有架構聲明的能力與意圖。以聲明的能力為基礎授予權限，正是產出「不被正當化的初始信任」的失效模式，而架構上的答案，是模擬。第十二章要發展的模擬基質，讓架構能在生產權限被授予之前，對照合成情境驗證推理品質。每一次往更高層級的晉升，都先通過模擬器。模擬器產出的證據，團隊可以用審查營運證據的同一套方式來審查（校準資料、溯源鏈、決策品質衡量、反模式指標），只不過它是在生產暴露「之前」產出的，而不是作為它的後果。

本章與下一章之間的橋樑，是一項架構承諾：信任在每一個階段都是以證據為基礎的。生產環境的信任來自生產環境的證據；上線前的信任來自模擬的證據；兩種證據有相同的結構形式。這套架構的連貫性，正來自這份一致性：一個生產環境裡的決策與一個模擬裡的決策，產出同一類產物，對照同一組指標被評估，由同一套治理機制決定團隊要授予什麼權限。第十二章，正是模擬器贏得自己一級架構元件地位的地方——那個讓架構能夠透過「團隊可以在行動影響使用者之前就審查的證據」而變得值得信賴的基質。下一章開始。