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