第六章
代理式可靠性架構

警告 一個為儀表板優化的訊號平面，會限制住它上層的一切。把訊號設計給人類消費的誘惑始終存在，因為通常是同一支工程團隊在維護儀表板與代理。這裡的紀律，是認清這兩種消費者想要的東西不同，並把訊號平面設計給要求較高的那一個。儀表板可以從決策級訊號中生成，反過來則不行。

proposal_id: "rp-48291"
triggering_signal: "latency_anomaly:v1.2"
leading_hypothesis: "dependency_saturation"
candidate_actions:
  - "throttle_non_critical_traffic"
  - "scale_read_replicas"
intent_alignment:
  primary_slo: "checkout_latency"
  allowed_degradation: true
risk_estimate: "low"
confidence: 0.82
requires_human_approval: false

警告 如果推理平面能直接行動，這套架構就是不安全的。為了速度而跳過治理平面的誘惑始終存在，尤其是對於例行行動而言。要抵抗它。治理平面的評估運行在毫秒之間，速度上的代價微不足道；而移除它的結構性代價，是這套架構失去了強制執行「自主性維持在當責邊界之內」的能力。這道邊界一旦消失，不重建系統就無法找回。

4.5　執行平面：在不失去控制的情況下行動

執行平面，是自主性變得真實的地方。到目前為止，架構裡的一切都關乎「理解」——訊號平面呈現現實，推理平面提議決策，治理平面核准或駁回它們，這些都不會改變系統。執行平面，是意圖變成行動的地方，也是大多數自主性專案在失敗時所失敗的地方。常見的錯誤，是把執行當成推理的簡單延續——如果一個系統能夠決定，它應該也就能夠行動。實務上，沒有邊界的執行，是可靠性被摧毀的速度比任何一次中斷都還要快的原因。

這個平面的工作恰好只有一項：精準地執行已核准的決策，不多做任何事。它把決策提案轉譯成具體的行動，強制執行範圍、權限與護欄，安全且可預測地執行，並把結果訊號發送回訊號平面以閉合迴圈。它不決定該做什麼，不對替代方案進行推理，也不會凌駕治理。正是這個區隔，讓自主性在規模化之後依然能夠存活。

讓這個平面的行為變得可預測的產物，是「行動契約」。就像訊號契約讓訊號平面的輸出值得信賴一樣，行動契約讓執行平面的行為有邊界。行動契約，是一個行動的機器可讀描述：它做什麼、它需要什麼、它如何逆轉，以及什麼算是成功。執行平面圍繞著一份行動契約目錄建構起來，這個平面不能執行任何不在這份目錄裡的東西——自由形式的行動生成，被明確排除在這個平面的範圍之外。這聽起來很限制，確實也是。這份限制，正是安全特質所在。可靠性的失敗，很少是因為「缺乏行動」，而是因為「不安全的行動」，而「缺乏行動」的問題，遠比「不安全的行動」的問題更容易解決。

第三章介紹的「節流非關鍵路徑」這個行動，一份具體的行動契約可能長這樣：

action_contract:
  name: throttle_non_critical_paths
  version: "1.2"
  owner: team-platform
  intent: >
    Reduce load on a degrading service by limiting non-critical request paths,
    preserving capacity for high-criticality user journeys.
  preconditions:
    triggering_signal: latency_anomaly:v1.2 or saturation_warning:v1.0
    confidence_threshold: ">= 0.75"
    service_criticality: tier-1
    error_budget_remaining: "> 30%"
    not_in_change_window: true
  action:
    method: traffic_classifier_update
    scope:
      service: <from_signal>
      path_classes: ["background", "secondary"]
      throttle_percent: 40
    duration_max: "10m"
  reversal:
    method: traffic_classifier_restore
    timeout_max: "30s"
    automatic: true
    trigger_conditions:
      - signal: latency_anomaly cleared
      - signal: error_budget_recovered
      - manual: operator_request
  success_criteria:
    primary: latency_p99_returned_to_baseline within 5m
    secondary: error_rate_remained_below 1.0
  outcome_signals:
    - latency_change
    - error_rate_change
    - throttled_request_count
    - revenue_impact_estimate

這份契約有幾項特質值得留意。intent 欄位是一段散文陳述，說明這個行動是為了什麼，寫給維護這份契約的人類看。前置條件是機器可評估的，只要有任何一項不成立，這個行動就不會執行。行動以機械化的方式宣告自己的範圍（哪些路徑、多少百分比、持續多久）。逆轉是強制性的——一個無法自動逆轉的行動，很少應該出現在這份目錄裡。成功標準是明確且可量測的，讓執行平面能評估這個行動是否達成了預期結果。結果訊號，宣告了這個平面將會把什麼回饋給訊號平面，這正是閉合 DRAL 迴圈、讓學習成為可能的關鍵。

這份契約，讓執行平面的行為變得可預測，這是自由形式的行動生成永遠做不到的。推理平面裡的一個代理，可以提議這個行動；治理平面，可以評估這個提案是否符合政策；執行平面，可以在嚴格定義的邊界內執行它，並在不奏效時自動回滾。關於這個行動行為的一切，都被宣告在這份契約裡，由特定團隊擁有，有版本控管，可被檢視。當有人類問，為什麼系統在凌晨三點對流量做了節流時，答案可以從觸發它的候選行動、以及限制它執行的行動契約中被重建出來。

