先说结论Agent-Reach 不是什么大模型应用也不是一个多智能体编排框架它是被“Agent 之间互相找不到、消息发出去没人回、偶尔还有两边同时执行同一个任务”这类问题逼到墙角之后我自己写的一层轻量级触达路由。Reach 这个词取自分布式系统里的“可达性”——在一个多 Agent 系统里一个 Agent 能不能被另一个 Agent 可靠地触达直接决定了这套系统到底是玩具还是能跑生产的工具。如果你也在搭多 Agent 协作系统或者正在被各种框架的“工具调用”“任务编排”概念绕得头晕那这篇文章大概对你有用。我会把 Agent-Reach 从设计思路到落地代码、再到我在联调阶段踩过的坑按真实推进顺序完整写一遍。适合的人群是已经跑通单 Agent开始折腾多 Agent 协作但对“Agent 之间怎么通信”这件事还没有成熟方案的人。1. 先弄明白“触达”到底是哪一环的问题1.1 从一次线上事故说起最早我手上有一套系统里面有七个 Agent 各管一摊一个抓数据一个做文本清洗一个跑摘要一个做情感判断还有一个专门质检。单看每个 Agent 都挺正常但把它们串起来之后问题就来了。最典型的一次事故是这样的Agent A 需要把一批文本交给 Agent B 做清洗结果消息发出去之后 B 没收到A 以为 B 崩了重试了三次。与此同时调度系统又把这个任务分给了 Agent C 执行C 和 B 的清洗逻辑不完全一样产出的数据格式差了一个字段。下游消费方拿到数据后直接报错整条链路卡了一个多小时。事后排查根子不在调度也不在某个 Agent 的代码而在“触达”这一层任务发出去之后系统根本不确认对方是否真的收到了、是否有能力处理、是否已经处理过类似任务。总线把消息塞进队列就认为完成了Agent 之间也没有统一的能力描述接收方只能靠消息里的任务名猜自己该不该接。当时我就意识到多 Agent 系统的问题不是“能不能调通”而是“该找谁调、怎么调、怎么确认调成功了”。于是有了 Agent-Reach。1.2 调度、路由与触达三个容易被混为一谈的环节很多人在讨论多 Agent 系统时会用一套模糊的说法把调度、路由和触达都叫做“编排”。实际拆开看这是三个完全不同的环节调度决定任务在什么时候执行、以什么顺序执行、是否需要并行或串行。典型的调度器是 Airflow、Prefect 这类工作流引擎它们的核心是 DAG 和时间条件。路由决定一个任务应该交给哪个 Agent 执行。核心是根据任务内容做匹配匹配的依据是 Agent 的能力描述、历史执行效果、当前负载等。触达决定一条消息能不能可靠地从发送方到达接收方并且被正确理解。核心是协议、确认机制、超时重试、幂等控制。很多项目在这三者上只做了调度然后强行把路由硬编码进 DAG触达则直接依赖消息队列“发出去即成功”的假象。上线之后就会发现队列只是保证了字节不丢根本没保证业务消息被正确消费。这就好比你把一份文件塞进公司内部快递柜系统告诉你“已投递”。但收件人到底有没有打开看、看没看懂、会不会按文件执行完全没有人追踪。Agent-Reach 补的正是这一块。1.3 Agent-Reach 的定位不做大脑只做可靠的神经系统我设计 Agent-Reach 时给自己定了一条边界它不做决策只做触达和寻址。Agent 到底该怎么处理任务、用什么模型、怎么生成结果都跟它无关它只解决三个问题谁在提供服务、能提供什么服务、目前是否健康一个请求来了应该匹配到哪些 Agent消息发出后怎么确认对方收到了并在失败时给出明确的反馈。这层定位用一句话概括它是多 Agent 系统的神经系统而不是大脑。大脑决定要做什么神经系统保证指令能准确到达该去的肢体并且知道肢体有没有真的动。方案能否感知 Agent 能力能否按意图寻址是否有端到端确认集成成本点对点直连否完全硬编码否取决于各 Agent 自己实现低消息队列否只保证字节送达否需额外写路由逻辑否队列不关心业务消费中工作流调度器否DAG 预先定义部分靠任务名映射部分只管节点状态高Agent-Reach是能力目录是意图寻址是触达协议低到中从表格里可以看到前三种方案都有自己的定位但在“Agent 感知 Agent”这件事上都有缺口。Agent-Reach 的定位就是把这个缺口补上而不用推翻你现有的调度器或消息基础设施。2. Agent-Reach 的三个核心设计能力目录、意图寻址与触达协议2.1 能力目录Agent 上线先“报到”写明自己会什么多 Agent 系统里最忌讳的事情就是写死调用链。你写死 Agent A 调 Agent B那 B 升级了接口、换了模型行为、或者临时下线A 立刻就崩。Agent-Reach 的做法是引入一层能力目录Capability Registry每个 Agent 启动时主动注册告诉系统自己会什么、怎么调用、参数长什么样。注册信息我设计成了一段 JSON大致是这样一个结构{ agent_id: text_cleaner_v3, name: 文本清洗器, capabilities: [ { capability: text_clean, description: 对原始文本做去重、去HTML标签、统一标点符号, input_schema: { type: object, properties: { content: {type: string, description: 原始文本内容}, options: {type: object, description: 清洗选项如 remove_html, deduplicate} }, required: [content] }, output_schema: { type: object, properties: { clean_text: {type: string}, meta: {type: object} } }, quality_score: 0.97, latency_p95_ms: 850 } ], ttl: 60, version: 3.2.1 }这个设计里有两个细节值得解释一下。首先是ttl: 60它表示这条注册信息只在 60 秒内有效Agent 必须周期性续租否则系统自动把它从目录里摘除。这样做的逻辑是一个连心跳都不能维持的 Agent大概率已经处于不可服务状态留着它只会让调用方浪费时间。其次是input_schema和output_schema它们不只是给开发者看的。当一个调用方 Agent 想要调用某个能力时Reach 可以把调用方生成的参数按 schema 做一次校验防止 Agent 之间因为参数格式不一致导致下游解析失败。这一步能挡掉很大一部分“接口联调”层面的低级错误。2.2 意图寻址调用方说“我要什么”而不是“我找谁”有了能力目录下一步就是怎么匹配。一开始我也想过最简单的方案调用方直接指名道姓说要调用text_cleaner_v3。但这个方案在真实环境里很快就会被推翻因为 Agent 会升级会替换今天叫text_cleaner_v3下个月可能就变成text_cleaner_v4业务方还得跟着改。所以 Agent-Reach 用的是意图寻址Intent Addressing调用方只描述自己需要什么能力以及相关的参数约束由 Reach 去目录里找合适的 Agent然后返回候选列表。调用方发的内容类似这样{ intent: text_clean, context: { language: zh, content_type: web_page, max_latency_ms: 2000, required_fields: [clean_text] } }Reach 拿到这个请求后会做三层匹配先按intent名称精确匹配这和函数名很像是最快的一路如果精确匹配没有结果再按描述文本做向量相似度检索把description里的语义和请求里的context做比对最后一层是用规则做兜底比如根据agent_id的白名单做人工指定。这里有一个刻意的取舍第一版我没有在路由匹配里跑大模型。原因是路由匹配要快、要稳定、要可解释大模型推理在这条链路上太慢也太贵。基于 embedding 的向量检索已经足够覆盖绝大多数语义匹配场景而且它的模型可以单独加载和 Agent 的推理链路完全隔离。2.3 触达协议消息不只要发出去还要确认对方收到了这是 Agent-Reach 和普通消息队列最大的区别。消息队列只负责把消息放到接收方的队列里不关心接收方有没有消费成功。Agent-Reach 则定义了一套轻量级触达协议核心是三个字段request_id全局唯一请求 ID用于幂等控制。接收方处理前先检查这个 ID 是否处理过处理过就直接返回旧结果不重复执行。expires_at消息的过期时间。超过这个时间还没被消费接收方可以直接丢弃避免堆了一堆过期任务还在执行。attempt当前是第几次尝试。接收方可以根据次数决定是执行还是拒绝比如一个幂等性差的任务第二次尝试时接收方可以选择不跑而是返回“请人工介入”。整个触达流程是一个带确认的闭环发送方把任务发给 ReachReach 选定目标 Agent 后投递目标 Agent 收到后先回一个 ACK确认接收然后执行执行完成后回传结果。如果发送方没收到 ACK就进入重试逻辑。这套机制的核心目标是把“我以为他收到了”变成“他确实收到了”。在真实业务里最坑的情况不是消息丢失而是消息被重复消费或者两边同时消费。ACK 加 request_id 的组合基本可以同时防住这两个问题。3. 最小可用版本的落地过程从注册到返回结果的完整链路3.1 技术选型为什么是 Python FastAPI Redis架构设计得再漂亮落地才是真考验。Agent-Reach 第一版我用的技术栈很朴素Python FastAPI Redis。选这个组合不是因为它最先进而是因为它最不容易出错。FastAPI 负责提供注册、寻址、投递三个 HTTP API它自带参数校验和 OpenAPI 文档联调时非常省事。Redis 在这里承担了两个角色一是用 TTL 存储能力目录天然适配 Agent 注册续租的场景二是用 Redis Stream 或者简单的 List 做消息暂存保证消息在 Reach 重启时不会直接丢。有人可能会问为什么不用 Kafka 或者 Pulsar 这种正经消息队列我的回答是Agent-Reach 的通信模型和普通事件流不一样。Agent 之间的触达是点对点请求确认模式不是主题订阅模式。Kafka 擅长的事情是多消费者并发消费同一份事件流而这恰恰是 Agent 通信里最需要避免的情况。用 Kafka 反而要花很多精力去做消息绑定的唯一消费者语义得不偿失。3.2 注册与心跳防止路由到“僵尸 Agent”注册端点非常直接核心逻辑就是对 Agent 提交的 JSON 做 schema 校验然后写入 Redis设置 TTLapp.post(/register) async def register(agent_info: AgentRegistration): # 校验必填字段 if not agent_info.agent_id or not agent_info.capabilities: raise HTTPException(status_code400, detailmissing required fields) key fagent:{agent_info.agent_id} # 用 Redis Hash 保存能力信息TTL 由 Agent 的 ttl 字段控制 await redis.hset(key, mappingagent_info.model_dump()) await redis.expire(key, agent_info.ttl) return {status: registered, agent_id: agent_info.agent_id}Agent 侧则要起一个后台任务定时去续租async def heartbeat_loop(agent_id: str, interval: int): while True: try: # 每次续租就是不间断地重新调用 register async with httpx.AsyncClient() as client: await client.post( http://reach-server:8320/register, jsonbuild_registration_payload(agent_id) ) except Exception: # 注册失败不要立刻退出记日志然后重试 logger.warning(heartbeat failed for %s, agent_id) await asyncio.sleep(interval)这里有一个经验要分享心跳失败不应该立刻重试而是记录日志、等下一个周期再试。因为如果 Reach 服务本身正在重启你那几秒内的疯狂重试只会把它的启动过程拖得更慢。心跳的关键不是每次成功而是长期保持注册信息的有效性。3.3 意图路由第一版就靠“精确匹配 向量检索 规则兜底”三层路由端是 Agent-Reach 的核心它的输入是上文的意图请求输出是一组按评分排序的候选 Agent。第一版实现我分了三层async def resolve_agents(intent_request: IntentRequest) - list[AgentCandidate]: candidates [] # 第一层意图名精确匹配 exact_agents await redis.smembers(fcapability:{intent_request.intent}) for agent_id in exact_agents: agent_info await redis.hgetall(fagent:{agent_id}) candidates.append(AgentCandidate(agent_idagent_id, score1.0, agent_infoagent_info)) # 第二层描述向量相似度匹配 if not candidates: intent_vector await embed_text(intent_request.context[description]) similar await vector_db.search(intent_vector, top_k5) for agent_id, score in similar: agent_info await redis.hgetall(fagent:{agent_id}) candidates.append(AgentCandidate(agent_idagent_id, scorescore, agent_infoagent_info)) # 第三层规则兜底 if not candidates and intent_request.context.get(fallback_agent_id): agent_id intent_request.context[fallback_agent_id] agent_info await redis.hgetall(fagent:{agent_id}) candidates.append(AgentCandidate(agent_idagent_id, score0.5, agent_infoagent_info)) # 统一按分数排序过滤超过负载阈值的 Agent return await filter_by_load(sorted(candidates, keylambda c: c.score, reverseTrue))这层实现的代码量不大但设计上有一个核心原则宁可返回空也不返回弱匹配。如果两层匹配都没有结果就直接告诉调用方“没有合适 Agent”而不是强行挑一个凑数。因为强匹配的 Agent 执行结果质量无法保证后续纠正的成本远高于这次的等待成本。3.4 消息触达与 ACK三个步骤控制消息不丢不重路由完成之后下一步就是投递消息。投递接口的语义很简单app.post(/dispatch) async def dispatch_message(payload: DispatchRequest): message { request_id: payload.request_id, from_agent: payload.from_agent, to_agent: payload.to_agent, payload: payload.payload, expires_at: time.time() 120, attempt: payload.attempt } # 写入 Redis 作为本地暂存 await redis.rpush(fqueue:{payload.to_agent}, json.dumps(message)) # 立即返回投递受理真正的送达以 ACK 为准 return {status: accepted, request_id: payload.request_id}目标 Agent 收到消息后的流程分三步先写request_id到 Redis 做幂等标记如果已存在则直接返回上次结果然后返回 ACK最后异步执行任务并把结果回传给调用方。ACK 返回是同步的执行是异步的这样发送方只等确认不等结果不会因为单个 Agent 处理慢而阻塞整条链路。这个“同步 ACK 异步执行”的模式是我在联调阶段调了很久才定下来的方案。一开始我是同步等待执行结果后来发现某个 Agent 偶尔要跑好几秒直接拖垮了调用方的线程池。改成 ACK 异步之后整条链路的吞吐量上去了问题也消失了。4. 异构 Agent 联调实录一次真实的跨语言协作请求4.1 三个 Agent 的注册信息长什么样理论说得再多不如现场跑一次联调。为了验证 Agent-Reach 的实用性我专门做了一次异构环境测试一个 Python 文本处理 Agent一个 Node.js 摘要 Agent还有一个跑在 Docker 容器里的外部服务封装成了一个 Agent 适配器。三个 Agent 注册进 Agent-Reach 后能力目录大致是这个样子Agent ID语言能力备注cleaner_svcPythontext_clean清洗文本去重、去标签summarizer_svcNode.jstext_summarize生成摘要支持长短两种格式toxicity_svcGocontent_moderate违规内容检测输出风险分它们之间没有任何直接依赖调用方只需要知道某个能力由谁提供不需要知道对方是 Python 写的还是 Node 写的。跨语言的差异被 Agent-Reach 的能力目录完全屏蔽掉了。这里有个很重要的体会异构环境才是多 Agent 系统的常态。你不可能把所有 Agent 都统一在一个技术栈里一个团队用 Python 做数据处理、另一个团队用 Node 写接口这是再正常不过的事。触达层如果绑定了某一门语言那这个系统天然就做不大。4.2 一次完整请求的全过程测试请求是这样的调用方想要清洗一批网页正文然后直接对清洗结果做摘要。按传统方式这需要调用方自己先调 A 再调 B中间还要处理可能的失败和重试。用 Agent-Reach调用方只需要连续发两次意图请求。第一步调用方发起清洗意图{ intent: text_clean, context: { content_type: web_page, max_latency_ms: 2000 } }Reach 返回cleaner_svc调用方随即把文章正文和 request_id 一起投递过去。cleaner_svc 收到消息后回 ACK开始清洗完成后把clean_text回传给调用方。第二步调用方发起摘要意图Reach 匹配到summarizer_svc。这次投递的时候调用方把上一步得到的clean_text作为 payload 完整传过去。summarizer_svc 处理完再回传摘要结果。整个过程从调用方视角看就是两次“发意图、收结果”中间 Agent 之间的协作细节完全透明。这大大降低了调用方的接入成本也避免了“A 调 B、B 又调 C、C 出错时 B 不知道怎么处理”这种链式耦合。4.3 两个现场翻车问题续租失败与意图误配联调过程没有一帆风顺恰恰相反我当场翻车了两次而且这两个问题很有代表性。第一个问题是续租失败。测试环境的 Docker 网络偶尔会抖动其中一个 Agent 的心跳连接超时了Reach 在 TTL 到期后把它的注册信息摘除了。之后调用方发起意图请求时Reach 返回“无匹配 Agent”。从 Agent 视角看它明明活着从目录视角看它已经“死了”。这件事让我意识到心跳摘除不能一刀切。现在的做法是临时摘除之前先探测一次 Agent 是否响应如果 ACK 正常则认为是网络抖动保留注册信息并延长 TTL只有连续多次都联系不上时才正式摘除。这个“先探测再摘除”的缓冲机制避免了大量因为网络瞬间波动造成的误杀。第二个问题是意图误配。测试时我发了一个比较模糊的意图描述“处理网页内容”结果 Reach 同时把清洗、摘要、违规检测三个 Agent 都匹配到了候选列表。调用方也没细看直接把任务投给了总结 Agent导致下游拿到的是摘要而不是清洗后的全文。这个问题的根源不在 Reach而在意图描述本身不够精确。后来我给方案补了一个约束意图请求里必须声明required_fields如果目标 Agent 的输出 schema 不包含这些字段直接过滤掉。光是加了这一个字段误配率就肉眼可见地降下来了。现象可能原因定位手段处理方式Agent 活着但目录里找不到心跳抖动导致 TTL 过期看心跳日志和 TTL 设置摘除前先探测防止误杀意图请求匹配到多个不相关 Agent意图描述太宽泛打印匹配到的候选和评分增加 required_fields 硬性过滤一个任务被两个 Agent 同时执行缺少幂等控制在两个 Agent 日志里找同一个 request_id用 Redis SETNX 做幂等标记下游拿到的数据格式不对输出 schema 没对齐对比注册信息里的 output_schema发送前做 schema 校验5. 工程化阶段我踩过的五个坑5.1 能力描述幻觉Agent 把自己说得无所不能如果说 Agent 会“撒谎”那一定是在注册能力描述的时候。本质原因是每个 Agent 的注册信息是它自己生成的而生成过程往往依赖大模型对自身能力的理解。大模型天然倾向于高估自己的能力于是很多 Agent 会在能力描述里写“我可以做任何形式的文本处理”但实际执行时稍微偏离训练分布就崩。这个问题的破解思路不是去审查描述而是让路由层用历史执行质量做动态加权。Agent-Reach 会记录每个 Agent 每次任务的成功率、平均耗时、结果质量评分然后把这些指标加权到路由排序里。一个 Agent 说得天花乱坠但实际屡屡翻车它的排名会自动下降甚至跌出候选列表。具体参数上我用的权重是能力描述相似度占 60%历史质量分占 30%负载状态占 10%。初期没有历史数据时三者按1.0 / 0.0 / 0.0工作跑完一百个任务之后逐渐过渡到上述默认权重。这是一个很朴素的“多臂老虎机”思路先探索后利用效果远好于静态打分。5.2 心跳误判一次网络抖动把正常 Agent 摘出了目录上面联调时遇到的续租失败在工程化阶段被放大了。压测的时候并发请求一上来某台机器偶尔出现几秒的 CPU 满载Heartbeat 请求超时Reach 就直接把它摘除了。而且摘除之后下一个心跳周期它又注册回来了再下一个周期又超时来来回回反复横跳。后来我加了两层保护。第一层是平滑连续失败计数只有连续五轮心跳失败才摘除中间任何一次成功都重置计数。第二层是摘除前的影子副本Agent 被摘除后它的注册信息不会立刻删除而是标记为degraded路由时排到候选列表末尾但不出现在正式候选里。影子副本的存在很关键因为有些 Agent 虽然暂时失联但它的调用方还在等它回传结果。如果把注册信息直接删掉回传结果到了 Reach 之后会因为没有对应路由而丢弃。影子副本至少能让回传结果有处可去。5.3 意图匹配的冷启动没有历史数据时怎么匹配这是向量检索方案天然的痛点。新上线一个 Agent它的能力描述只有短短一两句话向量库也还没有历史查询日志冷启动阶段全靠“description 文本语义”。而 Agent 能力描述往往很抽象比如“数据分析与可视化”但具体能做什么、不能做什么根本不存在文本里。我的经验是别指望纯自动匹配在冷启动阶段做到高准确率必须有人工种子数据。第一版我手动标注了大概两百组意图和 Agent 的对应关系作为规则层的兜底数据。当向量检索的分数低于某个阈值我设的是 0.65系统会优先走规则层而不是直接返回一个低置信度的匹配。这套思路的本质是不要让系统在它最没把握的时候自作主张。冷启动阶段宁可拒绝请求也不要给调用方一个不靠谱的 Agent。等人工确认的质量数据积累到五百条以上再逐步把规则层换成自动层。5.4 重试风暴下游一抖动上游全来打这是我在压测时遇到的最惊险的一次事故。某个 Agent 因为一个外部依赖变慢响应时间从 200ms 飙升到 5 秒。正常情况下 Reach 的超时重试逻辑会自动触发但问题是同时有几十个调用方都发起了请求每个调用方的重试策略又是“隔几秒重试一次”于是形成了一波接一波的重试风暴直接把那个 Agent 打挂了。事后我把重试策略彻底改了一遍核心三条重试采用恒定退避而不是抖动退避固定间隔 15 秒最多重试 3 次对同一个目标 Agent 的并发请求做合并类似请求合并成一个减少下游压力目标 Agent 连续失败三次后Reach 自动熔断不再向它投递任何消息持续 60 秒。这里最关键的是熔断。它的作用和电路保护器一样下游已经扛不住了上游还拼命塞只会让系统彻底瘫痪。熔断之后调用方会快速收到一个“该 Agent 暂不可用”的明确错误而不是一直超时等待这对调用方做降级策略反而更友好。5.5 链路可观测性异步通信的“黑匣子”问题Agent-Reach 把触达做成了异步这是好事但也带来了一个麻烦请求到底走到哪一步了是路由没匹配上还是消息投递失败还是接收方已经收到但还没执行完如果没有任何观测手段排查问题就等于在黑屋子里找一根针。解决方案一点也不复杂给每个消息打上trace_id从调用方发起意图请求开始到路由、投递、ACK、执行、回传结果全链路日志都带上这个 ID。然后挂一个日志面板按trace_id查询整条链路的每个节点状态。logger.info( reach_trace agent%s intent%s trace_id%s stagedispatched resultaccepted, payload.to_agent, intent_request.intent, payload.trace_id )这套日志方案粗糙但有效。有一次生产环境里某个 Agent 处理特别慢我直接按trace_id查日志发现问题卡在“已 ACK 但未执行完成”而这个 Agent 的执行逻辑里有一段死循环。没有 trace_id这个问题光靠猜至少要多花半天时间。6. 现在我的用法与后续扩展建议6.1 一套经过验证的最小配置建议如果你也想在自己的项目里搭一层 Agent-Reach我建议第一版不要贪多按下面这个配置起步注册和心跳TTL 设 60 秒心跳周期 20 秒连续 5 次失败才摘除路由匹配精确匹配 向量检索冷启动阶段加人工规则兜底触达协议request_id 幂等、expires_at 过期、ACK 同步返回、执行异步进行超时与重试固定退避 15 秒一次最多 3 次连续 3 次失败触发熔断 60 秒可观测性确保全链路日志都带 trace_id搭建一个简单日志查询面板。这套配置不算最优但足够稳。它允许你在不引入重型框架的前提下先把多 Agent 协作的骨架立起来再根据真实流量慢慢调整参数。6.2 可以扩展的方向Agent-Reach 目前的定位是单集群内的触达路由但它天然可以向外扩展。我觉得有几个方向值得关注第一个方向是多集群互访。多个业务线各跑一套 Agent 集群时一个集群内的 Agent 如何透明调用另一个集群里的服务需要在能力目录之上再加一层集群间路由。难点在于跨集群的延迟和权限控制但设计思路是完全一致的。第二个方向是意图路由策略的可学习化。目前的路由是“相似度 质量分”的静态组合后续可以把路由决策变成一个在线学习问题基于每次执行结果实时调整路由权重。这需要一套完整的效果回传链路本质上就是我上面提到的质量分动态加权只是把它做得更细。第三个方向是与人工审批流打通。某些高风险任务不能全自动执行应该在触达协议里增加一个approval_required字段Reach 匹配好 Agent 后先挂起等人工确认后再投递而不是直接自动执行。这个能力对合规场景几乎是刚需。6.3 给想自己造轮子的读者几句心里话如果你在考虑自己实现一套类似的机制我有一个很直接的建议先别追求全自动。能力目录 意图寻址 ACK 确认这三件套已经能解决掉多 Agent 协作里 80% 的触达问题。剩下的 20%包括动态路由调优、跨集群方案、自动化效果评估都可以在跑了真实业务之后再慢慢迭代。我自己最深的体会是多 Agent 系统最大的风险从来不是单个 Agent 不够聪明而是 Agent 之间缺乏一套可靠的协同语义。你让一百个聪明人在一起工作如果不给他们统一的指令格式和确认机制产出大概率不如十个普通人配合默契。Agent-Reach 解决的就是这个“配合默契”的问题。最后分享一个小技巧如果你在测试自己的 Agent 触达层一定记得人为注入故障比如随机停掉一个 Agent、让某个接口响应变慢 10 倍、故意发重复的 request_id。只有在故障注入下还能保证消息不丢、不重、不乱配的系统才敢放到生产环境里。我就是在轮番折腾了这三件事之后才真正对 Agent-Reach 有了信心。 
长河君 · 2026/10/15 10:38:32 · 阅读 1.2k Agent-Reach：多Agent系统轻量级触达路由设计与实践
先说结论Agent-Reach 不是什么大模型应用也不是一个多智能体编排框架它是被“Agent 之间互相找不到、消息发出去没人回、偶尔还有两边同时执行同一个任务”这类问题逼到墙角之后我自己写的一层轻量级触达路由。Reach 这个词取自分布式系统里的“可达性”——在一个多 Agent 系统里一个 Agent 能不能被另一个 Agent 可靠地触达直接决定了这套系统到底是玩具还是能跑生产的工具。如果你也在搭多 Agent 协作系统或者正在被各种框架的“工具调用”“任务编排”概念绕得头晕那这篇文章大概对你有用。我会把 Agent-Reach 从设计思路到落地代码、再到我在联调阶段踩过的坑按真实推进顺序完整写一遍。适合的人群是已经跑通单 Agent开始折腾多 Agent 协作但对“Agent 之间怎么通信”这件事还没有成熟方案的人。1. 先弄明白“触达”到底是哪一环的问题1.1 从一次线上事故说起最早我手上有一套系统里面有七个 Agent 各管一摊一个抓数据一个做文本清洗一个跑摘要一个做情感判断还有一个专门质检。单看每个 Agent 都挺正常但把它们串起来之后问题就来了。最典型的一次事故是这样的Agent A 需要把一批文本交给 Agent B 做清洗结果消息发出去之后 B 没收到A 以为 B 崩了重试了三次。与此同时调度系统又把这个任务分给了 Agent C 执行C 和 B 的清洗逻辑不完全一样产出的数据格式差了一个字段。下游消费方拿到数据后直接报错整条链路卡了一个多小时。事后排查根子不在调度也不在某个 Agent 的代码而在“触达”这一层任务发出去之后系统根本不确认对方是否真的收到了、是否有能力处理、是否已经处理过类似任务。总线把消息塞进队列就认为完成了Agent 之间也没有统一的能力描述接收方只能靠消息里的任务名猜自己该不该接。当时我就意识到多 Agent 系统的问题不是“能不能调通”而是“该找谁调、怎么调、怎么确认调成功了”。于是有了 Agent-Reach。1.2 调度、路由与触达三个容易被混为一谈的环节很多人在讨论多 Agent 系统时会用一套模糊的说法把调度、路由和触达都叫做“编排”。实际拆开看这是三个完全不同的环节调度决定任务在什么时候执行、以什么顺序执行、是否需要并行或串行。典型的调度器是 Airflow、Prefect 这类工作流引擎它们的核心是 DAG 和时间条件。路由决定一个任务应该交给哪个 Agent 执行。核心是根据任务内容做匹配匹配的依据是 Agent 的能力描述、历史执行效果、当前负载等。触达决定一条消息能不能可靠地从发送方到达接收方并且被正确理解。核心是协议、确认机制、超时重试、幂等控制。很多项目在这三者上只做了调度然后强行把路由硬编码进 DAG触达则直接依赖消息队列“发出去即成功”的假象。上线之后就会发现队列只是保证了字节不丢根本没保证业务消息被正确消费。这就好比你把一份文件塞进公司内部快递柜系统告诉你“已投递”。但收件人到底有没有打开看、看没看懂、会不会按文件执行完全没有人追踪。Agent-Reach 补的正是这一块。1.3 Agent-Reach 的定位不做大脑只做可靠的神经系统我设计 Agent-Reach 时给自己定了一条边界它不做决策只做触达和寻址。Agent 到底该怎么处理任务、用什么模型、怎么生成结果都跟它无关它只解决三个问题谁在提供服务、能提供什么服务、目前是否健康一个请求来了应该匹配到哪些 Agent消息发出后怎么确认对方收到了并在失败时给出明确的反馈。这层定位用一句话概括它是多 Agent 系统的神经系统而不是大脑。大脑决定要做什么神经系统保证指令能准确到达该去的肢体并且知道肢体有没有真的动。方案能否感知 Agent 能力能否按意图寻址是否有端到端确认集成成本点对点直连否完全硬编码否取决于各 Agent 自己实现低消息队列否只保证字节送达否需额外写路由逻辑否队列不关心业务消费中工作流调度器否DAG 预先定义部分靠任务名映射部分只管节点状态高Agent-Reach是能力目录是意图寻址是触达协议低到中从表格里可以看到前三种方案都有自己的定位但在“Agent 感知 Agent”这件事上都有缺口。Agent-Reach 的定位就是把这个缺口补上而不用推翻你现有的调度器或消息基础设施。2. Agent-Reach 的三个核心设计能力目录、意图寻址与触达协议2.1 能力目录Agent 上线先“报到”写明自己会什么多 Agent 系统里最忌讳的事情就是写死调用链。你写死 Agent A 调 Agent B那 B 升级了接口、换了模型行为、或者临时下线A 立刻就崩。Agent-Reach 的做法是引入一层能力目录Capability Registry每个 Agent 启动时主动注册告诉系统自己会什么、怎么调用、参数长什么样。注册信息我设计成了一段 JSON大致是这样一个结构{ agent_id: text_cleaner_v3, name: 文本清洗器, capabilities: [ { capability: text_clean, description: 对原始文本做去重、去HTML标签、统一标点符号, input_schema: { type: object, properties: { content: {type: string, description: 原始文本内容}, options: {type: object, description: 清洗选项如 remove_html, deduplicate} }, required: [content] }, output_schema: { type: object, properties: { clean_text: {type: string}, meta: {type: object} } }, quality_score: 0.97, latency_p95_ms: 850 } ], ttl: 60, version: 3.2.1 }这个设计里有两个细节值得解释一下。首先是ttl: 60它表示这条注册信息只在 60 秒内有效Agent 必须周期性续租否则系统自动把它从目录里摘除。这样做的逻辑是一个连心跳都不能维持的 Agent大概率已经处于不可服务状态留着它只会让调用方浪费时间。其次是input_schema和output_schema它们不只是给开发者看的。当一个调用方 Agent 想要调用某个能力时Reach 可以把调用方生成的参数按 schema 做一次校验防止 Agent 之间因为参数格式不一致导致下游解析失败。这一步能挡掉很大一部分“接口联调”层面的低级错误。2.2 意图寻址调用方说“我要什么”而不是“我找谁”有了能力目录下一步就是怎么匹配。一开始我也想过最简单的方案调用方直接指名道姓说要调用text_cleaner_v3。但这个方案在真实环境里很快就会被推翻因为 Agent 会升级会替换今天叫text_cleaner_v3下个月可能就变成text_cleaner_v4业务方还得跟着改。所以 Agent-Reach 用的是意图寻址Intent Addressing调用方只描述自己需要什么能力以及相关的参数约束由 Reach 去目录里找合适的 Agent然后返回候选列表。调用方发的内容类似这样{ intent: text_clean, context: { language: zh, content_type: web_page, max_latency_ms: 2000, required_fields: [clean_text] } }Reach 拿到这个请求后会做三层匹配先按intent名称精确匹配这和函数名很像是最快的一路如果精确匹配没有结果再按描述文本做向量相似度检索把description里的语义和请求里的context做比对最后一层是用规则做兜底比如根据agent_id的白名单做人工指定。这里有一个刻意的取舍第一版我没有在路由匹配里跑大模型。原因是路由匹配要快、要稳定、要可解释大模型推理在这条链路上太慢也太贵。基于 embedding 的向量检索已经足够覆盖绝大多数语义匹配场景而且它的模型可以单独加载和 Agent 的推理链路完全隔离。2.3 触达协议消息不只要发出去还要确认对方收到了这是 Agent-Reach 和普通消息队列最大的区别。消息队列只负责把消息放到接收方的队列里不关心接收方有没有消费成功。Agent-Reach 则定义了一套轻量级触达协议核心是三个字段request_id全局唯一请求 ID用于幂等控制。接收方处理前先检查这个 ID 是否处理过处理过就直接返回旧结果不重复执行。expires_at消息的过期时间。超过这个时间还没被消费接收方可以直接丢弃避免堆了一堆过期任务还在执行。attempt当前是第几次尝试。接收方可以根据次数决定是执行还是拒绝比如一个幂等性差的任务第二次尝试时接收方可以选择不跑而是返回“请人工介入”。整个触达流程是一个带确认的闭环发送方把任务发给 ReachReach 选定目标 Agent 后投递目标 Agent 收到后先回一个 ACK确认接收然后执行执行完成后回传结果。如果发送方没收到 ACK就进入重试逻辑。这套机制的核心目标是把“我以为他收到了”变成“他确实收到了”。在真实业务里最坑的情况不是消息丢失而是消息被重复消费或者两边同时消费。ACK 加 request_id 的组合基本可以同时防住这两个问题。3. 最小可用版本的落地过程从注册到返回结果的完整链路3.1 技术选型为什么是 Python FastAPI Redis架构设计得再漂亮落地才是真考验。Agent-Reach 第一版我用的技术栈很朴素Python FastAPI Redis。选这个组合不是因为它最先进而是因为它最不容易出错。FastAPI 负责提供注册、寻址、投递三个 HTTP API它自带参数校验和 OpenAPI 文档联调时非常省事。Redis 在这里承担了两个角色一是用 TTL 存储能力目录天然适配 Agent 注册续租的场景二是用 Redis Stream 或者简单的 List 做消息暂存保证消息在 Reach 重启时不会直接丢。有人可能会问为什么不用 Kafka 或者 Pulsar 这种正经消息队列我的回答是Agent-Reach 的通信模型和普通事件流不一样。Agent 之间的触达是点对点请求确认模式不是主题订阅模式。Kafka 擅长的事情是多消费者并发消费同一份事件流而这恰恰是 Agent 通信里最需要避免的情况。用 Kafka 反而要花很多精力去做消息绑定的唯一消费者语义得不偿失。3.2 注册与心跳防止路由到“僵尸 Agent”注册端点非常直接核心逻辑就是对 Agent 提交的 JSON 做 schema 校验然后写入 Redis设置 TTLapp.post(/register) async def register(agent_info: AgentRegistration): # 校验必填字段 if not agent_info.agent_id or not agent_info.capabilities: raise HTTPException(status_code400, detailmissing required fields) key fagent:{agent_info.agent_id} # 用 Redis Hash 保存能力信息TTL 由 Agent 的 ttl 字段控制 await redis.hset(key, mappingagent_info.model_dump()) await redis.expire(key, agent_info.ttl) return {status: registered, agent_id: agent_info.agent_id}Agent 侧则要起一个后台任务定时去续租async def heartbeat_loop(agent_id: str, interval: int): while True: try: # 每次续租就是不间断地重新调用 register async with httpx.AsyncClient() as client: await client.post( http://reach-server:8320/register, jsonbuild_registration_payload(agent_id) ) except Exception: # 注册失败不要立刻退出记日志然后重试 logger.warning(heartbeat failed for %s, agent_id) await asyncio.sleep(interval)这里有一个经验要分享心跳失败不应该立刻重试而是记录日志、等下一个周期再试。因为如果 Reach 服务本身正在重启你那几秒内的疯狂重试只会把它的启动过程拖得更慢。心跳的关键不是每次成功而是长期保持注册信息的有效性。3.3 意图路由第一版就靠“精确匹配 向量检索 规则兜底”三层路由端是 Agent-Reach 的核心它的输入是上文的意图请求输出是一组按评分排序的候选 Agent。第一版实现我分了三层async def resolve_agents(intent_request: IntentRequest) - list[AgentCandidate]: candidates [] # 第一层意图名精确匹配 exact_agents await redis.smembers(fcapability:{intent_request.intent}) for agent_id in exact_agents: agent_info await redis.hgetall(fagent:{agent_id}) candidates.append(AgentCandidate(agent_idagent_id, score1.0, agent_infoagent_info)) # 第二层描述向量相似度匹配 if not candidates: intent_vector await embed_text(intent_request.context[description]) similar await vector_db.search(intent_vector, top_k5) for agent_id, score in similar: agent_info await redis.hgetall(fagent:{agent_id}) candidates.append(AgentCandidate(agent_idagent_id, scorescore, agent_infoagent_info)) # 第三层规则兜底 if not candidates and intent_request.context.get(fallback_agent_id): agent_id intent_request.context[fallback_agent_id] agent_info await redis.hgetall(fagent:{agent_id}) candidates.append(AgentCandidate(agent_idagent_id, score0.5, agent_infoagent_info)) # 统一按分数排序过滤超过负载阈值的 Agent return await filter_by_load(sorted(candidates, keylambda c: c.score, reverseTrue))这层实现的代码量不大但设计上有一个核心原则宁可返回空也不返回弱匹配。如果两层匹配都没有结果就直接告诉调用方“没有合适 Agent”而不是强行挑一个凑数。因为强匹配的 Agent 执行结果质量无法保证后续纠正的成本远高于这次的等待成本。3.4 消息触达与 ACK三个步骤控制消息不丢不重路由完成之后下一步就是投递消息。投递接口的语义很简单app.post(/dispatch) async def dispatch_message(payload: DispatchRequest): message { request_id: payload.request_id, from_agent: payload.from_agent, to_agent: payload.to_agent, payload: payload.payload, expires_at: time.time() 120, attempt: payload.attempt } # 写入 Redis 作为本地暂存 await redis.rpush(fqueue:{payload.to_agent}, json.dumps(message)) # 立即返回投递受理真正的送达以 ACK 为准 return {status: accepted, request_id: payload.request_id}目标 Agent 收到消息后的流程分三步先写request_id到 Redis 做幂等标记如果已存在则直接返回上次结果然后返回 ACK最后异步执行任务并把结果回传给调用方。ACK 返回是同步的执行是异步的这样发送方只等确认不等结果不会因为单个 Agent 处理慢而阻塞整条链路。这个“同步 ACK 异步执行”的模式是我在联调阶段调了很久才定下来的方案。一开始我是同步等待执行结果后来发现某个 Agent 偶尔要跑好几秒直接拖垮了调用方的线程池。改成 ACK 异步之后整条链路的吞吐量上去了问题也消失了。4. 异构 Agent 联调实录一次真实的跨语言协作请求4.1 三个 Agent 的注册信息长什么样理论说得再多不如现场跑一次联调。为了验证 Agent-Reach 的实用性我专门做了一次异构环境测试一个 Python 文本处理 Agent一个 Node.js 摘要 Agent还有一个跑在 Docker 容器里的外部服务封装成了一个 Agent 适配器。三个 Agent 注册进 Agent-Reach 后能力目录大致是这个样子Agent ID语言能力备注cleaner_svcPythontext_clean清洗文本去重、去标签summarizer_svcNode.jstext_summarize生成摘要支持长短两种格式toxicity_svcGocontent_moderate违规内容检测输出风险分它们之间没有任何直接依赖调用方只需要知道某个能力由谁提供不需要知道对方是 Python 写的还是 Node 写的。跨语言的差异被 Agent-Reach 的能力目录完全屏蔽掉了。这里有个很重要的体会异构环境才是多 Agent 系统的常态。你不可能把所有 Agent 都统一在一个技术栈里一个团队用 Python 做数据处理、另一个团队用 Node 写接口这是再正常不过的事。触达层如果绑定了某一门语言那这个系统天然就做不大。4.2 一次完整请求的全过程测试请求是这样的调用方想要清洗一批网页正文然后直接对清洗结果做摘要。按传统方式这需要调用方自己先调 A 再调 B中间还要处理可能的失败和重试。用 Agent-Reach调用方只需要连续发两次意图请求。第一步调用方发起清洗意图{ intent: text_clean, context: { content_type: web_page, max_latency_ms: 2000 } }Reach 返回cleaner_svc调用方随即把文章正文和 request_id 一起投递过去。cleaner_svc 收到消息后回 ACK开始清洗完成后把clean_text回传给调用方。第二步调用方发起摘要意图Reach 匹配到summarizer_svc。这次投递的时候调用方把上一步得到的clean_text作为 payload 完整传过去。summarizer_svc 处理完再回传摘要结果。整个过程从调用方视角看就是两次“发意图、收结果”中间 Agent 之间的协作细节完全透明。这大大降低了调用方的接入成本也避免了“A 调 B、B 又调 C、C 出错时 B 不知道怎么处理”这种链式耦合。4.3 两个现场翻车问题续租失败与意图误配联调过程没有一帆风顺恰恰相反我当场翻车了两次而且这两个问题很有代表性。第一个问题是续租失败。测试环境的 Docker 网络偶尔会抖动其中一个 Agent 的心跳连接超时了Reach 在 TTL 到期后把它的注册信息摘除了。之后调用方发起意图请求时Reach 返回“无匹配 Agent”。从 Agent 视角看它明明活着从目录视角看它已经“死了”。这件事让我意识到心跳摘除不能一刀切。现在的做法是临时摘除之前先探测一次 Agent 是否响应如果 ACK 正常则认为是网络抖动保留注册信息并延长 TTL只有连续多次都联系不上时才正式摘除。这个“先探测再摘除”的缓冲机制避免了大量因为网络瞬间波动造成的误杀。第二个问题是意图误配。测试时我发了一个比较模糊的意图描述“处理网页内容”结果 Reach 同时把清洗、摘要、违规检测三个 Agent 都匹配到了候选列表。调用方也没细看直接把任务投给了总结 Agent导致下游拿到的是摘要而不是清洗后的全文。这个问题的根源不在 Reach而在意图描述本身不够精确。后来我给方案补了一个约束意图请求里必须声明required_fields如果目标 Agent 的输出 schema 不包含这些字段直接过滤掉。光是加了这一个字段误配率就肉眼可见地降下来了。现象可能原因定位手段处理方式Agent 活着但目录里找不到心跳抖动导致 TTL 过期看心跳日志和 TTL 设置摘除前先探测防止误杀意图请求匹配到多个不相关 Agent意图描述太宽泛打印匹配到的候选和评分增加 required_fields 硬性过滤一个任务被两个 Agent 同时执行缺少幂等控制在两个 Agent 日志里找同一个 request_id用 Redis SETNX 做幂等标记下游拿到的数据格式不对输出 schema 没对齐对比注册信息里的 output_schema发送前做 schema 校验5. 工程化阶段我踩过的五个坑5.1 能力描述幻觉Agent 把自己说得无所不能如果说 Agent 会“撒谎”那一定是在注册能力描述的时候。本质原因是每个 Agent 的注册信息是它自己生成的而生成过程往往依赖大模型对自身能力的理解。大模型天然倾向于高估自己的能力于是很多 Agent 会在能力描述里写“我可以做任何形式的文本处理”但实际执行时稍微偏离训练分布就崩。这个问题的破解思路不是去审查描述而是让路由层用历史执行质量做动态加权。Agent-Reach 会记录每个 Agent 每次任务的成功率、平均耗时、结果质量评分然后把这些指标加权到路由排序里。一个 Agent 说得天花乱坠但实际屡屡翻车它的排名会自动下降甚至跌出候选列表。具体参数上我用的权重是能力描述相似度占 60%历史质量分占 30%负载状态占 10%。初期没有历史数据时三者按1.0 / 0.0 / 0.0工作跑完一百个任务之后逐渐过渡到上述默认权重。这是一个很朴素的“多臂老虎机”思路先探索后利用效果远好于静态打分。5.2 心跳误判一次网络抖动把正常 Agent 摘出了目录上面联调时遇到的续租失败在工程化阶段被放大了。压测的时候并发请求一上来某台机器偶尔出现几秒的 CPU 满载Heartbeat 请求超时Reach 就直接把它摘除了。而且摘除之后下一个心跳周期它又注册回来了再下一个周期又超时来来回回反复横跳。后来我加了两层保护。第一层是平滑连续失败计数只有连续五轮心跳失败才摘除中间任何一次成功都重置计数。第二层是摘除前的影子副本Agent 被摘除后它的注册信息不会立刻删除而是标记为degraded路由时排到候选列表末尾但不出现在正式候选里。影子副本的存在很关键因为有些 Agent 虽然暂时失联但它的调用方还在等它回传结果。如果把注册信息直接删掉回传结果到了 Reach 之后会因为没有对应路由而丢弃。影子副本至少能让回传结果有处可去。5.3 意图匹配的冷启动没有历史数据时怎么匹配这是向量检索方案天然的痛点。新上线一个 Agent它的能力描述只有短短一两句话向量库也还没有历史查询日志冷启动阶段全靠“description 文本语义”。而 Agent 能力描述往往很抽象比如“数据分析与可视化”但具体能做什么、不能做什么根本不存在文本里。我的经验是别指望纯自动匹配在冷启动阶段做到高准确率必须有人工种子数据。第一版我手动标注了大概两百组意图和 Agent 的对应关系作为规则层的兜底数据。当向量检索的分数低于某个阈值我设的是 0.65系统会优先走规则层而不是直接返回一个低置信度的匹配。这套思路的本质是不要让系统在它最没把握的时候自作主张。冷启动阶段宁可拒绝请求也不要给调用方一个不靠谱的 Agent。等人工确认的质量数据积累到五百条以上再逐步把规则层换成自动层。5.4 重试风暴下游一抖动上游全来打这是我在压测时遇到的最惊险的一次事故。某个 Agent 因为一个外部依赖变慢响应时间从 200ms 飙升到 5 秒。正常情况下 Reach 的超时重试逻辑会自动触发但问题是同时有几十个调用方都发起了请求每个调用方的重试策略又是“隔几秒重试一次”于是形成了一波接一波的重试风暴直接把那个 Agent 打挂了。事后我把重试策略彻底改了一遍核心三条重试采用恒定退避而不是抖动退避固定间隔 15 秒最多重试 3 次对同一个目标 Agent 的并发请求做合并类似请求合并成一个减少下游压力目标 Agent 连续失败三次后Reach 自动熔断不再向它投递任何消息持续 60 秒。这里最关键的是熔断。它的作用和电路保护器一样下游已经扛不住了上游还拼命塞只会让系统彻底瘫痪。熔断之后调用方会快速收到一个“该 Agent 暂不可用”的明确错误而不是一直超时等待这对调用方做降级策略反而更友好。5.5 链路可观测性异步通信的“黑匣子”问题Agent-Reach 把触达做成了异步这是好事但也带来了一个麻烦请求到底走到哪一步了是路由没匹配上还是消息投递失败还是接收方已经收到但还没执行完如果没有任何观测手段排查问题就等于在黑屋子里找一根针。解决方案一点也不复杂给每个消息打上trace_id从调用方发起意图请求开始到路由、投递、ACK、执行、回传结果全链路日志都带上这个 ID。然后挂一个日志面板按trace_id查询整条链路的每个节点状态。logger.info( reach_trace agent%s intent%s trace_id%s stagedispatched resultaccepted, payload.to_agent, intent_request.intent, payload.trace_id )这套日志方案粗糙但有效。有一次生产环境里某个 Agent 处理特别慢我直接按trace_id查日志发现问题卡在“已 ACK 但未执行完成”而这个 Agent 的执行逻辑里有一段死循环。没有 trace_id这个问题光靠猜至少要多花半天时间。6. 现在我的用法与后续扩展建议6.1 一套经过验证的最小配置建议如果你也想在自己的项目里搭一层 Agent-Reach我建议第一版不要贪多按下面这个配置起步注册和心跳TTL 设 60 秒心跳周期 20 秒连续 5 次失败才摘除路由匹配精确匹配 向量检索冷启动阶段加人工规则兜底触达协议request_id 幂等、expires_at 过期、ACK 同步返回、执行异步进行超时与重试固定退避 15 秒一次最多 3 次连续 3 次失败触发熔断 60 秒可观测性确保全链路日志都带 trace_id搭建一个简单日志查询面板。这套配置不算最优但足够稳。它允许你在不引入重型框架的前提下先把多 Agent 协作的骨架立起来再根据真实流量慢慢调整参数。6.2 可以扩展的方向Agent-Reach 目前的定位是单集群内的触达路由但它天然可以向外扩展。我觉得有几个方向值得关注第一个方向是多集群互访。多个业务线各跑一套 Agent 集群时一个集群内的 Agent 如何透明调用另一个集群里的服务需要在能力目录之上再加一层集群间路由。难点在于跨集群的延迟和权限控制但设计思路是完全一致的。第二个方向是意图路由策略的可学习化。目前的路由是“相似度 质量分”的静态组合后续可以把路由决策变成一个在线学习问题基于每次执行结果实时调整路由权重。这需要一套完整的效果回传链路本质上就是我上面提到的质量分动态加权只是把它做得更细。第三个方向是与人工审批流打通。某些高风险任务不能全自动执行应该在触达协议里增加一个approval_required字段Reach 匹配好 Agent 后先挂起等人工确认后再投递而不是直接自动执行。这个能力对合规场景几乎是刚需。6.3 给想自己造轮子的读者几句心里话如果你在考虑自己实现一套类似的机制我有一个很直接的建议先别追求全自动。能力目录 意图寻址 ACK 确认这三件套已经能解决掉多 Agent 协作里 80% 的触达问题。剩下的 20%包括动态路由调优、跨集群方案、自动化效果评估都可以在跑了真实业务之后再慢慢迭代。我自己最深的体会是多 Agent 系统最大的风险从来不是单个 Agent 不够聪明而是 Agent 之间缺乏一套可靠的协同语义。你让一百个聪明人在一起工作如果不给他们统一的指令格式和确认机制产出大概率不如十个普通人配合默契。Agent-Reach 解决的就是这个“配合默契”的问题。最后分享一个小技巧如果你在测试自己的 Agent 触达层一定记得人为注入故障比如随机停掉一个 Agent、让某个接口响应变慢 10 倍、故意发重复的 request_id。只有在故障注入下还能保证消息不丢、不重、不乱配的系统才敢放到生产环境里。我就是在轮番折腾了这三件事之后才真正对 Agent-Reach 有了信心。