Ruszero01/dsh-tang-governance

面向 DeepSeek Harness 的、感知规模并在运行时强制执行的多智能体治理模式。

English · 简体中文

Tang Governance

Tang Governance 是一个独立的 npm 包，为 DeepSeek Harness 添加了三省六部开发模式。它不会修改 Harness 源代码。

该插件将单个编码请求转化为可审计的工作流，包括需求澄清、独立评审、显式用户批准、基于职责的执行、验收测试以及用户控制的收尾关卡。运行时检查会强制执行重要边界，而不是仅依赖提示词。

灵感来自唐代的行政结构；为现代 AI 智能体软件交付而设计。

亮点

- 感知规模的受理 — 中书省将请求分类为小型、中型或大型，并让简单任务避免不必要的全流程循环。
- 起草前先澄清 — 模糊需求会在编写方案之前暂停于原生选择界面。
- 独立评审与副署 — 门下省独立评审规格说明，并可退回具体问题。
- 显式用户关卡 — 在获得批准之前无法开始实现；在最终验收和用户确认之前，案件无法关闭。
- 统一的部门路由 — 尚书省会使用相同规则扫描全部六个职责域，仅派遣有实质性贡献的部门。
- 运行时强制边界 — 委派层级、部门角色、依赖关系、验证、批准和收尾均由代码校验。
- 可观测执行 — 响应式组织图、可折叠阶段时间线、每个智能体的 token 用量、实时状态和部门记录都集中显示在一个仪表盘中。
- 稳定的模型继承 — 三省可独立路由；六部继承尚书省的 provider 和 model，同时使用适合任务的推理强度。
- 持久案件文件 — 每个任务都会在 .tang/cases/<case-id>/ 下生成结构化卷宗。
- 工作区知识 — 每个新案件都会收到一个紧凑的共享索引，仅在需要时展开相关细节或源卷宗，并允许中书省将可复用发现去重为一份规范文档。
- 可恢复的停止语义 — 用户可随时停止工作，而不会丢弃已完成的产物。

产品导览

原生模式入口
直接从 Harness 预设菜单中选择治理模式。

组织架构图 + 实时追踪
部门状态、路由控制、真实调用、阶段与 token 用量共享同一个响应式视图。

规划前先澄清
当原始请求含糊不清时，中书会在起草前提出针对具体任务的问题。

可审查的审批关卡
经会签的 Markdown 提案会在专门的审批工作区中呈现。

可审计的部门记录
部门卡片无需离开仪表盘即可展示按时间顺序排列的阶段、证据与最终状态。

用户可控的结案
验收证据、产出物、风险与纪要在案件结案前始终可供审查。

安装

要求：

- Node.js ^22.19.0 || >=24
- DeepSeek Harness 0.1.1-rc.2 或兼容的 0.1.x 版本

从本地检出安装：

~~~bash
git clone https://github.com/Ruszero01/dsh-tang-governance.git
cd dsh-tang-governance
pnpm install
pnpm run check
dsh plugin --profile web add link:.
dsh web --no-open
~~~

打开 http://127.0.0.1:3080 并为新任务选择该模式。

首次启动时，插件会通过公开的 Agent Preset API 复制已安装的 Harness Standard mode，并追加其治理工具。因此，Shell、文件操作、技能、目标、计划、子代理与工作流原语都遵循已安装的 Harness 版本，而非冻结的源代码副本。

工作流

~~~text
用户请求
↓
中书 — 受理、规模评估、澄清、需求、起草
↓
门下 — 独立审查与可执行规范
↕
中书 + 门下 会签
↓
用户审批关卡
↓
尚书 — 分阶段计划与统一的六部扫描
↓
选定的各部 — 实现、基础设施、数据、接口或验证
↓
门下 — 最终验收
↓
中书省——最终报告、纪事与可复用知识提炼
↓
用户关闭关口
~~~

阶段归属

| 阶段 | 负责方 | 结果 |
|---|---|---|
| 接收 | 中书省 | 理解原始请求，判定其规模，仅提出阻塞性问题。 |
| 需求与草案 | 中书省 | 编写决策级需求与方案草案，不规定函数级补丁。 |
| 独立评审 | 门下省 | 验证范围、风险、验收标准，并产出最终可执行规范。 |
| 会签 | 中书省 + 门下省 | 就同一规模与规范达成一致；仅退回具体未决问题。 |
| 批准 | 用户 | 在创建任何执行部门之前批准、附反馈退回或取消。 |
| 执行规划 | 尚书省 | 编写 05-phased-development.md，扫描各部领域，记录分派与遗漏，并排列依赖顺序。 |
| 各部执行 | 选定的各部 | 产出有边界的代码、配置、文档、度量或独立证据。 |
| 验收 | 门下省 | 验证已批准的规范与分阶段计划；将失败项退回尚书省。 |
| 报告 | 中书省 | 编写案例本地报告与纪事，然后仅将可复用、有来源引用的发现更新至工作区知识库。 |
| 关闭 | 用户 | 可选地请求任务特定的手动检查，然后关闭、退回或取消。退回反馈会自动返回中书省；协调者仅转达其问题并安排所需的后续跟进。 |

