第八章
從變更到信心——代理式交付管線

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

如果事故應變是自主性在壓力下被檢驗的地方，交付就是自主性在意圖之下被檢驗的地方。大多數可靠性失敗，不是始於事故期間，而是始於變更期間——一次昨天還正確、今早卻錯了的設定調整；一次比理解速度更快的推出；一次技術上正確、脈絡上卻錯誤的部署，因為它降落其上的那套系統，自這次變更被撰寫以來已經漂移。變更本身很少是這個錯誤，錯誤通常是「這次變更遇到的系統」與「這次變更被測試所依據的系統」不同，而管線裡沒有任何東西注意到這一點。

本章是第二個試煉場，因為在一個重要的意義上，交付是兩個工作流程裡較容易的那一個。SRE 團隊早已在自己的管線裡接受了大量自動化——大多數現代工程組織，都在運行帶有確定性建構步驟、有把關的晉升，以及自動回滾掛鉤的 CI/CD。基質早已到位。當交付變得代理式時，改變的不是底層管線，而是運行在它之上的決策層——評估「這個變更」，在「這個時刻」，對照「這個系統狀態」，是否應該以原本計畫的方式發布。管線依然執行，改變的是「它如何執行」這個決策，變得聰明起來。

交付，也是這套架構最直接回報自己投資的地方。事故應變處理的是失敗發生「之後」；交付處理的是失敗發生「之前」。第四章那同一套四個平面，能偵測生產環境的惡化，如果被接上同一套機制來評估變更，也能偵測一次部署的惡化。第三章那同一套五大旗艦 SLO，能量測系統在事故期間如何推理，也能量測它在發布期間如何推理。核准一次節流的同一個治理平面，也核准一次推出。代理式交付大部分的工程工作，不是新的，而是既有的架構被指向了一個不同的工作流程，而把它指向那裡、且指得好的紀律，正是本章要展開的內容。

本章要安裝的東西，數量不多，後果卻很大。「決策感知交付」（decision-aware delivery），是本章的框架概念；「變更意圖」（change intent），作為附掛在每一次變更上、機器可讀的第一等產物；「變更風險分數」（Change Risk Score，CRS），本書最乾淨的一個實作公式，是把一次結構化的變更翻譯成一個系統其餘部分能據以行動的結構化風險數字的產物；「測試代理」（Test Agent），正式完整登場，是推理平面裡把驗證當成一個持續性控制迴路、而不是一道部署前關卡來運行的角色；四種被具名的交付模式，把這些原語組合成可重複使用的形狀。讀完本章，讀者會看見，交付不是一條單向的管線，而是一套決策系統：變更意圖進入，風險分數被計算，護欄被套用，行動被提交，結果被觀察，學習被擷取——正是第三章那同一套 DRAL 迴圈，套用到它最直接回報自己的那個工作流程上。

一開始就值得點名的另一件事，是交付正是 SRE 團隊早已接受最多自動化的工作流程，這正是它成為第二部第二章適當人選的原因。管線、自動化測試、部署協調器、流量轉移機制——這些在 2026 年都是已被正規化的技術。經常拖慢事故應變代理式導入的文化阻力（擔心代理會在壓力下做出危險的事），在交付裡的表現不同，因為代理做的不是驚慌下的決策，而是帶著校準過信心的例行決策，團隊能在任何高風險變更通過之前，先花幾週時間，以低賭注觀察這套系統做這些決策。交付，是建立這套架構其餘部分運作所需要的信任的工作流程。一支運行了一季 L3 交付的團隊，擁有把 L3 擴展到事故應變的營運信心；一支試圖在從未運行過 L3 交付的情況下、直接從 L3 事故應變開始的團隊，是在要求自己的架構在還沒證明它能在沒有壓力的情況下表現良好之前，就先在壓力下表現良好。順序很重要，第二部的順序是刻意安排的。

6.1　從靜態管線到決策感知交付

CI/CD 沒有壞。它是過去二十年最成功的工程實務之一，為軟體交付帶來了可重複性、速度與信心，大多數現代系統沒有它就無法運作。本章不會取代 CI/CD，而是要延伸它。值得謹慎點名的限制，不是「管線存在」這件事，而是「管線被設計來做什麼」，以及「管線從來就沒有被設計來做什麼」，以及這兩者之間的邊界，在 2026 年究竟落在哪裡。

傳統管線擅長的是執行：它們驗證程式碼、建構產物、跑測試、強制執行格式，並確保變更一致地流過各個環境。它們能很好地回答一個問題：這個變更「能不能」被成功執行？它們並不是被設計來回答經驗豐富的工程師在核准一次發布之前早已在問的那些更廣泛的問題：系統目前是否夠穩定，足以承受這次變更？過去一小時是否發生過相關的事故？我們是否運作在 error budget 之內？考量到流量模式一夜之間發生了變化，這次變更是否符合目前的意圖？這次變更要上線的系統，其依賴是否剛剛被打了修補程式、讓這次變更的測試已經不再能代表生產環境？這些問題不是被疏忽而忽略的，它們原本就在 CI/CD 最初的設計範圍之外，因為最初的預期是人類會處理它們。在現代規模下，這個假設已經無法可靠地成立。

大多數與交付相關的可靠性問題，不是來自管線的故障，而是來自管線精確地做了它被告知要做的事——只是在一個這麼做並不安全的時刻。錯誤的變更，在錯誤的時間，在錯誤的條件下。管線完美地運行了，本來會發現問題的發布工程師，正在開另一場會議；擁有那個即將失效的依賴情境的資深待命人員，剛好不在班上。這次變更，技術上是正確的，脈絡上卻是錯誤的，而這份脈絡上的錯誤，對管線而言是不可見的。這正是決策感知交付要填補的落差，而這道落差不在管線裡，而在管線之上——在那個決定「對於這個特定變更、在這些特定條件下，這條管線應該如何表現」的那一層。

