外观
OpenAI 与 Anthropic API 数据模型及兼容层安全
摘要
主流模型 API 在消息角色、内容块、工具调用、结束原因和错误表示上并不等价。第三方兼容层若只追求字段可解析，可能静默丢失工具参数约束、拒答状态、身份信息或安全相关事件。兼容验证必须覆盖语义与失败模式，而非只验证正常文本响应。
调研/复核日期：2026-07-29 本文比较 HTTP 请求/响应的数据模型；SSE/WebSocket 事件序列见 vendor-streaming-comparison.md，MCP/A2A 见对应独立笔记。
协议定位与核心差异
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 字段是否相似。
架构和消息流程
请求、输出和工具调用的对应关系如下：Chat Completions 使用 messages、choices[].message 和 tool_calls；Responses 使用 input[]、output[]、function_call 与 function_call_output；Anthropic Messages 使用顶层 system、content[] block、tool_use 与 tool_result。兼容层必须保留调用 ID、内容块类型、结束原因和错误状态，不能只抽取最终文本。
安全风险
第三方兼容层可能丢弃未知字段、调整参数范围、合并 reasoning、改变 stop reason，或只实现某个子集。具体风险包括工具参数约束丢失、并行调用关联错误、拒答或不完整状态被误判为成功、身份信息未传递，以及重试后重复执行有副作用的工具。
“官方 SDK 能发出请求”不等于完整协议等价，更不能证明厂商内部是原生实现还是转换网关。厂商宣称兼容 OpenAI 或 Anthropic API 时，应拆成以下验证层级：
厂商宣称兼容 OpenAI/Anthropic API 时，应至少拆成以下验证项：
- SDK/路径兼容：base URL、鉴权 header、endpoint 可被原 SDK 调用。
- schema 兼容：必填字段、content blocks、tool schema、错误对象和 usage 字段一致。
- 流式兼容：事件名、顺序、增量拼接、终止与中途错误语义一致。
- 行为兼容：tool choice、并行工具、多模态、结构化输出、缓存/推理参数确实生效。
- 运维兼容：超时、重试、限流 header、幂等性和连接中断行为可替换。
实现与验证建议
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 隐式缩放”“成本很低”等说法均不应作为事实保留。
抓包验证方法与安全要求
可在自有测试环境中用 Burp Suite 对比官方端点与兼容端点：
- 从 Burp 导出 PEM CA。
- 通过 shell 或
~/.claude/settings.json的env对象设置代理；没有证据表明存在独立顶层httpsProxy配置项。bashexport HTTPS_PROXY=http://127.0.0.1:8080 export NODE_EXTRA_CA_CERTS=/absolute/path/to/burp-ca.pem - 启动
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，并禁止把敏感记录提交到仓库。
结论适用范围
本文比较的是截至 2026-07-29 可由官方文档确认的公开 HTTP 接口。Kimi 的公开说明足以证明其提供 OpenAI Chat Completions 和 Anthropic 兼容端点，但未公开内部转换架构、完整字段覆盖矩阵或传输级一致性结果；不能据此推断 Responses API 兼容性或内部实现方式。流式事件序列需结合 vendor-streaming-comparison.md 单独验证。
参考链接
流式帧和事件序列：模型 API 流式事件协议对比。
MCP/A2A 的传输与应用层模型不同，不能把“都使用 HTTP/SSE”理解成报文兼容：见 MCP 协议机制和 A2A 协议机制。