# 多会话联调实战调研 与 dsh-session-link-pro 升级设计（2026-09-17）

> **更名通告**：本调研完成当日，插件已定名更名 `dsh-team-link`（0.3.0，分支 rename/dsh-team-link）。本文正文保留调研时点的旧名 `dsh-session-link-pro` 与 `session_link_pro_*` 工具名——它们是历史日志与证据链的准确记录，不做回写。实施级设计见 `team-upgrade-design-2026-09-17.md`（当前 v1.4，工具名已更新为 `team_link_*`）。
>
> **效力声明（评审 #6 补）**：本文 §5 是**已被取代的提案**——以 `team-upgrade-design-2026-09-17.md` §3.0 的差异清单与 §8 处置表为准（要点：心跳重档改为看门狗+schedule 分工、砍总线、换届两阶段令牌制、banner 承载信封）。落地实现请勿以本文 §5 为据。

> **文档用途**：本文档基于一次 16+ 小时真实多会话联调的日志复盘，评估「高配主会话协调 + flash 子会话实施」模式相对传统 agent team 的优劣，并给出 dsh-session-link-pro 的升级设计提案。文档将提交 DSH 会诊（多模型并行评审）做交叉评估——**§7 的开放议题是会诊的重点对象**，§1–§6 是证据与推导，供评审者核验。
>
> **插件归属边界（重要）**：本文只涉及 dsh-session-link-pro（跨会话消息 / 会话列表 / 导出 / 深链）。日志中出现的「会诊」（`consult_start` / `consult_stop`，多模型并行评审）是 **dsh-thincoder-suite** 插件的功能，不属于也不应并入本插件。DSH 版本 0.1.5，插件版本 0.2.4。

---

## 1. 调研范围与方法

- **方法**：只读分析。将 zstd 压缩的会话日志复制到临时目录解压，解析 JSONL 事件流（user/message、assistant/message、tool/call、tool/ptc-dispatch、request/header、subagent/catalog、session 等），统计通信流量、时序、模型配置与人工介入点。未做重放实验，未修改任何原始日志。
- **样本**：一次完整的工作弧线（8996 报告质量修复线，mal-analyze-cli 工作区），覆盖 2026-09-16 23:20 → 09-17 21:07，共 6 个相关会话：

| 会话 | 角色 | 模型 | 创建时间 | 日志体量 |
|---|---|---|---|---|
| `session-9c05bcaf` | 第 2 代协调者（夜班） | GLM-5.3 (zai-coding-cn, reasoning max) | 09-16 23:20 | 2289 事件 / 331 步 / 72 回合 |
| `session-1c2d629a` | 第 3 代协调者（白班） | GLM-5.3 (qax, reasoning max) | 09-17 15:03 | 3828 事件 |
| `session-d0a7bb39`（下称 W1） | 实施 worker（A-2 实验/切臂/门禁） | deepseek-flash (high) | 09-16 15:47 | 7860 事件 |
| `session-75cdc0ff`（下称 W2） | 实施/部署 worker（payload/部署窗/验收） | deepseek-flash (max) | 09-08 20:48（9 天账龄） | 32444 事件 |
| `session-0ecacb36` / `session-f3d0cde5` | 新 worker A / B（18 点换届后） | deepseek-flash | 09-17 18:17 / 18:25 上线 | — |
| `session-f6fd63e3` | 第 1 代协调者（更早，经交接文档下岗） | — | — | 21047 事件 |

- **日志位置**（复验用）：`D:\DSH-Portable\profile\sessions\--D-workspace-mal-analyze-cli--\session-<id>\session.v3.jsonl.zstd`

**样本局限**：单一工作弧线、单一操作者（用户）的使用习惯、协调者为强模型（GLM-5.3 max）。协议质量高的部分有多强协调者的贡献，不能完全归功于机制本身。

---

## 2. 实测架构与规模

### 2.1 团队拓扑：星型

