前言¶
用 DSH 做多步任务时,常见的做法是在一个聊天会话里让模型自己拆步骤、自己执行、再自己检查。这种做法的问题是上下文会越滚越大:执行细节、中间试探、报错输出都和最初的目标混在一起,模型审查自己刚写的代码时判断力明显下降,而且每一步都要你盯一下。
dsh-local-superagent(仓库 superchao5717/dsh-local-superagent,维护者 superchao5717)换了个思路:把任务管理做成一张本地看板,执行交给独立的 worker 会话,审查交给独立的 supervisor 会话,你只在被提问时回答。下面介绍这个插件的定位、安装方式和实际使用流程。
这是什么¶
一个 DSH 本地版 Superagent 任务看板插件。你在自己的 DSH 工作区布置任务,插件自动派发给独立执行会话(worker),由主管会话按验收条件审查结果并决定下一步;只有真正需要你决定时,任务才会进入「待你决定」。入口在左侧导航栏 Superagent。
需要说明的是,它是独立的社区插件,不是 DeepSeek 官方产品,也不是上游仓库的 fork 或官方改版。架构参考 DeepSeek 的 dsh-superagent-prototype(注意力经济学、主从双 Session、结构化汇报、审查与恢复),但不提供 GitHub/Gitee 自动接单,任务直接来自本地看板,工作区就是本机目录。
核心功能¶
- 主从双会话:worker 读代码、改文件、验证;supervisor 不读代码、不动手,只对照验收条件给出结论。两者上下文互不污染。
- 确定性派发:任务本身即明确授权,接单、排队、并发控制由 Host 代码完成,不经过模型,避免「漏接单」和一次额外的模型往返。
- 低打扰人工介入:正常推进不弹窗、不往聊天里发消息;只有
needs_you才把任务推到「待你决定」,一次只带一个问题。 - 结构化汇报:worker 只能通过
superagent_report交结果(状态 + 摘要 + 交付物 + 单个问题),状态取值为ready | needs_decision | blocked | failed;汇报内容越界会被 Host 校验或截断。 - 模型按会话注入:主管模型与执行模型范围都可在全局设置里配置;模型固定到会话,不改动 DSH 的全局默认模型。
- 任务附件(0.5.0 起):新任务和回答都支持图片、视频和普通文件,复用 DSH 原生
attachments.saveImages/saveFileStream与fileUploads服务,不另建文件仓库。 - 补充要求与新会话(0.6.0 起):对进行中或已结束的任务发起「关联任务」,自动沿用主管、工作区、历史附件及目标/报告快照,原任务不被中断或改写;最多保留 8 层关联。
- 可恢复:账本是 Host 端 JSON(原子写),插件或 DSH 重启后,运行中的任务重新排队,审查中的任务重新入队。
安装与启用¶
需要 Node.js >= 22 和 DSH。README 声明的实机验证范围仅为 Windows / DSH 0.2.1-rc.5,其他平台和 DSH 版本尚未实机验证。项目不发布 npm(private: true),分发方式是 GitHub 源码及 GitHub Release 的 .tgz,运行代码是 JavaScript,无需 build 步骤。
DSH Desktop:在插件页选择「添加插件」,在「包名或地址」填写固定版本号:
github:superchao5717/dsh-local-superagent#v0.6.0
DSH Web:在运行 DSH Web 的环境执行下面这条命令,注意 --profile 位于 add 之前:
dsh plugin --profile web add github:superchao5717/dsh-local-superagent#v0.6.0
Desktop profile 由 Electron 专属管理,不要使用 Web CLI 命令管理 Desktop。安装后在左侧导航栏打开 Superagent,不要手工编辑 profile 的 bundles 或依赖列表。包名保留 @local/dsh-local-superagent 以兼容已有 profile,@local 不代表只能本地安装。建议安装或升级后重启一次 DSH——插件在启动时轮换自己的主管会话来获得干净的提示词与工具注册。
仓库信息核对:GitHub 星标 0,许可证 MIT,最新版本 v0.6.0(2026-11-05 发布,Release 内含 dsh-local-superagent.tgz 与 SHA256SUMS.txt)。
典型用法¶
按 README 的快速开始走一遍:
- 左侧导航栏点击 Superagent;
- 选中一个 Superagent,新任务自动使用它的工作区;也可以先选工作区过滤主管。在主管 rail 点击 + 创建主管,选中主管旁的 ⋯ 菜单可改名或删除;
- 使用主管区域下方唯一的 布置任务 入口,填写标题、目标/要求、验收条件(可选)、优先级,确认主管归属后 加入队列;
- 插件自动派发、执行、审查;需要你决定时任务仍在「进行中」并显示等待标记,可在顶部问答区或任务详情直接回答,回答后自动继续。
配置在右上角「设置」里统一管理,是一份全局配置,对所有主管及 worker 生效,与当前工作区或主管筛选无关。主要项包括:
| 配置 | 作用 |
|---|---|
每位主管并发上限 maxWorkers |
1–4,是每位主管各自的上限,不是全看板共享的总 worker 池 |
| Superagent 模型 | supervisor 会话使用的模型,留空则跟随 DSH 部署默认模型 |
| 工作代理模型范围 | worker 允许使用的模型范围,可多选,第一个是默认执行模型;全部不选时继承 Superagent 模型 |
| 自动审查 | 开关 |
| 暂停 / 恢复 | 暂停停止派发新任务,运行中的继续 |
| 超时自主续办 | 默认关闭;开启后等待时间 1–1440 分钟,默认 30 |
关于模型范围有两点值得注意:主管审查时可以在 payload 里看到 worker_models 范围,判 continue 时可附带 worker_model,指定下一轮执行会话换一个范围内的模型(比如小模型没做出来时升级模型);不在范围内的模型会被 Host 拒绝并返回可选范围。执行会话默认使用范围内的第一个模型,也可以在设置里把任一已选模型「设为默认」。
完整执行链路如下:
看板布置任务(工作区 + 标题 + 目标 + 验收)
│ 确定性调度(Host 代码,不需要模型参与)
▼
每轮一个全新的 worker Session(工作区目录、工具集受限、系统提示注入)
│ superagent_report 恰好一次:ready | needs_decision | blocked | failed
▼
所属 Superagent 的持久 supervisor Session 审查(只判断、不执行)
│ superagent_review:done | continue | needs_you | fail
├─ done → 已完成
├─ continue → 按容量派发下一轮 worker(携带上一轮摘要,最多连续 2 轮)
├─ needs_you → 进入「待你决定」,只带一个问题
└─ fail → 失败
止损方面 worker 被要求「验证点到为止、同命令失败两次即停、单轮尽量 10 分钟」,Host 另有 45 分钟超时兜底,超时转人工决定。worker 会话会出现在所属工作区的会话列表里(标题 ⚡ 任务名),可以直接点开看执行过程。
适用场景与注意¶
适合想在 DSH 里把长任务拆成「执行—审查—人工决策」闭环、又不希望聊天窗口被中间过程淹没的用户。也适合需要按验收条件批量派发改动、人工只做审批节点的团队。
有几条限制要提前知道:
- 多主管不等于文件隔离。同一个工作区内的主管访问同一磁盘目录,插件不自动提供文件锁。并行修改同一仓库前要划分文件范围,或用项目自己的独立 worktree。
- 超时自主续办不绕过人的权限。暂停时不自动续办;登录、认证、权限、付款、新增授权这类必须由人完成的步骤不能借此绕过。每个任务在人回答或手动重试前最多尝试一次超时自主续办,后续仍会转人工。
- 附件上限。单文件/视频最多 100 MiB,单图片最多
min(原生限制, 20 MiB);每任务初始及全部回答累计最多 20 个 / 200 MiB。视频和其它文件通过原生文件工具读取,插件不自动转码或抽帧。图片需要所选模型支持,否则明确转人工处理。 - 图表与状态页不改动 DSH 全局默认模型。配置按会话注入,新值只影响后续审查与派发,不强行中断当前请求或执行轮。
- 验证范围有限。README 声明的实机验证只有 Windows / DSH 0.2.1-rc.5,另外 0.6.0 发布说明注明本版未重新验收真实模型的完整「附件 → 关联任务 → 主管审查」闭环。2026-11-05 的记录显示包版本仍为 0.5.0 时完成了 107/107 离线测试和 11 个运行文件语法检查。
- 升级前备份。0.4.0 迁移到 schema 3 前要备份账本并等待执行中的任务结束;schema 3 不建议直接用旧版 0.3.0 覆盖运行,也不承诺自动兼容降级。0.5.0 起的附件功能也不承诺降级后保留。
插件以当前 DSH 进程权限运行,安装前建议先读一遍源码,并核对许可证(MIT)。
小结¶
它解决的不是模型能力问题,而是上下文污染和注意力分配问题:把执行、审查、人工决策拆到独立会话里,看板只负责调度。如果你的工作流需要在本地目录上跑多轮验证、由一个「主管」按验收条件把关、只在关键节点问你一次,这个插件的结构是对口的;如果需要 GitHub/Gitee 自动接单或跨机器任务池,它目前不提供。