咨询公司销售AI智能体设计与落地：从客户画像到方案初稿

咨询行业的销售，尤其是做B端项目制销售的，应该都有这种体会：客户不是逛超市顺手买个方案，而是要走完“陌生接触—需求访谈—方案竞标—商务谈判—内部评估”这一整条链路。客单价高、决策链长、定制化程度高，每一单的售前投入都很大。而售前投入里最消耗人的，反而不是见客户那几次，是见客户前后的大把案头工作：梳理行业背景、整理客户公开信息、从一堆历史项目里找相似案例、搭方案框架、调报价模板。这些事情重复性极强，但每次都要从头再来，因为每个客户都不一样，历史项目的经验又散落在不同顾问的电脑和记忆里。

我在某咨询公司内部主导搭建了一套面向销售团队的AI智能体系统，目标就是把这些案头工作自动化掉。这套系统不是简单挂一个能聊天的机器人，而是一个能根据销售语境自动查知识库、写客户画像、生成方案初稿、跟进商机节奏的内部智能体平台。整套方案从设计到上线花了几个周期，中途踩了不少坑，也有不少可以复用的经验。本文把完整实现方案、关键技术选型、落地细节和教训都整理出来，希望能给正在做同类项目的团队一些直接参考。

1. 为什么咨询公司需要自己的销售智能体

1.1 咨询服务销售的本质难点

咨询公司的销售跟卖SaaS软件很不一样。SaaS软件的交付物相对标准化，产品边界清楚，销售可以在公开资料和竞品对比中完成大部分说明。但咨询服务卖的是“针对你的问题，组建最合适的人，用最适配的方法论，帮你解决问题”，这个价值主张必须在深度理解客户行业和现状的前提下才能说清楚。所以每一次客户沟通，顾问几乎都要提前做一轮mini版行业研究：目标客户在产业链什么位置、最近有什么经营动作、行业有哪些新的政策或技术趋势、竞争对手在做什么。

我观察到的实际情况是，一个资深顾问可能只需要半天就能完成高质量的客户准备，但一个刚入行的销售或顾问，可能要花两三天天，而且查到的资料还未必全。更难受的是，即使资深顾问快速做完了客户背调，方案框架的搭建也依然费力。公司过去十几年的行业案例、方法论文档、报价体系都存在，但分别散落在项目档案、邮件附件、共享盘里，搜索靠文件名，复用靠记忆。这本质上是一个“知识资产无法被组织化调用”的问题，而智能体对应的检索增强生成和结构化输出能力，正好能解决这个场景。

1.2 智能体能解决什么，不能解决什么

这个边界必须想清楚，否则项目很容易做成“什么都想干，什么都干不好”。

我当时的定位很务实：智能体负责“准备”和“初稿”，不负责“决策”和“关系”。所谓准备，指的是客户公开信息的自动整理、行业研究要点的快速检索、相似历史项目的匹配推荐。所谓初稿，指的是基于客户需求自动生成方案框架、沟通纪要、跟进邮件草稿。至于客户关系的建立、关键决策人的信任、谈判策略的取舍，这些必须由人完成，智能体只提供信息支撑。

明确这个边界有两个好处。第一，团队心理上更容易接受这套系统，因为它是助手而不是竞争者。第二，技术实现上复杂度可控，我不需要让智能体去处理那些模糊的、依赖隐性经验的判断，只需要把信息检索和文本生成的准确率做到足够高，就能产生价值。

2. 整体架构与智能体设计

2.1 核心架构：不要做一个大Bot，而要拆成一组小Agent

最早我试过用一个超大的Prompt驱动大模型完成从客户研究到方案写作的整个过程，但效果很不稳定。原因在于，不同环节对上下文的要求完全不一样：客户研究需要读大量长文档并提取要点，方案写作需要严格遵循方法论结构并引用公司案例，跟进邮件需要保持简明得体的商务语气。如果都塞进一个上下文窗口，不仅token消耗巨大，而且模型容易在长任务中“迷失”——写到后面忘了前面的客户信息，或引用了不存在的案例。

