多工具分布调用如何解决
1️⃣ 考察意图
面试官想考察你对 Agent 系统中“多工具调度”的架构设计能力，而非单纯背概念。刁钻点在于：如何平衡并发效率与结果可靠性，以及处理工具间的依赖、冲突和失败。答好了能展示你对异步编程、容错模式、结果聚合的实战理解，证明你能从单体 Agent 升级到生产级多工具编排系统。
2️⃣ 标准答
多工具分布调用的核心是编排（Orchestration），而非简单并发。我分四个层面展开：
1. 工具注册与发现
- 维护一个工具注册表（Tool Registry），每个工具包含：名称、描述（用于 LLM 选择）、输入参数 Schema（JSON Schema）、输出 Schema、调用端点（HTTP/gRPC/本地函数）。
- 关键取舍：描述要精炼（<50 字），避免 LLM 因冗余描述而误选。例如“get_weather”描述为“根据城市名返回当前天气”，而非“这是一个天气查询接口，支持输入城市名称，返回温度、湿度等”。
2. 工具选择与路由
- 两种模式：
- LLM 驱动：将工具描述拼入 System Prompt，让 LLM 输出函数调用（Function Calling）。适用于工具数 < 20 的场景。
- 路由模型：用轻量分类器（如 BERT 微调）预判意图，直接映射到工具。适用于工具数 > 50 或低延迟场景。
- 实战坑：LLM 可能“幻觉”出不存在工具参数（如虚构城市名）。解法：在 Prompt 中加“参数必须来自用户输入或上下文，禁止编造”，并在调用前做 Schema 校验。
3. 并发调用与依赖管理
- 使用 asyncio（Python）或 CompletableFuture（Java）实现并发。典型模式：
- 扇出（Fan-out）：无依赖的工具同时调用，如查天气 + 查航班。
- 链式（Chain）：有依赖的工具串行，如先查航班 ID，再查座位图。
- 工程取舍：并发数不是越高越好。设 Semaphore 限制并发数（如 5-10），防止下游 API 限流或 OOM。实际落地中，某次调用 20 个工具时，未限流导致 API 返回 429，改用 Semaphore 后成功率从 60% 升至 95%。
4. 结果聚合与错误处理
- 聚合策略：
- 合并：同类型结果（如多个天气源）取置信度最高或最新。
- 拼接：不同类型结果（如天气 + 酒店）直接拼接成结构化 JSON。
- 错误处理：
- 超时：每个工具设独立超时（如 3s），超时后返回“服务不可用”。
- 熔断：连续失败 3 次，标记工具为“降级”，后续请求跳过。
- 部分成功：不因一个工具失败而终止整个流程。例如航班 API 挂了，仍返回天气和酒店结果，并在回复中注明“航班信息暂缺”。
5. 实际落地的坑 + 解法
- 坑：工具返回数据格式不一致（如日期格式“2024-01-01” vs “01/01/2024”）。解法：在工具注册表中定义输出 Schema，并在聚合层加标准化转换器。
- 坑：LLM 在结果聚合时“遗忘”部分工具输出。解法：将聚合逻辑从 LLM 中剥离，用代码硬编码合并规则，只让 LLM 做最终的自然语言润色。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从工具注册、并发调度、结果聚合三个层面回答。工具注册层用 Schema 标准化描述，避免 LLM 误选；并发调度层用 asyncio + Semaphore 控制并发数，并处理依赖链；结果聚合层用代码硬编码合并规则，只让 LLM 做润色。总结一句：多工具调用的核心是编排，用异步并发提效，用容错模式保稳。”
4️⃣ 高频追问 & 应对
追问 1：如果两个工具返回冲突结果（如天气 A 说晴天，天气 B 说下雨），怎么处理？
采用投票 + 置信度机制。每个工具注册时附带置信度权重（如官方气象局 0.8，第三方 0.5）。冲突时，取加权平均或最高置信度结果。若置信度接近（差值 < 0.1），则返回“多个来源结果不一致，建议用户自行确认”。实战中，还可以引入第三个工具做仲裁（如查雷达图）。
追问 2：工具数量从 10 个扩展到 1000 个，架构怎么调整？
核心瓶颈在 LLM 的上下文窗口。解法：1）用分层路由：先分类（如“天气类”“交通类”），再在类内选具体工具。2）用向量检索：将工具描述嵌入向量库，用户意图向量化后召回 Top-5 工具，而非全量输入。3）用动态注册：工具按热度缓存，冷门工具从数据库懒加载。实测 1000 工具时，向量检索召回 Top-5 的延迟 < 50ms。
追问 3：如何保证工具调用的幂等性？
每个工具调用生成唯一 Request ID，下游 API 支持去重。对于非幂等操作（如“下单”），在调用前加预检查（如查订单是否已存在），并设置重试次数上限（如 3 次），重试间隔指数退避（1s, 2s, 4s）。若仍失败，记录到死信队列，人工介入。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“用 asyncio.gather 并发调用所有工具，然后等所有结果返回再聚合” → ✅ 正确做法：区分依赖关系，无依赖的扇出，有依赖的链式，并设超时防止死等。
- ❌ 说“让 LLM 自己决定调用顺序和聚合逻辑” → ✅ 正确做法：LLM 只负责选工具和解析参数，调用顺序和聚合用代码硬编码，避免 LLM 幻觉和上下文溢出。
- ❌ 说“所有工具失败都重试 3 次” → ✅ 正确做法：区分错误类型——网络超时重试，参数错误不重试（直接报错），业务错误（如“航班已满”）不重试。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“多工具调用类似多路召回”切入，强调并发检索和结果融合的相似性，并补充你如何用 asyncio 优化了检索延迟。
- 如果你只做过传统 NLP：用“微服务编排”类比，说明工具调用就像服务间 RPC，你熟悉超时、熔断、限流等模式，只是换成了 LLM 做路由。
- 如果你是校招无项目：聚焦论文复现——引用 Toolformer 或 Gorilla 论文，说明你理解工具注册和函数调用的原理，并写过一个 demo 用 asyncio 并发调用天气和新闻 API。
- Toolformer: Language Models Can Teach Themselves to Use Tools
- Gorilla: Large Language Model Connected with Massive APIs
- 论文：ReAct: Synergizing Reasoning and Acting in Language Models
- 博客：OpenAI Function Calling 官方文档与最佳实践
- 工具：LangChain Tool 模块源码分析（asyncio 并发实现）