OpenAI / Anthropic API 结构对比与第三方兼容层

调研/复核日期：2026-07-29 本文比较 HTTP 请求/响应的数据模型；SSE/WebSocket 事件序列见 vendor-streaming-comparison.md，MCP/A2A 见对应独立笔记。

1. 三种 API 不能混为一谈

OpenAI 同时保留 Chat Completions 和 Responses API。此前笔记用 Chat Completions 的字段解释 OpenAI，又把 Responses 写成“新版端点”，容易让人误以为两者只有 URL 不同。实际是三套不同的数据模型：

	OpenAI Chat Completions	OpenAI Responses	Anthropic Messages
端点	`POST /v1/chat/completions`	`POST /v1/responses`	`POST /v1/messages`
鉴权	`Authorization: Bearer <key>`	同左	`x-api-key: <key>`；`anthropic-version: 2023-06-01`
指令	`messages` 中的 `system`/`developer` role（依模型支持）	顶层 `instructions`，也可用带 role 的 input items	独立顶层 `system`，不能作为 Messages 的 `system` role
输入	`messages[]`	字符串或 `input[]` items；可引用前一 response/conversation	`messages[]`，每条 content 可为字符串或 block 数组
输出	`choices[].message`，支持 `n` 多候选	`output[]` items；SDK 常提供 `output_text` 便捷聚合	顶层 `content[]` blocks，无 `n` 多候选
函数/工具	assistant `tool_calls[]`；结果用 `tool_call_id`	`function_call` output item；结果用 `function_call_output.call_id`	`tool_use` / `tool_result` blocks；用 `tool_use_id` 关联
状态衔接	调用方回传历史 messages	`previous_response_id` 或 Conversation；也可完全无状态	调用方回传历史 messages
流式	`chat.completion.chunk` delta	带 `type`/`sequence_number` 的语义事件	带 `event:` 与 `data:` 的 content-block 事件

Responses API 还统一承载多模态 output item、内置 tools、background mode 等 agentic 能力，不能用 choices[0].message 解析。反过来，第三方声称“OpenAI-compatible”时通常只指 Chat Completions；除非明确列出 /v1/responses 及其事件/工具语义，否则不能推定支持 Responses。

Anthropic 的扩展推理以 thinking/redacted_thinking block 表示。Prompt caching 可通过顶层或 content/tool block 的 cache_control 设置，usage 里用 cache_creation_input_tokens、cache_read_input_tokens 计量；当前类型还区分 5 分钟和 1 小时 ephemeral cache。实验功能通常还要求 anthropic-beta header，不能只看 JSON 字段是否相似。

2. “兼容”有不同层级

厂商宣称兼容 OpenAI/Anthropic API 时，应至少拆成以下验证项：

SDK/路径兼容：base URL、鉴权 header、endpoint 可被原 SDK 调用。
schema 兼容：必填字段、content blocks、tool schema、错误对象和 usage 字段一致。
流式兼容：事件名、顺序、增量拼接、终止与中途错误语义一致。
行为兼容：tool choice、并行工具、多模态、结构化输出、缓存/推理参数确实生效。
运维兼容：超时、重试、限流 header、幂等性和连接中断行为可替换。

兼容网关可能丢弃未知字段、调整参数范围、合并 reasoning、改变 stop reason，或只实现某个子集。“官方 SDK 能发出请求”不等于完整协议等价，更不证明厂商内部是原生实现还是转换网关。

3. Kimi 官方兼容端点（截至复核日）

Kimi 官方文档明确给出两类接入：

OpenAI Chat Completions 兼容：使用 OpenAI SDK，将 base_url 设为 https://api.moonshot.cn/v1，调用 chat.completions.create。官方表述是“Kimi API 兼容 OpenAI API 格式”。这只证明对外接口兼容，不能据此断言内部“没有翻译层”，也不能自动外推到 Responses API。
Claude Code / Anthropic 兼容端点：官方 Claude Code 指南使用 ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic、ANTHROPIC_AUTH_TOKEN=<Kimi API Key>，并把 Claude Code 的各模型映射变量设为 Kimi 模型。当前示例主模型为 kimi-k3[1m]；模型名和端点会随区域/套餐变化，应以对应地区的官方页面为准。

bash

export ANTHROPIC_BASE_URL="https://api.moonshot.cn/anthropic"
export ANTHROPIC_AUTH_TOKEN="<Kimi API Key>"
export ANTHROPIC_MODEL="kimi-k3[1m]"

官方页面把它称为“Anthropic 兼容端点”，足以确认存在协议适配；但未公开内部转换架构、字段覆盖矩阵或完整 wire-level conformance 结果。因此此前关于“后加”“专门截获流量”“temperature 隐式缩放”“成本很低”等说法均不应作为事实保留。

4. 抓包验证方法与边界

可在自有测试环境中用 Burp Suite 对比官方端点与兼容端点：

从 Burp 导出 PEM CA。
通过 shell 或 ~/.claude/settings.json 的 env 对象设置代理；没有证据表明存在独立顶层 httpsProxy 配置项。
bash
```
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS=/absolute/path/to/burp-ca.pem
```
1
2
启动 claude --debug，确认代理与附加 CA 生效。
分别记录 request headers/body、SSE event sequence、error、usage 与 tool round trip。

Claude Code 支持 HTTP(S) proxy 环境变量，不支持 SOCKS。不要用 NODE_TLS_REJECT_UNAUTHORIZED=0 绕过证书校验。抓包会暴露 prompt、源码、tool 参数和 token；只在授权环境中进行，使用临时 key，并禁止把敏感记录提交到仓库。

引用清单

关联

流式帧和事件序列：vendor-streaming-comparison.md。
MCP/A2A 的 transport 与应用层模型不同，不能把“都使用 HTTP/SSE”理解成 wire-compatible：见 mcp-protocol.md、a2a-protocol.md。

OpenAI / Anthropic API 结构对比与第三方兼容层 ​

1. 三种 API 不能混为一谈 ​

2. “兼容”有不同层级 ​

3. Kimi 官方兼容端点（截至复核日） ​

4. 抓包验证方法与边界 ​

引用清单 ​