前言¶
在 DeepSeek Harness（DSH）里，多个子智能体往往以独立的 Cordis 会话并行跑在同一份任务上。彼此看不到对方的中间产物，也缺少统一的「等人就绪再继续」机制，常见结果是接口约定重复起草、切片之间对不齐，或者为了等依赖而用轮询浪费模型回合。
下面介绍社区插件 dsh-subagent-comms（仓库 SBBW512/DSH-Subagent-Comms，目录页 SkillHub）。它在当前 DSH 工作区内提供内存级发布/订阅与黑板存储，让兄弟子智能体可以交接契约、阻塞等待依赖、读取共享状态，以及广播轻量进度——不依赖外部消息队列，运行时零第三方依赖（仅使用 Node 标准库 node:events）。
这是什么¶
- npm 包名：
dsh-subagent-comms（当前资料版本 1.0.1） - Cordis 插件名：
peer-sync（通过dsh.bundle.patch加载./cordis.patch.yml） - 维护者：SBBW512
- 许可证：MIT（见仓库
package.json） - 分类：工作流（社区目录归类）
安装并重启 DSH 后，智能体工具列表中会出现四个固定名称的工具：peer_publish、peer_read、peer_await、peer_broadcast。
核心功能¶
进程内 Pub/Sub 与黑板¶
每个 topic + key 对应一条可覆盖写入的记录；同键再次 peer_publish 按后写覆盖更新，并重新计算 TTL。订阅侧通过 peer_await 在内存里等待指定键发布，无需轮询循环，也无需额外消耗 LLM token 去「盯着」是否就绪。
四个工具的分工¶
| 工具 | 作用（据 README） |
|---|---|
peer_publish |
向某 topic:key 写入载荷（可用 payload_json 传入 JSON 结构） |
peer_await |
阻塞等待指定 topic:key 被发布，支持 timeout_ms |
peer_read |
随时读取黑板上当前值及 published_at 等元数据 |
peer_broadcast |
向主题的滚动广播环缓冲投递轻量进度/状态消息 |
工作区隔离¶
存储与事件按 exec.agent.workspaceId 划分；若无 workspace id 则回退为字面量 default。不同 workspace 下相同的 topic:key 互不可见。每个 workspace 拥有独立的键值表、EventEmitter 与广播缓冲。
TTL 与体量限制¶
peer_publish 可选 ttl_seconds，默认 3600 秒；后台约每 60 秒清扫过期项。过大载荷会被拒绝而非截断（README 有说明）。初始化失败时以 [peer-sync] 前缀记录日志，而不拖垮宿主。
运行环境¶
- Node.js：
^22.19.0 || >=24.0.0 - DSH 机制：通过
ctx.tools.register注册工具，经标准 bundle patch 加载；README 写明仅在当前打包 DSH 构建上做过验证，其他版本未测试。
安装与启用¶
新装插件或工具后必须重启 DSH，四个 peer 工具才会出现在注册列表中。资料给出三条路径；生产或常规使用可优先 npm 或 手动复制（下文不展开 git 本地链接流程）。
方式一：npm（资料 Route 2，包发布后适用）¶
进入目标 profile 目录，例如：
cd ~/.dsh/profiles/<name>
安装包：
npm install dsh-subagent-comms
在同一 profile 的 package.json 中，把 bundle 名称加入 dsh.profile.bundles：
"dsh": {
"profile": {
"bundles": [
"dsh-subagent-comms"
]
}
}
然后重启 DSH。
方式二：手动安装（资料 Route 3）¶
- 将
dsh-subagent-comms目录放到profiles/<name>/node_modules/dsh-subagent-comms。 - 在 profile 的
package.json的dependencies中加入"dsh-subagent-comms": "*"。 - 同样在
dsh.profile.bundles中加入"dsh-subagent-comms"。 - 重启 DSH。
典型用法：四个步骤的协作模式¶
README 用「垂直切片」场景演示：Worker A 发布接口契约，Worker B 等待并实现客户端，双方还可广播进度。下列 JSON 为工具调用参数示例，可直接对照智能体侧 tool 调用格式。
步骤 1：Worker A 发布契约或构件
{
"topic": "contracts",
"key": "AuthService",
"payload_json": "{\"version\":\"1.0.0\",\"endpoints\":[\"/login\",\"/logout\",\"/refresh\"]}"
}
步骤 2：Worker B 用 peer_await 等待，无需轮询
# 工具名：peer_await
{
"topic": "contracts",
"key": "AuthService",
"timeout_ms": 60000
}
A 发布后，peer_await 以 resolved 状态返回载荷。
步骤 3：Worker B 用 peer_read 查阅黑板
{
"topic": "contracts",
"key": "AuthService"
}
返回示例（README）：
{
"found": true,
"topic": "contracts",
"key": "AuthService",
"payload": {
"version": "1.0.0",
"endpoints": ["/login", "/logout", "/refresh"]
},
"published_at": "2026-11-07T00:00:00.000Z"
}
步骤 4：任一方 peer_broadcast 进度
{
"topic": "contracts",
"sender": "worker-A",
"message": "AuthService contract published and ready for consumption"
}
经过上面的步骤，并行子智能体可以在同一 workspace 内完成「发布—等待—读取—通告」闭环，而无需把中间状态写进各自孤立的会话上下文。
适用场景与注意¶
适合谁
- 在同一 DSH workspace 内跑多个子智能体，需要共享接口契约、构建产物描述或阶段性结论。
- 希望依赖方用
peer_await做确定性等待，而不是用提示词轮询或重复推理。 - 接受进程内、易失存储：重启宿主或 TTL 过期后数据不再保留，不适合当作持久化数据库或跨机器总线。
安全与权限
插件随当前 DSH 进程权限运行，数据停留在该进程内存中。安装前应阅读仓库源码与 MIT 许可证，确认与组织策略一致。社区目录 SkillHub 与 DeepSeek / 幻方无官方从属关系；DSH 生态强调「一切皆插件」，本包是第三方工作流扩展，而非官方应用商店内置能力。
存储语义备忘
payload_json会解码为结构；纯字符串按原文存储，即使形如 JSON 也不会被自动解析。topic、key必须为字符串，否则peer_publish/peer_await会返回描述性错误。- 复合键在实现上做了长度前缀，避免
:等字符造成别名混淆。
结尾¶
dsh-subagent-comms 用最小依赖补上 DSH 子智能体之间「看不见彼此中间状态」的缺口：四个 peer 工具覆盖写入、等待、读取与广播，并按 workspace 隔离。若你正在编排并行子任务，可把 npm 包加入 profile bundle、重启 DSH 后，用 README 中的四步模式试跑一条 contracts 主题链路。
- 目录页：https://www.skillhub.cn/plugins/SBBW512/DSH-Subagent-Comms
- 源码与文档：https://github.com/SBBW512/DSH-Subagent-Comms