后来我换成了“主控Agent + 多个专业Agent”的架构，类似一个小团队流水线。主控Agent不直接干活，它负责接收销售的需求，拆解任务，然后路由给对应的专业Agent执行。每个专业Agent都有一个很小的职责范围，Prompt短而清晰，知识库访问权也严格限定。以下是实际采用的Agent划分：

主控Agent再加一层任务状态管理，每个任务都要明确标记“进行中、等待资料补充、已完成、需人工审核”。这样销售用起来的感觉是：抛了一个需求进去，能看到整个工作的拆解过程，而不是一个黑盒突然吐出一篇内容。

2.2 主控Agent的任务拆解逻辑

任务拆解是整个系统能不能用起来的核心。我给主控Agent定义了一套规则：首先识别用户目标，其次判断完成目标需要哪些信息，然后判断这些信息从哪来，最后决定用哪个Agent、按什么顺序调用。这里的关键是“让Agent意识到不知道什么”，而不是让它假装什么都知道。

我举一个实际场景。销售输入“准备某制造企业的数字化转型咨询提案”，主控Agent会拆成四步：第一步用客户研究Agent生成客户画像；第二步用行业情报Agent检索制造业数字化转型的最新趋势；第三步用历史项目匹配Agent找类似项目案例；第四步用方案撰写Agent结合以上信息生成提案框架。每一步都依赖前一步的输出，如果前一步信息为空，后面的生成就必须明确标注“缺少某项信息，需要补充”。

这相当于一个显式的推理过程。我对主控Agent的Prompt里写了一条规则：只要上游任务没有返回可靠结果，下游任务就必须在输出中声明“以下内容基于假设，未经核实”，不允许自行脑补。这一点在很大程度上抑制了幻觉问题。

有一种快捷的理解方式：整个过程类似接力跑，每一棒跑完必须把一个交接清单交给下一棒，下一棒拿到清单后按清单继续跑，交接棒掉了必须大声喊出来。实际工程实现上，我用的是结构化任务描述而非简单的自由文本对话，每个Agent的输入输出都规定了字段，这样后面做评测和问题追踪才有据可查。

3. 知识库建设：决定智能体智商的关键一步

3.1 知识来源与清洗

很多团队做智能体容易陷入一个误区，一上来就调模型接口，把大量精力花在提示词措辞上，结果发现回答总是不够专业。原因很简单，模型本身的通用知识是“什么都懂一点但不深入”，咨询公司的价值恰恰在于对特定行业、特定类型项目有经过验证的深度经验。这些经验必须通过知识库注入到智能体的生成过程中。

我们搭建知识库时，第一优先级是内部历史项目资料。包括项目结案报告、行业研究PPT、专家访谈纪要、方案终稿、报价单结构。这些资料集中在几块内容：方法论描述、客户痛点分析、项目交付过程、可量化的效果指标。但这些原始文档格式千差万别，PPT里的文字往往只有几个要点，真正的解释在备注里，Word报告可能有一两百页，Excel报价单更是不适合直接切块。所以清洗环节很费时间。

清洗时我坚持几条原则：第一，保留来源信息，每份文档入库前打上项目编号、行业标签、年份、文档类型四个metadata字段；第二，去敏感信息，客户名、联系人、具体金额一律用占位符替换，防止智能体检索到竞标敏感信息后误输出；第三，结构归一化，把PPT每页的标题+正文+备注拼成一段文本，把Word按章节抽取，Excel只保留表头说明和数值范围描述。

这里特别提醒一件事，外部资料如行业白皮书、研报摘要、政策文件也可以入库，但要注意两点：一是版权问题不能直接全文入库做商用，只保留摘要和关键数据点；二是时效性，外部资料必须建立过期自动下线机制，比如超过一年的研报降低检索优先级。

3.2 知识分块、向量化与召回策略