這個重新框架，說起來很直接：交付是一個「決策介面」（decision surface），不是一條純粹的執行路徑。決策介面，是任何在資訊不完整的情況下採取不可逆行動的點。交付，是任何系統裡最重要的決策介面之一，因為一旦一次變更被發布，系統就必須承受它的後果。決策感知管線，讓這個介面變得明確——它們把系統情境帶進工作流程裡，依照目前條件評估變更，並調整交付的進行方式。執行依然是自動化的，判斷則變得可觀察。代理在決策點內部參與，在宣告好的意圖與政策之內運作；人類定義目標、限制條件，以及可接受的風險；系統在這些邊界之內進行推理。正是這一點，讓自主性變得安全，而不是魯莽。

值得點名的架構後果，是決策感知交付不需要一套全新的管線產品，它需要的是既有的管線，在特定的幾個點上，向決策層發出呼叫：部署開始之前、流量爬升之前、晉升到完整生產環境之前、回滾決策之前、宣告一次發布成功之前。在每一個點上，管線都對這套架構的治理平面問同一個問題：根據目前的狀態、變更意圖、計算出的風險、驗證證據，以及相關政策，我現在被授權採取什麼行動？治理平面以一小組結構化回應之一作答（繼續、放慢、暫停、升級、回滾），管線執行這個回應。管線保持簡單，決策被獨立擷取、獨立稽核、獨立學習。發布代理（在第 5.3 節以客串身分被介紹過），正是推理平面裡擁有這場對話的代理，也是本章讓它終於贏得自己完整角色的地方。

這個整合也是漸進式的，正是這項特質，讓已經擁有可運作管線的團隊能夠可行地採用它。一支團隊可以從加入單一一個決策點開始：晉升到完整生產環境這一步。管線依然一如既往地運行 CI/CD，但最終的晉升，現在會諮詢治理平面——治理平面讀取 CRS（在 6.3 展開）與測試代理的驗證證據（在 6.5 展開），並回傳一個授權。如果團隊的 CRS 與驗證層還不成熟，早期的決策會很保守——系統大多時候會要求人類核准，團隊則把這些核准當成收緊政策的設計回饋。隨著基質成熟、資料累積，自主授權率會上升。團隊沒有重建自己的管線，他們只是加入了一個諮詢步驟，並隨時間讓它的自主性成長。這正是第 4.9 節的成熟度模型在交付裡的樣子：L2 是這個諮詢步驟以諮詢模式運行；L3 是這個諮詢步驟自主授權最常見的部署；L4 是這個諮詢步驟依照觀測到的結果調整自己的門檻；L5 是這個諮詢步驟透過風險輪廓感知的金絲雀規模設定，搶先制止壞的變更（第 5.10 節的 L5 情境）。

與另一種替代方案的對比，值得點名。有些團隊把代理式交付當成一次整體替換來對待：拆掉既有管線，安裝一個有主見的代理驅動平台，重新訓練團隊。這種做法幾乎總是失敗的，因為新平台所仰賴的工程基質，正是團隊原本就需要在自己既有管線裡成熟起來的同一套基質。決策層才是真正重要的工作，底層的管線只是一項商品。一支先在自己已經擁有的任何管線之上投資決策層的團隊，會在兩季之內運作在 L3 成熟度；一支先投資平台的團隊，會先花兩季做平台遷移，然後才開始對決策層做任何投資。第四章的架構教訓在這裡直接適用：結構是不變量，實作是在地的。結構，就是四個平面與 DRAL 迴圈；管線，只是執行平面在交付工作流程上的一種表現形式。

6.2　表達變更意圖的框架

決策需要意圖。傳統管線執行指令，它們不理解一次變更為什麼存在、它意圖產出什麼結果，或在發布當下適用什麼限制。人類隱含地把這份情境放在腦中，一旦某個不是作者的人必須對這次變更做出決策，這份情境就會流失。如果我們希望交付系統能夠推理，我們就必須給它一些具體的東西讓它據以推理，那個東西，就是變更意圖：一份附掛在每一次變更上、作為第一等產物的目的、期望與限制條件的結構化宣告。

變更意圖，回答經驗豐富的工程師早已本能地在問的四個問題：這次變更試圖達成什麼？什麼結果定義了成功？現在什麼程度的風險是可接受的？哪些限制條件不能被違反？這些問題不是新的，新的是這些答案變得機器可讀。這份意圖，會隨著變更一起流過管線，在每一個決策點都被檢視，並提供本章其餘機制運作所在的基質。6.3 的 CRS 從意圖讀取，6.5 的測試代理對照意圖驗證，6.7 的交付模式依照意圖選擇策略。沒有一份明確的意圖產物，這一切都無法運作；有了它，一切都可以。

一份實務上的變更意圖宣告，有五個欄位。「目標」，用系統術語（而不是任務術語）命名這次變更試圖產出的結果（「降低搜尋的 p95 延遲」，而不是「實作搜尋最佳化」）。「成功標準」，以具體的指標、狀態，或條件，宣告能確認目標已經達成的可觀察訊號。「風險容忍度」，宣告發布期間與之後，可接受的不穩定或惡化程度。「範圍與爆炸半徑」，宣告預期會受到影響的服務、環境，以及使用者群體。「限制條件」，宣告無論結果如何都不能被跨越的硬性限制。合在一起，這五個欄位，是一次變更要成為決策感知管線有用輸入所必須宣告的最低限度——少於這些，下游機制就必須推斷缺失的欄位，而這正是這套架構原本要消除的組裝工作。

意圖，只有在被當成一個有版本控管、可審查的產物來對待時，才會變得可操作。這意味著意圖存在於工程系統早已信任的同一批地方：原始碼控管、pull request 範本、發布中繼資料。引入這次變更的 pull request，是意圖宣告自然的所在地，因為審查程式碼的審查者，也正是應該審查「這份意圖是否乾淨」的人。CI 裡的一個 schema 驗證步驟，會在變更抵達決策層之前，就攔截住形式不良的意圖。結果是，意圖隨著變更一起流動，作為程式碼被審查，作為程式碼被版本控管。有幾種實作模式是可行的：意圖可以是服務儲存庫裡的一個檔案，由 CI 渲染成一個結構化產物；可以被儲存在一個服務目錄裡，在交付時被引用；也可以被表達成一個由 OPA 風格引擎評估的政策輸入。選擇取決於團隊既有的工程形狀，重要的是這份紀律：意圖是一項產物，不是一場對話，也是本章其餘機制據以推理的單位。

