登記處與閘道：所有基礎設施怎麼接上同一個治理基座

一家公司開始讓 AI 幫忙做事之後，很快會長出一堆「基礎設施」：一套共用的介面元件、一個存放公司已確認事實的知識庫、一組會做事的 AI 角色與技能、一批連到雲端硬碟和客戶管理系統的連接器、幾台跑排程的機器、一套決定資料放哪裡和怎麼備份的儲存規矩。每一塊單獨看都合理，問題出在它們之間。

介面元件要不要知道某個客戶案的檔案放在哪？AI 角色的權限寫在它自己的規格檔裡，還是別的地方？知識庫裡的一句品牌定位，能不能被複製一份到規則表？連接器可以自己決定今天要多寄幾封信嗎？如果這些問題每一塊各自回答，半年後就沒有人說得清楚「這件事到底是誰准的」。

這篇文章講的是我們的回答：所有基礎設施都接上同一個治理基座。治理基座同時扮演兩個角色，一個是登記處，一個是閘道。登記處回答「有什麼」，閘道回答「能不能做」。我們先講登記處和引用的方向，再講閘道的六關，最後用一個請求從頭走到尾，把整條路走一遍。

登記處：先回答「有什麼」

登記處的工作很樸素：每一塊基礎設施、每一個案、每一套外部系統，都要在治理基座留下一筆登記。登記的內容是它是誰、正本放在哪、對外提供什麼介面、誰負責、目前是運作中還是觀察中。治理基座本身也是一塊基礎設施，它同時是其他所有東西的登記處。

為什麼要先登記？因為沒有登記的東西，就沒辦法被治理。一台沒登記的機器跑了排程，出事時沒人知道該去哪裡找；一個沒登記的連接器拿著某個帳號的權限在外面動作，連「我們有哪些對外帳號」這種基本問題都答不出來。登記不是官僚手續，它是讓後面每一道檢查有東西可以對照的前提。

圖裡有幾個值得注意的地方。第一，案在最上面，它是工作倉儲，不是基礎設施；案可以引用基礎設施，例如鎖定某一版介面元件、引用某個事實的編號，但反過來不行。第二，每塊基礎設施和治理基座之間只有「登記」與「取權限」兩種關係，沒有基礎設施彼此私下授權。第三，外部系統掛在整合底下，治理基座只保存一份外部系統清單，記錄用途、負責人、是否含個資，但不保存密碼或金鑰。

Agent 基礎設施在圖上是虛框，表示它目前在觀察中，還沒有正式開立。這是刻意的誠實：會做事的 AI 角色已經有規格草稿，但還沒有一整套能被稽核的運作方式，所以先讓它照樣登記、照樣取權限，等條件成熟再升格。

引用的方向，比引用本身更重要

把東西接起來不難，難的是接起來之後不要變成一團。我們的原則是：引用只准朝固定的方向走。案往下用基礎設施；基礎設施往中間登記、往中間取權限；知識基礎設施只提供事實的編號，別人引用編號，不抄正文。

方向之所以重要，是因為依賴會傳遞。如果介面元件引用了某個客戶案的路徑，那個案一搬家，介面就壞；介面壞了，所有用到它的產品跟著壞。一條往錯方向的線，會把一個局部的變動放大成全面的故障。反過來，只要方向一致，任何一塊改版時，影響範圍都可以沿著箭頭算出來。

五個不准走的方向

光說「方向要一致」太抽象，所以我們把最容易出事的五個方向直接列為禁止。每一條都對應一種具體的壞法。

• 第一，不讀客戶資料。治理基座管登記和規矩，它知道某個客戶案存在、放在哪、資料等級多高，但不打開裡面的內容。理由是權限面最大的那一塊，一旦也能讀客戶資料，任何一個閘道漏洞都會直接變成資料外洩。
• 第二，不自己給自己權限。AI 角色或技能的規格檔裡，不准出現「我可以做什麼」的欄位。權限只存在一張綁定表裡，誰能做什麼只在那裡回答。否則一個 AI 只要改自己的規格檔，就等於替自己升權。
• 第三，不在別處寫規則。規則只放在治理基座的規則表；其他基礎設施、其他 AI 只能提議修改。若每個地方都能寫一點規則，衝突時就沒有一個說了算的版本。
• 第四，不存事實正文。公司已確認的事實，例如品牌定位或服務定義，正文只存在知識基礎設施；治理基座和所有技能只存編號。複製一份正文，就多一份會過期的版本。
• 第五，基礎設施不依賴任何一個案。這條最常被不小心違反，例如共用元件裡寫死了某個產品的路徑。案會搬、會封存、會結案，基礎設施不能跟著倒。

