dsh-tree-task-flow · 树形任务流

给 DeepSeek Harness 的树形任务流：把一件需要多步做完的事组织成
目标 → 任务 → 子任务三级树，每个节点完成时由模型提交结果，插件随即把这个节点的
执行过程从上下文里折叠掉，只留下那条结果。

安装即启用：dsh plugin add 之后就生效，不需要再改任何配置。
不想用的时候，在 profile 里写一句 enabled: false 就能关掉，关掉后一个字节都不碰会话。

它解决什么

长任务跑到后半程，上下文里绝大多数内容是过程：读过哪些文件、试过哪些错、
执行过哪些命令。这些内容对后面没有用，但会一直占着位置——每多一轮，
喂给模型的上下文就更长一分，而其中真正需要留住的只有寥寥几句。

真正需要留给后面的只有一句话：这一步做完了，它产出了什么。

所以这里的分工是：

折叠按什么切

规则只有一条，只看表层，与计划树无关：

从「上一次 tree_task_done 之后的第一个 tree_task_create」之后
→  到本次 tree_task_done 之前，这一段收走

起点是上一次 tree_task_done 之后的第一个 tree_task_create；
会话里还没有过 tree_task_done 时，就是表层第一个 tree_task_create；
区间里一次 tree_task_create 都没有时，回退到上一次 tree_task_done 之后。
tree_task_plan 不是边界——它的调用与返回跟普通过程一样，随这一段一起收走。
起点那次 create 的调用与返回留在上下文里，本次 tree_task_done 的调用与返回
同样留着（模型靠它们看"计划是什么、下一步干什么"）。
折叠只收它们之间的过程，换成一条计数通告：

[tree_task_create 调用] [返回：计划已建立 + 整棵树]
[tree_task消息：隐藏了 12 条过程上下文。读取：… 写入：…]
[tree_task_done 调用] [返回：接下来需要进行步骤：「二」(s-4)。]

两条硬约束：

• 折叠区间里夹着你的消息就不折——往前折丢了需求，往后折丢了回应，
  这一段整段跳过，一个节点都不动；
• 区间为空（起点那次调用与 done 紧挨着，中间没有过程）也什么都不注入，
  不追加、不留空消息。

每一次 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)。

按情形是三种之一：

两样都不重复提交内容（result 就在这次调用的参数里）。折叠时，这次
tree_task_done 的调用连同它的返回原样留在上下文里，被收走的只是它前面那段过程
——那一段里若夹着 tree_task_plan 调用，它也跟着一起收走。

子任务全部结束，不会让父节点自动完成。 那一刻树进入检查点，
也就是上表第二种返回。

检查点只是提示，不是闸门。 它出现在树上，也出现在 tree_task_done 的返回里，
但插件不会拦住任何工具——"这一层到底做完了没有"由模型判断，插件既不替它定死，
也不靠拒绝别的工具把它逼到墙角。

六个工具

层级固定三级，子任务是最低一级，不能再往下拆。

三层怎么分

折叠次数跟着 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 不经过模型，直接执行：

配置

默认值全在 lib/index.js 的 DEFAULT_CONFIG 里：

暂停与继续

界面上的暂停按钮（或 /task-tree pause）是真暂停，不是"关掉自动续行"：

• 正在执行的那个工具会正常跑完，不会被中途掐断；
• 它跑完之后，会话就静静停在原地——不再发起模型请求，也不再往下走一步；
• 全程不往会话里插任何消息，上下文干干净净。

继续（界面按钮或 /task-tree resume）就是从这个岔口放行：模型从它原本要请求的地方
接着请求，同样零新增消息。任务树的进度停在哪儿，就从哪儿接着跑。

重启 dsh web 之后暂停依然有效。 "被按住"这件事写在状态目录的 held/ 下，
重启后条目仍显示「已暂停」，点「继续」即可接着跑。区别只有一处：进程重启过之后，
没有挂在岔口上的那一口气可放，插件只能给会话排一条「恢复续行」的消息把它从 idle
推起来——只有跨过重启的这一次恢复会留下这条消息。若那个会话还没被打开（DSH 还没把它
加载成实时 agent），点继续会提示你先打开它，并且保留暂停状态，不会白丢。

