AI 時代的架構治理

作者 | Kyle Howard, Christian Johansen, Dana Katzenelson, Brian Rhot

譯者 | 明知山

本文由 InfoQ 認證架構師在線課程的學員撰寫，是其學習成果的集大成之作，反映了學員群體在 AI 與現代軟件架構交叉領域的集體學習心得。

代碼已成商品，對齊仍是難題

生成式 AI 大幅降低了編寫代碼所需的工作量，快速原型設計也變得越來越普遍。因此，如今軟件開發生命周期的瓶頸已轉變為組織將創意轉化為匹配自身能力的成果并在整個系統中保持凝聚力的能力。

圖 1. 來源：Eduardo Da Silva，經授權使用

一直以來，組織一直依賴人工流程與人工監督來保障架構的一致性。初創企業依靠核心技術人員捕捉架構設計與實際落地之間的偏差；大型企業則試圖通過變更管理委員會、不斷補充的 ADR（架構決策記錄）及相關文檔來維持架構凝聚力。但在這兩種模式下，偏差的識別都十分緩慢，因為都需要同步依賴中心化的權威決策。對初創企業而言，開發團隊需要等待忙碌的核心專家；對大型企業而言，則需要等待評審委員會審批，并在大量文檔化規范中進行篩選，還往往面臨內容已過時的問題。生成式 AI 進一步加劇了這一矛盾：以往開發者需要數天甚至數周才能完成代碼編寫，如今高管與產品經理僅需數分鐘或數小時內氛圍編程出功能原型。這使得開發團隊陷入了兩難困境：要么受制于人工審核速度而犧牲研發效率，要么在無法確認是否與整體架構對齊的情況下盲目推進進度。

隨著時間推移，這些零散的推進不斷累積，最終導致架構碎片化。組織往往通過增加流程、制定更嚴格的規范來應對，這反而進一步加大了發布對齊軟件的難度。這一惡性循環拖慢了交付速度，也削弱了創新能力。

聲明式架構，去中心化的對齊

要在生成式 AI 時代提升架構對齊能力，組織需要擺脫單純依賴人工監督的模式，轉向自動化防護機制，讓團隊能夠自主做出合規且安全的決策。為此，我們提出聲明式架構策略來實現架構治理的規模化擴展。

聲明式架構將架構決策與約束提煉為可由機器強制執行的設計意圖聲明，從而支持安全、獨立的研發行動。每個聲明都管控著一個明確的作用范圍，即在一個清晰界定的上下文內擁有執行權限。若缺乏這一邊界約束，聲明就會淪為它們本應取代的、臃腫散亂的設計指引。

聲明式架構的目的并不是為了做出更優的決策，而是確保決策不會被忽視。相較于查閱解讀架構文檔、等待專家或評審委員會的意見，機器可讀的架構意圖聲明讓合規路徑成為阻力最小的選擇。合規驗證不再依賴人為意識與記憶，而是被集成到開發者日常使用的工具中，包括編輯器、構建管道與代碼審查工具。在這一框架下，機器可讀性并非技術上的錦上添花，而是核心要求。僅能被人類理解的聲明依然需要人工參與校驗；只有可被機器推理的聲明才能讓治理能力超越個人或評審委員會的處理上限。后續章節中，我們將探討從事件模型、OpenAPI 規范及 ADR 中提煉聲明式架構的實際應用。

事件模型作為聲明式架構

事件模型描述了信息在系統中的流轉方式，通常通過協作建模來生成。

圖 2. 帶有高亮垂直切片（綠色矩形）的事件模型。每個切片是一個自包含的行為單元，擁有自己的命令、事件和讀取模型。來源：Adam Dymitruk，Adaptech Group

畫布上的可視化便簽內容被一一對應轉錄為具備形式化 Schema 支持的 eventmodel.json 文件中。該 eventmodel.json 構成了系統的聲明式架構：它是一份機器可讀的架構意圖藍圖，可據此生成符合規范的實現，也可讓智能體對照著對實現進行評估。

圖 3. 從事件模型到生成代碼

1. 為自動化提供支撐