一個具體的範例能釐清這個格式。一次優化搜尋延遲的變更，可能攜帶這樣的意圖：

change_intent:
  objective: "Reduce p95 latency for search requests"
  success_criteria:
    metric: search_latency_p95
    target: "< 300ms"
    evaluation_window: 30m
  risk_tolerance:
    max_error_rate_increase: 0.2%
    auto_rollback_threshold: 0.5%
  scope:
    service: search_api
    environment: production
    deployment_strategy: canary
    affected_users: "all_authenticated_search_traffic"
  constraints:
    error_budget_floor: 95%
    time_window: business_hours_only
    no_other_concurrent_search_deploys: true

這份意圖很小（十二行結構化的 YAML），很具體（數字，不是形容詞），而且可被檢視（任何審閱這個 PR 的人類，都可以問為什麼回滾門檻是 0.5%、而不是 0.3%，作者則必須為這個數字辯護）。它也正是 6.3 的 CRS 會讀取的輸入、6.5 的測試代理會據以驗證的對象，以及（第 5.8 節的）學習代理會在發布後拿來對照實際結果做比較的依據。

一種值得標記出來的常見失效模式，是把意圖隱含地嵌入管線邏輯或部署腳本裡。當意圖與實作糾纏在一起時，它會變得不透明且脆弱——管線無法演進，除非破壞掉那些把意圖編碼進腳本裡的變更；決策層也無法從沒有明確宣告意圖的程式碼裡讀出意圖。把意圖與實作分開，讓同一套交付系統能在不同條件下表現出不同的行為，而不需要重寫管線。管線保持穩定，意圖自我調適。這個區隔，正是讓「適應性交付」得以在不陷入混亂的情況下實現的關鍵，也是本章少數不容妥協的設計決定之一。一套意圖存在於腳本裡的交付系統，最終會以沒有人能完整重建的方式漂移，而它上方的代理層，會繼承這份漂移。

6.3　一套可重複使用的變更風險評分模型

一旦意圖變得明確，交付系統就面對一個無可迴避的問題：這次變更現在有多冒險？大多數團隊以非正式的方式回答這個問題——資深工程師掃視儀表板，發布經理回想近期的事故，團隊仰賴經驗與直覺。這份直覺很有價值，但它同時也是不透明、不一致，而且代理不可能安全套用的。如果交付是一個決策介面，風險評估就必須是明確的、可觀察的、可重複的。「變更風險分數」（Change Risk Score，CRS），為人類與系統都能據以推理的不確定性，提供了一套共享的語言。它是本書最乾淨的一個實作公式，本章其餘篇幅都運行在它的輸出之上。

CRS 不是一次確定的失敗預測，而是決策當下系統脆弱程度的一張快照。同一次變更，在不同時間，合理地可以有不同的分數：星期二上午十一點是 32，星期五下午四點是 67，星期一上午十點是 51。這個分數會依照目前的條件自我調適，因為條件本身就是輸入的一部分。這個分數的工作，不是保持穩定，而是保持誠實。一個忽略條件的穩定分數，是一個沒有人能據以行動的數字；一個追蹤條件的即時分數，則是交付系統用來選擇自己行為的一個控制訊號。

CRS 有四個組成部分，每一個各自評分 0 到 100，以加權和的方式組合起來。公式：

CRS = (Intent Sensitivity × 0.3)
    + (System Health Risk × 0.3)
    + (Blast Radius × 0.2)
    + (Historical Volatility × 0.2)

每一項組成，回答一個經驗豐富的工程師早已在問的不同問題。「意圖敏感度」（Intent Sensitivity），回答「相對於宣告的目標，失敗的代價會有多高」，它是從意圖宣告的範圍與限制條件計算出來的——一次針對營收關鍵服務第一級延遲的變更，敏感度高；一次針對內部工具的變更，敏感度低。「系統健康風險」（System Health Risk），回答「現在是不是一個好時機」，它是從即時訊號計算出來的：SLO 合規性、error budget 燃燒速度、飽和度指標、近期事故活動。當系統平靜時，同一個變更更安全；當系統承壓時，即使是一次小變更也可能引發連鎖反應。「爆炸半徑」（Blast Radius），回答「失敗可能傳播多遠」，它是從變更宣告的範圍與拓撲圖（拓撲代理為事故應變所維護的同一張圖）計算出來的——一次針對單一實例的金絲雀，與一次共享平台的變更，本質上是不同的。「歷史波動性」（Historical Volatility），回答「類似的變更過去是否造成過問題」，它是從學習代理對這類過去變更及其結果的紀錄計算出來的——有些類型的元件經常失效，有些幾乎從不失效，這份資料編碼了這種組織記憶。

選擇這四項組成的原因，是它們涵蓋了經驗豐富的事故指揮官在核准一次有風險的發布之前，實際會評估的維度。其中兩項是變更本身的特質（意圖敏感度、爆炸半徑），另兩項是「系統遇上這次變更」的特質（系統健康風險、歷史波動性）。這個結構，強迫這個分數對兩者都誠實：一個承壓系統裡的低風險變更，帶著一份只看變更本身的分數會漏掉的真實風險；一個平靜系統裡的高風險變更，帶著的風險，比只看變更本身的分數所暗示的要低。同一次變更，能在星期二上午得 32 分、在星期五下午得 67 分，正是因為四項輸入裡有兩項會回應目前的條件。正是這一點，讓這個分數能作為一個控制訊號來使用，而不是一個靜態標籤。

