不同的 LLM Provider 对 Tool Schema 的支持不完全一致，你会怎么处理这种差异？OpenClaw 是怎么做 Schema 适配的？
这道题考的是多 Provider 兼容架构的设计能力，核心是你能不能理解"每个 LLM Provider 长相不一样"这件事，并且在工程上做出合理的适配方案。
我从五个方面来讲：Provider 差异根源、分层回退机制、Native 与 Proxy 端点区别、工具能力验证、Schema 复杂度分级。
为什么不同 LLM Provider 的 Tool Schema 存在差异？
先搞清楚一个问题：Anthropic、OpenAI、Gemini、Bedrock 这些 Provider，看起来都是"让大模型调用工具"，但它们的接口长得完全不一样。
认证方式不同。 有的用 API Key，有的用 AWS 签名，有的用特殊的 Header。
模型命名规范不同。 OpenAI 管模型叫 gpt-4o-mini，Anthropic 叫 claude-sonnet-4-20250514，Google 叫 gemini-2.0-flash。没有统一标准。
Tool Calling 支持程度不同。 有的原生支持 function calling，有的要求你用特定格式，有的压根不支持。
配置难度不同。 有的开箱即用，有的需要手动配一堆参数。
这就是问题的根源——你不能把它们当同一种东西来处理。打个比方，就像不同手机的充电口：都是充电，但 Lightning、Type-C、microUSB 长得完全不一样，你得用专门的转接头。
OpenClaw 的分层回退机制
OpenClaw 解决这个问题的核心思路是分层回退（Tiered Fallback）。
简单说就是：不依赖单一模型。主路线用可靠的默认模型，主路线崩了才切换到备选链。这不是自动省钱机制，而是可靠性保障。
怎么实现的？
第一层：主模型选择。 OpenClaw 会根据你的 Provider 配置，选一个明确支持 tool calling 的模型作为主力。
第二层：Fallback Chain。 如果主模型出了问题（响应超时、API 报错、不支持该操作），自动切到下一层。备胎平时不用，只有主轮胎爆了才换上。
第三层：触发条件。 什么情况下触发切换？超时、API 错误、模型返回不支持 tool calling 的响应。这些都有明确的判断逻辑。
第四层：切换逻辑。 切换不是随机的，而是按配置好的 chain 顺序来。第一个备用失败，再试第二个，依此类推。
这样做的好处是什么？你不用手动盯着，出了故障系统自己处理。用户感知到的是"服务稳定"，而不是"某个模型挂了"。
Native vs Proxy 端点的关键区分
这是理解 OpenClaw Schema 适配的另一个关键点。
Native Endpoint 是什么？ 就是这个 Provider 原生的 API 入口，比如 OpenAI 的 API、Gemini 的 API。
Proxy Endpoint 是什么？ 就是通过第三方转发的，比如通过 AWS Bedrock 访问 Anthropic 模型。
两种端点的请求格式不一样。OpenClaw 的处理策略是：
在非 native endpoint 跳过 OpenAI 请求整形。 Native 端点按 OpenAI 格式走，第三方端点不强制整形，避免格式冲突。
在非 direct Anthropic-compatible endpoint 抑制隐式 beta headers。 第三方转发可能不支持某些 header，硬塞进去反而报错。
这就像翻译。同一句话，翻成中文和英文要调整语气、文化习惯，你不能直译过去。OpenClaw 做了这个"翻译官"的角色，根据不同端点的"语言习惯"调整请求格式。
配置的时候要注意：如果你用了第三方转发（比如 Bedrock），不要期待它跟 direct endpoint 完全一致。请求 surface 不同是正常现象，不是 bug。
工具能力验证与调试策略
接下来说实操层面的东西。
你配好了 Provider，配好了工具，怎么验证它真的能调用？
第一步：用测试提示确认能力。 发一个简单的测试请求，比如"帮我查一下北京今天天气"，看模型会不会调用你配的天气工具。
第二步：检查响应格式。 看返回的是不是 tool_calls 格式，还是普通文本，还是乱码。
第三步：如果出问题，先查模型能力。 很多新手会犯一个错误：工具调用失败了，第一反应是"框架有问题"。其实很可能就是这个模型本身就不支持 tool calling。
常见的坑：
- 用了不支持 tool calling 的模型（有些模型就是纯文本模型）
- Schema 格式不符合 Provider 要求
- Token 消耗超限，模型自动降级
- 工具描述写得太模糊，模型不知道怎么用
解决办法是什么？用明确支持 tool calling 的模型，配置后发测试提示验证能力，出现问题先排查模型能力而不是怀疑框架。
OpenClaw 内置工具的 Schema 复杂度分级
最后一个知识点：不同工具的 Schema 复杂度差异很大，OpenClaw 对此做了分级处理。
简单工具：大约 150 tokens。 结构简单，参数少，Schema 描述短。比如一个"获取当前时间"的工具。
中等工具：大约 200 tokens。 参数多一些，有嵌套结构。比如一个"搜索商品"的工具，需要传入类别、价格区间等参数。
复杂工具：500-800 tokens。 这才是大头。Browser 工具能到 800 tokens，Message 工具也有 400 tokens。为什么这么高？因为这类工具功能复杂，参数多，描述要详细，Schema 自然就大。
这意味着什么？
不同复杂度的工具需要不同的处理策略。 简单工具随便配，复杂工具要考虑 token 消耗对上下文的影响。如果你的 Context Window 不大，复杂工具塞进去可能直接爆掉。
不是所有 Provider 都能处理大 Schema。 有的模型对工具数量、Schema 大小有限制。OpenClaw 的分层回退机制在这里就有用了——主模型处理不了大 Schema，切到支持更大上下文的备用模型。
面试怎么答
基础版（100-150字）：
处理 Provider 差异，核心是分层适配。我会先了解主流 Provider（Anthropic、OpenAI、Gemini、Bedrock、Ollama）在认证方式、模型命名、Tool Calling 支持程度上的差异。OpenClaw 的方案是分层回退机制：主模型负责主要工作，出问题了自动切到备用链，而不是依赖单一模型硬扛。配置时区分 native 和 proxy 端点，不做不切实际的期待。配好后用测试提示验证工具调用能力，确保模型真的支持这个操作再上生产。
加分版（200字左右）：
除了基础版的做法，我想补充几点。Schema 复杂度分级对性能影响很大——简单工具 150 tokens，复杂工具像 browser 能到 800 tokens，Context Window 紧张的时候要优先考虑工具必要性。自定义 Provider 需要提供完整配置：Base URL、API shape、显式模型元数据，否则 OpenClaw 无法正确路由。最后澄清一个误区：分层回退不是成本优化机制，是可靠性保障——备胎平时不用，只有主路线挂了才切换。如果你的 Bedrock 请求表面和 direct Anthropic 不一样，这是正常现象，因为两者的请求结构本来就不同。
一句话总结
这道题的核心是：不同 LLM Provider 的 Tool Schema 长得不一样，工程上要用分层回退机制 + Native/Proxy 端点区分 + Schema 复杂度分级来处理这种差异。