在 Open Interpreter 中接入 DeepSeek：内置 Provider、Harness 行为与完整配置实战

Open Interpreter 内置 deepseek 模型提供方，可直接通过 DeepSeek 的 OpenAI 兼容 Chat API（/chat/completions）把 DeepSeek V4 系列模型作为编码代理运行，密钥从环境变量 DEEPSEEK_API_KEY 读取。本文以 docs/deepseek.md 为骨架，结合仓库中的 provider_catalog.json、chat-wire-compat 与 harness 路由源码，完整讲解从密钥配置、模型选择、Harness（Claude Code 与 DeepSeek TUI 两种形态）到故障排查的端到端用法，让读者能够在交互式、一次性脚本与 ACP/Codex SDK 三种场景下稳定使用 DeepSeek 模型。

一、内置 Provider：OpenAI 兼容 Chat API 直连

DeepSeek 是 Open Interpreter 内置的模型提供方，无需任何额外插件即可使用。它建立在两个约定之上：

• 走 DeepSeek 的 OpenAI 兼容 Chat 端点（即 chat/completions），而不是 Anthropic Messages 风格端点；
• 从环境变量 DEEPSEEK_API_KEY 读取 API 密钥，环境变量名由 provider 目录声明。

仓库中维护的 provider 目录 provider_catalog.json 完整记录了这一条目的默认参数：

字段	值	说明
id	deepseek	配置项 model_provider = "deepseek" 时使用的标识
name	DeepSeek	在 /model 选择器等 UI 中展示的名称
env_key	DEEPSEEK_API_KEY	读取密钥的环境变量
base_url	https://api.deepseek.com	API 基地址，Chat 请求将 POST 到其下的 chat/completions
wire_api	chat	传输协议标记：使用 OpenAI 兼容 Chat API

从源码结构看，wire_api = "chat" 的分支最终会进入 chat-wire-compat/src/client.rs 的兼容层，该层把内部的 Responses 请求转换成 Chat 风格请求体后，向 api.path = "chat/completions" 发起流式或非流式请求。因此接入层对 OpenAI 兼容端点做了较强的容错处理——例如在把请求体上送前会执行 sanitize_chat_body_for_provider，剥离那些“面向 OpenAI 兼容上游会被严格拒绝”的 Provider 私有扩展字段（如 deepseek-tui Harness 产出的 reasoning_content），以保证与严格兼容的网关（如 Groq 类端点）交互不报错。

二、快速开始：从密钥到首个会话

1. 获取并导出密钥

在 DeepSeek 开放平台创建 API Key 后，在终端导出并启动 Open Interpreter：

export DEEPSEEK_API_KEY="..."
interpreter

启动后进入交互式会话，输入斜杠命令 /model 打开模型选择器，选择 DeepSeek 提供方，再挑选一个具体模型即可开始对话。

2. 跳过选择器直接启动

如果你已经确定要用的模型，可以用 -c（config 内联参数）与 -m（model）直接完成“提供方 + 模型”双重指定，跳过交互式选择：

DEEPSEEK_API_KEY="..." interpreter \
  -c 'model_provider="deepseek"' \
  -m deepseek-v4-pro

其中 -c 'model_provider="deepseek"' 等价于在配置文件里写入 model_provider = "deepseek"，而 -m deepseek-v4-pro 指定模型 ID。两条参数组合后，会话即被固定到 DeepSeek 提供方。

3. 一次性非交互任务：interpreter exec

不进入交互界面、只跑一个独立任务时，使用 exec 子命令并把任务描述作为最后一个参数传入：

DEEPSEEK_API_KEY="..." interpreter exec \
  -c 'model_provider="deepseek"' \
  -m deepseek-v4-pro \
  "Review this repository and fix the highest-impact bug."

该模式非常适合 CI、批处理脚本或定时任务，例如代码审查、批量重构、仓库体检等一次性工作负载。

三、选择模型：以 /model 目录为唯一事实来源

DeepSeek 的当前 API 模型 ID 为：

• deepseek-v4-pro：面向更高能力需求（复杂推理、长链路代码任务）的主力型号；
• deepseek-v4-flash：成本或并发更敏感时使用的高性价比型号。

同时，DeepSeek 已公告旧的 deepseek-chat 与 deepseek-reasoner ID 将于 2026 年 7 月 24 日 停用。因此新配置应直接使用 V4 系列 ID，不要在新项目里写死旧 ID。在投入正式工作负载前，建议确认 DeepSeek 官方的 API 更新公告与定价页面，以当前可用型号与计费为准。

仓库中的 provider_catalog.json 还给出了几个与选择有关的实现事实：

模型 ID	能力标记（目录 description）	上下文窗口	reasoning	priority
deepseek-v4-flash	deepseek-flash · Reasoning · Tool calling	1,000,000	true	0
deepseek-v4-pro	deepseek-thinking · Reasoning · Tool calling	1,000,000	true	1
deepseek-reasoner（旧）	deepseek-thinking · Reasoning · Tool calling	1,000,000	true	2
deepseek-chat（旧）	deepseek · Tool calling	1,000,000	false	3

从该目录可以看出，V4 两款模型均标注“推理 + 工具调用”，且拥有 1M 量级上下文窗口，并已按 priority 排序供 /model 选择器展示。需要强调的是：模型选择器是从仓库维护的 provider 目录与提供方当前模型数据动态生成的，因此应以你已安装版本中 /model 展示的列表为准，而非本文或任何静态文档。

四、Harness 行为：Claude Code 形态与 DeepSeek TUI 形态

1. 默认 Harness：claude-code-bare

