企业官网建设流程全解析

最近在搞 Agent 项目的时候，我又踩到了那个熟悉的坑：Agent 本身跑得好好的，但让它去调用另一个 Agent，或者让一堆 Agent 协同干活，链路就频繁超时、找不到服务、重试风暴。说白了，单个 Agent 越来越聪明，但 Agent 之间怎么“够得着”对方，反而成了最大的瓶颈。这个被我叫做Agent-Reach的东西，就是专门解决“触达”问题的。

Agent-Reach 可以简单理解成一套面向智能体的“可达性触达框架”。它不关心 Agent 内部怎么推理、怎么规划，只管一件事：当 Agent A 需要调用 Agent B 时，怎么快、怎么稳、怎么不出错地找到 B，并且把结果送回来。它包含了服务注册与发现、动态路由、超时控制、优先级调度、降级熔断等一系列机制。这篇文章里，我想把这个框架从设计思路到落地实现，再到生产环境里的坑，完整地拆一遍。如果你正在做多 Agent 系统、Agent 平台基建，或者被 Agent 之间的通信问题折腾得头疼，这篇内容应该能给你一些可以直接用的思路。

1. 为什么需要 Agent-Reach：Agent 互通的最后一公里

1.1 从 Agent 爆发到触达困境

这两年 Agent 的热度不用我多说，从开源社区的 AutoGPT 到各家大厂推出的 Agent 平台，大家都在往“多 Agent 协作”的方向冲。但一个现实的问题是：Demo 里跑通单 Agent 很容易，一旦上了复杂度，让十几个 Agent 互相配合，问题就全出来了。

我自己做过一个挺有意思的对比实验。单 Agent 跑一个“查天气并订机票”的任务，P95 延迟在 3 秒左右，表现很稳定。但同样的任务拆成三个 Agent（天气 Agent、航班 Agent、订单 Agent）协作执行，P95 延迟直接飙到 15 秒以上，成功率从 99.5% 掉到 92%。多出来的时间基本全花在 Agent 之间的互相查找、超时等待和重试上，而不是真正干活的时间。

这背后的原因其实不复杂。单体架构里模块之间是进程内调用，快且稳定；分布式单体里是 RPC 调用，也有现成的服务发现和负载均衡方案。但 Agent 之间有一个本质区别：Agent 的调用关系不是写死在代码里的，而是根据用户的输入动态决定的。今天用户说“帮我订机票”，可能只用到航班 Agent；明天用户说“帮我安排一趟完整的差旅行程”，就可能需要航班、酒店、日历、天气、报销五个 Agent 协作。这种不确定性意味着调用拓扑是运行时才生成的，你没法像传统微服务那样预先定义好 API 网关的转发规则。

另一个让人头疼的点是 Agent 的“能力描述”非常复杂。传统微服务的接口是 POST /order、GET /user 这种明确的契约，但 Agent 对外暴露是自然语言。比如天气 Agent 暴露的能力是“查询全球任意城市的实时天气、未来 7 天预报、空气质量指数”，这种能力边界很难用简单的 URL 来表达。Agent-Reach 要解决的第一件事，就是怎么把这种“语义化能力”变成可注册、可发现、可路由的东西。

1.2 Agent-Reach 解决的核心问题清单

我把 Agent-Reach 需要解决的问题列了一个清单，开发的时候对照着做，基本不会跑偏：

服务注册与语义发现。Agent 启动时向注册中心上报自己的能力描述、运行状态、负载情况、支持的调用方式。其他 Agent 发起触达时，不是找“某个具体服务”，而是找“具备某类能力的服务”。

动态路由与智能选择。当一个能力有多个 Agent 都能提供时，Agent-Reach 需要根据语义匹配度、当前负载、历史成功率、响应延迟、地理位置等条件做路由选择，而不是简单的随机负载均衡。

异步触达与状态追踪。Agent 之间的一个任务往往执行时间很长，比如“调研新能源市场并生成一份 20 页报告”可能需要几分钟甚至更久。调用方不可能一直挂着连接等响应，Agent-Reach 需要支持异步任务提交、状态查询、结果回调。

超时、重试与降级。Agent 不是稳定的服务，它会因为大模型推理耗时、外部 API 限流、上下文过长等原因变慢甚至出错。Agent-Reach 需要有一套完整的超时控制、重试策略和降级方案。