任务规模是软性规划信号，而非硬性 token 上限。小型请求应保持紧凑，而困难工作可在证据或实现需要时扩展。仅由显式用户或部署配置设置 maxTokens。

六部

尚书省对全部六个部门应用相同的匹配流程。不偏好、不强制、不豁免任何部，也不将其用作通用回退。

| 部 | 领域 | 负责 | 不负责 |
|---|---|---|---|
| 吏部 / 吏部 | repository-governance | 仓库勘察、模块归属、任务分解、依赖关系与交接顺序 | 产品实现或测试批准 |
| 户部 / 户部 | data-dependencies | 数据与状态模型、迁移、依赖资源、性能影响及相关实现 | 无关产品功能或最终验收 |
| 礼部 / 礼部 | interfaces-documentation | API/UI 契约、兼容性、无障碍、文档、用户体验及相关实现 | 无关基础设施或最终验收 |
| 兵部 / 兵部 | application-code | 产品行为、核心应用代码、重构与代码迁移 | 自我批准或默认构建/发布工作 |
| Justice / 刑部 | quality-security | 独立测试、复现、安全与权限审查，以及回归验证 | 实现当前正在接受独立审查的功能 |
| Works / 工部 | infrastructure-release | 构建系统、开发工具、基础设施、集成、打包、部署和发布 | 通用产品实现或替代独立验证 |

尚书不是第七个实现代理。它负责调度、依赖协调、证据收集和阶段推进。每个部门要么被分配具体工作，要么收到具体的省略原因。对于涉及代码变更的阶段，每个实现任务都必须由一个独立的刑部验证依赖项覆盖。

运行时保证

该插件在代码中强制执行以下规则：

- 根协调器只能创建三省。
- 只有尚书可以创建六部。
- 中书、门下和六部不能进一步委派。
- 尚书必须在派遣各部之前注册结构化的阶段计划。
- 每个任务都引用匹配的部门、角色、推理强度、交付物、验证方法和依赖集。
- 失败的依赖项不会解锁下游任务。
- 在可以创建尚书之前，必须同时具备成功的审批结果和随后的 user-approval: passed 里程碑。
- tang_submit_final_report 需要成功的 menxia-acceptance: passed 里程碑。
- 内置的关闭决策和重复的验证选项会被安全地过滤，因此已完成的运行不会因冗余的模型输出而失败。
- 该插件使用公开的 Harness 扩展点，不依赖私有的 experimental/agent-team 包。

模型路由

组织视图可以为中书、门下和尚书设置提供商、模型和推理强度。设置存储在 Harness Settings 命名空间 tang-governance 中，并通过公开的请求路由瀑布应用。

六部从不选择独立的模型。它们继承尚书当前的提供商、模型和显式的 maxTokens；尚书为每个注册的任务选择适合任务的推理强度。不支持的推理级别会回退到模型声明的默认值，而不是使派遣失败。

可选的部署默认值可以添加到 Harness Home 下的 .agent-presets/tang/agent.cordis.yml 中：

~~~yaml
- id: tang-governance-tool
name: 'dsh-tang-governance/tool'
config:
autoDispatch: true
subagentProvider: spawn
offices:
zhongshu:
provider: deepseek-official
model: deepseek-v4
reasoningEffort: high
maxTokens: 16000
menxia:
provider: deepseek-official
model: deepseek-v4
maxTokens: 16000
shangshu:
provider: deepseek-official
model: deepseek-v4
~~~
autoDispatch 默认为 true。禁用后，在协调器首次调用模型之前，首个请求不再被强制派发。

案例档案

每个案例都使用以下持久化布局：

~~~text
.tang/
config.json
workspace-knowledge.md
cases//
01-requirements.md
02-draft-solution.md
03-review.md
04-spec.md
05-phased-development.md
06-final-report.md
07-chronicle.md
~~~

分阶段计划记录目标、变更面、边界、依赖、各部交付物、验证、风险、检查点和回滚方案。函数体与具体补丁仍由所选部门作为实现决策保留。

