整理 | 褚杏娟 最近，一个名为 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-2026https://github.com/Tiger3807861189/DeepSeek-V4-J-Space-Capability-Realization-Reporthttps://github.com/anomalyco/opencode/issues/16372?utm_source=chatgpt.comhttps://arxiv.org/abs/2608.01964?utm_source=chatgpt.comhttps://arxiv.org/abs/2608.15089?utm_source=chatgpt.com声明：本文为 InfoQ 原创，不代表平台观点，也不构成投资建议，未经许可禁止转载。

        今日好文推荐Dario “破防小作文”超千万人围观！

        LeCun 开炮：信任危机是因为你搞权力集中梁神变牢梁的原因找到了！

        疑似 DeepSeek 发错模型，HF配置和API后台紧急切换编程能力提高50%！

        GLM-5.3 满分通过了GPT-5.6给的Coding 测试Gemini 3.7 Flash 突袭！

        谷歌AI紧急换帅后的首个大动作，“内斗”真相浮出水面会议推荐2026 年 AICon 人工智能开发与应用大会 · 深圳站将于 8 月 21 日—

        22 日举办，10大专题+1个动手实验室、近60场重磅议题，集结浙大知名高校教授及阿里、腾讯、Google Cloud等头部企业技术专家，聚焦 Agent 工程化，构建可靠智能的技术路径。