前言¶

在 DeepSeek Harness（DSH）里用主智能体统筹、子代理并行干活，常见难点不在「能不能派活」，而在「任务边界是否被改写扩权、拆解是否合理、每步有没有可核对证据、能不能验收」。会话里文字来回说，很难一眼看出当前 run 卡在哪一步。社区插件 dsh-orchestrator-canvas（维护者 MrXiongBear）把「Brief → Decompose → Dispatch → Verify → Accept」做成宿主侧工具链 + 磁盘上的 run.json 证据链，并在客户端提供只读编排画布；它不另写调度引擎，而是组合宿主已有的 ctx.subagents 与可选的 dsh-flowglass 流视图。

这是什么¶

dsh-orchestrator-canvas 归类为 DSH 社区目录中的「工作流」插件。一句话定位：工作画布流——图即真相的编排闸门（Brief→Decompose→Dispatch→Verify→Accept）+ 只读编排画布。

数据落在 <dsh-home>\orchestrator\runs\<runId>\ 下的 run.json 与 events.jsonl；画布、抽屉与 /_dsh/orchestrator-canvas/api/* 均为只读，图只能经 orch_plan 等工具写入。仓库 README 标明：实验性、自用性质、100% 由 AI 生成并经人验收，未发布到 npm，且仅在编写时的 DSH 版本上验证过；宿主升级后可能失效。当前 package.json 版本为 0.1.6，声明兼容 DSH >=0.2.1-rc.2 <0.3.0、desktop profile，Node >=22.19。

与现有能力如何组合¶

下面是对 README 中对照表的归纳，便于判断要不要和别的插件一起装。

核心功能¶

宿主侧五工具¶

主智能体可见五个模型工具：orch_plan、orch_dispatch、orch_verify、orch_accept、orch_state。主智能体统筹，子代理执行 step；每一步完成与否以落到 run.json 的内容为准。

五道闸门¶

1. Brief（改写，不扩权）
orch_plan 的 brief 是对用户原话的改写，写入 run.json.brief，画布顶部只显示它。brief 只能收敛范围，不能新增需求；后续 orch_verify 也要对着 brief 判定。

2. Decompose（DAG）
节点类型：step（子代理执行）、check（挂在 step 之后，产出证据）、merge（可多父，汇合验收）。落盘前校验 id 唯一、边合法、无环、类型合法、每个 step 至少被一个合法 check 覆盖。返回 runId、拓扑序 order、layers、dispatchable。

3. Dispatch（真派活）
orch_dispatch 调用 ctx.subagents.startActivation 派发子代理，把 prompt、childId、原始输出、stopReason 写入 run.json.nodes[].attempts[]。默认并行上限 maxParallel: 3；依赖未完成、check/merge 节点会被拒。失败重跑产生新 attempt，不覆盖历史。派发异步，下一轮用 orch_state 看结果。

4. Verify（证据非空）
orch_verify 要求 evidence 每项含 kind（command|test|artifact|review）、value、author、at；空或缺字段直接拒绝。verdict: fail 会标记 check 失败并将下游标为 blocked。

5. Accept（人工显式确认）
前置条件：所有 step 为 done、所有 check verdict=pass、用户显式确认。不满足则拒绝并列出缺口；满足时写「交付物 → 节点 → 证据」摘要到 run.json.acceptance。确认经 ctx.userQuestions，且仅在 root agent 工具调用里弹出。

状态机与审计¶

节点状态：pending → running → done，失败则 failed 并阻塞下游；另有 blocked。events.jsonl 逐行记录 plan / dispatch / verify / accept / prune 等事件；run.json 采用写临时文件再 rename 的原子写。

只读编排画布¶

入口在输入框工具栏左侧「◈ 编排画布」（conversation.input.left），点开为 shell.overlay 全帧面板，Esc 或点遮罩关闭。顶部可按 本会话 / 本工作区 / 全部 过滤 run（范围仅内存，客户端不写 localStorage）。布局为依赖深度分列，卡片展示状态、类型、目标、子代理、证据数等；点卡片打开右侧抽屉查看 attempt 与证据。v0 不支持拖节点改图。

安装与启用¶

DSH profile 加载为全有或全无：任一插件 import 失败可能连坐整个 profile。安装前请备份 profile 里的 package.json 与 cordis.patch.yml。

本插件没有 npm 发布；官方 README 给出的路径是让插件管理器执行 install_bundle，target 指向本仓库目录，或等价手工方式：

1. 将本目录放入 profile 的 node_modules，或在 dependencies 中使用 "dsh-orchestrator-canvas": "link:<本目录绝对路径>"（必须是 link:，不能用 file:，否则 pnpm 会复制目录，客户端 bundle 修改后不生效）。
2. 在 profile 的 package.json 的 dsh.profile.bundles 中登记 dsh-orchestrator-canvas。
3. 在 profile 目录执行 pnpm install，使 node_modules 指向源码 junction。
4. 装完后在 workspace 跑审计再重启 DSH：

node <workspace>\tools\audit-dsh-plugins.mjs        # 期望 PROBLEMS: none

卸载：从 dsh.profile.bundles / dependencies 移除后重启。注意：remove_bundle 对 link: / file: 依赖可能删除本地源码目录，卸载前请归档仓库副本。可选删除历史：Remove-Item -Recurse -Force <dsh-home>\orchestrator。

cordis.patch.yml 中可选配置示例：

- id: orchestrator-canvas
  name: dsh-orchestrator-canvas
  config:
    runsDir: '<dsh-home>\orchestrator\runs'
    maxParallel: 3
    subagentProvider: spawn
    subagentCwd: ''
    autoPrune: true
    retentionDays: 30
    retentionBytes: 209715200
    outputLimit: 12000

典型用法（流程）¶

下面是可复现的主线，具体 prompt 由会话决定，顺序以 README 接缝测试为准：

1. 主智能体用 orch_plan 提交 brief 与 DAG（step / check / merge），得到 runId 与可派发列表。
2. 对 dispatchable 中的 step 节点调用 orch_dispatch；并行不超过配置的 maxParallel。
3. 子代理完成后，主智能体用 orch_state 查看节点与 attempt，再对 check 节点调用 orch_verify 提交 evidence 与 verdict。
4. 全部 step 完成且 check 通过后，调用 orch_accept 触发用户确认；确认后 run 状态为 accepted。
5. 随时点 ◈ 编排画布 只读查看当前 run 的图与抽屉详情。

证据 JSON 形态示例（字段缺一不可）：

{ "kind": "command|test|artifact|review", "value": "npm test → 26/26 pass", "author": "model", "at": "2026-10-29T13:20:00+08:00" }

适用场景与注意¶

适合：需要在 DSH desktop profile 下，用固定闸门约束「拆解 → 派子代理 → 验证据 → 人工验收」，并希望会话旁有一张只读 DAG 投影的开发者。

务必注意：

• 插件以当前 DSH 进程权限运行；安装前应自行阅读 GitHub 源码 与仓库声明（实验性、非商业、AI 生成）。
• 社区目录 skillhub.cn 插件页 与 DeepSeek / 幻方无官方从属关系，属于 DSH「一切皆插件」生态中的独立收录。
• README 未在已抓取片段中给出 SPDX 许可证字段；以仓库根目录实际 LICENSE 文件为准。
• 修改客户端源码后需执行 node tools/build-client.mjs 重建 client.js（link: 安装下才会反映到运行实例）。

结尾¶

dsh-orchestrator-canvas 把多智能体编排里最容易扯皮的部分——范围 brief、DAG 拆解、派发记录、非空证据、显式 accept——钉在 run.json 与五道工具闸门上，画布只做真相投影。若要进一步了解说明与自测命令，见社区目录页与 GitHub 仓库：

• 目录页：https://www.skillhub.cn/plugins/MrXiongBear/dsh-orchestrator-canvas
• GitHub：https://github.com/MrXiongBear/dsh-orchestrator-canvas