前言¶
在 DeepSeek Harness（dsh）里处理跨度大、步骤多的请求时，常见做法是让同一个会话里的主智能体一路做到底。上下文会不断叠加规划、执行细节和中间结论，窗口压力变大，后面的步骤也更容易被前面的噪声干扰。
下面介绍社区插件 dsh-taskforce（仓库 LiSheng5/dsh-taskforce，目录页 SkillHub）。它把长任务拆成任务图（DAG），由规划者分解工作，各 worker 在一次性、只含本任务所需信息的上下文中执行，并返回结构化报告而非完整对话转录；主流程再审查、通过或重做。DeepSeek Harness 的生态是「一切皆插件」；SkillHub 等目录站由社区维护，与 DeepSeek / 幻方无官方从属关系。
这是什么¶
dsh-taskforce 是面向 DeepSeek Harness 的多智能体编排插件，维护者为 LiSheng5。package 版本为 0.1.0（见仓库 package.json）。
核心循环（资料原文）：plan → dispatch（可并行）→ structured reports → review → pass | redo。在完整循环之上，插件还包含跨进程重启后的图恢复、Web 编排面板，以及用于「大请求未点名编排时仍可能被选中」的系统提示片段；其中「模型是否会在无人点名时主动调用 orchestrate_plan」的行为半部分，README 标明曾因无效 API Key 未跑完验证。
命名说明（有意保留）：本地目录历史名 dsh-orchestra，GitHub 与包名为 dsh-taskforce；工具名 orchestrate_*、服务名 orchestra、投影键 orchestraGraph 与主机 tool-call 日志绑定，改名会破坏旧会话恢复，不宜自行「整理」。
核心功能¶
任务图与上下文路由¶
- 规划阶段生成任务图；
src/graph.js负责 DAG 校验、就绪判断与状态迁移（CAS）。 src/router.js为每个 worker 准备「任务书」，只路由该任务需要的上下文。- 协议与校验：
src/protocol.js（Task / Report / Verdict 等 JSON Schema）、src/json-schema.js（参数校验子集）。
编排工具链¶
插件在 src/tools/ 提供 plan、status、dispatch、review、reroute、finalize 及 ping 等能力；对外工具名前缀为 orchestrate_*。例如 orchestrate_status 在主机重启后会基于恢复后的图作答。
审查与重派¶
审查者对 worker 的结构化报告给出通过或失败；失败时可 reroute 并 re-dispatch，直至 finalize 收尾。worker 报告应视为「主张」，由 reviewer 核实——这与 README 中的 Safety 说明一致。
重启恢复¶
图默认按会话保存在内存中，进程重启会丢失；恢复依赖 dsh 已有的会话日志：
- 主机记录
tool/call（完整参数）与tool/result（渲染输出）；插件不单独写会话事件。 - 注册
orchestraGraph会话投影，把上述事件折叠回任务图；首次由新进程触达该会话时加载。 - 调用效果在 result 落定后生效，避免对正在执行的 call 重复应用；被重启打断的 dispatch 不会半应用，任务停留在 orchestrator 上次所见状态。
若 composition 缺少投影注册表，插件仍可按纯内存模式运行（与旧行为一致）。早于特定 render 契约的旧会话可恢复计划、尝试次数、裁决与 finalized 标记，但无法恢复 dispatch 结果细节——资料明确说明不应伪造成功标记。
Web 面板与提示注入¶
client.js在对话 composer 上方提供编排面板（lazy__ModuleLoader__工厂）；package.json中dsh.client注入@deepseek-ai/dsh-client-ui-conversation，平台为 web，immediately: true。src/prompts.js包含 adoption 片段与 planner 指引；若 composition 没有@deepseek-ai/dsh-system-prompt，仅少「自动选用流水线」那一段，显式点名时各工具仍可用。
安全与 worker 权限¶
插件会拉起具备真实权限的子智能体：在会话工作区内读写文件、执行 shell，受各 worker profile 的工具白名单约束。默认会剥夺主机 agent-plane 的 control 工具（send_message、interrupt_agent、list_agents、subagent、subagent_fork），避免 worker 文本直接进入 orchestrator 会话或干扰父 agent；可通过配置 denyControlPlane: false 保留（README 说明该列表曾由实测校准）。
状态按会话隔离；worker 工具访问白名单可配置；src/profiles.js 映射 agent_type 到 persona / reasoning effort。
质量与兼容¶
- 离线回归：
node test/local-loop.mjs（无需 dsh、API Key、网络）；CI 在每次 push/PR 于 Node 20 / 22 / 24 运行（.github/workflows/offline-regression.yml）；README 称 16 个 offline test groups 通过。 - 兼容（README 表格）：
| dsh 版本 | 说明 |
|---|---|
0.1.7-rc.2 |
开发对标版本；完整循环、重启恢复与 Web 面板已验证 |
0.2.0-rc.2 |
桌面应用运行时；安装、挂载与提示组装在无头环境验证——完整编排循环与 Web 面板尚未在该版本重跑 |
dsh 为开发者预览，官方可能引入破坏性变更；升级 dsh 后建议跑一次上述离线套件。
安装与启用¶
插件 bundle 含 npm 依赖 @deepseek-ai/schemastery；在本地目录需先 pnpm install（README Install 节）。
CLI（web profile 示例）：从本地绝对路径安装：
pnpm install
dsh plugin --profile web add <path-to>/dsh-taskforce
<path-to> 必须为绝对路径。README 同时说明 dsh plugin add 可直接接受 git 规格，由 pnpm 在安装时解析依赖：
dsh plugin add github:LiSheng5/dsh-taskforce
（具体 profile 以你使用的 dsh 配置为准；web 场景常用 --profile web。）
桌面应用：使用自带 launcher，且 desktop profile 仅由应用管理，CLI 不能 boot/dump 或向其中安装。Windows 示例：
"<DeepSeek Harness>\resources\runtime\cli\bin\dsh.cmd" plugin --profile desktop add <path-to>\dsh-taskforce
应用侧栏 Plugins 页支持 registry 名、git 地址、tarball 或本地绝对路径，方式与上一致；bundle 默认启用。修改插件后需重启应用加载。
安装前请自行阅读仓库源码与许可证（private: true 的 npm 包仍应在 GitHub 查看授权与代码），并阅读 dsh SAFETY 说明。插件以当前 dsh 进程权限运行，不宜在未审计的工作区上直接跑大规模编排。
典型用法¶
资料中的主路径是 orchestrator 在会话中驱动 orchestrate_* 工具，而不是单独一条 shell 子命令。
- 规划：调用 plan 类工具，得到任务图（节点、依赖、各 worker 任务描述）。
- 查看状态：
orchestrate_status返回当前图；重启后同样基于日志投影恢复后再答。 - 派发：dispatch 可并行启动多个 worker；每个 worker 在 fresh one-shot 上下文中执行，返回结构化 Report。
- 审查：review 对报告给出 Verdict（pass / fail）；必要时 reroute 并 re-dispatch。
- 收尾：finalize 标记全部工作完成。
对话界面中，composer 上方的 Web 面板用于查看编排状态（与 0.1.7-rc.2 上「已 live 验证」的表述一致）。若希望大任务在未口头指定「用 taskforce」时仍可能被模型选用流水线，composition 需包含 @deepseek-ai/dsh-system-prompt（adoption 片段位置在 workflow 与 subagent 段之后，提示文本到达模型已验证；自动调用行为见前文「未完全验证」说明）。
升级 dsh 或插件后，在工作区根目录（插件仓库内）执行：
node test/local-loop.mjs
若从「重启恢复修复」之前的旧版升级，README 指向「Upgrading from a version that predates the fix」及 scripts/ 下维护脚本，用于修复旧会话日志；细节以 GitHub 该节为准。
更完整的设计说明见仓库旁的 DESIGN.zh.md（README 引用路径为 ../DESIGN.zh.md，以仓库实际布局为准）。
适用场景与注意¶
更适合：需要把「调研 + 多文件改动 + 交叉验证」拆成可并行子任务的长程开发或分析；希望 worker 上下文干净、产出为结构化报告便于审查；需要在 dsh Web / 桌面 UI 里看图状态，并依赖会话日志在重启后继续编排。
需要谨慎：任何会写盘、跑 shell 的多 agent 编排；务必保留 per-task timeout 与 attempt 上限（README Safety）；在重要仓库上先小范围试跑；桌面与 CLI 的 profile 不要混用（desktop 仅应用管理）。
资料未写或不作断言的内容：SkillHub 目录页当前星标为 0；未在已抓取片段中给出具体 cordis.patch.yml 字段或 worker profile 的完整配置示例——实施前请直接阅读仓库 cordis.patch.yml、src/profiles.js 与 index.js 的 inject/apply 逻辑。
结尾¶
dsh-taskforce 把「规划 → 并行派发 → 结构化报告 → 审查 → 通过或重做」做成可恢复、可面板观测的闭环，并刻意与 dsh 工具日志对齐以便重启恢复。若你在 Harness 里做长任务多 agent 协作，可从安装与 node test/local-loop.mjs 自检开始，再按会话内 orchestrate_* 流程试跑。
- 目录页：https://www.skillhub.cn/plugins/LiSheng5/dsh-taskforce
- GitHub：https://github.com/LiSheng5/dsh-taskforce
