文章摘要

企业售前人员经常需要在短时间内完成客户调研、需求分析、产品匹配、案例检索、技术方案、实施计划和风险说明。直接让大模型“生成一份完整方案”，虽然速度很快，却容易出现功能幻觉、客户信息混淆、章节重复和范围承诺失控。本文从业务流程、系统架构、知识体系、Planner、RAG、Reviewer、人工审批、状态持久化与效果评测等方面，完整设计一个可进入生产环境的企业售前方案生成Agent。

一、为什么售前方案适合使用Agent

售前方案不是单次文本生成任务。

一个真实方案往往需要：

理解客户背景 → 分析业务问题 → 整理需求 → 匹配产品能力 → 查找行业案例 → 识别能力差距 → 设计总体架构 → 编写实施计划 → 评估周期和风险 → 生成待确认问题 → 多角色审核 → 导出Word或PPT

其中包含：

• 多份文档；
• 多次知识检索；
• 多个业务系统；
• 多个责任角色；
• 多轮人工修改；
• 长时间任务；
• 正式业务承诺。

这类任务比普通聊天更适合使用：

工作流骨架 ＋Planner任务拆解 ＋RAG知识检索 ＋工具调用 ＋Reviewer复核 ＋人工审批

二、先明确系统边界

售前方案Agent可以负责：

• 读取客户资料；
• 生成需求摘要；
• 将需求映射到产品功能；
• 检索相似案例；
• 生成方案草稿；
• 标记不确定项；
• 检查功能承诺；
• 生成待确认问题；
• 组织实施计划草稿；
• 根据模板导出文档。

不应自动负责：

• 批准最终报价；
• 承诺定制范围；
• 确定研发排期；
• 承诺性能指标；
• 发送最终方案给客户；
• 修改合同条款；
• 代表产品、研发或法务签字。

系统定位应该是：

AI负责收集、分析、起草和校验，人对正式承诺负责。

三、总体系统架构

推荐分为八层：

1. 用户与工作台层 2. 任务编排层 3. Agent执行层 4. 企业知识层 5. 工具与系统集成层 6. 模型服务层 7. 治理与安全层 8. 数据与可观测性层

完整链路：

售前工作台 → 创建方案任务 → 上传客户资料 → Planner拆解任务 → RAG检索产品、案例和行业知识 → Agent逐章节生成 → 规则引擎校验 → Reviewer复核 → 产品、技术、商务人工审批 → 文档导出 → 结果与修改数据回流

四、工作台需要哪些功能

1. 项目基本信息

客户名称 行业 区域 项目名称 项目阶段 预计金额 负责人 截止时间 保密等级

2. 输入资料

支持上传：

• 客户需求文档；
• 招标文件；
• 会议纪要；
• 客户现状材料；
• 原有系统清单；
• 数据字典；
• 现场调研记录；
• 邮件和答疑文件。

3. 生成范围选择

用户可以选择：

需求分析 总体方案 功能方案 技术架构 系统集成 实施计划 服务方案 风险说明 报价说明 投标响应表

不要每次都生成整本方案。

4. 人工编辑与证据查看

每一段方案应支持：

• 查看引用证据；
• 查看功能状态；
• 标记错误；
• 重新生成；
• 锁定段落；
• 提交审核；
• 查看版本差异。

五、任务状态机

方案生成是长任务，必须有状态。

建议状态：

CREATED MATERIAL_PARSING REQUIREMENT_ANALYZING PLANNING GENERATING REVIEWING WAITING_CONFIRMATION WAITING_APPROVAL EXPORTING COMPLETED FAILED CANCELED

状态转换示例：

CREATED → MATERIAL_PARSING → REQUIREMENT_ANALYZING → PLANNING → GENERATING → REVIEWING ├─ 存在待确认项 → WAITING_CONFIRMATION ├─ 需要审批 → WAITING_APPROVAL └─ 通过 → EXPORTING → COMPLETED

