[Bug] 长回合（含并行子 Agent）完成后会话页持续转圈，疑似未收到回合结束事件，需手动重开恢复

问题类别 · Category

UI / 界面体验 · UI / UX

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

影响体验 · Major（任务实际完成、数据不丢，但 UI 呈"卡死"状，需手动重开恢复）

复现频率 · Reproducibility

仅一次 · Once（有完整日志佐证；触发条件——长回合 + 并行子 Agent——较常见，怀疑会复发）

问题描述 · Description

WSL2 远程模式下执行一次只读分析任务，主会话并行启动 3 个子 Agent。任务实际已成功完成：服务端日志完整记录了 turn.started → turn.completed 生命周期，会话数据正常持久化。但客户端页面的加载状态永不结束，持续转圈，看起来像整个会话卡死。关闭并重新打开该会话后一切正常，完整汇报结果可见。

判断："回合结束"事件在 服务端 → 云端网关 → 客户端页面 的实时链路上丢失（或客户端未处理），且 UI 缺少超时对账（watchdog）机制，无法自动恢复加载态。

复现步骤 · Steps to reproduce

1. 环境：Windows 客户端 + WSL2 远程模式（zcode-server 3.7.7 linux-x64，内核 6.18.33.2-microsoft-standard-WSL2），模型 GLM-5.3
2. 发起一个长回合任务：主会话并行启动 3 个子 Agent（本例总时长约 12 分钟）
3. 等待任务自然完成（服务端已记录 turn.completed）
4. 页面持续转圈，数分钟无任何变化
5. 关闭并重新打开该会话 → 汇报结果完整显示，状态恢复正常

期望表现 · Expected behavior

回合结束后（服务端已记录 turn.completed），页面加载态应结束并渲染最终回复。若实时事件流中断，UI 应在静止超时后通过拉取持久化会话状态对账并自动收敛（断线重连 + 状态对账），而非无限转圈。

实际表现 · Actual behavior

• 页面无限转圈，用户只能手动重开会话才能恢复
• 重开后数据完好，证明服务端与持久层无问题，故障在事件下发/客户端侧
• 当天日志 turn.started / turn.completed 计数平衡（除进行中回合），无相关错误；416 条 gateway 告警均为遥测 schema 噪音（performance.detail 字段不识别），与事件流无关

ZCode 版本 · ZCode version

3.7.7（zcode-server，linux-x64）

设备 / 系统 / 浏览器 · Device / OS / Browser

Windows 客户端 + WSL2 远程模式（内核 6.18.33.2-microsoft-standard-WSL2）

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

日志：~/.zcode/cli/log/zcode-2026-08-19.jsonl（UTC，+8 为本地时间）。关键时间线：

07:56:53Z  turn.started    主会话 sess_33be918c-e636-48d6-b2d9-6c470d5a21c4
07:58:46Z  turn.started ×3 三个子 Agent 会话并行启动
08:01:54Z  turn.completed  子 Agent 1
08:03:14Z  turn.completed  子 Agent 2
08:03:20Z  turn.completed  子 Agent 3
08:08:37Z  turn.completed  主回合 ← 服务端生命周期完整闭合，之后该会话无任何错误日志
（此后页面持续转圈，直至用户手动重开会话）

相关 issue：#246（同为 WSL 模式转圈，但该例为 zcode-server 卡死于 9p RPC，本例服务端正常完成，根因不同）；#158（加载态不收敛，表现类似但位于任务列表组件）。

建议修复方向

事件流断连或丢失结束事件后，客户端于静止超时（如 30–60s 无新事件）时通过持久化会话接口对账回合状态，发现回合已结束即清除加载态并渲染最终消息。

Start with the timeline in ~/.zcode/cli/log/zcode-2026-08-19.jsonl and trace handling of turn.started and turn.completed across the server, gateway, and session page. Compare this case with issues #246 and #158, then locate the client’s loading-state and persisted-session handling. Done means a completed turn reliably ends the loading state and the page recovers when the live event is missed.