workflow

<h1 align="center">DSH Workflow</h1>

<strong>把 DeepSeek Harness 的一次性多 Agent 调度，升级为可生成、可保存、可治理、可观察、可恢复的 Workflow 层。</strong>

中文 · <a href="README.en.md">English</a> · <a href="#快速开始">快速开始</a> · <a href="#它为-dsh-带来什么">DSH 价值</a> · <a href="#能力">能力</a> · <a href="docs/KODAX_PARITY.md">对标矩阵</a>

@dsh-external/workflow 是一个官方 bundle 形态、零核心 patch 的 DSH 插件。它完整参考 KodaX 的 workflow 设计能力，并针对 DSH 的 Cordis、ctx.subagents、Session、后台 jobs、审批、命令和工具机制做独立实现。

它不替换 DSH 已有的前台 workflow 工具。原生工具适合“这一次把若干工作并行跑完”；本插件负责更高一层的流程产品能力：命名、发现、生成、复用、暂停/恢复、重跑/续跑、持久证据、成本记录和治理。

它为 DSH 带来什么

DSH 已经有很强的 Harness 基础设施：模型路由、子 Agent provider、工具权限、审批、Session 日志、后台 jobs 与 UI 事件。但仅有这些“执行原语”，团队仍需在每次会话里重新描述如何拆解、并发、验证和汇总。

只有一次性调度时	安装 DSH Workflow 后
每轮重新提示如何拆任务，策略难复用	保存为项目或个人 workflow，按名字运行
并行结果散落在会话里	run graph、事件、artifact、结果摘要和成本永久落盘
中断后通常从头重来	按 run snapshot 重跑，或用 effect cache 续跑未完成部分
provider/模型/并发/预算靠提示词约束	manifest + preflight + 运行时硬限制
生成的脚本容易越权或不可复现	capability-only VM、JSON 边界、确定性 guard、审批分级
复杂流程只有作者自己知道怎么用	capsule 自带 intent、inputs、requirements、provenance
多 Agent 是一次性技巧	多 Agent 变成可审计、可分享、可演进的工程资产

对 DSH 项目本身，这个插件的价值是把已有 Harness 能力串成完整闭环：

flowchart LR
  A["DSH providers / models"] --> W["DSH Workflow"]
  B["tool filters / approval"] --> W
  C["Session / jobs / commands"] --> W
  W --> D["reusable capsules"]
  W --> E["durable run graph"]
  W --> F["resume / governance / evidence"]

因此，DSH 不只会“调用 Agent”，还可以承载长期维护的 Agent 工作流库。

快速开始

要求：Node.js >=22.19，以及与 compatibility.json 一致的 DSH 快照。

# 构建产物已提交，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 后，在会话中输入：

/workflow list
/workflow parallel-investigation {"question":"为什么这个测试会间歇失败？"}
/workflow create 为这个仓库设计一个并行安全评审流程
/workflow review --risk high --requirement "不得破坏公开 API" --test-evidence "pnpm test 通过" --wait
/workflow runs

/workflow create <request> 和未知名称的 /workflow <自然语言请求> 会像 KodaX 一样立即结束命令处理，并把显式 workflow 意图交给当前主 Agent。用户原始 query 以真正的 user message 进入 Session，所以会在对话中显示、参与 DSH 会话标题生成并可在左侧工作区中按标题识别；内部 authoring contract 则作为独立的折叠 plugin context 交给模型，不会污染标题或用户气泡。主 Agent 先用自身工具调查真实 workspace，再以 source + manifest 调用 run_workflow 生成和启动流程；长时间 scout/authoring 不会把斜杠命令卡在 command/run。这条命令只为对应消息中的第一次通过预启动冒烟校验的 inline workflow 提供一次性显式授权；如果脚本或子任务字段无效（例如 modelHint 不是 fast | balanced | deep），插件会在启动任何真实子 Agent 前返回精确错误，并保留本 turn 的一次性授权供主 Agent 修正后重试。内部 relay、后续直接用户消息或重复的有效调用都不能复用授权；工具产生的 scouting context 不会误撤销它。approvalMode: always 和 trusted-local workflow 的审批仍然保留。由于 authoring 由当前 Agent turn 接管，create/free-text 形式不接受 --wait；需要同步等待时请对命名 workflow、rerun、review 使用 --wait，或在工具调用中使用 wait: true。

DSH Web 的左侧工作区在“手动排序”且会话数超过 5 条时会折叠其余会话；新 workflow 会话已归属对应工作区，必要时点击“展开其余 N 个会话”，或将视图排序切换为“最近更新”让活动会话自动前置。

workflow 启动和 run_workflow 默认立即返回 { runId, status, jobId? }，不会让一个长流程占住当前 turn；支持等待的子命令显式传入 --wait（工具参数为 wait: true）才等待终态。/workflow show 默认显示最新 run，/workflow stop 默认停止当前活动 run。

模型也可以调用三个工具：

• workflow_list：发现 built-in、pattern、项目和个人 workflow；无效条目会报告但不会执行。
• run_workflow：运行命名 workflow、从自然语言 scout-then-author，或执行受限 inline workflow。
• workflow_manage：查看、暂停、恢复、停止、重跑、续跑、保存、改名、修订、删除和清理。

能力

与 KodaX workflow 对标的执行模型

…