agent-lead — /lead 带队模式

主 Agent 只负责理解、拆解、分发、验收与监工；改动类工作一律通过 assign 派给后台 subagent。每次派活都弹窗，由你选这个 subagent 用哪个模型。

装在 ~/.dsh/plugins/agent-lead/，通过 ~/.dsh/cordis.patch.yml 的 insert 行挂到宿主面，所以对所有 agent 预设（含「梁神模式」）生效，且不会被预设升级覆盖。

怎么用

输入	行为
/lead	切换带队模式开关（再次输入退出）
/lead off	强制退出带队模式（CLI 等适配器的显式写法）

命令不接受其他参数；进入模式后直接在对话里发任务即可。

进入后：

• 系统提示里出现带队策略（只在开启时出现，关闭时该区段为空、不进请求）。
• 主 Agent 调 write / edit / str_replace_editor 会被拒绝，并被告知改用 assign 派活。
• read / grep / glob / bash 保留——勘察和验收要用。
• 主 Agent 每次调 assign，你都会收到一个模型选择框。

模型只能弹窗选

assign 只有 description 和 prompt 两个参数，没有 model 参数：模型花多少钱、值不值得，是你的决定，不是模型的决定。所以这里既没有自然语言识别，也没有别名、默认值和「记住上次选择」。

弹窗候选按三段组装，按 provider|model 去重（先出现者保留）：

1. 当前主模型 —— 该会话此刻真正在用的路由，标注「（当前主模型）」。读取顺序：request/header 的 config → request/context → agent.options；首轮请求之前读不到，这一段就省略。
2. 最近最常用的 N 个 —— 来自本插件自己的派活历史，标注「（常用）」。按出现次数降序，同次数看最近一次使用时间。
3. 配置里固定列出的模型 —— 原序展示，保证弹窗永远非空。

显示名优先用配置里的 label，其次是 provider 目录（ctx.llm.listModels）里的名字，最后退回 model id。标签重复时自动追加 · <provider> 消歧。

配置

写在 ~/.dsh/cordis.patch.yml 的这一行里：

    - id: agent-lead
      name: '/home/jiangjunguang/.dsh/plugins/agent-lead/index.mjs'
      config:
        llmProvider: hfai
        models:
          - id: anthropic/claude-opus-4.6
            label: Opus 4.6
            description: 强，贵，适合复杂实现与重构
          - id: deepseek-v4-flash
            label: DeepSeek-V4-Flash
            description: 快，便宜，适合批量与机械改动

key	含义	默认
llmProvider	子 agent 默认 LLM 路由	必填
models[]	{ id, label?, provider?, description? }，固定候选段	必填非空
includeCurrentModel	是否把当前主模型置顶为一项	true
recentCount	「常用」段条数	3
recentWindow	统计频次时只看最近多少条派活记录	50
usageFile	派活历史文件（绝对路径）	$DSH_HOME/agent-lead-usage.json
subagentProvider	ctx.subagents 提供者	spawn
toolName	派活工具名	assign
commandName	命令名	lead
maxDepth	子 agent 深度上限	3
lockedTools[]	开启时禁止主 Agent 自己调用的工具（空数组＝不锁）	['write','edit','str_replace_editor']
section	带队策略提示文本（{{tool}} 会替换成工具名）	内置中文文本

配置非法（models 为空、label 重复、recentCount 不是正整数、usageFile 非绝对路径、commandName 不合法…）会在加载期抛错，而不是等到第一次派活才失败。

状态与数据

• 模式状态不写新的 session 事件类型：Session.append 无法给事件打 ignorable，而 KNOWN_SESSION_EVENT_TYPES 之外的类型会让日志加载直接拒绝。状态由 commands 注册表本来就会写的 command/run（name === commandName）折叠得出——空 args toggle 取反、off 强制退出、其他 args 忽略——因此 resume / fork / compaction 之后都能恢复，也满足「模型可见 ⟺ 已记录」。
• 派活历史存在 usageFile：{ schema: 1, entries: [{ provider, model, time }] }，只保留最近 200 条，写入串行化并原子替换（*.tmp + rename），文件权限 0600。只在派活成功启动后才记一条，失败的派活不进「常用」排序。

已知限制

• 每次派活都要人点一次。 这是设计目标，不是待优化项；不想点就 /lead off。
• 只派后台可续 subagent。 结算通知 + send_message / interrupt_agent 正是监工闭环需要的；本工具没有前台等待路径。
• 子 agent 不能用 assign 再往下派活。 提问通道只认活着的根 agent（DELEGATED_CALLER），此时工具会报错并要求它把待定决定写进最终结果交回主 Agent。
• 没有提问通道就直接失败。 没有 model 参数可兜底，headless / ACP 会话里 assign 会报错而不是偷偷挑一个模型。
• 历史是本机单文件。 多个 dsh 进程并发写为最后写入者赢；读失败只影响候选排序，不影响派活。
• 切换模式会让系统提示前缀变化，因此那一次请求的 KV cache 命中会失效一次。
• 「梁神模式」phase-1 锚定期看不到 assign（tool-bootstrap 会把工具裁到两件），晋升后出现——符合该预设的设计。