知识库搭建的技术细节会直接影响检索效果。我在分块时并没有用固定字数硬切，因为咨询文档的语义单元往往是“章节”或“主题段落”，硬切会把方法论的前因后果切断。我的做法是优先按文档的二级标题切块，标题下内容过长（超过500字）时再按自然段切分，每个分块之间保留标题作为前缀，重叠控制在10%左右。切好后用Embedding模型做向量化，同步建立关键词索引。

真正检索时不只靠向量相似度。我觉得只做向量召回有两个问题：向量模型对专业术语不够敏感，比如“数字化成熟度”和“数字化评估”语义相近，但“数字化”这个关键词本身可能比语义匹配更有价值；另外，元数据过滤往往才是最高优先级的约束，比如销售明确要“制造业方案”，那应该先按行业标签过滤，再算向量相似度。所以我最终采用的是混合检索方案：

三层跑完会得到一批候选文档，再过一个重排序模型，综合相关性、时效性、来源权威性给最终结果打分。实测下来，混合检索比单用向量检索的命中准确率提升明显，尤其在方案撰写Agent引用的历史案例匹配环节。补充一个经验：重排序模型不要嵌在大模型Prompt里做，这样太慢也容易出格式错误，应该作为独立的服务在检索层完成。

4. 核心销售流程的智能体落地

4.1 客户初筛与建档

客户初筛是销售工作流里最前置、也最容易被忽视的环节。过去销售拿到一个线索，习惯是先上官网看一眼、搜一下新闻，然后凭印象判断这个客户值不值得投入精力。但一个人手动收集信息的覆盖面很有限，而且判断标准不统一，经验丰富的资深顾问会关注战略动向、财务指标、组织架构、近期投资计划这些维度，新人往往只注意到“这个客户看起来很大”。

客户研究Agent把这件事标准化了。我给它配置了一套爬取和解析链路：销售只需要输入客户的官网地址或公司名称，Agent会自动访问公开页面、抓取近期新闻，并用结构化Prompt提取关键字段。输出的客户画像报告包含以下内容：

• 基本信息：行业、总部所在地、员工规模区间、上市状态
• 经营动向：最近财报摘要、重大投资项目、并购或组织调整
• 数字化相关的信号：是否提到数字化转型、智能制造、业务上云、AI应用等关键词
• 可能的痛点假设：基于公开信息合理推断的挑战
• 信息来源清单：每个结论后面都附带原文链接

这套流程跑下来，销售节省了大量搜索时间，更重要的是新人也有了跟资深顾问类似的研究框架，而不是凭感觉乱猜。

有一次我们拿一个中等规模的制造企业做测试，客户官网上并没有明显的数字化信号，但Agent在抓取新闻时发现该企业最近新建了一个海外工厂，且招聘信息里密集出现了“供应链计划”相关岗位。系统据此自动生成了一条判断：该客户近期可能在供应链计划领域存在信息系统升级需求，建议切入时以供应链优化话题开头。这个洞察销售后来实际用了，反馈说客户确实在调研供应链计划软件，沟通气氛立刻不一样。

4.2 方案初稿：从大纲到可交付的框架

咨询销售的方案初稿是工作量最大、最耗时、也最体现专业度的部分。它不是一个“标准化产品说明”，而是“基于客户问题，结合公司方法论和项目经验，给出解决思路”。这个内容写得好不好，直接决定客户愿不愿意继续谈下去。

方案撰写Agent的落地方式如下。第一步，主控Agent把客户画像、行业情报、历史相似项目清单打包传给方案撰写Agent。第二步，方案撰写Agent先从知识库中定位合适的方案模板（比如“战略规划项目模板”“数字化转型落地模板”“组织效能提升模板”），再结合客户画像填充行业情况部分，结合历史项目填充案例部分。第三步，Agent生成完整的提案框架，包括项目背景、客户现状分析、我们的理解、方法论、工作步骤、预期成果、项目周期、团队配置，但明确标注哪些内容需要顾问补充。

在实际提示词里，我对方案撰写Agent做了很严格的限定，包括：只能引用知识库中确实存在的案例和方法论，不允许编造数字；客户现状分析必须注明信息来源；如果有任何信息缺失，输出里必须用醒目标记标出“待顾问确认”。这样生成的初稿不是一份直接能发给客户的成品，但已经具备60%到70%的完成度，顾问只需要聚焦在行业定制、报价和表达风格上。

