前言¶

用 DSH 做多任务开发时，常见的做法是手工开多个会话，每个会话写一段指令，然后逐个盯着。任务一多，注意力就被「哪个会话卡住了、该给谁发消息、产物回来没有」耗掉，真正要你做的判断没有时间做。

dsh-leader-agent 换一个组织方式：你只跟一个 Leader 会话说目标，Leader 拆卡、派工、盯每个 worker 完成、验证产物并组织 Review，worker 在后台各自干活并自动回报，任务事实落在按项目组织的看板上。它不是「一段更聪明的 prompt」，而是靠会话身份、机制侧完成结算和常驻 worker 会话三件事撑起来的编排 bundle。

下面介绍这个插件：它是什么、怎么装、怎么跑、有什么限制。

这是什么¶

fengshenx/dsh-leader-agent，由 fengshenx 维护，MIT License，仓库语言 JavaScript，分类属于工作流。GitHub 描述是「DSH leader/worker orchestration bundle: project tree, delivery board, worker sessions」。

一句话定位：给 DeepSeek Harness（dsh）加一层 Leader/worker 编排，外加一个交付看板和项目树。

解决的问题是单个 DSH 会话只能盯一件事：拆出去的任务没有统一登记、没有验收锚点、worker 完成了也不知道，只能靠人逐个查会话。这个 bundle 把拆卡、派工、回报、验收收进一套机制里，目标是一个人同时推进多个任务而不必逐个陪跑。README 给出的目标规模是一次并行开发 10 个 feature。

• 版本：0.3.1，状态 developer preview（来自仓库 package.json 与 README 徽标）。
• 运行要求：dsh >=0.2.1-rc.2 <0.3.0，Node >=24.9.0（engines 字段）。
• 仓库数据：1 个 star，0 fork，4 个 open issue（取自 GitHub 仓库页面，2026-11-06）。

注意：README 明确「一人一个 worktree 是本仓库的约定，不是 bundle 的硬性要求」，不要把它当成安装前提。

核心功能¶

1、Leader 统一驱动开发与 Review¶

你只声明目标，Leader 负责拆卡、派工、盯住每个 worker 到完成、验证交付物、组织 Review。人的注意力回到「要什么」，而不是「哪个 agent 卡住了」。

支撑这一点的是工具面的裁剪，而不是提示词：Leader 会话拿得到 spawn_worker / message_worker，worker 拿不到；工具面在会话创建时由宿主裁剪。

2、项目树与右栏交付看板¶

左栏是项目与每个 Leader 派出的 worker；右栏 SidePanel 是交付看板，一卡一件事，卡面显示执行者槽位与实时信号灯，说明按 Markdown 渲染，链接可在详情浮层里直接编辑。

点卡面看详情（目标、范围、验收、链接，其余只读），点槽位 chip 直接下钻到那个 worker 的会话接着聊，不需要经过 Leader。worker 的回报渲染成气泡，同样支持 Markdown。

项目之间互相隔离：一个项目绑定一个 Leader 会话，删除项目只删记录，文件夹与会话保留（dsh 工作区不受影响）；换 Leader 时，原班 worker 与未投递的回报一并改投新会话。

3、规则写在 LEADER.md 与 SLOTS.md¶

编排规则不写进死提示词，而是写进两个文件：

两个文件在每次模型请求前求值、正文变化才追加，改文件即在下一个请求生效，不用重建会话。没写 SLOTS.md 的项目回落默认两角色 dev / review。项目初始化由 init-leader-agent skill 负责：先把仓库工程约定并入目标项目 AGENTS.md 的受管区块，再按包内骨架写 LEADER.md 与 SLOTS.md。

leader-mode skill 是给 Leader 的编排协议，按技术讨论 → 设计 → 实现交付 → 审查 → 合入分阶段给 playbook，另有并行协作与交接规范。它靠模型按需调 skill 工具加载，不是配置文件。

4、回看 worker 的会话过程，不唤醒它¶

read_worker_session 直读 worker 的会话日志，给出每轮的任务、正文、调过哪些工具与失败原因。它是只读的：不唤醒 worker、不产生模型调用。完成通知负责说明「产物是什么」，这个工具负责说明「过程是怎样的」，排查不必再开一轮。

5、完成由机制结算并自动唤醒 Leader¶

worker 那一轮结束时，Leader 自动收到一条回报，不轮询、不靠 worker 自觉。worker 是常驻根会话，能同时跑多个，进程重启后可以冷恢复。

安装与启用¶

Web 版¶

从 npm 安装（包名 dsh-leader-agent）：

dsh plugin --profile web add dsh-leader-agent
dsh web

profile 名必须用 web。自定义名不在 PROFILE_TEMPLATES 里，装出来缺 web-app bundle，客户端半边不加载。需要 dsh >=0.2.1-rc.2 <0.3.0，engines.dsh 不满足时安装与启动被拒绝。

指定版本、卸载、开发期安装的写法见仓库 docs/development.md。不装 profile 直接试跑，可在 dsh 源码目录执行：

