前段时间和一个做B2B获客的朋友聊天，他说自己团队每天要处理十几个平台过来的线索：官网表单、内容平台私信、展会扫码、广告落地页、老客户转介绍，格式五花八门。光是筛重、打标签、录入CRM、发第一封触达邮件，四个人一整天都干不完。我听完第一反应是：这活儿早该交给机器了。但真正动手搭系统的时候才发现，问题没有想象中那么简单——纯RPA只能把重复动作机械化，页面一改版就罢工；纯AI Agent能思考能写方案，但没有"手"，所有的结论都停在建议层面。最后我把AI Agent、RPA执行、数据飞轮三个部分拼成了一个完整架构，跑通了从线索接入到第一轮触达的全链路自动化。这篇文章就是把这套架构的拆解思路、关键设计和踩坑记录完整写出来，给正在做AI获客方向的朋友一个可以参考的落地方案。

1. 获客链路的核心痛点：为什么单点工具撑不起自动化

1.1 十多个平台、上千条线索背后的手工地狱

先还原一个真实的获客场景。一个中等规模的B2B业务团队，市场投放渠道不会少于五个：搜索引擎广告、内容平台、行业垂直媒体、线下活动、老客转介绍。每个渠道进来的线索字段完全不一样——有人在表单里填了公司名和电话，有人在私信里只留了一个微信，有人下载资料的时候填了职位但没填行业。这些线索首先要做归一化：去重、补全、清洗、分级，然后才能进CRM分配销售。

我见过很多团队在这个环节的做法是：运营从各个平台后台导出Excel，用VLOOKUP筛重，手工补字段，再人肉导入CRM，最后再手动写第一封跟进邮件。一个人一天处理两三百条已经是极限，而且这种高强度重复操作极易出错——比如同一家公司用不同销售邮箱注册了两条线索，系统没识别出来，销售各自跟了一周才发现撞单。

更麻烦的是时效性。广告投放带来的线索，黄金跟进窗口可能就是前几分钟到前几小时，晚一步客户可能已经加了别家销售微信。人工处理模式下，白天还好，晚上和周末进来的线索只能躺在后台等到第二天，错失率非常高。

1.2 AI 能"想"、RPA 能"做"，但二者单独用都不够

过去两年我试过不少单点方案，也见过同行在这个方向上的不同尝试，先说结论：只上 AI 或只上 RPA，都解决不了完整问题。

只接一个大模型对话助手，它确实能做到很多事情：帮你把线索字段结构化、生成个性化的第一封触达邮件、甚至通过对话让运营问答式地查询线索状态。但它有个天然短板——没有"手"。它不会真的去登录广告后台把线索导出来，不会自动去CRM里创建联系人，更不会定时把跟进任务推送给对应销售的企微。所有的结论输出到聊天框就结束了，落到业务上还得靠人再操作一遍。

只上 RPA 则走向另一个极端。RPA 非常擅长模拟人工操作：打开网页、点击按钮、填表、发消息、读取Excel，这些重复动作它可以7x24小时稳定执行。但 RPA 的逻辑是固定的，页面上一个按钮改个class名脚本就挂了；遇到"这个用户问了一个非标准问题"的情况，它没有任何应变能力；更不用说从一堆线索里判断谁更值得先跟、用什么话术跟——这些决策它完全做不了。

所以我的结论是：必须把"脑"和"手"接起来。大模型负责理解、分析、决策、生成内容，RPA负责把决策变成真实的操作，中间再穿一条数据流，让每次执行的结果都能反哺下一次决策。这才有了后面这套三层架构。

2. Agent 协同层：五个角色如何各司其职

2.1 情报 Agent、策略 Agent、内容 Agent、执行 Agent、复盘 Agent 的具体分工

再往下聊架构之前，先明确一个设计原则：我不会把所有的智能化能力塞进一个Agent里。原因后面单独说，先看我是怎么拆的。

整套系统的智能层一共五个Agent，每一个只做一件事：

