前言¶

智能体在真实项目里连续交付多个任务时，常见三类问题：任务状态只存在对话里，跑完的任务没法核对改动，循环派活没有人卡验收。qiqll/dsh-task-suite 把 Claude 的 task-* 任务体系移植到 DeepSeek Harness（DSH），提供一份磁盘上的任务池，加上状态机、主会话调度、后台 worker 和机器验收。

它没有 Web 任务板，backlog.md 就是看板；也不强制 git，没有 git 仓库时用文件快照完成基线比对、改动归属和回滚。下面介绍它的安装、目录结构、用法和验收逻辑。

一、这是什么¶

qiqll/dsh-task-suite 是 DSH 的本地插件，维护者 qiqll，许可证为 MIT（见 package.json），运行要求 Node >= 20。

它把四个角色拆进一份任务池加一套工具：主 agent 负责与需求方对话、排期、派活、验收；后台 subagent 在全新上下文里完成单个任务并输出结构化报告。任务池是磁盘上的 Markdown，需求方可以直接看、直接改。

与已有做法的区别：Claude 的 task-* 生态状态目录在 .claude/，本插件只使用 .dsh/tasks/，默认不碰 .claude/ 池。它没有内置心跳或 cron，长循环需要外部定时器提醒主会话 tick；也没有 Web 任务板。

二、安装与启用¶

从 GitHub 源码安装，这是当前推荐的方式：

dsh plugin add qiqll/dsh-task-suite

npm 包发布后也可以直接按包名安装：

dsh plugin add dsh-task-suite
# 或指定 profile
dsh plugin --profile web add dsh-task-suite

桌面版在 设置 → 插件 里搜索 dsh-task-suite 安装。首次安装后工具与三个 skill（task-admin / task-loop / task-worker）自动注册，无需重启。

插件按 awesome-dsh-plugin 的收录格式准备，市场卡片、安装与更新由该目录和 npm 版本驱动。这是社区目录，与 DeepSeek / 幻方无官方从属关系。

本地开发时把本目录用 link: 指向 profile 的依赖即可；改代码后对该插件行禁用再启用，就完成热重载。

三、状态目录与状态机¶

任务池落在 .dsh/tasks/：

.dsh/tasks/
├── backlog.md          # 需求方入口：P0–P3 表、待决策、人工阻塞、ID 规则
├── dev-plan.md         # AI 维护：当前批次、进行中、技术前置
├── dev-progress.md     # 已完成归档（按月）
├── inbox/              # 需求方/调度方投递（task_*.json），merge 后移到 .merged/
└── auto/               # 运行时状态，整目录 gitignore
    ├── current.json    # 当前任务：nonce / startSha / 脏文件 / 阶段
    ├── session.json    # 循环会话：active / max / hours / done / noprog
    ├── run.log         # 运行流水
    ├── STOP            # 停机标记
    └── snapshots/      # 非 git 模式：开工快照 + manifest（确认后删）
        └── T-001-<nonce>/
            ├── manifest.json
            └── files/

task_init 在 git 仓库里会把 .dsh/tasks/ 加进 .gitignore，非 git 目录不创建该文件。每个工作区独立一份池；任务池是运行态，不进业务提交。

状态机：

待开始 → 进行中 → 待验证 → 已完成
             └→ 阻塞 / 待决策 → 待开始
             └→ 打回 → 进行中

同一时刻只允许一个「进行中」；P0 可中断，旧任务记录断点。

四、建池与录入¶

先用 task_init 建目录，再用 task_add 录入任务：

task_init                                   # 建 .dsh/tasks/（git 仓库里顺带写 .gitignore）
task_add items=[{title, module, priority, deps, acceptance, note}]
task_status                                 # 全局视图 / 待决策 / 阻塞 / 流水

task_add 一次可以录入 1..N 条，会自动判重、分配 ID、检查依赖和验收字段，参数有 items[] 和 source。task_status 给出全局视图与下一步建议。

单步手动模式：

task_pick mode=manual task_id=T-001         # 自己认领并实施
task_accept report="<报告块>"               # 机器验收
task_confirm task_id=T-001 conclusion="..." # 需求方确认后归档

五、自动循环与后台 worker¶

自动循环是推荐用法：

task_loop action=start max=10 hours=8
task_loop action=tick        # 返回 worker_prompt
# 把 worker_prompt 原样交给 subagent 工具；然后结束回合等完成通知
# 收到 worker 的最后一条消息后：
task_accept report="<整段报告块>"
# 通过 → 待验证；需求方确认 → task_confirm；不通过 → task_reject
task_loop action=tick        # 派下一个

task_loop 的 action 有 start / tick / stop / halt / resume / requeue / status。正常停机用 task_loop action=stop reason="..."；中途叫停要先调用 interrupt_agent，再 task_loop action=halt，halt 保留提交但不回滚。叫停后继续用 action=resume（同一任务带断点重派），放回队列用 action=requeue。

没有内置心跳，长循环可以用 schedule_create 定时提醒主会话 tick。