爆炸半徑，是執行平面在結構上強制執行、而不是仰賴推理平面去限制的一項特質。每一份行動契約，都宣告自己的範圍、時長、影響幅度，以及可逆性限制，執行平面會機械化地強制執行這些限制。把一個服務擴容三個副本、為期兩分鐘，與無限期地擴容五十個副本，本質上是兩個不同的行動，這個平面會把它們當成帶有不同契約的不同行動來對待。這不是一個政策層面的議題，而是架構層面的議題。推理平面提議一個行動，這個行動攜帶著自己的爆炸半徑，執行平面強制執行它——這一切都不仰賴良好的意圖，或營運人員審慎的判斷。

有兩種實作模式值得在此簡短點名，因為本書其餘部分會遇到它們兩者。第一種是「集中協調式執行」，由單一執行服務接收已核准的提案、驗證契約，並透過受控的整合（雲端 API、部署系統、設定管理）執行行動。這種模式提供強一致性與集中式可稽核性，是擁有強大中央平台團隊的組織的預設選擇。第二種是「分散式執行代理」，由運行在它們所管理系統附近的輕量級執行器，接收已核准的行動，並在嚴格的契約邊界內就地執行。這種模式降低延遲、改善韌性，但需要更強的加密控制與契約強制執行。這兩種模式都是有效的，架構上的要求是：無論執行器身處何地，執行的權限都在結構上保持有邊界。

結果回報，是閉合這個迴圈的特質。執行不算完成，直到結果被觀察到為止。執行平面會把結果訊號發送回訊號平面：延遲變化、error budget 恢復、回滾觸發、行動逾時、部分失敗。沒有這些訊號，自主性無法改善，只能重複自己。這些訊號餵進 DRAL 的「學習」這一拍，正是系統對「在這些條件下採取這個行動」的信心，為下一次被精煉的地方。一個不發送結果訊號的執行平面，只是在產出行動，而不是在學習——一個會行動卻不會學習的系統，是自動化，不是代理式可靠性。

4.6　治理平面：編碼信任與當責

治理平面，是讓自主性變得可被接受的關鍵。沒有治理，代理式系統雖然強大，卻很危險。當治理被放錯位置（放在執行期之外、放在核准流程裡、放在變更諮詢委員會的會議裡）時，代理式系統會變得緩慢、脆弱，且與人工作業無異。解決這個問題的架構性做法，是把治理變成一項執行期的關注點——政策存在於系統裡，在毫秒之間，由治理平面自動地對每一個候選行動進行評估。

對 SRE 讀者而言，這是最違反直覺的一個平面，因為傳統維運把治理放在執行期之外——變更諮詢委員會審查變更，核准流程把請求路由給人類簽核，操作手冊把政策編碼成程序。這些機制，在行動稀少、時間壓力低的時候是有效的；在行動持續發生、時間壓力高的時候——也就是代理式系統運作所在的體制——它們會徹底失效。治理平面，正是對此的架構性回應：它把政策從一套系統之外的流程，移動到系統之內一個執行期的評估器裡，而且不會移除賦予政策意義的人類監督。

治理不對「狀態」進行推理，推理平面早已做過這件事；治理平面對「權限」進行推理。給定這個被提議的行動、這些輸入、這個信心，在這些目前的條件下、在這個團隊的擁有權與這些合規限制之下，這個行動是否被允許？在簡單的情況下，輸出是二元的（核准、駁回）；在真實的情況下，輸出是分級的（以完整範圍核准、以縮減範圍核准、附帶強制人類通知的核准、附帶升級的駁回）。這個平面消費三項輸入：來自推理平面的候選行動、來自執行平面目錄的行動契約，以及同時限制兩者的組織政策。只有這三者都對齊時，這個行動才會繼續進行。

一個簡單的政策範例，能釐清執行期治理長什麼樣子。以一條規範自主擴容行動的政策為例：

policy:
  name: autonomous_scaling_policy
  version: "2.0"
  applies_to: scale_service
  allow_when:
    confidence: ">= 0.80"
    service_criticality: ["tier-2", "tier-3"]
    time_window: "any"
    error_budget_remaining: "> 20%"
  constraints:
    max_instances_added: 3
    max_duration: "10m"
    max_cost_increase_percent: 5
  require_human_approval_when:
    confidence: "< 0.80"
    service_criticality: "tier-1"
    affects_regional_failover: true
  escalation:
    on_constraint_violation: require_human_approval
    on_repeated_failure: tighten_autonomy

這份政策，明確地編碼了信任。它在風險低的地方（第二級/第三級服務、高 error budget、保守範圍）允許自主性，並在後果較高的地方（第一級服務、區域性影響、低信心）路由給人類。不需要開會，不需要開工單，系統會在執行期，對每一個符合其範圍的提案評估這份政策，答案在毫秒之間就被計算出來。治理的人力成本，從「核准行動」轉移到了「設計政策」，而政策設計是以一種比核准流程曾經允許的更緩慢、更審慎的節奏在進行的。

