前言¶
DSH 的理念是「一切皆插件」，社区插件目录也是独立站点，不是 DeepSeek 官方应用商店。对使用 DSH 做智能体开发的场景来说，直接给 Agent 一句需求后允许其自由修改，容易出现两类问题：长会话中任务边界慢慢漂移，以及 bash、write、edit 这类修改能力在任务完成后仍然可用。
dsh-governed-workflow 试图把这类流程收敛成更明确的序列：先从公开 GitHub Issue 中读取任务 authority，只有任务进入 RUNNING 后才允许受保护的修改；任务进入 BLOCKED、COMPLETED 或 REVIEW_PENDING 后再次禁止受保护修改，并把最终验收留在 Builder Runtime 之外。
这是什么¶
dsh-governed-workflow 是一个面向 DeepSeek Harness agents 的独立社区插件，包名为 dsh-governed-workflow。资料中出现的仓库地址为：
https://github.com/zcx369658780/governed-workflow-for-dsh
当前资料未明确标注维护者；仓库路径中的 zcx369658780 仅来自 GitHub 地址线索，本文不将其写成已确认的维护者身份。
已核实的版本与归属信息如下：
- 当前阶段：
V0.9 Developer Technical Preview - 已验证基线：
@deepseek-ai/dsh@0.1.0-rc.6 - 包名：
dsh-governed-workflow - 许可证：
MIT - 本项目不隶属于 DeepSeek，也不代表 DeepSeek 官方背书
仓库 slug 是 governed-workflow-for-dsh，包名是 dsh-governed-workflow。本文以资料中出现的包名作为插件名。
核心功能¶
dsh-governed-workflow 的核心是把 Agent 工作流从“直接修改”改成“先确认 authority，再允许修改，最后进入独立验收”。
工作流如下：
GitHub Issue Authority
↓
OBSERVE
↓
ADMIT
↓
RUN
↓
BLOCK / COMPLETE
↓
REVIEW
具体能力包括：
-
GitHub Issue Authority
可选 provider 可以从公开 GitHub Issue 中读取机器可解析的 authority block。Builder 不应从旧聊天记录、分支存在或自己的计划中推断任务权限。 -
生命周期状态机
任务按下面顺序推进：
AUTHORITY_OBSERVED → TASK_ADMITTED → RUNNING → BLOCKED/COMPLETED → REVIEW_PENDING
非法迁移会 fail closed。
- RUNNING-only Mutation Guard
当前受保护的 DSH mutation tools 为：
bash
write
edit
如果没有 accepted authority，或任务状态不是 RUNNING，这些受保护修改动作会被拒绝。
- 模型侧治理工具
插件提供两个模型侧工具：
governance_status：只读状态查询governance_transition：受限动作集中的状态迁移
-
终态冻结
任务进入BLOCKED、COMPLETED或REVIEW_PENDING后，受保护修改会再次被禁止。 -
独立验收边界
Builder 不能自行 ACCEPT、merge、关闭已接受任务，也不能创建或激活后续任务。最终决定留在 Builder Runtime 之外。 -
治理证据
authority 观察与 lifecycle transition 会被记录为受限治理证据，用于审查和回放。
安装与启用¶
当前资料没有确认已发布的一键安装命令。资料中给出的是 IH-1 候选安装脚本，并且明确标注该候选尚待独立验收；在 IH-1 合并前，该脚本不在 main，因此暂不作为已发布的一键安装命令。
候选脚本路径为：
scripts/install-dsh-governed-workflow.mjs
候选调用方式为：
node scripts/install-dsh-governed-workflow.mjs --profile governed --ref <40位 Git commit SHA>
这一步要求显式提供 DSH profile 和 immutable source ref，不默认安装浮动的 main。
安装后执行：
dsh --profile governed --dump-config
这一步用于确认 Governed Workflow 的五个默认组件已经加载。当前候选脚本不会自动启用可选的 GitHub Issue network-authority bootstrap。
包信息与安装边界¶
已核实的 package.json 字段显示，该插件声明了以下权限列表：
[
"harness:tool",
"harness:skill",
"harness:guard",
"session:append",
"network:read",
"credentials:none",
"subprocess:none",
"native-code:none"
]
其他已显示的字段包括：
{
"name": "dsh-governed-workflow",
"version": "0.1.0",
"license": "MIT",
"type": "module",
"dshVersions": ["0.1.0-rc.6"]
}
安装相关字段为：
{
"install": {
"mode": "transactional",
"adapter": "profile-bundle",
"failurePolicy": "generation-rollback",
"touchesCurrentBeforeActivation": false
},
"lifecycle": {
"activation": "restart-profile",
"dispose": "unknown"
}
}
需要注意：资料中的 package.json 已截断，未显示完整字段，不能据此补全其他配置。README 中出现的 V0.9 Developer Technical Preview 与 package.json 中的 version: 0.1.0 可能表示不同版本体系，本文不将其统一为同一个版本号。
典型用法¶
经过上面的安装和配置确认步骤后，工作流大致按以下顺序推进：
1、任务 authority 来自公开 GitHub Issue 中的机器可解析 authority block。资料没有给出 authority block 的具体格式，因此这里不展开格式细节。
2、任务状态按 lifecycle 状态机推进：
AUTHORITY_OBSERVED → TASK_ADMITTED → RUNNING
3、只有在 accepted authority 已存在，且状态为 RUNNING 时，受保护的 bash、write、edit 才允许执行。否则执行会被拒绝。
4、任务结束后进入终态：
BLOCKED
COMPLETED
REVIEW_PENDING
进入这些状态后，受保护修改会再次被禁止。
5、验收发生在 Builder Runtime 之外。Builder 不能自行 ACCEPT、merge、关闭已接受任务，也不能创建或激活后续任务。
适用场景与注意¶
这种流程比自由式 vibe coding 多了 Issue、状态迁移和 Review 的流程成本，因此会牺牲一部分速度。它更适合需要明确停止条件、审查、回滚和验收的项目。
更适合：
- 中等及以上规模项目
- 多文件修改
- 长会话任务
- 多阶段交付
- 需要运行命令或修改真实代码的场景
- 上线或数据风险较高的 vibe-coding 项目
- App、后端服务、研究工具、自动化系统和长期维护仓库
不太适合：
- 一次性小脚本
- 几分钟的 throwaway prototype
- 完全可丢弃的实验
- 治理成本明显高于收益的场景
使用上需要特别注意：这不是完整 OS sandbox。allowedPaths 文件系统硬隔离、Git 命令语义、GitHub merge/close API 等仍不是 Runtime 强制边界。插件会以当前 DSH 进程权限运行，因此安装前应检查源码、许可证、权限字段和候选安装脚本状态。
链接与后续¶
dsh-governed-workflow 的价值在于把 Agent 的任务权限、生命周期和验收边界显式化：先有 authority，再允许 RUNNING 期间的受保护修改，终态冻结后交给独立验收。
社区目录页 URL 未在已核实资料中出现，本文不补充未确认链接。当前可核验的仓库地址为：
https://github.com/zcx369658780/governed-workflow-for-dsh
