一切皆插件:DeepSeek Harness 的野心与收敛鸿沟

“

2 小时做出一个应用，改一个文本框却花了 1 小时还没收敛。下一场竞争，在演示视频拍不出来的地方。

—— hugozhu

昨晚刷到一篇实测文，作者用 DeepSeek Harness 做了一个叫 MacDynamicIsland 的原生 macOS 应用——刘海、菜单栏、悬浮胶囊三个入口，快捷笔记、剪贴板、截图置顶全都有。时间线是这样的：

作者很克制，特意声明这不是一次公平对比——Codex 接手时已经有了完整的项目基础，问题边界也被前面的试错磨清楚了。我认同这个声明。但这条时间线里藏着一个比「谁更强」重要得多的信号：从 0 到 1 只花了 2 小时，从 1 到 1.1 却花了 1 小时还没做完。

而 DeepSeek 对这件事的态度，就写在它刚开源的 Harness 里。

📌 本文看点

先看官方页面最显眼的那行字：

这个公式我在四月份的《Agent = Model + Harness：从 Anthropic Managed Agents 看 Agent 架构演进》里讨论过——当时是从 Anthropic 的工程文章出发，讲 Harness 如何编码「模型做不到什么」的假设。四个月后，DeepSeek 直接把这个公式做成了一个开源产品，而且做得比「又一个 AI 编程工具」激进得多。

打开 GitHub 仓库，架构是三层：

关键在最底下那层。Cordis 内核不承载任何 Agent 的具体能力——模型是插件，循环是插件，沙箱是插件，连 UI 都是插件。这不是「一个工具有很多插件」，而是「运行时本身什么都不是，一切能力都由插件赋予」。DeepSeek 还给 Cordis 配了一篇论文，叫《A Programming Paradigm for Spatiotemporal Composability》——时空可组合性编程范式。用论文给插件系统背书，这个动作说明他们不是在写产品文档，是在立标准。

再看几个工程细节（均为撰文时 GitHub 页面所示数据）：

还有一个设计值得单独说：Trajectory 轨迹。模型看到的一切——系统提示词、思维链、工具调用与结果、子 Agent 调度、每一次上下文注入——全部写入仅追加（append-only）的会话日志。恢复、分叉、检索、回放共享同一份事件流。这是把 Agent 执行当成分布式系统的 event log 来管理。

把这些拼起来，DeepSeek 的野心就清楚了：它要争的不是「最好用的 coding 工具」这个位置，而是Agent 的运行时标准——模型只是运行时上的一个插件，随时可以换。

回到那条时间线。为什么 2 小时能做出一个应用，1 小时却改不好一个文本框？

这不是 DeepSeek 一家的问题，而是两类任务的本质差异。

从 0 到 1，Agent 的选择空间是敞开的。只要最终功能能跑，它可以挑自己最容易实现的结构和路径；细节不够成熟，也不会阻止 Demo 出现。生成阶段的评价标准只有一个：能不能跑起来。

从 1 到 N，选择空间反而收窄了。Agent 同时要扛三件事：理解这次的新要求、读懂已有代码为什么长这样、保证原本正确的功能不被破坏。修改范围可能只集中在一个文本框，需要保留的约束却分散在整个交互里。

拿案例里的文本框来说，它不是屏幕上的一个矩形：

从需求描述看，这叫「优化文本框」；从实现看，这是一组互相关联的状态机。当 Agent 只修复眼前的表现、没有完整理解这些关系时，就会出现实测里的情况：改动确实发生了，但修好一处，另一处又变了。

这正是我在《Agent 为什么在第 30 步翻车》里写过的失败模式——约束是分散的，而 Agent 的注意力是局部的。长任务里打败 Agent 的从来不是某一个高难度步骤，而是几十处低难度约束的叠加。

我把这个现象命名为收敛鸿沟（Convergence Gap）。一个 Coding Agent 的能力要分开看：

收敛的定义可以说得更精确：经过 N 次修改后，结果稳定满足全部需求，且已有功能不被破坏。

收敛不是运气，它有两个可工程化的前提：

这两个前提，没有一个是模型层能解决的。验收标准是任务定义问题，回归范围是上下文管理问题——它们都属于 Harness。

这也回应了实测文底下最可能出现的质疑：「这不就是 Codex 的模型更强吗？」作者自己已经披露了对比不公平，我再加一层：就算换一个更强的模型，如果 Harness 里没有回归机制，「修好一处坏一处」只会被推迟，不会被消除。模型强度抬高的是单次修改的成功率，Harness 机制决定的是连续修改的收敛性——这是两个变量。

有意思的是，对照收敛的两个前提，DeepSeek Harness 的架构已经铺好了一半。

仅追加的 Trajectory 日志，是回归的数据基础。每一次工具调用、每一次上下文注入都有据可查，意味着修改前后的对比、问题定位、失败回滚在原理上都是可行的——恢复、分叉、回放已经共享同一份事件流了。

极简模式的存在，说明他们在认真对待评测。只保留一个 shell 工具加一个文件编辑工具，专为最小化环境下的模型基准测试设计——仓库里甚至单独有一份BENCHMARK.md。

实测文的作者给出的建议——「让验收标准成为任务的一部分」——翻译成工程语言就是：

这正是我在《Evals 是新的 PRD》里说的同一件事：当执行者变成 Agent，需求文档的终点不再是「描述清楚要什么」，而是「给出可判定的验收条件」。作者从一次卡顿的体验里独立走到了这个结论——只是还没意识到，他描述的东西有个名字，叫 Eval。

需要强调：收敛鸿沟不是 DeepSeek 一家的问题，而是所有 Coding Agent 从演示走向日常工具的必经关卡。DeepSeek 的特别之处在于，它把模型之外的能力全部拆成了插件，又把执行过程完整暴露给用户——这意味着它有机会通过插件机制补上 Eval 和回归，而不是只能等下一代模型变强。架构已经把路修好了，就看车什么时候上路。

回到开头那条时间线：2 小时、1 小时、30 分钟。

它真正告诉我们的不是「DeepSeek 和 Codex 谁更强」，而是一个评估坐标的切换——当所有工具都能在几小时内把想法变成 Demo，首次生成速度的差异会越来越小，下一场竞争会转向一个演示视频拍不出来的地方：第 10 次修改时，它还能不能稳定抵达结果。

所以下次评估一个 Coding Agent，看完演示之后，多问一个问题：第 10 次修改，它怎么收敛？

你的团队在用哪个 Coding Agent？迭代到后期收敛吗？欢迎留言聊聊。

我是 hugozhu，AI原生思考。

如果你觉得今天这篇有收获，欢迎点赞、收藏、转发三连，我们下篇见。