- 协调者 ↔ 各 worker 双向消息；**worker 之间不直连**，跨 worker 信息全部经协调者中转。
- 消息全部走本插件 `session_link_pro_send`（接收方日志中消息 id 均为 `slp-` 前缀，source 形状 `{kind: "agent-message", form: "relay", senderSessionId}`）。

### 2.2 流量与延迟（夜班窗口 09-16 23:21 → 09-17 15:00）

| 指标 | 数值 |
|---|---|
| 协调者发出 / 收到 | 78 条 / 78 条（W1：41 出 43 入；W2：37 出 35 入） |
| W1 全生命周期 | 发出 105 条（3 代协调者 + 其他），收到 121 条 |
| 典型往返延迟 | 30 秒 – 3 分钟（接近实时协同） |
| 人工介入 | 23:20 布置交接 → 23:42 下纪律后离开；10:09 回来要晨报；**中间约 9.5 小时自主运行** |
| 交付成果 | A-2 三臂实验闭环、批O 三绿、H4c 验收双 FAIL 后回滚、G-x③ 部署+验收全绿、R-A2-1 四片补丁、P0-D 实施、GRANT 紧急修复——全部有 commit 与验收证据 |

### 2.3 涌现的协作协议（约定，非机制保证）

以下全部是模型间自发形成、靠 prompt 纪律维持的约定：编号裁决（【裁决：N 条】）、显式回执（【收到】）、自首文化（越界操作主动上报 + 损失清单）、陈旧读数作废声明、验收锚点表、落盘交接文档与会诊纪要（thincoder-suite 侧）作为团队持久记忆。

---

## 3. 关键证据清单

> 每条 = 事实（含出处）→ 含义。时间为本地时间，引用可按 §1 路径复验。

### 3.1 模式有效性证据

**E1 上下文隔离红利。** W2 带 9 天 / 32444 事件的上下文干活，协调者只看到 78 条蒸馏消息；协调者全程 331 步，W1 单日 511 次 pwsh + 244 write + 229 edit。贵的模型读结论，便宜的模型背原始上下文。
→ 多会话模式的核心价值：**上下文成本与模型档位解耦**。

**E2 故障隔离与自愈。** 00:14:34 W1 误删 `payload-v7.tar`（过宽 grep 选择器），**主动自首**带损失清单；协调者 32 秒内（00:15:07）转派 W2 重建，00:15:39 W2 报告已重建并恢复部署。
→ 单点事故不传染，hub 快速调度跨 worker 补救。

**E3 真正独立的执行循环。** W1 自跑 gate watcher 与哨兵（00:40:14 哨兵报 READY 自动触发切臂），不阻塞协调者回合。
→ worker 有自己的事件循环与后台任务，这是 subagent 模式难以原生提供的。

**E4 文档冷启动有效。** 18:25 新 worker A 上线，仅凭落盘交接文档 + 协调者起草的 onboarding prompt 在分钟级进入工作状态；18:17 新 worker B 的第一次方向确认即被协调者评价「质量很高」。
→ **换届的可行载体已验证：落盘文档 + 定向 prompt，不依赖旧会话上下文转移。**

**E5 混合架构已自然形成。** 协调者在会话内用 thincoder-suite 的会诊（4 模型并行评审）做设计裁决，用跨会话通道派实施。
→ 紧凑循环（评审）用进程内 subagent、重实施用持久会话——两者互补，不是二选一。

### 3.2 痛点证据

**P1 等待期静默（心跳缺失）。** 00:24:08 协调者发出指令后回合结束，两个 worker 都在跑长任务无人发消息，团队静默；00:31 用户抱怨「继续啊？怎么停下了？」，00:33 明确要求「等待验收也得有个心跳机制」。静默持续到 00:38:59（约 14 分钟，靠用户人工 nudg 打断）。
→ **没有任何机制负责在「双端都在等待」时叫醒协调者**。worker 忘记汇报 = 团队永久停摆（仅靠纪律约束兜底）。

**P2 星型中转税。** 00:15 W1 的事故通报需要协调者手工转发给 W2；纪律指令每次要发两遍（23:42、00:42 均为成对发送）。
→ 跨 worker 信息流 O(N) 经 hub，协调者成为信息瓶颈与单点。

