AIAgent十問十答，降低認知摩擦

新興技術的出現，總會伴隨著術語洪流和流派之爭，帶來認知摩擦。

近期 OpenAI 釋出了《A Practical Guide to Building Agents》電子書[1]，隨後 Langchain 負責人駁斥了電子書中的一些觀點，在官方部落格釋出了《How to think about agent frameworks》[2]。在一次夜聊中，受到同事亦盞的啟發：新興技術領域往往會經歷事實標準的爭奪，是模型往上，還是編排框架向下，時間才能給出答案，但作為行業從業者，不妨從中舉一反三，甄別對自己有價值的資訊。

本文透過提取並梳理以上兩篇文章中的技術術語和價值資訊，並進行擴充套件，再以問答形式來呈現，希望透過這種方式，在加深使用者和開發者對 AI Agent 的瞭解方面，起到一些幫助。

一、什麼是 AI Agent？

Agent，中文翻譯為代理，顧名思義，代替使用者在代理許可權內去處理相關事宜。例如我聘請你作為代理律師，那麼你將以我的名義進行民事法律行為；再例如我今天休假了，設定同事作為我的代理，去處理審批流等任務。

而 AI Agent 是指在普通代理的基礎上，具備對任務的理解、環境的感知、資訊的獲取能力，並透過推理能力，自主進行決策和執行。AI Agent 就是 LLM + 客戶端（Chatbot、AI IDE 等）組成的產品，代替我們去自主的完成下達的任務，這裡的客戶端具備規劃、工具使用，甚至記憶的功能，目的都是為了更準確的執行任務。

二、AI Agent 與傳統軟體、傳統自動化軟體

有何區別？

傳統軟體往往依賴使用者的明確指令和操作要求，並按照後端系統預設的規則和流程執行，使用者須深度參與其中。而AIAgent 藉助 LLM 的感知、理解和推理能力，依據任務要求，提取外部知識庫（RAG）、聯網搜尋、藉助各種工具和網頁、其他軟體等進行互動，從而完成代理目標。

例如，在客服場景，Agent 能像經驗豐富的客服人員一樣，準確理解客戶的問題，迅速從起呀專有知識庫中檢索相關資訊，組織語言，給出恰當且專業的回覆，從而獨立處理客戶諮詢、投訴等各類問題。

例如，在辦公場景中，只需告知報告的主題和詳細要求，Agent 便能自主收集資料，提取有效資訊，梳理文章結構，根據使用者偏好或行業規範（例如正式、技術範兒、詼諧、科普等）完成報告的撰寫，並繪製表圖，進行排版。

傳統自動化軟體雖然也具備依據任務要求，自動對任務進行拆解，並完成目標。例如一些自動化的處理程式，像每天定點發送代金券，定點彙總當日的賬單。但 LLM 驅動的 Agent 可以處理那些傳統自動化方法難以應對的複雜任務。例如：

需要決策：根據程式碼上下文靈活理解意圖、自主定位錯誤、自主規劃修復步驟，如程式碼場景。傳統自動化軟體只能按規則跑流程，遇到異常或不確定性時無法自主推理和修正。
需要連續推理與多步計劃：自動完成有邏輯連貫性的複雜任務，例如撰寫長篇技術報告場景。傳統自動化軟體最多能模板化填充內容，無法根據目標動態規劃章節結構、鋪設推理鏈條、前後自洽。
需要跨系統自主整合資料：在多個ERP、CRM、財務系統之間自動生成綜合運營報告。傳統 RPA（機器人流程自動化）只能定向拉取資料，無法理解資料之間的隱含關聯或異常。
需要處理模糊、不完整輸入：使用者只給出一句含糊需求（如“幫我最佳化一下銷售流程”），系統理解後完成多步落地執行，傳統自動化軟體需要結構化清晰指令，無法理解模糊自然語言並自主澄清、細化、規劃。
需要自主學習和演化：持續最佳化任務，進行自我糾錯。傳統自動化工具需要人為設定最佳化規則，無法根據實際結果自我改進。

簡單來講，AI Agent 是自動化+智慧，這就解釋了 AI Agent 出現前，已經透過自動化能做的事，AI Agent 能帶來哪些變化。

三、Chatbot 為何都在向 AI Agent 演進

這個過程中，發生了什麼？

早期，OpenAI 等基模公司提供的都是"能說會道"的 Chatbot，但幾乎大家都開始往"真知實幹"的 AI Agent 演進。兩者的區別，我們先來彙總一張基礎表格。

