从 alpha 转 rc，听着像是个里程碑。我把两个版本都拆开比了一遍，结论是：一个字节都没改。

先说结论

0.2.2-rc.1 发布于北京时间 2026 年 11 月 4 日 17:20（2026-11-04T09:20:32Z）。

我拿它和 2026 年 11 月 3 日发布的 0.2.2-alpha.3 做了逐文件 md5 比对，范围是顶层包、六个核心子包、以及底层框架 cordis，一共 290 个文件对齐算了一遍。

结果：每个包里唯一变的文件，都是 package.json。

dist、src、locale、README 全部一模一样。这不是「改动很小」，这是零改动。

我怎么比的

命令行就三步，没用什么特殊工具：

npm pack @deepseek-ai/dsh@0.2.2-alpha.3 和 @0.2.2-rc.1 各拉一份 tarball，解包到两个目录，然后按相对路径逐文件算 md5。

顶层包 20 个文件，六个子包各 30 到 60 个文件，cordis 32 个文件。两边同名文件全部对齐算一遍，只记下哈希不一致的。

没有新增，没有删除。八个包八处改动，全是版本号和依赖范围那一行。

唯一真正变了的东西

代码没变。但依赖版本号全换了一茬，这是这次发布唯一的实质动作：

一句话总结：把整个 cordis 家族的 alpha 后缀去掉，抬成正式版本号。

但这里有个细节值得说。我把 cordis 4.0.6-alpha.2 和 4.1.0 也拆开比了，它的 32 个文件里同样只有 package.json 不同。也就是说连框架层都是原样搬过去的，只换了门牌号。这个比上面那张表更有意思。

那次「版本号从 alpha 变正式」，改动量是零。

所以这次发布到底图什么

图一个 tag。

发布之前，latest 指向 0.2.1-rc.5，next 指向 0.2.2-alpha.3。想装最新的得手动写全版本号。

发布之后，latest 和 next 都指向 0.2.2-rc.1。这意味着 npm i -g @deepseek-ai/dsh 不加版本号，默认装的就是它。

对大项目来说这不是小事。alpha 线是「我们自己敢用」的标记，rc 是「你也来试试，接口已经定死了」的标记。改功能是开发，改标记是承诺。这一版做的是后者。

升级花了不到一分钟

全局装一条命令，npm i -g @deepseek-ai/dsh@0.2.2-rc.1，跑完 dsh --version 就是 0.2.2-rc.1。

第二条命令不是升级，是修 profile。这条很多人会漏，我上次就漏了：

dsh plugin --profile web add @deepseek-ai/dsh-cua-bundle@0.2.2-rc.1 @deepseek-ai/dsh-experimental-plugin-market-bundle@0.2.2-rc.1 @deepseek-ai/dsh-experimental-client-ui-agent-team@0.2.2-rc.1

pnpm 报回来：解析 62 个包，复用 41 个，下载 21 个，新增 22 个，耗时 939 毫秒。

装完我先用 headless 模式冒烟了一次，让它「只回答两个字：收到」。它回了「收到」，说明 profile 能正常启动、模型路由通、没有插件卡在 disable 状态。这一步比看界面快。

为什么要重跑？因为 dsh 的 profile 是一层叠一层的插件堆，全局升了 dsh 之后，profile 里那些还钉在 alpha.3 的插件和主程序版本对不上，启动时会被版本校验直接 disable。

上次升 alpha.3 我只升了全局，结果六行插件被关掉，storage-domain 就在其中。它一挂，工作区、会话列表、定时任务跟着全卡死，网页版直接废掉，最后靠这条命令才救回来。

所以我的顺序固定了：先全局，再 profile，最后验证。少一步就是给自己找麻烦。

上次没救回来的那个，这次回来了

上次升级唯一遗留的伤是 ui-agent-team：它版本线特殊，npm 上找不到能和 alpha.3 对齐的包，只能一直禁用着。

这次它有对应版本了。装完之后 profile_ping 报的插件清单里，这三个都在：

@deepseek-ai/dsh-experimental-agent-team

@deepseek-ai/dsh-experimental-client-ui-agent-team

@deepseek-ai/dsh-experimental-tool-agent-team

上一版被禁的 dsh-storage-domain 也在列表里。插件页面上，「Agent teams」那个开关是打开的，新会话的标题栏上还多了一个 Agent team 的标识。

装的时候出了一句提示，我觉得值得原样记下来：@deepseek-ai/dsh-experimental-client-ui-agent-team 没有声明 dsh.bundle，所以它是作为普通依赖装的，不是一个 profile 层。

