做了這么多年售前報價最磨人的不是算價格而是找案例。客戶丟過來一段需求你得翻歷史項(xiàng)目、比對相似場景、估算工作量、再湊一個像樣的報價方案。這一套流程傳統(tǒng)做法至少兩三天而且結(jié)果好壞高度依賴個人經(jīng)驗(yàn)。我最近把一個售前報價Agent從零搭到了能跑通的階段整個過程最有價值的不是模型選型也不是提示詞技巧而是幾個看起來不起眼的工程決策。這篇文章就把這些決策掰開揉碎講清楚適合正在做Agent落地、或者打算把銷售/售前流程自動化的朋友參考。這個Agent的核心能力就是把“找案例”和“出報價”這兩個動作串成一條自動化鏈路輸入客戶需求輸出一份帶參考案例、參數(shù)明細(xì)、報價區(qū)間的報價草稿。沒錯是草稿不是最終報價。這個定位很關(guān)鍵后面我會專門說。1. 先搞清楚這個Agent到底在解決什么問題1.1 售前報價場景的流程拆解售前報價不是“給個價格”這么簡單。我復(fù)盤了一下日常工作發(fā)現(xiàn)一筆報價從開始到落地至少要經(jīng)歷五個環(huán)節(jié)需求收集、案例檢索、方案匹配、工作量估算、報價輸出。傳統(tǒng)模式下需求收集靠郵件和會議紀(jì)要案例檢索靠腦子回憶和文件夾翻找工作量估算靠經(jīng)驗(yàn)拍腦袋報價輸出靠Excel表格手工拼。這五個環(huán)節(jié)里最耗時的是案例檢索和方案匹配因?yàn)槟阈枰獙Ρ葰v史項(xiàng)目的相似度、行業(yè)屬性、交付周期才能給出一個站得住的報價。這里有個很典型的痛點(diǎn)老售前人員腦子里有大量“案例庫”但換一個人來做同樣的需求可能報出完全不同的價格。團(tuán)隊(duì)里的報價口徑很難統(tǒng)一。Agent能做的就是把這個經(jīng)驗(yàn)沉淀下來變成一個可復(fù)制、可追溯的流程。1.2 為什么這個場景適合上Agent而不是寫死腳本有人可能會問既然流程這么固定寫個腳本不行嗎還真不行?？蛻粜枨笫乔ё?nèi)f化的自然語言有人發(fā)一段200字的場景描述有人就發(fā)三行關(guān)鍵詞還有人直接丟一份PDF。腳本能處理的只有結(jié)構(gòu)化輸入而售前需求恰恰是非結(jié)構(gòu)化的重災(zāi)區(qū)。但Agent不一樣。Agent的核心優(yōu)勢在于它可以自主理解一段口語化的需求描述去知識庫里檢索相似案例并且在流程跑偏的時候自行糾偏。這正好命中售前報價的痛點(diǎn)——需求表達(dá)隨意且模糊、知識庫是非結(jié)構(gòu)化的歷史項(xiàng)目資料、輸出結(jié)果需要靈活性又不失準(zhǔn)確性。用固定腳本做不了的事用Agent就能做。但前提是你得把工程邊界劃清楚。2. 七個工程決策每一個都是取舍2.1 決策一工作流編排優(yōu)先于自由Agent項(xiàng)目啟動時我一度想直接把Agent放養(yǎng)給它一個百科全書式的系統(tǒng)提示詞讓它自己決定先干什么再干什么。結(jié)果發(fā)現(xiàn)兩個問題第一Agent經(jīng)常漏步驟比如直接跳到報價環(huán)節(jié)漏掉了案例檢索第二它的思考過程不可控輸出格式五花八門有時候給表格有時候給大段文字下游解析邏輯根本沒法寫。后來我換成了“階段化工作流”模式。整個Agent被拆成三個依次執(zhí)行的階段需求理解、案例檢索、報價生成。每個階段內(nèi)部保留Agent的自主性但階段和階段之間的流轉(zhuǎn)由編排層控制。也就是說Agent只能在院子里跑不能跑出院子。這個決策的核心邏輯是報價場景是一個“順序漏斗”每一步都依賴上一步的輸出。需求理解階段產(chǎn)出的結(jié)構(gòu)化標(biāo)簽是案例檢索的輸入案例檢索找到的參考案例是報價生成的依據(jù)。把流程階段化之后每個階段的輸出都有審計(jì)點(diǎn)出了問題能定位到具體環(huán)節(jié)。這比讓Agent自由發(fā)揮要可靠得多。提示如果你的場景是“先做什么后做什么相對固定”的漏斗型流程建議優(yōu)先選階段化工作流別盲目追自由Agent。Agent的智能用在階段內(nèi)部的決策上就好。2.2 決策二案例匹配不靠LLM端到端“想”靠混合檢索最初版本里我試圖讓LLM直接根據(jù)客戶需求輸出“相似案例編號”結(jié)果非常不靠譜。模型經(jīng)常給出不存在的案例編號或者把兩個不同項(xiàng)目的細(xì)節(jié)張冠李戴。查下來發(fā)現(xiàn)是幻覺問題——LLM在“回憶”案例庫內(nèi)容時不可控。于是我把案例匹配改成了三段式向量檢索召回、結(jié)構(gòu)化字段過濾、LLM重排。具體做法是先把客戶需求做成embedding在案例庫的向量索引里召回Top50再用行業(yè)、產(chǎn)品線、交付周期這些結(jié)構(gòu)化字段做硬性過濾把范圍縮到Top10最后讓LLM對這10個案例做一個相關(guān)性打分按分?jǐn)?shù)取前3個作為參考案例。這套混合檢索的思路其實(shí)不復(fù)雜核心是讓不同引擎干各自擅長的事向量檢索解決“語義相似”問題結(jié)構(gòu)化過濾解決“硬條件匹配”問題LLM只負(fù)責(zé)排序理解。這比讓LLM直接“想”出案例編號靠譜得多。實(shí)測下來案例召回的準(zhǔn)確率從61%提升到了91%而且基本不會再輸出不存在的案例號。2.3 決策三上下文窗口是資產(chǎn)也是負(fù)債必須做預(yù)算剛開始我信奉“上下文越多Agent越聰明”于是把案例庫的全部字段、全部歷史對話一股腦拼進(jìn)去。結(jié)果token爆炸單次請求成本一度沖到一塊多錢而且Agent的注意力明顯被稀釋——報價單里居然出現(xiàn)了無關(guān)案例的項(xiàng)目名稱。后來我做了兩個動作收斂上下文、壓縮字段。每次報價請求的prompt總量被嚴(yán)格控制在8K到15K token的區(qū)間超過這個閾值就做摘要。案例庫字段也做了瘦身只保留對報價有直接影響的需求摘要、報價區(qū)間、交付周期、復(fù)用性備注、項(xiàng)目規(guī)模。至于那些“項(xiàng)目背景故事”“客戶評價”之類的字段全部不進(jìn)入Agent上下文。這里給大家一個成本對比參考同樣的一個報價需求喂15K token的輸入單次prompt成本大約是幾分錢如果放任不管喂到50K token成本直接漲到兩毛多而且響應(yīng)時間翻倍。對于需要頻繁調(diào)用Agent的場景這個賬必須算清楚。2.4 決策四報價計(jì)算必須“結(jié)構(gòu)化中間量優(yōu)先”LLM只做參數(shù)映射這是我在整個項(xiàng)目里踩得最深的一個坑。最初讓Agent直接輸出“總報價”結(jié)果同一個需求跑三次三次價格差出百分之二十?？蛻粢强吹竭@個信任感直接歸零。我后來做了一個關(guān)鍵調(diào)整LLM不再負(fù)責(zé)計(jì)算最終價格只負(fù)責(zé)生成一個結(jié)構(gòu)化的報價參數(shù)JSON——包括推薦產(chǎn)品線、參考案例編號、選型參數(shù)、單位、數(shù)量、市場參考價區(qū)間、折扣系數(shù)、風(fēng)險系數(shù)。這些參數(shù)生成之后由一段確定性的Python代碼去計(jì)算最終報價。LLM的參數(shù)映射能力用來“理解需求對應(yīng)什么類型的工作量”而真正需要精確計(jì)算的部分全部交給代碼。這個調(diào)整的效果非常直觀同一需求跑十次報價方差的波動控制在了±5%以內(nèi)。更重要的是這個結(jié)構(gòu)化的JSON成了整個報價流程的“事實(shí)表”每一步都可以回溯客戶問“這個價格怎么來的”你能直接拿出依據(jù)。2.5 決策五區(qū)分“參考給人看”和“報價給人簽”強(qiáng)制人工復(fù)核出口做一個全自動出報價的Agent技術(shù)上完全可行但業(yè)務(wù)上很危險。報價單是要給客戶簽合同的如果Agent自動算出一個離譜的價格然后直接推給客戶這個責(zé)任沒人擔(dān)得起。所以我在整個流程的最后設(shè)計(jì)了一個強(qiáng)制人工確認(rèn)環(huán)節(jié)Agent產(chǎn)出的是“報價草稿”附上參考案例、推薦理由、風(fēng)險備注由人工確認(rèn)后才能轉(zhuǎn)為正式報價單。與此同時Agent在生成報價草稿時如果發(fā)現(xiàn)需求里某些關(guān)鍵參數(shù)缺失必須標(biāo)注為“待確認(rèn)字段”而不是自動編一個默認(rèn)值補(bǔ)上。注意在設(shè)計(jì)報價Agent時一定要先定義清楚“責(zé)任邊界”。Agent能承擔(dān)的是“壓縮時間、提供參考”承擔(dān)不了的是“簽署合同、確認(rèn)商務(wù)條款”。這個邊界差了線上出問題就是大事故。2.6 決策六單Agent多階段優(yōu)于多Agent協(xié)作項(xiàng)目中期我看到市面上很多團(tuán)隊(duì)在搞多Agent協(xié)作什么“售前分析師Agent”“報價專員Agent”“風(fēng)險審核Agent”聽起來很高級我也一度動了心思。但拆開分析之后我放棄了這個方案。原因有兩個。第一調(diào)用成本翻倍。每增加一個Agent角色就多一輪獨(dú)立推理和上下文傳遞在同一個流程里反復(fù)切換Agent角色會帶來大量的冗余token消耗。第二延遲顯著上升。售前報價是有時間窗口的客戶在線等方案一個多Agent協(xié)作流程動輒要跑兩三分鐘基本沒人能忍受。所以我最終選擇了“單Agent多階段”同一個Agent實(shí)例在需求理解階段扮演分析師在報價生成階段扮演報價專員通過系統(tǒng)提示詞切換角色設(shè)定但上下文是連貫共享的。這本質(zhì)上是用“任務(wù)分解”代替“角色分工”。在順序漏斗型的場景里任務(wù)分解的效率和穩(wěn)定性都遠(yuǎn)高于多角色分工。2.7 決策七超時與降級——給Agent裝一個安全閥LLM調(diào)用是不可靠的偶爾會卡頓、輸出異常、甚至直接超時。一個不能容忍超時的Agent方案在生產(chǎn)環(huán)境就是定時炸彈。我給每個階段設(shè)置了獨(dú)立的超時閾值需求理解8秒、案例檢索4秒、報價生成15秒。整個流程的預(yù)算上限是30秒。超時后的處理也做了降級預(yù)案如果是需求理解超時直接返回“輸入無法識別”并轉(zhuǎn)人工如果是案例檢索超時退回到只有結(jié)構(gòu)化過濾的簡版檢索如果是報價生成超時返回一個基于模板的估算報價并標(biāo)注“該報價僅供參考未走完整評估流程”。這套安全閥看著不起眼但它在實(shí)際運(yùn)行里救了我好幾次。LLM抽風(fēng)的時候系統(tǒng)不會死掉而是優(yōu)雅地降級到可用狀態(tài)?？蛻艨吹降牟皇恰跋到y(tǒng)錯誤”而是“正在為您轉(zhuǎn)接人工”。這就是工程兜底的價值。3. 容易被忽略的兩個工程細(xì)節(jié)3.1 上下文隔離比“記憶”更重要我把Agent跑起來之后很快發(fā)現(xiàn)一個詭異的問題處理完A客戶的報價緊接著處理B客戶的需求時B的報價單里居然出現(xiàn)A的項(xiàng)目名稱和價格區(qū)間。查了半天原因在于Agent的上下文沒有清理干凈。這個問題的解決方案很樸素每處理完一個需求立即清空Agent的上下文緩存重置系統(tǒng)提示詞讓下一次報價從干凈狀態(tài)開始。這個機(jī)制看起來簡單但如果不做Agent的“記憶污染”會隨著使用次數(shù)增加而越來越嚴(yán)重。對話歷史里的舊案例會污染新需求的檢索結(jié)果甚至導(dǎo)致檢索階段偏航。3.2 為每一次報價生成traceId我在系統(tǒng)里給每一輪Agent運(yùn)行都打了一個traceId記錄每個階段耗時、命中案例列表、token消耗量、人工復(fù)核結(jié)果。一開始純粹是為了排查問題但后來發(fā)現(xiàn)這個traceId的價值遠(yuǎn)不止此——它成了Agent迭代優(yōu)化的數(shù)據(jù)基礎(chǔ)。通過分析trace日志我發(fā)現(xiàn)原本以為很完善的提示詞在需求理解階段居然有23%的輸入會被錯誤地打上行業(yè)標(biāo)簽。這直接影響到了下游案例檢索的召回結(jié)果。如果沒有traceId這種潛在的問題根本不可能被發(fā)現(xiàn)。4. 這個Agent跑起來之后的收益與迭代方向跑通之后我做了個小范圍的對比測試選10個歷史報價需求一組用傳統(tǒng)人工方式處理一組用Agent生成草稿。結(jié)果人工組平均耗時兩天Agent組平均耗時25分鐘報價口徑一致性上Agent組的方差明顯小于人工組人工復(fù)核率從100%降到了42%——也就是說有近六成的報價草稿基本可以直接使用。當(dāng)然Agent能做的還不止這些。我目前正在給它加兩個擴(kuò)展能力一是競品報價比對在報價草稿里附上同類產(chǎn)品的市場參考區(qū)間二是報價歷史趨勢分析看看同一類項(xiàng)目的單價在最近一年內(nèi)的波動情況。這兩個能力落地之后售前報價就不只是“報個價”而是帶有市場洞察的決策參考。5. 幾點(diǎn)個人體會整個項(xiàng)目做下來我最大的感受是報價類Agent的核心競爭力不是“聰明”而是“穩(wěn)定”?？蛻艉褪矍皥F(tuán)隊(duì)真正需要的不是一份偶爾驚艷但經(jīng)常離譜的報價而是一個每次都能穩(wěn)定輸出、口徑一致、邏輯可追溯的報價生成系統(tǒng)。工程決策的重要性遠(yuǎn)大于模型參數(shù)調(diào)整7個決策里有6個都在做“收斂”而不是“放開”。最后再分享一個小技巧在Agent的項(xiàng)目里別急著調(diào)大模型先控制好輸入。輸入端穩(wěn)定了輸出端自然不會太離譜。這比你事后花大把力氣做結(jié)果校驗(yàn)要劃算得多。