ksxz
AILLMBenchmark

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

褚杏娟··原文链接
收录于 2026/8/20 10:22:16

事件概述：一个"外挂"引发的刷屏

J-Space Cognition Suite 是一个面向 DeepSeek V4-Pro-0813 的社区开源项目。它不是微调模型，也不生成新 checkpoint，而是在模型运行时外面套一层 Harness——通过重试、验证、记忆、状态维护和停止条件等外围机制来改善 Agent 最终表现。

项目方公布了亮眼数据：加入 J-Space 后，Terminal-Bench 2.1 从 87.9 提升至 90.1，NL2Repo 从 61.5 提升至 73.4（+11.9 分），Toolathlon-Verified 从 74.1 最高提升至 79.5。"DeepSeek V4 Pro 借助 J-Space 击败 Fable 5" 的说法随即在 X 上迅速传播。

J-Space Cognition Suite Benchmark 数据对比

核心问题：零第三方复现

据 ExplainX 梳理，截至 8 月 18 日，所有性能提升数据全部来自项目方自测，没有任何独立团队在相同条件下复现。Terminal-Bench、NL2Repo、Toolathlon-Verified 三项均无外部验证。

这很关键——Agent Benchmark 越来越依赖外围 Harness，最终分数受太多变量影响：模型是否允许重试、多少轮工具调用、是否有额外记忆模块、停止条件由谁判断、验证失败后是否自动回滚。严格验证应当做 A/B 测试（同一模型，一组用 J-Space，一组不用，其余变量全控一致），但这样的复现至今没有出现。

撞名 Anthropic：此 J-Space 非彼 J-space

最容易产生误解的是名字本身。2026 年 7 月，Anthropic 发表了关于 Claude 内部"J-space"神经表征的可解释性研究，基于全局工作空间理论（Global Workspace Theory）分析模型内部信息传递。

而 J-Space Cognition Suite 是完全不同的东西——运行在 DeepSeek V4 Pro 外部 的推理时 Harness，与 Anthropic 无官方关系。两者技术形态截然不同：Anthropic 研究模型内部表征，J-Space 处理模型外部 Agent 执行流程。但命名确实迷惑了大量人，不少尝试者反馈无法复现。

有开发者扒了 GitHub 仓库后直言：这就是 "skill plugin"，即运行在模型外围的 skill 或脚手架。

开发者实测：Token 开销不降反增

一位开发者用 DSH + V4 Flash（DeepSeek 官方 API）跑了 10 个编程任务后得出实测数据：

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

结论：没有观察到所谓的成本节省效果，实际 Token 消耗反而更高，推理表现也没有超过不使用 J-Space 的裸 DeepSeek。

"这就是炒作，而且是假的。我没能复现其中任何一项说法。实际上，它消耗的 Token 反而比基线更多。"

Harness 进入"补短板"阶段

尽管 J-Space 缺少独立复现，但它试图解决的问题确实是行业共性痛点：

  1. 长任务状态管理：LongHorizon-Harness 研究将其概括为 "task-state management problem"——任务执行、状态和完成判断全放在膨胀的上下文中，状态越来越难追踪
  2. Compaction 矛盾：上下文不压缩→Agent 越来越臃肿；压缩→可能丢失任务目标、状态甚至权限边界（OpenCode 曾出现只读 Explore Agent 在 Compaction 后开始修改文件的 bug）
  3. 过早停止：Agent 还没完成任务就提前宣布结束。StateM 研究将其列为典型失败模式，通过持久状态、阶段化上下文和可恢复 Runbook 约束执行过程
  4. 成本爆炸：17 个前沿模型在 Long-Horizon-Terminal-Bench 上平均每任务消耗 980 万 Token，239 个回合，88.9 分钟

模型厂商正在快速补课。DeepSeek DSH v0.1.0-rc.7 增加了子 Agent Job Panel 管理、MCP 图片持久化、low 推理强度选项等系统层改进，而非单纯增加新工具。

通用 Harness vs 模型原生 Harness：路线分化

社区与厂商正在走向两条路线：

  • 通用路线（OpenCode）：将 Build/Plan/General/Explore/Scout 等 Agent 拆成不同权限和职责，Subagent 分工协作。但多 Agent 让权限管理变复杂——曾出现父 Agent 禁止写文件却可通过调用有写权限的 Subagent 绕过的问题
  • 模型原生路线（DeepSeek DSH / OpenAI Agents SDK）：DeepSeek 将 Model Adapter、Agent Loop、Session、Sandbox、Approval Policy 纳入统一插件架构；OpenAI 明确提出 "model-native harness"，将 Memory、文件/Shell 工具、Skills、Compaction 集成进 Agent Loop，同时把 Harness 和代码执行 Sandbox 拆成两层

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

Zero 的看法

这篇文章值得关注的不是 J-Space 本身——一个未经验证的社区项目，核心实现不过是 skill plugin + Python 看板脚本，实测 Token 反增。真正有信息量的是它揭示的 Agent Harness 工程化趋势：

  1. Benchmark 信用正在贬值。Agent Benchmark 分数越来越取决于 Harness 而非模型本身，重试次数、工具权限、停止条件、验证回滚都能显著改变成绩。没有 A/B 对照的 benchmark 数据，参考价值大打折扣
  2. 长任务状态管理是下一个工程主战场。Compaction 权限丢失、过早停止、上下文膨胀——这些问题对任何做 Agent 工程化的团队都是实打实的痛点。OpenCode 的 Compaction Agent bug 和 DSH 的 Job Panel 管理都是值得跟踪的工程实践
  3. 模型原生 vs 通用 Harness 的路线之争会持续。厂商有模型行为数据的优势，但通用 Harness 的跨模型兼容性对用户更有吸引力。短期内两者会并存

对于实际做 AI 编程工具落地的工程师：别被 "V4 Pro 碾压 Fable 5" 的标题党带节奏，关注 DSH、OpenAI Agents SDK、OpenCode 的 Harness 架构演进和 Compaction/状态管理实践，才是真正可迁移的工程经验。

评分：
暂无（0 人评分）
返回首页