把工作流装进安装包:dsh 生态落地纪实

上篇说了为什么要给工作流加一个壳、壳为什么来自开源社区而不是自研。这篇是落地纪实：我们把「齐套性交付」这套工作流，做成了一个 264MB 的 Windows 安装包——双击安装、填上自己的模型 key，一位「齐套性专家」就开始跑完整的交付能力。

技术细节放到了飞书知识库内，阅读原文可了解所有细节。这篇我们关注四个关键决策和它们背后的判断。

一、dsh 生态地图：三层，各司其职

dsh 生态是三层东西叠起来的，分清它们，就知道哪层拿来用、哪层可以换。

最底层是 DeepSeek Harness（DSH），Agent 执行层，DeepSeek 官方开源（MIT），构建在 Cordis 插件框架上，「Everything is a Plugin」——模型适配器、工具注册表、甚至 Agent loop 本身都是可替换插件。对我们最关键的：会话日志可回放、Skills 原生兼容 .agents/skills 布局（业务包零修改被发现）、模型零绑定、子代理并行扇出。

中间层是 dsh-desktop，社区做的 Electron 桌面壳（与深度求索无隶属关系）。薄壳一个，价值在工程链：运行时全部 vendored 进安装包，零依赖安装；3 个轮换 checkpoint 兜底升级翻车；桌面壳自己就是一个普通 Cordis 插件——你的插件和官方插件走同一条一等公民路径。

最外层是分发：插件就是 npm 包，另有开放的社区市场（收录 ≠ 安全审核）。

二、纪实：我们如何和 Coding Agent 一起完成

体力活，调研、spike 代码、打包链，由 Coding Agent 承担，判断点全由人拍板。按实际发生的顺序记四个决策。

决策零与一：先调研、再 spike

动手前先回答：这件事里真正属于自己的资产是什么？ 答案是 5 个 SKILL 包和编排经验；harness 只是执行层，是可替换的耗材。选型标准因此自然浮现：底座必须让业务资产零改造地跑起来。

按这个标准对两个仓库做源码级调研，四条结论定了后面的路：skills 扫描兼容 .agents/skills 布局 → 不换底座有依据；preset 机制支持人格 + 随包技能 → 「专家包 = 一个 npm 插件」成立；上游「升级后无法启动」是高频 issue → fork 必须保留 checkpoint 回滚；商标红线 → 产品定名「齐套性专家」。

调研结论要跑通才算。进入实现前做了一轮 spike，只验最致命的三条假设：插件包零改造被发现、人格真实注入、自定义 provider 连通。三条全 PASS 才进入实现——这一步跳过，后面所有工作都建立在沙子上。

动手入口：查四件事——skills 布局、preset 机制、issue 高频主题、license 商标；再装官方壳亲手验这三条假设，全过再谈实现。

决策二：两阶段落地

理由是风险成本不对称：同样的失败，发生在插件阶段只需改一个 npm 包，发生在 fork 阶段要动整个壳。

第一阶段：官方壳 + 插件包，只验证业务层。 一个很薄的 npm 插件包（人格 preset + 拷贝的 SKILL 包 + 几十行适配层）装进官方桌面端，跑通真实交付全流程。verify_styles 报的 8 项 FAIL 没有含糊过去，逐条归因：5 项模板固有、3 项填充引入。归因清楚，比全绿重要。

第二阶段：fork 换皮，出独立安装包。 业务验证过后才 fork：品牌配置脚本驱动、摘掉指向上游的更新端点、UI 按专家产品裁剪、完全便携化。所有偏离逐笔记在 FORK.md，把维护成本变成「有账单的清单」。

动手入口：先把业务封装成插件包装进官方壳跑真实流程，FAIL 逐条归因；全绿后再 fork，每笔偏离记「fork 账单」。

决策三：边界——哪些坚决不碰

• 不改原 SKILL 包：语义差异用几十行适配层兜住，原包一字不动——资产一旦为底座打了补丁，就被底座绑架；

• 不预置任何厂商 key：用户自己填 provider 和 key，产品不经手密钥；

• 不沿用上游自动更新：端点摘掉、升级显性化——对 0.x 阶段的上游，静默升级不是便利，是风险。

动手入口：差异用适配层兜、密钥让用户自己配、上游升级显性化。

决策四：质量门

贯穿始终的纪律：机器门禁全绿可以自动推进，方案选择、Go/No-Go、验收结论必须由人拍板。 四个坑全是验证环节撞出来的，没有一个靠「注释掉报错」混过去：

• 锁文件必挂（YN0028） → bundle 内容变化的提交，必须先刷新 yarn.lock 一起提交；

• CSS 被裹进 onboarding 作用域 → 新样式一律运行时注入，禁止新增 .css import；

• Git Bash 吃掉静默安装参数 → 安装卸载自动化一律走 PowerShell；

• 遮蔽上游 UI 依赖哈希前缀 → FORK.md 显式登记「上游升级时必须重核」，知道自己哪里脆。

最终验收是一串可复现的动作链，每步都有退出码或截图作证。

动手入口：验收 smoke 四步直接抄走——干净目录静默安装（用 PowerShell，别用 Git Bash）→ 首启查插件、人格、日志里的上游域名 → GUI 问「你是谁」→ 静默卸载确认业务数据保留。

三、架构层面的三点沉淀

抛开齐套性这个具体业务，这次落地有三个可复用结论：

• 通用块与专属块严格分离：下一个专家 = 换一个目录 + 可选新面板，壳和框架不动；

• 业务资产不被底座绑架：SKILL 包唯一事实源在业务仓库，安装包只是构建时拷贝——底座是耗材，资产是积累；

• 验证纪律本身是架构的一部分：调研带出处、spike 先验证、门禁人拍板、踩坑固化为规则——「换底座」从豪赌变成一条有账单的工程路径。

壳是开源社区给的，底座一行没改；我们的工作在边界上——资产划在哪、风险在哪一层暴露、哪些东西坚决不碰。

完整工程文档的链接放在了「阅读原文」，有兴趣我们可以在原文里探讨。