Everything is a Plugin
DSH 的 Plugin 意味着什么

1. 口号原文写了什么

官方DeepSeek 开发者预览页的标题就是 Everything is a plugin。同一页写明：每一项能力都是可替换、可重组的插件，范围包括 models、tools、skills、sessions、sandboxes、storage、loops、scheduling 和 UI。〔1〕

官方GitHub 仓库把这句话重复了一遍，并指向 Cordis，以及论文 A Programming Paradigm for Spatiotemporal Composability。〔2〕〔3〕

2. 官方架构把 Plugin 钉在哪

官方中文架构文档写得更硬：产品的每一部分都是插件，包括模型适配器、工具注册表、会话日志，以及 agent loop 本身；不存在需要打补丁的特权内核；扩展方式是把插件挂到旁边；各项注册都是副作用，会在插件卸载时撤销。〔4〕

Cordis 入门文档把同一件事拆成可操作的规则：插件用 inject 声明依赖，等所需服务出现后再激活；提示词片段、工具 schema、适配器和监听器通过 ctx.effect() / ctx.on() 注册，以便重载和拆除时按顺序撤回。〔5〕

所以这里的 Plugin，不是“给现成 Agent 再挂一个工具”。它可以是 Agent 自己怎么转圈。

3. 和 MCP、Skill 差在哪

日常说的“插件”多半指 MCP 服务器，或 Claude / Cursor 一类产品里的 Skill。它们都能扩展能力，但位置和运行机制不同。

MCP / Skill 一侧按常见产品机制归纳；DSH 一侧依据〔1〕〔4〕〔5〕。

维度一：位置与权限

oh-story-dsh 的架构说明从反面印证了这层分工：它明确把 Agent loop、模型、凭据、沙箱、权限审批留给 DSH，自己只贡献创作 Skills、Roles 和三栏工作台。〔8〕 换句话说，社区插件可以换交互和工作流，核心循环仍是可替换的官方缝，而不是焊死的黑盒。

维度二：工程与运行机制

论文Cordis 论文把动态组合收成两个正交条件：时间可组合（temporal composability）是卸掉一个组件时，能把它造成的副作用完整撤回去；空间可组合（spatial composability）是组件能声明彼此依赖，并由运行时跟着这些依赖做激活和停用。〔3〕

论文的实现层也写得很具体：可逆 effect、响应式 coeffect、声明式组件加载器、配置对账，以及热替换。〔3〕 这和官方那句“注册会在卸载时撤销”对得上，不是事后比喻。

对照现有扩展方式，差别主要在机制，不在口号：

• Skill 常见做法是把说明放进上下文，再让模型挑。装得越多，上下文越长，匹配面越大。这是机制成本，不是对某个产品的测速结论。
• MCP 服务器写在客户端配置里。删掉条目后，进程里已经挂上的工具和提示词，通常要靠重启或不完整的清理来处理。
• VS Code 一类扩展能装能关，但彻底干净往往要重载窗口；设置和贡献点也可能留下。
• DSH 把“想拔就拔”写成运行时性质：卸载走 inverse，依赖消失则相关组件停用。〔3〕〔4〕〔5〕

4. 为什么这两个条件重要

触及核心，再加上卸得干净，才会让“自己改自己”在工程上便宜。论文摘要开篇就把问题域写成：从插件系统到 self-evolving agent harnesses，都需要动态组合。〔3〕

官方Creator 模式提供了一截已经能看见的路径：检查当前运行时，在内存里试验 Cordis 插件，再把它们组合成新的 mode。〔1〕

1. 产品里已经能看见什么

官方预览页列出四种运行模式：Standard（完整编码 Agent）、Code（用模型生成的代码编排多轮工具调用）、Minimal（只留 shell 和文件编辑，用于评测）、Creator（检查运行时、内存中试验插件、组合成新 mode）。〔1〕

可观察当前 Web 产品里还有插件市场：能力按类展示、发现和安装。标准模式降低使用门槛，创造模式打开组合空间。两种模式共用同一个 Harness。

官方还写了开发者可以在配置里选择、替换或扩展任何能力，而不改 DSH 源码。〔1〕〔4〕 生产单位因此可以缩小：不一定交付一个完整 Agent，也可以只交付一个专业组件。

2. 案例：小说与短剧工作台

可观察oh-story-dsh 是社区做的 Cordis 插件，不是官方产品。仓库说明：DSH 继续管理 Agent、会话、模型、权限和 Chat；插件提供创作 Skills、专业 Roles、项目协议和三栏工作台。〔7〕〔8〕

上表直接摘自项目 Architecture 的 Ownership 表。〔8〕

它没有 fork DSH，也没有重写 agent-loop。Browser 入口走两个官方扩展位：shell.overlay 放下三栏工作台，tool.call.toolview 放下 Role 调用视图；官方 Chat 仍占第三列。〔8〕 安装方式是往 web profile 里加一个插件包。〔7〕

和 Flowise、Dify 一类“通用编排器上再挂小说节点”不同：这里交付的是一个小说 / 短剧工作台。用户面对的是创作文件、Roles 和分集文档，不是一个大而全助手外加几个写作按钮。

3. 由此可以推断什么

推断下面三句不是官方结论，是从第一部分的机制和第二部分的用法推出来的。

1. 如果核心循环、界面和工作流都可以按插件替换，Agent 产品就不必先做成一个覆盖所有场景的旗舰，再往上叠行业功能。
2. 更便宜的做法是：Harness 提供可逆、可声明依赖的运行时；具体服务以工作台或预设的形式出现。oh-story-dsh 走的是这条路。
3. 自我进化如果要发生，改的应是这棵可卸载的组件树，而不是在焊死的框架外再写一层记忆优化。目前能核对的，仍只到 Creator 模式和社区换工作台。

过去常见的是：中心化能力入口，再往上叠加服务。这里看见的是：服务自己成为载体。

推断Agent 更可能长成贴近用户工作流、可替换、可回滚的分布式形态，而不是再做一个更大的万能助手。这个判断依赖两个前提继续成立：核心模块保持可替换，卸载继续保持可逆。任一前提被收回，推断都要重写。