大概從 2024 年年底開(kāi)始我發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象身邊做后端、做前端的同事甚至做運(yùn)維的朋友簡(jiǎn)歷上開(kāi)始不約而同地出現(xiàn) RAG、Agent、MCP 這些詞。但真坐下來(lái)聊項(xiàng)目能把這幾個(gè)概念串成一條完整架構(gòu)鏈路的人并不多。很多人是“用過(guò) LangChain 做了個(gè) RAG 問(wèn)答”或者“調(diào)過(guò) OpenAI function calling”但再往深問(wèn)一步——RAG 的召回質(zhì)量怎么評(píng)估Agent 的工具調(diào)用失敗怎么恢復(fù)MCP 和 A2A 到底解決的是哪個(gè)層面的問(wèn)題——基本就卡住了。這篇文章我想直接用一線(xiàn)架構(gòu)設(shè)計(jì)的視角把 RAG、Agent、函數(shù)調(diào)用、MCP、A2A 這五件事拆開(kāi)揉碎講清楚。它們不是五個(gè)并列的技術(shù)名詞而是一條從“數(shù)據(jù)接入”到“智能體自治”再到“多系統(tǒng)協(xié)作”的完整遞進(jìn)鏈路。文章會(huì)涉及每個(gè)技術(shù)的核心原理、為什么需要它、架構(gòu)上放在哪個(gè)位置、實(shí)際落地要注意哪些坑以及完整架構(gòu)下怎么組合設(shè)計(jì)。適合正在做 AI 應(yīng)用開(kāi)發(fā)、或者準(zhǔn)備從“調(diào) API”向“設(shè)計(jì) AI 系統(tǒng)”進(jìn)階的工程師。我會(huì)盡量用講項(xiàng)目的方式來(lái)講而不是羅列概念。1. 內(nèi)容整體設(shè)計(jì)與思路拆解為什么這五項(xiàng)技術(shù)必須放在一起看我在團(tuán)隊(duì)里做技術(shù)評(píng)審時(shí)最常遇到的一種情況是產(chǎn)品經(jīng)理提了一個(gè)需求說(shuō)“我們要做一個(gè) AI 助手能回答內(nèi)部知識(shí)庫(kù)的問(wèn)題還能幫用戶(hù)操作 CRM 系統(tǒng)最好還能聯(lián)動(dòng)其他業(yè)務(wù)系統(tǒng)”。這個(gè)需求聽(tīng)起來(lái)很“AI”但架構(gòu)師一聽(tīng)就知道這句話(huà)里面其實(shí)埋了四層完全不同的技術(shù)問(wèn)題知識(shí)庫(kù)回答靠 RAG理解目標(biāo)并拆解動(dòng)作靠 Agent操作 CRM 靠函數(shù)調(diào)用跨系統(tǒng)協(xié)作靠 MCP 和 A2A。如果只盯著其中一個(gè)點(diǎn)做最后交付的系統(tǒng)一定是瘸腿的。1.1 為什么 RAG 是起點(diǎn)大模型天生記不住你的業(yè)務(wù)先明確一個(gè)最底層的事實(shí)通用大模型的知識(shí)截止日期是固定的參數(shù)里裝的是互聯(lián)網(wǎng)級(jí)別的公共知識(shí)。你問(wèn)它“l(fā)inux 怎么查端口占用”這種開(kāi)放性問(wèn)題它答得不錯(cuò)但你問(wèn)“咱們公司上個(gè)季度的退費(fèi)率為什么漲了”它就完全懵了。任何人都不能去微調(diào)大模型來(lái)記公司文檔成本不允許更新頻率也不允許。RAGRetrieval-Augmented Generation檢索增強(qiáng)生成解決的就是這個(gè)矛盾不修改模型的參數(shù)而是在回答前先從外部知識(shí)庫(kù)里檢索相關(guān)內(nèi)容把檢索結(jié)果塞進(jìn)上下文讓模型“開(kāi)卷考試”。RAG 架構(gòu)上有三個(gè)核心環(huán)節(jié)離線(xiàn)索引構(gòu)建、在線(xiàn)檢索、生成融合。離線(xiàn)階段要把文檔切塊、向量化、寫(xiě)入向量數(shù)據(jù)庫(kù)在線(xiàn)階段把用戶(hù)問(wèn)題做同樣的向量化然后做相似度檢索最后把檢索到的文本塊和問(wèn)題一起喂給大模型。這個(gè)流程看起來(lái)簡(jiǎn)單但實(shí)際工程里每一步都有大量細(xì)節(jié)后面我會(huì)展開(kāi)講。簡(jiǎn)單說(shuō)RAG 的價(jià)值在于用最低成本讓大模型獲得了“閱讀你私有數(shù)據(jù)”的能力這是幾乎所有企業(yè)級(jí) AI 應(yīng)用的第一站。1.2 Agent 的定位從“回答問(wèn)題”到“完成任務(wù)”RAG 做出來(lái)的系統(tǒng)本質(zhì)上還是一個(gè)“被動(dòng)問(wèn)答”系統(tǒng)用戶(hù)問(wèn)一句系統(tǒng)答一句。但真實(shí)業(yè)務(wù)需要的往往是“主動(dòng)完成任務(wù)”。用戶(hù)說(shuō)“幫我查一下上周所有未處理的工單并且給每個(gè)工單生成一段催辦文案”這種需求有明確的目標(biāo)但實(shí)現(xiàn)路徑是模糊的。Agent智能體就是從這里切入的。Agent 的核心不是某個(gè)模型而是一套執(zhí)行循環(huán)理解目標(biāo) → 拆解步驟 → 調(diào)用工具獲取結(jié)果 → 觀察返回 → 調(diào)整下一步 → 直到任務(wù)完成。在工程實(shí)現(xiàn)上這個(gè)循環(huán)的現(xiàn)代載體就是函數(shù)調(diào)用function calling——模型通過(guò)結(jié)構(gòu)化的方式輸出“我要調(diào)用哪個(gè)函數(shù)、參數(shù)是什么”程序負(fù)責(zé)真實(shí)執(zhí)行。Agent 是大腦函數(shù)調(diào)用是手而 MCP 是把“手”標(biāo)準(zhǔn)化接入的協(xié)議層。這四者存在嚴(yán)格的分工依賴(lài)關(guān)系。1.3 MCP 和 A2A把工具和智能體變成可插拔的生態(tài)在沒(méi)有 MCP 之前Agent 要接一個(gè)外部系統(tǒng)比如數(shù)據(jù)庫(kù)、CRM、藍(lán)湖設(shè)計(jì)稿就要為這個(gè)系統(tǒng)單獨(dú)寫(xiě)一套工具注冊(cè)邏輯每家的接口格式都不同每次接入都是重復(fù)勞動(dòng)。MCPModel Context Protocol就是干這個(gè)的——它統(tǒng)一了“模型上下文”的獲取方式。類(lèi)比來(lái)說(shuō)MCP 之于 AI Agent相當(dāng)于 USB-C 接口之于充電器之前每個(gè)設(shè)備一個(gè)充電口現(xiàn)在一個(gè)口能接所有設(shè)備。MCP 把工具、數(shù)據(jù)源、工作流封裝成標(biāo)準(zhǔn)化的 serverAgent 通過(guò)統(tǒng)一的 client 協(xié)議去訪問(wèn)。A2AAgent-to-Agent則是更上層的協(xié)議。它解決的不是“單個(gè) Agent 怎么調(diào)用工具”而是“多個(gè) Agent 之間怎么互相發(fā)現(xiàn)、通信、協(xié)作”。注意A2A 是 Google 在 2025 年 4 月開(kāi)源的定位和 MCP 完全不同。MCP 是應(yīng)用 ? 工具A2A 是智能體 ? 智能體。一個(gè)完整的 AI 系統(tǒng)架構(gòu)里RAG 提供數(shù)據(jù)底座一套函數(shù)調(diào)用機(jī)制讓 Agent 擁有行動(dòng)能力MCP 讓這些工具能夠“即插即用”A2A 讓不同的 Agent 可以協(xié)作解決更大范圍的復(fù)雜任務(wù)——這就是這幾個(gè)名詞的內(nèi)在邏輯線(xiàn)。2. 從 RAG 到 Agentic RAG知識(shí)檢索的工程化演進(jìn)很多人把 RAG 理解成“向量搜索 大模型”組合然后照著教程把 PDF 一切、embedding 一算、扔進(jìn)向量庫(kù)就完事了。但真實(shí)業(yè)務(wù)里這種“裸 RAG”的準(zhǔn)確率往往讓人一言難盡。用戶(hù)問(wèn)的明明是“我們?nèi)ツ觌p十一的優(yōu)惠券過(guò)期還能退嗎”你檢索出來(lái)的可能是幾段不相關(guān)的內(nèi)容。問(wèn)題出在哪可能在于文本切塊太粗暴、檢索召回不精準(zhǔn)、rerank重排序缺位甚至問(wèn)題本身需要先做意圖改寫(xiě)。RAG 工程化遠(yuǎn)不止“向量化三個(gè)字”那么簡(jiǎn)單。2.1 基礎(chǔ) RAG 鏈路切塊、向量化、檢索、重排讓我先把一條標(biāo)準(zhǔn) RAG 鏈路完整地走一遍這里面的參數(shù)選擇直接影響最終效果。首先文檔進(jìn)來(lái)后要解析成純文本。這一步看起來(lái)簡(jiǎn)單但 PDF 里的表格、掃描件、復(fù)雜排版如果解析工具不過(guò)關(guān)后面的所有步驟都會(huì)在錯(cuò)誤的數(shù)據(jù)上運(yùn)行屬于“垃圾進(jìn)垃圾出”。接下來(lái)是切塊chunking。切塊策略是 RAG 質(zhì)量的第一大坑。切得太小單塊語(yǔ)義不完整檢索到的片段可能只有半句話(huà)切得太大混入太多無(wú)關(guān)信息向量的語(yǔ)義向量被稀釋且占用大模型上下文空間。我常用的做法是分層切塊先按文檔的標(biāo)題層級(jí)把文檔切成長(zhǎng)度可控、語(yǔ)義完整的片段chunk再給每個(gè) chunk 關(guān)聯(lián)所屬的標(biāo)題、章節(jié)作為元數(shù)據(jù)。這樣檢索時(shí)既可以精準(zhǔn)定位到某一小節(jié)也可以結(jié)合父文檔上下文做擴(kuò)展。切完后進(jìn)入向量化環(huán)節(jié)。先說(shuō)明一點(diǎn)Embedding 模型直接決定召回質(zhì)量的天花板。中文場(chǎng)景下用戶(hù)搜索內(nèi)容對(duì)應(yīng)中文業(yè)務(wù)需要優(yōu)先選用在中文語(yǔ)料上表現(xiàn)好的 embedding 模型比如bge-large-zh、m3e-large等開(kāi)源方案。它們的向量維度通常為 1024 左右足夠區(qū)分中文語(yǔ)義差異。向量化后的數(shù)據(jù)存入向量數(shù)據(jù)庫(kù)。生產(chǎn)環(huán)境我實(shí)測(cè)下來(lái)比較穩(wěn)的組合是如果數(shù)據(jù)量在百萬(wàn)級(jí)以?xún)?nèi)直接用 PostgreSQL 的 pgvector 擴(kuò)展最省事一套數(shù)據(jù)庫(kù)搞定業(yè)務(wù)數(shù)據(jù)和向量數(shù)據(jù)不用額外維護(hù)一套專(zhuān)用向量庫(kù)數(shù)據(jù)量上了千萬(wàn)級(jí)再考慮 Milvus 或者 Qdrant 這種專(zhuān)用引擎。選型邏輯其實(shí)很樸素先用最少的組件驗(yàn)證效果別一上來(lái)就上重型武器。檢索完成后有個(gè)極其重要、但很多人直接忽略的環(huán)節(jié)——重排序Rerank。向量檢索召回 Top 20 后里面真正相關(guān)的可能只有 3-4 條其余都是“語(yǔ)義相近但并非答案所需”的干擾項(xiàng)。Rerank 模型比如bge-reranker會(huì)把檢回的候選重新計(jì)算相關(guān)性給出更精準(zhǔn)的排序。我用 Rerank 前后的對(duì)比做過(guò)量化測(cè)試在沒(méi)有 Rerank 的情況下Top 5 準(zhǔn)確率約為 65%加一層 Rerank 后能到 85% 以上。這 20 個(gè)百分點(diǎn)的差距恰恰是演示 Demo 和上線(xiàn)產(chǎn)品的分界線(xiàn)。2.2 檢索質(zhì)量的三個(gè)關(guān)鍵指標(biāo)與常用評(píng)測(cè)方法做 RAG 項(xiàng)目老板一定會(huì)問(wèn)一個(gè)問(wèn)題“效果到底怎么樣怎么衡量”如果你回答“感覺(jué)還行”那基本就會(huì)被定性為“不可靠”。RAG 的衡量要從檢索和生成兩個(gè)層面拆開(kāi)看。檢索層最核心的指標(biāo)有三個(gè)召回率RecallK前 K 個(gè)結(jié)果中相關(guān)文檔占全部相關(guān)文檔的比例、命中率Hit Rate前 K 個(gè)結(jié)果中是否至少有一個(gè)相關(guān)文檔、MRRMean Reciprocal Rank衡量第一個(gè)相關(guān)結(jié)果出現(xiàn)的位置位置越靠前越好如果第一個(gè)相關(guān)結(jié)果排第 2則分?jǐn)?shù)為 1/2 0.5。生成層的指標(biāo)則有兩個(gè)維度忠實(shí)度Faithfulness生成的回答是否嚴(yán)格基于檢索到的文本有沒(méi)有憑空捏造和答案相關(guān)度Answer Relevance回答是否真正解決了用戶(hù)的問(wèn)題。具體評(píng)測(cè)怎么做我的建議是兩條腿走路一條是標(biāo)注集評(píng)測(cè)找領(lǐng)域?qū)＜覍?duì) 100-200 個(gè)典型問(wèn)題做人工標(biāo)注標(biāo)注該問(wèn)題對(duì)應(yīng)哪幾個(gè)標(biāo)準(zhǔn)答案段落然后跑批量測(cè)試算出指標(biāo)分另一條是大模型自動(dòng)評(píng)測(cè)通過(guò)設(shè)計(jì)一個(gè)“評(píng)委”LLM給出檢索文本和生成回答讓它判斷回答是否有依據(jù)、是否跑題。不過(guò)我要提醒一點(diǎn)自動(dòng)評(píng)測(cè)的“評(píng)委”本身也可能誤判所以核心指標(biāo)還是得靠人工標(biāo)注把關(guān)。2.3 Agentic RAG讓檢索成為 Agent 決策的一部分普通 RAG 的問(wèn)題是“一次檢索定終身”用戶(hù)問(wèn)題進(jìn)來(lái)直接檢索直接生成。但真實(shí)問(wèn)題往往沒(méi)有這么直白。用戶(hù)的提問(wèn)可能是“我需要一篇包含市場(chǎng)分析和競(jìng)品對(duì)比的報(bào)告”直接檢索“市場(chǎng)分析”和“競(jìng)品對(duì)比”可能搜不到好的結(jié)果因?yàn)橄蛄肯嗨贫炔⒉焕斫狻鞍?A 和 B 的綜合性報(bào)告”這種復(fù)合意圖。Agentic RAG 的解法是把檢索過(guò)程交給 Agent 來(lái)動(dòng)態(tài)決策。具體做法有兩種典型模式。第一種是“路由模式”系統(tǒng)先分析用戶(hù)問(wèn)題判斷是屬于技術(shù)類(lèi)、財(cái)務(wù)類(lèi)還是產(chǎn)品類(lèi)然后路由到不同的知識(shí)庫(kù)分別檢索。本質(zhì)上是給 RAG 加了一個(gè)意圖分類(lèi)器。第二種是“多輪迭代模式”Agent 先把大問(wèn)題拆分比如先搜市場(chǎng)報(bào)告如果發(fā)現(xiàn)缺少今年第一季度數(shù)據(jù)就再發(fā)起一次補(bǔ)充檢索直到信息足夠才開(kāi)始生成答案。無(wú)論是哪種模式底層都要調(diào)用檢索工具而上層則是 Agent 的調(diào)度邏輯。當(dāng)一個(gè) RAG 系統(tǒng)開(kāi)始具備這種主動(dòng)決策能力的時(shí)候它就已經(jīng)跨到了 Agent 的領(lǐng)域。3. Agent 的函數(shù)調(diào)用機(jī)制大模型與外部世界握手的關(guān)鍵如果要用一句話(huà)說(shuō)明函數(shù)調(diào)用Function Calling解決什么問(wèn)題我傾向說(shuō)它讓大模型從“只能說(shuō)話(huà)”變得“能動(dòng)手”。沒(méi)有函數(shù)調(diào)用之前你讓模型查天氣它只能告訴你“我無(wú)法實(shí)時(shí)查詢(xún)天氣”有了函數(shù)調(diào)用模型會(huì)返回一個(gè)結(jié)構(gòu)化的“指令”比如get_weather(location: 北京, date: 2025-06-20)由你的代碼去真實(shí)調(diào)用天氣 API再把結(jié)果返回給模型生成最終回答。理解這個(gè)閉環(huán)的每一步是做 Agent 開(kāi)發(fā)的起碼要求。3.1 function calling 工作原理結(jié)構(gòu)化輸出的約束藝術(shù)函數(shù)調(diào)用的底層原理本質(zhì)上是通過(guò)“結(jié)構(gòu)化輸出約束”讓大模型在當(dāng)前對(duì)話(huà)上下文中選擇一個(gè)函數(shù)并填寫(xiě)參數(shù)。它不是模型在你代碼里執(zhí)行函數(shù)而是大模型生成一段 JSON函數(shù)真正的運(yùn)行是發(fā)生在你的程序環(huán)境中。所以工程上需要嚴(yán)格區(qū)分大模型的職責(zé)是決策和生成 JSON程序的職責(zé)是執(zhí)行和捕獲結(jié)果然后執(zhí)行結(jié)果再回到模型手里做總結(jié)或繼續(xù)決策。從 API 層面看OpenAI 的tools參數(shù)、Anthropic 的tools參數(shù)、以及 Google Gemini 的function_declarations雖然格式不同但底層邏輯都一致向模型聲明“你現(xiàn)在可調(diào)用的工具有哪些每個(gè)工具參數(shù)的結(jié)構(gòu)是什么”。模型在推理時(shí)會(huì)參考這個(gè)工具列表來(lái)決定是否調(diào)用工具。以 OpenAI 為例函數(shù)的 schema 遵循 JSON Schema 規(guī)范例如一個(gè)“查詢(xún)用戶(hù)訂單”的工具聲明如下{ type: function, function: { name: query_user_orders, description: 根據(jù)用戶(hù)ID查詢(xún)歷史訂單列表, parameters: { type: object, properties: { user_id: { type: string, description: 用戶(hù)唯一標(biāo)識(shí) }, status: { type: string, enum: [pending, completed, cancelled], description: 訂單狀態(tài)篩選條件 } }, required: [user_id] } } }這里有幾個(gè)容易被忽略的細(xì)節(jié)。第一description字段的作用比很多人想象中大得多。模型是靠文本描述來(lái)決定什么時(shí)候該調(diào)用哪個(gè)函數(shù)的寫(xiě)得太籠統(tǒng)它就會(huì)亂來(lái)。第二枚舉值要約束好否則模型會(huì)隨便填參數(shù)。第三——這是我在生產(chǎn)環(huán)境踩過(guò)最深的一個(gè)坑——不要依賴(lài)模型自己去理解函數(shù)內(nèi)部邏輯。函數(shù)描述說(shuō)的是“查詢(xún)訂單”你就必須保證這個(gè)函數(shù)的實(shí)現(xiàn)真能返回訂單結(jié)果別讓用戶(hù)去猜。這個(gè)哲學(xué)和 API 設(shè)計(jì)的原理是相通的工具邊界要明確實(shí)現(xiàn)要可靠。3.2 多工具并行調(diào)用與復(fù)雜任務(wù)編排實(shí)際業(yè)務(wù)中Agent 很少只調(diào)用一個(gè)函數(shù)就完事。用戶(hù)問(wèn)“我上個(gè)月的訂單總額是多少另外把未發(fā)貨的一起列出來(lái)”理論上需要同時(shí)調(diào)query_user_orders和calculate_total兩個(gè)函數(shù)。OpenAI 把這種能力叫做 parallel function calling在同一次回復(fù)中返回多個(gè) tool_calls每個(gè)調(diào)用都包含函數(shù)名和參數(shù)你只需要把它們?nèi)繄?zhí)行一遍然后把結(jié)果統(tǒng)一返回。這個(gè)功能極大減少了多輪調(diào)用帶來(lái)的延遲累積。多工具并行的工程處理上有個(gè)注意點(diǎn)當(dāng)模型返回多個(gè) tool_calls 時(shí)每個(gè)調(diào)用的關(guān)聯(lián)上下文如何維護(hù)。我習(xí)慣用tool_call_id來(lái)關(guān)聯(lián)把每個(gè)執(zhí)行結(jié)果都精確對(duì)應(yīng)到具體調(diào)用上避免多路結(jié)果張冠李戴。另外真實(shí) Agent 任務(wù)往往需要多輪“模型思考 → 工具調(diào)用 → 結(jié)果返回”的循環(huán)這個(gè)循環(huán)的終止條件必須明確要么 Agent 主動(dòng)聲明任務(wù)完成要么超過(guò)最大迭代輪數(shù)比如設(shè)置為 8-10 輪否則模型有時(shí)會(huì)陷入工具調(diào)用的尷尬怪圈。def run_agent(user_message): messages [{role: user, content: user_message}] for _ in range(10): response client.chat.completions.create( modelgpt-4o, messagesmessages, toolsorder_tools ) msg response.choices[0].message if not msg.tool_calls: return msg.content messages.append(msg) for tool_call in msg.tool_calls: result execute_tool(tool_call.function.name, tool_call.function.arguments) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) })這段代碼看起來(lái)很直觀但放到生產(chǎn)環(huán)境你要補(bǔ)的細(xì)節(jié)非常多。比如execute_tool執(zhí)行函數(shù)本身可能超時(shí)、可能報(bào)錯(cuò)返回給模型的錯(cuò)誤信息要足夠結(jié)構(gòu)化讓模型知道自己錯(cuò)在哪里、下一步怎么調(diào)整。另一個(gè)容易踩的坑是上下文長(zhǎng)度——每輪工具調(diào)用的輸入輸出都會(huì) append 到 messages 里幾輪下來(lái) token 就逼近上下文窗口了。需要在每輪迭代后做上下文摘要或裁剪。不要等到爆了再處理。4. MCP、A2A 與 AI 應(yīng)用架構(gòu)的最終形態(tài)如果只把函數(shù)調(diào)用當(dāng)成一個(gè) API 特性來(lái)用你開(kāi)發(fā)每個(gè) Agent 時(shí)都會(huì)陷入“手動(dòng)給每個(gè)系統(tǒng)寫(xiě)工具注冊(cè)邏輯”的麻煩中。隨著工具數(shù)量增多這個(gè)矛盾會(huì)更加突出每次接入一個(gè)業(yè)務(wù)系統(tǒng)都要寫(xiě)一套新的工具封裝。MCP 和 A2A 就是為了解決這些問(wèn)題而出現(xiàn)的基礎(chǔ)設(shè)施層協(xié)議。它們讓 AI 應(yīng)用具備真正的“可生長(zhǎng)性”而不是寫(xiě)死一個(gè) Demo。4.1 MCP 架構(gòu)拆解為什么說(shuō)它是 AI 應(yīng)用的“USB-C”我在給團(tuán)隊(duì)科普 MCPModel Context Protocol時(shí)通常用一個(gè)比喻它的角色相當(dāng)于 AI 世界里的 USB-C 接口標(biāo)準(zhǔn)。USB-C 之所以成功不是因?yàn)槟骋粋€(gè)廠商推動(dòng)了它而是因?yàn)樗压╇?、?shù)據(jù)傳輸、視頻輸出統(tǒng)一到一個(gè)物理接口。MCP 的邏輯也完全一致提供一套標(biāo)準(zhǔn)化協(xié)議讓 AI 應(yīng)用能以同一種方式接入不同的數(shù)據(jù)源、工具、工作流。不管是接數(shù)據(jù)庫(kù)、接設(shè)計(jì)稿藍(lán)湖 MCP、Figma MCP、接內(nèi)部工單系統(tǒng)或者是接搜索服務(wù)只要對(duì)方實(shí)現(xiàn)了 MCP Server你的 Agent 就能直接對(duì)話(huà)不再需要為每一種數(shù)據(jù)源寫(xiě)一套專(zhuān)用適配。關(guān)于 MCP 的規(guī)范和角色MCP 采用的是客戶(hù)端—服務(wù)器架構(gòu)跟 C/S 軟件開(kāi)發(fā)里的概念類(lèi)似。主程序如 Claude Desktop、Cursor、自研 Agent是 MCP Client通過(guò) JSON-RPC 2.0 格式發(fā)請(qǐng)求外部能力提供方是 MCP Server。會(huì)話(huà)建立時(shí)會(huì)先做一次“能力協(xié)商”客戶(hù)端聲明自己支持哪些能力比如提示詞、資源、工具服務(wù)端回復(fù)自己實(shí)現(xiàn)了哪些能力。而 MCP 三要素中工具Tools服務(wù)于“執(zhí)行動(dòng)作”資源Resources等同于“提供上下文給模型讀取”提示詞Prompts則提供“可復(fù)用的提示詞模板”。我實(shí)際做一個(gè) MCP Server 通常只需要 30-40 行代碼。比如 Express 里寫(xiě)一個(gè)最簡(jiǎn)單的 server核心代碼邏輯如下import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new McpServer({ name: order-query-server, version: 1.0.0 }); server.tool( query_order, 根據(jù)訂單號(hào)查詢(xún)訂單狀態(tài), { orderId: z.string().describe(訂單號(hào)) }, async ({ orderId }) { const data await db.orders.findUnique({ where: { orderId } }); return { content: [{ type: text, text: JSON.stringify(data) }] }; } ); const transport new StdioServerTransport(); await server.connect(transport);默認(rèn)走 stdio 傳輸主進(jìn)程直接以子進(jìn)程方式拉起 MCP Server兩者通過(guò)標(biāo)準(zhǔn)輸入輸出做 JSON-RPC 通信。實(shí)際往遠(yuǎn)程部署時(shí)則改用 SSEServer-Sent Events或 Streamable HTTP 作為傳輸層——這種情況適用于 MCP Server 部署在遠(yuǎn)程機(jī)器上Client 通過(guò)網(wǎng)絡(luò)訪問(wèn)。比如你需要把設(shè)計(jì)稿 MCP 部署在云端本地的 Codex 要連接它就應(yīng)該走 HTTP 而非 stdio。4.2 MCP 與函數(shù)調(diào)用的邊界什么時(shí)候用哪個(gè)這是個(gè)高頻問(wèn)題。我見(jiàn)過(guò)不少開(kāi)發(fā)者說(shuō)“我已經(jīng)有 function calling 了為什么還要 MCP不就是多一層封裝嗎”理解邊界關(guān)鍵看你的工具調(diào)用的來(lái)源是誰(shuí)。MCP 解決的是“工具發(fā)現(xiàn)與接入的標(biāo)準(zhǔn)化”而函數(shù)調(diào)用解決的是“模型如何輸出調(diào)用意圖”。你可以完全沒(méi)有 MCP靠手寫(xiě)一堆 function 走 function calling 完成一個(gè) Agent 應(yīng)用——這對(duì)單一、固定的系統(tǒng)沒(méi)問(wèn)題。但如果你開(kāi)發(fā)的 Agent 要?jiǎng)討B(tài)接入多個(gè)外部系統(tǒng)或者工具集合需要頻繁擴(kuò)展MCP 的價(jià)值就體現(xiàn)出來(lái)了新增一種工具的接入不用改 Agent 核心邏輯只需要在配置里新增一個(gè) MCP Server 地址。再往深一層MCP 的真正好處在于“語(yǔ)義級(jí)解耦”讓工具提供方和 AI 應(yīng)用方可以獨(dú)立演進(jìn)。比如你的公司有一個(gè)文檔查詢(xún)系統(tǒng)傳統(tǒng)開(kāi)發(fā)下的接入方式顯然就是問(wèn)對(duì)方“API 文檔給我我來(lái)封裝”而在 MCP 架構(gòu)下對(duì)方團(tuán)隊(duì)直接起一個(gè) MCP Server把文檔檢索能力封裝好所有 Agent 通過(guò)這個(gè) server 獲取信息。工具提供方一次開(kāi)發(fā)、多方復(fù)用。所以我的建議是原型和單系統(tǒng)內(nèi)部工具用 function calling 最直接面向多系統(tǒng)、多團(tuán)隊(duì)協(xié)作的平臺(tái)型架構(gòu)盡早引入 MCP。4.3 A2A 協(xié)議智能體之間的“普通話(huà)”如果說(shuō) MCP 是“應(yīng)用 ? 工具”的協(xié)議那么 A2AAgent2Agent解決的是“智能體 ? 智能體”的協(xié)作協(xié)議由 Google 在 2025 年推出并貢獻(xiàn)給 Linux Foundation。它的核心價(jià)值是讓不同團(tuán)隊(duì)、不同廠商開(kāi)發(fā)的 Agent 能發(fā)現(xiàn)彼此、協(xié)商能力邊界、互發(fā)任務(wù)、共享最終結(jié)果。本質(zhì)上是一個(gè)去中心化的智能體協(xié)作網(wǎng)絡(luò)的通信層。A2A 的協(xié)議流程具備清晰的探索—協(xié)商—執(zhí)行流程。協(xié)議里最核心的機(jī)制有三個(gè)Agent Card每個(gè) Agent 都要提供一個(gè)公開(kāi)的 JSON 描述文件說(shuō)明自己的身份、能力、 endpoints。其他 Agent 通過(guò)抓取 Agent Card 來(lái)發(fā)現(xiàn)“誰(shuí)能干什么”類(lèi)似服務(wù)注冊(cè)中心的作用。Task 生命周期任務(wù)從submitted已提交、working進(jìn)行中、input-required需要補(bǔ)充輸入到completed已完成或failed失敗的狀態(tài)流轉(zhuǎn)。這套狀態(tài)機(jī)和異步任務(wù)機(jī)制的成熟度決定了你能否在 Agent 網(wǎng)絡(luò)里追蹤一個(gè)長(zhǎng)時(shí)間運(yùn)轉(zhuǎn)的任務(wù)。消息與產(chǎn)物結(jié)構(gòu)A2A 的消息是標(biāo)準(zhǔn)化的支持純文本、結(jié)構(gòu)化 JSON也支持 artifact文件傳輸。舉一個(gè)實(shí)際場(chǎng)景來(lái)理解一個(gè)購(gòu)物助手 Agent 收到用戶(hù)請(qǐng)求“幫我訂一張周五下午去上海的機(jī)票并把行程同步給我的差旅審批 Agent”。購(gòu)物助手通過(guò) A2A 發(fā)現(xiàn)差旅 Agent 的 Agent Card然后提交一個(gè) Task——不是調(diào)用差旅 Agent 的某個(gè)函數(shù)而是給它一個(gè)任務(wù)目標(biāo)、上下文、約束條件。差旅 Agent 自行判斷要執(zhí)行審批流程完成后把結(jié)果返回。兩個(gè)完全獨(dú)立的 Agent兩者都不知道對(duì)方內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)唯一共享的就是 A2A 協(xié)議本身——這就達(dá)到了“系統(tǒng)與系統(tǒng)之間協(xié)作”的層面。4.4 A2A 與 MCP 的分工協(xié)作一套完整的 AI 應(yīng)用架構(gòu)視角最后把整個(gè)架構(gòu)串起來(lái)看。從數(shù)據(jù)到智能體再到生態(tài)技術(shù)棧是分層的第一層是數(shù)據(jù)與工具接入層核心是 RAG 鏈路知識(shí)庫(kù)處理和各種業(yè)務(wù) API這一層解決“大模型不知道的”以及“大模型做不了的”問(wèn)題。第二層是 Agent 執(zhí)行與編排層核心是函數(shù)調(diào)用機(jī)制與 Agent 循環(huán)。這里用戶(hù)下達(dá)目標(biāo)Agent 自主決策拆解步驟。第三層是協(xié)議標(biāo)準(zhǔn)化層MCP 把所有工具接入標(biāo)準(zhǔn)化讓 Agent 的“手腳”可以即插即用。第四層是智能體協(xié)作層A2A 讓不同 Agent 可以互相通信和配合實(shí)現(xiàn)更大范圍的自動(dòng)協(xié)作。在真實(shí)的系統(tǒng)設(shè)計(jì)方案里四者不是互斥選項(xiàng)而是應(yīng)該依次打通的組成部分。我畫(huà)過(guò)一張自己內(nèi)部用的分層清單層次核心問(wèn)題技術(shù)方案適用場(chǎng)景數(shù)據(jù)層模型不知道私域知識(shí)RAG知識(shí)庫(kù)問(wèn)答、私域數(shù)據(jù)接入行動(dòng)層模型無(wú)法直接操作外部系統(tǒng)Function Calling單系統(tǒng)內(nèi)的確定性工具調(diào)用連接層Agent 無(wú)法標(biāo)準(zhǔn)化接入多樣工具M(jìn)CP多系統(tǒng)工具復(fù)用與即插即用協(xié)作層Agent 之間無(wú)法協(xié)同A2A跨團(tuán)隊(duì)、跨系統(tǒng)的多 Agent 協(xié)作這張表建議你保存下來(lái)做技術(shù)方案時(shí)對(duì)著看看很容易發(fā)現(xiàn)自己系統(tǒng)缺在哪一層。比如如果你的 RAG 命中率低排查的是 embedding、切塊、rerank如果你的 Agent 經(jīng)常調(diào)用錯(cuò)工具排查的重點(diǎn)是函數(shù)描述質(zhì)量如果 Agent 接入系統(tǒng)太費(fèi)人力你要考慮引入 MCP如果你的業(yè)務(wù)形態(tài)需要多個(gè) Agent 各司其職、彼此配合則是 A2A 出場(chǎng)的時(shí)機(jī)了。5. 實(shí)操落地中的高頻問(wèn)題與排查思路這節(jié)內(nèi)容來(lái)自我實(shí)際做項(xiàng)目時(shí)踩坑的記錄每個(gè)問(wèn)題都對(duì)應(yīng)著一次加班或返工。按上面五層架構(gòu)的鏈路整理成速查表排查時(shí)可以對(duì)著看問(wèn)題現(xiàn)象可能原因排查方向與解法RAG 回答不準(zhǔn)確召回結(jié)果像是“有關(guān)但不相關(guān)”切塊粒度過(guò)大或過(guò)小、Embedding 模型不合適、未配 Rerank檢查檢索結(jié)果 Top 10 的原文相關(guān)性更換中文專(zhuān)用 embedding引入 Rerank 模型RAG 檢索返回空結(jié)果文檔解析失敗、向量化異常、數(shù)據(jù)庫(kù)集合名配置錯(cuò)誤驗(yàn)證原始文檔是否成功切塊寫(xiě)入抽查向量庫(kù)記錄數(shù)對(duì)著 collection 名稱(chēng)逐一核對(duì)Agent 調(diào)用工具時(shí)參數(shù)亂填函數(shù)說(shuō)明不夠詳細(xì)函數(shù)個(gè)數(shù)太多導(dǎo)致選擇困難在函數(shù) description 里寫(xiě)清楚調(diào)用場(chǎng)景和參數(shù)取值規(guī)則精簡(jiǎn)每個(gè)輪次暴露的工具數(shù)量Agent 在多輪工具調(diào)用中出現(xiàn)上下文超長(zhǎng)工具調(diào)用結(jié)果過(guò)大且未做摘要迭代輪數(shù)不受限將大段工具結(jié)果截?cái)嗷蛏烧笕肷舷挛南拗谱畲蟮啍?shù)并增加終止條件函數(shù)調(diào)用實(shí)際執(zhí)行的和模型認(rèn)為執(zhí)行的結(jié)果不一致工具執(zhí)行結(jié)果返回格式不規(guī)范模型無(wú)法解析統(tǒng)一工具返回 JSON 格式始終攜帶success、error_msg、data三字段MCP Server 已啟動(dòng)但客戶(hù)端連不上transport 類(lèi)型不匹配stdio vs SSE/HTTP、協(xié)議版本不兼容先確認(rèn) client 與 server 傳輸方式一致檢查 MCP SDK 版本是否一致開(kāi)啟 DEBUG 日志抓 JSON-RPC 消息MCP 工具已注冊(cè)但 Agent 不調(diào)用工具描述含糊、能力與當(dāng)前任務(wù)明顯不相關(guān)檢查 MCP 返回的 tools list 里是否有該工具及描述在 prompt 中明確告知 Agent 當(dāng)前有哪些可用工具A2A 任務(wù)提交后遲遲無(wú)響應(yīng)Agent Card 的 URL 不可達(dá)、Task 生命周期事件未正確實(shí)現(xiàn)用 curl 直接調(diào) Agent Card 里聲明的 endpoint 驗(yàn)證連通性確認(rèn)服務(wù)端是否實(shí)現(xiàn)了tasks/send等核心方法5.1 RAG 效果不佳時(shí)如何定位瓶頸RAG 效果不好先冷靜定位問(wèn)題在哪一層別一上來(lái)就換模型換數(shù)據(jù)庫(kù)。我有一套固定的排查順序隨機(jī)抽取 20 個(gè)測(cè)試問(wèn)題看檢索結(jié)果 Top 5如果檢索結(jié)果本身五花八門(mén)問(wèn)題出在檢索層進(jìn)一步檢查 cut 塊粒度、向量模型和 rerank如果 Top 5 里已經(jīng)有正確內(nèi)容但最終答案卻錯(cuò)了問(wèn)題出在生成層此時(shí)應(yīng)檢查 Prompt 是否足夠約束模型“只看檢索內(nèi)容回答”以及檢索內(nèi)容是否混入了太多噪音干擾生成。最后再檢查上下文里是否真的把檢索結(jié)果放進(jìn)了合適的位置比如 system 還是 user 消息。這個(gè)排查過(guò)程沒(méi)有捷徑但有個(gè)抽樣技巧可以大幅提升效率——不要用隨機(jī)問(wèn)題去測(cè)按用戶(hù)真實(shí)日志里的高頻問(wèn)題去測(cè)因?yàn)樗鼈儾攀敲袌?chǎng)景和性能瓶頸的樣本技術(shù)上稱(chēng)為“線(xiàn)上流量回放評(píng)估”。5.2 Agent 工具調(diào)用失敗的恢復(fù)機(jī)制設(shè)計(jì)Agent 最不可控的地方在于模型在工具結(jié)果不理想或報(bào)錯(cuò)時(shí)如何自然恢復(fù)——模型往往容易死循環(huán)。比如query_order返回狀態(tài) 500如果不給出錯(cuò)誤上下文的處理規(guī)范模型可能認(rèn)為“查詢(xún)成功只是沒(méi)有數(shù)據(jù)”給用戶(hù)一個(gè)錯(cuò)誤結(jié)論。所以工具執(zhí)行一定要有錯(cuò)誤信息聲明還要讓模型把異常納入思考。業(yè)內(nèi)常用的做法是工具對(duì)調(diào)用異常返回一段特定文本并附加糾錯(cuò)建議讓模型能與調(diào)用方協(xié)商調(diào)整策略當(dāng)連續(xù)兩次同一工具失敗時(shí)Agent 必須認(rèn)輸并以明確文案報(bào)告失敗而不是自我合理化編造不存在的調(diào)用結(jié)果?？梢栽?Prompt 里用很直白的話(huà)約束“如果你誠(chéng)實(shí)報(bào)告無(wú)法完成的任務(wù)將獲得更高的獎(jiǎng)勵(lì)評(píng)分如果你假裝完成會(huì)收到罰分?！?.3 MCP Server 調(diào)試時(shí)最值得加的幾行代碼MCP 的調(diào)試比普通 HTTP 接口要麻煩——它默認(rèn)走 stdio你沒(méi)法直接看到服務(wù)端日志出錯(cuò)很難定位。我給兩個(gè)定位技巧。第一在本地調(diào)試時(shí)配置 debug 環(huán)境變量并打開(kāi) MCP SDK 的日志輸出。第二也是我大概率建議團(tuán)隊(duì)的方案先做一個(gè)模式stdio/HTTP切換這樣你可以在本地用 SSE/HTTP 啟動(dòng)后在瀏覽器或 curl 里人工發(fā)送 JSON-RPC 請(qǐng)求測(cè)試。比如拿工具列表接口來(lái)試curl -N -X POST http://localhost:3001/mcp \ -H Content-Type: application/json \ -d {jsonrpc:2.0,id:1,method:tools/list,params:{}}如果返回了已注冊(cè)的工具列表說(shuō)明服務(wù)本身沒(méi)有大問(wèn)題問(wèn)題大概率在客戶(hù)端的連接方式或鑒權(quán)配置上。如果連列表都拿不到那就從服務(wù)實(shí)現(xiàn)層去查異常。另外一個(gè)常見(jiàn)的概念坑經(jīng)常遇到MCP 不等于 HTTP 接口不是起一個(gè) Web 服務(wù)就是 MCP Server 了必須遵循 MCP 協(xié)議的 schema 和 JSON-RPC 消息格式。工具注冊(cè)交給 SDK 處理但“入站請(qǐng)求和出站響應(yīng)”必須嚴(yán)格使用 MCP 協(xié)議層。6. 從學(xué)習(xí)路線(xiàn)到架構(gòu)設(shè)計(jì)如何系統(tǒng)掌握這幾項(xiàng)能力前面講完原理和細(xì)節(jié)最后給想系統(tǒng)進(jìn)階的人一條相對(duì)高效的行動(dòng)路線(xiàn)。先聲明一個(gè)基本觀點(diǎn)不要一上來(lái)就追框架先動(dòng)手在一個(gè)真實(shí)需求上把它們逐個(gè)落地比讀十篇論文都管用。我對(duì)團(tuán)隊(duì)新人的培養(yǎng)路線(xiàn)從周一到周五的實(shí)驗(yàn)項(xiàng)目是周一部署本地 embedding 向量庫(kù)搭一個(gè)檢索問(wèn)答 Demo跑通 RAG 全鏈路周二給 Demo 接入四個(gè)真實(shí)的工具查訂單、查庫(kù)存、查物流、發(fā)消息手動(dòng)完成多輪工具調(diào)用周三把一個(gè)工具封裝成 MCP Server與 Client 連接打通驗(yàn)證動(dòng)態(tài)工具發(fā)現(xiàn)周四用兩個(gè)自研 Agent 互發(fā)任務(wù)跑通 A2A并把需要外部知識(shí)的任務(wù)鏈路接到 RAG 上周五做一次完整的架構(gòu)設(shè)計(jì)復(fù)盤(pán)。這五天跑完基本上就對(duì) RAG、Agent、函數(shù)調(diào)用、MCP、A2A 有了全局手感。這輪學(xué)習(xí)完成后更進(jìn)階的側(cè)重點(diǎn)會(huì)有兩個(gè)。一個(gè)是“精確度工程”去研究 RAG 評(píng)測(cè)指標(biāo)如何量化、召回策略如何分層、檢索質(zhì)量如何監(jiān)控給每個(gè)模塊定可量化指標(biāo)并在業(yè)務(wù)上線(xiàn)后持續(xù)觀測(cè)知識(shí)庫(kù)每天都在更新向量庫(kù)和索引的質(zhì)量不會(huì)自己保持正確。另一個(gè)是“穩(wěn)定性和可觀測(cè)性”Agent 的隨機(jī)性會(huì)讓同樣的請(qǐng)求產(chǎn)生完全不同的執(zhí)行路徑需要引入 tracing鏈路追蹤體系記錄每輪決策、每次工具調(diào)用的輸入與輸出、每個(gè) token 的消耗這樣出了問(wèn)題才能復(fù)盤(pán)——LLM 應(yīng)用調(diào)試的本質(zhì)是“看軌跡找規(guī)律”這與傳統(tǒng)應(yīng)用通過(guò)打日志看異常的模式有本質(zhì)區(qū)別。架構(gòu)上我每次做技術(shù)選型評(píng)審都會(huì)帶著一個(gè)很簡(jiǎn)潔的決策清單如果需求核心是“讓模型能回答私域問(wèn)題”選 RAG需求變成“讓模型替代人完成多步驟操作任務(wù)”補(bǔ)上 Agent 函數(shù)調(diào)用工具數(shù)量超過(guò) 5 個(gè)并穩(wěn)定高于三位數(shù)并且還要繼續(xù)接入引入 MCP系統(tǒng)拆分成多個(gè) Agent 或需要對(duì)接別的團(tuán)隊(duì) Agent規(guī)劃 A2A。有了這張圖別人再說(shuō)什么“某某技術(shù)在改變世界”時(shí)你就能穩(wěn)定地判斷自己在整體框架中的位置——因?yàn)槟阋龅牟⒉皇亲分鸶拍疃歉鶕?jù)實(shí)際業(yè)務(wù)目標(biāo)選出合適的能力層。這套能力棧的開(kāi)放度很高組件走向標(biāo)準(zhǔn)化的時(shí)間窗口很近。我個(gè)人的建議仍然是把精力放在“理解問(wèn)題的能力”上面——把知識(shí)庫(kù)、決策鏈、工具系統(tǒng)、協(xié)作網(wǎng)絡(luò)四條線(xiàn)的機(jī)制徹底吃透換任何框架都只是改幾行配置和代碼的事。真正重要的是知道自己的應(yīng)用此時(shí)缺的是哪一層。