DeepSeek on KnightLi的博客

让 Codex 使用 DeepSeek 模型的两种方法：本地网关和 OpenRouter BYOK

Sun, 24 May 2026 09:52:55 +0800

想让 Codex 使用 DeepSeek，第一反应通常是改 ~/.codex/config.toml：

1
2

model = "deepseek-chat"
base_url = "https://api.deepseek.com"

这个思路在一些旧版本或普通 OpenAI SDK 场景里确实成立，但放到当前 Codex CLI 上，很容易撞到一个底层问题：Codex 的自定义模型供应商走的是 OpenAI Responses 协议，而 DeepSeek 官方接口主要提供 OpenAI 兼容的 Chat Completions 调用方式。

我本机当前是 codex-cli 0.111.0。codex --help 里可以看到它支持 --config、--model、--profile 这些配置入口；OpenAI 官方 Codex 配置参考也写得很明确：model_providers.<id>.wire_api 目前只支持 responses，省略时也默认是 responses。

DeepSeek 官方文档则给出的调用路径是 https://api.deepseek.com/chat/completions，示例也是 client.chat.completions.create(...)。所以问题不在于 DeepSeek 不能被 OpenAI SDK 调用，而在于 Codex 发出去的请求语义和 DeepSeek 原生接口能理解的语义不完全是一套东西。

这就是为什么直接把 base_url 改成 https://api.deepseek.com 后，可能出现下面这些现象：

请求路径不匹配，直接 404 或返回格式不对。
多轮对话、工具调用、补丁生成时解析失败。
tool_calls 顺序、消息结构、流式事件格式对不上。
看起来模型能回一句话，但一到 Codex 真正干活就开始报错。

更稳的办法，是在 Codex 和 DeepSeek 之间放一个“翻译层”。常见有两种路线。

方法一：用本地网关桥接 DeepSeek

本地网关的作用不是简单转发，而是把 Codex 侧的 Responses 风格请求，转换成 DeepSeek 能处理的 Chat Completions 风格请求，再把 DeepSeek 的结果转换回 Codex 能吃的格式。

如果你用的是 ccx 一类本地网关，配置思路大致是这样：

[profiles.deepseek-ccx]
model = "deepseek-v4-flash"
model_provider = "ccx-bridge"

[model_providers.ccx-bridge]
name = "Local CCX Gateway"
base_url = "http://localhost:3000/v1"
env_key = "DEEPSEEK_API_KEY"

然后在终端里设置 DeepSeek Key，再用这个 profile 启动：

1
2

export DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

PowerShell 里是：

1
2

$env:DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

这里有两个细节要注意。

第一，base_url 要指向网关暴露给 Codex 的地址，不是 DeepSeek 官方地址。网关背后再去调用 DeepSeek。

第二，env_key 写什么取决于网关怎么鉴权。有的网关直接读取 DeepSeek 官方 Key，有的网关会要求你给它一个本地代理 Key，再由网关自己的后台保存 DeepSeek Key。遇到这种情况，env_key 就应该改成网关要求的环境变量名。

这条路的优点是本地可控，延迟和成本也更容易算清楚。缺点是你必须确认网关真的支持 Codex 当前使用的 Responses 语义，而不是只做了普通 Chat Completions 代理。

方法二：用 OpenRouter BYOK 做线上桥接

如果不想在本地部署网关，可以考虑 OpenRouter 的 BYOK。BYOK 的意思是把你自己的上游供应商 Key 绑定到 OpenRouter，由 OpenRouter 负责路由和转发。

这里最容易写错的是环境变量。Codex 访问的是 OpenRouter，所以 env_key 通常应该是 OPENROUTER_API_KEY，不是 DEEPSEEK_API_KEY。DeepSeek Key 要在 OpenRouter 的 BYOK 或 provider key 设置里添加。

配置示例：

[profiles.deepseek-openrouter]
model = "deepseek/deepseek-chat"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

启动方式：

1
2

export OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

PowerShell：

1
2

$env:OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

然后在 OpenRouter 后台把 DeepSeek 的 provider key 加进去。OpenRouter 的 BYOK 文档说明，绑定的 provider key 会被加密保存，并用于路由到对应供应商。

这条路的优点是省掉本地网关维护成本，配置起来更像普通第三方 API 代理。缺点是中间多了一层线上服务，排障时要同时看 Codex、OpenRouter、DeepSeek 三边的错误信息。

要不要继续用 deepseek-chat 这个模型名？

DeepSeek 官方文档在 2026 年 5 月的说明里，推荐模型名已经出现 deepseek-v4-flash 和 deepseek-v4-pro，并提示 deepseek-chat、deepseek-reasoner 兼容别名会在 2026-07-24 之后废弃。

所以新配置里更建议优先测试：

`1`	`model = "deepseek-v4-flash"`

如果走 OpenRouter，则要按 OpenRouter 的模型命名来写，例如：

`1`	`model = "deepseek/deepseek-chat"`

实际可用名称以你所用网关或 OpenRouter 模型页为准。模型名不对时，错误通常会表现为 model not found、404，或者 provider 找不到对应 endpoint。

直接改 DeepSeek 官方 base_url 为什么不推荐

你当然可以试着写：

[profiles.deepseek-direct]
model = "deepseek-v4-flash"
model_provider = "deepseek"

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

但这更像排错实验，不适合作为稳定方案。因为 Codex 会按 Responses 协议去和自定义 provider 说话，而 DeepSeek 官方示例走的是 /chat/completions。如果 DeepSeek 或 Codex 未来补齐了兼容层，这种直连才可能变得简单；在此之前，桥接层更靠谱。

改完配置后还是走 OpenAI 怎么办

先确认配置文件位置。全局配置应该在：

`1`	`~/.codex/config.toml`

项目里的 .codex/config.toml 不适合放 model_provider、model_providers 这类机器级 provider 配置。OpenAI 官方文档也提醒，项目级配置不会覆盖这些本地 provider 和认证相关字段。

如果 Codex 仍然要求网页登录，或者看起来还在走默认 OpenAI 模型，可以先退出当前登录态：

`1`	`codex logout`

有些旧教程会写成交互界面里的 /logout。在当前 CLI 里，更稳的是直接在终端执行 codex logout。

还可以用临时参数做一次快速验证：

`1`	`codex --profile deepseek-ccx`

或者：

`1`	`codex -c model_provider=ccx-bridge -c model=deepseek-v4-flash`

如果这样能生效，说明配置本身可读；如果不生效，优先检查 profile 名称、TOML 语法、环境变量是否只在当前 shell 里有效。

排障清单

401：Key 不对，或者 env_key 指向了错误的环境变量。
404：base_url 或模型名不对，也可能是把 Responses 请求打到了只支持 Chat Completions 的地址。
tool_calls、patch、流式解析报错：大概率是协议桥接不完整。
仍然提示登录 OpenAI：执行 codex logout，再确认是否用了正确 profile。
PowerShell 设置环境变量后新开窗口失效：$env:... 只对当前会话生效，需要长期保存就改用户环境变量。
OpenRouter BYOK 没走自己的 DeepSeek Key：检查 OpenRouter 后台 provider key 是否绑定、是否允许当前 OpenRouter API Key 使用，以及是否开启了 fallback。

结论

让 Codex 使用 DeepSeek，不是不能改 config.toml，而是不能只改 base_url 就指望一切自动兼容。

当前更稳的两条路是：

用本地网关做协议桥接，Codex 连本地网关，网关再连 DeepSeek。
用 OpenRouter BYOK 做线上转发，Codex 连 OpenRouter，DeepSeek Key 绑定在 OpenRouter 后台。

如果只是想快速试用，OpenRouter 路线更省事；如果你希望 Key、成本、日志都尽量掌握在自己手里，本地网关更适合长期折腾。

参考资料：

DeepSeek-TUI：把 DeepSeek V4 变成终端里的编程智能体

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI 是一个把 DeepSeek V4 接入终端开发流程的开源项目。它不是普通聊天壳，而是更接近 Claude Code、Codex CLI 这类“命令行编程智能体”：能看文件、改代码、执行命令、调用工具，并在终端里用 TUI 方式持续推进任务。

如果你已经习惯在编辑器和终端之间切换，这类工具的价值很直接：不用把代码来回复制到网页对话框里，也不用手动描述完整项目结构。你把任务交给它，它可以在当前工作区里读取上下文、规划步骤、执行修改，再把结果交还给你审查。

它解决的是 DeepSeek 的使用入口问题

DeepSeek 模型本身提供了很强的推理和代码能力，但模型能力要落到真实开发流程里，还需要一层工程化外壳。

网页聊天适合问问题，不适合长时间改项目。API 适合接入系统，但普通开发者还要自己写工具调用、上下文管理、文件读写和权限控制。DeepSeek-TUI 想补上的正是这一层：把 DeepSeek V4 包成一个可以在终端里工作的 Agent。

从项目介绍看，它的重点能力包括：

终端 TUI 界面；
面向 DeepSeek V4 的对话与任务执行；
工具调用和文件操作；
1M 上下文支持；
Auto 模式；
子智能体；
沙箱执行；
持久化任务队列。

这些功能组合起来，目标不是“让模型回答得更像人”，而是让模型更容易进入开发现场。

TUI 比纯命令行更适合长任务

很多 AI CLI 工具一开始都是纯文本交互：输入提示词，等待输出，再复制命令或补充上下文。这种方式简单，但任务一长就容易混乱。

TUI 的好处是能把会话、文件、执行结果、任务状态放在一个更稳定的界面里。对编程 Agent 来说，这很重要。因为一次代码任务往往不是一问一答，而是包含：

理解项目结构；
查找相关文件；
修改代码；
运行测试或命令；
根据报错继续修复；
总结变更。

如果界面只是一串日志，用户很难快速判断 Agent 走到了哪一步。TUI 至少给了一个更适合观察和接管的入口。

Auto 模式适合明确边界的任务

DeepSeek-TUI 提到的 Auto 模式，适合用在边界比较清楚的工作里。例如修一个小 bug、补一个脚本、改一段配置、整理一组文档、实现一个局部功能。

这类任务的共同点是：目标清楚，检查方式明确，影响范围可控。Agent 可以自己查文件、改文件、跑命令，然后把结果交给用户确认。

但 Auto 模式不适合无限放权。尤其是在真实项目里，文件删除、批量重构、数据库迁移、部署命令都应该有明确确认。编程 Agent 的效率来自自动化，但风险也来自自动化。越是能执行命令的工具，越需要沙箱、权限边界和人工审查。

