四大 LLM API 深度对比：ChatGPT / Claude / Gemini / Grok

搭 LLM 应用的时候，你迟早要跟「会话」打交道：消息怎么存、上下文怎么管、多轮对话怎么不丢状态、超长对话怎么不爆上下文。

这一层看起来无聊，但其实是四大平台差异最集中的地方。同样是「对话」，OpenAI、Anthropic、Google、xAI 选了四条几乎不同的路——有些是工程取舍，有些是产品哲学，有些是生态战略。

这篇是我拆解这四个平台 API 的调研记录，带着代码和对比，也带着一些判断。

---

TL;DR

	ChatGPT	Claude	Gemini	Grok
上下文窗口	128K	200K	2M	128K
缓存控制	自动，不可控	显式，省约 90%	显式，省约 75%	不支持
API 兼容性	原创标准	独立设计	独立设计	OpenAI 兼容
实时数据	Web 搜索	无	Google Search	X 平台
多模态	图片（插件式）	图片 / 文档	原生图文音视频	图片
知识管理	GPTs（20 文件上限）	Projects（无限制）	Gems（无知识库）	无
一句话定位	生态最全，行业标准制定者	成本可控，开发者友好	超长上下文，多模态原生	零迁移成本，快速接入

快速选型：

• 已有 OpenAI 代码想换模型 → Grok（改一行 base_url）
• 长文档分析 / 超大上下文 → Gemini（2M tokens）
• 成本敏感 + 知识库问答 → Claude（显式缓存 + Projects）
• 需要实时 Google / X 数据 → Gemini 或 Grok

---

从 OpenAI 出发：一个成为行业标准的数据结构

OpenAI 的 Chat Completions API 在 2023 年迅速确立了「消息数组」作为 LLM 对话的事实标准：

{
  "role": "user" | "assistant" | "system",
  "content": "消息内容或内容块数组"
}

这个结构的设计非常克制——角色、内容，就这两个字段。但这种克制是有意为之的：无状态、无魔法、开发者完全掌控。每次请求传入完整的对话历史，API 什么都不记，出了问题全在你自己这边。

随着功能扩展，role 多了一个 developer（新版取代 system，优先级高于 user，明确区分「框架指令」和「用户输入」），内容也从纯字符串变成可以承载多模态的数组：

{
  "role": "user",
  "content": [
    { "type": "text", "text": "这张图片是什么？" },
    { "type": "image_url", "image_url": { "url": "https://..." } }
  ]
}

工具调用的设计形成了一个完整的闭环：assistant 发起 tool_calls，tool 角色返回结果，再触发下一轮推理。这个模式后来被 Grok 原封不动地沿用——不是因为懒，而是兼容性是一种战略。

// assistant 发起工具调用
{ "role": "assistant", "content": null,
  "tool_calls": [{ "id": "call_abc", "type": "function",
    "function": { "name": "get_weather", "arguments": "{\"location\": \"Beijing\"}" } }] }

// tool 返回结果
{ "role": "tool", "tool_call_id": "call_abc", "content": "{\"temperature\": 22}" }

API 的三代演进

OpenAI 自己也在重构这个体系。三代 API 代表了三种不同的状态管理哲学：

API	状态管理	状态
Chat Completions	无状态，每次传完整历史	持续支持
Assistants API	有状态（Thread 对象）	2026 年中弃用
Responses API	可选有状态，previous_response_id 链式对话	推荐

Responses API 是今年的重要转变：不再强迫开发者在「自己管历史」和「完全交给服务端」之间二选一，而是通过 previous_response_id 实现链式对话，同时跨轮次保留模型的推理状态（reasoning state）：

response1 = client.responses.create(model="gpt-4", input="Hello", store=True)
response2 = client.responses.create(
    model="gpt-4", input="继续",
    previous_response_id=response1.id  # 只传 ID，不传完整历史
)

实际效果：缓存命中率提升 40-80%，GPT-5 在某些推理基准上比 Chat Completions 提升 5%。

产品层：三个值得深挖的设计

**消息分支（Branching）**是 ChatGPT 很容易被忽视的一个设计。编辑历史消息会创建新分支，底层是树形结构，每条消息有 parent_id 和 children_ids[]。UI 上显示 ◄ 2/3 ► 的切换器，让用户在「对话的多个宇宙」之间导航——这对探索性对话非常重要，但大多数开发者做的应用并不支持这个能力。