举一个实际效果：以前一个中级顾问准备一份常规提案框架大约需要一天半，现在在Agent辅助下可以在两小时内完成大框架，再把两三个小时投入到深化行业洞察上。初稿质量对新人尤其有帮助，他们可以直接看到一份合格方案应该包含哪些部分、方法论应该怎么组织、案例引用应该怎么选取。

4.3 跟进节奏与销售漏斗看板

销售不能只靠一次性的大动作，日常跟进才是成交的关键，但很多销售会忽略或遗忘细节：上次沟通提到某位客户总监对成本敏感，这个信息没有记录；客户发了一封邮件问了一个问题，没有及时回复；客户最近发布了财报，里面有一句话值得作为再次触达的由头，没有看到。这类问题听起来很小，丢单却往往就丢在这种小细节上。

销售跟进Agent解决的是记录和提醒的问题。它的工作方式是：销售把每次沟通的核心内容用语音或短文录入系统，Agent自动结构化提取关键要点，更新到客户档案中，生成下一次沟通的准备建议和邮件草稿。这个环节的关键是“低摩擦”，不能要求销售额外做很多标准化录入动作，而是让Agent去消化那些非结构化的记录。

另外，我还做了一个“关键事件触发器”。Agent每天定时巡检目标客户的公开信息，如果发现某个客户发布了年报、新工厂投产、高管变更、获得融资等重大信号，就自动生成一条事件提醒，并附上建议的沟通切入角度。出发点是：与其只记录销售做了什么，不如主动告诉销售“现在重要的事发生了，应该去联系这个客户”。

交付时销售负责人最认可的其实是周报自动汇总功能。以往销售周报需要每个人手动填写本周跟进了哪些客户、进展如何、下周计划是什么，数据还不一定准确。现在Agent可以从客户档案和任务记录里自动生成本周业务摘要，销售只需要补充个人判断，这又节省了一轮机械性时间。

5. 模型选型与提示词工程

5.1 不同任务用不同配置，不要一个模型走天下

大模型选型是项目初期最难下决心的事情之一，因为外部选项多、评价维度杂、更新又快。我当时的策略不是找一个“全能模型”，而是按任务难度配置不同档位的模型服务。简单任务用轻量快速的低成本模型，复杂任务用参数量更大、推理能力更强的模型。这样做既控制成本，也避免重模型在简单任务上因为“想太多”而输出奇怪的内容。

我实际的划分方式如下：

成本方面，我按月做了一个预估模型，公式是：月度成本 = 月调用次数 × 平均输入token数 × 输入单价 + 月调用次数 × 平均输出token数 × 输出单价 + 向量化新增文档预估token成本。实际跑下来最烧钱的不是单次调用价格贵，而是长上下文的调用次数太多。比如方案撰写Agent一次调用就需要携带大量检索片段，如果历史项目匹配模块返回了5个长案例，一次调用的输入就可能超过2万token，这笔钱会迅速累积。控制方法是限制检索返回的TopK数量、对检索片段做摘要压缩、对长对话进行历史总结代替完整保留。

5.2 提示词模板：把“专业感”工程化

大模型通用知识很丰富，但如果直接让它“写一个咨询方案”，产出的内容往往堆满通用套话，缺少咨询公司特有的方法论推理。我不能把整个方法论全都塞进Prompt，因为每次执行的输入情境不同。我的做法是给方案撰写Agent设计一个带推理约束的Prompt模板，核心是要求Agent先经历四个思考阶段，再输出最终内容：

• 阶段一，基于客户画像，列出客户所处的行业特性、可能的经营挑战和数字化现状，但只能引用知识库中关于该行业的信息；
• 阶段二，基于历史项目匹配结果，选择最贴近客户情况的一个或两个案例，说明为什么选择它们；
• 阶段三，将公司方法论拆解为适用于该客户的具体步骤，而不是直接照搬通用框架；
• 阶段四，对缺失信息做明确标注，提醒顾问弥补。