子智能体的意义在于拆任务

子智能体不是新概念，但放在代码场景里很有用。

一个稍复杂的任务，通常会同时需要几类工作：有人负责读代码，有人负责改实现，有人负责检查测试，有人负责整理文档。传统多 Agent 系统经常显得花哨，是因为它们没有真实工具和真实工作区，只是在对话里互相讨论。

如果子智能体能结合文件系统、命令执行和任务队列，它就更像一种任务拆分机制。比如一个子智能体专门分析依赖关系，另一个负责修改某个模块，主智能体再整合结果。这样可以减少单个上下文里堆太多无关信息的问题。

当然，子智能体也会带来额外成本：更多 token、更复杂的状态、更难追踪的责任边界。所以它适合中等复杂度以上的任务，不一定适合每一次小修改。

1M 上下文不是万能，但很适合读项目

1M 上下文听起来很夸张，但在编程场景里并不只是营销数字。

真实代码库的上下文很碎：README、配置文件、类型定义、测试、调用链、历史约定、错误日志，都可能影响一次修改。更长上下文能减少“只看局部就动手”的问题，也能让模型保留更多项目约束。

不过，上下文长不等于判断一定更准。代码任务仍然需要检索、筛选和验证。把整个项目塞进上下文并不一定比精准读取相关文件更好。好的编程 Agent 应该把长上下文当作缓冲区，而不是把它当成替代工程判断的捷径。

更适合哪些用户

DeepSeek-TUI 更适合几类人：

想在终端里使用 DeepSeek 做代码任务的开发者；
不想自己搭工具调用和文件操作框架的人；
已经熟悉 Claude Code、Codex CLI，但想尝试 DeepSeek 模型入口的人；
需要本地项目上下文，而不是只在网页里问代码片段的人；
想把 AI 编程流程放进命令行环境的人。

如果你只是偶尔问一个函数怎么写，网页聊天已经够用。如果你希望模型直接参与项目修改，终端 Agent 才更有意义。

需要关注的风险

这类工具最需要关注三件事。

第一是权限。只要工具能读写文件、执行命令，就要确认它默认能访问哪里、能不能删除文件、能不能联网、危险命令是否需要确认。

第二是可回滚。使用前最好保持 Git 工作区干净，让每次 Agent 修改都能被 git diff 清楚看到。不要在一堆未提交改动里让 Agent 自动改项目。

第三是验证。Agent 写完代码不代表任务完成。测试、构建、lint、人工 review 仍然要保留。AI 编程工具可以提高推进速度，但不能替代最后的工程确认。

总结

DeepSeek-TUI 的意义不在于又多了一个聊天客户端，而在于它把 DeepSeek V4 放进了更接近真实开发工作的终端环境里。

对开发者来说，模型能力只是第一步。真正影响体验的是：它能不能读项目、能不能安全改文件、能不能执行验证命令、能不能在长任务里保持状态、能不能让用户随时接管。

如果你想把 DeepSeek 用在日常代码修改、项目阅读和自动化开发任务里，DeepSeek-TUI 值得关注。它代表的方向也很清楚：AI 编程工具正在从“回答代码问题”转向“参与项目执行”。

本地运行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的尝试

Mon, 11 May 2026 08:51:37 +0800

Antirez 开源了一个新项目：ds4。它不是通用 LLM 框架，而是一个面向 DeepSeek V4 Flash 的本地推理引擎，重点放在 Apple Silicon 和 Metal 后端上。

项目地址：https://github.com/antirez/ds4

ds4 是什么

ds4 的目标很明确：在 Mac 上本地运行 DeepSeek V4 Flash。

它当前提供三种使用方式：

交互式 CLI。
HTTP server。
一个实验性的 Agent 模式。

从定位看，它更像是一个针对特定模型深度优化的推理项目，而不是要替代 llama.cpp、Ollama 或 vLLM 这类通用工具。

为什么值得关注

这类项目值得看，主要有三个原因。

第一，作者是 Redis 作者 Antirez。他长期关注底层系统、性能和简单工具，项目风格通常比较直接。

第二，DeepSeek V4 Flash 属于面向高效推理的模型方向。如果本地运行体验足够好，对 Mac 用户来说会很有吸引力。

第三，ds4 直接面向 Apple Metal。相比“先支持所有平台，再慢慢优化”的路线，它更像是先把一个明确场景做深。

适合谁用

ds4 更适合这几类用户：

使用 Apple Silicon Mac。
想在本地运行 DeepSeek V4 Flash。
关注 Metal 推理性能。
愿意尝试 alpha 阶段项目。
想研究轻量推理引擎和模型运行细节。

如果你的目标是稳定部署、跨平台运行、OpenAI API 兼容生态，现阶段它未必是首选。它更适合作为实验工具和技术观察对象。

使用方式

项目 README 给出的基本流程是先构建，再运行。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

交互式运行：

./ds4

启动 HTTP server：

`1`	`./ds4 --server`

Agent 模式：

`1`	`./ds4 --agent`

具体参数和模型文件准备方式，建议以仓库 README 为准，因为项目仍在快速变化。

目前的风险

ds4 还处在早期阶段，使用前要有预期：

功能可能不完整。
参数、模型格式和命令行行为可能变化。
兼容性主要围绕 Apple Silicon 和 Metal。
Agent 模式更偏实验，不适合直接用于生产流程。
遇到问题时，需要自己阅读 README、issue 或源码排查。

也就是说，它现在更像“值得动手试的开源实验”，还不是面向普通用户的一键工具。

和通用推理工具的区别

通用推理工具通常追求模型格式、平台、后端和 API 的广泛兼容。ds4 的方向更窄：围绕 DeepSeek V4 Flash 和 Metal 做本地运行。

这种选择有利有弊。

好处是实现可以更集中，性能和体验更容易围绕单一目标优化。代价是适用范围有限，不适合拿来运行各种不同模型，也不适合替代完整的部署平台。

如果你已经在用 llama.cpp 或 Ollama，ds4 可以作为补充测试工具，而不是马上替换现有工作流。

小结

ds4 的看点不在“又一个本地大模型工具”，而在于它把范围收得很窄：DeepSeek V4 Flash、Apple Silicon、Metal、本地推理。

如果你手上有合适的 Mac，并且愿意折腾早期项目，可以关注它后续的性能表现、模型支持方式和 server/agent 能力演进。对于生产环境，建议继续观望，等接口和使用方式稳定后再评估。

参考

GitHub 项目：https://github.com/antirez/ds4

AI 编程工具这一轮，DeepSeek 为何成了省钱关键？

Mon, 11 May 2026 04:59:00 +0800

这一轮 AI 编程工具的竞争，表面上是在比模型能力、插件生态和 agent 自动化程度，真正用起来以后，最先撞上的问题却是成本。

Claude Code、Codex、OpenClaw、Superpowers 这类工具都很好用，但它们有一个共同特点：一旦进入复杂任务，就会非常吃 token。它们要读项目、建计划、调用工具、总结上下文、反复检查结果，还可能拉起多个子任务。模型越聪明，工作流越自动化，账单也越容易悄悄变大。

所以 DeepSeek 在这一轮里变得很关键，不只是因为它能写代码，而是因为它在长上下文和缓存成本上，刚好打中了 AI 编程工具最烧钱的地方。

Agent 工具为什么特别费 token

传统聊天式编程助手，通常是一问一答。你问一个函数怎么写，它回答一段代码。这个模式消耗不小，但还算可控。

Agent 工具不一样。它不是只回答问题，而是要像一个临时工程师一样进入项目：

先扫描目录和关键文件；
再理解需求和现有架构；
然后制定计划；
修改文件；
运行命令或测试；
根据报错继续修；
最后总结改了什么。

这个过程里，模型反复读取同一批上下文。项目说明、代码片段、工具结果、历史对话、计划和错误日志都会被塞回上下文。任务稍微复杂一点，几十万 token 很快就出去了。

如果再装一些更激进的插件，成本会更明显。比如有些 OpenCode 或 Claude Code 增强工具，会默认组织一整套 agent 团队。你只是想改一个小功能，它也可能启动规划、审查、执行、复盘等多个环节。任务当然显得更“智能”，但 token 也会一路往上跑。

Superpowers 的好处是按需触发

Superpowers 这类工具的一个优点，是它不会在所有任务里都强行拉起完整 agent 流程。

平时你还是可以让 Claude Code、OpenCode 或 Codex 按原来的方式工作。只有当你明确调用某个 skill，比如头脑风暴、写计划、执行计划、做复盘时，它才进入更重的自动化流程。

这对成本很重要。

AI 编程不应该所有任务都用重武器。改一行配置、查一个报错、写一个小脚本，用普通对话就够了；只有复杂重构、跨文件修改、长文档处理、多轮验证，才值得上完整 agent 流程。

工具越强，越要学会控制触发条件。否则自动化越多，浪费越多。

DeepSeek 的关键优势是缓存便宜

DeepSeek 适合接这类 agent 工具，一个很重要的原因是缓存命中成本低。

AI 编程任务里有大量重复前缀。比如项目背景、系统提示词、工具说明、文件内容、前几轮对话，经常会在后续请求里反复出现。如果模型服务支持 prompt cache，这些重复内容命中缓存后，成本会明显下降。

很多模型的缓存命中价只是比未命中便宜一些，比如便宜到三分之一左右。DeepSeek 的优势在于，命中缓存后的价格差距可以大很多。对长上下文、多轮调用、重复读取项目的 agent 工作流来说，这个差距会直接反映到账单上。

也就是说，DeepSeek 不是每一次回答都一定最强，而是在“长任务、多轮任务、反复读上下文”的场景里，成本结构特别适合 AI 编程。

长上下文让 Claude Code 更好用

把 Claude Code 或类似工具接到 DeepSeek V4 时，另一个明显优势是长上下文。

AI 编程工具最怕上下文不够。上下文一不够，就要频繁压缩；压缩一多，前面读过的细节就可能丢失。模型开始忘记项目结构、忘记约束、忘记某个文件为什么这么改，后续质量就会下降。

DeepSeek V4 系列的长上下文能力，让它更适合处理代码仓库、文档批处理、字幕翻译、站点文章整理这类任务。特别是接入 Claude Code、OpenClaw 这类工具时，如果配置得当，可以让它尽量晚一点进入上下文压缩，让模型保留更多项目细节。

这也是为什么有些任务用 DeepSeek 会显得“很经使”：它不一定每一步都惊艳，但能承受长时间、低成本、反复调用。

