本文是對《AIOS助力數字化項目建設的暢想與實現路徑》 https://idealworld.group/2024/10/05/aios/ 文章中“AI即系統”概念的延伸探討。

現狀

“軟件系統”這一概念幾乎每個人都不陌生。根據維基百科的定義：軟件系統是基于計算機系統的軟件（硬件和軟件組合）的組成部分。它通常由多個單獨的程序和配置文件組成，這些程序用于配置系統，提供運行環境，支持系統文檔和用戶文檔。 我們日常生活中常會提到“某某系統出現問題”或者“登錄某某系統”等等。

在軟件行業，許多項目以“系統”作為開發和運營的邊界。尤其是數字化企業，通常需要多個系統來滿足業務需求，有時甚至數千個系統并存。

?

上圖為一個典型的企業系統化架構，其中云平臺提供IaaS和PaaS能力，在此之上構建了包含多個系統的公共能力層，并基于公共能力層按業務領域構建各個業務系統。

系統化架構的困境

盡管這種系統化架構在過去十幾年里取得了一定的成功，但隨著企業規模的擴大，技術的日新月異，這種架構暴露出了越來越多的問題，具體表現為以下幾點：

1. 運維保障難
   各系統使用不同的技術、運行環境，運維團隊必須掌握多種技術和工具，導致運維成本居高不下。比如，數據庫的運維可能需要同時管理MySQL、Oracle、PostgreSQL等多種技術；
2. 業務集成難
   各系統之間的交互協議差異巨大，導致業務集成變得困難且低效。比如，某些系統可能使用SOAP協議，其他系統則采用RESTful或gRPC協議；
3. 二次開發難
   由于不同系統使用不同的開發語言和框架，二次開發的難度加大。比如，某些系統使用Java，而其他系統則使用Python或Go語言；
4. 邊界界定難
   各系統的邊界模糊不清，導致業務流程的復雜性增加，并且存在重復開發的情況。比如，公共能力中提供了IAM能力，但仍有許多系統自建用戶管理功能，結果導致重疊開發，無法充分利用公共能；
5. 數據治理難
   各系統的數據存儲方式、業務命名不同，導致數據治理困難。比如對用戶域的主數據命名不一致，A系統可能稱之為“用戶”，B系統可能稱之為“客戶”，C系統可能稱之為“會員”。

這些問題的積累使得以“系統”為邊界的數字化架構不僅增加了數字化的投入成本，而且在業務快速變化的背景下難以有效支持業務創新，同時難以滿足用戶體驗和數據治理的需求。

規范與中臺的演進

為了解決上述問題，業界普遍采取了兩種策略：制定規范、建設中臺/平臺。

許多規模較大的企業都會制定針對軟件采購、設計、研發、部署和運維的統一規范。這樣做的核心目的是解決不同系統之間在開發、運維和數據層面上的不一致性。然而，確保規范的全面性和執行力卻往往是一個巨大的挑戰。為什么這么說？

最基礎的兩個問題是：怎么確保規范可以滿足絕大部分的業務需求？怎么確保規范的執行落地？ 這需要企業有足夠的規范制定能力、執行能力，以及對規范的監督能力。對于大多數企業來說，規范都只流于紙面，很難真正落地。

核心的原因是什么？康威法則（Conway’s Law）指出： “Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.” 簡而言之就是 什么樣的組織架構產出什么樣的系統架構 。當我們都在關注軟件規范設計執行時，實際上真正要先改變是組織架構。不同研發團隊、業務團隊的匯報關系、考核方式、利益分配方式，是導致不同系統間不一致且規范無法推行的根本原因。

在此背景下，“組織先行”的理念應運而生。即在進行中臺建設之前，先調整組織架構，將多個小團隊合并成規模更大的跨領域團隊，進而提高規范執行力，從而解決不同系統間的割裂與不一致性。