Memory 系统的复杂程度远超用户感知。根据社区对 ChatGPT System Prompt 的逆向工程（来源：embracethered.com），Memory 不是”存储对话历史”，而是维护一个分 6 层的用户画像注入到 System Prompt：

1. Model Set Context       — 用户明确要求记住的内容（带时间戳）
2. Assistant Response Preferences — 推断的交互偏好（带置信度分数）
3. Notable Past Conversation Topics — 历史话题摘要
4. Helpful User Insights   — 个人/职业信息提取
5. Recent Conversation Content — 最近约 40 轮（仅用户消息）
6. User Interaction Metadata — 账户/设备/行为数据

几个关键设计：使用 RAG 而非全文嵌入；只存用户消息（不存助手回复），节省 token；OpenAI 后台异步更新用户画像。代价是用户无法查看或修改系统推断的信息——这大概是该功能至今未能在欧洲上线的原因之一（GDPR）。

Canvas 则是另一种思路：通过向系统提示词注入 canmore 命名空间的函数，让模型能操作一个独立的「文档面板」：

canmore.create_textdoc(content: string): { textdoc_id: string }
canmore.update_textdoc(textdoc_id: string, pattern: string, replacement: string)

这是一种很有趣的设计：UI 交互不通过传统的前端路由，而是通过模型输出的工具调用来驱动——内容超过 10 行时自动触发，Python 代码可以直接在浏览器 WASM 里跑。

---

Claude：反方向的极致——把控制权还给开发者

如果说 OpenAI 的哲学是「给你一个够用的标准，慢慢加功能」，那 Claude 的 API 设计哲学是**「让开发者对每件事都有显式控制权」**。

最典型的体现：System Prompt 不在消息数组里，而是单独的顶层参数。

{
  model: "claude-opus-4-5-20251101",
  system: "You are...",  // 独立参数，不混入 messages
  messages: [
    { role: "user", content: "..." },
    { role: "assistant", content: "..." }
  ],
  thinking: { type: "enabled", budget_tokens: 8000 }
}

这个选择和 Gemini 后来的 systemInstruction 独立参数设计方向一致——将「框架性指令」和「对话内容」物理分离，有利于缓存，也有利于组合复用。Grok 没有跟上（仍沿用 OpenAI 的消息角色方式）。

内容块类型：最丰富的系统

Claude 的内容块类型是四个平台里最多的。除了文本、图片、工具调用/结果之外，有两个类型值得特别说：

**思考块（Thinking Block）**带有签名：

{
  type: "thinking",
  thinking: string,
  signature: string  // Anthropic 服务端签名，防止客户端伪造
}

更重要的是行为：前一轮的思考块会自动从后续对话的上下文中剥离——不会累积，不会把中间推理暴露给后续轮次，也不占用上下文窗口。这一点 Gemini 的 Thinking Mode 做得不一样（思考过程在响应中可见，但不会自动清理）。

文档块原生支持 PDF，并且内置引用能力：

{
  type: "document",
  source: { type: "base64" | "url", media_type: "application/pdf", data: string },
  citations?: { enabled: true }
}

引用可以精确到字符位置或页码，这在文档问答场景下比其他平台都精细。

Prompt Caching：把成本优化变成工程问题

Claude 的缓存是显式的，粒度到内容块级别，TTL 可选 5 分钟或 1 小时：

{
  system: [{
    type: "text",
    text: "长文档内容...",
    cache_control: { type: "ephemeral", ttl: "1h" }
  }]
}

响应里会告诉你缓存命中了多少：

usage: {
  input_tokens: 1000,
  output_tokens: 500,
  cache_creation_input_tokens: 800,  // 这次写入缓存
  cache_read_input_tokens: 0         // 缓存命中（节省约 90% 成本）
}

相比 ChatGPT 的「自动缓存，不告诉你命中了多少」，这种设计让成本优化从「看运气」变成「可工程化」。对于需要重复处理同一份长文档的场景（代码审查、合同分析、知识库问答），这个差异很大。

Gemini 的 Context Caching 提供了类似的显式 API，命中可节省约 75% 输入成本。两者的区别在于：Claude 是内容块级别的控制，Gemini 是请求级别的缓存。

Projects：知识管理的另一个层次

Claude 的 Projects 在知识库容量上远超 ChatGPT GPTs（20 文件上限）：

