DeepSeek Harness 0.1.4 从来没存在过：版本号不再承诺成熟度，那该读什么

0.1.4 从来没存在过：版本号不再承诺成熟度，那该读什么

上篇发出去之后，DeepSeek Harness 又发了一版，然后又发了一版。

但要紧的不是"又发了一版"。

9 月 7 日晚上，v0.1.3-alpha.2。9 月 9 日凌晨，v0.1.5-alpha.1。

中间那个号——v0.1.4——从来没存在过。

先把事实摆平

不带解读的部分：

• v0.1.3-alpha.1：9 月 4 日 19:34（北京时间，下同）
• v0.1.3-alpha.2：9 月 7 日 21:59，距上一版 3 天 2 小时
• v0.1.5-alpha.1：9 月 9 日 00:16，距上一版 26 小时 17 分
• v0.1.4：仓库全部 13 个 tag 里没有它；按这个版本号去查，返回 404

第三篇我写过 v0.1.2 没有正式版——那是"一个版本准备了，但没发出来"。这次不一样：0.1.4 连准备都没准备过，它是一段空白。

这次跳的不是方向，是数字

到这儿得停一下，因为这一跳和前三次不是一回事。

前三次转向，来回都是 rc ↔ alpha——8 月 27 日退回去，9 月 3 日走回来，9 月 4 日又退回去。方向变，意味着一件事：我对我自己成熟度的判断变了。那是最值得读的信号，也是合集前两篇讲的东西。

这次呢？alpha.1 → alpha.2 → 0.1.5-alpha.1，全程待在 alpha 线上，方向一次都没变。变的只是数字，从 3 跳到了 5。

那它跳的是什么？

看一眼这两版改了什么就有答案：会话格式从 v2 升到 V3；插件 API 里的 ctx.agent 被移除，调用方得显式传 Agent 了；Inbox 从可构造的运行时类改成类型接口，插件改走 agent.inbox，hasPending 和 claim 不再是公共接口；默认文件编辑工具统一成 read / write / edit；自定义 persona 配置拆成前缀和后缀。

是破坏性变更又攒够了一个量级。

所以到这一步，这个项目的版本号已经不承诺成熟度了。它在当一个变更量计数器用——攒够一批改动，就把数字往上拨一格。0.1.4 之所以不存在，大概只是因为攒的那一批在中途被判定为"够格叫 0.1.5 了"。（这句是我猜的，官方没说；能确证的只有一件事：它没发过。）

那 4 天里，还发生了另一件事

如果只有跳号，这篇可以写得很短。但同一段时间里还有一件事，我认为它比跳号重要得多。

第三篇里我提过一句：v0.1.3-alpha.1 的发布说明里主动写了——

本版本存在一项已知的性能回退，可能影响部分历史 session 加载的响应速度，我们将在下一个版本中修复。

当时我的评价是"预发布项目在 changelog 里自陈'这一版更慢'，我是第一次见"。

现在可以补上后半句了。

v0.1.3-alpha.2 的体验优化第一条："改善长会话打开、恢复和持续对话时的卡顿，降低内存占用"。

"历史 session 加载的响应速度"和"长会话打开、恢复时的卡顿"——说的是同一件事。它修了。

再到 v0.1.5-alpha.1，发布说明里这条已知回退消失了，也没有新增同类条目。

三段连起来：说了更慢 → 下个版本修好 → 不再提。

这是这个合集里第一次出现一个完整的、可验证的承诺闭环。

同一个项目，两种信用

把这件事和跳号放在一起看，会出现一个挺有意思的对照：

• 它说"我要发 0.1.2"——没发；
• 0.1.4 该发的时候——连发都没发；
• 它说"这一版更慢，下版修"——修了。

前两篇的落点是"版本号上的承诺靠不住"。现在得补上后半句：同一个项目，对版本号食言，对 changelog 守信。

这不是它精分，是这两种"说出口的话"根本不是同一种东西。

