openchamber 1.9.2 发布解读：即时 Worktree、并行运行启动器与实时会话同步重构

• AI Agent
• 人工智能
• 代码智能体
• 交互助手

导读

openchamber 1.9.2 是 Agentic Development Environment 的一次以"性能与部署体验"为核心的迭代：它引入了 draft-first 的即时 Worktree 创建与重构后的 Multi-Run 启动器，为进程管理器场景补上了--foreground与显式--host参数，并从底层重写了实时会话同步与流式更新管线。阅读本文，你将掌握 1.9.2 中每一项变更的具体含义、对应的 CLI 参数用法与默认值、容器部署相关的行为调整，以及如何通过仓库源码验证这些能力。

版本总览

本版本对应的发布说明位于 changelog/1.9.2.md，发布日期为 2026-03-31，主题为 "Faster worktrees and smoother live sync"（更快的 Worktree 与更流畅的实时同步）。从变更内容看，1.9.2 的改动集中在四个层面：

• App 层：Worktrees/Multi-Run、CLI/Server、Chat/Performance、Models/Providers、Docker/Deployments、Web/PWA；
• VS Code 扩展层：Chat/Performance、Sessions/UI、Chat/Editor 集成、启动可靠性、推理内容渲染。

下文按主题逐项展开，并结合仓库源码给出可验证的实现依据。

Worktrees/Multi-Run：即时 draft-first Worktree 与全新启动器

即时创建 Worktree：先落草稿、后固化

1.9.2 为 Worktree 引入 "instant draft-first worktree creation"，核心思路是先以草稿（draft）状态即时创建工作树，再在后续流程中固化（materialize），从而避免用户等待完整创建链路的串行开销。这种设计让"开一个分支跑一个任务"从秒级等待变为近乎即时反馈。

仓库中的相关实现分布在 UI 层与同步层：

• Multi-Run 启动器与融合会话的界面实现在 packages/ui/src/components/multirun/MultiRunLauncher.tsx 与 packages/ui/src/components/multirun/MultiRunFusionDialog.tsx；
• 会话创建逻辑集中在 packages/ui/src/lib/multirun/createSession.ts（导出createMultiRunSession），由MultiRunFusionDialog.tsx直接调用；
• 底层的目录 Store 消费与事件路由由 packages/ui/src/sync 目录承载，其中 packages/ui/src/sync/DOCUMENTATION.md 对会话物化（materialization）、分页、缓存保留策略有完整描述。

从同步层文档可以印证 draft-first 思路背后的工程约束："Part-only streaming updates do not schedule retention"（仅含部分内容的流式更新不触发缓存保留清理），"一个会话的完整历史要么完整存在、要么整个消失"，这类策略保证了草稿会话可以即时渲染、又不会拖累长会话的内存占用。

Multi-Run 启动器：更干净的并行运行流程

1.9.2 重新设计了 Multi-Run 启动器（launcher），目标是"更干净、更快的并行运行流程"。从 MultiRunLauncher.tsx 的代码可以看到启动器的关键交互：

• 信任预检查：启动器在展示默认命令之前先处理共享命令的信任询问（"The launcher prepares a run: the shared commands ask for trust here, before they are shown as the defaults"），把信任决策前置到运行开始前；
• 文件附件与大小校验：对附加到运行的文件有大小限制（超出则提示fileTooLarge），并区分"单个文件已附加"与"多个文件已附加"两种提示，附件失败会有独立提示；
• 分组命名与基础分支选择：表单包含项目选择、分组名（group name）、base branch 等字段，isolateRuns（隔离运行）选项用于决定各并行会话是否在工作树中隔离执行；
• 部分失败容忍：调用createMultiRun后若failedCount > 0，会以 toast 提示部分失败，而不是整体报错，保证并行运行的部分成功结果不被丢弃。

融合会话（fusion session）是 Multi-Run 的高级形态：MultiRunFusionDialog.tsx会按session.time.created对各会话排序，并将多个并行会话的结果汇聚为一个融合会话，便于在一个窗口内对比不同 Agent 对同一任务的产出。

CLI/Server：--foreground、可配置 hostname 与显式--host

--foreground：面向进程管理器的一等公民

1.9.2 为openchamber serve增加了--foreground标志，专门服务于 systemd、supervisor、容器 entrypoint 等进程管理器场景——这类场景要求服务不自行 daemonize，由外部进程接管生命周期。

在 packages/web/bin/lib/cli-args.js 中，参数解析默认foreground: false，且--foreground与--no-daemon互为别名，都置为true：

// packages/web/bin/lib/cli-args.js case 'foreground': case 'no-daemon': options.foreground = true; break;

在 packages/web/bin/lib/commands-startup.js 中，服务注册命令（enable/start等）会明确打印建议的运行方式：

service command openchamber serve --foreground

