方案选型对比

跨模型兼容性挑战

当使用 OpenCode 等工具连接不同模型时，Tool Calling 的格式差异会导致以下问题：

常见错误场景

1. 参数解析失败 —— OpenAI 返回 arguments 字符串，某些模型期望对象
2. 字段名不匹配 —— parameters vs input_schema vs inputSchema
3. ID 关联错误 —— 工具调用结果无法正确匹配
4. 响应格式异常 —— 模型返回非预期的 JSON 结构

兼容方案对比

方案一：适配层模式

在应用层实现格式转换，将不同模型的输出统一为内部格式。

┌─────────────────────────────────────────────────────────┐
│                     Application Layer                    │
├─────────────────────────────────────────────────────────┤
│                   Tool Calling Adapter                   │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐        │
│  │ OpenAI      │ │ Anthropic   │ │ Gemini      │        │
│  │ Adapter     │ │ Adapter     │ │ Adapter     │        │
│  └──────┬──────┘ └──────┬──────┘ └──────┬──────┘        │
└─────────┼───────────────┼───────────────┼────────────────┘
          │               │               │
    ┌─────┴─────┐   ┌─────┴─────┐   ┌─────┴─────┐
    │  OpenAI   │   │ Anthropic │   │  Gemini   │
    │    API    │   │    API    │   │    API    │
    └───────────┘   └───────────┘   └───────────┘

优点：

• 完全控制转换逻辑
• 可针对特定模型优化
• 实现相对简单

缺点：

• 需要为每个模型维护适配器
• 新模型接入成本高
• 格式变更需要更新代码

方案二：MCP 协议标准化

采用 MCP 作为统一协议层，所有工具通过 MCP 服务器暴露。

┌─────────────────────────────────────────────────────────┐
│                     AI Application                       │
├─────────────────────────────────────────────────────────┤
│                   MCP Client Library                     │
└───────────────────────────┬─────────────────────────────┘
                            │ JSON-RPC 2.0
            ┌───────────────┼───────────────┐
            │               │               │
      ┌─────┴─────┐   ┌─────┴─────┐   ┌─────┴─────┐
      │  MCP      │   │  MCP      │   │  MCP      │
      │  Server A │   │  Server B │   │  Server C │
      └───────────┘   └───────────┘   └───────────┘

优点：

• 协议级别标准化
• 工具可独立部署和复用
• 社区生态支持

缺点：

• 需要模型原生支持或转换层
• 增加架构复杂度
• 学习成本

方案三：统一工具定义 DSL

定义一套抽象的工具描述语言，运行时转换为各模型格式。

# 统一工具定义
tool:
  name: get_weather
  description: Get current weather
  parameters:
    location:
      type: string
      required: true
    unit:
      type: string
      enum: [celsius, fahrenheit]

优点：

• 一次定义，多处使用
• 便于管理和版本控制
• 可扩展到新模型

缺点：

• 需要维护转换器
• 可能丢失模型特定功能
• 调试复杂度增加

方案四：模型能力探测

运行时探测模型的能力和格式要求，动态调整请求/响应处理。

优点：

• 自适应处理
• 减少硬编码
• 更好的容错性

缺点：

• 增加运行时开销
• 探测逻辑复杂
• 可能存在误判

决策矩阵

推荐方案

短期方案：适配层 + 格式验证

对于 OpenCode 这类需要支持多模型的工具，建议：

1. 实现统一的工具调用接口
2. 为每个模型创建适配器
3. 添加格式验证和错误恢复

长期方案：拥抱 MCP

MCP 正在成为业界事实标准：

• Anthropic 原生支持
• 开放协议，社区驱动
• 丰富的工具生态

GLM 模型特殊情况

GLM Tool Calling 格式

智谱 AI 的 GLM 系列模型采用类似 OpenAI 的格式：

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取天气信息",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {"type": "string"}
          },
          "required": ["location"]
        }
      }
    }
  ]
}

常见异常及解决方案

参考资料

• MCP Specification
• Anthropic MCP Integration