前言¶

DSH 自带的消息通道是有前提的：send_message 只在直接父子 agent 之间传，Agent Teams 只在同 Team 成员之间传，侧栏里两个普通会话之间没有路。想做跨会话交接（A 会话让 B 会话查回归结果、顺手新开会话写 CHANGELOG），以前只能靠人手动复制粘贴。本插件 tonyzdev/dsh-session-messaging 补的就是这条缺的通路：给每个顶层会话加三个工具，找会话、发消息、开新会话，收到的消息标明来源，对方用同一个工具回复。下面按功能、安装、用法、设置、注意事项的顺序介绍。

插件身份与来源¶

• 维护者：tonyzdev，社区维护，非 DeepSeek 官方。
• 分类：工作流（社区目录 SkillHub 归类）。
• 社区热度：GitHub 20 stars、4 forks，社区插件规模偏小，功能边界也小而明确。
• 许可证：MIT。
• 源码与发布：https://github.com/tonyzdev/dsh-session-messaging，包名 @tonyzdev/dsh-session-messaging。

本插件不调用模型、不需要额外 API key，价值纯粹在「会话之间能说话」这一件事上。安装前建议先读一遍 README 和源码，确认它正是你需要的转发行为。

核心功能¶

三个工具，作用正交，不改 DSH 原生会话模型。

1. session_list：按最近活跃列出可发消息的顶层会话，返回 id、运行中/空闲、标题。默认只看当前工作区，也可以列全部工作区或按标题搜索。
2. session_send_message：把消息送到另一个会话。运行中的会话下一步读到；空闲的会话立即开始新一轮；已存储（未加载）的会话先恢复再处理。带 delivery: "queue" 时等对方这一轮结束后再开新一轮。
3. session_create：在侧栏新开一个带标题的会话，并用你的消息开始第一轮。新会话独立干活，看不到发起方的对话；想让它回报，就在消息里写清楚。

来源标注是独立的一环：收到的消息显示为用户侧气泡，上方写「来自会话「标题」」。模型看到的是一行来源说明——哪个会话发的、由对方的 agent 而不是用户撰写、怎么回复。说明结尾提醒对方不要只为确认收到而回复，避免两个会话来回「收到」「好的」停不下来。

边界也在功能里一起说明了，后面会展开。

安装与启用¶

前置条件只有一条：DeepSeek Harness 0.2.0+（README 提到已在 macOS 版 0.2.1-rc.5 上实测）。engines 字段写的是 >=0.2.0-rc.1 <0.3.0-0。

方式一：让 DSH 自己装（推荐）¶

把下面这句话直接发给任意 DSH 会话，agent 会自动识别桌面端或网页端完成安装并热加载。bash 与 PowerShell 取 profile 的方式不同，命令里都写了。

请帮我在当前 DSH profile 安装插件 https://github.com/tonyzdev/dsh-session-messaging：若有 plugin_manager 工具请直接调用 install_bundle 安装并启用；否则读取当前 profile 名（bash 为 $DSH_PROFILE，PowerShell 为 $env:DSH_PROFILE；为 desktop 时调用 app.asar 同级 runtime/cli/bin 下的 dsh 或 dsh.cmd，其他情况用 PATH 中的 dsh，受沙箱限制时申请全盘权限审批）执行 dsh plugin --profile <profile> add github:tonyzdev/dsh-session-messaging，不要手改配置文件或重启宿主。

方式二：界面手动装¶

侧栏打开 插件 → 添加插件，填入完整仓库地址，点 安装，再点 立即启用。如果转发气泡样式还没出现，按 ⌘R / Ctrl+R 刷新页面。

https://github.com/tonyzdev/dsh-session-messaging

README 特别提醒：这里要填完整 GitHub 仓库地址，不要只填 dsh-session-messaging。npm 上同名无前缀包由其他作者维护，装错了不是本插件。

命令行与预打包安装¶

网页端走 profile web：

dsh plugin --profile web add github:tonyzdev/dsh-session-messaging

桌面端走应用内置 CLI（路径与平台有关）。macOS：

DSH="/Applications/DeepSeek Harness.app/Contents/Resources/runtime/cli/bin/dsh"
"$DSH" plugin --profile desktop add github:tonyzdev/dsh-session-messaging

Windows（PowerShell）：

& "$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\runtime\cli\bin\dsh.cmd" plugin --profile desktop add github:tonyzdev/dsh-session-messaging

README 注明，装了 Desktop 的机器上跑 --profile web 只会装进 profiles/web，不会出现在桌面端界面里。桌面端要用上面的内置 CLI 指向 --profile desktop，或直接在界面装。

也可以装预打包的 Release .tgz，不走完整 Git 拉取：

dsh plugin --profile web add https://github.com/tonyzdev/dsh-session-messaging/releases/download/v0.3.2/tonyzdev-dsh-session-messaging-0.3.2.tgz

本地开发用 link 方式安装，改代码直接作用于该副本：