這正是我們說「當責不會被委派」時的意思。第 3.7 節介紹了包圍著自主邊界的當責邊界這一層；治理平面，正是這道邊界變得可操作的地方。擁有這項服務的團隊撰寫政策，治理平面在執行期強制執行它。當系統行動時，是團隊的政策讓這個行動變得被允許；而當這個行動受到質疑時，團隊的政策，正是系統所指向的東西。政策的當責永遠不會移動，被政策允許的行動的執行權，則移轉給了系統。正是這個區隔，讓代理式營運變得可持續——沒有它，團隊要嘛保留所有執行權（緩慢、手動），要嘛放棄當責（快速、危險）。

「授權層級」，是治理平面用來讓政策變得分級、而不是二元的結構性概念。這個平面問的不是「這個行動是被允許還是被禁止」，而是「多少程度的授權才是合適的」。常見的層級包括：唯讀觀察（代理觀察，但不提議）、僅提議（代理提議，但不能執行）、執行可逆行動（代理在嚴格範圍內行動，並自動逆轉）、執行有邊界的不可逆行動（代理在逆轉不可能、但爆炸半徑受控的地方行動），以及要求人類核准（任何超出自主門檻的行動都路由給人類）。隨著信心上升、成熟度改善，服務可以往這些層級的上方移動；隨著信心下降（依照第 3.6 節的校準誤差 SLO）或條件變得異常，服務則往下方移動。這正是自主性能在不打破信任的情況下擴展的方式：它是分級的、可觀察的，並且在授權層級這個層面本身就是可逆的。

這裡值得點名兩種實作模式。「中央政策引擎」模式，把單一政策服務放在執行期裡，對每一個提案評估共享的規則，提供一致性與強稽核性，適合有標準化治理要求的組織。「分散式政策評估」模式，對政策包進行加密簽署，並在執行代理端就地評估，降低延遲、改善韌性，但需要謹慎的版本控管。這兩種模式並不互斥，許多成熟的組織兩者兼用：中央引擎用於跨切面的合規限制，分散式評估用於團隊專屬的營運政策。兩種形狀的工具都存在（中央模式的 OPA，分散式模式的已簽署政策包）。在架構上重要的是，無論由哪種模式承載評估，政策都是自動地、確定性地、在執行期被評估的。

可稽核性，是讓治理平面能隨時間保持值得信賴的特質。每一次核准、駁回、升級，都會產出一個稽核事件，擷取被評估的提案、被套用的政策、做出的決策、當時的信心，以及當責的擁有者。可稽核性不是為了追究責任，而是為了信任——當人類能夠審查系統做了什麼、為什麼這麼做時，自主性才會擴大；當稽核軌跡不完整或是事後才補上的，信任就會流失，團隊就會退回到更緩慢的機制。這個平面的稽核輸出，也正是讓監管互動變得具建設性、而不是對抗性的關鍵。一支能對任何過去的行動，展示觸發它的候選行動、核准它的政策，以及最終結果的團隊，和一支對「系統為什麼做了 X」的回答只有「代理決定的」的團隊，是處於根本不同的對話之中。

動態護欄，是第 11.2 節將展開的、執行期治理的延伸。治理平面裡的政策不必是靜態的，它們可以依照目前的條件自我調整：在高流量期間收緊限制，在低風險窗口放寬限制，在校準誤差上升時自動收窄授權，在下降時自動放寬。正是這一點，讓這套架構能運作在 L4 成熟度（適應性，在第 4.9 節定義），而不只是 L3（有邊界）。治理平面，是動態政策存在的介面，而設計動態政策的紀律，正是第十一章的工作。現階段，架構上的重點是：這個平面在結構上有能力支援它——政策是程式碼，在執行期被評估，可透過稽核被觀察，處理靜態規則的同一個評估器，也能處理動態規則。

4.7　人在迴圈中，作為一個控制迴路

「人在迴圈中」不代表「人工核准」。這句話就是本節的整個論點，本節其餘篇幅，都是這句話所隱含的工程工作。在代理式可靠性架構裡，人類的定位不是每一個行動的決策者，而是隨時間讓系統穩定、校準、演進的控制迴路。把人類當成核准關卡，會讓自主性崩解；把人類當成不存在，會移除當責；把人類當成控制迴路，則能同時保住這兩者——本節，正是本書其餘部分會回頭引用的正規處理方式。

核准式模型在代理式系統下會崩潰，有三個值得明確點名的原因。第一是速度：代理以機器的時間尺度進行推理與行動，人類核准會引入延遲，抵銷自主性的意義。第二是量：代理產生的決策量，遠超過人類能在即時狀態下合理審查的量，佇列的成長速度會快過人類清空它的速度。第三是品質：在時間壓力下審查局部情境的人類，做出的決策，往往比在明確邊界內運作、有良好限制的代理還要糟。這三者的組合，正是讓核准流程在結構上與持續性自主運作不相容的原因。修正的方式，不是去精煉核准流程，而是重新配置人類的角色。

行得通的心智模型，是古典控制理論裡的控制迴路。一個控制迴路不會決定每一個行動，它觀察系統行為，把它與期望結果做比較，並調整參數以維持系統穩定。代理持續在這個迴圈內部運作，人類則在特定的插入點上偶發性地介入——那些人類判斷力能增添最多價值的地方——而代理則在介入之間持續運作。這把對話從「人類有沒有核准這個行動」，轉變為「人類有沒有設計出這種行動會被核准的條件」。第一個問題，隨著行動數量而擴展；第二個問題，隨著行動「類型」的數量而擴展，而後者要小得多。