workspace-knowledge.md 是唯一的跨案例知识来源。其精简索引在受理时注入；智能体仅在需要时展开所选条目及其引用的案例产物。稳定的语义键会合并修正与新证据，而不是创建重复笔记。案例时间线保留在 07-chronicle.md 中；共享文档仅保留可复用的决策、约束、模式、陷阱和验证经验，并附来源案例 ID。

贡献

欢迎贡献——代码、文档、测试和报告。请先阅读 CONTRIBUTING.md。安全漏洞应按照 SECURITY.md 私下报告。

三省六部治理插件

三省六部治理插件是面向 DeepSeek Harness 的独立 npm Bundle，不修改 Harness 源码。

它把一条开发需求组织成可审计的智能体协作流程：需求澄清、独立审议、用户审批、按职责执行、最终验收、结案汇报与用户确认。关键边界由运行时校验，不只依赖提示词约束。

以唐代三省六部制度为灵感，为现代 AI Agent 软件交付提供清晰的职责分离与治理机制。

返回英文 · 查看产品截图

核心特性

- 按量级受理：中书省只判断任务量级，避免简单需求运行冗长流程。
- 起草前澄清：需求存在阻塞性歧义时，先通过原生选择界面询问用户，再继续起草。
- 独立审议与会签：门下省独立审查规格，并可针对具体问题封驳。
- 明确的用户门禁：批准前不能进入执行，终验和用户确认前不能结案。
- 六部统一扫描：尚书省按相同规则扫描六个职责域，仅调度能产生实际贡献的部门。
- 运行时职责约束：派发层级、部门角色、依赖、独立验证、审批与结案均由代码校验。
- 可视化执行：响应式架构图、可折叠阶段时间线、部门记录、实时状态和 Token 统计集中展示。
- 稳定模型继承：三省可分别路由模型，六部统一继承尚书省的 provider 和 model，再按任务调整思考等级。
- 持久化案卷：每个任务在 .tang/cases/<case-id>/ 下留下结构化文档。
- 工作区知识案卷：新案只预载共享索引，按需展开相关详情与原案证据，并由中书省将可复用结论去重写入唯一知识源。
- 可恢复叫停：用户可随时叫停任务，同时保留已经完成的产物与证据。

安装

环境要求：

- Node.js ^22.19.0 || >=24
- DeepSeek Harness 0.1.1-rc.2 或兼容的 0.1.x 版本

从本地仓库安装：

~~~bash
git clone https://github.com/Ruszero01/dsh-tang-governance.git
cd dsh-tang-governance
pnpm install
pnpm run check
dsh plugin --profile web add link:.
dsh web --no-open
~~~

打开 http://127.0.0.1:3080 即可开始使用。

新建任务时选择 三省六部模式。

插件首次启动会通过公开的 Agent Preset API 复制当前 Harness 安装版本的“标准模式”，再附加治理工具。因此 Shell、文件操作、Skills、目标、计划、子 Agent 和工作流等基础能力会跟随 Harness 版本更新，不会锁死在插件开发时的源码副本。

治理流程

~~~text
用户需求
↓
中书省：受理、量级判断、澄清、需求与草案
↓
门下省：独立审议与可执行规格
↕
中书省 + 门下省会签
↓
用户审批门
↓
尚书省：阶段计划与六部统一扫描
↓
按需启用六部：实现、数据、接口、基础设施或独立验证
↓
门下省最终验收
↓
中书省最终报告、史官记录与经验沉淀
↓
用户结案门
~~~
| 阶段 | 负责人 | 产出与约束 |
|---|---|---|
| 受理 | 中书省 | 理解原始需求、判断量级，只询问阻塞性问题。 |
| 需求与草案 | 中书省 | 编写决策层需求和方案，不预先规定函数级补丁。 |
| 独立审议 | 门下省 | 审查范围、风险和验收标准，形成最终可执行规格。 |
| 两省会签 | 中书省、门下省 | 对同一量级与规格达成一致，只针对实际未决问题封驳。 |
| 用户审批 | 用户 | 批准、附意见驳回或取消；批准前不创建执行部门。 |
| 执行规划 | 尚书省 | 编写 05-phased-development.md，扫描六部职责、记录派发与省略理由、排序依赖。 |
| 六部执行 | 按需选择的部门 | 交付有边界的代码、配置、文档、度量结果或独立证据。 |
| 最终验收 | 门下省 | 按批准规格和阶段计划验收，失败则退回尚书省。 |
| 奏报 | 中书省 | 根据真实执行和验收证据编写本案报告与史官记录，再将有复用价值且标明来源的知识合并到工作区知识案卷。 |
| 结案 | 用户 | 可先要求任务相关的手动检查，再确认、驳回或取消。驳回意见由运行时自动交回中书省，协调器只转交其澄清问题并调度必要的后续流程。 |

