团队纪律约束 141w/dsh-quorum

dsh-quorum

为 DeepSeek Harness 智能体团队提供机制层面的纪律约束。

一支编码智能体团队通常会在四个地方翻车：谁都能碰任何东西，没人知道讨论什么时候结束，账单事后才到，一份自信满满的报告被当成已经核实过的结论。像 firstmate 这样的项目解决了这些问题——但只是靠好好请求模型配合，因为终端 harness 没给它们别的地方挂钩子。

dsh-quorum 把这四条纪律落到机制层面。只读审查者不是选择不去改文件，而是根本改不了。

这是一个插件包，不是运行时。会话、模型请求、工具、智能体循环、花名册、邮箱、任务板和 Web UI 全部仍归 dsh 所有。这个包只在上面加一层策略——而且它读的是 dsh 已经记录的持久化事实。

安装

需要 dsh 0.2.0-rc.2 或兼容版本。三个包必须装进同一个配置档，顺序如下：web 应用、实验性 Agent Teams 配置档，最后是这个。

dsh plugin --profile <name> add -w @deepseek-ai/dsh-web-app@0.2.0-rc.2
dsh plugin --profile <name> add -w @deepseek-ai/dsh-experimental-agent-team-profile@0.2.0-rc.2
dsh plugin --profile <name> add -w github:141w/dsh-quorum

目前就用 github: 这种方式安装。这个包还没发布到 npm，所以 add dsh-quorum 解析不到任何东西，应用内搜索也找不到它——dsh 没有插件市场，只有一个表单，接受包名、GitHub 仓库或本地目录。让 dsh 插件能在 npm 上被搜到靠的是关键词约定（dsh、dsh-plugin、deepseek-harness），这个包已经声明了这些关键词，等发布后就能生效。

第一条命令很慢，但它没卡住。 @deepseek-ai/dsh-web-app 会拉将近 300 个包；在这台机器上实测花了 20 分钟，中间自动重试了一次 socket 超时。另外两条只要几秒。

如果你在意实际跑的是什么代码，就锁定版本——上游自己的建议就是锁定 revision，否则默认分支后续一次 push 就会改变安装时执行的代码：

dsh plugin --profile <name> add -w 'github:141w/dsh-quorum#v0.1.0'

已验证：7.6 秒解析完成，配置档里记录为 github:141w/dsh-quorum#v0.1.0，--dump-config 里仍然能看到 # == dsh-quorum 这一层。

从本地 checkout 安装效果完全一样，本文档就是用这种方式验证的：

dsh plugin --profile <name> add -w /path/to/dsh-quorum

跳过下面这三件事，你会踩坑：

1. 永远锁定版本。 对 @deepseek-ai/dsh-experimental- 这些包来说，latest dist-tag 指向的是更老的一条线（0.1.5-alpha.2），而不是和运行时匹配的 0.2.0-rc.2。不带版本号安装，你会得到一个静默加载失败的包。
2. 始终传 -w。 配置档本身就是一个 pnpm workspace，根目录就是配置档自己，所以 pnpm add 不加 --workspace-root 会直接拒绝（ERR_PNPM_ADDING_TO_ROOT）。
3. 智能体团队不是可选项，而且失败时悄无声息。 这个包会注入 agentTeams 服务。不装智能体团队包就安装它，插件永远不会激活——你只会看到一行警告，别的什么都没有：

dsh: warning: 1 entry did not activate
quorum (dsh-quorum): pending (waiting for service: agentTeams)

实测结果，不是假设：把 github:141w/dsh-quorum 装进全新配置档再启动，输出就是这样。

不启动任何东西也能验证——# == dsh-quorum 这行注释就是该层的来源标记：

dsh --profile <name> --dump-config | grep -A 12 "id: quorum"

然后启动（dsh --profile <name> --no-open 会打印一个带 token 的 URL），打开 Plugins 页面——智能体团队和 dsh-quorum 都应该处于开启状态。

github: 安装不跑构建步骤，所以 pnpm 不会要求你授权：这个包直接发布可运行的源码，并且刻意不声明 prepare 脚本。需要编译的 TypeScript 包则会逼着每个安装者在配置档的 pnpm-workspace.yaml 里把它加进 allowBuilds。

它约束什么

| 纪律 | 机制 | 验证状态 |
| 能力 —— 角色不能做没被授予的事 | 工具边界上的逐智能体单调守卫；拒绝会以 tool/result 形式出现，带 isError: true | ✅ 实测，三条路径：scout 写操作被拒，ship 越界写被拒，lead 放行 |
| 终止 —— 提交到达，讨论就结束 | quorum_wait，Lead 专属工具，阻塞在持久邮箱上（team/message/queued 减去 delivered） | ✅ 实测，两条路径：NOT met 并给出可操作的指引，以及 met — 1/1 |
| 证据 —— 报告只有锚定到真实工具运行才算数 | 通过 ctx.sessions.get() 读取成员自己的会话日志 | ✅ 实测：一个队友纯凭常识汇报，日志里零工具调用，闸门拒绝计数——判定 0/1 … backed by tool evidence |
| 成本 —— 有预算，触顶时优雅降级 | 从 assistant/message 用量事件统计 token；分级先停新成员，再停写操作 | ⚠️ 三个分级都做了行为单元测试，从未实测触发（实测触发需要约 280K token 的真实工作） |

