Change-Intent Governance:缺席的那一層

2026 年的平台工具版圖由兩種 control plane 主導。內部開發者平台(IDP)——Backstage、Port、Cortex、OpsLevel——掌握 catalog:有哪些服務存在、誰擁有它們、彼此如何相依。另一種是快速興起的 AI agent 治理層——MCP gateway、model gateway、human-in-the-loop 核准流程、runtime 可觀測性——盯著 agent 被允許做什麼,一次一個 tool call。

兩層都是真的,也都值得擁有。但有一個具體的問題,兩者都答不出來:這個即將落地的變更——它影響哪些專案,誰核准了它,證據在哪裡?

Catalog 答不出來,因為它治理的是庫存,不是變更。Agent gateway 答不出來,因為它治理的是動作,不是意圖。答案住在多數 stack 沒有的一層裡。我後來把它稱作 change-intent governance(變更意圖治理),這篇文章要談的,是為什麼 AI 原生交付把它從加分項變成必要條件——以及它的最小實作長什麼樣子。我的觀察位置先講在前頭:一個一人規模的 AI 原生交付作業——很小,但正是全速撞上這個缺口的規模。

既有兩層各自治理什麼

內部開發者平台治理的是存在什麼。它那份服務、擁有者、相依關係的 catalog,是由從 source repository、CI 系統、雲端供應商同步的整合拼出來的——也就是說,它是對 portfolio 的一種持續重新推導的信念,同步一落後於現實就會漂移。更關鍵的是,IDP 的 self-service 層是建來執行的。有些平台走得更遠:Port 的 workflow 可以在 catalog graph 上計算 blast radius,超過門檻時暫停等待人類核准——這是這一層最接近「對變更有感知的 gating」的東西,值得擁有。但那個預測被寫回它自己推導出來的、同一份可覆寫的 catalog,成為下一次同步或下一個寫入者可以無聲取代的一個屬性,而且一部分判斷還委派給了一個由 LLM 評分的風險欄位。仍然缺席的,是證據的形式:一個從不可變、有身份識別的 snapshot 決定性地計算出來的影響主張,以及一個綁定在那次確切計算上的核准,記在一份平台和申請者都改寫不了的 append-only 紀錄裡。

這一輪冒出來的 agent 治理產品,治理的是runtime 正在發生什麼。Gateway 可以允許或拒絕一次 tool call,可以要求人類核准一個敏感動作,可以記下 agent 發出的每一個請求。這確實有用——而它的顆粒度就是單一 agent 的單一動作。一份 tool call log 可以告訴你某個 agent 寫了某個檔案。它無法告訴你那次寫入屬於哪一個 portfolio 層級的變更、那個變更預期影響什麼,或者有沒有人為它的整體承擔了責任。

所以 catalog 治理存在什麼,gateway 治理正在發生的個別動作。一個被提出的變更——連同它跨專案邊界的預測影響,和一個可問責的決定——充其量是寫進 catalog 的一個屬性,下一次同步就可能把它覆寫掉。它從來不是一筆靠自己的證據站得住的紀錄。

IDP / 服務 catalog

存在什麼

「我們有哪些服務,誰擁有它們?」

可覆寫的 catalog,持續重新同步

Change-intent governance

缺席的那一層

即將改變什麼

「這個變更影響哪些專案、誰核准的、證據在哪?」

不可變 snapshot + append-only ledger

Agent gateway

此刻正在發生什麼

「這次 tool call 允不允許?」

逐動作的請求 log

為什麼這個缺口開始承重

當大部分程式碼由人來寫,這個缺口還可以忍受,因為 git log 是人類速度讀得完的。一個 tech lead 可以把一週的變更放在腦子裡;「這會動到什麼?」靠讀 diff 加上熟悉 codebase 就能回答。

AI 原生交付打破了這個假設。當大部分程式碼由 agent 產出——我自己的作業就是這樣運轉的——變更量會成長到沒有任何人能從 commit history 重建的程度。失敗模式不是一個壞變更溜過了審查。是整個組織失去了事後回答「哪些變更動到哪些專案、憑誰的授權」的能力,因為那個資訊從來沒有被記錄成第一級的產物——它只存在於某個人腦中的脈絡裡,或存在於一個早已被丟棄的 agent session 裡。

