AI 智能體在企業業務場景落地過程中的好壞與架構設計的工程化能力密切相關，特別是：總體架構分層設計、AI 智能體協作模式設計、MCP 工具調用標準化設計、AI 智能體編排框架設計等4個維度，本文結合我們實際落地的工程實踐視角，來展開剖析。

下文我們詳細剖析之。

一、AI 智能體總體架構分層設計

下圖展示了 AI 大模型時代和微服務時代技術架構分層設計的簡單對比，主要是為了明確領域層和基礎設施層的架構設計范圍。

在 AI 大模型時代，架構設計主要包括：AI 智能體的抽象定義、Tool 的抽象定義、業務 Prompt 的設計、業務數據的供給、經過微調的大模型以及完整的評測集。

明確這些架構設計分層技術目的是為了讓業務產品的開發和接入更多地圍繞這些關鍵部分展開。AI 智能體平臺需要提供與之配套的服務能力，比如：AI 智能體注冊與編排能力、Tool 接入能力、Prompt 調試能力、大模型微調能力和測評能力。

二、AI 智能體協作模式設計

1、互聯網架構的演變

如下圖所示，過去的互聯網架構經歷了從單體服務到微服務/云原生的架構演變。這種架構演變本質上是對業務系統高內聚低耦合的實踐。比如：一次優惠活動的創建，可能涉及營銷、庫存、限購、商品等多個領域，每個領域都有不同程度的參與。隨著單個領域的業務知識不斷膨脹，以及行業需求的不斷迭代，推動了我們對系統和服務進行拆分。

在微服務實踐中，我們在統一的系統編排框架（比如：Spring Cloud Alibaba）下進行交互，領域之間的互聯通過服務接口進行。因此，在 AI 時代，未來的系統交付物可能不再是某個服務，而是某個 AI 智能體。AI 智能體與傳統接口的最大區別在于，它可能涉及多輪交互，而不僅僅是簡單的輸入輸出。因此，協議設計需要考慮多輪交互來完成任務。同時，像服務注冊與發現這類能力，仍然具有很高的參考價值。

2、AI 智能體架構的演進路徑

在 AI 智能體系統的發展中，也會有類似的架構演進路徑。最初，一個 AI 智能體可能會逐漸變得功能強大，但隨著領域知識的積累和復雜度的增加，會催生出更多的 AI 智能體來共同完成某個任務。這種從單體 AI 智能體到多 AI 智能體協作的演進是必然的。

3、多 AI 智能體協作模式

既然從單體 AI 智能體到多 AI 智能體協作是必然的演進規律，那么就有必要關注多 AI 智能體協作模式。以下是多 AI 智能體協作的核心內容：

• 任務分配機制

     a.集中式任務分配

     b.分布式任務協商

     c.基于角色的任務劃分

     d.動態任務重分配

• 協作方式

     a.平行協作：多 AI 智能體并行解決問題

     b.層級協作：管理 AI 智能體統籌下級 AI 智能體

     c.專家協作：不同領域 AI 智能體聯合解決問題

• 沖突解決

     a.基于優先級的決策

     b.投票機制

     c.仲裁 AI 智能體介入

     d.基于規則的沖突處理

當前市面上關于多 AI 智能體協作的討論，主要圍繞任務的解決展開，包括任務分發、任務處理和任務結果回收。這也是 A2A 協議引入“任務”這個概念的原因。

4、多 AI 智能體協作架構設計

下圖是對多 AI 智能體協作架構設計的一個簡化理解。從業務主 AI 智能體出發，需要基于任務中心恢復當前任務上下文，繼續本次任務的處理。接著通過 AI 智能體倉庫找到需要協同的 AI 智能體。我們通過多 AI 智能體交互協議與其他協作 AI 智能體交互，并在主 AI 智能體的業務流程中完成結果決策或子 AI 智能體的狀態透傳。

這套多 AI 智能體架構設計也呼應了前面提到的，AI 智能體可以是任意一個能夠完成一定范圍內人類任務的系統，只要它能在我們的業務流程中參與協同并解決一類問題。它可以是“一行 Hello World 代碼”，也可以是一個復雜的交互系統。同樣，基于“萬物皆 AI 智能體”的思路，MCP 工具服務也可以抽象成一個 AI 智能體，并且可以在這一層做一些額外的事情，比如：鑒權、參數校驗等。

三、MCP 工具調用標準化設計

AI 智能體在企業落地中，Tool 的抽象也比較關鍵，尤其通過 Tool 來擴展和增強大模型的能力邊界。現在，雖然 MCP 已經成為行業標準，但是當前 MCP 協議整體還比較薄，需要進一步工程化的架構設計能力來增強，特別是：公網/內網級的權限控制、用戶態的權限控制、工具快速接入能力、長工具列表優化等工程化，如下圖所示：

1. 公網/內網級的權限控制

單體服務向微服務轉變后，會抽象出許多只在公司內部供給能力的領域。因此，工具和 AI 智能體需要在公網和內網的維度進行隔離。當前的 MCP 服務是基于公網的協議，這意味著內網的 MCP 服務需要有統一的網關層來收口，并根據請求類型提供相應的工具集。

2. 用戶態的權限控制

當前的 MCP 協議沒有用戶態信息，這會導致一些只對特定用戶開放的工具無法進行用戶級的鑒權。因此，需要在用戶態信息層面補充 MCP。對于公司來說，用戶態信息可以是多類型的，比如：電商用戶、外賣用戶、公司員工等。有了這層信息后，業務工具可以在自己的服務內部進行鑒權行為。與傳統應用不同，面向大模型的服務最好在工具供給這一層就做好權限控制，用戶沒有權限的工具直接對大模型不可見，以避免請求后無法獲取數據的錯誤。

3. 工具快速接入能力

從零開發一個 MCP Server 對業務團隊來說是有一定工作量的。開發框架（比如：Spring AI Alibaba）支持零代碼一鍵轉 MCP Server，這就是一種工具快速接入的能力。除了開發框架外，還有很多業務團隊常用的接入訴求，比如：SLS 日志查詢的接入、表讀取的接入、服務的接入等。這些能力可以快速支撐起一個簡單的應用場景。對于公司的 MCP 中心，如果能夠支持這種工具接入的收斂，可以提高業務應用建設的效率。

4. 長工具列表優化

隨著業務系統的復雜性提升，一個 AI 智能體系統依賴的工具可能會顯著增加。對于業務側來說，需要讓工具更加內聚和簡單。對于 MCP 中心來說，可以通過一些更通用的工程化手段來處理，比如：在服務發現的末端，基于用戶的請求前置過濾一些與本次無關的工具，可以通過向量相似性或 LLM 來處理。這種二階段工具匹配的做法不僅可以減少長任務下的上下文長度，還能提高工具匹配的準確性。

四、AI 智能體編排框架設計

下圖很好地總結了 AI 智能體編排框架的分層設計。除了前面提到 AI 智能體協作構建模式和既定的工具調用標準（MCP），AI 智能體在企業落地過程中還需要引入問題理解、關鍵記憶召回、知識庫增強、評測等能力。

基于這些能力，AI 智能體平臺衍生出了以下關鍵模塊：知識庫的管理與干預、模型市場中心、記憶管理、鏈路追蹤、評測管理與微調能力。這些關鍵模塊每一個都可以深入剖析，改天再來詳細剖析。

本文轉載自???玄姐聊AGI??  作者：玄姐