撞名Anthropic的“外挂”刷屏：让“DeepSeek V4‑Pro碾压 Fable 5”但无人能复现，Token开销反而翻倍

最近，一个名为 J-Space Cognition Suite 的社区项目近日在 X 上快速传播。项目方声称，在完全不修改 DeepSeek V4-Pro-0813 模型权重的情况下，仅通过一套推理时 Harness，就能显著提升模型在多项 Agent Benchmark 上的表现，甚至超过 Fable 5。

不过，这一看起来颇为惊人的结论目前仍缺少最关键的一环：第三方复现。据 ExplainX 梳理，截至 8 月 18 日，J-Space Cognition Suite 公布的所有性能提升数据均来自项目方自己的测试，尚未有独立团队在相同条件下复现相关结果。因此，“DeepSeek V4 Pro 已经借助 J-Space 击败 Fable 5”目前仍然只能被视为项目方及社区传播中的主张，而不是已经得到验证的事实。

更容易引发误解的是，J-Space Cognition Suite 与 Anthropic 此前公布的 J-space 研究并不是同一个东西。前者是一套面向 DeepSeek V4 Pro 的第三方 Agent Harness，后者则是 Anthropic 对 Claude 模型内部神经表征展开的可解释性研究。两者虽然名称相似，但技术对象和用途完全不同。

不改模型权重，靠 Harness 把 V4 Pro“榨干”？

J-Space Cognition Suite 是一个面向 DeepSeek V4-Pro-0813 的社区开源项目。本质上，它并不是一个经过微调的新模型，也没有生成新的模型 checkpoint，而是在模型运行时外面增加一层 Harness，通过调整 Agent 的任务执行流程改善最终表现。

项目方认为，DeepSeek V4 Pro 在长时间 Agent 任务中存在两个主要问题：一是“表征漂移”，二是“过早停止”。

所谓表征漂移，可以理解为模型执行长链路任务时，随着步骤不断增加，当前工作状态逐渐偏离最初目标，具体表现可能包括忘记此前的重要上下文、重复已经完成的工作，以及在任务持续推进过程中逐渐“跑偏”等。

“过早停止”的定义则更加直接，即 Agent 实际上还没有完成任务，却提前认为工作已经结束。例如在代码尚未完全修改、测试尚未完成或者仍存在错误的情况下，模型已经宣布任务完成并停止执行。

J-Space Cognition Suite 的核心思路并不是重新训练模型，而是在 Harness 层改善重试、验证、记忆、状态维护和停止条件等外围机制。项目背后的假设是：DeepSeek V4 Pro 模型权重本身已经蕴含更强的能力，只是现有 Agent 运行框架没有充分释放这些能力。

从这一角度看，J-Space 提出的是当下越来越受 AI 开发者关注的问题：同一个模型，在不同 Harness 下，究竟能够表现出多大的能力差距？

目前，在其官方 GitHub 上公布的一组数据显示，加入 J-Space Cognition Suite 后，DeepSeek V4-Pro-0813 在 Terminal-Bench 2.1 上的成绩从 87.9 提高至 90.1；NL2Repo 成绩从 61.5 提高至 73.4；Toolathlon-Verified 则从 74.1 最高提升至 79.5。

其中，Terminal-Bench 2.1 提升 2.2 分，NL2Repo 提升 11.9 分，Toolathlon-Verified 最高提升 5.4 分。也正是这些成绩，推动了“DeepSeek V4 Pro 通过 J-Space 击败 Fable 5”的说法在 X 上迅速传播。

一个对项目相对有利的细节是，其公布的改造前基准与 DeepSeek 官方成绩基本接近。这至少意味着项目没有通过人为压低 DeepSeek 原始基线来制造夸张提升。

但真正重要的问题发生在“改造后”。

ExplainX 指出，目前这些提升后的数字全部来自 J-Space Cognition Suite 项目方自己运行的 Benchmark。包括 Terminal-Bench、NL2Repo 和 Toolathlon-Verified 在内，尚未发现项目之外的独立团队按照相同模型、Prompt、Harness、工具权限和推理预算重新跑出类似结果。

因此，“DeepSeek V4 Pro 现在已经全面超过 Fable 5”还不能作为一个已经确认的 Benchmark 事实。尤其是在 Agent Benchmark 越来越依赖外围 Harness 的情况下，仅有最终分数已经很难说明全部问题。模型是否允许重试、可以执行多少轮工具调用、是否拥有额外记忆模块、任务停止由谁判断、验证失败后是否自动回滚，这些因素都可能显著改变最终成绩。

真正严格的验证方式，应当是针对同一个 DeepSeek V4-Pro-0813 进行 A/B 测试：一组使用 J-Space Harness，一组不使用；除此之外，Prompt、工具权限、推理强度、测试环境以及其他变量全部保持一致。只有在这种条件下，才有可能判断性能提升究竟来自 Harness 本身，还是 Benchmark 波动以及其他实验变量。

