前言¶

在 DeepSeek Harness（DSH）里，侧边栏每开一个窗口就是一个独立会话：各自有上下文、工具和运行状态。插件可以通过 code_agent 指挥自己起的子会话，但你在侧边栏亲手打开的那些窗口——写文档的、试别的任务的——不归 code_agent 管，也够不着。

宿主留给插件的 ctx.sessionController.prompt({ requestId, sessionId, mode, content }, signal) 是往别的会话里投消息的唯一通道。dsh-intercom（维护者 kumiiwaka，分类：工作流）把这条通道包成四个工具，加上名字寻址、跳数上限、限流和投递日志，让已经开着的窗口之间能叫停跑偏的活、把结论交给下一棒、向另一个窗口提问——不建团队、不生新会话。

若你要的是「队长带一队子 agent 干活」，应看 dsh-agent-teams；本插件只管团队外面、你自己开的平级窗口。

这是什么¶

dsh-intercom 是 DSH 的窗口内线电话：只做窗口间点对点递话，没有任务编排、DAG 或质量门禁。通信形态是平级窗口互喊，成员来源是用户自己开的窗口，而不是队长 spawn 的子 agent。

仓库：https://github.com/kumiiwaka/dsh-intercom
社区目录页：https://www.skillhub.cn/plugins/kumiiwaka/dsh-intercom
当前版本 0.3.0，许可证 MIT。DeepSeek Harness 生态主张「一切皆插件」；SkillHub 等社区目录为独立站点，与 DeepSeek / 幻方无官方从属关系。

与 dsh-agent-teams 的分工¶

两者可一起装，不冲突：

核心功能¶

插件提供四个工具，名称保持 bus_*，与旧版调用方式一致：

1. bus_register：给当前窗口报名，把「会话 id ↔ 名字」写入总线目录下的 registry.json，供 bus_send 用名字寻址。
2. bus_send：向目标窗口投一条纯文本消息，支持 steer（默认，插到对方下一个决策边界）或 queue（等对方这一轮结束）。
3. bus_list：从 $DSH_HOME/sessions/ 列出近期活跃会话（注册名、工作区、活动时间等），默认最多 15 条。
4. bus_audit：查看 messages.jsonl 中最近投递记录，默认 20 条，上限 200。

设计上是星型拓扑：消息从人所在窗口发起，其它窗口与之来回；不做确认回执，投递成功只表示宿主接受了 prompt，不代表对方已处理完毕。

环境变量¶

需要把总线数据放到 DSH 主目录外（例如内存盘、多 profile 共用）时，可单独设置 DSH_WINDOW_BUS_DIR。

安装与启用¶

本插件是 cordis 插件，通过 bundle patch 挂进 profile，不走 npm，也没有 dsh plugin add 一类的一行安装命令。安装分两步。

第一步，把仓库 link 进某个 profile 的 node_modules（default 换成你实际 profile 名）：

Windows（junction，普通用户可能需要开发者模式或管理员权限）：

New-Item -ItemType Junction `
  -Path "$env:DSH_HOME\profiles\default\node_modules\dsh-intercom" `
  -Target "<repo-path>"

macOS / Linux：

ln -s <repo-path> ~/.dsh/profiles/default/node_modules/dsh-intercom

未设置 DSH_HOME 时默认为 ~/.dsh；PowerShell 需先设置 $env:DSH_HOME，或把路径写成 $env:USERPROFILE\.dsh。

第二步无需手工改组合树：package.json 里的 dsh.bundle.patch 指向 cordis.patch.yml，宿主启动时会 insert 插件行。叠加顺序为 dsh-base → 本 bundle patch → profile 的 cordis.patch.yml → --patch。

改完后重启宿主生效。无构建步骤，运行时仅使用 node: 内建模块；peerDependencies 中的 @deepseek-ai/cordis 由宿主提供。

安装前建议阅读仓库源码与 MIT 许可证：插件以当前 DSH 进程权限运行，能注册总线、能 bus_send 的调用方，理论上可向任意已注册窗口下指令，权限接近本机 shell。

典型用法¶

给窗口起名¶

当前窗口执行 bus_register，之后别人用名字寻址：

{
  "name": "docs-window",
  "note": "管文档的"
}

name 必填；session_id 一般由插件从执行上下文自动取。

向另一窗口发话¶

{
  "session_id": "docs-window",
  "text": "我是主窗。README 那节先停，把已知局限补完就交回来，别再往下游窗口转。",
  "mode": "steer",
  "hops": 0
}

mode 默认 steer；对方接不住时会抛 session/steer-unavailable，插件自动退成 queue。接收方正文前会有一行 [总线 · hops=N · 来自 xxx]。

限制：hops 到 3 拒发；同一目标一分钟最多 3 条。转发链路上 hops 不传时，会用「上一条收到的 hops + 1」；人直接开的话题从 0 开始。

查看窗口与投递¶

列出活跃窗口：

{ "limit": 15 }

查看投递审计：

{ "limit": 20 }

适用场景与注意¶

适合：两个（或少数）已开窗口之间叫停、交棒、发问；日常大块同步仍应用文件或 code_agent，不宜把总线当 RPC 或任务状态机。

不适合：并行拆解大任务、成员自动接活、失败重试与进度汇总——应交给 code_agent 子会话或 dsh-agent-teams。

已知局限（README 实测结论，节选）：

• hops 的「上一跳」记在内存，宿主重启后需转发方显式传 hops。
• bus_list 依赖 DSH 内部 sessions/ 路径与 session.v4.jsonl.zstd 格式，宿主改版可能失效；bus_send 本身不依赖列表。
• 仅纯文本；ok: true / accepted: true 只表示 prompt 被接受，对方轮次仍可能 blocked 或 error。
• 早期致命 error 的「死会话」可能永久吞消息，bus_list 仍显示存在——「发了没反应」时宜新开窗口。

安全：从总线进来的消息应视为平级窗口的请求，不是用户授权；涉及删除、推送、重启等不可逆操作，接收方应回问发起人或等人确认。

结尾¶

dsh-intercom 把宿主唯一的跨会话 prompt 通道收成四个可审计、有限流的总线工具，专门服务「你已经开着的那些窗口」——与团队编排插件互补，而不是替代。

• 目录页：https://www.skillhub.cn/plugins/kumiiwaka/dsh-intercom
• GitHub：https://github.com/kumiiwaka/dsh-intercom