如果你是 Cursor 用户，刚看到 DeepSeek V4 发布，打算把它配置成 Composer 的后端模型，大概率会碰到这个错误：

{
  "error": {
    "message": "reasoning_content in the thinking mode must be passed back to the API.",
    "type": "invalid_request_error"
  }
}

这个报错通常在第二轮对话就出现——Cursor 发起工具调用后，DeepSeek 的 API 直接返回 400。根本原因在于 DeepSeek 的思考模式（thinking mode）有一个特殊要求：当对话中包含工具调用时，后续请求必须原封不动地回传此前积累的 reasoning_content 链条。而 Cursor 在处理工具调用请求时，直接丢弃了这个字段，导致校验失败。

我因此做了 deepseek-lane，一个运行在本地的轻量代理，专门负责在 Cursor 与 DeepSeek API 之间补全缺失的 reasoning_content，同时提供流式推理展示、ngrok 公网隧道等一系列实用功能。

架构总览

直观起见，先用一张图展示代理在整个请求链路中的位置与处理流程：

flowchart LR A[Cursor IDE] -->|HTTP 请求| B[deepseek-lane<br/>本地代理] B -->|规范化 & 注入 reasoning_content| C[上游 API<br/>DeepSeek / opencode] C -->|流式响应| B B -->|SSE 累加 & 推理展示| A B -->|持久化 reasoning 链| D[(SQLite 缓存)] C2[ngrok] -->|公网 HTTPS 隧道| B

请求首先到达代理而非直接发往上游 API。代理对载荷进行规范化处理、从 SQLite 缓存中查找并注入缺失的 reasoning_content，然后将转换后的请求转发给上游。收到流式响应后，代理逐块累积 SSE 事件、将推理 token 镜像为 Cursor 可见的 Markdown 折叠块，同时把新的推理内容写回缓存以供后续请求使用。

下面逐一展开每个环节背后的设计考量。

问题剖析：为什么偏偏是 reasoning_content 出问题？

要理解这个问题的本质，需要先搞清楚 DeepSeek 思考模式下工具调用对话的完整生命周期。

正常对话流程

一次包含工具调用的完整对话大致遵循以下时序：

sequenceDiagram participant U as 用户 participant C as Cursor participant D as DeepSeek API U->>C: 提问 C->>D: 请求（含 messages） D->>C: 响应（含 reasoning_content + tool_calls） C->>D: 工具调用结果（需回传 reasoning_content） D->>C: 最终回复 C->>U: 展示答案

关键在于第三步：当 DeepSeek 在第一轮回复中返回 reasoning_content 和 tool_calls 之后，客户端在下一轮请求中必须将 reasoning_content 原样带回。这不是可选的——API 层有严格的校验逻辑，一旦缺失就直接返回 400。

Cursor 这边发生了什么

Cursor 本身是一个对 OpenAI 兼容 API 做了一层封装的 IDE 客户端。它在构造后续请求的 messages 数组时，会保留 role、content、tool_calls、tool_call_id 等核心字段，但 reasoning_content 不在它的关注范围内——于是直接丢弃。等到第二轮请求发出去，DeepSeek 一校验就炸了。

代理的切入点

deepseek-lane 恰恰在这个环节介入：它缓存每一轮上游返回的 reasoning_content，在接受 Cursor 的后续请求时检查是否有缺失，如果有就从缓存中注入。对 Cursor 而言，它只是在和一个普通的 OpenAI 兼容 API 对话；对 DeepSeek 而言，它收到的请求字段是完整的。

核心机制一：请求规范化——不只是注入 reasoning_content

在代理收到 Cursor 请求后，第一步是规范化。这一阶段主要完成三件事：

1. 字段裁剪

Cursor 发出的请求可能携带一些 DeepSeek API 不支持的字段（比如某些 OpenAI 特有参数）。代理通过白名单机制裁剪载荷，只保留上游真正需要的字段：

const SUPPORTED_REQUEST_FIELDS = new Set([
  "model", "messages", "stream", "stream_options",
  "max_tokens", "response_format", "stop", "tools",
  "tool_choice", "thinking", "reasoning_effort",
  "temperature", "top_p", "presence_penalty",
  "frequency_penalty", "logprobs", "top_logprobs", "user",
  "seed", "n", "logit_bias",
]);

