前言¶

DSH 的 Agent 会话需要明确的目标才能干活，但这类目标往往已经躺在需求系统里：TAPD 的需求、禅道的任务。常见的做法是打开需求页面，复制标题和描述到 DSH，再口述要开哪个分支、用哪个工作区。复制粘贴多了就容易漏字段，分支名也常常是 Agent 随手起的。下面介绍 handsomeboy65/dsh-task-hub，它把「列出分配给我的工作 → 手填分支名 → 派发到会话」这条链路收敛到侧边栏的一个面板里。

插件由 handsomeboy65 维护，分类是「工作流」，在社区插件目录中可以找到。它解决的是：任务来源和 Agent 执行环境之间的那一次人工搬运。

定位¶

一句话：从 TAPD 或禅道读取分配给当前账号的需求 / 任务，选一个 DSH 工作区、手填一个分支名，把任务派给 Agent 在新会话里开工。

它不负责执行任务。派发之后是会话里的 Agent 自己规划和实现；插件也只建立会话、填好输入框草稿，不会替你发送。

核心功能¶

两个任务来源二选一，通过面板顶部的 tab 切换：同一时间只列出一个来源的数据，也只有一个来源生效，切换不会把两者合并展示。每个来源的地址、凭据、项目等配置分别保存在 settings.json 里，来回切换不会丢。

既然是二选一，凭据也不会混在一起：TAPD 的 API 账号密码、禅道的地址和账号分别填写，密钥写入 DSH credentials，不落到插件数据文件里。

派发时插件按顺序做四件事：用 git worktree add -b <分支名>（或就地 checkout -b）建分支；在工作树或仓库上建立（或复用）DSH 工作区并创建会话；把需求标题、来源链接、父需求及关联应用、完整正文、参考资料、工作环境和「补充要求」写进新会话的输入框草稿；把会话标题改成 <分支名> · <标题> 并跳转过去。它不会自动发送。

草稿里还挂了附件。TAPD 会带上需求附件（含父 / 根需求）和描述截图；禅道读取需求或任务详情，下载正文中的图片和附件。这些都只是挂在输入框上的草稿附件，你粘贴、改完再发。

重复派发同一条任务时，如果之前的会话还在，插件直接返回原会话；已发送的会话也走原会话，未发送的草稿可以点「打开」恢复。

派发过程有明确的状态反馈：面板显示分支、会话状态（运行中 / 空闲 / 待发送 / 会话已不存在），运行状态每 8 秒刷新一次；单个项目或产品查询失败只会在面板上提示，不会拖垮整张列表。

安装与启用¶

安装命令来自 README：

dsh plugin --profile web add github:handsomeboy65/dsh-task-hub

装完重启 dsh web，侧边栏会出现「任务中心」。桌面端在应用内的 设置 → 插件 里安装。包发布到 npm 之后，dsh plugin --profile web add dsh-task-hub 是等价写法。

需要 DSH 0.2.1 或更新版本，Node 版本要求 >=20。

首次配置¶

点击面板右上角「设置」，先在顶部选来源，再填该来源的配置。

TAPD 一侧需要认证方式（Token 或 API 账号 + 密码）、API 账号和密码、处理人过滤、项目 ID（TAPD 项目的 workspace_id，多个用逗号分隔，也可点「拉取项目」选择）以及可选的 Nick。注意 API 账号来自 TAPD 开放平台的个人设置，不是登录密码。

禅道一侧需要地址（例如 https://zentao.example.com，插件会自动补 /api.php/v1）、账号密码、范围（产品 读产品需求 stories，项目 读项目下各执行的任务 tasks）以及多选或逗号分隔的产品 / 项目 ID。禅道没有「分配给我」的接口，插件要先登录拿 token，再按当前账号在本地过滤。

通用部分配置默认工作区（如 TMS2.0）、基线分支（留空自动探测 origin/HEAD）、隔离 worktree（默认开启，在仓库同级 .dsh-worktrees/<仓库>-<分支> 另开工作树）、是否隐藏已完成项。

派发流程¶

配置完成后，使用链路很直接：

1、面板列出当前来源里「处理人 = 我」的条目，按最近修改排序，可筛选 未完成 / 已完成 / 全部。TAPD 需求的「应用」字段单独占一列排在 ID 之前，多应用时逐个标签竖排；当前来源没有应用字段时整列隐藏。
2、点某条的「派发 Agent」。
3、在弹窗里确认目标工作区（或手填仓库路径）、分支名称、是否用 worktree、基线分支，以及可选的「补充要求」。
4、确认后插件执行上面的建分支、建会话、写草稿流程，然后跳转到新会话。不会自动发送：任务说明和附件都已经在输入框里，看一眼、改一改，自己按发送。

分支名是整个过程里唯一必须手填的东西。插件要求填写完整名称（例如 feature/order-export），不会自动拼接 issue_<需求号>，也不会追加后缀；分支名会用 git check-ref-format --branch 校验，非法名字直接报错。

「补充要求」不是用来手写整份任务说明的。留空时插件用需求标题、描述、附件、图片和工作约定自动生成一份说明；你填的内容以 ## 补充要求 追加在后面，不会替换需求正文。

改动须知：设置在 ~/.dsh/task-hub/settings.json，派发记录在 ~/.dsh/task-hub/state.json；记录按 来源:id（例如 zentao:task-31）区分，不同系统的同号条目不会互相覆盖，旧 TAPD 记录仍按原 id 兼容。就地派发要求工作区干净，否则报「工作区有未提交改动」；已存在同名 worktree 但停在别的分支时报冲突，不会强改。

适用场景与注意¶

适合已经在用 DSH 写需求实现、任务来源又是 TAPD 或禅道、并且希望由开发者本人决定分支名的同学。它适合「一次处理一条待办」的节奏：选条目、填分支、发会话；不适合需要批量联动或回写来源系统的场景。

同时应当清楚边界：TAPD 只对接需求（stories），不含任务 / 缺陷；禅道按产品读需求或按项目读执行任务，不含缺陷。插件不回写来源系统，不改状态、不写评论；也不会代替 Agent 做执行计划。

安全提示：插件以当前 DSH 进程的权限运行，能读写它的数据文件、创建工作树和会话。安装前建议打开 GitHub 仓库看一下源码（MIT 许可证），确认 lib/ 下的 tapd.js、zentao.js、checkout.js、dispatch.js 等模块在做你预期的事，再决定是否把 TAPD / 禅道凭据交给它。

改完代码做验证时可以用仓库自带的测试：npm test，覆盖纯函数、git 流程、派发、客户端渲染和双来源适配。注意已安装的 bundle 需要重启 DSH 才会加载新的 JS 代次（安装时的首次加载可走 HMR）。

结尾¶

dsh-task-hub 做的事不复杂：把 TAPD / 禅道中分配给你的需求和任务拉到侧边栏，在填好工作区和分支名之后，把任务说明和附件灌进一个 DSH 会话的输入框，让你自己确认发送。它把「读需求、开分支、开工」中重复的人工搬运去掉，又不替开发者抢发送这一步，和他维护时声明的定位一致。

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