**P3 指令竞态。** 00:40:14 W1 哨兵自动触发切臂提交；00:42:49 协调者基于验收失败发出回滚指令——两条指令在途交叉。协调者只能事后用「新裁决覆盖旧指令」解序（00:43:23 连发两条定向解序消息）。
→ 发送方看不到接收方「正在回合中执行什么」，无忙碌可见性；时序冲突无事务性保障，靠模型自觉仲裁。

**P4 信任门禁阻塞 mesh 扩展。** 16:00:24 W2 按协调者指示**直投 W1 失败**（「直连通道未配对……请用户放行，或继续经你转」）——未配对直连触发接收门，超时按取消处理。
→ 配对/信任全部以会话 id 为键；**无人值守时新通道无法建立，只能退回 hub 中转**。

**P5 生命周期管理全手动（本调研第二轮重点）。** 24 小时内发生 5 次生命周期操作，还原如下：

| 操作 | 时间 | 用户手动步骤 |
|---|---|---|
| 协调者换届 #1→#2 | 09-16 23:20 | 新建会话 + 粘贴交接指令（读交接文档） |
| 协调者换届 #2→#3 | 09-17 15:03–15:13 | ① 新建 `1c2d629a` 粘贴「接手 @9c05bcaf」（15:03）；② **逐个进入 worker 粘贴「切换主管会话为：@新id」（15:04:20 W1，W2 同）**；③ 重新交代纪律（15:11），新协调者再向 worker 广播【纪律重绑定】（15:12） |
| worker 全换 | 09-17 18:03–18:25 | 用户宣布「收尾 + 另派新会话」（18:03）→ 协调者发收尾冻结指令（18:04）→ 协调者起草 2 份 onboarding prompt + 落盘交接文档（18:09–18:10）→ **用户手动建 2 个新会话、逐个粘贴 prompt**（18:17 / 18:25 上线） |
| 临时实验会话生灭 | 09-17 16:28–17:16 | 用户手动创建 `9c86806f` 跑对照实验，协调者收结果后宣告收官 |
| W1 自动压缩 | 09-17 15:10:07 | 无（DSH 自动 checkpoint「condensing an earlier span to free up context」） |

→ **换届频率高**（协调者 24h 换 3 代）、**每次 10–20 分钟纯粘合工作**、**漏步即事故**（漏通知一个 worker = 它继续向已退役会话汇报；漏配对 = 夜间断联，P4 已间接验证）。旧 pairs 在设置中成为死数据无限堆积。
→ 换届的根因（上下文疲劳）是结构性的：P5 末行的自动压缩是直接物证；压缩 ≠ 干净重置。

**P6 复盘观测性差。** 还原这次联调需要人工解压拼装 6 份日志（本调研本身的工作量即证明）；无统一团队时间线视图。

---

## 4. 对比结论：多会话联调 vs 传统 agent team

| 维度 | 多会话联调（本插件） | 传统进程内 agent team |
|---|---|---|
| 上下文 | 各自独立窗口，重上下文留在便宜会话（E1） | 父会话承担整合开销，长任务撑爆上下文 |
| 模型档位 | 天然异构（高配 hub + flash worker） | 通常同模型同配置，异构别扭 |
| 生命周期 | 持久、可跨天、可换届、可人工直接介入任意节点 | 一次性、黑盒、无法中途插话 |
| 并行 | 独立回合循环 + 后台任务（E3） | 子代理通常阻塞父会话等结果 |
| 故障隔离 | 会话级隔离，可弃可换（E2） | 子代理失败需父会话处理 |
| 调度 | **无调度器**，靠消息唤醒（P1 静默） | 父会话派发循环驱动 |
| 状态同步 | 散文 + 仓库文件，无事务性（P3 竞态） | 可共享 scratchpad / 队列 / 锁 |
| 通信开销 | 每条消息 = 接收方一次完整 LLM 回合 | 进程内调用，近零成本 |
| 观测性 | 需拼多份日志（P6） | 通常有单一 trace |
| 规模 | 3–5 会话可用（协议靠纪律维持） | 框架内可编码协议，扩展性更好 |

