企业官网建设流程全解析

如果你是 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 公网隧道等一系列实用功能。

架构总览

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

HTTP 请求

规范化 & 注入 reasoning_content

流式响应

SSE 累加 & 推理展示

持久化 reasoning 链

公网 HTTPS 隧道

Cursor IDE

deepseek-lane
本地代理

上游 API
DeepSeek / opencode

SQLite 缓存

ngrok

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

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

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

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

正常对话流程

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

DeepSeek APICursor用户DeepSeek APICursor用户提问请求（含 messages）响应（含 reasoning_content + tool_calls）工具调用结果（需回传 reasoning_content）最终回复展示答案

关键在于第三步：当 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关闭。

其他值得关注的细节

自动恢复机制

如果某个请求的对话历史中有一段推理内容因缓存过期而丢失