Agent 如何「发现「一个新注册的工具
配图（无描述）
1️⃣ 考察意图
面试官想看你能否设计 Agent 的工具发现机制——让 Agent 动态感知新工具的注册。刁钻点在于：发现机制不只是"查询列表"，还需要考虑实时性、效率、一致性。答好了能展示你在分布式系统事件通知方面的经验。
2️⃣ 标准答
工具发现从"拉模式、推模式、混合模式、缓存"四种机制设计：
1. 拉模式（Pull）
- Agent 定期（如每 30s）向注册中心查询可用工具列表
- 优点：实现简单，Agent 主动控制查询频率
- 缺点：新工具注册后最多 30s 延迟才能被发现。频繁查询增加注册中心负载
- 适用场景：工具变更频率低、实时性要求不高的场景
2. 推模式（Push）
- 注册中心在工具注册/变更时主动通知订阅者
- 实现：(1) Webhook——注册中心调用 Agent 的 webhook URL 推送变更；(2) Server-Sent Events（SSE）——Agent 与注册中心保持长连接，变更时推送；(3) 消息队列——注册中心将变更事件发到 Kafka/Redis Pub-Sub，Agent 订阅
- 优点：实时性强（<1s 延迟），减少无效查询
- 缺点：需要维护长连接或消息队列基础设施。Agent 离线时事件丢失
3. 混合模式（Hybrid）
- 首次启动：Agent 拉取全量工具列表（Pull）
- 后续更新：通过 watch 机制接收增量变更（Push）
- 定期兜底：每 5 分钟全量拉取一次，防止丢失事件
- 这是生产环境推荐的模式——兼顾实时性和可靠性
4. 本地缓存（Local Cache）
- Agent 本地缓存工具列表（内存中），减少对注册中心的依赖
- 缓存策略：(1) TTL 5 分钟——5 分钟后缓存过期，重新拉取；(2) 事件驱动失效——收到注册中心变更通知时立即失效对应缓存项；(3) 优雅降级——注册中心不可用时使用缓存数据继续工作
- 缓存内容：工具名称、地址、Schema、能力描述。不包括实时 metrics（每次调用时从网关获取）
3️⃣ 答题模板（30 秒电梯版）
"工具发现四机制：拉模式——Agent每30s查询注册中心，简单但延迟高。推模式——注册中心变更时通过Webhook/SSE/消息队列推送，实时<1s但需基础设施。混合模式——首次全量拉取+后续watch增量+5min全量兜底，生产推荐。本地缓存——TTL5min+事件驱动失效+注册中心不可用时降级用缓存。总结一句：生产环境用混合模式——Pull全量+Push增量+Cache兜底。"
4️⃣ 高频追问 & 应对
追问 1：watch 机制的延迟和可靠性怎么样？
etcd/Consul 的 watch 机制：(1) 延迟——变更后 <100ms 通知到所有订阅者。基于 gRPC stream 或 long-polling；(2) 可靠性——watch 事件有 revision 号，Agent 重连后从上次 revision 继续，不丢失中间事件。如果 revision 差距太大（如 Agent 离线 1 小时），注册中心发送"全量同步"事件让 Agent 重新拉取；(3) 限制——单个注册中心的 watch 连接数有限（etcd 默认 10000），大规模 Agent 需要分级 watch（如 Agent → 区域代理 → 注册中心）
追问 2：Agent 发现新工具后怎么知道何时用？
两步：(1) 工具描述注入——新工具的 description 和 input_schema 注入到 Agent 的 system prompt 或 Function Calling 的 tools 参数中。LLM 据此判断何时使用；(2) 能力匹配——如果 Agent 用语义搜索选工具（而非全量传给 LLM），新工具的 description 被 embedding 并加入向量索引。下次用户请求时自动匹配。注意：新工具加入后可能影响 LLM 的工具选择——新工具的 description 与现有工具相似时可能产生混淆。建议新工具上线后监控工具选择准确率变化
追问 3：Agent 离线期间错过了多个变更事件怎么办？
同步方案：(1) Revision 对比——Agent 重连时携带上次的 revision 号，注册中心返回该 revision 之后的所有变更。etcd 原生支持此机制；(2) 全量同步——如果 revision 差距过大（如 >1000 个变更），注册中心返回"需要全量同步"标志，Agent 重新拉取完整工具列表；(3) 版本号校验——Agent 本地缓存的每个工具有版本号，重连时批量校验版本号，只更新变化的工具。减少全量同步的数据量
5️⃣ 避坑 · 常见错误答法
- ❌ "用轮询就行，简单可靠" → ✅ "轮询有延迟（新工具30s后才发现）且浪费资源（即使没有变更也查询）。生产环境用 watch+轮询兜底的混合模式。"
- ❌ "发现新工具后立即传给 LLM" → ✅ "新工具可能影响 LLM 的工具选择准确率。应该先在影子模式测试新工具的选择准确率，确认不降低现有准确率后再全量上线。"
- ❌ "Agent 缓存工具列表后就不再查询" → ✅ "缓存会过期（TTL 5min），过期后需要刷新。且注册中心变更时需要主动失效缓存。完全依赖缓存可能导致使用过期的工具地址。"
6️⃣ 简历呼应
- 如果你有服务发现项目：从"Agent 工具发现机制"切入，描述你实现的 Pull+Push+Cache 混合模式
- 如果你只做过配置中心：用"配置推送"迁移——Nacos/Apollo 的配置推送机制直接适用
- 如果你是校招无项目：用 etcd 的 watch 机制实现工具发现，测试延迟和可靠性
- "Service Discovery: Push vs Pull" (Richardson, 2023)
- "etcd Watch Mechanism" (CNCF, 2024)
- "Agent Tool Discovery" (Wang et al., 2025)