前言¶

在 DeepSeek Harness（DSH）里跑多步任务时，常见做法是单次对话里串行调用模型或脚本：一步卡住、等人点头，后面就停；Host 重启后状态也难找回。若要把模型、命令和人工审批放在同一条业务线上，还要让多条需求并行推进，就需要一张可落盘、可并发的节点图，而不是一次性 prompt 链。

dsh-auto-workflow（维护者 lyingloong）是 DSH 生态中的工作流类插件，在 Host 常驻期间调度持久化节点图：新任务以独立 packet 入队，某处等待 Human 时，其他分支仍可继续。当前公开发布为 v1.1.0，仓库与文档见 GitHub 与 项目页。社区目录页：skillhub.cn/plugins/lyingloong/dsh-auto-workflow（独立站点，与 DeepSeek / 幻方无官方从属关系）。

文中 「Auto」 指已授权流程的持续调度，不是免审批。

这是什么¶

一句话：持久化、并发的节点图工作流插件，支持 agent、command、HTTP、human、fan-out/join、gate、subworkflow 等节点类型，带有序模型回退、权限、产物与实时看板。

它解决的是：在同一张图里协作调度模型、命令与人工决策；状态与数据引用落盘；Host 运行期间不因空闲或 Human 等待而结束。需要说明的是：Host 停止、插件重载或执行中断后，不自动重放不确定工作，也不承诺跨 Git/HTTP 的掉电事务。

核心功能¶

调度与并发¶

• 根并发上限为 6；命令与挖掘共享这六个槽位。示例业务图中 engineer 池、reviewer 池各最多 3，表示两个工作池上限，不是「每项需求三位 reviewer」。
• 节点类型覆盖智能体、壳命令、HTTP、人工卡点、扇出/汇合、门控与子工作流；字段与协议见仓库内插件参考文档。

七个 DSH 工具¶

文档明确：不要循环轮询 run。

Web 看板¶

• Human 待处理：可打开独立卡片，读取该 token 的输入 JSON，填写留言并在查看 outcome 后决策。
• 节点图模式：「简化」隐藏 busy-* 重试门；「完整」显示全部边。
• 节点方块用颜色区分空闲/运行/等待/错误/关闭，点击可查看详情、数据包与历史。

主示例：GitHub 项目持续开发¶

README 给出的唯一主示例，是「GitHub 项目持续开发」：工作流自行维护每需求分支、worktree 和 PR，外部 Codex 或人可以审核并 merge。业务流程大意如下（返修保留同一需求 ID、分支、worktree 和 PR；snapshot 把分支压成一个 commit）：

用户 intake（priority 0）与周期 producer/挖掘 → 需求队列 → 按来源与风险分流：低风险进 worktree 开发，中高风险先 Human 需求审批 → engineer/reviewer 池 → draft PR → 人工 brief/PR 门禁 → 标记 ready → 外部 merge → 验证合并（默认清理 worktree）。宽限期 selfMergeAfterMs 内仍未 merge 时，才进入需 Human 同意的自合并路径。

插件侧负责通用调度与引用；需求优先级、Git worktree、审查与合并策略属于示例业务代码。

安装与启用¶

环境要求（来自 package.json 与 README）：

• Node.js 22.5+
• DeepSeek Harness 0.2.1-rc.5+（首发已验证 rc.5）
• 开发示例另需 Git 与可用的模型工具环境

以下示例使用 desktop profile，请按实际配置替换 profile。

推荐固定 release，避免随开发分支变化：

dsh plugin --profile desktop add github:lyingloong/dsh-auto-workflow#v1.1.0

也可从 v1.1.0 Release 下载 .tgz，或安装本地包路径：

dsh plugin --profile desktop add /absolute/path/dsh-auto-workflow-1.1.0.tgz
dsh plugin --profile desktop add /absolute/path/dsh-auto-workflow

安装后重启 DSH Host，再刷新 Web GUI。安装插件不会把示例脚本复制到业务仓库，也不会自动启动工作流。

许可证：MIT（package.json）。

典型用法：五步走通主示例¶

下面步骤摘自 README「快速使用：持续开发一个本地 GitHub clone」，按顺序执行即可复现主路径。

1. 准备项目：克隆你有权修改的 GitHub 仓库，配置 origin 和 gh auth login（或 GITHUB_TOKEN）；把示例脚本 materialize 到项目内并本地提交，使 checkout 干净。选择项目外的绝对、canonical dataRoot。
2. 输入真实需求：初始化业务存储（会放入 baseline discovery seeds），提交用户需求；可选用 driver seed 补充相关证据 seed。用户需求优先级固定为 0；示例不监听所有聊天，也不自动抓取 GitHub Issues。
3. 授权并定义：检查示例图（docs/examples/development/workflow.json）与模型提示词，明确批准命令 allowlist，再调用 auto_workflow_define。HTTP 默认拒绝；agent 工具权限另行控制。
4. 开始运行：auto_workflow_start 绑定项目的绝对 cwd 和 { "dataRoot": "…" }；auto_workflow_run 挂载运行。在同一 run 中向 mine-gate 仅 enqueue 一次 producer，后续需求继续送入现有运行。
5. 审核与合并：每个需求在 auto/req-<id> 分支和独立 worktree 中开发；第一次 snapshot 后推送分支并创建 draft PR。review pass 与结构化 brief 后 PR 标记 ready，外部 Codex 或你可以直接 merge。默认 after-verified-merge 会删除 worktree（含开发期临时文件），提交和不可变记录保留。

经过上面的步骤，工作流会在本机 push 自己的需求分支并创建/更新 PR，但不会 merge 远端、不会自行批准 GitHub PR，也不会部署。

适用场景与注意¶

适合谁：需要在 DSH 里跑长时间、多分支、带人工卡点的工作流；尤其是想参考「本地 GitHub 仓库持续开发」示例的开发者。分类上属于社区目录中的「工作流」类插件。

权限与安全：

• 插件以当前 DSH 进程权限运行；安装前应自行检查源码与 MIT 许可证。
• command/HTTP 权限默认 deny。命令 allowlist 不是文件系统沙箱，也不替代 agent 工具权限。
• 单 Host、本地文件锁；不是分布式队列、外部审批服务或 exactly-once Git/HTTP 事务。

运维边界：

• 暂停和禁用节点不会取消在途工作；Stop 不等于回滚。失败或中断后先检查副作用，再显式恢复或新建 run。
• 包版本 1.1.0、定义 apiVersion: 2、运行状态 version: 3、示例业务存储 version: 2 是不同层的版本号，不要求相同。

仓库提供 npm test 做完整回归；验证范围与真实模型执行限制见 docs/verification.md。

结尾¶

dsh-auto-workflow 把 DSH 从「单轮对话链」扩展到可落盘、可并发的节点图：模型、命令与 Human 在同图协作，工具 API 覆盖定义、启动、挂载运行、入队、审批、控制与只读状态。若你正在 DSH 上搭建需要并行需求与审批门禁的流程，可从固定 v1.1.0 安装入手，再按 GitHub 持续开发示例 materialize 业务脚本。

• 目录页：https://www.skillhub.cn/plugins/lyingloong/dsh-auto-workflow
• 仓库：https://github.com/lyingloong/dsh-auto-workflow