pnpm dsh web --patch <本仓>/cordis.patch.yml

桌面版¶

桌面版使用独立 profile（$DSH_HOME/profiles/desktop），与 web 互不相通。图形界面安装：左侧 SidePanel 打开「插件」，点右上角「添加插件」，在包名框填 dsh-leader-agent 后点「安装」。

命令行安装要用桌面安装自带的 CLI，系统 dsh 拒绝管理 desktop profile：

# 先完全退出应用（关窗口只是隐藏）
"/Applications/DeepSeek Harness.app/Contents/Resources/runtime/cli/bin/dsh" \
  plugin --profile desktop add dsh-leader-agent

Windows / Linux 换成安装目录里对应的 runtime/cli/bin/dsh。DSH_HOME 要用绝对路径或 ~/ 写法。会话、项目与卡片数据与 web 共享，插件包与激活状态各自一份。

在本仓库内开发时改用 npm run desktop：挂当前工作树、重建产物并拉起应用，-- --remove 摘除。

从 dsh-leader-kit 升级¶

包名改成 dsh-leader-agent，不提供兼容路径。dsh plugin add 写进 dsh.profile.bundles 的是包名，旧条目升级后仍在，两个 bundle 都会生效，结果是工具注册两次、agent/created 订阅两次、两个 dispatcher 各结算同一个 turn/end。先删掉旧条目：

dsh plugin --profile web remove dsh-leader-kit
dsh plugin --profile web add dsh-leader-agent

数据目录随包名改为 $DSH_HOME/dsh-leader-agent，不迁移：升级后看板是空的，worker 登记表首次启动重建。

典型用法¶

按 README 的五步走一遍。

1、加项目。左栏「项目」区块点「加项目」，选一个目录。项目当场建好并绑定一个 Leader 会话，点项目行就是打开这个 Leader。

2、加载协议。在 Leader 会话里让模型加载 leader-mode，先读 playbooks/program.md，再按阶段读对应 playbook。

3、派工。spawn_worker 只要求 name（角色-任务短名），可带 cardId + slot 一次把卡槽位绑好；工具立即返回会话 id，此时 worker 还没开工。用 message_worker 投递任务正文（sessionId + message，可顺手 rename），第一条消息才开工。

4、记任务事实。create_card 建卡（title 必填），update_card 改卡（改内容带 expectedRevision 做乐观并发），list_cards 查卡。卡片按项目归属，编号全局递增，跨项目改卡会被拒绝。list_cards 与 create_card 只给 Leader，update_card Leader 与 worker 都有，但 worker 只能改自己挂着的卡，且只能挂 links 这类派生字段，title / spec / status / slots 都归 Leader。

5、看看板。右栏「看板」Tab，按当前会话所属项目拉卡片。Leader 建卡后自动打开；点卡片看详情，点槽位 chip 打开执行者会话。

经过上面的步骤，Leader 侧的循环是：建卡 → 派工 → worker 后台执行 → turn 结束由机制结算并唤醒 Leader → 看板信号灯更新 → 人可以直接打开任一 worker 接着聊。

适用场景与注意¶

适合的场景：一个 DSH 实例里同时推进多个相对独立的编码任务，希望有人统一拆任务、盯完成、做验收；或者希望按项目把会话和任务事实整理起来，而不是散落在一堆平级会话里。

需要先接受的前提：

• worker 在后台跑，Leader 没有中止 worker 的手段（interrupt_agent 对它无效并会返回假成功回执）。worker 卡住或跑偏，只能由人去那个会话里处理。
• worker 的沙箱模式与审批策略在派工那一刻从 Leader 继承，此后不再跟随 Leader 的 preset 变化。后台 worker 的 ask 没人应答，一律落到 unavailable，需要审批的调用会被直接拒绝。
• 后台编排只适用于长驻组合（web / desktop / sdk）。headless 是一次性 CLI，会话在 turn 结束后销毁，没有载体接收完成通知。
• LEADER.md / SLOTS.md 改动只在下一次模型请求生效，正在跑的那一轮不变。
• 插件代码运行在当前 dsh 进程内，以当前进程权限执行，并会注册会话事件等宿主扩展。安装前建议先读一遍源码与许可证（MIT）再决定是否引入。
• 项目当前处于 developer preview，README 也写了「项目还缺少一些初始化机制」，实际使用需要在项目内初始化 LEADER.md 与 SLOTS.md。

结尾¶

dsh-leader-agent 的价值在于把「多会话并发」这件事变成有登记、有验收、有回报的编排：Leader 负责拆与验，worker 负责干，看板负责让你一眼看到谁在工作、产物到哪一步。它解决的是注意力问题，不是模型能力问题，因此合理的预期是帮你管理并发，而不是降低任务本身的复杂度。

目录页：https://www.skillhub.cn/plugins/fengshenx/dsh-leader-agent
GitHub：https://github.com/fengshenx/dsh-leader-agent