Tool adapter 解决工具返回信息不完整问题

P1 · tool_calling · 🏢 腾讯

1️⃣ 考察意图

面试官想考察你对工具调用（tool calling）中非理想返回的工程处理能力，而非单纯背诵API调用流程。刁钻点在于：工具返回不完整（字段缺失、格式错误、超时截断）是生产环境高频问题，但多数候选人只关注“调用成功”的理想路径。答好了能展示：① 对LLM与外部系统交互脆弱性的深刻理解；② 系统设计中的防御性编程思维；③ 对adapter模式在AI Agent中落地的具体经验。属于系统设计+工程取舍混合型题目。

2️⃣ 标准答

核心问题：工具返回信息不完整，导致LLM推理时产生幻觉或决策失败。例如天气API返回了温度但缺少风速字段，LLM可能编造一个风速值。

解法：Tool Adapter 三层防御架构

Schema 校验层（Schema Validator）

使用 JSON Schema 或 Pydantic 对工具返回做严格校验，定义每个字段的 required、type、enum 约束。
坑：LLM 可能返回 null 而非缺失字段，需区分“字段存在但值为null”和“字段完全缺失”。
解法：统一将 null 视为缺失，触发 fallback。

缺失字段补全层（Field Completer）

策略 A：默认值注入——对已知枚举字段（如 status: "success" | "failed"），缺失时填 "unknown"。
策略 B：上下文推断——利用对话历史或工具调用链中的其他字段做轻量推理。例如用户问“北京天气”，工具返回缺少城市名，可从用户query中提取 "北京" 补入。
策略 C：二次调用——对关键字段（如股票价格），发起一个更轻量的子工具调用（如 get_price_fallback）获取缺失数据。注意：需设置最大重试次数（通常1-2次），避免无限循环。

语义降级层（Semantic Degrader）

当补全仍失败时，不硬塞错误数据，而是主动告知LLM信息不完整，让LLM做“带约束的推理”。
实现：在工具返回的 content 中插入特殊标记，如 [FIELD_MISSING: wind_speed]，并在system prompt中定义规则：“遇到 [FIELD_MISSING] 标记时，回答中必须声明‘该数据暂不可用’，不得编造。”
Trade-off：降级会降低回答完整性，但避免了幻觉。在金融/医疗场景，宁可说“不知道”也不能说“错误”。

实际落地的坑 + 解法

坑：工具返回超时（如第三方API 5秒无响应），导致整个Agent卡死。
解法：给每个工具调用设置硬超时（如3秒），超时后adapter直接返回 {"error": "timeout", "fields": {}}，触发降级层。同时用异步预加载——在LLM思考时并行发起工具调用，减少等待时间。
坑：补全逻辑本身引入错误（如从上下文提取的城市名是错的）。
解法：补全结果必须经过置信度阈值（如 < 0.7 则降级），且所有补全字段在最终返回中标记 [COMPLETED] 前缀，让LLM知道这是推断值。

为什么用Adapter而非直接改工具：工具可能是第三方不可控的（如Google Maps API），Adapter作为中间层，不侵入工具代码，可独立升级和A/B测试。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面解决：第一层是Schema校验，用JSON Schema或Pydantic严格检查字段完整性，区分null和缺失；第二层是缺失补全，按优先级用默认值、上下文推断、二次调用三种策略，但补全结果必须标记置信度；第三层是语义降级，当补全失败时主动告知LLM信息不完整，避免幻觉。总结一句：Tool Adapter的核心不是‘补数据’，而是‘在不确定时优雅地承认不确定’。”

4️⃣ 高频追问 & 应对

追问 1：如果工具返回的是部分正确但格式混乱（如JSON嵌套层级错误），怎么处理？

先用 json.loads() 尝试解析，失败后用正则或 demjson3 做模糊解析。如果仍失败，进入降级层。关键：不要试图修复所有格式错误——修复逻辑本身可能引入新错误。设置一个“格式修复成功率”监控指标，如果超过10%的工具返回格式错误，应优先联系工具提供方修复，而非依赖adapter。

追问 2：补全层用LLM做上下文推断，会不会太慢或太贵？

会。所以只在“关键字段缺失且默认值不可用”时才触发LLM补全，且用轻量模型（如GPT-4o-mini或本地7B模型）。更经济的做法是：对高频缺失字段预训练一个小分类器（如基于BERT的字段预测器），推理成本可降低90%以上。Trade-off是维护成本增加，适合字段模式稳定的场景。

追问 3：怎么测试Tool Adapter的鲁棒性？

用混沌工程思路：构造一个“工具返回变异器”，随机删除字段、改类型、加延迟，然后跑自动化测试用例，检查LLM输出是否仍符合预期（如不产生幻觉）。指标包括：① 字段补全成功率；② 降级触发后LLM回答的“诚实率”（是否明确说数据不可用）；③ 端到端延迟P99。

5️⃣ 避坑 · 常见错误答法

❌ “让LLM自己处理不完整数据，它很聪明能推断出来” → ✅ “LLM会自信地编造缺失数据（幻觉），必须用adapter做显式约束，不能依赖LLM的‘自觉’。”
❌ “把所有缺失字段都补上默认值，比如温度填0度” → ✅ “默认值必须语义合理（如‘未知’），且补全字段要标记来源，否则LLM会误以为0度是真实数据，导致后续决策错误。”
❌ “只关注JSON格式校验，忽略超时和空返回” → ✅ “生产环境中超时和空返回比格式错误更常见，必须设置硬超时和空值处理策略。”

6️⃣ 简历呼应

如果你有RAG项目：从“检索结果不完整”类比切入——RAG中chunk缺失字段（如日期）的处理逻辑可直接迁移到tool adapter的补全层，强调“信息完整性校验”的通用性。
如果你只做过传统NLP：用“NER中的OOV处理”类比——工具返回缺失字段类似NER遇到未登录词，都需要fallback策略（如字符级特征），展示你理解“不完整输入”的通用解法。
如果你是校招无项目：聚焦“论文复现”——引用Toolformer或Gorilla论文中关于工具返回处理的章节，说明你读过前沿工作，并自己写过一个小demo（如用FastAPI实现adapter中间件）。
Toolformer: Language Models Can Teach Themselves to Use Tools (Schick et al., 2023)
Gorilla: Large Language Model Connected with Massive APIs (Patil et al., 2023)
Pydantic v2 官方文档：数据校验与自定义验证器
“Chaos Engineering for LLM Applications” —— 博客文章，讨论如何测试Agent鲁棒性
JSON Schema 规范 (draft-07) 及 jsonschema Python库

—— 本场面试完 ——