這些權重不是神聖不可侵犯的，結構才是。團隊應該預期，隨著時間過去、依照自己的證據重新校準這些權重，第 6.8 節會展開這麼做的紀律。重要的是，這四項組成都被誠實地計算出來，各自能被獨立檢視，最終的分數也能被回頭稽核到它的輸入。當一次發布被一個 67 的 CRS 限制住時，工程師能看出是哪一項組成驅動了這個分數（考量到星期五下午四點的情境，大概是系統健康），並在需要時質疑它。這個分數不會封鎖這次發布，它只是為決定「這次發布如何進行」的政策提供資訊——這次發布不是被分數「核准」或「拒絕」，而是被分數「塑形」：哪種推出策略被選用、套用什麼程度的驗證嚴格性、提交它需要什麼授權層級。

change: optimise_search_latency
intent_target: search_api (tier-1)
current_system_state: healthy
recent_incidents: none in past 24h
similar_changes_volatility: low (12 deploys in past 90 days, 0 incidents)
CRS_components:
  Intent_Sensitivity: 60    # tier-1 service, latency-sensitive, but well-scoped and reversible
  System_Health_Risk: 18    # SLOs green, error budget at 96%, no concurrent incidents
  Blast_Radius: 45          # affects all authenticated users, but canary strategy limits exposure
  Historical_Volatility: 15 # shipped 12 times without incident; the change class is well-known

CRS = (60 × 0.3) + (18 × 0.3) + (45 × 0.2) + (15 × 0.2)
    = 18.0 + 5.4 + 9.0 + 3.0
    = 35.4

System_Health_Risk: 72  # recent incident, dependency stressed, error budget burn elevated
# all other components unchanged

CRS = (60 × 0.3) + (72 × 0.3) + (45 × 0.2) + (15 × 0.2)
    = 18.0 + 21.6 + 9.0 + 3.0
    = 51.6

這次變更的內容並沒有變得更危險，是這套系統變得更不安全，適合被改變。CRS 讓這一點變得可見，交付行為也隨之自我調適，而不需要任何人明確地注意到這件事。

兩項營運特質在實務上很重要。第一，這個分數是即時的。不同的組成，以不同的節奏更新：意圖敏感度與爆炸半徑，只有在變更定義改變時才會改變；歷史波動性，隨著事故累積而緩慢更新；系統健康風險，隨著遙測資料流動而持續更新。整體分數，會在任何輸入改變時重新計算，而交付決策諮詢的是目前的分數，而不是變更最初被撰寫時的分數。一次早上還安全的發布，如果條件在稍後惡化，可能會放慢或暫停，不需要變更的作者做任何事。第二，是平滑處理。一個即時的分數，必須夠穩定，不會因為雜訊而振盪——基於健康度的輸入，是依短期滾動視窗計算出來的，而不是瞬時的尖峰；門檻使用遲滯機制，讓小幅波動不會讓交付行為反覆翻轉。這個分數對訊號有反應，不對警報疲勞有反應。

值得點名的紀律是：CRS 是一個「放大器」，不是一個起點。如果底層能力薄弱，這個分數放大的是雜訊，不是洞見。在 CRS 產出有用的輸出之前，前幾章的幾項基礎必須先到位：明確的服務擁有權（第二章）——沒有它，風險無法被指派；決策級遙測（第二章）——沒有它，系統健康風險會振盪，並產生誤導；拓撲圖（第 2.4 節）——沒有它，爆炸半徑只是瞎猜；意圖即程式碼（6.2）——沒有它，意圖敏感度無法被推斷；變更可見性與歷史（發布代理的事件串流）——沒有它，歷史波動性是空的。一支處於 L1 成熟度、卻把 CRS 計算器硬接到自己管線上的團隊，會在兩週之內發現，這個分數正在產出雜訊，因為它所仰賴的基質還不是決策級的。第 4.9 節的成熟度模型，是「CRS 何時變得有用」的誠實地圖：L3 是自主的、由 CRS 驅動把關的下限；L2 可以把 CRS 當成一個由人類解讀的諮詢訊號；L1 應該先投資基質，再加入這個分數。

6.4　預測影響與強制執行護欄

一個風險分數，告訴系統一次變更有多脆弱，卻還沒有告訴系統該拿它怎麼辦。沒有護欄，這個分數只是一個人類仍然必須在壓力下解讀的諮詢訊號；有了護欄，這個分數就變成了一套受控交付系統的輸入，這套系統會依照分數所說的內容，調整自己的行為。本節，正是這個分數翻譯成行為的地方，這個翻譯是結構化的、事先議定的、可被檢視的。

護欄不是核准，它們是預先議定的限制條件，規範變更被允許如何流過這套系統。人類事先、在一個平靜的房間裡、經過審慎考慮，決定在哪些風險等級上，哪些行為是可接受的；代理則在壓力下，一致且持續地強制執行這些決定。這讓當責保持在人類手中，同時讓執行變得系統化。擁有這項服務的團隊，撰寫把 CRS 區間對應到交付行為的政策；治理平面在執行期評估這條政策；發布代理透過管線強制執行被選中的行為。這一切都不需要人類在一次例行發布期間身處迴圈之中——原本會讓人類有價值的那份工作，早已在幾週前、政策被撰寫的時候完成了。

一份實務上的護欄政策，有三個元素：「風險分帶」（risk bands），把 CRS 的離散區間對應到運作模式；「行為限制」（behavioural constraints），在每個分帶內套用到推出、驗證與執行的具體限制；「覆寫條件」（override conditions），明確規定即使在某個分帶的預設情況下，什麼時候需要人類介入。一個第一級服務典型的結構：