Prompt还强制规定：所有涉及客户行业的数据必须附带来源标记；所有类似“每年提升XX%”的表述，必须在知识库中找到对应的历史项目数据，否则不允许写。业务上还有一个特别的细节，我要求Agent在方案的“我们的理解”部分避免使用“我认为”“我们相信”这类表达，改为“基于对贵司行业现状的分析”，这样可读性更像正式咨询提案。

让我把方案撰写Agent的Prompt简化后展示如下，这里面藏着不少调过的参数细节：

你是某咨询公司的售前方案顾问助理，你的职责是基于已有资料生成提案初稿。 你必须遵守以下规则： 1. 只使用下面提供的【客户画像】、【行业情报】、【历史案例】作为事实依据，不得编造数据。 2. 输出结构必须为：项目背景 / 客户现状分析 / 项目目标 / 方法思路 / 实施步骤 / 预期成果 / 风险提示。 3. 客户现状分析中，凡有数据支撑的信息后必须标注【数据来源：xxx】；无数据支撑的观点必须加前缀“建议核实：”。 4. 引用历史案例时，只描述与本客户需求相关的部分，不展开与主题无关的项目细节。 5. 如果客户画像中缺少关键信息（如预算、决策流程、当前系统），在对应章节输出“待顾问补充”。 6. 语气专业克制，不使用营销式夸张表达。

这段Prompt前前后后调了差不多两周，最后效果稳定下来。另外汇总一个经验：写作类任务的temperature设置成0.7左右比较自然，太低会显得机械重复，太高会飘；抽取类任务直接设成0.1甚至0，务求稳定；分析类任务设0.3，有一些灵活性但不过度发散。

6. 安全、权限与合规：咨询公司的生命线

6.1 数据隔离与脱敏

咨询公司手里的客户数据是高度敏感的，项目交付过程中的战略规划、财务状况、人事调整信息一旦泄露，对公司声誉是毁灭性打击。所以内部智能体投入使用前，安全设计必须通过公司信息安全团队的评审，这是绝对不能跳过的环节。

我做的第一件事是按“客户项目”进行数据隔离。在向量数据库层面，每个客户项目都有独立的存储空间，智能体检索时，主控Agent会读取当前会话所属的客户项目编号，检索服务端再根据这个编号去对应空间里搜索。这样A项目销售看不到B项目的任何文档，哪怕是相似的行业案例也不行，除非该案例已经经过脱敏并被放入公共知识库。

第二件事是输出侧脱敏。内部项目文档中经常出现客户联系人手机号、邮箱、合同金额等敏感字段。我用脱敏模板把这些字段统一替换成“【保密】”或“客户代号”，保证Agent在大模型中检索时不会学习到这些信息。更重要的是，脱敏必须在向量化之前完成，而不是在生成结果之后再做后处理，否则敏感内容有可能残留在模型上下文或日志中。

第三件事是操作权限。不同角色的权限差异很大：销售负责人可以查看团队所有商机的完整摘要；一线销售只能查看自己负责客户的信息；方案顾问可以查看项目方法论文档但不能查看报价明细；新入职实习生只能访问脱敏后的行业公开研究。权限模型是在智能体接入层实现的，不是只在界面层控制。

这里补一个技术层面的建议：不要让大模型自己判断“这条信息有没有权限看”，这类判断必须由应用层的权限服务强制执行。大模型的本职是生成，不该让它承担数据访问控制的责任，否则很容易出现“尝试通过提示词绕过”的风险。

6.2 人工审核机制与置信度标注

即便做了这么多约束，大模型依然可能犯错。因此在系统设计里，我保留了一套人工复核机制，用智能体做“加速和辅助”，用制度做“兜底”。凡是属于以下三类场景之一的输出，必须有人工审核通过后才能正式使用：

