AI 智能體架構(gòu)設(shè)計(jì)的9大核心技術(shù)包括：AI 智能體、Agentic AI、WorkFlow、RAG、Fine-tuning、Function Calling、MCP、A2A、AG-UI 等，下文詳細(xì)剖析之。

一、AI 智能體架構(gòu)的9大核心技術(shù)

1、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)一：AI 智能體

AI 智能體是一種具備自主意識的軟件，它能夠感知環(huán)境、進(jìn)行邏輯推理和決策，并實(shí)施相應(yīng)動作。

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

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

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

這種設(shè)計(jì)使得 AI 智能體能夠高效地執(zhí)行任務(wù)，同時(shí)具備靈活性和適應(yīng)性。

2、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)二：Agentic AI

Agentic AI 開啟了一種全新的架構(gòu)范式。與傳統(tǒng)的單體 AI 智能體架構(gòu)不同，Agentic AI 系統(tǒng)架構(gòu)由多個(gè) AI 智能體組成，這些 AI 智能體能夠相互協(xié)作，具備動態(tài)任務(wù)分解、持久記憶和高級任務(wù)編排等能力。這種架構(gòu)使得系統(tǒng)能夠處理更復(fù)雜的工作流程，并實(shí)現(xiàn)更高層次的協(xié)調(diào)。

如果將 AI 智能體比作獨(dú)奏者，那么 Agentic AI 就像是一個(gè)交響樂團(tuán)。在Agentic AI 系統(tǒng)中，每個(gè) AI 智能體都有其獨(dú)特的角色和能力，它們可以相互協(xié)作、共享信息，并根據(jù)任務(wù)需求動態(tài)調(diào)整策略。這種協(xié)作模式讓系統(tǒng)能夠應(yīng)對那些超出單個(gè) AI 智能體能力范圍的復(fù)雜任務(wù)。

Agentic AI 的應(yīng)用場景極為廣泛且復(fù)雜。在醫(yī)療領(lǐng)域，它可以協(xié)調(diào)多個(gè)專業(yè) AI系統(tǒng)進(jìn)行綜合診斷；在科學(xué)研究中，它可以組織多個(gè)研究助手進(jìn)行協(xié)作調(diào)研；在機(jī)器人技術(shù)中，它可以指揮多個(gè)機(jī)器人協(xié)同工作。這些應(yīng)用場景都要求系統(tǒng)具備高度的協(xié)調(diào)能力和動態(tài)適應(yīng)性。

3、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)三：工作流（WorkFlow）

工作流 WorkFlow 其實(shí)很簡單，就是把一項(xiàng)大任務(wù)拆成很多個(gè)小任務(wù)，然后按順序一步一步完成，最后達(dá)成目標(biāo)。

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

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

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

不過，工作流也不是萬能的。如果設(shè)計(jì)得不好，比如步驟太多或者順序亂了，任務(wù)處理起來就會很慢。所以，我們需要專業(yè)的人員（比如產(chǎn)品經(jīng)理）來幫忙優(yōu)化，把工作流梳理得更合理。

4、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)四：RAG（Retrieval-Augmented Generation）

RAG（檢索增強(qiáng)生成）系統(tǒng)一直是企業(yè)里使用 AI 智能體最有用的技術(shù)之一。

RAG 最簡單的架構(gòu)設(shè)計(jì)實(shí)現(xiàn)方式如下所示：

預(yù)處理階段：

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

檢索階段：

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

5、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)五：微調(diào)（Fine-tuning）

通用大模型已經(jīng)很強(qiáng)大了，落地 AI 智能體應(yīng)用時(shí)，我們還需要繼續(xù)微調(diào)它，有以下5點(diǎn)需要微調(diào)的原因：

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

第二、缺乏專有數(shù)據(jù)，比如：企業(yè)內(nèi)部的私有數(shù)據(jù)。

第三、缺乏最新數(shù)據(jù)，比如：Qwen-3 的訓(xùn)練數(shù)據(jù)截止到2024年10月。

第四、預(yù)訓(xùn)練成本高，比如：DeepSeek R1 預(yù)訓(xùn)練成本為 500萬美金。

第五、提升數(shù)據(jù)安全性，比如：企業(yè)私有數(shù)據(jù)是不能傳遞給第三方大模型的，基于開源大模型的微調(diào)才能滿足業(yè)務(wù)的需求。

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

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

第二步、加載預(yù)訓(xùn)練大模型（比如：Qwen-3-32B）：選擇一個(gè)與所需任務(wù)相關(guān)的預(yù)訓(xùn)練大模型，并加載其權(quán)重。

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

基于以上步驟，詳細(xì)總結(jié)如下：

