试了两天我决定先认个错。之前在社区里聊 AI 编程我一直说 DeepSeek 写写小函数、改改正则没问题真要扔进 Codex 这种重工具调用的 agent 工作流里大概率撑不过三轮就得翻车。直到我把 DeepSeek Harness 装好用 ccswitch 把 provider 切到 DeepSeek API让它实打实跑完几个工程任务才明白自己错得多离谱。这篇东西是一次完整交代DeepSeek Harness 到底是什么、怎么装、配置里哪几个地方最容易踩坑、实测效果到底怎么样以及那个让我排查到半夜的 400 报错。适合所有想把 DeepSeek 这类高性价比模型驱动 AI 编程 agent 的人尤其是已经受够了按量计费肉疼的独立开发者。1. 从 Chat 到 Agent为什么 DeepSeek 缺的不是模型而是一层 Harness1.1 纯 API 调用和 Agent 化调用之间的差距先讲个类比。模型本身像一台发动机扭矩再大、马力再猛不装变速箱、传动轴和方向盘它驱动不了整台车。你直接用 curl 调 DeepSeek 的 API本质上是拿手掰曲轴能让轮子转起来但做不了精细的入库、倒车、变道这些操作。所谓 Harness就是给模型套上的一整套传动系统——文件读写、命令行执行、多轮工具调用、lint 反馈、错误堆栈回传这些能力组合起来模型才从聊天窗口里的答题机器变成坐在电脑前能干活的实习生。这个区别在 DeepSeek 上尤其明显。它的对话能力很强中文理解好代码生成的单次质量放在开源模型里是第一梯队。但单次回答质量高不等于能独立完成一个多文件、多步骤的工程任务。真实任务是这样的先读项目结构再定位到某个函数修改完跑一遍测试测试挂了读堆栈根据堆栈再修修完再跑循环往复。没有 Harness 这层壳模型根本接触不到文件系统和命令行的反馈回路它只能在你的提示词里盲答。这就是为什么光有 API key 远远不够Harness 才是让 DeepSeek 真正进入生产环境的关键拼图。1.2 Harness 工程和 Agent 的区别很多人没搞清楚社区里经常把 Harness 和 Agent 混着说我一开始也犯迷糊。后来自己搭过一遍才算理清Agent 是能自主决策的模型 工具使用权强调模型说了算Harness 是约束和控制 Agent 行为的工程框架强调的是边界、流程、反馈闭环。你可以理解成 Agent 是那个干活的实习生Harness 是公司里的一套制度和工具链——哪些目录能改、改完必须跑什么测试、出错之后怎么汇报、最多允许自查几次全由 Harness 定义。Harness 存在的意义一是让模型的行为可预期、可回滚二是让模型的工具调用过程变成一条可观测、可调试的流水线。DeepSeek Harness 这个说法其实就是社区对以 DeepSeek 为底座模型、接入编码 Agent 工具链的整套配置方案的统称。它不是一个单一软件而是一个组合模型 API、协议转换层比如 ccswitch 起的本地代理、Agent 执行器比如 Codex CLI、配置文件。理解了这一点后面所有安装步骤你都不会觉得碎片化因为你是在搭一条模型到工地的完整流水线。1.3 为什么我最后选了 DeepSeek 当主力试试点市面上能接进编码 Agent 的模型不少豆包、元宝、千问都有各自的 API我身边也有朋友在折腾但最终把 DeepSeek 当成我重点试的那个原因很实在。第一DeepSeek 的 API 兼容 OpenAI 的消息格式迁移成本极低ccswitch 这类工具几乎不需要额外适配就能切过去。第二它的 thinking mode 是可开关的简单任务用普通模式秒回复杂重构开深度思考灵活性比一竿子到底的模型强。第三价格真的低到可以放开跑我在后面专门算了一笔账同样的任务量用头部闭源模型跑到的金额够 DeepSeek 跑很久。第四也是很多开发者忽略的一点DeepSeek 是国内服务网络环境简单不折腾这对想稳定跑 agent 任务的人来说太重要了。当然便宜只是敲门砖真正让我吓一跳的是它在 Harness 里的实际表现。下一篇开始记录安装和配置全过程每一步都写清楚按着我这份走基本不会卡住。2. 首发安装实录零基础把 DeepSeek Harness 跑起来2.1 前置环境准备如果你已经装过 Codex CLI 和 Node.js这部分可以跳过。没有的话按顺序来。Codex 的底层运行时依赖 Node.js所以先去 Node 官网装一个 LTS 版本装完用node -v确认版本号是 18 以上就行。然后全局安装 Codex CLInpm install -g openai/codex装完输入codex --version能打出版本号说明第一步完成。要注意的是 Windows 用户建议用 WSL 跑原生 PowerShell 下 Codex 的终端交互偶尔会有渲染问题Windows 上硬踩的话会在 ANSI 转义字符上浪费时间没必要。下一步装 ccswitch。这个工具本来是社区里用来快速切换 Codex 不同模型提供商配置的小工具后来慢慢发展成支持本地代理协议转换的枢纽——DeepSeek Harness 社区方案里它承担了很重要的角色。安装同样是 npm 一行命令npm install -g ccswitch装好之后要确认 ccswitch 有权限管理 Codex 的配置文件。它本质上是往~/.codex/config.toml里写入 provider 信息所以装完要先跑一次它自带的检测命令通常输出config path: /home/xxx/.codex/config.toml就说明找对了。2.2 用一个最小配置让 DeepSeek 进到 Codex 里这是整个安装过程最核心的一步把 DeepSeek 配置成 Codex 的一个 model provider。直接改~/.codex/config.toml加下面这段model deepseek-v4-flash model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat然后设置环境变量export DEEPSEEK_API_KEYsk-你自己的key最后启动 Codex 时带上模型参数codex -m deepseek-v4-flash这里有个关键点wire_api决定了 Codex 用哪种协议跟上游通信。设成chat走的是标准 Chat Completions 格式DeepSeek 原生支持最简单设成responses则走 OpenAI 新的 Responses APIccswitch 会启动一个本地代理做协议转换灵活度更高但坑也更多——我后面专门讲那个 400 报错就跟这条路径有关。新手第一次跑我建议用chat先跑通了再说。2.3 首次启动验证和安装期最常踩的坎配置完成跑起来之后先不要急着派任务做一个一分钟的连接测试。让 Codex 解释当前目录下的一个文件或者让它画一个项目结构树观察它能否正常调用 shell 工具。如果它能列目录、读文件、给出合理修改建议说明整条链路通了。我第一次跑的时候就在这步踩了个坎请求发出去等了十几秒Codex 直接报provider error: invalid api key。我第一反应是 key 复制错了检查半天发现没错最后才注意到是自己没设环境变量就重开了终端——export只在当前会话有效换了终端窗口就丢了。这里建议直接把 export 写进~/.bashrc或~/.zshrc一劳永逸。另一个很常见的坎是 base_url 写错DeepSeek 的兼容端点有两种写法https://api.deepseek.com和https://api.deepseek.com/v1我在下一节会详细解释这两种写法背后的逻辑以及选错的后果。3. 配置项逐项拆解base_url、模型名与 thinking 模式的底层逻辑3.1 关键参数对照表安装完成后很多人会盯着 Config 文件发呆不知道每个字段是干嘛的。我整理了一份对照表按重要程度排序参数作用我的推荐model指定模型名deepseek-v4-flash或具体任务更强力的模型model_provider指向[model_providers.xxx]段落的 key与下面的 provider 名保持完全一致base_url决定请求发到哪个 API 端点DeepSeek 填https://api.deepseek.com/v1env_key从哪个环境变量读取 API keyDEEPSEEK_API_KEY避免明文写在配置里wire_api协议类型chat或responses省心选chat需要本地代理选responsestemperature随机性控制代码任务建议 0.2 或更低这里最需要注意的是model_provider和配置段落名的一致性。你写model_provider deepseek下有就必须有一个[model_providers.deepseek]段落名字拼错一个字母Codex 启动时会直接报未知 provider。3.2 thinking mode 和 reasoning_content 字段DeepSeek 的系列模型支持深度思考模式开启后模型会在给出最终答案之前输出一段内部推理过程API 返回的消息里除了正常的content还带一个reasoning_content字段里面装着思维链内容。这个字段在单轮对话时没人在意但你一旦把模型接进 Harness 跑多轮 agent 任务它就成了一个定时炸弹。原因是这样的DeepSeek 在 thinking mode 下多轮对话要求调用方把上一轮 assistant 回复中的reasoning_content原样回传目的是保持思维链的连续性和一致性同时防止上下文碎片化导致模型忘记自己刚才推理到哪了。如果请求历史消息里缺了这个字段API 会直接拒绝这次请求返回 HTTP 400。这种设计的背后逻辑你可以理解成推理轨迹是上下文的一部分。普通对话模式下你回传 content 就够了但思考模式下如果你不让模型看到自己之前的推理过程它在后续工具调用里很容易出现前后矛盾agent 任务做一半突然变傻。DeepSeek 用强制校验的方式把这个问题暴露出来虽然调试的时候很烦但本质上是在帮 agent 应用维持推理的一致性。3.3 base_url 的两种写法选错会怎样DeepSeek 的 API 文档里base_url 可以填https://api.deepseek.com也可以填https://api.deepseek.com/v1两种都合法。区别在于后面的路径拼接逻辑。Codex 在wire_api chat时会自动把模型请求拼到{base_url}/chat/completions上如果你 base_url 填了https://api.deepseek.com/v1最终请求是https://api.deepseek.com/v1/chat/completions没问题如果你填的是https://api.deepseek.com最终请求是https://api.deepseek.com/chat/completionsDeepSeek 的网关也能识别。两条路都通但一旦你跑了某个协议转换代理比如 ccswitch 的 local proxy代理内部的路径拼接规则就可能不再宽容——多一层/v1或少一层/v1都能变成 404 或 400。所以我建议统一用带/v1的写法兼容性最稳。4. 真实任务实测DeepSeek 驱动 Codex 的完整过程复盘4.1 我设计的测试任务和预期纸上谈兵没意思我直接在本地找了个遗留的 Node.js 项目当试验场。任务设计成三步第一步写一个脚本解析指定目录下所有 Markdown 文件提取每个文件里的代码块按语言分类生成一份索引 JSON第二步针对脚本写单元测试覆盖无代码块多语言混排嵌套代码块三个边界情况第三步跑 lint确保代码风格通过。整个过程要求 DeepSeek 自主规划 todo 列表自己决定文件结构遇到测试失败要读堆栈自行修复。我当时的预期并不高。DeepSeek 单次生成这种脚本大概率没问题但要求它连续完成读项目结构 → 写代码 → 写测试 → 跑通 → 修 lint的一整条流水线我觉得会在某个环节断掉。结果它跑完之后我盯着 terminal 愣了好几秒。4.2 运行过程中的几个关键观察整个任务大概花了 40 分钟左右全程我基本没干预。有几个观察印象很深。它在开工前自己列了一个 todo 清单分成了 5 个步骤扫描项目、设计脚本接口、实现解析逻辑、写测试、跑 lint 和修复。这比很多我在闭源模型上看到的直接甩出一坨代码要靠谱得多。第一次测试失败发生在解析 Markdown 代码块的正则上。它在处理四个反引号包裹的多行代码块时漏掉了边缘情况测试挂掉之后它自己读了堆栈定位到正则表达式的问题然后重新生成了处理函数。这个过程没有我的提示完全靠 harness 反馈回路里传递的报错信息自我纠错。说实话这在上一代国产开源模型上是不敢想的。它中途还犯过一次自作聪明的错误——在索引 JSON 里加了一个需求里根本没提的summary字段我在下一轮对话里指出来它道歉并快速移除了。态度很好反应也快。4.3 和其他模型同台的费用与效果账坦白说DeepSeek 在单次代码生成质量上和顶级闭源模型还有差距主要体现在非常复杂的多文件跨模块重构上它的规划偶尔会遗漏边界模块。但 agent 场景里有个被很多人低估的因素迭代成本。同样的任务如果用一个贵的闭源模型你不敢让它随便试错每多跑一轮都是钱拿 DeepSeek 跑你完全可以让它放开了自我纠错多试几轮方案反正费用低到可以忽略。我大致估算了一下这个 40 分钟、5 个 todo 步骤、几十轮工具调用的任务DeepSeek 的 API 费用大概只在几毛钱这个量级。同样任务量放在某些头部闭源模型上金额会到几十甚至上百。体验上的差异是我之前用贵模型遇到复杂任务会心疼 token倾向把任务拆碎、自己多写注释省得模型返工换成 DeepSeek 之后我变得很放纵一句话把任务描述完让它自己折腾。这种心态转变带来的效率和产出质量提升反而比模型本身的能力更重要这也是我说梁神我错了的直接原因。5. 400 报错排查全记录reasoning_content 多轮回传问题5.1 报错现场还原前面提到我把wire_api切到responses做过一次尝试结果炸出一个让折腾到半夜的报错。先把现场完整贴出来cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.场景是这样的Codex CLI 发出一个/responses请求ccswitch 本地代理负责把它转发给 DeepSeek 的接口DeepSeek 返回了 HTTP 400错误信息明确指向reasoning_content字段。关键规律是第一轮对话永远正常第二轮开始必挂。第一轮能通说明鉴权、模型名、base_url 全都没问题从第二轮开始挂说明问题出在多轮上下文传递这个环节。5.2 排查链路第一步逐个排除配置嫌疑遇到这种报错第一反应是配置又写错了。我先检查了 base_url没问题检查模型名官方文档里确实有这个型号检查 API key 权限能用普通对话模式正常调用。然后我把请求体打印出来仔细对比了两轮请求的差异发现第一轮的请求历史里只有 user 消息和 assistant 的普通 content第二轮开始历史里多了一整块 assistant 消息——里面既有 content也有 thinking mode 产生的 reasoning_content。问题其实已经浮出水面了当时还没意识到这是根因。5.3 排查链路第二步协议转换代理的锅于是把怀疑对象转到 ccswitch 的本地代理上。调试的思路是打开 ccswitch 的 debug 日志看代理从 Codex 收到什么、往 DeepSeek 转发了什么。对比之后发现ccswitch 在把 Codex 的历史消息重新打包转发给 DeepSeek 时把 assistant 消息里的reasoning_content字段静默丢弃了只保留了content。这其实不是 ccswitch 有意为之而是协议转换里字段映射的一个漏洞——Responses API 那边的格式和 Chat Completions 的格式不完全对得上代理在做格式转换时漏掉了这个字段。5.4 根因定位与最终修复问题的本质清楚了DeepSeek 的 thinking mode 在服务端做多轮上下文校验时要求历史消息里必须包含上一轮的reasoning_content否则直接拒绝请求。这既是 API 的硬性要求也是保证思维链连续性的机制。我最终的解决方案很朴素因为 ccswitch 在更新日志里明确说已经修复了这个字段映射问题所以第一步是升级它的版本。升级之后实测确实解决了。如果你遇到的情况是老版本代理没法升级还有两条可选路径。一条是干脆关掉 thinking mode改用不带深度思考的模型牺牲一点复杂任务的推理深度换来完全绕开这个字段的问题另一条是在代理层做一次手动补全在转发前把历史消息里缺失的reasoning_content从上一轮响应里提取出来重新填充到请求里。无论哪条路核心都是尊重 DeepSeek 的 thinking mode 规则——这个字段不能丢丢了它就认为你在破坏上下文完整性。5.5 同类坑多轮对话稳定性这个坑的本质是多轮对话中元信息字段的完整性。类似的情况不止出现在 DeepSeek 上任何带思维链输出的模型接入 agent 工具链时都会遇到上下文元信息保留的问题。排查时我总结出一个通用心法单轮正常、多轮必挂的问题八成出在历史消息打包逻辑上单轮就挂的问题才需要去怀疑鉴权、base_url 和模型名。这个诊断顺序能帮你省下大量时间。6. 让 Harness 更好用的几条调优经验6.1 用 AGENTS.md 给模型划定工作边界Codex 在工作时会读取项目根目录下的AGENTS.md文件把它当成项目级操作规范。这个文件的效果非常立竿见影。我在里面写了三条最要紧的规则一所有涉及删除文件的操作必须先向用户确认二修改依赖版本号后必须立刻跑npm install验证三测试失败时优先读堆栈不要盲目重试。写完之后DeepSeek 在 harness 里的表现变得明显更懂规矩。这比在每一轮对话里重复强调要好得多因为它是一种可持久化、可版本管理的约束方式。6.2 控制 lint 循环防止 token 烧在无畏挣扎里agent 自纠错是个好东西但失控的自纠错会变成灾难。我见过模型卡在一个 lint 问题上连续尝试 8 次每次都是换一种风格重写同一段代码全程没有本质进展。后来我在 Codex 的配置里限制了自动重试次数并且在 AGENTS.md 里加了一条同一问题连续失败两次后停止尝试并主动向用户汇报现状。加了这条之后模型遇到瓶颈时会主动求助而不是闷头乱试整体的任务完成速度和 token 消耗都改善了很多。6.3 多套配置随时切换的工作方式ccswitch 管着多套 provider 配置我的习惯是留三套默认用 DeepSeek 跑日常任务遇到真正的超级复杂重构时切到更强的闭源模型再留一套本地小模型跑高风险文件操作。切换就是一条命令的事。这种分级用车的策略很实用——简单任务不要用重武器重武器留着打硬仗成本下来之后你会发现 agent 工具的利用率和工作效率都高了一截。这也是我在整套折腾里学到的最实在的经验。
DeepSeek Harness实战：让DeepSeek驱动Codex的完整指南
试了两天我决定先认个错。之前在社区里聊 AI 编程我一直说 DeepSeek 写写小函数、改改正则没问题真要扔进 Codex 这种重工具调用的 agent 工作流里大概率撑不过三轮就得翻车。直到我把 DeepSeek Harness 装好用 ccswitch 把 provider 切到 DeepSeek API让它实打实跑完几个工程任务才明白自己错得多离谱。这篇东西是一次完整交代DeepSeek Harness 到底是什么、怎么装、配置里哪几个地方最容易踩坑、实测效果到底怎么样以及那个让我排查到半夜的 400 报错。适合所有想把 DeepSeek 这类高性价比模型驱动 AI 编程 agent 的人尤其是已经受够了按量计费肉疼的独立开发者。1. 从 Chat 到 Agent为什么 DeepSeek 缺的不是模型而是一层 Harness1.1 纯 API 调用和 Agent 化调用之间的差距先讲个类比。模型本身像一台发动机扭矩再大、马力再猛不装变速箱、传动轴和方向盘它驱动不了整台车。你直接用 curl 调 DeepSeek 的 API本质上是拿手掰曲轴能让轮子转起来但做不了精细的入库、倒车、变道这些操作。所谓 Harness就是给模型套上的一整套传动系统——文件读写、命令行执行、多轮工具调用、lint 反馈、错误堆栈回传这些能力组合起来模型才从聊天窗口里的答题机器变成坐在电脑前能干活的实习生。这个区别在 DeepSeek 上尤其明显。它的对话能力很强中文理解好代码生成的单次质量放在开源模型里是第一梯队。但单次回答质量高不等于能独立完成一个多文件、多步骤的工程任务。真实任务是这样的先读项目结构再定位到某个函数修改完跑一遍测试测试挂了读堆栈根据堆栈再修修完再跑循环往复。没有 Harness 这层壳模型根本接触不到文件系统和命令行的反馈回路它只能在你的提示词里盲答。这就是为什么光有 API key 远远不够Harness 才是让 DeepSeek 真正进入生产环境的关键拼图。1.2 Harness 工程和 Agent 的区别很多人没搞清楚社区里经常把 Harness 和 Agent 混着说我一开始也犯迷糊。后来自己搭过一遍才算理清Agent 是能自主决策的模型 工具使用权强调模型说了算Harness 是约束和控制 Agent 行为的工程框架强调的是边界、流程、反馈闭环。你可以理解成 Agent 是那个干活的实习生Harness 是公司里的一套制度和工具链——哪些目录能改、改完必须跑什么测试、出错之后怎么汇报、最多允许自查几次全由 Harness 定义。Harness 存在的意义一是让模型的行为可预期、可回滚二是让模型的工具调用过程变成一条可观测、可调试的流水线。DeepSeek Harness 这个说法其实就是社区对以 DeepSeek 为底座模型、接入编码 Agent 工具链的整套配置方案的统称。它不是一个单一软件而是一个组合模型 API、协议转换层比如 ccswitch 起的本地代理、Agent 执行器比如 Codex CLI、配置文件。理解了这一点后面所有安装步骤你都不会觉得碎片化因为你是在搭一条模型到工地的完整流水线。1.3 为什么我最后选了 DeepSeek 当主力试试点市面上能接进编码 Agent 的模型不少豆包、元宝、千问都有各自的 API我身边也有朋友在折腾但最终把 DeepSeek 当成我重点试的那个原因很实在。第一DeepSeek 的 API 兼容 OpenAI 的消息格式迁移成本极低ccswitch 这类工具几乎不需要额外适配就能切过去。第二它的 thinking mode 是可开关的简单任务用普通模式秒回复杂重构开深度思考灵活性比一竿子到底的模型强。第三价格真的低到可以放开跑我在后面专门算了一笔账同样的任务量用头部闭源模型跑到的金额够 DeepSeek 跑很久。第四也是很多开发者忽略的一点DeepSeek 是国内服务网络环境简单不折腾这对想稳定跑 agent 任务的人来说太重要了。当然便宜只是敲门砖真正让我吓一跳的是它在 Harness 里的实际表现。下一篇开始记录安装和配置全过程每一步都写清楚按着我这份走基本不会卡住。2. 首发安装实录零基础把 DeepSeek Harness 跑起来2.1 前置环境准备如果你已经装过 Codex CLI 和 Node.js这部分可以跳过。没有的话按顺序来。Codex 的底层运行时依赖 Node.js所以先去 Node 官网装一个 LTS 版本装完用node -v确认版本号是 18 以上就行。然后全局安装 Codex CLInpm install -g openai/codex装完输入codex --version能打出版本号说明第一步完成。要注意的是 Windows 用户建议用 WSL 跑原生 PowerShell 下 Codex 的终端交互偶尔会有渲染问题Windows 上硬踩的话会在 ANSI 转义字符上浪费时间没必要。下一步装 ccswitch。这个工具本来是社区里用来快速切换 Codex 不同模型提供商配置的小工具后来慢慢发展成支持本地代理协议转换的枢纽——DeepSeek Harness 社区方案里它承担了很重要的角色。安装同样是 npm 一行命令npm install -g ccswitch装好之后要确认 ccswitch 有权限管理 Codex 的配置文件。它本质上是往~/.codex/config.toml里写入 provider 信息所以装完要先跑一次它自带的检测命令通常输出config path: /home/xxx/.codex/config.toml就说明找对了。2.2 用一个最小配置让 DeepSeek 进到 Codex 里这是整个安装过程最核心的一步把 DeepSeek 配置成 Codex 的一个 model provider。直接改~/.codex/config.toml加下面这段model deepseek-v4-flash model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat然后设置环境变量export DEEPSEEK_API_KEYsk-你自己的key最后启动 Codex 时带上模型参数codex -m deepseek-v4-flash这里有个关键点wire_api决定了 Codex 用哪种协议跟上游通信。设成chat走的是标准 Chat Completions 格式DeepSeek 原生支持最简单设成responses则走 OpenAI 新的 Responses APIccswitch 会启动一个本地代理做协议转换灵活度更高但坑也更多——我后面专门讲那个 400 报错就跟这条路径有关。新手第一次跑我建议用chat先跑通了再说。2.3 首次启动验证和安装期最常踩的坎配置完成跑起来之后先不要急着派任务做一个一分钟的连接测试。让 Codex 解释当前目录下的一个文件或者让它画一个项目结构树观察它能否正常调用 shell 工具。如果它能列目录、读文件、给出合理修改建议说明整条链路通了。我第一次跑的时候就在这步踩了个坎请求发出去等了十几秒Codex 直接报provider error: invalid api key。我第一反应是 key 复制错了检查半天发现没错最后才注意到是自己没设环境变量就重开了终端——export只在当前会话有效换了终端窗口就丢了。这里建议直接把 export 写进~/.bashrc或~/.zshrc一劳永逸。另一个很常见的坎是 base_url 写错DeepSeek 的兼容端点有两种写法https://api.deepseek.com和https://api.deepseek.com/v1我在下一节会详细解释这两种写法背后的逻辑以及选错的后果。3. 配置项逐项拆解base_url、模型名与 thinking 模式的底层逻辑3.1 关键参数对照表安装完成后很多人会盯着 Config 文件发呆不知道每个字段是干嘛的。我整理了一份对照表按重要程度排序参数作用我的推荐model指定模型名deepseek-v4-flash或具体任务更强力的模型model_provider指向[model_providers.xxx]段落的 key与下面的 provider 名保持完全一致base_url决定请求发到哪个 API 端点DeepSeek 填https://api.deepseek.com/v1env_key从哪个环境变量读取 API keyDEEPSEEK_API_KEY避免明文写在配置里wire_api协议类型chat或responses省心选chat需要本地代理选responsestemperature随机性控制代码任务建议 0.2 或更低这里最需要注意的是model_provider和配置段落名的一致性。你写model_provider deepseek下有就必须有一个[model_providers.deepseek]段落名字拼错一个字母Codex 启动时会直接报未知 provider。3.2 thinking mode 和 reasoning_content 字段DeepSeek 的系列模型支持深度思考模式开启后模型会在给出最终答案之前输出一段内部推理过程API 返回的消息里除了正常的content还带一个reasoning_content字段里面装着思维链内容。这个字段在单轮对话时没人在意但你一旦把模型接进 Harness 跑多轮 agent 任务它就成了一个定时炸弹。原因是这样的DeepSeek 在 thinking mode 下多轮对话要求调用方把上一轮 assistant 回复中的reasoning_content原样回传目的是保持思维链的连续性和一致性同时防止上下文碎片化导致模型忘记自己刚才推理到哪了。如果请求历史消息里缺了这个字段API 会直接拒绝这次请求返回 HTTP 400。这种设计的背后逻辑你可以理解成推理轨迹是上下文的一部分。普通对话模式下你回传 content 就够了但思考模式下如果你不让模型看到自己之前的推理过程它在后续工具调用里很容易出现前后矛盾agent 任务做一半突然变傻。DeepSeek 用强制校验的方式把这个问题暴露出来虽然调试的时候很烦但本质上是在帮 agent 应用维持推理的一致性。3.3 base_url 的两种写法选错会怎样DeepSeek 的 API 文档里base_url 可以填https://api.deepseek.com也可以填https://api.deepseek.com/v1两种都合法。区别在于后面的路径拼接逻辑。Codex 在wire_api chat时会自动把模型请求拼到{base_url}/chat/completions上如果你 base_url 填了https://api.deepseek.com/v1最终请求是https://api.deepseek.com/v1/chat/completions没问题如果你填的是https://api.deepseek.com最终请求是https://api.deepseek.com/chat/completionsDeepSeek 的网关也能识别。两条路都通但一旦你跑了某个协议转换代理比如 ccswitch 的 local proxy代理内部的路径拼接规则就可能不再宽容——多一层/v1或少一层/v1都能变成 404 或 400。所以我建议统一用带/v1的写法兼容性最稳。4. 真实任务实测DeepSeek 驱动 Codex 的完整过程复盘4.1 我设计的测试任务和预期纸上谈兵没意思我直接在本地找了个遗留的 Node.js 项目当试验场。任务设计成三步第一步写一个脚本解析指定目录下所有 Markdown 文件提取每个文件里的代码块按语言分类生成一份索引 JSON第二步针对脚本写单元测试覆盖无代码块多语言混排嵌套代码块三个边界情况第三步跑 lint确保代码风格通过。整个过程要求 DeepSeek 自主规划 todo 列表自己决定文件结构遇到测试失败要读堆栈自行修复。我当时的预期并不高。DeepSeek 单次生成这种脚本大概率没问题但要求它连续完成读项目结构 → 写代码 → 写测试 → 跑通 → 修 lint的一整条流水线我觉得会在某个环节断掉。结果它跑完之后我盯着 terminal 愣了好几秒。4.2 运行过程中的几个关键观察整个任务大概花了 40 分钟左右全程我基本没干预。有几个观察印象很深。它在开工前自己列了一个 todo 清单分成了 5 个步骤扫描项目、设计脚本接口、实现解析逻辑、写测试、跑 lint 和修复。这比很多我在闭源模型上看到的直接甩出一坨代码要靠谱得多。第一次测试失败发生在解析 Markdown 代码块的正则上。它在处理四个反引号包裹的多行代码块时漏掉了边缘情况测试挂掉之后它自己读了堆栈定位到正则表达式的问题然后重新生成了处理函数。这个过程没有我的提示完全靠 harness 反馈回路里传递的报错信息自我纠错。说实话这在上一代国产开源模型上是不敢想的。它中途还犯过一次自作聪明的错误——在索引 JSON 里加了一个需求里根本没提的summary字段我在下一轮对话里指出来它道歉并快速移除了。态度很好反应也快。4.3 和其他模型同台的费用与效果账坦白说DeepSeek 在单次代码生成质量上和顶级闭源模型还有差距主要体现在非常复杂的多文件跨模块重构上它的规划偶尔会遗漏边界模块。但 agent 场景里有个被很多人低估的因素迭代成本。同样的任务如果用一个贵的闭源模型你不敢让它随便试错每多跑一轮都是钱拿 DeepSeek 跑你完全可以让它放开了自我纠错多试几轮方案反正费用低到可以忽略。我大致估算了一下这个 40 分钟、5 个 todo 步骤、几十轮工具调用的任务DeepSeek 的 API 费用大概只在几毛钱这个量级。同样任务量放在某些头部闭源模型上金额会到几十甚至上百。体验上的差异是我之前用贵模型遇到复杂任务会心疼 token倾向把任务拆碎、自己多写注释省得模型返工换成 DeepSeek 之后我变得很放纵一句话把任务描述完让它自己折腾。这种心态转变带来的效率和产出质量提升反而比模型本身的能力更重要这也是我说梁神我错了的直接原因。5. 400 报错排查全记录reasoning_content 多轮回传问题5.1 报错现场还原前面提到我把wire_api切到responses做过一次尝试结果炸出一个让折腾到半夜的报错。先把现场完整贴出来cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.场景是这样的Codex CLI 发出一个/responses请求ccswitch 本地代理负责把它转发给 DeepSeek 的接口DeepSeek 返回了 HTTP 400错误信息明确指向reasoning_content字段。关键规律是第一轮对话永远正常第二轮开始必挂。第一轮能通说明鉴权、模型名、base_url 全都没问题从第二轮开始挂说明问题出在多轮上下文传递这个环节。5.2 排查链路第一步逐个排除配置嫌疑遇到这种报错第一反应是配置又写错了。我先检查了 base_url没问题检查模型名官方文档里确实有这个型号检查 API key 权限能用普通对话模式正常调用。然后我把请求体打印出来仔细对比了两轮请求的差异发现第一轮的请求历史里只有 user 消息和 assistant 的普通 content第二轮开始历史里多了一整块 assistant 消息——里面既有 content也有 thinking mode 产生的 reasoning_content。问题其实已经浮出水面了当时还没意识到这是根因。5.3 排查链路第二步协议转换代理的锅于是把怀疑对象转到 ccswitch 的本地代理上。调试的思路是打开 ccswitch 的 debug 日志看代理从 Codex 收到什么、往 DeepSeek 转发了什么。对比之后发现ccswitch 在把 Codex 的历史消息重新打包转发给 DeepSeek 时把 assistant 消息里的reasoning_content字段静默丢弃了只保留了content。这其实不是 ccswitch 有意为之而是协议转换里字段映射的一个漏洞——Responses API 那边的格式和 Chat Completions 的格式不完全对得上代理在做格式转换时漏掉了这个字段。5.4 根因定位与最终修复问题的本质清楚了DeepSeek 的 thinking mode 在服务端做多轮上下文校验时要求历史消息里必须包含上一轮的reasoning_content否则直接拒绝请求。这既是 API 的硬性要求也是保证思维链连续性的机制。我最终的解决方案很朴素因为 ccswitch 在更新日志里明确说已经修复了这个字段映射问题所以第一步是升级它的版本。升级之后实测确实解决了。如果你遇到的情况是老版本代理没法升级还有两条可选路径。一条是干脆关掉 thinking mode改用不带深度思考的模型牺牲一点复杂任务的推理深度换来完全绕开这个字段的问题另一条是在代理层做一次手动补全在转发前把历史消息里缺失的reasoning_content从上一轮响应里提取出来重新填充到请求里。无论哪条路核心都是尊重 DeepSeek 的 thinking mode 规则——这个字段不能丢丢了它就认为你在破坏上下文完整性。5.5 同类坑多轮对话稳定性这个坑的本质是多轮对话中元信息字段的完整性。类似的情况不止出现在 DeepSeek 上任何带思维链输出的模型接入 agent 工具链时都会遇到上下文元信息保留的问题。排查时我总结出一个通用心法单轮正常、多轮必挂的问题八成出在历史消息打包逻辑上单轮就挂的问题才需要去怀疑鉴权、base_url 和模型名。这个诊断顺序能帮你省下大量时间。6. 让 Harness 更好用的几条调优经验6.1 用 AGENTS.md 给模型划定工作边界Codex 在工作时会读取项目根目录下的AGENTS.md文件把它当成项目级操作规范。这个文件的效果非常立竿见影。我在里面写了三条最要紧的规则一所有涉及删除文件的操作必须先向用户确认二修改依赖版本号后必须立刻跑npm install验证三测试失败时优先读堆栈不要盲目重试。写完之后DeepSeek 在 harness 里的表现变得明显更懂规矩。这比在每一轮对话里重复强调要好得多因为它是一种可持久化、可版本管理的约束方式。6.2 控制 lint 循环防止 token 烧在无畏挣扎里agent 自纠错是个好东西但失控的自纠错会变成灾难。我见过模型卡在一个 lint 问题上连续尝试 8 次每次都是换一种风格重写同一段代码全程没有本质进展。后来我在 Codex 的配置里限制了自动重试次数并且在 AGENTS.md 里加了一条同一问题连续失败两次后停止尝试并主动向用户汇报现状。加了这条之后模型遇到瓶颈时会主动求助而不是闷头乱试整体的任务完成速度和 token 消耗都改善了很多。6.3 多套配置随时切换的工作方式ccswitch 管着多套 provider 配置我的习惯是留三套默认用 DeepSeek 跑日常任务遇到真正的超级复杂重构时切到更强的闭源模型再留一套本地小模型跑高风险文件操作。切换就是一条命令的事。这种分级用车的策略很实用——简单任务不要用重武器重武器留着打硬仗成本下来之后你会发现 agent 工具的利用率和工作效率都高了一截。这也是我在整套折腾里学到的最实在的经验。
