DeepSeek Harness（dsh）现状：版本、更新与稳定性（2026）

dsh 至今仍是发布时的 0.1.0-rc.6，公开仓库自 2026-08-13 起没有收到过一条提交。 四天没有任何可见的上游变动，而 README 里写着这个项目正在快速迭代。

这些都不能说明它是个差工具。但它确实会改变一件事：把 dsh 接进任何你依赖的东西之前，你该先做什么。

当前版本:      0.1.0-rc.6，发布于 2026-08-13 12:35 UTC
已发布版本数:  6 个，全部在 2026-08-10 至 08-13 之间
最后一条提交:  2026-08-13 11:38 UTC
Release / Tag: 0 / 0
分支:          只有 master
Issue 通道:    已关闭，只有 Discussions 和 Discord
Discussions:   2,713 帖（2026-08-17 快照）
协议:          MIT
官方定位:      developer preview，明示会有破坏性变更
启动入口:      npx @deepseek-ai/dsh web，Web UI 在 127.0.0.1:3080

DeepSeek Harness 现在是哪个版本？

0.1.0-rc.6，2026-08-13 12:35 UTC 发布。 npm 上 latest 和 next 两个 dist-tag 都解析到它，所以直接 npx @deepseek-ai/dsh 和显式加 @next 拿到的是同一份文件。

完整的发布历史是六个版本、跨四天，其中一半集中在发布当天：

每一个版本都发在公开发布之前或当天。你今天装到的，就是上线第一天的那一版。

发布之后更新过吗？

公开层面没有。 master 上最后一条提交时间是 2026-08-13 11:38 UTC，仓库自己的 pushed_at 是 2026-08-13 13:00 UTC。2026-08-17 再查一次，两个都没变。

而且没有别的地方能读出状态：

• 0 个 release、0 个 tag，上游没有任何「这一版是好的」的信号
• 只有 master 一条分支，看不到开发线
• npm 也没动，排除了「先发 npm 后补 git」这种可能

这件事对一个成熟项目不算什么，但 README 明说了会有破坏性变更。一个预告会弄坏你的工具、又不给你任何 tag 可锁的项目，npm 版本号就成了你唯一的锚。

怎么自己核实 dsh 的状态？

三条命令，不需要 GitHub 账号。 本文里每个数字都会变，所以别信快照，自己验。

看当前版本和完整发布历史：

npm view @deepseek-ai/dsh dist-tags versions time

看公开仓库到底动没动：

curl -s https://api.github.com/repos/deepseek-ai/deepseek-harness \
  | jq '{pushed_at, has_issues, open_issues_count}'

截至 2026-08-17，这条返回的是 2026-08-13T13:00:21Z、false 和 0。release 和 tag 要单独调，两个都返回空数组：

curl -s https://api.github.com/repos/deepseek-ai/deepseek-harness/releases
curl -s https://api.github.com/repos/deepseek-ai/deepseek-harness/tags

如果你读到这里时 pushed_at 已经越过 2026-08-13，那下面的判断就变了，而锁版本这件事只会更重要，不会更不重要。

dsh 能上生产吗？

不能，而且 DeepSeek 自己就是这么说的。 README 为此单开了一节：

DeepSeek Harness is currently in developer preview and is iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES.

有两个结构性事实佐证这句话，而不是与它矛盾。

一是 Issues 被关闭，官方渠道只剩 Discussions 和 Discord。bug 报告和功能请求落在同一个信息流里，没有指派人、没有标签、没有状态。这套配置很适合收集信号，但很不适合追踪你提交的那个回归。

二是插件化架构指向同一个方向。dsh 里一切皆 Cordis 插件，连 UI 都是，这正是生态跑得这么快的原因。反过来说，上游一个破坏性变更可能落在你根本不知道自己依赖了的某个面上。

为什么 dsh 仓库说「快速迭代」却没有提交？

因为公开出来的是代码，不是围绕代码的过程。 仓库 2026-08-13 创建，但带着完整历史一起落地：12,293 条提交，最早回溯到 2026-06-10，第一条的 message 是 “Initialize repo with README, AGENTS.md, and CLAUDE.md symlink”。两个月的工作量，全都看得见。

留在私有侧的是代码之外的一切。merge commit 引用的 #2519、#2520、#2521 三个 PR 属于另一个你打不开的 deepseek-harness 组织，除 master 之外没有分支，发布当天之后再没推送过。