這套架構辨識出三種人類參與的模式，本書其餘部分會一致地使用這幾個詞：「迴圈之上」（above the loop）、「迴圈之中」（in the loop）、「迴圈之上監看」（on the loop）。每一種都有自己的工作、自己合適的節奏，以及自己的量測方式。

「迴圈之上」，是人類定義意圖的地方——服務目標、可接受的風險、爆炸半徑容忍度、成本限制、法規邊界、當責邊界本身。這些被編碼為政策與意圖宣告，而不是操作手冊。迴圈之上的工作，以緩慢的節奏（數週到數月）、審慎的注意力、在平靜的條件下，由擁有這項服務的團隊進行。代理在決策當下讀取這份意圖，並在其中運作；人類不在執行現場，人類的設計選擇存在於治理執行的那份政策裡。這是代理式系統裡最有價值的一種人類參與模式，也是那些把問題框架為「我們如何核准代理的行動」的團隊投資最不足的一種。正確的框架是「我們如何設計代理運作所在的條件」。

「迴圈之中」，是人類即時參與特定決策的地方——按設計，不是每一個決策；這套架構的紀律在於，迴圈中的參與是罕見的、且在結構上受政策限制的。當治理平面把一個提案路由給人類時（因為信心低、條件異常，或政策明確要求），人類進入這個迴圈，審查附帶著完整情境的候選行動，並核准、修改，或駁回。人類在這個模式裡的體驗，與傳統核准流程有根本上的不同：代理已經完成了調查，把情境結構化，命名了領先假設，為各個替代方案評分，並把這份提案呈現為一個連貫的產物。人類的工作，是為一個已經準備妥當的問題帶來判斷力，而不是從原始材料中組裝出這個問題——這正是讓「迴圈之中」的參與變得高價值、而不是耗損人心的關鍵。

「迴圈之上監看」，是人類觀察持續運作中的自主行動、只在有事需要介入時才介入的地方。他們盯著各項 SLO（第 3.6 節的五大旗艦，尤其是校準誤差），審查自主決策的樣本以驗證它們形式良好，在校準漂移時調整門檻，並依照趨勢證據所顯示的內容，擴大或收緊自主性。這是能夠擴展的模式：一名迴圈之上監看的工程師，可以監督每天數千個自主決策，因為這名工程師不是在核准它們，而是在觀察核准它們的那套系統。SLO 是這名工程師的儀器，稽核軌跡是這名工程師的證據，政策是這名工程師的槓桿。

為了讓這些模式變得具體，設想一個在疑似過載期間自動節流流量的代理。這個代理偵測到延遲上升，評估風險，以 85% 的信心提議節流。政策允許在信心高於 80% 時自主執行，於是這個行動被執行了。稍後，這位「迴圈之上監看」的人類審查了這次結果，注意到使用者影響很小，但營收損失卻比預期高（因為被節流的路徑，恰好承載了比政策所預期更多的營收流量）。這位人類沒有停用這個代理，而是在迴圈之上更新意圖，把尖峰時段的營收敏感度納入考量，相應地調整政策，下次同樣的條件出現時，這個代理就會以不同的方式進行推理。這位人類的介入，小、慢、審慎，而且是架構層面的，代理則在整個過程中持續運作。這正是正確做法的「人在迴圈中」，它能以核准流程永遠做不到的方式擴展。

另一項值得點名的特質是：人類的控制，行為應該像斷路器，而不是總開關。斷路器在偵測到不穩定時跳脫，保護系統，並在條件恢復正常時重置；總開關則停止一切，需要手動重啟，並在例行作業中引入恐懼與遲疑。代理式系統需要的是斷路器。人類設計斷路器何時跳脫（特定的校準誤差門檻、特定的失敗率、特定的異常條件），以及復原如何發生（當 SLO 恢復時自動重新接入，當跳脫是由一個未被辨識的條件造成時手動重新接入）。總開關依然為極端情況而存在，它是最後手段，不是預設的安全機制。

這個框架，正是在不崩解自主性的情況下保住當責的關鍵。擁有服務的團隊，依然對意圖定義、政策設計、門檻校準、以及覆寫決策負責。系統代表團隊行動，在團隊定義的限制之內，由團隊「迴圈之上監看」的工程師觀察。這支團隊，並不比在傳統作業下承擔更少的責任，他們只是對不同的事情負責。這個轉變，是從「核准行動」轉向「設計行動被允許的條件」，而正是這個轉變，讓可靠性工作能夠擴展到代理式系統所帶來的速度。

4.8　參考架構：把一切組合起來

目前為止所描述的一切（訊號、推理、執行、治理，以及作為控制迴路的人類），構成了代理式可靠性系統的結構語法。本節把這些部分組裝成一套單一的、可操作的參考架構，讓實務工作者能據以推理、調整，並漸進式地實作。這不是一份廠商範本，而是一張概念性的建構清單，設計來被畫在白板上，並套用到團隊實際工作所在的任何環境裡。我們會透過一個單一的實作情境走一遍：結帳服務上的一起第一級延遲惡化，由這套架構端到端地處理。