任务量级是用于精简规划的软性信号，不是固定 Token 上限。简单任务应保持紧凑，复杂任务可根据证据、实现和验证需要扩展。只有用户或部署配置显式设置的 maxTokens 才会成为请求上限。

六部职责

尚书省使用同一匹配流程扫描六部。不存在默认优先、强制启用、豁免或兜底部门。

| 部门 | 职责域 | 负责 | 不负责 |
|---|---|---|---|
| 吏部 | repository-governance | 仓库勘察、模块归属、任务拆分、依赖和交接顺序 | 产品实现、测试放行 |
| 户部 | data-dependencies | 数据与状态模型、迁移、依赖资源、性能影响及相关实现 | 无关业务功能、最终验收 |
| 礼部 | interfaces-documentation | API/UI 契约、兼容性、无障碍、文档、用户体验及相关实现 | 无关基础设施、最终验收 |
| 兵部 | application-code | 产品功能、核心代码、重构与代码迁移 | 自我验收、默认承担构建发布 |
| 刑部 | quality-security | 独立测试、缺陷复现、安全权限审计、回归验证 | 实现自己正在验收的功能 |
| 工部 | infrastructure-release | 构建系统、开发工具、基础设施、集成、打包、部署发布 | 兜底业务开发、替代刑部验证 |

尚书省不是第七个实现 Agent，只负责调度、依赖协调、证据收集和阶段推进。每一部都必须被派发实际任务或记录具体省略理由。任何修改代码的阶段，其实现任务都必须由独立的刑部验证任务覆盖。

运行时保证

插件通过代码强制执行以下规则：

- 顶层协调器只能创建三省。
- 只有尚书省可以创建六部。
- 中书省、门下省和六部不能继续派发。
- 尚书省必须先登记结构化阶段计划，再派发六部。
- 每项任务都必须匹配部门、角色、思考等级、交付物、验证方法和依赖。
- 失败的依赖不会解锁后续任务。
- 创建尚书省前，必须同时存在成功的用户审批结果和随后记录的 user-approval: passed 里程碑。
- tang_submit_final_report 只有在 menxia-acceptance: passed 后才能调用。
- 内置结案选项和重复验证选项会被安全过滤，不再因为冗余模型输出让已完成流程显示失败。
- 插件只使用 Harness 公开扩展点，不依赖私有的 experimental/agent-team 包。

模型路由

组织架构图可分别设置中书省、门下省和尚书省的 provider、model 与 reasoning effort。设置保存在 Harness Settings 的 tang-governance 命名空间，并通过公开请求路由生效。

六部不设置独立模型，始终继承尚书省当前的 provider、model 和显式 maxTokens；尚书省只为具体任务选择合适的思考等级。不支持的 reasoning level 会回退到模型声明的默认值，不再导致派发失败。

可在 Harness Home 的 .agent-presets/tang/agent.cordis.yml 中设置部署默认值：

~~~yaml
- id: tang-governance-tool
name: 'dsh-tang-governance/tool'
config:
autoDispatch: true
subagentProvider: spawn
offices:
zhongshu:
provider: deepseek-official
model: deepseek-v4
reasoningEffort: high
maxTokens: 16000
menxia:
provider: deepseek-official
model: deepseek-v4
maxTokens: 16000
shangshu:
provider: deepseek-official
model: deepseek-v4
~~~

autoDispatch 默认为 true。关闭后，运行时不再在协调器第一次模型请求前强制派发原始需求。

案卷目录

每个任务使用以下持久化结构：

~~~text
.tang/
config.json
workspace-knowledge.md
cases//
01-requirements.md
02-draft-solution.md
03-review.md
04-spec.md
05-phased-development.md
06-final-report.md
07-chronicle.md
~~~

阶段计划记录目标、变更面、边界、依赖、六部交付物、验证、风险、检查点与回滚。函数实现和具体补丁由被选中的执行部门自行决定。
workspace-knowledge.md 是同一工作区唯一的跨案知识源。新案受理时只注入精简索引，确有相关经验时再按知识 ID 展开详情，必要时继续读取条目引用的原案文件。稳定语义键用于合并修正和新增证据，避免重复记录；执行流水仍留在各案 07-chronicle.md，共享文档只保留带案卷来源的可复用决定、约束、模式、踩坑和验证经验。

参与贡献

欢迎任何形式的贡献——代码、文档、测试与问题反馈。请先阅读 CONTRIBUTING.md；安全漏洞请按 SECURITY.md 私下报告。

License

MIT