安全与权限边界。Agent 之间可以互相调用，但权限必须收敛。不是所有 Agent 都能调用所有能力，Agent-Reach 需要在触达链路里内置身份认证和权限校验。

这套问题清单看着像传统微服务治理，但实际落地时你会发现每个点都有“Agent 味儿”——语义匹配、长任务追踪、大模型不稳定性兜底，这些在传统框架里面没有现成答案。

1.3 Agent-Reach 与常见方案的差异

你可能想问：这玩意儿和消息队列、API 网关、RPC 框架有什么区别？我一开始也有这个疑惑，直接用了手头的 RabbitMQ + Kong API 网关来接 Agent，结果碰了一鼻子灰。

消息队列擅长的是解耦和削峰，但它不解决问题。生产者把消息丢进队列，消费者从队列里取，但如果消费者不存在、能力变了、或者处理不了这条任务，消息队列什么都不会做。你依然要自己写“查一下消费端在不在、能力匹不匹配、处理失败了怎么办”这一堆逻辑。

API 网关擅长的是什么？是协议转发、鉴权、限流。但它假设你已经知道了后端的服务地址和接口路径，只是做一个转发代理。Agent 场景下，调用方往往只知道“我要一个能查天气的能力”，不知道具体是哪个 Agent、路径是什么、参数怎么传。网关在这层就傻眼了。

RPC 框架（比如 gRPC、Dubbo）解决了服务发现和调用治理，但它的服务发现是基于服务名的，接口契约是 IDL 定义的，参数是结构化数据。Agent 的能力是语义化的，输入输出可能是自然语言，或者自然语言和结构化数据的混合体。

所以 Agent-Reach 不是要替代这些东西，而是站在这些基础设施之上，把“语义化的能力触达”这个层补上。传统基础设施解决的是“怎么把请求送到达”，Agent-Reach 解决的是“请求该送到哪儿、怎么判断送达了、送不到怎么办”。

2. Agent-Reach 的核心机制拆解

2.1 可达性判定：如何知道一个 Agent 是否“够得着”

Agent-Reach 的名字里带一个 Reach，也就是可达性。这个指标是整个框架的基石。什么才算“可达”？不是简单的“Ping 得通”，而是一个组合判断。

我把可达性拆成了四个维度：协议可达、服务存活、能力匹配、状态健康。

协议可达是这个 Agent 监听的端口有没有开放、传输层通不通。这是最基础的一层，也是最容易判断的。服务存活是 Agent 进程是否在运行、心跳是否正常上报。能力匹配是有没有 Agent 声明了调用方需要的那个能力。状态健康是 Agent 当前有没有过载、有没有在重试中、有没有进入降级模式。

光这四层还不够，Agent-Reach 里我加了一个“动态可达性评分”。每个 Agent 实例会实时计算一个 0 到 1 的分数，比如历史请求成功率 95%、当前请求队列水位 60%、平均响应时间 350ms，综合算下来得分是 0.83。调用方发起触达时，Agent-Reach 会优先选择评分高的实例，而不是所有活着的实例平均分摊流量。

这个设计思路是学自 Dapper 和 Hystrix 的混合体。Dapper 让我意识到“链路数据是最有价值的监控数据”，Hystrix 让我意识到“不健康的实例要被快速隔离”。Agent-Reach 把这两件事前置了——不等到调用失败才摘除节点，而是在路由阶段就通过评分把风险规避掉。

具体实现上，评分是一个加权滑动窗口的 EWMA 值。每完成一次请求，就以“成功得正分、失败得零分”的方式更新窗口，同时考虑请求耗时和超时次数。权重我调过很多轮，目前线上比较稳的设置是：成功率高权重 0.5、耗时低权重 0.3、稳定性（超时率、重试率）权重 0.2。这不是什么官方标准，是我根据实际观测调出来的经验值。

2.2 动态路由：把“语义请求”变成“准确触达”

语义路由是整个 Agent-Reach 里最有意思、也最容易翻车的部分。调用方发过来的不是“调用 HTTP API”，而是“我想知道北京明天的空气质量如何”，Agent-Reach 需要把这个诉求匹配到正确的 Agent 上。

我用的方案是三层匹配，逐层收敛：

第一层是标签索引。每个 Agent 在注册时除了自然语言描述，还会提供结构化标签，比如能力类型是 “weather.query”，领域是 “meteorology”，地域范围是 “global”。调用方的请求经过意图识别后，先做一个粗粒度的标签匹配，把候选集从几百个缩到几十个。