從答疑到連線物理世界

LLM Chatbot 本質是機率驅動的文字生成器，透過海量語料的訓練掌握語言模式，就像一位博聞強記的圖書管理員，能複述書中的知識，卻因為缺乏對真實世界的理解和排程能力，難以自主決策和行動。

此後，OpenAI 釋出了 Function Call 和 Operator，是技術上向 AI Agent 的探索，而 Devin 和 Manus 則是第一次把 AI Agent 以產品的形態呈現給公眾，讓大家感受到 AI Agent 到底長什麼樣，能做些什麼。

OpenAI Pro已經提供深度研究的擴充套件能力。

QWen 即將推出 MCP 外掛。

國產Chatbot 開源客戶端四小龍，Cherry Studio、DeepChat、LobeChat 等，也都正在開發對 MCP 的支援。（Higress 提供了 MCP 市場，支援客戶端快速提供 MCP 能力，https://mcp.higress.ai/）

抽象來講，能力邊界是 Chatbot 與 AI Agent 的本質差異。Chatbot 向 AI Agent 演進，是技術驅動和市場需求的必然。

技術驅動因素

LLM 能力本身提升了

部分大語言模型已經可以做複雜推理、鏈式思考（Chain of Thought），不僅能回答，還能自己拆解問題。
單純的對話，已經無法充分利用大模型的推理和行動潛力。

多工具協作（Tool Use）的成熟

Agent 可以呼叫外掛、API、瀏覽器、程式碼直譯器等外部工具，不再只是單一語言生成。
Chatbot 如果只靠純語言，很難完成複雜任務（比如訂一張機票，需要多步操作）。

長期記憶和自主效能力發展

記憶機制讓 Agent 能記住使用者習慣、歷史任務，自動最佳化策略。
自主性支援 Agent 根據反饋調整自身行為，不需要使用者的每一步指令。

規劃和推理模組的成熟：早期 LLM 只能“回答”，而現在已經可以“先思考計劃”，再執行，更像人類的助理。

市場/需求驅動因素

使用者對效率和自動化的要求更高：企業、個人使用者都希望AI可以代替人去做瑣碎、複雜的連續任務，而不是每次提問每次回答。

商業模式擴充套件需求：僅靠 Chatbot 很難延續收費模式，而基於 Agent 的服務能拓展出 SaaS、B2B 整合、專屬 Agent 市場。

競爭環境變化：幾乎所有的一線基模廠商都在發展 AI Agent，以及還有 Manus、AI 程式設計都在做 AI Agent，預計今年 Q3 會出現很多垂直領域的 AI Agent。

四、AI Agent 由哪些元件構成？

AI Agent 的構成尚無統一的標準。

Anthropic 認為是大模型基於環境反饋去使用工具的一套程式，並區分了 Workflow（LLM 和工具透過預定義程式碼路徑編排）和 Agent（LLM 動態控制流程和工具使用），且多數生產中的 “智慧體系統” 是兩者的結合。因此他有以下三個核心要素：

模型（Model）：Agent的“大腦”，是基座、是引擎。
環境反饋（Context）：定義了模型執行任務時，要用到的資訊的總和，包括透過 Tool 拿到的資訊、使用者輸入的資訊等等。
工具（Tool）：Agent的“手腳”，透過所依賴的外部函式或 API（應用程式介面），與外部系統進行互動，獲取資訊並執行操作。技術實現方式有 OpenAI 的Function Calling、Computer Use，以及 Antronic 發起的 MCP 通訊協議。Google 發起的 A2A，則是 Agent 和 Agent 之間互動的通訊協議。

OpenAI 則是定義為模型、工具和指令，弱化了環境反饋（Context），將其下沉到模型層，使命是讓 Agent 產品化，例如 OpenAI 最新發布的 o3 已經內建了很多 tools 的能力。

指令（Instruction）：是指Agent的行為準則，有了指令，就能喚醒 Agent。高質量的指令技巧能夠減少歧義，提高智慧代理的執行效果，而高質量的提示詞工程能夠提升 Agent 對指令的理解準確度。前者是面向結果，後者是面向過程。如果您對 Instruction 理解依舊不清晰，請參考下方的程式碼樣例。

和Anthropic 定義的區別是，OpenAI 對外部應用程式的呼叫和呼叫效果的最佳化，即 if/else 的判斷，下沉到了模型層，由模型來內化，而非編排層來實現。OpenAI 越來越往上，模型定義一切，Anthropic 越來越往外，生態成就一切。