**建议**：不是二选一。大颗粒/长周期/重上下文/需人工可控 → 多会话联调；低延迟/小结果/fan-out 评审 → 进程内 subagent（thincoder-suite 会诊即此用法，E5）。该夜班已自然收敛为混合架构。

---

## 5. 升级设计提案

### 5.0 分层视图

四个功能共享一个底层原语：

```
roster（角色注册表，身份层）  ← 底座
 ├── heartbeat（活性层）：解决 P1
 ├── broadcast（寻址层）：解决 P2/P4
 └── rotation（生命周期层）：解决 P5
receipts/busy（可观测层）：解决 P3/P6
```

### 5.1 P0-a：roster —— 角色注册表

**问题**：身份 = 会话 id（P4/P5 的共同根源：配对、信任、通知、心跳注册全绑在物理会话上）。

**设计**：
- 团队名 → 角色（coordinator / worker / …）→ 当前 session id → 版本历史（含 retired 记录，退役 ≠ 删除，export 保留可查）。
- 存储：插件 settings 命名空间即可（与 pairs 同级），另在 `team/` 目录落一份人可读 roster（与 §5.6 黑板合一）。
- 换届 = 更新 roster 条目 + 迁移配对 + 广播，三个原子动作。
- 顺带解决死 pairs 堆积：roster 变更时清理指向 retired 会话的 pairs/trustedSenders 条目。

### 5.2 P0-b：heartbeat —— 心跳/看门狗

**问题**：P1（双端等待时团队静默；用户原话点名要心跳）。

**设计**（两档，可分别实现）：
- **轻档**：`list_sessions` 暴露活性信号——「目标回合已结束但 N 分钟无外发消息」，供协调者轮询判断 worker 是否失联。（纯只读，零风险，最先做。）
- **重档**：会话可注册「M 分钟无消息则向自身 followup 一条 tick」（插件侧定时器，本质是自我唤醒），换届时注册随 roster 迁移。
- 心跳消息走普通 relay 通道，正文标记 `[heartbeat]`，接收方可低成本忽略。

### 5.3 P1-a：broadcast —— 角色制群播

**问题**：P2（星型中转税）+ P4（直连门禁阻塞）。

**设计**：
- `send(targets: [...] | team: <name>)`：一次调用多处投递（循环底层 send，非新通道）。
- **角色制寻址，非自由 mesh**：coordinator 可广播全队；worker 默认只能点对点发 coordinator 或经群总线只读可见。理由：(a) 协调者的价值部分在于**策展**每个 worker 看到什么（本次日志实证：事故通报是择要转发的）；(b) flash worker 最稀缺的资源是上下文，全连通互相污染（W2 已 9 天 3.2 万事件）。
- worker 间直连仍走配对门（用户放行后建立，解决 P4 的正确姿势是显式放行而非绕过）。

### 5.4 P1-b：rotation —— 编排式换届（「一键」的正确形态）

**问题**：P5（全手动 + 漏步风险 + 夜间断联）。

**设计原则**：
1. **机制与判断分离**：插件负责机械部分——冻结收尾清单、备换届包、广播身份变更、迁移信任（pairs 旧 id → 新 id、双向 trustedSenders）、重放纪律指令。交接**内容**（prompt、交接文档）仍由协调者模型起草——18:09 的 prompt 质量已证明模型做得比模板好。
2. **换届包 = roster + 近 N 条 relay 摘要 + 指向落盘交接文档的指针**。不做全量深链快照（16 小时协调会话的快照太大；落盘文档是已验证载体，E4）。
3. **收尾清单固化**（源自 18:04 实测协议）：停哨兵/后台 job → 确认无在飞服务器动作 → 状态冻结回报 → 交接。
4. **错峰默认**：默认引导「先换协调者 → 稳定 → 再换 worker」，任何时刻保留一个活记忆；「一次全换」提供但强制先跑收尾清单。
5. **可编程创建待验证**：若插件 API 面无法创建新会话，则做半自动（备好一切 + 打开预填 prompt 的新会话 UI，用户点创建）——仍消除 80% 手动步骤与几乎全部漏步风险。

