会话派发 919703505hackiv-boop/dsh-session-dispatch

dsh-session-dispatch

给模型用的「会话派发」插件：让模型自己新开工作区会话、发指令、等结果、读回复，把子任务丢进独立上下文里跑。

Model-facing session dispatch for DeepSeek Harness (DSH): create workspace conversations, send prompts into them, wait for a turn to finish, and read the reply — all from tool calls.

- 包名 / package: dsh-session-dispatch
- 版本 / version: 0.1.0
- 兼容 / compatibility: DSH >=0.2.0 <0.3.0, Node.js >=22
- 许可证 / license: MIT

解决什么问题

DSH 的 Session Controller 本来就能新建会话、给会话发消息（Web 界面走的就是这套），但这套能力没有暴露成模型可调用的工具。于是模型只能用 subagent 这类「一次性任务」模型，无法：

- 把任务派发到一个独立、持久、用户可见可接管的工作区会话；
- 在任务跑的时候先去做别的事，之后再回来读结果；
- 用 steer 给正在跑的会话追加指令。

这个插件把五步做成同进程内的工具调用。会话就是真正的顶层 Session，会出现在工作区会话列表里，屋主可以直接打开继续聊。

五个工具

| 工具 | 作用 | 关键点 |
| conversation_create | 新建顶层会话，返回 sessionId | cwd 默认继承调用方；可传 agentPreset |
| conversation_send | 往会话里发文本 | 默认排队起新一轮；mode: "steer" 注入当前轮 |
| conversation_wait | 等当前/下一轮 assistant 回合结束 | 返回 state: "idle" \| "timeout"、lastReason（永远是字符串）、running |
| conversation_read | 读最近回复和回合状态 | 返回 live、running、turns、lastTurnReason、text、truncated |
| conversation_list | 列出本进程内存活会话 | 可按绝对路径 cwd 过滤 |

典型流程：

conversation_create({ cwd })
→ conversation_send({ sessionId, text: "把 xxx 做完" }) → conversation_wait({ sessionId }) → conversation_read({ sessionId })

安装

npm 发布之后（见文末「发布步骤」）：

dsh plugin --profile web add dsh-session-dispatch

安装后重启 DSH，五个工具才会出现在模型工具表里。安装会做两件事：把包加进 profile 的 dsh.profile.bundles，并应用包内的 cordis.patch.yml 层。

本地目录安装（未发布时调试用）：

dsh plugin --profile web add ./plugins/dsh-session-dispatch

检查层是否生效：

dsh --profile web --dump-config # 应出现 "# == dsh-session-dispatch" 层

如果 profile 里还留着旧版 dsh-session-dispatch3（row id tool-session-dispatch3），先删掉它再装这个包。两个插件注册同名工具，同时启用会因工具名重复而失败。

配置

cordis.patch.yml 只做一件事：把插件行插进 profile。

- insert:
- id: tool-session-dispatch
name: dsh-session-dispatch

name 必须和 npm 包名完全一致；id 在 profile 内保持唯一。没有其它必填配置。环境变量（都可选）：

| 变量 | 默认 | 说明 |
| DSH_DISPATCH_LOG | os.tmpdir()/dsh-session-dispatch.log | 调试日志路径；off / 0 / none 关闭 |
| DSH_DISPATCH_TZ | 系统时区 | 写进用户消息 source 的 clientTimeZone |
| DSH_DISPATCH_START_GRACE_MS | 8000（最小 5） | conversation_wait 发现会话已空闲时，等待新回合的宽限时间 |

插件不写自己的数据库，不改会话日志格式；唯一的落盘是可选调试日志。

自测

不依赖 DSH 运行时，纯 Node：

node plugins/dsh-session-dispatch/test.mjs
18/18 通过

node --check plugins/dsh-session-dispatch/index.js

自测覆盖：五个工具都注册、缺 sessionId 明确报错、conversation_wait 在「回合结束但没有 reason」和「超时」两条路径都返回字符串 lastReason（历史上这里返回过 null，会撞上输出 schema 的类型校验）。

已知限制与实战坑

