做了这么多年售前报价，最磨人的不是算价格，而是找案例。客户丢过来一段需求，你得翻历史项目、比对相似场景、估算工作量、再凑一个像样的报价方案。这一套流程，传统做法至少两三天，而且结果好坏高度依赖个人经验。我最近把一个售前报价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的项目里，别急着调大模型，先控制好输入。输入端稳定了，输出端自然不会太离谱。这比你事后花大把力气做结果校验要划算得多。