失败后不应从头开始，而应记录失败步骤并恢复。

六、第一步：客户资料解析

资料解析不能只提取纯文本，还应提取结构。

输出统一材料对象：

{"material_id":"MAT-001","type":"CUSTOMER_REQUIREMENT","title":"渠道数字化建设需求","source_file":"客户需求V2.docx","sections":[{"section_id":"SEC-01","title":"项目背景","content":"……","page_start":1,"page_end":2}],"tables":[],"attachments":[],"confidentiality":"PROJECT"}

解析时需要处理：

• Word标题层级；
• PDF页码；
• 表格；
• 扫描件OCR；
• 图片说明；
• 附件关系；
• 重复页面；
• 页眉页脚。

七、第二步：需求结构化

客户原始需求通常不完整、重复甚至冲突。

需求Agent应输出：

{"requirement_id":"REQ-023","category":"渠道管理","original_text":"总部需要看到经销商后面的货去哪了","normalized_requirement":"追踪经销商到终端的商品流向","business_object":"商品流向","priority":"HIGH","mandatory":true,"source_ids":["MAT-001-SEC-04"],"questions":["是否要求追踪至单店？","经销商是否使用现有进销存系统？"]}

需求分析应完成：

去重 归类 优先级识别 强制项识别 业务对象识别 系统边界识别 待确认问题生成

八、第三步：需求与产品能力匹配

匹配不是让模型凭印象判断。

每条需求应对应：

完全匹配 部分匹配 需要配置 需要集成 需要定制 当前不支持 需要确认

匹配结果：

{"requirement_id":"REQ-023","match_type":"PARTIAL","features":[{"feature_id":"F-TRACE-018","status":"GA","coverage":"支持经销商出库和终端收货"}],"gap":"客户现有二批系统接口尚未确认","recommendation":"第一阶段完成经销商和终端流向，二批接口在详细设计阶段确认","evidence_ids":["DOC-TRACE-2026-3.1"]}

只有明确匹配结果后，才能进入方案生成。

九、知识库应该如何分域

Agent至少需要六个知识域：

1. 产品功能库

提供标准能力、版本、限制和负责人。

2. 行业方案库

提供行业业务对象、典型问题和解决路径。

3. 客户案例库

提供已落地范围、效果和可公开程度。

4. 技术架构库

提供部署、安全、接口、性能和运维基线。

5. 实施交付库

提供阶段、角色、周期估算和交付物。

6. 风险边界库

提供不能承诺的内容、常见失败和待确认事项。

检索时先按知识域过滤，再做混合召回。

十、Planner如何拆解方案任务

Planner不应该自由生成任意步骤，而应基于标准模板生成受控计划。

示例：

{"plan_id":"PLAN-20260719-001","objective":"生成渠道数字化售前方案","steps":[{"id":"S1","type":"ANALYZE_CUSTOMER","dependencies":[]},{"id":"S2","type":"NORMALIZE_REQUIREMENTS","dependencies":["S1"]},{"id":"S3","type":"MATCH_FEATURES","dependencies":["S2"]},{"id":"S4","type":"GENERATE_SOLUTION","dependencies":["S3"]},{"id":"S5","type":"REVIEW_CLAIMS","dependencies":["S4"]},{"id":"S6","type":"HUMAN_APPROVAL","dependencies":["S5"]},{"id":"S7","type":"EXPORT_DOCUMENT","dependencies":["S6"]}]}

Step Type必须来自白名单，防止Planner创造不存在的动作。

十一、分章节生成，而不是一次生成整本方案

一次性生成几十页方案容易产生：

• 章节重复；
• 前后口径不一致；
• 上下文过长；
• 引用来源混乱；
• 修改局部时全篇变化；
• 失败后无法恢复。

推荐按章节执行：

项目理解 业务痛点 建设目标 总体架构 功能方案 技术架构 实施计划 服务保障 风险和边界

每个章节有独立输入：

