去年我花了小半年时间把一个“能自动找客户、给客户打标签、再预测谁最可能成交”的销售 Agent 从零搭起来了。这个项目后来在团队里稳定运行把市场部沉淀多年的公开线索池全部接进来线索生成环节的无效量从 40% 压到 15% 以内转化预测模型在严格的时间外验证下 AUC 做到 0.82 左右。整个过程踩了不少坑尤其是把线索生成、客户画像、转化预测这三块串成一条完整链路的时候数据口径、特征时序、模型评估各种问题一起冒出来。这篇文章就把完整链路和踩坑点完整捋一遍给正在做销售数字化、CRM 智能化的产品经理、算法工程师和业务负责人参考。这个 Agent 不是一个单一的大模型而是一整套工程系统线索从公开渠道采集进来经过清洗和匹配生成候选池然后给每个客户打上结构化的画像标签最后用模型预测转化概率把结果按分数排序推给销售跟进。它解决的核心问题很朴素销售团队每天时间有限与其让他们自己翻资料、凭感觉找客户不如让系统把“谁值得联系、为什么值得、现在联系还是过两周再联系”提前算好。适合谁来参考一类是公司里负责销售工具链的算法工程师另一类是手握客户数据但不知道怎么用起来的业务负责人还一类就是像我一样从零开始搭整套系统的“全栈打杂选手”。1. 整体链路设计与方案选型1.1 为什么拆成三条流水线而不是一个大模型最开始我也认真考虑过一种“偷懒”的方案把所有客户资料喂给一个语言模型输入公司名直接输出“高/中/低意向”。试了一轮之后放弃了原因有三个。第一个原因是三个环节的数据特征差异太大。线索生成面对的是非结构化的文本资料可能是公司简介、官方网站上的产品词、招聘信息里的业务描述客户画像需要的是结构化的标签推论比如“这家公司规模在 100 人左右、近 30 天有活跃行为”转化预测本质上是一个时间序列问题必须严格区分“在某个时间点之前知道什么”和“之后发生了什么”。三个问题用同一种模型硬做最后必然是各方面都平庸。第二个原因是更新频率不匹配。线索生成可以每天批量跑一次客户画像的行为部分需要准实时更新而转化预测更适合按批次刷新——因为预测结果太频繁变化销售根本没法安排跟进计划今天看是高意向明天变低了人就会彻底不信任系统。拆成独立的流水线之后每个环节可以按自己的节奏迭代不会有“改一个匹配规则画像标签也得跟着重新训练”这种连锁反应。第三个原因是最关键的可解释性。销售团队天然抵触黑盒系统。你告诉他“这个客户得分 0.87去联系吧”他一定会问凭什么。线索生成环节给出匹配理由画像环节明确展示标签依据预测环节输出命中特征和行动建议每一层都可解释销售才愿意把你的输出当参考。否则系统做得再准前端业务不用就是零。最终落地的架构并不复杂一个调度器每天按编排好的顺序执行“采集、清洗、规则匹配、向量匹配、画像标注、模型预测、结果回写”这几个步骤各步骤之间通过数据库表和消息队列解耦。任何一个环节升级不影响其他环节。1.2 数据来源与合规边界销售 Agent 的地基是数据但数据获取这一步最容易出事。我做线索生成时给自己定了一条硬约束只使用公开信息。具体来说有三类来源。第一类是企业公开工商信息包括公司名称、注册地、行业分类、注册资本、经营范围这些信息来自依法公示的公开渠道。第二类是行业展会和活动的公开报名信息但必须做脱敏处理不能直接用报名表里的电话和邮箱只能提取“这家公司参加过什么主题的活动”这个意图信号。第三类是公司官网和公开新闻里主动披露的业务描述、联系方式这些本身是公司希望被外部看到的公开内容。很多人会劝你“买数据”“爬私有平台的数据”我强烈建议不要碰。一方面有法律风险不该用的数据来源会直接让整个系统失去合规基础另一方面从商业角度也不划算。我踩过的一个教训是曾经拿到一批“看起来很丰富”的关系网数据导入之后发现电话号码错号率超过六成最后还得全部清洗掉。数据质量远比数据量重要这是做线索生成绕不开的第一课。1.3 技术栈与资源选型这套系统的技术栈非常主流没有任何冷门框架核心原因就是团队维护成本必须低。采集层用 Python 的 requests 加 Playwright。大部分公开页面用普通请求就能拿到遇到少数需要渲染的页面再用无头浏览器兜底。清洗和特征加工用 pandas数据量在几十万到百万级别单机内存完全够用。任务编排用的 APScheduler 加一张数据库队列表没有引入重型调度框架——因为链路只有十几个任务复杂调度器反而增加运维负担。特征和画像的存储用 MySQL 宽表加 Redis 热点缓存向量相似度计算直接全内存跑开源中文向量模型编码后归一化点积几万条候选向量计算出结果只需要秒级。模型层主力是 LightGBMXGBoost 做交叉验证对比。对外统一用 FastAPI 封装成服务CRM 系统只需要调一个接口就能拿到线索列表和预测评分。这套选型的逻辑很简单能用单机解决的不用分布式能用 SQL 解决的不用引入大数据组件能用一个团队熟悉的语言解决的就不要搞异构系统。我见过不少团队上来就上全套大数据框架结果数据量连一张宽表都填不满纯属给自己添麻烦。2. 线索生成模块从零实现2.1 候选线索池的构建与清洗线索生成的起点是候选池。这一步别急着上模型先把数据管道做扎实。我做的第一版采集任务特别粗糙就是定时去抓公开页面然后把内容整段塞进数据库。上线第二天就出问题了同一条线索因为来源不同被插入了五次销售跟进列表里出现大量重复还有一些页面抓下来带着乱码和广告位文字直接导致后续相似度计算质量下降。后来我把清洗流程拆成五步每一步都有明确产出第一步去重用“行业 地域 联系人归一化 域名”拼接成指纹MD5 后建唯一索引第二步去噪剥离 HTML 标签、去掉导航栏文案和版权声明这类重复内容第三步字段标准化统一公司名简称、统一地域写法第四步联系方式校验号码长度、号段规则都要过一遍明显无效的剔除第五步给每条线索标记来源和首次入库时间方便后续监控数据新鲜度。这里有一个经验数据新鲜度一定要监控。我踩过的坑是某个数据源连续两周没有增量更新但采集任务一直显示“运行成功”因为 HTTP 请求返回了 200 但页面结构已经变了解析结果为空。所以在线索表里一定要维护“最近更新时间”字段调度器每次检查超过阈值就告警。数据源断更这种问题不会立刻报错但会像慢性病一样腐蚀整个 Agent 的输出质量。2.2 规则引擎与向量召回的双通道匹配线索生成的核心是“匹配”。我最终采用的是规则引擎加向量召回双通道而不是单纯跑一个模型。规则引擎解决的是业务硬约束。比如“只做华东地区的制造业客户”“排除注册资本低于 100 万的个体工商户”“排除已知黑名单行业”。这些约束用规则写死清晰透明也方便业务方直接提需求。规则引擎的产出是候选集 A保证每一条候选都符合基本业务边界。向量召回解决的是长尾机会。把公司简介、主营产品、官网业务描述用文本向量模型编码和理想客户画像向量做相似度计算取 top N 作为候选集 B。这部分能发现规则匹配不出来的机会比如一家公司官网写着“提供柔性生产线解决方案”但工商经营范围里只有“机械设备销售”光靠关键词规则怎么都匹配不上向量却能抓到语义上的相关性。双通道的合并逻辑是候选集 A 全部保留候选集 B 中与 A 不重合的部分按相似度阈值截断后加入。我实测下来单规则通道的有效线索率在 35% 左右单向量通道在 28% 左右双通道合并之后有效线索率提升到了 45%因为规则通道保证了底线向量通道补足了多样性。这里说的“有效线索”定义是销售人工确认“这家公司确实有潜在需求”的比例后面要按这个口径持续统计。2.3 匹配阈值怎么定才不是拍脑袋向量召回必须要有一个相似度阈值这一步最容易犯的错误是凭感觉定一个 0.6 或者 0.7 就开始跑。我在项目里做了一轮阈值扫描方法很简单把历史候选数据按相似度分桶从 0.5 到 0.75 每隔 0.05 算一组指标每组都统计覆盖率、精准率、有效线索率然后画成曲线看拐点。结果非常有意思阈值在 0.6 以下的时候覆盖率虽然高但有效线索率只有 20% 出头拉到 0.65 的时候覆盖率掉了 15%但有效线索率升到了 38%再往上拉到 0.7覆盖率又掉一大截有效线索率只增加两个百分点。所以我的选择是 0.65因为从业务角度看覆盖率损失可以接受而精准率提升是实打实的——销售每天能打的电话数量是固定的与其给他们 100 条碰运气的线索不如给 60 条更有把握的。另外匹配结果一定要给销售留一个人工驳回入口。销售在跟进列表里点“不相关”并选择原因这些数据会回流到负样本池既用于后续调阈值也用于模型训练。没有这个反馈闭环匹配质量永远不会变好。3. 客户画像模块从标签到动态更新3.1 三层特征体系怎么搭客户画像不是简单贴几个标签了事我把它拆成了三层特征体系。第一层是身份特征包括行业、地域、规模区间、成立年限、注册资本区间。这些特征相对静态来自采集和清洗阶段的结构化字段是画像的底色。第二层是行为特征包括访问官网频次、打开邮件次数、下载资料次数、发起询盘动作。行为来自埋点和业务系统的操作日志要求实时性好是判断客户当前兴趣度的核心。第三层是意向特征包括模型预测分区间、最近活跃时间、关键词命中强度、线索来源质量分。意向特征部分是模型输出回传的结果部分是规则计算的衍生指标。三层的关系可以这么理解身份特征决定“这家公司是不是我们的菜”行为特征决定“他最近有没有对我们的菜动心”意向特征决定“现在是不是推一把的最佳时机”。单看任何一层都会失真。我见过一个极端例子一家身份特征非常匹配的客户行为特征全为零如果只看身份特征会给高分但实际跟进发现对方需求已经转移了反过来也有身份特征不太匹配但连续两周高频访问定价页面的客户最后反而成交了。3.2 标签存储与冷启动更新策略标签存储这块很多人会过度设计动不动就上图数据库。我这次用非常朴素的方式解决了一张客户主表存身份特征和静态标签一张行为汇总表存统计类特征一张 JSON 扩展列存动态标签。单表一百万级别的客户配合 Redis 缓存热点数据查询性能完全够用开发效率还高。动态标签必须考虑时间衰减。我的策略是行为特征按时间窗口计算比如近 7 天、近 30 天、近 90 天的访问次数分别统计意向标签则做加权衰减30 天无任何动作的客户意向分自动下降一档。标签不是贴上就永远有效的客户的兴趣会衰退你的标签体系也得跟着腐烂。冷启动是新线索绕不开的问题。没有行为数据的客户唯一的依据就是身份特征和线索生成阶段的匹配分。我的处理方式是冷启动客户先打一个“待观察”标签预测分数给一个中性偏保守的值等行为数据积累超过一周再进入正式画像计算。实测这样做的好处是避免了大量冷启动客户被高估意向销售跟进无效电话的投诉明显减少。3.3 画像质量验证不要相信拍脑袋标签画像模块最容易出的事是工程师觉得标签体系设计得很完美但业务根本看不懂。我在上线前做了一次标签可用性评审从线上随机抽了 100 条已标注客户让销售团队人工核实“这个标签是否符合你对这家公司的了解”。结果三档分布是符合 62 条模糊 26 条不符合 12 条。模糊和不符合加起来快四成了说明标签定义和业务的认知有偏差。比如我把“活跃”定义成“近 30 天有任意行为”但销售认为“活跃”必须是“有实质互动比如打开邮件或点击链接单纯访问不算”。后来把标签口径重新对齐把“弱活跃”和“强活跃”分开模糊比例降到了 15% 以内。画像验证这件事要周期性地做不能上线验一次就再也不管。数据分布会漂移业务重点会调整标签体系也需要持续维护否则三个月后画像就成了一堆没人看的僵尸标签。4. 转化预测模块模型与样本工程4.1 正负样本定义与观察期设置转化预测是整个 Agent 里最讲究“科学方法”的模块。第一步就是定义清楚什么是正样本、什么是负样本这一步如果定义错了后面所有模型工作都白做。我用的正样本定义是线索进入系统后 90 天内发生有效询盘或成交标记的客户。负样本定义是90 天内销售关闭且没有任何有效互动的客户。注意这里加了一个“进入系统 90 天”的观察期约束——只有观察期内没有被标记为成交也没有被关闭的客户才能作为样本进入模型训练。为什么不能简单把“当前已经是客户”的标成正样本、把“还没成交”的标成负样本因为那些“还没成交”的客户可能只是还在跟进中把他当负样本会严重扭曲模型。样本定义还有一个容易踩的坑正负样本比例。销售场景下正样本往往很少可能只有 5% 到 10%。这个比例下 LightGBM 很容易出现“全预测为负样本”的偷懒行为所以训练时要设置正负样本权重或者用采样策略让模型见到的正例比例提高到 20% 左右。我整理样本集时最终保留了约 8 万条观察期内的样本正样本占比 7%按正负 1:4 的权重配比训练。4.2 时间穿越陷阱与特征一致性时间穿越是我在这个项目里踩过最大的坑没有之一。典型表现是验证集上的 AUC 高达 0.9 以上看着爽到不行一上线就效果崩盘。原因就是特征工程里用了“未来数据”。举个例子我要在 T 日预测某个客户会不会在未来 90 天内转化那么模型输入只能包含 T 日之前能拿到的信息。我做特征的时候好的一版是“截至预测日止近 30 天访问次数”坏的一版是直接用整张汇总表里“总访问次数”——后者包含了预测日之后才发生的行为在训练时等于偷偷看了答案。防止时间穿越的几条硬规矩我写进了项目文档第一所有行为特征必须带时间窗口不能存在“全量累计值”这种特征第二训练集和验证集必须按时间切分不能用随机抽样——用验证集数据里未来时间段的信息去预测过去指标必然虚高第三特征工程代码和预测代码必须共用同一套函数不能在训练时写一套 SQL、预测时写另一套。我那次的排查过程很典型。模型上线三周后销售反馈“系统给的 90 分客户打过去基本没反应”我拉数据一看预测分在中高分段大量堆积。回查特征才发现某个行为特征在训练阶段用了全量统计而预测阶段实时计算只能拿到截止当前的数据。修正之后 AUC 从虚高的 0.9 降到了 0.82但整个系统的可信度反而回来了。4.3 模型选型、特征筛选与业务阈值算法选择上没有太多花活。主力是 LightGBMXGBoost 作为交叉验证的对照组。对比下来 LightGBM 在这个数据量级下训练速度快一倍精度相当所以最后生产环境用了 LightGBM。类别特征的处理上高基数的标签比如行业细分、来源渠道用了频数编码和标签编码的组合没有做 one-hot——几十个类别做 one-hot 可以接受几百个上千个类别做 one-hot 就是在自找麻烦。特征数量最终控制在 80 个左右。筛选过程用 LightGBM 的特征重要性排序辅助但更重要的是做了一轮业务侧的人工特征审查把明显不合理的特征直接剔除。比如说“客户官网建站年份”这种特征相关性很弱留它只会增加过拟合风险。模型评估指标上我只看了两个数时间外验证的 AUC以及按分数分桶后的实际转化率单调性。前者衡量排序能力后者衡量业务可用性。AUC 0.82 左右、分桶转化率从 3% 到 25% 单调递增这个模型才算达到可上线标准。阈值选择同样不能拍脑袋我按预测分从高到低切成 Top 5% 到 Top 30% 几个档位统计每个档位覆盖的预期成交客户数和电话量成本最后选了 Top 15% 作为销售优先跟进线因为再往下拉新增线索的电话成本会翻倍但新增转化很少。4.4 可解释性与销售采纳模型要落地必须让销售理解为什么。我做了两个很简单的设计。一个是在线索详情页展示“命中特征 TOP 3”。比如“命中特征近 30 天访问官网 12 次、行业标签匹配、中大型规模区间”销售一眼就能明白这条线索为什么分数高。另一个是给出行动建议文案根据预测分和画像标签组合生成比如“高活跃、多标签命中建议两天内电话跟进”“活跃度低但画像高度匹配建议先发资料培育”。没有这两步模型再准也没用。我见过太多算法团队把预测分数做成一个 API前端直接展示一个孤零零的数字销售根本不买账。销售需要的是“System 告诉我现在该干什么”不是一个抽象的概率。所以行动建议这部分一定要让业务方参与设计哪怕只是简单的规则模板人机信任感也会完全不同。5. Agent 链路集成与工程落地5.1 任务编排与依赖管理三块模块各自开发完之后真正的挑战在于如何把它们编排成一条稳定运行的链路。我的做法是数据库队列表加状态机。队列表里每一条任务记录包括任务类型、依赖条件、状态、开始时间、结束时间、重试次数、错误信息。状态机只有四种状态pending、running、success、failed。调度器每隔一分钟扫一次把满足依赖条件的 pending 任务拉起失败的任务重试最多三次三次都失败就置为 failed 并触发告警。实际跑的调度链是这样每天凌晨两点触发采集任务采集完触发清洗清洗完成之后并行跑规则匹配和向量编码两道匹配都完成之后合并候选池再按客户 ID 触发画像更新画像更新完成后跑转化预测预测结果写回业务表早上八点前把当日优先跟进列表推送到销售工作台。每步任务的耗时在分钟级全链路跑完大概四十分钟。为什么用数据库队列表而不是直接写一个 Python 脚本按顺序执行因为线上环境一定有任务失败直接顺序执行会让“某一个环节失败导致整条链路不跑”变成常态。状态机的好处是某一步依赖失败其他任务可以跳过它继续跑等下一次调度重试时再补上。5.2 性能优化与外部依赖容错这套系统在性能上其实压力不大。几百个采集源、几十万客户库、每天新增几千条线索单机完全能扛住。真正容易翻车的是外部请求的不确定性。我对外部采集请求做了统一封装核心参数是连接超时 10 秒、读取超时 30 秒、失败重试 3 次、退避策略用指数退避。没有这套容错任何一个外部源的偶发超时都可能拖死整条采集链路。向量匹配的性能优化用了一个小技巧预先把所有候选公司的向量矩阵加载到内存新线索到来时用归一化点积计算相似度几万条候选只需要几百毫秒。几百毫秒看起来无所谓但如果每天要跑几千条候选性能差距会实打实影响调度链路的耗时。数据量上也预留了扩展空间。如果客户池增长到千万级别内存向量匹配会吃力到时候再引入近似最近邻索引现阶段单机的方案简单可靠完全够用。5.3 人机协同闭环Agent 给建议人为 Agent 纠偏Agent 跑得再顺也必须有一条人机协同的反馈回路。线索生成给销售的是候选建议销售跟进完要标记“有意向”“无需求”“暂时不匹配”三种结果预测模型给销售的是分数销售要去执行跟进动作跟进结果会作为新的样本回流到训练集。我做过一个体验很好的功能销售在系统中对线索点“不感兴趣”时必须选择一个原因标签比如“行业不符”“规模不符”“需求已被满足”。这些原因会实时进入线索生成模块的规则引擎如果某类原因积累超过一定数量对应的规则权重自动下调。另一个功能是每周一自动生成模型诊断报告包括分数分布、成交转化率、特征重要性变化让算法团队每周花半小时确认系统没有跑偏。没有这条闭环Agent 一定越跑越偏。数据分布会漂移销售策略会调整市场环境会变化静态的系统就像没有方向盘的车直线跑一段还可以时间一长必然偏离方向。6. 常见问题与排查实录6.1 线索重复率高怎么办现象销售反馈同一个公司出现在跟进列表里多次。原因不一定是采集重复也可能是规则匹配把所有关联公司都带出来了。我的处理方式是加多层去重第一层指纹去重过滤完全相同的记录第二层按域名和工商注册号做相似合并第三层是把同一集团下的强关联公司打上“集团提示”标签让销售知道这两家可能是一个老板。去重之后重复率从 12% 降到了 3% 以内。6.2 画像标签覆盖率不足现象上线后运行了两周统计标签覆盖率只有 60%大量线索只有身份标签没有行为标签和意向标签。原因有两条一是行为埋点数据接入得晚老线索没有历史行为二是部分外部来源的线索本身信息就少。处理方式是放宽统计窗口把“近 30 天行为”放宽到“近 90 天行为”先顶一阵子同时加快行为埋点的历史数据回补。这件事本质上是数据历史问题不是模型问题急不来。6.3 预测分整体过高区分度消失现象模型上线一段时间后80% 以上客户的预测分都集中在高分段销售看不出谁该优先跟进。排查后发现是特征泄漏某个特征包含了未来信息模型学到了一个虚假的高相关关系。按 4.2 的方式修正特征后分数分布恢复成“高分段少而精、中分段平稳”的健康形态。这里想强调的是分数分布一定要纳入日常监控异常往往在业务投诉之前就能发现。6.4 外部数据源突然断更现象采集任务一直显示成功但线索表新增量为零。排查发现是页面结构改版解析规则失效程序没有报错只是抓回空列表。处理方式是加数据新鲜度监控线索表每日新增量低于阈值即告警同时给每个采集源单独配置“最近更新时间”指标。这个问题给了我的一个教训不要只监控任务是否执行成功要监控任务产出的结果是否合理。6.5 销售反馈“打过去都不相关”现象销售对系统推荐的线索满意度下降反馈集中在“行业不对”“已经不是目标市场了”。处理方式分两步第一步上调向量匹配阈值宁可少推也不乱推第二步把销售的驳回原因做成负样本重新校准画像标签权重。调完之后的直接变化是销售优先跟进列表的拨打量下降了 20%但有效通话时长提升了 30%。对销售工具来说“不该推的少推”比“该推的多推”更重要。6.6 排查实录一次差点上线的事故上线前最后一周我用最近三个月的线上数据重新回测模型发现 AUC 从 0.82 掉到了 0.79。第一反应是数据出问题了查了整整三天才发现是画像模块新增了一个“近期浏览竞品页面”的事件标签但这个事件回传的数据只覆盖了新客户老客户全为空值等于特征上有了缺失模式偏差。这个问题的麻烦在于模型训练用的是全量客户预测时老客户的该特征为空会被填充成“无行为”但新客户的该特征有真实值。模型学到的是“这个特征为空代表老客户”而不是“有浏览竞品行为的客户意向更高”。最后处理方式是放弃这个特征等数据覆盖率到 80% 以上再考虑加入。这件事提醒我新增特征之前要做覆盖率评估不能因为某类新数据的采集方式很顺就急着进模型。7. 沉淀下来的几点经验如果让我只保留几条最值得说的经验我会选这几条。第一销售 Agent 的成败往往不取决于模型多先进而取决于数据管道、特征时序和反馈闭环是否扎实。我见过太多团队把精力花在换更强的大模型上忽略了数据质量结果照样效果拉胯。第二时间穿越是转化预测最危险也最隐蔽的错误来源所有特征必须有明确的时间窗口评估必须按时间切分上线后必须监控分数分布。第三系统要给业务留反馈入口不能只做单向输出。销售推动跟进结果模型才能持续迭代否则就是一个越跑越偏的静态脚本。这套系统后续的扩展方向还很清晰引入更细粒度的行为序列建模补充多触点归因以及把预测结果直接接到自动化的触达动作上。不过这些都是后话了先把现有的闭环跑稳让销售团队真正把 Agent 当作每天工作的第一站才是从 0 到 1 之后最重要的事。我个人在实际操作中最深的体会是搭销售 Agent 本质上是在把销售团队的经验结构化。模型学到的每一条规律其实都是销售老手已经知道的经验系统能做的是让这些经验以稳定的、可放大的方式用在每一个客户身上。想清楚这一点你就知道该把时间花在哪里了——不是堆模型而是把经验翻译成数据、特征和规则。