在 t=0 時，結帳服務開始惡化。/api/v2/cart/submit 端點上的 p99 延遲開始向上漂移。訊號平面早已透過第 4.3 節介紹的 latency_anomaly 訊號契約在觀察這項服務。在 t=15 秒時，這個訊號突破了契約的顯著性門檻，這份契約發送出一個結構化訊號：服務身分、端點、旅程分類、關鍵性層級（第一級）、百分位數值（p50/p99/p999）、上游依賴狀態（拓撲代理回報，付款依賴在過去三分鐘一直處於降級狀態）、近期變更情境（四分鐘前 inventory-api 上有一次部署上線），以及新鮮度/信心保證。這個訊號是決策級的——推理平面接下來需要的每一項特質，都已經在這個訊號本身裡了。

在 t=18 秒時，推理平面收到這個訊號，開始建構候選行動。它產生假設：依賴飽和（考量到付款降級訊號，機率高）、近期變更（考量到四分鐘前 inventory-api 的部署，機率中等）、流量轉移（考量到目前流量模式，機率低）、容量耗盡（考量到目前資源指標，機率低）。它依照可用證據為每個假設評分，領先假設是「依賴飽和」，信心 0.82。它依照這個領先假設評估候選行動：throttle_non_critical_paths（對依賴飽和適合度高、爆炸半徑低、完全可逆）、scale_read_replicas（適合度中等、爆炸半徑較高）、rollback_inventory_deploy（對這個領先假設適合度低，但被標記為若第二個假設被證實為真時的應變方案）。它產出一個候選行動，推薦 throttle_non_critical_paths，意圖對齊確認在事故期間第一級端點上允許降級，風險估計為低，信心 0.82，requires_human_approval 為否（因為信心超過了政策的自主執行門檻）。這個候選行動，跨越進入治理平面。

在 t=22 秒時，治理平面進行評估。它載入 autonomous_throttling_policy（規範第一級服務上 throttle_non_critical_paths 類型行動的執行期政策），檢查政策的條件：信心 ≥ 0.80（通過，0.82）、服務關鍵性為第一級（政策已明確處理，允許在依賴降級的條件下對第一級服務進行節流，只要節流保住了高關鍵性路徑）、剩餘 error budget > 30%（通過，目前為 67%）、不在變更窗口內（通過）、行動契約的 max_duration 上限為 10 分鐘（在政策限制內）、行動契約的逆轉是自動的（政策要求）。這份政策以完整的自主權限核准了這個行動，不需要人類核准。系統發出一個稽核事件：提案 ID、政策 ID、決策、評估當下的信心、當責擁有者（team-platform）。這個候選行動，轉移到執行平面。

在 t=23 秒時，執行平面載入 throttle_non_critical_paths 行動契約，最後一次驗證前置條件（訊號依然有效、信心依然超過門檻、error budget 依然健康），然後執行這個行動：結帳服務上的流量分類器，被更新為把次要與背景路徑分類節流 40%。這個行動把一個 action_started 結果訊號發送回訊號平面，訊號平面開始觀察這個行動的效果。執行平面為這個行動的成功標準設置了一個監視器：p99 延遲必須在 5 分鐘內回到基準線，錯誤率必須維持在 1.0% 以下。

在 t=180 秒時，監視器回報：p99 延遲已回到基準線，錯誤率全程維持在 0.4% 以下，被節流的請求數為 1,247（佔總量的一小部分），營收影響估計在政策容忍範圍之內。這個行動成功了。執行平面發送結果訊號（latency_change：已恢復；error_rate_change：穩定；action_outcome：成功），並在滿十分鐘時，除非底層條件發生變化，開始自動逆轉。DRAL 迴圈的「學習」這一拍，接手這個結果：針對這類失效（付款降級期間結帳服務上的依賴飽和）的 throttle_non_critical_paths 策略，被以一次成功的結果更新。推理平面對這類失效使用這項策略的信心，會稍微上升。下一次類似訊號到來時，推理平面會以稍高的信心，採用這個行動。

這就是整套架構的運作。從初始訊號到確認復原，不到四分鐘，例行執行過程中沒有人類介入迴圈，「迴圈之上監看」的工程師透過稽核軌跡得到通知，卻沒有被呼叫。每一步都是可觀察的，每一步都是可逆的，每一步都被契約與政策限制住。稽核軌跡擷取了完整的推理鏈——如果有任何地方出錯，團隊都能重建出發生了什麼、為什麼發生，一路追溯到決策當下的那個信心分數。

現在，思考一下這個情境沒有按計畫進行時會發生什麼。假設在 t=22 秒時，推理平面的信心是 0.74，而不是 0.82。治理平面的政策要求第一級服務上的自主執行需要信心 ≥ 0.80，於是政策把這個提案路由給人類。待命工程師的介面，收到附帶完整情境的候選行動：領先假設、替代方案、證據、建議的行動、建議的逆轉方式，以及展示「為什麼這個決策被路由給他們、而不是被執行」的稽核情境。工程師進行審查——代理已經完成的組裝工作全都攤在眼前，工程師不是從零開始。他們一鍵核准這個行動，從那一刻起，這套架構的行為完全一致：執行平面運行契約，監視器觀察，結果回流，學習發生。人類的參與只花了 30 秒，這位工程師從未需要從六個不同的工具中組裝情境。

