六個平面：一家 AI 公司的基礎架構怎麼分層

想像一家正在把大量工作交給 AI 的公司。一開始很單純：行銷部門接了一個聊天機器人，業務部門做了一個自動報價的小工具，交付團隊寫了幾個自動整理資料的流程。每一個都能用，每一個都解決了眼前的問題。半年之後，問題開始浮現：三個工具各自存了一份客戶名單，內容彼此不一致；每個工具都有自己的權限設定，沒有人說得清楚哪個 AI 能動哪份資料；某個流程寄錯了一封信，大家翻遍三個系統，才拼湊出到底發生了什麼。

這不是哪個團隊做錯了什麼，而是基礎設施沒有形狀。每個人都在蓋自己需要的東西，蓋的時候沒有一張共同的地圖，告訴大家「這一塊屬於哪一層、該向誰報到、不准往哪裡伸手」。這篇文章要介紹的，就是我們用來替基礎設施畫地圖的方法：六個平面。

先說清楚一件事：六個平面是一套分類與約束的規則，不是一套已經全部寫完的軟體。其中有些部分已經有程式在執行，例如登記與權限的查核；有些部分仍只是規格，或還在觀察期。文中會盡量把這兩者分開說。

為什麼要分平面，而不是分系統

最直覺的分法，是按系統分：報價系統、客服系統、專案系統。這種分法對使用者很友善，但對基礎設施很危險。因為每個系統都需要權限、需要記憶、需要儲存、需要被稽核，如果按系統切，同一種能力就會在每個系統裡各長一次。長出來的那幾份不會一模一樣，於是公司裡出現了好幾個「真相」。

平面換了一個問法。它不問「這東西屬於哪個產品」，而是問「這東西在回答哪一種問題」。誰說了算，是一種問題；規則是什麼、誰被允許做什麼，是另一種問題；實際動手做事，又是另一種。把回答同一種問題的東西放在同一層，同一種能力就只需要蓋一次，所有人共用。

我們最後收斂成六個平面，每一個都可以用一句話說清楚它負責什麼：

• 人類決策：誰說了算。哪些人有席位、誰能拍板、誰是最後的確認人。
• 控制：規則、登記與權限。公司有哪些規則、哪些東西已經登記、誰可以做什麼。
• 執行：實際動手。AI 代理的能力、流程，以及和外部系統的連接。
• 知識與產物：事實、記憶與交付物。公司知道什麼、做過什麼、產出長什麼樣子。
• 品質與可信：評測、稽核與復原。怎麼知道做得對，出錯時怎麼查、怎麼退回。
• 平台底座：機器、儲存、模型與成本。一切跑得起來的最底層。

這六個平面有一個隱含的方向：上層可以依賴下層，下層不認識上層。執行平面上的 AI 代理可以去讀知識平面上的事實，可以用平台底座上的機器；但儲存底座不應該知道某個代理在做什麼報價。方向一旦反過來，底層就會被某個特定用途綁住，換掉上層的時候底層也得跟著改，整個結構就失去了「可以替換」的性質。

一塊東西只能有一個家

平面規則裡最嚴格的一條是：每一塊基礎設施只能住在一個平面上。這聽起來有點死板，例如「記憶與回饋」看起來既和知識有關，也和品質有關。為什麼不允許它同時屬於兩層？

原因在於「誰負責」。如果一塊東西同時屬於兩個平面，那麼當它出問題時，兩邊都會覺得對方該處理；當它需要改版時，兩邊各有一套演進的節奏。一個家，意味著一個明確的負責範圍、一套版本節奏、一個出錯時可以去找的地方。至於「它也被別的平面用到」，那很正常，用到不等於住在那裡。

所以在實際歸類時，我們問的是：這塊東西最核心的職責是什麼？記憶與回饋的核心是保存接續卡和反思紀錄，讓下一次工作能接上，這是「公司知道什麼、做過什麼」，因此它住在知識與產物平面。品質平面會去讀這些紀錄，但不擁有它們。

同樣的邏輯也套用在介面上。介面元件和設計 token 看起來像是給產品用的，但它們真正回答的是「畫面要長成什麼樣、哪個版本才是正式版」，這是一種規則，所以介面住在控制平面，旁邊的鄰居是治理基座本身。

每一塊都向治理基座登記

有了平面，還需要一個地方記住「現在到底有哪些東西」。這個地方就是治理基座。它坐在控制平面的中心，同時扮演兩個角色：登記處與閘道。登記處記下每一塊基礎設施的存在、版本和它所屬的平面；閘道則是任何人或任何 AI 要動資料之前都必須通過的地方。