guardrail_policy:
  service: search_api
  tier: 1
  risk_bands:
    low:
      crs_range: [0, 30]
      behaviour:
        rollout_strategy: standard_canary
        canary_traffic_ramp: standard (5% → 25% → 50% → 100%)
        validation_strictness: normal
        auto_rollback_sensitivity: standard
        human_approval_required: false
    medium:
      crs_range: [31, 60]
      behaviour:
        rollout_strategy: extended_canary
        canary_traffic_ramp: cautious (2% → 5% → 15% → 50% → 100%)
        canary_hold_time_per_step: 15min
        validation_strictness: elevated
        auto_rollback_sensitivity: tightened (50% threshold)
        human_approval_required: false
    high:
      crs_range: [61, 80]
      behaviour:
        rollout_strategy: shadow_then_canary
        canary_traffic_ramp: minimal (1% → 5%, hold for review)
        validation_strictness: strict
        human_approval_required: true (release-engineer-on-call)
    critical:
      crs_range: [81, 100]
      behaviour:
        rollout_strategy: blocked
        human_approval_required: true (service-owner + on-call)
        deferral_recommended: true

確切的門檻與行為，是團隊在地的選擇。重要的是，這份政策是明確的、可見的、事先議定的，並且被自動評估。當 6.3 那個範例裡的搜尋延遲變更得分 35.4 時，medium 分帶自動觸發；當同一次變更在星期五下午得分 51.6 時，medium 分帶依然觸發，只是套用了謹慎的爬升方式。沒有人類需要決定哪種行為是合適的，政策早已事先決定，執行期只是對照即時分數評估。

護欄也需要「在推出期間」更新，而不只是在發布開始時。一次以 CRS 35 進入管線的變更，如果系統健康在推出過程中惡化，它的 CRS 可能會上升到 55。治理平面持續重新評估，推出策略會自動收緊：流量爬升暫停，自動回滾門檻下降，驗證嚴格性提高。變更的作者不需要做任何事，這次發布會在飛行中自我調適，就像第五章裡對事故的回應，會隨著情境覺知物件更新而自我調適一樣。這個架構上的對稱是刻意的：交付與事故應變，都是 DRAL 迴圈，只是訊號不同、行動契約不同，卻運行在同一套機制上。

值得點名的特質，是「影響預測」，正是把好的護欄與遲鈍的護欄區分開來的關鍵。CRS 擷取的是「這次變更有多脆弱」；影響預測擷取的是「如果這次變更失敗，什麼會失效」。商業影響代理（在第 5.4 節介紹過）在此參與，投射這次變更的暴露程度：一次推出時的迴歸，會影響多少使用者，這個流量窗口期間有多少營收處於風險之中，哪些客戶群組落在這次金絲雀的路徑上。護欄政策讀取這兩者：一個高影響窗口期間的中等 CRS，可能需要一個低影響窗口期間的同一個中等 CRS 不需要的核准。這正是二元關卡的架構替代方案——決策，沿著真正重要的維度被分級，而撰寫政策的人類，決定哪些組合需要他們的直接關注。第 11.2 節的動態護欄，會進一步展開這一點，讓政策本身能夠自我調適長期趨勢（一個校準誤差已經連續兩週上升的服務，會自動獲得更緊的護欄；一個成功部署次數已經超過 50 次、沒有事故的服務，則會獲得放寬的護欄）。現階段，架構上的重點是，護欄是政策即程式碼，在執行期被評估，依目前條件調校，且是分級的，而不是二元的。

一項值得點名的細微特質，是護欄也能「在飛行中收窄自主性」。第 5.6 節同一套授權層級機制在此適用：一次以自主執行權限開始的發布，如果條件在推出中途惡化，可能會失去這份授權。一個在部署過程中從中等跨越到高的 CRS，會觸發一次重新評估，政策可能會決定，剩下的晉升步驟現在需要人類核准，即使早期的步驟不需要。發布代理不會對此有異議，它會把這次變化呈現給團隊的待命人員，等待指示。反過來也一樣：一次以升級護欄開始的發布，如果條件改善、CRS 跌回觸發升級的分帶之下，它的護欄也可以被放寬。這套架構是對稱的：自主性在系統掙得它時擴大，在沒有時收縮。團隊的政策宣告這些規則，治理平面強制執行它們，發布代理在它們之內運作。這正是第十一章將要展開、作為第一等架構特質的同一套動態政策模式，只是在交付的脈絡裡，它已經以縮影的形式，最容易被觀察到。

6.5　自主測試與持續驗證迴圈

護欄塑造了一次變更如何被交付，卻還沒有證明系統的行為是正確的。傳統測試作為一道關卡運作：寫測試、部署前執行、通過就上線。這個模型對代理式交付而言是脆弱的，因為代理式交付必須回答的問題不同——不是「這次建構有沒有通過測試套件」，而是「這個系統，帶著這次變更，在即時條件下，是否在自己宣告的意圖之內運作」。這個問題無法在建構時被回答，因為建構時的系統條件，不是發布時的條件，它必須被持續回答，作為一個在變更上線之前、之中、之後都在運行的控制迴路。「測試代理」（Test Agent），是推理平面裡擁有這個迴圈的角色，本節，是它的完整登場。

測試代理帶來的轉變，是從「部署前執行的測試」，變成「變更上線期間執行的驗證」。測試依然有用，測試代理不會取代它們，它加上的，是一個與交付並行運作的持續驗證迴路，對照意圖宣告的成功標準評估即時遙測資料，並在每一個決策點把自己的評估回饋給治理平面。一次變更依然一如既往地通過 CI/CD，測試代理的貢獻，是部署之後發生的事：一個監視器，觀察這次變更對照意圖的行為，累積證據，並產出一個交付決策閘門會在每一步晉升之前諮詢的結構化信心分數。

這個驗證迴圈有四個階段。「期望定義」，直接從意圖宣告的成功標準（6.2 範例裡同一個 target: < 300ms）宣告，如果這次變更行為正確，什麼必須維持為真。「訊號選擇」，選出哪些即時訊號最能確認或反駁這個期望：延遲百分位、錯誤率、依賴健康度、下游系統行為。「評估邏輯」，隨時間、而不是在單一時間點解讀這些訊號，套用滾動視窗、遲滯，以及跨訊號關聯。「回饋行動」，宣告當信心跌破政策可接受範圍時會發生什麼：暫停推出、收緊護欄、觸發回滾、升級給人類。測試代理從變更進入生產環境的那一刻起，持續運行這個迴圈，直到它在生產環境裡待得夠久、足以從主動監控中退役（通常是幾天，對燃燒較慢的變更有時是幾週）。

