DeepSeek Harness 插件管理机制
DeepSeek Harness 插件管理机制：运行时安装、启停与卸载
- 作者
- DeepSeekAgent.io 编辑部
- 发布
- 更新
DeepSeek Harness v0.1.6-alpha.2 把 Plugin Manager 接入基础 Profile，并提供 Plugins 页面与 Agent 可调用的 plugin_manager 工具。插件由此获得一条完整的运行时管理链：查看当前配置、安装 Bundle、启用或停用条目、卸载 Bundle，并把结果持久化到当前 Profile。
这套机制让插件从手工编辑配置文件的扩展项，变成 DSH 工作区内可以发现和管理的长期能力。对于插件作者，安装成功只完成了一半；加载、实时停用、重新启用和最终卸载都成为必须验证的生命周期。
Plugin Manager 在架构中的位置
alpha.2 的 Base Composition 同时挂载两个条目：
plugin-manager → @deepseek-ai/dsh-plugin-manager
tool-plugin-manager → @deepseek-ai/dsh-plugin-manager/tools
Base Composition 由 Web、Headless、SDK 和 ACP Profile 共享。plugin-manager 提供管理服务，tool-plugin-manager 把受控操作注册为模型可见工具。Web 的 Plugins 页面与 Agent 工具最终操作同一份 Profile 状态，因此界面里启停的插件和 Agent 执行的管理动作不会形成两套配置。
六个管理动作
plugin_manager 使用一个 action 字段区分操作：
list_plugins
list_bundles
set_plugin
set_bundle
install_bundle
remove_bundle
其中 Plugin 和 Bundle 是两个层级。Plugin 是 Profile 中的具体加载条目；Bundle 是可安装、可整体启停的插件集合。管理时应先列出条目，取得准确 ID 或包名，再执行修改。
查询
list_plugins 与 list_bundles 支持 offset 和 limit，单次最多返回 100 条。分页设计说明插件目录可以扩展到较大规模，管理界面和 Agent 都不应假设一次响应会包含完整清单。
启停
set_plugin 需要具体 Plugin Entry ID，set_bundle 使用 Bundle 名称；两者都要求明确的 enabled。实时 Profile 会立即应用变化，启动型 Profile 需要重启后进入新状态。
安装与移除
install_bundle 接收包规格，可以在安装时决定是否启用。remove_bundle 删除已安装 Bundle。两项操作都会修改 Profile 的长期状态，影响以后创建的 Session，也可能影响当前正在运行的 Session。
为什么每次操作都需要高权限
官方工具在执行动作前统一请求 danger-full-access 或逐次审批。原因写在工具本身的权限说明里：Profile 修改会跨 Session 持久化，安装的 Host 代码运行在工作区沙箱之外。
安全边界可以拆成四层：
| 层级 | 需要确认的内容 |
|---|---|
| 包来源 | 包名、版本、发布者与源码是否对应 |
| 安装阶段 | 是否运行构建脚本，脚本会访问什么 |
| 运行阶段 | 注册了哪些 Tool、路由、事件和后台任务 |
| 持久化 | 修改了哪个 Profile，其他 Session 是否会继承 |
安装遇到待批准的构建脚本时，工具通过 pendingBuilds 返回脚本所属包。用户明确批准后，再把对应名称放入 approvedBuilds。审批对象应与当前安装结果一致，避免把宽泛许可复用到后来出现的其他依赖。
实时启停怎样工作
alpha.2 把插件依赖调整为运行时解析，并允许 Plugin Manager 执行运行时卸载。一个实时 Profile 中的典型状态变化是：
已安装但停用
→ 解析依赖
→ 激活插件并注册能力
→ 正常运行
→ 停止新调用
→ 释放资源并解除注册
→ 已安装但停用
“停用”需要完成两个方向的对称操作。加载时创建的资源，都应在卸载时找到对应的释放动作。
| 加载动作 | 卸载时对应动作 |
|---|---|
| 注册 Tool 或命令 | 注销 Tool 或命令 |
| 添加事件监听 | 移除监听器 |
| 启动定时器 | 清除定时器 |
| 建立文件监听 | 关闭 Watcher |
| 打开端口或连接 | 关闭 Server、Socket 或 Client |
| 创建临时文件 | 清理可安全删除的临时资源 |
重新启用是最容易暴露问题的测试：如果一个事件触发两次、Tool 出现重复名称、后台任务数量持续增加，通常说明上一次卸载没有完成。
Plugin、Bundle 与 Profile 的关系
可以把三者理解成不同的管理尺度：
- Plugin：一个具体能力或服务实例，例如一个 Tool Provider；
- Bundle：一组可以共同安装和分发的 Plugin；
- Profile：最终组合，决定当前 DSH 运行环境加载哪些 Bundle 与 Plugin。
插件市场适合展示 Bundle 的用途、版本、来源和安装入口；进入 DSH 后，Plugin Manager 负责把 Bundle 落到具体 Profile。用户看到的是一个产品条目，运行时管理的则是它展开后的多个插件实例。
Creator 模式发生了什么变化
alpha.2 的 Creator 模式移除原 Cordis 动态定义与执行工具，改为通过 Plugin Manager 安装持久化插件。能力生成流程因此变为：
描述需要的能力
→ 生成或选择 Bundle
→ 审查 manifest、依赖与脚本
→ 安装到 Profile
→ 启用并验证
→ 后续 Session 继续使用
这条路径要求生成结果具备完整的包结构和生命周期。一次会话里能运行的代码，不一定已经满足可安装插件的标准。Creator 产出的 Bundle 至少需要明确入口、配置 Schema、依赖、权限、加载失败信息和卸载行为。
插件作者的回归测试
1. 冷启动
在没有缓存和旧实例的 Profile 中安装，确认依赖解析、默认配置和首次激活。
2. 实时停用
保持 Session 打开并停用插件，确认新调用被阻止，现有任务得到可解释的结束状态，后台资源全部释放。
3. 再次启用
在同一进程中重新启用，确认 Tool、命令和事件只注册一次。
4. 配置变更
修改关键配置并应用，检查需要热更新的状态是否生效，需要重启的状态是否给出明确提示。
5. 卸载与重装
移除 Bundle 后确认 Profile 没有悬空引用，再安装同版本与新版本，分别检查残留状态和迁移逻辑。
6. 多 Session
同时打开两个 Session，在其中一个 Session 触发启停，确认另一个 Session 得到一致且可预测的状态。
对插件市场的意义
插件市场过去主要解决“发现什么插件”。Plugin Manager 补上“怎样把插件安全地装进当前 Profile，并在运行时管理”。市场页面可以进一步提供以下结构化信息：
- 精确包名与当前兼容的 DSH 版本；
- Bundle 展开后包含的 Plugin；
- 配置项与默认权限；
- 是否包含安装或构建脚本；
- 支持实时卸载，或需要重启；
- 卸载后保留哪些数据；
- 源码、发布记录和维护者。
这些信息可以让用户在点击安装前理解能力边界，也能让 DSH 的审批窗口显示更具体的上下文。
相关阅读
- DeepSeek Harness v0.1.6-alpha.2 更新
- DeepSeek Harness：Agent Preset 与 Plugin 的区别
- DeepSeek Harness 安全指南
- DeepSeek Harness 完整安装与使用教程
常见问题
Plugins 页面和 plugin_manager 工具会修改同一份配置吗？
两者都通过 Plugin Manager 服务操作当前 Profile。修改会影响该 Profile 的其他 Session。
停用 Bundle 和卸载 Bundle 有什么区别？
停用保留安装记录与配置，之后可以重新启用；卸载移除 Bundle，重装时需要重新执行安装和必要的迁移。
安装插件为什么可能执行构建脚本？
部分 npm 依赖在安装阶段需要生成原生模块或构建产物。Plugin Manager 会列出待批准脚本，获得明确批准后才继续对应步骤。