V4 Pro 和 V4 Flash 怎么分工

DeepSeek V4 Pro 和 V4 Flash 不应该混着用。

简单任务用 DeepSeek V4 Flash 更合适。它速度快、成本低，用在下面这些场景通常足够：

翻译字幕；
整理文档；
生成普通脚本；
修改小范围代码；
跑 OpenClaw 里的轻量任务；
做简单的站点内容处理。

复杂任务再考虑 DeepSeek V4 Pro：

大规模重构；
多模块代码理解；
复杂推理；
长链路 agent 任务；
高风险代码修改；
需要更强规划能力的工程任务。

很多人一上来就想挂最强模型，这反而不划算。AI 编程工具最现实的玩法，是把任务分层：便宜模型吃掉大量常规工作，贵模型只处理关键节点。

MiniMax、豆包和 DeepSeek 的位置不同

国产模型和套餐里，MiniMax、豆包、Kimi、DeepSeek 各有位置。

MiniMax 的优势是量大、便宜、功能全。它未必是最聪明的编程模型，但拿来做翻译、轻量整理、批处理，很划算。比如批量处理字幕、改格式、做简单校对，MiniMax 这类套餐很耐用。

豆包的优势是生态工具比较全，图片、视频、搜索、TTS、可能的 STT 和 embedding 都能接在一起。它更像综合型工具箱。

DeepSeek 的位置更明确：文本、代码、长上下文、低成本缓存。它没有完整的图像生成、语音、视频生态，短板很明显；但在 AI 编程和长文本 agent 工作流里，它的长板足够长。

所以不是谁替代谁，而是任务拆开以后各用各的。

省钱的关键不是只找便宜模型

AI 编程想省钱，不是简单把所有请求都换成便宜模型。

真正有效的省钱方式有几条：

简单任务不要启动重 agent。
能用 Flash 的任务不要上 Pro。
长任务尽量利用缓存。
重复上下文要稳定，避免无意义改动导致缓存失效。
大任务先让便宜模型做草稿和批处理，再让强模型做关键审查。
明确告诉 agent 不要重复描述事实，不要反复总结同一件事。

尤其是最后一点很重要。AI 工具很容易啰嗦，啰嗦不只是阅读体验问题，也是成本问题。提示词里明确要求“事实只描述一次，观点只表达一次”，能同时改善文章质量和 token 消耗。

DeepSeek 适合哪类 AI 编程工作流

DeepSeek 最适合这些任务：

长代码仓库阅读；
多文件轻量修改；
批量文档整理；
批量字幕翻译；
Hugo 文章整理；
agent 计划执行；
大量重复上下文的低成本自动化。

它不一定适合所有任务。如果要做特别强的前端审美、复杂产品判断、跨模态创作，可能还要搭配 Claude、GPT、Gemini、豆包或其他工具。

但只要任务是“长文本、长上下文、反复调用、成本敏感”，DeepSeek 就很容易变成首选。

小结

AI 编程工具这一轮，DeepSeek 的价值不只是“国产模型能写代码”，而是它解决了 agent 工具最现实的痛点：长任务太烧钱。

Claude Code、OpenClaw、Superpowers 这类工具会让开发流程越来越自动化，但自动化的背后是大量上下文读写和多轮调用。谁能把这部分成本压下来，谁就能让 AI 编程从“偶尔爽一下”变成“天天用得起”。

DeepSeek 的长上下文、低缓存成本和 V4 Flash / V4 Pro 分层使用，正好让它站在这个位置上。

这一轮真正省钱的关键，不是不用好模型，而是把好模型、便宜模型、缓存和 agent 流程搭配好。能把这套账算明白，AI 编程工具才真的会变成生产力，而不是一个漂亮但昂贵的玩具。

DeepSeek-TUI：在终端里运行 DeepSeek 编程 Agent

Fri, 08 May 2026 13:34:05 +0800

DeepSeek-TUI 是一个运行在终端里的 AI 编程 Agent。它围绕 DeepSeek V4 模型设计，通过 deepseek 命令启动，可以在 TUI 界面里读写文件、执行 shell 命令、搜索网页、管理 git、调用 MCP server，并支持子 Agent 协作。

它和普通聊天 CLI 的区别在于：DeepSeek-TUI 更像一个终端工作台。它不只是把问题发给模型，而是把“看代码、改文件、跑命令、检查诊断、保存会话、恢复状态”这些开发动作整合在一起。

项目仓库显示，DeepSeek-TUI 主要由 Rust 编写，许可证为 MIT。GitHub 项目描述是“Coding agent for DeepSeek models that runs in your terminal”。

它适合谁

DeepSeek-TUI 适合喜欢在终端里工作的开发者，尤其是这些场景：

想用 DeepSeek 模型做代码修改和项目分析。
不想打开完整 IDE，只想在终端里处理任务。
希望 AI 工具能读写本地 workspace。
需要 Plan、Agent、YOLO 这类不同自动化程度的模式。
希望保留会话、恢复长任务、回滚工作区改动。
想接入 MCP、LSP 诊断、HTTP/SSE runtime API 等扩展能力。

如果你只需要简单问答，普通 Web 端或轻量 CLI 已经够用。DeepSeek-TUI 更适合把模型真正放进本地开发流程里。

安装方式

DeepSeek-TUI 发布为 Rust 二进制程序，常用入口命令是 deepseek，配套 TUI 运行时是 deepseek-tui。README 提供了多种安装方式。

如果你已经使用 Node.js，可以通过 npm 安装：

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

npm 包本身是安装器和 wrapper，会下载对应平台的预编译 Rust 二进制文件。npm 包要求 Node.js >=18。

如果不想依赖 Node.js，也可以通过 Cargo 安装两个二进制：

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

macOS 用户可以使用 Homebrew：

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

也可以直接从 GitHub Releases 下载预编译版本。README 中列出的预构建平台包括 Linux x64/ARM64、macOS x64/ARM64 和 Windows x64。

Docker 运行示例：

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

国内网络环境下，如果 npm 或 GitHub 下载较慢，可以使用 npm 镜像、Cargo 镜像，或者从 Releases 手动下载二进制文件。

首次配置 API Key

首次启动时，DeepSeek-TUI 会提示输入 DeepSeek API key。保存后，它会写入：

`1`	`~/.deepseek/config.toml`

也可以提前通过命令配置：

1
2

deepseek auth set --provider deepseek
deepseek auth status

如果更喜欢环境变量，也可以这样启动：

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

配置完成后，可以用下面命令检查环境：

`1`	`deepseek doctor`

如果 deepseek doctor 提示 key 来源异常，可以用 deepseek auth status 查看当前 credential 来源。README 说明中提到，保存到配置文件的 key 优先级高于 keyring 和环境变量。

清除保存的 key：

`1`	`deepseek auth clear --provider deepseek`

Auto mode：自动选择模型和思考强度

DeepSeek-TUI 支持 auto 模式：

`1`	`deepseek --model auto`

也可以在 TUI 里使用：

`1`	`/model auto`

Auto mode 会同时决定两件事：

模型：deepseek-v4-flash 或 deepseek-v4-pro
Thinking：off、high 或 max

它的流程是：真正执行用户任务前，先用一次较小的路由调用分析当前请求和近期上下文，然后决定本轮应该使用哪个模型和思考级别。简单问题可以走 Flash 和低思考；复杂编码、调试、架构、安全审查或多步骤任务可以切到 Pro 或更高 thinking。

需要注意的是，auto 是 DeepSeek-TUI 本地功能。上游 API 不会收到 model: "auto"，而是收到 TUI 最终选择出来的具体模型和 thinking 设置。

如果你要做基准测试、控制成本，或者必须固定某个模型行为，建议直接指定模型，而不是使用 auto。

三种工作模式

DeepSeek-TUI 提供三种模式，自动化程度不同：

模式	用途
Plan	只读探索，模型先分析项目并提出计划
Agent	默认交互模式，工具调用需要 approval gate
YOLO	自动批准工具调用，适合可信 workspace

Plan 模式适合先看项目、定位问题、讨论方案。Agent 模式适合日常编码，模型可以执行多步任务，但关键动作仍有确认。YOLO 模式效率最高，但风险也最大，应该只在你完全信任的仓库和任务里使用。

这类工具能修改本地文件、运行命令，因此不要在不熟悉的目录里随便启用高自动化模式。涉及删除、迁移、批量改写、部署等任务时，最好保持 Agent 模式并看清每一步。

工具能力

根据 README，DeepSeek-TUI 的工具能力覆盖面很广，包括：

文件读写和 apply patch。
shell 命令执行。
git 操作。
web search 和 browse。
子 Agent 协作。
MCP server 接入。
LSP 诊断。
会话保存和恢复。
工作区回滚。
持久化任务队列。
HTTP/SSE runtime API。
skills 系统。

其中比较实用的是 LSP 诊断和工作区回滚。

LSP 诊断可以在编辑后把 rust-analyzer、pyright、typescript-language-server、gopls、clangd 等工具的错误和警告反馈给模型，减少“模型改完但项目编不过”的情况。

工作区回滚通过 side-git 快照记录每轮前后的状态，并提供 /restore 和 revert_turn 一类恢复能力。它不直接操作你仓库本身的 .git，但仍建议在重要仓库里保持正常 git 提交习惯。

常用命令

README 中列出的常用命令包括：

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

这些命令覆盖了交互式 TUI、一次性 prompt、模型指定、会话恢复、HTTP 服务、ACP 适配、PR 预处理、MCP 管理和更新检查。

Zed 和 ACP

DeepSeek-TUI 可以作为 Agent Client Protocol server 被编辑器调用。以 Zed 为例，可以添加自定义 agent server：

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

README 说明中也提醒：当前 ACP 支持新会话和 prompt response，但工具驱动的编辑和 checkpoint replay 还没有通过 ACP 暴露。

配置和多 provider

用户配置文件位于：

`1`	`~/.deepseek/config.toml`

项目级 overlay 可以放在：

`1`	`<workspace>/.deepseek/config.toml`

但 README 说明中明确限制了一些字段不能放进项目 overlay，例如 api_key、base_url、provider、mcp_config_path。这有助于避免把敏感配置随项目提交出去。

DeepSeek-TUI 默认 provider 是 deepseek，也支持 NVIDIA NIM、Fireworks、OpenAI-compatible endpoint、SGLang、vLLM、Ollama 等路径。

例如配置 OpenAI-compatible endpoint：

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

自托管 Ollama 示例：

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

成本和上下文

