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