霍格沃茨循环 dyikai/dsh-hogwarts-loop

Hogwarts Loop

dsh-hogwarts-loop

计划 → 构建 → 评审 → 提交，做成 DeepSeek Harness 插件。 每位角色一个子代理，各自跑在自己可配置的模型上。

@dyikai/dsh-hogwarts-loop 把 hogwarts-loop 这套纪律打包成插件：把大型工程任务从计划推进到评审通过、提交入库，全程拆成一个个小检查点，每个检查点独立验证。方法论以技能形式提供，每位角色都是受管理的子代理，通过同一个工具启动，每个角色背后的模型在客户端里设置，而不是写死在提示词里。

新增了什么

| 能力 | 形式 | 位置 |
| 循环方法论与各角色的详细职责 | hogwarts-loop 技能（也可用 /hogwarts-loop 触发） | skill/SKILL.md、skill/references/.md |
| 问题记录、批量校验、收敛上限与评估指南 | markdown 契约 + 合成种子用例 | skill/references/review-contract.md、skill/references/evaluation.md、skill/assets/eval-.md |
| 在同一个父会话里创建或继续同一位角色 | hogwarts_dispatch 工具 | 由 index.js 注册 |
| 按角色编辑服务商 / 模型 / 推理强度 / 输出上限 | Settings → Hogwarts Loop，以及插件页里本插件那一行 | client.js（浏览器端） |

// First call creates Harry; after CP1 passes, the next call continues him.
hogwarts_dispatch({ role: "harry", description: "CP1 build", prompt: "<first brief>" })
hogwarts_dispatch({ role: "harry", description: "CP2 build", prompt: "<next brief>" })

一个父会话，每个角色一个子代理。 检查点和修复轮次沿用同一个 childId；改 description、完成一个 CP、或者进入不活跃状态，都不会新建一个 Harry。各角色互相独立，所以 Harry 和 Severus 各自保留自己的历史。派发是非阻塞的：等某个角色交回报告，再给它派下一个 CP；对同一角色的并发调用不会产生并行的工作者。

插件重载、恢复同一个父会话之后，绑定关系依然保留。续接失败绝不会悄悄新建一个替身。历史较旧、角色绑定有歧义时，需要人工介入，而不是靠猜。真正新建的父会话会从计划重新水化，拥有自己的一套角色。
结果会区分 started 与 continued。创建时报告配置好的服务商/模型；续接时标识已有的子代理，而不会声称它使用了新改的默认值。cwd 只在创建时生效：后续调用传入非空 cwd 会被拒绝。省略它即可保留子代理既有的工作目录。名册标签保留首个 description；后续简报不会给子代理重新贴标签。

条件消融

该技能要求 Harry 每次交付都附一份复杂度报告。当消融策略触发时，Harry 会运行受控的移除/替换实验，且不放松验收标准，验证组合后的幸存项，并把证据交给 Severus 审计。这是工作流关卡，不是运行时扫描代码体积；直接手动派发会跳过该技能的检查点纪律。阈值与计数规则只有一个权威出处。

评审发现与收敛

评审行为被规定为文本化工作流契约，而非宿主权限。权威规则见 skill/references/review-contract.md。

- 每条发现都分开保留严重级别（P1/P2/P3）、证据状态 （candidate / confirmed / refuted / needs-evidence）和处置，并附带稳定 ID、来源、源快照、file:line、因果链、所检查的防护项和验证证据。
- 在评审报告与修复转交之间，Albus 用一次非源端遍历批量验证所有阻断项和安全候选——不是每条发现派一个智能体。零确认发现的报告不会悄悄批准尚未解决的必需验证。确认的 P1 绝不豁免；P2 豁免必须显式且注明归属；P3 只记录携带，不自动修复。
- 三个完整的评审/响应周期仍未解决后，自动迭代停止，Albus 记录一次显式重评估，并保留计数器。这个检查点级上限与同根 Harry（最多 3 次）/ Voldemort（最多 2 次）尝试上限相互独立；两者互不重置，仅凭反复折腾永远不触发升级。
- 每个检查点都跑一次轻量安全分诊；命名的敏感面（认证/权限、密钥、不可信输入、CI/发布/安装、加密、PII、外部信任边界）需要限定范围的安全视角。计划携带边界 → 证据 → 负责人 → 预算/停止条件，并在策略、发布、部署或迁移需要时，指定具名人工批准人和回滚负责人。模型共识不能替代必需的人工签核。
- 评估轻量且诚实。
skill/references/evaluation.md 定义反馈字段和一个小型合成种子语料，作为独立的目标输入与预期答案保存。它不是实测基准：已接受的修复不是标准答案，未实际运行就不声称任何模型得分。
在同一份冻结快照上做对比，非处理变量保持一致，并记录下有意做出的提示词、模型、工具、配置改动。
- 工作计划不是提交。 检查点计划、进度清单和评审报告默认放在会话记忆里，或放在工作区之外的任务级临时根目录；它们不提交，也不藏在 .gitignore 后面。经用户批准、长期维护的路线图或设计文档是例外，可以持久保存。skill/assets/plan-template.md 是产品模板，不是每次运行都要提交的文件。

