AI Agent人工智能代码智能体交互助手【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址https://gitcode.com/gh_mirrors/op/openchamber点击查看免费下载OpenChamber 1.6.02026-01-29 发布的主题是「Chat recovers automatically when it stalls」当 OpenCode 的事件流长时间没有数据时客户端能够检测到停滞并自动重新同步而不是让聊天界面永久卡死。本篇以 changelog/1.6.0.md 中的发布记录为骨架结合仓库中sseProxy代理层与聊天历史分页加载器的真实源码完整拆解本次发布的停滞检测机制、Load older 分页修复以及 PR 选择器、worktree 合并、会话活动状态跟踪等改进项的实际落地位置。一、1.6.0 解决了什么问题1.6.0 的发布说明按 AppWeb与 VS Code 两个客户端分别列出了变更核心条目如下摘自 changelog/1.6.0.mdAppWeb 客户端新增Chat 消息停滞检测与自动软重同步message stall detection with automatic soft resync改进Git PR 选择器现在会校验本地分支是否存在并提供刷新操作worktree 集成在合并前先同步干净的目标目录VSCode webview 隐藏时会话活动状态也能可靠更新Web 端的会话活动跟踪在多个浏览器标签页间保持一致修复聊天中「Load older」按钮的分页行为查看大量修改文件时 Diff 视图的内存泄漏大变更集改为懒加载plans 目录不存在时不再报错VS Code 扩展新增消息停滞检测与自动软重同步与 Web 端能力对齐改进扩展面板隐藏或折叠时会话活动状态仍能可靠更新修复长会话中「Load older」按钮的渐进式分页行为这些改动可以归为三条主线流式通道的可靠性停滞检测/软重同步、历史消息的分页正确性Load older 修复、周边 Git 与状态跟踪的工程化收尾。下面按主线展开并用仓库源码印证每条改动的实现细节。二、核心机制SSE 停滞检测与自动软重同步2.1 背景OpenChamber 依赖一条全局 SSE 事件流OpenChamber 的聊天、会话状态、Git 变更等信息都来自 OpenCode 服务端推送的事件流。从 sseProxy.ts 的注释可以看到OpenCode 2.x 在GET /api/event上提供一条全局事件流每个事件帧自带location.directory字段因此客户端无需为每个目录单独开流。VS Code 扩展作为 Webview 与 OpenCode 服务端之间的代理负责把这条流转发到 Webview代理逻辑即openSseProxyHTML 注入在 webviewHtml.ts 中完成。这种「单条长连接承载一切」的架构好处是连接数少、状态统一风险则在于一旦这条流安静下来服务端还在、但字节不再到达客户端不会感知到任何断开界面就停留在最后一次事件的状态上。1.6.0 的停滞检测正是针对这个失效模式设计的。2.2 停滞判定可重置的超时计时器停滞检测的核心在 pipeSseResponse 中。实现思路是「滑动窗口静默判定」默认超时阈值为 20 秒由常量DEFAULT_UPSTREAM_STALL_TIMEOUT_MS 20000定义sseProxy.ts#L23-L26调用方也可通过stallTimeoutMs参数覆盖resolveStallTimeoutMs会对非法值回退到默认值resetStallTimer在两种时机启动一个setTimeout流开始读取时以及每收到一个非空数据块后重置计时一旦计时器到期stalled被置为true并对底层 reader 执行cancel()主动掐断这条静默流后续清理阶段若抛出的是停滞引发的异常会被识别if (!stalled) throw error并静默处理避免把「正常检测出的停滞」误报成流错误这套机制的要点在于「每收到一个字节就重新计时」长工具调用、模型思考期间即便几十秒没有输出只要上游仍有保活字节到达就不会误判为停滞而真正卡死时20 秒的静默窗口足以让客户端在用户明显感知到「界面不动了」之前完成自愈。2.3 软重同步关闭旧流、指数退避重连「软重同步soft resync」中的软从源码结构看体现为只重建流层连接不销毁会话/聊天状态。openSseProxysseProxy.ts#L189-L278把重连策略封装成两层连接阶段重连connect()内部捕获非中止错误后最多重试MAX_RECONNECTS 3次采用指数退避——基础延迟 1 秒第 n 次重试等待1000 * 2^(n-1)ms即 1s、2s、4s流中断后重连当pipeSseResponse抛出错误时若错误cause.code是UND_ERR_SOCKET或ECONNRESETNode/undici 的 socket 层典型断连错误同样按指数退避重连并重新接管流重连成功则继续运行失败才把错误向上抛出因此一次「停滞→恢复」的完整链路是静默超过 20 秒 → 计时器置位并 cancel reader →pipeSseResponse正常返回或抛错 → 外层判定后按退避策略重新fetch GET /api/event→ 新流接管onChunkWebview 内的 UI store 基于事件帧继续收敛状态。对用户的可观察效果就是聊天卡住一段时间后自动「续上」无需手动刷新页面或重启扩展。2.4 测试用例对机制的锁定sseProxy.test.ts 中有两个直接对应该机制的用例closes a quiet upstream SSE stream after the stall timeoutL50用极小的stallTimeoutMs: 20模拟上游静默流断言流会在超时后被主动关闭resets the stall timeout when upstream bytes arriveL74验证字节到达会重置计时避免误杀仍在输出的流这两个用例恰好锁定了「判定」与「防误判」两端是回归验证该特性的最小入口。三、「Load older」分页修复从按钮到游标分页器1.6.0 在 App 与 VS Code 两侧都修复了长会话中「Load older」按钮的行为发布说明将其归因为「proper pagination / progressive pagination」。对应的实现集中在聊天历史加载器 session-message-loader.ts 中可以从源码看到这次修复落地的具体形态加载类型枚举SessionMessageLoadKind定义了initial | older | refresh | prefetch四种加载场景L44「Load older」对应loadOlder→loadOlderPage(target, interactive)L338-L342与首次加载、尾部刷新、后台预取在调度上完全解耦游标分页loadOlderPage以HISTORY_MESSAGE_PAGE_SIZE为页大小携带游标调用fetchPage(..., older, performance)拉取更早的一页并把partsByMessageID与消息列表按页合并游标随快照前进L353-L371并发与重复点击防护同一目标上若已有older类型的在途请求直接复用entry.inflight其完成后自动再取一页这保证了快速连点「Load older」时请求合并而非重复拉取无进展保护若追加取回的更早一页为空且流未结束抛出Session history pagination made no progress错误L366防止服务端游标异常导致按钮空转按钮的 UI 宿主在 ChatContainer.tsx 与 TimelineDialog.tsx 中仓库内「Load older」文案的引用点而分页状态机则由上述加载器统一驱动。这套结构解释了发布说明里「proper progressive pagination」的含义老消息按页渐进加载、可重复触发、且有明确的终止与防抖条件。四、Git 相关改进PR 选择器与 worktree 合并发布说明中的两条 Git 改进PR 选择器校验本地分支 刷新操作选择 PR 创建/切换分支前会先校验目标本地分支是否真实存在并提供手动刷新列表的入口。VS Code 侧的 Git 运行时按职责拆分在packages/vscode/src/下的bridge-git-*系列文件中如 bridge-git-runtime.ts、bridge-git-special-runtime.ts分支校验与刷新属于该运行时的分支解析逻辑worktree 集合成先同步干净的目标目录在把 worktree 变更合并回目标分支前先确保目标目录处于干净状态避免工作区脏文件与合并产生冲突。这条改进直接降低了 worktree 工作流的失败率是发布说明中「Improvements」而非「Fixes」属于行为增强这两项与 OpenChamber 的 worktree 多工作区能力文档见 packages/docs/content/docs/worktrees.mdx配套使「从 PR 分支拉工作区、改完合回去」的闭环更可靠。五、会话活动状态跨标签页、跨隐藏面板的可靠性1.6.0 还有两条看似零散、实则同源的状态跟踪改进VS Code扩展面板隐藏或折叠时会话活动状态仍可靠更新。从源码结构看扩展并不依赖 Webview 可见性来驱动事件处理——SSE 代理sseProxy运行在扩展宿主进程中Webview 只是流的消费者把活动状态计算与 UI 渲染解耦后面板隐藏不会暂停状态收敛Web会话活动跟踪在多个浏览器标签页间保持一致。多标签页各自维护 UI 状态但事件来源是同一服务端流1.6.0 的修复保证了不同标签页对「哪个会话正在活动」的判定一致结合停滞检测来看这两条改进与主线目标一致让状态在 UI 不可见/通道短暂静默的情况下依然收敛到真值而不是在用户重新看到界面时才「迟到」。六、其余可靠性修复Diff 内存泄漏一次查看大量修改文件时Diff 视图曾把全部文件内容一次性载入导致内存增长1.6.0 起大变更集改为懒加载按需渲染文件级 diff。相关测试夹具可见 DiffView.hunks.fixture.tsx 与 DiffView.hunks.test.tsplans 目录缺失容错plans 目录不存在时不再报错属于对缺失可选目录的防御性处理七、如何查看与验证本次变更发布记录changelog/1.6.0.md单版本记录汇总见 CHANGELOG.md 与 packages/vscode/CHANGELOG.mdVS Code 扩展侧停滞检测实现与测试packages/vscode/src/sseProxy.ts、packages/vscode/src/sseProxy.test.ts历史分页加载器与测试packages/ui/src/sync/session-message-loader.ts、packages/ui/src/sync/session-message-loader.test.ts适用前提说明以上机制描述以当前仓库快照为准。停滞检测依赖 OpenCode 2.x 的全局事件流GET /api/eventstallTimeoutMs默认 20 秒、最多 3 次指数退避重连均为代理层常量若你部署的服务端版本事件推送行为不同例如长静默但不断流实际恢复时延会随之变化可结合上述测试用例中的参数化方式自行验证。赞分享AI Agent人工智能代码智能体交互助手【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址https://gitcode.com/gh_mirrors/op/openchamber点击查看免费下载相关推荐Zcash 4.4.1 版本解析getheaders 同步停滞修复与 Windows 构建系统调整Zcash 4.4.1 版本解析getheaders 同步停滞修复与 Windows 构建系统调整 本篇技术指南以 Zcash 官方发布说明 doc/rele区块链金融科技密码学后端HY-Embodied-0.5硬件要求与配置从边缘设备到云端部署的完整指南HY Embodied 0.5硬件要求与配置从边缘设备到云端部署的完整指南 HY Embodied 0.5是腾讯推出的多模态AI模型结合了视觉与文本处理能力后端消息队列任务调度DeepSeek Harness 有界 LLM 请求恢复机制解析LlmFailure、dsh-llm-retry 与停滞流超时的完整实现DeepSeek Harness 有界 LLM 请求恢复机制解析LlmFailure、dsh llm retry 与停滞流超时的完整实现 本文基于仓库内架构决人工智能AI AgentAgent 框架DeepSeek上一篇Jupyter Docker Stacks 新特性贡献指南从提案、评审标准到本地构建与 CI 验证下一篇UnblockNeteaseMusic常见错误代码解析错误码1001到5000全解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenChamber 1.6.0：消息停滞时聊天自动恢复——SSE 停滞检测与软重同步的源码级解析
AI Agent人工智能代码智能体交互助手【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址https://gitcode.com/gh_mirrors/op/openchamber点击查看免费下载OpenChamber 1.6.02026-01-29 发布的主题是「Chat recovers automatically when it stalls」当 OpenCode 的事件流长时间没有数据时客户端能够检测到停滞并自动重新同步而不是让聊天界面永久卡死。本篇以 changelog/1.6.0.md 中的发布记录为骨架结合仓库中sseProxy代理层与聊天历史分页加载器的真实源码完整拆解本次发布的停滞检测机制、Load older 分页修复以及 PR 选择器、worktree 合并、会话活动状态跟踪等改进项的实际落地位置。一、1.6.0 解决了什么问题1.6.0 的发布说明按 AppWeb与 VS Code 两个客户端分别列出了变更核心条目如下摘自 changelog/1.6.0.mdAppWeb 客户端新增Chat 消息停滞检测与自动软重同步message stall detection with automatic soft resync改进Git PR 选择器现在会校验本地分支是否存在并提供刷新操作worktree 集成在合并前先同步干净的目标目录VSCode webview 隐藏时会话活动状态也能可靠更新Web 端的会话活动跟踪在多个浏览器标签页间保持一致修复聊天中「Load older」按钮的分页行为查看大量修改文件时 Diff 视图的内存泄漏大变更集改为懒加载plans 目录不存在时不再报错VS Code 扩展新增消息停滞检测与自动软重同步与 Web 端能力对齐改进扩展面板隐藏或折叠时会话活动状态仍能可靠更新修复长会话中「Load older」按钮的渐进式分页行为这些改动可以归为三条主线流式通道的可靠性停滞检测/软重同步、历史消息的分页正确性Load older 修复、周边 Git 与状态跟踪的工程化收尾。下面按主线展开并用仓库源码印证每条改动的实现细节。二、核心机制SSE 停滞检测与自动软重同步2.1 背景OpenChamber 依赖一条全局 SSE 事件流OpenChamber 的聊天、会话状态、Git 变更等信息都来自 OpenCode 服务端推送的事件流。从 sseProxy.ts 的注释可以看到OpenCode 2.x 在GET /api/event上提供一条全局事件流每个事件帧自带location.directory字段因此客户端无需为每个目录单独开流。VS Code 扩展作为 Webview 与 OpenCode 服务端之间的代理负责把这条流转发到 Webview代理逻辑即openSseProxyHTML 注入在 webviewHtml.ts 中完成。这种「单条长连接承载一切」的架构好处是连接数少、状态统一风险则在于一旦这条流安静下来服务端还在、但字节不再到达客户端不会感知到任何断开界面就停留在最后一次事件的状态上。1.6.0 的停滞检测正是针对这个失效模式设计的。2.2 停滞判定可重置的超时计时器停滞检测的核心在 pipeSseResponse 中。实现思路是「滑动窗口静默判定」默认超时阈值为 20 秒由常量DEFAULT_UPSTREAM_STALL_TIMEOUT_MS 20000定义sseProxy.ts#L23-L26调用方也可通过stallTimeoutMs参数覆盖resolveStallTimeoutMs会对非法值回退到默认值resetStallTimer在两种时机启动一个setTimeout流开始读取时以及每收到一个非空数据块后重置计时一旦计时器到期stalled被置为true并对底层 reader 执行cancel()主动掐断这条静默流后续清理阶段若抛出的是停滞引发的异常会被识别if (!stalled) throw error并静默处理避免把「正常检测出的停滞」误报成流错误这套机制的要点在于「每收到一个字节就重新计时」长工具调用、模型思考期间即便几十秒没有输出只要上游仍有保活字节到达就不会误判为停滞而真正卡死时20 秒的静默窗口足以让客户端在用户明显感知到「界面不动了」之前完成自愈。2.3 软重同步关闭旧流、指数退避重连「软重同步soft resync」中的软从源码结构看体现为只重建流层连接不销毁会话/聊天状态。openSseProxysseProxy.ts#L189-L278把重连策略封装成两层连接阶段重连connect()内部捕获非中止错误后最多重试MAX_RECONNECTS 3次采用指数退避——基础延迟 1 秒第 n 次重试等待1000 * 2^(n-1)ms即 1s、2s、4s流中断后重连当pipeSseResponse抛出错误时若错误cause.code是UND_ERR_SOCKET或ECONNRESETNode/undici 的 socket 层典型断连错误同样按指数退避重连并重新接管流重连成功则继续运行失败才把错误向上抛出因此一次「停滞→恢复」的完整链路是静默超过 20 秒 → 计时器置位并 cancel reader →pipeSseResponse正常返回或抛错 → 外层判定后按退避策略重新fetch GET /api/event→ 新流接管onChunkWebview 内的 UI store 基于事件帧继续收敛状态。对用户的可观察效果就是聊天卡住一段时间后自动「续上」无需手动刷新页面或重启扩展。2.4 测试用例对机制的锁定sseProxy.test.ts 中有两个直接对应该机制的用例closes a quiet upstream SSE stream after the stall timeoutL50用极小的stallTimeoutMs: 20模拟上游静默流断言流会在超时后被主动关闭resets the stall timeout when upstream bytes arriveL74验证字节到达会重置计时避免误杀仍在输出的流这两个用例恰好锁定了「判定」与「防误判」两端是回归验证该特性的最小入口。三、「Load older」分页修复从按钮到游标分页器1.6.0 在 App 与 VS Code 两侧都修复了长会话中「Load older」按钮的行为发布说明将其归因为「proper pagination / progressive pagination」。对应的实现集中在聊天历史加载器 session-message-loader.ts 中可以从源码看到这次修复落地的具体形态加载类型枚举SessionMessageLoadKind定义了initial | older | refresh | prefetch四种加载场景L44「Load older」对应loadOlder→loadOlderPage(target, interactive)L338-L342与首次加载、尾部刷新、后台预取在调度上完全解耦游标分页loadOlderPage以HISTORY_MESSAGE_PAGE_SIZE为页大小携带游标调用fetchPage(..., older, performance)拉取更早的一页并把partsByMessageID与消息列表按页合并游标随快照前进L353-L371并发与重复点击防护同一目标上若已有older类型的在途请求直接复用entry.inflight其完成后自动再取一页这保证了快速连点「Load older」时请求合并而非重复拉取无进展保护若追加取回的更早一页为空且流未结束抛出Session history pagination made no progress错误L366防止服务端游标异常导致按钮空转按钮的 UI 宿主在 ChatContainer.tsx 与 TimelineDialog.tsx 中仓库内「Load older」文案的引用点而分页状态机则由上述加载器统一驱动。这套结构解释了发布说明里「proper progressive pagination」的含义老消息按页渐进加载、可重复触发、且有明确的终止与防抖条件。四、Git 相关改进PR 选择器与 worktree 合并发布说明中的两条 Git 改进PR 选择器校验本地分支 刷新操作选择 PR 创建/切换分支前会先校验目标本地分支是否真实存在并提供手动刷新列表的入口。VS Code 侧的 Git 运行时按职责拆分在packages/vscode/src/下的bridge-git-*系列文件中如 bridge-git-runtime.ts、bridge-git-special-runtime.ts分支校验与刷新属于该运行时的分支解析逻辑worktree 集合成先同步干净的目标目录在把 worktree 变更合并回目标分支前先确保目标目录处于干净状态避免工作区脏文件与合并产生冲突。这条改进直接降低了 worktree 工作流的失败率是发布说明中「Improvements」而非「Fixes」属于行为增强这两项与 OpenChamber 的 worktree 多工作区能力文档见 packages/docs/content/docs/worktrees.mdx配套使「从 PR 分支拉工作区、改完合回去」的闭环更可靠。五、会话活动状态跨标签页、跨隐藏面板的可靠性1.6.0 还有两条看似零散、实则同源的状态跟踪改进VS Code扩展面板隐藏或折叠时会话活动状态仍可靠更新。从源码结构看扩展并不依赖 Webview 可见性来驱动事件处理——SSE 代理sseProxy运行在扩展宿主进程中Webview 只是流的消费者把活动状态计算与 UI 渲染解耦后面板隐藏不会暂停状态收敛Web会话活动跟踪在多个浏览器标签页间保持一致。多标签页各自维护 UI 状态但事件来源是同一服务端流1.6.0 的修复保证了不同标签页对「哪个会话正在活动」的判定一致结合停滞检测来看这两条改进与主线目标一致让状态在 UI 不可见/通道短暂静默的情况下依然收敛到真值而不是在用户重新看到界面时才「迟到」。六、其余可靠性修复Diff 内存泄漏一次查看大量修改文件时Diff 视图曾把全部文件内容一次性载入导致内存增长1.6.0 起大变更集改为懒加载按需渲染文件级 diff。相关测试夹具可见 DiffView.hunks.fixture.tsx 与 DiffView.hunks.test.tsplans 目录缺失容错plans 目录不存在时不再报错属于对缺失可选目录的防御性处理七、如何查看与验证本次变更发布记录changelog/1.6.0.md单版本记录汇总见 CHANGELOG.md 与 packages/vscode/CHANGELOG.mdVS Code 扩展侧停滞检测实现与测试packages/vscode/src/sseProxy.ts、packages/vscode/src/sseProxy.test.ts历史分页加载器与测试packages/ui/src/sync/session-message-loader.ts、packages/ui/src/sync/session-message-loader.test.ts适用前提说明以上机制描述以当前仓库快照为准。停滞检测依赖 OpenCode 2.x 的全局事件流GET /api/eventstallTimeoutMs默认 20 秒、最多 3 次指数退避重连均为代理层常量若你部署的服务端版本事件推送行为不同例如长静默但不断流实际恢复时延会随之变化可结合上述测试用例中的参数化方式自行验证。赞分享AI Agent人工智能代码智能体交互助手【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址https://gitcode.com/gh_mirrors/op/openchamber点击查看免费下载相关推荐Zcash 4.4.1 版本解析getheaders 同步停滞修复与 Windows 构建系统调整Zcash 4.4.1 版本解析getheaders 同步停滞修复与 Windows 构建系统调整 本篇技术指南以 Zcash 官方发布说明 doc/rele区块链金融科技密码学后端HY-Embodied-0.5硬件要求与配置从边缘设备到云端部署的完整指南HY Embodied 0.5硬件要求与配置从边缘设备到云端部署的完整指南 HY Embodied 0.5是腾讯推出的多模态AI模型结合了视觉与文本处理能力后端消息队列任务调度DeepSeek Harness 有界 LLM 请求恢复机制解析LlmFailure、dsh-llm-retry 与停滞流超时的完整实现DeepSeek Harness 有界 LLM 请求恢复机制解析LlmFailure、dsh llm retry 与停滞流超时的完整实现 本文基于仓库内架构决人工智能AI AgentAgent 框架DeepSeek上一篇Jupyter Docker Stacks 新特性贡献指南从提案、评审标准到本地构建与 CI 验证下一篇UnblockNeteaseMusic常见错误代码解析错误码1001到5000全解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考