用 dsh-plans 给 DeepSeek Harness 加上人机协同规划

DeepSeek Harness 插件 DeepSeek DSH dsh-plans 界面增强 人机协同 2026-08-17 102 阅读

前言

DeepSeek Harness（CLI 名为 dsh）是 DeepSeek AI 开源的智能体运行时，设计原则是「一切皆插件」：模型、工具、技能、会话和界面都可以用插件拼起来。官方仓库目前仍标为 developer preview，兼容性可能随时变化。

社区里还有一份独立的插件目录 deepseek-harness-plugin.com，用来检索第三方插件。它和 DeepSeek / 幻方没有官方从属关系，不是官方应用商店。

智能体改仓库时，常见情况是：一句话需求直接动手，改到一半才发现范围不对、验收标准含糊，或者 reviewer 意见来得太晚。dsh-plans 针对的就是这件事：先把粗略改动整理成工作区里可追踪的 Markdown 方案，经过 reviewer / criticizer 子代理打磨，再由人显式交接后进入执行。

本文按社区目录详情页、GitHub 仓库 README、preset.yml / agent.cordis.yml 以及捆绑技能文档核对后整理。

这是什么

dsh-plans 是 Optim-Agent 维护的 DeepSeek Harness 人机协同规划预设（agent preset），许可证为 MIT。社区目录把它归在「界面增强」分类。截至 2026-08-17，GitHub 仓库显示 22 颗星（目录页当时列出 12，以仓库页面为准）。

仓库说明写明：它移植自 prime-plans 的规划流程。同一维护者另有面向 Claude / Codex 的 optim-plans，五个技能名称与这里一一对应；dsh-plans 则把这套流程接到 DSH 原生机制上——ask_user_question、子代理、goal 循环和捆绑技能——不另做一套执行引擎。

它解决的问题可以概括成三步：

  1. 只读查看目标仓库，把改动需求写成 ./dsh-plans/ 下带稳定 ID 和 Verifier Checklist 的方案。
  2. 用 reviewer / criticizer 子代理多轮打磨；每一轮都要先问人（或 Auto-complete）选不选这个角色。
  3. 方案被接受后，再问一次没有自动完成选项的交接题：现在就作为 DSH goal 执行，还是只停在规划。

预设会关掉 DSH 内置的 plan mode。agent.cordis.yml 写明：内置 plan mode 的「单方案、禁止写入」循环，和这里要在规划阶段写出 PLAN_vN.md 的做法冲突，所以改由预设自己的交接问题来把门。

核心功能

一次运行怎么走

README 把一次完整流程写成六步：

  1. 智能体只读查看目标仓库，然后询问该工作区的语言设置（每个工作区问一次，之后沿用）。
  2. 规划问题一次只问一个，选项顺序固定：推荐项在前，Other 倒数第二，Auto-complete 最后。问题和答案写入 DECISIONS.md 和运行账本。
  3. 必须先做范围确认，才能写出第一稿 dsh-plans/YYYY-MM-DD-topic/PLAN_v1.md。方案要有稳定 ID、证据，以及 ## Verifier Checklist。
  4. 每个方案版本之后都要问打磨方式。reviewer / criticizer 不会在没人选的情况下自行启动。这两个角色走预设自己的 run_plan_subagent 工具：构造上只读，模型在该角色第一次真正使用时选定。
  5. 打磨收敛后，问一次没有 Auto-complete 的执行交接：现在作为 DSH goal 执行，或规划到此结束。
  6. 批准后，执行以 DSH goal 形式运行，目标指向被接受的方案及其 Verifier Checklist。实现遵循仓库所说的 ponytail 简化纪律和 MVP 最小测试集；只有清单每一项都通过，才调用 update_goal complete。

五份捆绑技能

智能体按请求选择技能，而不是每次都走同一套深度：