五、AI Agent 的工作原理？

AI Agent 的工作原理可以從感知、認知&推理&決策、行動、反饋和學習，4個關鍵過程來解釋。[3]

感知階段

這是喚醒 AI Agent 的第一步，感知內容分為。

來自物理世界的資訊：包括來自客戶端的任務，自然語言、程式碼、多模態等，以及透過感測器、攝像頭、麥克風硬體裝置的感測資訊。
來自虛擬環境的資訊：從資料庫、外部 API 介面等收集到的資訊。

認知&推理&決策階段

一旦 AI Agent 感知到環境資訊，依賴深度學習、強化學習帶來的訓練結果，對這些資訊進行識別與分析，以便作出明智的決策。這個過程中，會藉助 RAG、聯網搜尋、外部應用和系統呼叫。

這一階段是 AI Agent 行為的核心，直接決定了後續行動的有效性。但由於深度學習、強化學習的模型，依舊缺乏完全的可解釋性，是輸出結果不確定性的主要原因之一。

對於複雜任務，決策並不是一個結果，而是需要經歷和環境感知、認知和推理之間反覆互動的過程。因此還會受到提示詞工程的影響，例如我們在《Promt Engineering》分享的輸出長度、top-K 和 top-P 、Temprature 等引數，都會影響到最終的決策結果。

行動階段

最終，AI Agent 根據其決策採取行動。這一階段的目標是執行之前所做的決策，並進行輸出，例如一個模型、一份計劃書、甚至是一個物理界的執行動作（如自動駕駛中的車輛控制、機器人執行任務、下單等）。

反饋與學習

AI Agent 的能力不僅僅停留在執行階段，它還會不斷地根據執行結果進行反饋，並在每次任務後學習，例如 Monica 提供了記憶功能，透過學習，AI Agent 能夠逐漸最佳化自身的決策過程和行動策略。這一過程通常使用強化學習或其他線上學習技術來實現。

六、如何提升 AI Agent 的輸出效果？

從 LangChain 的調研來看，41% 的受訪者認為效能質量是構建可靠智慧體系統的最大限制。效能質量表現不佳常因模型不夠好或傳遞了錯誤（或不完整）的上下文，後者更加常見，包括不完整或簡短的系統訊息、模糊的使用者輸入、無法訪問正確的工具、工具描述不佳、未傳遞正確的上下文、工具響應格式不佳等。

因此提升 AI Agent 的輸出效果，關鍵也在於模型質量和環境反饋（Context），我們將環境反饋拆解成工具和指令來展開描述。

模型型別和質量

不同模型在任務複雜性、效能和成本方面具有不同的優勢和權衡。即便是同一個廠商，也會區分推理類模型、複雜任務類模型、多模態模型。我們應根據任務型別選擇更適合的模型。下圖是 Qwen 官網對主流模型的比對錶。

不同廠商相同型別的模型，輸出效果也不一樣，並且是動態變化的。就好像你的學生，每次拿第一的不會永遠是同一個人，不同科目的，也會有不同的排名。

人類競技有單場勝負，更有 N 連冠。但是人工智慧遍佈生活中的每一個場景，不是單次結果論英雄的競技場。因此在供應鏈視角，企業通常會採用多模型策略，透過 AI 閘道器在後端對接多個模型，一是為了提供更加豐富且對口的輸出結果，供使用者使用；二是滿足鑑權、安全防護、限流、可觀測、審計等方面的企業級需求。

工具

工具是指 AI Agent 使用外部應用程式或系統的 API 來擴充套件代理邊界的功能。例如 LLM Chatbot 在處理複雜的科學和數學問題時，“幻覺”會被放大。此時，AI Agent 整合Wolfram Alpha 的 Server，能夠準確地執行計算任務，避免因模型自身的侷限性而導致的錯誤。與大語言模型相比，Wolfram Alpha 基於廣泛的數學和科學知識庫，在處理複雜的數學公式、物理定律和科學概念時，能夠進行精確的計算、符號操作和公式推導。

目前主流的技術實現方式是 MCP 和 Function Call，Function Call 是最早提出的，MCP 是在此基礎之上做了協議的標準化。另外，OpenAI 今年1月推出 Operator 的形式（截圖，以視覺方式讀取瀏覽器的頁面資訊）來和外部頁面進行互動，透過視覺演算法模擬使用者操作來訪問網頁資訊。優勢是 token 消耗少，即便沒有 API 介面，也可以進行互動，且更容易適應不同的網站設計和佈局變化。但由於客戶端實現成本高，視覺演算法導致的出錯率不可控，服務端沒有參與感等原因，並未像 MCP 那樣形成廣泛共識。這算是兩個技術流派，MCP 和 Function Call 是工程派，Operator 是演算法派。

