研究表明，大多数主流LLM API（如OpenAI、Claude、Gemini、Grok、OpenRouter和DeepSeek）采用相似的JSON请求和响应结构，通常兼容OpenAI格式，但各有特定扩展用于工具、多模态输入等。 证据显示OpenAI的Chat Completions API在状态交互方面较为先进，而Claude的Messages API强调工具使用和结构化输出；Gemini则专注于多模态能力。 OpenRouter和DeepSeek设计为兼容OpenAI格式，便于集成，但它们路由到多个模型。 Codex作为OpenAI旧版代码模型已弃用，并集成到新GPT模型中；“Claude code”指Claude API通过工具实现的代码生成。 Gemini CLI不是API，而是命令行工具，用于终端交互。 API演进讨论中，OpenAI转向Responses以支持代理功能，而其他API保持更简单的聊天完成模式。

关键点：

• 标准化趋势：主流API围绕JSON HTTP POST请求和响应标准化，焦点在消息历史、生成内容和元数据上。OpenAI格式已成为事实标准，许多提供商兼容它以简化集成。
• 功能差异：OpenAI和Grok支持多模态和工具调用；Claude强调工具和代码执行；Gemini擅长媒体处理，但缺乏内置状态管理。
• 兼容性和特殊性：OpenRouter、DeepSeek完全兼容OpenAI；Codex已弃用；Gemini CLI为终端工具，非编程API。
• 争议与权衡：一些用户指出API在输出一致性上的差异（如OpenRouter vs. 原生），但结构化输出可缓解；状态管理（如OpenAI Responses vs. 无状态聊天）是设计辩论焦点。

OpenAI API

OpenAI的主要接口是Chat Completions API（https://platform.openai.com/docs/api-reference/chat），支持多模态交互。请求使用JSON体，包括“model”和“messages”；响应包含“choices”和使用指标。旧版Codex使用已弃用的Completions API。

Anthropic Claude API

Claude使用Messages API（https://docs.anthropic.com/en/api/messages），注重对话历史和工具。请求包括“messages”数组；响应有内容块和停止原因。没有单独“Claude code”API——代码生成通过主API工具处理。

Google Gemini API

Gemini API（https://ai.google.dev/gemini-api/docs/text-generation）通过“contents”数组处理文本和媒体。响应提供“candidates”和生成部分。多模态友好，但需通过多轮提示管理状态。

xAI Grok API

Grok的API（https://docs.x.ai/docs/api-reference）类似OpenAI，支持结构化格式。请求指定如“grok-4”模型；响应包括使用和可选工具。

OpenRouter API

OpenRouter（https://openrouter.ai/docs）兼容OpenAI，使用相同聊天完成格式，但基URL不同。

Gemini CLI

这是终端工具（https://github.com/google-gemini/gemini-cli），非API。命令如`gemini -p "prompt"`生成响应，用于交互或脚本。

DeepSeek API

DeepSeek（https://platform.deepseek.com/api-docs/en/）完全兼容OpenAI，使用“messages”聊天完成。适合成本效益集成。

---

主流LLM API格式的全面调查显示，这些接口在设计上趋向于标准化，以JSON为基础的HTTP POST请求和响应为核心，强调对话式交互、工具集成和多模态支持。这种标准化源于OpenAI格式的影响，许多提供商选择兼容以降低开发者门槛。 然而，各API在功能深度上存在差异：OpenAI强调代理式交互，Claude聚焦工具和代码执行，Gemini突出媒体处理，而Grok等新兴API则追求高性能集成。 本调查基于官方文档和示例，涵盖请求结构、响应模式、关键参数和实际考虑因素，并通过表格比较相似性和差异，以提供开发者全面理解。

API相似性和兼容性概述

大多数API采用对话范式，请求包括提示或消息历史，响应提供生成内容及元数据如令牌使用。OpenAI格式已成为事实标准，OpenRouter和DeepSeek明确兼容——只需更换基URL即可在OpenAI SDK中使用。 Claude和Gemini使用类似数组结构处理消息/内容，但添加独特字段用于工具或媒体。Grok与OpenAI Responses类似，强调结构化输出。 Codex代表旧式非聊天完成，已弃用并集成到GPT模型中。 Gemini CLI作为非API工具，专注于终端使用。

API设计争议包括状态管理（OpenAI Responses vs. 无状态聊天完成）和输出控制（新版结构化JSON强制）。 主要来源强调可靠性：始终使用API密钥认证，处理速率限制（如OpenAI层级），并为实时应用使用流式传输以避免超时。

各提供商详细请求和响应格式

OpenAI Chat Completions API 端点：POST /v1/chat/completions 头部：Authorization: Bearer <KEY>，Content-Type: application/json 关键参数：model（必需，如"gpt-4o"），messages（数组），temperature（0-2），tools（数组），stream（布尔）。 示例请求：

JSON

{
  "model": "gpt-4o",
  "messages": [{"role": "user", "content": "告诉我一个关于独角兽的三句睡前故事。"}],
  "temperature": 0.7
}

响应：包括id，choices（消息/内容），usage（令牌）。 示例响应：

JSON

{
  "id": "chatcmpl-...",
  "choices": [{"message": {"role": "assistant", "content": "在一个宁静的树林中..."}}],
  "usage": {"prompt_tokens": 36, "completion_tokens": 87}
}

