Cursor 中使用 DeepSeek V4-Pro

将 DeepSeek V4-Pro 接入 Cursor 时，如果使用默认的 OpenAI 兼容设置，第一个 tool call 就会返回 400 错误。原因虽小但很棘手：V4-Pro 是一个推理模型（thinking model），会返回 reasoning_content 块，而 Cursor 会在后续请求中剥离该字段，DeepSeek API 则会拒绝丢失推理链的 tool-call 消息。位于 yxlao/deepseek-cursor-proxy 的开源代理可以缓存推理内容并在发出的请求中重新注入。一旦代理运行，V4-Pro 在 Cursor 的自定义模型面板中的表现就和其他模型一样，推理 Token 会以可折叠的 Markdown 形式渲染。以下是完整的设置流程、成本计算和故障排除列表。

核心摘要 (TL;DR)

Cursor 配合 DeepSeek V4-Pro 默认会返回 400 错误，因为 V4-Pro 是推理模型，而 Cursor 在 tool-call 消息中会剥离 reasoning_content。
deepseek-cursor-proxy（开源，Python 编写）位于 Cursor 和 DeepSeek 之间，缓存每个对话的 reasoning_content 并重新注入，从而避免 tool call 失败。
设置步骤：通过 uv 或 pip 安装，运行 deepseek-cursor-proxy，将 ngrok URL 连同你的 DeepSeek API key 粘贴到 Cursor 的自定义模型设置中。
在 Cursor 中使用 V4-Pro 的成本约为每百万输出 Token 0.87 美元，比 GPT-5.5 的输出成本便宜约 34 倍。详情请参阅《DeepSeek V4-Pro 永久降价 75%》。

为什么需要代理

V4-Pro 在每次响应中都会返回两部分内容：常规的 content 字段和包含思维链（chain of thought）的 reasoning_content 字段。对于普通聊天，你可以忽略 reasoning_content。但问题出在 tool calls 上。

DeepSeek 对推理模型的 API 协议规定：当你继续一个包含 reasoning_content 块的对话时，必须在下一次请求中包含该块，并与 tool_calls 结果并列。推理链是对话状态的一部分。Cursor 并不了解这一要求。它使用的是 OpenAI 风格的聊天客户端，而 reasoning_content 并非 OpenAI 架构的一部分，因此它会丢弃该字段。接下来的 tool call 就会返回 HTTP 400 错误，提示缺少 reasoning_content。

这严格来说并不是 Cursor 的 bug，而是两个在大部分 API 表面都兼容的供应商之间的协议不匹配。在 Cursor 增加对 V4-Pro 的原生支持或 DeepSeek 放宽协议要求之前，解决方案就是使用一个能“记住” Cursor 所遗忘内容的代理。

代理的工作原理（三行概括）

在本地端口（默认 9000）监听 Cursor 发出的聊天请求。
缓存来自每个 V4-Pro 响应的 reasoning_content，并以规范对话前缀的 SHA-256 值作为键。
在每个新请求中，根据匹配的前缀查找缓存的 reasoning_content，并在转发给 DeepSeek 之前将其添加到消息中。

它还会通过 ngrok 隧道暴露本地端口，因为 Cursor 的自定义模型设置需要 HTTPS，且不接受 localhost URL。

缓存存储在 ~/.deepseek-cursor-proxy/reasoning_content.sqlite3 中。SHA-256 键值对意味着两个并行对话不会发生冲突。推理内容按 DeepSeek 返回的原样存储，因此 DeepSeek 自身的 prompt cache 仍然有效，这对于新的永久定价至关重要。

前置条件

在开始之前，你需要准备好以下四项：

Cursor 2.0 或更高版本。 自定义模型 UI 在 3.x 中也是一样的，两者皆可。
DeepSeek API key。 如果还没有，请在 platform.deepseek.com 注册。账户里有少量余额即可，定价详情见下文。
Python 3.11 或更高版本。 该代理是纯 Python 编写。推荐使用 uv，但 pip 也可以。
带有 authtoken 的 ngrok 账号。 免费版对于个人开发者来说足够了。静态域名是可选的，但如果你经常重启代理，静态域名会让操作更简单。

如果你从未安装过 uv，请参阅 uv 官方安装文档。对于 ngrok，ngrok 快速入门会引导你完成 authtoken 步骤。

第一步：安装代理

最快的方法是使用 uv。在任何目录下运行：

