前言¶
在 DeepSeek Harness（DSH）里用官方 @deepseek-ai/dsh-tool-workflow 跑多 agent 编排时，常见做法是每次会话把整段脚本交给模型再执行。官方 README 写明不支持 saved 或 nested workflows，调用方只能反复提供脚本。若某套编排已经跑通、希望下次只换参数复跑，就需要把脚本和元数据落在进程可访问的存储里，并提供 list/get/delete/run 一类工具面。下面介绍社区插件 dsh-tool-workflow-plus 如何以 drop-in fork 的方式补上这一块能力。
这是什么¶
dsh-tool-workflow-plus 由维护者 shuxidemosheng 发布，npm 包名与插件名均为 dsh-tool-workflow-plus，分类属于工作流。它在官方 workflow 工具 0.2.1-alpha.2 的模型面（参数 schema、run 生命周期、会话事件、UI 折叠）上逐字移植，增量只有一件事：在 ctx.storageDomain 上提供持久化的 saved workflow 库，对应 workflow_save、workflow_list、workflow_get、workflow_delete、workflow_run_saved 五件套。模型可以把跑通过的编排脚本写入库，后续会话用 workflow_run_saved 传入新 args 直接复跑，而不必重发整段脚本。
社区目录页：shuxidemosheng/dsh-tool-workflow-plus。源码与说明：GitHub 仓库。许可证为 MIT；package.json 标明版本 0.1.0，运行要求 Node >=24、DSH >=0.2.0-rc.2。
核心功能¶
saved workflow 五件套¶
安装后除 fork 本体 workflow 外，模型可使用以下工具（资料中的工具面摘要）：
| 工具 | 作用 |
|---|---|
workflow |
与官方等价；描述末尾追加 saved 库使用纪律。官方已注册同名工具时 fork 自动让位 |
workflow_save |
存 { meta, script }，key 为 meta.name；同名默认拒绝，需 overwrite: true 覆盖 |
workflow_list |
列出全部记录（名称、描述、whenToUse、phases、脚本大小，按更新时间倒序，不含脚本体） |
workflow_get |
取完整记录（含脚本），供审阅或修改后重存 |
workflow_delete |
按名删除 |
workflow_run_saved |
用已存脚本与 meta 启动引擎，注入新 args；支持 run_in_background |
脚本契约与官方一致：裸 JS body（无文件系统、网络、Node API），meta 为纯 JSON，args 作为全局 args 注入。保存期会校验 meta 形状并对齐引擎规则；脚本若带 export const meta 块会被拒绝，避免「存得进、跑不起来」。
持久化与 UI¶
- 存储域为
workflow_saved（表workflows，per-record 布局）；记录在标准 base bundle（backend: json）下落在dshHomePath('storages')，跨会话存活。 - 发起的 run 写入与官方同名的
tool-workflow/*durable 会话事件，客户端dsh-client-ui-workflow-run可照常渲染。 - 未挂载 storage 三件套的部署：插件激活不失败，调用 saved 工具时返回点名缺失件的错误。
与官方工具共存或接管¶
默认仅插入本插件 patch：若官方已占 workflow 名，fork 让位并打 warn，saved 五件套仍可用。若希望 fork 接管 workflow 名，可在 profile patch 中禁用官方 tool-workflow（资料注明部分 web/desktop 部署的官方行在 agent preset 组内，profile patch 可能够不着，此类环境保持共存即可）。
安装与启用¶
在 Git Bash 中执行（命令来自仓库 README）：
dsh plugin add dsh-tool-workflow-plus
也可在 profile 的 bundle 依赖里加入 dsh-tool-workflow-plus 后重载。
可选配置通过 patch 行 config 传入，未知键启动即报错：
| 键 | 默认 | 说明 |
|---|---|---|
toolName |
'workflow' |
fork 本体注册名 |
savedTools |
true |
是否注册 saved 五件套 |
enableRunInBackground |
true |
run_in_background 开关（需 ctx.jobs） |
maxResultChars |
50000 |
渲染结果截断上限 |
典型用法¶
下面步骤来自 README 中的模型视角示例，说明一次「跑通 → 入库 → 复跑」闭环。
1、第一次跑通后调用 workflow_save，传入 meta 与 script：
{
"meta": {
"name": "code-audit",
"description": "对一批文件做审计，再做一轮对抗校验",
"whenToUse": "用户要求大范围代码审计时",
"phases": [{ "title": "scan" }, { "title": "verify" }]
},
"script": "const files = args.files\nconst found = await pipeline(files,\n f => agent(`审计 ${f}，输出问题列表`, { phase: 'scan' }),\n (issues, f) => agent(`对抗校验：${JSON.stringify(issues)}`, { phase: 'verify' })\n)\nreturn found"
}
成功时返回形如 {"kind":"saved","name":"code-audit","overwritten":false,...} 的结果。
2、之后在任意会话中，用 workflow_run_saved 带新参数复跑：
{ "name": "code-audit", "args": { "files": ["src/a.ts", "src/b.ts"] } }
工具描述中会强调纪律：写长脚本前先 workflow_list 查库；跑通后用 workflow_save；同名再存需显式 overwrite: true（保留原始 createdAt）。
适用场景与注意¶
适合：
- 反复让模型编写相似的多 agent 编排，希望跑通一次后持久化并在后续会话复用；
- 希望用带 saved 库的版本替换或补充官方 workflow 工具（drop-in）；
- 部署中未挂官方 workflow 插件，但需要行为等价且带库的实现。
不适合：
- 需要可视化编排、治理、恢复等重型能力——资料指向独立 workflow 层项目，本插件刻意不覆盖；
- 仅需固定模板、不需要模型运行时写入——可考虑更轻的模板类插件；
- 大量 saved workflow 并发运行——存储域只管存取，调度仍依赖引擎与
ctx.jobs。
安全与权限： 插件在当前 DSH 进程权限下运行，saved 脚本属于用户资产；安装前请阅读源码与 MIT 许可证，确认存储路径与 profile 组合符合你的环境。DSH 社区目录（如 SkillHub）为独立站点，与 DeepSeek / 幻方无官方从属关系。
结尾¶
dsh-tool-workflow-plus 在官方 workflow 工具之上补全 persisted saved workflow 库，用五件套工具完成存、列、取、删、带参重跑，并与官方 run 生命周期和 UI 事件对齐。需要安装命令、配置项与 FAQ 时，以 GitHub README 为准；社区索引见 SkillHub 目录页。