第二层是语义向量的相似度计算。对每个 Agent 的能力向量和当前请求的向量做余弦相似度计算，阈值设为 0.78 以上才算匹配。这里的向量来自把 Agent 能力描述文本和请求文本同时塞进 embedding 模型的结果。

第三层是可达性评分排序。对第一层和第二层过滤出来的候选 Agent 集合，用上一节提到的可达性评分做排序，把当前最健康的 Agent 排在最前面。

这三层配合下来，准确率能到 96%。但我要提醒的是，这个方案有一个明显代价：每一层都可能误杀。标签打错了，向量相似度算歪了，评分排序排偏了，结果就是找不到可用的 Agent。所以我还有一个兜底逻辑：如果三层匹配的结果为空，就退回全量扫描，把请求文本直接和所有 Agent 的能力描述做一次暴力语义匹配。这个逻辑很傻，但在关键时刻真的能救命，尤其是新 Agent 刚上线还没打好标签的时候。

向量匹配的细节也踩过不少坑。选用 embedding 模型的时候，我对比过多种开源 embedding 模型的效果，最后选了 3 个高频次分词表更匹配中文场景的方案。这里没有绝对的最优，关键是要在你的真实数据上评测。我自己搭了一个小的评测集，里面放了 300 条真实用户请求和对应的正确 Agent，每次换模型就全量跑一遍，准确率低于 0.95 就直接否掉。

2.3 触达策略：同步、异步、优先级与超时

确定好把请求送到哪个 Agent 之后，下一个问题是怎么送。Agent-Reach 支持四种触达模式，场景不同选择不同。

同步触达适合快速问答类 Agent，比如“把这段英文翻译成中文”。调用方发起请求后同步等待 Agent 响应，整体超时控制在 5 秒以内。这种模式的实现最直接，但调用方要承担 Agent 慢响应导致的不确定性。

异步触达适合长耗时任务，比如“帮我读完这份 PDF 并总结要点”。调用方提交任务后立刻拿到一个任务 ID，然后轮询或者通过 Webhook 接收结果。这是 Agent 场景里用得最多、也最符合实际的模式。毕竟大模型跑一个长上下文任务，动不动就几十秒，同步等待纯粹是浪费线程。

批量扇出适合一次调用多个同质 Agent，比如“找三个不同的 Agent 分别点评这份方案，取平均分”。Agent-Reach 会把请求扇出给多个候选 Agent，配置等待策略（全部返回、多数返回、最快返回），然后把结果合并后回给调用方。

优先级抢占适合紧急任务。我做了四档优先级，P0 是系统告警处理类，P1 是用户实时交互类，P2 是后台任务类，P3 是离线批量类。高优先级请求可以插入到 Agent 的待处理队列头部，低优先级请求在 Agent 繁忙的时候可以被延迟甚至丢弃。这个机制有点像操作系统的进程调度，但在 Agent 场景里很实用，不然一个离线数据清洗任务可能会堵死所有在线请求。

超时的设置我走过一段弯路。最开始图省事，把所有请求统一设成 30 秒超时，结果在线翻译类任务超时率飙升，离线总结类任务又老是被误杀。后来改成根据 Agent 注册时的“预估处理时长”动态计算超时，公式是预估时长 × 1.5 + 3秒。比如 Agent 注册时声称处理时长 8 秒，那这个请求的超时就是 8×1.5+3=15 秒。这个公式在线上跑了很长时间，误杀率下降了大部分，整体稳定性改善明显。

3. 实操落地：从零把 Agent-Reach 跑起来

3.1 最小架构部署：三个组件缺一不可

Agent-Reach 的落地部署不像想象中那么重，最少只要三个组件就能跑起来。这套组合我在测试环境验证过很多次，新项目起步完全够用。

第一个是Reach Registry（注册中心）。它负责收集所有 Agent 实例的上线信息、心跳状态、能力标签、评分数据。存储层我用的是 Etcd，因为当时团队里已经有现成的 Etcd 集群，而且它的 Watch 机制非常适合做服务变更的实时推送。如果你从零开始，Redis 也能凑合，但注意 Redis 的发布订阅做动态推送在频繁变更时容易丢消息。

第二个是Reach Client（客户端 SDK）。它嵌入到每个 Agent 进程内部，负责三件事：启动时向 Registry 注册自身能力；感知自身健康状态并上报评分；提供触达远端 Agent 的 API。语言层面我优先支持了 Python 和 Go，因为团队内部这两类服务占比最高。其他语言也可以通过 HTTP API 接入，但不会享受 SDK 里的本地缓存和连接池优化。