一般性的論證我在〈可問責的生成〉裡講過:當生成的輸出變便宜,治理必須附著到意圖,因為問責住在意圖那裡。這篇文章是同一個論證套用到專案與專案之間的那一層。在單一 repository 之內,意圖層的治理是一種 code review 紀律。跨整個 portfolio——一個變更沿著相依邊,波及到別人、或別的 agent 擁有的專案——它需要機械裝置。

這套機械裝置必須提供什麼

把問題剝到稽核員、事故檢討、未來的維護者實際需要的東西,要求出乎意料地少。這些是對紀錄本身的性質要求,不是任何特定工具的功能:

• Portfolio snapshot 作為證據,而不是活的信念。 專案邊界、相依邊、真相源主張,在一個時間點被捕捉下來,讓每一個下游判斷都能引用它推導自哪一份 snapshot。這和 IDP 那份持續同步的 catalog 正好相反:snapshot 可以過期,但它不能無聲漂移,因為它的身份識別是紀錄的一部分。
• 影響是推導出來的,不是口頭宣稱的。 「這個變更影響這些專案」應該從 snapshot 的相依邊與真相源規則計算出來,讓這個主張可以從證據重現,而不是憑記憶打進一張 ticket。
• 變更意圖是一筆 append-only 的紀錄。 一份提案、它收到的核准或駁回、必要時的補救計畫、執行工作的 runner session,以及它們產出的證據——每一項都是一筆有行為者具名的明確紀錄,事後都不可編輯。不是一頁 wiki。是一份 ledger。
• 對 source repository 採唯讀姿態。 治理層觀察並記錄;它不伸手進 repository 去改動它們。這讓稽核軌跡可信——如果這一層對它觀察的 repository 有寫入權,它也就能竄改「發生了什麼」的證據——同時讓治理層自身的 blast radius 維持在零。
• 寫入需具名行為者把關。 每一筆進入 ledger 的紀錄,都寫明是誰放進來的。「系統決定的」不是一個可記錄的狀態;每一個決定都是一筆由具名行為者——人或 agent——寫下的明確紀錄。

這些都不會取代 catalog 或 agent gateway。它坐在兩者之間:它消化 catalog 知道的那種拓撲,並讓 agent 層的動作有個歸屬——一個受治理、有擁有者的變更。

一個參考實作

我維護著這一層的一個開源參考實作:aine-control-plane(Apache-2.0,撰文當下為 v0.7.0)。它是一個零相依的 Python core,加上一個參考 HTTP transport 和一個本地 React UI,正是圍繞上述要求建的:Registry snapshot 匯入,含專案、相依、真相源三種視圖;從這些 snapshot 推導的影響分析;append-only 的 SQLite 證據與稽核儲存;以及 change-request、核准、補救計畫、runner session 的工作流程,其中每一個決定都是一筆明確、標注行為者的紀錄。Core 沒有任何改動 source repository 的 API,也不發出任何網路呼叫。

它不是什麼,我也要說得同樣清楚,因為這正是定位文章通常誇大的部分。它是一個參考實作,不是 SaaS——沒有託管的 tenant,沒有計費,沒有強化過的多使用者部署;參考 transport 只綁定本機。它是一個一人作業的成果,由經營一個 AI 原生交付實務形塑,不是由一百個企業部署形塑。而且它不和兩側的層競爭:你需要服務 catalog,就仍然要 IDP;你需要 agent 行為的 runtime 強制執行,就仍然要那個 gateway。它提供的,是兩者之間那一層的契約——可攜的 schema、conformance 測試,以及一個實際運作的示範,證明這一層可以很小。

給你自己 stack 的三個問題

檢驗這個論證最便宜的方式,是拿你自己的組織來對照:

1. 當一個變更跨越多個 repository 落地,它的 blast radius 是被不可變地記錄為一個有人核准過的主張——還是只能事後靠工程師讀 diff 才挖得出來?
2. 如果稽核員從上一季挑出一個重大變更,你拿得出完整的鏈嗎——提案、影響、核准、執行證據——還是得從聊天紀錄和 git 考古裡重建?
3. 隨著 agent 接手你越來越多的程式碼產出,你對前兩題的答案是在變好,還是在變壞?

Catalog 回答你有什麼,gateway 回答 agent 此刻在做什麼。兩者都回答不了:哪個變更動到哪些專案、憑誰的授權,而且背後的紀錄不可能被無聲改寫過。那是獨立的一層,而參考實作存在的意義,就是證明它可以很小——小到能在稽核或事故逼問之前先加上去。