6、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)六：函數(shù)調(diào)用（Function Calling）

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

第一、工作原理

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

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

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

3.準(zhǔn)備參數(shù)：大模型準(zhǔn)備調(diào)用函數(shù)所需的參數(shù)。例如：

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

3.調(diào)用函數(shù)：AI 應(yīng)用使用這些參數(shù)調(diào)用實(shí)際的天氣 API，獲取北京的實(shí)時(shí)天氣數(shù)據(jù)。

4.整合回答：大模型將獲取的數(shù)據(jù)整合成一個(gè)完整的回答，比如：“根據(jù)最新數(shù)據(jù)，北京今天的天氣晴朗，當(dāng)前溫度23°C，濕度45%，微風(fēng)。今天的最高溫度預(yù)計(jì)為26°C，最低溫度為18°C。”

第二、對開發(fā)者的好處

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

第三、局限性

然而，F(xiàn)unction Calling 也有一些局限性：

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

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

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

第四、總結(jié)

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

7、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)七：MCP（Model Context Protocol）

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

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

第一、MCP 的架構(gòu)設(shè)計(jì)

MCP 采用了客戶端-服務(wù)器架構(gòu)，主要包括以下幾個(gè)核心組件：

1.MCP 主機(jī)（Hosts）

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

功能：它們是MCP生態(tài)系統(tǒng)的入口點(diǎn)，負(fù)責(zé)向用戶提供AI功能，并作為用戶與AI模型之間的橋梁。

2.MCP 客戶端（Clients）

角色：這些是協(xié)議客戶端，負(fù)責(zé)維持與 MCP 服務(wù)器的1:1連接。

功能：它們處理通信細(xì)節(jié)，確保主機(jī)和服務(wù)器之間的數(shù)據(jù)傳輸順暢，從而實(shí)現(xiàn)高效的數(shù)據(jù)交互。

3.MCP 服務(wù)器（Servers）

角色：這些是輕量級程序，每個(gè)服務(wù)器都通過標(biāo)準(zhǔn)化的 Model Context Protocol 暴露特定功能。

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

4.數(shù)據(jù)源

本地?cái)?shù)據(jù)源：包括您計(jì)算機(jī)上的文件、數(shù)據(jù)庫和服務(wù)，MCP 服務(wù)器可以安全地訪問這些資源。

遠(yuǎn)程服務(wù)：通過互聯(lián)網(wǎng)可用的外部系統(tǒng)（比如：通過 API），MCP 服務(wù)器可以連接這些系統(tǒng)，從而擴(kuò)展模型的能力。

第二、MCP 的優(yōu)勢

統(tǒng)一性：MCP 提供了一個(gè)統(tǒng)一的協(xié)議標(biāo)準(zhǔn)，使得不同 AI 大模型能夠以一致的方式連接到各種數(shù)據(jù)源和工具，從而避免了平臺依賴性問題。

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

靈活性：MCP 支持多種數(shù)據(jù)源和工具的連接，無論是本地資源還是遠(yuǎn)程服務(wù)，都可以輕松集成到AI 應(yīng)用中。

生態(tài)豐富：MCP 生態(tài)已經(jīng)得到了廣泛的支持，開發(fā)者可以利用現(xiàn)有的MCP服務(wù)器和工具，快速構(gòu)建和部署AI應(yīng)用。

第三、總結(jié)

MCP 通過其客戶端-服務(wù)器架構(gòu)和標(biāo)準(zhǔn)化的協(xié)議，為 AI 大模型與外部工具和數(shù)據(jù)源的集成提供了一個(gè)高效、安全且靈活的解決方案。它不僅解決了不同大模型與工具之間的兼容性問題，還為開發(fā)者提供了一個(gè)豐富的生態(tài)系統(tǒng)，使得AI應(yīng)用的開發(fā)和部署變得更加簡單和高效。

8、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)八：A2A（Agent2Agent）

第一、為什么會有 A2A？

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

這里面有3個(gè)固有的問題：

    1.不同框架實(shí)現(xiàn)的 AI 智能體系統(tǒng)之間，不支持系統(tǒng)狀態(tài)的轉(zhuǎn)移和交換。

    2.遠(yuǎn)程 AI 智能體之間也無法轉(zhuǎn)移系統(tǒng)狀態(tài)。

    3.離線的 AI 智能體不共享工具、上下文和內(nèi)存（包括系統(tǒng)狀態(tài)）。

第二、A2A 解決方案

A2A 是一個(gè)開放協(xié)議，它為 AI 智能體之間提供了一種標(biāo)準(zhǔn)方式，無論底層開發(fā)框架或供應(yīng)商如何，都可以進(jìn)行協(xié)作。