上圖為中臺化架構的示意圖，能夠看到將相關能力相近的系統整合到同一領域中，形成了數據、技術和業務的中臺。中臺建設有一個通俗的說法是“打山頭”，本質就是對系統進行整合和歸并，減少不必要的重復建設，然后再基于相對統一規范的服務化能力，構建一個個小微應用。

但是，中臺化的架構也是“理想很豐滿，現實很骨感”。我在往期多次講過，這里不贅述了。盡管這種做法能夠減少系統數量，提高業務能力的一致性，但它并沒有解決“系統化”的本質問題，只不過是將多個小系統合并成一個大系統。更重要的是，跨中臺之間的協調問題仍然沒有得到有效解決。

軟件架構的本質

在繼續深入探討之前，我們不妨先回顧一下幾個核心問題：

軟件的本質是“數據+算法（或流程）”的集合。數據是軟件的基礎，算法是其靈魂。軟件的最終目的是處理數據，并通過算法實現特定的業務邏輯。

軟件的最小單位是“函數”。函數是軟件的基本構成單元，函數之間通過參數傳遞數據，通過返回值傳遞結果。為了能夠更好的復用函數，我們將函數封裝成類、模塊、庫、服務等。

應用是為了解決某個具體的業務問題而開發的軟件，并提供用戶界面。而系統則是應用的集合，旨在解決一類或多個業務問題。

軟件的架構就是一層層的套殼（封裝），是典型的洋蔥架構。在這個架構中，數據和算法是軟件的核心，從最抽象的維度看，只要設計好了數據和算法，軟件就可以運行。但從工程的角度看，我們需要將數據和算法封裝成函數，將函數封裝成類、模塊、庫、服務，將服務封裝成應用、系統。

這也是“系統”存在的原因。在以前當我們說要去“系統”化時可能是天方夜譚，中臺（本質還是大系統套小系統）化架構也未能解決。

但是，我們要明確的是工程化的手段也隨著技術的進步在不斷的演進。當我們從軟件的本質出發，重新審視軟件的架構時，會發現：其實我們并不需要那么多的系統，在AI時代，只需要一個“AI系統”就夠了。

AI即系統

在之前的文章中，我提到過AI服務于數字化建設的階段：模塊AI化、系統AI化、AI即系統。AI即系統是數字化建設的最終目標，指的是將AI深度融入企業的核心業務和運營機制，推動業務從傳統系統向全面智能化系統的轉型。從傳統的根據需求建立一個個領域系統轉變成構建一個由AI驅動的大系統，通過自然交互實現需求。此階段的核心特征是系統的全面智能化和自我優化，AI不僅支撐決策，還能直接執行業務操作，形成從決策到執行再到交互的自動化閉環。

下文將進一步探討AI即系統的架構。

在AI即系統的架構中，AI操作系統（AIOS）是核心，它不僅具備常規的AI能力，還具備以下三個關鍵能力。

關鍵能力

數據管理能力

數據是AI的基礎，若沒有高質量的數據，AI便無從談起。

數據管理的目標一是要能按規范“分門別類”地規劃存儲；二是要能按權限“安全可靠”的讀寫；三是要能按需求“快速準確”的查詢。

數據管理在功能上包括數據采集、清洗、歸一化、存儲、查詢等能力。PaaS層提供包含事務型的操作類數據及分析類數據的通用化的計算、存儲能力，AIOS則實現定制化的數據處理能力。

數據管理在技術上沒有特別之處，這一領域也不是AI所特有的。整體上是要將企業的領域模型與主流的數據治理的方案（比如DAMA-DMBOK）相結合。

當然，如果一定要說AIOS在數據管理上有什么特別之處，可能有兩點：一是具備明確、規范的元數據信息，以確保AI可以準確地理解數據；二是包含更多向量的數據，以便AI可以更好地處理數據。

Agent管理