prepareUpstreamRequest 函数遍历 Cursor 请求中的所有字段，只保留白名单内的部分。对于 messages 数组中的每条消息，同样按角色对应的字段集合过滤——例如 assistant 消息允许保留 reasoning_content，而 user 和 system 消息不需要这个字段。

2. 旧版 API 兼容转换

部分早期客户端可能还在使用 functions / function_call 而非 tools / tool_choice。代理在规范化阶段自动完成格式转换，确保无论客户端实现如何，上游都能正确解析。

3. 推理内容注入

这是最关键的一步。代理在收到 Cursor 请求后，检查 messages 数组中每条 assistant 消息是否携带 reasoning_content。如果某个 assistant 消息含有 tool_calls 却缺少 reasoning_content，代理就从本地缓存中查找并补全：

export function prepareUpstreamRequest(
  body: ChatCompletionRequest,
  config: ProxyConfig,
  store: ReasoningStore
): PreparedRequest {
  // ...遍历 messages，对每条 assistant 消息检查 reasoning_content...
  const cacheEntry = store.get(lookupKey);
  if (cacheEntry) {
    // 从 SQLite 缓存中命中，注入缺失的 reasoning_content
    msg.reasoning_content = cacheEntry.reasoningContent;
  }
  // ...
}

PreparedRequest 类型中还包含一个 omittedToolCallIds 字段，记录因缓存缺失无法恢复的工具调用 ID。如果配置了 missingReasoningStrategy: 'reject'，代理会在发现缓存缺失时直接拒绝请求；默认的 recover 策略则会继续处理并通过系统消息告知模型上下文存在截断。

核心机制二：推理缓存与会话隔离

reasoning_content 的缓存管理是整个系统最精妙的部分——它必须在「精确匹配」和「容错弹性」之间找到平衡。

为什么需要会话级隔离

在多标签页或多项目并行使用时，Cursor 可能同时维持多个独立对话。不同对话可能产生完全相同的 tool_call_id（比如都以 call_1 开头）。如果缓存只看 tool_call_id，跨对话的数据污染将不可避免。因此代理使用对话上下文的 SHA-256 哈希作为命名空间，确保缓存映射只在同一会话内有效：

export function conversationScope(
  messages: ChatMessage[],
  namespace = ""
): string {
  const scopeMessages = messages.map(canonicalScopeMessage);
  const payload = namespace
    ? { namespace, messages: scopeMessages }
    : scopeMessages;
  return sha256(JSON.stringify(payload));
}

canonicalScopeMessage 将每条消息规整为仅含 role、content、name、tool_call_id、prefix 和 tool_calls 的结构，排除 reasoning_content 本身（否则会形成循环依赖），然后对整个消息列表做哈希。两条不同对话虽然都有 call_1，但各自的上下文哈希值截然不同，自然不会互相干扰。

便携缓存键：跨作用域恢复

会话作用域并非一成不变。比如用户在对话中开启新的 Composer 会话，上下文可能发生变化，导致此前的缓存键命中失败。为此代理会为每条缓存记录尝试计算跨作用域的便携别名。具体而言，它取当前消息列表中找到最后一个 user 消息的位置，从该位置往前回溯直到遇到另一个 user 消息（或到达列表开头），将这段连续的对话片段作为备用键。当主键匹配失败时，便携别名提供二次匹配机会，大大提高了缓存的复用率。

SQLite 持久化与过期策略

缓存使用 SQLite 本地存储，支持可配置的 TTL（过期时间）和行数上限。即使代理重启，之前的推理链依然可以恢复——只要旧请求再次命中相同的对话上下文。

KV 缓存兼容性：克制才是最好的设计

DeepSeek API 支持上下文硬盘缓存：如果两个请求在 prompt 前缀上有重叠（比如多轮对话中使用相同的系统提示和早期聊天记录），重叠部分的 KV 矩阵可以直接从缓存读取，无需重复计算，从而降低延迟和费用。

代理在这一点上的设计原则是最小干预——不注入任何合成的时间戳、线程 ID 或其他元数据到请求内容中。这样 Cursor 在连续对话中发出的请求在 DeepSeek 服务端看起来与直接调用几乎一致，历史前缀重合度越高，KV 缓存命中概率就越高。

核心机制三：流式响应的推理展示

DeepSeek 思考模式下，API 响应的流式 SSE 事件中会交替出现 reasoning_content（推理过程）和 content（最终回答）。但对于 Cursor 终端用户来说，如果推理过程完全不可见，用户体验会大打折扣——你只能干等，不知道模型在「想」什么。