垂直切片具有明確的邊界范圍，包含描述單個行為單元所需的聲明。這種最小化范圍是在各個層面實現自動化的關鍵。代碼工件可使用代碼模板從事件模型確定性地生成，無需依賴 AI。同時，由于每個切片都是自包含的，代碼工件也按切片進行組織（參見垂直切片架構）；一旦出現問題，只需替換單個切片，而無需拆解復雜的依賴網絡（仍需遵守對外部依賴的相關契約）。對于模板無法覆蓋的場景，形式化 Schema 可讓 AI 發揮更大作用。Nebulit 的 Martin Dilger 定義了一套 Claude 規則文件文件，用于分析代碼庫并從中生成事件模型。領域專家隨后可以通過 AI 智能體審查和優化模型，實現比代碼更高抽象層次的對話式編程。由于范圍被最小化，人與 AI 均可聚焦于獨立切片，大幅降低認知負荷。正是這種最小化范圍使得 Ralph Loop（下文詳述）得以實現，讓每個切片成為 AI 智能體的獨立迭代目標。

2. 大規模去中心化架構對齊

事件模型能夠實現去中心化，但其前提是建模過程必須跨團隊協作進行。如果各團隊在孤立環境中獨立建模，每個團隊的事件模型或許會在內部保持一致，但可能導致整個產品出現架構碎片化。Adaptech Group、Nebulit 等機構已實踐了覆蓋多個團隊的多領域協作建模，驗證了該模式可以拓展到單一團隊邊界之外。諸如 architecture.md、OpenAPI 校驗工具（下文會提到）這類技術對齊機制能強制規范系統的構建方式，但無法保證團隊協同構建出正確的產品。這就需要覆蓋范圍更廣的共享建模，例如事件建�；蚱渌麉f作式設計方法。好消息是：技術治理將人類的注意力從監督實現細節中解放出來，為實現產品級的架構對齊創造了空間。

3.Ralph Loop：從切片到交付

Ralph Wiggum Loop 是多種 AI 循環機制之一，智能體會反復執行任務，直至滿足完成標準；每次迭代都會以全新上下文重新啟動，避免推理能力退化。在早期迭代階段，通常會由架構師參與其中，對配置進行調整與驗證。這張圖展示了 AI 輔助 ADDR 流程在第二次迭代中的輸出結果示例。

事件模型中的每個垂直切片都對應一個迭代目標：智能體讀取切片規范、完成實現，并對照 Given-When-Then 規范進行驗證，循環執行直至驗證通過。由于每個切片都采用最小化范圍，能夠適配單個上下文窗口，即便使用輕量化模型，在這種條件下也能產出可靠的結果。

規范 + 垂直切片 = AI 的糖果（來源：Martin Dilger）

圖 4. Ralph Loop 文件結構

這個結構清晰地展現了整個流程：plan 文件夾相互獨立，支持并行執行。每個文件夾都包含獨立的進度標記、實現復選框與日志記錄。反饋循環中產生的決策與經驗會在各 plan 之間累積。當這些內容足夠重要時，由開發人員進行審核，并更新 AGENTS.md。智能體的行為基于整理后的經驗進行演進，而非自動自我修改。每次迭代都會產生組織知識，作為工作產出的副產品。[代碼庫鏈接]

4. 事件建模的前景

圖 5. Wardley 地圖：事件模型工具演進

上面的 Wardley 地圖展示了 AI 的工業化應用路徑：將成熟的事件模型工具與新興的模式標準相結合，催生出一種全新模式——對話式 AI 事件建模。這個過程將領域專家與生成式 AI 相結合，通過對話而非編寫代碼來完成系統建模。在上述事件建模工作流中，代碼成為可丟棄的產物。切片具備最小范圍且定義完整，受模板與架構的約束治理，無需人工維護，可直接從規范重新生成。這重新定義了遺留系統現代化的路徑：不必重寫數百萬行代碼，只需對領域建模并據此生成全新代碼即可保證系統持續保持架構對齊。

事件建模在領域行為層面開展，將業務意圖提煉為可由機器執行的切片。而這套聲明式模式同樣適用于領域邊界之外。當行為完成建模并在內部實現后，外部接口也必須保持一致。聲明式架構并非只局限于內部切片，還可延伸至維系系統協同的各類契約。

OpenAPI 驗證器作為聲明式架構

以一家中型企業為例，該企業運營著高度分布式的 SaaS 平臺，包含數十個由自治團隊負責的數百個組件，主要通過 HTTP API 進行交互。以往，該組織高度依賴隱性的個人架構負責制與“標準與實踐”文檔。所謂“正確”的做法，很大程度上取決于團隊咨詢了哪些人、最先查到哪些文檔。團隊往往難以找到最優方案，進而在項目初期就埋下架構偏離的風險。而在執行過程中，各類臨時決策會進一步加劇這種偏離，導致架構設計意圖與實際落地之間的差距不斷擴大。