登記的意思很具體：一塊基礎設施要被公司其他地方使用，必須先在治理基座留下一筆紀錄，說明它是什麼、屬於哪個平面、目前是哪個版本、由誰負責。沒有登記的東西，在公司眼中就不存在，其他地方也不應該依賴它。這條規則的好處是，任何時候都可以回答「公司現在有哪些基礎設施」，而不是靠記憶或翻聊天紀錄。

登記之外，治理基座還是權限的唯一來源。誰可以做什麼，只寫在一個地方，也就是它的綁定表。每一塊基礎設施要做事，都向治理基座申請權限，而不是自己決定。這背後的理由很簡單：只要權限有兩個來源，兩邊遲早會不一致，而不一致的地方，正好就是事故發生的地方。

圖中還有一類東西刻意被畫在外面：案，也就是實際的工作倉儲，例如某一件客戶專案、某一個內部專案或某一個產品的工作區。案不是基礎設施。案會用到基礎設施，鎖定介面的版本、引用知識的事實編號、使用某一版 Agent 能力，但反過來，基礎設施絕對不可以依賴任何一個案。

五個不准走的方向

比起「應該怎麼連」，我們發現「不准怎麼連」更能保住結構。圖中的紅框列了五個禁止方向，每一個背後都有一種具體的壞事：

• 基礎設施不得讀客戶資料。基礎設施是共用的，一旦它讀過某位客戶的資料，那份資料就可能在別的案裡被帶出來。客戶資料只存在於該客戶的案裡。
• 不得自己給自己權限。一個 AI 代理如果可以修改自己的權限，所有的權限檢查就形同虛設。權限只能向治理基座申請。
• 不得繞過基座自己寫規則。規則一旦散落在各處，就沒人說得清楚目前生效的是哪一條。
• 不得在基礎設施裡存事實的正文。基礎設施只引用事實的編號，正文只存在知識平面的一個地方，否則同一個事實會有好幾個版本。
• 任何基礎設施都不得依賴某個案。例如介面不能依賴某個產品；一旦依賴，那個產品一改，共用的介面就跟著壞。

結構不是靠大家記得怎麼連來維持的，而是靠「哪幾條線永遠不准畫」。

這五條目前的性質並不相同。權限只能從治理基座取得、子命令不在白名單就拒絕，這部分已經有程式在擋；至於其他幾條，有些靠登記時的檢查，有些仍是寫成文字的規則，需要靠審查來守。我們把這個差別清楚記下來，而不是假裝五條都已經自動化了。

九個領域共用同一組平面

基礎設施有了平面，業務也需要有自己的分法。公司的工作分成幾個領域：公司治理、公司戰略、核心引擎、創新研發、方法論、生產交付、品牌發展、成長飛輪與產品。另外還有一個領域專門負責建造和維護平面本身，它不列在下面這張表上，因為它是蓋房子的人，不是住戶。

這張表最重要的訊息是：沒有一個領域擁有自己的一套基礎設施。每個領域都只是在不同平面上「取用」能力。公司治理最常用到人類決策、控制和品質三個平面，因為它的工作是拍板、定規則和查核；生產交付主要用執行和品質，因為它的工作是把東西做出來而且做對；品牌發展主要用執行和知識，因為它要產出內容，而內容必須建立在正確的品牌事實上。

如果讓每個領域各自蓋一套，會發生什麼事？品牌領域會有自己的一份品牌事實，成長領域也會有一份，兩份很快就不一樣；交付領域會有自己的權限設定，產品領域也有一份，兩份也很快就不一樣。九個領域就會有九套權限、九份記憶、九種稽核方式。表上看起來是九個獨立的格子，實際上是九個需要分別維護、分別出錯的系統。

讓領域經過平面取用，還有一個不太明顯的好處：領域可以只說「我需要什麼」，不必關心「怎麼提供」。成長領域說「我需要知道哪些客戶上個月有互動」，它不需要知道資料存在哪一台機器、用哪一個模型處理。平面負責把這件事穩定地提供出來，領域則專心處理自己的業務判斷。

候選的三種去向：留下、併入、移出

平面規則最常被用到的場合，其實是在決定「這個東西該不該成為基礎設施」。隨著工作推進，總會有人提出：我們是不是需要一個客戶管理的基礎設施？一個財務成本的基礎設施？一個評測的基礎設施？這些提案一開始都先放在觀察區，當作候選，然後過一道篩選。

• 留下並登記：它被多個領域共用，而且能清楚落在一個平面上。例如記憶與回饋，幾乎每個領域都需要接續上一次的工作，它的職責也明確屬於知識與產物。
• 併入既有的一塊：它的職責和既有的某一塊重疊，若分開，就會出現兩個真相。例如評測與品質，原本被提為獨立的一塊，但評測的對象主要就是 AI 代理的能力，兩邊的版本必須同步演進，因此併入 Agent 能力，一起管理。
• 移出，改列領域需求：它只服務單一領域，或者它其實是業務本身而不是底座。客戶與夥伴、法務合規與資產、財務與成本，這三個候選最後都被移出，改列為相關領域的需求。