Project
├── Custom Instructions（项目级 System Prompt）
├── Knowledge Base
│   ├── 无文件数量限制，单文件最大 30MB
│   ├── 支持 PDF/DOCX/CSV/TXT/HTML/ODT/RTF/EPUB
│   └── Contextual Retrieval（不只是向量检索，还会给检索片段追加上下文细节）
└── Conversations（项目内的多个对话共享知识库）

RAG 实现叫 Contextual Retrieval，流程是：检索相关内容 → 追加上下文细节增强信息 → 与用户问题组合生成回答。这比纯向量相似度检索的质量高，但 Gemini 目前的 Gems 不支持上传知识库，这一差距比较明显。

Artifacts 与 Canvas 的设计哲学对比

Claude Artifacts 和 ChatGPT Canvas 解决的是同一个问题（生成内容的协作编辑），但设计哲学不同：

	Artifacts（Claude）	Canvas（ChatGPT）
内容管理	独立版本化对象，有完整版本历史	实时协作，无显式版本
存储	Personal / Shared 两种类型	会话内临时
代码执行	不支持	Python 在 WASM 跑
支持格式	Markdown/HTML/React/SVG/Mermaid	文档/代码

Artifacts 把「生成内容」当做一个有生命周期的对象管理，Shared 类型还支持多用户共享状态（排行榜、共同文档等）。Canvas 更偏向「实时协作」，但内容不独立存在于会话之外。

---

Gemini：从底层重新定义多模态

在四个平台里，Gemini 是唯一一个从一开始就把多模态作为一等公民来设计的。这不是功能层面的差异，而是数据模型层面的差异。

数据结构上的刻意不同

Gemini 的消息不叫 message，叫 Content；内容不叫 content，叫 parts；AI 的角色不叫 assistant，叫 model：

interface Content {
  role: "user" | "model";  // 不是 "assistant"
  parts: Part[];           // 不是 "content"
}

这些命名选择不是偶然——parts 数组比 content 更自然地表达「一条消息里同时包含文字、图片、音频」的概念。OpenAI 后来也支持了 content 数组，但语义上是「扩展」，Gemini 从一开始就是「原生」：

// 一条消息里混合多种模态，是一等公民
{ role: "user", parts: [
  { text: "帮我分析这段视频里的内容" },
  { fileData: { mimeType: "video/mp4", fileUri: "gs://..." } },
  { inlineData: { mimeType: "audio/mp3", data: audioBase64 } }
]}

支持的格式覆盖面是四个平台里最广的：图片（PNG/JPEG/WEBP/HEIC/HEIF）、音频（WAV/MP3/AIFF/AAC/OGG/FLAC）、视频（MP4/MPEG/MOV/AVI 等）、文档（PDF/TXT/HTML/JS/Python 等）。

2M 上下文窗口意味着什么

模型	上下文窗口	最大输出
Claude	200K tokens	8K
ChatGPT (GPT-4)	128K tokens	16K
Gemini 2.0 Flash	1M tokens	8K
Gemini 1.5 Pro	2M tokens	8K

2M tokens 不只是「更大的 128K」——它在质变：约 3000 页文档、约 2 小时视频、完整中型代码库，都可以整个塞进上下文，而不需要做 RAG 分块。这对需要「全局理解」而非「局部检索」的场景（代码重构、合同全文审查、学术论文分析）是真正的竞争优势。

Context Caching 让这个优势可以持续发挥而不爆成本：

// 创建缓存（只做一次）
const cache = await cacheManager.create({
  model: "gemini-1.5-pro",
  contents: largeContextContents,  // 这 2M 上下文
  ttl: "3600s"
});

// 后续请求只传新问题
const response = await model.generateContent({
  cachedContent: cache.name,
  contents: [{ role: "user", parts: [{ text: "基于全部代码，找出所有 N+1 查询问题" }] }]
});

缓存命中，输入 token 价格降低约 75%。

Google 生态整合：护城河，也是隐私问题

Grounding with Google Search 不只是「联网搜索」，而是带置信度分数的段落级来源标注：

// 启用实时搜索
{ tools: [{ googleSearch: {} }] }

// 响应带来源证据
groundingMetadata: {
  groundingChunks: [{ web: { uri: "https://...", title: "来源标题" } }],
  groundingSupports: [{
    segment: { startIndex: 0, endIndex: 100 },
    groundingChunkIndices: [0],
    confidenceScores: [0.95]  // 每个来源的置信度
  }],
  webSearchQueries: ["实际执行的搜索查询"]
}

