這系列引用最多次的東西
不是 spec，也不是哪個 repo
是一本書的四個名詞
今天把那四個名詞
放回它們原本的位置

前一天在盤點「要盯 agent 哪些維度」的時候，又撞到一次 histogram 桶太粗的老毛病，也順手把「請求成功」跟「證據夠不夠」分成兩件事在看。這幾天講的都是很細的東西。今天往後退一步。

因為這系列從第二階段開始，一路在借一本書的詞：決策級遙測、Signal Plane、信任天花板、靜默腐化、CEL。借得很順，順到我自己都忘了從頭到尾沒有一篇文章，把這本書的骨架完整畫出來過。一個從中間某天點進來的讀者，看到 Signal Plane 這個詞，是查不到的。它不是 OTel 的術語，是這本書的。

那本書是 O'Reilly 的《Agentic Reliability Engineering》（以下簡稱 ARE），還在 early release。我把它的正體中文翻譯放在 agentic-reliability-engineering-zh-tw，下面每一章都會連過去。今天這篇不寫新程式碼，做一件事：把 ARE 的四個 Plane、那個迴圈、那個成熟度模型講清楚，然後對照這系列實際蓋到哪一格。

這系列一直在靠一本書，但沒把它攤開過

先說這本書要解決的問題。它的第 1、2 章（〈Why Reliability Must Evolve〉、〈The Shift to Agentic Engineering〉）花很多篇幅講一個場景：半夜三點，一個資深的 on-call 工程師收到 checkout 路徑的延遲告警，照著 runbook 一步一步查：最近的部署、依賴健康、流量樣態、跨區容量、設定漂移。他在四個 dashboard 之間跳，把一次部署跟一次設定推送對起來，翻 Slack 看有沒有人回報鄰居服務吵鬧，跑一次拓撲查詢結果那個 metadata 服務剛好也在出事的那一區。等他湊出一個假設，影響範圍已經是三倍。

書裡的判斷是：這裡卡住的不是工具，是那個「湊上下文」的人。dashboard 有渲染、runbook 是對的、Slack 串是誠實的，每個系統都做完了自己的事，中間把它們接起來的是人腦，而人腦對現在系統變化的速度來說，結構性地太慢了。自動化沒有解決這件事，自動化讓「執行」變快，不讓「判斷」變快。ARE 這個詞就是從這裡來的：當迴圈中心那個做判斷的，不一定是人的時候，SRE（Site Reliability Engineering）會變成什麼。

舉個現實案例，我看過一個團隊為了壓 on-call 負擔，把告警分組、抑制、路由做成一個內部小產品，專人維護。
客戶是自己，產品是「還能忍受的 on-call」。
花資深工程師的時間去蓋這個，其實就是書裡講的那個認知天花板，只是換了個形狀。

人往哪裡去？書裡叫「移到迴圈上面」（above the loop）：人不再是每個動作的審批者，人去定義意圖、風險容忍度、影響範圍的上限，然後看系統在這些邊界裡跑得好不好。可靠度的衡量標準也跟著變，不只看 uptime，還看系統「在達到 uptime 的路上做的那些決定，品質如何」。

一句話：當迴圈中心不再一定是人

ARE 這本書分三個部分。Part I（第 1 到 4 章）是地基，講認知天花板、觀測性要變成什麼樣子、那個學習迴圈、還有四個 Plane 的架構。Part II（第 5 到 10 章）把同一套架構套到五個熟悉的 SRE 工作流上：事故處理、交付、混沌工程、事故前的預測。Part III（第 11 章〈Governed Autonomy〉、第 12 章〈Simulation-Driven Reliability〉）講受治理的自治跟模擬驅動的可靠度。

這系列到目前為止，全部落在 Part I 的地基裡，而且只碰了其中一塊。下面先把地基講完整。

DRAL：偵測 → 推理 → 行動 → 學習

書裡最常被回頭引用的一個東西，是第 4 章（〈From Chaos to Self-Healing〉）那個四拍的迴圈，叫 DRAL：Detect、Reason、Act、Learn。Part II 每一章開頭都會指著這個迴圈的其中一拍。