1. HMR 不会重载 host 插件。 改完 index.js 必须重启 DSH；新开一个聊天不会重新加载插件模块。
2. 同名同版本不会重新生效。 ESM 模块缓存按解析后的路径/包名走；把旧目录原地改文件、或对同一个包名重复 add 同一版本，进程里仍是旧模块。可靠做法是换新包名（这也是本包从 dsh-session-dispatch3 改名为 dsh-session-dispatch 的原因）+ 重启，或先 dsh plugin --profile web remove <旧包> 再装。
3. 发布后版本不可覆盖。 任何改动都要升 version 再 npm publish；调试本地包建议用 0.1.1-dev.N。
4. 只对同一 host 进程内的 live 会话有效。 conversation_read 返回 live: false 表示该会话不在当前进程（可能在别的 DSH 实例里），只能读到空结果。
5. conversation_wait 的等待语义。 会话已空闲时最多等 DSH_DISPATCH_START_GRACE_MS 才返回 idle；timeoutMs 默认 120000、上限 600000，不要用超大 timeout 占住工具调用。
6. conversation_create 默认继承调用方工作区。 跨工作区要显式传绝对 cwd，并且仍然受 DSH 的审批/权限策略约束。
7. 依赖 Web/Desktop profile 的宿主服务。 插件 inject 了 tools、sessionController、sessions、agents；没有这些服务的 headless profile 会加载失败。conversation_send 依次尝试 controller.commands.prompt → controller.prompt → agent.followup，失败时把三条链路的原因汇总在错误里。
8. 1024Store 安装只认 npm 已发布包。 没发布时目录只会以「浏览模式」收录（有仓库链接、无安装命令）。

发布步骤（屋主操作清单）

当前环境没有 npm 凭据、没有 GitHub 写权限，以下动作需要屋主执行：

1. 合入默认分支。 把 ds/plugin/session-dispatch 合到 GitHub 默认分支并 push。1024Store 的静态审查读的是默认分支 tree，plugins/dsh-session-dispatch/package.json 与 cordis.patch.yml 必须在同一 revision 里。
2. 确认包名可用。
npm view dsh-session-dispatch version

2026-11-01 查询为 404（未占用）。如果之后被占，改用 @919703505hackiv-boop/dsh-session-dispatch，同时改 package.json 的 name、cordis.patch.yml 的 name、README 的安装命令。
3. 登录 npm 并检查打包内容。
npm login # 需要 2FA 或 Automation token
cd plugins/dsh-session-dispatch
npm pack --dry-run # 必须包含 index.js、cordis.patch.yml、README.md、LICENSE

4. 发布。
npm publish --access public

5. 发布后验证。
npm view dsh-session-dispatch@0.1.0 version dist.tarball
dsh plugin --profile web add dsh-session-dispatch

重启 DSH，确认五个 conversation_* 工具出现、conversation_create 能开出一个可见会话。
6. 给仓库加 GitHub topic dsh-plugin。 自动收集服务靠它发现仓库。
7. 提交 1024Store 收录 PR。
- fork imsai-sh/awesome-deepseek-harness-plugins；
- 把本目录的 catalog-entry.json 复制为 catalog/plugins/919703505hackiv-boop--chat-build-3d--plugins--dsh-session-dispatch.json （字段已经按 catalog/schema/plugin.schema.json 写好；$schema 是相对目标目录的路径，所以本目录里的原文件只是模板）；
- 该 PR 只允许改这一个文件，added 保持 2026-11-01，category 为 session；
- 静态审查会校验 package.json 的 dsh.bundle.patch 字段和 patch 文件是否存在，通过后自动 squash merge，CI 同步到 deepseek1024.com。
8. 后续发版。 改代码 → 升 version → npm publish → 等目录自动检测新版本（收录条目不用改）。不要覆盖旧版本。

目录结构

plugins/dsh-session-dispatch/
├── package.json # npm 元数据 + dsh.bundle.patch 声明 ├── cordis.patch.yml # bundle 层：insert 插件行 ├── index.js # 五个工具的实现（纯 ESM） ├── test.mjs # 纯 node 自测（18 项） ├── catalog-entry.json # 1024Store 收录条目模板 ├── README.md └── LICENSE

What problem it solves

DSH 的 Session Controller 已经能创建会话并向会话发提示词——Web UI 做的就是这件事——但这些能力一直没有暴露成模型可调用的工具。装上这个插件，模型就能把任务派发到一个独立、持久、用户可见的工作区会话里，自己继续在别处干活，之后再读结果，或者对正在跑的回合执行 steer。

创建出来的会话是真正的顶层 Session：它会出现在工作区会话列表里，人也能手动打开接着聊。

