前言¶
在 DeepSeek Harness（DSH）里做多轮 Agent 协作时，常见做法是让不同角色轮流在对话里接话，或由开发者手工编排每一步交接。这样缺少明确的流程约束：审查有没有真正挡在合并前、测试失败后会不会仍沿「通过」路径推进，往往依赖临场记忆或额外提示词。dsh-agent-team-workflow（仓库 huaComPj/dsh-workflow-plugin）把「Manager 协调 → 角色分工执行 → 独立 Judge 核验 → 再进入下一节点」做成可配置的串行工作流，并支持可视化编辑与 YAML 持久化，让团队按节点交付，而不只是轮流回答。
这是什么¶
该插件由社区维护者 huaComPj 发布，分类为工作流，npm 包名为 dsh-agent-team-workflow，当前资料中的版本为 0.2.1-rc.2，许可证为 MIT。它为 DeepSeek Harness 提供可配置的串行团队工作流：Manager 协调任务，按角色安排开发、审查、测试等 Actor 分工执行，独立 Judge 根据节点验收条件核验结果，未通过则不能沿通过路径继续。
工作流按节点串行推进，不是并行任务调度器；核验能约束流程，但不保证模型输出绝对正确。恢复或终止流程不会撤销已发生的文件修改、推送或合并。
核心功能¶
下面介绍 README 中已明确列出的能力。
角色分工与独立核验。 按流程安排各角色；Judge 根据当前节点的验收条件核验结果，未通过就不能沿通过路径推进。
可视化配置。 在画布上编辑节点、结果分支、角色属性和子流程，保存为 YAML；工作流可复用，也可按项目调整。
按角色选择模型。 默认继承 Manager 的模型，也可为不同角色和 Judge 单独配置模型与思考档位。
在对话中启动。 通过「启动工作流」弹窗或 /dsh-flow start 提交任务，不必手工协调每轮交接。
进度可见、异常可处理。 可查看当前节点、Actor / Judge、执行记录和 BLOCK 原因；补充信息或处理障碍后可恢复推进。安装提供 betterSidebar 服务的配套侧栏后，还可打开「工作流监控」。
安装与启用¶
需要 Node.js ≥ 22.19（推荐 Node.js 24）、DSH ≥ 0.2.1-rc.2，以及可用的 dsh、pnpm 命令。安装已发布版本时无需克隆插件源码或自行构建。
已有 DSH 实例时，应先结束活动任务并停止对应实例；安装后启动或重启 Web 并刷新浏览器。已有开发版时避免与 npm 版重复加载；使用自定义 DSH_HOME 时全程保持一致。
1. 安装插件¶
这一步从 npm 安装指定候选版本并启动 DSH Web：
dsh plugin --profile web add dsh-agent-team-workflow@0.2.1-rc.2
dsh web
2. 初始化默认工作流¶
在已加载插件的 DSH 对话中执行。先用 --dry-run 预览，再正式初始化：
/dsh-flow init --dry-run
/dsh-flow init
经过上面的步骤，会安装 通用 Manager preset 和 development-workflow 示例工作流。已有不同内容时默认跳过，不覆盖自定义配置，也不删除其他模板。
3. 选择 Manager 并准备环境¶
重启 DSH 后，选择 团队工作流 Manager（通用） 新建会话，把工作目录设为目标项目，并为 Manager 配置可用模型。默认模板的开发、审查、测试角色及 Judge 均继承该模型。
默认示例围绕 GitHub Issue / PR 工作，运行前需具备 Git、可用的 GitHub 访问工具（如 gh CLI）和仓库权限；它会创建 Issue、任务分支，提交、推送并创建 PR，需先获得相关操作授权，合并另经用户确认。若只允许只读操作，应先调整模板，不要直接启动完整交付流程。
典型用法¶
普通安装只初始化通用开发流程；复杂流程见仓库内进阶配置示例，不是默认自动安装项。
检查与启动任务¶
先列出工作流、检查配置（check 只检查配置，不发送真实模型推理请求），再启动任务：
/dsh-flow list
/dsh-flow check development-workflow
/dsh-flow start development-workflow 修复指定问题，并完成审查和测试
也可在输入区点击「启动工作流」，选择配置并描述任务。启动后用 /dsh-flow status 查看进度。
默认五节点开发流程¶
init 安装的 development-workflow 是单仓库、单 Issue、单 PR 流程，节点顺序为：
澄清需求并建 Issue → 开发实现 → 独立审查 → 独立测试 → 人工确认后合并
Manager 负责澄清需求、记录验收标准，并在最后向用户确认具体合并候选；开发、审查和测试由相应角色执行，各节点结果还需 Judge 核验。审查或测试发现必修问题，或候选修订发生变化时，会回到实现并重新走审查、测试。最后取得用户明确确认后，以 squash 合并并核验结果、关闭关联 Issue；默认模板不部署、不发布、不删除分支。
更完整的操作可跟随仓库文档 默认工作流任务示例；配置细节见 默认模板源码 与 模板与配置说明。
适用场景与注意¶
| 场景 | 使用方式 |
|---|---|
| 单仓库修复 Bug、实现小功能或重构 | 使用默认开发流程，围绕一个 Issue / PR 完成实现、审查、测试与合并 |
| 补测试、修改文档等需要独立检查的任务 | 使用默认流程，在 Issue 中写清楚适用检查与验收标准 |
| 多个任务按里程碑交付 | 按需采用进阶模板，组织拆票、逐票交付和集成验收 |
| 前后端等跨仓库联动 | 按需采用多仓库模板，并明确各仓库、分支与操作授权 |
权限与安全。 插件在当前 DSH 进程权限下运行；实际执行会调用模型，并可能执行已获准的本地或远端操作（如 git push、gh 等）。安装与启用前宜阅读仓库源码与 MIT 许可证，按项目策略评估授权范围。
生态说明。 DSH 理念是「一切皆插件」；社区插件目录 SkillHub 上的条目 为独立站点，与 DeepSeek / 幻方无官方从属关系。
结尾¶
dsh-agent-team-workflow 把 Manager、多角色 Actor 与独立 Judge 写成可复用的串行 YAML 工作流，适合在 DSH Web 里按 Issue / PR 节奏做实现—审查—测试—合并，或用可视化编辑器按项目改节点与验收条件。目录页：https://www.skillhub.cn/plugins/huaComPj/dsh-workflow-plugin；源码与文档：https://github.com/huaComPj/dsh-workflow-plugin。