• 涉及对外正式交付内容的，包括最终发送给客户的方案邮件、提案文件、报价说明
• 涉及法律或合规相关表述的，比如合同条款摘要、承诺性描述
• 涉及具体数额、百分比、时间承诺的，比如投入资源估算、项目周期预期

为了让人工审核高效，Agent输出时自带置信度标注。比如方案撰写Agent会在文末列出一张“本方案引用了哪些知识库来源”的清单，并标注每个来源的年份和可信等级。它还支持对“客户现状分析”部分做证据标注，如果某句话是“推断”，就明确标为“推断”。质检Agent会跑一遍一致性检查，比如知识库检索结果引用的是不是同一份报告、案例年份是否超过5年未更新，这些检查结果都会附带在审核页面上，审核人不需要重新翻原始文档就能判断风险等级。

对销售团队来说，这个设计反而让他们更信任智能体，因为他们知道系统不会自作主张把不靠谱的内容直接发给客户。

7. 落地实施与迭代节奏

7.1 三阶段推进：不要一开始就铺开全量

内部工具最怕的就是“打造几个月，上线没人用”。所以落地策略我采用了小步快跑的三阶段节奏，每阶段聚焦有限目标，只解决销售团队最痛的一个问题。

第一阶段是MVP验证，我只做“客户研究Agent + 行业情报Agent + 检索问答”。目标很明确：每天销售把想了解的新客户名称发给智能体，它能回一份简洁的客户画像。这两周的任务就是跑通链路，发现哪个环节延迟高、哪类问题回答率低。这个阶段不追求自动化，甚至允许很多场景退化为“人工复制粘贴搜索结果”，但要保证销售体验到“信息获取比原来快”。

第二阶段是试点运营，选一个销售小组跑“方案初稿”的闭环。试点组成员需要有代表性，不能全是技术接受度高的年轻人，要有一个老资历的顾问，因为老顾问的反馈对系统专业度的提升极有价值。这个阶段我每周和试点组做一次复盘，收集三个问题：哪些输出可以直接用、哪些输出需要大改、哪些输出干脆不用。根据反馈持续调知识库和Prompt。

第三阶段才是全量推广，接入所有销售成员、打通CRM、启用跟进Agent和漏斗看板。全量推广的前提是配置了完善的培训材料和帮助文档，并且有一位内部“智能体推广负责人”来持续讲解使用场景。实际推广中最有效的手段不是培训PPT，而是每周发布“本周Agent帮团队做了什么”的实例报告，让销售人员直接看到同事的使用成果。

7.2 销售团队不抵触的几个关键做法

工具落地最大的障碍往往不是技术而是人。我在推进过程中体会到：只要这个工具被理解为“监控”或“替代”，大家就会消极抵抗；如果被理解为“帮自己减负”和“提升话语质量”，接受度就会高很多。

第一条经验，不要要求销售人员把Agent写的东西原封不动发出去。Agent定位是“第一稿助手”，哪怕只有一半能派上用场，也已经省了很多时间，而完整的终稿必须由销售自己打磨和把关，这既是质量保障，也是给销售保留专业掌控感的空间。

第二条经验，让智能体学习销售自己的表达风格。我在客户档案设计里增加了一个“常用表达”字段，销售可以把他们平时常用的开场白、案例描述的偏好、邮件惯用语录入进去，方案和邮件生成时会优先参考这些个人风格。这样做的好处是销售看到的输出不是“别人写的”，而是“自己风格的草稿”。

第三条经验，跟销售考核指标挂钩，但不直接考核使用次数，而是考核“从智能体节省的时间是否重新投入到客户关系上”。比如使用客户研究Agent后，销售可以在首次拜访前增加一次电话预沟通，这部分时间应该体现在跟进记录里。销售负责人只要看到这个正向循环，就自然会要求团队多用。

8. 常见问题与教训总结

8.1 幻觉与知识过时

幻觉是大模型应用绕不开的问题。我处理幻觉不指望模型不犯错，而是让系統把“不知道”说出来。前面已经提到，Agent输出必须标注信息是否来自知识库、是否经过人工审核。实践中最有用的一个细节是：给知识库的每条内容标一个准确到“年-月”的发布日期，当客户问“最近一年的行业趋势”时，Agent只检索发布时间在一年内的文档，并在输出里标注“以下信息来自xx年xx月的xx报告”。这样即使被引用的报告本身有错，审核人也能及时发现。

