做AI触达这个方向最怕的就是把“Agent-Reach”理解成单纯堆模型、堆外呼通道。真正跑过一遍全流程就会明白这种系统最大的坑不在某一个单点技术而在“从发现一条线索到完成一次有效对话”的整个链条怎么被串起来。Agent-Reach这个名字本身就点明了这件事——Agent负责“说话”和“判断”Reach负责“找到人”和“把话送到”。两边单独看不难难的是让它们像一个整体那样协同。这篇文章我会把Agent-Reach从设计思路、系统架构、实操落地到踩坑实录完整拆一遍。不管你是想给自己的业务搭一套智能触达系统还是正在做Agent类产品但总觉得“接不上业务”这篇都能给你一套可以直接抄作业的参考框架。1. Agent-Reach整体设计为什么是Agent而不是一堆脚本1.1 核心需求解析传统触达方式到底卡在哪先看一个很常见的业务场景运营团队手里有十万条存量用户数据要做沉默用户召回。传统的做法是写一套短信模板群发再配几个客服人工外呼。短信群发的问题很明显——用户看惯了营销短信打开率连5%都不到人工外呼又太慢十个人一天也打不了几千通而且话术不统一有的客服会追问有的用户一说“不需要”就直接挂电话浪费了太多本来可以挽回的客户。这背后其实是三个痛点触达内容不个性化、触达时机不智能、触达后的反馈无法自动沉淀。Agent-Reach这套东西要解决的就是把这三点用一个统一框架串起来。Agent不是只用来“聊天”的它要在整个触达链路里做判断——判断这个人该不该触达、用什么话术触达、用户给了什么反应、下一步该切到哪个流程。1.2 “Reach”这个词的完整含义不只是把消息发出去很多第一次接触这个概念的人会觉得“Reach”就是外呼、短信、邮件这些通道的集合其实不对。Reach包含四个层次触达前的筛选在存量列表里挑出真正值得触达的用户而不是无差别群发。这个环节通常需要一个打分模型把“高意向、中意向、低意向”分桶。触达通道的选择同一个用户可能短信已经被屏蔽了但企业微信还能联系上邮件可能没人看但电话外呼有人接。Reach要做的是根据用户历史行为自动匹配最优通道。触达过程中的动态调整用户接起电话说“我现在在开会”Agent要能识别出这个状态并自动切换成“那我晚点再联系您”的后续计划而不是继续照着话术念。触达后的反馈回流每次触达的结果包括用户说了什么、情绪怎么样、有没有意向都要结构化地存下来反哺给下一次触达的筛选和话术优化。把触达理解成这四个层次之后你就会发现Agent-Reach本质上是一个闭环系统模型、通信、业务逻辑、数据仓库全部都要打通。我见过很多团队只做了第一层和第二层结果效果不好又回去怪模型不行其实是系统架构就没搭对。1.3 方案选型思考为什么采用“大模型Agent通道适配层”的组合架构在技术选型上有个常见的争议到底是直接用大模型做全自动外呼还是用规则引擎加有限状态机还是两者结合我的选择是用“Agent为主、状态机兜底”的组合架构理由有三点。第一纯大模型在真实触达场景里不够稳用户一句“你说什么”就可能把Agent带到沟里去必须有状态机约束它的行为边界。第二纯状态机又不够灵活用户稍微换个说法就匹配不上意图更别提个性化话术了。第三这个架构有很好的演进空间——先用状态机保证下限再逐步放大模型在意图识别、话术生成上的权重项目能稳步迭代。这个思路落实到系统里就是大模型负责“感知”和“表达”状态机和规则引擎负责“调度”和“兜底”。感知是识别用户的意图和情绪表达是生成下一句要说什么调度是决定这条线索该进哪个流程兜底是万一模型输出超出预期时保证对话不会失控。2. 系统架构从一条线索到一次有效触达中间发生了什么2.1 整体模块划分调度中心、Agent引擎、通道适配层整个系统我拆成了五个核心模块每个模块都有明确的分工模块职责关键技术点调度中心管理所有触达任务的优先级、并发、频控队列、任务分片、动态优先级Agent引擎生成话术、识别意图、维护对话记忆大模型、提示词模板、状态机通道适配层统一接入电话、短信、邮件等外部通道协议转换、重试、限流数据回流层将每一轮对话结果结构化存储意图标签、情绪分值、转人工标记运营配置台配置触达策略、话术模板、接管规则可视化编排、灰度发布这里边最关键的是调度中心和数据回流层但它们是最容易被低估的。很多团队把精力全放在Agent引擎上结果调度没做好高频外呼被运营商限制数据回流没做好下一轮优化根本没有依据。我后面会详细讲这两个模块的实操细节。2.2 调度中心如何平衡“触达效率”与“用户体验”调度中心的核心任务用一句话概括就是在正确的时间、以合理的频率、把合适的任务交给合适的通道。先看时间。触达时机的选择直接影响成功率比如面向C端用户的电话外呼工作日上午10点到11点、下午3点到5点通常是接通率比较高的时段而短信更适合在用户活跃时段前后发送比如很多App的午休时段和晚间时段。系统里可以给每个任务打上“最佳触达时间窗”的标签调度中心按时间窗排列队列不在窗内的任务先挂起。再看频率。假设你给同一个用户既配了短信又配了电话外呼还配了邮件如果不做频率控制用户一天之内可能被触达四五次轻则投诉重则把号码拉黑。我自己的经验是任何单一通道同一个用户一周最多触达两次跨通道总触达次数每周控制在三次以内。这个上限可以做成系统级的硬约束任何运营策略都不能突破它。然后看并发。外呼通道的并发数不是越高越好尤其是用语音线路的时候并发过高会导致通话质量下降或者被上游通道判定为骚扰。调度中心要支持动态并发调节接通率低的时候自动降低并发等待队列积压太多的时候再逐步调高。做到这一步AI外呼的接通率一般能比固定并发高出5到10个百分点。2.3 通道适配层为什么不能用“一个云厂商的SDK打天下”通道适配层要解决的是“异构通道的统一接入”问题。每个通道的接口协议、限流策略、回调格式都不一样如果不做抽象业务代码里就会到处散落着云厂商SDK的调用换一个厂商就是一次改造灾难。我做这层时会定义一个统一的Outcome结构体包含触达状态、回执码、通话时长、录音URL等字段然后用适配器把各家通道的响应转换成统一格式。好处有两个一是业务方只需要依赖一个抽象接口不会和具体厂商绑定二是在A通道质量下降时可以快速切到B通道运维侧只需要调整配置不用改代码。如果你的项目初期只接一个通道这个看起来像是过度设计但一旦你开始接短信、邮件、电话外呼、App推送这个适配层会帮你省掉后面大量的返工成本。我从第二家通道接入起就用这种模式后续每加一个通道基本上只需要写几百行适配代码。2.4 Agent引擎SOP流程如何使用状态机落到对话中Agent引擎不是只靠大模型“自由发挥”而是在一个大框架里做生成。这个框架就是基于目标导向的状态机。举个例子一个信用卡回访任务的状态机可以这样定义{ id: card_revisit_v1, initial: opening, states: { opening: { description: 确认用户身份并说明来意, transitions: [ { on: user_confirm, to: main_question }, { on: user_deny, to: closing_polite }, { on: user_busy, to: reschedule } ] }, main_question: { description: 询问用户近期用卡体验, transitions: [ { on: positive_feedback, to: offer_recommend }, { on: negative_feedback, to: problem_solving }, { on: no_response, to: retry_question } ] }, offer_recommend: { description: 推荐新的权益活动, transitions: [ { on: user_accept, to: closing_success }, { on: user_reject, to: closing_polite } ] }, reschedule: { description: 记录回拨时间, transitions: [ { on: time_agreed, to: closing_polite } ] } } }状态机里的“on”字段就是大模型要识别并输出的意图标签。模型每轮要干两件事先理解用户当前这句话对应哪个意图标签再根据当前状态机的合法转移路径生成话术。这样即使模型生成的话术内容有偏差流程也不容易跑飞。这里有个细节值得注意状态机的转移条件要设计成“意图标签优先、规则校验兜底”。就是说模型输出一个意图标签后先丢给规则引擎判断当前状态允不允许这个转移如果不允许就按默认路径走。这样既保留了Agent的灵活性又保证了流程不失控。3. 实操过程从零搭一套最小可用的Agent-Reach3.1 准备工作先别写代码把这两张表做出来很多团队一上来就急着接大模型API结果跑到一半发现需求都还没对齐。我自己的习惯是先做两张表。第一张是触达矩阵表横轴是用户分层高意向、中意向、低意向、沉默用户纵轴是触达通道电话、短信、邮件、App推送单元格里填入每个组合下的触达策略。比如“高意向用户电话外呼”对应的是“10分钟内优先外呼专人跟进”“沉默用户短信”对应的是“低频次利益点吸引”。第二张是话术场景表列出业务里最常见的30种对话场景包括用户拒绝、用户忙、用户感兴趣、用户投诉、用户要求回电等每个场景准备两个版本的话术骨架一个偏标准一个偏个性化。这两张表做完你和业务方的认知对齐就基本完成了后面写代码时也更有方向。3.2 最小闭环设计从外呼到线索回流的完整流程第一阶段我不建议直接做全通道、全功能而是选一条链路跑通比如“电话外呼企业微信添加线索标签回流”。最小闭环包含六个步骤从CRM导出目标用户列表按用户分层打标签。调度中心按策略设定外呼时间窗和并发数。Agent引擎拨出电话在开场白后按状态机流程询问、推荐、记录意向。对话结束后把录音和对话记录存到数据仓库意图标签写回CRM。对高意向用户触发企业微信好友添加请求。后端根据标签变化自动更新下一次触达策略。这个闭环跑通后系统就有了最基本的“发现线索—触达—反馈—再触达”能力。后续在这个框架上增加通道、增加话术模板都只是量变不需要推翻架构。3.3 Agent提示词和话术生成的实际配置接下来是Agent引擎里最容易被低估的部分——提示词设计。它不像网上示例那样一句“你是一个客服机器人”就够了而是要给出足够多的上下文约束。我常用的提示词结构是这样拆的角色你是一名信用卡客户回访专员语气自然亲和不机械。 任务你需要完成一次信用卡用户回访了解近期卡片使用情况并提及一项新权益活动。 规则 1. 每次回复不超过2句话第一句回应用户当前表达第二句推进流程 2. 当用户表示忙碌时主动提议改时间不要继续介绍权益 3. 当用户表达不感兴趣时礼貌结束不做强行挽留 4. 从用户语句中提取意图只输出以下标签中的一个user_confirm、user_deny、user_busy、positive_feedback、negative_feedback、no_response 5. 不要透露你正在被录音 6. 如连续两次未识别出意图请转人工话术。这里有三个我踩过坑之后的经验要分享。第一意图标签的名称要固定。模型输出的标签如果一会儿是“user_busy”一会儿是“用户忙碌”规则引擎就没法处理所以提示词里必须限定枚举范围并且在后处理阶段再做一次“非法标签转默认标签”的兜底。第二不要透露被录音这是真实外呼场景中非常重要的合规红线但你如果不在提示词里明说模型有可能会自己冒出一句“本次通话将被录音”在一些业务里这反而会引发用户反感。先把这条规则写死在提示词里后续再根据业务实际调整。第三每轮回复限制在两句话以内。大模型天然有长篇大论的趋势外呼场景里用户没耐心听完一段长句。两句话的约束看似简单但能显著提升对话自然度和用户留存。3.4 意图识别与后端逻辑的对接方式提示词只是第一层真正要落地还得解决模型输出和代码逻辑之间的对接。我的做法是让模型返回一个结构化的JSON包含意图标签、情绪分值、话术文本三部分然后在后端做一层“意图校验”。校验规则包括意图标签必须是白名单里的同一状态下重复出现的意图不能超过两次用户表达了“拒绝”后不能再进入“推荐”路径。这层校验可以用几百行代码实现但能把系统的整体跑飞率降低一个量级。对接时还有一个小技巧不要等模型返回完整JSON才继续流程而是用“流式输出”的方式先拿到意图标签就立刻推进状态机同时并行渲染话术文本。这样用户的等待时间可以缩短一半以上体验会好很多。4. 实战中的四大坑触达率、并发、数据回流、合规边界4.1 触达率被通道质量拖垮怎么办我见过不止一个项目Agent做得很好话术也自然但整体效果很差一查发现是“接通率只有15%”——问题不在AI在通道质量。首先号码标签库要前置。接通率低的号码池里往往混了大量沉默号、空号、被标记号触达前先过一遍号码清洗服务过滤掉明显无效的号码。别心疼那一点清洗成本它换来的接通率提升是实打实的。其次本地号码比固话号码更可信。同一个业务用本地手机号外呼比用固话号码接通率高这是用户在潜意识里对号码归属地的信任度问题。如果你的通道支持归属地匹配尽量把外呼号码的归属地设置成目标用户的所在城市。最后被标记的次数一定要监控。每次触达后都要记录当前号码的标记情况一旦达到阈值就自动降低该号码的使用频次反之外呼效果好的号码可以动态调高权重。4.2 并发一高对话就乱还有一个高频问题并发量一旦上去Agent就开始“串线”——A用户的对话内容跑到B用户那边去了或者同一个用户被两个Agent同时触达。这类问题90%以上出在会话上下文的隔离上。很多开发同学会用一个大列表存所有会话记录并发一高列表读写混乱上下文就被意外覆盖。解决办法有两个一是用Redis或数据库按会话ID做独立存储每个会话的上下文只能由单个会话的处理器读写不加全局共享二是在调度层给每个任务分配唯一的会话ID并且在外部传入的请求头里带上这个ID整条链路都靠它来做隔离。如果是多个Agent实例在跑那就还需要加一层“会话归属锁”——同一时刻同一个用户只能被一个Agent实例占用。这个锁可以放在调度中心里以用户ID为粒度加分布式锁超时时间设为60秒到期强制释放并转人工。4.3 数据回流不完整后续优化没有依据回到最前面说的闭环逻辑。闭环要成立数据回流就必须完整。可实际中很多项目只回传了“通话时长”和“用户是否接听”这种粗粒度数据关于用户在对话里说了什么、情绪如何、最终有没有产生意向全都丢了。这个问题要从对话的一开始就设计解决。Agent在每一轮都要输出结构化的过程数据包括当前状态、识别到的意图、置信度、话术模板版本号。这些过程数据全部写入日志系统再通过定时任务汇总到数据仓库。这样后续优化话术时就能直接对比“话术A被拒率”和“话术B被拒率”到底差多少而不是靠感觉拍脑袋。另一个容易被忽略的是负面情绪预警。对话结束后如果系统识别到用户情绪值低于某个阈值要自动把记录推给人工客服做回访防止用户不满升级成投诉。这条看起来简单但能帮你避免很多业务风控上的麻烦。4.4 合规和安全的边界哪些事情必须做在前头做触达系统合规问题绝对跑不掉尤其是外呼场景。第一必须有用户授权或者合理的业务关联。你有没有想过用户接起电话的第一反应是“你怎么知道我的号码”所以触达前必须确认号码来源是用户主动留资、历史下单或其他具备业务关联的途径。不要从来路不明的渠道买号打。第二必须提供退订入口。短信场景要在内容里带退订指令外呼场景用户在明确表示“不要再打了”之后系统要立刻停止对该用户的所有触达任务。这里不光是人情问题也是底线问题。第三通话录音的告知。不同业务对告知要求不一样但整体原则是“告知越充分风险越低”。即便你在提示词里说“不要主动透露录音”也应该在系统的首次通话转接或IVR层级里给用户明确的录音提示让用户在知情的前提下继续对话。这些合规措施看似降低了触达效率但实际上它们保护的是你整个通道的可用性一旦通道被投诉停用损失的效率远大于那一点合规成本。5. 效果评估与持续优化怎么判断Agent-Reach真的跑起来了5.1 核心指标不要只盯“接通率”和“对话轮数”很多团队评估触达系统只盯接通率和平均对话轮数但我觉得这两个指标只能反映系统“通没通、聊没聊”不能反映业务目标达成没有。更实用的指标应该围绕业务结果来定。我自己在项目里会重点看三个指标意向率对话结束后被标记为“高意向”或“中意向”的用户占有效接通用户的比率。它直接反映话术和策略好不好。转化率意向用户最终完成目标行为的比率比如加了企业微信、领了权益、预约了到店。这是系统最终价值的证明。成本漏斗打响数、接通数、有效对话数、意向数、成交数每一层的转化损耗都要量化。如果某个环节损耗过大问题就集中在那里排查而不是漫无目的地优化话术。5.2 优化方法用“A/B实验过程数据”驱动迭代系统上线后最常用的优化路径有这么几条。第一话术实验。同一场景准备两个版本的话术模板随机分给同等数量的会话跑一周之后对比意向率和拒绝对话比例。实验数据足够时直接把优版本全量上线。这就是过程数据回流的价值。第二通道策略调优。如果发现某条通道的接通率连续几天下降大概率是被通道侧限制或号码被标记增多了这时要主动降低该通道的量级把任务切到备用通道。备用通道的建设优先级应该在一开始就被拉高。第三用户分层迭代。把“从未被触达过的用户”和“已经被触达过两次的用户”分开打标签分别用不同策略对待避免一刀切。反复被触达但始终没有意向的用户应该自动进入“冷却清单”降低触达频率把资源让给更可能转化的用户。从实际经验看做完这三轮优化意向率普遍能比冷启动时提升30%到50%。这个提升不是某一个技术点的功劳而是调度、话术、数据回流、通道策略共同迭代的结果。5.3 一个关于人机协同的额外建议最后提一个经常被忽略的环节——人机协同。全自动Agent再聪明也没法完全替代人在关键节点的判断。我的做法是给系统设置三个“人工介入点”用户对话中出现强烈负面情绪时、用户明确要求“找人工”时、高意向用户完成会话准备进入成交环节时。这三个点自动把会话转给人工客服系统为人工提供完整的前序对话摘要、意向标签和话术建议。人机协同的好处有两方面。一方面业务成交流程里“临门一脚”通常由真人才最稳妥另一方面人工接管的对话记录又能反哺给模型做优化。一次人工成功转化的对话拆解后可能就是下一次Agent话术改进的最佳样本。让Agent和人在自己的位置上各司其职这才是Agent-Reach这类系统最终应该呈现的形态。