DeepSeek-TUI 围绕 DeepSeek V4 设计，README 中提到 deepseek-v4-pro 和 deepseek-v4-flash 支持 1M-token context，并且 TUI 会显示 token、成本估算、prefix-cache 命中和未命中等信息。

这对长任务很重要。AI 编程 Agent 往往会不断读文件、总结历史、携带上下文，成本不只取决于模型单价，也取决于它是否能复用 prefix cache、是否及时压缩上下文、是否避免无意义的大段输出。

如果只是轻量改动，deepseek-v4-flash 或 auto mode 可能更合适。复杂重构、长上下文调试和架构分析，再考虑更高 thinking 或 Pro 模型。

由于模型价格和优惠会变化，真正使用前仍建议查看 DeepSeek 官方定价页，以及 TUI 当前版本里的成本估算说明。

使用建议

建议从低风险流程开始：

在一个小型测试仓库里安装并运行 deepseek doctor。
使用 Plan 模式让它只读分析项目。
在 Agent 模式里让它做小范围修改。
每次修改后用 git diff 和测试命令确认结果。
熟悉 /restore、会话恢复和配置路径后，再尝试更长任务。
YOLO 模式只用于你能接受自动修改的临时分支或测试目录。

不要把 API key 写进项目目录，也不要把 ~/.deepseek/config.toml 复制到公共仓库。涉及公司代码时，还要确认模型服务、日志、web search 和第三方 provider 是否符合内部安全要求。

小结

DeepSeek-TUI 是一个功能比较完整的终端 AI 编程 Agent。它把 DeepSeek V4、TUI、工具调用、LSP 诊断、会话恢复、工作区回滚、MCP 和 skills 系统放在同一套 Rust 工具链里，适合愿意在终端里完成 AI 辅助开发的人。

它不是最轻的 DeepSeek 客户端，但它的优势也正在这里：它把“模型对话”推进到“可执行的本地开发流程”。如果你已经习惯 Claude Code、Codex 或其他终端 Agent，那么 DeepSeek-TUI 值得作为 DeepSeek 模型方向的一个重点选择。

参考资料

DeepSeek V4 本地私有化部署方案：国产芯片与消费级显卡集群怎么选

Fri, 08 May 2026 09:39:35 +0800

DeepSeek V4 发布后，很多企业开始关注一个问题：能不能不走外部 API，把模型部署在自己的机房、私有云或专有集群里？

这个需求很现实。金融、医疗、政企、制造、法律和研发团队往往不能把内部文档、代码、合同、工单、客户数据直接发到公有云模型。对这些场景来说，DeepSeek V4 的吸引力不只是模型能力，而是它给了企业一个更接近“可控大模型基础设施”的选择。

不过，DeepSeek V4 本地部署不是下载模型、找几张显卡就能跑起来。尤其是 Pro 这类超大 MoE 模型，总参数规模、激活参数、上下文长度、KV cache、并发量和推理框架都会直接决定硬件成本。企业真正要做的不是盲目追求满血版本，而是先确认业务需要哪种部署形态。

先明确部署目标

企业做本地私有化部署，常见目标有三类：

数据不出域：内部文档、代码、客户资料、日志和知识库不离开企业环境。
稳定可控：模型服务、权限、审计、日志和升级节奏由企业自己掌握。
降低长期成本：高频调用时，本地推理可能比长期购买外部 API 更可控。

如果只是少量员工偶尔问答，本地部署不一定划算。真正适合私有化的是高频、稳定、数据敏感、流程明确的场景，例如：

内部知识库问答。
代码审查和研发助手。
客服工单总结。
合同、病历、报告等文档分析。
数据库查询助手。
Agent 工作流自动化。

这些场景的共同点是：数据敏感、调用稳定、可通过权限和日志纳入企业治理。

不要一上来就追求满血 Pro

DeepSeek V4 常见版本包括 Pro 和 Flash。公开资料中，Pro 面向更强推理和复杂 Agent 任务，Flash 更强调成本和响应速度。企业选型时，不应默认所有业务都上 Pro。

可以按任务复杂度分层：

简单问答、摘要、分类、标签生成：优先考虑 Flash 或更小模型。
内部知识库检索增强：Flash 足够覆盖大量场景，重点反而是 RAG、权限和检索质量。
代码 Agent、复杂推理、长上下文分析：再评估 Pro。
高价值低频任务：可以使用 Pro，但不一定需要高并发。
普通办公助手：没有必要长期占用最贵的推理资源。

MoE 模型的优势在于每次推理只激活部分参数，但它并不等于硬件压力很小。权重存储、专家并行、网络通信、上下文缓存和并发调度仍然很重。尤其是 1M token 级别长上下文，真正吃掉资源的往往不是单次回答，而是长上下文、多用户并发和持续会话。

国产芯片路线：适合企业级私有云

如果企业已经有国产算力池，或者有信创、合规、供应链要求，可以优先评估昇腾、寒武纪等国产芯片路线。

这条路线的优势是：

更符合国产化和供应链可控要求。
适合进入企业机房、专有云和政企项目。
便于统一做权限、审计、资源隔离和运维。
对长期稳定服务更友好。

但国产芯片路线也要看三个现实问题。

第一，框架适配。模型能不能跑，不只取决于芯片算力，还取决于推理框架、算子、通信库、量化格式、MoE 专家并行和长上下文优化是否成熟。

第二，工程经验。企业需要的不只是“启动成功”，而是稳定服务：多租户、限流、监控、失败恢复、灰度升级、日志审计、权限隔离都要补齐。

第三，生态差异。同一套模型在 NVIDIA、昇腾、寒武纪等平台上的性能、精度、量化支持和部署工具不会完全一致。上线前必须做实际压测，而不是只看标称算力。

因此，国产芯片更适合预算明确、合规要求高、愿意投入平台工程的企业。它不是最省事的路线，但可能是最符合长期治理要求的路线。

消费级显卡集群：适合试点和中小团队

如果目标是先验证业务价值，消费级显卡集群更容易起步。RTX 4090、RTX 5090、RTX 3090、RTX 3060 12GB 这类显卡在社区工具、量化模型和本地推理框架上资料更多，试错成本更低。

消费级显卡路线适合：

研发团队做内部试点。
中小企业做知识库问答。
低并发代码助手。
离线文档处理。
对 SLA 要求不高的内部工具。

但它也有明显限制：

显存小，难以直接承载完整大模型。
多卡通信能力弱，跨机器通信更麻烦。
消费级硬件长期满载稳定性不如服务器方案。
机箱、电源、散热、驱动和运维会变成隐性成本。
不适合一开始就承诺企业级高可用。

更现实的做法是：消费级显卡先跑 Flash、蒸馏版、量化版或小模型，把业务流程跑通；等调用量、效果和数据治理都验证后，再决定是否迁移到服务器 GPU 或国产算力平台。

可能的部署架构

一个比较稳的企业私有化架构可以分成六层：

模型层：DeepSeek V4 Pro、V4 Flash，或根据任务选择更小的蒸馏模型。
推理层：SGLang、vLLM、llama.cpp、厂商 NPU 推理栈或企业自研服务。
网关层：统一鉴权、限流、审计、模型路由和调用日志。
知识层：向量库、全文检索、文档解析、权限过滤和 RAG。
应用层：客服、代码助手、文档分析、报表问答、Agent 工作流。
运维层：监控、告警、成本统计、灰度发布、回滚和安全审计。

这里最容易被低估的是网关层和知识层。很多项目失败，不是模型完全不能用，而是权限、检索、日志、上下文管理、提示词模板和业务流程没有做好。

企业内部部署大模型时，应该把模型当作基础能力，而不是一个孤立聊天页面。真正产生价值的是模型进入流程后，能不能稳定处理企业自己的数据和任务。

硬件选型思路

硬件不要只看“能不能跑”，还要看“能不能稳定服务”。

可以按阶段选：

验证阶段

目标是证明业务是否值得做。

使用 1-4 张消费级显卡。
优先跑 Flash、小模型、蒸馏模型或量化模型。
并发要求低，重点看任务完成率。
不承诺高可用。

这个阶段不要过早采购大规模硬件。先确认员工是否真的用、业务是否真的省时间、回答是否能进入流程。

试点阶段

目标是让一个部门或一个业务线稳定使用。

使用 4-16 张 GPU 或一组国产 NPU 节点。
加入统一网关、日志和权限控制。
做 RAG、文档解析、模型路由和缓存。
开始统计 token、并发、延迟和失败率。

这个阶段要开始关注运维。模型效果只是其中一部分，稳定性、成本和数据治理同样重要。

生产阶段

目标是进入企业级服务。

使用服务器 GPU、国产算力集群或私有云资源池。
建立多副本、限流、故障转移和容量规划。
按任务路由模型：简单任务走轻量模型，复杂任务走 Pro。
接入企业身份系统、审计系统和安全策略。

生产阶段不建议所有请求都打到最强模型。合理的模型路由通常比堆硬件更省钱。

推理框架怎么选

DeepSeek V4 这类模型对推理框架要求较高，尤其涉及 MoE、长上下文、稀疏注意力、量化和多卡并行时，框架成熟度会直接影响速度和稳定性。

常见选择可以这样理解：

SGLang：适合关注高性能推理、Agent、多轮工具调用和复杂服务编排的团队。
vLLM：生态成熟，适合通用 LLM 服务，但具体支持要看版本和模型适配进度。
llama.cpp：更适合小模型、量化模型和边缘部署，不适合直接承载满血超大 MoE。
国产 NPU 推理栈：适合信创和国产算力环境，但要重点验证算子、量化和长上下文支持。

框架选择不要只看 benchmark。企业更应该测试自己的真实输入：内部文档长度、并发数、平均输出长度、RAG 命中率、Agent 工具调用次数、失败重试次数。

数据安全要做在模型外面

私有化部署不等于自动安全。模型跑在本地，只是解决了“数据是否离开企业”的一部分问题。

还需要补齐：

账号和权限：不同部门只能访问自己的知识库。
日志审计：谁问了什么、调用了哪个模型、访问了哪些文档。
数据脱敏：客户信息、身份证号、手机号、合同金额等敏感字段要处理。
提示词安全：避免用户通过提示词绕过权限或泄露系统提示。
输出审查：重要场景要有人审或规则审。
数据生命周期：上传文档、向量索引、缓存和会话记录要能删除。

企业做本地大模型，不能只找算法团队。安全、法务、运维、业务负责人都要参与，否则上线后风险会被集中暴露。

成本不要只算显卡

本地部署的成本通常被低估。除了显卡或 NPU，还要算：