以一条线索的生命周期来看，它的路径是这样的：广告后台新增一条表单线索，情报Agent定时抓取后做字段归一化，补充公司规模、行业标签，然后写入线索池广播事件；策略Agent收到事件后根据线索评分规则判断优先级，决定"30分钟后通过邮件先触达，如果48小时没回复再换私信渠道"；内容Agent根据客户画像和产品特点生成对应版本的邮件内容；执行Agent收到任务后把任务塞进队列，调度RPA在指定时间点执行发送；发送完成后回复数据回流，复盘Agent每周做一次分析，输出话术和渠道的优化建议。

这套分工的好处是每个Agent的提示词都可以写得很聚焦。情报Agent只关心数据格式对不对、字段全不全，不需要懂销售话术；内容Agent只需要管文字好不好，不需要关心怎么登录后台。提示词短了，出错的概率和token消耗都会明显下降。

2.2 协作机制：任务下发、结果回传与状态同步

Agent 之间不是简单互相调用，我采用的是"事件驱动 + 任务队列 + 状态机"的组合方式。

具体来说：每个Agent处理完自己的环节后，不是直接调用下一个Agent的方法，而是把结果写入一个共享事件流（我用的Redis Streams，也可以用Kafka或者甚至一张MySQL表来当队列用）。下游Agent订阅自己关心的事件，收到后再触发下一步动作。

比如执行Agent给RPA下发任务时，我会先创建一个带唯一ID的任务记录，状态是pending，然后把RPA要执行的指令序列以JSON形式写入指令队列。RPA执行器消费队列，执行过程中不断把状态回写为running、success或者failed。整个链路通过这个任务ID串起来，任何一个环节出了异常，都能很快定位是哪一步。

一段简化的伪代码大概是这样的：

# 策略Agent产出任务后，提交到执行队列 def dispatch_task(lead): task = { "task_id": generate_uuid(), "lead_id": lead.id, "action": "send_email", "channel": "email", "timing": "t+30min", "content_id": content_result.id, "priority": lead.score } queue.push("rpa_task_queue", task) # 进队列 state.set(task["task_id"], "pending") # 状态机置为待执行 return task # RPA执行器消费 def rpa_worker(): while True: task = queue.pop("rpa_task_queue") state.set(task["task_id"], "running") try: rpa_client.execute(task["instruction"]) state.set(task["task_id"], "success") except Exception as e: state.set(task["task_id"], "failed", reason=str(e))

这套设计让我能很清楚地回答"系统现在的任务卡在哪"这个问题。以前没有状态机的时候，Agent之间互相直接调用，一旦某个环节超时，整个链条就是一团乱麻，后来加上任务ID和状态流转，排查效率提升了一个量级。

2.3 为什么我坚决不用"一个大而全的 Agent"

其实最早我也偷懒过，试图让一个大模型Agent包揽所有环节：给它所有工具——抓数据、写文案、发消息、分析数据，让它自己看着办。结果跑了一个多星期，效果惨不忍睹。

第一个问题是上下文爆炸。一个大Agent要把情报、策略、内容、执行、复盘的能力都装进去，系统提示词写了上千行，每次对话还要携带大量的中间状态和工具返回结果，经常一轮还没跑完就到了上下文长度上限，后续动作直接"失忆"。

第二个问题是职责耦合导致的提示词互相污染。让同一个模型同时扮演"冷静的线索打分员"和"有感染力的文案写手"，这两种风格会产生冲突，模型经常在线索分析任务里开始讲段子，写文案的时候又一副数据分析师的口吻，质量极不稳定。

第三个问题更现实——故障隔离太差。大Agent里任何一个小工具调用失败，整个流程就断了，而且定位问题非常难：到底是模型理解错了、工具报错了，还是参数传错了？都要从一大坨日志里慢慢扒。

