前言¶

在 DeepSeek Harness（DSH）里用单个 Agent 完成改代码、写文档、查证材料时，常见两类问题：做完就由模型自行宣布「已完成」，缺少独立于执行方的验收；方向偏离后仍沿原路继续，token 与时间成本持续上升。单轮对话很难在同一进程里同时承担「定标准、动手做、按标准判」三种职责。

下面介绍社区插件 dsh-council（循环决议 · Council）。它在 DSH 上依托 Agent Teams，把与你对话的 Leader、执行者、检验者拆成三个独立上下文的智能体，用可判定的验收标准和有限轮次的派活→检验循环，把「完成」交给检验者与 Leader 终检，而不是执行者自评。本文依据 GitHub 仓库 README 与 package.json 整理，安装与配置以原文为准。

这是什么¶

dsh-council 由维护者 0131kikimy 发布，在 SkillHub 插件目录 分类为「工作流」。package.json 版本为 0.1.0，许可证 MIT。

一句话定位：Leader 与用户对话并登记任务与标准，执行者按简报动手并附证据回报，检验者逐条判定 PASS/FAIL（默认禁用写文件工具），不达标自动进入下一轮；达标后 Leader 抽查并 council_finish 交付。六个 council_* 工具仅注册在 Leader 侧，成员在机制上不能改标准或自行宣布通过。

插件以当前 DSH 进程权限运行；安装前请自行查看源码与许可证。社区目录 SkillHub 为独立站点，与 DeepSeek / 幻方无官方从属关系。

它解决什么问题¶

README 用表格归纳了两类毛病及对策：

代价是多轮往返与额外 token，因此适合可检验的实活（改代码、写文档、查证材料），不适合闲聊和一次就能答完的问题；指令里也要求 AI 自行判断是否滥用。

三个角色与上下文隔离¶

        你（用户）
          │  对话
          ▼
   ┌──────────────┐
   │    Leader    │
   │  理解/判断/交付 │
   └──┬────────┬──┘
      │派活     │送检
      ▼        ▲
 ┌─────────┐  ┌──────────┐
 │ 执行者   │─▶│ 检验者    │
 └─────────┘  └──────────┘

执行者与检验者不知道你与 Leader 的完整聊天内容；信息经插件拼装的简报传递，成员只看到「这一轮该干什么」。Leader 不能代替执行者动手；检验者不能改标准、不能宣布通过。

核心能力与工作流程¶

开局与标准¶

Leader 调用 council_start，登记 task 与 3～6 条 criteria（须可被第三方判定，例如路径、命令、证据），并创建 executor 与 verifier 成员。坏标准如「代码质量要好」不可判定；好标准如「npm test 退出码为 0」可判定。

派活与送检¶

• council_send(to="executor")：插件自动拼装派活简报（轮次、任务、标准、写入范围、回报格式）；Leader 仅用可选 note 补上下文（≤500 字），不重复粘贴全文。
• council_send(to="verifier", report=...)：送检简报要求检验者逐条输出 PASS/FAIL、证据与必须修的问题；无证据判 FAIL。

裁决与循环¶

council_verdict：PASS 则阶段转 ready，Leader 再抽查后 council_finish；FAIL 则开下一轮并把 fixes 附到任务。默认最多 2 轮（maxRounds 可配 1～8），到顶进入 escalated，交回用户。

Leader 还可通过 council_verdict(criteria=[...]) 修订标准，或通过 council_policy(deny=[...]) / allow 对成员收权、放权。council_status 查看轮次、阶段、成员与裁决历史。

兼容的 Harness 版本为 0.2.2-rc.1 系列（依赖 ctx.agentTeams、ctx.tools.restrict 等）。

安装与启用¶

前置条件¶

1. DeepSeek Harness 桌面版或 CLI。
2. 已启用 Agent Teams（@deepseek-ai/dsh-experimental-agent-team；若报错缺 Agent Teams，还需 @deepseek-ai/dsh-experimental-tool-agent-team）。
3. Node.js ≥ 22.19.0（见 package.json 的 engines）。

安装步骤¶

1. 将本插件仓库放到任意目录，例如 ~/dsh-plugins/dsh-council（README 未给出 dsh plugin add github:... 一类命令，以目录 + bundle 安装为准）。
2. 在 DSH 中让 AI 执行安装，或直接调用插件管理器：

安装插件：install_bundle，target 填本目录的绝对路径

3. 看到 application: applied 即安装成功。
4. 重开会话（已有会话保持启动时的插件版本）。

验证¶

在新会话中询问「现在有哪些 council 工具？」，应列出：council_start、council_send、council_verdict、council_policy、council_status、council_finish。也可调用 council_status，未开局时可见 阶段：idle　轮次：0 等提示。

装好后无需额外配置即可用自然语言提需求；Leader 会判断是否开局。也可直接指挥，例如收紧标准、叫停、收回执行者写文件权限。

配置项（可选）¶

通过 cordis.patch.yml 的 config 或在 profile 的 patch 层覆盖。节选默认值：

放宽到 3 轮并给检验者额外禁用 shell 的示例：

- insert:
    - id: dsh-council
      name: dsh-council
      config:
        maxRounds: 3
        verifierDenyTools:
          - write
          - edit
          - apply_patch
          - bash
          - ops_bash

非法配置会抛错，不会静默回落默认值。

典型用法示例¶

适合开局的表述（明确、可检验）：

帮我把 X 功能实现出来，并且保证有测试。

帮我查证「某说法」是否成立，要给出可追溯的来源。

不建议用 council 跑一句话能答完的问题（例如「这个报错是什么意思？」）。

用户侧指挥循环（README 原文示例）：

这轮标准太松了，把第 2 条改成「必须有实际命令输出作为证据」再重来。

检验者老挑毛病但都不是成果问题，停了吧，把情况告诉我。

别再让执行者改文件了，把它的写文件权限收回来。

若装好但 AI 不用，可直接说「用 council 跑这个任务」。

适用场景与注意¶

• 适合：验收标准能写成可检查条目（文件路径、命令退出码、标题结构等）的任务。
• 不适合：不可检验的创意、闲聊；会明显增加延迟与 token。
• 安全：插件与 Agent 成员共享 DSH 进程能力；收权用 council_policy 才是真限制，而非仅靠提示词。
• 卸载：remove_bundle，target 填 dsh-council，重开会话；.council/ 可手动删除。

开发者可在插件目录执行 npm test，期望看到 ALL LOCAL TESTS PASSED 与 SMOKE PASSED（见 README）。

结尾¶

dsh-council 把「定标准—执行—验收—返工」固化进 DSH 工作流：独立简报降低无关上下文 token，工具权限不对称保证检验者只判不动手，轮次上限避免空转。需要多智能体协作且任务可检验时，可按 README 用 install_bundle 安装并重开会话验证六个 council 工具。

• 目录页：https://www.skillhub.cn/plugins/0131kikimy/dsh-council
• 源码与说明书：https://github.com/0131kikimy/dsh-council