技能里的规则不会安装工具 ACL、审批提示词或运行时状态机制。直接手动派发会绕过技能的检查点纪律，主机级权限仍然要在主机上配置。

安装

需要 Node.js ≥ 20 和一个 DeepSeek Harness 配置档。

从 Add plugin 向导安装

在 Add plugin 向导的搜索框里输入 @dyikai/dsh-hogwarts-loop，然后点 Install。

用 dsh 命令行安装

dsh plugin --profile web add @dyikai/dsh-hogwarts-loop
dsh web

不需要构建步骤，也不用重启，但请看下面的重载说明。

从本地检出安装

plugin_manager -> { action: "install_bundle", target: "<path-to-this-repo>" }

卸载：

plugin_manager -> { action: "remove_bundle", target: "@dyikai/dsh-hogwarts-loop" }

安装之后——或者改过 client.js 之后——把页面重载一次，浏览器那一半才会加载，设置区才会出现。主机那一半会随插件行一起重新装配。

使用

插件不是任务，没有启动按钮。装好之后它一直在，提供三样东西：hogwarts_dispatch 工具、hogwarts-loop 技能和设置页。「让它工作」的意思是触发技能，技能再去指挥主智能体派发。即使没人触发，插件也保持加载。

三种入口：

1. 直接调用技能 —— 输入 /hogwarts-loop，技能内容就注入当前会话。
2. 说出你的需求 —— 「用 hogwarts loop 规划这个里程碑，然后实现、评审并提交每个检查点」。技能自带描述，任务匹配时模型也会自己加载它。
3. 手动派发一次 —— 「用 hogwarts_dispatch 把 harry 派去做 X」。这直接使用插件，跳过技能里的检查点 / 评审纪律。

怎么判断它真的在工作：

- 会话里出现 hogwarts_dispatch 工具调用；
- 反复向同一角色派发，返回的 childId 相同；
- 子会话日志里记录的 agentModel 和 config.model 等于该角色配置的路由（比如 harry 走 deepseek-flash，severus 走 deepseek-v4-pro），而不是主会话的模型。

配置角色阵容

Settings → Hogwarts Loop（侧边栏底部的设置入口）是主入口。它以 settings.section 注册，顺序为 60。
同一份表单还有第二个入口：Plugins → Installed plugins → @dyikai/dsh-hogwarts-loop → hogwarts-loop 行 → Configure（plugins.row.config）。

页面列出全部角色，每个角色一行：provider 和 model 是下拉框，选项来自宿主的模型目录（remote.session.modelCatalog()，按服务商分组）；切换服务商时，模型会切到该服务商的第一项。Reasoning effort 也是下拉框，选项由所选模型实际支持的档位生成（留空 = 模型默认值），max output tokens 字段可以留空。再往下是 Dispatch settings，用来设置子代理后端和委派深度上限。

保存时，所有改动会合并成一次原子、带版本围栏的 mutate，写入当前配置档中本插件对应的行。下一个新建的角色会用到它 —— 不用重装，也不用重启。继续使用已有角色时，会保留它的子会话，不会套用新的创建默认值，也不会为了切换模型而替换它。

默认值（没有任何覆盖时的行为）：

| 角色 | 席位 | 默认模型 |
| harry | 实现者（写代码、跑门禁） | deepseek-flash |
| severus | 评审者（正确性负责人；只读） | deepseek-v4-pro |
| alastor | 安全专家 | deepseek-v4-pro |
| filius | 性能专家 | deepseek-flash |
| minerva | 并发专家 | deepseek-flash |
| argus | 收尾 UI 走查 | deepseek-flash |
| voldemort | 升级实现者（只处理一个升级问题） | deepseek-v4-pro |

升级：Voldemort

Harry 对一个问题最多尝试三次（一次尝试 = 一轮 build → gate → review）。如果三次都失败 —— 门禁仍然红，或者 Severus 反复把同一个根因列为 P1 —— 问题就升级一次给 voldemort。升级简报必须带上检查点验收标准、三次尝试各自改了什么、每次的确切失败证据，以及已经排除的可能性。

