一、為什么關(guān)注 Agent 的工具接入在大模型應(yīng)用落地中RAG 主要解決的是“讓模型基于外部知識回答問題”比如商品說明、活動規(guī)則、售后政策、平臺規(guī)則等知識類內(nèi)容。但是在真實(shí)客服場景里用戶的問題往往不只是“問知識”還會涉及具體業(yè)務(wù)動作例如查詢訂單狀態(tài)查詢物流軌跡判斷是否滿足價(jià)保條件創(chuàng)建售后工單查詢退款進(jìn)度觸發(fā)人工審核這類問題僅靠 RAG 是不夠的因?yàn)樗枰L問業(yè)務(wù)系統(tǒng)甚至需要執(zhí)行某些操作。因此在 Agent 系統(tǒng)中工具調(diào)用就成了非常關(guān)鍵的一層。最早做 Agent 工具調(diào)用時(shí)常見方式是通過 Function Calling 或 Tool Calling把訂單查詢、物流查詢、售后工單等接口包裝成工具讓模型根據(jù)用戶意圖決定是否調(diào)用。這種方式可以跑通業(yè)務(wù)流程但隨著工具數(shù)量增加也會遇到一些工程問題不同工具的參數(shù)格式不統(tǒng)一不同接口的返回結(jié)構(gòu)不一致Agent 側(cè)需要維護(hù)較多工具調(diào)用邏輯工具異常、超時(shí)、重試、降級處理分散多 Agent 共用工具時(shí)容易出現(xiàn)重復(fù)封裝因此工具接入層需要逐步從“能調(diào)用”走向“標(biāo)準(zhǔn)化、可維護(hù)、可擴(kuò)展”。二、Tool Calling 在客服 Agent 中的基本流程以電商客服場景為例一個(gè)典型的用戶問題是我的訂單什么時(shí)候發(fā)貨系統(tǒng)大致會經(jīng)歷下面幾個(gè)步驟接收用戶問題判斷問題屬于訂單物流類意圖提取訂單號、用戶 ID 等必要參數(shù)調(diào)用訂單查詢工具調(diào)用物流查詢工具根據(jù)工具返回結(jié)果生成回復(fù)如果工具異常則進(jìn)入重試或人工兜底如果使用 LangGraph 編排可以把這個(gè)過程拆成多個(gè)節(jié)點(diǎn)用戶輸入 ↓ 意圖識別節(jié)點(diǎn) ↓ 槽位提取節(jié)點(diǎn) ↓ 訂單服務(wù) Agent ↓ 工具調(diào)用節(jié)點(diǎn) ↓ 結(jié)果整理節(jié)點(diǎn) ↓ 回復(fù)生成節(jié)點(diǎn)在這個(gè)流程里L(fēng)angGraph 主要負(fù)責(zé)流程編排和狀態(tài)流轉(zhuǎn)Tool Calling 主要負(fù)責(zé)讓模型決定是否調(diào)用工具以及調(diào)用哪個(gè)工具。例如訂單查詢工具可以抽象成defquery_order(order_id:str,user_id:str)-dict: 根據(jù)訂單號和用戶ID查詢訂單狀態(tài)。 pass物流查詢工具可以抽象成defquery_logistics(order_id:str)-dict: 根據(jù)訂單號查詢物流軌跡。 pass售后工單工具可以抽象成defcreate_after_sale_ticket(order_id:str,reason:str,user_id:str)-dict: 創(chuàng)建售后工單。 pass這種方式比較直觀適合早期 PoC 或工具數(shù)量較少的場景。三、直接使用 Tool Calling 會遇到的問題當(dāng)系統(tǒng)從單個(gè) Agent 發(fā)展到多個(gè) Agent 后工具調(diào)用會變復(fù)雜。例如客服系統(tǒng)中可能會拆出三個(gè)專項(xiàng) Agent商品咨詢 Agent負(fù)責(zé)商品參數(shù)、活動規(guī)則、使用說明訂單服務(wù) Agent負(fù)責(zé)訂單狀態(tài)、物流軌跡、發(fā)貨時(shí)效售后處理 Agent負(fù)責(zé)退款、退貨、價(jià)保、憑證補(bǔ)充這三個(gè) Agent 都可能需要調(diào)用工具。比如商品咨詢 Agent 可能需要查詢商品信息 訂單服務(wù) Agent 可能需要查詢訂單和物流 售后處理 Agent 可能需要查詢訂單、物流、售后政策和工單狀態(tài)如果每個(gè) Agent 都直接維護(hù)自己的工具調(diào)用邏輯后期會出現(xiàn)幾個(gè)問題。1. 工具定義重復(fù)訂單查詢工具可能同時(shí)被訂單 Agent 和售后 Agent 使用。如果兩個(gè) Agent 各自封裝一遍后期接口字段變化時(shí)就需要多處修改。2. 參數(shù)校驗(yàn)分散有些工具必須校驗(yàn)訂單號、用戶 ID、手機(jī)號后四位、售后類型等字段。如果校驗(yàn)邏輯散落在不同 Agent 中很容易出現(xiàn)遺漏。3. 返回格式不統(tǒng)一有的接口返回status有的接口返回code有的接口返回success。如果不統(tǒng)一Agent 后續(xù)處理會比較麻煩。4. 異常處理不集中工具調(diào)用可能出現(xiàn)接口超時(shí)、參數(shù)缺失、訂單不存在、重復(fù)提交等問題。如果每個(gè) Agent 單獨(dú)處理會導(dǎo)致重試、降級、人工兜底邏輯不一致。5. 后續(xù)擴(kuò)展成本高當(dāng)業(yè)務(wù)新增“發(fā)票查詢”“優(yōu)惠券查詢”“工單催辦”等工具時(shí)如果沒有統(tǒng)一的工具接入規(guī)范系統(tǒng)會越來越難維護(hù)。四、MCP 適合解決什么問題MCP 可以理解為 Agent 和外部工具、數(shù)據(jù)源之間的一層標(biāo)準(zhǔn)化協(xié)議。它不是替代 LangGraph也不是替代 RAG而是更偏向解決Agent 如何以統(tǒng)一方式發(fā)現(xiàn)工具、理解工具、調(diào)用工具。在客服 Agent 場景里可以把訂單、物流、售后等能力統(tǒng)一封裝成 MCP Server 暴露的工具。例如訂單 MCP Server ├── query_order ├── query_logistics └── query_invoice 售后 MCP Server ├── query_after_sale_policy ├── create_after_sale_ticket ├── query_ticket_status └── submit_refund_requestAgent 側(cè)通過 MCP Client 獲取這些工具并根據(jù)工具描述完成調(diào)用。這樣一來Agent 不需要直接關(guān)心底層接口來自哪個(gè)系統(tǒng)也不需要在每個(gè) Agent 中重復(fù)維護(hù)工具定義。更清晰的職責(zé)劃分是LangGraph負(fù)責(zé)流程編排、狀態(tài)流轉(zhuǎn)、條件路由、中斷恢復(fù) MCP負(fù)責(zé)業(yè)務(wù)工具的標(biāo)準(zhǔn)化暴露和調(diào)用 FastAPI負(fù)責(zé)統(tǒng)一入口和底層業(yè)務(wù)接口封裝 Redis負(fù)責(zé)熱問緩存、會話狀態(tài)和冪等控制 RAG負(fù)責(zé)政策、規(guī)則、商品說明等知識檢索 LLM負(fù)責(zé)意圖理解、工具選擇和回復(fù)生成五、一個(gè)客服 Agent 的工具調(diào)用鏈路假設(shè)用戶問我這個(gè)訂單物流一直沒更新可以幫我看看嗎系統(tǒng)可以這樣處理1. FastAPI 接收用戶請求 2. Orchestrator 判斷用戶意圖屬于訂單物流問題 3. LangGraph 將請求路由到訂單服務(wù) Agent 4. Agent 從上下文中提取訂單號 5. 如果訂單號缺失先進(jìn)行槽位追問 6. 訂單號完整后通過 MCP Client 調(diào)用物流查詢工具 7. MCP Server 調(diào)用底層物流接口 8. 工具返回物流軌跡和當(dāng)前狀態(tài) 9. LangGraph 將結(jié)果寫入 State 10. 如果物流異常進(jìn)入售后處理 Agent 或人工審核流程 11. 最終生成面向用戶的回復(fù)這里面最關(guān)鍵的是Orchestrator 負(fù)責(zé)判斷去哪一個(gè) AgentAgent 負(fù)責(zé)完成當(dāng)前任務(wù)MCP 負(fù)責(zé)調(diào)用業(yè)務(wù)工具State 負(fù)責(zé)保存上下文Checkpointer 負(fù)責(zé)中斷后的恢復(fù)如果用戶問題升級為物流一直沒動我想申請退款。流程就會從訂單服務(wù) Agent 轉(zhuǎn)到售后處理 Agent訂單物流查詢 ↓ 判斷物流異常 ↓ 路由到售后處理 Agent ↓ 檢索售后政策 ↓ 調(diào)用訂單和工單工具 ↓ 風(fēng)控規(guī)則判斷 ↓ 低風(fēng)險(xiǎn)自動處理 / 高風(fēng)險(xiǎn)轉(zhuǎn)人工審核這類流程就不是簡單 RAG 能完成的而是需要 Agent 編排、工具調(diào)用、狀態(tài)管理和風(fēng)控規(guī)則共同配合。六、MCP 和 FastAPI 的關(guān)系很多人容易把 MCP 和 FastAPI 混在一起。我的理解是FastAPI 更偏業(yè)務(wù)服務(wù)接口。 MCP 更偏 Agent 工具協(xié)議。也就是說底層業(yè)務(wù)系統(tǒng)可以仍然使用 FastAPI 提供接口例如GET /api/orders/{order_id} GET /api/logistics/{order_id} POST /api/after-sale/tickets而 MCP Server 可以在這些接口之上再封裝一層把它們變成 Agent 更容易理解和調(diào)用的工具query_order query_logistics create_after_sale_ticket這樣做的好處是底層系統(tǒng)仍然保持原有接口設(shè)計(jì)Agent 層則通過統(tǒng)一工具協(xié)議訪問這些能力。簡單理解FastAPI 面向業(yè)務(wù)系統(tǒng)和普通服務(wù)調(diào)用。 MCP 面向 Agent 的工具發(fā)現(xiàn)和工具調(diào)用。七、工具調(diào)用中的幾個(gè)工程細(xì)節(jié)在真實(shí)業(yè)務(wù)里工具調(diào)用不能只考慮“調(diào)通”還要考慮異常和穩(wěn)定性。1. 參數(shù)校驗(yàn)比如售后工單創(chuàng)建工具至少需要校驗(yàn)用戶 ID 是否存在訂單號是否合法訂單是否屬于當(dāng)前用戶是否超過售后期限是否已經(jīng)存在同類工單退款原因是否在允許范圍內(nèi)否則模型生成的參數(shù)可能會導(dǎo)致錯誤調(diào)用。2. 冪等控制用戶可能會重復(fù)點(diǎn)擊網(wǎng)絡(luò)也可能重試。如果沒有冪等控制可能會重復(fù)創(chuàng)建工單?？梢允褂糜脩鬒D 訂單號 售后類型作為冪等鍵避免重復(fù)提交。3. 超時(shí)重試業(yè)務(wù)接口可能會超時(shí)因此工具調(diào)用需要設(shè)置超時(shí)時(shí)間和重試策略。常見方式是最多重試 3 次 每次重試間隔遞增 失敗后返回降級結(jié)果 必要時(shí)轉(zhuǎn)人工處理4. 返回結(jié)構(gòu)統(tǒng)一工具返回結(jié)果最好統(tǒng)一成類似結(jié)構(gòu){success:true,code:OK,message:查詢成功,data:{},trace_id:xxx}這樣 Agent 后續(xù)處理會更穩(wěn)定也方便日志排查。5. 狀態(tài)持久化對于需要人工審核的流程不能只依賴內(nèi)存狀態(tài)?？梢詫?dāng)前會話的 State 保存到 Redis 中包括用戶意圖訂單上下文已完成節(jié)點(diǎn)工具調(diào)用結(jié)果風(fēng)控標(biāo)簽人工審核狀態(tài)人工審核完成后再從 Checkpointer 恢復(fù)流程繼續(xù)執(zhí)行。八、RAG、Tool Calling 和 MCP 的區(qū)別在客服系統(tǒng)里這三者經(jīng)常同時(shí)出現(xiàn)但解決的問題不一樣。能力主要解決的問題典型場景RAG查知識、找依據(jù)、減少幻覺售后政策、活動規(guī)則、商品說明Tool Calling讓模型決定調(diào)用哪個(gè)工具查詢訂單、查詢物流、創(chuàng)建工單MCP標(biāo)準(zhǔn)化暴露和調(diào)用工具多 Agent 共用訂單、物流、售后工具可以簡單記成RAG 解決“回答依據(jù)從哪里來”。 Tool Calling 解決“模型什么時(shí)候調(diào)用工具”。 MCP 解決“工具如何標(biāo)準(zhǔn)化接入 Agent”。九、一個(gè)更完整的工程流程結(jié)合 LangGraph、RAG、MCP 和業(yè)務(wù)工具一個(gè)客服 Agent 系統(tǒng)可以抽象成下面的流程用戶輸入 ↓ FastAPI 統(tǒng)一入口 ↓ 參數(shù)校驗(yàn) / 安全攔截 / 會話初始化 ↓ Orchestrator 意圖識別 ↓ LangGraph State 更新 ↓ 條件路由 ├── 商品咨詢 Agent │ └── FAQ / RAG 檢索商品知識 │ ├── 訂單服務(wù) Agent │ └── MCP 調(diào)用訂單、物流工具 │ └── 售后處理 Agent ├── RAG 檢索售后政策 └── MCP 調(diào)用訂單、工單、退款工具 ↓ 風(fēng)控規(guī)則判斷 ↓ 低風(fēng)險(xiǎn)自動回復(fù) / 高風(fēng)險(xiǎn)人工審核 ↓ Checkpointer 保存狀態(tài) ↓ 生成最終回復(fù)這個(gè)架構(gòu)中每一層職責(zé)比較清晰FastAPI負(fù)責(zé)接收請求和接口服務(wù)Orchestrator負(fù)責(zé)統(tǒng)一調(diào)度LangGraph負(fù)責(zé)流程狀態(tài)和節(jié)點(diǎn)編排RAG負(fù)責(zé)知識檢索MCP負(fù)責(zé)工具接入Redis負(fù)責(zé)緩存和狀態(tài)保存風(fēng)控規(guī)則負(fù)責(zé)業(yè)務(wù)邊界控制十、總結(jié)在大模型應(yīng)用開發(fā)中RAG 解決的是知識增強(qiáng)問題Agent 解決的是任務(wù)執(zhí)行問題而 MCP 更偏向解決工具接入標(biāo)準(zhǔn)化問題。對于電商客服這類業(yè)務(wù)場景用戶問題往往會同時(shí)涉及知識查詢、訂單狀態(tài)、物流軌跡、售后規(guī)則和人工審核。如果只使用 RAG系統(tǒng)只能回答知識類問題如果只使用 Tool Calling隨著工具數(shù)量增加維護(hù)成本會逐漸變高。因此比較合理的設(shè)計(jì)是用 LangGraph 管流程 用 RAG 查知識 用 MCP 接工具 用 Redis 存狀態(tài) 用風(fēng)控規(guī)則控邊界。這樣既能保留大模型的理解和生成能力也能讓系統(tǒng)更貼近真實(shí)業(yè)務(wù)流程減少工具調(diào)用混亂、狀態(tài)丟失和異常不可控的問題。對我來說MCP 更像是 Agent 工程化過程中的一層“工具協(xié)議抽象”。它不一定是所有項(xiàng)目一開始就必須引入的組件但當(dāng)系統(tǒng)中存在多個(gè) Agent、多個(gè)業(yè)務(wù)工具、多個(gè)外部數(shù)據(jù)源時(shí)MCP 的價(jià)值會更加明顯。