最值得關注的階段是評估。單點量測在推出期間是脆弱的——金絲雀第三分鐘 p99 延遲的一次瞬間小波動，不應該讓系統驚慌。測試代理使用三項技術來保持評估的穩定：對照基準線的「滾動視窗比較」——目前的量測值，是與變更之前的穩定狀態分布做比較，而不是與一個靜態門檻比較；「變化速率偵測」，而不是絕對值——問題是這個指標是否正朝一個令人擔憂的方向趨勢化，而不是它是否已經越過了一條線；「跨訊號關聯」——單獨的延遲上升是模糊的，但延遲上升，若與上升的錯誤率、以及那個變更服務上升高的 CPU 一起出現，就是相互佐證的證據。輸出不是一個二元的通過/失敗，而是一個附掛著相關訊號的信心分數，結構化為讓治理平面讀取，並隨時間由學習代理（5.8）校準。

把這件事具體化，6.2 與 6.3 裡那個標準的搜尋延遲變更，在測試代理的觀察下：

validation_state:
  change_id: search_api_rel_2026_05_14_001
  intent_success_criteria:
    metric: search_latency_p95
    target: "< 300ms"
    evaluation_window: 30m
  live_observation at t=0:15min:
    current_search_p95: 247ms (well within target)
    baseline_search_p95: 245ms (matched within noise)
    error_rate: 0.003% (stable, no regression)
    dependency_health: payment-gateway healthy, recommendation-api healthy
    cross_signal_correlation: no anomalous patterns detected
    confidence: 0.94 (high confidence the change is behaving as intended)
    feedback_action: continue_ramp (next step: 25% traffic)
  live_observation at t=1:42min, during 25% canary:
    current_search_p95: 312ms (above target, concerning)
    baseline_search_p95: 245ms (no change in baseline)
    error_rate: 0.004% (stable)
    dependency_health: all healthy
    cross_signal_correlation: latency rise is concentrated in canary traffic,
                              not affecting non-canary requests
    confidence: 0.41 (moderate, leaning negative)
    feedback_action: pause_ramp; hold current traffic split; require additional
                     observation before promoting

在 t=0:15 時，這次變更明顯符合意圖，測試代理回報高信心，並授權下一次爬升步驟。在 t=1:42 時，有些不對勁：p95 已經漂到目標之上。測試代理不會驚慌，它把推出保持在原地，蒐集更多證據。這裡跨訊號關聯很重要：延遲上升出現在金絲雀裡，而不是在平行的非金絲雀流量裡，這意味著涉及的是這次變更本身，而不是某個無關的條件。信心下降，回饋行動從「繼續」變成「暫停並觀察」。治理平面讀取這一點，暫停推出並等待——如果延遲穩定下來、信心恢復，推出就繼續；如果沒有，推出就回滾。變更的作者全程收到通知，他們不需要採取行動，但如果他們看見了代理沒看見的東西，他們有覆寫的選項。

值得點名的架構特質，是測試代理讀取的，是與 CRS 相同的那份意圖宣告。6.2 裡的成功標準欄位，是測試代理判定成功的真相來源；風險容忍度欄位，決定測試代理對負面訊號的回應有多激進；限制條件欄位，決定測試代理把哪些行為視為政策違規，無論指標健康與否。這三者，全都是變更作者在 PR 時宣告的，由團隊審查，並由測試代理在執行期據以運作。意圖就是契約，測試代理，是在這次變更於生產環境裡存活期間，強制執行這份契約的監視器。這正是把本章連貫起來的架構對稱：意圖從作者流出，經過 CRS，經過護欄政策，經過測試代理的驗證，經過學習代理的變更後擷取——不同的角色，同一個產物，套用在工作流程的不同節點上。

6.6　決策強制執行與人類控制迴路

第 4.7 節命名了人在迴圈中的三種模式，第 5.7 節把它們套用到事故應變。本節把它們套用到交付上。實質內容不變，改變的是營運節奏，因為發布是有節奏的，而不是驚慌失措的，人類的貢獻，也落在不同的地方。

交付裡的「迴圈之上」，是這次變更被撰寫之前發生的工作——團隊的意圖 schema、他們的護欄政策、他們的 CRS 權重、他們的行動契約、他們的決策閘門設定。這些都不是在發布期間發生的，卻全都在發布期間運作。迴圈之上的人類，對每一次發布的貢獻，是他們幾週前所做的工作，而這份貢獻的品質，決定了本章其餘機制究竟能否自主地運作這次發布。交付裡的「迴圈之中」，依設計而言是罕見的——CRS 分帶與影響預測，被建構成只把高風險的變更路由給人類（6.4 的 high 與 critical 分帶），而這個路由，會在分數與影響預測跨越政策門檻時自動發生。迴圈之中的人類，收到的是一份結構化的資料包：這次變更、它的意圖、它的 CRS、貢獻的組成、建議的策略、替代策略、他們被呼叫的政策理由。他們的決策以秒計，不是以分鐘計，因為組裝工作早已完成。交付裡的「迴圈之上監看」，是大多數工程師一般一週裡所處的位置——他們盯著 SLO，抽樣驗證結果，審查測試代理近期發布的信心趨勢，在資料證明有理時調校 CRS 權重。他們不是在核准每一次發布，而是在觀察核准它們的那套系統，只在系統本身發出「需要介入」的訊號時才介入。

