把工作流封装成软件:从工作站到安装包

我们之前用「结合 Coding Agent 的工作站架构」，把「如何与 AI 协作」这件事情梳理清楚了，它就是一套借助 AI 放大个人能力的工作流——用工程化的思路固化流程、保证质量、积累知识，让工作闭环在和 Coding Agent 的一次次对话里「聊」出来。

这套模式可以相当私人化，而且维护成本的大头不在我们——Agent 能力的迭代由 Coding Agent 厂商扛着，我们只管工作流里的 SKILL、脚本、工具链协作和业务知识，也就是业务那一层。

但工作站模式有一个隐形前提：使用它的人是我，或者说，是懂工程的人。搭目录、写 AGENTS.md、配环境、和 Agent 磨合——这些对我们是乐趣，对不懂工程的人是门槛。当一套工作流已经成型、我想把它交给不会用 Coding Agent 的人手上时，问题就变了。

怎么让一个人双击软件，就拥有我这整套工作流？

背景：为什么还要一个壳

这套工作流做成的第一件事，是把「软件开发齐套性交付」检查封装成一个桌面软件：客户拿到安装包，双击装好，在设置里填上自己的模型 key，就能让一位 AI 专家跑完整的齐套性检查——不需要知道什么是 Coding Agent，不需要配任何环境。

在回答「怎么封装」之前，有必要说个更轻的选项：SKILL + 工具链这个形态，本身并不需要封装成软件——上传到 SkillHub 这类技能市场（一键安装、平台安全审查，宿主覆盖 WorkBuddy / OpenClaw / Claude Code 等），几乎是零成本分发。

那为什么还要一个壳？

技能市场上架的是能力，安装包交付的是承诺——验收标准型业务必须控制运行环境，确定性本身就是产品的一部分。像齐套性检查这种要给结论背书的场景，「在谁的宿主、什么版本上跑出这个结果」必须可承诺，技能包给不了这个承诺。

信任和采购的最小单位是软件，不是技能。客户的采购清单里能立项、能验收、能付款的条目是软件；一个技能包，进不了采购流程。

平台和软件不是二选一，是漏斗两端——平台做获客入口，自己的壳做交付闭环。平台上是一键安装的低门槛试用，真正把确定性交付到客户环境里的，是自己的安装包。

技术层面视角

之前也说过「软件已经足够便宜」，言下之意是，壳不再是壁垒，不值得恋战——用最低成本让壳适配业务，力气全花在 SKILL、验收标准和领域知识上的工作流串联。而反过来，正因为人人都能有壳，光有壳毫无价值：壳是交付形态的必要条件，不是竞争优势；业务层才是。

那问题回到起点，壳从哪来。这次我们尝试 dsh-desktop：基于开源的 dsh-desktop（DeepSeek Harness 的社区 Electron 桌面客户端，MIT 协议），把工作流封装成一个完整的 Agent 桌面软件。我已经用它把「软件开发齐套性交付」这套工作流做成了第一个实例，后面会从真实落地记录铺开，来看看如何从技术角度出发，尽可能低地成本做到。

先看终态：

对比以前的工作站模式，「维护成本在厂商」的逻辑也被完整保留了：我们把 Coding Agent 厂商换成了开源社区，业务层还是业务层。

为什么不自研

动手之前我也认真考虑过自研「harness + 完整 Agent 软件」。毕竟自己有工程能力，写一个可用的 Agent 并不难。但算账之后放弃了，因为自研的真实成本不在「可用」，而在那些只有长期运营才会暴露的子系统：

这些恰好全部「与业务零耦合」。自研它们，等于把工作站的核心理念反过来用——把精力从业务层抽走，投进别人已经做好的通用层。fork 路线则把这些未知研发黑洞，换成了已知的、有账单的维护成本：钉死版本、记账每笔改动、升级时按清单重核。

我认为还有一个更核心的理由：业务资产不该被 harness 绑架。我的 SKILL 包唯一事实源在业务仓库，底座只是运行时载体——哪天换底座，业务一行不用改。这和工作站模式里「SKILL 沉淀在骨架层」是同一种思维。

下篇预告：dsh 生态落地纪实

搞清楚 dsh 的生态，有利于我们进一步把握自己的业务产品边界，这也是一个很重要的出发点。开源底座自然能让我们省很多事，但真正成为安全可信的产品底座，并非「无脑」使用。

首先还是业务判断：哪些能力是业务真正需要的，哪些是功能冗余、可以砍掉，哪些存在安全隐患、必须隔离或移除，哪些能与业务结合、放大价值，哪些需要定制化研发来适配业务，哪些是业务嵌入时必须新开发的部分。

下篇会接着往下深入技术，把 dsh 生态的架构看清楚，并按实际发生的顺序复盘整个落地过程：《把工作流装进安装包：dsh 生态落地纪实》。

当然，说到这里，dsh 其实不是唯一选择。在 AI 时代，底座的供给只会越来越充裕：Anthropic 的 Claude Agent SDK、OpenAI 的 Agents SDK、跑在自有硬件上的 OpenClaw、从终端一路铺到桌面和 IDE 的 OpenCode，还有更极简的 Pi Agent——它们本质上都在解同一道题，只是路线不同；再过半年，很可能又会出现更顺手的那个。

业务资产不变，只是换交付形态

从工作站到专家软件，其实是同一个判断框架的两次应用：

先分清哪些是业务、哪些是 harness、哪些是壳，然后只为第一层写代码。

工作站模式里，我们把 Agent 能力交给 Coding Agent 厂商；封装软件时，我们把 harness 和壳交给开源社区。而 SKILL、工具、人格、流程共识、质量标准、领域知识这些真正有价值的东西，从头到尾长在我们自己的仓库里——它们在工作站里是可对话的工作流，在安装包里是开箱即用的专家，形态变了，资产没变。

这也是那篇工作站文章结尾那句话的自然延伸：

通用的部分交出去，差异化的部分长在自己手里——只不过这次，交出去的对象从厂商产品变成了开源底座，长出来的东西从私人工作站变成了可以递到别人手上的软件。