dsh-agent-lead:DSH 带队模式插件

前言

在 DSH(DeepSeek Harness)的插件生态中,主 Agent 容易陷入具体实现细节,或者在派活时缺乏对模型选择的控制权。dsh-agent-lead 插件旨在解决这个问题。它将主 Agent 的职责锁定在规划、拆解、分发和验收上,将具体的代码改动工作派发给后台 subagent,并强制在每次派活时由用户选择模型。

是什么

这是一个工作流类插件,用于构建“带队模式”。主 Agent 只负责监工,不直接执行写文件等操作。所有改动类工作必须通过 assign 工具派给后台 subagent。插件通过 /lead 命令控制模式,每次派活都会弹窗让用户选择 subagent 使用的模型。

  • 维护者:JunguangJiang
  • 许可:MIT
  • 安装位置:~/.dsh/plugins/agent-lead/

核心功能

  1. 角色分工:主 Agent 只负责理解、拆解、分发、验收与监工。主 Agent 调用 write / edit / str_replace_editor 会被拒绝,改用 assign。
  2. 模型选择:assign 工具没有 model 参数,必须由用户在弹窗中手动选择模型。系统会根据当前主模型、常用历史记录和配置列表提供候选。
  3. 命令控制:
    • /lead:切换带队模式开关。
    • /lead off:强制退出带队模式。
    • /lead auto:开启全自动派活(assign 不弹窗,自动采用上次选择的模型)。
    • /lead manual:恢复手动选模型(assign 每次弹窗)。
  4. 职责范围(Scope):每次 assign 必须声明 scope(summary 和 paths),作为子 agent 的“地盘契约”。系统支持路径重叠预警,防止多个子 agent 操作同一文件。
  5. 队列与状态:支持 manage_queue 管理待执行消息,支持 lead_status 查看所有子 agent 的实时状态、地盘地图和派活台账。

安装与启用

插件安装后,文件位于 ~/.dsh/plugins/agent-lead/。通过修改宿主配置文件 ~/.dsh/cordis.patch.yml 的 insert 行挂载,对所有 agent 预设生效。

在 cordis.patch.yml 中添加配置:

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

典型用法

基础命令

进入带队模式并提交任务:

/lead <任务描述>

切换模式状态:

/lead              # 切换开关
/lead off          # 强制退出
/lead auto         # 开启全自动派活
/lead manual       # 恢复手动选模型

结合任务提交:

/lead auto <任务>  # 开启 auto 模式并提交
/lead manual <任务> # 恢复 manual 模式并提交

工具调用

派活:assign 是唯一的创建子 agent 途径,必须声明 scope。

assign({
  description: "任务简述",
  prompt: "任务详细说明...",
  scope: {
    summary: "负责数据预处理流水线",
    paths: ["src/preprocess/", "tests/preprocess/"]
  }
})

查看状态:派活前必须调用 lead_status 查看地盘地图。

lead_status        # 查看所有子 agent 状态
lead_status <id>   # 查看特定子 agent

队列管理:查看或操作待执行队列。

manage_queue({
  action: "list"  // list, clear, remove, replace, push, push_front
})

推翻指令:需要打断当前工作或彻底更换方向时使用。

redirect({
  subagentId: "xxx",
  message: "新指令...",
  clearQueue: true,
  scope: { ... } // 可选,用于更新职责范围
})

工作流与决策逻辑

插件内部采用“简版派工单”流程,并在派活前执行决策链:

  1. 规划阶段:Agent 勘察现状,输出简版派工单(任务名 + 干什么),等待用户确认。
  2. 决策链(路由):
    • R1 单一写者:改动的文件与在编 subagent 地盘重叠,必须派给现有 agent。
    • R2 返工归原主:验收不合格发回原主,两次仍不合格则止损换人。
    • R3 独立评审必须新人:审查/验收任务不能派给原作者。
    • R4 同域延续优先复用:基于已完成工作的延续,复用并只写增量。
    • R5 独立新域必新建:无重叠或需真并行,新建 subagent。
    • R6 污染即退役:被 redirect 两次以上或跑偏,不再派新活,新建接班人。
  3. 执行阶段:用户确认后,根据决策结果选择 assign(新建)、send_message(追加)或 redirect(推翻)。
  4. 验收阶段:子任务完成后,主 Agent 按下发指令的验收标准读文件、看 diff,向用户汇报结论。

注意事项

  1. 每次派活都要人点一次:这是设计目标,不想点就使用 /lead off。
  2. 只派后台可续 subagent:插件没有前台等待路径,适合后台任务。
  3. 子 agent 不能再次派活:subagent 不能使用 assign 往下派活,必须把决定写回主 Agent。
  4. 数据持久性:派活台账为内存态,进程重启后丢失;派活历史为单文件(usageFile)。
  5. Scope 重叠:派活时系统会自动检测路径重叠,防止多 agent 修改同一文件。

结尾

dsh-agent-lead 通过强制的主 Agent 监工模式和用户介入的模型选择机制,解决了复杂任务中的责任归属和资源调度问题。适合需要严格代码风格、多人协作或对模型成本敏感的团队。

羽毛球分组比赛记分
小程序二维码

欢迎使用《羽毛球分组比赛记分》微信小程序

小夜