前言¶

用 DSH 跑 agent 的人大概都遇到过一类问题：模型信誓旦旦地说「我记得这部分上下文」「计划已经定好了」「benchmark 通过了」「这次 release 没问题」，但你找不到它得出结论的依据。它只是断言，没有证据。

现有的做法通常是在系统提示里加几句「请谨慎、请说明依据」，或者为每个场景单独装一个 skill 包。前者约束很弱，后者让同一套纪律散落在五个包里，各自要装一次、各自在索引里占一个位置。

dsh-ops-kit 是维护者 YaoleWu 提交到 SkillHub 社区目录的插件，分类为工作流，目前 2 个 star。它把纪律压成一句话：在 agent 说「我记得」「计划可行」「基准通过」「发布安全」之前，它应该能指出证据。 五个只读 skill pack 共享这套原则，同时附带一个运行时 doctor，用来检查官方 PTY prompt handshake 的兼容性。

定位¶

一句话：dsh-ops-kit 是 DeepSeek Harness 的只读能力包，把记忆检索、编排规划、agent loop 规则、基准结果门禁和发布检查清单打包在一起，给 agent 提供「计划、检查和证据词汇」，而不替它执行有副作用的操作。

它明确不做这些事：不悄悄建 issue、不调远程 API、不启动 benchmark、不改仓库、不读凭据。所有带副作用的动作都留在包外，成为一次显式、可审查的操作。

顺带一提「只读」的判断依据：清单里的工具一侧只有 Git-first memory 和 repository audit 标注为 Read-only，其余标注为 None（无副作用）；包本身不下载凭据、不注入运行输出，也不包含机器相关的配置。

核心能力¶

插件注册了八个工具，按能力包划分如下。

Capability pack                    工具                         作用                                   副作用
Capability index                   dsh_ops_capability_catalog   列出包含的能力包                         无
Evidence-based orchestration       dsh_ops_workflow_plan        产出 scope → baseline → context →
                                                                    execute → verify → handoff 计划      无
Skill reference                    dsh_ops_skill_read           读取包内完整的 skill 定义                无
Git-first memory                   dsh_ops_memory_search        在限定的本地 Markdown / 代码根目录下
                                                                    检索先前上下文，带来源出处            只读
Repository audit                   dsh_ops_repository_audit     审计 Git 干净度、未跟踪文件、
                                                                    凭据路径卫生                        只读
Release hygiene                    dsh_ops_release_checklist    产出完整的 DSH 插件发布检查清单         无
Release verification               dsh_ops_plugin_doctor        按清单逐项核查插件仓库的可安装性与
                                                                    可发布性                            只读
Runtime health                     dsh_ops_runtime_doctor       检查官方 terminal / persistent-bash
                                                                    prompt 兼容性                       只读

三个设计上的取舍值得单独说。

第一，编排规则不做成独立工具。leader-only dispatch、共享 worktree 的协调、运行时归属、清理证据这几项 agent loop 规则，以及基准门禁的 manifest、precheck、产物清单、结果完整性检查，都内嵌在 workflow-plan 和 release-checklist 两个 skill 里。

第二，清单和核查是分开的两个工具。dsh_ops_release_checklist 说「发布需要什么」，dsh_ops_plugin_doctor 用它去量「实际上做到了没有」。README 里的解释是，一条没人核查的清单，就是一个启动套件打印 SKIPPED 然后 exit 0、CI 变绿而集成检查根本没跑的坑，也是一个插件长期停在 "private": true、根本无法发布的问题。