换句话说它能用，但它在体系里的位置和那些 bundle 不一样。这种话厂商不会写在发布说明里，只在安装输出里闪一句。

profile 里不全是官方包

顺手看了一眼 profile 的依赖清单，六条：

三个 bundle 现在是 rc.1，agent-team-web-profile 还停在 0.1.6-alpha.2，剩下两条是我自己装的，一个从本地 tgz 装，一个直接从 GitHub 仓库装。

这说明 dsh 的 profile 不是一个封闭的官方套装，是你自己拼的组合。好处是你想加什么加什么，代价是升级时得自己盯：哪些是官方的、哪些钉在某个版本、哪些根本不在官方的版本线上。

agent-team-web-profile 就是例子。它是 agent-team 的界面层，版本线和主程序完全独立，主程序到 rc.1 了它还在 alpha.2。这种包不会跟着你升级，它自己走自己的。

顺手验了一遍

升级完之后我在网页版开了一个新会话，只发一句：调用 profile_ping，把返回的 JSON 原样贴出来。

十秒完成，返回的开头是 "profile": "web", "dshVersion": "0.2.2-rc.1", "plugins": [ 后面跟着 212 个插件名。

这 212 行就是我这个 profile 现在的真实构成，从 cordis-plugin-timer 一直到我自己写的 dsh-plugin-profile-ping。想确认升级到底有没有生效，看这一个数字比看任何界面都准。

顺带一提，这个查询本身花了 56.3K token，缓存命中 86%，上下文只用了 3%。开销主要在插件清单太长，不在推理。

一个查版本的经验

如果你也想追 dsh 的版本，有个坑得避开：子包的 latest 标签是滞后的。

比如 dsh-experimental-client-ui-agent-team，它的 latest 停在 0.1.5-alpha.2，alpha 停在 0.2.2-alpha.3，真正的新版本在 next 里。

npm view <包名> dist-tags 三个标签一起看，别只看 latest。主包现在 latest 是对的，子包不是。

我的判断

这类版本值不值得跟？我的答案是跟，但不用急。

代码零变化意味着风险接近零，升不升都不会坏你的环境。真正的收益不在 dsh 本身，而在那些跟着转正的插件：ui-agent-team 这种跨版本线的包，只有在整条线一起转 rc 的时候才会被放出来。

反过来说，如果你手上有个跑得好好的 alpha.3，没有任何插件被禁，那这次不用动。等 0.2.2 正式版出来再一次性跟上，中间这几天不会有新功能给你。

你升级的时候会先看发布说明，还是直接拆包比一遍？

我本机天天在用 dsh，跑的是 2026 年 10 月 28 日发的 0.2.2-alpha.2，看到这条的第一反应不是转述，是试一遍。

于是我在自己的 web profile 里开了一个 Creator mode 的会话。给它的需求只有一句话：写一个最小的插件，注册一个叫 profile_ping 的工具，返回当前 profile 名、dsh 版本号、以及这个 profile 里装了哪些插件。

九分钟之后，这个工具躺在插件管理页里，我新开一个会话调它，十秒拿到了结果。

dsh 一共有四种模式

打开 web 界面，输入框上面有个模式选择器，点开是四条：

• Standard，写代码、查资料、跑命令，适合大多数任务
• PTC，包住 Standard 全部能力，额外适合「批量调工具再筛、去重、统计」这类活
• Minimal，只给终端和读图，用来测基础能力
• Creator，官方原话是「通过对话定制 dsh，让 agent 写插件加功能或界面，或者把工具和提示词组合成你自己的模式」

我这次点的是第四条。

它没有一上来就写代码

这点是我最意外的。

接到需求之后，它先载入了一个叫 cordis-plugin-development 的技能包，然后开始查运行时。

界面右侧的 Trajectory 里能看到它一连串动作。先 inspect providers 看有哪些服务，再 query runtime 问 Service.listService 的方法签名，一遍遍查 pluginManager、profileContext、defineTool 的确切契约。

它甚至去翻了 @deepseek-ai/dsh-app-boot 的源码，来判断「插件里能不能 import 这个包」。它要拿 dsh 版本号，而版本号只能从安装目录的 package.json 里读。

这一步的判断过程我觉得比结果更值钱：它先确认「profile 里装的插件解析不到安装目录的包」，然后改用运行时已经提供的 profileContext，从 installAnchor 那个路径自己去读。

写出来的东西是这个样子

生成物在会话的工作区里，是个标准的 bundle 包：清单、补丁、入口、两份语言文件、一枚图标，外加一份 README。

package.json 里那句 "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }，就是它跟 dsh 打招呼的方式。补丁文件只有三行，插入一条 id 叫 profile-ping 的行。

index.js 六点九 KB，自己注册工具、定义参数和输出 schema、写 render。中文名字「Profile 探针」是它自己起的。

中间我拒了它一次

安装那一步它调的是 plugin_manager 的 install_bundle，界面上弹出一个授权框，写明「这会把改动写进 profile，装进去的 Host 代码在沙箱外面跑」。

我点了 Allow once。

后来它想把打包好的 tgz 从 /tmp 复制到 Documents 下做长期保存，又申请一次授权。这次我点了 Reject，因为这是我准备做完实验就清理的临时东西。

它的反应值得记一笔：它停下了，并且明确说「用户拒绝了这次提权，所以我不该绕开，解释清楚就行」。

这条规矩写在它的技能包里，不是模型的即兴发挥。原文是「不要手写 profile 的 package.json，不要自己在 profile 目录里跑 pnpm，这些事由 install_bundle 做」。

跑通了

新开一个会话，我说「直接调用 profile_ping，把返回原文贴出来」。

十秒钟，它贴出来：

返回就三行开头：Profile: web、dsh version: 0.2.2-alpha.2、Plugins (209):。后面跟着两百零九个包名，排在末尾的那个，正是它自己写的。

插件管理页的「已安装」里也多了一行：Profile ping，带图标、带描述、开关是开的。

它的技能包里把规矩写死了

跑完我才去读它载入的那份技能文档，读完明白它为什么这么走。文档里写道，这套流程分五步，第一步就是「先交付能用的版本」。

文档开头就写：先交一个能跑的版本，再谈好不好看。视觉需求如果没说落在哪，默认就是当前这个 Web 界面；不要先做预览页、别做几套设计稿、别写截图脚本。

然后是三条禁止：不要手写 profile 的 package.json，不要在 profile 目录里跑 pnpm，不要在 $DSH_HOME 下面造包。这些活统一交给插件管理器的 install_bundle，手工写一次就要一次审批。

还有一条验证规矩：装完看返回里的 application 字段和 warnings，别看日志、别看进程列表、别看页面是不是起了。

我这次全程没干预它的技术判断，唯一做的就是两次授权点击，一次同意一次拒绝。它在这套规矩里自己走完了。

三个坑，我得说清楚

第一个，它创建的工作区目录名带了反斜杠。dsh 在 macOS 上把路径拼成了 deepseek-harness\creator-lab，那个反斜杠是真的字符，不是转义。结果 ESM 加载这种路径直接报错，插件根本 import 不进来。它自己发现的，改用打包成 tgz 安装绕过去了。

第二个，装完当回合调不到工具。工具列表是这个回合开始时就定死的，新注册的工具下一轮才出现。它在 Trajectory 里连着打转了好几次，自己在思考里写「我可能只能发出静态列表里的工具」，我另开一个会话，才验证成功。

第三个，安装记录里写的是 file:/tmp/dsh-plugin-build/xxx.tgz。也就是说，清了临时目录，这个插件下次就装不上。它想修的正是这一点，被我拒了。真要长期用，得把包放到工作区里，用 install_bundle 指目录安装。

它现在能造什么，造不出什么

能造的：工具类插件，往 agent 的工具箱里加一个能力，我这次的 profile_ping 就是；配置类插件，改宿主某个服务的行为；界面类插件，往 Web 界面的插槽里挂一块。技能包里这三类各有模板和参考文档。

造不出的：需要新宿主服务的插件，它自己文档里写着这个插件不是内核，不加服务、不加会话事件类型、不加沙箱后端；还有跨 profile 的改动，一次只能动当前这个 profile。

一个更实际的限制是 token。这次九分钟的活，烧掉 890 万 token，缓存命中 99% 才压住了成本。你要让它干大活，得先想清楚值不值。

我的判断

「用聊天造插件」这个说法容易让人以为它是个生成器：你描述，它吐代码。

不是。它更像一个懂这套框架的工程师：先查运行时有哪些能力，再读源码确认约束，然后照技能包里的流程施工，装的时候申请授权，装完自己验一遍。

真正稀缺的是那套流程本身。技能包里把「先交一个能跑的版本，再谈好看」「视觉需求默认落在当前界面」「安装结果看 application 字段而不是日志」这些规矩都写死了。模型会换，这套规矩不换。

一个能力边界放这儿：它九分钟里烧了 890 万 token，缓存命中 99%。这不是零成本的魔法，是一次真刀真枪的施工。

你手上有哪个工具，是每次都要手动翻一遍配置才知道状态的？那种东西，值得让它给你写一个插件。