我是去年开始重度做智能体Agent落地的前后搭过好几套对话机器人但真正让我把注意力转到Agent-Reach这个方向上的是因为一个很现实的问题Agent可以在单次会话里表现得很聪明可一旦要在真实业务里大规模触达用户、把不同场景的任务分配给不同Agent、再让它们按策略完成动作并回收结果整套体系的复杂度完全不一样。Agent-Reach本质上解决的就是“智能体触达”这件事也就是让一组Agent能够稳定、可控、可度量地去覆盖目标人群和目标渠道把对话、通知、任务执行这些动作真正变成业务增长的手脚。这篇文章就把我在这套系统上的完整设计思路、数个关键模块的落地细节和实操中踩过的坑一次讲清楚适合正在做Agent应用、客服中台、营销触达平台或IM机器人集成的同学参考。1. 为什么需要Agent-Reach从单点智能体到规模化触达的演进1.1 从“一个Agent对话”到“一群Agent触达”的转变很多团队一开始做Agent都是先做一个“聊天机器人”的形态用户问一句Agent答一句中间接知识库、接工具调用看起来已经足够智能。但真实业务场景里Agent不是孤立的它要主动找人、要跟业务流程对接、要在多个渠道里统一身份、要与其他Agent协作。这时候你会发现单独一个Agent的对话能力再强也无法决定用户能不能被触达、消息能不能送达、动作能不能被正确执行。我拆这个问题的起点很简单把“智能体”看作一个有决策能力的大脑而“Agent-Reach”这层要做的事情就是给大脑接上手脚和神经网络让它可以主动触达用户、触达业务系统、触达各类渠道并且每一次触达都有回执、有度量、有优化闭环。换句话说没有这层触达能力Agent再聪明也只是坐在原地等人来问有了触达能力Agent才真的成为业务流程的一部分。这个转变带来的第一个变化是架构上的。原来我们只需要关心“请求-响应”这一条链路现在要有目标选择、渠道调度、消息投递、状态追踪、重试补偿、效果回流这一整张网。第二个变化是思维上的对话场景里关心的是“回答得好不好”触达场景里关心的则是“能不能在正确的时间、用正确的方式、让正确的人收到正确的信息”这是两种完全不同的工程问题。1.2 Agent-Reach要解决的四个核心问题我在设计这套系统的时候把复杂的问题收敛成四个核心问题。第一个是“我是谁”。同一个用户可能在App、小程序、公众号、短信、邮件等多个渠道出现Agent要触达他之前必须先把这些渠道里的碎片化身份还原成一个统一的用户实体否则就会出现重复触达、漏触达、甚至触达错人的问题。第二个是“触达谁”。Agent的每个动作都要有明确的目标人群这个人群可能是“近30天活跃但最近一周沉默的用户”也可能是“加购未下单的用户”或者是“客服会话中被打断的高意向用户”。这个圈选逻辑必须跟业务标签系统打通不然Agent触达得再勤也只是盲目群发。第三个是“怎么触达”。同一用户推送通知、短信、邮件、企微客服消息通道属性完全不同。有的适合紧急通知有的适合承载富媒体内容有的到达率低但成本便宜。系统要做的是根据策略把每次触达路由到最合适的渠道还要考虑用户渠道偏好、免打扰设置、频控限制这些硬约束。第四个是“效果如何”。每一次触达之后用户有没有收到、有没有打开、有没有点击、有没有引起后续转化这些数据一定要能回传并归因到具体的Agent动作和策略配置上。没有这一步Agent-Reach就只是一个消息发送器无法迭代优化。2. Agent-Reach整体架构与设计决策2.1 分层架构接入层、策略层、执行层、度量层架构搭建上我采用了很清晰的分层方式分成接入层、策略层、执行层、度量层四层。接入层负责对接上游Agent调度系统和业务系统接收“触达任务”请求统一协议、统一鉴权、统一入口。策略层是核心决策区负责身份解析、人群圈选、渠道路由、频控限流、时间窗策略等所有“智能”的部分基本都集中在这一层。执行层就比较朴素了负责把决策好的触达动作真正发出去对接各类渠道网关比如推送服务、短信服务商、邮件服务商、企微API等。执行层我做得比较薄尽量只是做协议转换、签名鉴权、发送和异常捕获把重试、幂等这些机制放到策略层或消息队列里处理避免执行层承担太多业务逻辑。度量层则是整套系统的眼睛。我在这层统一采集送达回执、点击回执、转化回执以及各环节的耗时、失败原因、重试次数清洗之后写入数据仓库。业务方和算法同学都从这层取数用来调策略和做人群体检。这四层之间全部通过消息队列解耦前面Agent调度系统发一个触达指令过来策略层算完直接丢给执行层执行层回执再异步回流到度量层整个链路不打阻塞才能支撑比较大的峰值流量。2.2 三个关键的选型权衡架构定下来之后真正磨人的是几组细节选型。我逐个说一下当时做的权衡和理由。第一组是“同步调用还是异步解耦”。一开始群里有人提方案说让Agent直接同步调渠道发送这样反馈快、实现简单。但实际压测发现短信通道99分位延迟经常到一两秒推送渠道更不稳定如果同步调用一个Agent调度线程池很快会被慢渠道拖垮下游Agent就会集体假死。最终我选的是全链路异步Agent只投递触达指令到Topic后续路由、发送、回传都走异步管道Agent侧只负责确认“指令已受理”不等待最终送达结果。第二组是“拉模式还是推模式”。拉模式是指Agent每次要触达之前主动向系统查询当前该发什么、发给谁推模式是上游把触达任务直接推给系统。对快速变化的实时营销场景推模式更自然因为我希望Agent的低层编排逻辑能实时决定触达动作。所以最终以推模式为主同时保留一个拉模式的查询接口用于补偿场景比如定时任务需要在每天早上推送前重新拉取人群标签。第三组是“规则路由还是算法路由”。渠道路由这个问题起初我天真地想直接用强化学习去动态选渠道后来发现训练数据不够、回执不够及时、业务约束又太多根本跑不起来。最终我采用了“规则优先 评分辅助”的方案先通过硬规则过滤掉不可用渠道比如用户已经退订、当前处于免打扰时段、渠道余额不足等再在剩余渠道里用一套简单的打分模型综合考虑用户历史打开率、渠道成本、消息紧急程度、内容类型选出最优渠道。这个方案实现成本低上线快而且效果上完全可控。拆完这些选型我最大的体会是触达系统这类偏向底层的平台稳定性比智能感重要得多。技术选型别追新要把“不怕流量冲击、坏了能补偿、日志能追溯”放在第一位。3. 核心环节的落地实现3.1 身份统一与触达目标解析身份统一这部分我起的名字叫“主ID图谱”。每个用户会有一个全局统一ID我们内部叫uid然后各渠道的标识都作为别名绑定在uid下面。比如小程序里有openidApp里有设备token短信里有手机号企业微信里有external_userid。触达任务进来的时候自带的目标标识会先做归一化全部映射到uid再从uid展开出来获取他要使用的推送token或手机号。这个映射表刚开始维护得比较痛苦微信的openid跟App的alias不一致、手机号更换了旧的没注销、一个手机号关联了多个账号等等各种脏数据都遇到过。后来我定了一套规则以uid为唯一权威键每个外部标识只允许绑定一个uid绑定关系变更时必须先解绑再绑定并记录操作日志。同时用一张名字像 id_mapping 的宽表来存映射查询走缓存更新走消息队列异步写库避免同步写入压垮主库。触达目标的解析也不是简单拼SQL。业务方提交目标时会带条件和标签组合我实现了一个轻量级的条件解析器支持“标签交集、并集、排除、时间范围筛选”这些常见语义。解析器先把条件转成内部AST再翻译成查询逻辑最后在用户标签库上拉出uid集合。这块我特别强调要做“人群快照”即在任务创建时把当时的uid集合固化下来而不是发送时实时查询。因为发送是异步的实时查容易导致延迟波动而且快照便于后续效果归因和重跑补偿。实际操作中代码层面比较关键的是快照存储。我用了列存格式存人群包每个任务一个文件里面只有uid列表加任务元信息。发送时从文件流式读取分批投递到消息队列。这样几十万级别的目标人群也能平稳地全部进管道。3.2 渠道能力抽象与路由策略渠道抽象这步是Agent-Reach里比较容易做乱的一环。我要求所有渠道都实现同一个接口统一提供 send、queryStatus、parseCallback、checkAvailability 四个方法。send负责发送queryStatus负责查询主动状态parseCallback负责解析渠道回调checkAvailability负责告知当前是否可用以及剩余配额。适配层把各家API的差异全部吞掉上层不管背后是自研推送平台还是第三方短信商。做一个这样的接口层好处非常明显后面接入新渠道时只需要新写一个适配器不用动任何路由和重试代码。我这边已经接过了短信、邮件、极光推送、企微群机器人、App推送等渠道每加一个大概就一到两天的工作量大部分时间花在联调回调格式上。路由策略的实现上前面说了是“规则过滤 评分排序”。过滤规则我总结成下面这张表这也是我日常排查时最爱看的几个字段规则类型判断依据命中处理用户退订用户是否在退订名单直接丢弃不触达免打扰时段当前时间是否在用户静默期延后发送或丢弃渠道频控该渠道近N小时已发次数换次优渠道渠道余额与状态checkAvailability返回false换次优渠道消息大小限制内容长度/附件是否超限转文本渠道或截断内容敏感风控命中黑名单敏感词拦截并告警评分模型的输入我取了四个特征用户近30天在该渠道的点击率、该渠道当下拥堵系数由回执延迟拟合、消息紧急程度上游任务自带标签、内容形态匹配度。四个特征各乘系数加权系统里先用固定权重跑至少两周之后再根据AB实验数据调整。有个过来人的建议是别一开始就用太复杂的模型先上了把链路跑通让数据积累起来比算法上的小儿科重要得多。3.3 重试、限流与幂等触达系统不可能不出错所以我把“失败处理”当成一个一等公民来做。所有发送失败都会进入重试管道但重试不是无脑重发。首先每个触达任务在创建时就要带一个唯一任务ID另外每条消息也有一个消息ID这俩ID贯穿始末。渠道方虽然也返回自己的消息ID但我一律用自己生成的消息ID作为幂等键回调回来时必须能对上否则不认。重试策略我分了三个级别可立即重试、可延后重试、不可重试。比如网络超时、渠道临时限流属于可立即或延后重试一般延迟10秒、1分钟、5分钟指数退避最多三次而用户退订、手机号失效、参数格式错误这类属于不可重试要直接标记为dead message并告警人工处理。这里有个坑就是渠道接口如果返回“成功”但实际没有发送成功这种情况只能靠回执超时兜底我会定时扫描那些发了很久还没回执的消息超过阈值自动转入人工核查队列。限流方面我做双层。第一层是渠道配额限流由渠道适配层从checkAvailability里拿实时配额超过配额就不接新任务宁可排队也不硬发。第二层是用户级频控同一个用户在某个自然日内的触达次数、同一个渠道的触达次数都受控这个用Redis计数器实现在策略层就掐掉避免用户被骚扰。幂等的核心是Redis加数据库双重校验。消息发出前先写入消息表状态为pending同时设置Redis键作为发送锁。画个重点同一个消息ID如果已经在pending或success状态系统直接拒绝重复投递。因为发送和状态更新是异步的仅仅依赖数据库状态会有窗口期所以Redis锁要设置合理的过期时间我们调到了2分钟保证这个链路里不会漏锁也不会死锁。3.4 效果回传与Agent-Reach指标体系整条Agent-Reach链路最后能不能自证价值关键就在指标度量。我搭建的指标体系分为送达指标、互动指标、业务转化指标三层。送达指标包括发送量、送达量、送达率、退订率、失败分布互动指标包括打开率、点击率、单次触达带来的会话轮数业务转化指标则根据场景不同而不同比如电商场景是诱导支付率、优惠券核销率客服场景是第一响应时长、问题解决率。回传机制上所有渠道的回调都先进入同一个回执Topic由回执处理器解析归类更新消息状态然后打宽表。宽表里我重点记录了任务ID、消息ID、uid、渠道、内容模板ID、Agent动作ID、发送时间、回执时间、状态、失败码、耗时。有了这张宽表后面要做任何分析、排查、AB实验都很方便。这里我要重点说一下Agent动作ID这个字段刚开始很容易忽略。因为Agent可能对同一个人做了多个动作比如先发一条优惠提醒再发一条库存紧张通知如果没有动作ID串联最后做归因的时候根本分不清是哪个Agent动作带来了转化。我要求上游Agent系统在触达指令里必须带动作ID触达系统原样透传并落库。这套机制跑了一段时间后我甚至可以清楚地算出不同Agent的触达带来的投入产出比差异从而反过来指导Agent的决策逻辑。4. 实操中的典型故障与排查记录4.1 消息积压导致Agent触达延迟上线初期最吓人的一个故障是一次大促活动的定点触达十几分钟里涌入了上百万的触达指令消息队列分片全部打满消费速度跟不上消息堆积最严重时延迟到了半小时以上。业务方的反馈很直接用户在大促预热期收到了半小时前的优惠信息领券入口都快被抢完了。这个问题的根子不在执行层而在策略层。人群圈选和路由打分做的是CPU密集计算消费并发起得不够。我做了三处调整第一人群快照改成提前生成并缓存任务创建时直接拉取快照不再实时查标签库第二路由评分的结果也做了近实时缓存同一人同类型内容在短时间内的路由结论直接复用第三把消费端做成动态扩容根据队列积压深度自动增加消费者数量。调整之后百万级别的消息在几分钟内就能全部完成路由和发送积压问题基本消失。4.2 重复触达和幂等失效有一次排查数据时发现某个渠道的短消息送达率异常偏高送达量甚至超过了发送量一看就知道有重复。查下去发现是重试机制和回调更新之间有竞态渠道返回成功但回执还没更新状态时系统又发起了一轮重试结果用户收到两遍。修复方式就是前面说的幂等键双保险核心是在重试判断里增加“回执响应等待窗口”。具体到代码逻辑上重试前必须查一下消息状态只有状态还是pending且超过重试间隔的消息才允许重新投递同时Redis锁的过期时间不能太长否则一旦消费方宕机重启锁还没过期就全都卡住了。另外我还在消息表加了一个 super_check 字段在发送前用事务做一次状态确认把最后的并发缝隙也堵上了。这个问题解决后重复率降到了万分之几以下。4.3 回执丢失让效果被低估第三方推送的回执链路是很脆弱的有时候渠道会主动重推回调有时候干脆丢了。有一次短信渠道的回执大量延迟导致送达量在指标看板上非常难看业务方差点以为系统挂了。排查后发现是回执解析器在处理某些扩展字段时抛了异常处理器没有做异常捕获一批回执直接进入了死信队列。我除了修复解析代码还加了两个防御措施一是所有回执处理都必须try-catch包裹解析失败只记录日志、不影响主流程二是对死信队列做定时重放超过一定时间还没有成功处理的回执用渠道查询接口主动查状态补偿。经过这轮调整回执完整率基本稳定在99%以上。4.4 高并发下渠道网关限流高峰期渠道商也不是稳的。短信服务商在高并发时会返回限流错误码推送网关偶尔也会直接拒绝连接。最开始我的处理很粗糙凡是被拒的直接进入重试队列结果重试太快反而加剧了渠道压力。后来我把渠道限流当成一等条件来管理每个渠道都在Redis里维护自己的令牌桶。发送之前先取令牌取不到就排队等待而不是立即触发重试。同时针对不同渠道设置了不同的重试基础延迟比如短信是30秒推送是5秒。这样做的好处是系统不跟渠道对着干而是顺着渠道的健康度动态调整发送速度整体吞吐反而提升了。5. 从Agent触达平台到Agent编排的延伸5.1 把触达能力下放到Agent编排链路Agent-Reach稳定跑通之后我开始考虑怎么跟Agent的编排逻辑做更深的联动。这个系统的标准动作是“接收指令、执行触达、回流效果”但我很快发现它可以作为Agent编排能力的一部分而不是简单的外部消息发送工具。现在我把触达结果作为Agent的记忆上下文回传给上游决策层。比如一个Agent发出“提醒用户完成实名认证”的触达后系统会把送达情况、用户是否点击了实名入口、后续是否完成了认证作为下一步决策的动作依据。这样Agent就不再是每次都要从头推理而是可以根据之前的触达反馈动态调整策略比如触达两次没效果就换话题、换渠道或者直接转人工。这种设计让Agent-Reach从工具变成了Agent的另一个“感官”。5.2 几个值得注意的原则触达是请求不是命令。所有渠道发送都可能失败必须重试、补偿、记录而不是假设一定送达。用户体验优先级要高于触达效率。频控、退订、免打扰这些规则永远置顶宁可少触达也不要让用户拉黑。指标是工程的镜子。任何一个环节没有回执就等于没有发生这句话是我这几个月听到最有价值的一句总结。保持系统简单。路由规则用配置化管理能不改代码就不改代码。灵活性和稳定性之间的平衡是这类系统长期演进的隐性格局。这个项目做到后面与其说是搭了一套触达平台不如说是重新思考了Agent跟真实世界打交道的方式。Agent的“智能”如果长在没有触达能力的身体上就像纸上谈兵而有了Agent-Reach这层能力智能才真正落到了业务动作里每一句话、每一个通知、每一次动作都有了确切的结果可以追踪。最后再分享一个很小但很实用的经验无论你的系统设计得多完善一定要把所有环节的关键字段都打日志。现在排查线上问题我第一反应都是去翻触达链路日志把任务ID和消息ID串起来从创建到回执一条线拉出来看这一步能省掉90%的排查时间。如果你也在做Agent相关的基础设施我强烈建议一开始就把可观测性当成核心功能设计进去而不是事后补。