一支 Agent 只替單一團隊查 Logs，另一支可以修改正式環境。兩者可能使用相同框架，甚至相同模型，導入時要先處理的問題卻不一樣。前者需要受限的資料權限與可查詢的結果，後者還要在修改前確認目標、參數和批准。

第三種情況是多個團隊都開始使用 Agent，各自處理登入、Provider Key、重試和觀測。每支應用仍能運作，共同規則卻逐漸分岔。這時優先事項可能是收斂流量入口，而不是再替每支 Agent 加一個新工具。

本篇按這些需求安排導入順序。先看已有的控制和維護者，再看下一個控制能接走什麼工作。每個情境都有可以正式停留的架構，也要留下需求改變時重開評估的條件。

先盤點現有基礎與改動風險

可以先用 Day 27 的 Capability Ledger 畫出現有身分、請求、交付與觀測位置。我們已有由人維護的 LGTM 觀測平台，用來查 Logs、Metrics 和 Traces，也有 Git 和映像交付流程，Human／M2M 的 Cognito 路徑已經跑通。這些既有能力讓 Agent 可以沿原來的工作方式接入，新增成本主要在工具權限、事件欄位和查詢契約，而不一定要先建新後端。

讀者的基礎可能不同。原有 IdP 可以替代 Cognito，原有監控平台也可以替代 LGTM。需要保留的是三種能力：辨認誰在呼叫、知道實際跑哪份程式，以及查回這次操作的結果。先找它們目前的負責人，再討論哪一段真的缺控制。

風險也要從工具能力看。唯讀工具仍可能讀到敏感資料，但修改、刪除和部署還會改變系統狀態。共享需求則是另一條軸：只有一個團隊，不表示高風險工具可以省略授權。很多團隊使用，也不表示每支唯讀 Agent 都需要人工批准。

下圖可以沿需求分支閱讀。新增副作用先走動作授權，共同流量規則開始重複才走 Gateway，部署與目錄的共用需求成立後再看控制面。它不是要求所有人爬完的階梯。

單一團隊的唯讀查詢

以 SRE Agent 查 Loki 為例，首先要確認查詢帳號只能讀必要資料，Runtime 能處理工具錯誤與空結果，回應也保留能查證的線索。若使用者問的是某個服務，工具卻可讀整個組織的 Logs，就算沒有寫入能力，資料權限仍然需要收斂。

登入與服務憑證可以沿既有機制。Human 的互動登入，和背景服務取得 Token 的流程分開管理。Runtime、工具程式與依賴由應用 Repository 維護，部署沿既有流程，觀測資料送到原有平台。這讓應用、身分、資料來源和 SRE 各自承擔熟悉的工作。

唯讀情境的驗收可以具體到一次查詢：允許範圍內找得到資料，超出範圍會拒絕，工具失敗有清楚狀態，值班者能沿操作找到事件或 Trace。Day 25 的 Grafana MCP 路徑提供了這類範例，單是工具名稱出現在 UI 裡還不夠。

若只有一個團隊維護，沒有共享入口或跨團隊上架需求，就可以停在自建 Runtime、Git 交付和原有觀測平台。憑證輪替、套件升級、工具失敗仍要有人處理，停留代表範圍明確，並不是後續工作消失。

我們自己的架構已經有 agentgateway。這個較簡單起點是為了讓尚未遇到共同流量問題的團隊，也能有可維護的選擇。若它們的既有入口已足夠，就不需要只為了跟著系列再複製一層。

工具開始修改資料時的控制

當 Agent 能改資料，第一個問題會變成：這筆修改對哪個資源、依據什麼需求、允許哪些參數？例如工單只允許測試環境，工具提出的資料庫卻是正式環境，這個差異應在真正呼叫資源以前被檢查。

規則可以先由應用與 Resource Server 實作。ADK Callback 能在工具執行前做檢查，資源服務則以自己掌握的權限和業務狀態作最後判斷。集中式平台未成立時，單一應用仍可以有明確的授權路徑，不需要等 Registry 或控制面才開始保護資源。

執行紀錄也要跟著改變。只記請求耗時已經不足以調查修改，還需要操作識別、規則版本、目標、必要的參數摘要、實際執行產物與資源結果。敏感參數不必完整寫入，但事件要能核對這次判斷涵蓋的內容。