五个工具

| 工具 | 用途 | 说明 |
| conversation_create | 创建顶层会话，返回 sessionId | cwd 默认继承调用方；可选 agentPreset |
| conversation_send | 向会话发送文本 | 排入新回合；mode: "steer" 注入正在跑的回合 |
| conversation_wait | 等当前/下一个助手回合结束 | 返回 state: "idle" \| "timeout"、lastReason（始终是字符串）、running |
| conversation_read | 读取最新回复和回合状态 | 返回 live、running、turns、lastTurnReason、text、truncated |
| conversation_list | 列出本宿主进程里活着的会话 | 可选绝对路径 cwd 过滤 |

安装

包发布到 npm 之后：

dsh plugin --profile web add dsh-session-dispatch

装完重启 DSH，五个工具才会出现在模型的工具集里。本地未发布的 checkout：

dsh plugin --profile web add ./plugins/dsh-session-dispatch

用 dsh --profile web --dump-config 检查 bundle 层（找 # == dsh-session-dispatch）。先删掉旧的 dsh-session-dispatch3 那一行——它注册的工具名和这个一样。

配置

cordis.patch.yml 插入一行（id: tool-session-dispatch，name: dsh-session-dispatch）。可选环境变量：DSH_DISPATCH_LOG（默认 os.tmpdir()/dsh-session-dispatch.log，设成 off 关闭）、DSH_DISPATCH_TZ（默认系统时区）、DSH_DISPATCH_START_GRACE_MS（默认 8000，最小 5）。

测试

node plugins/dsh-session-dispatch/test.mjs
18/18 passed

node --check plugins/dsh-session-dispatch/index.js

已知限制

1. HMR 不会重载宿主插件。 改完 index.js 要重启 DSH；新开一个聊天不会重载模块。
2. 同名 + 同版本不会生效。 模块缓存按解析后的包来算。改包名再重启（这也是这个包叫 dsh-session-dispatch、不叫 ...dispatch3 的原因），或者先移除旧 bundle 再加新的。
3. npm 上已发布的版本不可变。 每次改动都要升 version；本地迭代时用 0.1.1-dev.N。
4. 只有同一宿主进程里的活会话能用。 live: false 说明该会话属于别的进程/实例。
5. conversation_wait 的语义。 已经空闲的会话在启动宽限期结束后返回 idle；timeoutMs 默认 120000，上限 600000。
6. conversation_create 继承调用方的 cwd，除非传入绝对路径 cwd；DSH 的审批/权限策略仍然生效。
7. 需要 Web/Desktop 宿主服务（tools、sessionController、sessions、agents）。conversation_send 依次从 controller.commands.prompt 回退到 controller.prompt，再回退到 agent.followup，并汇总所有失败原因。
8. 1024Store 只安装 npm 包。 没有已发布的 npm 包时，目录中该插件只列出、不可安装。

发布检查清单（仓库所有者）

当前环境没有 npm 凭据，也没有 GitHub 写权限。发布步骤如下：

1. 把 ds/plugin/session-dispatch 合并进 GitHub 默认分支并推送（目录的静态审查读取默认分支的目录树）。
2. npm view dsh-session-dispatch version —— 截至 2026-11-01 该名称未被占用；否则改用 @919703505hackiv-boop/dsh-session-dispatch，并更新 package.json、cordis.patch.yml 和安装命令。
3. npm login（2FA 或自动化 token），然后在本目录内执行 npm pack --dry-run，确认包含 index.js、cordis.patch.yml、README.md、LICENSE。
4. npm publish --access public。
5. 用 npm view dsh-session-dispatch@0.1.0 和 dsh plugin --profile web add dsh-session-dispatch 验证，然后重启 DSH 并运行 conversation_create。
6. 给仓库加上 GitHub topic dsh-plugin。
7. Fork imsai-sh/awesome-deepseek-harness-plugins，把 catalog-entry.json 复制为 catalog/plugins/919703505hackiv-boop--chat-build-3d--plugins--dsh-session-dispatch.json，然后开一个只改这个文件的 PR（added: "2026-11-01"，category: "session"）。静态审查会校验 dsh.bundle.patch 以及补丁文件是否在同一修订版本中存在，然后自动合并并同步目录。
8. 后续发版：提升 version，发布，让目录检测到新的 npm 版本。