当没有显式配置 harness 时，DeepSeek 模型会自动使用 claude-code-bare。这意味着 Open Interpreter 会把一个精简的“Claude Code 形状”的代理行为面（工具集、提示与回合结构）承载到 DeepSeek 的 Chat Completions 端点之上——整个过程完全在内部完成，并不会在外部拉起一个真正的 Claude Code CLI 进程。

当前启用的 harness 可通过交互命令 /harness 查看或切换。

2. 可选 Harness：deepseek-tui

当你想使用 DeepSeek 自身 TUI/CodeWhale 形状的提示词与工具时，可显式配置 deepseek-tui：

model_provider = "deepseek"
model = "deepseek-v4-pro"
harness = "deepseek-tui"

deepseek-tui 在仓库中同样是受支持的 harness 类型，体现在多处源码中：

• tools/src/harness.rs：把配置名 "deepseek-tui" 解析为 Harness::DeepSeekTui；
• core/src/tools/handlers/harness_aliases.rs：在 deepseek-tui 形态下走对应别名逻辑；
• core/src/harness/routing.rs：显式拒绝 wire_api = "messages" 与 deepseek-tui 的组合（messages 需要 Anthropic 风格原生传输，只有 chat 风格的 deepseek-tui 请求才被支持）。

需要提示的是：如果你在 ~/.openinterpreter/config.toml 里残留了旧的显式 harness 配置，可能会导致当前生效的代理行为面与预期不符。此时用 /harness 检查，或直接删除显式 harness 行，即可回到推荐的全自动默认（DeepSeek 下即 claude-code-bare）。

3. Harness 与底层传输的对应关系

从 routing.rs 的路由矩阵可以观察到一条清晰规律：wire_api（传输协议）与 harness（行为面）必须相互匹配，messages 类端点要求 claude-code/zcode 这类 Anthropic 风格会话形态，而 deepseek-tui 等 Chat 风格 harness 必须搭配 wire_api = "chat"。这解释了为什么文档反复强调“更换端点后务必保持 wire_api = "chat"”——因为 DeepSeek 的兼容层本质就是 Chat Completions 传输。

五、配置详解：Provider 块与代理/自定义部署

内置 provider 与如下 TOML 配置完全等价：

model_provider = "deepseek"
model = "deepseek-v4-pro"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"
wire_api = "chat"

正常情况下不需要手动复制这段 provider 块——顶层两行（model_provider 与 model）就足以使用内置条目。复制它的价值在于两类场景：

1. 理解代理链路：排查“请求到底发给了谁”时，直接对照 base_url 与 env_key 就能确认目标端点与密钥来源；
2. 自定义/代理部署：当公司内网、代理网关或兼容中间层需要改写端点时，以该块为模板，替换 base_url 即可。

修改端点时有一条不可逾越的约束：保持 wire_api = "chat"。DeepSeek 兼容层是针对 OpenAI 兼容 Chat API 实现的，任何把 wire_api 改成 messages 或其它值的尝试，都会在 harness 路由阶段被直接拒绝（参考上文 routing.rs 的校验逻辑）。

六、编辑器与 SDK：同一份配置的三端复用

DeepSeek 的接入配置不只服务于终端交互会话。同一份 provider 配置可以在另外两个入口复用：

• ACP 兼容编辑器：通过 interpreter acp 启动 ACP（Agent Client Protocol）服务端后，ACP 兼容的编辑器即可直接使用 DeepSeek 模型。接入细节见 ACP 文档。
• Codex SDK 兼容层：在 sdk/python 与 sdk/typescript 等 SDK 使用场景下，沿用同样的 deepseek provider 配置即可。相关说明见 Codex SDK 兼容。

也就是说，无论你是用终端交互、编辑器内代理，还是用 SDK 编写自动化流水线，DeepSeek 的密钥、端点与模型配置都是同一份心智模型。

七、故障排查手册

针对 DeepSeek 接入的高频问题，按现象逐条给出处理建议：

现象	根因	处理方式
请求返回 401/403	DEEPSEEK_API_KEY 缺失、过期，或密钥属于其它端点	检查环境变量是否已导出、密钥是否有效，并确认它与 base_url 指向同一账号体系
旧模型 ID 失效	使用已废弃的 deepseek-chat/deepseek-reasoner（2026-07-24 停用）	打开 /model 选择当前 V4 模型，而不是在配置里硬编码替换版本
代理行为面与预期不符	残留了旧的显式 harness 配置	运行 /harness 检查，并删除 ~/.openinterpreter/config.toml 中旧的 harness 行
经代理后无法工作	代理暴露的是非 Chat 协议	让代理与 wire_api 匹配（DeepSeek 场景即保持 "chat"），不要假设所有“DeepSeek 兼容”端点底层传输都相同

八、小结：把 DeepSeek 正确“接住”的三个要点

结合文档与源码，在 Open Interpreter 中使用 DeepSeek 模型可以提炼为三点：

1. 认准内置入口：model_provider = "deepseek" + DEEPSEEK_API_KEY，通过 provider_catalog.json 中声明的 chat 协议直连 https://api.deepseek.com；
2. 以工具为源：模型可用性与当前启用的 harness，都以交互命令 /model、/harness 以及你安装版本中维护的目录数据为准；旧 ID 即将停用，新负载一律选 V4 系列；
3. 理解行为面与传输的绑定：默认 claude-code-bare 在内部承载 Claude Code 形状的代理行为，可选的 deepseek-tui 走 DeepSeek TUI 形状，二者都要求 wire_api = "chat"；改端点不改协议，排查时先看 /harness 与残留配置。

掌握了这三条，你就能在交互会话、interpreter exec 一次性任务、ACP 编辑器与 SDK 场景中稳定、可预期地使用 DeepSeek V4 模型完成编码代理工作。