工程開發
- 撰寫對象
developer- 它導向的那個決定
- 決定採用它在我的程式碼庫裡要付出什麼代價，以及它實際觸得到我的哪些動作。
這一切從哪裡開始
你正要出貨一個代理，而治理這件事是以阻礙者的身分出現，而不是以一套函式庫的身分出現。
你想知道的事情很小、很具體：我要加什麼、它包裝什麼、政策說不行的時候它會怎麼做，以及它會漏掉什麼。而你通常拿到的是一張架構圖。
為什麼它成了這一季的問題
資安要求你先提出證據，說明你的代理被允許做什麼，才會核准它使用正式環境憑證，而程式碼庫裡卻沒有任何東西可以指給他們看。
Agent Assembly 對此做了什麼 — 以及每個答案能走多遠
兩種整合形態，而它們並不對等。SDK 會包裝你的框架的工具接縫，在工具主體執行之前檢查一次呼叫。受管啟動則把該行程的對外流量放到代理伺服器前面，而目的地、憑證與 MCP 這幾筆項目正是在那裡生效。前者位於你的程式碼之內，屬於建議性質；後者位於你的行程之外，也是拒絕真正站得住的地方。
底下每一張卡片，都是這四個頁面共用的十六筆主張登錄表中的一筆項目，皆為原句引用而非改寫。用語是登錄表自己的用語，是從證據抄下來的，而不是為了配合句子挑選的；旁邊的界限是這項主張的一部分，不是它的背景說明。每一筆項目 — 包含這一頁沒有引用的那些 — 都會連同背後的能力清單列一起公開：共用主張登錄表。
透過被包裝的框架接縫發出的工具呼叫，會在工具主體執行之前先被檢查。
它到哪裡為止。 SDK 在設計上就是建議性的 — 它是縱深防禦的一層姿態，不是權威的把關點，而不去呼叫它的代理根本沒在問。Python 會在主體之前拋出例外，並且失效關閉。Go 也失效關閉，但需要明確呼叫 WrapTools。Node 的預設模式會把檢查導向一個一律放行的無作用用戶端，所以那裡根本不會產生任何拒絕；在沒有具檢查能力的模式時要求強制執行，會在初始化時被明確拒絕並報錯，而不是無聲地放行。
透過 aasm run 啟動一個工具，會把代理伺服器的設定寫進該工具的環境裡，而那正是把它的對外連線放上這條路徑的原因。
它到哪裡為止。 寫入某個工具自己的設定檔屬於工具治理，不是資料路徑上的主張；這些轉接器所帶來的任何防止效果，都是代理伺服器的，透過啟動環境借來的。在已出貨的轉接器之中，Claude Code 是唯一一個高於 Integrated 的，也是唯一一個有啟動證據測試的。Copilot 的啟動在構造上一定會失敗。Codex 與 Windsurf 只注入代理伺服器環境變數，沒有 CA 信任，而那正是被量測到會無聲地讓交握失敗的組態。aasm run --no-proxy 是一種已明示的繞道方式。未受管的啟動則是一種繞道方式，而且偵測不到。
在你導流經過 Agent Assembly 的路徑上所建立的連線，會依你所設定的目的地清單進行檢查，並在代理伺服器撥號之前遭到拒絕。
它到哪裡為止。 這次拒絕出自代理伺服器自身的本機對外流量組態，而非控制平面的決策。目的地清單預設為空 — 這次拒絕之所以存在，是因為有維運者設定了它。在 Linux 上是發行產物；在 macOS 上，cargo install aa-proxy 是唯一的途徑；在 Windows 上沒有任何本機中介。如果代理伺服器不在這條連線前面，這條連線就只是單純地被建立起來。
在 Agent Assembly 會檢查的模型供應商主機上，被辨識出來的憑證會在請求被轉發之前從中移除。
它到哪裡為止。 共三個內建主機，因為 llm_only 預設開啟。預設行為是遮蔽後轉發，而非拒絕。偵出率受限於樣式集合 — 並沒有 Stripe 的偵測器。該路徑上的模型回應不會被掃描。
MCP 工具呼叫可以由控制平面依你的政策進行檢查，並在代理伺服器轉發之前遭到拒絕。
它到哪裡為止。 這是本產品中唯一一個由閘道決定、且發生在撥號之前的拒絕，而它預設關閉。它涵蓋的是在已設定閘道端點的被攔截非 LLM 主機上，以一般 HTTP/1.1 POST 送出的 MCP。以 stdio 執行的工具伺服器 — 最常見的設定方式 — 以及 SSE 與 WebSocket 都沒有攔截機制；Streamable HTTP 則被記錄為在功能上就是壞的，而不只是未被涵蓋。
之後有什麼不一樣
一次被包裝的工具呼叫，會在它的主體執行之前先被檢查，而在失效關閉的那些路徑上，它會拋出例外而不是執行下去。
這項決策會記錄在你的代理身分之下，所以「證據在哪」這個問題有了一個答案，而那個答案不是去日誌裡 grep。
你可以查證什麼，以及在哪裡查
各框架、各語言的轉接器狀態，就是能力清單中 SDK 各列的「框架」與「涵蓋範圍」欄位 — 在你依它做規劃之前，先讀你那個框架的那一列。
能力清單 →政策語法，以及它能表達什麼。政策是納入版本控管的 YAML 或 JSON，你用原本就在用的 Git 流程審閱它，所以本站描述的規則，就是你可以自己查得到的規則。
政策參考文件 →各語言的 SDK 層級細節 — Python、Node 與 Go 的文件，包含哪些模式會產生拒絕、哪些不會。
SDK 文件 →SDK 在信任模型中的位置，以及它為什麼是建議性而非權威性 — 這是在架構決策紀錄裡明白寫出的，不是從一張圖推論出來的。
ADR 0033 →
那些你原本會比較晚才發現的事
- SDK 在設計上就是建議性的。它是縱深防禦的一層姿態，不是權威的把關點（RC5）。面對不配合的行程仍然站得住的拒絕，是代理伺服器的，位於你的行程之外。
- Node 的預設模式不會產生任何拒絕。除非選用具檢查能力的模式，否則檢查會被導向一個一律放行的無作用用戶端。在沒有選用該模式的情況下要求強制執行，會在初始化時被明確拒絕，而不是無聲地放行；而自動偵測到的框架只會發出警告，不會拋出例外 — 這是刻意的，為的是保住零組態。這是任何一頁 Node 整合說明上最重要的一句話。追蹤於 AAASM-4991。
- 包裝在各框架之間並不一致，而差異就在拒絕訊號上。有些 Python 轉接器會在主體之前拋出例外；另一些則回傳一個哨符字串，所以只攔截政策例外的呼叫端，會把一次被拒絕的呼叫當成一次結果為字串的成功。LangGraph 與 Mastra 的節點掛鉤，以及 LangChain 的回呼處理器，在構造上就無法拒絕 — 它們只是觀測。明確指定的 LangChain 包裝器則可以，而它預設關閉。
- Go 需要一次明確的呼叫。在沒有 FFI 建置標籤與 CGO 的預設建置下，每一次被包裝的呼叫都會被拒絕，而不是被允許；這是失效關閉，但也不是所宣傳的行為。
- 沒有轉接器的框架不在涵蓋範圍內。沒有經過被修補接縫的直接呼叫也不在。包裝器觸得到的就是它所包裝的那些，其餘一概不及。
- 凡是 SDK 沒有包裝到的，都在它之外。原生 HTTP、子行程、檔案系統、資料庫驅動程式，以及從你的行程內部發動的瀏覽器自動化。這一整類正是代理伺服器存在的理由，而在主機層動作上，已發行的版本裡根本沒有任何機制。
- 以 stdio 承載的 MCP 不在受中介的路徑上。而那正是工具伺服器最常見的執行方式（RC4）。
- 導流的前提條件在環境裡，不在你的原始碼裡。這個工具必須以會設定代理伺服器環境變數、且 CA 受到信任的方式啟動。Codex 與 Windsurf 只注入了前者，沒有後者（RC15），而那正是被量測到會無聲地讓交握失敗的組態。
- 「需要核准」不是你可以拿來對接整合的東西。需要核准RC12
不作任何主張。
它到哪裡為止。 能力清單裡沒有任何一列達到這個用語。這個擱置在閘道這條路徑上確實存在，且逾時會失效關閉，但沒有任何已出貨的維運者介面能夠回應它；而在 MCP 通道之內，待決的決策會直接被降級成一次拒絕，所以在那裡也同樣找不到人來處理。AAASM-5657。