現在，思考一個更糟的情況。假設在 t=22 秒時，信心是 0.82，但政策偵測到，這將是過去一小時內，這項服務上的第三次節流行動。政策的升級規則被觸發：repeated_action_threshold_exceeded。治理平面沒有執行，而是調降自主性，並把它路由給人類，稽核軌跡明確顯示出這個重複行動的模式。工程師審查後看見，系統一直在反覆節流、卻沒有底層的復原——這正是第 3.8 節的「過度矯正與隱藏的損害」失效模式。他們沒有核准另一次節流，而是把它升級為一次調查。這套架構的行為是正確的：它透過政策辨識出了這個失效模式，把它呈現給人類，並且沒有讓自主行動掩蓋底層問題。這正是架構在自己的失效模式演變成營運災難之前，先把它們抓住的樣子。

關於團隊實際如何採用這套架構，有幾點實務上的觀察值得一提。第一，你不會一次採用全部四個平面。大多數團隊從強化訊號平面開始，因為其他每個平面都依賴它。有了決策級訊號，推理平面就能漸進式地被引入，通常先從諮詢模式開始（代理提議，但不執行）。一旦推理平面產出的提案值得被治理，治理平面就開始變得有意義——這通常也是自主執行開始的時候。執行平面的行動目錄會隨時間成長，先從爆炸半徑最小的行動開始（流量塑形、功能降級），再隨著信心與政策成熟度而擴展。這種漸進式的採用，正是第 4.9 節的成熟度模型要講清楚的內容。

第二個觀察，是大部分的工程工作，存在於平面之間的邊界上：訊號—推理邊界上的訊號契約，推理—治理邊界上的候選行動格式，推理/治理—執行邊界上的行動契約，執行—訊號邊界上的結果訊號。每一道邊界，都是一個明確、有版本控管、有擁有者的介面。一支代理式可靠性團隊的工作，很大程度上就是設計並演進這些介面的工作；而一支代理式可靠性平台團隊的工作，很大程度上就是維護承載這些介面的基礎架構的工作。

第三個觀察，是這套架構是可以被畫出來的。一位讀完本章的實務工作者，應該能在五分鐘內，不查閱本書，就在白板上畫出四個平面、它們之間的邊界，以及它們形成的那個迴圈。這種「可畫性」，正是這套架構是否已被內化的測試。如果你畫不出來，你就還沒有真正掌握它；如果你畫得出來，你就能把它套用到自己的環境裡，本書其餘部分，就會變成對一個你已經理解的形狀所做的一系列精煉。

4.9　代理式可靠性成熟度模型

大多數成熟度模型，都以同樣的理由讓實務工作者失望：它們描述你身在何處，卻不告訴你要讓自己安全地往前走，必須具備什麼。在代理式系統裡，這道落差是危險的。自主性不是靠野心或工具就能解鎖的，它是在可觀測性、推理、授權這三個維度上都具備特定能力、且治理在執行期被強制執行時，才會被解鎖。這三個維度中的任何一個薄弱，都會製造出一道「信任天花板」（trust ceiling）：一個系統無法安全運作的臨界點，無論其他維度看起來多麼先進。本節安裝的成熟度模型，是本書其餘部分會回頭引用的架構。它是本書除了「四個平面」之外，被引用次數第二多的一節，也是「我們怎麼知道自己準備好邁向下一個等級了」這個問題的結構性答案。

這套模型有五個等級、三個維度。五個等級是「反應式」（Reactive）、「輔助式」（Augmented）、「有邊界」（Bounded）、「適應式」（Adaptive）、「系統性」（Systemic）。三個維度是「可觀測性」（系統能感知並賦予情境的能力）、「推理」（決策如何被形成與驗證）、「授權」（代理被允許採取哪些行動）。治理在這套模型裡不是第四個維度，因為治理是強制執行「授權」的執行期機制；治理成熟度的「等級」，隱含在授權這個維度裡。每個等級的定義，是這三個維度必須各自具備什麼，這個等級才能被安全地運作。跳過等級並不會加速導入，只會產出第三章所點名的失效模式，尤其是「信心崩潰」（當授權跑得比推理快時）與「靜默學習腐化」（當推理跑得比可觀測性快時）。

L1，反應式（人類主導）。可觀測性是孤島式的：指標、日誌、事件、追蹤存在於各自獨立的工具裡，在事故期間由人類專業知識手動關聯。推理是靜態的：if-then 邏輯內嵌在腳本或操作手冊裡，橫跨元件沒有情境覺知。授權完全屬於人類：人類確認警報、執行所有變更。這是大多數組織的起點，作為起點，這沒有什麼不對。在這個等級導入代理，不會產出回報，只會產出意外，因為它們所需要的基質尚未存在。第三章的代理式 SLO，在這個等級並不適用，傳統的 MTTR 與可用性指標，依然是正確的量測方式。

