dsh-tree-task-flow · 树形任务流
给 DeepSeek Harness 的树形任务流：把一件需要多步做完的事组织成 目标 → 任务 → 子任务三级树，每个节点完成时由模型提交结果，插件随即把这个节点的 执行过程从上下文里折叠掉，只留下那条结果。
安装即启用：dsh plugin add 之后就生效，不需要再改任何配置。
不想用的时候，在 profile 里写一句 enabled: false 就能关掉，关掉后一个字节都不碰会话。
它解决什么
长任务跑到后半程，上下文里绝大多数内容是过程：读过哪些文件、试过哪些错、 执行过哪些命令。这些内容对后面没有用，但会一直占着位置——每多一轮， 喂给模型的上下文就更长一分，而其中真正需要留住的只有寥寥几句。
真正需要留给后面的只有一句话：这一步做完了，它产出了什么。
所以这里的分工是：
| 内容 | 去向 | |
|---|---|---|
| 过程 | 读文件、试错、命令输出 | 节点完成时整段折叠掉 |
| 结果 | 模型在 tree_task_done 里提交的 result |
留下来，供后续节点引用 |
折叠按什么切
规则只有一条，只看表层，与计划树无关：
从上一个边界调用之后 → 到下一个 tree_task_done 之前，这一段收走
边界调用是 tree_task_create / tree_task_plan / tree_task_done 这三个工具，
它们的调用与返回都留在上下文里——模型靠它们看"计划是什么、下一步干什么"。
折叠只收它们之间的过程，换成一条计数通告：
[tree_task_plan 调用] [返回：已添加 2 个子任务 + 整棵树]
[tree_task消息：隐藏了 12 条过程上下文。读取：… 写入：…]
[tree_task_done 调用] [返回：接下来需要进行步骤：「二」(s-4)。]
两条硬约束：
- 两次边界调用之间夹着你的消息就不折——往前折丢了需求，往后折丢了回应， 这一段整段跳过，一个节点都不动；
- 两次调用挨着（中间没有过程）也什么都不注入，不追加、不留空消息。
每一次 tree_task_done 的调用与它的返回都留在上下文里，一轮轮累积；
模型下一轮还看得到"我刚做完了什么、接下来干什么"。
折叠发生在 agent/pre-step——上一轮已结束、下一个请求还没构造的那一刻。
工具执行中途不能折叠，那时 surface 还在增长，替换会把自己卷进去。
注入消息与 tree_task_done 的返回
一次折叠在上下文里留下两样东西：
一、折叠通告——哪一段被收走了
tree_task消息：隐藏了12条过程上下文。
读取：C:\apps\x\a.js、C:\apps\x\b.js
写入：C:\apps\x\c.js
只报条数与读写了哪些文件：过程收走了，但"这活碰过哪些文件"得留下，
否则模型要从头再找一遍。路径取自工具调用的 file_path / path 参数——
界面列出文件变更用的是同一个来源；pwsh / bash 里碰过什么文件看不出来，不计入。
二、tree_task_done 的返回——下一步干什么
tree_task消息：接下来需要进行步骤：「步骤二」(s-4)。
按情形是三种之一：
| 情形 | 返回的是 |
|---|---|
| 同层还有下一个 | tree_task消息：接下来需要进行步骤/任务：「标题」(id)。 |
| 同层到头、上一层还没交 | tree_task消息：检查点：任务/目标<id> 的步骤/任务已全部结束，请确认<id> 是否完成，如果完成请调用tree_task_done，如果还需继续，可使用 tree_task_plan 新增步骤/任务继续。 |
| 整棵树都完了 | tree_task消息：请汇报最终结果。 |
两样都不重复提交内容（result 就在这次调用的参数里）。折叠时，这次
tree_task_done 的调用连同它的返回原样留在上下文里，被收走的只是它前面那段过程。
子任务全部结束，不会让父节点自动完成。 那一刻树进入检查点， 也就是上表第二种返回。
检查点只是提示，不是闸门。 它出现在树上，也出现在 tree_task_done 的返回里，
但插件不会拦住任何工具——"这一层到底做完了没有"由模型判断，插件既不替它定死，
也不靠拒绝别的工具把它逼到墙角。
六个工具
| 工具 | 用途 |
|---|---|
tree_task_status |
查看整棵树、各节点状态与已提交的结果，以及现在该推进哪个节点 |
tree_task_create |
新增一个目标：这个目标 + 它下面的若干任务。可多次调用，多个目标并存，不替换已有计划 |
tree_task_plan |
给一个节点追加子节点：给目标追加任务，给任务追加子任务 |
tree_task_done |
完成一个节点并提交它的结果，result 必填；返回的就是"下一步干什么"，这次调用连同返回留在上下文里，被收走的只是它前面的执行过程 |
tree_task_update |
修改一个节点的标题或说明 |
tree_task_drop |
丢弃一个节点；丢弃目标会连同它下面的任务与子任务一起走，丢弃任务带上它的子任务 |
层级固定三级，子任务是最低一级，不能再往下拆。
三层怎么分
| 层 | 是什么 | 怎么算分对了 |
|---|---|---|
| L1 目标 | 最终要交付的东西 | 一个会话可以有多个，按创建顺序排；每个都写清要交付什么 |
| L2 任务 | 交付节点 | 一件能独立验收的交付物（一个文件、一条能跑的命令、一份结论）；下面覆盖多个步骤，别拆到只剩一两个 |
| L3 子任务 | 步骤 | 任务内部一两次工具调用能做完的事 |
折叠次数跟着 tree_task_done 的次数走：每完成一个节点就折一次，界面也会因此多一张
系统提示词卡片。所以任务别拆得太碎——够厚，done 的次数少，上下文前缀变动的次数也少。
result 分两层写：任务的 result 写交付物 + 怎么验收（文件在哪、怎么跑、验出什么、
已知限制），子任务的 result 一句话说清这步做了什么就够。
安装
需要 Node.js 22.19 以上，以及能运行 dsh。
从 npm 安装：
dsh plugin --profile web add dsh-tree-task-flow
从源码目录安装（装成 link:，改完源码重启即生效）。把仓库克隆到任意目录，
然后指向那个目录：
dsh plugin --profile web add <插件目录>
dsh plugin add 会把包加进 profile 的 dsh.profile.bundles，而本包自带的
cordis.patch.yml（由 package.json 的 dsh.bundle.patch 指定）会顺势把
task-tree 这一行插进插件列表——装上即启用，不需要再改任何配置。装完可以核对：
dsh --profile web --dump-config # 输出里应出现 task-tree 这一行，且不带 config
必须重启 dsh web 才生效——运行中的会话不追溯，新工具要在新会话里才会出现。
关闭
不想要了，除了 dsh plugin remove 卸掉，也可以只把它关掉。在
$DSH_HOME/profiles/<名字>/cordis.patch.yml 里写：
- id: task-tree
config:
enabled: false
然后重启 dsh web。仓库里的 config.example.yml 有可以直接抄的完整版本。
⚠️ profile 这一层按行覆盖时
config是整体替换，不是逐字段深合并—— 覆盖时要把想保留的字段一起写全，没写的会走插件默认值（见下面的配置表）。
关掉之后插件一个字节都不碰会话：不注册工具、不加提示词段落、不折叠、不续行、
不挂暂停闸门。只留一条 /task-tree 命令，让你确认它是被关掉的以及怎么打开。
界面
输入框上方的「树形任务流」条目（和内置的待办、目标条目并排，宽度与消息正文对齐）。
外观照内置条目做——用的是同一套 UI 基座（@deepseek-ai/dsh-client-ui-primitives
的图标、Tooltip 与 CSS 变量），所以它看起来就是内置的一部分：
- 折叠时是目标条那样的 36px 单行条：左边清单图标，中间「阶段标签 + 目标标题 + 进度」， 右边一排圆形图标按钮——暂停/继续、清空计划、展开。 阶段标签四种：进行中 / 已暂停 / 检查点 / 已全部完成。
- 展开后是待办清单那样的卡片：三级树之间有竖线与拐角连线，层级一眼看得出来； 同一层的节点之间、节点内部的各个内容块之间，各有一条分界线。 默认只摊开正在走的那条路径——目标一路展开到当前子任务，其余节点收起， 一打开就能看见正在跑的那一个，不用在一堆已经收尾的节点里翻；检查点所在的节点 也一样默认摊开。想细看哪个就点它行尾的箭头，逐层摊开或收起。 当前节点的虚线圈会匀速转，已完成打勾、丢弃的划掉。
- 节点标题不缩略：有多长写多长，多了自动换行。
- 提交的结果默认只占一行，点一下摊开看全文。
- 节点上可以直接完成、丢弃，不用敲命令。
- 数据每 4 秒自动拉一次，模型在后台改计划时界面会自己跟上。
没有计划的会话一个像素都不占——读不到计划就返回 null，不会平白挤掉内置的
待办与目标条目。
开关不在界面上，在 profile 的 cordis.patch.yml 里（见上面的「关闭」一节）。
命令
/task-tree 不经过模型，直接执行：
| 命令 | 作用 |
|---|---|
/task-tree |
查看本会话的任务树与检查点状态 |
/task-tree done <id> <结果> |
提交某个节点的结果并完成它 |
/task-tree drop <id> |
丢弃某个节点 |
/task-tree pause |
暂停：正在跑的工具跑完就停住，不再往下推进 |
/task-tree resume |
继续：从停住的地方接着跑，不往会话里插消息 |
/task-tree reset |
清掉本会话的计划树 |
配置
默认值全在 lib/index.js 的 DEFAULT_CONFIG 里：
| 字段 | 默认 | 说明 |
|---|---|---|
enabled |
true |
总开关；装上即启用，写 false 关掉 |
autoContinue |
false |
模型停下时是否自动续行 |
maxAutoRounds |
5 |
连续自动续行的轮次上限 |
promptOrder |
1800 |
工具说明段落的排序 |
rootDir |
null |
状态目录，默认 $DSH_HOME/dsh-task-tree |
暂停与继续
界面上的暂停按钮（或 /task-tree pause）是真暂停，不是"关掉自动续行"：
- 正在执行的那个工具会正常跑完，不会被中途掐断；
- 它跑完之后，会话就静静停在原地——不再发起模型请求，也不再往下走一步；
- 全程不往会话里插任何消息，上下文干干净净。
继续（界面按钮或 /task-tree resume）就是从这个岔口放行：模型从它原本要请求的地方
接着请求，同样零新增消息。任务树的进度停在哪儿，就从哪儿接着跑。
闸门开在 agent 的 agent/pre-step 上——一个 step 走完、工具结果都已落盘、模型还没
发起下一次请求的那一刻。这是唯一同时满足"不打断工具"和"不留痕迹"的位置：再晚一点
的 agent/turn-stopping 一旦放行，就得靠 steer() 推一条消息才能续上，那就留下痕迹了。
闸门只拦自动推进，不拦真人发言。 暂停期间你自己发一条消息，说明你要它跑， 插件会直接放行并解除暂停，不会把你堵在门外。
暂停期间人按界面上的停止（中断本轮）也不会卡住：闸门盯着本轮的取消信号， 信号一 abort 就立刻放行。
自动续行的三道闸门
autoContinue 默认关闭，开着也只是兜底：tree_task_done 的返回文本里已经带了
"请继续执行下一个子任务"，模型通常会在同一轮里接着做。这里兜的是模型仍然停下来的情况。
开启后仍有三道闸门，缺一不可：
- 默认关——
autoContinue: false时不注册续行逻辑。 - 中断即停——用户按下停止（
agent/turn-stopping且signal.aborted）， 这个会话就被标记为不再自动续行，直到真人再发一条消息。 - 轮次上限——连续续行达到
maxAutoRounds就停；只有真人发的消息才重置配额。
队列里还有排队输入时也不抢，让用户先说话。
另外，暂停会一并压住它：/task-tree pause 之后，即使模型自己停了下来，
兜底也不会把它重新拉起来；/task-tree resume 再放开。
状态文件
全部在 $DSH_HOME/dsh-task-tree/ 下，以 sessionId 为键：
| 文件 | 内容 |
|---|---|
plans/<sessionId>.json |
计划树（每个会话一棵） |
surfaces/<sessionId>.json |
三层的进度游标 { key, cursor }（只给界面看，不参与折叠） |
目录名沿用插件改名前的标识，为的是不让既有的计划文件失联；插件名与它无关。
计划属于建立它的那个会话。放到会话无关的位置，任何一个会话的计划都会被 所有会话读到——那等于把不相干的节点指派塞进别人的上下文。
写入一律走「临时文件 + rename」，进程崩在写入中途也不会留下半截 JSON。
插件绝不直接写会话日志，会话里的一切都走 session.append()。
你会观察到的行为
完成必须写
result。 节点的执行过程会被折叠掉，result是它唯一的出口； 空result会被拒绝。所以要写清"产出了什么"，写成能独立看懂的样子—— 过程会丢，别把过程写进去。折叠只看表层。 两次边界调用之间没有过程时，什么都不注入；中间夹着你的消息时 整段不折——那一段原样留着（往前折丢需求、往后折丢回应），代价是上下文不收缩。
模型看到的工具说明不随计划变化，也不复述工具清单。 那一段只讲什么时候用 这组工具、完成时守什么规矩；每个工具的用法由它自己的
description承担。 要了解计划就让模型调tree_task_status。折叠几次，界面就多几张「系统提示词」卡片，但上下文里的系统提示词始终只有一条。 DSH 把"上下文被替换过"记成一次请求序列的边界（下一次请求带
reason=series）， 界面在reason不是change的请求上都会画一张系统提示词卡片；锚点跟着那一轮 step 走， 卡片于是一张张堆起来。上下文里system/message自始至终只有一条，折叠没有伪造 任何系统消息。已实测：3 次折叠 → 3 次series→ 界面 3 张卡片。改需求用「丢弃 + 追加」，不要重建整棵树。 丢掉的节点留在树里可查， 它和完成的节点会一起被那一段折叠收走（通告只报条数，不区分完成还是丢弃）。
暂停不留痕迹。 暂停后模型看到的是"没有下一条请求"，看不到任何"你被暂停了" 之类的提示；继续之后也不会有"继续"消息进上下文。想让模型知道中间发生过什么， 得自己发消息说。
不做的事
| 不做 | 原因 |
|---|---|
| 资料 / 文件快照 / 记忆 | 上下文里值得留下的只有结果，其余靠模型自己重读 |
| 文件回退 / 撤销 | 改需求用「丢弃 + 追加」 |
| 并行推进多个目标 | 结构上支持一个会话有多个目标（目标层就是兄弟列表），但同一时刻只沿一条活动路径走 |
| 把计划内容注入提示词 | 计划状态由 tree_task_status 现取，提示词里只放不随计划变化的说明 |
卸载
dsh plugin --profile web remove dsh-tree-task-flow
状态目录不会自动清理，需要的话手动删 $DSH_HOME/dsh-task-tree。
许可
MIT
No comments yet. Be the first to write one.