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

本文来自微信公众号： InfoQ ，作者：褚杏娟，原文标题：《撞名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模型内部神经表征展开的可解释性研究。两者虽然名称相似，但技术对象和用途完全不同。

1不改模型权重，靠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日，项目之外的独立复现仍然没有出现。

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

3 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下一阶段要解决的问题还包括什么时候值得再让模型重试、什么时候继续运行已经不划算等。

4通用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适配模型？目前并没有标准答案。

参考链接：

https://explainx.ai/blog/j-space-cognition-suite-deepseek-v4-pro-harness-august-2026

https://github.com/Tiger3807861189/DeepSeek-V4-J-Space-Capability-Realization-Report

https://github.com/anomalyco/opencode/issues/16372?utm_source=chatgpt.com

https://arxiv.org/abs/2608.01964?utm_source=chatgpt.com

https://arxiv.org/abs/2608.15089?utm_source=chatgpt.com