dsh-agent-lead

LIMITATIONS

Known limitations

- **每次派活都要人点一次。** 这是设计目标，不是待优化项；不想点就 `/lead off`。 - **只派后台可续 subagent。** 结算通知 + `send_message` / `interrupt_agent` 正是监工闭环需要的；本工具没有前台等待路径。 - **子 agent 不能用 `assign` 再往下派活。** 提问通道只认活着的根 agent（`DELEGATED_CALLER`），此时工具会报错并要求它把待定决定写进最终结果交回主 Agent。 - **没有提问通道就直接失败。** 没有 `model` 参数可兜底，headless / ACP 会话里 `assign` 会报错而不是偷偷挑一个模型。 - **历史是本机单文件。** 多个 dsh 进程并发写为最后写入者赢；读失败只影响候选排序，不影响派活。 - **台账为内存态。** 进程重启后丢失。只影响 `lead_status` 历史展示，不影响工具功能。 - **切换模式会让系统提示前缀变化**，因此那一次请求的 KV cache 命中会失效一次。 - **「梁神模式」phase-1 锚定期看不到 `assign`**（`tool-bootstrap` 会把工具裁到两件），晋升后出现——符合该预设的设计。 - **结算误报** — DSH 核心侧的结算通知有时把正常完成的 subagent 标记为 failed/stopped，属已知核心侧问题，后续跟进。带队策略已要求 captain 先查产物再定性。 - **消息无 read-ack** — 目前无法确认子 agent 实际读到了某条消息（只能确认入队），read-ack 属 DSH 核心侧后续跟进。 - **队列操作只对在线子 agent 生效** — 不在线的子 agent 无法操作其 inbox（inbox 随 Agent 生命周期），需先 send_message 唤醒。