服务器、机柜、电源、散热和网络。
存储和备份。
推理框架适配和工程开发。
运维监控和故障处理。
模型升级、回滚和兼容性测试。
安全审计和权限系统。
业务侧提示词、RAG 和工作流建设。

如果调用量很低，外部 API 可能更便宜。如果调用量高、数据敏感、流程稳定，本地部署才更容易摊薄成本。

比较合理的策略是混合部署：

高敏感数据走本地模型。
低敏感通用任务可以走外部 API。
简单任务走小模型。
复杂任务走 DeepSeek V4 Pro。
高频任务优先优化缓存、检索和模型路由。

小结

DeepSeek V4 让企业本地私有化部署有了更强的想象空间，但它不是一个简单的“本地版 ChatGPT”。真正的难点在工程：硬件、框架、模型路由、权限、RAG、审计、监控和成本控制都要一起考虑。

国产芯片路线更适合合规要求高、长期建设私有云的企业；消费级显卡集群更适合试点和中小团队快速验证。Pro 适合复杂推理和 Agent，Flash 或小模型更适合大量普通任务。

如果只记住一句话：DeepSeek V4 私有化部署不要从硬件采购开始，而要从业务场景、数据边界和调用规模开始。先把场景跑通，再决定要不要上大模型、上多大模型、上哪种算力。

参考资料

如何在 Cline 中调用 DeepSeek V4 Pro

Fri, 01 May 2026 20:59:06 +0800

Cline 本身已经支持 OpenAI Compatible Provider。 DeepSeek API 也兼容 OpenAI SDK 风格的调用方式，所以把 deepseek-v4-pro 接到 Cline 里并不复杂：选 OpenAI Compatible，填 DeepSeek 的 Base URL、API Key 和模型名即可。

下面按 VS Code 插件界面和 Cline CLI 两种方式整理。

准备 DeepSeek API Key

先到 DeepSeek 开放平台创建 API Key。

需要准备三个值：

项目	填写内容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek 官方文档说明，V4 系列使用现有 OpenAI 兼容接口，base_url 保持为 https://api.deepseek.com，调用时把 model 设置为 deepseek-v4-pro 或 deepseek-v4-flash。

在 Cline 插件里配置

如果你用的是 VS Code 里的 Cline 插件，可以按这个路径配置：

打开 VS Code 侧边栏里的 Cline。
进入 Cline 的设置或模型配置页面。
Provider 选择 OpenAI Compatible。
API Key 填入 DeepSeek API Key。
Base URL 填：

`1`	`https://api.deepseek.com`

Model ID 填：

`1`	`deepseek-v4-pro`

保存配置，回到 Cline 对话框测试一次简单任务。

可以先让 Cline 做一个低风险测试：

`1`	`请读取当前项目目录结构，并总结这个项目是什么类型，不要修改任何文件。`

如果能正常读取和回答，说明模型链路已经通了。

在 Cline CLI 中配置

如果你使用 Cline CLI，可以用 cline provider configure openai-compatible 进入交互式配置。

示例：

`1`	`cline provider configure openai-compatible`

交互时填写：

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

配置完成后，可以用一个只读任务测试：

`1`	`cline "Summarize this repository structure without changing files."`

如果你希望先降低成本，也可以把 Model ID 临时改成：

`1`	`deepseek-v4-flash`

等遇到复杂规划、事实核查、多工具协作或高风险代码修改时，再切回 deepseek-v4-pro。

模型	适合场景
`deepseek-v4-flash`	日常代码阅读、批量改小问题、生成脚本、整理上下文、低风险前端修改
`deepseek-v4-pro`	架构规划、复杂 bug、跨文件重构、事实核查、多工具调用、高风险改动

上下文长度怎么填

DeepSeek V4 Pro 和 Flash 都支持很长上下文。在 Cline 里如果需要手动填写 context window，可以按 DeepSeek 官方模型页给出的 1M 上下文来理解。

实际使用时不建议一开始就把所有文件都塞进上下文。 Cline 会按任务读取文件，通常更好的方式是：

先让它看目录结构；
再让它定位相关文件；
最后只围绕目标文件执行修改。

这样更省 Token，也更容易保持任务边界清晰。

常见问题

1. 提示模型不存在

先检查 Model ID 是否写成：

`1`	`deepseek-v4-pro`

不要写成 DeepSeek V4 Pro、deepseek-v4 或其他显示名称。

2. 提示 401 或认证失败

检查 API Key：

是否复制完整；
是否带了多余空格；
是否填到了 Cline 当前正在使用的 provider 配置里；
DeepSeek 账户是否有可用额度。

3. 提示连接失败

检查 Base URL：

`1`	`https://api.deepseek.com`

不要在末尾额外拼 /v1/chat/completions。 Cline 的 OpenAI Compatible Provider 会自己按兼容接口组织请求。

4. Cline 调用很贵怎么办

可以先把日常任务切到 deepseek-v4-flash，只在复杂任务里使用 deepseek-v4-pro。

另外，尽量把任务描述写清楚：

`1`	`只修改登录页相关文件，不要重构无关模块。先给出计划，确认后再改代码。`

Agent 任务最怕边界不清。边界越清楚，读文件越少，工具调用越少，成本也越可控。

5. 报错 reasoning_content must be passed back

如果你看到类似错误：

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

这通常不是 Key、额度或 Base URL 的问题，而是 DeepSeek V4 Pro 的 thinking mode 和当前客户端的多轮工具调用记录没有对齐。

DeepSeek 官方文档说明：

thinking mode 默认是 enabled；
thinking mode 下会返回 reasoning_content；
如果某一轮发生了 tool call，后续请求必须把该轮 assistant message 里的 reasoning_content 一起传回 API；
如果客户端没有正确回传，就会返回 400。

Cline 通过 OpenAI Compatible Provider 接入时，如果当前版本没有完整保留并回传 DeepSeek 的 reasoning_content，就可能在第二轮或工具调用后触发这个错误。

可尝试的处理顺序：

先升级 Cline 到最新版；
确认使用的是 OpenAI Compatible，而不是普通 OpenAI provider；
如果 Cline 支持自定义 request body，尝试关闭 thinking mode：

{
  "thinking": {
    "type": "disabled"
  }
}

如果 Cline 不支持额外 body 参数，暂时改用不触发该问题的模型或服务中转；
等 Cline 适配 DeepSeek V4 的 reasoning_content 回传后，再切回 deepseek-v4-pro。

需要注意：关闭 thinking mode 会牺牲一部分复杂推理能力，但可以绕开客户端没有回传 reasoning_content 的兼容性问题。

一个可直接复制的配置清单

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

如果要低成本模式：

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

小结

在 Cline 中调用 DeepSeek V4 Pro 的关键只有三步：

Provider 选择 OpenAI Compatible；
Base URL 填 https://api.deepseek.com；
Model ID 填 deepseek-v4-pro。

配置完成后，建议先用只读任务测试，再逐步交给它执行真实代码修改。如果你经常跑 Agent 任务，可以把 Flash 和 Pro 分开用：Flash 负责高频轻量任务，Pro 负责复杂判断和兜底。

参考来源：

DeepSeek V4 降价如何改写 AI Agent 的成本模型

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 发布时没有制造出特别夸张的声量。没有大型发布会，也没有一眼碾压所有对手的跑分叙事。但几天之后，它真正影响行业的地方开始显现：连续降价。

这次变化的重点不是“模型强了一点”，而是“使用成本被打到另一个层级”。当 Token 价格低到普通 Agent 任务几毛钱、一两块钱就能跑完时，很多 Coding Plan、Token Plan 的商业逻辑都会被重新审视。

发布当天没有炸场

DeepSeek V4 的第一波反馈并不算热烈。很多人期待它像 R1 那样带来强烈冲击：跑分全面领先、国产算力验证、多模态和 Agent 能力一起爆发。但真正发布后，大家发现它更像一次稳健升级。

V4 Pro 确实是强模型，尤其在代码、数学、长上下文和 agentic coding 上表现不错。但它不是那种让所有同类模型瞬间失色的产品。所以发布当天，舆论一度有些尴尬：想夸，但很难找到一个足够爆炸的角度。

真正的转折点不是发布当天，而是后续价格调整。

连续降价才是关键

DeepSeek V4 发布后，价格开始连续下探。按照 DeepSeek 官方价格页和原文整理的信息，当时的大致价格是：

DeepSeek V4 Flash：输入 100 万 Token 约 1 元；缓存命中后 100 万 Token 约 2 分钱；
DeepSeek V4 Pro：输入 100 万 Token 约 3 元；缓存命中后 100 万 Token 约 2.5 分；
全系列模型输入缓存命中价格降到首发价格的 1/10；
V4 Pro 曾处在 2.5 折优惠期，优惠延长到 2026 年 5 月 31 日 23:59。

如果按美元 API 价格看，会更直观：

模型	缓存命中输入	非缓存输入	输出	上下文
`deepseek-v4-flash`	$0.0028 / 100万 Token	$0.14 / 100万 Token	$0.28 / 100万 Token	1M
`deepseek-v4-pro` 促销价	$0.003625 / 100万 Token	$0.435 / 100万 Token	$0.87 / 100万 Token	1M
`deepseek-v4-pro` 原价	$0.0145 / 100万 Token	$1.74 / 100万 Token	$3.48 / 100万 Token	1M

这里要注意两个点。

第一，V4 Pro 的 $0.435 / $0.87 是促销价，不是长期原价。 DeepSeek 官方说明里，这个 75% 折扣延长到 2026 年 5 月 31 日 15:59 UTC。

第二，缓存命中价格才是 Agent 成本模型里的关键。 Flash 的缓存命中输入低到 $0.0028 / 100万 Token，Pro 促销期缓存命中输入是 $0.003625 / 100万 Token。这意味着大量重复项目上下文、工具定义、系统提示词和历史摘要，不再按完整输入价格计费。

这个价格最重要的地方，是它让很多任务的 Token 成本变得“不敏感”。过去开发者会担心一次 Agent 任务吃掉大量上下文、反复读写代码、频繁调用工具。现在只要缓存命中率足够高，成本会被压得很低。

和 GPT、Claude 的价格对比

只看 DeepSeek 自己的价格，还不容易感受到差距。把它和同期常见的闭源模型放在一起，对比会更明显。

