最近如果你也在做AI Agent相关的落地项目应该跟我一样经历过一段“自我感觉良好但一上线就翻车”的阶段。我这边踩的最大的一个坑不是模型提示词写得不够好而是多个Agent协作时任务根本没有被正确的Agent接住——消息发出去好几个小时既不报错也没有结果直到用户发来投诉我们才知道订单卡死了。这也是我今天想认真聊聊Agent-Reach这套设计的原因它是我们自研的一套多Agent触达与调度中间件专门解决“任务能不能被正确的Agent接住、协作消息该不该广播、整个链路对用户是否可感知”这三件看似简单、实际非常坑的事。如果你正准备让Agent从单体走向群组协作或者正在做Agent产品化这篇文章应该能帮你少走很多弯路。1. 从单体Agent到群组协作Agent-Reach要解决的“触达”问题是什么1.1 单Agent时代的隐性顺风先说清楚背景。早期我们做Agent就是一个大而全的提示词包用户说什么它全权处理。那种阶段根本不需要“触达”这个概念——所有任务都是顺序执行的一个Agent内部分步骤自问自答不存在“消息要传给谁”的问题。真正的问题出现在我们把Agent拆成专业角色之后。比如客服主理Agent负责理解用户诉求订单核查Agent负责查订单状态退款审批Agent负责走资金流程库存同步Agent负责更新后续数据。拆开之后每个Agent的专业能力和提示词都更聚焦了单个任务的完成质量确实提升了但随之而来的是一个此前完全没考虑过的新问题用户的一句话进来到底该由哪个Agent接着干1.2 “触达失败”的三种典型症状我在第一个多Agent版本里为了不遗漏任务采取了一个最原始的办法每条进入系统的消息群发给所有Agent。结果很惨烈。在退款场景里库存同步Agent拿到退款申请它根本不知道怎么处理资金问题但依然尝试“推理”并返回了一段没有实际意义的中间结果订单核查Agent和退款审批Agent同时认为自己该负责两边各自生成了不同的审批结论最后数据互相覆盖。反过来又有另一种情况某次我们把“退款审批”这个意图的精确匹配规则写得太严格要求用户原话必须包含“退款”两个字。结果用户说“我不想要了帮我退一下钱”这个意图没有被任何规则命中任务直接被丢进了死信队列。没有人处理没有报错唯一的感知是用户第二天发现钱还在原地。我把这类问题统称为“触达失败”。它不一定是网络层面的失败更常见的是语义层面的错过任务根本没被正确的Agent感知到或者被太多Agent感知到但没有一个Agent真正“接住”。1.3 Agent-Reach名字里的三层含义给这套中间件命名为Agent-Reach其实是想清楚了三层含义这三层正好对应了多Agent协作里的三个核心命题。第一层是可达性。系统必须保证任何合法进入的任务在路由图上都能找到一条通路最终到达一个有能力处理它的Agent。就像送快递地址要能解析到具体的收货人不能出现“查无此人”。第二层是覆盖面。协作过程中确实存在需要广播的消息但广播是要付出代价的——每一个Agent被触达就意味着一次LLM调用、一次上下文拼接、一次潜在的误处理。触达策略需要在“全覆盖”和“最小化打扰”之间找到平衡。第三层是触达价值。一个任务从产生到最终完成用户感知到的是一条完整、正确的服务链。如果中间某个环节只是“被触达了但没有产生有效动作”那这次触达就是无效的甚至是负面的。所以Agent-Reach不是某一个算法而是一整套规则机制谁来登记自己可以干什么消息怎么判断意图触达多少个候选Agent触达之后怎么防止重复处理失败之后怎么兜底。它处在Agent能力层之上、业务编排层之下是一层典型的“消息中间件”。1.4 适合谁用、从哪里下手如果你现在的系统还是单个Agent全权处理那Agent-Reach对你的价值不大甚至会觉得这套东西过度设计。但只要你已经出现了两个以上协作Agent或者正在规划把Agent拆分成专业角色就值得把这套机制引进去。我建议的切入顺序是先把Agent的注册信息建起来再做一个简单的意图路由最后再碰触达策略和租约机制。不要一上来就追求复杂的调度算法那只会让你陷入调参地狱。2. Agent-Reach的整体设计注册中心、意图路由与触达策略三件套2.1 服务注册中心先让系统知道“谁会干什么”Agent-Reach的第一块基石是所有Agent在上线时必须做一次登记。这个登记不是写一行配置文件而是带结构化能力的描述。我们内部叫它“Agent Profile”有点像家政平台上的阿姨档案她叫什么、擅长什么、不能接什么活、接单之后多久能完成、如果搞砸了怎么赔付。具体到代码层面每个Agent注册时会带上如下字段{ agent_id: refund-approver, display_name: 退款审批Agent, capabilities: [ { intent: refund_approval, confidence: 0.95, input_schema: { order_id: string, amount: number, reason: string }, output_schema: { decision: approve|reject|manual_review, reason: string } } ], timeout_seconds: 30, weight: 10, tags: [finance, refund, risk] }这套注册机制解决了两个问题。一是身份问题。任务路由时系统能确定“这件事有没有人可能管”而不是闭着眼睛乱发。二是能力边界问题。每个Agent声明了自己的输入输出Schema触达的时候可以把上下文裁剪成它认识的形状避免把一堆无关数据塞进去。实际做的时候有一个教训能力描述里的confidence字段初期我们没当回事全部填0.99。结果意图路由变成了一个纯规则匹配器完全失去了“按置信度候选排序”的意义。后来我们养成了一个习惯每次Agent新版本上线先用历史任务回放一遍跑出真实命中分布再把这个值校准到合理的区间。2.2 意图路由层从自然语言到候选Agent列表有了注册中心之后第二步是从任务消息里抽取出意图然后映射到候选Agent列表。这里最容易犯的错误是意图分类做得太重。有些团队一上来就搞一个“意图分类大模型”把整个系统的前置延迟拉高到几秒钟。Agent-Reach的做法是分层处理。第一层是硬规则匹配。事件类型、用户操作、回调来源这些结构化信息直接用规则解析。比如订单系统回调了一个order.payment.failed事件规则层直接判断为支付流程类意图根本不需要LLM介入。第二层是轻量分类。对于自然语言文本先用一个小的分类模型或者关键词打分器粗筛生成意图候选及分数。这个阶段不追求完美重要的是快、便宜、能覆盖绝大多数情况。第三层才轮到LLM兜底。只有当规则层和轻量分类都给出低置信度时才把完整上下文交给LLM做意图识别。这样做的好处是大约百分之七十的常规任务根本不需要惊动大模型成本和延迟都大幅下降。意图路由的核心输出不是唯一的Agent而是一个按匹配度排序的候选列表# 伪代码示意Agent-Reach 意图路由结果 candidates [ {agent_id: refund-approver, score: 0.97}, {agent_id: cs-human-support, score: 0.82}, {agent_id: inventory-sync, score: 0.12} ]这个列表是后续触达策略的输入。它决定了消息是被“精确投递”给退款审批Agent还是“广播”给前两个高分Agent还是先咨询用户澄清。2.3 触达策略表在精确单发和全量广播之间做决策触达策略是Agent-Reach最核心的部分它本质上是一张“决策表”。我见过不少团队在这里走极端要么全部单发导致低置信度任务无人认领要么全部广播导致消息风暴和重复动作。Agent-Reach给出的思路是用策略表把业务风险量化。触达不是一次性的二选一而是一个可配置的过程。常用的几种触达模式如下精确触达意图置信度高于0.95时只把任务发给排名第一的Agent。TopK触达置信度位于0.60至0.95时将任务发给前2至3个候选Agent让它们竞争应答谁先拿到租约谁处理。澄清式触达置信度低于0.60时不直接分发而是生成一份澄清消息回问用户或触发工单进入人工流程。广播触达只在极少数需要全局状态同步的场景里使用且必须对所有非相关Agent屏蔽执行权只允许订阅观察。场景候选Agent最高分触达模式相关Agent数量潜在风险级别支付失败回调0.98精确触达1低用户退款申请0.87TopK触达2中用户语气模糊的投诉0.45澄清式触达0低全系统配置变更通知0.00广播订阅N需屏蔽执行权这里给你一个建议不要试图用建一堆复杂规则来穷尽所有场景而是先用一张简单的策略表跑起来把每天路由失败的事件全部记下来再围绕真实数据迭代规则。Agent系统的复杂性是长出来的不是设计出来的。2.4 为什么“可配置”比“全自动”更重要在设计Agent-Reach的过程中我最深的一个体会是这种中间件不能追求“全自动智能”。如果每个任务都用同一个模型来决定发给谁系统整个行为就变成了一个黑盒出了问题根本没法排查。策略表的好处是显式、可审计、可局部调整。你今天发现退款意图容易被误判就只调退款相关的阈值不需要动其他任何Agent的路由行为。这也是为什么我把触达策略设计成独立于意图路由之外的一部分。意图路由负责“猜得准”触达策略负责“给得稳”。两者解耦之后无论模型怎么更换触达的稳定性都有一张明确的表格兜底。3. 核心链路拆解一次任务从进来到被正确Agent接住的完整过程3.1 一条任务在Agent-Reach内部的完整路径只讲概念还不够我直接拆一条真实链路的细节。假设用户在前端输入了一句“我不想要这个订单了能退钱吗”这条消息在Agent-Reach内部会经过以下环节第一步网关接入。消息落到统一的入口队列生成一个全局唯一的trace_id。从这个时候开始所有日志、回调、Agent响应都带着这个ID。第二步意图路由。规则层解析用户ID、订单ID等结构化字段发现当前用户确实有活跃订单轻量分类模型给出意图“退款申请”概率0.86由于这是非高置信度项按策略表进入TopK候选流程。第三步候选生成。注册中心查询出3个候选Agent退款审批Agent得分0.86客服人工Agent得分0.72订单核查Agent得分0.50。这批候选并不是直接全部触达。第四步触达决策。策略表读取相关配置“退款申请”的TopK设置为2。于是系统确定触达退款审批Agent和客服人工Agent订单核查Agent不进入本轮触达。第五步租约锁定。这是整个机制里最关键的一步。两个候选Agent同时收到任务但只有拿到租约的那个Agent才有最终扰动系统的权利。第六步投递与执行。退款审批Agent拿到租约后按自己的输入Schema接收裁剪好的上下文开始处理客服人工Agent未拿到租约仅被通知“本次任务由退款审批Agent处理”不产生执行动作。第七步结果回写。退款审批Agent返回审批决策Agent-Reach将其回写到事件总线同时释放租约并把全链路状态标记为“已处理”。这七步之间每一步都有超时、重试、日志、指标少了任何一个环节后面排查问题的时候都会抓瞎。3.2 租约机制为什么必须有它而不是靠Agent自觉多Agent系统里最大的并发噩梦就是两个Agent同时改同一张订单。模型本身没有分布式锁的概念它只会看到“有活就干”。如果没有一个外部机制来决定谁是主人结果就是数据被反复覆盖看起来每个Agent都成功执行了实际上业务状态彻底错乱。Agent-Reach的租约机制实现上类似于分布式锁但比普通锁多了一层“任务生命周期”语义。租约不是永久持有而是绑定一个明确的过期时间。当任务被投递给多个候选Agent时每个Agent都会收到一个尝试获取租约的请求执行权归属于第一个成功获取租约的Agent。# Agent-Reach 租约获取伪代码 def acquire_lease(task_id, agent_id, ttl_seconds30): now current_time() # 原子操作CAS 避免两个 Agent 同时拿到锁 acquired redis.set( flease:{task_id}, agent_id, nxTrue, exttl_seconds ) if not acquired: lease_holder redis.get(flease:{task_id}) return {acquired: False, holder: lease_holder} return {acquired: True, holder: agent_id}这个租约机制里有几个细节需要注意。租约的TTL不能太短否则任务还没处理完租约就过期了另一个Agent会抢进来也不能太长否则Agent异常挂掉之后任务要等很久才能被接管。我们的经验是先按每个Agent声明的最长处理时间乘以1.5倍来做默认值再配合心跳续约机制。续约是指持有租约的Agent在处理过程中会定时调用“renew”接口告诉Agent-Reach“我还活着还在处理”。如果租约过期且没有续约系统就会判定当前处理者已失联自动把任务重新投入路由队列。另一个容易忽略的点是租约必须携带版本号。执行完的Agent返回结果时要带上自己拿到的租约版本结果回写时只有当前版本才被接受。这样能彻底避免“上一个Agent处理完的结果晚到了覆盖了下一个Agent的新结果”这种幽灵覆盖问题。3.3 超时、退避和重试让失败能被看见而不是被吞掉分布式系统的铁律是任何调用都可能超时任何Agent都可能卡死。Agent-Reach一开始犯过最蠢的错误就是无限重试任务失败之后每隔一秒重发一次直到把队列塞满把模型调用费打到天上去。后来我们改成了带指数退避和最大重试次数的标准策略。首轮无应答时在2秒后重试第二次失败后4秒再往后8秒、16秒最多重试4次。第四次仍然失败任务不再自动重试而是进入“挂起状态”触发告警并通知人工值班人员。这里有一个必须强调的设计重试必须是幂等的。投递消息本身可以重复但Agent接收到重复消息时必须能通过trace_id和任务版本判断出它是重试而不是新任务。否则用户一句“退款”被重试三次Agent就会走三遍审批流程产生三个审批单。我建议在Agent端的入口统一包一个“去重层”用分布式存储记录当前正在处理的任务ID集合遇到重复投递直接返回上一次的中间结果或状态而不是重新执行一次完整推理。这个去重层非常便宜但能省掉无数个可怕的线上事故。3.4 兜底矩阵所有候选Agent都失败时任务去哪里设计了这么多路由和重试依然要考虑最坏情况意图识别偏差导致没有候选Agent或者所有候选Agent都超时、拒绝、宕机。这时候任务不能被静默丢弃也不能停在待处理队列里永远等待。Agent-Reach的兜底方案是一个“三级降级矩阵”。第一级系统尝试唤醒备用Agent池比如把任务从“自动审批”降级为“人工客服Agent”。第二级如果没有可用的人工Agent任务转入工单系统并向前端用户发送一次可感知的延迟通知告诉用户“我们已收到申请会有人处理处理时间预计X小时”。第三级对于资金类、安全类的高风险操作不自动降级而是直接冻结任务并告警等待工程团队介入。这三级降级的核心原则只有一个任何任务都必须有一个明确定义的最终状态。要么完成要么明确失败回滚要么显式进入人工流程。永远不要有一个任务处于“不知道谁在处理”的灰色状态。这个原则做多Agent编排的人越早理解踩的坑越少。4. 实测效果与踩坑记录触达率、消息风暴和上下文溢出的修复4.1 第一版全广播模式触达率100%但代价是不可承受的Agent-Reach第一版上线时触达策略非常粗放为了防止漏接任务所有事件全部广播给所有Agent。第一周监控面板上的“触达率”确实很漂亮100%——每个任务都至少被一个Agent收到了。但打开成本面板和日志之后问题根本藏不住。一次普通的退款申请全广播模式下会触发8次无效的LLM调用。原因是库存Agent、物流Agent、售后Agent都收到了退款事件它们被迫“了解”自己根本不需要处理的信息。更可怕的是这些无效触达并不是免费的——每个Agent都会把上下文拼接起来然后调用一次模型判断“这事跟我有关吗”单次判断成本不高但乘以每天几千个任务、乘以每个任务的额外候选费用就是指数级增长。我用一组实测数据来说明问题全广播模式下每1000个真实任务会产生约4200次Agent调用其中真实有效执行约830次净无效调用率接近81%。模型账单飙升日志量爆炸排查问题时看到的是几百条与任务无关的Agent日志交织在一起的乱麻。4.2 引入意图置信度后的新问题无效调用降了无人认领来了第二版我们引入了完整的意图路由按照策略表把大多数任务从广播改为TopK或精确触达。结果无效调用率大幅下降从81%降到了14%左右成本肉眼可见地下来了。但新的问题立刻浮出水面无人认领的任务变多了。原因很典型轻量分类模型的置信度分布和策略表阈值没对齐。我们设置的“精确触达阈值”是0.95但实际运行中大量用户表达方式的置信度在0.7到0.9之间。按照TopK触达策略这些任务应该发给前两个候选Agent。可候选列表里的客服人工Agent在当时的版本里积分很低经常排在第二位但几乎没有实际处理能力退款审批Agent虽然拿到了任务但由于任务上下文里有模糊表达它反复要求用户澄清导致环节卡住。这次踩坑给我的教训是触达率不是越高越高也不是越低越好而是要匹配业务风险的“有效触达率”。如果一个Agent被触达后只是回了一个“理解不了”还不如一开始就不打扰它。我们后来做的调整是把“产出无效响应的触达”单独记账作为一项核心负面指标。这个指标一拉起来哪些Agent在浪费大家的时间一目了然。4.3 Agent上下文溢出触达不是把全部历史都塞过去让Agent判断是否自己处理的时候必须给它上下文但给多少上下文是个非常关键的控制点。我们碰到过一个真实案例某个Agent被触达之后会把自己历史对话记录里的所有内容全部打包再加上当前任务的完整原始消息一起塞进模型上下文。结果一个本可以用800个token处理完的退款任务实际消耗了1.2万个token。成本翻倍是小事更严重的是上下文太长之后模型注意力分散反而漏掉了最关键的退款金额和订单号信息。Agent-Reach针对这个问题增加了一个“触达载荷截断器”。它的逻辑是在投递消息给Agent之前先把它需要的上下文裁剪成一个结构化摘要包。摘要包里只包含四类信息当前任务的task_id与trace_id与意图直接相关的关键业务字段最近两个时间窗口内的事件摘要以及最多三轮与用户相关的对话历史。超过这个范围的内容全部截断不进入Agent上下文。# 触达载荷构造示意 def build_payload(task, agent_capability): return { task_id: task.id, trace_id: task.trace_id, intent: task.intent, fields: extract_by_schema(task.payload, agent_capability.input_schema), event_summary: recent_events(task.subject, window_minutes30), recent_dialogue: task.dialogue_history[-3:], }这个截断器上线之后平均单任务模型输入token下降了六成多同时任务完成率反而提升了近8%。因为Agent收到的信息里没有大量无关噪音它更容易命中核心诉求。4.4 资金敏感场景的强制二次确认不能只依赖概率最后一类避坑经验来自资金敏感场景。退款审批这类任务如果意图识别的置信度只有0.85你敢直接让退款Agent执行吗从概率上看它大概率是对的但从业务风险上看一旦剩下那15%错了就是实打实的资金损失。我们的处理方式是建立“强制二次确认规则”任何涉及资金操作金额超出阈值的任务无论意图置信度多高都必须同时触达自动退款Agent和人工风控Agent。自动Agent负责正常流程人工风控Agent作为复核通道存在。只有自动Agent和人工复核都同意退款才会真正执行。这种场景下触达策略不再追求“少打扰”而是要刻意地“冗余触达”。这也进一步证明了我前面说的没有放之四海皆准的触达策略只有基于业务风险设计的触达策略。这个案例值得所有做Agent编排的人记住当触达决策涉及真金白银时请怀疑每一个置信度。5. 从“能用”到“好用”可观测性设计、成本控制与后续扩展方向5.1 三大监控指标触达率、无效触达率、总往返时延多Agent系统上线之后我每天看的监控面板只有三张图。第一张是触达率代表任务被有效Agent接收并响应的比例。第二张是无效触达率代表所有触达中最终没有产生有效动作的比例——这个数字偏高说明路由或策略有问题。第三张是总往返时延从任务进入系统到最终结果回写的完整时间。指标目标区间过高/过低意味着什么有效触达率高于95%低于此值任务可能大量落入无人认领或人工流程无效触达率低于15%高于此值路由过宽或Agent能力边界声明不清P95往返时延任务类型而异过高候选Agent过多、上下文载荷过大或下游API过慢这三张图之外我还会看一个辅助指标叫“触达轮数分布”。正常情况下任务应该在1至2轮触达内被接住如果大量任务需要4轮以上才能找到正确Agent说明意图路由的候选排序能力太弱或者Agent注册信息没有及时更新。我还建立了一个“路由回放”工具每天把意图路由的输入、候选分数、触达决策、Agent响应的完整日志导出来做一次离线回放。这相当于给Agent系统做定期体检很多问题在变大之前就是从这个回放报告里发现的。5.2 全链路追踪不丢、不重是排查问题的底线说到排查问题就不能不强调trace_id贯穿到底的重要性。Agent-Reach从网关接入开始就把trace_id写入消息头、日志、Redis租约键、Agent响应回调里。这样任何一次任务的完整旅程都能被串起来。我举一个实际排查案例某次大量订单出现“已退款但用户未收到消息”的投诉。只看单个Agent的日志每个Agent都显示自己完成了任务。但因为全链路日志里有trace_id我们把一次典型任务的所有日志捞出来立刻发现退款审批Agent成功执行后结果回写时因为租约版本过期而被拒绝任务状态被错误标记为“已回写”。就是说动作执行了但结果没有真正进入业务线。如果没有全链路追踪光是靠打听“订单状态哪里变了”来定位至少要折腾大半天。所以强烈建议在设计Agent编排系统的那一天就把日志结构化、trace_id贯穿、关键状态变更埋点这三件事做扎实。它们才是真正保证你在深夜能安心睡觉的东西。5.3 成本控制让每一次触达都有账单视角AI Agent系统的成本不光来自大模型调用还来自每个Agent之间传递的上下文流量、中间件存储、失败重试占用的并发资源。如果你不给触达定价成本就会像漏水一样慢慢侵蚀利润。我习惯在Agent-Reach里建立一套“虚拟成本计价”指标。每个Agent注册时默认有一个成本系数模型调用量大的Agent成本系数高只用规则解析的Agent成本系数低。每次触达动作都会累计“估算成本”。然后在成本面板里按业务线汇总按任务类型拆解找出“哪个业务线在亏钱”。这个动作不是为了记账而是为了做路由决策的输入。当一个任务的候选Agent里有两个分数很接近的选项一个便宜但置信度稍低一个昂贵但置信度更高系统会结合业务风险偏好来决策。低风险任务可以选便宜Agent高风险任务可以牺牲一点成本换更高准确度。这就是“触达性价比”的调度。5.4 后续扩展事件驱动触达、多模态感知与流式结果回传Agent-Reach目前还是以“请求响应”模式为主的中间件。我下一步想做的扩展有两个方向。第一个是事件驱动触达。现在很多任务并不是用户实时发起的而是业务系统里发生了某个状态变化需要相关Agent自动感知。比如用户上传了新凭证这个事件应该触达风控Agent和客服Agent比如库存跌破阈值应该触达补货Agent和营销Agent。事件驱动模式下的触达更像是一套“Agent总线”每个Agent按自己的兴趣订阅事件流Agent-Reach负责保证事件被最少但足够的Agent处理。第二个是流式结果回传。现在多数Agent是处理完一次性返回结果的用户体验上就是“等一会儿”。如果Agent在推理过程中能逐步回传中间状态比如“已识别退款意图”“正在核对订单金额”“等待风控确认”再配合用户端的流式展示体验会好太多。这需要Agent-Reach支持触达后的持续状态通道而不只是简单的结果回写。多模态感知也在计划里。用户如果在对话中发来一张订单截图纯文本意图路由几乎没法处理。我们打算增加一个视觉理解Agent作为候选补充。用户发图之后Agent-Reach先触发视觉Agent解析图片抽取关键信息再带着结构化信息去路由后续任务。这个方向会显著增加系统复杂度但对用户体验的提升是很直接的。做Agent-Reach到现在我最大的体会是多Agent系统真正的复杂度从来不在模型能力而在消息是否正确到达、到达之后是否有人确认负责、负责人是否能把结果可靠地交回来。把这三个环节用透明的机制管好Agent系统才算真正有了可维护的基础。如果你也在做类似的体系刚开始别追求惊艳的算法效果先把触达链路做成一张看得清、查得到、改得动的表后面所有优化都建立在这张表之上。
最近如果你也在做AI Agent相关的落地项目应该跟我一样经历过一段“自我感觉良好但一上线就翻车”的阶段。我这边踩的最大的一个坑不是模型提示词写得不够好而是多个Agent协作时任务根本没有被正确的Agent接住——消息发出去好几个小时既不报错也没有结果直到用户发来投诉我们才知道订单卡死了。这也是我今天想认真聊聊Agent-Reach这套设计的原因它是我们自研的一套多Agent触达与调度中间件专门解决“任务能不能被正确的Agent接住、协作消息该不该广播、整个链路对用户是否可感知”这三件看似简单、实际非常坑的事。如果你正准备让Agent从单体走向群组协作或者正在做Agent产品化这篇文章应该能帮你少走很多弯路。1. 从单体Agent到群组协作Agent-Reach要解决的“触达”问题是什么1.1 单Agent时代的隐性顺风先说清楚背景。早期我们做Agent就是一个大而全的提示词包用户说什么它全权处理。那种阶段根本不需要“触达”这个概念——所有任务都是顺序执行的一个Agent内部分步骤自问自答不存在“消息要传给谁”的问题。真正的问题出现在我们把Agent拆成专业角色之后。比如客服主理Agent负责理解用户诉求订单核查Agent负责查订单状态退款审批Agent负责走资金流程库存同步Agent负责更新后续数据。拆开之后每个Agent的专业能力和提示词都更聚焦了单个任务的完成质量确实提升了但随之而来的是一个此前完全没考虑过的新问题用户的一句话进来到底该由哪个Agent接着干1.2 “触达失败”的三种典型症状我在第一个多Agent版本里为了不遗漏任务采取了一个最原始的办法每条进入系统的消息群发给所有Agent。结果很惨烈。在退款场景里库存同步Agent拿到退款申请它根本不知道怎么处理资金问题但依然尝试“推理”并返回了一段没有实际意义的中间结果订单核查Agent和退款审批Agent同时认为自己该负责两边各自生成了不同的审批结论最后数据互相覆盖。反过来又有另一种情况某次我们把“退款审批”这个意图的精确匹配规则写得太严格要求用户原话必须包含“退款”两个字。结果用户说“我不想要了帮我退一下钱”这个意图没有被任何规则命中任务直接被丢进了死信队列。没有人处理没有报错唯一的感知是用户第二天发现钱还在原地。我把这类问题统称为“触达失败”。它不一定是网络层面的失败更常见的是语义层面的错过任务根本没被正确的Agent感知到或者被太多Agent感知到但没有一个Agent真正“接住”。1.3 Agent-Reach名字里的三层含义给这套中间件命名为Agent-Reach其实是想清楚了三层含义这三层正好对应了多Agent协作里的三个核心命题。第一层是可达性。系统必须保证任何合法进入的任务在路由图上都能找到一条通路最终到达一个有能力处理它的Agent。就像送快递地址要能解析到具体的收货人不能出现“查无此人”。第二层是覆盖面。协作过程中确实存在需要广播的消息但广播是要付出代价的——每一个Agent被触达就意味着一次LLM调用、一次上下文拼接、一次潜在的误处理。触达策略需要在“全覆盖”和“最小化打扰”之间找到平衡。第三层是触达价值。一个任务从产生到最终完成用户感知到的是一条完整、正确的服务链。如果中间某个环节只是“被触达了但没有产生有效动作”那这次触达就是无效的甚至是负面的。所以Agent-Reach不是某一个算法而是一整套规则机制谁来登记自己可以干什么消息怎么判断意图触达多少个候选Agent触达之后怎么防止重复处理失败之后怎么兜底。它处在Agent能力层之上、业务编排层之下是一层典型的“消息中间件”。1.4 适合谁用、从哪里下手如果你现在的系统还是单个Agent全权处理那Agent-Reach对你的价值不大甚至会觉得这套东西过度设计。但只要你已经出现了两个以上协作Agent或者正在规划把Agent拆分成专业角色就值得把这套机制引进去。我建议的切入顺序是先把Agent的注册信息建起来再做一个简单的意图路由最后再碰触达策略和租约机制。不要一上来就追求复杂的调度算法那只会让你陷入调参地狱。2. Agent-Reach的整体设计注册中心、意图路由与触达策略三件套2.1 服务注册中心先让系统知道“谁会干什么”Agent-Reach的第一块基石是所有Agent在上线时必须做一次登记。这个登记不是写一行配置文件而是带结构化能力的描述。我们内部叫它“Agent Profile”有点像家政平台上的阿姨档案她叫什么、擅长什么、不能接什么活、接单之后多久能完成、如果搞砸了怎么赔付。具体到代码层面每个Agent注册时会带上如下字段{ agent_id: refund-approver, display_name: 退款审批Agent, capabilities: [ { intent: refund_approval, confidence: 0.95, input_schema: { order_id: string, amount: number, reason: string }, output_schema: { decision: approve|reject|manual_review, reason: string } } ], timeout_seconds: 30, weight: 10, tags: [finance, refund, risk] }这套注册机制解决了两个问题。一是身份问题。任务路由时系统能确定“这件事有没有人可能管”而不是闭着眼睛乱发。二是能力边界问题。每个Agent声明了自己的输入输出Schema触达的时候可以把上下文裁剪成它认识的形状避免把一堆无关数据塞进去。实际做的时候有一个教训能力描述里的confidence字段初期我们没当回事全部填0.99。结果意图路由变成了一个纯规则匹配器完全失去了“按置信度候选排序”的意义。后来我们养成了一个习惯每次Agent新版本上线先用历史任务回放一遍跑出真实命中分布再把这个值校准到合理的区间。2.2 意图路由层从自然语言到候选Agent列表有了注册中心之后第二步是从任务消息里抽取出意图然后映射到候选Agent列表。这里最容易犯的错误是意图分类做得太重。有些团队一上来就搞一个“意图分类大模型”把整个系统的前置延迟拉高到几秒钟。Agent-Reach的做法是分层处理。第一层是硬规则匹配。事件类型、用户操作、回调来源这些结构化信息直接用规则解析。比如订单系统回调了一个order.payment.failed事件规则层直接判断为支付流程类意图根本不需要LLM介入。第二层是轻量分类。对于自然语言文本先用一个小的分类模型或者关键词打分器粗筛生成意图候选及分数。这个阶段不追求完美重要的是快、便宜、能覆盖绝大多数情况。第三层才轮到LLM兜底。只有当规则层和轻量分类都给出低置信度时才把完整上下文交给LLM做意图识别。这样做的好处是大约百分之七十的常规任务根本不需要惊动大模型成本和延迟都大幅下降。意图路由的核心输出不是唯一的Agent而是一个按匹配度排序的候选列表# 伪代码示意Agent-Reach 意图路由结果 candidates [ {agent_id: refund-approver, score: 0.97}, {agent_id: cs-human-support, score: 0.82}, {agent_id: inventory-sync, score: 0.12} ]这个列表是后续触达策略的输入。它决定了消息是被“精确投递”给退款审批Agent还是“广播”给前两个高分Agent还是先咨询用户澄清。2.3 触达策略表在精确单发和全量广播之间做决策触达策略是Agent-Reach最核心的部分它本质上是一张“决策表”。我见过不少团队在这里走极端要么全部单发导致低置信度任务无人认领要么全部广播导致消息风暴和重复动作。Agent-Reach给出的思路是用策略表把业务风险量化。触达不是一次性的二选一而是一个可配置的过程。常用的几种触达模式如下精确触达意图置信度高于0.95时只把任务发给排名第一的Agent。TopK触达置信度位于0.60至0.95时将任务发给前2至3个候选Agent让它们竞争应答谁先拿到租约谁处理。澄清式触达置信度低于0.60时不直接分发而是生成一份澄清消息回问用户或触发工单进入人工流程。广播触达只在极少数需要全局状态同步的场景里使用且必须对所有非相关Agent屏蔽执行权只允许订阅观察。场景候选Agent最高分触达模式相关Agent数量潜在风险级别支付失败回调0.98精确触达1低用户退款申请0.87TopK触达2中用户语气模糊的投诉0.45澄清式触达0低全系统配置变更通知0.00广播订阅N需屏蔽执行权这里给你一个建议不要试图用建一堆复杂规则来穷尽所有场景而是先用一张简单的策略表跑起来把每天路由失败的事件全部记下来再围绕真实数据迭代规则。Agent系统的复杂性是长出来的不是设计出来的。2.4 为什么“可配置”比“全自动”更重要在设计Agent-Reach的过程中我最深的一个体会是这种中间件不能追求“全自动智能”。如果每个任务都用同一个模型来决定发给谁系统整个行为就变成了一个黑盒出了问题根本没法排查。策略表的好处是显式、可审计、可局部调整。你今天发现退款意图容易被误判就只调退款相关的阈值不需要动其他任何Agent的路由行为。这也是为什么我把触达策略设计成独立于意图路由之外的一部分。意图路由负责“猜得准”触达策略负责“给得稳”。两者解耦之后无论模型怎么更换触达的稳定性都有一张明确的表格兜底。3. 核心链路拆解一次任务从进来到被正确Agent接住的完整过程3.1 一条任务在Agent-Reach内部的完整路径只讲概念还不够我直接拆一条真实链路的细节。假设用户在前端输入了一句“我不想要这个订单了能退钱吗”这条消息在Agent-Reach内部会经过以下环节第一步网关接入。消息落到统一的入口队列生成一个全局唯一的trace_id。从这个时候开始所有日志、回调、Agent响应都带着这个ID。第二步意图路由。规则层解析用户ID、订单ID等结构化字段发现当前用户确实有活跃订单轻量分类模型给出意图“退款申请”概率0.86由于这是非高置信度项按策略表进入TopK候选流程。第三步候选生成。注册中心查询出3个候选Agent退款审批Agent得分0.86客服人工Agent得分0.72订单核查Agent得分0.50。这批候选并不是直接全部触达。第四步触达决策。策略表读取相关配置“退款申请”的TopK设置为2。于是系统确定触达退款审批Agent和客服人工Agent订单核查Agent不进入本轮触达。第五步租约锁定。这是整个机制里最关键的一步。两个候选Agent同时收到任务但只有拿到租约的那个Agent才有最终扰动系统的权利。第六步投递与执行。退款审批Agent拿到租约后按自己的输入Schema接收裁剪好的上下文开始处理客服人工Agent未拿到租约仅被通知“本次任务由退款审批Agent处理”不产生执行动作。第七步结果回写。退款审批Agent返回审批决策Agent-Reach将其回写到事件总线同时释放租约并把全链路状态标记为“已处理”。这七步之间每一步都有超时、重试、日志、指标少了任何一个环节后面排查问题的时候都会抓瞎。3.2 租约机制为什么必须有它而不是靠Agent自觉多Agent系统里最大的并发噩梦就是两个Agent同时改同一张订单。模型本身没有分布式锁的概念它只会看到“有活就干”。如果没有一个外部机制来决定谁是主人结果就是数据被反复覆盖看起来每个Agent都成功执行了实际上业务状态彻底错乱。Agent-Reach的租约机制实现上类似于分布式锁但比普通锁多了一层“任务生命周期”语义。租约不是永久持有而是绑定一个明确的过期时间。当任务被投递给多个候选Agent时每个Agent都会收到一个尝试获取租约的请求执行权归属于第一个成功获取租约的Agent。# Agent-Reach 租约获取伪代码 def acquire_lease(task_id, agent_id, ttl_seconds30): now current_time() # 原子操作CAS 避免两个 Agent 同时拿到锁 acquired redis.set( flease:{task_id}, agent_id, nxTrue, exttl_seconds ) if not acquired: lease_holder redis.get(flease:{task_id}) return {acquired: False, holder: lease_holder} return {acquired: True, holder: agent_id}这个租约机制里有几个细节需要注意。租约的TTL不能太短否则任务还没处理完租约就过期了另一个Agent会抢进来也不能太长否则Agent异常挂掉之后任务要等很久才能被接管。我们的经验是先按每个Agent声明的最长处理时间乘以1.5倍来做默认值再配合心跳续约机制。续约是指持有租约的Agent在处理过程中会定时调用“renew”接口告诉Agent-Reach“我还活着还在处理”。如果租约过期且没有续约系统就会判定当前处理者已失联自动把任务重新投入路由队列。另一个容易忽略的点是租约必须携带版本号。执行完的Agent返回结果时要带上自己拿到的租约版本结果回写时只有当前版本才被接受。这样能彻底避免“上一个Agent处理完的结果晚到了覆盖了下一个Agent的新结果”这种幽灵覆盖问题。3.3 超时、退避和重试让失败能被看见而不是被吞掉分布式系统的铁律是任何调用都可能超时任何Agent都可能卡死。Agent-Reach一开始犯过最蠢的错误就是无限重试任务失败之后每隔一秒重发一次直到把队列塞满把模型调用费打到天上去。后来我们改成了带指数退避和最大重试次数的标准策略。首轮无应答时在2秒后重试第二次失败后4秒再往后8秒、16秒最多重试4次。第四次仍然失败任务不再自动重试而是进入“挂起状态”触发告警并通知人工值班人员。这里有一个必须强调的设计重试必须是幂等的。投递消息本身可以重复但Agent接收到重复消息时必须能通过trace_id和任务版本判断出它是重试而不是新任务。否则用户一句“退款”被重试三次Agent就会走三遍审批流程产生三个审批单。我建议在Agent端的入口统一包一个“去重层”用分布式存储记录当前正在处理的任务ID集合遇到重复投递直接返回上一次的中间结果或状态而不是重新执行一次完整推理。这个去重层非常便宜但能省掉无数个可怕的线上事故。3.4 兜底矩阵所有候选Agent都失败时任务去哪里设计了这么多路由和重试依然要考虑最坏情况意图识别偏差导致没有候选Agent或者所有候选Agent都超时、拒绝、宕机。这时候任务不能被静默丢弃也不能停在待处理队列里永远等待。Agent-Reach的兜底方案是一个“三级降级矩阵”。第一级系统尝试唤醒备用Agent池比如把任务从“自动审批”降级为“人工客服Agent”。第二级如果没有可用的人工Agent任务转入工单系统并向前端用户发送一次可感知的延迟通知告诉用户“我们已收到申请会有人处理处理时间预计X小时”。第三级对于资金类、安全类的高风险操作不自动降级而是直接冻结任务并告警等待工程团队介入。这三级降级的核心原则只有一个任何任务都必须有一个明确定义的最终状态。要么完成要么明确失败回滚要么显式进入人工流程。永远不要有一个任务处于“不知道谁在处理”的灰色状态。这个原则做多Agent编排的人越早理解踩的坑越少。4. 实测效果与踩坑记录触达率、消息风暴和上下文溢出的修复4.1 第一版全广播模式触达率100%但代价是不可承受的Agent-Reach第一版上线时触达策略非常粗放为了防止漏接任务所有事件全部广播给所有Agent。第一周监控面板上的“触达率”确实很漂亮100%——每个任务都至少被一个Agent收到了。但打开成本面板和日志之后问题根本藏不住。一次普通的退款申请全广播模式下会触发8次无效的LLM调用。原因是库存Agent、物流Agent、售后Agent都收到了退款事件它们被迫“了解”自己根本不需要处理的信息。更可怕的是这些无效触达并不是免费的——每个Agent都会把上下文拼接起来然后调用一次模型判断“这事跟我有关吗”单次判断成本不高但乘以每天几千个任务、乘以每个任务的额外候选费用就是指数级增长。我用一组实测数据来说明问题全广播模式下每1000个真实任务会产生约4200次Agent调用其中真实有效执行约830次净无效调用率接近81%。模型账单飙升日志量爆炸排查问题时看到的是几百条与任务无关的Agent日志交织在一起的乱麻。4.2 引入意图置信度后的新问题无效调用降了无人认领来了第二版我们引入了完整的意图路由按照策略表把大多数任务从广播改为TopK或精确触达。结果无效调用率大幅下降从81%降到了14%左右成本肉眼可见地下来了。但新的问题立刻浮出水面无人认领的任务变多了。原因很典型轻量分类模型的置信度分布和策略表阈值没对齐。我们设置的“精确触达阈值”是0.95但实际运行中大量用户表达方式的置信度在0.7到0.9之间。按照TopK触达策略这些任务应该发给前两个候选Agent。可候选列表里的客服人工Agent在当时的版本里积分很低经常排在第二位但几乎没有实际处理能力退款审批Agent虽然拿到了任务但由于任务上下文里有模糊表达它反复要求用户澄清导致环节卡住。这次踩坑给我的教训是触达率不是越高越高也不是越低越好而是要匹配业务风险的“有效触达率”。如果一个Agent被触达后只是回了一个“理解不了”还不如一开始就不打扰它。我们后来做的调整是把“产出无效响应的触达”单独记账作为一项核心负面指标。这个指标一拉起来哪些Agent在浪费大家的时间一目了然。4.3 Agent上下文溢出触达不是把全部历史都塞过去让Agent判断是否自己处理的时候必须给它上下文但给多少上下文是个非常关键的控制点。我们碰到过一个真实案例某个Agent被触达之后会把自己历史对话记录里的所有内容全部打包再加上当前任务的完整原始消息一起塞进模型上下文。结果一个本可以用800个token处理完的退款任务实际消耗了1.2万个token。成本翻倍是小事更严重的是上下文太长之后模型注意力分散反而漏掉了最关键的退款金额和订单号信息。Agent-Reach针对这个问题增加了一个“触达载荷截断器”。它的逻辑是在投递消息给Agent之前先把它需要的上下文裁剪成一个结构化摘要包。摘要包里只包含四类信息当前任务的task_id与trace_id与意图直接相关的关键业务字段最近两个时间窗口内的事件摘要以及最多三轮与用户相关的对话历史。超过这个范围的内容全部截断不进入Agent上下文。# 触达载荷构造示意 def build_payload(task, agent_capability): return { task_id: task.id, trace_id: task.trace_id, intent: task.intent, fields: extract_by_schema(task.payload, agent_capability.input_schema), event_summary: recent_events(task.subject, window_minutes30), recent_dialogue: task.dialogue_history[-3:], }这个截断器上线之后平均单任务模型输入token下降了六成多同时任务完成率反而提升了近8%。因为Agent收到的信息里没有大量无关噪音它更容易命中核心诉求。4.4 资金敏感场景的强制二次确认不能只依赖概率最后一类避坑经验来自资金敏感场景。退款审批这类任务如果意图识别的置信度只有0.85你敢直接让退款Agent执行吗从概率上看它大概率是对的但从业务风险上看一旦剩下那15%错了就是实打实的资金损失。我们的处理方式是建立“强制二次确认规则”任何涉及资金操作金额超出阈值的任务无论意图置信度多高都必须同时触达自动退款Agent和人工风控Agent。自动Agent负责正常流程人工风控Agent作为复核通道存在。只有自动Agent和人工复核都同意退款才会真正执行。这种场景下触达策略不再追求“少打扰”而是要刻意地“冗余触达”。这也进一步证明了我前面说的没有放之四海皆准的触达策略只有基于业务风险设计的触达策略。这个案例值得所有做Agent编排的人记住当触达决策涉及真金白银时请怀疑每一个置信度。5. 从“能用”到“好用”可观测性设计、成本控制与后续扩展方向5.1 三大监控指标触达率、无效触达率、总往返时延多Agent系统上线之后我每天看的监控面板只有三张图。第一张是触达率代表任务被有效Agent接收并响应的比例。第二张是无效触达率代表所有触达中最终没有产生有效动作的比例——这个数字偏高说明路由或策略有问题。第三张是总往返时延从任务进入系统到最终结果回写的完整时间。指标目标区间过高/过低意味着什么有效触达率高于95%低于此值任务可能大量落入无人认领或人工流程无效触达率低于15%高于此值路由过宽或Agent能力边界声明不清P95往返时延任务类型而异过高候选Agent过多、上下文载荷过大或下游API过慢这三张图之外我还会看一个辅助指标叫“触达轮数分布”。正常情况下任务应该在1至2轮触达内被接住如果大量任务需要4轮以上才能找到正确Agent说明意图路由的候选排序能力太弱或者Agent注册信息没有及时更新。我还建立了一个“路由回放”工具每天把意图路由的输入、候选分数、触达决策、Agent响应的完整日志导出来做一次离线回放。这相当于给Agent系统做定期体检很多问题在变大之前就是从这个回放报告里发现的。5.2 全链路追踪不丢、不重是排查问题的底线说到排查问题就不能不强调trace_id贯穿到底的重要性。Agent-Reach从网关接入开始就把trace_id写入消息头、日志、Redis租约键、Agent响应回调里。这样任何一次任务的完整旅程都能被串起来。我举一个实际排查案例某次大量订单出现“已退款但用户未收到消息”的投诉。只看单个Agent的日志每个Agent都显示自己完成了任务。但因为全链路日志里有trace_id我们把一次典型任务的所有日志捞出来立刻发现退款审批Agent成功执行后结果回写时因为租约版本过期而被拒绝任务状态被错误标记为“已回写”。就是说动作执行了但结果没有真正进入业务线。如果没有全链路追踪光是靠打听“订单状态哪里变了”来定位至少要折腾大半天。所以强烈建议在设计Agent编排系统的那一天就把日志结构化、trace_id贯穿、关键状态变更埋点这三件事做扎实。它们才是真正保证你在深夜能安心睡觉的东西。5.3 成本控制让每一次触达都有账单视角AI Agent系统的成本不光来自大模型调用还来自每个Agent之间传递的上下文流量、中间件存储、失败重试占用的并发资源。如果你不给触达定价成本就会像漏水一样慢慢侵蚀利润。我习惯在Agent-Reach里建立一套“虚拟成本计价”指标。每个Agent注册时默认有一个成本系数模型调用量大的Agent成本系数高只用规则解析的Agent成本系数低。每次触达动作都会累计“估算成本”。然后在成本面板里按业务线汇总按任务类型拆解找出“哪个业务线在亏钱”。这个动作不是为了记账而是为了做路由决策的输入。当一个任务的候选Agent里有两个分数很接近的选项一个便宜但置信度稍低一个昂贵但置信度更高系统会结合业务风险偏好来决策。低风险任务可以选便宜Agent高风险任务可以牺牲一点成本换更高准确度。这就是“触达性价比”的调度。5.4 后续扩展事件驱动触达、多模态感知与流式结果回传Agent-Reach目前还是以“请求响应”模式为主的中间件。我下一步想做的扩展有两个方向。第一个是事件驱动触达。现在很多任务并不是用户实时发起的而是业务系统里发生了某个状态变化需要相关Agent自动感知。比如用户上传了新凭证这个事件应该触达风控Agent和客服Agent比如库存跌破阈值应该触达补货Agent和营销Agent。事件驱动模式下的触达更像是一套“Agent总线”每个Agent按自己的兴趣订阅事件流Agent-Reach负责保证事件被最少但足够的Agent处理。第二个是流式结果回传。现在多数Agent是处理完一次性返回结果的用户体验上就是“等一会儿”。如果Agent在推理过程中能逐步回传中间状态比如“已识别退款意图”“正在核对订单金额”“等待风控确认”再配合用户端的流式展示体验会好太多。这需要Agent-Reach支持触达后的持续状态通道而不只是简单的结果回写。多模态感知也在计划里。用户如果在对话中发来一张订单截图纯文本意图路由几乎没法处理。我们打算增加一个视觉理解Agent作为候选补充。用户发图之后Agent-Reach先触发视觉Agent解析图片抽取关键信息再带着结构化信息去路由后续任务。这个方向会显著增加系统复杂度但对用户体验的提升是很直接的。做Agent-Reach到现在我最大的体会是多Agent系统真正的复杂度从来不在模型能力而在消息是否正确到达、到达之后是否有人确认负责、负责人是否能把结果可靠地交回来。把这三个环节用透明的机制管好Agent系统才算真正有了可维护的基础。如果你也在做类似的体系刚开始别追求惊艳的算法效果先把触达链路做成一张看得清、查得到、改得动的表后面所有优化都建立在这张表之上。
