夜雨聆风
8 月 13 日，DSH 刚发布，我就迫不及待地安装食用了。
照这个速度，怎么也算个“种子用户”吧。我主要看了界面和操作方式。
官方发布页最醒目的一句话是：Everything is a plugin，一切皆插件。
我看到这句话的第一反应很简单：这不就是 PI 的变种吗？仓库里也确实有一个基于 pi-ai 的 LLM 适配层。再往下看，DSH 官方强调的底层叫 Cordis，README 还挂了一篇关于时空可组合性的论文。
那篇论文我还没细看，不过不影响先“食用”一下 DSH。
01 先看 DSH 现在有什么
这次隔离运行的版本是 @deepseek-ai/dsh@0.1.0-rc.6。启动后是一套熟悉的 Coding Agent 界面：左边是工作区和会话，中间输入任务，新会话可以选择模式。这次我只聊界面和操作方式，谁更强、谁更快、稳不稳，留到真正跑任务时再说。
当前中文界面有四种模式：标准、PTC、极简、创造。
标准模式最像大家熟悉的 Coding Agent，文件编辑、Shell、搜索、Skills、计划和子代理都放进去了。
PTC 模式通过 Code Mode SDK，让模型用 TypeScript 组合多步操作。
极简模式只留下持久 Bash 和文件编辑器。创造模式更有意思，可以检查运行时、实验插件、创建 Agent preset。
再打开插件列表，会看到一个很醒目的数字：133。
这里的 133 是当前部署列出的运行时插件数量，不是第三方插件商店的生态规模。
往下看，llm、session、agent、api-gateway 都算插件。这个数字没那么像应用商店，更像拆开机器外壳以后看到的零件数量。
官方架构文档写得很清楚：model adapter、tool registry、session log、agent loop 都在插件树里。
插件教程则给出了具体写法：插件是导出 apply 函数的 TypeScript 模块，加载时拿到 ctx，再向运行时注册能力。
模型、工具、Skills、会话、沙箱、存储、循环、调度，连 UI 都可以换。“一切皆插件”已经落到了架构里。
你拿到了一盒积木。盒子里已经有不少东西，怎么搭，由你说了算。
02 再看 Codex
Codex 官方文档把终端、代码审查、本地和云环境、Git worktrees、Skills、plugins、hooks、MCP，以及 SDK 和第三方集成放在同一个产品工作流里。
DSH 开放得更深。model adapter、tool registry、session log、agent loop、沙箱和 UI 都留有继续拆换的空间。主动定制的人得到更多控制权，也接过了更多集成工作。
Codex 把常用工作流装好了，DSH 把更多零件摊在桌面上，等你自己选。
我要马上完成任务，Codex 更省事；我要搭一套自己的 Agent，DSH 给的空间更大。今天直接把 DSH 叫作 Codex 替代品，我不认。
DSH 能慢慢搭出类似的工作流，现在离“装好就用”还隔着一段产品化工作。官方也把它标成 developer preview，并且用大写提醒：后面会有破坏兼容性的变化。
03 它更适合想做专属 Agent 的程序员
我认为 DSH 现在更适合程序员，尤其是想做一个专属 Agent 的程序员。
他们会固定自己的模型入口，保留自己的会话方式，接一套顺手的工具，控制沙箱和凭据，再把 UI 调成自己愿意天天使用的样子。
想做模型评测，可以用极简模式减少工具集合和运行环境带来的变量；想折腾运行时，可以进创造模式看插件、做 preset；想搭内部 Agent，可以自己决定每一层怎么组合。
它就是程序员手里的一套 Agent 开发底座。愿意花时间的人，可以慢慢把它调成一件真正贴合自己的工具。
04 自由带来的坏处就是复杂度上升
模型能换，工具能换，会话能换，沙箱也能换。听起来很爽。轮到升级、排错和回归测试，这些自由会一项不少地回来找你。
你要选插件、锁版本、管配置、查加载顺序，还要确认几个插件放在一起以后能不能正常协作。今天跑通的组合，明天遇到核心 API 或配置结构变化，测试得再来一遍。
DeepSeek 把开关都交给了你，也把维护单一起放进了盒子里。最后组合出来的产品靠不靠谱，还是要有人负责。
愿意承担依赖、版本和兼容性的人，可以拿这些工作换更大的控制权。只想装好就用的人，看到的多半是一份突然增加的作业。
05 安全这块，现在就是个问题
到了安全这一层，我还不敢放心地把真实凭据交给 DSH 的插件。
DSH 的插件是可执行 TypeScript 模块，会通过 ctx 注册和消费服务。安装一个插件，等于把一段代码接进 Agent 运行时。
偏偏 DSH 插件化的范围很深。官方架构列出的基础层里有沙箱、审批策略、设置和凭据。当这些东西都进入可组合体系，插件从哪里来、能碰什么、改配置时有没有明确提示，就不能只靠用户胆大心细。
8 月 14 日，一位社区用户在 GitHub Discussion #587 报告：0.1.0-rc.6 的第三方插件会在启动阶段进入核心进程，可能影响沙箱、审批策略和凭据配置；他还质疑 dsh plugin add 缺少签名、来源和配置差异确认。
截至 8 月 15 日，维护者还没有回复。
安全问题就摆在这里。沙箱、审批和凭据都靠近插件树，DSH 就需要把信任边界讲明白：第三方插件到底能碰到哪里，谁能修改保护其他插件的规则，安装时用户能看到哪些变化。
现阶段就该只装来源能审查的插件，锁定版本，先在隔离环境里跑，真实凭据和重要工作区晚一点再接。签名、权限说明、变更确认和隔离能力，这几项都得尽快跟上。
06 我想定制一个自己的 Agent
我已经受够了在不同 Agent 产品之间来回切换。
每个产品都有自己的模型入口、会话、工具和设置。换一个产品，又要重新适应一遍。功能越来越多，我花在“搬家”上的注意力也越来越多。
所以 DSH 这种路线对我有吸引力。我可以把它当成一块长期底座，慢慢换模型、加工具、调会话、收紧权限，最后定制出一个属于自己的 Agent。
这个过程肯定比安装一个成品麻烦。对我来说，这份折腾至少朝着自己的体系积累。developer preview 阶段免不了版本迁移，好过每换一个产品就从头适应。
如果你也受够了不同产品来回切换，又愿意承担长期维护和安全检查，DSH 很适合拿来慢慢定制。
07 别让工具反客为主
无论 Codex、DSH，还是后面再出来的各种 harness 产品，都是工具。
工具可以写代码、跑命令、查资料、审查改动，甚至替我们完成越来越长的任务。选什么问题、相信什么结果、承担什么后果，最后还是人的事。
今天要直接完成工作，我会选 Codex；想慢慢搭一套专属 Agent，我会折腾 DSH。工具怎么选，取决于我要完成什么事，决定权应该一直留在人手里。
人是驾驭者，工具就该待在工具的位置。别把顺序颠倒了。
祝大家工作顺利，生活愉快。