做 LLM 應用的人十有八九遇到過同一個尷尬對話、問答、文本總結都跑通了演示效果也很驚艷但一提到“下單”“加購”“支付”這種真實交易動作項目就卡住了。要么是模型只能在對話框里聊得熱鬧要么是業務系統根本不敢讓 AI 直接碰購物車。這個“從 LLM 到購物車”的距離恰恰是 LLM 應用從 Demo 走向生產力的關鍵一環。最近在一些電商出海項目里我一直在研究一個非常具體的場景用戶在聊天窗口里說“我想買一瓶 30 歐元以內的波特酒”LLM 能理解意圖、檢索商品、把東西加進購物車然后讓用戶確認結算。整個流程聽起來不復雜但真正實現時會碰到工具調用、商品檢索、數據一致性、權限安全等一系列問題。這篇文章就圍繞一個虛構但很典型的葡萄牙電商場景完整拆解從 LLM 對話到購物車操作的架構鏈路、核心代碼和工程落地要點。讀完你可以自己復現一個最小可用的“LLM 購物助手”也知道下一步往生產環境走時該注意哪些坑。1. 這篇文章真正要解決的問題先說清楚為什么“LLM 到購物車”值得單獨寫一篇文章市面上講 LLM Agent、RAG、MCP 的文章已經很多但大多停留在一個層面——讓模型“會說話”或者“會查資料”。而購物車屬于交易鏈路它對準確性和安全性要求完全不一樣。想象一個葡萄牙電商平臺的場景。用戶在聊天窗里用葡萄牙語說“Preciso de um vinho do Porto até 30 euros para oferecer.”我需要一瓶 30 歐元以內的波特酒送人。如果只是讓 LLM 回復一句“好的我幫您找找”那這個應用毫無價值。用戶真正需要的是模型理解意圖 → 從商品庫中找到符合條件的波特酒 → 把商品加入購物車 → 返回購物車摘要給用戶確認。每一步都必須可執行、可驗證、可回滾。所以這篇文章要解決的核心問題是LLM 如何安全地調用業務系統不是讓模型直接寫數據庫而是通過受控的工具Tool/Function Calling操作購物車 API。商品知識怎么給到模型商品信息經常變化不可能全部塞進 Prompt需要 RAG 或結構化檢索兜底。多輪對話中的狀態管理用戶可能先問產品再問價格最后才說“加入購物車”Agent 怎么記住上下文。生產環境的安全邊界模型輸出不可控購物車操作必須做參數校驗、冪等和權限控制。這篇文章適合正在做 LLM 應用開發、想讓 AI 真正觸達業務交易的讀者也適合對電商系統接 AI Agent 感興趣的架構師。如果你只是寫對話機器人這篇文章可能偏工程化如果你想做 AI 導購、智能客服、Agent 購物助手那這篇文章正好踩在你的需求點上。2. LLM 到購物車核心鏈路與架構判斷從架構上看“LLM 到購物車”不是一條直線而是四層協作。我習慣把它拆成下面這張邏輯鏈路用戶消息 ↓ LLM 對話層意圖理解、多輪上下文 ↓ Agent 工具層Function Calling、工具選擇、參數提取 ↓ 業務服務層商品檢索、購物車 API、訂單服務 ↓ 數據層商品庫、向量索引、購物車存儲每一層干的事情完全不同想清楚之后再動手才不會把自己繞暈。第一層LLM 對話層。這一層負責理解用戶說了什么。它不做業務操作只負責把用戶的自然語言轉換成結構化意圖。比如“我要一瓶 30 歐元以內的波特酒”在這一層會被理解成用戶想買酒、有價格上限、是波特酒品類。這一層的輸出是“意圖 關鍵參數”不是 SQL也不是購物車操作。第二層Agent 工具層。這一層是 LLM 和業務系統之間的“隔離帶”。LLM 不直接訪問數據庫或購物車而是從預定義的工具列表中選擇合適的工具。比如search_products、add_to_cart、view_cart。LLM 要做的是給工具填參數真正執行交給業務服務。這個設計背后的原因是模型輸出天然不穩定必須用代碼約束模型能做的事情。第三層業務服務層。這里就是傳統后端開發的地盤。商品檢索服務查數據庫或向量庫購物車服務執行加購操作。這一層要做參數校驗、權限校驗、冪等控制它是整個鏈路的安全底線。第四層數據層。商品結構化數據、向量索引、購物車存儲。對購物車來說數據一致性很關鍵比如庫存不足時不能加購商品下架時要從購物車移除。這個架構的直觀類比是LLM 像一個聰明的導購員它很會說話但不能直接碰收銀臺。它把用戶的需求轉達給收銀員業務服務收銀員確認商品、價格、庫存之后才會真正把東西放進購物車。有一個常見誤區要提前說很多人以為讓 LLM 直接調數據庫、直接執行 SQL 就是“LLM 到購物車”。這在 Demo 里能跑但生產環境絕對不能這么做。模型生成的 SQL 一旦出錯輕則查詢失敗重則誤操作數據。更穩妥的做法是LLM 只負責“意圖理解 參數提取”SQL 和寫操作全部由固定代碼完成。工具層就是這層保護網。3. 場景設計與環境準備3.1 場景定義葡萄牙電商購物助手為了把文章講具體我們定義一個可復現的場景。假設我們要為一個面向葡萄牙市場的電商平臺做一個 AI 購物助手支持以下能力用戶可以用英語或葡萄牙語描述購物需求。助手能檢索商品目錄支持按品類、價格區間、關鍵詞篩選。助手能查看當前購物車內容。助手能把符合條件的商品加入購物車。助手不處理支付支付環節由用戶在前端完成。商品數據我們用一個 JSON 文件模擬包含葡萄牙特色商品波特酒Port Wine、葡萄牙陶瓷瓷磚Azulejos、軟木制品Cork Products、橄欖油Olive Oil等。3.2 技術選型與環境要求本文示例使用 Python 生態核心組件如下組件用途版本建議Python編程語言3.10FastAPI購物車服務0.100openai 或兼容 SDK調用 LLM以官方最新版為準本地或云端 LLM對話與工具調用支持 Function Calling 即可內存數據結構模擬商品庫和購物車無額外依賴重點說明一下 LLM 的選擇。如果你使用 OpenAI 兼容接口包括各類國產大模型、本地部署模型只要模型支持 Function Calling / Tool Calling就可以跑通本文示例。如果沒有合適的 API也可以在開發階段直接用一個模擬的“假 LLM”返回固定意圖來調試購物車鏈路。后者我建議你至少做一次因為把業務鏈路跑通和調模型是兩件事。3.3 項目結構我們按下面的目錄組織代碼llm-shopping-cart/ ├── app.py # FastAPI 入口購物車 API ├── products.json # 商品數據 ├── agent.py # LLM Agent 入口工具調用邏輯 ├── tools.py # 工具定義商品檢索、加購、購物車查詢 ├── retriever.py # 商品檢索模塊含簡單 RAG 檢索 ├── config.py # 配置文件 └── requirements.txt # 依賴清單這個結構足夠小適合學習和二次開發。實際項目可以把服務拆成product-service和cart-service但原理一致。4. 核心流程拆解從用戶消息到加購完成在寫代碼之前我們先完整走一遍流程搞清楚每個環節的職責。4.1 完整交互時序一次完整的“LLM 購物”交互可以拆成五個步驟第一步用戶發送消息。用戶在聊天窗口輸入自然語言需求比如“我想買一箱葡萄牙軟木杯墊預算 20 歐元以內。”第二步LLM 理解意圖并選擇工具。系統把用戶消息和歷史對話一起發給 LLM同時告訴它有哪些工具可用。LLM 判斷這一步需要通過search_products工具查商品于是返回一個結構化的工具調用請求包含參數query軟木杯墊,max_price20。第三步業務服務執行工具。我們的代碼收到工具調用請求后執行search_products從商品庫中檢索出符合條件的商品列表。第四步LLM 生成回復并確認加購。商品列表返回給 LLMLLM 組織語言告訴用戶“為您找到兩款軟木杯墊分別是 12 歐元和 18 歐元您想加入購物車嗎”用戶回復“加第一款吧”。這一次 LLM 調用add_to_cart工具參數是商品 ID 和數量。第五步購物車服務執行加購并返回結果。購物車服務校驗商品存在、庫存充足然后執行加購操作返回購物車最新內容。LLM 最后向用戶確認“已經將‘經典軟木杯墊 4 件裝’加入購物車當前購物車有 1 件商品合計 12 歐元。”4.2 每步的關鍵判斷這個流程最核心的架構判斷是LLM 不直接返回購物車操作是否成功的最終結果而是返回“我打算調用哪個工具、參數是什么”由代碼執行并校驗。這樣做有三個好處可控性即使 LLM 生成了錯誤的參數業務服務可以拒絕執行。可審計每次工具調用都可以記錄日志方便回溯。可回滾加購操作是冪等的用戶取消時可以直接刪除購物車條目。4.3 多輪對話的狀態處理購物場景天然是多輪的。用戶可能在同一次會話中先搜索、再比價、再改變主意。Agent 需要維護對話歷史。最簡單的方案是把歷史消息逐條發給 LLM由 LLM 自行理解上下文。復雜方案是引入記憶模塊把用戶偏好比如“喜歡 30 歐元以下的酒”存起來后續對話直接使用。文章示例采用第一種方案代碼實現最直接也足夠支撐演示場景。4.4 語言問題葡萄牙語與英語混合面向葡萄牙市場的應用需要處理葡英混合輸入。LLM 本身有多語言能力這個不用我們額外做太多工作。真正的挑戰在商品檢索用戶用葡萄牙語描述需求但商品名稱可能是英語或葡萄牙語。解決方案是檢索時同時匹配多語言關鍵詞或者對商品名稱做翻譯索引。5. 完整示例代碼實現下面我們逐步實現整個鏈路。先從購物車服務開始再寫商品檢索最后把 LLM Agent 接上。5.1 商品數據先準備一份模擬商品數據。文件路徑products.json。[ { id: P001, name: Classic Cork Coasters (4 pcs), category: cork, price: 12.0, currency: EUR, stock: 50, keywords: [cork, coaster, 軟木, 杯墊] }, { id: P002, name: Premium Cork Coasters (6 pcs), category: cork, price: 18.0, currency: EUR, stock: 30, keywords: [cork, coaster, premium, 軟木, 杯墊] }, { id: P003, name: Port Wine Ruby Reserve 750ml, category: wine, price: 22.0, currency: EUR, stock: 100, keywords: [port, wine, vinho, 波特酒] }, { id: P004, name: Port Wine Tawny 10 Years 750ml, category: wine, price: 35.0, currency: EUR, stock: 40, keywords: [port, wine, tawny, vinho, 波特酒] }, { id: P005, name: Portuguese Azulejo Tile Decoration, category: ceramic, price: 15.0, currency: EUR, stock: 20, keywords: [azulejo, tile, ceramic, 瓷磚] }, { id: P006, name: Extra Virgin Olive Oil 500ml, category: food, price: 9.5, currency: EUR, stock: 200, keywords: [olive, oil, azeite, 橄欖油] } ]這里的keywords字段是多語言檢索的關鍵。用戶說葡萄牙語“vinho do Porto”我們匹配keywords里的vinho和port就能找到對應的波特酒。5.2 購物車服務用 FastAPI 寫一個最小購物車服務。文件路徑app.py。# 文件路徑app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import Dict, List import json app FastAPI(titleLLM Shopping Cart Service) # 模擬商品庫實際項目請替換為數據庫 with open(products.json, r, encodingutf-8) as f: PRODUCTS json.load(f) # 模擬購物車key商品IDvalue數量 # 實際項目請替換為 Redis 或數據庫存儲 CART: Dict[str, int] {} class AddItemRequest(BaseModel): product_id: str quantity: int 1 class CartItem(BaseModel): product_id: str name: str price: float quantity: int subtotal: float app.get(/products) def list_products(category: str None, max_price: float None): 商品檢索接口支持按品類和價格過濾。 result PRODUCTS if category: result [p for p in result if p[category] category] if max_price is not None: result [p for p in result if p[price] max_price] return {products: result} app.get(/products/{product_id}) def get_product(product_id: str): 按 ID 查詢單個商品。 for p in PRODUCTS: if p[id] product_id: return p raise HTTPException(status_code404, detailProduct not found) app.post(/cart/items) def add_to_cart(req: AddItemRequest): 加入購物車帶庫存和商品存在性校驗。 product next((p for p in PRODUCTS if p[id] req.product_id), None) if product is None: raise HTTPException(status_code404, detailProduct not found) if req.quantity 0: raise HTTPException(status_code400, detailQuantity must be positive) if req.quantity product[stock]: raise HTTPException(status_code400, detailInsufficient stock) CART[req.product_id] CART.get(req.product_id, 0) req.quantity return get_cart() app.get(/cart) def get_cart(): 查看購物車內容。 items: List[CartItem] [] total 0.0 for product_id, quantity in CART.items(): product next((p for p in PRODUCTS if p[id] product_id), None) if product is None: continue subtotal product[price] * quantity total subtotal items.append(CartItem( product_idproduct_id, nameproduct[name], priceproduct[price], quantityquantity, subtotalsubtotal )) return {items: items, total: round(total, 2)} app.delete(/cart/items/{product_id}) def remove_from_cart(product_id: str): 從購物車移除商品用于用戶取消或回滾。 if product_id in CART: del CART[product_id] return get_cart() if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)這段代碼的關鍵點有三個參數校驗前置加購前檢查商品存在性和庫存避免把無效商品寫進購物車。購物車返回結構統一無論加購、查看還是刪除都返回同樣的結構方便 LLM 解讀。內存存儲僅用于演示CART字典重啟即丟失。生產環境替換為 Redis 或數據庫時接口簽名可以保持不變。5.3 商品檢索模塊購物場景里用戶很少直接說商品 ID更多是用自然語言描述。所以我們需要一個檢索模塊把用戶描述映射到商品。最輕量的方式是關鍵詞匹配數據量大了之后換成向量檢索。文件路徑retriever.py。# 文件路徑retriever.py import json class ProductRetriever: 基于關鍵詞匹配的商品檢索器。 生產環境建議替換為向量檢索 關鍵詞檢索的混合方案。 def __init__(self, products_path: str products.json): with open(products_path, r, encodingutf-8) as f: self.products json.load(f) def search(self, query: str, max_price: float None): 根據查詢詞和價格上限檢索商品。 query 支持中英葡多語言關鍵詞匹配商品名稱、分類和關鍵詞字段。 query_lower query.lower() results [] for p in self.products: # 將商品所有可搜索字段拼成一個文本塊 searchable_text .join([ p[name].lower(), p[category].lower(), .join([k.lower() for k in p[keywords]]) ]) # 簡單匹配查詢詞中的每個詞只要出現在可搜索文本中即命中 query_terms [term for term in query_lower.split() if len(term) 1] if all(term in searchable_text for term in query_terms): results.append(p) if max_price is not None: results [p for p in results if p[price] max_price] return results這個檢索器用all()保證查詢詞全部命中避免“只要是酒就行”和“我要波特酒”混在一起。它的問題是詞序無關、不做語義匹配但作為最小示例已經足夠。生產環境建議的做法是用向量模型把用戶查詢和商品描述編碼成向量通過向量相似度召回候選再結合價格、品類等結構化條件過濾。5.4 LLM Agent 與工具調用現在到了最核心的部分讓 LLM 根據用戶意圖調用工具。我們使用 OpenAI 兼容的 Function Calling 接口。文件路徑tools.py和agent.py。先定義工具描述。這些描述會傳給 LLM模型根據描述決定調用哪個工具。文件路徑tools.py。# 文件路徑tools.py import json from retriever import ProductRetriever retriever ProductRetriever(products.json) TOOLS [ { type: function, function: { name: search_products, description: 根據用戶描述檢索商品。支持按關鍵詞、品類、最高價格篩選。, parameters: { type: object, properties: { query: { type: string, description: 用戶描述的商品關鍵詞例如波特酒、軟木杯墊、vinho do Porto }, max_price: { type: number, description: 最高價格歐元用戶提到預算時使用 } }, required: [query] } } }, { type: function, function: { name: add_to_cart, description: 將指定商品加入購物車。需要提供商品 ID 和數量。, parameters: { type: object, properties: { product_id: { type: string, description: 商品唯一 ID例如 P001 }, quantity: { type: integer, description: 購買數量默認 1 } }, required: [product_id] } } }, { type: function, function: { name: view_cart, description: 查看當前購物車內容和總價。, parameters: { type: object, properties: {} } } } ] def execute_tool(name: str, arguments: dict): 執行工具返回給 LLM 的結果。 if name search_products: results retriever.search( queryarguments.get(query, ), max_pricearguments.get(max_price) ) return json.dumps({products: results}, ensure_asciiFalse) if name add_to_cart: product_id arguments[product_id] quantity arguments.get(quantity, 1) # 調用 FastAPI 購物車服務 import requests resp requests.post( http://localhost:8000/cart/items, json{product_id: product_id, quantity: quantity} ) resp.raise_for_status() return json.dumps(resp.json(), ensure_asciiFalse) if name view_cart: import requests resp requests.get(http://localhost:8000/cart) resp.raise_for_status() return json.dumps(resp.json(), ensure_asciiFalse) raise ValueError(fUnknown tool: {name})這里我直接用requests調用本地 FastAPI 服務讓 Agent 和購物車服務解耦。生產環境通常不會讓 Agent 進程直接調 HTTP可以換成內部 RPC 或者直接注入服務層對象。但 HTTP 調用的好處是邊界清晰本地開發調試也方便。然后是 Agent 主邏輯。文件路徑agent.py。# 文件路徑agent.py import json from openai import OpenAI from tools import TOOLS, execute_tool client OpenAI( base_urlhttps://api.openai.com/v1, # 當地或其他兼容服務按需替換 api_keyYOUR_API_KEY # 請使用環境變量注入 ) SYSTEM_PROMPT 你是一個面向葡萄牙市場的電商購物助手。 你可以幫助用戶搜索商品、查看購物車、把商品加入購物車。 你不處理支付支付由用戶在網頁上完成。 當用戶要求加購時必須使用 add_to_cart 工具。 回復用戶時使用簡潔友好的語氣并給出商品名稱、價格和購物車總價。 def run_agent(user_message: str, historyNone): 運行 Agent處理用戶消息并返回最終回復。 messages [{role: system, content: SYSTEM_PROMPT}] if history: messages.extend(history) messages.append({role: user, content: user_message}) # 最多循環 5 次防止工具調用死循環 for _ in range(5): response client.chat.completions.create( modelgpt-4o-mini, # 按實際可用模型替換 messagesmessages, toolsTOOLS, tool_choiceauto, ) msg response.choices[0].message # 沒有工具調用直接返回 LLM 的文本回復 if not msg.tool_calls: return msg.content # 有工具調用先把助手消息加入對話歷史 messages.append(msg) # 依次執行每個工具調用并把結果加入對話歷史 for tool_call in msg.tool_calls: tool_name tool_call.function.name tool_args json.loads(tool_call.function.arguments) print(f[Agent] 調用工具: {tool_name}, 參數: {tool_args}) result execute_tool(tool_name, tool_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) return 抱歉操作次數過多請重試。 if __name__ __main__: # 簡單命令行測試 history [] while True: user_input input(你: ) if user_input.lower() in (quit, exit): break reply run_agent(user_input, history) print(f助手: {reply}) history.append({role: user, content: user_input}) history.append({role: assistant, content: reply})這段代碼的循環邏輯值得仔細看每次把用戶消息發給 LLM附帶工具定義。如果 LLM 返回tool_calls說明它想調用工具。執行工具后把工具結果以roletool的消息回傳給 LLM。LLM 基于工具結果生成用戶可讀的最終回復。這個“多輪工具調用”的循環是 LLM Agent 的核心模式。它允許模型根據需要連續調用多個工具比如先搜索商品再查看購物車再決定加購。5.5 配置文件與依賴最后是配置和依賴文件。文件路徑config.py。# 文件路徑config.py import os # LLM API 配置推薦用環境變量注入不要硬編碼 LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini) # 購物車服務地址 CART_SERVICE_URL os.getenv(CART_SERVICE_URL, http://localhost:8000)文件路徑requirements.txt。fastapi0.115.0 uvicorn0.30.6 openai1.40.0 requests2.32.3 pydantic2.8.2注意版本號僅供參考請以實際環境可用的版本為準。如果模型 API 不支持 OpenAI 兼容協議你需要換成對應廠商的 SDK但整體邏輯不變。6. 運行結果與效果驗證代碼寫完之后按下面的順序啟動和驗證。6.1 啟動購物車服務pip install -r requirements.txt python app.py看到類似輸出說明服務啟動成功INFO: Uvicorn running on http://0.0.0.0:8000先手動驗證購物車 APIcurl -X POST http://localhost:8000/cart/items \ -H Content-Type: application/json \ -d {product_id: P001, quantity: 1}預期返回{ items: [ { product_id: P001, name: Classic Cork Coasters (4 pcs), price: 12.0, quantity: 1, subtotal: 12.0 } ], total: 12.0 }這一步驗證的是業務鏈路本身。如果購物車 API 有問題先在這里修好再往上接 LLM。6.2 啟動 Agent 并測試對話在另一個終端運行python agent.py然后輸入你: 我想買一瓶30歐元以內的波特酒送人如果一切正常你應該看到類似日志[Agent] 調用工具: search_products, 參數: {query: 波特酒, max_price: 30} 助手: 為您找到一款符合預算的波特酒Port Wine Ruby Reserve 750ml價格 22 歐元。需要我幫您加入購物車嗎繼續輸入你: 加購物車吧預期日志[Agent] 調用工具: add_to_cart, 參數: {product_id: P003, quantity: 1} 助手: 已將 Port Wine Ruby Reserve 750ml22 歐元加入購物車。當前購物車共 1 件商品合計 22 歐元。6.3 如何判斷是否成功一個功能完整的 LLM 購物助手應該滿足以下四條驗收標準意圖識別準確用戶說“30 歐元以內的波特酒”模型能正確設置max_price30和query波特酒/vinho。工具調用正確加購操作使用add_to_cart而不是模型編造的 SQL 或假數據。業務校驗生效如果用戶要加購一個不存在的商品 ID購物車服務返回 404Agent 能把這個錯誤轉化成友好提示。多語言可用分別用中文、英語、葡萄牙語測試同一需求模型都能理解。6.4 失敗時的第一排查方向如果 Agent 不調用工具而是直接生成文本回答先檢查三點模型是否支持 Function Calling不是所有模型都支持確認你用的模型和接口版本。工具描述是否清晰description寫得不清楚模型就不知道該在什么情況下調用。消息格式是否規范尤其注意tool_call_id必須與模型返回的一致否則接口會報錯。如果是模型調用了工具但報錯先看execute_tool里的異常信息再檢查購物車服務是否在運行、商品 ID 是否真實存在。7. 常見問題與排查思路把我在類似項目里踩過和見過的坑整理成一張排查表問題現象可能原因排查方式解決方案模型不調用工具只輸出文字模型不支持 Function Calling或工具描述不清晰查看模型文檔確認功能支持打印 tools 參數檢查描述換支持 Function Calling 的模型重寫工具 description明確“什么情況下調用”工具調用后報tool_call_id錯誤消息記錄中 assistant 消息與 tool 消息未正確配對檢查 messages 列表中 tool 消息的tool_call_id是否與 assistant 返回一致嚴格按照 OpenAI 協議先追加 assistant 消息再逐條追加 tool 消息加購時提示商品不存在商品 ID 是模型編造的或商品已下架查看 Agent 日志中add_to_cart的參數手動調用/products/{id}驗證在工具描述中強調“必須使用 search_products 返回的商品 ID”商品下架時返回友好提示用戶說葡萄牙語檢索不到商品商品索引缺少葡語關鍵詞檢查products.json的keywords字段補充多語言關鍵詞或者接入翻譯 向量檢索購物車數量不對加購接口重復被調用查看 Agent 循環日志確認是否多次執行同一個工具在 Agent 循環中增加去重邏輯購物車服務做冪等控制一次對話中工具循環次數過多模型反復調用工具但沒有收斂打印每次工具調用的參數和結果限制最大循環次數本文為 5 次檢查工具執行結果是否足夠明確生產環境模型返回不穩定沒有用溫度參數控制輸出在 API 請求中設置temperature0或較低值對需要工具調用的請求建議temperature0減少隨機性購物車數據丟失使用了內存存儲重啟服務后 CART 被清空生產環境換 Redis、MySQL 等持久化存儲這里要特別強調一個問題模型編造商品 ID。這在不做檢索直接讓模型生成加購參數時尤其常見。預防辦法是工具描述里明確寫“product_id 必須來自 search_products 的結果”同時購物車服務側必須校驗商品是否存在。雙保險缺一不可。另一個容易被忽視的問題是重復加購。用戶說“把剛才那瓶酒加購物車”Agent 可能因為上下文理解不準確連續調兩次add_to_cart導致數量翻倍。工程上可以從兩方面兜底一是在 Agent 循環里維護已執行工具的去重集合二是購物車服務支持“同商品合并數量”并對前端展示明確提示。8. 最佳實踐與工程建議到這里最小鏈路已經跑通了。但真要上生產環境還有很多工程細節值得打磨。下面按優先級排列。8.1 安全與權限邊界LLM Agent 能操作購物車就意味著它擁有部分用戶權限。這里有一個不可逾越的原則Agent 代表用戶操作但必須經過用戶確認且不能越過權限邊界。具體落地建議加購操作先返回給用戶確認用戶確認后再執行。可以在 Agent 的add_to_cart工具前增加一個confirm_add_to_cart的中間步驟。會話必須綁定用戶身份。購物車不能是全局共享的每個用戶一個購物車Agent 調用購物車 API 時帶上用戶 Token。價格、庫存等關鍵數據以服務端為準不能相信 LLM 從對話歷史里記住的數字。用戶說“剛才不是 18 歐元嗎”時助手應該重新查商品接口確認。涉及支付、退款、修改收貨地址等高危操作不要交給 LLM Agent。購物車以下就是邊界。8.2 參數校驗與冪等模型生成參數是有概率出錯的所以業務服務必須當作“外部不可信輸入”來對待quantity必須校驗為正整數且不能超過庫存。product_id必須存在且商品處于上架狀態。加購接口最好支持冪等鍵。用戶點擊兩次“加購”不能加兩次。可以在請求里帶request_id服務端記錄已處理過的請求重復請求直接返回原結果。8.3 工具設計粒度要合適工具的粒度直接影響 Agent 的穩定性和業務安全。我的經驗是查詢類工具可以給模型較大自由度比如search_products允許組合多種篩選條件。寫入類工具要給最小權限參數盡量少并且強制校驗。比如add_to_cart只接受商品 ID 和數量不接受價格、折扣這類模型不該決定的字段。工具數量不要太多。一兩百個工具會讓模型選擇困難建議按業務域分組或者做一個“工具路由層”先粗篩再精調。8.4 可觀測性與日志Agent 的每次工具調用都應該有完整日志包括用戶原始輸入。LLM 返回的工具調用名稱和參數。工具執行結果。最終返回給用戶的文本。按trace_id貫穿整條鏈路這樣線上出問題時可以快速定位是模型理解錯了、參數傳錯了還是業務服務報錯了。8.5 RAG 與商品檢索的工程化本文用了關鍵詞匹配但真實商品庫動輒幾十萬 SKU需要更可靠的檢索方案。推薦分層架構召回層向量檢索商品名、描述、關鍵詞的 embedding召回 Top 50 候選。精排層用價格、品類、庫存、用戶偏好等結構化條件過濾和排序。兜底層如果召回為空觸發“相似品類推薦”或“向用戶說明庫存情況”而不是讓模型自由發揮。不要指望一個檢索函數解決所有問題。檢索質量直接決定 Agent 的體驗上限。8.6 多語言與本地化面向葡萄牙市場的應用語言本地化不是一句“模型支持多語言”就完了。要做的功課包括商品數據要有en、pt等語言字段或者至少保證keywords覆蓋主要語言。用戶可見的商品名稱、單位、貨幣格式要本地化。葡萄牙本地化的價格格式是22,00 €而不是€22.00這些細節會影響用戶信任感。模型 Prompt 里可以要求助手默認使用用戶當前語言回復。多語言場景下最好顯式把用戶的語言偏好傳到 Prompt 里而不是指望模型自己判斷。8.7 從 Demo 到生產的完整清單最后給一張檢查清單幫你判斷自己的 LLM 購物應用是否達到生產標準檢查項Demo 階段生產要求購物車存儲內存字典Redis/MySQL 用戶維度隔離參數來源模型直接生成業務側強校驗 商品 ID 來自檢索結果加購確認無用戶確認后再寫購物車權限控制無用戶 Token 綁定 操作審計日志無全鏈路 trace_id 日志模型選擇單一模型按場景區分對話模型、檢索模型、意圖識別小模型兜底策略無工具調用失敗時給出引導文案并上報灰度發布無小流量灰度監控工具調用成功率和加購轉化率9. 總結與后續學習方向這篇文章的核心是把“LLM 對話”和“購物車操作”這兩件本來割裂的事通過四層架構串成了一條可落地的鏈路LLM 負責理解意圖工具層負責隔離和控制業務服務負責校驗和執行數據層負責支撐檢索和存儲。整套代碼跑通之后你對 LLM 應用的理解會上一個臺階你會發現真正讓 AI 從“聊天”走向“交易”的不是模型本身多聰明而是工程上怎么約束它、校驗它、審計它。購物車只是一個縮影同樣的模式可以遷移到工單系統、CRM、供應鏈等任何“需要 LLM 調用業務系統”的場景。如果繼續深入學習我建議按這個順序展開Function Calling 進階研究不同模型對工具調用的差異比如并行工具調用、流式輸出時的工具處理。RAG 工程化把關鍵詞檢索替換成向量檢索接入真實商品庫關注召回率和準確率。Agent 框架選型在 Spring AI、LangGraph、自研編排之間做選型。框架能幫你省時間但本文的核心鏈路邏輯不會變。生產安全重點學習權限模型、操作審計、模型輸出校驗和 fail-safe 設計。最后提醒一句不要在還沒有業務校驗的生產環境直接放 Agent 寫購物車。先用最小閉環驗證用戶接受度再逐步放開權限。購物車雖小但它是交易的第一步值得用最高標準對待。建議把本文的示例代碼 clone 下來自己跑一遍尤其是agent.py里那個工具調用循環親手改幾個參數你會比看十篇文章理解得更深。 LLM購物助手落地指南：從對話到購物車的架構與代碼實現
做 LLM 應用的人十有八九遇到過同一個尷尬對話、問答、文本總結都跑通了演示效果也很驚艷但一提到“下單”“加購”“支付”這種真實交易動作項目就卡住了。要么是模型只能在對話框里聊得熱鬧要么是業務系統根本不敢讓 AI 直接碰購物車。這個“從 LLM 到購物車”的距離恰恰是 LLM 應用從 Demo 走向生產力的關鍵一環。最近在一些電商出海項目里我一直在研究一個非常具體的場景用戶在聊天窗口里說“我想買一瓶 30 歐元以內的波特酒”LLM 能理解意圖、檢索商品、把東西加進購物車然后讓用戶確認結算。整個流程聽起來不復雜但真正實現時會碰到工具調用、商品檢索、數據一致性、權限安全等一系列問題。這篇文章就圍繞一個虛構但很典型的葡萄牙電商場景完整拆解從 LLM 對話到購物車操作的架構鏈路、核心代碼和工程落地要點。讀完你可以自己復現一個最小可用的“LLM 購物助手”也知道下一步往生產環境走時該注意哪些坑。1. 這篇文章真正要解決的問題先說清楚為什么“LLM 到購物車”值得單獨寫一篇文章市面上講 LLM Agent、RAG、MCP 的文章已經很多但大多停留在一個層面——讓模型“會說話”或者“會查資料”。而購物車屬于交易鏈路它對準確性和安全性要求完全不一樣。想象一個葡萄牙電商平臺的場景。用戶在聊天窗里用葡萄牙語說“Preciso de um vinho do Porto até 30 euros para oferecer.”我需要一瓶 30 歐元以內的波特酒送人。如果只是讓 LLM 回復一句“好的我幫您找找”那這個應用毫無價值。用戶真正需要的是模型理解意圖 → 從商品庫中找到符合條件的波特酒 → 把商品加入購物車 → 返回購物車摘要給用戶確認。每一步都必須可執行、可驗證、可回滾。所以這篇文章要解決的核心問題是LLM 如何安全地調用業務系統不是讓模型直接寫數據庫而是通過受控的工具Tool/Function Calling操作購物車 API。商品知識怎么給到模型商品信息經常變化不可能全部塞進 Prompt需要 RAG 或結構化檢索兜底。多輪對話中的狀態管理用戶可能先問產品再問價格最后才說“加入購物車”Agent 怎么記住上下文。生產環境的安全邊界模型輸出不可控購物車操作必須做參數校驗、冪等和權限控制。這篇文章適合正在做 LLM 應用開發、想讓 AI 真正觸達業務交易的讀者也適合對電商系統接 AI Agent 感興趣的架構師。如果你只是寫對話機器人這篇文章可能偏工程化如果你想做 AI 導購、智能客服、Agent 購物助手那這篇文章正好踩在你的需求點上。2. LLM 到購物車核心鏈路與架構判斷從架構上看“LLM 到購物車”不是一條直線而是四層協作。我習慣把它拆成下面這張邏輯鏈路用戶消息 ↓ LLM 對話層意圖理解、多輪上下文 ↓ Agent 工具層Function Calling、工具選擇、參數提取 ↓ 業務服務層商品檢索、購物車 API、訂單服務 ↓ 數據層商品庫、向量索引、購物車存儲每一層干的事情完全不同想清楚之后再動手才不會把自己繞暈。第一層LLM 對話層。這一層負責理解用戶說了什么。它不做業務操作只負責把用戶的自然語言轉換成結構化意圖。比如“我要一瓶 30 歐元以內的波特酒”在這一層會被理解成用戶想買酒、有價格上限、是波特酒品類。這一層的輸出是“意圖 關鍵參數”不是 SQL也不是購物車操作。第二層Agent 工具層。這一層是 LLM 和業務系統之間的“隔離帶”。LLM 不直接訪問數據庫或購物車而是從預定義的工具列表中選擇合適的工具。比如search_products、add_to_cart、view_cart。LLM 要做的是給工具填參數真正執行交給業務服務。這個設計背后的原因是模型輸出天然不穩定必須用代碼約束模型能做的事情。第三層業務服務層。這里就是傳統后端開發的地盤。商品檢索服務查數據庫或向量庫購物車服務執行加購操作。這一層要做參數校驗、權限校驗、冪等控制它是整個鏈路的安全底線。第四層數據層。商品結構化數據、向量索引、購物車存儲。對購物車來說數據一致性很關鍵比如庫存不足時不能加購商品下架時要從購物車移除。這個架構的直觀類比是LLM 像一個聰明的導購員它很會說話但不能直接碰收銀臺。它把用戶的需求轉達給收銀員業務服務收銀員確認商品、價格、庫存之后才會真正把東西放進購物車。有一個常見誤區要提前說很多人以為讓 LLM 直接調數據庫、直接執行 SQL 就是“LLM 到購物車”。這在 Demo 里能跑但生產環境絕對不能這么做。模型生成的 SQL 一旦出錯輕則查詢失敗重則誤操作數據。更穩妥的做法是LLM 只負責“意圖理解 參數提取”SQL 和寫操作全部由固定代碼完成。工具層就是這層保護網。3. 場景設計與環境準備3.1 場景定義葡萄牙電商購物助手為了把文章講具體我們定義一個可復現的場景。假設我們要為一個面向葡萄牙市場的電商平臺做一個 AI 購物助手支持以下能力用戶可以用英語或葡萄牙語描述購物需求。助手能檢索商品目錄支持按品類、價格區間、關鍵詞篩選。助手能查看當前購物車內容。助手能把符合條件的商品加入購物車。助手不處理支付支付環節由用戶在前端完成。商品數據我們用一個 JSON 文件模擬包含葡萄牙特色商品波特酒Port Wine、葡萄牙陶瓷瓷磚Azulejos、軟木制品Cork Products、橄欖油Olive Oil等。3.2 技術選型與環境要求本文示例使用 Python 生態核心組件如下組件用途版本建議Python編程語言3.10FastAPI購物車服務0.100openai 或兼容 SDK調用 LLM以官方最新版為準本地或云端 LLM對話與工具調用支持 Function Calling 即可內存數據結構模擬商品庫和購物車無額外依賴重點說明一下 LLM 的選擇。如果你使用 OpenAI 兼容接口包括各類國產大模型、本地部署模型只要模型支持 Function Calling / Tool Calling就可以跑通本文示例。如果沒有合適的 API也可以在開發階段直接用一個模擬的“假 LLM”返回固定意圖來調試購物車鏈路。后者我建議你至少做一次因為把業務鏈路跑通和調模型是兩件事。3.3 項目結構我們按下面的目錄組織代碼llm-shopping-cart/ ├── app.py # FastAPI 入口購物車 API ├── products.json # 商品數據 ├── agent.py # LLM Agent 入口工具調用邏輯 ├── tools.py # 工具定義商品檢索、加購、購物車查詢 ├── retriever.py # 商品檢索模塊含簡單 RAG 檢索 ├── config.py # 配置文件 └── requirements.txt # 依賴清單這個結構足夠小適合學習和二次開發。實際項目可以把服務拆成product-service和cart-service但原理一致。4. 核心流程拆解從用戶消息到加購完成在寫代碼之前我們先完整走一遍流程搞清楚每個環節的職責。4.1 完整交互時序一次完整的“LLM 購物”交互可以拆成五個步驟第一步用戶發送消息。用戶在聊天窗口輸入自然語言需求比如“我想買一箱葡萄牙軟木杯墊預算 20 歐元以內。”第二步LLM 理解意圖并選擇工具。系統把用戶消息和歷史對話一起發給 LLM同時告訴它有哪些工具可用。LLM 判斷這一步需要通過search_products工具查商品于是返回一個結構化的工具調用請求包含參數query軟木杯墊,max_price20。第三步業務服務執行工具。我們的代碼收到工具調用請求后執行search_products從商品庫中檢索出符合條件的商品列表。第四步LLM 生成回復并確認加購。商品列表返回給 LLMLLM 組織語言告訴用戶“為您找到兩款軟木杯墊分別是 12 歐元和 18 歐元您想加入購物車嗎”用戶回復“加第一款吧”。這一次 LLM 調用add_to_cart工具參數是商品 ID 和數量。第五步購物車服務執行加購并返回結果。購物車服務校驗商品存在、庫存充足然后執行加購操作返回購物車最新內容。LLM 最后向用戶確認“已經將‘經典軟木杯墊 4 件裝’加入購物車當前購物車有 1 件商品合計 12 歐元。”4.2 每步的關鍵判斷這個流程最核心的架構判斷是LLM 不直接返回購物車操作是否成功的最終結果而是返回“我打算調用哪個工具、參數是什么”由代碼執行并校驗。這樣做有三個好處可控性即使 LLM 生成了錯誤的參數業務服務可以拒絕執行。可審計每次工具調用都可以記錄日志方便回溯。可回滾加購操作是冪等的用戶取消時可以直接刪除購物車條目。4.3 多輪對話的狀態處理購物場景天然是多輪的。用戶可能在同一次會話中先搜索、再比價、再改變主意。Agent 需要維護對話歷史。最簡單的方案是把歷史消息逐條發給 LLM由 LLM 自行理解上下文。復雜方案是引入記憶模塊把用戶偏好比如“喜歡 30 歐元以下的酒”存起來后續對話直接使用。文章示例采用第一種方案代碼實現最直接也足夠支撐演示場景。4.4 語言問題葡萄牙語與英語混合面向葡萄牙市場的應用需要處理葡英混合輸入。LLM 本身有多語言能力這個不用我們額外做太多工作。真正的挑戰在商品檢索用戶用葡萄牙語描述需求但商品名稱可能是英語或葡萄牙語。解決方案是檢索時同時匹配多語言關鍵詞或者對商品名稱做翻譯索引。5. 完整示例代碼實現下面我們逐步實現整個鏈路。先從購物車服務開始再寫商品檢索最后把 LLM Agent 接上。5.1 商品數據先準備一份模擬商品數據。文件路徑products.json。[ { id: P001, name: Classic Cork Coasters (4 pcs), category: cork, price: 12.0, currency: EUR, stock: 50, keywords: [cork, coaster, 軟木, 杯墊] }, { id: P002, name: Premium Cork Coasters (6 pcs), category: cork, price: 18.0, currency: EUR, stock: 30, keywords: [cork, coaster, premium, 軟木, 杯墊] }, { id: P003, name: Port Wine Ruby Reserve 750ml, category: wine, price: 22.0, currency: EUR, stock: 100, keywords: [port, wine, vinho, 波特酒] }, { id: P004, name: Port Wine Tawny 10 Years 750ml, category: wine, price: 35.0, currency: EUR, stock: 40, keywords: [port, wine, tawny, vinho, 波特酒] }, { id: P005, name: Portuguese Azulejo Tile Decoration, category: ceramic, price: 15.0, currency: EUR, stock: 20, keywords: [azulejo, tile, ceramic, 瓷磚] }, { id: P006, name: Extra Virgin Olive Oil 500ml, category: food, price: 9.5, currency: EUR, stock: 200, keywords: [olive, oil, azeite, 橄欖油] } ]這里的keywords字段是多語言檢索的關鍵。用戶說葡萄牙語“vinho do Porto”我們匹配keywords里的vinho和port就能找到對應的波特酒。5.2 購物車服務用 FastAPI 寫一個最小購物車服務。文件路徑app.py。# 文件路徑app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import Dict, List import json app FastAPI(titleLLM Shopping Cart Service) # 模擬商品庫實際項目請替換為數據庫 with open(products.json, r, encodingutf-8) as f: PRODUCTS json.load(f) # 模擬購物車key商品IDvalue數量 # 實際項目請替換為 Redis 或數據庫存儲 CART: Dict[str, int] {} class AddItemRequest(BaseModel): product_id: str quantity: int 1 class CartItem(BaseModel): product_id: str name: str price: float quantity: int subtotal: float app.get(/products) def list_products(category: str None, max_price: float None): 商品檢索接口支持按品類和價格過濾。 result PRODUCTS if category: result [p for p in result if p[category] category] if max_price is not None: result [p for p in result if p[price] max_price] return {products: result} app.get(/products/{product_id}) def get_product(product_id: str): 按 ID 查詢單個商品。 for p in PRODUCTS: if p[id] product_id: return p raise HTTPException(status_code404, detailProduct not found) app.post(/cart/items) def add_to_cart(req: AddItemRequest): 加入購物車帶庫存和商品存在性校驗。 product next((p for p in PRODUCTS if p[id] req.product_id), None) if product is None: raise HTTPException(status_code404, detailProduct not found) if req.quantity 0: raise HTTPException(status_code400, detailQuantity must be positive) if req.quantity product[stock]: raise HTTPException(status_code400, detailInsufficient stock) CART[req.product_id] CART.get(req.product_id, 0) req.quantity return get_cart() app.get(/cart) def get_cart(): 查看購物車內容。 items: List[CartItem] [] total 0.0 for product_id, quantity in CART.items(): product next((p for p in PRODUCTS if p[id] product_id), None) if product is None: continue subtotal product[price] * quantity total subtotal items.append(CartItem( product_idproduct_id, nameproduct[name], priceproduct[price], quantityquantity, subtotalsubtotal )) return {items: items, total: round(total, 2)} app.delete(/cart/items/{product_id}) def remove_from_cart(product_id: str): 從購物車移除商品用于用戶取消或回滾。 if product_id in CART: del CART[product_id] return get_cart() if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)這段代碼的關鍵點有三個參數校驗前置加購前檢查商品存在性和庫存避免把無效商品寫進購物車。購物車返回結構統一無論加購、查看還是刪除都返回同樣的結構方便 LLM 解讀。內存存儲僅用于演示CART字典重啟即丟失。生產環境替換為 Redis 或數據庫時接口簽名可以保持不變。5.3 商品檢索模塊購物場景里用戶很少直接說商品 ID更多是用自然語言描述。所以我們需要一個檢索模塊把用戶描述映射到商品。最輕量的方式是關鍵詞匹配數據量大了之后換成向量檢索。文件路徑retriever.py。# 文件路徑retriever.py import json class ProductRetriever: 基于關鍵詞匹配的商品檢索器。 生產環境建議替換為向量檢索 關鍵詞檢索的混合方案。 def __init__(self, products_path: str products.json): with open(products_path, r, encodingutf-8) as f: self.products json.load(f) def search(self, query: str, max_price: float None): 根據查詢詞和價格上限檢索商品。 query 支持中英葡多語言關鍵詞匹配商品名稱、分類和關鍵詞字段。 query_lower query.lower() results [] for p in self.products: # 將商品所有可搜索字段拼成一個文本塊 searchable_text .join([ p[name].lower(), p[category].lower(), .join([k.lower() for k in p[keywords]]) ]) # 簡單匹配查詢詞中的每個詞只要出現在可搜索文本中即命中 query_terms [term for term in query_lower.split() if len(term) 1] if all(term in searchable_text for term in query_terms): results.append(p) if max_price is not None: results [p for p in results if p[price] max_price] return results這個檢索器用all()保證查詢詞全部命中避免“只要是酒就行”和“我要波特酒”混在一起。它的問題是詞序無關、不做語義匹配但作為最小示例已經足夠。生產環境建議的做法是用向量模型把用戶查詢和商品描述編碼成向量通過向量相似度召回候選再結合價格、品類等結構化條件過濾。5.4 LLM Agent 與工具調用現在到了最核心的部分讓 LLM 根據用戶意圖調用工具。我們使用 OpenAI 兼容的 Function Calling 接口。文件路徑tools.py和agent.py。先定義工具描述。這些描述會傳給 LLM模型根據描述決定調用哪個工具。文件路徑tools.py。# 文件路徑tools.py import json from retriever import ProductRetriever retriever ProductRetriever(products.json) TOOLS [ { type: function, function: { name: search_products, description: 根據用戶描述檢索商品。支持按關鍵詞、品類、最高價格篩選。, parameters: { type: object, properties: { query: { type: string, description: 用戶描述的商品關鍵詞例如波特酒、軟木杯墊、vinho do Porto }, max_price: { type: number, description: 最高價格歐元用戶提到預算時使用 } }, required: [query] } } }, { type: function, function: { name: add_to_cart, description: 將指定商品加入購物車。需要提供商品 ID 和數量。, parameters: { type: object, properties: { product_id: { type: string, description: 商品唯一 ID例如 P001 }, quantity: { type: integer, description: 購買數量默認 1 } }, required: [product_id] } } }, { type: function, function: { name: view_cart, description: 查看當前購物車內容和總價。, parameters: { type: object, properties: {} } } } ] def execute_tool(name: str, arguments: dict): 執行工具返回給 LLM 的結果。 if name search_products: results retriever.search( queryarguments.get(query, ), max_pricearguments.get(max_price) ) return json.dumps({products: results}, ensure_asciiFalse) if name add_to_cart: product_id arguments[product_id] quantity arguments.get(quantity, 1) # 調用 FastAPI 購物車服務 import requests resp requests.post( http://localhost:8000/cart/items, json{product_id: product_id, quantity: quantity} ) resp.raise_for_status() return json.dumps(resp.json(), ensure_asciiFalse) if name view_cart: import requests resp requests.get(http://localhost:8000/cart) resp.raise_for_status() return json.dumps(resp.json(), ensure_asciiFalse) raise ValueError(fUnknown tool: {name})這里我直接用requests調用本地 FastAPI 服務讓 Agent 和購物車服務解耦。生產環境通常不會讓 Agent 進程直接調 HTTP可以換成內部 RPC 或者直接注入服務層對象。但 HTTP 調用的好處是邊界清晰本地開發調試也方便。然后是 Agent 主邏輯。文件路徑agent.py。# 文件路徑agent.py import json from openai import OpenAI from tools import TOOLS, execute_tool client OpenAI( base_urlhttps://api.openai.com/v1, # 當地或其他兼容服務按需替換 api_keyYOUR_API_KEY # 請使用環境變量注入 ) SYSTEM_PROMPT 你是一個面向葡萄牙市場的電商購物助手。 你可以幫助用戶搜索商品、查看購物車、把商品加入購物車。 你不處理支付支付由用戶在網頁上完成。 當用戶要求加購時必須使用 add_to_cart 工具。 回復用戶時使用簡潔友好的語氣并給出商品名稱、價格和購物車總價。 def run_agent(user_message: str, historyNone): 運行 Agent處理用戶消息并返回最終回復。 messages [{role: system, content: SYSTEM_PROMPT}] if history: messages.extend(history) messages.append({role: user, content: user_message}) # 最多循環 5 次防止工具調用死循環 for _ in range(5): response client.chat.completions.create( modelgpt-4o-mini, # 按實際可用模型替換 messagesmessages, toolsTOOLS, tool_choiceauto, ) msg response.choices[0].message # 沒有工具調用直接返回 LLM 的文本回復 if not msg.tool_calls: return msg.content # 有工具調用先把助手消息加入對話歷史 messages.append(msg) # 依次執行每個工具調用并把結果加入對話歷史 for tool_call in msg.tool_calls: tool_name tool_call.function.name tool_args json.loads(tool_call.function.arguments) print(f[Agent] 調用工具: {tool_name}, 參數: {tool_args}) result execute_tool(tool_name, tool_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) return 抱歉操作次數過多請重試。 if __name__ __main__: # 簡單命令行測試 history [] while True: user_input input(你: ) if user_input.lower() in (quit, exit): break reply run_agent(user_input, history) print(f助手: {reply}) history.append({role: user, content: user_input}) history.append({role: assistant, content: reply})這段代碼的循環邏輯值得仔細看每次把用戶消息發給 LLM附帶工具定義。如果 LLM 返回tool_calls說明它想調用工具。執行工具后把工具結果以roletool的消息回傳給 LLM。LLM 基于工具結果生成用戶可讀的最終回復。這個“多輪工具調用”的循環是 LLM Agent 的核心模式。它允許模型根據需要連續調用多個工具比如先搜索商品再查看購物車再決定加購。5.5 配置文件與依賴最后是配置和依賴文件。文件路徑config.py。# 文件路徑config.py import os # LLM API 配置推薦用環境變量注入不要硬編碼 LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini) # 購物車服務地址 CART_SERVICE_URL os.getenv(CART_SERVICE_URL, http://localhost:8000)文件路徑requirements.txt。fastapi0.115.0 uvicorn0.30.6 openai1.40.0 requests2.32.3 pydantic2.8.2注意版本號僅供參考請以實際環境可用的版本為準。如果模型 API 不支持 OpenAI 兼容協議你需要換成對應廠商的 SDK但整體邏輯不變。6. 運行結果與效果驗證代碼寫完之后按下面的順序啟動和驗證。6.1 啟動購物車服務pip install -r requirements.txt python app.py看到類似輸出說明服務啟動成功INFO: Uvicorn running on http://0.0.0.0:8000先手動驗證購物車 APIcurl -X POST http://localhost:8000/cart/items \ -H Content-Type: application/json \ -d {product_id: P001, quantity: 1}預期返回{ items: [ { product_id: P001, name: Classic Cork Coasters (4 pcs), price: 12.0, quantity: 1, subtotal: 12.0 } ], total: 12.0 }這一步驗證的是業務鏈路本身。如果購物車 API 有問題先在這里修好再往上接 LLM。6.2 啟動 Agent 并測試對話在另一個終端運行python agent.py然后輸入你: 我想買一瓶30歐元以內的波特酒送人如果一切正常你應該看到類似日志[Agent] 調用工具: search_products, 參數: {query: 波特酒, max_price: 30} 助手: 為您找到一款符合預算的波特酒Port Wine Ruby Reserve 750ml價格 22 歐元。需要我幫您加入購物車嗎繼續輸入你: 加購物車吧預期日志[Agent] 調用工具: add_to_cart, 參數: {product_id: P003, quantity: 1} 助手: 已將 Port Wine Ruby Reserve 750ml22 歐元加入購物車。當前購物車共 1 件商品合計 22 歐元。6.3 如何判斷是否成功一個功能完整的 LLM 購物助手應該滿足以下四條驗收標準意圖識別準確用戶說“30 歐元以內的波特酒”模型能正確設置max_price30和query波特酒/vinho。工具調用正確加購操作使用add_to_cart而不是模型編造的 SQL 或假數據。業務校驗生效如果用戶要加購一個不存在的商品 ID購物車服務返回 404Agent 能把這個錯誤轉化成友好提示。多語言可用分別用中文、英語、葡萄牙語測試同一需求模型都能理解。6.4 失敗時的第一排查方向如果 Agent 不調用工具而是直接生成文本回答先檢查三點模型是否支持 Function Calling不是所有模型都支持確認你用的模型和接口版本。工具描述是否清晰description寫得不清楚模型就不知道該在什么情況下調用。消息格式是否規范尤其注意tool_call_id必須與模型返回的一致否則接口會報錯。如果是模型調用了工具但報錯先看execute_tool里的異常信息再檢查購物車服務是否在運行、商品 ID 是否真實存在。7. 常見問題與排查思路把我在類似項目里踩過和見過的坑整理成一張排查表問題現象可能原因排查方式解決方案模型不調用工具只輸出文字模型不支持 Function Calling或工具描述不清晰查看模型文檔確認功能支持打印 tools 參數檢查描述換支持 Function Calling 的模型重寫工具 description明確“什么情況下調用”工具調用后報tool_call_id錯誤消息記錄中 assistant 消息與 tool 消息未正確配對檢查 messages 列表中 tool 消息的tool_call_id是否與 assistant 返回一致嚴格按照 OpenAI 協議先追加 assistant 消息再逐條追加 tool 消息加購時提示商品不存在商品 ID 是模型編造的或商品已下架查看 Agent 日志中add_to_cart的參數手動調用/products/{id}驗證在工具描述中強調“必須使用 search_products 返回的商品 ID”商品下架時返回友好提示用戶說葡萄牙語檢索不到商品商品索引缺少葡語關鍵詞檢查products.json的keywords字段補充多語言關鍵詞或者接入翻譯 向量檢索購物車數量不對加購接口重復被調用查看 Agent 循環日志確認是否多次執行同一個工具在 Agent 循環中增加去重邏輯購物車服務做冪等控制一次對話中工具循環次數過多模型反復調用工具但沒有收斂打印每次工具調用的參數和結果限制最大循環次數本文為 5 次檢查工具執行結果是否足夠明確生產環境模型返回不穩定沒有用溫度參數控制輸出在 API 請求中設置temperature0或較低值對需要工具調用的請求建議temperature0減少隨機性購物車數據丟失使用了內存存儲重啟服務后 CART 被清空生產環境換 Redis、MySQL 等持久化存儲這里要特別強調一個問題模型編造商品 ID。這在不做檢索直接讓模型生成加購參數時尤其常見。預防辦法是工具描述里明確寫“product_id 必須來自 search_products 的結果”同時購物車服務側必須校驗商品是否存在。雙保險缺一不可。另一個容易被忽視的問題是重復加購。用戶說“把剛才那瓶酒加購物車”Agent 可能因為上下文理解不準確連續調兩次add_to_cart導致數量翻倍。工程上可以從兩方面兜底一是在 Agent 循環里維護已執行工具的去重集合二是購物車服務支持“同商品合并數量”并對前端展示明確提示。8. 最佳實踐與工程建議到這里最小鏈路已經跑通了。但真要上生產環境還有很多工程細節值得打磨。下面按優先級排列。8.1 安全與權限邊界LLM Agent 能操作購物車就意味著它擁有部分用戶權限。這里有一個不可逾越的原則Agent 代表用戶操作但必須經過用戶確認且不能越過權限邊界。具體落地建議加購操作先返回給用戶確認用戶確認后再執行。可以在 Agent 的add_to_cart工具前增加一個confirm_add_to_cart的中間步驟。會話必須綁定用戶身份。購物車不能是全局共享的每個用戶一個購物車Agent 調用購物車 API 時帶上用戶 Token。價格、庫存等關鍵數據以服務端為準不能相信 LLM 從對話歷史里記住的數字。用戶說“剛才不是 18 歐元嗎”時助手應該重新查商品接口確認。涉及支付、退款、修改收貨地址等高危操作不要交給 LLM Agent。購物車以下就是邊界。8.2 參數校驗與冪等模型生成參數是有概率出錯的所以業務服務必須當作“外部不可信輸入”來對待quantity必須校驗為正整數且不能超過庫存。product_id必須存在且商品處于上架狀態。加購接口最好支持冪等鍵。用戶點擊兩次“加購”不能加兩次。可以在請求里帶request_id服務端記錄已處理過的請求重復請求直接返回原結果。8.3 工具設計粒度要合適工具的粒度直接影響 Agent 的穩定性和業務安全。我的經驗是查詢類工具可以給模型較大自由度比如search_products允許組合多種篩選條件。寫入類工具要給最小權限參數盡量少并且強制校驗。比如add_to_cart只接受商品 ID 和數量不接受價格、折扣這類模型不該決定的字段。工具數量不要太多。一兩百個工具會讓模型選擇困難建議按業務域分組或者做一個“工具路由層”先粗篩再精調。8.4 可觀測性與日志Agent 的每次工具調用都應該有完整日志包括用戶原始輸入。LLM 返回的工具調用名稱和參數。工具執行結果。最終返回給用戶的文本。按trace_id貫穿整條鏈路這樣線上出問題時可以快速定位是模型理解錯了、參數傳錯了還是業務服務報錯了。8.5 RAG 與商品檢索的工程化本文用了關鍵詞匹配但真實商品庫動輒幾十萬 SKU需要更可靠的檢索方案。推薦分層架構召回層向量檢索商品名、描述、關鍵詞的 embedding召回 Top 50 候選。精排層用價格、品類、庫存、用戶偏好等結構化條件過濾和排序。兜底層如果召回為空觸發“相似品類推薦”或“向用戶說明庫存情況”而不是讓模型自由發揮。不要指望一個檢索函數解決所有問題。檢索質量直接決定 Agent 的體驗上限。8.6 多語言與本地化面向葡萄牙市場的應用語言本地化不是一句“模型支持多語言”就完了。要做的功課包括商品數據要有en、pt等語言字段或者至少保證keywords覆蓋主要語言。用戶可見的商品名稱、單位、貨幣格式要本地化。葡萄牙本地化的價格格式是22,00 €而不是€22.00這些細節會影響用戶信任感。模型 Prompt 里可以要求助手默認使用用戶當前語言回復。多語言場景下最好顯式把用戶的語言偏好傳到 Prompt 里而不是指望模型自己判斷。8.7 從 Demo 到生產的完整清單最后給一張檢查清單幫你判斷自己的 LLM 購物應用是否達到生產標準檢查項Demo 階段生產要求購物車存儲內存字典Redis/MySQL 用戶維度隔離參數來源模型直接生成業務側強校驗 商品 ID 來自檢索結果加購確認無用戶確認后再寫購物車權限控制無用戶 Token 綁定 操作審計日志無全鏈路 trace_id 日志模型選擇單一模型按場景區分對話模型、檢索模型、意圖識別小模型兜底策略無工具調用失敗時給出引導文案并上報灰度發布無小流量灰度監控工具調用成功率和加購轉化率9. 總結與后續學習方向這篇文章的核心是把“LLM 對話”和“購物車操作”這兩件本來割裂的事通過四層架構串成了一條可落地的鏈路LLM 負責理解意圖工具層負責隔離和控制業務服務負責校驗和執行數據層負責支撐檢索和存儲。整套代碼跑通之后你對 LLM 應用的理解會上一個臺階你會發現真正讓 AI 從“聊天”走向“交易”的不是模型本身多聰明而是工程上怎么約束它、校驗它、審計它。購物車只是一個縮影同樣的模式可以遷移到工單系統、CRM、供應鏈等任何“需要 LLM 調用業務系統”的場景。如果繼續深入學習我建議按這個順序展開Function Calling 進階研究不同模型對工具調用的差異比如并行工具調用、流式輸出時的工具處理。RAG 工程化把關鍵詞檢索替換成向量檢索接入真實商品庫關注召回率和準確率。Agent 框架選型在 Spring AI、LangGraph、自研編排之間做選型。框架能幫你省時間但本文的核心鏈路邏輯不會變。生產安全重點學習權限模型、操作審計、模型輸出校驗和 fail-safe 設計。最后提醒一句不要在還沒有業務校驗的生產環境直接放 Agent 寫購物車。先用最小閉環驗證用戶接受度再逐步放開權限。購物車雖小但它是交易的第一步值得用最高標準對待。建議把本文的示例代碼 clone 下來自己跑一遍尤其是agent.py里那個工具調用循環親手改幾個參數你會比看十篇文章理解得更深。