更深的整合在 Extensions：Gemini 可以直接访问用户的 Gmail、Drive、Calendar、Maps，不是通过 API 调用，而是通过授权后的直接数据访问。这是 ChatGPT Actions 做不到的深度，也是 Claude 主动回避的方向。

但这也是 Gemini 最大的隐患：深度数据访问意味着更大的隐私风险，而且 Extensions 是预定义的（官方集成），用户无法自定义，灵活性远不如 GPTs 的 Actions 体系。

Live API：实时交互的新前沿

Gemini 2.0 的 Live API 支持 WebSocket 实时音视频流——这在其他三个平台里只有 ChatGPT 的 Realtime API 有类似功能，Claude 和 Grok 都不支持：

const ws = new WebSocket("wss://generativelanguage.googleapis.com/ws/...");
ws.send(JSON.stringify({
  realtimeInput: { mediaChunks: [{ mimeType: "audio/pcm", data: audioChunkBase64 }] }
}));

适用场景：语音助手、实时翻译、视频通话分析。

---

Grok：独家数据 + 兼容策略

Grok 是四个平台里生态最小、成立最晚的，但它有两个其他平台复制不了的东西。

独家护城河：X 平台实时数据

Grok 的核心差异化不在模型能力，在数据源：

用户提问："最近关于 AI 监管有什么最新动态？"
        ↓
X 平台实时检索（最新推文 + 趋势话题 + 用户讨论串）
        ↓
System Prompt + 实时数据 + 用户消息 → 上下文组装
        ↓
包含最新信息的回复（带 X 平台来源）

注入的数据包括推文内容、作者信息（粉丝数、认证状态）、互动数据（点赞/转发/浏览量）、讨论串结构。

对于舆论分析、突发新闻追踪、社交媒体热点监控这类场景，这是其他任何平台都复制不了的优势——即使 Google Grounding 有 Google Search，X 平台的数据也不在里面。

战略兼容性：把 OpenAI SDK 当作接入成本为零的入口

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.XAI_API_KEY,
  baseURL: "https://api.x.ai/v1"  // 换这一行，其他代码不动
});

这个选择有很明确的战略逻辑：降低接入门槛 → 让已经在用 OpenAI 的开发者无缝试用 → 积累用户数据和信任 → 再推差异化功能。从市场份额角度看，这是一个合理的后发策略。

支持的端点完整覆盖了常用 API：/v1/chat/completions、/v1/completions、/v1/embeddings、/v1/images/generations，以及 Function Calling（完全 OpenAI 兼容的格式）。

目前的局限也很明显：无知识库管理、无项目组织能力、无缓存支持。但这可能是有意为之——先占住「X 数据入口」和「兼容层」这两个战略位置，其他功能后续跟进。

DeepSearch 与个性化模式

DeepSearch 是 Grok 的深度研究功能，不只是「搜索」，而是多源聚合 + 交叉验证 + 结构化报告。流程：分解复杂问题 → X 数据 + 网络搜索 + 权威来源并行检索 → 交叉验证 + 可信度评分 → 生成有来源引用的报告。耗时较长（分钟级），适合需要综合分析的场景。

Fun Mode / Regular Mode 通过不同 System Prompt 切换风格，Regular 专业直接，Fun 幽默有个性。这个设计在其他平台里没有直接对应——Claude 的 Styles 功能类似，但定位是帮助用户调整助手的沟通风格，而不是给助手设定「人格模式」。

---

横向对比

关键维度总结

维度	ChatGPT	Claude	Gemini	Grok
最大上下文	128K	200K	2M	128K
AI 角色名	assistant	assistant	model	assistant
System Prompt 位置	消息角色 / 顶层参数	顶层 system	顶层 systemInstruction	消息角色
API 兼容性	原创（行业标准）	独立设计	独立设计	OpenAI 兼容
多模态深度	图片（插件式）	图片/文档	原生图文音视频	图片
实时数据	Web Browsing	无	Google Search + Grounding	X 平台原生
知识管理	GPTs（20 文件）+ Memory	Projects（无限文件）	Gems（无知识库）	无
协作编辑	Canvas	Artifacts（版本化）	无	无
缓存控制	自动，不可控	显式 TTL，节省约 90%	Context Caching API，节省约 75%	不支持
深度思考	o1 系列（独立模型）	Extended Thinking（可配置预算）	Thinking Mode	不支持
实时音视频	Realtime API	无	Live API	无

