前言¶

DSH 的会话生命周期是独立的：会话 A 做完的工作，会话 B 默认不知道；子 agent 跑完的任务，也带到不了下一个会话。想继续上次的事，要么靠人把上下文重新讲一遍，要么把待办抄进某个外部工具。dsh-task-relay 就是把这块外部工具挪到插件里：一个基于持久队列的跨会话任务接力板，外加会话交接摘要。

下面介绍这个插件的定位、工具、安装方式和典型用法。信息以 YaoleWu/dsh-task-relay 仓库 README 与 GitHub 仓库元数据为准。

这是什么¶

dsh-task-relay 由 YaoleWu 维护，MIT 许可，TypeScript 编写，目前 GitHub 上 2 个星标，分类属工作流方向。它提供两样东西：

• 一个跨会话共享任务队列，任何会话（包括子 agent）都能投递、认领、完成、取消任务；
• 一份会话交接摘要，会话结束时记录进展和待办，新会话启动时读取。

它不联网、不执行外部命令，数据落在本地 JSON 文件里。插件定位是纯工具插件，注册 7 个工具供会话调用。

七个工具¶

README 的工具一览如下：

任务状态在 open、claimed、done 之间流转，取消时按当前状态区分处理。认领和完成有会话归属校验，防止别的会话乱改。

安装与启用¶

README 给出的安装命令如下：

# 安装到 web profile
dsh plugin --profile web add github:LeslieWylie/dsh-task-relay

# 安装到 headless profile
dsh plugin --profile headless add github:LeslieWylie/dsh-task-relay

或者在 cordis.yml 中追加 bundle 声明：

- id: task-relay
  name: 'dsh-task-relay'

需要留意一点：README 里的 owner 是 LeslieWylie，而当前仓库实际位于 YaoleWu/dsh-task-relay。安装前建议先确认该 GitHub 路径可解析，或以目录页与仓库页面上的实际命令为准。

启用后如果想找别的路径，在 bundle 行加 config.root 即可：

- id: task-relay
  name: 'dsh-task-relay'
  config:
    root: '~/.dsh/task-relay-staging'

仓库内还有 cordis.patch.yml，作为 DSH bundle patch 使用。

典型用法¶

跨会话任务接力¶

会话 A 投递一条任务：

task_push title="修复登录页 Bug" priority="high" tags=["bug","frontend"]
→ { "id": "T1723647600000-1", "title": "修复登录页 Bug", "status": "open", ... }

会话 B 查看并认领：

task_list status="open" priority="high"
→ 共 1 条任务，显示 1 条
task_claim id="T1723647600000-1"
→ { "id": "T1723647600000-1", "status": "claimed", "claimedBy": "session-b", ... }

会话 B 完成后回写结果：

task_done id="T1723647600000-1" result="已修复，commit abc123"
→ { "id": "T1723647600000-1", "status": "done", "result": "已修复，commit abc123", ... }

这条链路不要求两会话同时在线，队列持久化后由下一个认领者接着做。

会话交接¶

会话结束时写摘要：

handoff_write summary="完成了功能 A 的开发，剩余功能 B 和 C 待做。功能 B 的前端组件已搭好框架，后端 API 需要从 session-x 的交接中获取接口文档。"
→ { "sessionId": "session-a", "summary": "...", "openTasks": 2, ... }

新会话启动时读摘要：

handoff_read
→ 共 3 条交接摘要，显示最近 5 条

handoff_write 返回里带 openTasks 数量，handoff_read 可以按会话 ID 取，也可以取最近 N 条。

数据存放与边界¶

队列文件默认位于 $HOME/.dsh/task-relay/queue.json，写入采用 temp file + rename 的原子写入，避免进程中途被杀造成数据损坏。目录权限为 700，其他用户读不到。

输入验证在源码层做：标题 200 字符、描述 4000 字符、摘要 2000 字符、标签最多 10 个。验证逻辑集中在 src/invariant.ts，存储在 src/store.ts，工具定义在 src/tools.ts。单元测试 18 个覆盖存储层，8 个覆盖工具注册与执行，另有 tests/boot.test.mjs 通过真实 cordis registry 执行构建产物。

仓库里同时提交了 lib/ 构建产物。README 解释了原因：pnpm 出于安全考虑默认拒绝为 git 依赖执行构建脚本，从 GitHub 安装时会因为包入口 lib/index.js 不存在而失败，所以必须把 tsc 产物一并提交。代价是构建产物可能与源码脱节，boot.test.mjs 和 CI 各自重新构建一次再比对，脱节就报错。

适用与注意¶

适合的使用方式是：长任务拆成多个会话接力、子 agent 之间交接中间产物、给后续会话留一份可检索的工作记录。纯工具插件的定位也意味着它不适合需要联网协作或权限隔离的场景——所有数据都在本机主目录下。

几点提醒：

• 插件运行时以当前 DSH 进程的权限操作文件，安装前应先读一遍源码，确认调用方可访问 ~/.dsh/task-relay/；
• 许可证为 MIT，商用前看一眼 LICENSE 原文；
• peer 依赖范围写得比较绕，@deepseek-ai/dsh-tools 限定为 >=0.0.1-rc.1 <0.1.0 || >=0.1.0-rc.1 <0.2.0-0，理由是 semver 的预发布版本匹配规则，直接写成 >=0.0.1-rc.1 <0.2.0 会匹配不上当前的 0.1.0-rc.6；
• 目录页是社区独立站点，与 DeepSeek / 幻方无官方从属关系，插件信息以仓库为准。

结尾¶

dsh-task-relay 的价值在于把跨会话的调度成本压到几个工具调用：task_push 投递、task_claim 认领、task_done 回写、handoff_write 交接，再加上本地原子持久化和输入校验。星标还不多，源码规模有限，接口清晰，值得在需要跨会话接力时试一下。

目录页：https://www.skillhub.cn/plugins/YaoleWu/dsh-task-relay
仓库：https://github.com/YaoleWu/dsh-task-relay