dsh-interconnect

跨实例消息互通与事件通知插件，用于 DeepSeek Harness (DSH)。 让一个 DSH 实例能向同一个实例、另一台机器、或另一台机器上的别的 DSH 实例发送消息、探测活性，并在实例之间双向推送事件。

项目状态（2026-09-16）：本仓库是该插件的树外（out-of-tree）主源。并入 DSH monorepo 的计划（PR #3243）已按「保持树外」的评审意见关闭；插件继续经 npm 分发（dsh-interconnect），并由团队内部的插件集合仓以 git submodule 引用本仓库。

包含三个插件

interconnect —— host 服务（ctx.interconnect）：

• 全走持久 WebSocket 链接：跨实例、跨机器投递消息、枚举 live session、探测活性（send/reply/ping/list 经 /interconnect/link 的 msg/query 帧）
• /interconnect/link WebSocket 端点：双向实时事件推流，含心跳与指数退避重连；也承载 send/reply 消息（msg/msg-result 帧）。0.9 起没有 HTTP 端点，也没有 HTTP 回退
• 事件 fan-out 只在 WebSocket 链路上；入站事件以 interconnect/event 发出
• 共享密钥鉴权（DSH_INTERCONNECT_TOKEN，bearer，fail-closed，timing-safe 比较）

tool-interconnect —— 模型可见工具：

• interconnect_peers：列出本实例已配置的对端及其拨号链路状态（up/down），用于在不知道 peer id 时先看有哪些可用目标，也是区分「没配这个 peer」与「配了但链路不通」的唯一入口
• interconnect_send：向对端实例的指定 session 投递消息；默认唤醒没有 live agent 的持久 session（resume: false 关闭），可选 delivery 选投递模式
• interconnect_list：列出对端实例的 live session（id + 标题 + 状态），用于在不预先知道 session id 时寻址
• interconnect_ping：探测对端实例活性与身份
• interconnect_reply：向记录过的发送方回传消息，只需文本；回信 session 是本 agent 自己的，无需再次寻址

skill-interconnect —— 配套 skill：

• 向模型注册 dsh-interconnect skill，说明 peers/list/ping/send/reply 的完整用法、 投递模式、resume 唤醒语义与失败处理。
• 明确告知模型：interconnect_send 会自动注入发送方的 instanceId 和 sessionId， 接收方凭记录的 sender 即可用 interconnect_reply 回信，不需要手工传地址。
• 依赖 interconnect 服务，只有传输层存在时才注册进 ctx.skills。

用法

寻址（0.9 起用 instanceId，全走持久链接）

从 0.9 起，传输只走 WebSocket 持久链接，不再有 HTTP 端点，寻址参数从 baseUrl 改为 instanceId：

• interconnect_send(instanceId="peer", sessionId=..., text=...)
• interconnect_ping(instanceId="peer")
• interconnect_list(instanceId="peer")
• interconnect_peers()（不接受参数；返回本实例配置的全部对端及其链路状态）
• interconnect_reply(text=...)（只需文本；回信 session 是本 agent 自己的，目标从记录的 sender 解析）

instanceId 是 interconnect 行 peers 映射里的键；真正用来拨号的 origin 由该映射的值给出（例如隧道端点 http://127.0.0.1:13080），instanceId 本身从不出现在线上，也不参与路由——origin 才是唯一的拨号依据。

对端没配在这里时，send/reply 返回 peer-not-configured，ping/list 则在返回 reachable: false 的同时带上 configured: false——这一支重试永远不会成功，只能去补 peers 映射。配了但链路不通是另一支：链路断或两端 token 不一致时返回 unreachable （configured: true），重连成功后就可能通（无 HTTP 回退）。

interconnect_peers 就是这两支的判据来源，输出每行一个对端：

peer-a  http://127.0.0.1:13080  [up]
peer-b  http://127.0.0.1:13081  [down]

up/down 是拨号链路当前是否可用；down 不代表对端没开——重连按指数退避自己跑，改完 网络或对端重启后无需重启本实例，链路会自己回来。

增删或改点 peers 同样不需要重启：profile patch 层的改动会重建本插件的 fiber，构造器按新映射 重新建链。这条已实测（双向对照）：patch 层加入 peers 后出现拨号、删掉后拨号消失；改 instanceId 后新链接自报的就是新名字。生效的前提是这一层被真正应用——由 dsh 启动、组合里带 hmr 行的实例会自己应用（见「安装」一节），其它启动方式只能重启。构造器只在激活时读一次该 映射，所以改了文件但没被应用时，行为仍是旧的。

interconnect_list 返回对端当前 live 的 session，每一行的 sessionId 在调用时刻都是合法的投递目标：

session-264d37b0-…  重构 interconnect 插件  [idle]
session-b07326da-…                          [running]

title 与 status 是尽力而为的：标题来自可选的 title projection 服务，对端没装该服务、或 该 session 还没有标题时，整个键不出现（而不是空字符串），所以「无标题」与「该对端不提供 标题」可以区分。projection 抛错只会让那一行降级成只有 id，不会让整个列表失败。

只列 live session 是有意的：send 能到达的正好是这些。对端存在但没有运行 agent 的 session 不会出现在列表里，也收不到消息。

…