OpenChamber 1.3.8 版本解析Intel Mac 支持与消息队列模式【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址: https://gitcode.com/gh_mirrors/op/openchamber本篇技术指南围绕 OpenChamber 1.3.8 版本2025-12-29 发布展开聚焦该版本的两大核心能力为桌面应用新增的Intel Mac (x86_64) 架构支持以及全新引入的队列消息模式queued message mode——后者包含消息 chips、批处理、空闲自动发送与附件支持并在设置中提供了跨运行时持久化的开关。此外本文还覆盖该版本在 dev server HMR、Agents/Commands 管理与滚动位置持久化方面的改进。读完本文你将理解 OpenChamber 队列消息的完整工作链路UI 队列 → 服务器持有 → 空闲自动派发、Intel Mac 构建的架构解析规则以及这些特性在仓库源码中的具体实现位置。版本概览版本 1.3.8 的改动同时作用于桌面应用App与 VS Code 扩展两大客户端核心变更集中在三点架构支持、消息交互模式与工程化改进。领域变更类型内容AppNewIntel Mac (x86_64) 桌面应用支持由社区贡献者 rothnic 提供AppNew队列消息模式chips、批处理、空闲自动发送含附件AppNewOpenChamber 设置中的队列模式开关聊天部分跨运行时持久化AppImprovements构建工作流为 Apple Silicon (arm64) 与 Intel (x86_64) Mac 分别产出构建AppImprovements改进 dev server HMR复用健康的 OpenCode 进程以避免僵尸实例AppImprovements重构 Agents/Commands 管理支持配置 project/user 作用域AppFixes修复跨会话切换时活动对话轮次的滚动位置持久化VS CodeNew队列消息模式chips、批处理、空闲自动发送含附件VS CodeNew设置中的队列模式开关聊天部分VS CodeImprovements重构 Agents/Commands 管理支持配置 project/user 作用域VS CodeFixes滚动位置持久化修复在仓库中该版本的发布说明源文件位于 changelog/1.3.8.md其 front matter 记录了version: 1.3.8、date: 2025-12-29与标题 Intel Mac support and message queuing。根据 changelog/README.md 的说明发布时oc-dev create-release会将此类源文件渲染为 VS Code 扩展的 CHANGELOG 与站点的版本索引因此该文件即权威的版本变更记录。Intel Mac 支持x86_64 与 arm64 双架构构建在 1.3.8 之前桌面应用主要面向 Apple Silicon 用户。该版本通过社区贡献thanks to rothnic为 Intel Macx86_64 架构补齐了完整的构建与分发链路。架构解析规则桌面端打包脚本通过 packages/electron/scripts/target-architecture.mjs 统一解析目标架构。核心逻辑如下支持两种正式架构x64与arm64每种架构分别映射到 Node.js、electron-builder 与 OpenCode CLI 三者的对应取值提供架构别名归一化amd64、x86_64均归一为x64aarch64归一为arm64目标架构的指定优先级为OPENCHAMBER_TARGET_ARCH环境变量 ELECTRON_BUILDER_ARCH electron-builder 命令行参数--x64、--arm64、--arch均未指定时回退到宿主机架构若多种来源同时指定且不一致会直接报错拒绝构建Linux 平台强制原生构建目标架构与宿主机不一致时抛出 Linux AppImages must be built natively 错误。macOS 的构建产物为dmg与zipWindows 为 NSIS 安装程序Linux 为 AppImage详见 packages/electron/README.md。macOS 的更新清单由 packages/electron/scripts/finalize-latest-yml.mjs 生成Intel Mac 的更新通道通过latest-mac.yml对应x86_64-apple-darwin独立维护确保 x64 与 arm64 用户各自解析到架构匹配的安装包不会互相覆盖。对开发者的意义从源码结构看这一改进让同一套桌面代码库可以面向两类 Mac 硬件产出分发物packages/electron下的打包管线package.mjs在构建时依据上述规则选定架构并将同一目标同步用于内嵌的 OpenCode CLI、原生模块重编译与 electron-builder。若你需要在 Intel Mac 上构建只需保证宿主机为 x64 或显式设置OPENCHAMBER_TARGET_ARCHx64即可。队列消息模式核心新特性队列消息模式是本版本最实质性的功能变更。它解决了一个真实的交互痛点当会话处于 busy 状态模型正在生成回复时用户继续输入的新消息不再被丢弃或强制抢占而是进入一个可见、可编辑、可排序的消息队列在会话空闲后自动发送。为什么需要消息队列在 OpenCode 的协议中向一个正在运行的会话发送提示行为是转向steer当前回合而非开启下一个回合——这一点在 packages/web/server/lib/message-queue/DOCUMENTATION.md 中有明确说明prompt_async进入一个正在运行的回合会转向到该回合内而不是启动下一回合。因此用户在多轮对话中趁模型还在思考时把接下来的指令都打出来的诉求需要一种更安全的中间态先把消息排队等回合真正结束会话回到 idle后再逐条发出。设置入口与行为开关队列模式开关位于 OpenChamber 设置的聊天chat部分。在 packages/ui/src/components/sections/openchamber/OpenChamberVisualSettings.tsx 中该设置以followUpBehavior单选组的形式呈现提供两个选项steer会话忙时输入的新消息直接转向当前回合OpenCode 协议的默认投递行为queue默认新消息进入队列会话空闲后自动发送。FollowUpBehavior类型定义于 packages/ui/src/stores/messageQueueStore.ts默认值为queue。设置通过setFollowUpBehavior动作写入 store并同步调用updateDesktopSettings持久化因此该偏好跨运行时web、桌面、移动端保持一致。该 store 还实现了历史持久化迁移旧版本持久化过的immediate值在 busy 会话上行为与 steer 完全相同会被归一为steer旧版queueModeEnabled布尔值也会被映射为对应的新枚举值。消息 chips可视化的队列交互队列中的每条消息都会以chip形式渲染在输入区上方相关组件为 packages/ui/src/components/chat/QueuedMessageChips.tsx。每个 chip 提供以下操作拖拽排序通过 dnd-kit 实现桌面端拖拽距离 8px 触发、触屏长按 200ms 触发reorderQueue会同步到服务器PUT .../order要求提交完整的 itemIds 排列编辑popToInput将完整消息含附件与上下文从队列取回输入框修改后可重新入队单独发送onSendMessage立即派发该条消息删除removeFromQueue本地移除并同步服务器。chips 面板支持折叠/展开折叠状态是跨会话共享的 UI 偏好不会随会话切换重置每条 chip 展示消息首行预览有附件时额外显示附件数量徽标。队列消息同样进入输入历史createInputHistorySubmission确保可追溯。空闲自动发送与重试机制队列的自动派发逻辑集中在 packages/ui/src/hooks/useQueuedMessageAutoSend.ts其核心是空闲门控仅当会话状态为idle时才会派发队列头消息会话状态判定同时参考/session/status与最后一条消息若最后一条是尚未完成的 assistant 消息则视为 busy状态映射只列出 busy 会话遗漏的 busy 事件不能漏过用户刚刚停止abort后存在 2 秒的冷却窗口RECENT_ABORT_WINDOW_MS 2000避免停止后立即被下一条提示顶入发送失败按指数退避重试基础延迟 2 秒每次失败翻倍上限 60 秒getQueuedAutoSendRetryDelayMs同一时间同一会话只允许一条消息在途inFlightSessionsRef store 中的sendingIds避免重复投递。派发时使用入队时刻捕获的发送配置sendConfigprovider、model、agent、variant而不是派发时的实时配置确保所见即所得若旧队列未捕获配置则回退到当前会话配置并在配置未就绪时按基础延迟重试。附件的队列化附件与消息正文一并入队。QueuedMessage的attachments字段完整保留了文件元数据id、文件名、MIME 类型、大小、来源服务器持有其 dataUrl 载荷编辑取回时popToInput会把附件重新挂回输入区的已附加文件列表。队列的容量边界messageQueueStore.ts 定义了明确的容量约束每个会话最多20 条排队消息超出后从队尾裁掉最旧的最多50 个队列目标runtime directory session 三元组超出时按最早创建时间淘汰绝不淘汰有消息在途的队列服务器端单会话内容总量上限200k 字符附件载荷受路由家族 50MB JSON 限制见 message-queue/DOCUMENTATION.md。队列的底层架构服务器持有 vs VS Code 本地队列模式在两个运行时采用了不同的持有策略这一点在 messageQueueStore.ts 的isServerOwnedMessageQueue中有清晰注释web、桌面、移动端都连接一个 OpenChamber 服务器队列由服务器权威持有无论 UI 是否打开都会继续投递关闭标签页、锁屏、断线都不会丢弃消息VS Code没有自己的服务器因此扩展 UI 维护本地队列并使用前台自动发送 hook 驱动派发所有 webview 关闭时排队消息不会投递。服务器端交付循环服务器端队列运行时位于 packages/web/server/lib/message-queue/runtime.js其设计文档为 DOCUMENTATION.md交付循环分六步start()订阅全局事件 hub 并加载持久化文件每次 hub 重连后重新武装所有有排队的会话监听session.statusidle启动 500ms 的静默定时器合并回合边界的突发busy/retry取消message.updated收到已完成的 assistant 回复同样武装避免错过 idle 事件导致队列搁浅tick(sessionId)在队列为空、有消息在途或会话被 hold 时直接退出并处理 2 秒 abort 后冷却与头部消息的退避重试发送前向 OpenCode 重新校验空闲状态GET /session/status不得列为 busy/retry且尾部消息不得是未完成的 assistant 回复本服务器启动前产生的未完成回复不阻塞其运行已随旧进程消亡不会再有完成时刻头部消息标记在途并广播随后按规则投递以/开头且匹配 OpenCode/command列表含 skills且未携带捕获上下文的走POST /session/:id/command否则走POST /session/:id/prompt_async部件顺序与 UI 发送一致文本、文件、捕获上下文、skill 调用、待定的 project knowledge、agent mention成功后移除该条并广播失败则保留并退避重试下一条在下一个 busy→idle 周期后发出。持久化与修订号队列持久化于data-dir/message-queue.jsonOPENCHAMBER_DATA_DIR或~/.config/openchamber格式为{ version, revision, sessions }通过临时文件 重命名原子写入。关键设计损坏文件不会被当作空队列吞掉而是移存为message-queue.json.corrupt-timestamp后再以空队列启动避免后续写入覆盖用户数据revision是全局单调递增计数器客户端据此拒绝陈旧快照在途消息sendingId、退避、abort 时间戳与 holds 刻意仅存内存——重启时不存在在途发送持久化的 sending 标志反而会让消息永久搁浅。Holds 与多端同步UI 驱动的自动审查auto-review会通过PUT .../hold { held: true, ttlMs? }让服务器暂停某会话的队列投递默认 5 分钟、上限 10 分钟自动过期UI 每两分钟续期防止队列消息与自动审查迭代互相穿插。每次变更都会向所有已连接客户端SSE 与 WS广播openchamber:message-queue.updated事件多个设备共享同一队列视图。REST 路由一览队列暴露于/api/message-queue路由族在 packages/web/server/lib/opencode/feature-routes-runtime.js 中于通用 OpenCode 代理之前注册路由用途GET /api/message-queue全量快照{ revision, sessions[] }POST .../sessions/:id/items追加消息并武装派发DELETE .../sessions/:id/items/:itemId移除在途时返回 409POST .../sessions/:id/items/:itemId/take取出完整消息含载荷POST .../sessions/:id/take按序取出所有非在途消息PUT .../sessions/:id/order提交完整排列的{ itemIds }DELETE .../sessions/:id清空队列在途消息保留PUT .../sessions/:id/hold{ held, ttlMs? }暂停/恢复投递工程化改进与问题修复dev server HMR复用健康 OpenCode 进程1.3.8 改进了开发模式的热更新体验HMR 重载时不再盲目新建 OpenCode 进程而是复用仍在健康运行的既有进程从而避免产生僵尸实例。这一改进服务于本地开发链路oc-dev等脚本见 scripts对日常使用者的直观收益是开发环境更稳定、进程资源不再随每次热更新累积泄漏。Agents/Commands 管理重构Agents/Commands 管理被重构为支持project 作用域与 user 作用域的配置能力。从源码结构看该重构为不同层级的 Agent 与命令配置提供了更清晰的归属边界项目级配置随仓库分发、用户级配置全局生效为后续的配置管理与同步机制打下了基础。滚动位置持久化修复此前切换会话后当前对话的滚动位置会丢失该版本修复了活动对话轮次的滚动位置在会话切换间的持久化。相关实现位于 packages/ui/src/hooks/useChatTimelineScroll.ts会话切换时restoreSnapshot恢复视口状态列表节点替换时通过 retireScrollContent.ts 安全退役旧节点内容避免 Chromium 保留已卸载 DOM 导致的内存/滚动问题相关说明见 packages/ui/src/sync/DOCUMENTATION.md。同时滚动到顶部的悬浮按钮pill、键盘跟随滑动keyboardFollowGlide与streamingAutoFollowEnabled偏好共同构成了完整的滚动行为体系。总结与验证路径OpenChamber 1.3.8 以两个里程碑式变更巩固了日常使用体验Intel Mac 用户首次获得官方 x86_64 构建与独立更新通道队列消息模式则从根本上改善了模型忙碌时继续输入的工作流——可见的 chips、可排序可编辑的队列、空闲自动发送与断线不丢消息的服务器持有设计让它同时适用于桌面、Web、移动与 VS Code 场景。如需进一步验证或深入阅读可在仓库中按以下路径追踪版本说明源文件changelog/1.3.8.md队列 UI store 与契约packages/ui/src/stores/messageQueueStore.ts队列自动发送 hookpackages/ui/src/hooks/useQueuedMessageAutoSend.ts队列 chips 组件packages/ui/src/components/chat/QueuedMessageChips.tsx服务器端队列运行时与设计文档packages/web/server/lib/message-queue/runtime.js、packages/web/server/lib/message-queue/DOCUMENTATION.md队列行为测试packages/web/server/lib/message-queue/runtime.test.js、packages/ui/src/hooks/useQueuedMessageAutoSend.test.ts架构解析与打包packages/electron/scripts/target-architecture.mjs、packages/electron/scripts/finalize-latest-yml.mjs设置面板中的队列开关packages/ui/src/components/sections/openchamber/OpenChamberVisualSettings.tsx。【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址: https://gitcode.com/gh_mirrors/op/openchamber创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
