销售自动化这个事儿，圈子里聊了快十年，从最早的邮件合并工具聊到今天的AI Agent，但我见过绝大多数团队还是停在“Excel里躺着一堆线索，销售天天手动扒官网，方案从零开始拼”的状态。我也一样，前两年带一个B2B产品的增长团队，眼看着线索量上来之后跟进速度完全跟不上，才下定决心把整条链路——线索挖掘、客户跟进、方案生成——交给智能体去跑。中间用了一堆方案，最后在OpenClaw上跑通了全部流程，这篇文章就是把这段工程化落地过程中的思路、踩坑和设计细节完整记录下来。适用对象是销售运营、SDR团队负责人，以及想用开源Agent框架替代手工重复流程的开发者，看完可以少走一大截弯路。

1. 选型那点事：为什么最终锁定了OpenClaw而不是自己造轮子

1.1 销售自动化对Agent底座的要求

在动手之前，一定要先想清楚一件事：销售自动化里跑的不是一个“能聊天的机器人”，而是一个要对接N个系统、按N种节奏触发、还要能随时被人接管的常驻执行体。我拆下来大概四个硬性要求。

第一是触发方式要多样。线索挖掘可能是每天凌晨两点定时跑，客户跟进可能是外部CRM的Webhook推一条“对方刚回复”过来就立刻触发，方案生成则是销售在群里@一下机器人说“给某客户出一版方案”。这意味着Agent不能只是一个命令行工具，它必须常驻运行，且天然支持定时、事件、消息触发。

第二是跨系统操作能力。销售链路里要碰浏览器抓网页，要调CRM API写记录，要处理邮件服务器，要生成Word文档，偶尔还要读PDF。OpenClaw这类Agent框架核心价值在于它把浏览器自动化、API调用、文件操作、知识库检索这些能力内聚成了可复用的技能包，而不是每次都要从头去拼装。

第三是要有状态和记忆。跟进客户不是聊一次就完，Agent得知道这个客户上周聊到哪、产品偏好是什么、上次报价是多少。所以Agent底座必须有持久化的记忆存储，而不是无状态地调用一次LLM就结束。

第四是人工介入权。销售场景里AI可以干80%的体力活，但20%的关键动作——群发、报价、删数据——必须有人点头。所以Agent框架得有暂停、审批、复核这一类机制位。

1.2 三条岔路：自写脚本、裸调API、传统RPA

我一开始没有直接上OpenClaw，而是把市面上能想到的三条路各试了一遍，都是“看起来很美，跑起来头疼”的结局。

先说自写脚本。线索挖掘无非是爬官网、抓列表页、提取邮箱和公司信息。听起来简单，但真实场景里网站改版、登录墙、反爬、字段缺失这些事能把一个Python脚本维护到崩溃。更难受的是，脚本是一锤子买卖，它没有记忆，今天爬到一半挂了，明天就得从零来。

再说裸调LLM API。语言模型确实能做信息抽取、邮件生成、方案撰写，但业务链路不是只有“生成文字”这一步。你得自己写调度器、自己处理文件格式、自己接CRM、自己管token成本。我在原型阶段光是把一个“读取客户资料→生成邮件→发送→记录结果”的闭环写完，就已经写了六百多行胶水代码。

最后说传统RPA。这类工具强在界面元素级的自动化，鼠标点击、键盘输入都很稳，但遇到“理解网页内容并做出判断”这种需要语义理解的任务就傻眼了。它的编排方式偏重，而且跟大模型能力的结合往往是事后补丁，不是原生支持。

OpenClaw在这种对比下优势很明显：它本身就是面向任务型Agent设计的，把“感知—决策—行动”的闭环做成了框架能力，我只需要往里面注册业务逻辑，而不是从零搭一个Agent运行时。

1.3 OpenClaw的工程视图：进程、任务与技能包

如果让我用一句话描述OpenClaw在工程上的样子：它是一个常驻后台的Agent运行时，你能往里面挂无数个自动化任务，每个任务由多个技能包驱动，技能包内部封装了工具调用和提示词逻辑。

从实际使用来看，我建议把它当“一个能自己干活的业务机器人”来理解，而不是当“聊天机器人”来理解。你要给它定义工作目标、给它挂上必要的数据源、给它设定执行边界，然后它在你设定的流程里自主地把事情办完。