uv tool install deepseek-cursor-proxy

如果你更喜欢使用 pip，请克隆仓库并将其作为可编辑包安装：

git clone https://github.com/yxlao/deepseek-cursor-proxy.git
cd deepseek-cursor-proxy
pip install -e .

无论哪种方式，都会在你的 PATH 中添加一个 deepseek-cursor-proxy 命令。通过 deepseek-cursor-proxy --help 进行验证。

第二步：配置 ngrok

代理需要一个公网 HTTPS URL，因为 Cursor 的自定义模型字段不接受 http://localhost。ngrok 提供了这个隧道。

ngrok config add-authtoken YOUR_NGROK_AUTHTOKEN

注册后从 ngrok 仪表板获取你的 authtoken。免费版在每次重启时都会给你一个随机的子域名。如果这让你感到困扰，可以在仪表板中申请一个保留域名，并通过 --ngrok-url https://your-reserved.ngrok-free.app 传递给代理。

第三步：启动代理

对于大多数设置，默认值即可：

deepseek-cursor-proxy

第一次运行时，代理会创建 ~/.deepseek-cursor-proxy/config.yaml，开启隧道，并打印公网 URL。输出如下所示：

Starting deepseek-cursor-proxy
Tunnel: https://random-name.ngrok-free.app
Local:  http://127.0.0.1:9000
Cache:  /Users/you/.deepseek-cursor-proxy/reasoning_content.sqlite3

常用参数：

--port 9000: 如果 9000 端口被占用，可以更改本地端口。
--verbose: 打印请求和响应体。在调试 Cursor 集成时非常有用。
--no-ngrok: 跳过隧道。在使用接受 http://localhost 的工具进行测试时很有用。
--no-display-reasoning: 在 Cursor 视图中隐藏可折叠的推理块。推理过程仍然存在，只是不进行渲染。

让代理在单独的终端中持续运行，或者在 macOS 上将其封装为 launchctl 任务。Cursor 的每个请求都会与之通信。

第四步：配置 Cursor

打开 Cursor 设置，导航到 Models，并添加一个自定义模型。你需要填写的字段：

Model name: deepseek-v4-pro。代理会将此字符串直接转发给 DeepSeek，因此它必须匹配真实的 DeepSeek 模型标识符。使用 deepseek-v4-flash 可以选择更便宜的变体。
Base URL: 代理打印的 ngrok URL，加上 /v1。例如：https://random-name.ngrok-free.app/v1。
API key: 你的 DeepSeek API key（以 sk- 开头）。代理本身没有认证层，它会原样转发 key。

Cursor 会运行“Verify model”检查。该检查会发送一个简单的 chat completion。出现绿色对勾表示配置成功。连接错误通常指向 ngrok URL：请从代理输出中重新复制，并确认它以 /v1 结尾。

第五步：选择模型并尝试 tool call

在聊天面板中打开模型选择器，选择你的新自定义模型。第一个要尝试的 prompt 应该是强制使用工具的，因为 tool calls 是原始 400 错误发生的地方：

“打开此仓库中的 README，列出每个代码块，并告诉我哪些代码块缺少语言提示。”

Cursor 将发起一个 read_file 的 tool call。如果代理正常工作，响应链如下：

Cursor 将用户消息发送给代理。
代理转发给 DeepSeek，不带 reasoning_content（这是第一轮对话）。
DeepSeek 返回文本、一个 reasoning_content 块以及一个 tool_calls 请求。
代理缓存由对话前缀哈希值作为键的 reasoning_content。
Cursor 运行工具，然后发送包含工具结果的后续请求。该后续请求不含 reasoning_content，因为 Cursor 丢弃了它。
代理通过前缀哈希查找缓存的 reasoning_content，并在转发前重新注入。
DeepSeek 接受请求，继续推理，并返回最终答案。

使用 --verbose 运行，你将在日志中看到注入过程。

实际成本计算

在 Cursor 中使用 V4-Pro 支付的是 DeepSeek 的标准 API 费率，而不是 Cursor 的捆绑额度。截至 2026 年 5 月，这些费率是永久性的：

| Token 类型 | 每 1M Token 费率 | | :--- | :--- | | 输入 (cache miss) | $0.435 | | 输入 (cache hit) | $0.003625 | | 输出 | $0.87 |

一个高强度的 Cursor 使用日大约包含 50 轮对话和 20 个 tool-call 链。每轮平均约 8,000 个输入 Token（文件上下文 + system prompt + 历史记录）和 1,500 个输出 Token。计算如下：

