同一个 DeepSeek-V4-Flash，为什么在 Codex 里像换了模型？
[series:Harness 深水区] [date:2026-08-01] [read:17min] [words:8.0k] #Agent#Harness#DeepSeek#Codex#Claude Code
这是「Harness 深水区」系列的补充篇。上一篇《Model + Harness = Agent：产品差距的大头，不在模型》讲的是两条腿：模型给出潜能，Harness 负责把潜能带进真实任务。DeepSeek V4 Flash 让我在同一个后端模型上看到了这条关系。
先把 Harness 说成人话：Harness（智能体运行时）就是模型的工作台——负责拆任务、提供工具、保留上下文、验收结果，并在失败后让模型重试或回滚。它不是模型外面可有可无的包装，而是模型与现实世界之间的执行系统。
如果上一篇讲的是“模型的能力怎样被运行栈兑现”，配套实践篇《DeepSeek V4 Flash 应该怎么用：把强模型留给不确定性》讲的就是另一半：不同阶段，应该把什么样的模型放上去。
两篇可以独立阅读；如果一起看，我建议先从实践篇理解模型分工，再回到这篇看运行时为什么会放大或损耗这种分工。
先给结论：同一个后端 model id，换一套协议、工具契约和恢复机制，长任务里能兑现出来的能力就可能完全不同。这篇不再展开复述 DeepSeek 的发布背景，只保留足够核对样本的证据，把篇幅放在三个问题上：差异究竟通过哪几层发生、怎样做一个更像实验的验证、以及为什么短期内 Harness 可能比模型更快形成产品差距。
先看本地样本：观察成立到哪一步
我先把本地事实摆出来。它足以支持“运行栈配对不同”，还不足以支持“某个产品整体更强”：
| 样本 | 可观察事实 | 能说明什么 |
|---|---|---|
| Codex | 一个培训演示稿从大纲扩充到 40 多页，反复做溢出、翻页、概览和几何检查后收敛 | 这套模型–运行栈配对完成过长程、跨文件、反复验收的任务 |
| Claude Code Flash | 另一轮任务启动了多路只读审查并返回综合报告，但报告质量未独立核验 | Claude Code 并非完全不能做大事；这不是可与上例直接比较的成功率 |
把第一行说得更具体：当任务是“把 40 页演示稿逐页改到能交付”时，好的工作流会让模型读文件、改一页、开预览、发现溢出、再修正；我本地看到的是这种反复闭环，而不是一次生成一版代码。这组演示稿样本，与配套实践篇里的群聊游戏案例不是同一场实验。
这条证据能支持的是：Codex 这套模型–运行栈配对完成过长程、跨文件、反复验收的任务。它不能支持“Codex 默认总是更强”。当前证据支持的是模型版本 × 协议 × 运行时 × 任务形状的交互。
“同一个模型”校准到哪里就够了
DeepSeek 在 7 月 31 日的更新日志里把版本标为 DeepSeek-V4-Flash-0731，model id 仍是 deepseek-v4-flash。对本文来说，核对到“后端 model id 相同”就够了；其他条件恰恰是差异可能发生的地方：
| 项目 | codex-ds | ccc-ds-flash |
|---|---|---|
| 客户端 / 线路 | Codex CLI 0.146.0 / Responses API | Claude Code 2.1.220 / Anthropic-compatible API |
| 后端模型 | deepseek-v4-flash | deepseek-v4-flash（显式 pin） |
| 运行时 | 1M context、并行 tool calls、freeform patch、multi-agent v2 | Claude Code 的 system prompt、工具协议、上下文与 subagent 规则 |
| 推理设置 | 配置 high；复杂会话实际 max | max effort，adaptive thinking 关闭 |
我特意使用 ccc-ds-flash，因为裸 ccc-ds 的主模型默认是 Pro，Flash 只映射在部分槽位。两边的 effort 语义、客户端版本、工具 schema、上下文压缩、权限和重试策略也不完全相同，所以这是可审计的工作流对照，不是“其他条件完全相同”的严格实验。
因此更准确的描述不是“V4 Flash 在 Codex 里好、在 Claude Code 里坏”，而是：
在我的长任务样本里，DeepSeek-V4-Flash-0731 通过 Responses API + Codex 运行时所呈现的有效交付表现，高于它通过 Anthropic-compatible API + Claude Code 运行时所呈现的表现。
背景只留三条公开信号
为了不让已知背景遮住论点，这里只保留三条对判断真正有用的信号：
- Harness 是 benchmark 条件。 DeepSeek 的更新日志写明，公开代码 Agent 任务使用自家的 Harness minimal mode；minimal 指最小评测运行环境，不是没有 Harness。这意味着成绩单测量的是模型、运行时和推理设置的组合。
- V4 Flash 为 Codex 做了特定适配。 官方称它原生支持 Responses API、specifically adapted for Codex；Codex 集成文档还写入了模型目录和工具能力声明。Anthropic 兼容线路能接通，但部分字段并不完全透传（兼容文档）。
- DeepSeek 开始组建第一方 Code Harness。 研究员招聘信息和岗位页把 Model + Harness = Agent 写进团队使命，并要求与模型训练协作。这证明战略下注和组织动作，不证明产品已经上线或商业成功。
三条信号的共同指向不是“DeepSeek 已经有一辆完成的车”，而是：它把模型被使用的执行面，也当成模型产品的一部分。
这些信号如何解释我的体感
下面是机制假设，不是这次单人样本已经证明的因果分解。我的核心判断也不是“Responses API 会把模型凭空变聪明”，而是：运行时决定模型每一轮看见什么、能做什么、错了以后能不能回来，以及什么时候算做完。长任务的差异，往往是这四个问题累积出来的。
1. 协议不是运输层，而是轨迹接口
模型每一轮都在读一种“工作语言”：请求怎样表达目标，工具结果怎样返回，中间状态怎样续上，哪些字段代表还要继续行动。协议因此不只是把文字从 A 送到 B 的运输层，它会影响模型对当前状态的解释。
如果模型和 Responses 结构共同适配过，运行时就可能更容易把状态按它熟悉的轨迹传回去；兼容层即使仍能生成有效答案，也可能重新映射或忽略部分字段，让长程行动少几个抓手。这里的“可能”很重要：要证明损失发生在哪里，需要原始 request/response 和 tool trace，而不是凭体验猜测。
这个假设有一个可检验的预测：固定任务、模型和工具，只换协议时，差异应该首先出现在被忽略的参数、状态重建、错误重试和中途重新规划的次数上，而不只是最终文字质量上。
2. 工具契约决定模型实际拥有的动作空间
read、edit、shell、search 不是四个按钮，而是一套 schema、参数、返回格式和失败信号组成的动作语法。模型能否完成任务，取决于它能不能把判断翻译成这套语法；工具名称相同，不代表动作空间相同。
更关键的是，模型的调优通常会适应某种工具契约和轨迹分布。第一轮请求成功，只说明电路接通，不能说明二十轮交互仍能收敛。一个参数被改名、一个错误变成模糊文本、一个补丁工具从结构化变成自由文本，都可能让模型从“执行”退回“描述”。
因此我更关心的不是“有没有工具”，而是四个细节：模型是否知道工具的边界、失败信号是否可读、动作结果是否能被下一轮直接引用、以及工具错误是否会触发明确的修复路径。
3. 上下文与恢复，把局部聪明变成长期工作
短问题里，模型只要给出一次好答案；长任务里，它必须一直记得目标、禁区、已验证事实、未完成分支和验收条件。上下文压缩如果只保留摘要，最容易丢掉的正是“为什么不能这么做”和“哪一步已经被验证”。
所以 Harness 的恢复能力比单次规划更重要：它能否从工具错误、测试失败和工作区状态发现偏航，保留失败证据，回退到最后一个稳定状态，再让模型重新规划？我在 Codex 这次会话里看到的是“读文件—修改—预览—发现问题—修复—复验”的闭环，而不是一次生成一版代码。
如果这层是主要差异，长任务的曲线应该表现为：前几轮两边都能启动，轮次增加后，恢复次数、重复劳动和上下文自相矛盾逐渐拉开，而不是一开始就出现完全不同的答案。
4. 验收规则决定“完成”到底是什么意思
模型说“完成了”，只代表它生成了一个自洽的叙述；对 Agent 来说，完成应该意味着文件存在、测试通过、页面没有溢出、权限没有越界，或者某个外部状态真的发生了变化。没有独立验收，运行时会把“看起来完成”误当成“已经交付”。
这也是为什么我把 acceptance Gate 单独算作 Harness 的一部分：它把模型的自我判断接到真实世界的证据上。好的 Gate 不需要替模型做判断，但必须能阻止未经验证的结论直接出场，并把失败变成下一轮可用的输入。
把“能力兑现率”写成一个可检验的假设
上一篇文章的公式是：
Model + Harness = Agent
这次可以把它写成一个概念模型：
Effective Agent = Model potential × Harness realization rate
这里的兑现率不是现成的单一指标，而是一个待测的工程变量。可以先拆成四个可观察维度：
| 维度 | 应该记录什么 | 失败时会看到什么 |
|---|---|---|
| 协议匹配 | 参数透传、状态续接、推理设置 | 字段被忽略、状态重建、行动中断 |
| 工具契约 | 调用成功率、错误类型、结果可引用性 | 参数反复改错、工具结果无法利用 |
| 上下文与恢复 | 压缩前后约束、回滚点、重试轮次 | 重复劳动、目标漂移、越错越远 |
| 验收与证据 | 测试、预览、文件状态、人工接管 | “已完成”但没有可验证产物 |
这样一来，“Harness 更好”就不再是一句无法讨论的体感，而是一组可以逐项对账的工程假设。
近期研究也开始把 Harness 当成独立评测轴。Harness-Bench与 Co-Harness都把模型–运行时配对和失败轨迹当成研究对象。它们是外部预印本，不是 DeepSeek 实验，能说明研究方向，不能替这次本地观察补上因果证据。
这个判断怎样被推翻
我不希望把 Harness 变成一个可以解释一切的词。只要把客户端版本、effort、权限、工具 schema、上下文和验收标准真正对齐，差异就大幅消失，那么这次观察主要可能是配置混杂；如果在多个任务、多个重复样本和原始轨迹里，差异仍稳定落在状态续接、恢复和验收上，Harness 解释才更有说服力。
换句话说，下一步不是再找一句更漂亮的口号，而是收集两套运行栈的原始 request/response、tool trace、失败类型和人工介入点。能指出差异发生在哪一轮，比再次宣布“某个模型更聪明”更有价值。
为什么短期内 Harness 可能是更粗的那条腿
这里的“更粗”只指特定任务窗口里的可兑现用户价值和产品迭代速度，不是说 Harness 能替代模型，更不能突破模型的知识与判断上限。它更可能成立的条件是：模型已经过了任务能力阈值，任务长、工具密集，而当前主要失败来自运行时。
可以把任务形状粗略分成三种：
| 任务形状 | 更可能的瓶颈 | 为什么 |
|---|---|---|
| 短问答、单步生成 | 模型 | 运行时几乎没有机会展示恢复和验收差异 |
| 模型尚未达到任务阈值 | 模型 | 工具再完整，也无法替代缺失的知识与判断 |
| 长任务、多工具、需要交付证据 | Harness | 失败主要来自状态、重试、权限和验收的累积损耗 |
在第三种任务里，Harness 的迭代周期可能短于模型权重迭代：
- 离失败现场更近。 它能看到调用格式错了、约束在压缩时丢了、测试没跑或需要回滚。
- 修复可以马上复用。 工具 schema、重试策略或验收 Gate 的一次改动，会影响后续每个任务。
- 能形成反馈与经济闭环。 单位任务成本不只是推理费用，还包括重试、等待、token 浪费和人工接管；可以把待验证的账写成：一次成功交付成本 = 推理 + 工具/重试 + 人工介入 + 延迟。Harness 每减少其中一项，用户就会立刻感到“模型变稳了”。在用户授权和隐私合规前提下，失败分类与验证轨迹再可能服务下一轮训练。
这也是它可能成为产品护城河的地方：默认工具、权限、记忆、验收和分发入口会提高迁移成本；真实任务轨迹和评测资产会形成反馈优势。但通用 Harness 也可能被开源和标准化，模型特化还可能带来锁定。持久壁垒最终要看专有任务数据、可靠性、企业集成和评测资产，而不是 prompt 包装本身。
对用户：比较完整配置，不要只比较模型名
最小可行的对照实验可以很简单：同一后端 model id、同一任务和代码状态，分别固定客户端版本、effort、权限与验收标准；每套至少重复 3 次，记录是否交付、返工时间、工具错误、人工介入和回滚。最好再把每次失败归类为协议、工具、上下文、恢复或验收问题。
若这些条件无法固定，就把结果称为“运行栈观察”，不要称为模型排名。评测结果最好标出完整配置：
deepseek-v4-flash × Responses × Codex × tool/context/recovery policy
这比只写一个 deepseek-v4-flash 更接近用户真正买到的东西。用户买到的从来不是一串 model id，而是一条从请求到证据的交付链。
对模型厂商：最好的发布物是 Model–Harness 配对
DeepSeek 已经展示了一个方向：把 Harness 写进 benchmark 条件，为 Codex 提供原生适配和能力声明，并通过招聘建立第一方 Code Harness。下一步若能公开 minimal Harness 的工具契约、上下文策略、推理设置和验收口径，开发者才知道“这个分数在哪辆车上跑出来”，第三方也才能复现或替换其中一层。
更重要的是，模型厂商争夺的将不只是参数、数据和算力，还包括谁先看到真实任务的失败、谁能最快修复运行时、谁拥有分发入口和反馈闭环。模型发布的最小单位，可能会从“一个 checkpoint”变成“一个经过验证的 Model–Harness 配对”。这仍是产业推论；DeepSeek 的公开招聘目前证明的是战略意图，不是产品成功。
结尾：比较完整的 Agent，而不是孤立的模型
DeepSeek V4 Flash 把我的观察推进了一步：模型没有变，模型—协议—工具—上下文—恢复组成的完整运行栈变了，于是有效能力变了。
对我的长任务样本来说，Codex 这座桥看起来更完整；真正值得追问的不是“哪家模型更聪明”，而是差异具体发生在协议、动作空间、状态恢复，还是验收证据上。
这也回扣上一篇：我当时观察到，Kimi K3 放在 Claude Code 里，反而比放在 Kimi 自家 Harness 里更好用。
模型给潜能，Harness 决定其中多少能稳定兑现。发布一个新模型时，别只问它有多少参数；还要问它配哪套 Harness、在哪辆车上测、失败轨迹会回到谁手里。
本文引用与延伸阅读
官方资料
- DeepSeek API 更新日志：DeepSeek-V4-Flash-0731（含 Harness minimal mode 与 Codex 特定适配）
- DeepSeek：Integrate with Codex（Responses API、模型目录与运行时声明）
- DeepSeek：Using the Anthropic API（模型映射与兼容字段）
- DeepSeek V4 Preview Release（V4-Flash 参数规模）
公开招聘与报道
- 陈德里：DeepSeek Code Harness 招聘帖
- DeepSeek / High-Flyer：Harness 产品经理与 Harness 研发工程师
- 甲子光年：DeepSeek 正在组建 Harness 团队
- Decrypt：DeepSeek Is Building Its Own Claude Code
延伸研究（预印本）
注：文中 Codex/Claude Code 的配置与会话是作者本机 2026-08-01 的快照；体验是个人工作流观察，不是独立第三方基准。公开招聘说明团队建设与战略方向，不代表 DeepSeek 已发布第一方 Harness 产品。