這五條現在的狀態並不一樣，必須說清楚。其中幾條已經寫成每天自動跑的檢查規則，例如掃描 AI 規格檔裡有沒有自授權限的欄位、掃描基礎設施的文字檔裡有沒有寫死案的路徑，違反數必須為零，若真有例外得在案裡明確宣告並寫上期限。其他幾條目前仍是設計原則，靠審查把關。

閘道：每個請求都要過的六關

登記處回答「有什麼」，閘道回答「能不能做」。所有動作，不論是人在手機上下的指令、半夜的排程，還是一封來信觸發的工作，都走同一個入口，依序通過六關。這一段是目前已經在跑的程式，不只是規格。

第一關，認身分。每個請求都要說出自己是誰，AI 也不例外，必須報出它是哪個角色、代表誰在做事。身分從固定的來源依序找；如果一個都找不到，系統不會猜，而是把它當成匿名、只讀。匿名者能看健康狀態、能看今日清單，但任何寫入一律拒絕，並提示該怎麼設定身分。早期我們曾經把「沒設身分」預設成創辦人，後來改掉了：預設值給最高權限，是最危險的一種方便。

第二關，查權限，預設拒絕。請求的動作必須出現在白名單上，不在名單上的一律拒絕，不需要理由。名單之外，再依綁定表查這個身分的角色能不能做這件事。綁定表是權限的唯一來源，前面說過的「不准自授權限」就是在這裡兌現。被拒絕時，系統寫一筆安全事件，然後結束。

第三關，確認關卡。會動到資料夾結構的動作，例如開一個新案、導正一個既有資料夾，必須附上一張已經裁決的裁決卡：狀態是已裁，確認人是有權限的人。沒有裁決卡，系統只允許預覽或試跑，讓人先看清楚會發生什麼，再決定要不要簽。這一關把「想做」和「准做」切成兩個時刻。

第四關，執行，寫入時持有案鎖。寫一個案之前先拿到那個案的鎖，寫完才釋放。兩個寫入者同時想開同名的案，後到的那一個會在建立資料夾那一步失敗，而不是把前一個的成果蓋掉。中途失敗時，系統不自動刪除已建的東西，鎖和半成品都保留，交給人判斷。

第五關，留紀錄，只准追加。每一次執行都寫一筆事件：哪個動作、結果是成功還是哪一種失敗、是不是試跑、花了多久。紀錄只能往後加，寫錯了用一筆更正事件指回原本那一筆，每一筆都帶著前一筆的指紋，中間被偷改就會斷鏈。

第六關，限流。同一種動作執行期間會留下一個「執行中」的標記，後到的同類請求看到標記就停下並回報，而不是兩個同時跑。這讓排程撞上人工操作時，結果是可預期的排隊，而不是互相覆寫。

有人會問：每一塊基礎設施自己做權限檢查不是更分散、更有彈性嗎？我們選擇單一閘道，有三個理由。第一，規則只有一個版本，不會出現介面說可以、知識庫說不行的情況。第二，紀錄只有一本，查「當時發生什麼」只需要翻一個地方。第三，新加一塊基礎設施時，它不需要重新發明權限系統，只要登記、只要從閘道取權限，就自動繼承了全部的保護。

代價也要說清楚：閘道成了一個關鍵點。它停擺時，系統要能退回人工模式；它的規則要能被審查、能被回溯。這也是為什麼治理基座本身只管登記、規則與紀錄，不碰內容；它管得越少，越不容易壞，也越容易被信任。

事件只喚醒，不授權

有了事件紀錄，很自然會想：既然每件事都有事件，能不能讓事件直接觸發下一步？例如「收到客戶來信」這個事件，直接讓 AI 去回信。

我們的答案是：事件只能把 AI 叫醒，不能替它授權。收到事件的 AI 可以起來看一看，但它接下來要做的任何事，仍然要從第一關重新走一遍：報身分、查權限、該附裁決卡的附裁決卡。理由很直接，事件的內容來自外部，外部內容是資料，不是指令。如果事件本身就能授權，任何能寄一封信給你的人，都等於拿到了一把鑰匙。

事件告訴你「該醒來看一看了」，不告訴你「你可以做什麼」。

這一條目前是規格。閘道已經擋下沒有身分、沒有權限的請求，但「被事件叫醒的 AI」這條路徑本身還沒有完整實作，我們不把它說成已經上線。

對外動作的三種狀態

內部的寫入有鎖、有紀錄，出錯了可以更正。對外動作不一樣：寄出去的信收不回來，發布的頁面已經被看到，付款已經扣款。所以對外動作要多一層設計。

