文章摘要
企业建设AI售前助手时，常见误区是把通用大模型、RAG和Agent当成三个可以互相替代的方案。实际上，通用大模型负责语言理解与生成，RAG负责把内部知识送入上下文，Agent负责规划任务、调用工具和推动流程。本文围绕需求分析、产品匹配、方案生成、报价、投标和审批等售前任务，给出三类能力的边界、组合方式和选型建议。
一、先看三个典型需求
需求一：润色一段方案文字
请把这段产品介绍改得更专业。
只需要通用大模型。
需求二：根据企业产品资料回答功能问题
我们的仓储系统是否支持批次效期管理？
需要RAG，因为答案必须来自企业内部资料。
需求三：读取招标文件，拆解评分项，匹配产品功能，生成响应表并发起审批
这已经不是单次问答，需要Agent编排多个步骤和工具。
三个需求看起来都与“生成文本”有关，但系统复杂度完全不同。
二、通用大模型负责什么
通用大模型擅长：
- 理解自然语言；
- 提炼需求；
- 改写和润色；
- 生成结构化草稿；
- 对信息进行归纳；
- 按模板输出内容；
- 判断文本语义关系。
它不天然知道：
- 企业当前产品版本；
- 哪些功能已经正式上线；
- 某客户历史项目情况；
- 最新报价；
- 研发排期；
- 内部审批规则；
- 招标文件中的真实评分项。
因此，通用大模型适合做“语言和推理引擎”，不适合直接充当企业事实数据库。
单模型适用场景
改写客户邮件
润色方案摘要
将口语需求整理成列表
生成会议纪要草稿
把技术描述转换为客户语言
这些任务不依赖企业私有事实，或者用户已经把全部必要信息放进当前输入。
三、RAG负责什么
RAG的核心链路是：
用户问题
→ 查询改写
→ 检索企业资料
→ 重排
→ 组装证据
→ 模型回答
在售前场景中，RAG主要解决：
- 产品功能查询；
- 版本差异；
- 案例检索；
- 参数和接口说明；
- 行业方案复用；
- 招标条款定位；
- 标准报价说明；
- 实施边界查询。
RAG的价值
不是简单让模型“知道更多”，而是让回答具备：
内部资料依据
＋版本范围
＋可追溯来源
＋权限隔离
RAG不能自动解决什么
RAG召回文档后，仍可能出现：
- 召回过期资料；
- 把客户定制功能当成标准功能；
- 引用了不适用的行业案例；
- 找到多个冲突版本；
- 模型错误拼接证据；
- 引用正确但结论错误。
因此，RAG还需要：
- 元数据过滤；
- 文档版本；
- 功能状态；
- 权限控制；
- Reviewer；
- 规则校验。
四、Agent负责什么
Agent处理的是多步骤任务和真实动作。
一个售前方案Agent可能执行：
读取客户资料
→ 分析客户行业和规模
→ 解析需求清单
→ 查询产品功能库
→ 查询相似案例
→ 识别功能差距
→ 生成方案目录
→ 分章节生成内容
→ 检查功能承诺
→ 生成待确认问题
→ 发起产品经理审批
→ 导出Word或PPT
这里包含：
- 任务规划；
- 多次RAG检索；
- 调用CRM；
- 调用报价系统；
- 调用文档生成工具；
- 人工审批；
- 状态持久化；
- 失败恢复。
这就是Agent存在的原因。
五、三者的关系不是替代，而是分层
推荐架构：
售前业务应用
↓
Agent流程层
↓
任务规划、工具调用、审批、状态
↓
RAG知识层
↓
产品、案例、招标、制度、报价知识
↓
通用大模型层
↓
理解、推理、生成、结构化输出
可以把它们理解为：
| 能力 | 角色 |
|---|---|
| 通用大模型 | 大脑中的语言与推理能力 |
| RAG | 可检索的企业记忆 |
| Agent | 任务执行和流程控制系统 |
六、只使用通用大模型会发生什么
优点
- 开发最快；
- 成本低；
- 适合快速演示；
- 不需要维护知识库。
问题
- 企业事实错误；
- 功能承诺不可控；
- 无法引用内部资料；
- 无法读取最新版本；
- 无法执行真实业务动作。
只适合：
非事实性文案
＋用户提供完整上下文
＋低风险草稿
七、只使用RAG会发生什么
很多企业把RAG问答界面称为Agent，但它实际只是：
输入问题
→ 检索
→ 回答
它可以回答：
产品是否支持某功能？
某个项目采用了什么方案？
招标文件第几页要求数据备份？
但它不能自动完成：
拆解任务
持续执行
调用多个业务系统
等待人工审批
恢复失败任务
生成最终交付物
RAG是Agent的重要工具，但不是完整Agent。
八、直接使用Agent又会发生什么
如果知识库和功能基线没有治理，就直接搭建Agent，会放大错误。
例如Agent自动完成：
生成方案
→ 生成报价
→ 发给客户
一旦模型把错误功能写入方案，系统会更高效地把错误传播出去。
Agent上线前必须先具备：
- 稳定知识库；
- 产品功能基线；
- 权限体系；
- 工具白名单；
- 人工审批；
- 审计日志；
- 任务预算；
- 幂等机制。
九、售前任务对应的能力选择
| 售前任务 | 通用模型 | RAG | Agent |
|---|---|---|---|
| 文案润色 | 必须 | 不需要 | 不需要 |
| 会议纪要整理 | 必须 | 可选 | 可选 |
| 产品功能问答 | 必须 | 必须 | 不一定 |
| 历史案例推荐 | 必须 | 必须 | 可选 |
| 招标文件问答 | 必须 | 必须 | 不一定 |
| 自动生成完整方案 | 必须 | 必须 | 推荐 |
| 多系统数据收集 | 必须 | 可选 | 必须 |
| 报价和成本计算 | 可选 | 可选 | 必须 |
| 审批流转 | 不负责 | 不负责 | 必须 |
| 对外发送最终文档 | 不应直接负责 | 不负责 | Agent＋人工审批 |
十、一个推荐的售前AI演进路线
阶段一：通用文案助手
功能：
- 需求摘要；
- 文案润色；
- 邮件生成；
- 会议纪要。
特点：
上线快
风险低
但业务价值有限
阶段二：售前知识库
接入：
- 产品资料；
- 案例；
- 行业方案；
- 接口文档；
- 常见问题。
提供带证据的问答和内容生成。
阶段三：方案生成工作流
固定流程：
客户分析
→ 需求拆解
→ 功能匹配
→ 内容生成
→ 风险校验
→ 人工审核
这时可以使用工作流Agent。
阶段四：跨系统Agent
接入：
- CRM；
- 产品管理；
- 报价系统；
- 项目管理；
- 审批系统；
- 文档平台。
阶段五：数据闭环
将后续结果回流：
方案是否中标
哪些内容被客户认可
哪些承诺导致范围变更
哪些功能经常被询问
哪些行业模板转化率高
用于优化知识库、模板和产品规划。
十一、如何判断当前是否需要Agent
可以问五个问题：
1. 任务是否需要多个步骤？
如果只需要一次回答，不一定需要Agent。
2. 是否需要调用真实工具？
例如CRM、报价、审批和文档导出。
3. 是否需要持久化任务状态？
如果任务可能跨越几十分钟或多次人工确认，需要Agent状态管理。
4. 是否需要失败后恢复？
长任务不能失败后从头生成。
5. 是否存在高风险动作？
如果会修改数据、发送文件或形成承诺，需要确定性工作流和人工审批。
满足三个以上，通常值得引入Agent。
十二、模型选择应该放在哪一层
不要让业务代码直接写：
使用某个旗舰模型完成全部任务
可以按任务路由：
需求分类 → 低成本模型
复杂规划 → 强模型
RAG回答 → 平衡型模型
格式抽取 → 小模型
风险复核 → 强模型＋规则
三者分工之后，模型替换不会破坏整个业务架构。
十三、常见错误理解
1. RAG可以消除所有幻觉
RAG只是提供证据，不保证模型正确使用证据。
2. Agent就是会调用工具的大模型
生产Agent还需要状态、预算、权限、审批和恢复。
3. 模型越强越不需要知识库
再强的通用模型也不知道企业最新内部事实。
4. 上了Agent就可以无人审核
售前承诺、报价和合同相关内容必须保留责任人。
总结
在售前场景中，通用大模型、RAG和Agent的正确分工是：
通用大模型负责理解和生成
RAG负责提供可信企业知识
Agent负责执行任务和推动流程
最稳妥的建设顺序不是一步到位搭建全自动Agent，而是：
文案助手
→ 知识库
→ 受控工作流
→ 跨系统Agent
→ 数据闭环
延伸阅读
如果你正在关注企业级 AI 应用、Agent、RAG、MCP 与大模型工程化落地，欢迎访问 智元界：
https://www.zyentor.com/
智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。
