当 Harness 注定被模型吞噬——为什么 DeepSeek 反过来把它做成"可拼装运行时"

8 月 13 日，DeepSeek 正式发布了第一款 Agent 产品 DeepSeek Harness（DSH）。同一天，DeepSeek-V4-Pro 正式版上线。

往前倒两个月，6 月 14 日，红杉资本播客上，Google AI Studio 负责人 Logan Kilpatrick 抛出一句让整个 AI 圈坐不住的话："最短在 12 个月内，Harness 会被模型吞噬掉，红利会转移到其他地方。"

同样的两个月里，DeepSeek 的工程师没停手。他们没去赌"Harness 会消失"，反而把 Harness 做成了一款比 Codex 更狠的产品——可拼装的 Agent 运行时。

这就是值得停下来想一想的反向押注：在所有人都觉得 Harness 会被吃掉的时候，梁文锋这帮人押的是——Harness 才是 Agent 时代的事实标准。

同一模型、不同 Harness，差距有多大

为了不被任何人说"模型决定论"或"Harness 只是壳"带偏，先看一组对照实验。

爱范儿 APPSO 拿到 DSH 内测资格后，让同一个 DeepSeek-V4-Flash 模型在三个不同的 Harness 里跑同一个任务：用 Three.js 写一个滑沙游戏。

DSH 版本里，玩家从一开始就滑行、穿过每个门、画面配色金黄阳光、沙漠绿洲做完整收尾。Reasonix 版本画面粗糙，金字塔、人物、天空都不像一款 3D 游戏。Codex+V4 Flash 干净工作区版表现合理，但配色和细节明显单薄。

模型完全相同，Harness 不同，产物完全不同。

这件事对"模型会吞噬 Harness"的论断是直接打击：哪怕 V4 Flash 是同一个月训练的版本，不同 Harness 给出的工具、提示词、上下文组织、执行策略，足以把"模型能做什么"这件事彻底改写。Logan 说的"12 个月被吞噬"——至少在 2026 年 8 月的实测里，没发生。

DSH 的核心解法：一切皆插件，但插件必须"可逆"

DSH 的官方关键词是"everything is a plugin"。模型接入、工具执行、会话记录、循环本身、界面，全部走插件机制。

这不是营销话术。它把整个框架构建在一个开源项目 Shigma 的 Cordis 之上。Cordis 的定位很朴实：一个处理依赖注入、作用域服务、生命周期清理的通用 JavaScript 框架，跟 Agent 没关系、跟 LLM 没关系。

光有"一切皆插件"还不够。普通插件系统的麻烦在于：插件一多，谁来清理、谁负责卸载、出错怎么办？VSCode 的扩展宿主不能卸载单个扩展，禁用/卸载必须重启整个宿主；Koishi 改完配置也要 reload daemon。

DSH 选了另一条路。每个插件的生命周期都通过 ctx.effect() 登记，副作用和它的"逆"写在一起，框架在卸载时按 LIFO（后进先出）反序逐个撤销。子 Fiber 自动级联清理，作者不用写卸载路径。

这套机制解决了一个具体问题：自进化 Agent 的可行性。

腾讯程序员 chino 在 8 月 14 日的深度拆解里引用了 Cordis 论文的一句话——"未来的 harness 会在持续服务请求的同时生成并部署对自己组件的修改……没有时间可组合性，每次自我修改都迫使完整重启，丢弃所有进程内累积状态。"

**没有"可逆"，自进化就是空话。**Agent 装上自己写的新工具、新提示词、新 UI，跑坏了要能回滚，而且回滚机制本身不能被新组件弄坏。DSH 把这件事从"作者自觉"变成了"框架结构保证"。