模型	输入	缓存输入	输出	适合场景
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高频 Agent、常规 coding、批量任务
`deepseek-v4-pro` 促销价	$0.435 / M	$0.003625 / M	$0.87 / M	复杂 coding、规划、事实核查
`deepseek-v4-pro` 原价	$1.74 / M	$0.0145 / M	$3.48 / M	促销结束后的 Pro 成本基准
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高质量复杂任务、通用推理
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	编程和专业任务的中档选择
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	成本更低的通用/子任务模型
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高质量写作、复杂推理、长任务
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	编程、Agent、综合任务
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	轻量任务、摘要、分类

这张表里最刺眼的是输出价格。 Agent 不只读上下文，还会不断生成计划、补丁、解释、日志和下一步动作。如果输出很多，DeepSeek V4 Pro 促销价的 $0.87 / M 和 GPT-5.5 的 $30 / M、Claude Sonnet 4.6 的 $15 / M 相比，差距会被不断放大。

即使按 V4 Pro 原价 $3.48 / M 输出算，它也明显低于 GPT-5.4、GPT-5.5 和 Claude Sonnet / Opus。如果任务可以用 Flash 承担，输出价会进一步降到 $0.28 / M。

缓存输入差距更夸张。 DeepSeek V4 Flash 的缓存输入是 $0.0028 / M，而 GPT-5.5 和 Claude Opus 4.7 的缓存输入都是 $0.50 / M。这不是同一个数量级。对反复读取同一代码仓库的 Agent 来说，这个差距比普通聊天更重要。

Agent 任务为什么特别受影响

AI Agent 和普通聊天不一样。普通聊天通常是一问一答，输入上下文相对有限。 Agent 任务会反复读取项目文件、生成计划、调用工具、检查结果、再修改代码。

这类任务有两个特点：

Token 消耗大；
重复上下文多。

第二点很关键。在代码项目里，模型会反复读取同一批文件、目录结构、错误日志和修改结果。如果平台支持缓存命中，重复输入的成本会大幅下降。

原文里提到一次实际体验：把 DeepSeek V4 Pro 和 Flash 接到 Claude Code 一类工具中，让它拉取一个提示词仓库并做成本地搜索网站。任务最终完成，总成本大约 8 毛多，其中 Pro 缓存命中率达到 98.7%。

这个例子说明了一个现实问题：Agent 任务越像“围绕同一个项目反复工作”，缓存命中越有价值。如果一次生成网站、修 bug、改前端只花几毛钱到几块钱，订阅套餐的吸引力就会下降。

可以用一个简化任务估算差距。假设一次 coding agent 任务包含：

50 万 Token 输入，其中 80% 能命中缓存；
5 万 Token 输出；
不计算工具调用、搜索和平台加价，只看模型 Token 成本。

大致成本如下：

模型	估算成本
DeepSeek V4 Flash	约 $0.03
DeepSeek V4 Pro 促销价	约 $0.09
DeepSeek V4 Pro 原价	约 $0.36
GPT-5.4 mini	约 $0.30
GPT-5.4	约 $1.01
GPT-5.5	约 $1.75
Claude Sonnet 4.6	约 $1.11
Claude Opus 4.7	约 $1.65

这个估算不是说 DeepSeek 在所有任务上都更好。模型质量、工具调用稳定性、长上下文检索能力、代码风格和事实可靠性都要单独评估。但从成本上看，DeepSeek V4 把“让 Agent 多跑几轮”的边际成本压得很低。这会鼓励开发者设计更长流程、更频繁的自检和更多候选方案，而不是每次都担心 Token 账单。

Coding Plan 和 Token Plan 的差别

很多 AI 产品现在会提供两类套餐：Coding Plan 和 Token Plan。

它们的差别大致是：

Coding Plan 通常主要面向编程；
Token Plan 通常覆盖更多能力，例如 STT、TTS、绘图、搜索、embedding、RAG；
STT 是语音转文字；
TTS 是文字转语音；
Coding Plan 往往把用户限制在编程场景里，其他能力还需要另买。

从商业角度看，Coding Plan 更像自助餐。用户预先付一笔固定费用，厂商赌的是大多数人不会把额度用满。有人用得多，有人用得少，平均下来平台仍然能赚钱。

但如果按量 Token 价格足够低，用户就会开始计算：我为什么一定要买套餐？如果一个月真实使用成本只有几块钱、十几块钱，买 40 元、200 元的套餐就不一定划算。

降价为什么会冲击套餐模式

订阅套餐的成立，需要一个前提：用户觉得单次使用很贵，或者不想计算每次调用成本。当 Token 价格高时，套餐看起来更安心。当 Token 价格低到几乎无感时，按量付费反而更自然。

DeepSeek V4 的降价相当于把底牌亮出来：

Agent 任务可以很便宜；
长上下文不一定贵到不能用；
缓存命中可以显著降低成本；
普通开发者不一定需要固定订阅；
模型入口可以从“套餐平台”转向“低价 API”。

这会让做 Coding Plan 的平台不舒服。如果用户发现按量调用更便宜、更自由，就没必要为了一个平台的套餐被绑定。

Flash 和 Pro 怎么选

DeepSeek V4 的一个实用思路，是把 Flash 和 Pro 分工使用。

Flash 适合高频、轻量、可重复的任务：

改 bug；
写前端；
写脚本；
做常规代码理解；
处理较长上下文里的普通信息整理；
跑大量子任务。

Flash 便宜，速度快，而且同样支持很长上下文。对日常 coding agent 来说，很多任务不需要一上来就用 Pro。

Pro 更适合复杂判断和兜底任务：

多轮规划；
复杂 Agent 流程；
多次 function call；
事实核查；
财经研究；
需要更强知识和判断力的内容生产；
高风险代码修改。

一个合理配置是：Flash 负责跑量，Pro 负责兜底。普通任务先用 Flash，遇到长程规划、复杂判断、事实核查或多工具协作时再切 Pro。这样既能控制成本，也能保留模型质量。

DeepSeek 为什么可以这么定价

DeepSeek 和很多大厂的业务结构不同。它没有电商、社交、短视频、云计算、手机、汽车、办公套件、操作系统、浏览器或大规模企业 SaaS 生态。

这意味着它不需要把用户锁在一个完整平台里。它可以只卖文本模型能力：你在这里用便宜的文本模型，其他能力要调用谁都可以。

大厂的逻辑通常不同。如果你买了它的 Coding Plan 或 Token Plan，就会被拉进它的云、搜索、绘图、语音、数据库和开发工具生态。套餐不是单纯卖模型，而是在争夺用户入口。

DeepSeek 的打法更直接：把文本模型价格压低，争取成为 Agent 的默认模型入口。只要默认入口被占住，很多开发者和工具链就会自然围绕它适配。

开源模型和默认入口

DeepSeek V4 如果保持开放模型路线，第三方云厂商和平台很可能会自行部署并提供服务。这对 DeepSeek 来说既是传播，也可能是分流。

低价官方 API 的意义就在这里。如果官方价格已经足够低，其他平台即使能部署，也很难在价格上明显更有优势。用户会倾向于直接使用默认、便宜、稳定的入口。

对 Agent 工具尤其如此。 Agent 任务依赖长上下文、缓存、工具调用和稳定吞吐。一旦某个模型在这些场景里成本足够低，它就有机会成为默认选项。

Coding Plan 仍然不是完全没用

这并不意味着 Coding Plan 会马上消失。它仍然有适合的人群。

如果某些用户真的是高强度使用者，每天把套餐额度打满，那么固定订阅可能仍然划算。就像自助餐，如果完全没有人能吃回本，用户也不会愿意买。

但问题在于，绝大多数用户不是这种极端高频用户。低频用户、轻量开发者、偶尔写脚本或改项目的人，更适合按量付费。当 DeepSeek 把按量成本压低后，套餐的吸引力会被削弱。

未来更可能出现的是分层选择：

高频重度用户继续买 Coding Plan；
普通用户转向低价 API；
Agent 工具根据任务自动选择 Flash / Pro；
平台套餐需要提供更多非模型价值，例如工作流、IDE 集成、部署、团队管理和安全审计。

小结

DeepSeek V4 的发布并没有靠跑分制造最大冲击。真正改变行业预期的是后续降价。

当输入 Token 和缓存命中价格被压到很低时，AI Agent 的使用成本会发生变化。过去看起来昂贵的长上下文、代码项目分析、多轮工具调用，现在可能变成几毛钱到几块钱的日常消耗。

这会直接冲击 Coding Plan 和 Token Plan 的商业逻辑。如果用户可以按量付费、自由组合模型和工具，而且成本足够低，就不一定愿意被绑定在某个平台套餐里。

DeepSeek V4 这次真正动到的，不只是模型能力排名，而是 AI Agent 的成本结构和默认入口之争。

参考来源：

free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型

Fri, 01 May 2026 03:41:49 +0800

free-claude-code 是一个给 Claude Code 使用的 Anthropic-compatible proxy。

它的思路不是破解 Claude Code，也不是提供官方免费的 Claude 服务，而是在本地启动一个兼容 Anthropic API 形状的代理服务，把 Claude Code 发出的请求转发到其他模型后端。README 中提到的后端包括 NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp 和 Ollama。

简单说，它想解决的是：你喜欢 Claude Code 的终端体验，但希望把模型请求接到别的 provider 或本地模型上。

它解决什么问题

Claude Code 的交互体验很适合开发任务。

它可以在终端里阅读代码、修改文件、执行命令、根据项目上下文推进任务。问题是，很多用户并不一定想始终使用同一个模型后端：

想试试 OpenRouter 上的不同模型
想用 DeepSeek 这类模型降低成本
想把请求接到本地 Ollama
想用 LM Studio 或 llama.cpp 跑本地模型
想在开发环境里统一走一个代理入口
想比较不同模型在 Claude Code 工作流里的表现

free-claude-code 的定位，就是在 Claude Code 和这些模型服务之间加一层兼容代理。

这样 Claude Code 仍然按 Anthropic 风格发请求，代理负责把请求适配到不同后端。

工作方式

可以把它理解成三层：

前端是 Claude Code
中间是 free-claude-code 代理
后端是 OpenRouter、DeepSeek、本地模型或其他模型服务

Claude Code 以为自己在访问一个 Anthropic-compatible API。

代理收到请求后，根据配置选择目标 provider，转换必要字段，再把响应返回给 Claude Code。

这类结构的好处是，你不用改 Claude Code 本身，也不用让每个模型服务都原生支持 Claude Code。只要代理能把接口对齐，就能把更多模型接进同一个工作流。

支持哪些后端

README 中列出的方向包括：

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

这些后端代表了几类不同使用方式。