拆成多Agent之后，这三个问题都缓解了。每个Agent可以独立调试、独立升级，内容Agent想换更强的模型不需要牵动其他模块；情报Agent抽风了，任务队列里其他Agent的数据还在，系统不会瘫痪。代价是多了一层协作的复杂度，但从工程可控性的角度看，这个代价非常值得。

3. RPA 执行层：Agent 的"手"怎样把动作落到实处

3.1 Agent 与 RPA 的边界：谁决策、谁动手

前面聊的Agent再聪明，最终还是要落到"真的去网页上点一下按钮"这个动作上。这里就涉及我整个架构里我认为是最关键的边界划分：Agent只做决策，绝不直接操作界面；RPA只做执行，不做任何理解。

为什么不直接用Agent去操作浏览器？现在确实有方案让模型直接控制页面，比如截屏然后输出坐标去点击，或者让模型调用浏览器API去操作DOM，听起来很"原生化"。我试过，体验并不理想：直接截屏点击的方案，模型每做一步都要截图、分析、生成坐标，一次操作要好几秒，而且页面布局稍微变一点坐标就全错；直接操作DOM的方案，成本和延迟虽然低一些，但对页面的兼容性要求很高，稍微特殊的页面结构就会抽风，出错后还很难有稳定的重试方案。

RPA在"稳定执行重复操作"这件事上积累了十几年能力：元素选择器、图像识别、OCR、录制回放、断点续跑，这些能力是现成的，而且执行效率和稳定性都远超让模型自己上手。所以我的最终划分是：Agent负责"做什么、什么时候做、怎么做更好"，把具体指令翻译成结构化的操作序列；RPA负责把操作序列老老实实变成鼠标键盘的动作。就像人体里大脑做决策，但真正动手动脚的是肌肉和骨骼，你不可能让大脑直接去搬砖。

3.2 执行稳定性设计：重试、补偿与人工兜底

RPA执行层在真实环境里最大的敌人不是"不会做"，而是"做挂了没人知道"。我在这套系统里总结了RPA执行会遇到的三大类问题：元素定位失败（页面上按钮找不到）、超时（页面加载慢、网络抖动）、意外弹窗（Cookie同意框、公告浮层等）。

针对这三类问题，我的方案是给每个RPA操作定义一套三级容错逻辑。

第一级是选择器降级。影刀这类RPA工具里，一个按钮通常可以配置多种定位方式：元素选择器、图像识别、OCR文本匹配。默认用选择器，如果失败就自动降级到图像识别，再不行就OCR找文本。绝大多数元素定位问题在这一级就能解决。

第二级是有限重试。操作失败后，不是立刻报错，而是退避重试，比如间隔10秒、30秒、60秒各重试一次，每次重试前先做一次页面状态检测（比如判断页面标题、URL、有没有特定元素），防止在错误的状态下盲目重试。

第三级是人工兜底。同一操作连续失败3次以上，系统会把当前页面截图、操作日志、失败原因打包，通过企微通知到值班人员，并且自动暂停这个RPA任务的下游动作，防止在异常状态里越走越远。

这一整套逻辑里，我踩过最大的坑是"过度重试"。早期我把重试次数设成10次，结果有一个任务因为目标系统正在做版本升级，页面元素全部变了，RPA在十分钟里重试了10次，把目标系统打了一堆无效操作。后来我加了一个熔断机制：如果某个任务的重试次数和失败模式有规律可循，就直接熔断进入人工处理，而不是无脑重试。

3.3 安全闸门：哪些动作必须过人工审批

自动化系统一定要留有刹车，尤其是涉及对外动作的场景。我在设计执行层时定了一条铁律：高风险的对外操作，RPA执行前必须先过一道"审批闸门"。

哪些算高风险？我列了一个清单：发送带报价单或合同的邮件、大批量群发触达（超过一定数量）、删除或修改CRM里的已有数据、向外部系统提交订单或支付操作。这些动作执行Agent不会直接下发，而是先生成一条审批任务，推送给业务负责人，负责人审核通过后，流程才继续。

