前言¶
DeepSeek Harness（DSH）已经具备模型路由、子 Agent、工具权限、审批、Session 日志和后台 jobs 等执行原语。实际开发中，团队往往仍要在每轮会话里重新描述如何拆任务、并行执行、验证结果并汇总——策略难以复用，中断后通常只能从头重来，并行结果也散落在对话里。
omdsh-dev/dsh_workflow（包名 @dsh-external/workflow）针对的正是这一层缺口：在 DSH 原生 workflow 工具之上，增加命名、发现、生成、复用、暂停/恢复、重跑/续跑、持久证据、成本记录和治理等流程产品能力。它不替换 DSH 已有的一次性并行调度，而是把多 Agent 编排沉淀为可审计、可分享、可演进的工程资产。
这是什么¶
@dsh-external/workflow 是一个官方 bundle 形态、零核心 patch 的 DSH 插件，由 omdsh-dev 维护，在 SkillHub 社区目录中归类为「工作流」。插件完整参考 KodaX 的 workflow 设计能力，并针对 DSH 的 Cordis、ctx.subagents、Session、后台 jobs、审批、命令和工具机制做独立实现。
许可证为 MIT。README 标注兼容 DSH 0.0.1-rc.2，插件当前版本 0.1.2，测试套件 179 项通过。
核心功能¶
执行模型¶
下面介绍插件与 KodaX workflow 对标的执行能力。
- 版本化
dsh.workflowv1 capsule，包含 manifest、source、intent、inputs、requires、provenance。 - 统一
async function run(wf, args)入口，提供完整 WorkflowApi：phase、spawnAgent、runAgent、wait、snapshot/output、send/stop、parallel、pipeline、synthesize、单层嵌套 workflow、artifact、log、budget。 - 六个标准 pattern：classify-and-act、fan-out-and-synthesize、adversarial-verification、generate-and-filter、tournament、loop-until-done。
- 两个内置 workflow：
parallel-investigation（可按 rubric/agent/concurrency 参数化）和scoped-review（含 packet/schema/read-contract/双 primary/逐 finding verifier/audit artifact）。
发现与复用¶
workflow 搜索顺序是确定性的：
- 插件内置 workflow 与 pattern（不可被磁盘文件遮蔽）；
- 项目目录
.dsh/workflows； - 个人目录
$DSH_HOME/workflows。
项目同名条目覆盖个人条目；同一目录中 .workflow.json 优先于 .ts/.mjs/.js。
生命周期与持久化¶
每个 run 有 running → paused/completed/failed/denied/stopped 状态和稳定 id，默认写入项目目录：
.dsh/workflow-runs/<run-id>/
├── run.json # 状态、结果摘要、成本
├── events.jsonl # append-only 事件图
├── workflow.workflow.json # 不可变执行快照
├── results/ # 确定性 effect cache
└── artifacts/ # workflow 命名证据
支持按 run id 重跑（使用不可变 capsule snapshot）、按 saved name 重跑（使用当前保存版本），以及 resume-run（相同调用序号与 task input 命中缓存，其余任务继续执行）。
安全与治理¶
- 生成型脚本运行在 QuickJS WebAssembly 独立堆中，只能通过冻结的 WorkflowApi 发起 effect，静态 policy 拒绝 import/require、process、文件、shell、网络等非确定性 API。
- manifest + preflight + 运行时硬限制管控 provider/模型/并发/预算。
approvalMode支持never | generated-and-local | always三级审批。
安装与启用¶
要求 Node.js >=22.19，以及与插件 compatibility.json 一致的 DSH 快照。
先做插件安装，再验证 profile 合成树：
# 构建产物已提交，git 源安装不需要在用户侧编译
dsh plugin --profile web add "github:dsh-external/dsh_workflow#main"
# 验证 bundle 已进入 profile 合成树
dsh --profile web --dump-config
预期配置中出现：
- id: dsh-external-workflow
name: '@dsh-external/workflow'
重启对应 DSH profile 后生效。安装前建议阅读 GitHub 仓库 源码与 MIT 许可证，确认以当前 DSH 进程权限运行是否符合团队安全要求。
典型用法¶
重启 profile 后，在会话中可直接使用斜杠命令：
/workflow list
/workflow parallel-investigation {"question":"为什么这个测试会间歇失败？"}
/workflow create 为这个仓库设计一个并行安全评审流程
/workflow review --risk high --requirement "不得破坏公开 API" --test-evidence "pnpm test 通过" --wait
/workflow runs
workflow 启动默认立即返回 { runId, status, jobId? }，不会占住当前 turn。需要同步等待终态时，对命名 workflow、rerun、review 传入 --wait。
模型也可调用三个工具：
workflow_list：发现 built-in、pattern、项目和个人 workflow。run_workflow：运行命名 workflow、从自然语言 scout-then-author，或执行受限 inline workflow。workflow_manage：查看、暂停、恢复、停止、重跑、续跑、保存、改名、修订、删除和清理。
常用管理命令：
/workflow help
/workflow show [--full] [runId]
/workflow pause|resume|stop [runId]
/workflow rerun|resume-run <runId|savedName> [JSON args] [--wait]
/workflow save <runId> <name> [project|personal]
/workflow prune [--dry-run] [--keep N] [--older-than 7d|24h]
常见配置片段如下，完整字段见仓库 docs/CONFIGURATION.md：
- id: dsh-external-workflow
name: '@dsh-external/workflow'
config:
approvalMode: generated-and-local
maxAgents: 64
maxConcurrency: 8
maxRetainedRuns: 500
适用场景与注意¶
适合谁
- 需要把多 Agent 并行调查、代码评审、任务拆解等流程固化为可复用资产的个人开发者或团队。
- 已在 DSH 上使用子 Agent 和后台 jobs，希望补齐命名、持久化、续跑和成本记录的团队。
- 需要对标 KodaX workflow 行为、在 DSH 生态内独立实现同等能力的集成方。
使用注意
- 插件以当前 DSH 进程权限运行；trusted-local workflow 具有 Node 宿主权限，不要把不可信第三方源码标为 trusted-local。
- 它不替换 DSH 原生前台
workflow工具——原生工具适合「这一次把若干工作并行跑完」，本插件负责更高一层的流程产品能力。 create和自由文本形式的/workflow <自然语言请求>由当前 Agent turn 接管 authoring，不接受--wait。- 当前 DSH 通用 subagent seam 不直接支持 existing-agent target、per-agent effort 和 worktree；相应请求需部署注册 adapter，未注册时会明确失败。
结语¶
经过上面的步骤，omdsh-dev/dsh_workflow 把 DSH 已有 Harness 能力串成完整闭环：从一次性多 Agent 调度，升级为可生成、可保存、可治理、可观察、可恢复的 Workflow 层。
- SkillHub 目录页：omdsh-dev/dsh_workflow
- GitHub 仓库：github.com/omdsh-dev/dsh_workflow