該組織正處于增長的關鍵節點，計劃推出面向客戶的 API 層。組織優先保障兼容性與易用性，以最大化這一新接口的使用率。同時，它也希望保留高度自治團隊所帶來的高效交付優勢，并意識到當前臨時化的架構治理方式已形成瓶頸。此外，該組織還希望確保架構能夠持續適配不斷變化的業務需求。

為了調和這種緊張關系，該組織采用了基于 OpenAPI 規范的聲明式架構方案：由中央平臺團隊制定標準并提供校驗工具（代碼檢查工具）。這些校驗工具將平臺團隊的架構意圖進行編碼，向開發團隊提供合規性自動反饋，并集成至 CI/CD 流程中，避免生產環境出現架構偏離。同時，這類工具也被整合進開發者工作流（如 IDE 插件、GitHub 狀態檢查），實現快速反饋并將偏差檢測左移。這種集中決策、分散執行的模式保障了跨領域 API 在路徑規范、版本控制與向后兼容、分頁設計、錯誤結構等方面的一致性，最終為內部產品團隊與外部 API 使用者提供流暢的開發者體驗。

這種方法可以自然地融入到組織現有的軟件生命周期中，而該生命周期本身就高度依賴聲明式基礎設施與獨立可部署能力。每個團隊的 OpenAPI 規范均作為 API 的部署配置來使用，平臺會將 OpenAPI 文檔轉換為 API 網關配置、授權策略及面向用戶的文檔。由于所有開發團隊共用一套標準化的構建、測試、部署流水線，平臺團隊只需通過一個統一且可預期的節點即可強制執行架構意圖，無需逐一對各團隊進行協調。各團隊可繼續沿用他們熟悉的現有流程，部署時的校驗機制從根本上杜絕了架構偏離的可能性。只有驗證通過部署才能成功，因此存在偏差的內容永遠不會進入生產環境。

圖 6. 包含構建時與部署時校驗的 API 生命周期

這種模式旨在為開發團隊降低認知負擔、提升自治度，同時在生產環境中實現嚴格的架構一致性，最終為客戶提供統一且直觀的 API 體驗。前期反饋表明，該方案正按預期落地：如今 API 團隊可以直接將通過的驗證結果作為客觀依據，而這些治理需求以往需要數天甚至數周的人工審核。

由于架構意圖已被編碼為機器可驗證的規則，架構對齊變得可觀測。平臺團隊通過校驗工具收集各類遙測數據，包括校驗錯誤率、變更前置時間、產品團隊反饋等，以此識別系統性的流程阻塞。重復出現的違規通常意味著標準不夠清晰或不切實際；較長的前置時間可能表明約束過多；而持續較低的違規率則說明相關約定穩定可行。

正如 ADDR 流程中的 R 環節用于優化 API 設計，這類校驗工具的反饋也能讓架構意圖本身持續迭代。平臺團隊基于實際觀測到的行為優化規則，而非依靠定期修訂標準或臨時討論。架構隨業務同步演進，團隊也能順勢做出調整。

確定性驗證守護著系統邊界，但架構遠不止語法與結構。它是長期積累的判斷力，而這種判斷力無法被規整地寫進檢查規則里。

關于架構決策記錄

“在項目生命周期中，各項決策背后的核心動機是最難追溯的內容之一。” ——Michael Nygard，2011 年

架構決策記錄（ADR）是軟件開發項目中各項重大變更背后的推理依據。它能夠將相關背景從決策者傳遞給后續負責維護系統的人員，而這類背景信息往往會因敏捷開發動態迭代的特性而丟失。

ADR 提供了一套聚焦于識別權衡方案與替代選項的決策框架，同時補充了各類上下文信息——這些信息對最終決策的影響往往甚于單純挑選“更優方案”本身。ADR 也成為了驅動軟件系統持續演進的集體決策歷程記錄。

然而，隨著生成式 AI 的出現，研究時間大幅縮短，生產力預期也在不斷提升，ADR 很可能難以有效地達成目標。人反而成了瓶頸，這在那些要求決策記錄在實施前必須審批通過的組織中，問題會尤為突出。Michael Nygard 在 2011 年的博文中就曾提到，“沒人會閱讀長篇大論的文檔”，這也是他設計 ADR 的初衷之一�？扇缃裎臋n可以輕松批量生成，即便短小的文檔也沒人看時，又會發生什么？智能體會是解決方案嗎？

