Portkey-AI Gateway 中 Google Gemini 工具调用问题的技术解析

在 Portkey-AI Gateway 项目中，开发者在使用 Google Gemini 模型进行工具调用时遇到了几个关键的技术问题。这些问题揭示了不同 AI 提供商在 API 实现上的差异，以及 JSON Schema 规范在实际应用中的兼容性挑战。

参数规范兼容性问题

Google Gemini 对工具调用参数的处理与其他主流模型存在显著差异。具体表现在：

1. additionalProperties 限制
   虽然 JSON Schema 标准允许使用 additionalProperties 来定义对象是否允许额外属性，但 Gemini 的 API 实现明确拒绝接受此参数。这与 OpenAI 和 Anthropic 的实现形成对比，后两者完全支持这一标准参数。

2. strict 模式不支持
   开发者常用的 strict 模式参数在 Gemini 中同样不被识别。这个参数通常用于强制要求工具调用必须严格匹配定义的参数结构，但在 Gemini 的 API 设计中似乎没有对应的实现。

运行时错误分析

即使移除了上述不兼容参数，系统仍会遇到更底层的运行时错误：

TypeError: Cannot read properties of undefined (reading 'parts')

这个错误表明 Gateway 在处理 Gemini 的响应时，预期中的数据结构与实际返回不符。可能是由于：

• Gemini 返回的工具调用响应格式与其他提供商不同
• 响应解析逻辑没有针对 Gemini 进行特殊处理
• 流式传输(streaming)模式下的数据分块方式存在差异

解决方案与最佳实践

对于需要在 Portkey-AI Gateway 中使用 Gemini 进行工具调用的开发者，建议：

1. 简化参数定义
   避免使用 additionalProperties 和 strict 等高级参数，保持参数定义最小化。

2. 版本适配
   确认使用的 Gateway 版本是否包含对 Gemini 的最新适配。1.8.5 版本可能存在已知问题。

3. 错误处理
   实现健壮的错误处理逻辑，特别是针对不同提供商的响应格式差异。

4. 测试策略
   在切换模型提供商时，进行充分的兼容性测试，特别是工具调用等高级功能。

技术启示

这个案例展示了在多模型网关开发中的典型挑战：

• 不同AI提供商对同一功能的技术实现差异
• 标准规范(如JSON Schema)在实际应用中的解释差异
• 网关层在统一不同提供商API时面临的兼容性问题

Portkey-AI Gateway 作为中间层，需要不断适配这些差异，为开发者提供一致的接口体验。理解这些底层差异有助于开发者更好地设计跨模型的AI应用架构。