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