DeepSeek Harness 0.1.2 没有正式版：一个 rc 是怎么被放弃的

0.1.2 没有正式版：一个 rc 是怎么被放弃的

上篇发出来的那天，DeepSeek Harness 又发了一版。

我在这个合集里已经写过两篇关于它版本号的文章。第一篇说它从 rc 退回 alpha，第二篇说它 13 天后又爬回了 rc。第二篇的最后我下了个判断："退回 alpha 是真的在改骨架，回到 rc 是真的改完了。"

那句话发出去不到 11 小时，v0.1.3-alpha.1 发布。

它又退回 alpha 了。

先把事情说清楚

不带任何解读的部分：

• v0.1.2-rc.1 发布于 2026-09-03 06:06（UTC）
• v0.1.3-alpha.1 发布于 2026-09-04 11:34（UTC，北京时间 19:34）
• 中间隔了 29 小时 28 分

关键在最后一层。v0.1.2-rc.1 是 0.1.2 这个版本的唯一候选，也是最后一个。它不是被"下一个 rc"接替的，而是被一个更高一位的全新版本号取代的。

所以 v0.1.2 的正式版永远不会发布。

一个 rc 活了 29 个小时，然后连它准备发的那个版本一起，消失了。

rc 到底承诺了什么

我以前对 rc 的理解是"快要发了"。不算错，但漏了一半。

rc 其实说了两句话：一句是"我准备发这一版"，另一句是"发之前不再改功能"。

第一句是意图，第二句是约束。平时我们盯的是第一句，因为它是好消息。但真正能拿来当契约用的是第二句——它意味着你可以开始做兼容性测试，不用担心下周接口又变了。

这次的事说明了一件我之前没想透的事：第一句是可以作废的。

rc 承诺的是"我准备发这个版本"，不是"这个版本一定会发"。这两句看着差不多，差别在于：前者是当下的意图，后者是对未来的保证。开源项目只给得起前者。

想到这儿再回头看，其实很好理解。项目在 rc 期间发现还需要改骨架，改完之后有两种选择：一是继续叫 0.1.2，硬着头皮发出去，把一个自己都不满意的版本钉成一个正式号；二是承认"这不是我以为的那个版本"，把版本号升到 0.1.3，重新走一遍流程。

选了第二条的项目不多，因为它要付出一个很实在的代价——所有等着 0.1.2 的人，都得重新对齐一次。

那 29 小时里发生了什么

什么都没发生。

我是说，在这 29 小时里，DSH 没有出事故，没有发紧急补丁，没有任何戏剧性的事。它就是按部就班地，把下一个版本发出去了，然后顺手把版本号换掉。

新版的内容倒是很实在，一堆破坏性变更：Session 持久化 API 改由 SessionHandle 提供，agentLoop.create() 变成异步，新增 session 锁（同一个 session 至多被一个进程持有），会话日志换到 Session 格式 v2，出站请求开始遵循 HTTP_PROXY 这类环境变量，模型探测支持 Anthropic 原生模型列表并回填上下文窗口和最大输出 token，Skill 选择器支持模糊搜索。

还有一句很罕见的话，写在发布说明里：

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

预发布项目在 changelog 里主动写"这一版更慢"，我是第一次见。多数项目的发布说明只写新增了什么，回退这类词能不提就不提。

没变的那些东西

比起换了什么，更值得看的是没换什么。

换掉版本号的这次提交里，README 上那句 developer preview 一个字没动——连后面那句大写的"会有破坏性变更"都还挂着。安全说明里那四条边界也一字未改：没做过安全审计；沙箱、审批和权限控制可以降低风险，但不保证隔离；别把它当成不可信负载的唯一安全控制；优先用一次性的虚拟机或容器。

版本号翻来覆去，这两处一直没挪。

这一条我越想越觉得重要。一个项目可以对版本号很随意，也可以对底线很固执，这两件事完全可以同时发生。而我们平时判断一个项目靠不靠谱，看的往往是它"承诺了什么"；但承诺会改，尤其在这种半个月转三次向的阶段。反倒是那些一直没变的东西，才是它真正的坐标。

14 天，三次转向

把时间线拉平了看，形状很清楚：

日期	版本	方向
08-21	v0.1.1-rc.2	rc
08-27	v0.1.2-alpha.1	退回 alpha
08-31 前后	alpha.2 / .3 / .4	alpha
09-02	alpha.5	alpha（热修升级崩溃）
09-03	v0.1.2-rc.1	重回 rc
09-04	v0.1.3-alpha.1	又退回 alpha

14 天，三次转向。

单看每一次都像独立事件，连起来看就有节奏了：这个项目在同时做两件事——往里改骨架，往外调版本号。而且这两件事不同步。改骨架是连续的、每天都在发生；调版本号是阶梯式的，攒够了才跳一次。

所以版本号不是进度的刻度，它是项目对外重估自己的时刻。每跳一次，等于它对外说一句"我现在敢让你依赖到这个程度"。往回跳，就是承认上次说早了。

顺着这个看法，那 5 个 alpha 一点都不浪费。它们不是原地打转，是在重新定义自己——接口改名、调用面删掉、后端移除、会话格式换掉。这些事做完了，它才发现"这不是 0.1.2 了"，于是换了个号。

换号不是倒退，是承认已经变成另一个东西了。

所以该怎么读

前面两篇分别讲怎么读"倒退"和怎么读"回归"，这篇补上第三种：怎么读"版本号被换掉"。

三件事，按顺序看。

先看版本号跳了几位。小版本号变（0.1.2 → 0.1.3）是重新出发，补丁号变（0.1.2 → 0.1.3 里最后一位）是修修补补。这次跳的是小版本，加上前一个版本连正式版都没发，说明不是修补，是重来。

再看破坏性变更停没停。这一条最实在。新一版里接口说删就删、说改名就改名，只要还在这么干，它就还是 pre-release，后缀叫什么 alpha 还是 rc 都不改变这一点。

最后看那些一直没变的话。README 上的状态声明、安全说明里的边界，这些才是真正稳的坐标。版本号每周都能变，这几句话半年没动过。

三件事看完，结论就很清楚了：这个项目的版本号不提供任何关于"什么时候能进生产"的信息，提供这个信息的只有它自己那句 developer preview——而那句话，从 8 月挂到 9 月，一个字没改。

写在最后

合集前两篇发出去之后，有读者问我是不是盯这个项目盯得太紧了。

其实不是。我只是觉得，一个项目在半个月内把版本号来回调了三次、还敢在 changelog 里写"这一版有性能回退"，这种样本不好找。大多数时候我们看到的版本线都是一路向前的，看不出版本号背后那些没说出口的取舍。

这次它把取舍摊开了：宁可让所有等着 0.1.2 的人重新对齐一次，也不把一个自己不满意的版本钉成正式号。

就这一条，比它是 alpha 还是 rc 更值得记。

至于什么时候能进生产——上一篇的结尾我已经写过一次了，这次还是那句：官方 README 那句话还挂在那儿呢，等它摘下来再说。

---

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

---

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

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

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