四拍裡最容易被跳過的是 Learn。一個會偵測、會推理、會動，但不更新自己的系統，對同一個輸入會永遠給同一個輸出。它復原得快，但沒有變得更可靠，只是變得更會修。書裡把「同一類故障，每次發生都變得更不可能、影響更小、或吸收得更快」當成可靠度的定義，而那個「每次都更好一點」的曲線，就靠 Learn 這一拍撐著。

推理這一拍跟傳統自動化的差別，也是這系列一直在講的那條線：傳統自動化是規則直接映射到動作（延遲超標就重啟 pod），推理是拿多個輸入去權衡（遙測給證據、策略給約束、歷史結果給信心、意圖給優先序），然後吐一組排過序的選項，而不是單一動作。推理的延遲本身就是可靠度的一部分：一個在故障擴散完之後才到的決定，跟沒有決定沒兩樣。

四個 Plane，以及把它們併起來會怎樣

第 6 章（〈The Agentic Reliability Architecture〉）是這本書的核心。它把整個系統切成四個 Plane（平面），刻意不叫 layer（層）。層有上下、有依賴、故障往上傳；Plane 是正交的，各做各的事，各有各的契約跟故障隔離。

這四個 Plane 串成一個一直在跑的迴圈，正好對應 DRAL：Signal 是 Detect，Reasoning 是 Reason，Execution 是 Act，Learn 靠 Execution 把結果訊號吐回 Signal Plane 收尾。Governance 夾在 Reason 跟 Act 中間。

這個切法同時是一份體檢表。書裡點名三種「把兩個 Plane 併在一起」的情況：監控系統直接觸發腳本，是 Signal 併 Execution，中間沒有留給推理的空間；自動化裡埋著 policy 判斷，是 Execution 併 Governance，policy 變得看不見也管不動；而 AI 系統又決定又執行、中間沒有約束，是 Reasoning 併 Execution，這是最危險的一種，因為它把「讓自治保持有界」的那道檢查整個拿掉了。每一種併合都讓速度變快、安全變差。

縫在哪裡：四張契約

書裡有句話我覺得值得記：Plane 跟 Plane 之間的那條縫，才是大部分工程量的所在。四條縫，四張契約：

• signal contract（Signal → Reasoning）：一條訊號代表什麼、Signal Plane 保證什麼（新鮮度、最小觀察窗、可信度）、它是設計來支援哪些決定。Reasoning Plane 讀的是契約，不是原始資料流。契約版本一變，上面就知道。
• candidate action（Reasoning → Governance）：把觸發訊號、主假設、排序過的候選動作、意圖對齊、風險估計、信心分數、需要的授權等級，包成一個結構化的物件。它同時是給人看的稽核紀錄：之後有人問「agent 為什麼那樣做」，答案就是這個物件。
• action contract（Governance/Reasoning → Execution）：一個動作做什麼、前提是什麼、怎麼回滾、什麼算成功。Execution Plane 只能執行目錄裡有的，自由生成動作明確在範圍外。
• outcome signal（Execution → Signal）：動作做完往回吐的訊號（延遲變化、錯誤預算恢復、回滾觸發）。沒有這個，自治沒辦法變好，只能重複自己。

這四張契約，這系列的第二階段實際做出來的是第一張的一部分（contracts.yaml 那份權威 SLI 宣告），其他三張還是文章裡的形狀。

Governance Plane：管的是「准不准」

這個 Plane 對 SRE 背景的人最反直覺，第 6 章跟 第 11 章〈Governed Autonomy〉 都花篇幅在講。傳統維運把治理放在 runtime 外面：變更管理委員會（CAB）、審批流、runbook 把 policy 寫成程序。這些在「動作很少、時間壓力低」的時候有效，在「動作是連續的、時間壓力高」的時候整個垮掉，而 agentic 系統正好跑在後面那種狀態裡。

Governance Plane 的做法是把 policy 搬進 runtime，對每一個候選動作自動求值，用毫秒算完。它問的不是「這個動作對不對」（那是 Reasoning Plane 算過的），是「給定這個提案、這個信心、這個當下條件、這個團隊的 ownership，agent 被允許做這件事嗎」。答案不是只有准跟駁：可以是「照全範圍准」「縮小範圍准」「准但強制通知人」「駁回並升級」。