第三个是Reach Gateway（触达网关）。它是所有跨网络触达请求的统一入口，负责鉴权、路由转发、超时控制、结果回传。为什么需要网关而不是让 Agent 之间点对点直连？因为点对点直连会让鉴权逻辑散落到每个 Agent 里，维护成本很高，而且也没法做统一的流量观测。网关集中处理，问题要好定位得多。

这三个组件在测试环境跑起来，我建议从 Docker Compose 起步。一个简单的编排文件包含 1 个 Etcd 节点、1 个 Reach Gateway、2 个模拟 Agent（一个天气 Agent、一个计算器 Agent），一行命令就能拉起来，适合先跑通流程再上生产。

3.2 核心配置与参数，怎么定不靠猜

配置参数是整个系统最容易出问题的地方，因为每个参数都互相影响。我整理了一份我线上实际使用的配置清单，附带调整思路，你可以直接拿去当参考起点，但一定要根据自己数据调整。

注册心跳间隔：我设的是 5 秒，最大允许离线时间 15 秒。如果 Agent 超过 15 秒没上报心跳，注册中心就把它的可达性评分清零并摘出路由池。这个参数不要设太短，否则网络抖动会导致大量误摘除；也不要太长，否则故障感知滞后。

语义匹配阈值：余弦相似度阈值我设为 0.78。调低到 0.7 会让召回率上升但误匹配也明显增加，调高到 0.85 则有些新注册的 Agent 永远匹配不到。0.78 是在我自己评测集上试出来的均衡点，建议你也搭一个评测集，用真实请求验证。

同步触达默认超时：5 秒。异步触达不设固定超时，而是按 Agent 注册时的预估处理时长动态计算。动态超时的公式上面提过，这里再强调一次：预估时长 × 1.5 + 3秒，偏保守但不容易误杀。

重试最大次数：同步触达 2 次，异步触达 1 次。为什么异步触达反而少？因为异步任务本身就是长时运行，重试一次的成本可能是一分钟以上，重试两次如果还失败，大概率不是运气问题而是 Agent 本身出问题了。重试时的退避策略是指数退避 + 随机抖动，第一次重试间隔 1 秒，第二次 2 秒，加上随机 ±200ms，防止重试风暴。

路由候选集大小：默认 Top 5。也就是只在 5 个候选 Agent 里做评分排序，而不是全量实例。这个数字兼顾了路由效果和计算开销，候选集再大收益并不明显，反而拉高每次触达的决策耗时。

3.3 关键代码实现：注册、发现、触达三个动作

代码示例我尽量精简到只保留核心逻辑，但都是可以直接改改用进生产的样子。下面的示例是基于 Python 的 Reach Client，为了展示核心流程我用的是简化版。

注册动作发生在 Agent 启动时。核心是构造一个包含能力描述、标签、预估处理时长的注册数据，然后 POST 到注册中心：

import requests def register_agent(registry_url, agent_id, agent_desc, tags, estimate_latency_ms): payload = { "agent_id": agent_id, "agent_desc": agent_desc, "tags": tags, "estimate_latency_ms": estimate_latency_ms, "status": "ACTIVE", "endpoint": f"http://{agent_id}:8000/reach" } # 注册后约定按时发送心跳，比如每5秒调用 /heartbeat 接口 resp = requests.post(f"{registry_url}/v1/agents/register", json=payload, timeout=3) if resp.status_code == 200: print(f"[Reach] agent {agent_id} registered") else: print(f"[Reach] registration failed: {resp.text}") # 注册失败需要退出吗？我的建议是不退出，转成退化模式 # 用本地静态配置顶上，不能因为注册中心故障就杀掉 Agent 进程

import requests def reach_sync(gateway_url, user_query, request_id): # 触达一个语义能力，而不是一个服务地址 payload = { "request_id": request_id, "query": user_query, "mode": "sync", "timeout_ms": 5000 } resp = requests.post(f"{gateway_url}/v1/reach", json=payload, timeout=6) return resp.json()

调用方只需要提供语义请求和 request_id，剩下的路由全部交给网关。这里有一个设计细节：调用方不直接指定 Agent ID。我第一次设计的时候图省事支持了直接指定 Agent ID，结果使用者迅速在业务代码里写死了对某个 Agent 的依赖，换版本或者做灰度的时候痛苦不堪。后来我强制所有生产调用走语义触达，这才真正体现出了 Agent-Reach 的“动态路由”价值。

