用 dsh_workflow 把 DSH 的一次性多 Agent 调度做成可恢复工作流

DeepSeek Harness 插件 DeepSeek DSH dsh_workflow 工作流自动化 多Agent 2026-08-17 69 阅读

前言

DeepSeek Harness（以下简称 DSH）把模型路由、子 Agent、工具权限、审批、Session 日志和后台 jobs 都做成了可替换的插件能力。官方仓库 deepseek-ai/deepseek-harness 的口号就是「一切皆插件」：不改内核，也能在配置层挂上新能力。

真正跑复杂任务时，缺口往往不在「能不能再起几个 Agent」，而在流程本身。并行调查、分区评审、对抗验证这类工作，如果每次都在当前会话里重新描述怎么拆、怎么并发、怎么汇总，策略很难复用；中途断开后，结果散落在对话里，通常只能从头再来。DSH 自带的前台 workflow 工具适合「这一次把若干工作并行跑完」，但还不是一份可以命名、保存、审计和续跑的工程资产。

社区插件 dsh_workflow 做的就是这一层。本文按社区目录页、GitHub README、package.json 和许可证交叉核对后整理：它是什么、装完能干什么、命令怎么写，以及安装前必须看清的权限边界。社区插件目录是独立站点，和 DeepSeek / 幻方没有官方从属关系，不要把它当成官方应用商店。

这是什么

dsh_workflow 是一款面向 DSH 的工作流与自动化插件。社区目录标注维护者为 icetomoyo，许可证为 MIT，主要语言是 TypeScript。npm 包名是 @dsh-external/workflow，挂进 profile 后的插件 id 为 dsh-external-workflow。当前发布版本是 0.1.2（2026-08-13）。截至 2026 年 8 月 17 日，GitHub 显示 63 颗星。

仓库简介和目录页用同一句话概括它的目标：把 Claude Code 的 UltraCode 模式带给 DSH，把一次性多 Agent 调度升级为可生成、可保存、可治理、可观察、可恢复的 Workflow 层。Claude Code 文档里，UltraCode 会为实质任务自动写编排脚本、扇出子 Agent；dsh_workflow 在 DSH 里补的是更靠后的产品能力，而不是把 Claude Code 原样搬过来。README 写明：实现完整参考 KodaX 的 workflow 行为，并针对 DSH 的 Cordis、ctx.subagents、Session、后台 jobs、审批、命令和工具机制做独立实现，不复制 KodaX 的受限许可源码。

它明确不替换 DSH 已有的前台 workflow 工具。原生工具继续负责单次并行；本插件负责更高一层：按名字发现和运行、现场生成、暂停/恢复、按快照重跑或按缓存续跑、把 run graph / 事件 / artifact / 成本永久落盘。README 里的「官方 bundle 形态、零核心 patch」指的是按 DSH 插件 bundle 方式挂载、不改 Harness 源码，不是 DeepSeek 官方出品。

GitHub 上 icetomoyo/dsh_workflow、dsh-external/dsh_workflow 目前会解析到同一仓库（组织 omdsh-dev 下的 dsh_workflow）。安装时仍以目录页给出的命令为准。

核心功能

一次性调度和可复用工作流的差别

DSH 已经有执行原语，缺的是把这些原语收成可维护的流程。仓库 README 用对照表说明安装前后的变化，核心差别可以收成这几条：

  • 拆任务的策略不再每轮重写，而是保存为项目或个人 workflow，按名字运行。
  • 并行结果不再只留在会话气泡里，而是写入 run graph、事件流、artifact、结果摘要和成本记录。
  • 中断后可以按 run 快照重跑，或用 effect cache 续跑未完成部分，不必整段推倒。
  • provider、模型档位、并发和预算不再只靠提示词约束，而是走 manifest、preflight 和运行时硬限制。
  • 生成出来的脚本默认跑在 capability-only 的 QuickJS WebAssembly 隔离堆里，通过 JSON 边界和审批分级收权。

对 DSH 项目来说，效果是：多 Agent 从「这一次的技巧」变成可以审计、分享和演进的工程资产。

胶囊、内置流程和六种模式

执行单元是版本化的 dsh.workflow v1 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。