闸门开在 agent 的 agent/pre-step 上——一个 step 走完、工具结果都已落盘、模型还没
发起下一次请求的那一刻。这是唯一同时满足"不打断工具"和"不留痕迹"的位置：再晚一点
的 agent/turn-stopping 一旦放行，就得靠 steer() 推一条消息才能续上，那就留下痕迹了。

闸门只拦自动推进，不拦真人发言。 暂停期间你自己发一条消息，说明你要它跑，
插件会直接放行并解除暂停，不会把你堵在门外。

暂停期间人按界面上的停止（中断本轮）也不会卡住：闸门盯着本轮的取消信号，
信号一 abort 就立刻放行。

自动续行的三道闸门

autoContinue 默认关闭，开着也只是兜底：tree_task_done 的返回文本里已经带了
"请继续执行下一个子任务"，模型通常会在同一轮里接着做。这里兜的是模型仍然停下来的情况。

开启后仍有三道闸门，缺一不可：

1. 默认关——autoContinue: false 时不注册续行逻辑。
2. 中断即停——用户按下停止（agent/turn-stopping 且 signal.aborted），
   这个会话就被标记为不再自动续行，直到真人再发一条消息。
3. 轮次上限——连续续行达到 maxAutoRounds 就停；只有真人发的消息才重置配额。

队列里还有排队输入时也不抢，让用户先说话。

另外，暂停会一并压住它：/task-tree pause 之后，即使模型自己停了下来，
兜底也不会把它重新拉起来；/task-tree resume 再放开。

状态文件

全部在 $DSH_HOME/dsh-task-tree/ 下，以 sessionId 为键：

> 目录名沿用插件改名前的标识，为的是不让既有的计划文件失联；插件名与它无关。

计划属于建立它的那个会话。放到会话无关的位置，任何一个会话的计划都会被
所有会话读到——那等于把不相干的节点指派塞进别人的上下文。

写入一律走「临时文件 + rename」，进程崩在写入中途也不会留下半截 JSON。
插件绝不直接写会话日志，会话里的一切都走 session.append()。

你会观察到的行为

1. 完成必须写 result。 节点的执行过程会被折叠掉，result 是它唯一的出口；
   空 result 会被拒绝。所以要写清"产出了什么"，写成能独立看懂的样子——
   过程会丢，别把过程写进去。

2. 折叠只看表层。 起点是上一次 done 之后的第一个 create；
   tree_task_plan 不是边界，它的调用与返回跟过程一样会被收走；区间里没有过程时
   什么都不注入，夹着你的消息时整段不折——那一段原样留着（往前折丢需求、
   往后折丢回应），代价是上下文不收缩。

3. 模型看到的工具说明不随计划变化，也不复述工具清单。 那一段只讲什么时候用
   这组工具、完成时守什么规矩；每个工具的用法由它自己的 description 承担。
   要了解计划就让模型调 tree_task_status。

4. 折叠几次，界面就多几张「系统提示词」卡片，但上下文里的系统提示词始终只有一条。
   DSH 把"上下文被替换过"记成一次请求序列的边界（下一次请求带 reason=series），
   界面在 reason 不是 change 的请求上都会画一张系统提示词卡片；锚点跟着那一轮 step 走，
   卡片于是一张张堆起来。上下文里 system/message 自始至终只有一条，折叠没有伪造
   任何系统消息。已实测：3 次折叠 → 3 次 series → 界面 3 张卡片。

5. 改需求用「丢弃 + 追加」，不要重建整棵树。 丢掉的节点留在树里可查，
   它和完成的节点会一起被那一段折叠收走（通告只报条数，不区分完成还是丢弃）。

6. 暂停不留痕迹。 暂停后模型看到的是"没有下一条请求"，看不到任何"你被暂停了"
   之类的提示；继续之后也不会有"继续"消息进上下文。想让模型知道中间发生过什么，
   得自己发消息说。

7. 内置压缩之后会有一条提醒。 DSH 自己的压缩把一大段历史收成一条检查点之后，
   如果这个会话里有计划树，插件会注入一条
   tree_task消息：上下文刚被压缩过，计划树没有被压缩。用 tree_task_status 取回当前进度…。
   计划树本身不在压缩范围内——它存在磁盘上；但模型会忘掉它，所以补这一句。
   同一个压缩点只提醒一次，之后再被压缩会再提醒一次。

不做的事

卸载

dsh plugin --profile web remove dsh-tree-task-flow

状态目录不会自动清理，需要的话手动删 $DSH_HOME/dsh-task-tree。

许可

MIT