平台與 SRE
- 撰寫對象
operator- 它導向的那個決定
- 決定這東西會加什麼到我的待命輪值上，以及它壞掉的時候會做什麼。
這一切從哪裡開始
代理的工作負載進來時沒有任何維運契約。它們由開發者在筆電上啟動、由 CI 在執行器上啟動，會去連你沒有核准過的第三方端點，而出事時的第一個問題 — 它到底做了什麼 — 既沒有負責人，也沒有答案。
你被要求讓它們安全，卻沒有人給你一個立足點。
為什麼它成了這一季的問題
一次事故檢討問起是哪一個代理發出了那次呼叫，而答案要花兩天、橫跨三套系統做日誌關聯，最後仍然只是猜測。
Agent Assembly 對此做了什麼 — 以及每個答案能走多遠
少數幾個由你執行、由你負責的行程：一個回答政策問題並保存記錄的控制平面、一個放在線路上的旁掛式代理伺服器，以及一個把某個工具的流量放到代理伺服器前面的受管啟動。有四筆項目決定了這在維運上要付出什麼代價。
底下每一張卡片，都是這四個頁面共用的十六筆主張登錄表中的一筆項目，皆為原句引用而非改寫。用語是登錄表自己的用語，是從證據抄下來的，而不是為了配合句子挑選的；旁邊的界限是這項主張的一部分，不是它的背景說明。每一筆項目 — 包含這一頁沒有引用的那些 — 都會連同背後的能力清單列一起公開：共用主張登錄表。
在控制平面已設定、卻變成連不上的情況下，決策路徑會拒絕，而不是允許。
它到哪裡為止。 在有閘道的那些路徑上是失效關閉：執行環境在閘道連不上時會拒絕，代理伺服器會拒絕啟動，而閘道在政策載入失敗時會中止。反過來則不對稱 — 完全沒有設定閘道的執行環境，會落到一次本機評估，其最終預設是允許。已設定然後壞掉是失效關閉；從未設定則是失效放行。
在某項控制原本已規劃、目前卻無法使用的情況下，本產品會回報所規劃的等級以及實際達到的等級。
它到哪裡為止。 降級必須同時帶著兩個等級，否則就不是這個用語。有一列達到它，是針對 eBPF 載入或掛載失敗。回報的那一半並沒有閉合：降級會被發出、有型別，卻沒有任何地方會呈現它；而讀不到的 eBPF 政策檔會無聲地失效放行，根本不會發出任何降級事件。
某一項決策的記錄是否持久地抵達稽核鏈，並未被確立。驗證工具是真實存在的 — aasm audit verify-chain 隨開放原始碼版本一併提供 — 但它所證明的是現存項目的完整性，而不是任何一項特定的決策確實產生了一筆記錄。
它到哪裡為止。 能力清單中關於這個主題的唯一一列，是寫出失敗時會發生什麼的那一列，而該列帶著 coverage: unmeasured、failure_posture: fail_open 與 evidence: gap。所以誠實的用語就是該列自己的用語。關於這條鏈的其他一切都是界限，不是能力：它可察覺竄改，但既非不可變更，也未經簽章 — 它是一個無金鑰摘要，所以任何能改寫輸出目的地的人都能重新算出它。鏈首會在送出之前就先推進，而通道滿載時會丟掉該筆項目、該次呼叫卻仍然返回，這使得被丟棄的項目與被刪除的項目無從分辨。一份被清空的日誌驗證起來也會是乾淨的。除非代理伺服器的稽核路徑已設定，否則它根本不會寫出任何本機記錄。請見那兩個缺口。
透過 aasm run 啟動一個工具，會把代理伺服器的設定寫進該工具的環境裡，而那正是把它的對外連線放上這條路徑的原因。
它到哪裡為止。 寫入某個工具自己的設定檔屬於工具治理，不是資料路徑上的主張；這些轉接器所帶來的任何防止效果，都是代理伺服器的，透過啟動環境借來的。在已出貨的轉接器之中，Claude Code 是唯一一個高於 Integrated 的，也是唯一一個有啟動證據測試的。Copilot 的啟動在構造上一定會失敗。Codex 與 Windsurf 只注入代理伺服器環境變數，沒有 CA 信任，而那正是被量測到會無聲地讓交握失敗的組態。aasm run --no-proxy 是一種已明示的繞道方式。未受管的啟動則是一種繞道方式，而且偵測不到。
之後有什麼不一樣
代理的對外流量會變成一件有組態、有失效姿態、有負責人的事，而不是行程周遭自然發生的行為。
當控制平面已設定卻消失時，依賴它的那些路徑會拒絕，而不是悄悄放寬。反過來並不成立，而底下的限制一節就是從這件事開始講起。
你可以查證什麼，以及在哪裡查
各種部署形態與容器的部分 — 什麼跑在哪裡，以及一套受限功能的自行架設堆疊包含什麼。
Docker 與容器 →執行中的系統會揭露什麼、又不會揭露什麼 — 在你據以設計任何告警之前先讀這個。
自行架設的可觀測性 →逐列的失效姿態與預設狀態 — 這兩個欄位是摘要最先砍掉、而維運者最先去看的 — 涵蓋全部 80 列。
能力清單 →各元件的版本與平台位置，以及每個產物實際上會出現在哪個通路。
真實來源與狀態 →針對你實際上真的會被叫起來處理的那些故障，所準備的第一線應對材料。
疑難排解 →
那些你原本會比較晚才發現的事
- 失效關閉並不對稱。已設定但連不上會拒絕；而完全沒有設定閘道的執行環境，則會落到一次本機評估，其最終預設是允許（RC11）。兩者之間只差一個組態疏失。
- 有三種失效模式是無聲的。讀不到的 eBPF 政策檔會退回成一組空的規則集，且不會發出任何降級事件；損毀的預算儲存區會把上限重設為零花費；滿載的稽核通道會丟掉該筆項目，而該次呼叫仍然回報成功。這三者都不會傳呼你。
- 降級會被發出，卻沒有任何地方會呈現它。事件型別存在，產生端也存在，但沒有任何消費端 — 健康檢查端點的「已降級的層級」欄位是一份開機時的快照，從此不再更新，而它的狀態是一個寫死的字面值（RC10）。追蹤於 AAASM-5535。要嘛規劃自己去消費這個事件串流，要嘛就規劃好自己不會知道。
- 散布通路的狀況並不一致，而它決定了你能安裝什麼。代理伺服器在 Linux 上是發行產物；在 macOS 上唯一的途徑是 cargo install。eBPF 載入常駐程式只出現在 crates.io，在 GitHub Release 的產物、Homebrew tap 與安裝指令稿中都沒有 — 所以透過上述任何一種方式安裝的維運者，都沒有主機層元件，而在 macOS 上，受管啟動也沒有代理伺服器可以啟動（RC8、RC9）。追蹤於 AAASM-5653。
- 核心探針只做回報，它們不做決策。已觀測 · 已偵測RC8
在 Linux 上，核心探針會回報 TLS 明文、行程執行與檔案活動。
它到哪裡為止。 沒有任何 eBPF 訊號參與任何允許或拒絕的決策。唯一一個做強制執行的程式，是一個選擇性啟用的系統呼叫防護，它會在有問題的系統呼叫已經執行過之後才終止被限制的行程，這是已偵測，不是執行前拒絕。檔案 I/O 探針僅支援 x86_64。擁有所有核心操作的特權載入常駐程式只出現在 crates.io — 在 GitHub Release 的產物、Homebrew tap 與安裝指令稿中都沒有。
- 受管啟動會把整個父行程的環境交給子行程。代理內部的 shell 或檔案工具，可以讀到你匯出到啟動它的那個 shell 裡的任何憑證。
- 代理伺服器會拒絕非回送位址的監聽端。即使加上遠端用戶端旗標也一樣，因為它沒有監聽端 TLS，也沒有用戶端驗證。不要繞過它。
- 承載內容檢查預設僅限於模型供應商主機。更廣的檢查是你要自己去設定的，而且它帶有延遲與相容性上的代價（RC3）。
- Windows 上沒有任何本機中介。不支援RC14
被指名的那些傳輸協定與平台並不可用，而對照表說明了是哪些。
它到哪裡為止。 Windows 上沒有任何形式的本機中介。UDP、QUIC 與 HTTP/3 不在傳輸協定範圍內；在被攔截的主機上，HTTP/2、gRPC 與 WebSocket 也不在，以 WebSocket 承載的 MCP 同樣不在。某一個元素為不支援，並不等於整個產品為不支援。
一頁要讀，一件事要做
讀「自行架設的可觀測性」 — 執行中的系統會揭露什麼，正是你在它之上會建立的每一個告警與儀表板的輸入。
自行架設的可觀測性 →然後在規劃推行之前先確認你的平台與通路 — 上面那條散布限制代表，這個答案會決定你到底裝得到哪些元件。
相容性對照表 →