DeepSeek Harness 插件中文指南：安装、激活与排错
DeepSeek Harness 使用插件组成应用能力，Profile 的配置层与 Bundle 共同决定启用哪些功能。安装一个 npm 依赖，不等于它已经加入 Bundle 层，也不等于新 Agent 已启用对应工具。先检查插件包身份、清单与代码，再选择目标 Profile 安装；通过依赖列表、启动诊断和一个最小工具调用逐项确认结果。
分享仅包含公开链接，不携带本地进度或私人配置。
先理解插件、Bundle 与 Profile
Cordis 插件提供能力；声明 dsh.bundle 元数据的安装包可以贡献配置 patch 层；Profile 决定这次启动使用的应用组合。一个没有 Bundle 声明的普通依赖可以安装成功，但不会因此自动加入 Profile 的层栈。不要根据 npm 安装成功提示直接判断工具已经可用。
在目标 Profile 管理依赖
官方 dsh plugin --profile <name> <args...> 在对应 Profile 目录转交 pnpm；pnpm 需要位于 PATH。明确目标 Profile 后再执行安装、移除或依赖检查。相对本地路径先相对调用目录解析，不要把项目目录与 Profile 目录混为一谈。
- 记录插件的正式包名、精确版本或源码 commit。
- 使用干净 Profile 验证单个插件，再组合其他插件。
- 管理命令成功后检查磁盘上的清单和 Bundle 声明。
dsh plugin --profile web list --depth 0预期检查： pnpm 应列出 web Profile 的直接依赖；命令报错时先核对 pnpm 与 Profile。列表中出现包，只证明它作为依赖存在，不能证明对应工具已经激活。
区分 Bundle 变更与普通配置热重载
安装、移除或更新 Bundle 改变磁盘上的 Profile 清单。已经运行的 Profile 保留本次启动的 Bundle 集合，按官方参考应重启该 Profile。普通 cordis.patch.yml 编辑只在对应 HMR 行启用时热重载，未启用时仍需重启；某些子代理工具还需要在 Preset 中单独启用。
构建被拦截时先读脚本
源码型 Git 插件可能依靠 prepare 构建；pnpm 的 allowBuilds 提示只说明脚本被策略拦截。检查脚本后，按它实际打印的包键对该 Profile 授予构建许可，再重试。不要复制其他插件的键，也不要为了清除错误开放所有构建脚本。
用一次最小工具调用验收
重启目标 Profile 并确认配置后，创建新 Agent 或会话检查工具。若激活失败，保留原始错误和完整的插件依赖链；先移除最近新增的 Bundle，恢复上次可运行组合。分享日志前查看内容，启动报告中的原始插件错误可能包含敏感值。
常见问题
插件安装成功，为什么界面还没有工具？
依次检查是否装入正确 Profile、包是否声明 Bundle、Profile 是否重启，以及新 Agent 的 Preset 是否启用了工具。依赖存在只是第一项证据。
社区插件能否当作官方插件？
不能。包的来源、维护者、代码和所需权限需要分别审查。本站的官方资料链接与社区报告分组展示，不因仓库名称相近而视为官方。
改配置和更新 Bundle 都要重启吗？
官方 CLI 参考区分这两种变更：普通 patch 编辑在 HMR 启用时热重载，未启用需重启；改变 Bundle 成员后，运行中的 Profile 保留本次启动的集合，需要重启。
官方资料
使用新版本前，打开以下固定版本或注明核验日期的资料。