六、工具一览¶

七、Worker 报告契约¶

worker 最后一条消息只输出结构化报告块：

=== TASK-AUTO REPORT ===
NONCE: <current.json 的口令>
RESULT: DONE | NEEDS_DECISION | BLOCKED | BASELINE_RED | FAILED | GATE_PENDING_REVIEW
TASK: T-001
START_SHA: <开工 SHA>
COMMITS: <sha...>
TEST_CMD: <[cd dir &&] 单条测试命令 路径...>
TEST_RESULT: 基线 x passed, y failed → 交付后 z passed, w failed；既有失败：...
TEST_CHANGES: 仅新增 / 无改动 / 有修改（说明）
GATE: <code-reviewer H×n M×n；跳过原因；...>
ACCEPTANCE: <对照验收标准>
ASSUMPTIONS: — / ...
DECISION: — / 问题 / 选项 / 推荐
BLOCKER: — / ...
DERIVED:
- [P2] 标题 | 涉及文件 ... | 来源 ...
BRIEF:
给需求方的 1–3 句人话说明
=== END REPORT ===

task_accept 校验 nonce、任务归属、阶段、提交信息里的任务 ID、脏文件、测试范围与基线失败集合、测试是否被改弱、高风险路径。通过后把任务落到「待验证」并生成衍生任务；失败则按 RESULT 进入待决策 / 阻塞 / 自动失败计数。

GATE_PENDING_REVIEW 时验收暂停在 review_pending：调度员自己看 start_sha..HEAD，通过就再调用 task_accept 并传 review="pass: ..."（同一报告即可）；不通过就把发现发回 worker 修复并重交。

八、两种基线模式¶

mode 默认 auto：能拿到 git HEAD 就用 git 模式，否则自动用文件模式；也可以强制 mode: file / mode: git。

快照默认排除 .git、node_modules、.venv/venv、__pycache__、dist/build、.dsh/tasks 等。项目很大时用 snapshotIgnore 排除更多目录，或调大 snapshotMaxBytes / snapshotMaxFiles。任务确认/打回后快照会删除，默认只保留最近 10 份快照。

文件模式的 TEST_CMD、测试改弱审计、nonce、遗留文件检查与 git 模式完全一致；只是「提交归属」换成「快照差异归属」。

九、验收与防作弊¶

1、nonce：每次 claim 生成一次性口令，旧报告/重复通知直接丢弃。
2、提交归属（git）：git log START_SHA..HEAD 里每个 commit 的 message 必须含任务 ID；出现别人的 commit 就停下，不自动处理。
3、改动归属（文件）：与开工快照比对，新增/修改/删除都列出；报告 CHANGES 与实际不符会告警。
4、基线比对：当前测试失败时，在 git worktree 的 START_SHA（git）或快照副本（文件）上重跑同一命令，只有「基线也失败」的用例才算既有失败；新失败 → 打回。
5、测试范围：TEST_CMD 必须是单条命令，禁止 ; | & $( > < 与 -k/--deselect/--ignore/--lf/--collect-only/--passWithNoTests；改动/删除的测试文件必须落在命令路径参数覆盖范围内。
6、改弱审计：删除用例、移走文件、skip/xfail、注释断言、断言净减少、测试配置 ignore 都会产生告警；DONE 带告警 → 转「待决策」。
7、高风险路径：认证、支付、迁移、部署、CI、依赖清单等；命中时要求报告写 GATE 与 ASSUMPTIONS，否则转人工 review。

机器验收在原 verify_tests.sh / check_test_weakening.sh 的基础上重写为 Node 实现，判定口径保持一致。

十、配置项¶

插件配置写在 cordis.patch.yml 的 config，可以覆盖以下默认值：

十一、适用场景与注意¶

适合需要在本地项目里连续做多个任务、希望每一条交付都有验收和归档的 DSH 使用者；也适合没有 git 仓库，但仍要区分「这次改动属于哪个任务」的场景。

需要注意几点：插件以当前 dsh 进程的权限运行，会写 .dsh/tasks/，并按配置做快照、git worktree 和测试命令回放。安装前应阅读源码与许可证，确认测试命令、进程派生与文件操作范围符合项目要求。

开发自测可以直接执行：

cd dsh-task-suite
node selftest.mjs

自测覆盖两种模式：git 下的建池/录入/解析、认领、报告解析、DONE 验收与归档、FAIL_NEW 基线比对、测试改弱、inbox、待决策、循环启停、halt/resume/requeue；非 git 下的快照认领、快照差异归属、DONE 验收、FAIL_NEW 基线、测试改弱、失败回滚。

结尾¶

dsh-task-suite 把 task-* 的排期、派活、验收三件事落到磁盘上：backlog.md 可读可改，验收由机器按基线比对与改弱审计完成，git 仓库和非 git 目录都能跑。目录页在 https://www.skillhub.cn/plugins/qiqll/dsh-task-suite，源码在 https://github.com/qiqll/dsh-task-suite。