审批的载体我直接用的企微或飞书机器人卡片，卡片上会显示这条任务的完整上下文：什么线索、基于什么策略判断、要在什么时间发什么内容。负责人点击通过，机器人回调接口把任务解锁；点击拒绝，任务直接终止并记录原因。这套机制看起来牺牲了一点点全自动化程度，但换来了业务对系统的信任感。我见过不少团队急吼吼做全自动化，结果一次误操作把报价发给了错误客户，整个项目直接被叫停，得不偿失。

需要说明的是，这个闸门不是永远不变。系统运行一段时间、稳定性和准确率都验证过之后，是可以逐步下放权限的。比如把"单条报价邮件需要审批"改成"单笔金额超过一定数量的报价才需要审批"，把低频的审批权限收回来，把高频的放给系统。自动化的本质是管理风险，不是消灭风险。

4. 数据飞轮：执行结果如何反哺下一次触达

4.1 从执行端到数据湖的回流路径

很多做自动化的项目死在哪？不是系统跑不起来，而是跑起来之后没有数据沉淀，等于让系统在黑暗里重复劳动。所以我从第一天开始就坚持：每个动作都要留痕、留数、留上下文。

我把数据回流分成三个层面。第一层是RPA执行过程数据：每个任务的开始时间、结束时间、成功或失败、每一步操作的耗时、元素匹配的命中率，这些数据用来评估RPA本身的健康度。第二层是Agent决策数据：策略Agent当时为什么判定这个线索是A级、内容Agent生成邮件时用了哪些模板和变量、执行Agent选择了哪个发送渠道，这些数据让"决策过程"变得可回放。第三层是业务结果数据：邮件打开了没有、链接点击了没有、客户回复了什么、有没有约上会议，这些是最终的效果反馈。

这三层数据会统一通过一个轻量级的ETL流程写入数据仓库。我的架构里这一层没有做得很重，因为实时性要求没那么高——RPA的执行日志实时写入Redis和日志文件，每5分钟批量同步一次；业务结果数据则通过各平台的回调接口实时接入。数据量也不会大到需要上沉重组件，一台上限适中、配置合适的普通服务器上跑一套MySQL配合分析型数据库，完全扛得住。

4.2 线索评分、话术迭代与策略调整的闭环

数据回流之后，飞轮就转起来了。整套系统里，数据反哺最明显的三个环节是线索评分、话术优化和触达策略调整。

先说线索评分。情报Agent的标准化线索包进来之后，策略Agent会算一个分，这个分决定这条线索排在触达队列的哪个位置。评分公式并不是一开始就设计好的，而是通过历史数据回归出来的。我最初的版本就是一个简单加权：

score = 行业匹配度 * 0.3 + 公司规模分 * 0.2 + 行为热度分 * 0.3 + 渠道质量分 * 0.2

跑了一阵子之后复盘Agent发现，来自特定渠道的线索虽然量大，但成交率特别低，反而是另一个渠道的线索虽然数量少，但回复率和成单率都高。于是我把渠道质量分的权重从0.25调到了0.35，行业匹配度权重稍微下调，整体转化率确实上去了。

话术迭代更有意思。内容Agent生成触达文案时，不是每次都从零开始写，而是基于一个"高转化话术库"来改写。复盘Agent每周分析一次所有触达邮件的打开率、回复率、负反馈率，把表现最好的Top文案拆解成可复用的结构和变量，回填到话术库里。比如其中一个发现是：邮件标题里如果含有客户公司所在行业的近期动态关键词，打开率会比通用标题高不少；私信第一条如果只提"最近看到贵司在招XX岗位"而不直接推产品，回复率反而更高。这些规律来自真实数据，比拍脑袋写得靠谱太多。

触达策略调整则是另一个维度。执行Agent会给每个线索记录"触达历史"——什么时间、通过什么渠道、发了什么内容、结果如何。复盘Agent分析这些记录后，能发现一些时间规律：比如早上八点到九点发邮件打开率最高，午休时间发私信回复率更好，周五下午尽量不要发触达类内容。这些规律会被写回策略Agent的规则库，下一条同类线索进来时，触达时间就自动优化了。

