这套架构拆解我基于真实落地经验来写。平时总有人问我说AI获客到底是不是噱头能不能真的把销售从重复劳动里解放出来。我自己的答案很明确能但前提是你别把“AI获客”理解成装一个聊天机器人而是要把一整条获客链路拆开让不同环节交给最合适的自动化工具再通过数据和反馈把它们串成一个不断自我优化的闭环。这篇文章就是一次完整复盘覆盖Agent协同、RPA执行、数据飞轮这三个核心组件以及它们如何配合实现从“找到潜在客户”到“把线索喂给销售”的全链路自动化。1. 整体架构思路为什么把 Agent、RPA 和数据飞轮绑在一起先讲一个我自己的经历。早两年我帮一家做企业服务的公司搭获客系统他们当时的问题特别典型市场部每天从公开渠道扒线索销售助理手动去各个平台找联系方式加了微信之后还要手动给客户打标签、写备注、录CRM。这套流程跑下来人均一天真正能触达的潜在客户不超过20个大量时间都花在复制粘贴和页面跳转上。更麻烦的是经验全部留在几个老销售脑子里新人来了要从零摸索线索质量忽高忽低。后来我给他们搭了一套现在回头看非常朴素的自动化脚本解决了“手动重复操作”的问题但很快发现新的瓶颈脚本只能按照固定规则办事一旦客户的回复偏离预期整个流程就卡住了。比如脚本发出“您好我们提供数据分析服务”之后客户回一句“你们和XX公司有什么区别”脚本就不知道怎么接。这时候我才意识到获客这件事本质上不是一个“执行”问题而是一个“决策”问题。这正好是Agent和RPA的分工逻辑。Agent负责所有需要判断的环节判断这个线索值不值得跟、判断客户这句话背后的意图是什么、判断应该用哪套话术去回应。RPA负责所有不需要动脑子的环节打开网页、翻页、填表、点击、复制、粘贴。两者一配合才能既保证速度又保证应变能力。但只有这两个还不够。因为Agent的“聪明”不是天生的它依赖数据和反馈。今天发的100条消息里哪条话术打开了率最高哪个渠道来的线索最终成交了这些问题不回收答案系统就只能永远用一个固定套路去获客本质上还是“自动化执行”谈不上“智能增长”。所以第三个组件是数据飞轮把运行时产生的所有行为数据、结果数据、反馈数据收集起来清洗加工后反哺给Agent的策略和模型让系统每一轮获客都比上一轮更准。简单讲Agent负责思考RPA负责动手数据飞轮负责让系统越用越聪明。这个架构真正解决的不是某一个环节的效率问题而是获客这件事的整体系统性问题。适合谁参考呢我建议这么分如果你手里有10个以上的获客渠道、每周要处理上千条线索这套架构能明显降低人力和时间成本如果你已经用了某种CRM或营销工具但数据散落、复盘靠猜数据飞轮部分尤其值得认真看如果你是技术负责人或独立开发者想从“写脚本”升级到“搭智能体”Agent和RPA的协同设计思路可以直接迁移。2. Agent 协同层多智能体如何分工干活很多刚接触Agent开发的人第一反应是“用一个万能Agent搞定所有事”。实际落地下来这种方式在处理获客这种长链路任务时非常脆弱。原因很简单获客涉及的子任务类型差异太大有的需要创造力和语言能力比如写推广文案有的需要严谨的结构化输出比如判断线索所属行业还有的涉及敏感操作比如发送好友申请必须严格按照频控执行。所以我在架构里很少用单体Agent更多是把任务拆给多个职责单一的Agent再用一套编排机制让它们协作。这叫Agent协同也叫多智能体架构。下面是我的具体设计。2.1 场景定义与角色划分以B2B获客为例我把整条链路拆成五个Agent线索挖掘Agent根据设定的行业、地区、公司规模等画像条件在公开数据源中筛选潜在客户输出结构化线索列表内容生成Agent针对不同客户类型、不同触达阶段生成个性化的沟通内容包括首访消息、跟进的文案、FAQ应答话术调度执行Agent统一接收上层目标判断当前应该调用哪个Agent干活并整合结果做下一步决策相当于“主编”触达执行Agent对接RPA负责按节奏发起好友申请、发送消息、评论互动同时记录每次触达的时间窗口和反馈质量评估Agent对每条已触达线索进行打分评估意向等级判断是否应转入工跟进或者进入培育池。这里有一个关键原则角色划分必须和业务流程一一对应而不是按照技术方便来分。比如“触达执行”在技术上可能也就是“调一个API”但如果后续要调整发送策略独立抽出来会方便得多不用动其他Agent。2.2 目标分解与任务编排有了角色之后调度执行Agent要做的事就是把用户或运营设置的宽泛目标比如“这个月获取300条MQL市场认可线索”拆成可以执行的具体任务步骤。这个过程业内通常叫规划Planning。实操中我会让调度Agent输出一个JSON格式的任务清单。示例{ goal: 本月获取300条有效线索华东地区优先, tasks: [ {agent: lead_miner, action: search, params: {industry: SaaS, region: East_China, size: 50-500}, priority: 1}, {agent: content_generator, action: compose_variants, params: {count: 5, style: professional}, priority: 1}, {agent: outreach_coordinator, action: check_channels, params: {channels: [linkedin, wechat, email]}, priority: 2}, {agent: lead_miner, action: enrich, params: {fields: [email, phone, title]}, priority: 2}, {agent: quality_evaluator, action: score_leads, params: {min_score: 70}, priority: 3} ] }生产环境中这个任务清单不一定要以这种固定的方式生成可以结合规则的优先级和Agent的动态判断来生成。比如线索挖掘Agent发现某个公开数据源结构改了返回“抓取失败”状态调度Agent会自动调整策略换一个数据源或者要求内容生成Agent改用另一种话术补偿。这种动态调整能力是固定的脚本流程很难实现的。2.3 协同机制上下文管理与信息共享多Agent之间怎么共享信息这是最容易踩坑的地方。如果每个Agent都把结果写在各自的文件里调度Agent每次都要去翻文件找答案那效率低不说还很容易因为格式不一致导致解析出错。更好的方式是用一个独立的记忆模块来管理上下文。所有Agent产出的结构化结果统一写入这个模块并且每一条数据都带上“谁写的、什么时候写的、数据来源是什么”。调度Agent在决策时只从记忆模块里取它需要的内容。这里我不建议一开始就上特别复杂的向量数据库先用最简单的关系表或KV存储完全够用。关键是定义好数据格式。以下是我常用的一段数据结构示例{ thread_id: 20250607_lead_001, agent_name: lead_miner, message_type: lead_record, payload: { company: 某某科技有限公司, industry: SaaS, employee_count: 120, source: industry_directory, contact: {name: 张经理, title: 市场总监} }, timestamp: 2025-06-07T10:30:00Z }统一结构带来的好处是后续无论是质量评估Agent消费这份数据还是数据飞轮做分析都不需要再写一堆解析逻辑。这是我在多次重构后总结出的教训Agent协同的第一步不是选最花哨的框架而是先把“交流的语法”统一好。2.4 模型选型与成本控制Agent层离不开大模型但并不是每个Agent都需要用最强的模型。如果什么都用顶配模型线索量大一点成本立刻失控。我一般会按任务难度做模型分层大致策略如下表Agent类型典型任务推荐模型档位原因调度执行任务分解、意图判断强模型如顶配推理模型决策错误影响全局值得花成本内容生成个性化文案、改写中档模型需要一定创造力但不要求极致推理线索挖掘信息提取、结构化输出轻量模型主要靠规则和提示词约束质量评估打分、分类轻量到中档模型逻辑简单重吞吐低延迟触达执行不涉及模型推理无需模型判断交给RPA和规则执行实践中可以给每个Agent配置一个“模型开关”低频时期用轻量模型核心链路跑不通再升级。不要一上来就追求全智能、全顶配先把流程跑通再根据瓶颈位置逐步升级。2.5 上下文压缩与记忆维护多Agent协同跑久了上下文中会堆满历史信息。尤其是触达执行Agent和客户来回对话十几轮之后如果每次都把完整聊天记录丢给调度Agent做决策一方面浪费token另一方面模型很容易被无关细节干扰。我的做法是引入记忆压缩机制每次对话结束由质量评估Agent顺带生成一段摘要把客户的关键信息行业、痛点、意向等级、下一次建议动作浓缩成几条结构化记录。后续决策只读取摘要只有需要完整回溯时才去翻原始对话。这个策略能让长期运行的智能体保持稳定不至于聊着聊着“忘掉前文”。3. RPA 执行层把决策变成物理动作Agent的产出是“决定做什么”但如果真的要去网页上操作、在系统里点按钮、跟外部平台交互就需要另一个层面的工具来执行。这就是RPA的位置。我最早用RPA时觉得它很笨就是机械地录屏回放后来才发现真正用得好的RPA和Agent配合起来几乎可以伪装成一个真人运营。3.1 为什么需要RPA而不是直接写脚本理论上所有网页操作都能用脚本模拟HTTP请求完成。但实际上获客过程往往要操作的对象是别人的平台比如脉脉、LinkedIn、企业微信管理后台这些平台大多有反爬策略接口也不公开。如果写纯脚本去请求页面不仅容易被封而且一旦平台前端改版脚本就全废。RPA的优势在于它模拟的是人操作浏览器的行为通过元素定位和点击事件来操控界面。它走的是正常用户的操作路径风控识别难度更高而且大部分RPA工具都提供了可视化元素选择器页面变化时只需要重新定位元素不需要像纯脚本那样重写逻辑。所以在获客场景下我的结论是凡是和外部平台交互、没有公开API的场景一律交给RPA凡是内部系统之间的数据传输优先走API或数据库直连。3.2 影刀RPA的实际落地配置市面上主流RPA产品我基本都试过影刀是让团队上手最快的一个尤其在中文互联网生态的适配度上表现得比较省心。它的元素选择器能直接拾取按钮、输入框、下拉菜单还能自定义选择器来应对动态页面这对业务同学来说很友好不需要懂代码就能搭出基础流程。我简单描述一个用影刀RPA实现“自动发送企业微信好友申请”的流程搭建思路方便没有接触过的读者有个直观参考准备一份线索列表来源可以是Agent生成的CSV也可以直接读数据库视图在影刀中创建工作流第一步是读取Excel或API接口数据解析出待添加的微信号或手机号第二步打开企业微信或其他触达工具使用“搜索联系人”组件定位到搜索框输入号码第三步找到“添加到通讯录”按钮点击第四步填写验证消息。验证消息这里可以直接读取Agent生成的话术字段实现千人千面的个性化触达第五步点击发送并记录发送结果到日志表最后加上随机延时逻辑比如发送完一条后随机等待30到60秒再处理下一条以降低被平台判定为机器操作的风险。这套流程跑起来之后一个人可以维护多个企业微信账号同时执行只需要定期检查日志。这里尤其要对没有RPA经验的读者强调一点RPA的“录屏”功能用来做原型验证很方便但正式流程千万别只依赖录屏。比如你录了一个“点击按钮”的动作录制时按钮在屏幕固定位置下次运行时窗口大小或屏幕分辨率变了它就找不到按钮了。所有关键元素都应该用元素选择器去绑定而不是坐标定位。3.3 与Agent的接口设计指令协议与状态回传这是Agent和RPA协同最核心的部分。Agent要有办法把“下一步做什么”告诉RPARPA做完后还要把结果反馈给Agent两边才能形成闭环。我的做法是引入一个简单的指令队列本质上就是一个数据库表两个部分各自读写。表结构大致如下字段说明示例task_id任务唯一IDoa_20250607_001agent_source指令来源Agentoutreach_coordinatoraction_type指令动作send_friend_requestpayload动作参数JSON{contact: 138xxxx, message: 张总您好...}status执行状态pending / running / success / failedresult执行结果信息success / timeout / blockedretry_count重试次数1created_at创建时间2025-06-07 10:30:00executed_at执行完成时间2025-06-07 10:31:12Agent发现某个客户需要被触达就在表里插入一条记录RPA以轮询或消息通知的方式获取待办指令执行完成后更新状态和结果。Agent读取状态决定下一步动作是继续跟进该客户还是转入培育池还是标记为无效线索。这个设计的好处是Agent和RPA完全解耦。Agent不需要关心RPA怎么打开页面、怎么点击RPA也不需要知道Agent的意图判断逻辑。哪边出问题都可以独立替换这是系统稳定运行的关键。3.4 稳定性设计异常处理、重试与人工介入RPA跑线上流程最大的敌人不是写不出脚本而是流程跑崩了没人知道。所以我特别强调异常处理机制。影刀本身支持“异常捕获”和“流程失败后跳转”逻辑生产环境中我会在每个关键节点都埋上日志打开页面失败记录截图自动重试一次再失败则切换备用浏览器环境找不到目标元素说明页面结构变了把错误信息写入日志并自动降级为“人工处理”不是无限重试发送被拦截或触发风控立即暂停该渠道的所有任务通知管理员介入避免账号被进一步限制。另外所有的RPA流程都应该支持手动按钮——一键暂停、一键恢复。不要把所有操作都交给自动化关键时刻人的介入可以避免很多不必要的麻烦。4. 数据飞轮让每一轮获客都成为下一次的燃料前面两大部分解决的是“自动化执行”的问题数据飞轮解决的是“越用越聪明”的问题。没有数据飞轮的系统就像一个人每天都重复同样的动作却从不记录哪些动作有效运气好时来几个客户运气差时颗粒无收。而有了数据飞轮每一轮触达的结果都会变成下一轮优化的依据。4.1 数据采集哪些数据值得回收很多团队做数据回收时有个误区什么数据都存。实际上数据存得越多清洗成本越高分析时噪声也越大。我在获客系统里只回收四类核心数据触达数据什么时间、通过哪个渠道、用了什么话术版本、触达了几次响应数据客户是否回复、回复内容、响应耗时、是否点击了外链或查看了资料转化数据是否加微成功、是否进入CRM、是否参加demo会议、是否最终成交过程异常数据哪些环节报错、哪些平台触发了风控、哪些页面结构频繁变化。每一类数据都对应一个明确的分析目的。比如响应耗时这个字段是为了给调度Agent提供“什么时候联系客户效果最好”的依据过程异常数据是为了给RPA的稳定性优化提供线索。4.2 反馈闭环把转化结果送回Agent策略数据回收之后下一步是做反馈闭环。这个环节如果做得不好数据就只躺在数据库里变成一堆数字。我的做法是做两级反馈第一级是短期反馈面向单次触达的对话策略。例如触达执行Agent发出一条消息后客户回了某个高频问题这个回合的记录被自动标记并由内容生成Agent更新FAQ话术库下次再接客户问同样问题时能直接给出更好的回答。第二级是长期反馈面向获客策略的整体效果。例如通过数据解读发现“华东地区SaaS类企业30人以内的初创公司最优触达时间在上午10点前后”这些洞察会被写回策略表调度Agent在做任务计划时直接读取这个表作为约束条件。在实际工程实现上我用了一个比较轻量的策略引擎本质上就是一张“策略配置表”加一段“策略解释器”代码。数据飞轮产出洞察后通过人工审核或者半自动确认的方式写入策略表。Agent在跑任务前会先加载策略表再动态调整自己的执行计划。这样既不会让数据直接控制Agent造成失控又能持续把有效经验沉淀到系统里。4.3 飞轮指标怎么衡量系统是否在变聪明如果搭建了一套系统却无法衡量它是否真的在变好那数据飞轮就沦为了空转。我常用的指标有几个线索响应率发出的触达中获得回复的比例。这是一个结果指标短期看话术和触达时机长期看线索挖掘Agent的画像筛选质量有效线索率进入CRM并且被销售跟进后标记为“有效”的比例。这个衡量的是从线索到商机的质量防止系统只顾数量不管质量内容采纳率内容生成Agent给出的文案有多少比例被直接采用多少需要人工修改。这个指标能反向检验Agent生成内容的质量流程自动化覆盖率整条获客链路中无需人工介入的环节数量占比。衡量自动化本身的落地程度单条有效线索成本总成本除以有效线索数。这是最终业务负责人最关心的指标。每个月我会回顾一次这组指标观察变化曲线。如果响应率在涨但有效线索率没涨说明话术更吸引人了但线索画像筛选可能变宽了需要回头调Agent的筛选阈值。如果自动化覆盖率很高但单条成本没降说明RPA执行中可能重复跑了太多无效任务需要优化任务调度。4.4 数据质量与飞轮护栏这里我要特别提醒一个容易忽略的点数据飞轮也可能“越转越歪”。原因是训练反馈的数据本身有噪声。比如触达执行Agent发出100条消息其中30条被系统判定为“已读未回”如果直接把“已读未回”当成“不感兴趣”喂回策略可能就误判了一批只是还没来得及回复的高意向客户。所以我在设计数据飞轮时专门加了一个“护栏”环节所有回流给Agent优化的数据必须先经过质量门槛校验。比如“意向降低”这个结论至少要满足两个条件客户已经超过7天没有响应且至少触达3次不能因为一次未读就打上消极标签。这个校验逻辑用规则写死不交给模型判断因为规则更稳定、更可解释。5. 常见问题与排查技巧实录这套架构从开发到上线我有几个踩过的坑印象特别深刻这里逐一列出来。如果你也在搭类似的AI获客系统大概率会遇到同样的问题。5.1 Agent上下文爆炸决策越来越慢刚开始跑时调度Agent会参与所有环节的决策导致它的上下文越来越长响应速度直线下降成本也一路涨。后来我改成了“关键节点汇报制”调度Agent不需要每步都参与只有在线索评分低于阈值、触达被拒、数据源切换这些关键节点才由它做决策其他常规流程都走预设规则。排查技巧如果Agent响应超出预期时间先检查它的上下文token数再检查最近的对话是否都是“不需要决策”的重复性请求。如果是果断把这类请求交给预设规则处理。5.2 RPA选择器频繁失效流程中断影刀RPA这类工具的选择器在页面稳定时很可靠一旦目标平台改版比如按钮class名变了、页面结构调整老选择器立刻失效。最严重的一次我的一套选品自动化流程在一周内中断了三次。解决办法是给关键步骤做“多级降级”优先用元素名称定位失败后用父级元素文本组合定位还失败就利用OCR识别点击。最后兜底方案是指派人工处理并截屏留档。不到万不得已不彻底改流程因为频繁改会造成新的不稳定。另外建议给每个关键节点配置“失败截图自动上传”功能出问题不用人工跑去看现场直接看图定位排查效率提升一个量级。5.3 数据噪声导致策略漂移第一次跑数据飞轮时我遇到一个典型问题运营反馈说系统推荐的话术越来越“软”没有全盛期那种进攻性了。排查后发现大部分高意向线索的成交都发生在“客户主动追问产品价格”这个场景下而这类追问大多出现在活动促销期非促销期素材很少。结果显示数据里有个别高意向客户触达了“询价”类话术并成交导致飞轮把“多问价类问题”错误地强化成了通用策略。这就是数据漂移。解法是给飞轮数据加上“环境标签”比如是否促销期、渠道是否在投广告、行业是否旺季让分析过程排除外部因素的干扰。任何结论产出后运营都需要人工复核才能写入策略表不能完全自动更新。5.4 账号风控与频控问题做触达类RPA最怕的就是账号被限制。我经历过同一台设备上了三个企业微信账号后被批量封禁的事故。后来总结出的经验是每台设备最多跑一个主账号其余用低频率辅助操作每次登录之间要做随机延时不要一开机就同时执行模拟人的操作习惯设定每日触达上限比如每个账号每天新增好友申请不超过30个超过后自动切换别的渠道定期更换用户代理和设备指纹保持环境相对真实。5.5 常见问题速查表问题场景可能原因排查与处理动作Agent响应速度慢上下文过长查看token使用量开启记忆压缩与摘要机制RPA定位不到元素页面改版切换多级定位策略失败后自动截图并转人工线索质量下降飞轮数据漂移检查环境标签人工复核策略配置账号被限制触达频率过高降低每日上限启用随机延时切换备用设备触达后无响应话术或时机问题对比不同时段和话术版本的响应率优化策略表指令队列堆积Agent产出任务过多检查调度Agent的目标分解参数增加RPA执行节点最后分享一个我个人的体会在多次迭代这套架构之后我最大的感受是技术本身不复杂复杂的是让各个模块真正配合起来。Agent再聪明如果RPA执行层不稳定一切决策都停留在“嘴上”RPA再稳定如果没有Agent的智能调度也只是多了一个能自动点击的干电池数据飞轮设计得再完美不回流到Agent策略也只是数据库里多了几张没人看的报表。所以给准备动手搭建的朋友一个建议不要一上来就追求大而全的“AI超级系统”。先把一个最小的链路跑通比如“线索挖掘Agent 影刀RPA自动发消息 日志回收”。跑通后你会发现数据会源源不断告诉你下一步该优化哪里。这个架构最迷人的地方就在于此它不是一套固定死板的系统而是一台能自我生长的机器你给它喂数据和反馈它还你更多好线索。后续可以考虑往哪个方向扩展呢我个人下一步计划是加一个AI拨号外呼的Agent来覆盖电话渠道再把短视频平台的私信场景也接进来。模块化设计的好处就是这些扩展基本不会动到底层架构。