dsh-agent-team-auto-orchestrator

dsh-agent-team-auto-orchestrator

DSH 智能体团队编排器（纯宿主插件，无客户端 UI）。

它解决什么问题

DSH 的官方团队包 @deepseek-ai/dsh-experimental-agent-team-profile 只提供工具面

（spawn_teammate / team_task_* / wait_agent / send_message），不注入任何提示

（实测其 lib/index.js 全文 grep systemPrompt 零命中）。结果是：团队工具在线，

但模型默认仍单线程串行干活——「枪在枪套里，没人下命令」。

本插件补的就是这条「下命令」的缺口：注册一条常驻 system-prompt 段，把「判可拆性 →

并行 → 按自定义预设路由 → 任务板跟踪 → 主线程只做拆分与汇总」写进**每个会话、每个

预设**的系统提示里。

机制（为什么是「常驻」而不是「技能」）

| 层 | 生效条件 | 是否常驻 |

|---|---|---|

| 技能（agent-team-routing-law 等） | 需要被 skill 工具加载 | 否（按需） |

| 预设 persona | 该预设的会话 | 是，但每个预设要各写一遍 |

| 本插件的 prompt 段 | 插件挂载即生效 | 是，覆盖全部预设 / 全部会话 |

ctx.systemPrompt.section({ name, order: 250, text }) 是 DSH 官方的常驻提示注册接口，

dsh-todo-float-ball（todo 纪律）、dsh-artifact-linker（产物路径铁律）、

dsh-skill-guard（技能库治理）用的都是同一套。

注入的 8 条规则（v0.3.4 实测 1881~1990 字符；无硬截断，全文注入）

1. 每轮先判可拆性（判独立性，不判难度）。

2. 可拆就并行：默认 2~3 路，独立块 4~6 路，上限 8（含 lead）。

3. 预设路由表：不写在代码里（v0.3.2 起外置）。在 /team-orchestrator.local.json

的 presetRoutes 里填「域 → 你自己的预设 id」（示例见 docs/local-config.md）；

未配置时一律走 spawn_teammate 自建成员，不会猜任何预设 id。

4. >2 个子任务必须建任务板（team_task_*），写入范围不重叠（write_scopes 用工作区相对路径）；建完立刻 claim 认领（owner 参数不生效）→ reassign 改实际执行成员 → 回报后逐个 complete，禁止无主堆积。

5. 主线程只做四件事：拆任务 → 派活 → 收结果 → 合并验收；不亲自跑长活。

6. 团队未开时的降级路径：仍用 subagent 并行，并提示用户「说开团队」。

7. 动手前必须先派活（v0.2.0 硬门，v0.3.0 收紧）：本轮判定为 Fluent / 插件 / DSH / 预设域时，除豁免名单外任何工具调用前都必须先出现 subagent / subagent_fork / spawn_teammate 调用；只建任务板不算开团队。

工具层硬门（v0.2.0）

提示是建议，模型可以不理；硬门在工具分发层强制。

四层判定

| 层 | 机制 |

|---|---|

| 0 域识别 | 订阅 agent/inbox/claimed 缓存本轮用户消息，关键词判 fluent / plugin / dsh / preset 四域（strong 命中 1 个即入域；weak 命中 2 个以上才入域） |

| 1 工具分类 | 入域 → 除豁免名单外全部工具都要先开团队（含 read/glob/grep）；未入域 → 只拦动手类（pwsh/bash/write/edit/run_code/mcp__ansys-fluent__*） |

| 2 状态判定 | 扫 session.snapshotEvents()，本轮出现 subagent / subagent_fork / spawn_teammate 任一即视为已开团队；⚠️ team_task_create 不算（v0.3.0 起，建板只留痕） |

| 3 防死循环 | 同一 turn 最多拦 gateMaxStrikes 次（默认 4），之后放行；拒绝理由会回显「本 turn 第 N / 4 次拦截，再拦 X 次后强制放行」 |

🔴 Fluent 域按【全流程】判定

几何参数 / 命名 / 透明图 / 网格划分 / 网格质量检查 / setfile / 初始化 / MRF / 通气 / PBM / 进程监控 / 云图矢量图 / xyplot / 数据导出 / 产物整理 / 清理 / 排错 —— 每一步都算，连读日志、查 case、读 setfile 也一样要先开团队。

> 这一条是 2026-11-08 用户纠正后的口径：上一版只拦 mcp__ansys-fluent__fluent_run_* 那 5 个工具，面太窄——Fluent 任务绝大多数是用 pwsh 跑 PyFluent、用 write 写 journal，照旧版等于没拦。

豁免名单（永远不拦）

todo_write / ask_user_question / team_task_ / subagent / subagent_fork / spawn_teammate / list_agents / send_message / wait_agent / interrupt_agent / skill / present / cordis_inspect_

> 不豁免这些会死锁：模型连建任务板、加载技能都被拦，就无法自救。

设计原则

• 全部路径 try/catch → fail-open：宁可闸门不生效，绝不因闸门自身 bug 阻塞工作。
• 不要求"必须 ≥2 路并行"：只要求"先派活"；不可拆的单步任务也要派给 1 个子代理或自建 1 个成员，不要自己闷头干。
• 不按调用序号判定：只看"本轮有没有团队工具调用"，天然免疫 run_code 包装与并行批次乱序（dsh-todo-float-ball 踩过"计数卡死"事故，这个坑必须避开）。

v0.3.0 修复（「任务板只增不派、子代理一个不开」）

用户 2026-11-08 实测：多个会话的共享任务板一路涨到 8 条，全是「未分配 · 待处理」，list_agents 只有 lead 一个人。

根因：v0.2.x 的 TEAM_TOOLS 里含 team_task_create，于是「建一条任务板」就算「已开团队」。

模型选了成本最低的过关路径 —— todo_write（豁免）→ pwsh 被拦 1 次 → team_task_create → 放行 → 全程自己干。

叠加两件事：文案写着「不可拆的单步任务也请建一条单任务记录再动手」，且每个 turn 都会重置判定 → 每个 turn 至少往板上丢一条任务；

而 team_task_create 建的是 unowned pending，官方任务板不会自动释放 owner、面板又是只读的 → 永远「未分配」。

| 方案 | 改动 |

|---|---|

| A 判定收紧 | TEAM_TOOLS 剔除 team_task_create，只留 subagent / subagent_fork / spawn_teammate。建板仍在 EXEMPT_TOOLS（永不拦），但不再等于开团队 |

| A′ 配额 | gateMaxStrikes 默认 2 → 4（cordis.patch.yml 同步）；拒绝理由回显「第 N / 4 次，再拦 X 次后强制放行」 |

| B 文案改写 | 第七条改「必须先出现 subagent / subagent_fork / spawn_teammate；只建任务板不算开团队」；末条改「不可拆的单步任务也要派 1 个子代理或自建 1 个成员」 |

| C 任务板卫生 | 第四条新增：建完立刻 claim（owner=实际执行成员）→ 派活 → 回报后逐个 complete；每轮开头收口上轮遗留 pending 无主任务（⚠️ 此处 owner 写法已被 v0.3.1 更正为「claim 只认领自己 + reassign 改 owner」） |

| D 通道选择表 | 新增第三条：按预设分域 → subagent(agent_preset=...)；要常驻/多轮/中途引导/进成员面板 → spawn_teammate（不能指定预设，继承 Lead） |

> 改不掉的边界：spawn_teammate 没有 agent_preset 参数（官方 schema 决定），所以「团队成员按预设分工」做不到。