Voldemort 和 Harry 是完全相同的实现者：同样的检查点范围、同样的门禁、同样要求「树是绿的，外加原始证据」，他也不提交。唯一的区别是模型更强，以及带着三次失败的历史。他的职责是一个具体问题，不是整张清单：他只改这个问题需要改的地方，不接管剩下的检查点，不「顺手清理」，问题修好并通过 Severus 之后，控制权交回 Harry。他最多尝试两次，他的工作同样要通过 Severus 才能提交。如果两次都失败，循环停止：报告问题、五次尝试（3 + 2）、证据、已排除的项，以及可选项 —— 不会有第四个 Harry，不会有第三个 Voldemort，也不会悄悄扩大范围把门禁刷绿。
这两个数字写在 skill/SKILL.md 的 Escalation 一节里——技能文本就是规则。角色阵容本身由 index.js 里的 DEFAULT_ROLES 定义。另有贯穿整个检查点的三循环收敛上限（以及它与这些尝试次数上限的优先级关系），写在 skill/references/review-contract.md。

表单写入的是本插件的配置档行（cordis.patch.yml 里的 hogwarts-loop 条目）。手动改这一行的 config，或者批量改，同样可行；字段定义见 index.js 里的 Config 导出。

Albus 就是你——主会话。它的模型由会话的模型选择器决定，不受本插件控制；插件只决定它派发的每个子代理走哪条路由。

表单为什么长这样

- 表单注册了两次——一次在设置面板的 settings.section，一次在 Plugins 页面的 plugins.row.config（键为 @dyikai/dsh-hogwarts-loop#hogwarts-loop）——两处渲染同一个 FormBody。
- 设置面板那个入口通过共享的 settings.describe 镜像解析本插件的命名空间（匹配 hogwarts-loop 后缀，所以带 include: 前缀也能用），再经 ctx.configForms.get(ns) 拿到带版本围栏的写句柄。Plugins 入口直接从页面收到绑定的 form，不必猜命名空间。
- 在宿主侧，Config 把 delegation 和 roles 这两个顶层对象标成 .volatile()（schemastery 不能嵌套 volatile，所以引用只能挂在对象上）。这一手既让设置服务把该条目当作可编辑、并供给设置面板，也保证新建角色读到的是当前默认值，而不是插件激活时拍的快照。
- 读不到模型目录时（登录过期、目录请求失败），同样的字段会退化成文本输入框，页面不会崩。
- 创建时模型填错不会静默失败：hogwarts_dispatch 在创建角色前先校验路由，返回可操作的 tool 错误。

验证路由

派发角色后，子会话的日志会记下真实路由。会话目录在 ~/.dsh/sessions/<encoded-cwd>/<childId>/ 下，其中 <encoded-cwd> 是项目路径，分隔符换成短横线：

node -e '
const fs = require("node:fs"), zlib = require("node:zlib");
const base = ${process.env.HOME}/.dsh/sessions/<encoded-cwd>/<childId>;
const f = fs.readdirSync(base).find((n) => n.endsWith(".zstd"));
const ev = zlib.zstdDecompressSync(fs.readFileSync(${base}/${f}))
.toString("utf8").split("\n").filter(Boolean).map(JSON.parse);
console.log(ev.find((e) => e.type === "subagent/descriptor")?.data);
console.log(ev.find((e) => e.type === "request/header")?.data.header.config);
'
预期 agentModel / config.model 等于该角色配置的模型。

仓库结构

.
├── package.json # @dyikai/dsh-hogwarts-loop; dsh.bundle.patch + dsh.client
├── cordis.patch.yml # inserts the hogwarts-loop row
├── index.js # host half: Config schema, skill registration, hogwarts_dispatch
├── client.js # browser half: per-role config form in Settings and on the Plugins page
├── locale/{en,zh}.json # plugin name and description in the Plugin Manager
├── icon.svg # plugin icon
└── skill/
├── SKILL.md # the loop overview + "dispatch with hogwarts_dispatch"
├── references/*.md # planner / implementer / reviewer / loop / example /
│ # review-contract / evaluation
└── assets/
├── plan-template.md # working plan: risk, review ledger, convergence
├── eval-inputs.md # synthetic seed targets (reviewer-safe)
└── eval-expectations.md # answers kept separate from the targets

已知限制

- 设置项是插件自己注册的页面（settings.section），不是宿主根据 Config 自动生成的表单——当前客户端版本还没有这个渲染器（内置客户端都不消费 autoGenerate）。
- 首次派发使用可续的 spawn 后端，后续派发会恢复那个子进程。一次性后端无法满足持久角色约定。fork 风格的后端继承父级路由，无法为每个角色独立选择模型。
- delegation.maxDepth 默认为 1：子进程不能再向下派发。
- 子进程加入父会话当前的智能体预设，并使用它的工具。
- 插件是配置档级的：安装一次，这个配置档里的每个会话都能看到 hogwarts_dispatch 和 hogwarts-loop 技能。

许可

MIT © dyikai