Agent-Reach框架：把AI智能体从“会聊天”改造成“能出业绩”

上个月复盘运营数据的时候我发现一个扎心的事实团队里三十多个AI客服机器人确实都很“会聊天”但真正能把用户从“感兴趣”推进到“留资、下单、预约”的不到两成。问题不是模型不行而是大多数智能体只解决了“对话”没解决“结果”。后来我把整套逻辑重新拆了一遍做了一个内部代号叫Agent-Reach的目标触达型智能体框架才把转化这件事从碰运气变成了可配置、可调优的流水线。这里的Agent指智能体Reach指触达。Agent-Reach要做的事情很简单给Agent一个业务目标让它自动判断该触达谁、走什么渠道、说什么话术、什么时候停手然后把结果回传给人。它不是来聊天的是来完成目标的。这篇文章我会把这套框架的来龙去脉、核心设计、落地步骤以及上线后踩过的三个真实大坑全部摊开讲一遍。适合正在做AI应用、私域运营、自动化客服、线索流转的团队参考。如果你只是想抄一个“会说话”的机器人那这篇不太适合你如果你想要的是“能出业绩”的智能体那这篇你应该能省下几周时间。1. 为什么叫Agent-Reach从“能对话”到“能触达目标”1.1 大多数Agent产品只解决了交互没解决结果我见过太多团队把“用户回复了”当作“目标达成”。用户问一句“多少钱”机器人答一句“298元”对话结束然后运营看到会话记录开心得不行觉得AI真能干。可实际上呢用户问完价格就跑了既没留资、也没下单、也没预约等于白聊。真正有价值的智能体必须有一个明确的业务终点。这个终点可以是用户提交了表单线索用户点击了活动链接并完成预约用户完成了工单催办中的确认动作用户明确回复“不需要别再发了”Agent-Reach的核心思路就是把“对话”当作手段把“业务结果”当作终点。它不追求每句话都说得漂亮而是追求在整个触达流程结束时目标字段有没有被点亮。我内部给它的定义是目标触达型智能体框架 目标识别 触点选择 分步触达 反馈回收。其中任何一个环节缺失整套系统都会退化回“会聊天的机器人”。1.2 Agent-Reach的核心定义与能力边界直接说一下Agent-Reach到底由什么组成。它不是一个大模型也不是一个独立软件而是一套夹在“用户数据层”和“执行通道层”中间的调度引擎。上层接收业务目标下层对接企业微信、短信、邮件、站内信、人工坐席等触点中间用模型判断时机和话术。它的能力边界我整理成了下面这张表方便你判断自己的场景适不适合能力维度说明典型场景目标驱动每个任务都有一个可量化的预期结果线索激活、活动召回、工单催办渠道协调自动安排多个触达渠道的顺序先IM再短信最后转人工分步执行不是一次性轰炸而是根据反馈分阶段执行第一天发资料第三天追一次第五天放弃自动终止目标达成或用户拒绝后立即停止用户已预约则不再推送同类活动结果回传每次触达的结果反馈给业务系统用户看了没点、点了没留资、留资后被邀约反过来不合适的场景我也踩过。比如纯闲聊陪伴、需要强人工判断的谈判型销售、以及完全依赖用户主观意愿的开放式咨询这些场景不适合用Agent-Reach硬套。因为目标太模糊Reach就不知道该往哪走。1.3 一套能用起来的逻辑拿“线索召回”举例拿我们最常用的“沉默线索召回”来说。用户加过企业微信也点过产品页但已经14天没有任何互动。传统做法是运营手动发一句“在吗最近怎么样”——这种话术基本等于自杀式开场用户回你的概率全看心情。Agent-Reach的做法是三步走判断状态读取用户最近30天的行为事件包括访问频率、内容偏好、历史采购、退订倾向输出一个“当前可触达性”和“潜在意向度”分数。生成计划第一天推送一份匹配其内容偏好的资料包第二天只对“已打开但未回复”的用户追加一条语音留言第三天仍未响应转入人工坐席跟进。回收反馈用户只要产生任意一个关键行为比如点击资料、回复“现在不方便”、直接拉黑系统就会更新目标状态决定是继续推进还是立即终止。这套逻辑跑起来之后我的体感是智能体不再是“等着用户来问”的服务员而是“带着目标去推进”的运营专员。Reach这个词含义就是“够到那个业务结果”。2. 核心设计把触达闭环做成一个可配置的引擎2.1 目标池所有任务先被结构化Agent-Reach第一步不是调模型而是把目标结构化。我在代码里管它叫“目标对象”每个进入系统的任务都会被拆成一个JSON结构{ goal_id: GR-20240516-001, user_id: U_889912, goal_type: lead_reach, expected_action: submit_form, priority: 0.85, deadline: 2024-05-20 18:00:00, channel_plan: [im, sms, human], channel_index: 0, state: initial, feedback: [] }重点说几个字段goal_type目标类型。同一个框架可以承载多种业务线索激活、活动召回、工单催办各自有类型后续的提示词和判定逻辑都会根据这个字段切换。expected_action预期动作。这是整个系统的北极星所有触达都为了点亮它。priority优先级。0到1之间由目标价值、用户价值、时间窗口共同决定。channel_plan触达通道计划。按顺序执行每执行完一轮更新channel_index。state目标状态。initial、reaching、achieved、stopped、escalated。为什么一定要先结构化因为模型输出不稳定你需要让“目标进度”这件事脱离自然语言用稳定字段来表示。否则每次对话都要让模型重新理解“这个用户现在处于什么阶段”既贵又不可靠。2.2 意图评分把模糊感觉变成可计算分数触达之前系统先回答一个问题这个用户现在该不该触达我写了一个不算复杂的评分方法综合三个维度综合意图分 意图分 x 0.4 行为分 x 0.4 紧急度 x 0.2意图分由模型根据用户最近7天行为生成比如搜索产品关键词、反复查看价格页、在竞品评论区提过同类型问题这些会抬高分数。行为分来自业务系统里的硬指标比如访问次数、停留时长、加购动作、优惠券领取情况。行为分比模型输出更客观所以我给它的权重也是最高的。紧急度和时间窗口有关比如活动今晚结束、工单还有2小时超时紧急度会随时间快速升高。这里有一个容易搞错的点三个维度是相乘关系不是相加关系。如果你只是做加法一个用户即使行为分很低靠模型意图分也能混到0.7然后被你无脑触达。我内部的做法是先做门禁判断行为分低于0.3直接进沉默池不参与后续评分避免浪费触达成本。综合意图分出来之后会映射到三个分段0.8以上高优先级立刻进入触达流程0.5到0.8中优先级进入观察队列等行为分变化再决定0.5以下本周不触达自动进入下周重评这个分段一开始是我拍脑袋定的后来跑了三周数据发现0.8以上的用户留资转化率确实比中分段高出两倍多。所以拍脑袋不可怕可怕的是拍完不去验证。2.3 触点优先级为什么先站内信再短信最后人工触达渠道不是想用哪个就用哪个我按“成本从低到高、骚扰感从轻到重”排了一个默认顺序轮次渠道成本适用条件第一轮站内信 / 企业微信极低可推送图文、卡片、小程序第二轮短信 / 邮件低用户7天未读站内信时触发第三轮人工坐席高意图分持续高于0.8且目标接近过期每一轮只推进一个渠道等一个反馈周期再决定是否进入下一轮。这么设计是为了控制骚扰感如果用户还在站内信里活跃你直接短信轰炸人家第一反应不是“这产品不错”而是“你怎么有我手机号”。有一个细节换渠道不等于重复发同一句话。第二轮短信的内容必须比第一轮更稀缺比如增加时效权益、增加紧迫感否则用户会觉得你是群发了三遍。2.4 反馈回收与终止条件会停比会聊更重要Agent-Reach最让我觉得“值回票价”的功能是自动终止。早期版本里智能体像个推销员一样永不放弃把用户从“感兴趣”硬聊成“接电话就烦”。后来我设计了硬性终止条件满足任意一条目标直接置为stopped目标达成用户完成expected_action状态变为achieved。用户拒绝用户回复“不需要”“别再发了”“取消”或者点击退订、拉黑。疲劳度超限同一个用户30天内被触达超过5次进入冷却期。沉默上限连续两轮触达均无任何反馈自动关闭任务等待下个自然周期再评估。我把“停止”这个动作看得比“触达”更重。原因很简单一个被骚扰走的用户比十个沉默用户更难挽回。你少发一次推送损失的是一次转化机会多发一次损失的是未来三个月的所有转化机会。3. 从零到一实现Agent-Reach的关键步骤3.1 第一步先别接模型先接你的业务数据这步是我最想强调的。很多研发第一反应是“我去接个大模型”但真正决定系统能不能用的是业务数据能不能被模型读取。你需要先做三类数据接入用户画像姓名、行业、历史采购、产品偏好。行为事件流用户每一次访问、点击、下单、退订、投诉带时间戳。目标历史这个用户过去被触达过多少次、上次结果是什么。我用的方式是将这三类数据统一聚合到一张宽表里按user_id组织每次模型调用前直接查宽表不实时查库。这样部署要看的是快速迭代而不是实时推理性能压力也小。这一步能少走很多弯路。一开始我试图让模型空手从对话历史里猜用户意图结果又慢又差。接了行为事件流之后意图判断的准确率几乎翻倍。3.2 第二步定义统一的目标对象数据模型刚才说过所有任务进来都需要结构化。这一步的核心是你要先把业务目标抽象成一个字段集合而不是让每个场景自己建一个表。统一模型的JSON放在公司内部的共享包里所有上游系统只要组装出符合这个结构的对象就可以丢给Agent-Reach调度。好处显而易见新场景接入不用改框架只改channel_plan和expected_action。所有场景共享一套调度逻辑、频控逻辑、终止逻辑。数据埋点完全一致后续做评估非常方便。3.3 第三步搭建“意图识别 策略调度”双引擎我把整个大脑分成两个部分意图识别引擎负责“看人”策略调度引擎负责“做事”。意图识别引擎用的是一个提示词模板我贴个简化版给你参考你是一个触达策略助手。根据用户最近7天的行为事件判断用户完成{goal_type}的可能性。 用户画像{user_profile} 行为事件{event_list} 请输出JSON { intent_score: 0-1, reason: 简要说明判断依据, suggested_channel: im/sms/email/human }策略调度引擎不依赖模型用确定性规则保证系统不失控。我把核心调度逻辑写成了一个简单的Python伪代码思路比代码本身更重要def reach_scheduler(goal, user_events): if goal[state] in (achieved, stopped): return if user_events.has_refused(): goal[state] stopped log(user refused, stop reach) return if user_events.has_completed(goal[expected_action]): goal[state] achieved log(goal achieved, lock user) return if fatigue_exceeded(goal[user_id]): goal[state] stopped log(fatigue limit reached, cool down) return plan goal[channel_plan] idx goal[channel_index] if idx len(plan): goal[state] escalated notify_human_agent(goal) return current_channel plan[idx] feedback send_reach(goal, current_channel) goal[feedback].append(feedback) if feedback.positive_click(): goal[channel_index] idx 1 goal[state] reaching else: goal[channel_index] idx 1 goal[state] stopped这段代码明确了“智能体什么时候该干什么”。模型负责判断该不该发、发什么规则引擎负责确保不会乱发、多发、忘停。我强烈建议你保住这套确定性抽查逻辑不要连这个都指望模型。3.4 第四步接入触达通道和人工坐席触达通道的接入接口设计越统一越好。我定义了一个适配层接口每个通道只需要实现四个方法class ChannelAdapter: def send(self, user, message, params): ... def get_feedback(self, channel_message_id): ... def opt_out(self, user, reason): ... def deliverability_check(self): ...用这层抽象短信、邮件、企业微信、站内信、人工坐席都能被统一调度。人工坐席比较特殊它不是一个自动通道而是一个“可以接管任务的对象”。当目标状态变为escalated时系统生成一条“待接管工单”推给坐席坐席处理完后点击“已完成/已失败/需继续跟进”结果会回写目标状态。这一步的核心是让坐席操作也变得可编程。否则人一进来链路就断了Agent-Reach就退化成普通客服系统。4. 上线后踩过的三个真实坑4.1 坑一把“触达动作”当成了“目标”用户被刷屏第一次上线时我们犯了一个特别蠢的错误运营团队在Agent-Reach里配置了五六个并行任务活动召回、新客欢迎、满意度问卷、企业微信拉群、老客回访同时跑。结果用户一天之内收到五六条来自不同“Agent分身”的消息有人直接回复“你们是不是有病”。排查报告出来之后非常扎心每个单独任务发送的信息量都不大但因为不同的目标各自调度、互不通信同一个用户被多个智能体重复触达了。这个问题的本质是触达框架里必须有一个全局的疲劳度控制中心不管有多少个任务在跑对同一个用户的总触达次数必须统一扣减。后来我们在调度引擎入口加了一个全局频控服务规则很简单同一用户24小时内最多收到2条Agent触达同一用户7天内最多收到4条Agent触达用户处于沉默冷却期时所有任务禁止触达同一业务目标最多串行执行3轮加完之后退订率从4.7%降回1.1%转化率没降反升。因为用户终于不会被刷屏刷烦了偶尔收到的消息反而更愿意点。这里我想给你一个判断标准如果你的触达动作没有设计“停止并退出”按钮那它就不配叫触达引擎只能叫群发器。真正的目标触达型智能体是把“不打扰”当作和“高转化”同等重要的指标来考核。4.2 坑二意图识别分数画出了一条假曲线第二个坑更隐蔽。Agent-Reach跑了两周后我发现意图分高得离谱大量用户被标记为“高意向”平均分到了0.82。可转化率还是那副半死不活的样子。后来把行为事件一条条拉出来对比发现问题出在数据窗口上。当时我们给意图识别引擎喂数据时用了“最近7天全部事件”。但这些事件里既有真实购买信号也有一些垃圾事件比如误触、下拉刷新、在“关于我们”页面待了10秒。模型被这些噪音干扰把“频繁打开App”误判成“高购买意向”。打个好理解的比方一个人每天路过你家楼下看热闹跟一个人真的敲门问你“房子卖不卖”行为看起来都是“出现”但意图差着十万八千里。模型的意图分看到的是“出现了”而业务真正需要的是“有明确行动”。修复方案是加了一个“行为权重分层”行为类型权重示例强意向信号3倍点击付款页、下载报价单、咨询库存中意向信号1倍浏览产品参数、观看介绍视频噪声信号0倍滚动页面、误触、秒退同时我要求模型在输出intent_score时必须附上reason并且由规则层做一道硬校验若行为事件里没有任何一个强意向信号则意图分直接封顶0.49。这一刀切下去模型再也不敢把所有用户都打成“高意向”了。之后目标达成率明显回升因为系统能把资源集中到真正具备购买信号的人身上。这个坑给我最大的教训是模型的分数再智能也顶不住脏数据的毒打。意图评分需要经过清晰的业务信号校准不校准就等于让模型闭着眼睛猜。4.3 坑三人工坐席的加入破坏了自动闭环第三个坑出现在转人工环节。刚开始Agent经过两轮触达没能达成目标系统会创建工单转给坐席。坐席跟进后用户其实已经付了定金但坐席只在CRM里手动标记了“已成交”没有把状态同步回Agent-Reach。结果Agent-Reach不知道目标已经完成还在继续给这个用户发下一轮触达用户直接回了一句“我都付款了你们还想怎样”场面非常尴尬。这个问题的根因是我把人工坐席当成了“系统外的人”而没有把人工结果纳入目标状态机。后来补了一个很小的功能坐席接单工作台里加三个按钮——“目标已完成”“目标失败”“需要继续跟进”。坐席每点一个按钮Agent-Reach都会收到状态变更事件。这步改造不大但效果非常明显。转人工后的重复触达率从22%降到了不到3%。我也得到一个更通用的结论只要流程里涉及人就必须给人提供“上报结果”的入口否则人机协作的闭环永远有一截是断的。5. Agent-Reach的下一步评估体系和策略调优5.1 用一套“触达效率指标”代替聊天满意度做Agent-Reach之前我们看的是“机器人满意度”“会话量”“转人工率”。这些指标对客服够用但对目标触达型智能体来说毫无意义。一个用户满意地聊了十分钟但最后没留资对业务来说依然等于零。所以我把评估体系整个换掉了现在只看四个指标指标名计算方式我的目标参考值目标达成率达成目标数 / 进入触达流程的用户数8%-15%平均触达轮次总触达次数 / 目标达成数控制在3轮以内骚扰率退订拉黑投诉 / 触达总数低于0.5%人工接管率转人工任务数 / 总任务数低于10%这四个指标配合起来看能反映一个关键事实你触达得是否“猛”、是否“有效”、是否“烦人”。只看目标达成率容易变成杀鸡取卵只看骚扰率又容易变成缩头乌龟不敢触达。两个放在一起才有意义。我的实践体会是目标达成率比平均触达轮次重要平均触达轮次比响应速度重要骚扰率是前面所有指标的地板。一旦骚扰率超标优先停下整个触达计划先调频控和文案再谈转化。5.2 策略调优A/B测试什么、不测试什么Agent-Reach跑起来之后最自然的想法是疯狂做A/B测试。但测什么想清楚就不容易踩坑了。我建议把变量分成两类值得测的触达渠道顺序先站内信还是先短信测3轮整体对比。文案差异同一渠道下利益点前置型文案和故事型文案哪个更容易引发点击。频控阈值低频触达和高频触达在同一个7天窗口内的转化差异。优惠权益强度一张无门槛券和三张阶梯券目标达成率差异。不轻易测的底层模型不要因为一两天数据波动就换底座模型否则你根本分不清是模型变化还是文案变化导致的结果。目标定义expected_action不要三天两头改否则所有历史数据全部失效。评分权重0.4和0.5之间的差异除非跑满30天以上样本否则纯属自我安慰。调优的前提是日志埋点足够详细。我强烈建议从第一天开始就记录每次触达的完整链路渠道、内容模板、意图分、行为分、用户是否点击、是否转化、是否退订。没有这些数据所有“优化”都是拍脑袋。5.3 从单场景到多场景复用的扩展思路最后说说扩展。现在Agent-Reach在我这边已经不只是线索召回用了。它还被用在工单催办用户提交售后工单后未提供必要信息Agent按预设节奏提醒补充材料目标状态是“信息补全”。回款提醒B端合同到期前三天自动发送提醒及回款链接逾期后策略升级为人工催收。老客激活90天未复购用户根据历史购买品类推荐新品目标状态是“加购”。活动后召回报名未到场用户24小时内推送回放和专属券目标状态是“领取权益”。每次接入新场景我只需要写一个新的goal_type、设定expected_action、调整channel_plan和提示词模板其余调度、频控、终止、评估逻辑完全复用。这就是前面“统一目标对象模型”带来的复利。如果你要在自己团队里落地我从实际操作中给你的建议是第一次不要追求全自动先跑两到三周“人审Agent推荐”模式。让Agent生成触达计划和话术由运营人工确认后再发。这样既能快速验证目标拆分和意图识别准不准又不会因为一次自动化翻车把用户全得罪光。等积累了足够的反馈数据之后再逐步放开自动执行那时候你已经知道它在真实场景里可以用到多大程度了。Agent-Reach对我最大的改变不是写了几千行代码而是逼我把“触达用户”从一句口号拆成了可度量、可路由、可终止的系统工程。一个智能体真正的价值也不是它能聊得多热络而是它能在正确的时间、用正确的渠道、把正确的用户带到那个你真正想让他去的地方。