这意味着系统服务单元可直接把openchamber serve --foreground作为 ExecStart，由 init 系统统一管理重启与日志。容器内启动也沿用了该模式：在 packages/web/server/lib/spaces/places/docker.test.js 的容器启动命令中可以看到：

exec openchamber serve --foreground --api-only --host 127.0.0.1 --port 27600

即隔离空间（space）内的 OpenChamber 服务始终以--foreground运行，同时配合--api-only与回环地址--host 127.0.0.1，只向空间内部暴露 API 端口。

显式--host与更安全的 localhost 默认值

1.9.2 增加了显式的--host选项，并为未指定 host 的场景提供更安全的 localhost 默认行为（感谢 @colinmollenhour、@rapidrabbit76、@yulia-ivashko）。参数解析位于 cli-args.js：

case 'host': { const { value, nextIndex } = consumeValue(i, inlineValue); i = nextIndex; if (typeof value !== 'string' || value.trim().length === 0) { throw new TunnelCliError('Missing value for --host.', EXIT_CODE.USAGE_ERROR); } options.host = value.trim(); break; }

要点：

• --host必须携带非空值，空值会以EXIT_CODE.USAGE_ERROR报错并提示Missing value for --host.；
• 默认host: undefined，配合"safer localhost defaults"，即未显式指定时服务倾向绑定到本机回环地址，避免意外暴露到局域网；
• 需要对外提供服务的场景（如局域网访问、容器端口映射）应显式传入--host 0.0.0.0或具体网卡地址。

--host在启动参数组装中同样生效：packages/web/bin/lib/cli-startup.js 的buildStartupArgs会把用户传入的 host 拼接进最终命令行：

const args = [resolveCliEntrypoint(), 'serve', '--foreground', '--port', String(options.port || DEFAULT_PORT)]; if (typeof options.host === 'string' && options.host.length > 0) { args.push('--host', options.host); }

托管服务器 hostname 可配置

同一批改动中，托管（managed）服务器的主机名（hostname）变为可配置项。cli-args.js中hostname默认为undefined，通过--hostname <value>设置：

case 'hostname': { const { value, nextIndex } = consumeValue(i, inlineValue); i = nextIndex; options.hostname = typeof value === 'string' ? value : options.hostname; break; }

这一选项让"托管服务器暴露给客户端的地址标识"可以由部署方控制，适合在多网卡、多域名或反向代理环境下部署的场景。

Chat/Performance：实时同步与流式更新重构

问题与目标

1.9.2 最重要的性能改动是重写实时会话同步（live session sync）与流式更新（streaming updates），目标是：削减渲染抖动（render churn）、降低 CPU 峰值，让长对话在多种运行时（Web、Electron、VS Code 扩展）下保持流畅稳定。

底层机制

同步层的实现细节集中在 packages/ui/src/sync/DOCUMENTATION.md，从中可以提取出本次重构的几个关键设计：

• 窄订阅取代宽订阅："Cross-directory selectors subscribe to the narrow child-store field they aggregate"，且"每个会话行订阅一个 session ID，而不是扫描每个子 store"。这意味着某个会话的message.part.delta等流式事件不再触发全局会话/状态扫描，渲染只发生在真正变化的最小范围；
• 事件增量更新：全局会话状态索引由事件（event）增量驱动，权威的按目录状态快照用于播种、清理遗漏的会话并调和错过的事件；"Unrelated streaming events such asmessage.part.deltamust not trigger global session/status scans"；
• 流式频率与排序解耦："Session display order is independent from streaming-frequencytime.updatedpublications"，会话排序只在权威活动阶段跨越settled（idle/error）与active（busy/retry）边界时推进，重复的 busy/retry 事件为 no-op，从而避免高频流式更新把会话列表"顶来顶去"；
• 部分内容不触发保留清理："Part-only streaming updates do not schedule retention"，即半截消息的到达不会打断缓存的 5 分钟空闲宽限，长对话期间缓存不会被频繁重建；
• 子 Agent 保持父回合：后台子 Agent 工作时父会话保持"运行中"展示（"an idle parent with a running descendant does not settle"），会话行、标签页与会话切换器通过useSessionTurnActive读取该状态，保证多 Agent 并行时 UI 状态与真实运行一致。

这套机制正是"长对话流畅、CPU 峰值下降"的实现来源：渲染从"整体重算"变为"最小粒度增量更新"。

VS Code 扩展：聊天体验、侧栏与启动可靠性

1.9.2 对 packages/vscode 扩展的改进与 App 层同源，但落地在扩展的 webview 与宿主集成上：