對大部分使用者而言，並不會太關注工具背後的技術實現方式，更關注的是工具的新增，別給原本就容易產生幻覺的大模型新增煩惱。其次是信任感，例如 DeepSeek 首次將深度思考的過程呈現給使用者時，這對 Chatbot 的體驗而言，獲得了大幅提升，隨後各家都相繼推出深度思考的功能。AI Agent 也是類似。MCP 和 Function Call 在使用者端呈現的是，Agent 呼叫 MCP tool 的過程，是程式碼語言，而Operator 呈現的是使用者語言，例如在 Manus 裡，會展示他在頁面瀏覽器的操作過程。後者因為更透明，給使用者帶來更多的信任感。[4]

另外，從供應端來看，工具雖然拓展了 AI Agent 的想象空間，但也帶了一些難題：

資訊對齊難：LLM 讀取 MCP Server 的資訊時，就像讓兩個哲學家用摩斯密碼聊黑格爾，除錯得當神配合，搞錯了那就是哲學災難。因此，構建 MCP Server，少不了和大模型聯調的過程。
協議開銷大：相比 Chatbot，AI Agent 的上下文記憶鏈條、任務步驟更多，即時任務秒變“慢動作回放”，單個任務可能耗時半小時。

這也催生了 MCP as a Service，例如MCP Marketplace，幫你找到乾淨好用、無須調優的 Server，透過閘道器的許可權和標籤能力來控制工具的使用範圍；當工具數量的增加，使用MCP Registry來解決工具在批次生效、除錯、歷史版本管理灰度、健康檢查的需求。以及 AutoMCP，讓模型透過反覆試驗來學習工具的使用方法，而不只是透過提示工程來最佳化工具的呼叫效果。

指令

指令分為兩類，一類是終端使用者提問時的提示詞技巧，一類是開發者側訓練大模型用的提示詞工程。但無論是哪一種，以下4個可以看作是改善輸出結果的原則。

利用現有文件：將現有的操作流程或政策檔案轉換為智慧代理可以理解的指令。

終端使用者：上傳報告、圖片，讓大模型提取其中內容進行二次加工。

開發者：只要是涉及醫療領域的任務，一律自動追加‘答案僅供參考，請諮詢專業醫生”。

分解任務：將複雜的任務分解為更小、更清晰的步驟，減少歧義。

終端使用者：根據提示詞，讓大模型輸出一篇報告，改為按章節、段落來輸出。

開發者：將分解使用者的任務進分解成計算機語言可以描述和執行的步驟，並針對多選答案和使用者完成核實後再執行下一步。

定義明確的行動：確保每個步驟都有具體的行動或輸出，避免模糊不清的指令。

終端使用者：將自己的任務儘可能拆解成計算機能理解的描述，而非即便自然語言也會出現理解偏差的任務或指令。

開發者：透過自然語言理解（NLU）將指令拆解成可以精確計算的步驟。

考慮邊緣情況：提前規劃如何處理使用者提供的不完整資訊或意外問題。出現問題時能自主糾錯，在遇到故障時還可暫停執行並將控制權交回使用者。

作為使用者，如果編寫指令有困難，可以將你覺得滿意的任務結果，例如一篇論文、一張圖片，餵給模型，由他來生成指令，這是設計指令的有效技巧。同時，指令要常用，內化成習慣，才能更高效的使用 Agent，這就像大部分企業管理者每天早上到公司都會先開啟資料系統瞭解過去1天的業務資料，這時候，“開啟資料系統”就是一則對人腦的指令。

指令也正在內化為大模型的能力，透過對話引導的方式來幫助使用者將自己的任務描述的更加清楚，因為很多情況下，我們對大模型的輸出效果不滿意，不是其不夠智慧，而是我們沒有將任務描述、分解的足夠明確。來看一個例子。

當我提問：AI 閘道器在 Agent 構建過程中，起到了哪些作用？顯然這個任務描述的不夠明確。於是，大模型給出了描述更加明確的方式，如下。

七、如何定義 Workflow、Agent、Agentic 的聯絡和區別？

