昨晚刷到一篇实测文，作者用 DeepSeek Harness 做了一个叫 MacDynamicIsland 的原生 macOS 应用——刘海、菜单栏、悬浮胶囊三个入口，快捷笔记、剪贴板、截图置顶全都有。时间线是这样的：
- 2 小时：从零到大部分功能可运行
- 1 小时：改一个文本框的交互和字体颜色，反复修改，始终没有收敛——修好一处，另一处又坏了
- 30 分钟：把同一份代码交给 Codex，文本框、字体颜色、交互优化基本收敛到可接受状态
作者很克制，特意声明这不是一次公平对比——Codex 接手时已经有了完整的项目基础，问题边界也被前面的试错磨清楚了。我认同这个声明。但这条时间线里藏着一个比「谁更强」重要得多的信号：从 0 到 1 只花了 2 小时，从 1 到 1.1 却花了 1 小时还没做完。
而 DeepSeek 对这件事的态度，就写在它刚开源的 Harness 里。
一、DeepSeek 开源的不是工具，是运行时
先看官方页面最显眼的那行字：
Agent = Model + Harness
这个公式我在四月份的 Agent = Model + Harness：从 Anthropic Managed Agents 看 Agent 架构演进 里讨论过——当时是从 Anthropic 的工程文章出发，讲 Harness 如何编码「模型做不到什么」的假设。四个月后，DeepSeek 直接把这个公式做成了一个开源产品，而且做得比「又一个 AI 编程工具」激进得多。
打开 GitHub 仓库，架构是三层：
┌────────────────────────────────────────────────┐
│ 配置层 组合模式：标准 / PTC / 极简 / 创造 │
├────────────────────────────────────────────────┤
│ 插件层 模型·工具·技能·会话·沙箱·存储·循环·调度·UI │
│ 通过 Cordis 服务与事件彼此协作 │
├────────────────────────────────────────────────┤
│ Cordis 内核 只管插件加载/卸载/依赖 │
│ 不承载任何 Agent 能力 │
# generated by hugo AI
关键在最底下那层。Cordis 内核不承载任何 Agent 的具体能力——模型是插件，循环是插件，沙箱是插件，连 UI 都是插件。这不是「一个工具有很多插件」，而是「运行时本身什么都不是，一切能力都由插件赋予」。DeepSeek 还给 Cordis 配了一篇论文，叫《A Programming Paradigm for Spatiotemporal Composability》——时空可组合性编程范式。用论文给插件系统背书，这个动作说明他们不是在写产品文档，是在立标准。
再看几个工程细节（均为撰文时 GitHub 页面所示数据）：
- 81.4k stars，12,293 commits，MIT 协议——commits 数量说明这不是发布会前突击出来的项目，Harness 层的投入比外界以为的早得多
- 仓库里有六套 vitest 配置，除了单测还有 e2e、snapshot、web-stress、web-perf——一个开发者预览版就配压力测试和性能测试，这是把 Harness 当基础设施在做
- 根目录放着
AGENTS.md和CLAUDE.md——用 Agent 开发 Agent 工具，dogfooding 到底
还有一个设计值得单独说：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 的能力要分开看：
| 启动能力（0→1） | 维护能力（1→N） | |
|---|---|---|
| 核心动作 | 生成 | 收敛 |
| 选择空间 | 敞开，任选可行结构 | 收窄，受已有代码约束 |
| 评价标准 | 能不能跑起来 | 第 N 次修改后，是否仍满足全部要求且不破坏旧功能 |
| 失败形态 | 生成不出来（少见） | 修好一处坏一处，反复横跳（常见） |
| 演示价值 | 高——「两小时做出一个应用」 | 低——演示视频拍不出来 |
收敛的定义可以说得更精确：经过 N 次修改后，结果稳定满足全部需求，且已有功能不被破坏。
收敛不是运气，它有两个可工程化的前提：
- 验收标准可机器判定——「完成」不等于「代码被修改过」，而是「通过了一组可检查的条件」。改文本框这个任务，验收条件应该写成：字体颜色正确、拖动正常、缩放不影响文字、截图功能仍可用。逐项验证，全部通过才算完成。
- 回归范围可声明——动手前说明准备改哪些文件、可能影响哪些功能；改完之后，除了验证新需求，还要重新检查相关的旧功能。
这两个前提，没有一个是模型层能解决的。验收标准是任务定义问题，回归范围是上下文管理问题——它们都属于 Harness。
这也回应了实测文底下最可能出现的质疑：「这不就是 Codex 的模型更强吗？」作者自己已经披露了对比不公平，我再加一层：就算换一个更强的模型，如果 Harness 里没有回归机制，「修好一处坏一处」只会被推迟，不会被消除。模型强度抬高的是单次修改的成功率，Harness 机制决定的是连续修改的收敛性——这是两个变量。
四、DeepSeek 其实已经铺好了一半
有意思的是，对照收敛的两个前提，DeepSeek Harness 的架构已经铺好了一半。
仅追加的 Trajectory 日志，是回归的数据基础。 每一次工具调用、每一次上下文注入都有据可查，意味着修改前后的对比、问题定位、失败回滚在原理上都是可行的——恢复、分叉、回放已经共享同一份事件流了。
极简模式的存在，说明他们在认真对待评测。 只保留一个 shell 工具加一个文件编辑工具，专为最小化环境下的模型基准测试设计——仓库里甚至单独有一份 BENCHMARK.md。
缺的是另一半：任务面板里还没有验收标准，修改流程里还没有回归声明。 目前的「完成、进行中、待处理」描述的是进度，不是验收。
实测文的作者给出的建议——「让验收标准成为任务的一部分」——翻译成工程语言就是：把 Eval 写进 Harness。这正是我在 Evals 是新的 PRD 里说的同一件事：当执行者变成 Agent，需求文档的终点不再是「描述清楚要什么」，而是「给出可判定的验收条件」。作者从一次卡顿的体验里独立走到了这个结论——只是还没意识到，他描述的东西有个名字，叫 Eval。
需要强调：收敛鸿沟不是 DeepSeek 一家的问题，而是所有 Coding Agent 从演示走向日常工具的必经关卡。DeepSeek 的特别之处在于，它把模型之外的能力全部拆成了插件，又把执行过程完整暴露给用户——这意味着它 有机会 通过插件机制补上 Eval 和回归，而不是只能等下一代模型变强。架构已经把路修好了，就看车什么时候上路。
写在最后
回到开头那条时间线：2 小时、1 小时、30 分钟。
它真正告诉我们的不是「DeepSeek 和 Codex 谁更强」，而是一个评估坐标的切换——当所有工具都能在几小时内把想法变成 Demo，首次生成速度的差异会越来越小，下一场竞争会转向一个演示视频拍不出来的地方：第 10 次修改时，它还能不能稳定抵达结果。
所以下次评估一个 Coding Agent，看完演示之后，多问一个问题：第 10 次修改，它怎么收敛？
你的团队在用哪个 Coding Agent？迭代到后期收敛吗？欢迎留言聊聊。