授權是分級的，書裡列的等級大概是：只觀察 → 只提案 → 執行可逆動作（範圍很緊、自動回滾）→ 執行有界的不可逆動作（回滾不可能，但影響範圍被框住）→ 一律轉人。信心上升、成熟度提升，服務往上爬；信心掉下來（用校準誤差這個 SLO 判斷）或條件變得不尋常，服務往下掉。

從平台工程的角度看，這一 Plane 的重點是：policy 是擁有那個服務的團隊自己寫的，Governance Plane 只是在 runtime 執行它。系統動手的時候，是那個團隊的 policy 讓這個動作變得可行；動作被質疑的時候，系統指向的也是那個團隊的 policy。問責從來沒有轉移，轉移的只是「執行 policy 允許的那些動作」。這跟這系列一路在講的那條線是同一件事：治理是平台團隊提供給產品團隊的介面，不是中央多設的一道關卡。差別只在，這裡的介面消費者是一個會自己動手的東西。

我來回改了很多版 policy 才體會到一件事：把審批從「批准動作」換成「設計動作被允許的條件」，人花的時間不會變少，是換了個地方花。
批准是跟著動作數量長的，設計條件是跟著動作「種類」長的，後者小得多。
但前期那筆設計成本是實的，不會因為「agent 幫你做了人本來做的事」就免費 ^^

CEL：書裡那個，跟我們這個

這系列從第二階段開始一直在用 CEL 這個縮寫，這裡要說清楚它其實有兩個意思。

書裡的 CEL 是 Context Enrichment Layer（情境豐富層），在 第 10 章〈Observability Augmentation and Pre-Incident Intelligence〉 才正式定義，位置是「夾在 Signal Plane 跟 Reasoning Plane 中間的那個架構元件」。它把原始訊號補上 baseline、趨勢、拓撲位置、變更情境，讓 Reasoning Plane 拿到的每一條訊號都自帶足夠的上下文。

這系列的 CEL 是那一層在這個 repo 裡的實作，app/signals/ 那八個模組，前面盤點過它對著四項職責（enrichment、correlation、projection、grounding）只做到一項半：拓撲那格滿的，grounding 一半，baseline 只夠 attribution 那一條邊用，trajectory、correlation、change context 是空的。projection 是想清楚了不做（沒有校準的推估比沒有推估更危險），其他幾格是還沒輪到。

換句話說，這系列蓋的是 ARE 四個 Plane 裡最底下那個 Signal Plane，而且是 Signal Plane 裡 CEL 這一小段，而且這一小段還有一半是空的。這不是在貶低進度，是在標定位置。一個讀者如果以為這系列做完了「決策級遙測」，那份地圖是錯的。

成熟度模型跟信任天花板

第 6 章還有一個東西，書裡說是全書第二常被引用的段落：成熟度模型。五個等級（Reactive、Augmented、Bounded、Adaptive、Systemic），三個維度（Observability、Reasoning、Authority）。每一級的定義，是「這三個維度上各自要成立什麼，這一級才能安全運轉」。

書裡特別點名 L2 跳 L3 是整個模型裡最難的一跳，叫信任天花板。這一步是系統第一次拿到「自主寫入」的授權，而多數導入就死在這裡。失敗的樣子很一致：團隊想用「把 prompt 寫得更嚴」去補 Governance Plane 沒投資的洞，而 prompt 層級的安全在負載下撐不住。過這道天花板只有一條路：Governance Plane、action contract、自動回滾、校準過的信心，四個結構機制得在同一個時間點全部到位。

配著這個模型的是五個旗艦 SLO，它們是關卡不是指標：ARR（Autonomous Resolution Rate，自主解決率）隨等級上升；DQ-SLO（決策品質）隨成熟度上升；RL-SLO（推理延遲）L3 才可執行；AE-SLO（動作有效性）隨動作目錄跟 policy 的品質上升；CE（Calibration Error，校準誤差）是唯一一個每一級都必須壓低的，過度自信的推理在任何成熟度都危險。另外 L2 有個專屬關卡 SAR（建議採納率），L5 有個 GR（Grounding Rate）。

這系列有碰到其中一部分：校準誤差跟過度自信，是前面幾天在 governance._calibration_verdict() 那條路徑上一直在算的東西；band accuracy 從 1.0 掉到 0.5 那次，就是「還沒遇到高信心的錯例」被戳破。但那是零星地量，不是照這個模型系統性地在爬。