architecture.md 作為聲明式架構

利用架構適應度函數對 OpenAPI 規范進行靜態分析只是第一步，而在規范驅動開發的當下，我們需要更進一步。確定性驗證器固然可以校驗語法、風格與結構，但應用程序本身的設計意圖該如何保障？

確定性工具只知曉你明確告知它們的內容，它們無法指出一個完全有效的 REST 端點違反了要求內部通信使用異步事件的核心架構決策，除非依賴脆弱的白名單和例外。以往，我們試圖通過“左移”和引導開發者查閱大量架構決策記錄（ADR）維基文檔來彌補這一差距，但這會給團隊帶來沉重的認知負擔。我們并非真正做到左移，而是將負擔直接轉嫁給了開發側，這必然會導致架構隨著系統擴展逐漸偏離設計初衷。

我們需要一種既能理解指導方針的字面含義又能領會其核心精神的機制。我們需要將架構提煉為智能體模型可執行的格式，在開發過程中實時為開發者提供指導，而不只是對代碼進行把關校驗。

引入 architecture.md

這份文件是將我們的架構指南精簡提煉為智能體友好型指令的成果，可在每次執行時靈活且一致地應用。將海量陳舊的維基文檔直接交給智能體只會引發混亂與幻覺，甚至導致流水線停滯。因此，每份 ADR 都必須提煉成人類與智能體均可理解、并能應用到代碼中的簡潔指令：

我們做 X 而不是 Y。

當 C 為真時，我們優先選擇 A 而不是 B。

每個 ADR 和技術要求都有獨立的適用范圍與處理方式，被封裝為意圖的原子單元。

* [ADR-073] [警告] 禁止記錄包含個人可識別信息（PII）的請求體。日志記錄前需通過 `Redact()` 工具對載荷進行脫敏處理。

圖 7. architecture.md 示例

閉環：自動化治理

如果我們放任靜態文件過時，它們就變得毫無用處。為了避免 architecture.md 變成又一個陳舊的維基頁面，我們將它作為代碼進行管理。治理智能體可在每日夜間運行，將倉庫清單與中央 ADR 語料庫進行比對，若檢測到新增或已被替代的決策，便會自動發起拉取請求更新規范，確保倉庫始終不會偏離企業基準架構。

隨著實現逐步成熟，你可能會遇到 architecture.md 變得臃腫的情況，但這個問題可以通過使用目錄結構輕松解決（如 這個提案，加上 agents.md，將限定范圍的片段放在單獨文件中）。

有了經過驗證的清單，運行時執行就變得簡單。無論是以 GitHub Action 還是本地 IDE Copilot 的形式運行，智能體只需獲取相關條款（例如僅在涉及 Schema 文件時加載數據規則），評估代碼的語義意圖，并提供就地修復方案。

如果你的架構是一份可執行清單，你的工具就不再是批評者，而是協作者。用于指導智能體進行代碼審查的同一份文件既可以作為生成適應度函數的依據，也可以作為基礎設施身份的驗證依據。我們不只是在左移，而是為“左側”提供了清晰的指引。

結 論

在生成式 AI 時代，代碼與文檔的編寫已趨于通用化，因此保障整個組織內的一致性與標準變得比以往更為關鍵。通過采用聲明式架構與反饋循環，組織能夠持續演進，并自動化地落實架構意圖。運用事件建模、OpenAPI 校驗、架構決策記錄等行業標準實踐，并將成果提煉為機器可執行的架構意圖聲明，組織可以讓團隊高效推進工作，同時保持高度一致且可靠的協同。這種模式可擴展至智能體流程，覆蓋以往僅能由人工驗證工作意圖的場景。

為消除集中式治理帶來的瓶頸，架構決策必須直接編碼到用于生成和驗證實現的工具中。合規路徑應當是最簡便的路徑。生成器應在項目啟動階段及開發者工作流內部發揮作用。驗證器則應集成到 IDE、拉取請求和部署環節中。交付管道之外的治理機制很容易被繞過，而嵌入到流程中的治理機制變得隱形且自動化。這些機制必須配備能夠持續演進聲明式架構的反饋循環。

代碼如今已十分充足，但對齊一致性卻并非如此。架構治理的未來不在于更多審查委員會或更完善的文檔，而在于持續執行與優化聲明式意圖，使其與所治理的系統保持同速演進。

查看英文原文：

https://www.infoq.com/articles/architectural-governance-ai-speed/

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。