仓库目前带两个内置流程：

  • parallel-investigation：可按 rubric、agent、concurrency 参数化的并行调研。
  • scoped-review：带 packet / schema / read-contract、双 primary、逐 finding verifier 和 audit artifact 的分区评审。/workflow review 可以直接捕获当前 Git 范围并启动它，不需要给 DSH 核心打 /review 补丁。

另外还有六个标准 pattern：classify-and-act、fan-out-and-synthesize、adversarial-verification、generate-and-filter、tournament、loop-until-done。Agent 侧可以指定 phase、scope、只读、provider / 子 Agent 类型，以及 fast | balanced | deep 三档路由。

发现顺序是确定的，不会「碰巧读到另一份同名文件」：

  1. 插件内置 workflow 与 pattern（磁盘文件不能遮蔽）
  2. 项目目录 .dsh/workflows
  3. 个人目录 $DSH_HOME/workflows

项目同名条目覆盖个人条目；同一目录里 .workflow.json 优先于 .ts/.mjs/.js。符号链接、路径逃逸、超大文件、未知 capsule 字段、版本不兼容、manifest 和文件名不一致，都会在执行前失败。

生命周期、落盘和续跑

每个 run 都有稳定 id，状态在 running → paused/completed/failed/denied/stopped 之间切换。默认写入项目目录：

.dsh/workflow-runs/<run-id>/
├── run.json                    # 状态、结果摘要、成本
├── events.jsonl                # 只追加的事件图
├── workflow.workflow.json      # 生成型 workflow 的不可变执行快照
├── results/                    # 已完成且验证通过的 effect cache
└── artifacts/                  # workflow 命名证据

按 run id 重跑用的是该次不可变 snapshot；按已保存名字重跑用的是当前保存版本。resume-run 在相同调用序号和相同 task input 上命中缓存，其余任务继续执行。终态 run 会按 maxRetainedRuns 自动清理，也可以用 prune 预览或执行清理。

斜杠命令、模型工具和后台 jobs 走同一套引擎、run store 和安全策略。workflow 启动和 run_workflow 默认立刻返回 { runId, status, jobId? }，长流程不会占住当前 turn；需要同步等到终态时，再显式加 --wait 或 wait: true。

安装与启用

社区目录页给出的安装命令如下，在 DeepSeek Harness 终端里运行即可：

dsh plugin add github:icetomoyo/dsh_workflow

目录页同时提示：如需可复现安装，请固定 commit 哈希。当前 main 最新提交是 44b83c182aa02d1be8a0803e8446cb495f93cd8f（作者 icetomoyo，2026-08-13），可以写成：

dsh plugin add github:icetomoyo/dsh_workflow#44b83c182aa02d1be8a0803e8446cb495f93cd8f

GitHub README 额外给出了挂到 web profile 的写法，并说明构建产物已经提交，git 源安装不需要在用户侧编译：

dsh plugin --profile web add "github:dsh-external/dsh_workflow#main"
dsh --profile web --dump-config

验证时，配置里应出现：

- id: dsh-external-workflow
  name: '@dsh-external/workflow'

改完 profile 后需要重启对应 DSH 进程。运行要求来自 README 和 package.json：Node.js >=22.19（package.json 写的是 ^22.19.0 || >=24.0.0），以及与仓库 compatibility.json 一致的 DSH 快照。该文件当前记录的兼容基线是 DSH 0.0.1-rc.2，测试时间 2026-08-13。

插件以当前 dsh 进程的权限运行，安装时可能执行代码。安装前请检查源代码仓库和许可证。

典型用法

重启对应 profile 后，README 建议先在会话里跑这组命令：

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

/workflow list 会列出内置、pattern、项目和个人 workflow；无效条目会报告，但不会执行。/workflow <name> [JSON args] 按名字启动已保存流程。/workflow show 默认看最新 run，/workflow stop 默认停当前活动 run。

/workflow create <request> 以及未知名称的 /workflow <自然语言请求> 不会把斜杠命令卡在 command/run 上。它们会立刻结束命令处理，把原始用户问题作为真正的 user message 交给当前主 Agent；内部的编写约定则以折叠的 plugin context 交给模型，避免污染会话标题。主 Agent 先用自身工具调查 workspace，再以 source + manifest 调用 run_workflow 生成并启动流程。这条路径不接受 --wait；需要同步等待时，请对命名 workflow、rerun 或 review 使用 --wait。