于是代码史异常透明，当前状态异常不透明。dsh 是怎么走到 0.1.0-rc.6 的，你能逐行读完；接下来会发生什么，你一无所知。

所以「快速迭代」大概率是真的，只是从外部观察不到。这本身是一种合理的项目运作方式。

但它对你有一个具体后果：2026-08-13 之后的任何时间点，你都分不清「安静是因为稳定」还是「安静是因为在忙」。 你会和所有人在同一刻知道答案——下一个版本出现在 npm 上的那一刻。

务实的应对是锁版本。npx @deepseek-ai/dsh@0.1.0-rc.6 今天不花你任何成本，而它是你与那个被预告过的破坏性变更之间唯一的东西。

dsh 的社区有多大？

很大，而且涨得比代码快得多。 2026-08-17 08:00 UTC 查的时候 GitHub Discussions 有 2,713 帖，而三天前我们自己那次快照大约是 620。写这篇的一小时内它就过了 2,730。星标和 fork 涨得一样快，所以本文里任何具体数字都请当成时间戳而不是事实，唯一稳定的只有方向。

这些帖子都在聊什么：

2,713 条讨论对零条提交，这是本文最有用的一组数字对照。需求是真的，可见的迭代不是。

再看一眼生态那一行意味着什么。当插件跑得比它们所依附的内核还快，而内核又预告了破坏性变更，那么最先坏掉的一定是插件。这不是让你别用 dsh 的理由，而是让你把 dsh 装得薄一点的理由。

dsh 会告诉你每个任务花了多少钱吗？

目前不会。 现在这一版没有任何逐轮的 token 或成本显示。Ideas 区里赞数较高的一条帖子发于 2026-08-14，要的正是这个功能；发布当天也已经出现了一个社区做的成本追踪插件来补这个缺口。

时间点让这件事比看起来更尖锐。DeepSeek 已于 2026-08-16 把 V4 全系改成峰谷两档计价，同一个 agent 循环现在按落在哪个小时收两种价。

deepseek/deepseek-v4-pro 的缓存命中峰时涨了 12.1 倍，deepseek/deepseek-v4-flash 涨 5 倍。而一个每轮都重发同样系统提示和文件内容的 agent harness，恰好就是这次调价打中的那类负载。

在 harness 自己把这个数字露出来之前，你只能靠服务商控制台、自己的代理日志，或者社区那些显示单任务成本和峰谷状态的插件。这些东西 dsh 一个都没自带。

现在什么场景可以用 dsh？

可以拿来探索，不能拿来依赖。 这条线比「developer preview」这个标签划得更清楚，因为它取决于下一个版本落地时会弄坏什么。

分界线就是：一次弄坏你配置的升级，代价是一个下午，还是一个 deadline。DeepSeek 已经用全大写告诉你它准备来哪一种了。

把 dsh 接进工作流之前该做什么？

锁版本、让模型端点保持可替换、暂时别放到关键路径上。 前两件不花成本，第三件才是真正的决策。

一份具体的清单：

1. 锁版本。跑 npx @deepseek-ai/dsh@0.1.0-rc.6，别用裸 dsh。
2. 把它指向一个你自己控制的 base URL，而不是写死的厂商默认值。
3. 任何有 deadline 的事情，留一个第二 harness 是能用的。
4. 盯 npm 而不是 GitHub，下一个版本会先出现在 npm 上。
5. 每次升级后重读一遍 README。破坏性变更只在那里公告，别处没有。

第 2 条是最常被跳过的。dsh 的内建路由读 DEEPSEEK_BASE_URL 和 DEEPSEEK_API_KEY，自定义 provider 表单接受任何 OpenAI 兼容端点，所以只要一开始就这么配，模型层是真的可以换。

在 ofox 上这两个字符串是 deepseek/deepseek-v4-flash 和 deepseek/deepseek-v4-pro，共用一把 key。价值不在网关本身，而在于：dsh 坏掉的那天，或者价格再动的那天，你要改的只有模型名这一个字符串。

两条路的分步做法都在 dsh 自定义 provider 配置指南里。想看 dsh 在可扩展性和模型绑定这两点上与 Claude Code、Codex 等工具怎么比，见编码 agent harness 横评。

References

• deepseek-ai/deepseek-harness（GitHub）
• dsh README 的 developer preview 声明
• DeepSeek Harness Discussions
• npm registry 上的 @deepseek-ai/dsh
• Cordis：dsh 所基于的插件运行时
• DeepSeek API 价格
• DeepSeek 更新日志