• 準備送出：送出前先記一筆事件，並產生一把防重複鑰匙，同一件事永遠用同一把鑰匙。
• 已發生：拿到對方的回執，記下回執，結束。
• 未發生：明確知道沒有送出，例如對方回覆拒絕，可以用同一把鑰匙重試。
• 不確定：斷線、逾時、沒有回執。這是最危險的狀態，規則是先對帳，查清楚對方到底有沒有收到，不准直接重試。

「不確定」之所以要單獨列出來，是因為最常見的事故正是在這裡發生的：網路斷了一下，程式以為沒寄出去，於是又寄了一次，客戶收到兩封一樣的報價。先對帳再決定，比快速重試慢一點，但不會把一個小問題變成一次對客戶的道歉。

對外動作還有一個配套：核准要綁四件事，也就是版本、動作、去處和期限。核准的是「這一版報價、寄給這位聯絡人、在今天之內」，不是籠統的「可以寄」。換了版本、換了收件人或過了期限，核准就失效。必須說清楚：對外三態與核准四綁定目前都只有規格，閘道還沒有實作這一段。

人在哪裡出現

把這麼多事交給閘道，人的角色是不是就消失了？剛好相反。我們刻意讓人只在少數幾個地方出現，但每一次出現都有分量。

• 核准：對外動作逐次核准；會動到資料夾結構的事，簽一張裁決卡。
• 被通知：完成、不確定、異常都會通知人，事後知道發生了什麼。
• 看今日清單：每天一張清單，不確定的項目排在最上面，先處理最可能出事的。

另外有一類事永遠不交給 AI：付款、刪除、改權限、輸入密碼。AI 可以把材料準備好，但最後那一下由人按。沒有人在的時候，系統不會因為「沒人可以問」就自己決定，而是自動降級：對外動作排隊等人，能逆轉的內部動作照做，不能逆轉的就停下。

走一遍：一個請求從頭到尾

用一個常見的例子把整條路走一遍。假設創辦人在手機上說：「幫新客戶開一個案，然後把歡迎信寄給對方窗口。」交給一個專案經理角色的 AI 處理。

• 認身分：AI 報出自己的角色，以及它代表創辦人在做事。身分找得到，通過。
• 查權限：開案在白名單上；綁定表裡，這個角色可以在指定範圍內開案。通過。
• 確認關卡：開案會建立資料夾，需要裁決卡。AI 先跑預覽，產出一張預覽卡，列出名稱、類型、位置、預設的資料等級，以及有沒有名字相近的既有案，然後停下來等。
• 創辦人看過預覽卡，回覆「可」，裁決卡記下確認人與決定。AI 帶著這張卡重新送出請求，第三關通過。
• 執行：AI 取得新案的鎖，依類型建立第一層資料夾與身分檔，寫完釋放鎖，再到登記處登記這個案。
• 留紀錄：事件紀錄追加一筆「開案成功」，包含路徑與身分檔前後的指紋。
• 限流：如果此時排程正好在跑同一種動作，後到者會停下回報，不會同時寫。
• 寄歡迎信是對外動作：再走一次六關，加上逐次核准，核准綁定這一版信件、這位收件人和期限。送出前記一筆、帶防重複鑰匙；送出時網路逾時，狀態落在「不確定」，AI 不重寄，先對帳，查到對方已收到，改記為已發生，並通知創辦人。

注意這個例子裡沒有發生的事：AI 沒有讀任何客戶既有的資料，沒有修改自己的權限，沒有把客戶名稱寫進共用元件，也沒有因為逾時就再寄一次。這些「沒發生」，正是前面那些方向和關卡存在的意義。最後一步的對外三態目前是規格，現在仍由人親手寄出並確認。

重點回顧

• 治理基座同時是登記處與閘道：先登記才能被治理，權限只在一張綁定表裡回答。
• 引用只准朝固定方向走：案往下用基礎設施，基礎設施往中間登記；判斷法是「另一端消失，這端還能不能活」。
• 五個禁止方向：讀客戶資料、自授權限、在別處寫規則、存事實正文、依賴某個案；部分已有每日自動檢查，部分仍靠審查。
• 每個請求依序過六關：認身分、預設拒絕、裁決卡、持鎖執行、只追加紀錄、限流；被拒的也記一筆。
• 事件只喚醒不授權；對外動作分已發生、未發生、不確定三態，不確定先對帳。後兩者目前是規格。
• 人在核准、被通知、看今日清單三處出現；付款、刪除、改權限、輸入密碼永不交給 AI。