L2，輔助式（決策就緒）。可觀測性被標準化：遙測資料被一致地標記，訊號與服務、依賴關聯起來，有相當一部分遙測資料是結構化的。推理以諮詢模式運作：代理提議行動，有時透過 ReAct 風格的模式，但不會自主執行。授權僅止於建議：人類在每一次寫入觸及系統之前都要核准。治理是有文件記載的政策，加上初步的提示詞層級護欄。這個等級的主要指標，是「建議採納率」（Suggestion Acceptance Rate，SAR）：人類實際採納的代理建議所佔的百分比。80% 或更高的目標，代表代理的推理夠好、值得被聽取；低於 60%，代表這個代理正在產出雜訊；高於 95%，代表這個代理過度保守，只是在提供人類本來就會做的事。SAR 是 L2 的指標，也是判斷是否準備好邁向 L3 的關卡。

L3，有邊界（政策鎖定）。可觀測性加上了橫跨服務的情境敘事與因果關聯覺知，拓撲圖是可查詢且經過驗證的。推理變成多步驟的：代理能夠拆解一個問題，在步驟之間保持短期的工作階段記憶，並產出結構化的候選行動。授權允許對低風險、預先核准的行動進行自主執行，由執行平面契約上的政策即程式碼把關。治理平面正式運作，在執行期依政策評估提案。這是第一個真正的自主性門檻。這個等級的主要指標，是「自主解決率」（ARR）落在 20-40% 的範圍內（大多數決策依然升級處理，但有相當一部分自主執行），以及「校準誤差」（CE）低於 25%（代理宣稱的信心，與它觀測到的成功率有良好的對齊）。行動契約有版本控管，自主行動的逆轉是自動的。「迴圈之上監看」的角色，成為人類參與的主導模式。

L4，適應式（目標導向）。可觀測性支援橫跨服務的環境式漂移感知，通常透過組合了拓撲、擁有權與歷史模式的知識圖來實現。推理變得具反思性：代理會自我批判自己的提案，跨事故（而不僅是事故內）學習，並依照 DRAL「學習」這一拍調整自己的假設產生方式。授權變得動態：代理依照意圖與政策的目前狀態選擇戰術，而不是依照一份固定的操作手冊。治理變得風險適應性：治理平面的政策本身，被目前的 SLO 狀態參數化，讓自主性在校準良好時擴大、在校準不良時收縮。ARR 上升到 40-70% 的範圍，推理延遲（RL-SLO）變得可強制執行且可見。系統此時是在適應，而不是在重複，人類的角色進一步移往「迴圈之上」的意圖設計。

L5，系統性（自主生態系）。可觀測性涵蓋系統的完整語意情境，包括跨租戶覺知，以及代理彼此之間的關係。推理發生在彼此協作的代理之間：拓撲代理、發布代理、商業影響代理、資源配置代理等，透過結構化的移交進行協調（第十四章展開這些協調模式）。授權延伸到全端優化，包括在當責邊界限制內，對服務與政策進行自主重新設定。治理包含不可否認的稽核帳本，通常經過加密簽署，讓稽核軌跡本身在結構上就能防止竄改被察覺。ARR 超過 70%。L5 的關卡指標，是「溯源率」（Grounding Rate，GR）高於 99%：能夠端到端重建其證據鏈（訊號、假設、政策、契約）的自主行動所佔的百分比。在這個等級，可靠性不再是反應式的，而是在團隊宣告的限制內自我維護的。實務上，極少組織運作在這個等級——這套模型之所以包含這個等級，是為了描述如果它們真的達到了，會是什麼樣子。

第 3.6 節的五大旗艦 SLO，對應到這些成熟度等級，是作為「關卡」，而不是「目標」。ARR 隨成熟度等級上升而上升；DQ-SLO 隨成熟度上升（一個更成熟的系統，出手時做出更好的決策）；RL-SLO 只有在 L3 才變得可強制執行，在 L4 才變得有意義；AE-SLO 隨行動目錄與政策的品質而上升；CE 是唯一一項必須在每個等級都維持低點的 SLO——過度自信的推理，在任何成熟度下都是危險的。建議採納率是 L2 專屬的關卡，溯源率是 L5 專屬的關卡。在某個特定等級上，一整套代理式 SLO 的表現，就是「這個等級可量測的就緒度長什麼樣子」這個問題的答案。

信任天花板值得一段更深入的說明，因為它會塑造團隊該如何規劃自己的導入計畫。L2 → L3 的轉換，不是一個隨著代理推理能力自然改善而水到渠成的技術步驟，而是一項離散的組織決定：第一次授予代理自主的寫入權限。這個決定，要求結構性的安全機制（治理平面、行動契約、自動逆轉、校準過的信心）在同一時刻全部就緒。許多團隊在四項機制中只具備三項的情況下嘗試這個轉換，然後發現，缺失的那一項，正是第一次自主失敗降落的地方。這種對稱性毫不留情——一個產出校準良好提案的推理平面，無法彌補一個缺失的治理平面；一個擁有健全行動契約的執行平面，無法彌補從目錄中溜出的不可逆行動；一個擁有強大代理式 SLI 的訊號平面，無法彌補尚未依照結果驗證過的信心模型。這四項機制，在 L3 都是必要的，且必須同時具備——這正是這個轉換之所以困難的原因。