最值得標記的情況，是測試代理的信心在推出中途急劇下降時、CRS 因為系統健康惡化而在部署中上升時，或商業影響代理的暴露估計在飛行中被向上修訂時。依照政策，這些情況每一種都可能觸發升級，發布代理處理升級的方式，與這套架構處理事故的方式相同：它不會自己升級自己的權限，而是把不確定性升級給人類，附帶完整的推理軌跡。人類讀取這個軌跡（幾秒鐘），做出判斷（修改、暫停、回滾、核准繼續），發布代理執行他們決定的內容，這套架構繼續運作。稽核軌跡，把人類的決定與理由，連同代理的一起記錄下來。學習代理擷取這份資料：什麼條件導致了升級、人類在那些條件下做了什麼決定、人類的判斷最終是否被證明是正確的。隨著時間過去，政策的升級門檻，會依照資料所顯示的內容而收緊或放寬。第 5.7 節的框架在此直接適用：人類設計行動被允許的條件，這套架構處理落在這些條件之內的行動，人類處理例外。這個轉變，是從「核准發布」，轉變為「設計發布被允許的條件」。這個轉變，是可以擴展的。

6.7　進階交付模式與失效圍堵

當失敗被允許不受控制地擴散時，自主性就會變得危險。到了本章這個地方，意圖已經被表達，風險已經被評分，護欄是政策即程式碼，驗證持續運行。剩下的問題，是一旦這些原語到位，交付會採取「什麼形狀」。如果我們試圖窮舉每一種形狀，本章會無止盡地擴展下去——這裡的編輯原則，是為那些反覆出現的形狀命名，讓其餘的形狀從組合中浮現。四種模式值得被命名，因為本書其餘部分會引用它們，也因為每一種都適配一種獨特的 CRS 輪廓與意圖形狀的組合。

「先影子、後晉升」（Shadow-then-promote），適用於高 CRS 變更，這種情況下團隊需要生產環境的證據，才會讓任何使用者流量暴露其中。新版本被部署在目前版本旁邊，接收一份生產流量的副本，但不對使用者回傳任何回應。測試代理比較影子版本的輸出與目前版本的輸出；CRS 依照影子版本觀測到的行為重新計算。只有當影子的信心累積了足夠的證據時，推出才會開始讓真實使用者暴露其中。這種模式適合系統健康可接受、但變更的爆炸面很大的高 CRS 情境。代價是重複的執行期環境，好處是代理能在任何使用者面臨風險之前，就在生產條件下學到這次變更的實際行為。最適合用於：重大的演算法變更、關鍵路徑上的依賴版本升級，以及任何測試套件無法完全預測生產環境行為的情況。

「附帶信心把關的金絲雀」（Canary-with-confidence-gating），是 L3 及以上主導的模式，也正是 6.3 到 6.5 裡搜尋延遲範例一直在展示的內容。這次變更部署到一個小型金絲雀群組，測試代理觀察，CRS 即時更新，治理平面依照測試代理的信心與目前的 CRS，決定是否在每個爬升步驟晉升。晉升不是按固定節奏進行的，而是由證據把關的：一個表現良好的金絲雀，會被積極晉升；一個顯示出模糊訊號的金絲雀，會被保持原地；一個正在惡化的金絲雀，會被回滾。這種模式適合護欄政策中間分帶裡大多數的中等 CRS 變更，L3 成熟度下大多數的生產部署，預設都使用它。最適合用於：生產環境行為能以小規模安全取樣的標準服務變更。

「平行決策」（Parallel-decision），適用於高風險變更，這種情況下團隊希望兩條獨立的推理鏈在行動之前趨於一致。推理平面透過兩條不同的推理路徑（不同的提示策略、不同的證據加權、不同的基準線視窗）評估這次變更，治理平面要求兩條路徑都同意，才會授權晉升。這種模式在運算上比單一路徑的推理更昂貴、收斂得更慢，但能大幅降低「自信地犯錯」決策的機率（第 3.8 節的失效模式）。最適合用於：罕見、不可逆的變更（schema 遷移、跨區域容錯移轉決策，以及任何回滾不可能或代價高昂的情況）。第十四章的 L5 成熟度處理，會展開讓平行決策成為生態系特質、而不是單一代理技術的多代理協調模式。

「附帶學習的回滾」（Rollback-with-learning），是把一次失敗的部署轉化為系統模型結構化更新的模式。當一次變更回滾時，學習代理會擷取完整的狀態：意圖、部署時的 CRS、驅動這個分數的 CRS 組成、測試代理的驗證軌跡、回滾觸發條件、觀測到的結果。這份擷取，會餵進這類變更的歷史波動性、CRS 校準模型，以及回滾行動本身的行動有效性評分。隨著時間過去，同一類變更會變得更不容易被誤判分數，不是因為模型變聰明了，而是因為資料變豐富了。一支虔誠地運行「附帶學習的回滾」的團隊，會在六個月後發現，CRS 的校準比採用之初實質上更好，而這正是第 5.8 節封閉學習迴圈在交付脈絡裡的具體套用。

這些模式是可以組合的。一次針對第一級服務的高 CRS、不可逆變更，可能在第一階段使用先影子、後晉升，在晉升步驟之前使用平行決策，在面向使用者的推出使用附帶信心把關的金絲雀，並以附帶學習的回滾作為安全網。每一種模式，命名的是一套獨特的決策紀律；把它們組合起來，正是團隊處理最困難變更的方式。這些名字之所以重要，是因為團隊在設計審查裡討論策略時，需要一套共享的詞彙。一次需要先影子、後晉升的變更，在結構上不同於一次需要附帶信心把關的金絲雀的變更，而在兩者之間做選擇的設計對話，正是那種在幾週後產出良好結果的迴圈之上工作。

6.8　在代理式交付系統裡運作與學習

代理式交付，只有在它隨時間改善時，才會贏得信任。學習代理（第 5.8 節）在這裡同樣閉合了這個迴圈，而且無論這次變更成功或失敗，這個迴圈都會運行。交付與事故應變的結構性差異，在於交付是高流量、穩定節奏的：對一個成熟的工程組織而言，每季有數百或數千次變更，每一次都產出一份結構化的結果紀錄，成為系統模型的輸入。第 3.0 節的複利曲線，在本節裡生死攸關。一支在每次發布之後擷取正確資料、並把它回饋進正確模型的團隊，會看見自己的 CRS 校準變得更銳利，測試代理的信心變得更值得信賴，護欄門檻在資料證明有理的地方收緊、在沒有的地方放寬。一支發布之後就遺忘的團隊，會看見自己的交付系統漸近趨於它最初的校準——這通常是保守的，通常是緩慢的，也通常是團隊最終退回到人工作業的原因。