章节目标 客户需求 允许功能 行业知识 案例 写作模板 禁止内容 输出Schema

十二、章节生成的结构化中间结果

{"section_id":"SOL-04","title":"总体解决方案","summary":"……","paragraphs":[{"paragraph_id":"P-001","text":"……","claim_ids":["C-001","C-002"],"evidence_ids":["DOC-01","DOC-02"]}],"unresolved_questions":[],"risk_flags":[]}

先生成结构化结果，再渲染为Markdown、Word或PPT。

十三、Reviewer应该检查什么

建议设置三类Reviewer。

1. 事实Reviewer

检查：

• 功能是否存在；
• 版本是否匹配；
• 证据是否支持结论；
• 案例是否真实；
• 数字是否有依据。

2. 范围Reviewer

检查：

• 标准与定制是否区分；
• 客户责任是否说明；
• 第三方依赖是否说明；
• 二阶段能力是否误写入一期；
• 是否出现未经确认的周期。

3. 文档Reviewer

检查：

• 章节结构；
• 重复内容；
• 术语一致性；
• 客户名称；
• 标题层级；
• 表格完整性；
• 是否符合公司模板。

Reviewer输出：

{"passed":false,"issues":[{"severity":"HIGH","type":"UNSUPPORTED_CLAIM","location":"SOL-04/P-001","message":"自动补货功能没有GA证据","suggestion":"改为二阶段定制建议"}]}

十四、确定性规则不能缺少

以下规则应由代码完成：

没有Evidence ID的功能声明不允许通过 非GA功能不能使用“已支持” 报价没有审批编号不能导出 证书过期不能引用 客户名称必须来自项目主数据 性能数字必须关联测试报告 高风险段落必须有人审核

伪代码：

defvalidate_proposal(proposal:dict)->list[dict]:issues:list[dict]=[]forclaiminproposal.get("claims",[]):ifnotclaim.get("evidence_ids"):issues.append({"type":"MISSING_EVIDENCE","claim_id":claim.get("claim_id")})if(claim.get("claim_type")=="SUPPORTED"andclaim.get("feature_status")!="GA"):issues.append({"type":"INVALID_COMMITMENT","claim_id":claim.get("claim_id")})returnissues

十五、工具注册与权限设计

Agent可能调用：

search_customer read_crm_project search_product_features search_cases calculate_estimate create_approval export_word export_ppt

每个工具需要：

工具名称 输入Schema 输出Schema 允许角色 风险等级 超时 重试 幂等规则 审计字段

示例：

{"tool":"export_proposal","risk_level":"MEDIUM","allowed_roles":["PRESALES","MANAGER"],"requires_approval":true,"idempotent":true}

模型只能建议调用，真正授权由服务端完成。

十六、人工审批流程

推荐至少三道审核：

产品审核

确认产品能力、版本和定制范围。

技术审核

确认架构、接口、安全、性能和实施可行性。

商务审核

确认报价、周期、付款和服务条款。

审批记录：

{"approval_id":"APR-001","proposal_version":7,"role":"PRODUCT_OWNER","status":"APPROVED","comments":"自动补货已调整为二阶段定制","approved_at":"2026-07-19T18:30:00+08:00"}

方案内容发生关键修改后，应使相关审批失效并重新提交。

十七、版本管理

方案至少需要：

版本号 父版本 修改人 修改类型 变更摘要 生成模型 Prompt版本 知识库版本 审批状态

版本示例：

V0.1 AI初稿 V0.2 售前修改 V0.3 产品审核修改 V0.4 技术审核修改 V1.0 最终对外版

对外文件必须能追踪到内部版本。

十八、数据表设计

方案任务表

proposal_task ├── task_id ├── project_id ├── customer_id ├── status ├── current_step ├── template_id ├── knowledge_snapshot_id ├── created_by ├── created_at └── updated_at

需求表

