前言¶
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 的工具一覽如下:
| 工具 | 能力 | 描述 |
|---|---|---|
task_push |
推送任務 | 投遞新任務到共享隊列,指定標題/描述/優先級/標籤 |
task_list |
查詢任務 | 按狀態/優先級/標籤篩選,返回降序列表 |
task_claim |
認領任務 | 認領一個開放任務,標記爲 claimed |
task_done |
完成任務 | 標記任務爲已完成,記錄結果 |
task_cancel |
取消任務 | open 則刪除,claimed 則退回 open |
handoff_write |
寫交接摘要 | 記錄當前會話的工作進展和待辦事項 |
handoff_read |
讀交接摘要 | 按會話 ID 或最近 N 條讀取 |
任務狀態在 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