必須流動的資料並不奇特。在每一次發布之後，學習代理擷取決策紀錄（意圖、CRS 組成、被選中的策略、驗證證據、推出軌跡），並把它與結果紀錄（第一天發生了什麼、第一週發生了什麼、是否有任何事故可歸因於這次變更、意圖裡的成功標準是否真的被達成）配對。這對紀錄餵進四條學習路徑。「CRS 校準」：這個分數的預測，是否符合觀測到的結果？一次得分 35（中低）、卻產出了一次輕微事故的變更，就是這個分數對這一類變更的某項組成權重不足的證據——學習代理會把這個呈現為一項供人類審查的建議調整。「模式選擇」：被選中的交付模式，是否適合這個情況？一次產出回滾的附帶信心把關金絲雀，不必然是模式的失敗，它可能是這個模式正在做好自己工作的證據；一次花了 48 小時影子時間、卻沒有呈現出有用訊號的先影子、後晉升，則可能是「影子對這一類變更而言用力過猛」的證據。「測試代理校準」：驗證信心，是否準確地預測了這次變更的實際行為？測試代理信心評分上的 CE，正是告訴團隊「在某個門檻下，是否該信任代理的輸出」的關鍵。「失效類別回饋」：當一次變更失敗時，它產出了哪一類失效，系統的模型過去是否知道這一類失效？新的失效類別，會餵進混沌代理（第七章），成為假設產生的候選對象；已知的失效類別，則會餵進 CRS 的歷史波動性組成，作為額外的證據。

值得點名的誘惑，是在基質尚未成熟之前，就過度工程化這套學習自動化。一支運行了 L3 六個月的團隊，擁有足夠的資料，可以開始收緊自己的 CRS 權重；一支只運行了六週的團隊則沒有。學習代理的提案，應該以這套架構一般處理自主性時同樣分級的方式套用：低風險調整，附帶審查自動套用（限度內的小幅權重變化、小幅門檻位移）；中風險調整，需要明確的人類核准（新的失效類別特徵、新的模式建議）；結構性調整，需要在設計審查裡審慎討論（CRS 公式變更、新增組成）。保護執行平面在事故應變裡的同一套授權層級，在交付裡也保護著學習代理——校準是受治理的，校準不是代理可以無人監督自由進行的事。

讓本章主張負起責任的營運量測，是同一套第 3.6 節的五大旗艦 SLO，套用到交付上。「自主解決率」（ARR）在交付脈絡裡，量測端到端出貨、不需要人在迴圈中介入的變更百分比。一支在第一級服務上處於 L3 成熟度的團隊，可能跑交付 ARR 60-75%，剩下的依政策路由給人類。「決策品質」（DQ-SLO），量測交付決策（被選中的模式、計算出的 CRS、驗證結果）是否正確，依照這次變更上線後前 48 小時的實際生產環境行為來評估。「推理延遲」（RL-SLO），量測代理從變更就緒到晉升決策，需要花多長時間做出交付決策；對交付而言，這通常以分鐘、而不是以秒計。「行動有效性」（AE-SLO），量測被選中的策略是否產出了預期結果、且沒有附帶損害。「校準誤差」（CE），量測 CRS 分數與測試代理的信心分數，是否符合觀測到的結果——這是交付裡單一最重要的 SLO，因為 CE 的漂移，正是標記「學習迴圈是否已被腐化」的金絲雀指標。與事故應變相同的五項 SLO，同一套架構，套用到一個不同的工作流程上。這套代理式運作模型，在整個可靠性工作的範疇裡是連貫的，而本章對交付的主張，也能以第二部其他一切相同的術語被量測。

6.9　本章總結：交付作為一套決策系統

交付不是一條單向的管線，它是一套決策系統，而這個差異在每個階段都很重要。變更意圖，作為一份由變更擁有者撰寫的結構化產物流入；CRS，依照這次變更要上線所處系統的即時狀態，為這次變更評分；護欄政策，把這個分數翻譯成一套交付策略；測試代理，在這次變更身處生產環境期間，運行一個持續的驗證迴圈；治理平面，依照驗證證據與目前的 CRS，為每一步晉升把關；發布代理，透過管線協調這些步驟；學習代理，擷取結果，並為下一次變更精煉系統的模型。第三章那同一套 DRAL 迴圈，第四章那同一套四個平面，3.6 節那同一套五大旗艦 SLO，套用到一個靠「情境」、而不是靠「驚慌」生存的工作流程上。基質是相同的，套用方式不同，複利曲線正在運行。

本章「沒有」主張管線會消失，它們不會。CI/CD 依然是交付的骨幹，代理式交付大部分的工程工作，是坐落在既有管線之上的決策層，而不是取代它。發布代理不運行這條管線，發布代理在決策點諮詢這條管線，並授權接下來會發生什麼。已經運行著強大管線的團隊，會發現代理式交付的工作是增量式的，而不是破壞性的；運行著薄弱管線的團隊，則會發現，建構一條強大管線的工作，是本章任何內容變得有用的前提。CRS、測試代理、護欄政策、學習代理，全都是對底層管線品質的放大器——它們能讓一條好的管線變得更好，卻無法讓一條壞的管線變好。

第七章是混沌工程。如果交付談的是關於「變更」的決策，混沌工程談的就是關於「不確定性」的決策。同一套四個平面再次出現，同一批代理再次出現（混沌代理將完整登場），第 3.3 節有界故障注入的紀律，被套用為一個持續的學習訊號，而不是一場季度演練。這套架構持續複利累積，工作流程那幾章，持續精煉這套架構在遇上特定營運議題時所採取的形狀。不同的議題，同一套架構。第二部收尾之前，還有三個工作流程。