版本号上的那句，是意图。意图表达的是此刻的想法，想法会变，而且没人能保证它不变——第三篇已经说过，开源项目只给得起意图，给不起保证。

changelog 里那句"已知问题，下版修"，是债务。白纸黑字记下来的欠账，所有人都看见了，跑不掉。更要命的是它有个性质：可验证。过一版你就能去查它还了没有。

再往下还有第三层。README 上那句 developer preview 和"会有破坏性变更"，SAFETY 里那四条边界——没做过安全审计、沙箱审批权限不保证隔离、别把它当成不可信负载的唯一安全控制、优先用一次性的虚拟机或容器。这两处从 8 月挂到现在，中间它退回 alpha、重回 rc、又退回 alpha、换掉版本号、跳过版本号，一个字没改。

那不是意图，也不是债务，是底线。

所以该怎么读

合集前三篇分别讲了怎么读"倒退"、怎么读"回归"、怎么读"版本号被换掉"。这篇补上第四种——怎么读"版本号被跳过"。但更重要的是，它把前三篇的方法论往前推了一步：

当版本号连成熟度都不再承诺的时候，就把眼睛从版本号上移开，去看别的。

看三处，按可信度从高到低：

第一，看 changelog 里的"已知问题"。 这是唯一能验证上游靠不靠谱的公开材料。绝大多数项目的发布说明只写新增了什么，肯写"这一版更慢"的不多，写了还按时还上的更少。这条能连续对上几次，比它是 alpha 还是 rc 有说服力得多。

第二，把"已知问题"当工单，建一张兑现台账。 拿到一个预发布项目，把它的 Known issues / 已知缺陷逐条抄进你自己的表格，标上"承诺修复的版本"，然后每发一版去核一次。这张表比任何版本号都更能告诉你：这个上游说话算不算数。DSH 这次是三版一个闭环，你可以拿同一把尺去量你现在依赖着的那个项目。

第三，盯住数据格式里的单向门。 这一轮对我冲击最大的其实不是跳号，是会话格式：9 月 4 日升到 v2，9 月 9 日升到 V3，5 天换了两代，而且官方写得很清楚——升级后的会话不支持降级读取。原文件会保留，但新版日志回不去上一代。

这条对企业读者是硬风险：你的历史会话本身就是资产。一旦被新版本读过一次，它们就整体升代，旧版本再也读不了。想拿老版本复现一次几个月前的结果，门已经关了。所以别只备份原始输入，要把 session 目录按版本整份快照归档；升级前先停一下，想清楚要不要现在就过这道门。

写在最后

合集写到第四篇，我其实一直在做同一件事：找一个能判断"这个项目离生产还有多远"的坐标。

第一篇以为是版本号——后来发现它会往回走。第二篇以为回到 rc 就算数——结果那个 rc 只活了 29 小时。第三篇退到底线：至少 developer preview 那句话不会骗人。这一篇发现，还有一处比版本号诚实得多——它自己写下来的欠账。

版本号会跳、会退、会被换掉、会被跳过。欠账不会。

所以下次再看到一个预发布项目，别急着问"它到 rc 了没有"。翻到发布说明最底下，找那句"本版本存在一项已知的……"。

那句话在不在，比版本号更能说明问题。

---

本文事实基准：DeepSeek Harness v0.1.5-alpha.1（2026-09-08 16:16 UTC / 北京时间 09-09 00:16 发布，developer preview，非 GA）。版本时间线、changelog、README 与 SAFETY 声明均取自官方仓库 github.com/deepseek-ai/deepseek-harness（master 分支，2026-09-09 核对）。这类项目迭代极快，你读到这一刻的最新版本大概率已经不是文中这个号了——方法论可以复用，具体版本请以当日仓库为准。

---

📱 关注公众号，追更不迷路

本系列文章首发于微信公众号「农夫三拳有点癫」，每周更新源码拆解与架构实战。

在微信扫描下方二维码即可关注：