工程上有一个关键点：状态文件。OpenClaw会把每个任务的执行进度、中间结果、上下文都沉淀下来，任务中断之后可以恢复，这比我在初版自写脚本里手动存JSON靠谱得多。后面第五部分我会详细讲稳定性和幂等性问题，这里先记住一个结论——一个Agent框架能不能做“长跑型任务”，第一看状态管理，第二看技能复用，OpenClaw这两点都能兜住。

2. 线索挖掘：把散落的信息源变成结构化Pipeline

2.1 三类信息源的解析策略

线索挖掘不能指望一个API统一搞定，我从实际业务里梳理出三类最常见的信息源，OpenClaw需要分别用不同方式处理。

第一类是官网与产品页。最典型的是“目标客户官网的解决方案页里写了他们用什么技术栈、在招什么岗位、最近发什么动态”。这类信息源的问题是结构五花八门，页面特征完全不一样。我用OpenClaw的浏览器自动化能力，针对高频客户站点做了DOM解析模板，低频站点则走“先抓正文→LLM抽取”的兜底路线。两条路线并行，覆盖率高很多。

第二类是行业展会与协会名单。这类信息源最大的价值是“已经帮你筛选过一遍目标客户”，但往往是一张几百行的Excel或PDF。OpenClaw处理这类数据时，我让它先按表头自适应解析，再结合公司名去公开站点补充联系人信息。这里有个实操心得：不要直接信任名单里的邮箱，一定要让Agent去官网二次校验，因为展会名单往往是两年前的。

第三类是公开招标与采购信息。这类信号极其精准——对方有明确预算、有明确需求，是最理想的线索源。OpenClaw定时抓取相关页面，把标题、采购方、预算、截止日期解析成结构化字段，再跟我方产品做初步匹配度打分。匹配度低的直接进低优先级池，匹配度高的进销售待跟进队列。

2.2 数据清洗与线索评分：规则打底、LLM兜底

信息源抓回来之后，最怕的就是“垃圾进、垃圾出”。我的处理策略分两层：规则层负责硬清洗，LLM层负责软补全。

规则层干这些事：格式校验（邮箱正则、URL正则、日期规范化）、去重（同域名同联系人直接合并）、黑名单过滤（离职邮箱后缀、竞对域名、无效格式）。这些不需要大模型，用常规脚本就能跑得又快又准。OpenClaw的task里可以直接挂一段Python逻辑作为清洗步骤，跑完再走LLM。

LLM层干的是规则做不了的事：从一段公司官网原文里判断这家公司大概什么规模、属于什么行业、当前有哪些业务痛点、和我方产品有没有关联点。这里不要用贵的大模型，用中档模型足够，把输出限定成JSON，方便后续入表。我实际跑下来，LLM在做意向判断上比任何关键词规则都好用，尤其是面对“客户官网根本没提需求，但字里行间明显在扩张”这种隐含信号。

线索评分我走的是最朴素的加权模型，参考维度如下表：

总分80分以上直接转销售，60到80分进入培育池，60以下归档观察。这套模型不复杂，但胜在可解释——销售来问“为什么给我这条线索”，我能直接拉出各维度得分，比一个黑盒模型好沟通得多。

2.3 与CRM的同步策略

线索清洗评分之后，最大的坑出现在CRM同步环节。我第一次上线时直接用API逐条写入，结果Webhook重试机制导致同一条线索在CRM里出现三条记录，销售同事第二天直接炸了。

后来我把同步逻辑改成**“幂等写入+人工确认双保险”**。幂等写入的核心是：以联系人邮箱+公司域名为唯一业务键，写入前先查询，存在则更新、不存在则创建。同时OpenClaw侧维护一个本地同步游标，记录上次同步到哪条记录，避免整表重扫。

人工确认这个环节也是后来补上的。新线索进入一个**“待确认队列”**，每周运营同事花二十分钟扫一遍，把明显不靠谱的（比如联系人职位明显不符的）标记为无效。OpenClaw定时任务每周一早上把队列里待确认的线索汇总成一张表推到IM群里，操作成本极低，但准确率显著提升——因为规则和LLM打分再准，也会漏掉一些只有人才知道的行业潜规则。

3. 客户跟进：调度、个性化与防骚扰的平衡

3.1 跟进节奏模型：触发式>订阅式>盲目群发

客户跟进最容易犯的错就是“把AI当成群发机器”。我用OpenClaw搭了一套三层触发模型，按优先级排序：

