Claude Code 的护城河不是模型，而是其集成框架。我为 DeepSeek 重构建了这 9 个组件

DeepSeek 和 Claude 在基准测试中各有胜负，但直接使用 DeepSeek 原始 API 的体验与 Claude Code 相比显得支离破碎。差距不在于模型本身——而在于九项几乎无人提供的集成框架组件。我构建并开源了这些组件。

错配

DeepSeek V4 的成本大约仅为 Claude Opus 4.7 每百万 token 成本的 1/50。

然而，大多数尝试用原始 DeepSeek 替换 Claude Code 的工程师，往往在一天之内就放弃了。“它记不住东西，无法修复自己的 Bug，也读不懂我的文件。”

直觉上人们会责怪模型。但这并不是模型的问题。

这是因为你在比较 一个被装在罐子里的模型 与 一个配备了完整集成框架的模型 ——包括工具、权限门控、缓存策略、LSP 反馈、MCP、子代理、上下文压缩，以及一个你真正愿意沉浸其中的 TUI（文本用户界面）。这个集成框架占据了产品的 80%。Claude Code 提供了它，而 DeepSeek API 没有。目前也没有其他人在端到端地填补这一空白。

我花了十周时间来填补这个空白。以下是能够缩小 DeepSeek V4 与 Claude Opus 之间差距的实际组件清单。

DeepSeek V4 缺失的九个组件

1. 带有权限门控的工具循环

约五十种工具（读取/编辑/写入/bash/grep/glob/web_fetch/git 操作等），每种工具都配有 JSON Schema、权限级别（自动/询问/计划中拒绝）以及合理的错误注入格式。

错误格式的重要性比人们想象的要大——“模型生成了错误的 JSON，这是解析错误”这类反馈需要以一种能让模型自我修正而不耗尽三次交互回合的方式返回。

2. 感知缓存的提示组装

DeepSeek 的前缀缓存能将已缓存 token 的成本降低至列表价格的 ~10%。如果不能利用这一折扣，你原本 1/50 的成本优势将瞬间减半。

两条不易察觉的规则：

• 系统提示和工具 Schema 必须置于最顶部，并且在多轮对话中保持字节级稳定。重新排序任何一个工具，都会导致缓存失效，重新计费。

• 对话必须严格采用追加模式。不要对旧的用户消息进行追溯性编辑，也不要就地压缩旧的助手回复。如果必须进行压缩，应将旧前缀快照为一个合成消息，并从此处开始新的前缀。

大多数临时拼凑的代理循环一旦在不同轮次间以不同方式格式化内容，就会破坏缓存。

3. reasoning_content（推理内容）回放

V4 的思维模式会生成用户看不见的内部独白 token。不易察觉的是：你必须将这些 token 在下一轮对话中重新喂给模型，否则它会丢失上下文线索。

Anthropic SDK 在这里帮不上忙。你需要自己从响应中提取 reasoning_content，并将其作为结构化的助手回合重新附加。

如果跳过这一步，你的代理在消息之间会显得像是被切除了额叶——同一个模型，但连贯性显著变差。

4. 五种上下文压缩策略

1M 的上下文窗口不等于可用的上下文。包括：基于工具结果的微观修剪、阈值自动摘要、模型请求的反应式压缩、跨会话的持久会话记忆提取，以及手动 /snip 命令。

你需要全部五种策略，因为它们在时间尺度上不同——内联工具修剪是按轮次的，自动摘要是按每 N 个 token 触发的，会话记忆提取是在会话结束时进行的等等。一旦你观察真实的会话，就会发现通用的“满时摘要”策略行不通。

5. 计划/代理/YOLO 模式的分离

三种权限配置文件，可在会话中途切换。

计划模式 = 只读 + 草稿，无写入权限；

代理模式 = 写入，每次调用需确认；

YOLO 模式 = 无人值守运行时写入所有内容。

该模式是允许的工具集 × 权限默认值 × 确认提示样式的函数。它不仅仅是一个 UI 开关——它必须封装工具分发器，并能在子代理生成时存活下来。

6. 真正的 MCP 客户端

生态系统才是关键——一旦你支持 MCP，每一个 Linear/GitHub/Postgres/浏览器服务器只需一行配置即可连接。如果跳过它，你将成为唯一一个需要为每个集成编写一次性代码的代理。

7. LSP 反馈循环

启动相应的语言服务器（tsserver/rust-analyzer/pyright/gopls/clangd），并在每次编辑后将诊断信息管道传输回模型。

一旦 LSP 进入循环，模型的首次修复率将从 ~30% 提升至 ~80%。

每个服务器都有自己独特的初始化流程和特性；这是一项繁琐且持续的工作。

8. 子代理扇出

主代理将长时间任务分解为 N 个独立的子代理，每个子代理拥有全新的上下文、受限的工具预算和权限范围。

结果汇总回主代理。这将“审计代码库”或“跨 200 个文件重构”等任务的墙钟时间（wall-clock time）缩短一个数量级。

难点在于契约：子代理如何流式传输进度、共享工件，并在不污染主代理的情况下优雅地处理失败？

9. TUI + 斜杠命令 + 技能加载器

Solid + opentui（或其他方案——但请尽量不要用 Electron）。Vim 模式。在流式输出下稳定的滚动缓冲区。约 100 个斜杠命令（/clear, /diff, /plan, /compact, /skill 等）。一个技能加载器，可扫描 .openseek/skills 和 .claude/skills，使社区现有的技能库直接可用。

这看似只是“前端”工作，但它却是用户接触的全部界面。如果做错了，其余的集成框架将变得不可见。

那又怎样？

构建全部九个组件，指向 DeepSeek V4，体验将与 Claude Code 趋同。成本约为后者的 1/50。

构建这些内容工作量巨大。所以我构建了它。

openseek —— 开箱即用的多提供商支持：DeepSeek、任何兼容 OpenAI 的端点、Anthropic、Bedrock、Vertex、Azure。相同的集成框架，可替换模型。

仓库：https://github.com/LichAmnesia/openseek