從第7問開始，之所以會轉到 Workflow，是因為當下討論較多的“ Workflow 是否會被 LLM 顛覆”這個問題，是一個典型的 LLM 侵蝕工程化、產品化的案例，很多人在工程、產品上做了大量的原創設計和調優工作，某一天卻被 LLM 直接接管了。而 Workflow 更加特別，由於他的功能和定位，影響到的群體更大。

Workflow，即工作流，常見於應用編排框架中，是將任務依據特定業務邏輯有序排列的流程，以實現業務流程自動化處理。任務之間有清晰的依賴關係和流轉規則，每個任務都有明確的輸入、輸出和執行邏輯。定義他的是人，優點是確定性足夠強，不太會出錯，短板是不夠泛化。而LLM 是足夠泛化，但確定性不夠。

從語義上看，Agent 是一個名詞， Agentic 是一個形容詞，前者是以二元的方式來判斷某個東西是否是智慧體，後者則是更傾向於討論一個系統的智慧體程度。討論Agent的時候，很容易進入將是否使用了Workflow 來判斷這是否一個 AI Agent，尤其是在 Workflow 中了定義了大量的 if/else 邏輯，減弱了大語言模型控制力的時候。討論Agentic的時候，關注的是判斷流程是否進入下一步、判斷流程是否最終完成、判斷是否出現問題、判斷出現問題後是否把控制權限交給使用者等流程節點時，是由Workflow 來控制，還是有LLM來控制。LLM 控制越多，智慧程度越高，反之越低。

現階段，很多AI Agent都存在Workflow和LLM結合的情況。結合的方式包括：

LLM賦能Workflow：在工作流的各個任務環節中，嵌入大模型能力。例如在內容創作工作流裡，在素材收集階段，大模型可對海量的文字、影像等素材進行智慧篩選和分類，快速定位符合需求的資源；在創作環節，利用大模型生成初步內容框架或文案，像新媒體文章創作，大模型能依據主題生成文章大綱和部分段落內容，創作者在此基礎上最佳化完善，提升創作效率。
Workflow驅動LLM互動：以工作流的流程邏輯來引導大模型的互動過程。比如在智慧客服工作流中，當用戶諮詢問題時，工作流先對問題進行初步分類，然後根據分類結果呼叫大模型進行針對性回答。若問題涉及產品使用方法，工作流將問題精準傳遞給已在產品知識上微調的大模型，獲取準確答案後返回給使用者，確保回答的專業性和高效性。

八、Workflow 和 LLM 如何選擇？

首先澄清下，這個標題並不是引導二選一。如第7個 Q&A 所說，大多數實際生產中，AI Agent 的任務處理邏輯設計，是 Workflow 和 LLM 的組合。之所以業內有這樣的爭論，也許是因為 LLM 派信仰的是智慧本身，可以透過指令來提升智慧的確定性（參考第6個 Q&A 中的對話案例），Workflow 派信仰的是智慧無法覆蓋所有場景，必然有場景需要透過 Workflow 來精確決定資料的流動方式。

《How to think about agent frameworks》給出了一個採用 Workflow 和 LLM 的權衡方式。

圖中使用的是 workflow vs. agents，為區別 AI Agent，本文改為 workflow vs. LLM 來描述

低門檻：低門檻框架對初學者友好，容易上手。但自由度會下降，尤其是要去滿足複雜的業務需求的情況下。
高門檻：高門檻框架意味著學習曲線陡峭，需要具備大量知識或專業技能才能有效使用，但更適用於解決複雜的業務場景。
低上限：低上限框架指的是其在所能完成的任務上存在限制。
高上限：高上限框架為高階用例提供廣泛的功能和靈活性。

Workflow：上限高，門檻高，你必須自己編寫大量的智慧體邏輯。LLM：門檻低，上限也低，容易上手，但對於複雜用例來說不夠用。

以上來自 Langchain 的觀點，信仰 LLM 的人一定不認可“ LLM 是門檻低，上限也低，容易上手，但對於複雜用例來說不夠用”的論斷，隨著 LLM 更加智慧，並透過對話的方式幫助使用者來完善指令，並藉助畫布等產品互動方式，降低指令的最佳化難度。完善的內容包括任務的描述完整度和準確度，任務的拆解，每一步驟和使用者進行確認，從而減少甚至避免單個步驟90%準確率，10個步驟準確率陡降為90%的10次方的情況。

以這種方式來提升 LLM 在複雜用例的表現。本質上，這是兩種技術/產品流派的碰撞。

九、什麼是 Single-Agent System和 Multi-Agent System？

