DeepSeek Harness Two Weeks In: Hype, Backlash, and What Shipped
DeepSeek Harness 发布两周复盘：三次发版、star 数信任危机、真实用户好评差评并存，以及不同人群现在该不该上车。
DeepSeek 于 2026-08-13 开源 DeepSeek Harness（dsh）两周后，故事已经从首发当天的 star 数狂欢往前走了。过去五天里，官方发了三个版本，社区就"star 数是否可信"公开吵了一架，开发者也在"一切皆插件"到底是有远见的架构还是过度设计上分成了两派。这是我们第一周复盘的续篇——同样的有据可查风格，这次覆盖 2026-08-16 至 2026-08-21，一个目前全网几乎没人认真写过的时间窗口。
五天三个版本：官方到底发了什么
和模型侧不同，dsh 本体的发版节奏在官方渠道上一直很低调——下面每个版本都是第三方最先发现的，不是官方账号主动公告的。npm 的 latest/next 标签目前指向 0.1.1-rc.1，这是第一个跳出 0.1.0 系列的版本。
| 版本 | 日期 | 核心变化 |
|---|---|---|
v0.1.0-rc.7 | 08-17 | 插件可自行注册设置卡片；Codex/Claude Code 子代理任务接入 Job Panel；Code mode 更名为 PTC mode |
v0.1.0-rc.8 | 08-19 | /goal、/plan 支持原生图片输入；Claude Code/Codex 子代理可作为 Profile Bundle 安装，支持非交互权限模式；破坏性变更：settings.plugin.item slot 现在强制要求 options.key |
v0.1.1-rc.1 | 08-21 | 新增 DeepSeek-V4-Flash-Vision-Exp 模型适配器；修复了一个 Bubblewrap 沙箱绕过漏洞（经 /proc/<pid>/root）；ask_user_question 支持多行输入 |
节奏大约两天一版。文档站也换了形态：任意已发布路由现在都能在同一路径加 .md 后缀拿到纯 Markdown 孪生版本，配套自动生成的 llms.txt 索引——对直接读取文档的 Agent 是很直接的优化。同时，文档部署不再是"每次 push master 就上线"，而是改成只在打了 release tag 之后才发布，堵上了一个此前存在的口子：未发布内容可能在无鉴权的公开文档站上抢在对应 npm 包之前泄露。这两处变化都能在 deepseek-harness 仓库本周的提交历史里看到。
如果你打算从 rc.6 往后升级，options.key 这个破坏性变更、以及社区报告的低内存机器 npm 安装 OOM 问题，值得升级前先了解——完整清单见我们的升级指南。社区报告的 OOM 规避方式是：
NODE_OPTIONS=--max-old-space-size=6144 npx @deepseek-ai/dsh@0.1.1-rc.1 web
没人再完全相信的 star 数
GitHub API 显示仓库目前有 178,538 star（截至 2026 年 8 月 21 日）——本站全文引用的都是这个口径。但本周 Reddit 上声量最大的一条帖子其实和 dsh 的功能几乎无关。一条 511 票的 r/tech_x 帖子声称"100K+ GitHub star，仅用 2 天"，收获 119 条评论，但绝大多数评论都在争论这个增长是不是真实的：不少人直接判定是刷出来的（"90% of these are prob bought/gamed"），有人自曝被中介以 0.01 美元/star 的报价推销刷星服务，只有零星几条评论真正在讨论 dsh 本身（有人提到 OpenCode V2 正在加入 dsh 风格的特性；也有人指出第三方 harness reasonix 自己已经有 3 万多 star）。
这种怀疑不代表增长是假的——它意味着对这个仓库来说，单纯的 star 数现在是一个偏弱的信号，你在别处看到它被引用时，应当把它当作"关注度"而不是"验证过的质量证明"。
从首发狂欢到"开始挨骂"
对本周风向转变最直接的概括来自 @xmglab 在 X 上的一条广泛转发的推文，他写道 dsh 在第二周"开始挨骂了"。争议核心是"一切皆插件"的架构：模型、工具、Skills、会话、沙箱、Agent Loop 全部可替换。一派认为这是为未来"需要这种灵活性"的 Agent 提前搭好的底座；另一派认为对绝大多数人来说，日常写代码根本用不上这么复杂的东西。截至 08-21，star 数的增长看起来并没有明显放缓，但讨论的语气显然变了。
插件兼容性方面的抱怨给这个叙事添了柴。@VersunPan 在 X 上自称"deepseek harness 受害者+1"，指出插件质量参差不齐、版本之间不断出现破坏性变更，建议等第三方稳定发行版出现后再用，而不是直接追官方仓库——他还明确类比了直接用 Linux 内核 vs 用打包好的发行版（比如 Ubuntu）之间的区别。
Hacker News 上的故事更安静，但讲的是同一件事。最初的发布帖停在 744 分、约 299 条评论，两个数字自 08-16 以来基本没变——过去一周里这条主线程没有再收到任何新评论。此后所有新的 dsh 相关提交都是给某个小插件或竞品插件目录站打广告性质的 Show HN，没有一条得分超过个位数。讨论没有再回到 HN 首页。
真正用过的人怎么说
两条 Reddit 帖子给出了最详细的第一手体验。r/DeepSeek 的"Deepseek Harness is on whole different level"（242 票）称赞了 UI 和"code mode"，说 dsh 不会中途卡住等用户输入、能在任务过程中自己发现并纠正错误——但也指出子代理（sub agents）问题和报错很多，归因于预发布阶段。r/DeepSeek 的"My First Impressions"（99 票）给出了相反的评价：慢、耗 token 多、配置令人困惑——楼主提到放在 .agents 目录下的 Skills 没有自动加载，文档也没说清楚原因。
| 好评（有据可查） | 差评（有据可查） |
|---|---|
| UI 和"code mode"被特别点名称赞（r/DeepSeek，242 票） | 子代理经常报错，预发布阶段质量（r/DeepSeek，242 票） |
| 不会中途卡住等输入，任务中能自我纠正（r/DeepSeek，242 票） | 比预期慢、耗 token 多（r/DeepSeek，99 票） |
本地 llama.cpp 连跑 16 小时、2000 万+ token，u/cviperr33 报告无失败（r/LocalLLaMA，101 票） | WSL 环境不稳定，u/Armanlex 报告被迫换成第三方 harness（r/LocalLLaMA，320 票） |
| 社区上手几天内就已经自己写插件（r/DeepSeek，99 票） | .agents 下 Skill 自动加载机制文档不清楚（r/DeepSeek，99 票） |
"轻量 harness"叙事正在崛起
本周信息量最大的一条帖子，r/LocalLLaMA 的"why is feels better"（101 票），其实讨论的不只是 dsh 本身——而是自部署模型用户群体里对"系统提示词精简的 harness"越来越明显的偏好。最高票评论认为，OpenCode、Claude Code、Codex 这类主流 harness 的系统提示词"臃肿到本地模型根本负担不起"；dsh 和另一款独立的"Pi" harness 被反复点名为精简的替代选项，而对比之下有一款编排层被报告注入了约 1.9 万到 2 万 token 的系统提示词，任务还没开始就已经吃掉这么多。这种偏好能否推广到本地推理圈之外还不好说，但这是本周一个一致、有据可查的现象——也解释了为什么"按需安装、插件化"的 harness 会吸引这么多关注。
生态数字一览
GitHub dsh-plugin topic 目前有 10,071 个仓库，比 08-16 增加约 3,967 个——这部分增长里大多数是未经验证的噪声，不代表真实插件数。awesome-dsh-plugin 清单（FindHarness 插件索引所依赖的人工审核来源）目前收录 1,840 条；npm 上 keywords:dsh-plugin 搜索能命中 2,273 个包。两个专门的子版块 r/DeepSeekHarness 和 r/DeepSeekHarnessPlugin 也在本周出现——说明"如何找到一个好插件"这个问题足够真实，社区已经开始为它单独搭建阵地，而不只是围着 dsh 本体转。
这个窗口期里几个值得关注的新插件：dsh-ios（会话内直接操作 iOS 模拟器/真机，21 个 agent 工具）、dsh-plugin-bridge（跨 preset 会话迁移，带 benchmark 数据佐证）、以及 dsh-poison-guard——一个插件安全扫描器，属于正在成长的安全工具链的一部分，完整图景见我们的《DeepSeek Harness 安全现状》。在成本这一侧，dsh-token-anxiety 会按峰谷电价窗口追踪每个任务的花费，直接回应了上面提到的 token 成本抱怨。
还有几件事我们在别的文章里已经写过，这里一句带过：第三方插件市场 dsh-hub.cc 在一条收获 91 条评论的 GitHub Discussion里宣称收录 7,000+、验证 3,800+ 插件——完整全景见《DeepSeek Harness 插件市场大全》。首发周的 benchmark 可信度争议本周已经从"DeepSeek 是否造假"转向了方法论层面——讨论 agent 分数对 prompt 和工具 schema 选择有多敏感，见《为什么 DeepSeek Harness 的 benchmark 分数各不相同》。而 0.1.1-rc.1 视觉能力背后的模型 DeepSeek-V4-Flash-Vision-Exp，官方公告在这里——它在 dsh 里到底能做什么，见我们的视觉功能指南。
现在该不该上车？
- 尝鲜者/早期采用者：这两周的信息不需要改变你的计划——dsh 仍然是开发者预览版，每隔几天就会有破坏性变更，这本来就是你选择尝鲜时默认接受的条件。自动化脚本里记得锁定版本号。
- 考虑生产环境使用的团队：这两周的数据还不足以让答案变成"可以了"。插件兼容性抱怨、子代理报错、以及同一版本里修复的真实沙箱绕过漏洞，都指向"再等等"——这正是 dsh 自己的 README 一直在说的话。
- 插件开发者：这可以说是现在最好的入场时机。
rc.8里的options.key破坏性变更是一次性成本，生态发现的问题还没被解决（两个新 subreddit 就是证据），插件目录增长速度足够快，一个文档写清楚、定位精准的插件很容易被看见——动手前先去 /zh/plugins 看看已经有哪些同类插件。
FAQ
两周后，DeepSeek Harness 还是开发者预览版吗？
是的。我们查阅的所有来源——README、发版说明、社区直接报告——都把它当作 1.0 之前的预发布版本，会有破坏性变更，最近一次就是 rc.8 的 options.key 强制要求。
从 rc.6 升级到 0.1.1-rc.1 之前，我需要知道什么？
settings.plugin.item slot 的破坏性变更、新的 SQLite 存储格式（升级前先备份会话数据）、原生依赖现在需要 npm approve-scripts、以及一个 Bubblewrap 沙箱修复。完整步骤见我们的升级指南。
178k、166k、136k、95k 这些不同的 star 数报告都准确吗？
不能一概而论。178,538（GitHub API，08-21）是我们独立核实过的唯一数字；其他数字来自不同账号在不同日子的自述，彼此互相矛盾——这正是一条 511 票的 Reddit 帖子大部分评论都在争论的内容。
"一切皆插件"的架构对日常写代码来说是不是过度设计？
这确实存在真实争议。一部分开发者认为这是为未来"模型、工具、沙箱都需要可替换"的场景搭好的底座；另一部分认为对不需要这种灵活性的任务而言就是不必要的复杂度。截至本周，双方都没能说服对方。
我应该相信别人引用的 dsh benchmark 数字吗?
在依赖任何单一数字（无论官方还是独立复测）之前，先拿自己的实际工作负载验证一遍——目前的共识（在《为什么 DeepSeek Harness 的 benchmark 分数各不相同》里有更详细的讨论）是，agent benchmark 分数对生成它的具体 harness 配置高度敏感。
Next steps
- 错过了第一周？先看《DeepSeek Harness 发布一周复盘》。
- 打算从
rc.6往后升级？动手前先读升级指南。 - 好奇新的视觉模型到底能做什么？看视觉功能指南。
- 想了解安全修复和还未解决的问题？看《DeepSeek Harness 安全现状》。
- 浏览完整的、有据可查的插件目录 /zh/plugins，或从安全与权限、视觉、语音与多模态分类开始。