proposal_requirement ├── requirement_id ├── task_id ├── source_id ├── category ├── normalized_text ├── priority ├── mandatory └── status

功能匹配表

requirement_feature_match ├── requirement_id ├── feature_id ├── match_type ├── gap ├── evidence_ids └── reviewer_status

章节表

proposal_section ├── section_id ├── task_id ├── version ├── title ├── content_json ├── status └── locked_by

十九、失败恢复与幂等

长任务必须支持：

步骤级Checkpoint 章节级重试 工具调用幂等 任务取消 从失败步骤恢复

例如文档导出工具的幂等键：

proposal_id ＋version ＋template_id ＋format

重复请求不能生成多个不同文件并造成用户混淆。

二十、模型路由策略

不同任务不需要全部使用最强模型。

材料分类 → 小模型 需求标准化 → 平衡型模型 方案规划 → 强模型 简单章节生成 → 平衡型模型 风险复核 → 强模型＋规则 标题和摘要 → 小模型

还可以按内容风险路由：

普通介绍 → 自动生成 功能承诺 → 强模型＋证据校验 报价周期 → 不由模型决定 合同安全 → 人工负责

二十一、Prompt版本管理

Prompt不能散落在代码中。

每个Prompt记录：

prompt_id version task_type system_prompt input_schema output_schema model_constraints owner status

上线新Prompt前，使用固定测试集回归。

二十二、质量评测体系

建议建立四组指标。

1. 事实质量

功能事实准确率 证据覆盖率 错误案例引用率 过期知识命中率 数字无依据比例

2. 方案质量

需求覆盖率 章节完整率 重复内容比例 客户针对性评分 人工修改率

3. 流程效率

初稿生成时间 平均审核轮次 平均完成时间 失败恢复率 人工节省时间

4. 业务结果

方案使用率 中标率变化 客户反馈 范围变更次数 错误承诺数量

不能只统计生成了多少字。

二十三、一个合理的MVP范围

第一版不要直接接报价和外发。

建议MVP包含：

上传客户资料 → 需求结构化 → 产品功能匹配 → 生成方案目录 → 生成三个核心章节 → 显示证据和待确认项 → 人工编辑 → 导出内部草稿

暂不包含：

• 自动报价；
• 自动发送客户；
• 自动承诺工期；
• 自动生成合同；
• 无审批导出最终版。

二十四、90天实施路线

第1—30天：知识和MVP

完成：

• 产品功能基线；
• 三个行业模板；
• 20个历史项目清洗；
• 客户材料解析；
• 需求结构化；
• 核心章节生成。

第31—60天：流程和审核

完成：

• 功能匹配；
• 证据链；
• Reviewer；
• 人工审批；
• 版本管理；
• Word导出。

第61—90天：系统集成和评测

完成：

• CRM集成；
• 产品系统集成；
• 项目模板；
• 测试集；
• 指标看板；
• 小范围试点。

二十五、最容易失败的五个地方

1. 没有产品功能基线

模型不知道什么能承诺。

2. 直接使用全部历史方案

错误和过期内容会被复用。

3. 追求全自动

正式承诺没有责任人。

4. 一次生成整本文件

无法校验、恢复和局部修改。

5. 只关注文案质量

没有统计事实错误、范围风险和人工修改。

二十六、最终推荐架构

固定业务工作流 ＋受控Planner ＋分域RAG ＋结构化Claim ＋确定性规则 ＋多角色Reviewer ＋人工审批 ＋版本和审计

智能应该用于提升分析和生成效率，控制权必须留在系统和责任人手中。

总结

企业售前方案生成Agent不是“输入客户名称，自动生成一份PPT”的演示工具。

真正可用的系统需要把售前工作拆成：

材料 需求 功能 证据 章节 风险 审批 交付

并让每一条产品能力、技术承诺和实施结论都可追溯。

只有做到：

模型负责智能 规则负责边界 系统负责流程 人负责承诺

售前方案Agent才能从写作助手进入企业生产流程。