前言¶
在 DeepSeek Harness（DSH）里开多个会话并行做事时，常见做法是人为切换窗口、复制粘贴上下文，或等某个会话跑完再口头交代下一步。同一 DSH 进程里，会话 A 里的智能体无法直接给会话 B 注入一条「用户消息」并唤醒 B 继续一轮推理。
dsh-peer-message 是 respawnlife 维护的 Host-only 插件，在同一 DSH 进程内向其他会话投递消息并唤醒目标会话。下面介绍它的定位、工具参数、安装方式、典型用法与安全边界。
这是什么¶
- 名称：dsh-peer-message（npm 包名一致，当前版本 0.1.1，MIT 许可证）
- 维护者：respawnlife
- 仓库：https://github.com/respawnlife/dsh-peer-message
- 能力：通过
peer_list、peer_send两个工具，让当前会话把文本消息投到另一会话，并按目标状态选择followup（新开一轮）或steer（在运行中的下一步边界插入）；不向公网发请求，不读写工作区文件，只读会话元数据（id、标题、工作目录、状态）。
DSH 0.2.x 自带 team-message / agent-message 等消息源；本插件是独立的进程内实现，只走 agents 服务，不接入官方 team 通道，可与内置能力共存。
核心功能¶
投递流程（概念）¶
Conversation A（用户正在对话的会话）
└─ peer_send(to: "report session", message: "take care of xxx")
└─ agents.get(sessionId).followup(userMessage)
└─ Conversation B 收到一条用户消息并开启新回合
典型用途包括：并行会话间委派或交接任务、让另一会话做校验、任务完成后向其他会话汇报。
工具一览¶
| 工具 | 参数 | 作用 |
|---|---|---|
peer_list |
query?、scope?（workspace / all）、limit?（默认 30，最大 100） |
列出可投递的会话（id、标题、工作目录、是否已加载/运行），并标记当前会话；默认仅当前 workspace |
peer_send |
to（会话 id / id 前缀 / 标题）、message、mode?（auto / steer / followup） |
投递消息并唤醒目标；成功时返回目标会话、实际使用的 mode、是否已唤醒 |
mode 含义：
auto（默认）：目标空闲 →followup新开一轮；目标运行中 →steer在下一步插入。steer：强制插入（仅目标运行中才有步骤边界）。followup：强制新开一轮；若目标正在运行则降级为steer，避免消息被吞掉。
限制：不能发给自己；单条消息正文上限 20000 字符；目标未加载时会先唤醒再投递。
消息在界面上的表现¶
正文会加上前缀 【跨会话消息 · 来自 DSH 会话"标题"(id)】，便于在日志里辨认来源；UI 仍按普通用户消息渲染，无单独卡片或来源徽章。
环境与依赖¶
- DSH：
>=0.2.2-rc.1 <0.3.0-0（0.2.x 线，含 prerelease；在0.2.2-rc.1上测试过；上界排除 0.3 prerelease） - Node.js：
>=22（与 DSH 捆绑运行时一致即可） - 无 npm 运行时依赖，无构建步骤；Host-only bundle
安装与启用¶
安装前请确认 DSH 版本落在上述区间。官方 README 给出两条路径，按你当前 DSH 支持的能力二选一。
1. 用插件管理器安装目录（常规 Host-only 方式）¶
使用 plugin_manager 的 install_bundle，将 target 设为该插件目录的绝对路径。
2. 本地开发 link¶
- 在 profile 的
package.json的dependencies中加入："dsh-peer-message": "link:/path/to/dsh-peer-message"（将路径换成你本机克隆或解压后的目录）。 - 在
dsh.profile.bundles中加入dsh-peer-message。 - 让插件管理器完成安装；不要手写 profile 的 patch 文件。
安装完成后，该 profile 下的每个会话都会获得 peer_list / peer_send，重启后仍保留。
卸载¶
- 用插件管理器
remove_bundle，或set_plugin且enabled: false；或 - 从 profile 的
package.json的dependencies和dsh.profile.bundles中移除，然后重启 DSH。
卸载后两个工具消失，不再注入新消息；已投递到目标会话的消息不会撤回。
典型用法思路¶
- 在当前会话调用
peer_list，必要时用query过滤、scope: "all"看全进程会话（列表过滤不等于权限边界）。 - 用返回的 id、id 前缀或标题作为
peer_send的to。 - 写好
message；需要强制行为时指定mode。 - 在目标会话中把这条消息当作用户输入处理，继续原有工作流。
README 中的示例语义：peer_send(to: "report session", message: "take care of xxx")，表示从会话 A 向标题或标识为 report session 的会话 B 投递任务说明。
安全边界（安装前建议通读）¶
peer_send 是模型可自行触发的有副作用操作，效力等价于在进程内跨会话写入一条用户消息：
- 无需人工确认：运行中的智能体可在同一 DSH 进程内向任意会话投递消息；若需人工把关，应通过 DSH 的工具审批 / 权限策略限制该工具。
- 接收方视为用户消息：目标会话按你的输入处理，存在提示注入横向移动风险；
workspace仅影响列表范围，不是隔离边界。 - 唤醒消耗配额：未加载的会话会通过 host 的
sessionController.resolveAgent()唤醒并可能开启新回合，触发模型调用、token 与工具副作用。 - 范围：仅当前 DSH 应用进程；无跨进程、跨机器、无网络。
- 信任环境：建议在可信的单用户环境启用；不要把
peer_send暴露给不可信的提示来源（例如自动抓取的网页或外部消息通道）。
插件以当前 DSH 进程的权限运行；安装前请自行查看源码与 MIT 许可证条款。
实现要点（供排查兼容问题时参考）¶
Host 侧复用进程内已有服务：agents（get / list、followup / steer）、sessionQuery / sessions 列会话与标题、sessionController.resolveAgent 唤醒未加载会话。消息结构为进程内 user 消息，source.kind 为 plugin:peer-messaging。工具通过 DSH Host 插件形式 export function apply(ctx, config) 注册。
与 DSH 内部 API 的耦合无公开稳定性承诺；engines.dsh 在 package.json 中声明为 >=0.2.2-rc.1 <0.3.0-0。
结尾¶
dsh-peer-message 解决的是同一 DSH 进程内「会话 A 通知并唤醒会话 B」的落地问题，适合并行多会话协作、校验与回报类工作流。社区目录页：https://www.skillhub.cn/plugins/respawnlife/dsh-peer-message；源码与完整说明：https://github.com/respawnlife/dsh-peer-message。