会话数据模型核心差异

ChatGPT:  messages[{ role: "assistant", content: string | array }]
Claude:   messages[{ role: "assistant", content: string | array }] + 顶层 system
Gemini:   contents[{ role: "model", parts: Part[] }] + 顶层 systemInstruction
Grok:     messages[{ role: "assistant", content: string | array }]  ← 完全同 OpenAI

三家沿用了 OpenAI 的 assistant 和 content，只有 Gemini 用了 model 和 parts——不是偏好不同，而是多模态优先的设计哲学在数据模型层面的体现。

缓存策略的三种哲学

这个维度最能体现产品哲学差异：

• ChatGPT：自动缓存，不告诉你命中了多少。「你专注于对话，我来优化成本。」但这意味着你无法预测实际花销。
• Claude：显式 cache_control，粒度到内容块，TTL 可选，响应里告诉你命中了多少 token。「成本可工程化，你来负责。」
• Gemini：Context Caching API，请求级别的缓存，适合「固定大段上下文 + 变化的问题」模式。
• Grok：不支持缓存，这在长上下文场景下是明显的劣势。

对于成本敏感的生产环境，Claude 的显式缓存控制是目前最成熟的方案。

流式响应格式

平台	SSE 事件格式
ChatGPT	data: {"choices":[{"delta":{"content":"..."}}]}
Claude	event: content_block_delta + data: {"delta":{"text":"..."}}
Gemini	{"candidates":[{"content":{"parts":[{"text":"..."}]}}]}
Grok	与 ChatGPT 相同

Claude 用事件类型区分数据块（content_block_start、content_block_delta、content_block_stop），解析复杂响应（思考块 + 文本块 + 工具调用）更清晰，但接入成本略高。

---

对开发者的启示

选平台的逻辑：

场景	首选	核心理由
长文档分析	Gemini（2M）/ Claude（200K）	真正的超长上下文
知识库问答	Claude	知识库无限制 + Contextual Retrieval
实时信息	Grok（X 数据）/ Gemini（Google Search）	独家数据源
多模态应用	Gemini	原生多模态，非插件式
快速 API 接入	Grok（兼容 OpenAI SDK）	零迁移成本
成本敏感 + 长上下文	Claude	显式缓存，可预测成本
安全合规	Claude	无生态整合，数据边界清晰

消息数据结构的推荐实践：

interface Message {
  id: string;
  role: "user" | "assistant" | "system";
  content: string | ContentBlock[];
  created_at: string;
  parent_id?: string;       // 支持分支——ChatGPT 的实践证明这很有价值
  children_ids?: string[];
  metadata?: {
    model?: string;
    tokens?: number;
    cache_hit_tokens?: number;  // Claude 风格的缓存追踪
    tool_calls?: ToolCall[];
  };
}

System Prompt 独立于消息数组管理（Claude / Gemini 的选择），有利于缓存和组合复用。

上下文管理策略：

场景	推荐做法
短对话	完整历史传输，无需特殊处理
长对话	滑动窗口 + System Prompt 优先保留
知识密集	RAG + 显式上下文缓存（参考 Claude/Gemini）
深度推理	Extended Thinking + 思考块清理（参考 Claude）

五个不会过时的趋势：

1. 消息数组模型已成标准，各家都在这个基础上往上加，根本性重构的可能性极低
2. 上下文窗口会继续扩大，但 2M 之后的收益边际递减，更值得关注的是成本曲线
3. **多模态从「插件」到「原生」**是不可逆的趋势，Gemini 的 Part 类型设计代表未来方向
4. 生态整合是护城河，Google 全家桶和 X 平台数据是其他平台短期内无法复制的
5. 显式缓存控制越来越重要，成本优化将成为 LLM 应用工程的核心课题之一

---

参考资料：

• OpenAI Chat Completions API Reference
• OpenAI Responses API vs Chat Completions — Simon Willison
• How ChatGPT Remembers You: Memory Deep Dive — embracethered.com
• ChatGPT’s Canvas: Internal Technical Details
• Claude Messages API Reference
• Claude Extended Thinking Guide
• Claude Artifacts Help
• Gemini API Documentation
• Gemini Context Caching Guide
• Gemini Grounding with Google Search
• xAI / Grok API Documentation