dsh-expert-orchestrator

dsh plugin --profile web add dsh-expert-orchestrator

<div align="center">

DSH Expert Orchestrator（专家编排模式）

多智能体编排 · PM 先行规划 · 合并花名册专家委派 · 依赖 DAG 任务板 · 门禁交付 · 经验沉淀

一个 DeepSeek Harness（DSH）agent preset 插件：安装后 DSH 即获得一个「首席编排者」会话模式——

不亲自写码，而是分诊任务、请项目管理专家规划、把实施委派给最合适的领域专家，并以门禁保证交付质量。

[安装](#-安装) · [工作流](#-工作流) · [五大机制](#-五大机制) · [自定义](#-自定义) · [License](#license)

</div>

---

✨ 它做什么

场景 · 行为

收到任务 · 每轮强制重新分诊（三级：大型 / 小型实施 / 只读），杜绝"上一轮在做就直接续"的漂移

大型任务 · 先召唤 PM 专家（高级项目经理 / 项目推进专员）产出结构化计划，再逐项委派

实施改动 · 一律委派专家执行（合并花名册优先：bundled-core + 已启用来源；无匹配时回退自带专家库；dsh-agency-agents 为可选共存项而非依赖）；协调官只做只读验证

并行协作 · 专家产出走文件消息总线落盘，协调官只读摘要不转述全文

交付前 · 独立评审专家（评审者 ≠ 实现者，回炉 ≤2 轮）+ PM 检查点，双门禁放行

任务收尾 · 提炼 ≤3 条教训写入经验池，下次同类任务自动注入

🧪 实测能力边界（2026-10-19 对照评测）

在进入技术细节之前，先如实告诉你这个插件能做什么、不能做什么——这是实测出来的，不是宣传语。我们在 2026-10-19 做了一次同台对比（本插件 2.9.8，宿主 dsh 0.2.1-rc.2）：同样的 18 个任务场景，开插件跑 3 遍、不开插件再跑 3 遍，共 108 次任务，全部由同一个模型（glm-5.3-flash）完成，总花费约 $11.55。

用大白话说：

• 简单任务：两种设置都能做对。 开不开插件，简单任务没有差别。
• 较难任务：开插件略稳一些，而且每成功解出一题花的钱还略少（判分口径 $0.0766 vs $0.0887）。这个成本差距当参考就好——统计上并不显著。
• 诚实预期：整体正确率提升 +6.7 个百分点（可判分的 15 个场景上 86.7% → 93.3%）。 这是本轮实测到的提升，但没有达到我们实验前预注册的 +20pp「显著提升」门槛，置信区间下界为 0——所以不能宣称大幅提升。按预注册协议，我们选择继续加测（加重复次数、加更难场景），而不是改写结论。
• 没有回归。 整轮测试里，没有出现任何一个「不开插件能做对、开了插件反而做砸」的场景。
• 更安全：全轮仅有的 2 例不安全判定，全部出现在不开插件的基线臂；开插件一臂在判分任务中零不安全判定。

一句话结论： 这是一个「不减分、难任务略稳、单题成本略低」的编排层，不是能力银弹。本次对照只覆盖单一模型、单一工况，数字不能外推到其他模型或环境。

完整数据与正式判读见 [docs/internal/experiments/2026-10-19-capability-ab/](docs/internal/experiments/2026-10-19-capability-ab/)（[AB-REPORT.md](docs/internal/experiments/2026-10-19-capability-ab/AB-REPORT.md) 为正式判读文档；[AA-REPORT.md](docs/internal/experiments/2026-10-19-capability-ab/AA-REPORT.md) 为 A/A 噪声底）。

🧭 工作流

用户请求 → 分诊（每轮重做）
  ├─ 只读操作 → 协调官亲自做
  ├─ 小型实施 → 免 PM，直接委派 1 名执行专家 → 验收
  └─ 大型任务 → PM 规划召唤（高级项目经理）
        → 任务板建档（依赖 DAG）→ 逐子任务委派专家
        → 并行专家产出落盘消息总线 → 协调官只读摘要整合
        → 独立评审（回炉 ≤2）→ PM 检查点 → 交付
        → 经验沉淀（lessons.md）
每步行动前过五锚自检：回顾｜收敛｜反跑题｜协作｜资源

🧩 五大机制

机制 · 说明

🎯 每轮分诊 + 五锚自检 · 三级分诊 + 五项显式自检（含"连续 2 轮无进展→换策略或召 PM 重排"），跨轮不漂移

📋 任务板 taskboard.py · 文件任务板：pending→ready→running→done/failed 状态机，--dep 依赖 DAG（done 自动解锁下游），崩溃 recover

💬 消息总线 bus.py · 信箱式落盘消息：send/read/ack/broadcast/stats，并行专家零转述协作，省协调官上下文

🛡️ 交付门禁 · 独立评审（同意/部分同意/反对+理由，回炉上限 2 轮）→ PM 检查点，commit 前强制

💾 经验池 · 全局 lessons.md + 项目级 .expert-lessons.md 双层沉淀，委派任务书自动注入相关教训

🧙 原生专家工具 · list_experts（浏览合并花名册，紧凑/展开双模式）、summon_expert（白纸精召：persona 经 sanitizePersona 注入，解析链 exact→aliases→无歧义 title，shadowed/disabled 拒绝，task 8000 码点上限）、summon_experts（批量 ≤8、并发 4、部分成功语义）。递归防护：spawn 子代理带六项 toolFilter deny（不可再召唤专家、不可嵌套 subagent/fork、不可 workflow），工具 schema default 3 纵深兜底——单层委派，无失控专家树

📚 每专家经验池 + persona 方法论分层（v2.4.0） · summon 自动尾部注入 expert-lessons/<slug>.md 该专家历史教训（≤2000 字符，按字符截断，2K 上限，无命中零变化）；persona frontmatter method: + <!-- methods-cut --> 瘦身注入+按需深读指针（Top-5 bundled-core 已分层，fail-safe 全量回退，合入经预注册 A/B 实验门禁，档案见 docs/internal/experiments/）；list_experts 显式标注跨源 conflict/shadowed，自定义专家删除支持清理。已知限制：设置面板「清空已删除」按钮 UI 待接线（RPC 契约已就位）

🆕 v2.8 新特性

特性 · 说明

🛡️ 委派安全门禁（WP-7） · 围绕 summon_expert 的四层可审计执法：origin chain 链路溯源——每次派发在任务书末行追加标记，链上出现重复 (专家, cwd) 对即拒绝且报错含完整链路、深度由链长推导（默认开启，A/B 实验档案见 docs/internal/experiments/）；四小门禁——工件归属登记（taskboard.py own，冲突具名 artifact_owned）、A→B→A 委派振荡告警（非阻断）、effort 能力预检、per-cwd 写锁（DSH_EXPERT_CWD_LOCK=1，同 cwd 第二位写型专家当场拒绝而非排队）；per-专家工具调用硬预算（DSH_EXPERT_TOOL_BUDGET，默认关闭）——事件溯源计数（模型自报不计入）、三档（告警/收尾/中断——交付出口永不拒绝）、budget <id> [--reset]；idle-edge 自动续领（DSH_EXPERT_IDLE_RECLAIM=1，默认关闭）——最后一位在途专家成功收尾时经既有 claim 路径以 owner=编排者 领取 ready 无 owner 任务，领取≠派工、绝不自动召唤专家

🧩 per-专家档案与 prompt 瘦身（WP-6 余项） · ~/.dsh/expert-profiles.json（全局层）+ <当前目录>/.dsh/expert-profiles.json（项目层覆盖）按专家调 model / toolFilter 白黑名单 / skills / MCP server 白名单 / effort，每次 summon 现场重读（热改文件下次召唤即生效）；toolFilter 收窄与递归防护 deny 求并不放宽、空 allow fail-closed；persona 中 <!-- tools: … -->…<!-- /tools --> 标记段在点名工具对该专家全部不可见时整段剪除

🧾 评审台账收口 · v2.7 评审后置 14 项台账全部处置：taskboard.py --json 结构化信封、bus 信箱根约定成文、归档同秒碰撞唯一后缀、视图超前/损坏归档板升格 unrecoverable，另四项书面裁定留档

🔌 兼容性 · engines.dsh / @deepseek-ai/dsh-tools 区间自 2.6.0 起未变（静态 semver 矩阵复验，记录见 docs/internal/verification/）；PROTOCOL 刷新清单维持 14 项

#16 硬预算 × #20 idle-edge 自动续领：建议组合开启

两个开关默认均关闭；若要开启，建议同时开启——各自补上对方留下的缺口。

#20 开而 #16 关时。 每次成功的空闲边沿都会把 ready 且无 owner 的任务（每轮扫描 ≤8 条）以 owner=编排者 领取。领取后未及时派工的任务由 watchdog 从时间面接管（nudge→reclaim 回 ready、清 owner）——而下一个空闲边沿会再次领取。该 claim→reclaim→再 claim 的慢循环在此组合下没有计数上限：#16 的预算累计兜底只在 #16 开启时存在，而 watchdog reclaim 本身是编排面命令，不计入任何预算。

为什么它无害——但也仅是有界。 三个事实兜住它：watchdog 时间窗为循环限速（每个时间窗至多一轮回收周期）、循环零 token（领取≠派工——扫描绝不召唤专家）、每一跳都在事件流可见（事件 type=claim，args 携带 {owner, ids} 可辨来源）。它可以空转，但花不掉 token、也藏不住。

建议。 同时设置 DSH_EXPERT_TOOL_BUDGET=1：续领取道既有 claim 路径，per-(task, expert) 计数跨 reclaim 累计；interrupt 档当场拒绝（budget_interrupted），budget <id> --reset 是唯一放行出口。交付出口（done/fail）永不拒绝——中断=强迫交还，绝不阻断交付。

🆕 v2.7 新特性

特性 · 说明

🗂️ 崩溃安全的编排状态（WP-4b） · 任务板改为事件溯源（append-only 事件流为权威、双层完整性哈希、崩溃后确定性重放）；消息总线按派工代际过滤并给出三态裁决，支持增量读取（--since-seq）；watchdog 会在孤儿专家的完成证据已在总线上时将其收养。summon_expert 可在新代宿主上把中断的专家运行恢复为持久续跑（裁决 Q2=2A——旧代宿主保持一次性行为；DSH_EXPERT_RESUME=0 可关闭）

🚦 质量门禁（WP-5） · PM 规划阶段先落 draft、批准后方生效（create --draft / approve）；--kind review 子任务要求显式裁决——含 findings 校验、自动回炉路由与 escalated 终态；多评审任务（--quorum-m，默认 3，裁决 Q3=3A）仅在 ≥m 票同向且零反向票时达成裁决，每条回到 ready 的路径都重置票数

📄 文件层专家与零 token 手势（WP-6） · 专家 persona 按项目层 > 全局层 > 内置的 .md 文件层解析（裁决 Q4=4A）并支持运行时重读；/expert-<name> 手势以零模型调用注入 11 位核心专家（见下文「零 token 专家手势」小节）

🆕 v2.6 新特性

特性 · 说明

🔒 任务板并发正确性（WP-1） · 全部写操作携带 expected_revision 乐观锁（旧 revision 返回具名错误且不落盘）；attempt 代际——转派撤销旧代际，旧代际的 done/汇报被拒；板文件损坏返回显式 unrecoverable 错误而非静默空列表；依赖写入前全图环检测

📮 消息总线 at-least-once（WP-2） · 游标仅在收到成功回执后前进（投递中途崩溃可重投）；携带已撤销 attempt

…(truncated)