Single – Agent System（單智慧體系統）：指在一個系統中僅存在單個智慧體，該智慧體獨立完成任務，其決策和行動僅基於自身的感知、知識與能力，不與其他智慧體協作或互動。Multi – Agent System（多智慧體系統）：由多個智慧體組成，這些智慧體相互協作、互動，共同完成複雜任務。各智慧體具有自主性，可獨立做出決策，但透過資訊共享、協作等方式實現共同目標。

預計今年 Q3 會上線很多垂直領域的單智慧體系統，例如專注於做表格的，專注於做報告的，專注於做旅行計劃的，並逐步呈現網際網路 APP 的繁榮景象。這些垂直領域的單智慧體系統，將成為未來多智慧體系統的協作基礎。

對於多智慧體系統，理論上可以為經理模式和去中心化模式。經理模式下，存在一箇中心 “經理” 代理，它以呼叫工具的方式協調多個專業代理。“經理” 代理負責將任務分配給合適的專業代理，並整合最終結果，提供統一的使用者體驗，適用於希望由一個代理掌控工作流程並與使用者互動的場景。去中心化模式中，多個代理地位平等，可相互移交任務執行權。當一個代理呼叫移交函式，新代理立即開始執行並接收最新對話狀態。

十、為什麼需要多智慧體系統？

拋開技術因素，會有兩個截然不同的觀點。

正方：模型越強大，所有 AI Agent 都有可能被“模型即產品”所替代，不需要多智慧體系統。

反方：模型再智慧，也無法主動甄別所有環境感知（Context），每個細分領域的 Agent，調研類 Agent、Coding Agent、表格 Agent，都需要花大量的時間，少則半年多則一年，去設計環境感知（Context），減少模型幻覺，Agent 會像網際網路 APP 那樣百家齊放，而不是一家獨大。

這個需要時間來證明。單隻從技術視角看，多智慧體系統是必要的。

複雜性管理

隨著業務規模和複雜度的提升，單體架構會變得龐大且難以維護，牽一髮而動全身，就像大型工廠擴充套件業務後，內部管理混亂，效率降低。而微服務將業務拆分成多個獨立的小服務，每個服務專注於單一功能，降低了系統複雜度。

對於多智慧體系統，將複雜任務分解給多個智慧體。每個智慧體負責特定任務，各自獨立執行和決策。以及維護迭代，既利於對每個智慧體進行獨立除錯和迭代，也利於任務的分解，提高了系統的可管理性。例如撰寫一篇報告，將任務分別佈置給梳理整體報告邏輯的智慧體、收集和歸類資訊的智慧體、繪製圖表的智慧體，每個智慧體均有自己的特長。這種設計也是延續了人類社會的分工，一份報告需要有策劃、編輯、拍版、設計師等通力協作完成。

靈活性和可擴充套件性

單體架構在擴充套件新功能或修改現有功能時，往往需要對整個系統進行調整，成本高且風險大，如同在大型工廠裡改變生產流程，需要停產並大規模改造。微服務架構則允許獨立擴充套件和修改單個服務，靈活性和擴充套件性強。

對於多智慧體系統，新增或修改一個智慧體的功能，不會對其他智慧體造成太大影響，還可以根據任務需求靈活增加或減少智慧體，提高系統應對變化的能力。使用者甚至可以對智慧體進行排列組合，例如若發現繪製圖表的智慧體不夠優秀，可以使用另一款多模態智慧體。

資源成本最佳化和並行處理

微服務架構中每個服務可以根據自身需求分配資源，實現資源的最佳化利用，並且不同服務可以並行處理任務，提高整體效率。

如果所有任務都指派給同一個效能最強的智慧體，資源消耗大。採用多智慧體系統，每個智慧體系統因為只擅長各自領域的任務，引數更小，能顯著降低資源消耗。另外，每個智慧體可以根據自身任務需求分配計算資源、時間等，而且多個智慧體可以同時處理不同任務，實現並行處理。

容錯性和可靠性

單體架構一旦出現故障，整個系統可能會癱瘓；微服務架構中某個服務出現問題，其他服務可以繼續執行，透過服務的冗餘和容錯機制提高系統的可靠性。

對於多智慧體系統，某個智慧體出現故障，其他智慧體可以繼續工作，透過智慧體之間的協作和備份機制，確保系統整體的穩定性和可靠性。

[1]https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

[2]https://blog.langchain.dev/how-to-think-about-agent-frameworks/

[3]https://www.allaboutai.com/ai-agents/anatomy/