import asyncio async def submit_async_task(gateway_url, user_query, request_id, callback_url): payload = { "request_id": request_id, "query": user_query, "mode": "async", "callback_url": callback_url, "priority": 1 } async with aiohttp.ClientSession() as session: async with session.post(f"{gateway_url}/v1/reach", json=payload) as resp: result = await resp.json() # 返回任务 ID，调用方可以轮询 /v1/tasks/{task_id} 查状态 return result["task_id"]

异步模式里callback_url是任务完成后的回调地址。这个比我最初用的“只轮询不回调”要优雅得多。建议在所有生产环境启用回调，否则调用方要维护大量轮询线程，浪费资源，还会因为轮询间隔设不好而增加延迟。

3.4 端到端联调：一个 Agent 触达的完整现场

下面我用一个实际场景把整个链路串一遍。假设我们现在有两个 Agent 服务：

• weather-agent：提供天气查询能力，标签是["weather", "query", "global"]，预估处理时长 800ms，端口 8001
• calc-agent：提供加减乘除计算能力，标签是["calculator", "query"]，预估处理时长 200ms，端口 8002

一个用户请求进来：“北京明天会下雨吗？”

第一步，调用方通过 Reach Client 发送语义触达请求，query 是 “北京明天会下雨吗”。网关接到请求后先做意图识别和标签匹配，发现带weather标签的候选 Agent 有 3 个（包括天气 Agent 本身）。

第二步，对 3 个候选的计算语义向量相似度，其中天气 Agent 的相似度最高，0.92，其余两个均低于阈值。再对天气 Agent 做可达性评分，当前实例心跳正常、历史成功率 99%、负载 30%，综合评分 0.95。

第三步，网关把请求转发给天气 Agent。请求内容是{"query": "北京明天会下雨吗"}，天气 Agent 内部调用天气 API 和大模型回答生成，返回{"answer": "明天北京为多云转晴，降水概率10%，不大可能下雨"}，全程耗时 720ms。

第四步，网关记录这轮触达的耗时、成功率、Token 消耗，把结果返回给调用方，整个过程用户感知不到背后有一个“路由决策”发生了。

这个联调看起来很简单，但它覆盖了语义注册、动态匹配、评分路由、请求转发、结果回传五个核心环节。任何一环出了问题，整个流程都会断掉。把这个链路用日志和指标完整记录下来，是后续排查问题的基础。

4. 生产环境中的常见问题与排查技巧

4.1 高频问题速查表

运行 Agent-Reach 小半年时间，我把团队在生产环境踩过的坑整理成了一张速查表，遇到问题优先对照查一遍：

这六类问题占了我们线上故障的七成以上，剩下的基本都是基础设施层面的网络抖动或大模型 API 响应异常。

4.2 三个高频坑的深挖

第一个坑是Agent 描述文本写得太“像人话”。刚开始我要求团队成员用自然语言描述 Agent 能力，比如“本 Agent 负责查询天气和天气预报信息，包括当前温度、湿度、风向等”。听起来没问题，但 embedding 之后它和“今天要不要带伞”这类请求的匹配度只有 0.71，达不到 0.78 的阈值。后来我把描述改成混合式：开头是一段自然语言，末尾加一长串明确标签，比如 “query_type=weather, operation=check, scope=city”。标签对向量匹配有帮助，测试后相似度提升到 0.85。如果你也遇到“明明描述清楚了但匹配不上”的问题，试着加一段密集的术语标签。

第二个坑是异步任务丢失回调。异步触达升级到生产后，出现了一个奇怪的 bug：任务实际执行成功了，但调用方永远收不到回调。查到最后发现是网关的回调发送环节没有做持久化，网关进程重启后未发送的回调直接丢了。修复方案是给待发送回调做一个本地持久化队列，发送失败后自动重试，直到调用方确认收到。这件事让我养成了一个习惯：所有关键消息至少落一次本地盘，不能只靠内存转发。

