DeepSeek V4 Pro正式版发布三天，口碑从“逼近Fable 5”跌到“不如Flash”，但事情没那么简单！
2026年8月12日深夜，DeepSeek通过API文档更新悄然上线了DeepSeek-V4-Pro-0813。官方跑分漂亮得惊人——Terminal Bench 2.1拿到87.9分，距离全球第一的Anthropic Fable 5只差0.1分。但第三方测试机构Vals用自研的Terminus 2 Harness跑了一遍同一模型，只拿到54.68分。33.22分的差距。同一个模型，不同的测试框架，分数直接蒸发掉三分之一。这不是误差，这是整个社区都在追问的一个问题：DeepSeek V4 Pro到底是真的强，还是只会在自家Harness里考试？
官方跑分87.9，第三方实测54.68，33分的差距直接把社区炸开了
先看官方数据。DeepSeek官方公告显示，V4 Pro正式版在Terminal Bench 2.1上得分87.9，预览版只有72.1。DeepSWE从预览版的12.8分飙到62.7分，涨了近五倍。Cybergym拿到83.3分，直接反超了竞品。七项Agent测试全面领先Flash，性能梯度清晰。配合1.6万亿总参数、每次推理激活490亿参数的MoE架构，以及每百万Token输入3元、输出6元的价格——官方传达的信息很明确：旗舰性能，白菜价格，逼近全球第一。
但Vals AI的独立测试给出了完全不同的画面。在Terminal Bench 2.1的三轮完整测试中，V4 Pro只拿到54.68%的平均分，在52个模型中排名第33。硬任务（hard tasks）上更惨，只有28.89%。也就是说，同样一个Terminal Bench 2.1，官方跑出87.9，第三方跑出54.68。同一个benchmark，同一个模型版本，差距33.22分。这已经不能用“测试条件略有不同”来解释了。这就怪了！
DeepSeek自己先打了预防针：你们测的和我测的可能不一样
回头看DeepSeek的官方公告，有一句话当时被大多数人忽略了：“对于公开基准测试集中的Code Agent任务，DeepSeek-V4-Pro-0813使用DeepSeek Harness极简模式作为框架进行测试（使用max档位，topp=0.95，temperature=1.0），其他框架下结果可能略有不同。”
“可能略有不同”——这话说得太轻了。33分的差距叫“略有不同”吗？但DeepSeek确实提前声明了测试框架：DeepSeek Harness的Minimal模式。问题在于，大多数第三方测试者没有用这个模式。他们用的是自己的Harness，或者DeepSeek Harness的Standard模式。然后分数就崩了。
这就引出了第一个认知翻转：不是DeepSeek造假，而是他们测试用的那个“壳”——Harness Minimal模式——可能才是激活V4 Pro真实能力的关键。
Minimal模式不是“简化版”，它是模型训练时的原生环境
DeepSeek Harness是DeepSeek开源的Agent运行时，DeepSeek曾给出过一个公式：Model加Harness才等于Agent。模型是大脑，负责思考和推理；Harness是身体和神经系统，提供工具调用、文件读写、沙箱环境。Harness内置四种预设模式：Minimal（极简）、Standard（标准）、Code（代码）、Cordis（创造）。
Minimal模式长什么样？系统提示词只有一句话：“You are a helpful software engineer assistant.”。只暴露两个工具：bash和str_replace_editor。禁止向系统提示词注入任何额外的身份指引和工具引导，禁用运行时上下文注入，省略上下文压缩。整个Minimal模式的系统提示词才4KB。对比一下，Claude Code 2.1.153版的系统提示词有93KB。
Minimal模式不是Standard模式的“精简版”。它是专门为V4 Pro的RL训练接口设计的——发送的是训练时用的那套精确的RL提示词和工具schema。换句话说，V4 Pro在训练时就是在Minimal模式这种环境下学会使用工具的。你让它用Standard模式的25个工具、带一堆上下文注入和压缩策略的环境去跑，它反而懵了。
同一个Harness里，换个模式分数就从99掉到91
真正致命的数据来自社区在DeepSeek Harness内部做的对比实验。开发者xiaobright的modeltest项目在Project2评测中发现：V4 Pro在DSH Minimal加max档位下连续两跑拿到99分和96分。但同样的环境——同样的WSL、同样的max档位——切换到Standard模式，分数掉到91分。切换到PTC（DeepSeek的Code模式配置），只有92分。
三个模式都在DeepSeek Harness内部跑。框架没换，模型没换，机器没换。换的只是预设配置——系统提示词、工具列表、上下文注入策略。分数从99跌到91。这直接否定了“模型只过拟合了DeepSeek Harness这个框架”的说法。问题不在框架，而在框架里的那个“入口”——Minimal模式的那套提示词和工具schema。
首轮只给两个工具，第一轮调用后解锁全部25个，分数立刻回到98
社区接着做了一个更聪明的实验。他们设计了一个叫“anchored-standard”的两阶段预设：第一轮请求只给Minimal模式的两个工具（bash和str_replace_editor）和那句极简系统提示词。模型发起第一次工具调用之后，从第二轮开始恢复Standard模式的全部25个工具。
结果是什么？在Windows原生Project2测试中，这个“锚定标准”方案连续跑出98分和99分。跟灰测的99/96、Fable 5的98、Opus 5的97、GPT-5.6-sol的99/98处在同一个顶端分数带。模型不需要一直待在两个工具的环境里。它只需要从那里开始。第一轮的那个极简提示词和两个工具的schema，像一把钥匙，把模型最强的Agent策略给激活了。一旦激活，给它25个工具它照样用得好。这就像一辆赛车，你非得用特定的点火方式才能启动它的满血模式。启动之后，换什么轮胎、加什么油都不影响它飙车。
V4 Pro的天花板极高，但入口极窄——这不是过拟合，这是接口依赖
所以问题的本质是什么？不是DeepSeek故意把模型过拟合到自家Harness上骗跑分。而是V4 Pro的Agent后训练产生了一个副作用：它对初始的系统提示词、工具schema、上下文注入策略极其敏感。
同一个API端点，同一个deepseek-v4-pro模型，在不同条件下会表现出三种截然不同的推理风格。一类频繁以“Let me”开头，接近预览版。一类常出现“The user wants me”，类似Flash。另一类大量使用“we”，被社区称为能力更强的“神版V4 Pro”。这三种风格的性能差异极大。Minimal模式触发的是第三种——“we need”风格，也就是最强的那个。Standard模式触发的往往是“Let me”风格，性能差一截。
V4 Flash在不同Harness下表现更稳定，但峰值性能较低。V4 Pro反过来：上限极高，但不够鲁棒，换一个Harness、换一套提示词、换一种工具暴露方式，性能就可能大幅波动。这不是过拟合，这是接口依赖。模型的最强策略没有被藏起来，只是触发它的“入口”非常窄。
同一个模型，换了个壳就差一倍——Agent能力的评测标准该重新想了
这件事最让人回不去的地方在于：它动摇了我们对“模型能力”这个概念的认知。当我们说一个模型“强不强”的时候，我们到底在测什么？是模型本身的权重？还是包裹它的那个Harness？DeepSeek给出的答案是：两者不可分割。Agent等于Model加Harness。这意味着，脱离Harness谈Agent模型的能力，本身就是个伪命题。
但问题来了——如果不同的Harness测出同一个模型33分的差距，那整个行业靠benchmark排名来评判模型优劣的做法还成立吗？Terminal Bench 2.1上官方87.9、第三方54.68；DeepSWE上官方62.7、mini-swe-agent上63%正负6%——同一个模型在不同Harness下表现天差地别。这到底是模型的问题，还是评测标准的问题？
V4 Pro在SWE-bench Verified上用mini-swe-agent配合单个Bash工具跑出了96.4%。这说明V4 Pro的能力确实存在，而且很强。但前提是——你得用对“壳”。Minimal模式的4KB提示词、两个工具、零上下文注入——这套配置看起来简陋，但它恰好是V4 Pro训练时的原生环境。你用Standard模式的25个工具、93KB的提示词、各种上下文压缩策略去跑，反而把模型最强的策略给“淹没了”。
那33分不是被藏起来了，是被你用的那个“壳”挡在了外面
回到最初那个问题：DeepSeek V4 Pro到底有没有过拟合到DeepSeek Harness？更准确的答案是——它确实对Minimal模式的那套提示词和工具schema产生了极强的依赖，但这种依赖不是“只能在Minimal模式下工作”，而是“必须从Minimal模式启动”。一旦启动成功，模型可以在任何工具集下正常工作。
这像什么？像某些高端跑车必须用特定的启动程序才能激活运动模式。启动之后你怎么开都行，但启动那一下的流程不能错。V4 Pro的最强Agent策略一直都在那里，没有被隐藏，没有被阉割。只是进入那个策略的门，窄得只容一个人侧身通过。
但还有一个细节让这件事变得更有意思：GitHub上已经有开发者报告，即使在同样的anchored-standard预设下，也未能稳定复现98/99的高分。有人在Windows上跑出来了，有人在同样的条件下没跑出来。这意味着“入口窄”可能还不是故事的全部。首轮锚定能大幅提高触发概率，但似乎还有别的变量在起作用——也许是运行环境，也许是API路由，也许是某个还没被发现的触发条件。这件事，还没完。