标题栏还有一个可见入口：官方团队入口旁边的 Quorum 按钮，列出绑定到本 Team 的角色卡、每个成员的阶段，以及共享任务板及其写作用域警告。没有 Team 的会话上它什么都不渲染。

两条设计规则是承重的，也很容易被破坏：
- 汇报是权利，不是特权。 send_message 和 present 不受 allow 列表限制。一旦受限，侦察型智能体永远无法提交，法定人数永远无法凑齐，而且不会有任何东西大声报错——12 个通过的测试没抓到这个问题，只有实际跑一遍才发现。
- 普通会话靠代码豁免，不是靠运气。 只有会话真正拥有队友之后，才会被管控。否则改一下 lead 卡片，就会悄悄收紧机器上所有无关的对话。

配置

所有内容都在 bundle 的 cordis.patch.yml 里，所以用户可以从自己的配置档补丁覆盖，不用碰这个包。注意，补丁层会替换整行的 config，不做深度合并——覆盖时要把需要的每个键都重新写一遍。

roles:
lead: { shape: ship, writeScopes: [], maxMembers: 4 }
reviewer: { shape: scout, allow: [read, read_image, grep, glob, list] }
fixer: { shape: ship, writeScopes: ["src/", "tests/"] }
defaultRole: { shape: scout, allow: [read, read_image, grep, glob, list] }
budget: { maxBilledTokens: 400000, softTier: 0.7, hardTier: 0.9 }
quorum: { requires: all, timeoutMs: 300000, pollMs: 30000 }
debug: { logExemption: false }

- 角色绑定的是队友的持久 Team 名称，不是提示词里怎么写它。
- writeScopes: [] 表示不限制，不是禁止。
- 没列出的队友会拿到 defaultRole，也就是 scout：没人声明的角色，不会默认获得修改 checkout 的信任。
- pollMs 必须 ≥ 10000——上游的 change-wait 会拒绝更短的超时。
- 计费 token 是 input + output，刻意不采用官方 UI 显示的数字。参见 docs/architecture.md 里的计费说明。

已知限制

信任它之前先读这些。它们都是实测出来的，不是假设。

- 头部面板显示的内容少于插件掌握的信息。 client.js 只注册了一个 conversation.session.header.actions 占位：绑定持久名册的角色卡片、成员阶段、任务板及其 writeScopeWarnings。它不显示法定人数进度、证据裁定或预算档位，因为浏览器根本收不到这些——agentTeam 投影的线上形态是 {members, tasks, failure}，邮箱留在服务端。要把这些展示出来，需要一个 dsh-api- 风格的远程服务，那是下一块机器，不是样式活。
- quorum_wait 从不唤醒沉默的成员，也从不重发。 它只等待持久状态。如果某个成员不活跃，Lead 必须 send_message 它，然后再调一次——上游的 wait_agent 明确拒绝唤醒不活跃的队友，所以这不是我们能诚实补上的缺口。
- writeScopes 是子串匹配。 src/../secrets 能走出去。它防的是模型犯错；它不是安全边界。真正的边界需要比较解析后的路径。
- writeScopes 重叠不会产生警告。 实测：writeScopeWarnings 全程保持 []。真正防止工作丢失的是文件系统层面的乐观并发保护（FS_STALE_VERSION），不是任务板。
- 预算归属从 agent/created 开始。 成员在 session→team 映射建立之前产生的用量不计入。
- 被拒绝的操作只有在模型尝试时才会留下记录。 Lead 从不要求 scout 写入，就完全不会产生拒绝记录。
- 上游还是 alpha。 dsh 0.2.x 明确说明会有破坏性变更。这个 bundle 只绑定有文档的接缝和生成的 API 表面。

Development

没有构建步骤 —— 插件是纯 ESM，零 import，因为链接的包如果 import 宿主包却没声明 peerDependencies，会静默导入失败。

npm run build # node --check index.js && node --check client.js
npm test # 27 tests

client.js 是浏览器端那一半，通过 package.json 里的 dsh.client 声明，作为 combo bundle 的一部分提供。它是纯 React.createElement，没有构建步骤，除了 react 这个 seed word 之外没有依赖；它通过 ctx.locale 注册字典，并通过 ctx.slots.inject 注册一个 slot occupant。

想试试？docs/TESTING.md 里有六个场景，每个都给出确切命令，用来检查持久证据，而不是相信助手自己的报告。

docs/verification.md 记录了上面每条结论的原始命令和原始输出，包括失败的部分。docs/D2-finding.md、docs/D3a-verified.md 和 docs/D5-live-verified.md 记录了改变设计的几个结果：插件无法贡献持久会话事件类型（写入一个会让会话永久无法打开），豁免必须靠正面证据证明，而不是靠沉默，以及一个在回合中途武装的工具，如果不告诉模型，就是不可见的。

License

MIT —— 见 LICENSE。