### 5.5 P1-c：receipts + busy —— 回执与忙碌可见性

**问题**：P3（竞态）+ P6（观测性）。

**设计**：
- 两级回执：已投递到目标会话 / 已被目标回合消费。发送方 `list_sessions` 可见，消灭「发进虚空」。
- 忙碌可见性：`list_sessions` 增加「当前回合开始时间 / 最近一条 assistant 消息时间」——发送前可预判 steer vs followup，避免指令在途交叉（P3 的 00:42 场景本可预防）。

### 5.6 P2：结构化信封 + 团队黑板

- **信封**：紧急度（🔴 手写约定已有效）/ 消息类型（裁决/回执/汇报/提问）/ in-reply-to。**约束**：0.1.5 的 source 白名单锁死三成员（`agent-message` + `relay` + `senderSessionId`），元数据只能走正文 banner 或 sidecar 索引文件（按 `slp-` id 索引）——不得扩 source。
- **黑板**：标准化 `team/` 目录（roster、decision log、纪律条款），`list_sessions` 顺带展示——日志显示团队已自发收敛到用仓库文件当持久记忆（交接文档 ×3、纪要、账本），插件只需把约定固化。

### 5.7 非目标（明确不做）

1. **不做自主编排器**（自动派活/自动协商/swarm）——模式价值恰在人在环上、模型异构、可控介入。
2. **不做全连通自由群聊**——上下文污染 + 配对组合爆炸。
3. **不对抗 0.1.5 source 白名单**——违反代价见 README「会话格式兼容」。
4. **不并入会诊/多模型评审**——thincoder-suite 边界；本插件保持「传输 + 身份 + 生命周期」定位，组合权留给会话内的模型。

---

## 6. 风险与诚实声明

- 单一工作弧线样本；协议质量含强协调者（GLM-5.3 max）贡献，机制收益无法完全剥离。
- 未做重放实验；P1/P3 为观测性归因（机制链清晰但无受控对照）。
- 「插件能否编程创建会话」「settings 迁移 API 的写入语义」未验证，影响 5.4 的实现档位。
- worker 换届的收益证据（E4）同样适用于「换掉表现差的会话」与「上下文疲劳重置」两种解释，本样本无法区分权重。

---

## 7. 会诊议题（评审重点）

1. **优先序**：roster 先行（作为三功能底座）vs heartbeat 先行（独立可发布、痛点最新鲜）——哪个排序对？半自动换届（5.4 之 5）在 API 受限下是否仍值得先做？
2. **群播拓扑**：hub 中转 + 角色制广播（5.3）vs 共享总线（全员只读可见）vs 受控 mesh——在「协调者策展价值」与「中转税」之间怎么切？
3. **换届自动配对的安全性**：插件侧受信操作自动迁移 pairs（5.4 之 1）vs 始终用户在环确认——夜间无人值守换届的安全边界应划在哪？
4. **错峰 vs 全换**：5.4 之 4 的默认策略是否过保守？「一次全换 + 强制收尾清单」是否可接受为默认？
5. **信封载体**：正文 banner vs sidecar 索引（5.6）——对会话日志可迁移性、UI 渲染、token 成本各有什么影响？
6. **规模目标**：按 3–5 会话设计，还是预留 8–10？后者对 roster/广播/心跳的形状有什么实质影响？
7. **心跳重档（自我 followup）与 DSH goal 轮次 / 自动 checkpoint 的交互**：00:31 的静默是否实为 goal 轮次耗尽（晨间「Goal 已恢复（40/70）」暗示）？插件心跳是否应感知 goal 状态？
8. **对 §4 对比结论的反驳**：有哪些传统 agent team 框架能力被低估，或本模式优势被高估？

---

*调研：ZCode (GLM-5.3)，2026-09-17。方法与原始数据见 §1；全部时间戳可按日志路径复验。*