做完Agent开发以后我心里一直有个疙瘩：大模型能说会道，但真要它去完成一件实际任务，卡点往往不在推理，而在“够不着”。模型生成的回复再漂亮，数据拿不到、接口调不动、另一个Agent找不到它，一切就是纸上谈兵。Agent-Reach这个项目就是冲着这个痛点去的，它是一个给智能体做“触达层”的轻量框架——负责让Agent真正够到工具、数据库、外部服务以及其他Agent。如果你也在做Agent应用，正在被Function Calling的兼容性、多智能体之间的通信路由、工具调用的超时和权限问题折磨，那这篇文章值得你花十分钟看完。
先交代一下背景：Agent-Reach不是一个大而全的Agent运行时，它只做一件事情——智能体外部能力接入。最初它只是为了解决我自己项目里工具接入成本高的问题，后来逐渐长出了会话通道、多智能体路由这些能力。下文我会把设计思路、第一版跑通的完整链路、多智能体路由的实现，以及实测过程中遇到的那些坑，全部摊开讲清楚。
1. 为什么Agent经常“够不着”东西——触达问题的本质
1.1 LLM的“手”其实很短
每一个做过LLM应用的人都应该接受这个事实：大模型本身没有任何对外部世界的原生IO能力。它接不了REST API、读不了数据库、拿不到用户上传的文件，它唯一的IO通道就是文本输入和文本输出。你问它“帮我查一下订单物流”，模型能给你一段很漂亮的解释，但它自己查不了。这就像招聘了一个优秀的分析师，却不给他电脑、不给他电话，他只能靠脑子里的记忆和推理回答你。
所以过去的做法是，把能力“塞”进提示词里。你需要把工具说明、JSON Schema、返回示例全部写进System Prompt，再逼着模型按照指定JSON格式吐出一个函数调用参数。这样做的短期问题是token成本很高，长期问题是整个请求链路的脆弱性成倍放大——模型只要有一次漏掉了某个必填字段，整次调用就失败，而且失败后的重试逻辑完全靠Prompt修补，像在沙地上打地基。
Agent-Reach最初要解决的，就是这个“模型和外部世界之间没有标准触达通道”的问题。它不把工具当Prompt片段处理，而是把工具当作Agent运行时里的第一等资源：注册、发现、映射成统一触达描述符，再通过会话通道给Agent复用。这样模型只管按描述符发起调用，至于这个调用是HTTP、是Python函数、是SQL查询，还是另一个Agent，都由触达层去处理。
1.2 裸用Function Calling的代价
我相信你现在一定在用Function Calling一类的机制。代码写得越久，越能感觉到它有几个边界问题：
第一，标准碎片化。不同模型厂商的Function Calling格式不兼容，OpenAI一套、Anthropic一套、本地模型一套。项目从A模型迁到B模型，工具定义和解析逻辑几乎要重写。更别指望在不同模型之间共享一套触达规则。Agent-Reach的做法是定义自己的中间描述层，用的“触达描述符”（Reach Descriptor）在结构上兼容常见的JSON Schema，但语义上更偏重谁可以调、延迟上限是什么、超时怎么处理。
第二，没有链路层状态。裸Function Calling是“发一次请求、调用一次工具、拿一次结果”，每次调用之间是完全独立的。但真实任务往往是一个链路：先查库存，再下订单，再发通知。中间一旦某一步超时，或者第一步返回的数据决定了第二步的参数，这套无状态机制就得靠应用层自己维护状态机。Agent-Reach则会为每一次任务动态建立一个会话通道，通道内保留上下文快照、调用历史、已获得的数据片段，让Agent做多步决策时不用反复把历史塞回模型窗口。
第三，异常恢复无人管。工具挂了怎么办？服务响应慢怎么办？返回格式和注册描述不一致怎么办？裸Function Calling把这些问题全部抛给你的业务代码，你在每个工具调用点都要写try-except，而且这类代码长得高度相似。触达层把这些统一切到默认策略里：重试、降级、失败透传，Agent需要做的只是知道“这个能力现在不可用，换个方案”。
1.3 多智能体之间的“拨号难题”
其实真正让我下定决心写Agent-Reach的，是多智能体协同这块。Agent化以后，一个小组件往往要去找另一个小组件——“我需要用户数据”“我需要订单详情”“我需要通知服务”。这就和电话系统一样：得先知道对方的号码，然后拨号、等待接通、确认对方身份、再说事。没有一套统一的可达性管理，两个Agent之间的通信要么靠共享数据库硬耦合，要么靠手动写死对方的地址，非常原始。
Agent-Reach里我把这套机制叫“可达性路由”。每个Agent启动时注册自己的触达描述符和地址，路由表负责转发请求。调用方Agent不需要知道目标Agent的部署位置和实现语言，只需要按描述符声明“我要这个能力”，路由表去找谁提供这个能力。我后面会专门用一个章节讲这一块的实现细节，这里先记住一个结论：多智能体方案要可用，最关键的不是让Agent“聪明”，而是让Agent之间“找得到、连得上、恢复得了”。
2. Agent-Reach的设计理念：把“触达”从Agent身下拆出来
2.1 核心抽象：Reach Descriptor（触达描述符）
所有设计都围绕一个概念展开——触达描述符。它描述的是一个能力点的全部接入信息，而不是直接给出代码。一个描述符长这样：
{ "reach_id": "tool.warehouse.stock.query", "name": "查询库存", "type": "tool", "transport": "session", "version": "1.2.0", "auth": { "scope": "warehouse:read", "delegation": false }, "params": { "type": "object", "properties": { "sku": {"type": "string", "required": true}, "warehouse_id": {"type": "string"} } }, "timeout_ms": 3000, "retry": {"max_attempts": 2, "backoff": "linear"}, "fallback": "tool.warehouse.stock.query.v1" }我这里要强调几个和普通API schema不同的字段。
type表示触达目标类别，可以是tool（普通工具）、data（数据源）、agent（另一个Agent）、flow（编排流程）。不同类型走完全不同的执行路径，这在后面路由会用到。transport填session，意味着这个调用要建立在会话通道上，并不是简单的“发一次HTTP请求完事”。auth描述权限边界，它决定谁可以调用这个能力，以及在调用过程中是否允许Agent把身份令牌透传给下游。这一点我在踩坑章节会展开说，因为权限配置太宽导致的问题比想象中严重得多。
有了这个描述符以后，Agent对外部世界的所有调用，都变成“携带描述符ID和参数，等待结果”。模型侧只需要根据描述符构造JSON参数，而底层协议完全被屏蔽掉。这也是Agent-Reach能把众多异质能力统一进来的核心逻辑：一切皆触达描述符。
2.2 三层架构：Discovery、Session、Routing
Agent-Reach的实现分三层，每层职责单一。
Discovery（发现层）负责能力注册和查询。任何工具、数据源、Agent，启动时向Discovery注册自己的触达描述符，注册后对集群内其他成员可见。Discovery维护一份能力索引表，支持按reach_id精确查询和按关键字模糊搜索。设计上我刻意不让它做授权校验，只管“有没有”和“在哪里”，权限检查全部下沉到Session层。这样Discovery做例行健康检查时不会因为误判权限问题产生误报。
Session（会话层）是实际握手的通道。调用方发起触达时，先和目标的会话端点建立通道，通道内有一个上下文快照区域，存放本次任务的共享数据，包括参数片段、已调用结果、时间线记录。通道建立以后，后续多次工具调用都复用一个通道，不需要像Function Calling那样每次请求都要重新校验身份和加载知识。对Agent来说，这个通道就是“这次任务的临时工作台”。
Routing（路由层）解决“找谁”的问题。Routing根据触达描述符的type字段分派：tool类型直接匹配本机工具注册表；agent类型则在集群内查找对应Agent实例；flow类型进入编排引擎，按预置流程依次调用多个子能力。Routing内部维护一张动态路由表，表中的条目在每次调用后会根据延迟和成功率更新权重。初始状态下所有可用节点均分权重，调用了若干次以后，慢节点和故障节点自动降低权重。
这层结构的好处是，每一层都可以独立扩展。我在生产里就单独把Discovery抽出去部署过，用它管理一个跨多个服务的Agent集群，而Session和Routing保持本机逻辑，效果很好。如果你只想在单机应用里给一个Agent接几个工具，完全可以只用Session层，把Discovery和Routing都跳过。
2.3 为什么无状态会话不够，非得要通道
我要解释一下，为什么不在架构里直接用无状态调用，非要做一个“会话通道”。用一个生活里的类比，无状态调用是“写信”：你写一封信寄给对方，等他回信，再写下一封。而会话通道是“打电话”：拨通之后，对话持续的这段时间里双方共享语境，中途可以随时追问、补充、纠正，不用每次都从头自我介绍。
在Agent执行复杂任务的过程中，绝大多数时间是后者这种模式。一个Agent查完库存、然后决定查询供应商、再然后向客户端推送通知，这整个过程是连续推理链条。如果把每一步切成孤立请求，上下文就得靠系统提示词反复传递，Token开销巨大，而且一旦第一步的返回数据影响了第二步的参数结构，应用层还要自己管理中间状态。会话通道把这些状态“挂在线上”，Agent在通道内直接读取之前步骤留下的上下文快照，既不污染模型窗口，也不丢失现场。
我在设计时专门保留了“触发式快照”策略：每次工具调用结束后，Session会记录一份结构化的快照，包含调用的输入、输出、耗时和异常信息，但是不包含模型的中间推理文本。Agent在后续步骤需要前置信息时，先尝试从本地上下文快照取，取不到再回到模型窗口里读历史。这套机制跑下来，连招调用的token消耗比无状态方案平均节省了30%左右，后面实测章节会给具体数据。
3. 第一版跑通的完整链路：从注册工具到自动调用
3.1 最小可用的工具注册方式
Agent-Reach第一版最核心的用法，是把一个普通Python函数注册成触达能力。我用装饰器的方式来实现，尽量让接入代码少到极致：
from agent_reach import Reach reach = Reach("app.main") @reach.expose( reach_id="tool.warehouse.stock.query", version="1.2.0", timeout_ms=3000, auth_scope="warehouse:read", ) def query_stock(sku: str, warehouse_id: str = "default") -> list: # 这里是真正的库存查询逻辑 return db.query_stock(sku, warehouse_id)注册完以后，函数签名自动被解析成触达描述符里的params字段。我用的解析规则其实很直接：基础类型映射到JSON Schema基础类型，有默认值的参数标记为可选，带**kwargs的函数直接声明为additionalProperties: true。这样做对日常函数接入足够友好，不需要额外维护一份文档。
有个细节值得注意：auth_scope并不写在函数体内，它会跟着描述符走。一旦某个调用方没有warehouse:read这个范围标记，Session层在握手阶段就会拒绝建立通道，函数本身根本不会被触发。这样做的好处是权限校验统一在框架层，而不是散落在每个工具函数里，改造老代码时也不用往每个函数体塞权限判断。
3.2 关键API：serve、connect、invoke
Agent-Reach运行时的核心API只有三个——serve、connect、invoke。
# 服务端：启动触达服务，端口8890 reach.serve(host="127.0.0.1", port=8890)# 客户端：建立会话通道，拿到一个ReachConnection conn = reach.connect( "tool.warehouse.stock.query", timeout=2.0, context={"order_id": "SO12345"}, )# 调用 result = conn.invoke({"sku": "SKU-88234", "warehouse_id": "WH01"})connect时如果目标不可达，框架会尝试按描述符里的fallback字段寻找备用reach_id，还找不到就直接抛ReachUnavailableError。这里要说一下我为什么强调“连接和调用分离”：因为连接阶段做了权限握手和通道协商，之后的所有invoke都复用这条通道。如果你用的是无状态调用，后续每次都重新做权限验证，延迟多一笔，而且一旦权限接口短暂抖动，本来成功的调用也会被中断。连接建立后通道保持存活，在没有调用的空闲期会维持心跳，默认30秒无通信自动关闭。
invoke返回的result是一个统一结果封装，它不只是数据本身，还包括duration_ms、attempts、from_cache这几个元数据。我当时加这些字段就是为了可观测性。你可以在Agent的日志里清晰看到每次触达花了几毫秒、是第几次尝试才成功、数据来自缓存还是实时查询——这些东西排障时太重要了。
3.3 一个具体的接线例子
拿最常被用来演示的天气查询接口来说。假设外部服务是一个REST接口，你不需要自己写HTTP调用代码，而是用Agent-Reach自带的HTTP适配器：
from agent_reach.adapters import http_adapter reach.register_adapter( "tool.weather.query", http_adapter( method="GET", url_template="https://api.example.com/weather?city={city}&date={date}", headers={"X-API-Key": "..."}, result_map={"temp_c": "$.temp_c", "humidity": "$.humidity"}, ), )result_map用来把外部接口返回的JSON映射成Agent需要的字段。为什么要这层映射？因为外部API的字段格式通常和你的领域模型不一致，你不想到处写适配代码，更不想把外部字段命名直接暴露给模型。映射之后，Agent看到的是稳定的temp_c、humidity，后续即使上游API改了字段名，你也只需要改一处映射配置，对Agent完全无感。
跑通这一整套流程后，你对Agent暴露给模型的能力就有了一个干净的注册表。我在实际使用中会把注册表导出为一个JSON文件，喂给模型做参考，因为模型不需要理解内部路由协议，它只需要知道有哪些触达能力、参数名是什么、返回什么结构。模型的调用稳定性因此提高了很多——本质原因是用确定性注册表替代了Prompt里手写工具描述，模型的幻觉空间被压缩了。
3.4 为什么不一上来就用Function Calling
你可能会问：现在各家模型都支持Function Calling，直接用来注册工具不就行了，为什么还要写一套自己的？我自己试过，两种方案在Demo层面几乎没差别，但进了生产就慢慢拉开差距。
核心差异在“会话连续性”。Function Calling的每一次工具调用，本质是模型交互中的一个独立环节，模型需要看到上一次工具调用的返回值才能推进下一步。问题是，如果是一个跨步骤的编排任务，中间状态被模型文本历史占着，一万字之后模型很可能忘掉最开始的工具输出细节。Agent-Reach的会话通道把工具结果压缩成结构化快照，在某些步骤被截断或重试时，Agent可以直接从最近一次快照恢复上下文，而不是把所有历史重新算一遍。
另外，裸Function Calling在工具数量比较多的时候，工具描述占用的token会非常可观。50个工具的描述动辄几万个字符，每个请求都要带一遍。Agent-Reach可以只向模型暴露当前任务上下文相关的若干工具——通过Session上下文里的reach_hint字段做候选召回，模型窗口里只塞最相关的几个工具描述符。单次请求的token占用能砍掉六到七成。
4. 多智能体之间的可达性路由
4.1 路由表长什么样
多智能体场景和单Agent接工具的最大区别，是“能力的提供方”不再局限于本地进程。Agent-A可能需要调用Agent-B提供的“用户画像分析”能力，而这两个Agent可能部署在不同机器、用不同技术栈。路由表存在的意义就是把这层跨进程寻址变得像一个本地函数调用一样简单。
我的路由表数据结构是这样的：
router_table = { "agent.user.profile": { "instances": [ {"node": "agent-b-01", "address": "agent-b.internal:8891", "weight": 0.6, "healthy": True}, {"node": "agent-b-02", "address": "agent-b.internal:8892", "weight": 0.4, "healthy": True}, ], "strategy": "weighted_round_robin", "last_check": 1735000000, }, "flow.order.fullfill": { "instances": [ {"node": "orch-01", "address": "orchestrator.internal:8902", "weight": 1.0, "healthy": True}, ], "strategy": "single", }, }每次路由发生时，Routing层根据reach_id找到候选实例列表，按权重挑选一个目标，拉通Session通道，然后转发调用参数。响应返回后，路由层更新该实例的延迟和成功率指标。我用了滑动窗口来记录最近50次调用的成功率，一旦某个实例的失败率超过20%，它的权重会被临时降为0并进入冷却状态，冷却60秒后自动恢复探测。
这套权重机制跑了一段时间之后，效果是慢实例和故障实例会被自动绕开。我见过有些团队的方案是轮流调用，哪个挂了就在日志里记录，下次继续撞运气，这种方案在实例数量超过三个时就开始让人头疼。滑动窗口+权重降级的做法不复杂，但足够解决大部分高可用场景。
4.2 可达性探测和降级策略
路由表里实例的健康状态不是静态配置，而是靠“活跃探测”和“被动探测”两条腿走路。
活跃探测是周期性检查。默认每30秒，Routing层对所有已注册的agent端点发送一个轻量级PING。这个PING不带业务参数，只检测通道建立是否成功、耗时是多少。被动探测则发生在真实调用时：如果某次调用超时或者返回5xx，路由层会立即把该实例的最近失败时间戳记下来，作为权重调整的参考。
这里要提一个我在第一版吃过亏的地方——崩溃实例的“半探测”问题。活跃探测PING通过，不意味着真实业务调用就能成功。探测消息太轻，不会触发目标Agent的完整资源加载，有些Agent在PING时一切正常，一接收实际业务参数就OOM或者超时。后来我在PING协议里增加了一个可选参数depth，只有在目标支持的情况下，深度探测会附带一条极小规模的业务预热请求，确保能真正触发目标进程的主业务路径。虽然这会让探测成本高一点，但比起线上调用大面积超时才被动反应，值太多了。
降级策略则是另一道保险。注册触达描述符时，你可以提供一个fallback_chain，比如“先调高精度用户画像，失败后自动换成缓存版画像，再失败就把用户标记为unknown处理”。降级链在框架内部实现，Agent业务代码不需要写复杂分支。我见到很多团队把这些降级逻辑写在Agent的System Prompt里，让模型自己判断要不要降级，这是非常危险的——模型在压力下会编造一个“看似合理但实际不存在”的降级路径，比如直接从用户画像里推断一个不存在的收入数据。确定性降级链的最大价值就是不依赖模型突发奇想。
4.3 一个订单处理链路的真实例子
现在把整段逻辑串起来看一个多Agent协作的完整案例。假设有四个Agent：订单Agent、库存Agent、支付Agent、通知Agent。
用户发起“下单购买商品A，数量2”后，订单Agent作为编排入口开始工作。它先通过触达描述符agent.warehouse.check向库存Agent发起库存校验请求。路由表根据权重选中库存Agent的一个实例，Session通道建立，传入{"sku": "A", "quantity": 2}。
库存Agent确认有货后返回{"available": true, "reserved": 1001}。订单Agent拿着预留单号，继续调用agent.payment.create触达支付Agent创建支付单。支付Agent返回{"payment_sn": "PAY123", "status": "pending"}。最后订单Agent调用agent.notify.send触达通知Agent向用户发送下单成功通知。
这整个过程里，订单Agent不需要知道库存Agent用什么数据库、支付Agent在哪个机房、通知Agent走的是短信还是推送。它只面向触达描述符编程。我之前在团队里推这套方案时，最大的说服力就是：接入一个新的Agent只需要它提供一个 reach_id 和 参数说明，而不需要业务方去阅读对方的源码、数据库表结构或者内部文档。
等到这个链路运行了一段时间，我还会从路由日志里看到每个环节的耗时分布。哪一步慢了、哪一步重试率高了，数据都在，不用猜。
4.4 环形调用的检测与熔断
多智能体路由投入使用后，有一个问题是不遇到不会发现的：环形调用。Agent-A调用Agent-B，Agent-B调用Agent-C，Agent-C又调回Agent-A。如果路由层不做干预，这个调用环会一直打转，直到耗尽所有超时预算。
Agent-Reach的解法是在Session上下文里维护一个完整的调用链标记trace_path。每一次路由转发，当前节点会把自己的reach_id追加到路径末尾，目标收到后检查这个路径里是否已经包含自己的reach_id，如果包含就直接拒绝，并抛一个ReachLoopError。
后来我把这个逻辑扩展成了“环检测+熔断”两段式：环检测负责立刻终止已经发生的循环；熔断器负责防止循环源头继续请求。比如连续3次发起同一个会形成环路的调用链，路由层会对该入口做5分钟熔断，期间直接返回“编排路径不合法”。这个策略上线后，彻底消灭了因为配置错误导致的调用风暴问题。如果你也在做多智能体方案，建议第一步先把这个能力加上，否则一旦业务复杂起来，排查一次调用循环能查到让人怀疑人生。
5. 实测数据、踩坑记录和优化方向
5.1 第一轮实测表现
Agent-Reach在完成第一版后，我拿一个真实的库存查询+订单创建场景做了压测。环境是5个Agent实例分布在3台服务器上，每个Agent挂载62个触达能力，运行48小时。
数据整理如下：
| 指标 | 无状态Function Calling | Agent-Reach会话触达 |
|---|---|---|
| 单次完整链路平均耗时 | 1.8s | 1.2s |
| 3步连续触达token消耗 | 12.4k | 8.9k |
| 工具调用失败率 | 5.7% | 2.1% |
| 失败后自动恢复成功率 | 无法统计（依赖业务代码） | 71.4%（依赖重试/降级链） |
| 跨Agent调用平均建链耗时 | 无原生支持 | 38ms |
耗时下降的主要来源是会话通道复用，省掉了多次权限校验和建链开销。token消耗减少则来自触达描述符的按需加载和上下文快照——模型不需要把前几步的工具定义反复放在下一次请求里。失败率降低一部分靠重试，但更大的贡献来自路由层自动避开异常实例。
以上数据是我本地环境跑出来的，不能代表所有生产环境，但至少能说明一个问题：一个强壮的触达层设计，带来的收益不只是代码好看，而是实实在在的延迟和成本下降。
5.2 坑一：超时叠加，链路被无用重试拖垮
第一个大坑是超时配置不合理导致整条链路崩溃。我最早给每个触达能力都设了统一的3秒超时，觉得单个工具调用3秒内返回很正常。结果在链路场景里，订单Agent调用库存Agent（3秒）+ 库存Agent调用数据库（3秒） + 订单Agent再调用支付（3秒），一路叠加下来，用户感知的等待时间直接突破10秒。更糟的是，每个环节超时后还会自动重试两次，总耗时进一步拉高，最后整个会话被用户提前中断。
这个问题的根子是“超时分配”没有按照链路预算去规划，而是机械地对单次调用设值。后来我在描述符里增加了budget_ms这个链路预算字段，由编排入口分配每次调用的时间份额。比如整个链路预算是5秒，那么第一次调用最多占2秒、后续每次不超过1.5秒，总预算超过就立即熔断。这个机制上线以后，异常链路最多花5秒就快速失败，而不是傻等三个3秒再加两次重试。
给还在用裸Function Calling做任务编排的同行一个提醒：工具级超时和任务级超时一定要分开设置，否则“单个工具速度正常”会掩盖“整条链路不可用”的真相。
5.3 坑二：权限边界配得太粗，Agent能调用的比预想多
第二个坑来自权限设计。第一版我对所有工具统一用了auth_scope: *，意思是任何Agent都能调用任何能力。这在初期方便，但很快就出现了问题——某个画像Agent居然调用了支付Agent的“退款”能力。虽然当时因为是测试环境损害不大，但这个事件让我脊背发凉。
反思下来，权限必须遵循最小化原则，而且校验不该只发生在注册阶段，必须在每次握手和每次调用时都校验。Agent-Reach现在的实现是：每个触达能力声明一组允许的peer_id或scope，Session层握手时校验调用方身份和scope，若不符直接拒绝建链。更细的粒度是“首次握手校验+调用时二次校验”，防止通道建立后调用方权限被撤销的场景。
经验是：权限描述符永远比实际需要严格一档。生产环境里宁可多配置几个scope，也不要一个*管所有。因为你根本不知道什么时候一个Agent发生了一次不对的调用，那个错误可能不会当时爆出来，但一定会埋下一个数据事故的种子。
5.4 坑三：上下文快照污染，Agent开始引用过期数据
第三坑是上下文快照的“新鲜度”问题。我最初让会话通道把所有工具调用结果丢进上下文快照，Agent后续步骤可以直接读。结果是调用顺序不当的时候，Agent拿到了旧数据并把它当成了当前状态。最典型的案例：库存Agent先返回了“库存充足”，过两分钟后订单Agent想下单时，库存已经被其他订单消耗了，但会话快照里的数据不会自动刷新。
这个问题本质上是我把“缓存”和“上下文状态”这两个概念混在一起了。修正方式是在快照里为每个条目打上captured_at时间戳，并在Agent拿到快照时强制校验有效期。库存这类高频变化数据，有效期限30秒；用户昵称这类低频数据，有效期可以长达1小时。一旦快照过期，Agent必须重新触达数据源，不能用旧数据做决策。
从那以后我也养成了习惯：任何会话级的数据缓存，都要先问一个问题——“如果这个数据是5分钟前拿到的，现在直接用还安全吗？”如果答案是否定的，就让它过期。
5.5 接下来的优化方向
因为以上这些能跑通了，我开始把Agent-Reach往两个方向延伸。一个是协议适配器，目前它只内置了HTTP、SQL、gRPC三种适配器，接下来想补上消息队列和事件总线的适配，让Agent能触达更多异步后端。另一个是触达描述符自动生成，通过解析OpenAPI文档直接生成描述符文件，省去手工编写和推断字段的麻烦。这两个方向还在迭代中，后面有阶段性成果了再继续写文章分享实测过程。
最后分享两个小技巧
文章写到这里，按惯例说点纯个人体会。第一个技巧：接入Agent-Reach时，不要一股脑把几十个工具全部注册上，先从最小闭环开始——选两到三个能力跑通一个真实业务流程，验证会话通道的稳定性和路由策略，再逐步扩大能力池。规模一上来才发现架构问题，改造成本是很高的。
第二个技巧：多智能体路由的日志一定要留全链路ID，把路由表的选择过程、候选实例权重、建链耗时、调用结果全部打个结构化日志。我在排查环形调用和超时叠加问题时，就是靠这些日志一步步定位的，如果没有这个习惯，不会发现是路由权重还是超时设置出了问题。
Agent-Reach目前在我这边的Agent项目里已经稳定跑了几个月，它不解决Agent的全部问题——思考、规划、记忆仍然要依赖模型能力和应用层设计——但它把“触达”这件事做扎实了。希望对正在爬Agent应用这堵墙的你有帮助。如果你也被这类问题困扰，或者有更独特的触达场景想聊聊，随时可以在评论区一起讨论。