4.3 转速调优：最容易被忽视的双写一致性问题

数据飞轮听起来很美好，但真正把系统跑起来之后，我碰到的最头疼的问题不是算法，而是一个看起来不怎么起眼的工程问题：双写一致性。

什么意思？执行端（RPA和业务系统）和决策端（Agent和历史数据）各自维护了一份数据，比如一条线索的状态，执行端更新了"已发邮件"，如果这个更新没有及时同步到决策端，策略Agent可能判断"这条线索还没触达过"，于是再发一次，造成重复触达。

我踩过这个坑。早期线索状态是两边各写各的，执行端写自己的库，决策端定时同步，结果有一次同步延迟了半小时，二十多个客户在一个小时内收到了两遍一模一样的触达邮件，投诉直接打到销售负责人那里。从那以后我改成"单一数据源"原则：线索的触达状态只用一张表、从一个接口写入，其他所有模块要读状态都从那一个地方读，不再搞本地缓存副本。如果确实需要缓存，也会加上显式的失效时间和版本号，保证最终一致。

飞轮的"转速"也需要控制。我见过有的团队把复盘周期设成实时，每个小时都用最新数据调整策略，结果模型被短期波动带着走，策略天天在变，执行层反而乱了。我的经验是：执行过程数据实时回流没有问题，但策略调整类反馈一定要有周期，复盘Agent一天一次、特殊渠道专项分析一周一次，给短期波动一个沉淀期，这样飞轮转得才稳。

5. 上线过程中的关键决策与踩坑记录

5.1 调度冲突：多个 Agent 并发时的资源竞争

系统真正开始并发跑任务的时候，第一个翻车点不是模型，也不是RPA工具本身，而是任务调度。我有一次同时跑了三个渠道的线索接入任务，情报Agent、策略Agent、执行Agent全部并发工作，结果同一个RPA机器人被同时塞进来两个任务，一个在登录后台，另一个也去登录后台，两个流程互相打架，最后双双失败。

这个问题后来通过调整调度策略解决了。核心原则是：写操作串行化，读操作并行化。凡是要登录系统、要往外部平台写数据的操作，全部进同一个串行队列，由调度器按优先级和任务类型一一执行；只读的抓取、查询类操作可以并行。调度器里再给不同渠道的任务设置最大并发数，保证任何时刻全局并发不会超过RPA机器人数量和目标系统能承受的极限。

这里我建议在项目早期就把任务调度层的抽象做好，不要等到并发出问题再来补。一个简单的调度器，几百行代码就能实现，优先级、超时、重试、并发数控制，一个都不能少。

5.2 平台风控与触发阈值：如何把控节奏

自动化系统大规模运行时，一定会和平台的风控系统打交道。这个问题的核心不是"怎么绕过规则"，而是"怎么在规则内保持合理的节奏"。

我踩过的一次教训是群发私信。最开始触达策略刚上线，为了快速验证效果，我把同一批线索的私信发送间隔设得很短，结果不到两天，账号就收到了平台警告，私信功能被限制了一周。整个触达链路瘫痪，损失远大于那几天的测试收益。

从那以后，我建立了一套节奏控制机制。每类触达动作都配置了明确的最小间隔和每日上限，间隔参数不是一个固定值，而是带随机抖动的区间，避免出现毫秒级精准规律的机器操作特征。更重要的一点是：单个账号的触达量绝对不能超过平台对人工操作的正常预期范围，如果线索量大，就要分摊到多个账号、多个渠道去做平衡。这部分内容执行Agent会严格按照配置来，不能为了短期转化率去赌账号权重。

我把这套机制里的关键参数放在一个配置中心里，运营可以在不用改代码的情况下动态调整。每次调整参数后，系统会给出一个预估的"风险等级"，如果当日触达量超过阈值，调度器会直接拒绝执行并提示运营确认。

