售前报价Agent落地：七个关键工程决策与稳定输出

做了这么多年售前报价最磨人的不是算价格而是找案例。客户丢过来一段需求你得翻历史项目、比对相似场景、估算工作量、再凑一个像样的报价方案。这一套流程传统做法至少两三天而且结果好坏高度依赖个人经验。我最近把一个售前报价Agent从零搭到了能跑通的阶段整个过程最有价值的不是模型选型也不是提示词技巧而是几个看起来不起眼的工程决策。这篇文章就把这些决策掰开揉碎讲清楚适合正在做Agent落地、或者打算把销售/售前流程自动化的朋友参考。这个Agent的核心能力就是把“找案例”和“出报价”这两个动作串成一条自动化链路输入客户需求输出一份带参考案例、参数明细、报价区间的报价草稿。没错是草稿不是最终报价。这个定位很关键后面我会专门说。1. 先搞清楚这个Agent到底在解决什么问题1.1 售前报价场景的流程拆解售前报价不是“给个价格”这么简单。我复盘了一下日常工作发现一笔报价从开始到落地至少要经历五个环节需求收集、案例检索、方案匹配、工作量估算、报价输出。传统模式下需求收集靠邮件和会议纪要案例检索靠脑子回忆和文件夹翻找工作量估算靠经验拍脑袋报价输出靠Excel表格手工拼。这五个环节里最耗时的是案例检索和方案匹配因为你需要对比历史项目的相似度、行业属性、交付周期才能给出一个站得住的报价。这里有个很典型的痛点老售前人员脑子里有大量“案例库”但换一个人来做同样的需求可能报出完全不同的价格。团队里的报价口径很难统一。Agent能做的就是把这个经验沉淀下来变成一个可复制、可追溯的流程。1.2 为什么这个场景适合上Agent而不是写死脚本有人可能会问既然流程这么固定写个脚本不行吗还真不行。客户需求是千变万化的自然语言有人发一段200字的场景描述有人就发三行关键词还有人直接丢一份PDF。脚本能处理的只有结构化输入而售前需求恰恰是非结构化的重灾区。但Agent不一样。Agent的核心优势在于它可以自主理解一段口语化的需求描述去知识库里检索相似案例并且在流程跑偏的时候自行纠偏。这正好命中售前报价的痛点——需求表达随意且模糊、知识库是非结构化的历史项目资料、输出结果需要灵活性又不失准确性。用固定脚本做不了的事用Agent就能做。但前提是你得把工程边界划清楚。2. 七个工程决策每一个都是取舍2.1 决策一工作流编排优先于自由Agent项目启动时我一度想直接把Agent放养给它一个百科全书式的系统提示词让它自己决定先干什么再干什么。结果发现两个问题第一Agent经常漏步骤比如直接跳到报价环节漏掉了案例检索第二它的思考过程不可控输出格式五花八门有时候给表格有时候给大段文字下游解析逻辑根本没法写。后来我换成了“阶段化工作流”模式。整个Agent被拆成三个依次执行的阶段需求理解、案例检索、报价生成。每个阶段内部保留Agent的自主性但阶段和阶段之间的流转由编排层控制。也就是说Agent只能在院子里跑不能跑出院子。这个决策的核心逻辑是报价场景是一个“顺序漏斗”每一步都依赖上一步的输出。需求理解阶段产出的结构化标签是案例检索的输入案例检索找到的参考案例是报价生成的依据。把流程阶段化之后每个阶段的输出都有审计点出了问题能定位到具体环节。这比让Agent自由发挥要可靠得多。提示如果你的场景是“先做什么后做什么相对固定”的漏斗型流程建议优先选阶段化工作流别盲目追自由Agent。Agent的智能用在阶段内部的决策上就好。2.2 决策二案例匹配不靠LLM端到端“想”靠混合检索最初版本里我试图让LLM直接根据客户需求输出“相似案例编号”结果非常不靠谱。模型经常给出不存在的案例编号或者把两个不同项目的细节张冠李戴。查下来发现是幻觉问题——LLM在“回忆”案例库内容时不可控。于是我把案例匹配改成了三段式向量检索召回、结构化字段过滤、LLM重排。具体做法是先把客户需求做成embedding在案例库的向量索引里召回Top50再用行业、产品线、交付周期这些结构化字段做硬性过滤把范围缩到Top10最后让LLM对这10个案例做一个相关性打分按分数取前3个作为参考案例。这套混合检索的思路其实不复杂核心是让不同引擎干各自擅长的事向量检索解决“语义相似”问题结构化过滤解决“硬条件匹配”问题LLM只负责排序理解。这比让LLM直接“想”出案例编号靠谱得多。实测下来案例召回的准确率从61%提升到了91%而且基本不会再输出不存在的案例号。2.3 决策三上下文窗口是资产也是负债必须做预算刚开始我信奉“上下文越多Agent越聪明”于是把案例库的全部字段、全部历史对话一股脑拼进去。结果token爆炸单次请求成本一度冲到一块多钱而且Agent的注意力明显被稀释——报价单里居然出现了无关案例的项目名称。后来我做了两个动作收敛上下文、压缩字段。每次报价请求的prompt总量被严格控制在8K到15K token的区间超过这个阈值就做摘要。案例库字段也做了瘦身只保留对报价有直接影响的需求摘要、报价区间、交付周期、复用性备注、项目规模。至于那些“项目背景故事”“客户评价”之类的字段全部不进入Agent上下文。这里给大家一个成本对比参考同样的一个报价需求喂15K token的输入单次prompt成本大约是几分钱如果放任不管喂到50K token成本直接涨到两毛多而且响应时间翻倍。对于需要频繁调用Agent的场景这个账必须算清楚。2.4 决策四报价计算必须“结构化中间量优先”LLM只做参数映射这是我在整个项目里踩得最深的一个坑。最初让Agent直接输出“总报价”结果同一个需求跑三次三次价格差出百分之二十。客户要是看到这个信任感直接归零。我后来做了一个关键调整LLM不再负责计算最终价格只负责生成一个结构化的报价参数JSON——包括推荐产品线、参考案例编号、选型参数、单位、数量、市场参考价区间、折扣系数、风险系数。这些参数生成之后由一段确定性的Python代码去计算最终报价。LLM的参数映射能力用来“理解需求对应什么类型的工作量”而真正需要精确计算的部分全部交给代码。这个调整的效果非常直观同一需求跑十次报价方差的波动控制在了±5%以内。更重要的是这个结构化的JSON成了整个报价流程的“事实表”每一步都可以回溯客户问“这个价格怎么来的”你能直接拿出依据。2.5 决策五区分“参考给人看”和“报价给人签”强制人工复核出口做一个全自动出报价的Agent技术上完全可行但业务上很危险。报价单是要给客户签合同的如果Agent自动算出一个离谱的价格然后直接推给客户这个责任没人担得起。所以我在整个流程的最后设计了一个强制人工确认环节Agent产出的是“报价草稿”附上参考案例、推荐理由、风险备注由人工确认后才能转为正式报价单。与此同时Agent在生成报价草稿时如果发现需求里某些关键参数缺失必须标注为“待确认字段”而不是自动编一个默认值补上。注意在设计报价Agent时一定要先定义清楚“责任边界”。Agent能承担的是“压缩时间、提供参考”承担不了的是“签署合同、确认商务条款”。这个边界差了线上出问题就是大事故。2.6 决策六单Agent多阶段优于多Agent协作项目中期我看到市面上很多团队在搞多Agent协作什么“售前分析师Agent”“报价专员Agent”“风险审核Agent”听起来很高级我也一度动了心思。但拆开分析之后我放弃了这个方案。原因有两个。第一调用成本翻倍。每增加一个Agent角色就多一轮独立推理和上下文传递在同一个流程里反复切换Agent角色会带来大量的冗余token消耗。第二延迟显著上升。售前报价是有时间窗口的客户在线等方案一个多Agent协作流程动辄要跑两三分钟基本没人能忍受。所以我最终选择了“单Agent多阶段”同一个Agent实例在需求理解阶段扮演分析师在报价生成阶段扮演报价专员通过系统提示词切换角色设定但上下文是连贯共享的。这本质上是用“任务分解”代替“角色分工”。在顺序漏斗型的场景里任务分解的效率和稳定性都远高于多角色分工。2.7 决策七超时与降级——给Agent装一个安全阀LLM调用是不可靠的偶尔会卡顿、输出异常、甚至直接超时。一个不能容忍超时的Agent方案在生产环境就是定时炸弹。我给每个阶段设置了独立的超时阈值需求理解8秒、案例检索4秒、报价生成15秒。整个流程的预算上限是30秒。超时后的处理也做了降级预案如果是需求理解超时直接返回“输入无法识别”并转人工如果是案例检索超时退回到只有结构化过滤的简版检索如果是报价生成超时返回一个基于模板的估算报价并标注“该报价仅供参考未走完整评估流程”。这套安全阀看着不起眼但它在实际运行里救了我好几次。LLM抽风的时候系统不会死掉而是优雅地降级到可用状态。客户看到的不是“系统错误”而是“正在为您转接人工”。这就是工程兜底的价值。3. 容易被忽略的两个工程细节3.1 上下文隔离比“记忆”更重要我把Agent跑起来之后很快发现一个诡异的问题处理完A客户的报价紧接着处理B客户的需求时B的报价单里居然出现A的项目名称和价格区间。查了半天原因在于Agent的上下文没有清理干净。这个问题的解决方案很朴素每处理完一个需求立即清空Agent的上下文缓存重置系统提示词让下一次报价从干净状态开始。这个机制看起来简单但如果不做Agent的“记忆污染”会随着使用次数增加而越来越严重。对话历史里的旧案例会污染新需求的检索结果甚至导致检索阶段偏航。3.2 为每一次报价生成traceId我在系统里给每一轮Agent运行都打了一个traceId记录每个阶段耗时、命中案例列表、token消耗量、人工复核结果。一开始纯粹是为了排查问题但后来发现这个traceId的价值远不止此——它成了Agent迭代优化的数据基础。通过分析trace日志我发现原本以为很完善的提示词在需求理解阶段居然有23%的输入会被错误地打上行业标签。这直接影响到了下游案例检索的召回结果。如果没有traceId这种潜在的问题根本不可能被发现。4. 这个Agent跑起来之后的收益与迭代方向跑通之后我做了个小范围的对比测试选10个历史报价需求一组用传统人工方式处理一组用Agent生成草稿。结果人工组平均耗时两天Agent组平均耗时25分钟报价口径一致性上Agent组的方差明显小于人工组人工复核率从100%降到了42%——也就是说有近六成的报价草稿基本可以直接使用。当然Agent能做的还不止这些。我目前正在给它加两个扩展能力一是竞品报价比对在报价草稿里附上同类产品的市场参考区间二是报价历史趋势分析看看同一类项目的单价在最近一年内的波动情况。这两个能力落地之后售前报价就不只是“报个价”而是带有市场洞察的决策参考。5. 几点个人体会整个项目做下来我最大的感受是报价类Agent的核心竞争力不是“聪明”而是“稳定”。客户和售前团队真正需要的不是一份偶尔惊艳但经常离谱的报价而是一个每次都能稳定输出、口径一致、逻辑可追溯的报价生成系统。工程决策的重要性远大于模型参数调整7个决策里有6个都在做“收敛”而不是“放开”。最后再分享一个小技巧在Agent的项目里别急着调大模型先控制好输入。输入端稳定了输出端自然不会太离谱。这比你事后花大把力气做结果校验要划算得多。