• 触发式（最高优先级）：客户回复了邮件、点了方案链接、在官网上留资，立刻触发一条个性化后续动作。这类动作和客户当下的意图强相关，转化率最高。
• 订阅式（中优先级）：对培育池中的客户，每周或每两周发一封行业洞察或产品更新摘要，内容不以推销为主，更像“价值输出”。
• 事件式（低优先级）：公司发布了重大新功能、有行业活动时，补充一次群发触达，但频率严格限制。

这套模型最大的价值在于可控。AI不会因为“反正不用花人力”就无限触达，所有发送动作都要经过发送频率阈值检查，同一客户28天内最多接收到两封不同类型的内容。

3.2 个性化生成的工程实现

个性化这个事儿，很多人以为“在模板里填上客户公司名”就算个性化，其实用户一眼就能看穿。我让OpenClaw做到真正的基于上下文生成，核心步骤分三步。

第一步，读取客户画像。包括行业、规模、近期动态、此前所有聊天记录、已购买产品模块。生成前把画像压缩成一段结构化摘要。

第二步，检索相关内容。从产品知识库里检索和客户痛点相关的解决方案片段和案例，作为生成的素材输入。

第三步，用模板骨架+向量检索结果+LLM改写的方式生成邮件。模板只保留段落骨架和语气规范，具体内容由模型根据上下文填充。我给LLM的写信指令里有一条硬要求：“不要提‘希望您’‘打扰您’这类废话开场，第一段直接说明和对方业务的关联”。这条改完，邮件的开信率比之前的通用模板高了将近三成。

3.3 定时任务值守与退信处理

OpenClaw的定时能力在跟进链路里的角色是“值班员”。每天早上九点，它先把当天应跟进的客户列表拉出来，按优先级排序，再逐条检查是否有新的上下文（客户凌晨有没有回信）。全部确认完之后，生成当天跟进清单发到销售IM群，销售可以一键决定“这封直接发”或“这封我来写”。

退信和明确拒绝的处理必须自动化，而且要快。OpenClaw每发一封邮件都会监控退信通知和“请勿再联系”类回复，一旦命中，立刻自动把客户状态改为“已退订”，并停止后续所有触达任务。这块不只是效率问题，也是合规底线——自动化越激进，越要重视退订和拒绝信号的收敛逻辑。

我在这个环节踩过最大的坑是：客户退订后，因为另一条线索挖掘任务又抓到了同一个客户，导致客户再次被写入跟进队列。后来给全局加了一道“黑名单过滤”，所有线索在入队前先跑一遍黑名单库，命中直接丢弃。这个黑名单库会自动吸纳退订客户和投诉客户，形成闭环。

4. 方案生成：知识库、RAG与文档编排

4.1 把产品知识变成可检索的资产

方案生成和线索挖掘的底层逻辑完全不同。线索挖掘是“从外界抓取信息”，方案生成是“从内部知识资源里抽取信息并组装成文档”。所以第一步不是写文案，而是整理知识资产。

我把团队里的产品手册、销售FAQ、历史成交方案、售前技术方案、报价区间说明全部做了一遍清洗，按不同知识域切分，存进向量检索库。这一步不需要多复杂的技术，但有一件事必须做扎实：每一条知识片段都要带属性标签，比如适用行业、适用规模、关联产品模块、是标准物料还是酌情使用。没有标签的知识库，检索出来往往是“看起来相关，实际不能直接用”。

4.2 方案编排：检索、组装、渲染三步走

方案生成我在OpenClaw任务里设计成三步流水线：

• 检索：把客户的需求文本作为query，从知识库里召回相关产品模块、案例片段、FAQ答案，同时从CRM里拉出客户的历史数据和画像。
• 组装：用一个“方案大纲Agent”把召回的素材排布成章节结构，每个章节标注素材来源ID。这一步非常关键，它保证最终方案的每一句话都可以溯源。
• 渲染：按标准方案模板把组装结果填充成docx，自动生成目录、附录、联系方式页。我用的是模板渲染引擎，表格和报价部分走固定格式，正文段落走LLM生成。

整套流程跑下来，一个中等复杂度的方案初稿，从原来的一个售前半天时间，压缩到二十分钟出一版可复核的草稿。这里说句公道话：AI生成的方案初稿不能直接发给客户，但它的价值在于把“从零开始拼文档”变成“审阅修改”，效率提升是实打实的。

4.3 生成结果的复核关卡

方案生成这个环节，我始终坚持**“人审必须保留”**。AI可以负责体力劳动，但不能完全替人做判断，尤其是涉及价格、承诺、合规边界的表述。