50 轮 × 8,000 输入 × $0.435 / 1,000,000 = 最坏情况 $1.74
如果 6,000 Token 的系统和上下文前缀有 60% 的缓存命中率：约 $0.85
50 × 1,500 × $0.87 / 1,000,000 = $0.065 输出

总计：高强度使用一天约 1 美元。与通过 Cursor Pro 捆绑的 GPT-5.5 配额运行相同工作负载相比，在配额限制生效前，这要便宜一个数量级。完整的降价计算见《DeepSeek V4-Pro 永久降价 75%》。

关于 DeepSeek 其他产品线的上下文，请参阅《什么是 DeepSeek V4 以及如何使用 DeepSeek V4 API》。

V4-Pro 在 Cursor 中的使用体验

与默认的 Cursor 模型相比，有三个明显的区别。

1. 推理 Token 可见。 默认情况下，代理会将 DeepSeek 的推理过程渲染为每个响应上方的一个可折叠 Markdown 块。Cursor 的聊天面板将其显示为 <details> 元素。这对于调试 prompt 很有用，但对于日常工作可能显得有些嘈杂。可以使用 --no-display-reasoning 进行切换。

2. 第一次 tool call 的延迟较高。 V4-Pro 是推理模型，推理链在任何 tool call 之前运行。预计在第一个工具触发前会有 2 到 4 秒的延迟，随后的处理速度则恢复正常。

3. Cursor 的 “Apply” 建议在复杂重构中表现更好。 这是核心优势。V4-Pro 的推理链能捕捉到扁平生成模型（flat-completion models）容易忽略的多文件依赖关系。以前需要 GPT-5.5 进行三轮对话才能完成的重命名、签名更改和配置驱动的重构，使用 V4-Pro 通常一轮就能搞定。

其他关于 DeepSeek 配合 Cursor 的教程针对的是前代模型。有关旧模式的信息，请参阅《如何在本地配合 Cursor 使用 DeepSeek R1》和《Cursor 配合 DeepSeek V3：分步指南》。本指南中的代理取代了那些文章中记录的手动注入推理内容的黑科技。

使用 Apifox 测试你的 DeepSeek 设置

Cursor 集成仅证明了 Cursor 内部的路径。如果你要将 V4-Pro 应用到其他场景（CI 机器人、后端 Agent、自定义 IDE 插件），你需要一个针对代理转发的相同端点的确定性测试框架。

这就是 Apifox 的用武之地。将 Apifox 环境指向 https://api.deepseek.com/v1，填入你的 API key，并导入 OpenAI Chat Completion 架构。你可以：

记录来自 V4-Pro 的标准响应，并在每次 prompt 更改时回放，以捕捉偏差。
使用 JSON Schema 断言验证 tool_calls 的形状，防止错误的 system-prompt 修改悄悄破坏你的生产环境 Agent。
使用 Apifox 的测试场景，在相同的输入批次下并排比较 V4-Pro 和 GPT-5.5。

下载 Apifox，导入 DeepSeek OpenAPI 规范，你就能在五分钟内拥有一个可工作的 V4-Pro 测试台。这与我们在《如何使用 DeepSeek V4 API》中介绍的工作流一致。

常见陷阱

第一次 tool call 后出现 400 错误。 这是该代理旨在修复的经典故障模式。如果设置后仍然看到此错误，说明代理未运行或 Cursor 指向了错误的 base URL。请重新检查 URL 是否以 /v1 结尾，以及代理日志是否显示有传入请求。

ngrok 隧道不断重连。 免费层隧道在重启时会轮换。如果 Cursor 的验证通过了，但几分钟后失败，说明你的隧道更新了。请改用保留域名（在 ngrok 仪表板中一键操作），并通过 --ngrok-url 传递。

推理内容重复出现。 当两个代理实例运行在同一个 SQLite 缓存路径上时会发生这种情况。停止两者，删除 ~/.deepseek-cursor-proxy/reasoning_content.sqlite3，然后启动一个实例。

缓存命中率看起来很低。 DeepSeek 的 prompt cache 要求前缀字节级一致。Cursor 会在某些 system prompt 中注入时间戳和会话 ID，这会破坏缓存命中。解决方法不在代理内部；要么接受成本，要么在 V4-Pro 会话中使用 Cursor 的“无系统提示（no-system-prompt）”模式。