Agent也叫智能體，目前Agent是一個很寬泛的概念，可以是一個簡單的腳本，也可以是一個復雜AI產品。

對AIOS而言，Agent的目標一是要能具備原子化數據CURD、函數（算法）的執行能力；二是要能具備針對一組流程化的需求的編排能力。

Agent在技術上最基礎的是要能基于Function Call實現函數調用，其次要能具備聯網查詢、數據處理、API調用等通用化的能力。每個Agent本質上就是一個個有副作用（因為涉及外部數據）的函數。

響應式交互框架

為了能將用戶的需求轉化為AIOS的操作，AIOS需要具備響應式交互能力。

響應式交互框架可通過語音、視覺的方式輸入用戶意圖并返回結果。何為“響應式”？就是能夠根據用戶的輸入實時調整輸出。比如用戶說“我要看最新的銷售數據”，AIOS可以實時返回最新的銷售數據，而不是返回一個固定的、包含其它冗余信息的結果。

響應式交互框架在技術上最核心的是要構建一套DSL，要求Agent可以返回DSL格式的結果，同時AI也可以根據DSL格式的輸入轉換成純文本、圖像、復雜排版（HTML格式）的輸出。特別是復雜排版的輸出，需要涉及對模型的微調或訓練，以確保輸出的結果是符合用戶期望的。

示例

AIOS最核心的三個能力介紹完畢，但在這此之上還需要構建一個響應式的通用應用，用于把響應式交互框架的能力包裝到不同的平臺之中。比如電腦、手機、智能音箱、車機等。

舉一個簡單的例子：用戶在手機上通過響應式的通用應用說“我要看最新的銷售數據”。其流程如下（需結合《AIOS助力數字化項目建設的暢想與實現路徑》一文理解）：

1. [響應式的通用應用]用戶說出“我要看最新的銷售數據”；
2. [響應式交互框架]將用戶的語音轉化為合法的文本DSL作為輸入；
3. [推理執行鏈-融合感知]根據Token獲取用戶身份，并將權限信息附加到請求中；
4. [能力監管]內容審計；
5. [推理執行鏈-意圖理解]根據AI明確要查詢銷售數據，條件是最新記錄；
6. [推理執行鏈-Function Call]命中銷售查詢Agent，但缺少必要的產品類型參數；
7. [響應式的通用應用]提示用戶補充要看的產品類型；
8. [銷售查詢Agent]用戶補充后進入銷售查詢Agent，該Agent根據傳入的業務參數及權限條件生成業務查詢SQL；
9. [數據管理]在數據管理中查詢SQL并返回；
10. [銷售查詢Agent]將查詢結果轉換成合法的DSL作為輸出；
11. [能力監管]內容審計；
12. [響應式交互框架]根據DSL轉換成復雜排版（HTML格式）顯示結果界面：一個整體的最新銷售數據、按地區/門店的最新銷售數據。

主流AI能力

除了這幾個關鍵能力外，AIOS還需要具備主流的AI能力，以用于構建模塊AI化、系統AI化。比如通過OpenAPI、低代碼，將AI能力暴露給開發者，以便于構建較為固定的業務應用（上圖的應用1、2、3）。

小結

“AI即系統”代表了數字化建設的終極目標，它不僅僅是一種技術升級，而是徹底改變企業運營的方式。屆時企業數字化只有一個系統，即AI操作系統。通過將AI深度融入企業的核心業務，AI操作系統將極大提升效率和智能化水平，企業將不再依賴傳統的多個分散系統，而是依托一個智能化的系統平臺來驅動所有業務。這一愿景盡管尚未實現，但隨著AI技術的飛速發展，我們可以期待這一目標在不遠的將來成為現實。

彩蛋：納德拉在一次采訪中所表達的AI Agent或將替代所有SaaS （ https://www.youtube.com/watch?v=d6J4H1KaJ0A ） 也是對這個方向的一個預言。

閱讀原文：原文鏈接