git clone https://github.com/tonyzdev/dsh-session-messaging ~/.dsh/local-plugins/dsh-session-messaging
"$DSH" plugin --profile desktop add link:$HOME/.dsh/local-plugins/dsh-session-messaging

移除方式：

"$DSH" plugin --profile desktop remove @tonyzdev/dsh-session-messaging

打个补丁配置项¶

改配置走 profile 补丁文件，不要手改其他配置。桌面版补丁路径是 ~/.dsh/profiles/desktop/cordis.patch.yml，只写要改的字段，没写的用默认值：

- id: session-messaging
  config:
    crossWorkspace: false

保存后生效；没生效就重启 DeepSeek Harness。

典型用法¶

不需要背工具名，直接告诉 agent 要做什么。下面三句都来自 README 示例，可直接复制到会话里试：

问问「修复登录超时」那个会话：bug 修好了吗？改了什么？

告诉「前端重构」那个会话：接口字段 user_id 改名为 uid 了。

开一个新会话，让它把这条修复写进 CHANGELOG.md，写完告诉我。

对应到工具参数，对照这张表更清楚：

有一点要明确：工具只返回送达确认，不返回对方的回答。回答会作为一条新消息回到发送方会话，从气泡或下一轮里读。

设置项¶

README 给出四个可配项，默认值如下：

想收紧跨工作区访问，把 crossWorkspace 设为 false 即可，这是默认值唯一可能想动的项。

实现方式（简要）¶

说明实现，是为了解释为什么有些限制存在，也帮你判断能否扩展。

消息转发走 sessionController.resolveAgent，和网页端发送 prompt 是同一条路径，必要时从存储冷恢复会话。消息带 DSH 内置的转发来源 { kind: 'agent-message', form: 'relay', senderSessionId }，写进对方的会话日志。浏览器端覆盖 Chat 的 turn-trigger 渲染器，只接管本插件转发的消息，复用 DSH 自带的 conversation.chat.user.content 气泡；目标、定时任务、子 agent 等其他触发消息仍走原生卡片。所以模型收到的内容不变，只改显示。

开新会话走 sessionController.create({ workspaceId })，也就是网页端「新对话」的路径。第一轮开始前会先改好标题，因为转发消息不触发 DSH 的自动起标题——这也解释了为什么 session_create 设的标题之后不会被自动改写。

主要文件对应关系：

子 agent 在 agent/created 时用 agent.ctx.tools.restrict({ deny }) 隐藏这三个工具，所以子 agent 无法经这条通道收到回复。

已知限制与防范¶

这些是 README 明确列出的，决定了你把它用在什么场景合适。

1. 被唤醒或新开的会话按自己的设置运行。新开的会话用默认模型和默认审批策略（README 提到实测为 ask），不继承发起会话的设置。它若需要审批，审批请求停在那里，可能没人看。
2. 只在顶层会话之间通信；子 agent 和 Team 成员仍用 DSH 自带的 send_message。
3. 「送达」只代表对方收件箱接受了消息，不代表已处理；没有重试、去重或已读回执。
4. 对方正在运行时收到的消息并入它这一轮，模型能收到，但不显示成气泡；只有唤醒会话的消息显示为气泡。
5. 气泡不渲染 Markdown，也不折叠很长的消息。
6. 发消息没有频率限制；防来回客套靠来源说明里的提示。createLimit 存在内存里，插件重载或重启后清零，也不限制「A 开 B、B 再开 C」这样的链条。
7. session_create 设的标题像手动改名一样固定，DSH 之后不再自动改。

适用场景¶

适合这些情况：

• 需要跨会话交接的顶层 agent。比如一个会话专做代码改动，另一个会话专做发布整理，前者把结果写进消息，后者醒来读取。
• 想要派生独立任务。主会话开一个新会话写文档或跑一次独立验证，不想暴露自己的对话上下文。
• 想用自然语言而不是工具调用去编排：「问问那个会话有没有修好」。

不适合这些情况：

• 需要可靠回复保证的流程。没有重试和去重，消息可能丢了或只到达对方某一轮的中间。
• 子 agent 之间需要收发消息。这条通路不覆盖子 agent，仍是 DSH 原生 send_message。
• 需要审批隔离的场景要谨慎。被唤醒的会话用默认审批策略，可能停下等人。

收尾¶

一句话回顾：tonyzdev/dsh-session-messaging 在 DSH 顶层会话之间补了一条甘草通路，加了三个工具，把跨会话交接从手动复制降级为一句自然语言，代价是保留了 DSH 原有的顶层边界，并带来几条明确的能力边界。如果你的工作流里确实需要「A 问 B、B 派生 C」，先按上面的安装方式热装试一轮，确认限制与你预期一致再纳入常规流程。

• 目录页：https://www.skillhub.cn/plugins/tonyzdev/dsh-session-messaging
• GitHub：https://github.com/tonyzdev/dsh-session-messaging