移出不代表這些事不重要。客戶關係、法務與財務當然重要，但它們是「業務內容」，不是「讓業務跑起來的底座」。把客戶資料做成一塊基礎設施，就直接違反了「基礎設施不得讀客戶資料」這條禁止方向；把財務做成基礎設施，會讓底座開始理解業務邏輯，下層就認識了上層。把它們放回領域，由領域經平面取用儲存、權限與稽核，結構反而乾淨。

這個判斷也誠實地留有未定的部分。例如 Agent 能力本身，目前仍在觀察中；它的範圍會隨著實際使用再調整。我們寧可讓一塊東西在觀察區多待一陣子，也不要太早把它登記成正式的基礎設施，之後再花更大的力氣拆掉。

走一遍：一份週報從請求到交付

用一個虛構但典型的情境，把六個平面串起來。假設某家公司的交付團隊，替一位零售品牌客戶每週產出一份活動成效週報。過去這份週報由人工整理，現在要交給 AI 代理起草，人負責審閱與寄出。

第一步發生在人類決策平面。誰是這份週報的確認人？誰有權決定它可以寄給客戶？這些資訊住在人員與席位裡。代理在任何時候都不會被當成確認人，它只能起草。

第二步是控制平面。排程觸發後，代理先向治理基座報上身分，再查詢自己能做什麼。綁定表說：這個代理可以讀這個客戶案裡的活動資料，可以寫入週報草稿，但不能寄信。報表的版面使用介面的哪一個版本，也在這裡鎖定，避免本週和上週長得不一樣。

第三步是執行平面。代理使用某一版的 Agent 能力開始工作，透過整合裡已登記的連接器，從外部的資料系統拉取上週的活動數據。連接器只能讀它被登記的範圍，不會因為代理好奇就多讀一份別的客戶資料。

第四步是知識與產物平面。代理需要品牌的正式名稱與用語，它不會把這些正文複製一份存起來，而是依事實的編號去讀知識平面。週報使用交付版型的固定格式；上週工作留下的接續卡，告訴代理上次客戶在意哪一項指標。

第五步是品質與可信平面。草稿完成後先經過評測，檢查數字是否和來源一致、格式是否符合版型；每一個動作都寫進只准追加的事件紀錄。若評測不通過，草稿退回，不會流到人手上。

第六步是平台底座。整個過程跑在執行環境的排程與機器上，資料依等級存放在儲存底座，模型與運算的成本也落在這一層記帳。最後，確認人審閱草稿、決定寄出；對外的寄送動作是由人簽核的，而不是代理自己決定。

從領域的角度看，這件事屬於生產交付領域，它主要用到執行與品質兩個平面；品牌用語的部分則借用了品牌發展領域維護的知識。沒有任何一個領域為這份週報另外蓋一套權限、記憶或儲存，它們都只是取用同一組平面。

這套做法的代價與還沒做完的地方

任何分層都有代價。最明顯的一個是：要多走幾步。過去一個小工具可以直接讀資料庫、直接寄信，現在必須先登記、申請權限、引用事實編號。對只做一次的小事來說，這確實比較慢。我們接受這個代價，因為省下來的是之後每一次出錯時的追查成本，以及每一次換掉某一層時的重寫成本。

第二個代價是歸類本身需要判斷。某一塊東西到底屬於哪個平面，有時並不一目了然，也會有人不同意。我們的做法是把判斷寫下來，附上理由，必要時再改；平面的地圖本身也有版本，而不是一次定死。

最後要誠實說明目前的狀態：登記與權限的查核已經有程式在執行；禁止方向中有一部分靠程式擋，其餘仍靠規則與審查；Agent 能力還在觀察期；對外動作的完整狀態追蹤，目前仍是規格。六個平面給了我們一張清楚的地圖，但地圖上的每一條路，並不是都已經鋪好了。

重點回顧

• 基礎設施依「回答哪一種問題」分成六個平面：人類決策、控制、執行、知識與產物、品質與可信、平台底座；上層依賴下層，下層不認識上層。
• 每一塊只能有一個家，並且向治理基座登記；權限只有一個來源，五個禁止方向守住結構。
• 九個業務領域不各自蓋底座，而是經由同一組平面取用能力。
• 候選基礎設施會被留下、併入或移出；只服務單一領域或本身是業務內容的，就回到領域當作需求。
• 這是一套已部分落實的規則：有些部分有程式在擋，有些仍是規格，我們把兩者分開記錄。