技能 适用情况（仓库原文）
create-a-small-plan 小范围仓库改动，1～3 个规划问题。建议打磨：一轮 criticizer，再接受执行。
create-a-plan 范围较大或有风险，5～10 个规划问题，并做联网调研。建议：一轮 reviewer，再一轮 criticizer。
create-a-big-plan 开放或高风险，10 个及以上规划问题，并做联网调研。建议：三个并行 reviewer 由主代理汇总，再一轮 criticizer。
diagnose-before-plan bug、CI 失败、回归、事故、RCA 或行为异常，需要先诊断再规划。
reference-before-plan 下载的项目、文章、论文或文档必须先分析，规划选择才安全。

diagnose-before-plan 会先根据仓库、日志、测试和用户提供的现象做 RCA（最多 5 Whys，证据不够就标 unknown，不编造原因），再问要不要进入修 bug 的规划。选择继续后才会写 PROBLEM_ANALYSIS.md。

reference-before-plan 要求在写 PLAN_v1.md 之前下载至少 3 份可信参考，大文件默认放在仓库外的 ~/.cache/dsh-plans/refs/，并写入 REF_ANALYSIS.md。每一份参考都要先问至少 3 个采纳问题，答案记下来之后，其中的想法才能进方案。

工作区产物

对外可提交的文件留在工作区：

dsh-plans/YYYY-MM-DD-topic/
  DECISIONS.md
  PROBLEM_ANALYSIS.md     # 仅 diagnose-before-plan
  REF_ANALYSIS.md         # 仅 reference-before-plan
  PLAN_v1.md
  PLAN_v1_reviewer_comments.md
  PLAN_v2.md

机器状态放在产物旁边，默认不提交（helper 会写入 .gitignore 中的 .state/）：

dsh-plans/.state/
  config.json             # 语言 + 各角色模型
  active.json
  runs/<run-id>/

每个工作区会记住语言；reviewer / criticizer / executor 的模型在该角色第一次实际使用时询问一次并持久化。executor 就是当前会话的 goal 循环，确认过的模型即会话模型。

安全边界

README 把支持范围限定为：规划纪律、可持久状态、显式交接。交接之前，工作流只写 dsh-plans/.state/ 和 dsh-plans/ 下的产物，不动目标源码、配置或测试。

run_plan_subagent 会拒绝子代理使用写入、goal、向用户提问和再委派等工具，reviewer / criticizer 只能通过最终输出回报。Auto-complete 可以回答规划和打磨问题，但不能批准 goal 执行、安装、部署、合并、推送、使用凭据，或任何改变外部状态的操作。

安装与启用

社区目录页给出的安装命令是：

dsh plugin add github:Optim-Agent/dsh-plans

需要可复现安装时，目录页建议固定 commit 哈希：

dsh plugin add github:Optim-Agent/dsh-plans#commit

把 #commit 换成具体哈希即可。目录页同时提醒：插件以当前 dsh 进程的权限运行，安装时可能执行代码。

仓库本身没有 package.json。README 把安装写成克隆到用户预设目录，由 roster 扫描后出现在预设选择器里：

mkdir -p ~/.dsh/.agent-presets
git clone https://github.com/Optim-Agent/dsh-plans.git ~/.dsh/.agent-presets/dsh-plans

roster 每次读取都会重新扫描根目录，新预设会立刻出现。为新会话选中 dsh-plans，不必重启整个 dsh 服务。更新已有安装：

git -C ~/.dsh/.agent-presets/dsh-plans pull

两种写法来源不同：前者是目录页原文，后者是仓库 README。按自己使用的 dsh 版本核对后再执行，不要混用后想当然地认为效果相同。

Code Mode 前提

dsh-plans 通过 DSH Code Mode（run_code 加上生成的 TypeScript SDK）呈现全部工具。README 说明，这样可以避开某些模型会填满每一个可选 Bash 参数的函数 schema 问题，同时保留原来的 Bash 实现、沙箱升级检查、审批、后台任务和取消行为。

