AI 智能體架構設計的9大核心技術包括：AI 智能體、Agentic AI、WorkFlow、RAG、Fine-tuning、Function Calling、MCP、A2A、AG-UI 等，下文詳細剖析之。

1、AI 智能體架構的9大核心技術

AI 智能體架構設計核心技術一：AI 智能體

AI 智能體是一種具備自主意識的軟件，它能夠感知環境、進行邏輯推理和決策，并實施相應動作。

它可以被比作一位高效的個人助手，不僅能夠執行命令，更重要的是能夠理解任務的上下文、規劃執行方案，并在遇到挑戰時靈活地改變策略。

AI 智能體的核心在于其如何接收指令、執行任務并做出決策。以下是其關鍵組成部分：

1. Prompt（提示詞）Prompt 是指導大語言模型（LLM）如何行動的指令，它定義了 LLM 可以使用的“工具”。Prompt 的輸出是一個 JSON 對象，用于描述工作流程中的下一步操作，比如：“工具調用”或“函數調用”。
2. Switch 語句Switch 語句根據 LLM 返回的 JSON 內容決定后續操作。這是整個流程中的一個重要環節，用于解析 LLM 的輸出并執行相應的動作。
3. 累積的上下文累積的上下文用于記錄已執行的操作步驟及其運行結果。這一部分是 AI 智能體決策的重要依據，幫助其跟蹤任務的進展。
4. For 循環For 循環是整個流程的驅動機制。它循環執行以下操作，直至 LLM 返回終止信號（比如：標記為“Terminal”的工具調用或自然語言響應）：將 switch 語句的執行結果加入上下文窗口，并讓 LLM 決定下一步動作。

這種設計使得 AI 智能體能夠高效地執行任務，同時具備靈活性和適應性。

AI 智能體架構設計核心技術二：Agentic AI

Agentic AI 開啟了一種全新的架構范式。與傳統的單體 AI 智能體架構不同，Agentic AI 系統架構由多個 AI 智能體組成，這些 AI 智能體能夠相互協作，具備動態任務分解、持久記憶和高級任務編排等能力。這種架構使得系統能夠處理更復雜的工作流程，并實現更高層次的協調。

如果將 AI 智能體比作獨奏者，那么 Agentic AI 就像是一個交響樂團。在Agentic AI 系統中，每個 AI 智能體都有其獨特的角色和能力，它們可以相互協作、共享信息，并根據任務需求動態調整策略。這種協作模式讓系統能夠應對那些超出單個 AI 智能體能力范圍的復雜任務。

Agentic AI 的應用場景極為廣泛且復雜。在醫療領域，它可以協調多個專業 AI系統進行綜合診斷；在科學研究中，它可以組織多個研究助手進行協作調研；在機器人技術中，它可以指揮多個機器人協同工作。這些應用場景都要求系統具備高度的協調能力和動態適應性。

AI 智能體架構設計核心技術三：工作流（WorkFlow）

工作流 WorkFlow 其實很簡單，就是把一項大任務拆成很多個小任務，然后按順序一步一步完成，最后達成目標。

想象一下工廠里的流水線：一個大任務被分成很多個小步驟，每個步驟都有專人負責。比如，第一個人做完自己的部分，就把東西交給第二個人，第二個人接著做，就這樣一直傳下去，直到最后完成整個任務。這樣一來，每個人都知道自己該做什么，效率和質量都能提高。

在一些特別需要準確性的場景里，如果讓 AI 智能體自己決定任務怎么一步步做，可能會出錯，甚至產生一些不靠譜的結果（我們叫它“幻覺”）。這時候，工作流就能派上用場了。我們可以提前把任務的步驟安排好，讓 AI 智能體按照這個順序來執行，這樣就能減少出錯的幾率。

舉個例子，假設我們有一個處理訂單的 AI 智能體。當員工把訂單信息錄進去后，工作流就會自動開始檢查庫存。如果庫存夠，AI 智能體就直接安排發貨；如果庫存不夠，它就先創建一個補貨任務，通知采購部門趕緊補貨，同時還會給客戶發個消息，告訴他們大概什么時候能發貨。

不過，工作流也不是萬能的。如果設計得不好，比如步驟太多或者順序亂了，任務處理起來就會很慢。所以，我們需要專業的人員（比如產品經理）來幫忙優化，把工作流梳理得更合理。

AI 智能體架構設計核心技術四：RAG（Retrieval-Augmented Generation）

RAG（檢索增強生成）系統一直是企業里使用 AI 智能體最有用的技術之一。

RAG 最簡單的架構設計實現方式如下所示：

預處理階段：