OpenRouter 更像模型聚合入口，可以测试不同商业和开源模型。

DeepSeek 适合关注中文能力、代码能力和成本的人。

LM Studio、llama.cpp、Ollama 则偏本地模型路线。它们适合在自己的机器或内网环境里运行模型，减少外部 API 依赖，也方便做离线实验。

NVIDIA NIM 则更偏企业和 GPU 推理部署场景。

为什么是 Anthropic-compatible proxy

Claude Code 本来围绕 Anthropic 的接口和模型习惯设计。

如果你想让它接入其他模型，最直接的问题就是接口不一致：

请求字段不同
模型名称不同
streaming 格式不同
tool use 表达不同
错误返回格式不同
token 和上下文限制不同

代理层的价值就在这里。

它把 Claude Code 这边看到的接口维持在接近 Anthropic 的形状，再在后端做适配。对用户来说，配置一次代理后，就可以在相同 Claude Code 工作流里测试不同模型。

适合什么场景

free-claude-code 适合这些场景：

想用 Claude Code 的终端工作流
想测试非 Anthropic 模型在 Claude Code 里的表现
想降低模型调用成本
想把 Claude Code 接到 OpenRouter
想接入 DeepSeek 等兼容模型服务
想用 Ollama、LM Studio、llama.cpp 跑本地模型
想为团队统一配置一个模型代理入口

如果你只是正常使用官方 Claude Code，并且对模型提供方、成本和本地部署没有特殊需求，那不一定需要这类代理。

但如果你经常比较模型，或者希望让 Claude Code 接入本地和第三方模型，这类工具会很有用。

和直接用 OpenRouter 或 Ollama 有什么区别

直接用 OpenRouter、Ollama 或 LM Studio，通常只是和模型聊天，或者通过 API 调用模型。

free-claude-code 的重点不是替代这些服务，而是把它们接到 Claude Code 这个开发工作流里。

区别在于：

你仍然使用 Claude Code 的终端体验
AI 可以围绕代码仓库执行任务
模型后端可以换成其他 provider
本地模型也有机会进入 Claude Code 工作流
配置集中在代理层，而不是每个工具单独改

所以它更像桥接器，而不是新的聊天客户端。

本地模型要注意什么

把 Claude Code 接到本地模型很有吸引力，但也要注意现实限制。

第一，模型能力差距。

Claude Code 的任务通常不只是聊天，还包括理解代码、规划修改、编辑文件、处理命令输出。本地小模型不一定能稳定完成这些任务。

第二，上下文窗口。

代码任务很吃上下文。模型上下文太小，会导致它读不全文件、漏掉约束，或者在多轮任务里丢失背景。

第三，tool use 兼容性。

Claude Code 工作流依赖工具调用和结构化行为。后端模型即使能聊天，也未必擅长遵循工具调用协议。

第四，速度和硬件。

本地模型的速度取决于机器配置、量化方式和模型大小。代码任务如果响应太慢，体验会明显下降。

所以，本地模型更适合实验、低风险任务和特定场景。真正复杂的代码任务，仍然要根据模型能力谨慎选择。

使用边界

这类项目很容易被标题误解，所以边界要说清楚。

第一，它不是官方 Claude Code 免费额度。

它只是把 Claude Code 的请求转发到其他模型后端。你使用 OpenRouter、DeepSeek、NVIDIA NIM 或其他 API 时，仍然需要遵守对应服务的价格、额度和使用条款。

第二，它不是绕过授权的工具。

使用任何代理工具时，都应该遵守 Claude Code、模型服务商和项目本身的许可协议。不要把它理解成规避官方限制的方式。

第三，代理会处理你的请求内容。

代码、命令输出、项目上下文可能会经过代理和后端服务。部署时要考虑日志、密钥、网络和隐私边界。涉及公司代码或敏感项目时，最好使用受控环境。

第四，不同模型表现差异会很大。

同样的 Claude Code 操作，换一个模型后可能出现完全不同的行为。不要默认所有模型都能替代 Claude。

和 LiteLLM 这类代理有什么关系

从思路上看，free-claude-code 属于“兼容接口代理”这一类工具。

这类工具的共同目标是减少上层应用和底层模型服务之间的耦合。上层应用只需要面对一个相对统一的接口，底层 provider 可以按配置切换。

不同项目的侧重点不同。有的更偏通用模型网关，有的更偏 OpenAI-compatible API，有的专门为 Claude Code 这类工具做适配。

free-claude-code 值得关注的地方，是它把目标场景直接放在 Claude Code 上，而不是做一个泛泛的聊天代理。

适合怎样的用户

它更适合有一定折腾能力的用户：

熟悉 Claude Code
知道 API key 和模型 provider 怎么配置
能理解代理服务的启动和环境变量
能排查网络、端口、模型名称和 streaming 问题
愿意比较不同模型在代码任务里的表现

如果你只想开箱即用，官方配置通常更省心。

如果你愿意搭代理、换模型、调参数，并且想让 Claude Code 进入更多模型环境，这个项目就值得研究。

参考

Alishahryar1/free-claude-code

最后一句

free-claude-code 的价值，不在于“免费”这个词，而在于它把 Claude Code 和更多模型后端之间接了一座桥。

当你想保留 Claude Code 的开发体验，同时测试 OpenRouter、DeepSeek、本地模型或企业推理服务时，这类 Anthropic-compatible proxy 就有了用武之地。

DeepSeek V4 Pro 对比 GPT-5.5：前端、写作、代码实测后，差距比想象更大

Sat, 25 Apr 2026 11:12:00 +0800

DeepSeek V4 Pro 和 GPT-5.5 这种对比，最近越来越容易引发讨论。因为它已经不是“谁能不能用”的问题，而是：当任务落到前端、写作、代码这三类高频场景时，谁更适合当主力？

很多人做这类比较时，习惯先问一句：哪个更强。
但更有价值的问题通常不是这个，而是：在具体任务里，哪个更稳、哪个更省沟通成本、哪个更容易产出能直接继续推进的结果。

如果先给一个简化版结论，可以大致这样理解：

需要更均衡、产品化体验更完整的综合输出时，很多人还是会先看 GPT-5.5
需要中文语境下高频迭代、成本更敏感、追求响应效率时，DeepSeek V4 Pro 会更容易进入候选名单
真正决定体验的，往往不是模型名字本身，而是任务类型、提示方式和你后续要不要继续改

下面按三个最常见的比较场景展开。

1. 前端任务：比的不是“会不会写页面”，而是能不能继续接着改

前端任务看起来很适合拿来做模型对比，因为它结果直观：
页面能不能跑、样式好不好看、结构清不清楚，一眼就能看到。

但真正拉开差距的，往往不是第一版能不能写出来，而是后续这些问题：

结构是不是足够清晰
组件拆分是否自然
改一处时会不会连带改坏别的地方
能不能在多轮指令下继续保持同一套实现思路

这也是为什么很多“首轮效果惊艳”的前端演示，放进真实工作流后未必依然占优。

如果你的任务是：

快速生成一个可运行的页面原型
把一个落地页思路先写出来
按要求补齐样式、按钮、卡片、表单等基础元素

那两类模型通常都能完成得八九不离十，区别更多体现在输出风格。

而如果你的任务变成：

持续多轮改 UI
一边读现有代码一边接着改
同时兼顾组件结构、样式一致性和可维护性
从静态页面逐步推进到真实项目代码

那你更应该观察的就不是“第一轮谁更像样”，而是“谁在第五轮以后还不容易跑偏”。

所以前端对比真正该看的，不是模型能不能生成页面，而是它能不能在你连续追加约束之后，依旧保持结构稳定、命名一致、修改成本可控。

2. 写作任务：比的不是字多不多，而是风格稳不稳、重写顺不顺

写作是另一类特别容易出现误判的场景。

因为很多时候，模型第一次输出看起来都不差：
结构完整、段落齐全、语气顺滑，乍看之下很容易觉得“差不多”。

但只要你把任务往前推一步，差异就会冒出来：

能不能准确理解你要的受众
能不能在同一主题下切换不同口吻
重写时会不会丢掉原文重点
压缩、扩写、改标题、换结构时是否稳定

写作任务里最怕的不是“写不出来”，而是“看起来写出来了，但你还得重改很多遍”。

所以在 DeepSeek V4 Pro 和 GPT-5.5 之间，更实用的比较方式通常不是让它们各写一篇，而是连续做这几轮：

先写初稿
再换一个语气重写
再压缩成更短版本
再改成更适合标题党或搜索分发的写法

如果一个模型在这几轮里仍然能保持重点不散、表达不飘、结构不乱，那它在真实写作工作流里的价值才会更高。

也就是说，写作任务真正比的不是“文采”，而是改稿能力、服从度和连续协作感。

3. 代码任务：真正拉开差距的是长链路稳定性

代码任务比前端任务更容易暴露模型真实水平，因为它不仅要“输出”，还要“对接现实”。

你很快就会遇到这些问题：

它能不能理解已有项目结构
能不能同时修改多个文件
改完以后有没有引入新的问题
出错时会不会顺着日志继续往下查
多轮之后还记不记得前面已经做过什么

这类任务里，用户最在意的通常不是某一段代码漂不漂亮，而是：能不能帮我持续往前推进，而不是让我来收拾残局。

所以比较 DeepSeek V4 Pro 和 GPT-5.5 时，最值得看的往往不是单点题，而是这种更接近真实工作的过程：

读一个已有仓库
找到一个 bug
改多个相关文件
根据报错继续修
最后把结果整理清楚

只要任务进入这种连续推进模式，模型的上下文保持能力、执行习惯、解释质量和返工率，都会比“单轮答题效果”更重要。

这也是为什么很多用户在代码场景里，最终形成的不是“永远只用一个模型”，而是按任务阶段切换主力。

4. 真正值得比较的，不是输赢，而是“哪类任务交给谁更划算”

把 DeepSeek V4 Pro 和 GPT-5.5 放在一起时，如果目标只是争一个总冠军，最后往往会得到一个很空的结论。

因为现实任务不是统一题目：

有的是一次性生成
有的是多轮协作
有的是中文写作
有的是工程改动
有的是强调速度
有的是强调稳定性
有的是强调成本

所以更接近真实使用的方法，通常是按任务目标分：

想要更完整的综合体验、更成熟的交互和更稳定的通用输出，可以优先试 GPT-5.5
想要在中文环境里高频试错、快速迭代，并且更关注投入产出比，DeepSeek V4 Pro 值得重点放进工作流里
如果任务本身是长链路、多轮修正、多人协作，那就不要只看第一轮结果，要看五轮以后谁还更稳

