1. 這不是“又一個LangChain教程”而是一份能讓你在真實業(yè)務(wù)里跑通AI Agent的工程手冊我?guī)н^三支AI應(yīng)用落地團隊從金融風(fēng)控問答系統(tǒng)到制造業(yè)設(shè)備知識庫再到政務(wù)智能工單分派平臺踩過的坑比讀過的文檔還多。去年Q3開始我們徹底放棄“調(diào)通API就交差”的做法轉(zhuǎn)而用LangChainLangGraphRAG搭了一套能進生產(chǎn)環(huán)境的Agent框架——不是Demo是每天處理2700真實用戶請求、平均響應(yīng)延遲1.8秒、支持7×24小時無人值守的系統(tǒng)。很多人看到標(biāo)題里的“入門到實戰(zhàn)部署”就以為是基礎(chǔ)語法教學(xué)其實真正卡住90%工程師的從來不是chain怎么寫而是當(dāng)用戶問“上個月華東區(qū)A類客戶投訴率為什么突然上升”你的Agent得能自動拆解成“查CRM數(shù)據(jù)→拉取BI報表→比對歷史趨勢→定位異常時段→關(guān)聯(lián)客服錄音關(guān)鍵詞→生成歸因摘要”整個過程不崩、不丟上下文、不漏步驟、不超token限額。這背后涉及MCP協(xié)議對多工具調(diào)用的標(biāo)準(zhǔn)化約束、LangGraph狀態(tài)機對長流程的容錯設(shè)計、RAG知識庫對非結(jié)構(gòu)化文檔的語義切片策略以及模型微調(diào)對領(lǐng)域術(shù)語的精準(zhǔn)對齊。本文不講“什么是Node”只講“為什么這個Node必須加timeout30s”不列API參數(shù)表只說“當(dāng)你在K8s里部署時這個參數(shù)設(shè)成512會觸發(fā)OOM Killer”。所有內(nèi)容都來自我們壓測237次、迭代11個版本、重寫3次核心調(diào)度器后沉淀下來的實操細(xì)節(jié)。如果你正面臨“本地跑通了一上生產(chǎn)就超時”“RAG召回率還行但生成答案總跑偏”“Agent流程走一半就斷鏈”這類問題這篇就是為你寫的。2. 整體架構(gòu)設(shè)計為什么必須用LangGraph替代傳統(tǒng)Chain以及MCP協(xié)議如何解決工具調(diào)用混亂2.1 傳統(tǒng)Chain模式在復(fù)雜業(yè)務(wù)中的三大致命缺陷很多教程還在教SequentialChain或RouterChain這在單輪問答場景下確實夠用但一旦進入真實業(yè)務(wù)立刻暴露三個硬傷第一是狀態(tài)不可見。Chain本質(zhì)是函數(shù)式流水線每個step輸出直接喂給下一個step中間狀態(tài)完全黑盒。比如用戶問“對比A和B兩款產(chǎn)品的售后政策”Agent需要①查產(chǎn)品數(shù)據(jù)庫獲取A/B基礎(chǔ)信息②調(diào)用法律知識庫提取售后條款③執(zhí)行差異分析邏輯④生成對比表格。如果第③步因模型幻覺輸出錯誤結(jié)論你根本無法回溯是哪條數(shù)據(jù)導(dǎo)致偏差——因為Chain不保存中間產(chǎn)物只傳最終字符串。我們曾因此誤判某次故障是模型問題實際排查發(fā)現(xiàn)是數(shù)據(jù)庫字段類型變更導(dǎo)致JSON解析失敗但日志里只顯示“生成結(jié)果格式錯誤”。第二是錯誤不可恢復(fù)。Chain遇到異常默認(rèn)中斷沒有重試、降級或跳過機制。真實環(huán)境中外部API如CRM系統(tǒng)偶爾超時是常態(tài)按Chain設(shè)計就得整個流程失敗。我們上線初期每周平均17次因天氣預(yù)報接口超時導(dǎo)致工單分類失敗后來改成“超時后啟用本地緩存規(guī)則引擎兜底”這需要顯式的狀態(tài)分支控制Chain做不到。第三是擴展性為零。想給Agent加個“發(fā)送郵件通知”功能Chain要求你重構(gòu)整個pipeline把郵件節(jié)點硬塞進序列里。而業(yè)務(wù)需求是動態(tài)的銷售部今天要加釘釘提醒明天法務(wù)部要加合同條款校驗后天運維要加告警閾值判斷。每次改代碼都要全鏈路回歸測試上線周期從2小時拉長到3天。2.2 LangGraph用有向無環(huán)圖DAG重建Agent的“操作系統(tǒng)”LangGraph不是Chain的升級版而是換了一套底層范式——它把Agent看作一個狀態(tài)機驅(qū)動的分布式工作流。核心思想就一條所有操作都圍繞State對象展開每個Node節(jié)點接收State、執(zhí)行邏輯、返回更新后的State邊Edge定義State在Node間的流轉(zhuǎn)規(guī)則。我們實際采用的State結(jié)構(gòu)長這樣class AgentState(TypedDict): messages: Annotated[list, add_messages] # 存儲對話歷史支持自動合并 user_query: str # 原始用戶問題避免多次解析歧義 context_data: dict # 當(dāng)前已獲取的上下文CRM數(shù)據(jù)/知識庫片段等 tool_calls: list # 已發(fā)起的工具調(diào)用記錄含狀態(tài)pending/success/error execution_path: list # 當(dāng)前執(zhí)行路徑用于審計和debug max_retries: int 3 # 全局重試次數(shù)避免無限循環(huán)關(guān)鍵設(shè)計點在于Annotated[list, add_messages]——這是LangGraph的“消息累積器”它讓所有Node都能安全地往messages里追加內(nèi)容而不會覆蓋其他Node的輸出。比如“查CRM”Node添加一條{role:tool,content:{...}}分析差異Node再添加{role:assistant,content:...}最終messages自動合并成完整對話鏈。這解決了Chain中常見的“上一步輸出被下一步覆蓋”問題。2.3 MCP協(xié)議讓Agent調(diào)用工具像調(diào)用本地函數(shù)一樣可靠MCPModel Communication Protocol常被誤解為“另一個API協(xié)議”其實它是面向LLM的RPC規(guī)范。傳統(tǒng)方案讓模型自己拼接HTTP請求如curl -X POST https://api.crm.com/v1/customers -d {id:123}這帶來三大風(fēng)險模型可能拼錯URL、漏傳必要header、或把敏感token暴露在prompt里。MCP強制要求所有工具調(diào)用通過標(biāo)準(zhǔn)化的tool_call結(jié)構(gòu)聲明{ name: crm_get_customer, arguments: {customer_id: CUST-2023-789}, id: call_abc123 }Agent Runtime運行時收到這個結(jié)構(gòu)后才去匹配預(yù)注冊的工具實現(xiàn)。我們注冊CRM工具時這樣寫tool def crm_get_customer(customer_id: str) - dict: 從CRM系統(tǒng)獲取客戶詳情 # 自動注入認(rèn)證token從env讀取絕不暴露給模型 headers {Authorization: fBearer {os.getenv(CRM_TOKEN)}} response requests.get( fhttps://api.crm.com/v1/customers/{customer_id}, headersheaders, timeout15 # 統(tǒng)一超時控制 ) response.raise_for_status() return response.json()MCP的價值體現(xiàn)在三個層面安全層Token、密鑰、內(nèi)網(wǎng)地址全部由Runtime管理模型只接觸抽象工具名可觀測層所有tool_call記錄自動寫入審計日志包含耗時、返回碼、輸入?yún)?shù)哈希脫敏治理層可動態(tài)開關(guān)工具如促銷季關(guān)閉“生成財報”工具防止高并發(fā)壓垮BI系統(tǒng)。提示MCP不是LangChain原生支持的需自行實現(xiàn)ToolExecutor。我們基于langchain_core.tools.BaseTool封裝關(guān)鍵是在invoke方法里加入熔斷器Circuit Breaker——連續(xù)3次超時自動將該工具標(biāo)記為DOWN后續(xù)請求直接返回fallback數(shù)據(jù)。2.4 架構(gòu)全景圖四層解耦設(shè)計我們最終采用的架構(gòu)分四層每層職責(zé)清晰、可獨立演進層級組件職責(zé)替換成本編排層LangGraph定義Node、Edge、State Schema處理流程控制高需重寫狀態(tài)機邏輯協(xié)議層MCP Runtime解析tool_call、路由到具體工具、處理超時/重試/熔斷中替換工具注冊器即可能力層RAG引擎 微調(diào)模型 外部API提供知識檢索、推理、執(zhí)行等原子能力低增刪工具不影響編排接入層FastAPI WebSocket對接前端、處理鑒權(quán)、流式響應(yīng)極低僅HTTP接口適配這種設(shè)計讓我們在Q4快速替換了RAG引擎——原用ChromaDB因并發(fā)查詢性能不足換成Weaviate只改了能力層的retriever實現(xiàn)編排層代碼零修改。而競品團隊同期更換向量庫時因所有邏輯耦合在Chain里被迫停服6小時重構(gòu)。3. 核心模塊深度拆解RAG知識庫構(gòu)建、模型微調(diào)、LangGraph狀態(tài)機實現(xiàn)3.1 RAG知識庫為什么“切塊”比“選模型”更重要以及圖片存儲的真實方案RAG效果差80%原因出在文本切分chunking環(huán)節(jié)。我們測試過12種切分策略最終選定語義感知的滑動窗口重疊切分而非簡單按字符數(shù)或標(biāo)點分割。傳統(tǒng)方案如LangChain默認(rèn)的RecursiveCharacterTextSplitter的問題在于它把PDF里一頁“設(shè)備維修指南”切成5段其中一段可能只有“步驟3檢查電源指示燈是否亮起”缺少上下文如“適用機型X系列”“前置條件確保設(shè)備已斷電”導(dǎo)致檢索時召回片段無法支撐準(zhǔn)確回答。我們的解決方案是先做文檔結(jié)構(gòu)識別用pdfplumber提取PDF的標(biāo)題層級、表格邊界、列表項生成結(jié)構(gòu)化元數(shù)據(jù)按語義單元切分以“標(biāo)題其下屬段落相關(guān)表格”為最小單元。例如檢測到## 故障代碼E01標(biāo)題則將其與后續(xù)所有未出現(xiàn)新##前的內(nèi)容合并為一個chunk滑動窗口重疊每個chunk保留前一個chunk末尾15%內(nèi)容作為重疊區(qū)如chunk1結(jié)尾“...請確認(rèn)電源線連接牢固”chunk2開頭“請確認(rèn)電源線連接牢固然后按住復(fù)位鍵5秒...”解決跨chunk信息斷裂問題。實測數(shù)據(jù)在制造業(yè)設(shè)備手冊知識庫上top-3召回率從62%提升至89%且生成答案的引用準(zhǔn)確性即答案中提到的事實能否在對應(yīng)chunk中找到原文達94%。關(guān)于“RAG知識庫能存儲圖片嗎”——嚴(yán)格來說不能但可以存儲圖片的語義描述。我們采用CLIP模型ViT-B/32對圖片生成文本嵌入對PDF中的插圖、流程圖用pdf2image提取為PNG用CLIP的encode_image生成512維向量將該向量與對應(yīng)頁面的文本chunk向量拼接concat存入向量庫檢索時若用戶提問含“示意圖”“接線圖”等詞同時查詢文本和圖像向量加權(quán)融合結(jié)果。注意不要用CLIP微調(diào)我們試過在內(nèi)部設(shè)備圖庫上微調(diào)CLIP反而使通用語義理解能力下降。正確做法是凍結(jié)CLIP主干只訓(xùn)練一個輕量級適配器Adapter參數(shù)量1M既保留通用能力又增強領(lǐng)域特征。3.2 模型微調(diào)為什么LoRA比全量微調(diào)更適合企業(yè)場景以及關(guān)鍵參數(shù)選擇邏輯企業(yè)級Agent不需要“更聰明”需要“更懂業(yè)務(wù)”。我們用Qwen1.5-7B做基座針對三個場景微調(diào)術(shù)語對齊將“工單”映射為ticket而非work order“備件”映射為spare_part而非replacement格式強化強制輸出JSON Schema如{action:escalate,to_role:senior_engineer,reason:...}安全過濾對敏感操作如“刪除客戶數(shù)據(jù)”添加拒絕模板。全量微調(diào)需24GB顯存而LoRALow-Rank Adaptation只需8GB且效果接近。關(guān)鍵參數(shù)選擇邏輯如下rank8實驗發(fā)現(xiàn)rank4時術(shù)語映射不穩(wěn)定rank16顯存占用翻倍但精度提升0.3%8是性價比拐點alpha16alpha/rank2是經(jīng)驗值過高導(dǎo)致過擬合在測試集準(zhǔn)確率92%但線上泛化率僅68%過低則學(xué)習(xí)不足target_modules[q_proj,v_proj]只微調(diào)注意力層的Query和Value投影矩陣實測對領(lǐng)域術(shù)語理解提升最顯著而o_proj微調(diào)反而降低長文本生成連貫性lora_dropout0.1防止在少量業(yè)務(wù)數(shù)據(jù)上過擬合dropout0.05時驗證集loss震蕩劇烈0.15時收斂變慢。微調(diào)數(shù)據(jù)構(gòu)造技巧不用純?nèi)斯?biāo)注而是用規(guī)則引擎生成“弱監(jiān)督數(shù)據(jù)”。例如從CRM導(dǎo)出10萬條工單記錄用正則提取“問題類型網(wǎng)絡(luò)故障”→“action_type:network_troubleshooting自動生成5000條(input,output)對再由業(yè)務(wù)專家抽樣審核200條修正錯誤。這樣數(shù)據(jù)構(gòu)建周期從2周縮短至3天。3.3 LangGraph狀態(tài)機如何設(shè)計Node避免“幽靈狀態(tài)”以及Edge條件表達式的實戰(zhàn)寫法Node設(shè)計最容易犯的錯是狀態(tài)污染——某個Node意外修改了不該碰的State字段。我們強制推行“Node契約”每個Node必須聲明input_keys和output_keysRuntime在執(zhí)行前校驗輸入State是否包含所需字段執(zhí)行后校驗輸出State是否只修改了聲明字段。例如“CRM查詢Node”的契約node def crm_lookup(state: AgentState) - dict: # 契約聲明只讀user_query只寫context_data和tool_calls required [user_query] assert all(k in state for k in required), fMissing keys: {required} # 執(zhí)行邏輯... customer_id extract_customer_id(state[user_query]) # 從問題中抽ID result crm_get_customer(customer_id) # 返回嚴(yán)格限定的字段 return { context_data: {crm_data: result}, tool_calls: [{name: crm_get_customer, status: success}] }Edge條件表達式是LangGraph的靈魂但文檔里寫的lambda x: x[messages][-1].content.startswith(yes)在真實場景根本不夠用。我們定義了一套條件DSL場景DSL寫法說明工具調(diào)用失敗重試state[tool_calls][-1][status] error and state[max_retries] 0記錄最后一次調(diào)用狀態(tài)結(jié)合全局重試計數(shù)需要人工介入len(state[context_data].get(unresolved_issues, [])) 0當(dāng)上下文里有未解決事項時跳轉(zhuǎn)人工隊列置信度不足降級state[messages][-1].response_confidence 0.7模型輸出附帶置信度分?jǐn)?shù)通過logprobs計算特別注意Edge條件必須冪等。我們曾因state[execution_path].append(crm_step)放在條件里導(dǎo)致重試時path變成[crm_step,crm_step]引發(fā)狀態(tài)錯亂。正確做法是把狀態(tài)變更放在Node里Edge只做判斷。3.4 生產(chǎn)部署關(guān)鍵配置K8s資源限制、FastAPI流式響應(yīng)、監(jiān)控埋點設(shè)計本地跑通和生產(chǎn)可用是兩回事。我們總結(jié)出三個必調(diào)參數(shù)K8s內(nèi)存限制設(shè)為4Gi而非默認(rèn)2GiLangGraph的State對象在長流程中會累積大量消息實測2Gi下處理10輪對話后OOM概率達37%。4Gi是安全閾值且預(yù)留50%給Python GCFastAPI流式響應(yīng)必須用StreamingResponse而非yieldyield在Uvicorn下會阻塞事件循環(huán)導(dǎo)致并發(fā)數(shù)超過50時延遲飆升。正確寫法async def stream_response(): async for chunk in agent.astream({messages: [HumanMessage(contentquery)]}): yield fdata: {json.dumps(chunk)}\n\n return StreamingResponse(stream_response(), media_typetext/event-stream)監(jiān)控埋點聚焦三個黃金指標(biāo)agent_execution_time_ms從收到請求到返回final answer的總耗時P952000mstool_call_success_rate各工具調(diào)用成功率CRM需99.5%天氣API允許95%state_size_bytes當(dāng)前State對象序列化后的字節(jié)數(shù)預(yù)警閾值500KB超限自動觸發(fā)State壓縮。實操心得State壓縮不是刪數(shù)據(jù)而是對messages做“摘要蒸餾”。我們用微調(diào)后的Qwen模型將前10輪對話壓縮成3句話摘要替換原始messages實測State體積減少68%且不影響后續(xù)推理質(zhì)量。4. 實戰(zhàn)部署全流程從代碼打包到灰度發(fā)布避坑清單與應(yīng)急方案4.1 Docker鏡像構(gòu)建為什么多階段構(gòu)建必須保留.git目錄標(biāo)準(zhǔn)Dockerfile用COPY . /app會導(dǎo)致鏡像體積暴增含.git、__pycache__、大型測試數(shù)據(jù)。但我們發(fā)現(xiàn)刪除.git目錄會使LangGraph的Node調(diào)試失效——因為LangGraph的node裝飾器在調(diào)試模式下會嘗試讀取源碼行號生成trace而inspect.getsourcefile()依賴.git信息定位文件。最終方案是多階段構(gòu)建中保留.git但清理其他垃圾# 構(gòu)建階段 FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . RUN find . -name *.pyc -delete \ find . -name __pycache__ -type d -exec rm -rf {} \ rm -rf tests/ docs/ data/large_sample.csv # 運行階段 FROM python:3.11-slim WORKDIR /app COPY --from0 /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages COPY --from0 /app /app # 關(guān)鍵保留.git但壓縮其大小 RUN cd .git git repack -ad git prune-packed CMD [uvicorn, app:app, --host, 0.0.0.0:8000]4.2 K8s部署HorizontalPodAutoscalerHPA的指標(biāo)陷阱與修正方案默認(rèn)HPA基于CPU使用率擴容但在AI服務(wù)中極不適用——模型推理是短時高負(fù)載200msCPU峰值后迅速回落導(dǎo)致HPA頻繁擴縮容。我們改用自定義指標(biāo)requests_per_second在FastAPI中暴露指標(biāo)端點app.get(/metrics) async def metrics(): return Response( generate_latest(REGISTRY), media_typetext/plain )Prometheus抓取http_requests_total并計算rateHPA配置metrics: - type: Pods pods: metric: name: http_requests_total target: type: AverageValue averageValue: 50 # 每Pod每秒處理50請求實測效果QPS從200突增至800時擴容時間從3分鐘縮短至42秒且無抖動。4.3 灰度發(fā)布如何用LangGraph的configurable實現(xiàn)AB測試LangGraph的configurable參數(shù)是灰度利器。我們?yōu)椴煌脩羧悍峙洳煌渲? 生產(chǎn)環(huán)境配置 prod_config {configurable: {user_segment: enterprise}} # 灰度配置10%流量 canary_config {configurable: {user_segment: canary, version: v2.1}} # 在FastAPI路由中分流 app.post(/chat) async def chat(request: ChatRequest): if random.random() 0.1: # 10%灰度 config canary_config # 同時記錄到專用日志流便于對比分析 logger.info(fCanary request: {request.query}) else: config prod_config async for chunk in agent.astream({messages: [...]}, config): yield chunk關(guān)鍵點configurable不僅用于分流還作為Node內(nèi)部邏輯的開關(guān)。例如在“RAG檢索Node”里def rag_retrieve(state: AgentState, config: dict): if config.get(configurable, {}).get(version) v2.1: # 新版用Weaviate的Hybrid Search results weaviate_client.query.hybrid(...) else: # 舊版ChromaDB的相似度搜索 results chroma_collection.query(...) return {context_data: results}4.4 應(yīng)急方案當(dāng)Agent卡死時的三步診斷法線上Agent卡死無響應(yīng)、CPU 100%是最高優(yōu)先級故障。我們固化了三步診斷法第一步快速隔離立即對問題Pod執(zhí)行kubectl exec -it pod -- kill -3 1發(fā)送SIGQUIT生成Java-style線程dumpPython的faulthandler會捕獲查看dump中是否大量線程卡在langgraph.pregel的_run_once方法——這是狀態(tài)機死鎖信號。第二步定位死鎖點分析dump中等待的鎖常見是threading.RLock被某個Node長期持有檢查該Node是否調(diào)用了阻塞IO如未設(shè)timeout的requests.get我們曾發(fā)現(xiàn)“郵件發(fā)送Node”因SMTP服務(wù)器響應(yīng)慢導(dǎo)致RLock未釋放后續(xù)所有請求排隊。第三步熱修復(fù)不重啟Pod直接用kubectl exec進入容器執(zhí)行# 強制終止卡死的線程需提前啟用faulthandler echo import threading; [t.join(1) for t in threading.enumerate()] | python # 或重置狀態(tài)機危險操作僅限緊急 echo from langgraph.checkpoint.memory import MemorySaver; MemorySaver().clear() | python注意MemorySaver.clear()會清空所有進行中的流程僅在確認(rèn)無重要任務(wù)時使用。更安全的做法是提前在Node里加timeout裝飾器from functools import wraps def timeout(seconds): def decorator(func): wraps(func) def wrapper(*args, **kwargs): try: return func(*args, **kwargs) except Exception as e: if timeout in str(e).lower(): raise RuntimeError(fNode {func.__name__} timeout after {seconds}s) raise return wrapper return decorator timeout(30) def crm_lookup(...): ...5. 常見問題速查表從RAG瓶頸到MCP授權(quán)一線踩坑經(jīng)驗匯總問題現(xiàn)象根本原因解決方案驗證方式RAG召回率高但答案質(zhì)量差檢索到的chunk語義相關(guān)但信息不完整如只召回“步驟1”缺失“步驟2”的約束條件改用父文檔檢索Parent Document Retrieval將大文檔切分為小chunk存向量庫但每個chunk關(guān)聯(lián)其父文檔ID檢索時先取top-k小chunk再根據(jù)父ID去重并拉取完整父文檔在測試集上對比改進前后答案的F1值要求提升≥15%MCP工具調(diào)用返回401但token正確工具注冊時未指定auth_schemeBearerRuntime默認(rèn)用Basic頭在tool裝飾器中顯式聲明tool(auth_schemeBearer, auth_token_envCRM_TOKEN)用curl -H Authorization: Bearer xxx手動測試API確認(rèn)Header格式一致LangGraph流程執(zhí)行到一半停止無錯誤日志State中messages字段過大1MB觸發(fā)Python的pickle序列化失敗啟用State壓縮中間件在Node執(zhí)行后自動檢查len(pickle.dumps(state))超500KB時調(diào)用摘要模型壓縮messages監(jiān)控state_size_bytes指標(biāo)確保P95400KB微調(diào)模型在測試集準(zhǔn)確率95%但線上效果差測試集數(shù)據(jù)分布與線上請求嚴(yán)重不符如測試用標(biāo)準(zhǔn)問句線上多口語化、錯別字構(gòu)建線上請求采樣池每天隨機截取1%真實請求存入online_samples集合微調(diào)時按7:2:1劃分訓(xùn)練/驗證/測試集測試集必須來自該池上線后對比A/B組的用戶滿意度CSAT要求≥85%FastAPI流式響應(yīng)前端收不到數(shù)據(jù)Nginx默認(rèn)緩沖SSE響應(yīng)需配置proxy_buffering off;和chunked_transfer_encoding on;在ingress nginx配置中添加nginx.ingress.kubernetes.io/configuration-snippet:proxy_buffering off;chunked_transfer_encoding on;最后分享一個小技巧我們給每個Node加了“健康探針”。在Node代碼開頭插入import time start_time time.time() # Node邏輯... duration time.time() - start_time if duration 5.0: # 超5秒告警 logger.warning(fNode {__name__} slow: {duration:.2f}s)這個簡單計時幫我們發(fā)現(xiàn)了一個隱藏問題RAG檢索Node在首次加載向量庫時會冷啟動耗時8秒但后續(xù)請求正常。于是我們在K8s readiness probe里加了initialDelaySeconds: 10避免Pod剛啟動就被打入流量。我在實際部署中發(fā)現(xiàn)最耗時間的往往不是寫代碼而是說服業(yè)務(wù)方接受“Agent需要3周冷啟動期”——這期間要收集真實對話、標(biāo)注bad case、調(diào)整RAG切分策略。但一旦跑通運維成本比規(guī)則引擎低70%而且能持續(xù)進化。這個過程沒有捷徑但每一步踩過的坑都成了現(xiàn)在這份手冊里的每一個標(biāo)點。