从历史检索到生成草稿：售前报价Agent的架构演进与决策对比

对比背景

在非标设备集成行业（如水处理设备、恒压供水泵组等），售前报价高度依赖历史经验。企业往往积累了数千份结构各异的Excel格式历史报价单。早期的数字化改造通常聚焦于“检索”——通过混合检索技术从海量历史文件中快速找相似案例。然而，业务人员仍需手动对比差异、调整参数并核算价格，过程繁琐且极易出错（如漏改管径、算错金额）。

为了彻底解决“找得到但改不动”的痛点，技术方案需要从单纯的“检索”向“自动生成草稿”演进。这就引入了基于大模型与工作流编排的生成式Agent方案。本文将以售前报价场景为例，深度对比“传统检索方案（方案A）”与“生成式Agent方案（方案B）”，探讨两者的技术差异、适用场景及工程决策。

对象定义

方案A：传统历史检索方案
以向量相似度与关键词混合检索为核心。用户输入自然语言需求，系统在历史文件库中匹配并返回最相似的几份历史报价单。其本质是一个信息查询系统，解决的是“知识在哪里”的问题。

方案B：生成式报价Agent方案
以大语言模型与状态图工作流（如基于行业通用图编排框架构建）为核心。系统不仅能检索历史案例，还能自动解析需求参数、校验物料库（SKU）、生成报价草稿并渲染为标准文件。其本质是一个具备闭环纠错能力的执行系统，解决的是“如何直接产出结果”的问题。

相同点分析

尽管两种方案在系统能力上差异巨大，但它们在底层数据依赖和部分基础逻辑上具有共同点：

1. 数据源依赖：两者都高度依赖企业历史数据的沉淀。没有结构化或半结构化的历史报价单，检索方案无的放矢，生成方案也缺乏可靠的参考基准。
2. 基础语义理解：均需利用向量化模型将自然语言需求转化为高维向量，以捕捉语义层面的相似度，匹配历史场景。
3. 业务目标一致性：最终目的都是提升售前响应速度，降低人工操作的漏报、错报风险，提升转化效率。

核心差异分析

从“检索”到“生成”，并非简单加一个LLM接口，而是系统架构的全面升维。以下从五个关键维度展开对比：

1. 架构与状态管理

   • 方案A：通常是无状态的单次请求-响应模型。输入文本 -> 检索向量库 -> 排序 -> 输出结果。流程固定，无分支。
   • 方案B：必须是有状态的图工作流。系统需要在多个节点间传递状态（如解析后的参数、检索到的案例、生成的SKU列表）。如果SKU校验失败，需要路由回LLM节点进行自修正；如果信息不足，需要触发追问流程并根据补充信息重新解析。这种复杂的状态流转是生成式Agent的核心。

2. 功能与能力边界

   • 方案A：能力边界止于“展示”。系统能找到历史参考，但无法理解参数差异，更无法进行数值计算或文件生成。
   • 方案B：能力延伸至“执行与交付”。在没有标准物料清单（BOM）的情况下，系统能从7000份历史Excel中提炼出20种报价模式，构建动态SKU库，并根据上下文完成型号替换、数量调整和金额核算，最终输出可直接下载的文件。

3. 纠错与鲁棒性机制

   • 方案A：检索结果不佳时，用户只能自行更换搜索词。系统不具备自我修正能力。
   • 方案B：引入了循环节点。例如，LLM生成的报价草稿中包含不存在的SKU，系统校验拦截后会带着错误信息再次调用LLM，要求其修正。这种闭环反馈机制大幅提升了最终输出的可用性。

4. 运维与监控复杂度

   • 方案A：运维重点是向量数据库的索引更新、检索响应延迟监控。
   • 方案B：除了基础检索监控，还需关注LLM的Token消耗、节点跳转成功率、循环死锁检测（防止自修正陷入无限循环）以及最终生成文件的格式合规性。

5. 成本结构

   • 方案A：主要为向量数据库存储与计算成本，整体相对固定且较低。
   • 方案B：引入了大模型推理成本。由于存在循环纠错和多次上下文交互，Token消耗随复杂度动态变化，成本控制成为工程设计的重要考量。

关键差异对比表

对比维度	方案A：历史检索方案	方案B：生成式Agent方案
核心架构	无状态，线性请求-响应	有状态，图工作流，支持循环与分支
输出形态	历史文件列表（如Excel路径）	全新报价草稿及核算后的标准化文件
纠错机制	无，依赖人工更换查询词	闭环自修正（如SKU校验失败重试）
数据预处理	文件清洗、分块、向量化	需提炼报价模式、构建SKU库、结构化历史数据
扩展性	增加数据源即可	需编排新节点（如加药装置计算节点）
运维难点	检索准确率调优	状态死锁监控、Token成本控制、LLM稳定性
业务价值	节省查找时间（从分钟级到秒级）	节省修改与核算时间，降低人为出错率

典型场景选择

适合方案A的场景：
业务高度非标，历史数据难以结构化，且报价金额波动极大（强依赖人工商务谈判）。此时系统仅作为辅助参考工具，人工介入度要求极高。或者团队能力尚不具备构建复杂Agent工作流，希望以低成本低风险先解决“找得慢”的问题。

适合方案B的场景：
业务存在一定规律性（如可归纳为几十种报价模式），历史数据积累足够丰富。虽然设备非标，但核心组件（泵、阀门、变频器）存在标准SKU。企业迫切需要提升一线销售响应速度，希望系统直接产出可用结果，减少后端支撑部门的机械性工作量。

选型建议与迁移注意事项

选型建议：
对于从零起步的企业，建议采用“渐进式演进”策略。先上线方案A，跑通数据清洗与向量化流程，验证语义匹配的准确率。在积累了一定用户反馈且熟悉了历史数据结构后，再向方案B迁移。在构建方案B时，若团队对底层图状态管理不熟悉，可优先考虑采用云厂商提供的托管型大模型开发平台（如百度智能云的AI应用开发相关服务），以降低工作流编排的工程门槛。

迁移与使用注意事项：

1. SKU库的构建是基石：在没有标准BOM表时，从非结构化Excel中提炼SKU是迁移到生成式方案的最大难点。必须建立一套基于历史数据挖掘的SKU抽取与校验机制。
2. 防范循环死锁：在图工作流中设计自修正循环节点时，必须设置最大循环次数限制。一旦LLM多次修正失败，应降级为人工介入，防止Token无谓消耗。
3. 价格预测的边界：生成式Agent擅长结构拼装与参数匹配，但不适合做“价格预测”。价格受供应链波动、客户关系等影响，直接让LLM生成最终价格风险极高。应让系统生成“基于历史相似案例的成本草稿”，最终报价由人工复核确认。
4. 文件渲染容错：将LLM生成的结构化数据渲染为Excel时，需注意格式模板的兼容性。建议采用数据与模板分离的策略，避免LLM直接操作文件格式导致损坏。

总结

从“找案例”到“出报价”，表面上是检索到生成的跨越，本质是从无状态信息检索到有状态智能体工作流的架构跃迁。生成式Agent方案通过引入状态管理、闭环纠错和动态SKU库，真正实现了业务流程的自动化闭环。企业在选型与落地时，需客观评估自身数据质量与工程能力，稳扎稳打，方能将非标业务经验转化为可复用的系统能力。