DeepSeek V4 Pro正式版之谜：同一个模型，为啥能力差距会断档？

DeepSeek Harness 发布即大火，截至目前，GitHub Star 数已经将近 160K。

本来知危想好好体验一下 “ Everything is a Plugin ” 的魔力，但过程中先被一个基础问题卡住了，就是模型能力。

这也是 DeepSeek V4 Pro 正式版发布以来尚未彻底解决的问题。

首先，此前的 DeepSeek V4 Flash 的能力是得到大家认可的，知危简单体验了一下，写一个网页版 Excel、3D 引擎都是一遍过，这是目前开源模型第一梯队才能达到的水平。

但到了 DeepSeek V4 Pro 正式版刚发布、DeepSeek Harness 发布前，其接入 Codex 连写个简单的植物大战僵尸都会出 bug，比如豌豆射手的子弹打到僵尸身上没反应，或者写个网页版 Excel 实现的功能是不完整的或有 bug，比如缺少撤销/恢复功能，左右对齐/居中功能是失效的。

当时，社区普遍认为是需要配合 DeepSeek Harness 才能发挥最大的能力。

等 DeepSeek Harness 发布后，知危也第一时间尝试了“ DeepSeek V4 Pro 正式版+DeepSeek Harness ” 这个组合，结果仍然发生了和上述例子类似的问题。

而从社区反馈看来，这并不是偶然现象，社区实测认为 “ DeepSeek V4 Pro 正式版+DeepSeek Harness ” 是不如灰度测试预期的。

据 GitHub 开发者 xiaobright 描述，“ DeepSeek V4 Pro 会强烈依赖 API 中可见的工具目录选择执行轨迹。”

简单来说就是，如果你用的是 DeepSeek Harness 的极简模式，能直接激活 “ 高效 ” 模式，激发出最大能力，推理轨迹中会出现 “ we need ” 关键词，但如果用标准模式和 PTC 模式，则激活的是 “ 低效 ” 模式，能力直降一档，推理轨迹会出现 “ let me ” 关键词。

知危用标准模式来开发网页版 Excel 时确实能在轨迹看板中看到 “ let me ” 关键词。

而知危用极简模式来写网页版 Excel 时，确实能力更胜一筹，能一次完整地完成任务，在轨迹看板中也能看到 “ we need ” 关键词。

据社区解释，激发 “ 高效 ” 模式主要依靠的是首轮工具锚定，极简模式只有 2 项核心工具，标准模式有 25 个工具，“ V4 Pro 的核心能力并未丢失，但可能在强化学习 （ RL ） 后训练阶段对特定的 Harness 框架与工具暴露环境存在显著过拟合。”

为了能在激活 “ 高效 ” 模式后也能充分利用标准模式的 25 个工具，xiaobright 开源了插件 “ dsh-anchored-standard ”，该方案采用 “ 首轮锚定 + 动态晋升 ” 策略：首次请求仅暴露 2 项核心工具以锚定优质推理轨迹，一旦模型发起首次 Tool Call，立即在后续轮次解锁全部 25 项标准工具。

安装完这个插件后，就会在 DeepSeek Harness 的主界面的模式选项中出现一个 “ Anchored Standard (experimental)” 选项。

在这个模式下，知危写的网页版植物大战僵尸依然存在 “ 豌豆射手发射的子弹不能击中僵尸 ” 的 bug，但写网页版 Excel 是一次成功了。

之前用来对比 GLM 5.2 和 Claude Opus 4.8 的 “ 给开源 excel Luckysheet 增加权限管理系统 ” 的测试中，最后一道题是给现有的 “ 角色-权限 ” 体系细化粒度，细化到用户 ID 级别，构建 “ 用户-角色-权限 ” 系统。（ 任务的挑战在于，这是一个有近 5 万文件数和数十个功能模块的项目，权限管理系统属于自上而下的业务类功能，功能逻辑涉及多个文件和模块，主要考验业务理解和跨模块理解能力。）

在 “ Anchored Standard (experimental)” 模式下，给 DeepSeek 开 Max 思考强度，也能很好地完成最后的测试。

为了进一步探一探 “ DeepSeek V4 Pro 正式版+DeepSeek Harness ” 的上限，知危参考小红书用户 Amor.的 “ 四冲程柴油机 3D 交互仿真 ” 测试案例，让 “ Anchored Standard (experimental)” 模式、Max 思考强度下的 DeepSeek 尝试用 Three.js 写一个机器人 3D 仿真系统。

对于机器人本体，要把结构实现的非常细致，比如关节要有减速器结构，手必须是完整的五指灵巧手结构等等，还要提供行走、下蹲等运动仿真测试能力，以及详细的信息面板。

提示词如下 （ 已经过压缩简化 ）：

请生成一个高精度人形机器人 3D 交互仿真系统，要求如下：

一、整机结构与部件建模 （ 全尺寸、可拆解级精度 ）

完整呈现一台具有真实机械结构的双足人形机器人，整机比例合理，目标为约 25–30 个主动/被动自由度 （ DOF ）。

1. 主体结构

完整建模：

头部总成

颈部总成

胸腔 / 上躯干

腰部 / 躯干旋转机构

骨盆

左右大腿

左右小腿

左右足部

左右上臂

左右前臂

左右手腕

左右手掌

左右手指模块

主体结构需要体现真实的人形机器人机械比例，而不是简单的人体模型。

2. 关节与执行机构

完整呈现：

颈部俯仰 / 偏航 / 滚转关节

左右肩部多自由度关节

左右肘关节

左右腕关节

腰部旋转关节