我在OpenClaw的流程里加了三道复核关卡：第一道是格式校验，模板字段是否完整、章节是否齐全、图表是否正常；第二道是事实一致性校验，方案里引用数据和知识库原数据是否一致，有没有幻觉出来的案例；第三道是人工确认点，也就是方案在发出之前必须有一位授权人在IM里点确认，Agent收到确认指令之后才发送。

实际运行下来，方案初稿的“可用率”大概在七成左右，剩余三成主要问题集中在“语气太AI”“案例客户描述过度美化”“把历史方案里其他行业的表述混进来”这几类。这些恰恰是必须由人盯住的最后一公里。

5. 工程化落地中那些没人提前告诉你的细节

5.1 稳定运行三件套：重试、锁与熔断

销售自动化跑在生产环境里，和做Demo最大的区别就是：线上永远有意外。系统追平这个问题要在源头解决。

我的处理核心是三件套：

• 重试：所有外部API调用（CRM、邮件、检索库）统一走带指数退避的重试机制，网络抖动和超时基本不会导致任务中断。
• 锁：任务级和记录级两层锁。任务级锁防止同一个定时任务被重复调度；记录级锁防止两个并发任务同时处理同一条线索。这个是我在追查“CRM重复写入”问题时引入的，后来证明它是稳定性提升贡献最大的一个改动。
• 熔断：当某个外部依赖连续失败次数超过阈值，自动暂停该依赖相关的所有任务，发告警到群里，而不是让任务傻傻地反复撞墙。我在邮件服务出过一次故障，OpenClaw在五分钟内自动拉停了所有群发任务，避免了退信轰炸和客户投诉。

5.2 Token成本与运行效率的平衡

销售自动化跑起来之后，最大的运营成本不是服务器，是LLM调用费。为了控制成本，我把所有模型调用按任务类型做了分级：

另外还有几个省钱的细节：公共知识片段的检索结果只算一次并缓存；同一客户的多次跟进复用画像，而不是每次重新抽取；定时任务尽量错峰调度，避免并发拉高瞬时费用。一个月实践下来，整体token费用比最初无差别使用高档模型下降了大概45%，而各环节的质量指标没有明显回退。

5.3 权限、审计与人工确认点

把Agent放进业务链路，安全设计必须在第一天就考虑，而不是上线出问题再补。我个人的原则是“Agent能多看，但关键动作必须人批”。

具体落到销售链路里，我做了一张操作权限矩阵：

这里有个容易被忽视的点：审计日志不能只记录“参数和结果”，必须记录“推理过程和素材来源”。比如Agent发了某封邮件，日志里要能看到它是基于哪条知识库片段、哪个客户画像生成的。这样万一出了客户投诉或内容争议，能回溯完整链条，而不是只知道“发过一封信”。

OpenClaw在这块给了比较完善的消息确认机制，但关键是业务侧要愿意把“人工确认点”真正留在流程里。很多团队上一套自动化系统就恨不得全自动，结果出了问题又全盘退回人工。正确的姿势是：把Agent能干的80%自动跑起来，把20%需要判断的环节留给人，这才是可持续的工程化状态。

最后补充一点亲测经验

整条链路跑了大半年，我最大的体会是：OpenClaw这类Agent框架能不能在销售场景里真正创造价值，拼的不是模型智商，而是流程设计的细致程度——线索评分规则是否清晰，跟进节奏是否克制，方案生成是否可溯源，异常任务是否有人兜底。一个“不怎么聪明但流程闭环”的Agent，远胜过一个“聪明但没有边界”的Agent。

如果你准备在自己团队搭这套东西，我的建议是从线索挖掘的“单点任务”入手，先跑通一个最小闭环，比如“每天自动抓取竞对动态并汇总到群里”，感受一下Agent的运行逻辑，再逐步叠加客户跟进和方案生成。另外一个小技巧：给所有定时任务加一个**“静默模式”**，任务一旦出错不要反复打扰群里的人，只把告警发到固定异常频道，每周汇总一次。这样既保证了监控，又不让团队被机器噪音淹没。

自动化只是把重复劳动交给机器，真正的判断力永远要留在人这一侧。这套体系跑到现在，团队省下来的时间并没有用来减少人员，而是把省下来的精力全部投到了复杂客户的深度跟进上，整个销售漏斗的转化率反而比纯手工时代提升了一截——这大概就是我理解的“工程化”的意义。