备注：支持后台处理和代理对话。旧Codex使用Completions API（已弃用）。

Anthropic Claude Messages API 端点：POST /v1/messages 头部：x-api-key: <KEY>，Content-Type: application/json 关键参数：model（必需，如"claude-3-5-sonnet-20241022"），messages（数组），max_tokens，temperature（0-1），tools（数组），tool_choice（"auto"等），stream。 示例请求：

JSON

{
  "model": "claude-3-5-sonnet-20241022",
  "messages": [{"role": "user", "content": "你好，Claude！"}],
  "max_tokens": 1024,
  "temperature": 0.7
}

响应：id，type ("message")，content（块数组），stop_reason，usage（输入/输出令牌）。 示例响应：

JSON

{
  "id": "msg-...",
  "type": "message",
  "role": "assistant",
  "content": [{"type": "text", "text": "你好！我能帮你什么？"}],
  "stop_reason": "end_turn",
  "usage": {"input_tokens": 10, "output_tokens": 15}
}

对于"Claude code"：通过主API工具集成，如code_execution——无单独格式。

Google Gemini API 端点：POST /generateContent（或streamGenerateContent） 头部：x-goog-api-key: <KEY>，Content-Type: application/json 关键参数：contents（数组，含role/parts），parts包括text或inline_data（mime_type/data用于图像）。 示例请求（文本）：

JSON

{
  "contents": [{"parts": [{"text": "解释AI如何工作。"}]}]
}

响应：candidates（含content/parts数组），finishReason，usageMetadata。 示例响应：

JSON

{
  "candidates": [{"content": {"parts": [{"text": "在其核心..."}], "role": "model"}, "finishReason": "STOP"}]
}

多模态示例：parts中包含base64数据。支持流式块。

xAI Grok API 端点：POST（类似OpenAI /chat/completions） 头部：Authorization: Bearer <KEY> 关键参数：model（如"grok-4"），messages，temperature，tools。 示例请求：类似OpenAI。 响应：id，choices，usage。支持结构化输出通过模式。

OpenRouter API 端点：POST /api/v1/chat/completions 头部：Authorization: Bearer <KEY>，可选HTTP-Referer/X-Title 关键参数：model（如"openai/gpt-5.2"），messages。 示例请求：

JSON

{
  "model": "openai/gpt-5.2",
  "messages": [{"role": "user", "content": "生命的意义是什么？"}]
}

响应：choices（含message/content）。 完全兼容OpenAI；用于聚合模型。

OpenAI Codex（已弃用） 使用Completions API：POST /v1/completions 关键参数：model，prompt，max_tokens，temperature。 示例请求：

JSON

{
  "model": "gpt-3.5-turbo-instruct",
  "prompt": "说这是一个测试",
  "max_tokens": 7
}

响应：id，choices（含text），usage。 现集成到GPT模型——改用Chat Completions。

Google Gemini CLI（非API） 用法：命令行工具，如gemini [options]。 示例命令：

• 交互：gemini
• 提示：gemini -p "解释此代码" --output-format json
• 模型：gemini -m gemini-2.5-flash 支持文件、搜索，但仅限终端——非HTTP API。

DeepSeek API 端点：POST /chat/completions 头部：Authorization: Bearer <KEY> 关键参数：model（如"deepseek-chat"），messages，stream。 示例请求：

JSON

{
  "model": "deepseek-chat",
  "messages": [{"role": "user", "content": "你好！"}]
}

响应：类似OpenAI。兼容OpenAI。

关键功能跨API比较表

提供商/API	端点	多模态支持	工具/函数调用	流式传输	兼容性备注	最大令牌参数	温度范围
OpenAI Chat Completions	/v1/chat/completions	是（文本/图像）	是（tools数组）	是	N/A（标准）	max_completion_tokens	0-2
Claude Messages	/v1/messages	有限（文本为主）	是（tools）	是	部分类似OpenAI	max_tokens	0-1
Gemini	/generateContent	是（inline_data）	有限	是	独特contents结构	N/A（隐式）	N/A（默认1）
Grok	类似OpenAI /chat/completions	是	是	是	类似OpenAI	max_tokens	0-2
OpenRouter	/api/v1/chat/completions	视模型而定	视模型而定	是	完全OpenAI	max_tokens	0-2
Codex（已弃用）	/v1/completions	否	否	是	旧版	max_tokens	0-2
Gemini CLI	N/A（CLI）	是（文件）	内置（搜索/壳）	部分	仅终端	N/A	N/A
DeepSeek	/chat/completions	否	有限	是	完全OpenAI	max_tokens	0-2

此表突出核心差异；例如，OpenAI和Grok提供更宽参数范围，而Gemini在媒体处理上领先。

实际实现提示

• 认证：始终使用Bearer令牌；安全存储。
• 错误处理：响应常含stop_reason或finishReason——检查"max_tokens"以更高限制重试。
• 成本与限制：监控usage字段；如Claude包含缓存令牌以提高效率。
• 迁移：从Codex到现代API，转向聊天式messages以更好上下文。
• 争议方面：部分用户指出提供商间输出格式不一致（如OpenRouter vs. 原生），但结构化输出缓解此问题。
• 最佳实践：从官方SDK开始（如OpenAI Python用于兼容API）；测试流式用于UI应用。

此调查整合官方文档所有细节，确保准确性无虚构。