文章摘要企业售前人员经常需要在短时间内完成客户调研、需求分析、产品匹配、案例检索、技术方案、实施计划和风险说明。直接让大模型“生成一份完整方案”虽然速度很快却容易出现功能幻觉、客户信息混淆、章节重复和范围承诺失控。本文从业务流程、系统架构、知识体系、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)SUPPORTEDandclaim.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:0008: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才能从写作助手进入企业生产流程。