若需要人工批准，就得固定待執行的動作，交給有權處理這個資源的人。批准後目標或參數改變，原決定應失效。Day 18 已驗證相容 BYO 路徑的 Pause／Resume，正式批准者身分與完整動作綁定則仍需另外驗證。

這個情境能否停下來，取決於允許與拒絕是否可重現，批准是否對應真正執行的內容，以及結果能否核對。把所有修改送去人工審核，也不能替代程式本來就能確定的環境與權限限制。

多個 Runtime 共用流量規則

第二支 Agent 上線，不一定馬上需要共同 Gateway。可以先看是否真的出現重複工作：多個 Runtime 各自持有 Provider Credential、驗同一類 Token、設定重試與等待，再送不同格式的觀測欄位。若規則只改一次，卻要跨好幾個 Repository 才能完成，就已經有共享控制的需求。

agentgateway 可以在這時接手 LLM、MCP、A2A 的共同認證、路由、政策和流量觀測。平台團隊維護入口契約，應用團隊依契約使用它，保留自己的工具和工作流程。既有 Ingress 仍可以處理對外 TLS 和 Host Routing，兩層的責任要明確。

這種收斂需要遷移計畫。先挑一條流量，核對憑證來源、拒絕行為、Timeout 和 Trace Context，再逐步接更多 Runtime。共同入口失敗可能影響多個應用，因此上線時也要有維護者、回退方式與容量考量。這些是導入設計，不能只由 Quickstart 能啟動就推論完成。

成本分組也可以在入口收斂。先用可信團隊對應和有限維度觀察用量，若需要正式分帳，再接價格版本與 Provider 帳務核對。Day 24 的失敗 Attempt 沒有 Usage，就應保持未知，面板上的完整外觀不能代替成本證據。

當共同規則已有負責人，Runtime 仍由應用維護，觀測也能查回操作，就可以停在 BYO Runtime、Git、單一 Gateway 與原有平台。Gateway 接管流量，並不會自然產生集中部署或目錄需求。

跨團隊部署與目錄的需求

之後若多個團隊都需要自助發布 Agent、取得可用版本、提供 Agent Card 和操作入口，就可以評估部署控制面。kagent 提供 Kubernetes 上的 Agent 部署與發現能力，實際可沿用哪些 Runtime 操作，則要用團隊自己的 Agent 契約驗證。

Registry 處理的是另一項需求：集中搜尋、上架和管理部署宣告。它可以和部署平台整合，也會新增可以修改期望狀態的入口。導入前要說明 Git 與 Registry 誰能修改、版本如何批准，以及失敗部署和下架由誰接手。

交付的內容識別不必等 Catalog 才做。先將完整 Agent Image 固定到 Digest，保留建置和批准紀錄，再讓執行事件核對實際版本，既有 Git 和映像流程就可以開始承擔這項工作。新增 UI 不會自動讓可移動 Tag 變成可信產物。

在我們的經驗裡，Keycloak 技術鏈曾跑通，但企業人員生命週期尚未有人完整承接，所以沒有繼續擴成新的 Identity Center。部署與目錄也沿用相同判斷：需求、維護者和交接範圍一起成立，才有平台能持續接走的工作。

可以獨立啟動的需求

工作負載驗證、額外保存和正式成本分攤，不必等到某一層平台完成。若只是事故定位需要知道哪個 Pod 產生事件，可以先保存 Pod UID。若下游要依工作負載身分授權，才需要它能驗證的憑證與信任設定。

保存要求也要從目的出發。先檢查既有 Git 變更歷史、Kubernetes Audit Log 和觀測資料的範圍，是否符合要保存的事件與期限。若提出防刪改或特定存取要求，再由相關負責人確認缺口和補強方式。這些能力都不會因為安裝了 kagent 或 Registry 順便成立。

導入審查可以留一份簡單決策紀錄：目前的問題、新控制接走的工作、負責人、已驗收的結果，以及什麼變化會重開評估。例如新增有副作用的工具，或多個應用的認證設定開始漂移，就讓先前停留的架構重新接受檢查。

Agent Governance Adoption Trigger Matrix 提供可複製的細項。它將需求、控制、維護者和重驗條件放在一起，方便下次 Review 看條件是否改變。導入順序由實際工作推進，讀者可以使用自己的系統填這份表。

高風險工具最後仍會留下一個問題：平台可以維護共同規則，但哪個角色有權決定某次修改可以做？下一篇沿一筆測試與正式環境不一致的操作，把這個決定交回具體的資源與業務負責人。