什么是 DeepSeek Harness 插件？

一句话定义

可以把插件理解成 agent 中一个可替换的小部件。DSH 会把包加载到指定 profile，读取包里的 dsh.bundle 清单，再把它声明的能力交给正在运行的 Harness。包负责实现能力，profile 负责决定是否启用。

这个边界很重要：更换某个能力时，你的提示词、profile 设置和其他插件都能保持不变。你可以尝试新的记忆后端、模型适配器或界面，然后从同一个 profile 移除包来回滚。

插件不只是复制进配置文件的一段提示词。它有包名、版本、入口和启用边界，DSH 可以在启动时检查这些信息。这样你能知道安装的是哪个版本、哪个 profile 负责它，以及它是否真的完成加载。

插件可以扩展什么

插件并不只负责一种集成。更实用的问题是：agent loop 的哪一部分需要新的边界？

把能力对应到它必须可用的时机：模型适配器属于 Provider 选择，记忆后端属于上下文检索，通知钩子属于事件边界。这样的映射能让插件保持单一职责，也更容易审查权限。

• 模型与 Provider 连接模型 Provider、路由器或本地推理运行时，同时保持 agent 使用的 API 稳定。
• 工具与工作流 增加 agent 可以发现和调用的工具、命令或可重复工作流，并明确所需权限。
• 记忆与上下文 保存跨会话笔记、检索相关上下文，或用更适合业务数据的后端替换默认存储。
• 界面与可观测性 增加 Web 界面、通知、追踪或生命周期钩子，而不改动核心 Harness 源码。

用 profile 控制影响范围

DSH profile 是最小的隔离单元。把实验性插件安装到开发 profile，再启动同一个 profile 来评估它。默认 profile 不会被改变；第二个 profile 也可以使用同一个包的另一个版本。

如果插件会改变行为，建议使用有描述性的 profile 名称，例如 `memory-local` 和 `memory-cloud`。这样运行命令本身就能说明当前配置，回滚也更容易预测。

profile 也能帮助定位问题。如果插件在 `memory-local` 有效、在 `default` 无效，差异通常是配置，而不是每个任务内部都藏着一个未知问题。把 profile 定义、包版本和所需环境变量放在一起，其他人才能复现同一轮测试。

DSH 如何识别插件

dsh.bundle 清单是包和 Harness 之间的契约。它告诉 DSH 包提供了什么能力，以及应该加载哪个入口。包可以发布在 npm 或 GitHub，但只有清单有效、声明的入口可以加载时，它才是一个可用的 DSH 插件。

这也是目录把 bundle 验证和流行度分开显示的原因。Stars 和下载量代表关注度；bundle 检测代表 DSH 能否识别这个扩展。安装前应该同时查看这两类信号。

如果清单缺失或格式错误，问题通常会在 agent 开始工作前暴露：包可能被忽略、在启动时失败，或者一直不能在 profile 中使用。先把它当作打包问题处理，检查清单和入口，不要先改提示词或模型设置。

插件的生命周期

大多数插件都遵循四步：发现包、安装到 profile、重启 DSH 让 profile 重新加载、检查启动日志或界面完成验证。把步骤拆开后，你能区分包本身的问题、profile 问题和启动问题。

升级也遵循同一个边界。需要可复现时固定已知可用的版本；升级前阅读变更说明；在新版本通过真实工作流验证前保留旧版本。

对团队而言，这也是一份简短的变更记录：写下 profile、包来源、版本、权限和一次验证结果。如果升级改变了延迟或工具输出，你就能比较新旧行为，而不用重新搭建整个 agent 环境。

• 发现 阅读包说明、源代码仓库、许可证和近期活动。
• 安装 把包添加到你实际要启动的 profile。
• 验证 重启 DSH，确认插件显示为已激活。
• 观察 运行真实工作流，关注权限、延迟和兼容性问题。

信任与权限

插件会作为 agent 环境的一部分运行，因此应当像审查依赖一样审查它，而不是把它当成一段普通提示词。检查源代码、安装脚本、请求的凭据、网络访问和文件访问。即使包很小，只要它在启动阶段执行钩子，影响范围也可能很大。

优先选择有清晰仓库、明确许可证、持续维护且职责单一的包。从 GitHub 安装时，如果需要可复现，就固定到具体 commit；没有检查过的包不要轻易允许构建脚本。

只授予完成能力所需的最小权限。记忆插件可能需要存储路径，但不需要 shell；Provider 适配器可能需要网络凭据，但不需要访问整个 home 目录。如果请求的访问范围明显超过工作需要，先暂停并寻找更窄的替代方案。

如何选择第一个插件

从当前工作流里一个真实、具体的问题开始。只改变记忆能力的插件比同时改变模型、工具和界面的包更容易评估。安装前先定义一个成功标准，例如检索质量、响应延迟，或某个缺失工具是否可用。

插件通过标准后，记录 profile、版本和权限。这个简短记录能把一次实验变成团队可以复用的配置。

目录可以缩小第一次搜索范围，但不能代替你自己的审查。把摘要、bundle 状态、许可证和近期活动当作信号，再阅读仓库，并用预先写下的成功标准运行一次。小而可回滚的实验，比难以解释的大范围安装更有价值。