1. 把整個知識庫的文本資料分割成一個個小塊，每個小塊都是一段可以查詢的文本。這些資料可能來自不同的地方，比如：公司內部的文檔、PDF 報告等。
2. 用一個特殊的模型（嵌入模型）把這些文本塊轉換成一種特殊的代碼（向量嵌入）。
3. 把這些代碼存到一個特殊的數據庫（向量數據庫）里，同時保存每個向量對應的原始文本和指向向量的鏈接。

檢索階段：

1. 在向量數據庫里，用同一個嵌入模型處理知識庫中的文檔內容和用戶的問題，確保查詢和知識庫中的信息能夠準確匹配。
2. 在向量數據庫的索引上運行查詢，選擇要檢索的向量數量，這決定了你將用多少上下文信息來回答查詢。
3. 向量數據庫會執行一個搜索，找到最相似的向量，然后把這些向量映射回它們對應的原始文本塊。
4. 把問題和檢索到的上下文文本塊一起通過一個提示詞傳遞給大語言模型，告訴模型只用這些上下文來回答這個問題。這并不意味著不需要設計好的提示詞--你還需要確保模型返回的答案符合預期，比如：如果檢索到的上下文中沒有相關信息，就不要編造答案。

AI 智能體架構設計核心技術五：微調（Fine-tuning）

通用大模型已經很強大了，落地 AI 智能體應用時，我們還需要繼續微調它，有以下5點需要微調的原因：

第一、大模型和人腦在處理信息時采用的策略有很大的不同。

第二、缺乏專有數據，比如：企業內部的私有數據。

第三、缺乏最新數據，比如：Qwen-3 的訓練數據截止到2024年10月。

第四、預訓練成本高，比如：DeepSeek R1 預訓練成本為 500萬美金。

第五、提升數據安全性，比如：企業私有數據是不能傳遞給第三方大模型的，基于開源大模型的微調才能滿足業務的需求。

微調（Fine-tuning）分為全參數量微調和局部參數量微調，或者叫 PEFT 高效參數微調，PEFT 微調步驟如下：

第一步、數據工程，選擇整理本次微調所需要的知識即任務數據集，以（Q，A）的問答對整理好，微調的數據量最好在 10K~100K 量級。

第二步、加載預訓練大模型（比如：Qwen-3-32B）：選擇一個與所需任務相關的預訓練大模型，并加載其權重。

第三步、對大模型進行微調：將第一步任務數據集作為輸入，以最小化大模型在此數據集上的損失函數。在這個過程中，通常需要在訓練集和驗證集上進行多次迭代，以避免過擬合問題。

基于以上步驟，詳細總結如下：

AI 智能體架構設計核心技術六：函數調用（Function Calling）

Function Calling 是由 OpenAI 等公司推動的一種技術，它允許大語言模型（LLM）通過自然語言指令與外部工具和服務進行交互，從而將自然語言轉換為具體的 API 調用。這一技術解決了大語言模型在訓練完成后知識更新停滯的問題，使大模型能夠獲取實時信息，比如：當前的天氣、股市收盤點數等。

第一、工作原理

Function Calling 的工作原理可以通過以下4個步驟來理解：

1.識別需求：大模型識別出用戶的問題需要調用外部 API 來獲取實時信息。比如：用戶詢問“今天北京的天氣如何？”大模型會識別出這是一個關于實時天氣的問題。

2.選擇函數：大模型從可用的函數庫中選擇合適的函數。在這個例子中，大模型會選擇 get_current_weather 函數。

3.準備參數：大模型準備調用函數所需的參數。例如：

{
  "location": "北京",
  "unit": "celsius"
}

3.調用函數：AI 應用使用這些參數調用實際的天氣 API，獲取北京的實時天氣數據。

4.整合回答：大模型將獲取的數據整合成一個完整的回答，比如：“根據最新數據，北京今天的天氣晴朗，當前溫度23°C，濕度45%，微風。今天的最高溫度預計為26°C，最低溫度為18°C?！?/p>

第二、對開發者的好處

對于開發者來說，使用 LLM 的 Function Calling 入門相對容易。開發者只需按照 API 的要求定義函數規格（通常是 JSON 格式），并將其隨 Prompt 請求發送給大模型。大模型會根據需要調用這些函數，整個邏輯相當直觀。因此，對于單一大模型、少量功能的簡單應用，Function Calling 的實現非常直接，幾乎可以“一鍵”將大模型輸出對接到代碼邏輯中。

第三、局限性

然而，Function Calling 也有一些局限性：

缺乏跨大模型的一致性：每個 LLM 供應商的接口格式略有差異，這使得開發者在支持多個大模型時需要為不同的 API 做適配，或者使用額外的框架來處理這些差異。

平臺依賴性：Function Calling 通常依賴于特定的平臺或框架，這限制了其在不同環境中的通用性。