截至 8 月 18 日，项目之外的独立复现仍然没有出现。

此 J-Space，与 Anthropic 研究不是一回事

此次事件中最容易产生误解的地方，是“J-Space”这个名字。

2026 年 7 月，Anthropic 曾发表一项关于 Claude 内部“J-space”的研究。该研究关注的是 Claude 内部一组特殊的神经表征，并尝试从“全局工作空间理论”（Global Workspace Theory）的角度理解模型内部信息如何被读取、传递和利用。这是一项模型可解释性研究。

而此次围绕 DeepSeek V4 Pro 传播的 J-Space Cognition Suite，则是完全不同的社区项目。它是一个运行在 DeepSeek V4 Pro 外部的推理时 Harness，与 Anthropic 没有官方关系，也不是将 Anthropic 的 J-space 直接移植到了 DeepSeek。

J-Space Cognition Suite 使用了一些类似“global workspace”的语言描述自己的推理机制，其命名究竟是受到 Anthropic 研究启发，还是单纯的命名巧合，目前并不能确认。但从技术形态来看，两者区别非常清楚：Anthropic 研究的是模型内部表征，而 J-Space Cognition Suite 处理的是模型外部 Agent 执行流程。

也就是说，社区目前传播的“V4 Pro + J-Space”并不是“DeepSeek 用上了 Anthropic 发现的 J-space”。但这个命名确实迷惑了很多人，不少人在尝试后反馈无法复现，没有得到很好的结果。

有开发者扒了 J-Space 的 GitHub 仓库代码后，直言这就是“skill plugin”，即运行在模型外围的 skill 或脚手架。

不过也有网友指出，J-space 也可以通过提示词来操控，比如“先思考一下 XYZ，然后再说 blablabla”，并不一定非要通过直接注入的方式。所以，理论上确实可以用这种方式来利用 J-space，但具体怎么做、哪些方法有效，仍然需要实际的探针实验去验证。

“这就是炒作，而且是假的。我没能复现其中任何一项说法。实际上，它消耗的 Token 反而比基线更多，推理表现也没有超过不使用这个 Skill 的 DeepSeek。”有尝试过的开发者说道。

还有开发者尝试用 DSH 跑了一遍后，发现它确实能够运行，并且也表示，它的实现形式是一个 Skill，再加上一些 Python 辅助脚本，用来做类似看板的持久化任务管理。不过，这次测试的 10 个任务都比较简单，虽然覆盖了不同类型的编程工作，但可能也是测试结果不理想的原因之一。

该开发者测的是 V4 Flash 的 Token 消耗，不是 Pro 版本，（不过项目方也提到这套方法对 Flash 同样有效，只是提升幅度会更小），并且用的是 DeepSeek 官方 API。测试结果如下：

• PI：作为基线。
• PI + J-Space：成本大约是基线的 2～4 倍。
• DSH + J-Space：Token 消耗相比基线高约 50%。

该开发者的结论是，用原生 Harness + V4 Flash 跑了一个设计得并不严谨的 Benchmark 后，其没有观察到所谓的成本节省效果。相反，相比直接使用裸 PI，实际 Token 消耗反而更高。

J-Space Cognition Suite 的传播还与另一个名字发生了交叉：Operation Cheepseek。

同期，OpenCode 宣布“Operation Cheepseek: Phase 1 Complete”，OpenCode Go 用户据称可以以 10 美元获得 30 美元额度。与此同时，OpenCode 还将 DeepSeek V4 Flash 的请求限额从每 5 小时 31,650 次调整到 3,800 次，降幅约 88%。

由于这些信息都集中出现在 DeepSeek、Agent Harness 和 OpenCode 相关社区中，部分传播内容开始将 OpenCode 的 Operation Cheepseek 与 J-Space Cognition Suite 联系起来。

但 ExplainX 指出，目前没有证据能够证明两者属于同一个项目，也没有证据表明这是一次协调行动。因此，在缺少进一步信息之前，将两件事直接合并是不准确的。

Harness 进入“补短板”阶段

J-Space 尽管仍缺少独立复现案例，但它所试图解决的问题并不特殊：长任务状态怎么保存、模型什么时候应该继续、什么时候真正完成、工具失败后如何恢复、上下文越来越长后如何避免遗忘，以及这些机制需要付出多少额外 Token 成本，正在成为几乎所有 Agent Harness 共同面对的问题。

模型厂商和开源社区也正在围绕这些问题快速补课。

