61 lines
2.7 KiB
Markdown
61 lines
2.7 KiB
Markdown
---
|
||
tags: [实体, 概念, 协议]
|
||
created: 2026-09-15
|
||
updated: 2026-09-15
|
||
sources: [raw/notes/2026-09-15-deepseek官方api接入codex.md]
|
||
---
|
||
|
||
# OpenAI 兼容 API
|
||
|
||
> 一种让第三方服务按 OpenAI 接口形状对外提供模型能力的约定；客户端只需认这套协议，就能不经适配地切换到任意兼容 provider。
|
||
|
||
## 简介
|
||
|
||
传统上每接入一家模型厂商都要写一套适配代码。OpenAI 兼容 API 把这层差异抹平：只要服务端暴露的端点、鉴权方式和请求/响应结构对齐 OpenAI 规范，客户端（如 [[Codex]]、各类 SDK、Agent 框架）改一个 `base_url` 就能换 provider。
|
||
|
||
本知识库中它同时出现在两条素材里，分别代表这个约定的两侧：
|
||
|
||
- **消费侧**：《DeepSeek 官方 API 接入 Codex》——Codex 通过配置指向 DeepSeek 提供的兼容端点。
|
||
- **供给侧**：[[Hermes API Server]]——把 Hermes Agent 暴露成 OpenAI 兼容 HTTP 端点，供 n8n 等上层调用。该关联为跨素材推断，原文并未提及 Hermes。
|
||
<!-- confidence: INFERRED -->
|
||
|
||
## 关键信息
|
||
|
||
- **类型**：概念（接口协议 / 约定）
|
||
- **领域**：大模型集成
|
||
- **在 Codex 侧的落点**：`wire_api = "responses"`、`requires_openai_auth = true`、`base_url`
|
||
- **相关概念**：[[Codex]]、[[DeepSeek]]、[[Hermes API Server]]
|
||
|
||
## 详细内容
|
||
|
||
素材中体现该约定的关键配置（摘自 [[Codex 配置三件套]]）：
|
||
|
||
```toml
|
||
[model_providers.DPWorking]
|
||
name = "OpenAI"
|
||
wire_api = "responses"
|
||
requires_openai_auth = true
|
||
base_url = "https://api.deepseek.com/v1"
|
||
experimental_bearer_token = "sk-xxxxxxxx"
|
||
```
|
||
|
||
可以读出的三条经验：
|
||
|
||
1. **provider 名由用户自定义**（`DPWorking` 是随意取的），协议语义字段才是有约束的部分。
|
||
2. **`name = "OpenAI"` 与 `requires_openai_auth = true`** 表示客户端仍按 OpenAI 的鉴权与调用习惯走，只是端点换成了 DeepSeek。
|
||
3. **协议兼容不等于能力等价**：接入后桌面端会显示 `Custom`、部分模型参数（如思考强度滑块）可见性下降，说明兼容层主要保证调用链路，不保证体验完全一致。
|
||
|
||
## 不同素材中的观点
|
||
|
||
- [[Hermes API Server]]（供给侧）：Hermes 内置 API Server 默认端口 `8642`，对外提供标准 OpenAI 格式接口，n8n 用 HTTP Request 节点零适配调用。
|
||
- 本素材（消费侧）：Codex 借助同一兼容协议接入 DeepSeek 模型。
|
||
- 两篇素材合起来说明：**OpenAI 兼容 API 已成为 Agent 生态事实上的通用接缝**，既能作为被接入方，也能作为提供方。
|
||
|
||
## 相关页面
|
||
|
||
- [[Codex]]
|
||
- [[DeepSeek]]
|
||
- [[Hermes API Server]]
|
||
- [[Codex 配置三件套]]
|
||
- [[AI 编程工具接入]]
|