左右髋关节

左右膝关节

左右踝关节

每个主要关节应包含：

关节外壳

电机 / 执行器

输出轴

减速机构

轴承

联轴结构

固定法兰

螺栓

密封件

结构连接件

可根据实际机械结构选用：

谐波减速器

行星减速器

RV 减速器

皮带 / 齿轮传动

不要求所有关节使用同一种传动方案，应体现不同关节根据负载、空间和运动范围采用不同设计。

3. 上肢机械结构

完整呈现：

肩部执行器

上臂结构件

肘关节执行器

前臂骨架

腕部执行器

手掌骨架

手指关节

手指执行机构或连杆结构

手部不能仅使用一个简单方块表示，应至少具有：

拇指

食指

中指

无名指

小指

手指至少体现基本关节结构和机械连接关系。

4. 下肢机械结构

完整呈现：

髋关节执行器

大腿主承力结构

膝关节执行器

小腿结构

踝关节执行器

足部支撑结构

脚掌 / 足底

重点体现下肢承重结构、关节连接关系和足部支撑结构。

5. 内部组件

打开外壳后可以看到：

电机

减速器

驱动器

控制板

电池模块

电源模块

主控计算单元

IMU

编码器

力 / 力矩传感器

关节位置传感器

温度传感器

通讯模块

线束

连接器

散热结构

需要合理安排内部空间，体现真实工程中的装配关系。

其它要求：

• 按照机器人真实运动学结构驱动。
• 当鼠标悬停于任一零件表面时，弹出悬浮信息卡。
• 支持拆解与装配。
• 视觉与呈现要求：采用 PBR 物理渲染。
• 界面提供实时状态面板。
• 模型应达到：全尺寸、高精度、工程结构级视觉精度。
• 使用 Three.js 等适合浏览器实时 3D 的技术实现，保证在普通桌面设备上能够流畅运行。
• 最终不能只是生成一个 “ 看起来像机器人 ” 的 3D 模型。必须形成一个真正的：“ 可观察、可操作、可运动、可拆解、可查询、可验证 ” 的人形机器人数字样机。

实际做出来的成果已经很出乎意料地完整，可以看到界面中包含了：每个零件的多维度信息面板，机器人本体机构的实时状态展示，不同运动状态、观察视图的选择，以及完整的机器人本体。选择 “ 下蹲 ” 运动后，机器人能做出顺滑的下蹲、起身动画。

当然，细节程度肯定还是不够的，放大关节后并不能看到减速器结构这样的细节。

但要知道，DeepSeek V4 Pro 没有原生多模态能力，能做到这种程度很不错了。那它是怎么做到的？查看轨迹后发现思维链有大量三角函数计算过程，看来是用几何函数思维补足了视觉思维。

另外，它完成的比标准模式下的 DeepSeek V4 Pro 要好多了，特别是本体设计上，标准模式下的模型莫名其妙地用了好多 “ 线轴” 来充数，动作方面只有单一的行走，也没有对每一个部件的多维度信息面板，走路还同手同脚。

从目前的实测结果来看，证据上是支持 “ 高效 ”、“ 低效 ” 两种模式的存在性，并且 “ 高效 ” 模式在模型能力上接近 Claude Opus 4.8，虽然没有同步测试对比的案例，但从视觉建模案例的效果来看，应该还达不到 Claude Fable 5 的水平。

用提示词或上下文显著改变模型的行为表现，从 CoT 刚被发现时就存在了，而模型对于 Agent 工具集合这类与任务本身相关性小的线索过度敏感这样的现象，也确实被学界所关注到了，2026 年发表的论文《Spurious Prompts: Can Irrelevant Prompts Steer Large Language Models?》就表明，语义上与任务无关的提示也能引导模型行为，甚至让其表现更优。

而其它一些与提示词相关的研究比如 2026 年发表的论文《Measuring LLMs’ Sensitivity to Paraphrased Opinion Prompt》则表明，如果模型对意义相近的提示词响应差距大，可能是模型后训练出了问题。

当然，以上探讨都不代表实锤，还是得等官方回应。

解决了模型问题之后，才能继续去研究 DeepSeek Harness 的创造模式，目前社区已经在非常积极地进行二创。

在 “ dsh-plugin ” 的 GitHub 话题下可以看到，给 DeepSeek Harness 补充视觉能力和自定义视觉主题的相关插件应该是最多的，但 DeepSeek Harness 的灵活性远不止于此，你可以将其改造成属于自己的 Codex 或 WorkBuddy，也可以在 DeepSeek Harness 下嵌套一个 Codex，或者反过来，在 Codex 下嵌套一个 DeepSeek Harness。至于更多的运行时、工作流编排等相关的插件，则是为了深入更动态、复杂的场景所需要。

X 上的开发者鸭哥表示，DeepSeek Harness 作为 Agent 框架，最大的特点是可以在运行时动态改变控制流的骨架，比如把单 agent 循环改成多 agent 协作循环，这是 Codex 等 Agent 框架做不到的。

但这种机制在什么场景下是必要的？鸭哥认为目前没有明确的答案，只是表示这“ 让 Harness 本身的行为具备了适应与演化的可能 ”。

知危原本设想在一个足够复杂的任务里或许能让 DeepSeek 自主激发这种能力，但在上述构建机器人仿真的案例中，DeepSeek 最终也只使用了一种 Agent Loop。

到此，对 DeepSeek Harness 的初步体验就结束了，希望后续能看到更多官方和社区反馈，解答我们诸多的疑惑，如果您有相关使用心得，也欢迎在评论区留言一起探讨~