但知识库会不断过期，所以我设计了一个月度刷新机制。每个月末自动对库内所有文档生成一份“过期评分”，内容包括：文档发布时长、是否被近期检索命中、与该主题相关的最新文档是否已入库。评分较低的文档自动降权甚至下线。这个机制最开始是手工维护的，后来改成半自动，因为咨询项目的知识产出速度很快，完全手工跟不上。

8.2 销售人员用不起来

销售人员不愿意用内部工具的现象太普遍了，多数时候不是懒，而是工具太难用。我在早期犯过一个错误：把智能体做成一个独立的Web页面，虽然功能齐全，但销售需要切换系统、复制粘贴文本、还要自己组织提问。真实场景里，销售是在企微/飞书里跟客户聊完，立刻就要用系统，如果还要开一个新页面，很多人就放弃了。

后来我把智能体嵌入到企业IM里，销售在聊天窗口直接@机器人，用自然语言提交请求，结果在工作台里异步生成。还把输出内容格式做了统一：表格优先、要点短句、不要大段散文。系统会用“【回复可直接发送】”和“【内部参考，请勿直接发送】”两种标签区分输出用途，销售不需要再猜能不能直接用。这两个改动上线后，使用率明显提升。

8.3 成本失控

前文已经提到长上下文是成本大头。另一个容易忽视的成本点是Embedding调用次数。项目早期我在每次检索前都会重新计算所有文档的向量，后来优化为“文档入库时生成一次向量，查询时复用”，并增加向量缓存和增量更新。模型API层也设置了每日预算告警，超过阈值自动降级到低档模型，防止某次异常调用造成巨额账单。

有一个更实用的成本优化办法：不压缩Prompt就永远省不了钱，所以我增加了一个“上下文压缩Agent”，在将历史案例、会议记录传给方案撰写Agent之前，先用一次小模型调用把内容压缩成要点。压缩后的信息虽然损失了一些细节，但对于方案框架生成来说，要点粒度已经足够，成本能下降一半以上。

8.4 评测怎么做

内部工具上线前如果没有评测机制，后期迭代很容易是“凭感觉改Prompt”。我建了一个评审集，包含50个典型销售任务，覆盖客户研究、方案初稿、跟进邮件、知识问答这几类，每个任务都有明确的优秀答案标准，比如“客户画像是否包含行业和经营动态”“方案是否引用了真实项目”“邮件语气是否正式”。每周跑一次评审集，对每个输出做三个维度的打分：事实准确性、结构完整性、风格专业度。

这个机制帮助我发现过不少隐含回归问题。比如有一次某个Agent的Prompt微调导致它在客户画像报告里经常输出“该客户可能在XX方面有挑战”，但缺失了信息来源标注。这类问题如果没有评测集，根本不会注意到。评测集也需要每个月根据真实使用反馈补充新题目，因为新客户类型、新业务方向会不断出现。

写在最后的一点体会

回头看我主导搭建的这个内部销售AI智能体，最大的感悟是：不要把智能体项目做成一个“技术展示平台”，而要从销售团队最具体的痛点出发，小步迭代。技术选型、Prompt优化、知识库搭建这些当然重要，但真正让系统活下来的，是销售每天打开聊天窗口，提出问题，然后得到一份能用、可信、省时间的答案。

如果你也想在类似的组织里推动这样一个项目，我的建议是先从客户研究这一个环节做起，它信息量大、判断标准清晰、容错空间大，是最容易让团队尝到甜头的切入点。跑通之后再做方案初稿跟进提醒，逐步扩大覆盖面。这个路线我们走过，效果稳定，供你参考。中间有一步卡住的话，欢迎对照本文的实现细节逐项排查，大概率能定位到是知识库覆盖不足、模型配置不当还是提示词约束不够。