宿主必须提供 codeRuntime。DSH Web profile 已经加载 dsh-code-runtime-worker-thread。没有 code runtime 的 profile 在挂载预设时会明确失败，而不会退回不兼容的 Native 工具呈现。工具呈现是在组合智能体时固定的，更新后需要新开一个 dsh-plans 会话；一般不必重启整个 DSH 服务，已有会话也不会热迁移。

典型用法

预设选好之后，在任意目录里可以直接说：

Create a plan for <your change>

把 <your change> 换成具体改动即可，例如给某个模块加接口、修一条 CI 失败、或评估一次依赖升级。智能体会按请求挑选上面五份技能之一，先只读查看仓库，再按该技能的问题数量和打磨轮次推进。

一次中等规模改动（对应 create-a-plan）大致会经过：

  1. 工作区语言（若尚未记录）。
  2. 5～10 个规划问题，每次一个选项题。
  3. 最终范围确认，写出 PLAN_v1.md。
  4. 默认一轮 reviewer，再一轮 criticizer；每轮前后都要再问打磨方式。
  5. 接受方案后，问「现在作为 DSH goal 执行」还是「规划到此结束」。

大方案的 reviewer 轮次会在同一条助手消息里并发三个只读 reviewer，主代理去重后写入 PLAN_vN_reviewer_comments.md，每轮最多向用户展示 5 条高优先级意见。criticizer 每轮最多 5 个追问；改方案前要把这些问题的答案记下来。

仓库还提供自检命令（不改变目标仓库）：

node --test scripts/test_plan_subagents.js
python3 scripts/validate_preset.py
python3 scripts/dsh_plans_state.py init --workdir /tmp/dsh-plans-smoke

适用场景与注意事项

比较适合：

  • 多文件、跨模块、涉及外部 API 或依赖升级，需要先把范围和验收标准写清楚的改动。
  • 先要做 RCA 或先读外部资料，再决定怎么改的任务。
  • 希望方案、决策和打磨意见都落在仓库里、可以一起提交审查的团队。

不太适合、或需要改用别的路径：

  • 用户明确说不要规划、只要直接改。技能文档把这类请求排除在外。
  • 纯事实问答、一次性命令、没有仓库改动的解释类问题。
  • 宿主 profile 没有 codeRuntime：预设会挂载失败。
  • 指望它替换 DSH 内置 plan mode 的「禁止写文件」行为：这个预设在规划阶段会写 dsh-plans/ 产物，并关掉内置 plan mode。

安装和使用时需要记住：

  • 插件 / 预设以当前 dsh 进程的权限运行，安装时可能执行代码。安装前应检查源代码仓库和许可证（本仓库为 MIT）。
  • 社区目录不是 DeepSeek 官方商店；星标、分类和安装命令以当时打开的页面为准，并尽量和 GitHub 交叉核对。
  • Auto-complete 不能批准执行。交接题没有自动完成选项，这是有意为之。
  • 执行阶段会按 ponytail 纪律尽量简化实现，测试也只保留能证明核心逻辑的最小集合。清单没过完，goal 不会被标成 complete。

小结

dsh-plans 把「先规划、再改代码」写成一套可落盘的 DSH 预设：方案在 ./dsh-plans/ 里版本化，reviewer / criticizer 只读打磨，执行必须经过没有自动完成的交接，再用 DSH 自己的 goal 循环做到 Verifier Checklist 通过。

目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-plans/

GitHub：https://github.com/Optim-Agent/dsh-plans

相关文章

快速从零部署一个DeepSeek-R1服务 2025-04-05 使用 dsh-anchored-standard 为 DeepSeek Harness 配置两阶段 Agent 预设 2026-08-17 用 dsh-web-ui 把 DeepSeek Harness 网页界面补成工作台 2026-08-17 用 modlens 给 DeepSeek Harness 的纯文本模型补上视觉 2026-08-17 用 dsh-TUI 给 DeepSeek Harness 补上全屏终端界面 2026-08-17
羽毛球分组比赛记分
小程序二维码

欢迎使用《羽毛球分组比赛记分》微信小程序

小夜