Cursor 报告 “model not found”。 Cursor 设置中的模型名称必须匹配真实的 DeepSeek 模型。目前的有效值包括 deepseek-v4-pro、deepseek-v4-flash、deepseek-v3-2-pro 和 deepseek-r1-1。代理不负责翻译名称，它只是转发。

如果代理不适合你，还有哪些替代方案

代理是目前最优雅的路径，但还有两个替代方案：

不带代理使用 V4-Flash。 V4-Flash 不是推理模型，不返回 reasoning_content。Cursor 可以直接与其通信，无需任何变通方法。你放弃了思维链的提升，但保持了集成的简单性。定价为每百万 Token $0.14 / $0.28。
使用 Cline、Continue 或其他原生支持推理模型的 AI IDE 插件。 这些工具原生处理 tool-call 消息中的 reasoning_content。如果你不执着于 Cursor，更换编辑器有时比运行代理更容易。请参阅《2026 年最佳开源编码助手：免费的 Cursor 替代品》。

其他详细介绍的 Cursor 模型集成包括：Claude Opus 4.6 配合 Cursor、Kimi K2.5 配合 Cursor 以及 Gemini 3.0 Pro 配合 Cursor。

常见问题解答 (FAQ)

为什么 Cursor 不原生支持 DeepSeek V4-Pro？ Cursor 的聊天客户端遵循 OpenAI Chat Completions 架构。reasoning_content 并非该架构的一部分；它是 DeepSeek 随 R1 系列推出并在 V4-Pro 中保留的特定扩展。Cursor 需要添加特定供应商的处理逻辑来透传该字段。他们可能会这样做；在此之前，代理是变通方案。

该代理是否支持 DeepSeek R1 或 V3.2？ 是的。任何返回 reasoning_content 且要求在 tool-call 后续请求中包含它的 DeepSeek 推理模型都受支持。只需在 Cursor 设置中将模型名称设置为真实的 DeepSeek 模型标识符即可。

让代理一直运行安全吗？ 安全，但有一个注意事项：SQLite 缓存包含你对话中的原始推理内容。如果你在多用户环境或共享机器上运行，请限制缓存目录的权限，或使用 --no-cache 运行（仅限内存存储，这意味着代理重启后 tool call 会失败）。

我可以不使用 ngrok 吗？ 可以，使用 --no-ngrok。代理将仅暴露 http://127.0.0.1:9000。Cursor 的自定义模型 UI 在标准版本中拒绝 http:// URL，但某些侧载版本和修改过的配置接受 localhost。大多数用户仍需要 ngrok 或同类工具（Cloudflare Tunnel, Tailscale Funnel）。

这是否适用于 Cursor Composer 2.5？ Composer 使用与聊天面板相同的模型路由管道，所以答案是肯定的。Composer Agent 内部的第一个 tool call 会触发相同的 reasoning_content 要求，代理会以同样的方式修复它。

代理的延迟开销是多少？ 微乎其微。代理在每个请求中增加了一个本地网络跳跃、一次 SQLite 查找和几 KB 的 JSON 处理。实测开销为每次调用 5 到 15 毫秒。ngrok 会根据最近的边缘节点增加 30 到 80 毫秒。代理本身不是瓶颈。

代理如何决定缓存什么？ 它会对对话前缀（最新用户或工具消息之前的所有内容）进行哈希处理，将该哈希的 SHA-256 值作为键，存储来自上一个 DeepSeek 响应的 reasoning_content。在下一次请求中，它计算新前缀的哈希并查找匹配项。这种方式比较保守。部分前缀匹配不会触发缓存命中，因此两个近乎相同的对话不会互相干扰。

Anthropic、OpenAI 或 Cursor 会破坏这个方案吗？ Anthropic 和 OpenAI 与此无关。Cursor 可能会添加原生的推理模型支持（届时代理将变得不再必要），或者更改请求格式导致代理失效。该仓库有人维护；请关注其 Issues 以获取兼容性更新。

总结

V4-Pro 的编码能力在基准测试中与 GPT-5.5 旗鼓相当（DataCamp 对比），而输出价格仅为后者的 1/34 左右。Cursor 用户唯一的障碍就是围绕 reasoning_content 的 API 协议不匹配。deepseek-cursor-proxy 仓库通过不到一百行核心代码和五分钟的设置解决了这个问题。

接下来的三个具体步骤：