關於團隊該如何使用這套模型，有幾點實務上的觀察。第一，成熟度在一個組織裡不會是均勻的。一支運行第一級服務的團隊，可能在那項服務上處於 L3，同時在第二級服務上處於 L2，在其他一切上處於 L1。這是健康的——這套模型是要依服務、依工作流程來套用，而不是作為一張組織記分卡。第二，進展不是單調遞增的。一項服務可能運作在 L3，然後因為 CE 上升超過了 L3 的門檻，而暫時退回到 L2——這也是健康的。這套架構優雅地降級自主性的能力，正是讓更高的等級能夠被安全運作的關鍵。第三，這套模型描述的是就緒度，而不是規範步調。一支真正處於 L2 的團隊，不會單靠野心就在一季內變得「L3 就緒」——那些基質工作（訊號契約、行動契約、政策即程式碼、代理式 SLI 儀表化）需要花它該花的時間。一支試圖跳過步驟的團隊，會發現自己陷入第 3.8 節的那些失效模式。

等級之間的邊界，往往也是這套架構最大投資的落腳處。L1 → L2 的轉換，大多是可觀測性工作：標準化標籤、訊號 schema、擁有權中繼資料。L2 → L3 的轉換，是架構性的轉換：治理平面投資、行動契約、政策即程式碼，把推理平面從諮詢模式升級為有邊界的自主模式。L3 → L4 的轉換，是學習性的轉換：DRAL「學習」這一拍跨服務正式運作，校準變得具適應性，推理變得具反思性。L4 → L5 的轉換，是協調性的轉換：多個代理協同工作、加密稽核、全端優化。每一次轉換，都有自己典型的工作，明確地為這次轉換命名，正是團隊把正確資源分配到正確階段的方式。

這套成熟度模型，也是本書其餘部分安排自身期望的方式。第五章談事故應變，為它的標準情境假設了 L3 或更高；第十一章談有邊界的自主性，為它對動態護欄的討論假設了 L4；第十四章談多代理協調，為它最具野心的模式假設了 L5。讀者可以用這套模型來定位自己的系統，辨識哪些章節描述的是自己目前的運作模式，哪些章節描述的是自己正試圖成長進去的模式。正是這一點，讓這套模型對實務工作者真正可用，而不只是描述性的。它是一個羅盤，不是一張記分卡。

4.10　本章總結

架構，是代理式可靠性裡決定其他一切能否被真正部署的那部分。沒有它，第二部裡的工作流程只是憧憬；有了它，它們才變成工程工作。四個平面、人在迴圈中的控制迴路、成熟度模型，是第二部每一章都會取用的結構性遺產。第五章談事故應變，會透過這些平面追溯 DRAL 迴圈在一個標準情境裡的路徑。第六章談交付，會把部署當成一連串由治理平面評估的行動契約。第七章談混沌，會把 BFI 當成一門透過有邊界行動契約執行的推理平面紀律。第八章談事前工作，會讓訊號平面以預測模式、而不是反應模式運作。每一章工作流程，都假設這套架構已經存在；而這套架構，也只有在一支團隊能把它畫出來、建構它、並在符合自身情境的成熟度等級上運作它時，才真正重要。

本章「沒有」主張的是：這套架構是一件已經完成的工作。四個平面是結構語法，為某個特定環境設計具體契約、政策與代理的工作，才是團隊會花掉大部分時間的地方。成熟度模型說明每個等級何時可以安全運作，從一個等級走到下一個等級的工作，大多是不起眼的基礎架構：schema、契約、政策即程式碼、校準儀表化。人在迴圈中的控制迴路是正確的框架；為某個特定團隊設計具體的意圖宣告與政策包的工作，是持續進行的。這一切都不是「隨插即用」，全部都是工程工作，做得好會複利累積，被忽略則會腐蝕。

第一部在此收尾。三章下來：第一章命名了為什麼以人類為中心的可靠性，無法擴展到這個產業如今所到達的地方；第二章命名了未來十年可靠性工作運行所在的可觀測性基質；第三章命名了把觀察轉化為學習的韌性迴圈，以及讓這個迴圈可量測的五大旗艦 SLO；本章命名了承載這個迴圈的架構，以及為它的導入定速的成熟度模型。這四章合在一起，是代理式可靠性工程的概念核心。第二、三、四部裡的一切，都會回頭引用其中之一。內化了這四章的讀者，能在自己的環境裡建構、運作、演進代理式可靠性；沒有內化的讀者，會發現接下來的工作流程那幾章，比它們原本需要的還要難——不是因為這些工作流程本身困難，而是因為它們假設了一個原本應該在這裡被打下的基礎。

下一章，是這套架構第一次遇上一個熟悉的 SRE 工作流程的地方。事故應變，是這個產業裡被最切身理解的可靠性實務，也是代理式可靠性工程最明顯能證明自己價值的地方。檢驗這套架構是否已被內化的方式，是看那一章工作流程讀起來，是不是像是在一個你已經理解的形狀上做精煉，而不是要吸收一套全新的框架。如果你不查閱本書，就能畫出四個平面、DRAL 迴圈與五項 SLO，接下來的工作流程那幾章會彼此複利累積；如果你還做不到，現在正是翻回去、把它們鞏固起來的時候。