根據(jù)谷歌的官方文檔： A2A 協(xié)議促進(jìn)了“客戶端”和“遠(yuǎn)程” AI 智能體之間的通信。

簡單來說，“客戶端” AI 智能體創(chuàng)建任務(wù)并與“遠(yuǎn)程” AI 智能體溝通，期望執(zhí)行某些工作或返回?cái)?shù)據(jù)。

第三、A2A 架構(gòu)設(shè)計(jì)

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

    2.任務(wù)管理：通信協(xié)議，時(shí)代短期和長期任務(wù)變得更容易。它幫助通信中的 AI 智能體保持同步，直到請求的任務(wù)完成并返回答案。這很重要，因?yàn)橛行?AI 智能體可能需要很長時(shí)間來執(zhí)行工作，而且目前沒有統(tǒng)一標(biāo)準(zhǔn)如何等待這種情況發(fā)生。

    3.協(xié)作：AI 智能體可以相互發(fā)送消息以傳達(dá)上下文、回復(fù)、工件或用戶指令。

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

通過 A2A 公開的 AI 智能體的發(fā)現(xiàn)是一個(gè)重要話題。谷歌建議使用統(tǒng)一的位置來存儲組織的“Agent Card”。

比如：

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

這并不意外，因?yàn)楣雀鑼⑻幱谧罴盐恢茫軌蛩饕蛩锌捎玫?nbsp;AI Agent，可能創(chuàng)建一個(gè)類似于當(dāng)前搜索引擎索引的全球 AI Agent 目錄。

我喜歡 A2A 強(qiáng)調(diào)無需重新發(fā)明輪子，并且建立在現(xiàn)有標(biāo)準(zhǔn)之上：

    1.該協(xié)議建立在現(xiàn)有、流行的標(biāo)準(zhǔn)之上，包括：HTTP、SSE、JSON-RPC，這意味著它更容易與企業(yè)日常使用的現(xiàn)有 IT 堆棧集成。

    2.默認(rèn)安全 - A2A 旨在支持企業(yè)級身份驗(yàn)證和授權(quán)，與 OpenAPI 的身份驗(yàn)證方案相當(dāng)。

9、AI 智能體架構(gòu)設(shè)計(jì)核心技術(shù)九：AG-UI（Agent User Interaction Protocol）

隨著 AI 智能體在企業(yè)中應(yīng)用越來越廣，AI 智能體在落地過程中，MCP 解決了 AI 智能體到 Tools 之間的通信標(biāo)準(zhǔn)，A2A 解決了 AI 智能體到 AI 智能體之間的通信標(biāo)準(zhǔn)。但是仍缺少一塊：用戶到 AI 智能體的通信協(xié)議。

.

AG-UI 協(xié)議橫空出世，專為解決前端應(yīng)用與 AI 智能體的通信交互而設(shè)計(jì)。

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

AG-UI 完善了 AI 協(xié)議棧，專注于構(gòu)建 AI 智能體與用戶前端之間的橋梁。它采用事件驅(qū)動的設(shè)計(jì)，定義了16種標(biāo)準(zhǔn)事件，并支持 SSE、WebSocket 和 Webhook 等傳輸方式，與 LangGraph、CrewAI 等框架兼容。

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

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

每個(gè) AI 智能體后端都有自己的工具調(diào)用、ReAct 樣式規(guī)劃、狀態(tài)差異和輸出格式機(jī)制。

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

但要遷移到 CrewAI/Dify 等，一切都必須進(jìn)行調(diào)整，這樣工作量大大增加。

第二、AG-UI 架構(gòu)設(shè)計(jì)

AG-UI 使用一個(gè)輕量級、事件驅(qū)動的協(xié)議來連接 AI Agents 和前端應(yīng)用程序，架構(gòu)設(shè)計(jì)如圖所示：

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

第三、AG-UI 工作機(jī)制

AG-UI 的核心工作機(jī)制非常簡潔而優(yōu)雅，如下圖所示：

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

AG-UI 不再是單向的信息流，而是一種真正的雙向“心跳式”交互機(jī)制。AG-UI 就像 REST 是客戶端到服務(wù)器請求的標(biāo)準(zhǔn)一樣，AG-UI 將實(shí)時(shí) AI 智能體更新流式傳輸回 UI 的標(biāo)準(zhǔn)。從技術(shù)上講，AG-UI 使用服務(wù)器發(fā)送事件（SSE）將結(jié)構(gòu)化 JSON 事件流式傳輸?shù)角岸恕?/p>

本文轉(zhuǎn)載自???玄姐聊AGI??  作者：玄姐