DSH 一切皆插件
很荣幸参与DeepSeek Harness在8月初的内测，在这里为大家介绍DSH最有特点的插件系统。
提到插件系统，人们通常会想到一个已经完成的主程序：浏览器先存在，再安装扩展；编辑器先存在，再安装主题和语言插件。插件负责增加外围能力，核心程序仍然拥有不可替代的主干。
DSH 采用了更彻底的设计：Agent Harness 本身由插件构成。模型适配、系统提示词、工具、会话记录、Agent Loop、执行环境和浏览器界面等产品能力，都作为插件参与组合。
这篇文章讨论三个问题：为什么 Agent Harness 适合插件化，DSH 开放了哪些定制方式，以及这种架构可能怎样改变 Agent 开发社区。
一、为什么 Agent Harness 能够插件化
Harness 是一组协作能力
大模型负责根据上下文预测下一步输出，但一个 Agent 要完成真实任务，还需要有人组织上下文、提供工具、执行动作、记录结果，并判断是否继续下一轮。承担这些工作的系统就是 Agent Harness。
一个典型 Harness 至少要回答下面的问题：
- 使用哪个模型，怎样处理流式输出和失败重试？
- 哪些信息进入上下文，什么时候压缩，哪些内容对模型可见？
- Agent 能调用哪些工具，工具运行在哪里，权限怎样限制？
- 一次工具调用结束后，继续请求模型还是结束任务？
- 对话和执行结果怎样持久化，怎样回放和投影到界面？
- 不同 Agent、用户和部署环境怎样获得不同能力？
这些问题没有一套适合所有场景的固定答案。终端 Agent、网页研究 Agent、企业内部 Agent 和自动化工作流可能共享同一个执行循环，却需要不同的模型、工具、存储、权限和界面。因此，Harness 是一组相互协作、可以拆分和替换的能力。
这些变化主要发生在能力组合和策略选择上。插件化直接对应问题本身的结构：把每项能力做成可以替换的节点，把依赖和协作关系表达成边，再由一次部署选择需要的组合。
真正困难的是让变化安全地发生
把代码拆成许多包并不等于插件系统。一个能够长期演化的 Harness 还需要解决五类运行时问题。
第一，依赖必须明确。工具插件不能假设某个 Shell 或 Session 服务碰巧已经启动；它需要声明自己依赖什么，由运行时按照依赖关系激活。
第二，协作需要稳定的接口。模型请求、工具执行、停止判断和会话更新不能依赖插件彼此直接导入。服务负责提供能力，事件负责让多个插件在同一执行阶段协作。
第三，注册必须可撤销。插件卸载后，它注册的工具、监听器、服务和后台资源也应当释放，否则热更新很快会变成重复监听、幽灵工具和资源泄漏。
第四，模型看到的事实必须可以重建。如果一段临时注入的信息改变了模型决策，却没有进入会话记录，那么回放、调试和上下文恢复就无法解释 Agent 为什么这样行动。
第五，部署需要可组合。开发者不仅要写出一个插件，还要决定它与哪些插件一起运行、使用哪份配置，以及怎样针对终端、Web 或自动化环境形成不同组合。
DSH 底层使用 Cordis 提供上下文、依赖注入、事件和可逆生命周期。产品层没有一个要求所有扩展都去修改的巨大核心；Session、Prompt、Tools、Agent 和 LLM 等能力作为插件服务彼此组合。这里的“小内核”主要负责加载和生命周期语义，产品差异留在插件图中。
插件化有边界
“可逆”表示运行时能够撤销纳入生命周期管理的注册和资源，不表示它能回滚已经写入的文件、数据库操作或网络请求。“作用域”只负责依赖查找和能力可见性，不提供安全隔离。第三方插件仍然是运行在 Host 中的可信代码。
因此，插件化解决的是架构上的独立演化与组合问题，不会自动解决事务、安全和质量问题。这些约束越清楚，插件系统才越有可能形成可靠生态。
二、DSH 有哪些插件化接口可以定制
理解 DSH 的扩展方式，可以直接从“我想改变什么”出发，无需先背包名。
| 想改变的事情 | 主要扩展方式 | 需要遵守的约束 |
|---|---|---|
| 接入新的模型或执行后端 | Service Definition、Provider、Consumer | 能力接口、实现和消费方应形成完整能力接缝 |
| 增加模型可调用的动作 | Tool Registry | 参数需要有 Schema；模型可见的结果需要进入会话记录 |
| 增加系统提示词或动态上下文 | System Prompt 与 Context 插件 | 任何实际进入模型请求的输入都必须可从 Session Log 重建 |
| 在模型或工具调用前后加入策略 | Agent、LLM 与 Tools 事件 | Waterfall 监听器必须调用 next() 才会继续下游处理 |
| 增加持久事实或新的界面投影 | Session Event 与 Projection | 事件需要稳定类型；读模型必须处理它承诺理解的持久事实 |
| 为不同 Agent 提供不同能力 | Scope 与 Agent Preset | 最近作用域优先；服务隔离需要显式配置 |
| 增加 Web 页面、设置项或结果渲染 | Client Module 与 UI Slot | Host 和浏览器分别由 Cordis Loader 管理生命周期 |
| 组合并分发一组插件 | Bundle、Profile 与 Patch | Patch 层次决定配置来源；插件激活顺序仍由依赖图决定 |
| 让 Agent 临时扩展自己的运行时 | Cordis 自修改工具 | 临时插件不持久化，并与执行 Shell 代码具有相近的信任要求 |
1. 用服务表达可替换能力
服务适合表达“只有一个或少数实现向其他插件提供能力”的关系。以 Shell 为例，服务定义声明执行接口，本地或远程 Provider 提供实现，Bash 工具作为 Consumer 把这项能力暴露给模型。
DSH 把一项完整能力拆成 Service Definition、Provider 和 Consumer 三个角色。这样，更换执行环境不要求修改 Bash 工具；增加一个新工具也不要求理解本地进程实现。依赖关系通过 inject 声明，运行时按照依赖图激活插件，配置文件的书写顺序不参与决定。
2. 用注册表承载一对多贡献
工具、提示词片段、Agent 定义和界面 Slot 等能力允许多个插件同时贡献，适合使用注册表。插件激活时注册贡献，卸载时由 disposer 撤销。
工具注册尤其能体现 DSH 的设计：一个工具同时包含可调用函数、模型看到的名称、说明和参数 Schema，还要处理结果怎样写入会话、怎样在终端或界面中呈现。模型体验从一开始就是插件接口的一部分。
3. 用事件扩展执行过程
如果插件需要观察或改变一次 Agent 运行，事件比修改 Agent Loop 更合适。插件可以在一次模型请求前补充策略，在流式响应期间处理输出，在工具调用前后做审批、记录或转换，也可以参与停止判断。
其中部分事件采用 Waterfall 语义：每个监听器既可以在下游处理前后工作，也可以有意截断链路。调用 next() 明确表达“把控制权交给后续插件”；省略它则表示有意截断。
DSH 同时区分实时运行事件和持久 Session Event。前者协调当前执行，后者记录已经发生的事实。模型可见信息必须落到后者，这条约束把插件扩展与回放、调试和持久化连接起来。
4. 用 Scope 组合不同 Agent
插件可以只在特定作用域内可见。DSH 可以为 Agent 和 Preset 建立作用域，使同一 Host 中的不同 Agent 获得不同工具、提示词和策略。查询能力时遵循 Agent Scope、Preset Scope、Global Scope 的就近关系。
这让“创建一个专用 Agent”从复制一套运行时，变成挂载一组有边界的插件。多个 Agent 可以共享底层模型或执行 Provider，同时保留各自的模型可见能力。
5. 用 Bundle 和 Profile 管理分发
运行时 Plugin、分发 Bundle 和部署 Profile 是三个不同概念。Plugin 定义行为；Bundle 把代码与 Cordis 配置补丁放在一起；Profile 决定一次部署依赖哪些 Bundle，并叠加自己的配置。
DSH 的配置依次叠加 Bundle Patch、Profile Patch、用户目录 Patch 和命令行 Patch。Patch 决定最终配置从哪里来，inject 依赖图决定插件何时激活，事件注册顺序决定同一事件链怎样执行。这三种顺序不能混为一谈。
外部能力采用可安装的 Profile Bundle 分发。安装 Git 依赖可能执行构建脚本，因此来源固定、提交锁定和构建授权也是插件使用流程的一部分。
6. Host 和浏览器都可以插件化
带有客户端入口的包可以同时提供 Host 插件与浏览器插件。Host 收集启用模块，浏览器端 Cordis Loader 再根据依赖激活 UI 服务和 Slot。会话事实因此可以由后端插件产生，再由独立的前端插件负责呈现。
这意味着插件化不止发生在工具调用层。一个完整能力可以同时包含 Provider、模型工具、会话事件和界面投影，并分别在正确的运行时中管理生命周期。
三、社区影响力讨论和展望
作为内测用户，我为什么看好这套插件系统
DSH 刚刚发布。作为内测用户，我对它最明确的判断是：DSH 把插件化放在了 Agent Harness 的核心，这也是它真正有价值的地方。模型、工具、会话、执行策略、Agent 组合和客户端界面共同组成一张可以持续重组的能力图。
内测期间，我已经看到围绕这套架构出现插件模板、系统教程、开发指南和真实问题汇总。这些材料让开发者开始用同一套语言讨论依赖、生命周期、模型可见内容和部署组合，也为社区协作搭起了共享的工程语义。
插件化已经是 Agent 产品的共同方向，但不同项目所说的“插件”并不处在同一层。MCP 标准化 Host 与外部工具、资源和 Prompt 的连接；LangChain Middleware 提供模型和工具调用前后的执行钩子；Codex Plugins 把 Skills、Apps 和工作流能力打包给用户和组织安装。DSH 继续向 Harness 内部推进，把会话、Provider、执行策略、Agent 组合和客户端界面也纳入同一套插件生命周期。
这些扩展方式位于不同层次，并在实际系统中协作：MCP 负责跨进程能力交换，Skill 承载可复用的工作方法，DSH Plugin 负责 Host 内的运行时能力，Bundle 和 Profile 负责分发与部署组合。Agent 生态会由这些层次共同构成。
它改变的是社区贡献的基本单位
第一，社区贡献可以从“维护一个 Harness 分叉”变成“实现一项完整能力”。模型 Provider、执行环境、压缩策略、审批机制或 UI 投影都能独立演化，贡献者不必先改写整个 Agent Loop。
第二，社区复用的对象已经从一段代码扩展为一组可运行的约束。一个完整插件同时声明依赖、配置、生命周期、模型可见内容和验证方式。别人拿到的是一项可以直接进入现有运行时的能力。
第三，Agent 产品的差异会更多地表现为组合。同一组底层能力经过不同 Profile、Preset 和 Scope，可以形成面向终端、研究、自动化或垂直业务的 Agent。团队可以直接比较两种能力组合，不必维护两套不断分叉的产品。
第四，Agent 自修改有了具体的工程载体。模型可以为当前任务临时挂载插件，增加工具、提示词或监听器；验证有效后，再由开发者把它整理成带配置、测试和来源审查的持久 Bundle。运行时试验因此可以自然地沉淀为可分发能力。
一个插件社区真正比拼什么
一个插件社区真正比拼的是工程质量。我认为 DSH 接下来最需要建立五套机制：
- 兼容性契约：明确插件支持的 DSH、Cordis 和能力版本，并在升级失败时给出可理解的诊断。
- 可信分发：让用户看清安装来源、构建脚本、依赖和发布者，区分 Host 中的可信代码与受限外部服务。
- 质量证据：同时通过单元测试与真实 Profile 验证插件能够加载、卸载，并保持模型输入和会话记录可以回放。
- 组合可解释性：让用户知道多个插件同时修改 Prompt、Tool Chain 或停止策略时，谁先执行、什么实际生效、冲突发生在哪里。
- 维护责任：明确核心团队、Provider 作者和社区贡献者各自承担哪些兼容性与安全责任。
可逆生命周期和显式依赖已经提供了工程基础。版本治理、供应链安全、评测和文档决定这套基础最终能否承载长期协作。插件生态的壁垒体现在陌生能力加入以后，整个系统是否仍然可组合、可解释、可维护。
从插件目录走向能力网络
我期待 DSH 最终形成一张能力网络。
第一步是建立少量可信样板：统一的 Bundle 模板、真实 Loader 测试、清晰的模型体验说明、固定来源的安装方式，以及能够解释最终配置的工具。社区需要先形成“什么叫完整插件”的共同标准。
接下来，Provider、工具、策略和 UI 贡献会围绕不同场景组成 Profile。人们会选择一组经过验证、可以共同运行的 Agent 能力。
再往后，Agent 可以根据任务生成临时插件，人类和自动评测再决定哪些能力值得沉淀、分享和复用。插件系统到那时既是开发者扩展软件的接口，也会成为 Agent 组织自身能力的一种基本形式。
所以我判断 DSH 插件系统最重要的社区价值，是把 Agent 开发从“修改一套固定产品”变成“组合一组完整能力”。衡量它是否成功，需要看一个新能力能否独立加入、可靠组合、干净退出，能否解释它给模型看了什么，又能否在失败时指出责任所在。
DSH 正在构建一张能够持续重组的 Agent 能力图。这也是我认为它最值得关注的地方。