换句话说，真正该问的不是“谁绝对更强”，而是：
前端、写作、代码这三类任务里，哪一个模型更像你当前阶段最顺手的工具。

5. 怎么做一次更像样的模型对比

如果你自己也准备测 DeepSeek V4 Pro 和 GPT-5.5，一个更靠谱的做法通常不是只跑一轮，而是这样测：

给两边同一份初始需求
保持相同限制条件
连续追问三到五轮
记录改动质量、跑偏次数和返工量
最后再看速度、成本和最终可用度

这样测出来的结果，会比“谁第一轮更惊艳”更接近真实工作。

尤其在前端、写作、代码这三类任务里，很多时候真正决定体验的不是起跑线，而是谁能陪你把事情做完。

6. 可以先这样记

如果只想先记一个够用的版本，可以先这么理解：

GPT-5.5：更像综合型、产品化、默认可用的主流工作台
DeepSeek V4 Pro：更像在中文环境和高频试错里更值得纳入日常工作流的竞争者
真正的比较重点：不是首轮炫技，而是多轮修改之后谁更稳、谁更省事

所以这类对比里，真正重要的从来都不是“谁赢了”，而是：
你的前端、写作、代码任务，交给谁之后最容易持续推进、最少返工、最能稳定产出。

DeepSeek-V4 Preview 发布：1M 上下文、双模型与 API 切换提醒

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek 在 2026-04-24 发布了 DeepSeek V4 Preview Release。从官方新闻页来看，这次更新的重点非常集中：1M context、V4-Pro 与 V4-Flash 双模型、对 Agent 场景的专门优化，以及 API 侧的模型切换。

如果只看一句话，这次发布的核心信号是：DeepSeek 不只是继续做更强的模型，而是在把超长上下文和 Agent 能力一起往“可直接上线使用”的方向推进。

1. 这次一共发布了什么

官方页面里，DeepSeek-V4 Preview 主要包含两条产品线：

DeepSeek-V4-Pro
DeepSeek-V4-Flash

对应的官方描述也很直接：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

从命名就能看出来，这次不是单模型升级，而是把高性能版本和更高性价比版本同时推了出来。

其中 V4-Pro 更强调上限，官方说它的表现已经可以和全球顶级闭源模型竞争；V4-Flash 则更强调速度、效率和成本，更适合对响应速度和 API 成本更敏感的场景。

2. `1M context` 是这次最突出的卖点

官方页面最醒目的表述之一，就是：“Welcome to the era of cost-effective 1M context length.”

DeepSeek 这次不只是说“支持长上下文”，而是明确把 1M context 当成这代模型的默认能力来讲。页面里也写得很清楚：

1M context 已经成为官方 DeepSeek 服务的默认标准
V4-Pro 和 V4-Flash 都支持 1M context

这件事的意义不只是“能塞更多 token”。它更直接影响下面这些任务：

长代码仓库理解
长文档问答和资料整合
多轮 Agent 工作流
跨多文件、多工具、多阶段的复杂任务

如果上下文窗口足够大，模型就更不容易因为中途丢上下文而反复回读材料，这对 Agent 编码和复杂知识工作会特别重要。

3. `V4-Pro` 主要在强调什么

从官方页的措辞看，DeepSeek-V4-Pro 重点强调三件事：

Agentic Coding 能力
世界知识
推理能力

页面里提到，V4-Pro 在 Agentic Coding benchmark 上达到开源 SOTA；在世界知识方面领先当前开源模型，仅落后于 Gemini-3.1-Pro；在数学、STEM 和编码能力上超过当前开源模型，并且可以和顶级闭源模型竞争。

换句话说，V4-Pro 的定位并不是单纯回答问题，而是更偏向高难度推理、复杂编码和长任务执行。

4. `V4-Flash` 并不是简单的缩水版

另一个值得注意的点是，官方没有把 V4-Flash 包装成“低配模型”，而是强调它在很多实际任务里已经足够强。

按照新闻页给出的说法，V4-Flash：

推理能力已经很接近 V4-Pro
在简单 Agent 任务上与 V4-Pro 表现相当
参数规模更小，响应更快，API 定价更便宜

这意味着 DeepSeek 这次给出的并不是“一个旗舰、一个入门”的非常割裂的组合，而更像是：

V4-Pro：追求更高性能和更强上限
V4-Flash：追求更低延迟和更好成本效率

对于开发者来说，这样的组合会更实用，因为很多线上任务真正需要的不是“理论最强”，而是“够强、够快、够省”。

5. 官方特别强调了 Agent 优化

这次发布页里还有一个很明确的方向：DeepSeek 在主动把 V4 往 Agent 场景上推。

官方页面提到，DeepSeek-V4 已经和一些主流 AI Agent 深度集成，包括：

Claude Code
OpenClaw
OpenCode

同时 DeepSeek 也提到，V4 已经在内部 agentic coding 场景中使用。

这说明它想覆盖的，不再只是聊天或普通补全，而是更长链路的工作方式：读代码、理解结构、调用工具、生成结果，再把整条流程串起来。

如果你最近正好在关注 coding agent，这个信号值得留意。因为它意味着模型厂商已经不再只拼 benchmark，而是在拼“能不能真正接进工作流”。

6. 底层结构创新在为长上下文服务

在技术描述上，官方页把这次的结构创新总结为：

token-wise compression
DSA (DeepSeek Sparse Attention)

页面给出的方向非常明确：目标是把长上下文做得更便宜、更高效，尽量降低计算和显存成本。

虽然新闻页没有展开完整技术细节，但这至少说明 DeepSeek 这次不是单纯靠“更大算力硬堆更长窗口”，而是在结构层面针对长上下文效率做了专门优化。

对实际使用者来说，这通常比单纯“窗口数字变大”更重要，因为真正决定可用性的，不只是能不能开到 1M，还包括：

速度是否还能接受
成本是否还能接受
长上下文任务是否真的稳定

7. API 已经可用，但要注意模型切换

官方页面明确写到，这次 API 当天就已经可用。

接入方式也比较简单：

base_url 保持不变
把模型名切换为 deepseek-v4-pro 或 deepseek-v4-flash

同时页面说明，这两个模型都支持：

1M context
Thinking / Non-Thinking 双模式
OpenAI ChatCompletions
Anthropic APIs

这意味着如果你原本已经接了 DeepSeek API，升级门槛并不高，主要是模型名切换和能力验证。

8. 旧模型的退役时间也写得很明确

对开发者来说，这次新闻页里最不能忽略的信息之一，其实是旧模型退役提醒。

官方写明：

deepseek-chat
deepseek-reasoner

会在 2026 年 7 月 24 日 15:59（UTC） 后完全退役并不可访问。

页面还说明，当前这两个模型实际上已经路由到 deepseek-v4-flash 的非思考 / 思考模式。

这意味着如果你的项目里还直接写着 deepseek-chat 或 deepseek-reasoner，现在就应该开始安排迁移，而不要拖到正式下线前再处理。

9. 这次发布值得怎么理解

如果把这次更新浓缩成几个重点，大概可以这样看：

DeepSeek 开始把 1M context 从“高配能力”变成默认标准
双模型路线更清晰：一个冲性能上限，一个冲速度和性价比
Agent 能力已经被放到很核心的位置
API 升级路径相对直接，但旧模型退役时间需要尽快关注

对普通使用者来说，最直观的变化可能是：长文档、长代码、长流程任务会更容易放进一次上下文里。
对开发者来说，更重要的是：如果你已经在做 Agent、代码助手、资料整理、复杂工作流，这一代模型显然就是朝这些场景设计的。

DeepSeek 这次发布，不只是一次常规模型更新，更像是在明确它下一阶段的产品方向：超长上下文 + Agent 优化 + 更实际的 API 可用性。

DeepSeek on KnightLi的博客

让 Codex 使用 DeepSeek 模型的两种方法：本地网关和 OpenRouter BYOK

方法一：用本地网关桥接 DeepSeek

方法二：用 OpenRouter BYOK 做线上桥接

要不要继续用 deepseek-chat 这个模型名？

直接改 DeepSeek 官方 base_url 为什么不推荐

改完配置后还是走 OpenAI 怎么办

排障清单

结论

DeepSeek-TUI：把 DeepSeek V4 变成终端里的编程智能体

它解决的是 DeepSeek 的使用入口问题

TUI 比纯命令行更适合长任务

Auto 模式适合明确边界的任务

子智能体的意义在于拆任务

1M 上下文不是万能，但很适合读项目

更适合哪些用户

需要关注的风险

总结

本地运行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的尝试

ds4 是什么

为什么值得关注

适合谁用

使用方式

目前的风险

和通用推理工具的区别

小结

参考

AI 编程工具这一轮，DeepSeek 为何成了省钱关键？

Agent 工具为什么特别费 token

Superpowers 的好处是按需触发

DeepSeek 的关键优势是缓存便宜

长上下文让 Claude Code 更好用

V4 Pro 和 V4 Flash 怎么分工

MiniMax、豆包和 DeepSeek 的位置不同

省钱的关键不是只找便宜模型

DeepSeek 适合哪类 AI 编程工作流

小结

DeepSeek-TUI：在终端里运行 DeepSeek 编程 Agent

它适合谁

安装方式

首次配置 API Key

Auto mode：自动选择模型和思考强度

三种工作模式

工具能力

常用命令

Zed 和 ACP

配置和多 provider

成本和上下文

使用建议

小结

参考资料

DeepSeek V4 本地私有化部署方案：国产芯片与消费级显卡集群怎么选

先明确部署目标

不要一上来就追求满血 Pro

国产芯片路线：适合企业级私有云

消费级显卡集群：适合试点和中小团队

可能的部署架构

硬件选型思路

验证阶段

试点阶段

生产阶段

推理框架怎么选

数据安全要做在模型外面

成本不要只算显卡

推荐落地路径

小结

参考资料

如何在 Cline 中调用 DeepSeek V4 Pro

准备 DeepSeek API Key

在 Cline 插件里配置

在 Cline CLI 中配置

推荐的模型分工

上下文长度怎么填

常见问题

1. 提示模型不存在

2. 提示 401 或认证失败

3. 提示连接失败

4. Cline 调用很贵怎么办

5. 报错 reasoning_content must be passed back

一个可直接复制的配置清单

2. `1M context` 是这次最突出的卖点

3. `V4-Pro` 主要在强调什么

4. `V4-Flash` 并不是简单的缩水版