多智能体协作台 HuaimaoCy/dsh-agent-hub

协作台 · dsh-agent-hub

一个 DSH 插件：让多个不同模型的智能体同时执行同一个目标，并在同一块界面上实时交换进度。

它解决什么

DSH 本身已经能派子智能体，但一次只能看到一个。这个插件把「派发」和「围观」合成一件事：

- 一个目标 → 一份分工：让协调者模型把目标拆成若干独立角色，每个角色负责不同的文件范围。拆分结果是一张可编辑的表，你可以在启动前改名字、改任务、改模型、改权限。
- 每个智能体各用一个模型：deepseek-official/deepseek-flash、zai-coding-cn/glm-4.6…… 每个角色单独选。这是它与 Agent Teams 的关键区别——Agent Teams 的成员没有 per-teammate 模型。
- 实时看到每一个人：每条泳道显示状态、模型、耗时、token、当前动作，以及逐 token 正在生成的文本。
- 两个面：进行中 / 已完成。泳道区只显示正在进行的智能体——它回答的是"现在发生了什么"；已结束的（完成 / 出错 / 已停止）移到「已完成」页，动作照样保留：唤醒一个已完成的智能体追问一句，正是它该有的用法。
- 进度真的在交换：智能体用 hub_post 把里程碑发到共享进度板，也能点对点把消息投进同伴的收件箱并唤醒它；你随时可以插话、广播、打断。
- 权限逐人设置：只读 / 可写文件 / 可执行命令，在界面上勾选。只读写进精确拒绝：把运行时真正注册了的写类与命令类工具逐个拒掉，其余工具原样保留——真的改不了文件，而且不会连带砍掉无关工具。
- 但 codex 路由是例外（对照实测）：路由到 codex-chatgpt/* 的子会话不在 DSH 里跑——它是外部 Codex 进程，工具是 Codex 自己的（apply_patch、exec_command、MCP 应用），没有 hub_post/hub_read、也没有 DSH 的读写工具，写权限由 Codex 自己的沙箱决定（subagent-codex 的 permissionMode 默认 never → 只读）。同一次开台里两边做了同一件事：deepseek 行拿到 39 个 DSH 工具、write 成功落盘；codex 行两者都没有。所以需要读文件、需要向进度板汇报、需要按文件分工的活，派给进程内路由。

它跑的是真实的 DSH 子智能体会话（有工具、能读写工作区、能多轮续话），不是"多个模型各说一段话"的假并行。

安装

在 dsh 源码 checkout 根目录
pnpm dsh plugin --profile web add <这个目录的绝对路径>

装好后必须重启 dsh web：宿主半是进程内 ESM 模块，换掉已安装的包不会热更（浏览器半会自己热更，宿主半不会）。

在 dsh 源码 checkout 根目录
pnpm run start:web

重启后刷新页面，侧边栏会出现「协作台」。

怎么用

1. 打开一个会话（协作台挂在会话上，子智能体的父会话就是它）。
2. 侧边栏点「协作台」，或会话顶部页签切到「协作台」。
3. 写下目标，点「智能拆分」。协调者会返回一张表；逐行检查、改模型、勾权限。
4. 点「并行启动」。N 个智能体同时开跑，泳道里能看到实时输出。
5. 需要干预时：对单个智能体插话（排队或立即打断当前步）、唤醒已空闲的它、中断当前这一轮，或对全体广播。

一个前提

派发要求父会话当前有活动智能体。如果会话是冷启动的空壳，启动会返回：

这个会话当前没有活动的智能体，无法派发子智能体。请在对话里发一条消息（哪怕一个字）让会话激活，再回到协作台启动。

这是刻意的：插件不替你去 resume 一个会话（那会把会话的归属权拿到插件手里，插件卸载时连带你正在用的会话一起消失）。

智能体之间的两条通道

| 工具 | 作用 |
| hub_post | 把一行进度发到共享板（全体可见）。传 to: '同伴名' 时会同时投进那个同伴的收件箱并唤醒它。 |
| hub_read | 读名册 + 所有人的最新进度。出工前读一次可以避免和同伴做重样的事。 |

还有一个建议用法：让每个智能体在收尾时 hub_post 一行"交付了什么、在哪"，这块板就自动变成了一份可读的收尾报告。

让 AI 真的会去用它

一块没人打开的板是装饰，一个没人调用的工具等于不存在。所以除了界面，插件还做了两件事：

常驻策略段落（src/policy.js，写进每个智能体的系统提示词）。它写成政策而不是口号，因为两种失败都是真的：没被告知这块板是干什么的智能体，会一直单线程硬做；被告知"多用它"的智能体，会为一个两行的改动开台，白白付出一次协调者调用加每个智能体各自的上下文。所以它同时给出：

- 触发条件：目标能拆成互相独立的部分；要的是跨模块、跨方案、跨来源的广度；需要一个不同模型的判断；长活该在后台跑而对话继续；需要只读角色去攻击另一个角色的产出。
- 克制条件：步骤之间有依赖；只有一处文件要改，或几个角色注定写同一批文件；两三步就能做完（开台的成本大于收益）；背景没法在一条提示里交代清楚——子智能体看不到你的对话。
- 怎么用：知道"何时"就够用，剩下的动作一看就会。
- 一行实时状态：报出当前这块台有几个智能体、几个在跑，让智能体加入已有的台而不是再开一块。

hub_launch 工具——没有它，策略就是一句无法执行的建议：在此之前智能体能往板上发言、能读板，但只有人按按钮才能开台。只给目标时由协调者拆分；给了名册就跳过协调者调用。名册里的角色默认只读：模型没说要写，就不会因为默认值而拿到一个会写文件的智能体。

这段策略文本会随部署里每个会话的每次请求发出，所以可以用 policy: false 关掉；关掉后协作台就只作为界面存在。

按提供商灵活调配

三种粒度，从最省事到最精确：

| 你想做的 | 怎么做 |
| 让另一个模型来评审 | 在那一行的 provider / model 里指定；策略会告诉模型可用的路由 |
| 只想把活摊开，不想逐个挑 | 传 models: ["provider/model", …]，没指定模型的行由宿主轮流分配 |
| 让协调者按角色分配 | 不传 models，协调者知道有哪些路由可选，会自行分配（重判断的给强模型、机械活给便宜的、对抗评审刻意换个模型） |

三处支撑：

1. 策略段落里列出可用路由（可用模型路由（provider/model，共 N 条）：…，实时从目录读，最多列 12 条）。没有这一行，模型只能编路由名——而编出来的路由会被校验丢掉，整队静默回落到同一个模型，且不报任何错。
2. 协调者的请求里带上完整目录，并明确告诉它：model 必须逐字复制清单里的值；分工相似时用同一个模型就是正确答案，不要为了多样性而制造多样性。
3. hub_launch 新增 models：给了名册时，没写模型的行轮流取用；给了目标时，协调者没指定模型的行也用它兜底。格式错误的条目会被丢掉（broken/、/nope），不会让整次派发失败。

修掉的真实缺口：在此之前协调者的提示词里根本没有 model 字段，也没人告诉它有哪些提供商——所以自动拆分出来的队永远是同一个模型。逐人指定模型一直可用，但只有在你手写名册时才用得上。

按行指定的路由若提供商不服务，会让那一行的启动失败并写明原因（其它行照常运行），不会被悄悄替换成别的模型。

与原生 Agent Teams 的关系

两者确实重合——都是"一份花名册 + 一块共享板 + 成员之间投递"。所以这里是集成，不是并列两套：

| | 谁拥有 |
| 持久化：成员、任务、依赖、写入范围 | 原生 Agent Teams：写在 Lead 的会话日志里，宿主重启不丢 |
| 逐人模型、逐人工具范围、逐 token 实时视图 | 协作台：原生 spawn_teammate 只有 provider，没有 model |

具体做了三件事：

1. 同一块板。协作台把自己的泳道与原生团队的名册画在一起：op=state 里的 team 字段直接读 ctx.agentTeams，不镜像、不复制，所以原生那边的变化立刻出现在这里，且原生团队自己建的任务也一并显示。
2. 同一份计划。hub_launch 审批过的分工会被写成原生任务（createTask → claim），智能体收尾时用 CAS 完成它。于是团队面板、team_task_list 与这块板看到的是同一张带版本号、依赖与写入范围的任务表——而不是一份自由文本的"计划"加一份真正的任务表。
3. 失败不致命。任务板写入失败不会取消派发（智能体已经在跑了），只在团队区块留下一行可见告警，不往进度板里灌重试噪音。

仍然存在的一条缝

原生的 list_agents / send_message 认不出协作台派发的智能体——它们不是团队成员。原因很具体：SpawnTeammateRequest 只有 provider 没有 model，而团队服务没有"收养一个已存在子会话"的 API，所以走原生 spawn 就等于放弃逐人模型，那正是这个插件的立身之本。

两条收口路径，都未实施：

- 上游的正路：给 SpawnTeammateRequest 加 agentOptions 并透传进内部的 startContinuable。能力其实已经具备——spawn provider 声明了 agentOptions/persona/toolFilter，continuable 路径也不做能力校验，缺的只是 Team 这一层没往下传。
- 手工写事件：session.append('team/member', …) 确实能把协作台的智能体登记成成员，而且它们恰好满足投递所需的"Lead 的直接 continuable 子会话"。但团队投影是严格校验的，一条非法记录会让该会话的 Agent Teams 永久进入 failure、之后所有事件都不再生效。这个代价不该由一个第三方插件替用户承担，所以没有采用。

主智能体也在板上

它确实在干活（策略里就写着"开台后……然后继续做你自己那一份"），所以它是第一条泳道：状态、模型、当前动作、输出尾部、token 用量都在，和派发出去的智能体一样。

但它不在可派发的名册里。那个名册是"可以插话、唤醒、中断"的集合，把主智能体放进去会有三个后果：重新派发会把它当旧名册替换掉、「全部停止」会去中断你正在说话的对话、界面的分工编辑器会把它显示成一条可编辑的草案行。所以它在宿主的 state.lead 里、走自己的 lead 事件，界面上单独渲染且没有动作按钮——你不会去中断自己。

它的事件按同样规则归属：父会话自己的会话事件（工具调用、回复、用量）折叠进它的卡片；而更深的后代——协作台的智能体自己再派出去的帮手——属于同一块台，但它们的产出不会算到主智能体头上，否则就是把别人的工作记在它名下。

可见范围：一块台，且只有一块台

一个智能体只能看到自己所属会话那块台上的同伴摘要——其他对话的协作台对它不可见。这条边界是代码强制的，不是约定：

- 一块台属于一个会话。该会话的任何子智能体（包括"子智能体的子智能体"，例如某个智能体自己再派出去的帮手）都解析到同一块台，所以它能读到同一批同伴的名称、角色、状态与最近进度。
- 对话之间互不可见。B 的台不会出现在 A 的任何读取里。
- 子智能体不能自己开台或清台（409）。它已经是某个会话的子智能体，只能与那块台上的同伴协作；要看进度用 hub_read，要汇报用 hub_post。

为什么这条要写进代码：子会话的 session.id 是它自己的。若不做解析，一个子智能体调用开台就会以它自己的会话为 key 新建一块台，从那一刻起它的 hub_read 看到的是那块空台而不是它正在协作的团队——花名册静默撕裂，而且没有任何报错。所以"一块台属于一个会话"是解析规则，不是提示词里的一句请求。

被替换掉的智能体会随卡片一起失权：重新派发或清台之后，旧子会话再来汇报会得到"不在任何协作台上"，而不是写进一块陌生的空台。

状态语义

| 状态 | 含义 |
| draft | 还没启动，可编辑 |
| running | 正在跑 |
| idle | 已启动、当前空闲——可以被唤醒，不是结束 |
| done | 这一轮按正常原因收尾（仍可唤醒续话） |
| error / stopped | 出错 / 被中断 |

终态只由 subagent/end 决定；会话事件只报告过程，不改终态。这是刻意的——否则一次 turn/end 就会把还在待命的智能体显示成"完成"。

配置

cordis.patch.yml 里可改（也可在 profile 的 cordis.patch.yml 覆盖）：

| 选项 | 默认 | 说明 |
| provider | '' | 子智能体 provider；空表示用运行时报告的第一个（通常是 spawn） |
| maxAgents | 8 | 单次派发上限 |
| defaultWrite | true | 新建行的"可写文件"默认值 |
| defaultShell | false | 新建行的"可执行命令"默认值 |
| policy | true | 是否把"何时该开台"的策略段落写进每个智能体的系统提示词 |
| outputLimit | 4000 | 每个智能体保留的输出尾部字符数 |
| feedLimit | 200 | 进度板保留条数 |
| coordinatorTimeoutMs | 120000 | 拆分调用超时 |
| coordinatorMaxTokens | 4000 | 拆分调用输出上限 |
| routeMeta | {} | 对内置路由元数据（定价／额度档位／擅长／边界）的逐条覆盖，见下节 |

非法值在装载期就报错，不会静默回退。

成本感知的模型选择

协调者在拆分时看到的不再是裸的 provider/model 列表：每条路由后面跟着它的成本（估价或订阅制）、额度档位（充裕／一般／紧张）、擅长与边界，系统提示要求它按「机械批量任务用低价档、判断密集任务才用高价档、额度紧张的路由每队最多一两个、不把角色派给边界不覆盖它的模型」来分配。这些元数据来自 src/catalog.js 的内置估价表，是静态估计。

用 routeMeta 按部署修正（键可以是完整 provider/model，也可以只写 provider 作兜底；字段可只给需要改的，其余沿用内置值）。校验是逐字段的，且发生在装载期：未知字段、不存在的档位/额度取值、负数或非数字的价格、错类型都会让插件装载失败并指出是哪个路由的哪个字段。给尚未服务的路由预写覆盖是允许的（该路由出现时即刻生效）——为将来加模型做准备不会在今天就报错。

允许的字段只有 in、out、metered、tier、quota、strengths、boundaries；任何"写了但没人读"的字段都会被拒绝，因为那会让配置看起来生效了。

agent-hub:
routeMeta:
codex-chatgpt/gpt-6-astra:
quota: thin # ample | normal | thin
metered: false # 订阅制时不按 token 计价 deepseek-official/deepseek-flash: in: 0.1 # 每百万 token 输入价（USD，估计） out: 0.4 # 每百万 token 输出价 tier: cheap # free | cheap | mid | high strengths: 快速批量任务 boundaries: 不做架构裁决

策略段落里的路由清单同样会括注成本档位，让主智能体在写 models: 短名单时也带着成本意识。协调者如果把整行批注原样抄回，splitRoute 会剥掉 ｜ 之后的部分再校验，不会因此失效。

数据存在哪

不落库。 协作台是宿主进程内的投影：状态来自 subagent/start|end、session/event、agent/assistant-stream、agent/status，重启即空。子智能体本身是持久会话，重启后在普通会话列表里还能找到。

这样选是因为：进度板是"正在发生什么"的视图，不是第二份真相。要长期留存的结论应该写进文档或记忆库，而不是让插件再造一张表。

已知边界

- 父会话必须在活动状态才能派发/投递（见上）。
- 协作台的进度板不持久化，宿主重启后清空。
- 实时传输是插件自己的同源 SSE 路由。若该路由长连不可用，界面会自动降级为轮询并显示「轮询」状态。
- 逐 token 增量来自 agent/assistant-stream；模型如果不开流式，界面就只按步骤更新。
- 工具名到权限的映射在运行时先探测再使用：只有当前注册表里真实存在的工具才会进 toolFilter（tools.restrict() 对未知名字会抛错）。

开发

node --no-warnings tests/smoke.mjs # 宿主半：路由边界、编排、事件投影、实时流（77 项）
node --no-warnings tests/integration.mjs # 跨两半契约：宿主状态 → 浏览器半，浏览器载荷 → 宿主校验（18 项）

宿主半的测试用模拟 ctx 驱动真实的 apply、路由处理器与事件处理器，所以断言的是要发布的代码，而不是它的复刻。

集成测试是这套测试里最值钱的一个：两半之间只共享 CONTRACT.md 与那根网线，任何一侧单独看都可能是绿的，而接缝已经断了——它用宿主半真实产出的快照去驱动浏览器半的纯函数，再让浏览器半构造的派发载荷回到宿主半去过校验。

另有一个需要 DSH 源码 checkout 的检查（不在 npm test 里）：tests/check-primitives.mjs 会把 client.js 解构的每个基元/图标名与外壳真实产物 packages/client/ui-primitives/lib/index.js 的导出做差集。基元名写错会在浏览器里白屏，而任何 Node 侧测试都看不见它。