★ FEATURED ARTICLE 差不多一年前我们团队开始把AI Agent从“能对话”往“能办事”的方向推结果第一个拦路虎不是模型效果而是触达能力。你让Agent去预约会议、发通知、做回访它总得有办法把消息送到人面前送到微信、邮件、短信、站内信甚至语音外呼里。一开始我们直接在业务代码里堆渠道调用每个场景一套逻辑改需求就要动一大片代码。后来实在扛不住了沉淀了一套内部系统代号就叫“Agent-Reach”。这套东西专门解决智能体触达范围、渠道编排和消息可靠性的问题今天把它拆开了讲讲适合正在做Agent落地、或者被消息推送和触达逻辑缠住手脚的技术团队参考。Agent-Reach说白了一个道理Agent不需要关心对方在哪个渠道上只需要提出“我要触达这个用户优先级很高限时10分钟内送达”剩下的渠道选择、频控、重试、回执全部由触达层来完成。这个抽象做扎实之后业务代码从每个渠道各写一套变成了只面向一个API开发效率和稳定性都上来了。1. 为什么需要Agent-Reach智能体触达问题的解题思路1.1 智能体触达和传统消息推送的本质差异很多人第一反应是消息推送平台都那么成熟了为什么还要自己做这里有个特别容易踩的误区。传统消息推送解决的是“把一条模板消息发给一批人”它面向的是固定文案、固定渠道、一次性执行。Agent-Reach这类智能体触达层解决的是“在对话上下文中把一条动态生成的消息用最合适的渠道、在合适的时间送达指定的人”并且要支持多轮交互、跨渠道接力、按用户实时状态切换策略。举个具体例子。传统推送里“您的订单已发货”这种消息文案是运营写死的渠道是预先配置好的。Agent场景里Agent要先判断用户当前活跃在哪个端如果用户在手机App上聊过天优先走站内推送如果超过30分钟未读自动转短信再不行降级成语音外呼。这个过程里消息内容是Agent生成的触达策略也是动态算出来的。这套逻辑放在业务代码里会非常痛苦因为它不是纯业务也不是纯渠道是两者之间的一层编排。Agent-Reach把这一层单独拿出来之后业务方只做一件事调用统一的触达API传入接收方ID、消息内容和意图标签。至于这个用户是否订阅了某个渠道、今天已经收到几条短信、该走Webhook还是渠道原生接口全部下沉到Agent-Reach内部处理。这个设计不光减少重复代码更重要的是触达策略可以统一迭代不会出现A业务换了策略B业务还在用老逻辑的情况。1.2 触达层设计里的“可控”和“可观测”做触达层我最看重两个词可控、可观测。可控是指任何一次触达都可以被取消、被延后、被替换渠道可观测是指每一条消息的最终状态都能追踪到。传统消息推送把消息发出去就算成功但Agent场景里消息送达只是开始用户有没有看、看完有没有回复、回复后Agent怎么接上下文这些都要有迹可循。所以在Agent-Reach里一条消息从业务侧提交开始就绑定了一个唯一的触达任务ID这个ID贯穿渠道调用、重试、回执、上下文回传的全过程。业务侧随时可以查这个ID的当前状态也会通过回调收到状态变更。这个设计在排查问题时特别有用不用像以前那样用户说没收到消息只能挨个去翻各个渠道的后台日志。“可控”还体现在渠道注册上。Agent-Reach对每个渠道都做了统一的接口抽象渠道可以是微信服务号、邮件系统、短信网关、语音外呼也可以是你们自己内部的App推送网关。每个渠道注册时要声明自己的速率上限、单条消息长度限制、回调能力。Agent-Reach在路由时就会考虑这些约束不会把超过渠道能力的消息硬塞进去。2. 核心拆解Agent-Reach的路由、上下文与幂等控制2.1 路由判断不只看渠道还要看状态和成本Agent-Reach的路由不是简单的if-else而是一套基于规则的评估器。每次触达请求进来时路由引擎会读取以下几个维度的数据接收方ID、接收方当前的在线状态、用户在各个渠道上的历史互动频率、消息的紧急程度、以及渠道当前的健康状态。举个例子同样一条“您的订阅即将到期”提醒如果用户最近三天都在App里活跃Agent-Reach会优先选择站内推送如果用户已经一周没打开App但留了手机号并且手机没在免打扰时段就自动走短信。这两个决策在代码里是一个策略列表每个策略有一组条件和一个权重按顺序评估。实际跑下来这套规则比让业务方自己判断要准得多因为业务方往往只有用户ID没有全渠道行为数据。成本控制也是路由时必须要考虑的。短信和语音外呼都是真金白银不能什么消息都往贵渠道上怼。Agent-Reach里允许为不同渠道配置成本系数路由引擎在多个渠道优先级相近的时候会倾向于选成本更低的。这个设计听着简单实际帮忙省了不少预算尤其是批量触达场景成本差一个数量级都是可能的。2.2 上下文绑定每一条触达消息都是一个对话节点Agent场景下消息不是孤立存在的。用户收到一条短信回了一个“好”这个“好”如果不能回到Agent的对话上下文里触达就是断链的。因此Agent-Reach在触达消息里嵌入了上下文标识渠道的回执和用户回复会带着这个标识回到Agent编排层。这个上下文标识的设计要特别注意长度限制。短信场景里标识不能太长邮件的限制宽一些站内推送给个整数ID就够了。所以Agent-Reach内部用的是短ID加签名的方式把上下文压缩成一段十几位的字符串放到各个渠道允许的自定义字段里。用户侧看到的短信文本保持干净背后的标识跟着消息走。跨渠道接力也依赖这个上下文。比如Agent通过站内推送给用户发了一个调查问卷链接用户没点半小时后转成了短信短信里带的链接其实指向同一个交互会话。用户不管从哪个渠道点进来Agent都能知道“这是他上次没回完的那个问卷”。没有上下文绑定这种体验根本做不出来。2.3 幂等重复触达是体验事故的源头触达场景里最隐蔽的问题就是重复消息。网络超时、渠道回调重试、前端按钮双击都可能导致同一条业务消息被提交两次。如果触达层不做幂等用户可能在两分钟内收到两条一模一样的短信这种体验几乎等于事故。Agent-Reach的做法是在入口处加一层幂等校验业务侧调用时带上请求幂等键这个键由业务消息的唯一语义生成比如订单号加消息类型。Agent-Reach收到请求后先查幂等表如果同一个键已经处理过直接返回之前的触达任务ID不重复创建任务。这个表我们用了Redis存储键过期时间设成7天覆盖所有渠道可能的最大重试窗口。幂等设计还得考虑并发场景。两个完全相同的请求同时到达时如果只是查一下再做插入会有竞态条件。实际实现时用的是先写入再加锁的方式通过Redis的SET NX来做唯一约束保证只有一个请求能创建触达任务。这个细节非常重要很多系统做到一半才发现并发重复问题就得返工。3. 线上接入实录Agent-Reach的落地配置与参数调优3.1 渠道接入的标准配置样例渠道接入是Agent-Reach里最基础但最关键的步骤。每个渠道在配置中心里对应一份配置声明接入方式、限流参数、超时时间、回调地址等。这里给一个精简的渠道配置示例以短信渠道为例channels: sms: provider: ali access_key_id: ${SMS_AK} access_key_secret: ${SMS_SK} sign_name: 某某服务通知 template_code: SMS_123456 rate_limit: 5 concurrency: 2 timeout_ms: 5000 max_retries: 2 retry_delay_ms: 1000 endpoint: https://api.example.com/sms/send这里几个参数要重点说明。rate_limit代表每秒最多向这个渠道提交多少条消息concurrency代表同时有多少个请求在途timeout_ms是渠道响应的最大等待时间。这几个值不是拍脑袋填的要和渠道服务商确认不同的短信套餐对应的吞吐能力不一样填大了会被渠道限流封禁填小了会白白延迟消息触达。接入时建议先做一次小流量联调拿真实渠道的测试号码验证发送、回执两条链路都通再开放给业务侧使用。Agent-Reach里每个渠道都有独立的开关至少留一个维护中的状态避免渠道升级维护时还把流量发过去导致大面积消息积压。3.2 限流和队列参数怎么算限流是整个触达层最容易出问题的地方。渠道侧的限流通常是两个维度每秒请求数和每分钟总量。Agent-Reach在渠道代理层做了令牌桶来控制速率同时在队列层做了容量上限防止渠道阻塞把上游请求全部拖死。队列容量的计算逻辑是这样的假设渠道A的并发上限是2单条消息平均耗时300毫秒那这个渠道每秒最多处理大约6条消息。如果业务侧瞬时提交了100条队列至少要能容纳100条同时要设置拒绝策略比如队列满时直接返回“繁忙请重试”而不是无限堆积。Agent-Reach的默认队列大小公式是并发数 * 100实测下来大部分渠道都能稳住。重试参数的设定也有讲究。短信、邮件这类渠道瞬时失败可以重试但重试间隔要成指数退避避免渠道还没恢复又被同一批消息冲垮。我们实际使用的重试序列是1秒、4秒、16秒最多重试3次。超过这个次数后消息进入“待人工”队列由值班同学确认是渠道故障还是号码问题。3.3 告警与监控送达率波动是触达层的第一信号Agent-Reach上线后我最推荐的监控指标有三个渠道送达率、平均送达延迟、队列积压量。送达率跌到99.5%以下不用等用户投诉先看是不是某个渠道出现了大规模失败平均送达延迟突然翻倍大概率是渠道侧限流需要检查速率配置是否合理队列积压量持续增加说明消费速度跟不上生产速度要么加并发要么降流量。日志方面Agent-Reach给每个触达任务打一份完整的生命周期日志从提交、路由、渠道发送、回执回调一路记下来。查问题时直接按触达任务ID搜日志基本十分钟内能定位是业务侧没调对还是渠道侧出了问题。没有这套日志靠猜和肉眼翻后台效率是完全没法比的。4. 常见问题与排查技巧实录4.1 用户反馈没收到消息该怎么查这是最频繁的问题而且往往不是单点故障而是链路里好几个环节叠加的结果。我建议按以下顺序排查先在Agent-Reach后台按用户ID查最近的触达任务确认任务是否创建然后看任务状态是排队超时、发送失败还是已发送但回执迟迟不来。如果任务状态是已发送但用户说没收到重点看渠道侧。短信场景里可能是杀毒软件拦截也可能是网关通道问题App推送场景里可能是厂商推送服务返回了成功但设备离线。Agent-Reach不会把“渠道返回成功”直接当成最终成功只有收到用户的回执或者设备确认后才标记为完成。这个“半成品状态”的处理逻辑能帮你区分究竟是消息丢了还是反馈链路断了。4.2 渠道回调重复触发怎么办渠道的回调接口天然可能重复推送状态这是Webhook机制的通病。Agent-Reach在回调入口也做了和触达入口相同的幂等逻辑按回调事件ID去重。同一个事件ID无论推几次回调处理器只会处理一次后续重复请求直接返回成功。这个小处理非常关键。如果不做去重渠道回调和业务补偿任务同时更新状态可能把消息状态从“成功”改回“失败”造成连锁的误判。我们早期就踩过这个坑后来统一了所有状态变更操作的顺序按时间戳取最新值彻底解决了状态回跳的问题。4.3 升级渠道API时老消息还在飞怎么办渠道服务商升级API是必然会发生的事Agent-Reach里有一个“渠道灰度”机制。每个渠道配置可以指定API版本然后按百分比灰度流量。升级时先起新版本渠道实例切5%流量观察确认稳定后再逐步放量。这个流程看着笨但在真实环境里特别管用毕竟渠道API的兼容性文档写得再好也不如自己线上验证一遍来得可靠。灰度期间要注意观察送达率、延迟和错误码分布这三项指标。如果新版本的错误码类型和旧版本不一致先停下来对比参数差异多半是新版API对必填字段更严格。之前我们遇到过新版本要求增加签名时间戳没注意到直接调旧参数结果大量请求被拒幸好灰度比例小影响范围可控。5. Agent-Reach后续演进从编排到自适应5.1 用反馈数据自动调整触达策略Agent-Reach现在的路由规则大部分是人工配置的但我们在试下一个阶段的方向让系统根据历史触达反馈数据自动调参。比如系统发现某个用户对邮件响应率极高对短信几乎不读那后续触达策略会慢慢把邮件权重调高。这个调整基于机器学习也能做但我建议先从简单的统计规则开始把数据积累起来再引入模型。自动调整最重要的前提是数据回流做扎实。每一次触达、每一次回执、用户是否点击、点击后是否完成转化都要结构化地落到数据仓库。没有这套数据自动优化就无从谈起。Agent-Reach天生就是数据生产方这些数据反哺给业务后价值非常大不只是触达策略连Agent的对话内容都能跟着优化。5.2 多区域部署下的触达一致性如果你们的Agent服务是跨区域部署的触达层的压力会大不少。用户在上海Agent在北京渠道网关可能在深圳链路绕一圈延迟和失败率都会上升。Agent-Reach的计划是做区域化路由按照接收方归属地把触达任务分发到最近区域的实例处理降低跨区域网络开销。多区域部署还会遇到同一用户在不同区域重复触达的问题这时候全局幂等就不能只存在单机Redis里了要换成跨区域的分布式锁或者数据库唯一索引。这个改造我建议在初期就考虑进去否则后续数据迁移和一致性处理的成本非常高。Agent-Reach目前单区域跑得很稳但如果你一开始就知道要跨区域最好第一天就设计成有全局唯一标识的架构后面会省掉许多麻烦。在做Agent-Reach的过程中我最大的一个体会是智能体能不能真正落地很多时候不取决于模型多聪明而取决于它周围那套工程系统多扎实。触达是Agent和真实世界之间最直接的一层这层做稳了用户才会觉得Agent“靠谱”。如果你也在做类似的事情建议先把幂等、上下文、可观测这三件事设计到位其他功能可以逐步加这三件是地基地基不牢后面全是补窟窿。
阅读完成 · 觉得有帮助？