仓库还提供受限 capsule 示例 examples/review.workflow.json。它声明 readOnly: true，按 implementation / tests / docs 这类独立 scope 做 fan-out，再走 verifier 和 synthesize，适合对照 capsule 字段看一遍，而不是直接当生产流程复制。

模型侧对应三个工具：

  • workflow_list：发现可用 workflow
  • run_workflow：运行命名流程、从自然语言 scout-then-author，或执行受限 inline workflow
  • workflow_manage：查看、暂停、恢复、停止、重跑、续跑、保存、改名、修订、删除和清理

常用治理命令还包括：

/workflow help
/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]

斜杠命令通过 ctx.userQuestions 做一次性人类确认；模型工具使用当前 turn 的 ctx.approval。后台运行会尽量注册到 ctx.jobs，同时始终保留插件自己的 durable run id。

如果用的是 DSH Web，左侧工作区在「手动排序」且会话数超过 5 条时会折叠其余会话。新 workflow 会话已经归属对应工作区，必要时点「展开其余 N 个会话」，或把视图改成「最近更新」。

适用场景与注意事项

比较适合这些情况：

  • 需要把并行调研、分区评审、对抗验证做成可复用流程，而不是每次在对话里重写拆解方式
  • 希望 run 有稳定 id、事件图和成本记录，中断后能重跑或续跑
  • 团队要把多 Agent 策略当成项目资产放进 .dsh/workflows，而不是只留在某个人的会话里

不适合把它当成 DSH 原生 workflow 工具的替代品。单次把几项工作并行跑完，继续用前台工具即可。也不要指望它自动补齐当前 DSH 子 Agent 接口里还没有的能力：README 写明，通用 subagent seam 目前不直接支持 existing-agent target、per-agent effort 和 worktree；这些请求需要部署侧注册 adapter，未注册时会明确失败，而不是悄悄降级。

还需要记住这些边界：

  • 生成型脚本只能通过冻结的 WorkflowApi 产生副作用，运行在独立的 QuickJS WebAssembly 堆中；import/require、process、文件、shell、网络、timer 和非确定性 API 会被静态拒绝。它仍然是进程内组件，不是操作系统级容器。
  • 项目或个人目录里的可信本地模块（.ts/.mjs/.js）以 Node 宿主权限执行，每次都要显式确认。不要把未审查的第三方源码标成 trusted-local。
  • 只有生成型 capsule run 会保存不可变 script snapshot；纯函数的 trusted-package / local run 不能从 run id 再保存。
  • dsh.workflow v1 与 KodaX capsule 不做协议兼容，外部 capsule 不会被误执行。
  • 内建 verification 覆盖实际 read/mutation 工具证据、Git workspace 变化、required path 前后指纹和文本后置条件；非 Git 工作区或需要外部权威证据时，要自己注册 verification adapter。

常见配置项（完整字段见仓库 docs/CONFIGURATION.md）包括 approvalMode（never | generated-and-local | always，README 示例默认 generated-and-local）、maxAgents、maxConcurrency、maxRetainedRuns，以及 fast / balanced / deep 三档的 provider 与 token 上限。workflow 声明的 requirement 不在部署能力清单里时会直接失败，不会偷偷降级。

再次强调：插件以当前 dsh 进程的权限运行，安装时可能执行代码。安装前检查源代码和 MIT 许可证；需要可复现环境时，固定 commit，并核对 compatibility.json 里的 DSH 快照。

小结

dsh_workflow 没有另起一套和 DSH 平行的编排内核，而是把已经存在的 provider、子 Agent、审批、Session 和 jobs 收成可命名、可落盘、可续跑的工作流层。对经常要把多 Agent 跑法沉淀下来的人来说，它补的是「流程产品」而不是「再多一个并行开关」。

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

GitHub：https://github.com/icetomoyo/dsh_workflow

相关文章

快速从零部署一个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
羽毛球分组比赛记分
小程序二维码

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

小夜