擴展性有限：雖然 Function Calling 能夠解決特定問題，但在面對更復雜的任務時，其擴展性可能會受到限制。開發者可能需要為每個新功能編寫新的函數，并確保這些函數與模型的交互邏輯兼容。

第四、總結

Function Calling 是一種強大的工具，它為大語言模型提供了與外部工具和服務交互的能力，從而解決了大模型知識更新停滯的問題。然而，它的局限性在于缺乏跨模型的一致性和平臺依賴性。盡管如此，Function Calling 仍然是一個重要的技術，尤其是在需要快速實現特定功能時。未來，隨著技術的不斷發展，我們期待看到更多能夠克服這些局限性的解決方案。

AI 智能體架構設計核心技術七：MCP（Model Context Protocol）

MCP（Model Context Protocol）是由 Anthropic 公司提出的一種協議，旨在解決不同大語言模型（LLM）與不同外部工具集成的標準化問題。通過MCP，開發者能夠以一種統一的方式將各種數據源和工具連接到 AI 大模型，從而提升大模型的實用性和靈活性。

1目前，MCP 生態已經得到了廣泛的支持，包括 Anthropic 的 Claude 系列、OpenAI 的 GPT 系列、Meta 的 Llama 系列、DeepSeek、阿里的通義系列以及 Anysphere 的 Cursor 等主流模型均已接入 MCP 生態。

第一、MCP 的架構設計

MCP 采用了客戶端-服務器架構，主要包括以下幾個核心組件：

1.MCP 主機（Hosts）

角色：這是需要訪問數據的程序，例如Claude Desktop、各種IDE或AI工具。

功能：它們是MCP生態系統的入口點，負責向用戶提供AI功能，并作為用戶與AI模型之間的橋梁。

2.MCP 客戶端（Clients）

角色：這些是協議客戶端，負責維持與 MCP 服務器的1:1連接。

功能：它們處理通信細節，確保主機和服務器之間的數據傳輸順暢，從而實現高效的數據交互。

3.MCP 服務器（Servers）

角色：這些是輕量級程序，每個服務器都通過標準化的 Model Context Protocol 暴露特定功能。

功能：服務器是 MCP 的核心，它們連接 AI 大模型與實際數據源，使模型能夠訪問和操作數據。

4.數據源

本地數據源：包括您計算機上的文件、數據庫和服務，MCP 服務器可以安全地訪問這些資源。

遠程服務：通過互聯網可用的外部系統（比如：通過 API），MCP 服務器可以連接這些系統，從而擴展模型的能力。

第二、MCP 的優勢

統一性：MCP 提供了一個統一的協議標準，使得不同 AI 大模型能夠以一致的方式連接到各種數據源和工具，從而避免了平臺依賴性問題。

安全性：通過 MCP，數據的傳輸和訪問過程更加安全，敏感數據可以保留在本地，無需全部上傳到云端。

靈活性：MCP 支持多種數據源和工具的連接，無論是本地資源還是遠程服務，都可以輕松集成到AI 應用中。

生態豐富：MCP 生態已經得到了廣泛的支持，開發者可以利用現有的MCP服務器和工具，快速構建和部署AI應用。

第三、總結

MCP 通過其客戶端-服務器架構和標準化的協議，為 AI 大模型與外部工具和數據源的集成提供了一個高效、安全且靈活的解決方案。它不僅解決了不同大模型與工具之間的兼容性問題，還為開發者提供了一個豐富的生態系統，使得AI應用的開發和部署變得更加簡單和高效。

AI 智能體架構設計核心技術八：A2A（Agent2Agent）

第一、為什么會有 A2A？

現在越來越清楚，未來的 Agentic AI 將是多 AI 智能體的。而且，這些 AI 智能體會在彼此之間遠程協作，每個 AI 智體都可能使用不同的 AI 智能體框架（比如：Spring AI Alibaba、LangGraph、AutoGen、CrewAI、Agent Development Kit 等）來實現。

這里面有3個固有的問題：

    1.不同框架實現的 AI 智能體系統之間，不支持系統狀態的轉移和交換。

    2.遠程 AI 智能體之間也無法轉移系統狀態。

    3.離線的 AI 智能體不共享工具、上下文和內存（包括系統狀態）。

第二、A2A 解決方案

A2A 是一個開放協議，它為 AI 智能體之間提供了一種標準方式，無論底層開發框架或供應商如何，都可以進行協作。

根據谷歌的官方文檔： A2A 協議促進了“客戶端”和“遠程” AI 智能體之間的通信。

簡單來說，“客戶端” AI 智能體創建任務并與“遠程” AI 智能體溝通，期望執行某些工作或返回數據。

