1. 從能聊到能干活MCP 到底解決了什么核心問題如果你最近在折騰 AI 編程智能體大概率會(huì)遇到一個(gè)很尷尬的局面模型本身很聰明能寫代碼、能解釋邏輯但一旦讓它去讀你本地的項(xiàng)目文件、查一下數(shù)據(jù)庫(kù)、調(diào)一下內(nèi)部接口它立刻就瞎了。你只能手動(dòng)把文件內(nèi)容復(fù)制粘貼到對(duì)話框里或者寫一堆膠水代碼把工具硬塞進(jìn) prompt。這種做法在 demo 階段還能湊合一旦要上生產(chǎn)、要接十幾個(gè)工具、要多人協(xié)作立刻就崩。MCPModel Context Protocol出現(xiàn)的意義就是把這個(gè)膠水層標(biāo)準(zhǔn)化。你可以把它理解成 AI 世界的 USB-C 接口以前每個(gè)工具都要為每個(gè)模型單獨(dú)寫適配現(xiàn)在只要工具實(shí)現(xiàn)了 MCP Server任何支持 MCP 的客戶端都能直接接入。這不是一個(gè)簡(jiǎn)單的協(xié)議規(guī)范它真正改變的是智能體的能力邊界——從只能處理你喂給它的文本變成能主動(dòng)去獲取上下文、調(diào)用外部能力。我在實(shí)際項(xiàng)目里踩過最深的坑就是早期用純 LangChain 的 Tool 機(jī)制硬接工具。每個(gè)工具都要寫tool裝飾器、定義 schema、處理參數(shù)校驗(yàn)工具一多prompt 里塞滿了工具描述token 消耗暴漲不說模型還經(jīng)常選錯(cuò)工具。換成 MCP 之后工具發(fā)現(xiàn)和調(diào)用變成了運(yùn)行時(shí)行為模型只需要知道有哪些能力可用具體怎么調(diào)由協(xié)議層處理。這個(gè)轉(zhuǎn)變帶來的直接收益是工具數(shù)量從 5 個(gè)擴(kuò)展到 30 個(gè)prompt 長(zhǎng)度幾乎沒變。這篇文章面向的是已經(jīng)了解 LangChain 基礎(chǔ)、想往商業(yè)級(jí)智能體方向走的開發(fā)者。我會(huì)從協(xié)議理解、架構(gòu)設(shè)計(jì)、工具接入、并發(fā)處理、安全邊界幾個(gè)維度把我在真實(shí)項(xiàng)目里驗(yàn)證過的方案完整拆開講。不會(huì)只給你一個(gè)能跑的 demo而是告訴你為什么這么設(shè)計(jì)、哪里容易翻車、怎么扛住真實(shí)流量。2. MCP 協(xié)議的核心機(jī)制與常見誤解澄清2.1 MCP 的三層結(jié)構(gòu)Host、Client、Server 各管什么很多人第一次看 MCP 文檔會(huì)被 Host、Client、Server 這三個(gè)詞繞暈。我用一個(gè)生活化的類比來解釋把 MCP 想象成餐廳點(diǎn)餐系統(tǒng)。Host是餐廳本身比如你的 AI 編程助手應(yīng)用Client是服務(wù)員Server是后廚。顧客用戶跟服務(wù)員說想吃什么服務(wù)員把訂單傳給后廚后廚做好菜再通過服務(wù)員端回來。對(duì)應(yīng)到技術(shù)層面Host承載 AI 對(duì)話的應(yīng)用負(fù)責(zé)管理會(huì)話、渲染結(jié)果、決定什么時(shí)候調(diào)用工具。它不直接跟 Server 通信。ClientHost 內(nèi)部為每個(gè) Server 維護(hù)的連接實(shí)例負(fù)責(zé)協(xié)議握手、能力協(xié)商、消息路由。Server真正提供能力的一方比如文件系統(tǒng) Server、數(shù)據(jù)庫(kù) Server、Git Server。這個(gè)分層的關(guān)鍵價(jià)值在于隔離。Host 不需要知道 Server 是用 Python 還是 Node 寫的Client 不需要知道具體業(yè)務(wù)邏輯Server 不需要關(guān)心是哪個(gè)模型在調(diào)用它。每一層都可以獨(dú)立替換和擴(kuò)展。我見過最常見的誤解是把 MCP Server 當(dāng)成一個(gè) HTTP API 來理解。實(shí)際上 MCP 支持多種傳輸方式本地場(chǎng)景常用 stdio標(biāo)準(zhǔn)輸入輸出遠(yuǎn)程場(chǎng)景用 SSE 或 Streamable HTTP。stdio 模式下Server 是作為子進(jìn)程被 Client 啟動(dòng)的通信走管道延遲極低但生命周期跟 Client 綁定。這個(gè)細(xì)節(jié)在部署時(shí)非常關(guān)鍵——如果你把 Server 部署成獨(dú)立服務(wù)就要用 HTTP 傳輸如果只是本地工具stdio 更簡(jiǎn)單。2.2 能力協(xié)商為什么 MCP 比硬編碼工具更可靠MCP 在連接建立時(shí)會(huì)做一次capability negotiation能力協(xié)商。Client 和 Server 互相告訴對(duì)方自己支持哪些特性Server 聲明自己提供哪些 tools、resources、promptsClient 聲明自己支持哪些采樣能力、根目錄訪問等。這個(gè)機(jī)制解決了一個(gè)硬編碼方案無法解決的問題工具的動(dòng)態(tài)發(fā)現(xiàn)。在傳統(tǒng)方案里你必須在代碼里寫死工具列表模型看到的工具描述是靜態(tài)的。而 MCP 允許在運(yùn)行時(shí)查詢tools/list拿到當(dāng)前可用的工具集合。這意味著你可以根據(jù)用戶權(quán)限、環(huán)境配置動(dòng)態(tài)調(diào)整可用工具而不需要改代碼重新部署。注意能力協(xié)商不是可選項(xiàng)。如果你的 Client 沒有正確處理 Server 返回的 capabilities某些工具可能永遠(yuǎn)不會(huì)被激活。我在調(diào)試一個(gè)數(shù)據(jù)庫(kù) Server 時(shí)就是因?yàn)?Client 沒聲明支持 resources導(dǎo)致表結(jié)構(gòu)信息一直讀不到。2.3 三個(gè)高頻誤解MCP 不是框架、不是模型、不是萬能膠第一個(gè)誤解MCP 是框架。不是。MCP 是協(xié)議就像 HTTP 是協(xié)議一樣。LangChain、LlamaIndex 這些是框架它們可以集成 MCP但 MCP 本身不提供編排能力。你仍然需要 LangGraph 或類似工具來做多步推理的流程控制。第二個(gè)誤解MCP 能提升模型能力。不能。MCP 只是讓模型能訪問外部能力模型本身的推理水平不變。一個(gè)不會(huì)寫代碼的模型接了代碼執(zhí)行 Server 也寫不出好代碼。MCP 放大的是有能力的模型的產(chǎn)出不是沒能力的模型的短板。第三個(gè)誤解MCP 可以替代所有工具集成方案。不現(xiàn)實(shí)。對(duì)于極簡(jiǎn)單的場(chǎng)景比如只調(diào)一個(gè)天氣 API直接寫個(gè) function call 比搭 MCP Server 快得多。MCP 的價(jià)值在工具數(shù)量多、需要跨應(yīng)用復(fù)用、需要?jiǎng)討B(tài)發(fā)現(xiàn)的場(chǎng)景。選型時(shí)要算清楚投入產(chǎn)出比。3. 商業(yè)級(jí)智能體的架構(gòu)分層設(shè)計(jì)3.1 為什么不能把 LangChain Agent 直接當(dāng)生產(chǎn)架構(gòu)用 LangChain 的create_react_agent或者AgentExecutor跑通一個(gè) demo 很容易但直接拿它上生產(chǎn)會(huì)暴露一堆問題。最典型的是狀態(tài)管理混亂Agent 的中間步驟、工具調(diào)用結(jié)果、對(duì)話歷史全混在一個(gè) context 里一旦需要做斷點(diǎn)續(xù)跑、人工介入、多輪修正就無從下手。我在一個(gè)代碼審查智能體項(xiàng)目里就吃過這個(gè)虧。最初用 AgentExecutor用戶提交一個(gè) PRAgent 自動(dòng)跑 lint、跑測(cè)試、生成審查意見?？雌饋砗苊赖珜?shí)際跑起來發(fā)現(xiàn)測(cè)試失敗時(shí) Agent 會(huì)反復(fù)重試同一個(gè)工具陷入死循環(huán)用戶想中途補(bǔ)充信息沒法插入任務(wù)跑到一半服務(wù)重啟所有進(jìn)度丟失。這些問題的根源是把編排邏輯和狀態(tài)管理耦合在了一起。商業(yè)級(jí)架構(gòu)必須把這兩層拆開。3.2 分層架構(gòu)編排層、狀態(tài)層、能力層的職責(zé)劃分我最終采用的架構(gòu)分三層編排層用 LangGraph 實(shí)現(xiàn)。LangGraph 的核心優(yōu)勢(shì)是把 Agent 的執(zhí)行建模成狀態(tài)圖每個(gè)節(jié)點(diǎn)是一個(gè)處理步驟邊是轉(zhuǎn)移條件。這樣你可以精確控制什么時(shí)候調(diào)工具、什么時(shí)候問用戶、什么時(shí)候結(jié)束。相比 ReAct 的隱式循環(huán)狀態(tài)圖是顯式的可測(cè)試、可調(diào)試、可中斷。狀態(tài)層用獨(dú)立的持久化存儲(chǔ)。LangGraph 自帶 checkpointer 機(jī)制可以把每一步的狀態(tài)存到數(shù)據(jù)庫(kù)。我用 PostgreSQL 做 checkpointer配合 thread_id 實(shí)現(xiàn)會(huì)話隔離。這樣服務(wù)重啟后用同一個(gè) thread_id 就能恢復(fù)執(zhí)行。人工介入也簡(jiǎn)單了——暫停圖執(zhí)行等用戶輸入再 resume。能力層就是 MCP Server 集群。每個(gè) Server 負(fù)責(zé)一類能力文件操作、代碼執(zhí)行、數(shù)據(jù)庫(kù)查詢、內(nèi)部 API 調(diào)用。編排層通過 MCP Client 統(tǒng)一訪問不關(guān)心具體實(shí)現(xiàn)。這個(gè)分層的直接好處是可替換性。編排邏輯要改只動(dòng) LangGraph 部分換個(gè)數(shù)據(jù)庫(kù)只動(dòng)狀態(tài)層加個(gè)新工具只加一個(gè) MCP Server。三層之間通過明確接口通信互不干擾。3.3 狀態(tài)圖設(shè)計(jì)把智能關(guān)進(jìn)可控的籠子里很多人對(duì) Agent 有個(gè)浪漫的想象給它一個(gè)目標(biāo)它自己規(guī)劃、自己執(zhí)行、自己糾錯(cuò)。實(shí)際生產(chǎn)中這種完全自主的 Agent 是災(zāi)難。它會(huì)做出你意想不到的操作消耗你意想不到的資源產(chǎn)生你意想不到的副作用。我的做法是用狀態(tài)圖約束 Agent 的行為空間。具體來說把任務(wù)拆成有限的狀態(tài)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)明確能做什么、不能做什么、什么條件下轉(zhuǎn)移。比如代碼生成任務(wù)解析需求節(jié)點(diǎn)提取用戶意圖識(shí)別編程語(yǔ)言和框架檢索上下文節(jié)點(diǎn)通過 MCP 讀取相關(guān)文件、依賴、歷史提交生成方案節(jié)點(diǎn)調(diào)用模型生成代碼草案靜態(tài)檢查節(jié)點(diǎn)通過 MCP 調(diào)用 linter測(cè)試執(zhí)行節(jié)點(diǎn)通過 MCP 在沙箱里跑測(cè)試修正循環(huán)節(jié)點(diǎn)測(cè)試失敗則回到生成方案最多重試 N 次輸出節(jié)點(diǎn)生成最終結(jié)果每個(gè)節(jié)點(diǎn)都有明確的輸入輸出和失敗處理。模型只在生成方案和修正節(jié)點(diǎn)里發(fā)揮創(chuàng)造力其他節(jié)點(diǎn)都是確定性的。這樣既保留了 AI 的靈活性又保證了流程的可控性。提示重試次數(shù)一定要設(shè)上限。我見過 Agent 因?yàn)橐粋€(gè)永遠(yuǎn)修不好的測(cè)試用例重試了 200 多次燒掉了幾十美元的 token。設(shè)個(gè) 3 到 5 次的上限超了就轉(zhuǎn)人工。4. MCP Server 的工程化落地細(xì)節(jié)4.1 工具粒度一個(gè) Server 該暴露多少工具這是設(shè)計(jì) MCP Server 時(shí)第一個(gè)要做的決策。我的經(jīng)驗(yàn)是按領(lǐng)域劃分 Server按操作劃分工具。比如文件操作是一個(gè) Server里面可以有 read_file、write_file、list_dir、search_files 等工具。不要把文件操作、數(shù)據(jù)庫(kù)操作、HTTP 請(qǐng)求全塞進(jìn)一個(gè) Server那樣能力協(xié)商會(huì)變得很重權(quán)限控制也沒法做細(xì)。工具粒度本身也有講究。太粗比如一個(gè)do_everything工具模型不知道怎么用太細(xì)比如把 read_file 拆成 open、read、close 三個(gè)工具模型要調(diào)三次才能讀一個(gè)文件效率極低。合理的粒度是一個(gè)工具對(duì)應(yīng)一個(gè)完整的用戶意圖。讀文件就是讀文件不需要暴露文件句柄這種底層概念。我在一個(gè)項(xiàng)目里把 Git 操作設(shè)計(jì)成 12 個(gè)細(xì)粒度工具結(jié)果模型經(jīng)常搞混git_add和git_commit的順序。后來合并成stage_and_commit一個(gè)工具錯(cuò)誤率直接降了一半。工具設(shè)計(jì)要站在模型的角度想它需要完成什么任務(wù)而不是底層 API 長(zhǎng)什么樣。4.2 參數(shù) schema 設(shè)計(jì)讓模型一次就調(diào)對(duì)MCP 工具的參數(shù)用 JSON Schema 描述。這個(gè) schema 的質(zhì)量直接決定模型調(diào)用的準(zhǔn)確率。我總結(jié)了幾個(gè)實(shí)戰(zhàn)要點(diǎn)必填參數(shù)要少。每多一個(gè)必填參數(shù)模型出錯(cuò)的概率就上升。能推斷的參數(shù)就給默認(rèn)值能從上下文拿的就不要暴露給模型。枚舉值要明確。如果一個(gè)參數(shù)只能是幾個(gè)固定值一定要用 enum 約束并在 description 里解釋每個(gè)值的含義。模型對(duì)自由文本參數(shù)的處理遠(yuǎn)不如對(duì)枚舉可靠。description 要寫什么時(shí)候用而不只是是什么。比如一個(gè)search_code工具description 寫在代碼庫(kù)中搜索遠(yuǎn)不如當(dāng)需要查找某個(gè)函數(shù)、變量或字符串在代碼庫(kù)中的定義和引用位置時(shí)使用來得有效。模型是根據(jù) description 來決定調(diào)不調(diào)這個(gè)工具的。錯(cuò)誤信息要可操作。工具執(zhí)行失敗時(shí)返回的錯(cuò)誤要告訴模型怎么修正。比如文件不存在不如文件不存在請(qǐng)先用 list_dir 確認(rèn)路徑。這樣模型能自我糾正而不是卡在那里。4.3 流式輸出與長(zhǎng)任務(wù)處理商業(yè)場(chǎng)景里很多工具調(diào)用是耗時(shí)的跑一次完整測(cè)試可能幾分鐘查一個(gè)大表可能幾十秒。如果等工具全部執(zhí)行完再返回用戶體驗(yàn)極差。MCP 支持流式返回中間結(jié)果這個(gè)能力必須用起來。我的做法是MCP Server 在執(zhí)行長(zhǎng)任務(wù)時(shí)通過 progress notification 持續(xù)上報(bào)進(jìn)度。Client 收到后實(shí)時(shí)推給前端用戶能看到正在編譯... 正在跑測(cè)試用例 3/15...。這不僅是體驗(yàn)問題也是信任問題——用戶看到進(jìn)度才知道系統(tǒng)沒卡死。對(duì)于超長(zhǎng)任務(wù)還要考慮超時(shí)和取消。MCP 協(xié)議支持 cancellationClient 可以主動(dòng)取消正在執(zhí)行的請(qǐng)求。我在 Server 端實(shí)現(xiàn)了優(yōu)雅取消收到取消信號(hào)后清理臨時(shí)資源、回滾未提交的操作、返回部分結(jié)果。這個(gè)細(xì)節(jié)不做用戶取消任務(wù)后可能留下臟數(shù)據(jù)。5. 并發(fā)、安全與可觀測(cè)性生產(chǎn)環(huán)境的三個(gè)硬骨頭5.1 并發(fā)場(chǎng)景下 MCP 連接池的設(shè)計(jì)單用戶單會(huì)話時(shí)一個(gè) MCP Client 對(duì)應(yīng)一個(gè) Server 連接就夠了。但商業(yè)級(jí)應(yīng)用要面對(duì)多用戶并發(fā)這時(shí)候連接管理就成了瓶頸。stdio 模式下每個(gè)連接都是一個(gè)子進(jìn)程100 個(gè)并發(fā)用戶就是 100 個(gè)子進(jìn)程內(nèi)存直接爆掉。我的方案是連接池 會(huì)話隔離。維護(hù)一組 MCP Server 進(jìn)程每個(gè)進(jìn)程可以服務(wù)多個(gè)會(huì)話但會(huì)話之間的狀態(tài)嚴(yán)格隔離。具體實(shí)現(xiàn)上Server 端用 session_id 區(qū)分不同會(huì)話的上下文Client 端用池化技術(shù)復(fù)用連接。這樣 100 個(gè)并發(fā)用戶可能只需要 10 個(gè) Server 進(jìn)程。但這里有個(gè)坑有狀態(tài)工具不能共享連接。比如一個(gè)維護(hù)了工作目錄的 shell 工具如果兩個(gè)會(huì)話共用一個(gè)進(jìn)程A 用戶 cd 到某個(gè)目錄B 用戶的命令就會(huì)在錯(cuò)誤的目錄執(zhí)行。解決辦法是給這類工具標(biāo)記為獨(dú)占每個(gè)會(huì)話分配獨(dú)立進(jìn)程或者干脆把狀態(tài)外置到會(huì)話存儲(chǔ)里。注意連接池的大小要根據(jù)實(shí)際負(fù)載壓測(cè)確定。我一開始設(shè)了 20結(jié)果高峰期排隊(duì)嚴(yán)重調(diào)到 50 后 CPU 又打滿。最后用動(dòng)態(tài)擴(kuò)縮容低峰 10 個(gè)、高峰 50 個(gè)才找到平衡點(diǎn)。5.2 權(quán)限邊界MCP Server 能碰什么、不能碰什么這是安全上最容易被忽視的地方。MCP Server 本質(zhì)上是給 AI 開了一扇通往你系統(tǒng)的門如果權(quán)限控制不到位模型一個(gè)幻覺就可能刪庫(kù)跑路。我的原則是最小權(quán)限 白名單 沙箱。文件操作 Server 只能訪問指定的工作目錄路徑要做規(guī)范化校驗(yàn)防止../穿越。代碼執(zhí)行 Server 必須跑在容器里限制 CPU、內(nèi)存、網(wǎng)絡(luò)。數(shù)據(jù)庫(kù) Server 用只讀賬號(hào)敏感表直接不暴露。還有一點(diǎn)工具的危險(xiǎn)等級(jí)要分級(jí)。讀操作可以放開寫操作要確認(rèn)刪除操作要二次確認(rèn)。我在編排層實(shí)現(xiàn)了審批節(jié)點(diǎn)遇到高危工具調(diào)用時(shí)暫停執(zhí)行等用戶確認(rèn)后再繼續(xù)。這個(gè)機(jī)制救過我好幾次——有一次模型想批量刪除測(cè)試文件審批節(jié)點(diǎn)攔下來用戶發(fā)現(xiàn)路徑寫錯(cuò)了。5.3 可觀測(cè)性怎么知道 Agent 到底在干什么Agent 的黑盒特性是運(yùn)維的噩夢(mèng)。用戶說它卡住了你根本不知道卡在哪一步。可觀測(cè)性必須從第一天就做。我埋了三層日志協(xié)議層記錄所有 MCP 消息的收發(fā)包括請(qǐng)求參數(shù)和返回結(jié)果編排層記錄狀態(tài)圖的節(jié)點(diǎn)轉(zhuǎn)移每個(gè)節(jié)點(diǎn)的輸入輸出和耗時(shí)模型層記錄每次 LLM 調(diào)用的 prompt、response、token 消耗。三層日志用統(tǒng)一的 trace_id 串聯(lián)出問題時(shí)能完整還原執(zhí)行鏈路。指標(biāo)方面重點(diǎn)監(jiān)控幾個(gè)工具調(diào)用成功率、平均耗時(shí)、重試率、token 消耗、并發(fā)會(huì)話數(shù)。這些指標(biāo)異常時(shí)能提前預(yù)警。比如工具調(diào)用成功率突然下降可能是某個(gè) Server 掛了token 消耗飆升可能是模型陷入了循環(huán)。6. 從 Demo 到上線我踩過的五個(gè)真實(shí)坑6.1 坑一工具描述太長(zhǎng)導(dǎo)致模型選擇困難早期我把每個(gè)工具的 description 寫得很詳細(xì)一個(gè)工具描述 200 多字。30 個(gè)工具就是 6000 多字光工具描述就占了大半 context。結(jié)果模型經(jīng)常選錯(cuò)工具因?yàn)樗究床贿^來。后來我把 description 精簡(jiǎn)到 50 字以內(nèi)只保留什么時(shí)候用和關(guān)鍵參數(shù)說明詳細(xì)文檔放到 Server 端模型需要時(shí)再通過 resources 讀取。工具選擇準(zhǔn)確率從 60% 提升到 90% 以上。6.2 坑二stdio 子進(jìn)程泄漏stdio 模式下如果 Client 異常退出沒有正確關(guān)閉 Server 子進(jìn)程這些進(jìn)程會(huì)變成孤兒進(jìn)程越積越多。我有個(gè)服務(wù)跑了一周積累了 300 多個(gè)僵尸進(jìn)程內(nèi)存被吃光。解決辦法是在 Client 端注冊(cè)退出鉤子確保所有 Server 進(jìn)程被正確終止。同時(shí) Server 端要實(shí)現(xiàn)心跳檢測(cè)長(zhǎng)時(shí)間收不到 Client 消息就自行退出。雙保險(xiǎn)。6.3 坑三模型把工具返回的錯(cuò)誤當(dāng)成正常結(jié)果有一次數(shù)據(jù)庫(kù)查詢工具返回了表不存在的錯(cuò)誤模型沒有意識(shí)到這是錯(cuò)誤反而基于這個(gè)錯(cuò)誤信息編造了一個(gè)查詢結(jié)果。這是典型的錯(cuò)誤語(yǔ)義丟失。修復(fù)方法是在 MCP 返回結(jié)果里明確標(biāo)記isError: true并在編排層做攔截工具返回錯(cuò)誤時(shí)不直接喂給模型而是先經(jīng)過一個(gè)錯(cuò)誤處理節(jié)點(diǎn)把錯(cuò)誤翻譯成模型能理解的指令比如查詢失敗表名可能拼寫錯(cuò)誤請(qǐng)先用 list_tables 確認(rèn)。6.4 坑四并發(fā)下的會(huì)話串?dāng)_前面提過連接池的坑這里說個(gè)更隱蔽的共享緩存導(dǎo)致的串?dāng)_。我在 Server 端做了查詢結(jié)果緩存來提速但緩存 key 沒帶 session_id結(jié)果 A 用戶的查詢結(jié)果被 B 用戶讀到了。這在多租戶場(chǎng)景下是嚴(yán)重的數(shù)據(jù)泄露。修復(fù)很簡(jiǎn)單所有緩存 key 必須包含 session_id。但這個(gè)坑提醒我任何共享狀態(tài)都要審查隔離性。連接池、緩存、臨時(shí)文件、日志凡是跨會(huì)話共享的都要問一句會(huì)不會(huì)串。6.5 坑五LangGraph 狀態(tài)膨脹LangGraph 的 checkpointer 會(huì)把每一步的狀態(tài)存下來。如果狀態(tài)里塞了完整的文件內(nèi)容、大段代碼數(shù)據(jù)庫(kù)很快就撐爆了。我有個(gè)項(xiàng)目狀態(tài)表一個(gè)月漲到 50GB。優(yōu)化方案是狀態(tài)里只存引用不存內(nèi)容。文件內(nèi)容存到對(duì)象存儲(chǔ)狀態(tài)里只存 URL 或 ID。同時(shí)設(shè)置狀態(tài)過期策略完成的任務(wù)定期歸檔清理。這樣狀態(tài)表穩(wěn)定在幾 GB 以內(nèi)。7. 一些關(guān)于選型和演進(jìn)的個(gè)人判斷關(guān)于 MCP 和 LangChain 的關(guān)系我的看法是它們不是競(jìng)爭(zhēng)是互補(bǔ)。LangChain 負(fù)責(zé)編排和抽象MCP 負(fù)責(zé)能力接入。LangGraph 做狀態(tài)機(jī)MCP 做工具層這個(gè)組合目前是我認(rèn)為最穩(wěn)的生產(chǎn)方案。關(guān)于要不要自研 MCP Server取決于你的場(chǎng)景。如果只是接幾個(gè)公開工具用現(xiàn)成的 Server 就行。但如果涉及內(nèi)部系統(tǒng)、敏感數(shù)據(jù)、特殊業(yè)務(wù)邏輯自研是必須的。自研的成本主要在協(xié)議實(shí)現(xiàn)和錯(cuò)誤處理上用官方 SDK 能省不少事。關(guān)于 Agent 的自主性我的態(tài)度是能約束就約束。商業(yè)場(chǎng)景要的是穩(wěn)定、可預(yù)測(cè)、可審計(jì)不是炫技。把 Agent 的能力關(guān)在狀態(tài)圖的籠子里讓它在該發(fā)揮的地方發(fā)揮在該確定的地方確定這才是工程化的思路。最后分享一個(gè)我最近在試的方向多 Agent 協(xié)作。用 MCP 把不同專長(zhǎng)的 Agent 封裝成 Server一個(gè)主 Agent 負(fù)責(zé)調(diào)度需要寫代碼時(shí)調(diào)代碼 Agent需要查數(shù)據(jù)時(shí)調(diào)數(shù)據(jù) Agent。這樣每個(gè) Agent 的 context 更聚焦整體效果比單個(gè)大 Agent 好。這個(gè)方案還在驗(yàn)證中等跑穩(wěn)了再單獨(dú)寫一篇。如果你也在做類似的事情歡迎交流。這個(gè)領(lǐng)域變化太快一個(gè)人踩坑不如一群人踩坑。