第三，doctor 只检查不修改。它核对 dsh.bundle 加 cordis.patch.yml 能否安装、patch 行与包名是否对应、private / files / exports 是否可发布、@deepseek-ai/* 是否保持为 peer、以及启动套件是否打印 SKIPPED 后 exit 0。它自己从不编辑 node_modules。

安装与启用¶

安装走 registry，不需要构建步骤，也不需要 allowBuilds 审批。

dsh plugin --profile <profile> add dsh-ops-kit

如果希望手工编辑 profile manifest，等价写法如下。

// ~/.dsh/profiles/<profile>/package.json
{
  "dependencies": {
    "dsh-ops-kit": "^0.1.0"
  },
  "dsh": {
    "profile": {
      "bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "dsh-ops-kit"]
    }
  }
}

改完之后对该 profile 重新安装依赖并重启。

包的版本号是 0.1.1，许可证为 MIT，Node 要求 >=22.19.0，@deepseek-ai/cordis、@deepseek-ai/dsh-skill、@deepseek-ai/dsh-tools 声明为 peer dependencies。包内还带了一个受保护的 dsh-terminal-hotfix 命令，只在精确布局匹配后修补官方 rc.6 的编译入口，改动前生成带时间戳的备份，改完验证 prompt handshake：

dsh-terminal-hotfix --check
dsh-terminal-hotfix --apply

应用后需要重启 DSH。该命令不会被插件加载器自动执行，也不会静默改动依赖。

配置本地检索根目录¶

dsh_ops_memory_search 和 dsh_ops_repository_audit 需要限定可检查的目录。根目录要尽量窄，且绝不指向凭据目录。

# example overlay; adapt to the profile's configuration format
- id: dsh-ops-kit
  config:
    roots:
      - /workspace/project
      - /workspace/memory
    maxFiles: 120
    maxBytesPerFile: 160000

如果不配置 roots，工具默认使用 DSH 进程的当前工作目录。凭据类路径和常见的 run/secret 目录会被拒绝或跳过。

典型用法与验证¶

装好之后的验证链路如下，按这个顺序走一遍。

pnpm install --offline --ignore-scripts
pnpm build
pnpm typecheck
pnpm test

在真实 profile 里装好后，README 建议逐项确认：DSH endpoint 返回 HTTP 200、profile 重启后仍在运行、包内 skill 被列出、dsh_ops_capability_catalog 返回全部能力包、dsh_ops_runtime_doctor 状态健康。

如果 doctor 报告 terminal-prompt-mismatch，先用 dsh-terminal-hotfix --check 确认，再决定是否应用可回滚的修补。

适用场景与注意事项¶

适合这类人：已经在用 DSH 跑多步研究、多 agent 协作、基准测试或插件发布流程，并且希望 agent 在关键节点停下来给证据而不是直接给结论。插件里的方案偏保守，如果你需要的是激进自动执行，它不合适。

三点必须说清楚。

第一，插件以当前 DSH 进程的权限运行。安装前先自己审一遍源码和许可证。许可证是 MIT，README 声明这是从通用工程实践提炼的独立集成层，不是任何内部仓库的副本，包内不含凭据、私有数据、运行输出或机器相关配置。

第二，README 内嵌的 package.json 片段里，repository / bugs / homepage 三个字段写的是 LeslieWylie/dsh-ops-kit，与社区目录页记录的维护者 YaoleWu 不一致。files 字段里列出的 README.zh.md 也没有在本 README 导航中明确给出链接。这类字段与仓库归属的出入，装之前应以实际仓库为准。

第三，SkillHub 是独立站点，与 DeepSeek / 幻方没有官方从属关系，不是官方应用商店。上面的 star 数和分类来自该目录页的记录。

小结¶

dsh-ops-kit 的价值不在多，在于把同一条纪律——结论要有证据——摊到记忆、编排、benchmark、发布四个环节里，并且让 agent 的每一步都落在可审查的只读检查上。如果你在 DSH 里跑的流程已经有「看起来对但没人验证」的风险，可以从 dsh_ops_capability_catalog 和 dsh_ops_runtime_doctor 两个工具开始，它们不带副作用，能先告诉你这个包装了什么、运行时是否健康。

目录页：https://www.skillhub.cn/plugins/YaoleWu/dsh-ops-kit
仓库：https://github.com/YaoleWu/dsh-ops-kit