第三、A2A 架構設計

    1.能力發現：所有實現 A2A 的 AI 智能體都通過“Agent Card”公開其能力目錄。這有助于其他 AI 智能體發現給定 AI 智能體實現的潛在有用功能。

    2.任務管理：通信協議，時代短期和長期任務變得更容易。它幫助通信中的 AI 智能體保持同步，直到請求的任務完成并返回答案。這很重要，因為有些 AI 智能體可能需要很長時間來執行工作，而且目前沒有統一標準如何等待這種情況發生。

    3.協作：AI 智能體可以相互發送消息以傳達上下文、回復、工件或用戶指令。

    4.用戶體驗協商：這是一個很有趣的功能。它允許協商數據返回的格式，以符合用戶界面的期望（比如：圖像、視頻、文本等）。

通過 A2A 公開的 AI 智能體的發現是一個重要話題。谷歌建議使用統一的位置來存儲組織的“Agent Card”。

比如：

https://<DOMAIN>/<agreed-path>/agent.json

這并不意外，因為谷歌將處于最佳位置，能夠索引全球所有可用的 AI Agent，可能創建一個類似于當前搜索引擎索引的全球 AI Agent 目錄。

我喜歡 A2A 強調無需重新發明輪子，并且建立在現有標準之上：

    1.該協議建立在現有、流行的標準之上，包括：HTTP、SSE、JSON-RPC，這意味著它更容易與企業日常使用的現有 IT 堆棧集成。

    2.默認安全 - A2A 旨在支持企業級身份驗證和授權，與 OpenAPI 的身份驗證方案相當。

AI 智能體架構設計核心技術九：AG-UI（Agent User Interaction Protocol）

隨著 AI 智能體在企業中應用越來越廣，AI 智能體在落地過程中，MCP 解決了 AI 智能體到 Tools 之間的通信標準，A2A 解決了 AI 智能體到 AI 智能體之間的通信標準。但是仍缺少一塊：用戶到 AI 智能體的通信協議。

AG-UI 協議橫空出世，專為解決前端應用與 AI 智能體的通信交互而設計。

AG-UI 讓你能夠輕松地在網頁、APP、應用程序或嵌入式設備中集成 AI 助手、AI 客服和智能問答 UI，避免了為每個應用程序重復開發基礎功能的麻煩，也省去了處理交互邏輯的煩惱。

AG-UI 完善了 AI 協議棧，專注于構建 AI 智能體與用戶前端之間的橋梁。它采用事件驅動的設計，定義了16種標準事件，并支持 SSE、WebSocket 和 Webhook 等傳輸方式，與 LangGraph、CrewAI 等框架兼容。

它就像是為你的前端安裝了一個 AI “大腦”，無需綁定到特定的模型或框架，一套協議就能滿足所有的交互需求。

第一、為什么需要 AG-UI？

每個 AI 智能體后端都有自己的工具調用、ReAct 樣式規劃、狀態差異和輸出格式機制。

如果你使用 LangGraph，前端將實現自定義的 WebSocket 邏輯、雜亂的 JSON 格式和特定于 LangGraph 的 UI 適配器。

但要遷移到 CrewAI/Dify 等，一切都必須進行調整，這樣工作量大大增加。

第二、AG-UI 架構設計

AG-UI 使用一個輕量級、事件驅動的協議來連接 AI Agents 和前端應用程序，架構設計如圖所示：

• Front-end：通過 AG-UI 進行通信的應用（聊天或任何啟用 AI 應用） ；
• AI Agent A：前端可以直接連接的 AI Agent，無需通過代理；
• Secure Proxy：一個中介代理，安全地將前端的請求路由到多個 AI Agents；
• AI Agent B 和 C：由代理服務管理的 AI Agents。

第三、AG-UI 工作機制

AG-UI 的核心工作機制非常簡潔而優雅，如下圖所示：

• 客戶端通過 POST 請求啟動一次 AI 智能體會話；
• 隨后建立一個 HTTP 流（可通過 SSE/WebSocket 等傳輸協議）用于實時監聽事件；
• 每條事件都有類型和元信息（Metadata）；
• AI 智能體持續將事件流式推送給 UI；
• UI 端根據每條事件實時更新界面；
• 與此同時，UI 也可反向發送事件、上下文信息，供 AI 智能體使用。
  

AG-UI 不再是單向的信息流，而是一種真正的雙向“心跳式”交互機制。AG-UI 就像 REST 是客戶端到服務器請求的標準一樣，AG-UI 將實時 AI 智能體更新流式傳輸回 UI 的標準。從技術上講，AG-UI 使用服務器發送事件（SSE）將結構化 JSON 事件流式傳輸到前端。

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