5.3 合规红线：数据来源、触达方式与授权管理

最后一条必须单独讲：合规。自动化获客是把双刃剑，用得好是效率神器，用得不好就是合规事故。

我给自己定了几条不能碰的红线。第一，数据源必须合规。系统处理的线索只允许来自广告后台的正式授权数据、官网表单的客户主动留资、公开渠道的企业信息，以及客户已授权的存量CRM数据。任何通过非正常手段获取的个人联系方式，一律不进系统。第二，触达必须尊重用户意愿。每一条触达内容里都会带上退订或者拒绝的方式，用户一旦表达了拒绝意向，系统会立即把该用户拉入黑名单，所有后续触达任务自动取消。第三，审批记录完整留存。前面说的审批闸门，每条审批的发起人、审批人、时间、意见都会记录，出了问题可以追溯。

这些要求看起来增加了很多流程负担，但从长期看是必须的。我见过有的同行在自动化获客上冲得很快，结果一次数据合规问题，整个项目被停掉，公司还被处罚，得不偿失。自动化系统越强大，越要给自己戴上缰绳。

6. 成本结构与架构演进方向

6.1 token、RPA 机器人数量与实际转化率的平衡

很多人在设计这类系统时忽略了一个实际问题：成本模型。我先列一下我实际运行这套架构的主要成本项，用表格会更直观：

跑下来最直观的经验是：不要把五个Agent都接到同一个最强模型上。情报Agent和处理结构化数据的策略Agent，用轻量模型就够了，响应快、成本低；真正需要语言生成能力的内容Agent，再上更强的模型。这样一来，整体API成本能下降很多，而输出质量几乎没有下降，因为结构化处理根本不需要那么强的生成能力。

RPA机器人的数量和执行任务量之间也不是线性关系。一个机器人同时只能跑一个流程，但如果任务本身耗时短（比如发一封邮件只要30秒），一个机器人一天就能处理上千个任务。所以不要一开始就买一堆机器人许可，先跑最小闭环，看任务积压情况再决定是否扩容。我现在的配置是三个机器人支撑了全天五千个触达任务，其中一个还主要用来跑报表生成，负载并没有想象中那么高。

6.2 从"流程自动化"到"决策自动化"的演进路径

最后聊聊这套架构未来还能往哪个方向走。我目前跑通的是第一层：流程自动化——Agent做规则内的决策，RPA把决策执行掉，数据回流后优化规则。这个过程里，"决策"本质上还是人在制定规则，Agent只是更快地执行规则。

下一步我计划往决策自动化走。具体来说，就是从"固定规则 + 参数调优"升级到"策略自动探索"。比如现在的策略Agent决定触达时间靠的是复盘Agent总结的历史规律，这些规律还是人review过再加入规则库的。未来可以让系统在多个策略间做小流量A/B测试，自动找出效果最好的组合，再自动扩大应用范围。内容生成也是类似的方向：从一个话术模板库扩展到基于历史反馈内容的动态生成，甚至针对每个用户生成多版文案做A/B测试。

这个演进方向对数据飞轮的要求会更高。策略自动探索意味着系统需要更细粒度的数据回流、更清晰的效果归因、更完善的防失控机制。但这也是整套架构最有想象空间的地方——当系统开始用数据自己做决策并不断迭代时，它才真正从"自动化工具"变成了"增长引擎"。

做了这套架构小半年，我最大的感受是：AI获客智能体的核心难点其实不在"AI"，而在工程化。模型能力大家都有，真正拉开差距的是分工设计、调度稳定性、数据闭环和合规控制这些看着不起眼的工程细节。如果你正准备做类似的方向，我的建议是别贪大求全，先把一条渠道、一个触达动作跑通，把数据回流和审批机制搭好，再往多Agent、多渠道扩展。自动化这东西，跑得起来不算本事，跑得久、跑得稳、出事能刹车，才算是真正落地了。