Part III：把治理當成一個要維運的系統

前面講的 Governance Plane 是「有一道 runtime 求值」。Part III 那兩章把那道求值當成一個要日常經營的系統在看。

第 11 章〈Governed Autonomy〉 把授權分級講得更細，分 T0 到 T3（只建議 / 有界預授權 / 影響範圍內自主 / 自主僅留稽核），而且等級綁在「動作類別」上，不是綁在 agent 上，所以同一隻 agent 對不同動作可以在不同等級。配套的機制：dynamic guardrails 隨當前校準、override 率、事故視窗自動收放，帶遲滯（hysteresis）避免它一直來回跳；emergency shunt 是人手動把自治瞬間降到 T0/T1，但候選動作照樣看得到，跟 kill switch 不一樣，不是全部停掉；還有把 Override Rate（人推翻了多少比例的架構決定）跟 SAR 當成信任的遙測在盯。書裡有個刻意的不對稱：降階容易、升階難，升階要證據。這一整套操作介面叫 Reasoning Control Plane，是值班的人每天真正在碰的東西，看稽核、調參數、重新校準，建議每個月做一次校準循環。

第 12 章〈Simulation-Driven Reliability〉 處理的是更前面的問題：在給自治之前，怎麼知道這隻 agent 值不值得信。答案是先在模擬裡跑。書裡一直強調「模擬不是測試」：測試問「程式碼有沒有照測試的預期跑」，模擬問「這個架構會做出什麼決定，我們該不該放它做」。它需要一個 digital twin（拓撲、變更事件、訊號生成都照 production 建，而且要每天對拓撲、每週重放變更、每月比訊號分佈，防 twin 漂移）、一份 scenario library（過去的故障、沒驗證過的假設、變更驅動的情境三類），升階之前先讓那個動作類別對著整份 library 跑一遍，高 CRS 的變更也在 CI/CD 裡先過模擬。最有用的一點是校準：高信心那個 bin 的校準誤差在 production 上很難修（那種錯很少發生），在模擬裡靠計算量就能刷起來。

這系列離 Part III 還很遠。校準判決那條路徑算是第 11 章「治理是個會學習的系統」的一小片手工版，但沒有授權分級、沒有 dynamic guardrails、沒有 emergency shunt。模擬那一章更是一格都沒有：這系列每一個分數都是拿真的 store 去跑出來的，也正因為這樣，前面才會踩到「空視窗量的是環境不是答案」那個坑。一個 digital twin 會讓那種前置檢查變成內建的。

讀完第 12 章有點後悔沒早點看。
前面為了「分數不算數」來回折騰的那些天，一半的痛點它整章都在講怎麼繞過去 QQ

對照表：我們在這張地圖的哪裡

把上面的東西收成一張表。左邊是 ARE 的結構，右邊是這系列的現況。

右邊那一整排「概念」，就是這系列一開始講的「留給後面」的東西。ARE 的第 3 版大綱把它們明確劃出範圍：這系列做到「agent 能組出讓人推理的豐富事件、給診斷、給信心、給下一步建議」，不做「能自主執行、能自我校正」，後者要 Governance Plane、校準機制都到位，不是一段能誠實交代完的。

小結

總結來說，今天做的事情比較像整理而不是進展：把這系列借了二十幾天的那四個名詞（Signal Plane、Reasoning Plane、Execution Plane、Governance Plane）放回 ARE 那本書裡它們原本的位置，順便畫出 DRAL 迴圈跟那個成熟度模型。對值班的人來說，這張地圖的用處是知道「現在這隻 agent 能信到哪」：它在 L2 往 L3 之間，卡在信任天花板下面，也就是說它可以給你一份查得不錯的情境跟一個帶信心的假設，但它不該自己動手，因為讓它安全動手的那三個結構（Governance Plane、action contract、自動回滾）這系列還沒蓋。

畫完之後最有感的一件事是比例：這系列蓋的是四個 Plane 裡最底下那個，而且是那個 Plane 裡 CEL 那一小段，而且那一小段還有一半是空的。ARE 這本書大概八成的篇幅，這系列連碰都還沒碰到。