DeepSeek Harness 不止是编码Agent，可能指向AI自我进化

这两天看了很多关于 DeepSeek Harness 的讨论，但很遗憾，99%的讨论都没有真正搞懂DSH想要做什么。有人把它当成一个产品，认为 UI 粗糙、配置复杂、完成度低，所以 DSH 是个失败的 Agent 产品。也有人把它放到 Codex、Claude Code 旁边比较，讨论谁的 Coding Agent 工作流更完整。

这些讨论看起来都对。但如果仔细看 DSH 的架构，以及最近关于 Harness Self-Improvement 的一系列研究，我认为更值得讨论的问题其实是： DeepSeek Harness 可能是在为 Harness 层的 RSI 准备一套 Runtime。首先，今天绝大多数 Agent 都可以粗略抽��成： Agent = Model + Harness Model 提供底层的推理与决策能力，Harness 则定义模型如何观察环境、能够采取哪些动作，以及整个执行过程如何组织。

例如Codex、Claude Code，乃至更加开放的 Pi，都已经拥有越来越强的 Harness 扩展能力。开发者可以通过 Skill、Plugin、Hook、Extension 等机制加入新的工具和工作流，Pi 甚至允许替换内置 Tool、修改 Context 与 Compaction。但今天这些系统的 Harness，主体上仍然是由人类设计和演化的。

模型可以使用这些扩展能力，甚至帮助人类编写新的 Skill 或 Extension，但「应该修改 Harness 的哪一部分、修改以后是否真的更好、是否应该保留这个修改」通常还没有成为模型自身持续执行的优化循环。DSH 的在这一点上非常不同。DeepSeek 官方对它最核心的描述是：Everything is a Plugin。

这里的 Everything 包括 Model、Tool、Skill、Session、Sandbox、Storage、Agent Loop、Scheduling，甚至 UI。也就是说，传统 Agent 系统里很多被视为固定 Runtime 的部分，在 DSH 中都被重新暴露成了可以组合和替换的模块。仓库里的 Core 也采用了 event-sourced session log，并将 system prompt assembly、tool registry、agent、agent loop 等能力拆成相对独立的 subsystem。

这看起来很工程师，甚至有点太技术狂了。但如果把目标从「让人方便开发 Agent」换成「让 Agent 修改自己的 Harness」，这套设计就有了另一层意义。因为 Harness RSI 首先需要解决的，并不是模型够不够聪明。

而是三个非常工程化的问题： - Harness 是否可以被修改。- 修改前后的 execution trajectory 是否可以被完整观察和比较。- 一个修改是否能够被验证、保留，并进入下一轮迭代。

只有这些条件存在，Agent 才可能从： Model → 使用 Harness 逐渐进入： Model → 观察自己的失败 → 修改 Harness → 重新运行 → 比较结果 → 保留有效修改 也就是把 Harness 本身放进优化循环。刚好在这里推荐一下之前看过的 RHI 这篇论文，也就是 Recursive Harness Self-Improvement，研究的正是这个方向。RHI 把 Harness 表示成 Agent Loop 的 specification，让系统根据自己历史版本之间的 execution feedback，不断修改 Harness。

在30个机器学习研究任务中，只经过少量 Harness 迭代，低 reasoning effort 的 Agent 就可以超过对应 maximum reasoning effort 的配置，同时推理成本最高降低约60%。更值得注意的是，论文发现性能提升主要并不是来自「模型思考得更久」，而是来自更好的 task-specific context management 和 inter-agent information flow。这意味着一个很重要的事情： Agent 能力的上限，并不完全取决于模型，很大一部分也取决于 Harness。

同一个模型，给它不同的 Context 管理方式、工具结构、信息流、验证机制和 Agent Loop，可以表现得像两个完全不同的系统。因此 Harness 本身就成为了一个可以优化的对象。但事情走到这里还没有结束。

真正重要的是 Harness RSI 如何重新影响 Model。RHI 的论文里有一个我认为很关键的观点： Harness 不只是 inference-time scaffold，它同时也是 data-generating component。因为 Harness 决定模型：看到什么 Context、什么时候调用什么 Tool、如何获得 environment feedback、失败以后如何重试、如何进行 verification、以及最终留下什么样的 execution trajectory。

所以当 Harness 发生变化以后，改变的不只是一次推理结果。它实际上改变了模型未来训练数据的分布。更好的 Harness 产生更干净、更有效的 trajectories； 这些 trajectories 用来训练更强的模型； 更强的模型又能够发现此前弱模型无法发现的、更高阶的 Harness bottleneck。

于是 Model 和 Harness 不再是「模型升级，脚手架跟着适配」的单向关系，而开始形成共同进化。最后，从今天的产品完成度看，DSH 是个彻头彻尾的半成品。UI 很粗糙，门槛很高，普通用户完全没有理由选择它。

如果这不是 DeepSeek 发布的项目，它现在大概率根本不会获得这么大的关注。很可能只会在少数研究 Agent、Harness、Self-Improvement 的人之间流传。但这恰恰可能才是 DSH 有意思的地方。

DeepSeek 根本没想做下一个 Codex。这也是我现在理解 DSH 最重要的角度。从系统设计上看，DSH 至少提供了一块非常适合进行 Harness Self-Improvement 实验的土壤： 把原本写死的 Agent Runtime，变成一个高度模块化、可替换、可观测的 Runtime。

所以我不会用「它是不是比 Codex 好用」来评价 DSH。真正应该评测的是Agent 能不能自己提出 Harness 修改？能不能根据真实任务结果验证这些修改？

能不能把有效改变持续沉淀下来？最终能不能用改进后的 Harness 产生更好的训练数据，再反过来更新 Model？如果这些环节能够真正闭合，那么 DSH 的意义就远远不是一个 Agent Harness，它对应的是一个更大更未来的方向。

过去，我们优化模型，然后给模型写 Harness。未来可能是模型和 Harness 互相优化。Model 改变 Harness。

Harness 改变