StreamAccumulator 类负责累积接收到的 SSE 事件，并在整个流式传输过程中维护一份完整的推理历史。它追踪每个事件块的增量内容，确保最终缓存到 SQLite 中的推理文本与 API 实际输出的完全一致：

export class StreamAccumulator {
  content = "";
  reasoning = "";
  toolCalls: Map<number, ToolCallAccumulator> = new Map();
  finishReason: string | null = null;
  usage: ChatUsage | null = null;

  addDelta(delta: DeltaChoice): void {
    if (delta.content) this.content += delta.content;
    if (delta.reasoning_content) this.reasoning += delta.reasoning_content;
    // 累积 tool_calls 增量...
  }
}

CursorReasoningDisplayAdapter 更进一步——它把原始 reasoning_content 流实时转换为 Markdown 格式的折叠块：

<details>
<summary>Thinking</summary>

...推理内容...

</details>

在 Cursor 的聊天面板中，这些块会以可折叠区域的形式呈现，用户可以展开查看模型的完整推理过程，也可以折叠以减少干扰。这既保留了思考链的可审计性，又不会让聊天面板被大量中间推理 token 淹没。

核心机制四：ngrok 公网隧道

Cursor 有一项不容忽视的限制：自定义 API 的 Base URL 必须是公网可访问的 HTTPS 地址，不接受 localhost 或局域网 IP。这意味着即便代理在本地 127.0.0.1:9000 正常运行，Cursor 也无法直接连接。

传统的解决办法包括手动申请域名、配置 HTTPS 证书、设置端口转发等，对只想快速使用的开发者来说颇有门槛。deepseek-lane 直接集成了 ngrok SDK——配置好 authtoken 后，启动代理时间会自动创建一条公网 HTTPS 隧道，并在终端打印完整的公开 URL。对于不需要隧道的场景（比如使用 Cloudflare Tunnel 或在内网部署），也可以通过 --no-ngrok 关闭。

其他值得关注的细节

自动恢复机制

如果某个请求的对话历史中有一段推理内容因缓存过期而丢失，代理会在请求中插入一条系统消息，告知模型「较早的推理上下文已不可恢复，后续上下文可能不完整」，让模型能够自行调整。默认的 recover 策略允许在这样的条件下继续对话，而非直接中断。

Cursor 思考块的剥离

有时上游响应中可能包含 Cursor 格式的 <thinking> 标签（这些是 Cursor 自行注入的），代理通过正则表达式 CURSOR_THINKING_RE 在向上游转发请求时将其剥离，避免这些冗余内容干扰 API 处理。

交互式向导

首次运行 dsl start 时，代理会启动一个交互式设置向导，引导用户完成 API 提供商、默认模型、端口、推理强度、ngrok 等基础配置。配置项统一保存在 ~/.deepseek-lane/config.yaml 中，后续启动直接读取。

Quick Start

从零开始的完整配置不超过五分钟：

# 前置条件：Node.js 20+
# 1. 注册 ngrok 并配置 authtoken（免费账户即可）
brew install ngrok
ngrok config add-authtoken <你的-token>

# 2. 全局安装并启动
npm install -g deepseek-lane
dsl start

# 首次运行会进入交互式配置向导，完成后终端会打印：
# ✓ Model: deepseek-v4-pro (thinking, max)
# ▸ Local:  http://127.0.0.1:9000/v1
# ▸ Public: https://your-tunnel.ngrok-free.dev/v1

然后在 Cursor 的 Settings → Models → Add Custom Model 中将 Base URL 设为 ngrok 公开地址、API Key 填上你的 opencode 订阅密钥或 DeepSeek API Key，就可以在模型选择器中找到 deepseek-v4-pro / deepseek-v4-flash 并正常使用了。

更多配置项（自定义端口、推理强度、是否显示推理过程等）请参见项目的 README 或 中文说明。

写在最后

感谢 deepseek-cursor-proxy 提供的灵感。

其实这个小工具非常简单，最早的功能就是解决一个具体的 400 错误。在实现过程中，逐渐延伸出了推理展示、多对话隔离、自动恢复、便携缓存键等一整套围绕 reasoning_content 的基础设施。如果你也在用 Cursor + DeepSeek 思考模式做开发，欢迎在 GitHub Issues 中反馈使用体验或提出功能建议。

Github 仓库地址是 https://github.com/guangzan/deepseek-lane，欢迎使用、star 🌟！