这种变化从 DeepSeek Harness 最新的更新内容中也能看出来。8 月 17 日发布的 v0.1.0-rc.7 增加了 Codex 和 Claude Code 子代理任务的 Job Panel 管理、MCP/ACP 图片附件持久化，同时修复了极简模式下 Persistent Bash 卡顿、大历史消息分页栈溢出以及 max-token 截断后会话无法继续等问题。DeepSeek 还新增了 low 推理强度选项。相比“增加一个新工具”，这些更新更集中在子 Agent 调度、长会话、状态恢复和推理成本控制等系统层问题。

Harness 目前最明显的短板之一，是长任务状态管理。

8 月发布的“LongHorizon-Harness”研究直接把这一问题概括为“task-state management problem”。研究人员指出，现有 Agent Harness 通常将任务执行、任务状态和完成判断全部放在持续膨胀的上下文中，状态越来越难追踪，错误的自我判断也可能继续传播。

这也是 J-Space 引入类似 Kanban 的外部持久化设计的原因。其思路并不是单纯要求模型“记性更好”，而是在模型之外保存任务进度，让 Agent 即使在某一轮推理中发生遗忘或偏离，也还有机会被外部状态拉回原来的任务轨道。

但状态外置并没有彻底解决问题，因为长上下文通常还需要另一个机制：Compaction（压缩），即把越来越长的历史压缩成更短的摘要。

OpenCode 目前就内置了一个隐藏的 Compaction Agent，当上下文过长时自动生成更短的状态摘要；同时，它还将 General、Explore、Scout 等不同 Subagent 分工处理不同任务。

但社区实际使用也暴露出 Compaction 的风险。OpenCode 今年的一项 Issue 报告称，一个原本被定义为只读的 Explore Agent，在触发 Compaction 后可能丢失原有权限约束，开始修改文件。问题提出者因此建议 Compaction 必须保留原 Agent 的工具和权限限制。

这揭示了当下一个很现实的矛盾：上下文不压缩，Agent 会越来越臃肿；压缩以后，又可能丢失任务目标、状态甚至权限边界。

Agent 会做事以后，新的问题变成“什么时候算真正做完”。因此，越来越多 Harness 开始把 Verification 和 Stop Condition 从模型自己的语言判断中拆出来，比如 DSH 甚至将 agent/turn-stopping 设计为一个独立扩展节点，插件可以在模型准备结束任务时继续介入。

近期的 StateM 研究也把“过早停止”列为长任务 Agent 的典型失败模式之一。研究者没有改变底层模型权重，而是通过持久状态、阶段化上下文、经过检查的状态转移以及可恢复 Runbook 来约束执行过程。论文报告称，相同 Harness 可以将 DeepSeek V4 Flash 在 Terminal-Bench 2.1 上的成绩从 82.7% 提高至 88.1%，并进一步讨论了使用廉价模型和 Harness 控制实现更高性价比的可能性。

但验证、重试和更多状态检查也带来了新的成本问题。

有研究团队对 17 个前沿模型进行了 Long-Horizon-Terminal-Bench 评测。结果显示，Agent 平均每项任务消耗约 980 万 Token，每次运行大约经历 239 个执行回合，平均执行时间为 88.9 分钟。

因此，Harness 下一阶段要解决的问题还包括什么时候值得再让模型重试、什么时候继续运行已经不划算等。

通用 Harness 还是模型原生 Harness？

另一个正在形成的分化是，社区越来越希望 Harness 能够兼容所有模型，而模型厂商则开始主动开发更贴合自身模型特性的原生 Harness。

OpenCode 属于典型的通用路线。它将 Build、Plan、General、Explore 和 Scout 等 Agent 拆成不同权限和职责，让 Subagent 之间分工协作，同时通过 Permission 体系限制文件编辑和 Shell 操作。

但多 Agent 也让权限管理明显变复杂。今年 4 月，OpenCode 曾被报告存在父 Agent 禁止写文件，但可以通过调用拥有写权限的 Subagent 绕过限制的问题。后续修复方案开始将父 Session 中的 deny 规则和外部目录权限传递给子 Agent。

而模型厂商正在选择另一条路线：更深地了解自己的模型行为，并围绕这些特性设计 Harness。

DeepSeek 直接推出官方 DSH，将 Model Adapter、Agent Loop、Session、Sandbox、Approval Policy 等都纳入统一插件架构；OpenAI 今年 4 月升级 Agents SDK 时，则明确提出“model-native harness”，将 Memory、文件和 Shell 工具、Skills、Compaction 等能力集成进 Agent Loop，同时把 Harness 和真正执行模型生成代码的 Sandbox 拆成两个层次，以提高隔离性、持久性和扩展能力。

是让模型适配 Harness，还是让 Harness 适配模型？目前并没有标准答案。

本文来自微信公众号“InfoQ”（ID：infoqchina），作者：褚杏娟，36氪经授权发布。