• Chat/Performance：与 App 层相同的实时同步与流式更新重构，减少扩展内的 re-render 抖动，让长对话在编辑器集成环境中保持流畅；
• Sessions/UI：侧栏行为打磨——更干净的间距、更好的截断与 tooltip，并新增可调整大小的会话面板（resizable sessions pane），用户可按需扩展/收窄会话列表，获得更紧致的空间控制；
• Chat/Editor 集成：改进了从资源管理器（Explorer）向聊天插入文件的流程（file-to-chat mention flows），插入更顺滑；
• 启动可靠性：启动阶段将 bridge 与 stream 请求排队，直到 API 就绪（"startup now queues bridge and stream requests until the API is ready"），避免扩展在 OpenCode/OpenChamber 后端尚未就绪时发出无效请求导致竞态；
• Chat 渲染：推理内容（reasoning content）改为通过 markdown 管线渲染，推理过程与结论的展示样式统一、可读性更好。

扩展侧相关的实现可继续查阅 packages/vscode/src/extension.ts、packages/vscode/src/ChatViewProvider.ts 与 packages/vscode/src/AgentManagerPanelProvider.ts。

Models/Providers：自定义 Provider 元数据的加载与缓存改进

1.9.2 优化了自定义 Provider 模型元数据（model metadata）的加载与缓存（感谢 @ZeppLu）。模型元数据来自 OpenCode 侧，通过 HTTP 接口下发，对应服务端路径为GET /api/openchamber/models-metadata（记录于 packages/web/server/lib/opencode/DOCUMENTATION.md）。

结合客户端 packages/ui/src/stores/useConfigStore.ts 中的 stale-while-revalidate 模式可以推断：元数据快照在冷启动时先以持久化的缓存"即时上色"（instant paint），随后在后台刷新为实时数据——即"缓存命中先渲染、后台取新"的策略，既保证模型选择器在冷启动时立即可用，又不让陈旧数据停留超过一次拉取周期。这项改进直接服务于自定义 Provider 场景：用户自行接入的模型元数据不再需要每次冷启动都等待完整网络往返。

Docker/Deployments：容器默认值与部署体验

UID 1000 用户行为

1.9.2 调整了容器默认行为，让隔离空间统一以 UID 1000 运行（感谢 @yulia-ivashko）。从 packages/web/server/lib/spaces/places/docker.test.js 可以看到空间与 gatekeeper 容器的创建参数均携带--user 1000:1000：

docker run ... --user 1000:1000 ...

同时，在 packages/web/server/lib/spaces/DOCUMENTATION.md 中明确记录："a Docker space already runs as uid 1000 by default"，因此空间内执行命令的 argv（execArgv）不再需要额外的用户检查——容器本身就以该 UID 运行。对部署方而言，这意味着空间内文件的所有权、进程身份与宿主 UID 1000 对齐，便于挂载卷与权限规划。

非致命 SSH 密钥生成

容器默认行为中，SSH 密钥生成改为非致命（non-fatal）：密钥生成失败不再阻断容器启动流程，而是降级继续，避免因/etc/ssh或宿主随机数源等环境问题导致空间无法启动。这一调整对受限网络、只读根文件系统等容器环境尤其友好。

容器网络中的 localhost 检测

1.9.2 还改进了容器网络环境下的 localhost 检测。在隔离空间设计中，空间网络对代理（proxy）与 NO_PROXY 有明确约定（见 spaces/DOCUMENTATION.md）：

NO_PROXY / no_proxy = gatekeeper,localhost,127.0.0.1

窗口（window）流量跳过走廊（gatekeeper），空间自身的回环流量同样跳过。1.9.2 对容器网络中的本机地址识别做了修正，避免在 Docker 默认网络下把容器网关或host.docker.internal误判为 localhost，从而保证代理路由与访问控制策略（corridor 的私有地址拒绝规则）在容器部署中行为一致。

Web/PWA：Cloudflare Access 后的 Manifest 修复

1.9.2 修复了 PWA 在Cloudflare Access之后的 manifest 行为（感谢 @arthurfiorette）。PWA manifest 的注册逻辑位于 packages/web/index.html：客户端会动态创建<link rel="manifest">标签，并使用crossOrigin = 'use-credentials'加载 manifest——这样浏览器在获取 manifest 时会携带认证 Cookie，使被 Cloudflare Access 等网关保护的站点也能正常读取动态 manifest。

服务端侧，manifest 由 packages/web/server/lib/opencode/pwa-manifest-routes.js 提供：GET /manifest.webmanifest支持pwa_name/app_name/appName等查询参数覆盖应用名，并动态解析应用名与最近会话快捷方式（recent-session shortcuts）。修复后，位于 Access 之后的 Web 应用能够正确获得 manifest，PWA 安装提示、图标与应用名不再缺失。

升级建议与验证路径

1.9.2 的变更分布在以下源码位置，供读者对照验证：

部署侧建议：进程管理器（systemd/supervisor）直接使用openchamber serve --foreground；需要对外提供服务时显式--host 0.0.0.0；容器场景保持 UID 1000 与--foreground --api-only --host 127.0.0.1的组合，由外部网关做端口暴露与鉴权。整体升级成本低，收益集中在长对话流畅度、并行运行创建速度与部署可控性三方面。

• AI Agent
• 人工智能
• 代码智能体
• 交互助手