第三个坑是评分窗口太短导致流量倾斜。我第一次实现评分统计窗口是 60 秒，很快发现某个 Agent 在 60 秒内出现几次超时，评分骤降，然后所有流量都会涌向另一个 Agent，导致另一个 Agent 过载，评分也骤降，流量再反灌回来。这是典型的“抖动放大”。后来把评分窗口拉长到 5 分钟，并且给评分变化加了“惯性”，单次异常最多拉低 0.05 分，不会因为一次故障就把节点摘除。抖动的问题解决了，故障快速隔离的能力也保留了，因为持续故障会持续压低分数。

4.3 性能优化与容量规划

Agent-Reach 本身不是重组件，但如果设计不当也会有性能问题。我线上运营的网关实例是 4 核 8G 的容器，单实例峰值 TPS 在 800 左右，路由决策本身耗时中位数 3ms，P99 是 15ms。这个数据是经过一轮优化后的结果，刚开始完全没有这么乐观。

第一版网关的 embedding 计算是在请求路径里同步做的，一次语义匹配要 30~50ms，几股流量一冲，路由耗时直接飙升。优化方案是给每个 Agent 预先算好能力向量，缓存到内存里，请求来时只算请求文本的向量，然后做矩阵点乘。加上结果缓存，命中缓存的请求路由耗时降到 1ms 以内。

容量规划这块，我的建议是按 Agent 数量而不是请求量来规划资源。模型是：注册中心的内存占用约等于全量 Agent 元数据的 2~3 倍，网关的 CPU 开销约等于每秒触达请求数 × 0.1 核。举个具体的例子，1000 个 Agent、每秒 500 次触达的场景，网关配 8 核、注册中心配 4G 内存已经绰绰有余。真正吃资源的大头实际上是 Agent 本身，尤其是接了大模型推理的 Agent，一个实例就要好几 G 内存。

另一个容易忽视的指标是注册中心的 Watch 连接数。每个 Agent 客户端会和注册中心保持一个长连接来接收变更推送，1000 个 Agent 就是 1000 个长连接。Etcd 默认对单个连接有 4MB 流控限制，1000 个连接虽然不至于爆，但建议把--max-request-bytes和连接相关的参数提前调大，别等服务量上来之后才手忙脚乱。

4.4 监控与观测：能清楚看到每一跳，才谈得上排查

排查 Agent 触达问题，最痛苦的是链路太长：调用方 → 网关 → 语义路由 → Agent → 大模型 → 外部 API，任何一环出问题都可能导致最终结果异常。所以 Agent-Reach 在设计时就把全链路追踪作为一等公民。

每个触达请求从进入网关开始，就分配一个全局 Trace ID，并把这个 ID 透传到所有下游环节。日志格式统一为trace_id | span_id | 服务名 | 动作 | 耗时 | 状态码 | 附加信息。排查时只需要拿 Trace ID 一把梭，从日志系统里把所有相关日志拉出来，按时间线排好，问题出在哪个环节一目了然。

指标监控方面，重点指标有这么几个：路由决策耗时、语义匹配成功率、按 Agent 维度的请求量和错误率、异步任务完成率和平均排队时间、网关和注册中心的内存与 CPU。这些指标我全部接入 Prometheus，配合 Grafana 做看板。每次发版前先把看板截图留底，发完再截一张对比，任何异常的数据波动都能第一时间暴露。

回滚策略也值得一提。Agent-Reach 的配置全部支持热更新，调整阈值、开关、路由权重都不需要重启进程。生产环境如果踩到问题，先临时调参止血，再慢慢排查根因。比如语义匹配阈值一度调成了 0.8 导致大量新 Agent 匹配不上，我看监控发现匹配成功率掉到 70% 后，第一件做的事就是通过配置中心把阈值改回 0.78，直接恢复了服务，然后再回头分析为什么阈值会漂移。

写到这里，Agent-Reach 从设计思路到生产实践这部分已经都覆盖到了。最后说一点个人体会：很多做 Agent 的团队一开始都不重视触达这层基建，觉得“不就是互相调用一下嘛”，结果一上规模就到处救火。我自己也经历过那个阶段，所以特别建议在 Agent 数量超过 10 个、或者开始搞多 Agent 协作的时候，就把这层基础设施规划起来。真出问题的时候再补，代价高得多。另外提一个实用的小技巧：Agent 的能力描述文本建议至少包含一段“密集术语”的标签式描述，这对语义匹配的准确性帮助非常大，也是我在实践中试过性价比最高的优化手段。如果后续有精力，我还会把 Agent-Reach 里的“能力协商”机制写一篇——Agent 触达之前先交换元数据、确认输入输出格式，那个部分也很有意思。