OpenClaw 24h 更新快报（2026-11-07）：OpenClaw ID 隧道、更新状态库拷贝、模型输出上限
过去一天，OpenClaw 主干合入了 300 余个 PR，变化集中在三条主线上。第一，OpenClaw ID 的隧道传输、网关中继设备鉴权以及控制台的账号入口与 Access 页面陆续落地，远程接入这条此前缺失的链路基本补齐。第二，更新流程暴露出一个长期被忽略的性能问题：为了读取状态，几乎每次操作都会复制整个状态库，导致 400MB 级别数据库的一次更新写出近 90GiB 磁盘，而本轮多个 PR 从不同角度开始削减这类拷贝。第三，模型侧的默认输出预算被重新定义，未知上下文窗口时不再沿用 8192 token 的保守上限。
这三条线各自独立，但共同指向同一件事：让远程使用、批量更新和长文本输出这三种最容易在真实环境里崩掉的场景，先能在架构上站得住。
身份与远程接入：OpenClaw ID 打通隧道到控制台
PR #192345 是本轮体量最大的一组改动（162 个文件），它一次性引入了隧道传输、面向控制台的 OpenClaw ID 登录，以及网关对中继设备的鉴权。核心问题是：一个已绑定的 claw 必须能被所有者的浏览器通过中继访问，而网关必须依据「设备成员身份」而不是请求头之类的凭据来确认来者身份。默认情况下 gateway.openclawId.enabled 这个 Labs 开关是关闭的，不会产生隧道子进程、入站监听或隧道主体解析器，鉴权路径与主干完全一致；开关打开后，网关才会启动受监督的隧道子进程并接受中继设备接入。
PR #192352 补上了用户侧的界面，同样以 Labs 开关为前提：侧边栏头像变成账号菜单，提供登录、为一个 claw 打开远程访问、保管恢复包、批准其他浏览器以及邀请和管理成员等入口，并附带一个 Access 插件和访问页面。值得注意的是这两个 PR 都被打上了 merge-risk: 🚨 security-boundary 标签，团队在合入前明确要求补充证明材料，说明远程身份链路仍处在需要额外证据的阶段。
安全侧的漏洞也在同一时段被修掉。PR #193990 修复了委派所有者设备的越权路径：此前一台被委派的所有者设备可以在其批准对象被吊销后继续存活，或者重新为自己（乃至其他设备）申请新证书，从而拿回已被收回的能力。修复后吊销一台所有者设备会连带移除它批准过的全部设备，降低设备能力等级也会持续生效，直到恢复包重新提升。该改动只涉及 7 个文件，但直接改写了 addOwnerDevice 的语义，属于典型的低成本高价值修补。
更新链路：从每次全量拷贝到按需读取
本轮最直观的性能问题出在更新与备份流程。PR #194042 记录了根因：在 400MB 的状态库上执行一次更新，会向磁盘写入约 88GiB，而其中 94% 是整库快照拷贝——每次 schema 检查、租约读取甚至单行读取之前，都先把整个数据库复制一份，副本大小约为数据库的 213 倍。修复后更新写盘下降约 28%，总耗时缩短约 3.5 分钟，其中需要停网关的激活阶段从 581 秒降到 402 秒。
与之配套的是 PR #193941，它把更新过程中的恢复守卫检查从「每次都拷贝整个状态库」改为复用已有结果，单次更新因此少了 12 次整库复制，而且守卫不再因为一次拷贝而占住更新的主线程。这两条改动都明确标注为不彻底解决上游问题：即便如此，400MB 数据库的一次更新仍会写出约 62GiB，剩下的调用方还需要继续收敛。
存储介质层面的问题则由 PR #194239 处理。在慢速或冷启动的磁盘上，备份命令和更新的备份发现步骤会因为 4096 条路径探测错过 10 秒期限而直接报 SQLite header probe timed out 并拒绝备份；修复后备份与更新可以在慢盘上正常完成，仍然无法应答的路径会按既有上限有界地拒绝，而不是无限等待。
交互层面，PR #194289 消除了一个恼人的误报：更新进行期间在聊天里执行 /update，确认消息之后紧接着会收到「没有返回答案，请再问一次」，尽管更新实际正在运行。修复后 `/update` 只显示确认、进度与最终结果，不再提示重试，真实失败仍会照常送达请求方。
模型与推理：输出预算与登录链路
PR #193899 修正了一个影响面很广的默认策略：当模型没有已知的输出上限时，OpenClaw 会合成一个 8192 token 的输出预算（自定义供应商向导里更是只有 4096），回复因此在中途被截断。新的策略是以上下文窗口为参照的有界默认值，最高 32768：窗口未知时取 32768，窗口已知时取窗口与 8192 的较小值再被 32768 封顶。这一改动覆盖了 Ollama、OpenRouter、Bedrock、Copilot、DeepInfra、LM Studio 等一批内置与扩展供应商路径，被标记为兼容性风险项，因此属于一次有意的默认预算调整，而非单纯修补。
登录链路方面，PR #191508 解决了「使用 ChatGPT 登录（Beta）」在 8080 端口被占用时必然失败的窘境。原先 SIWC 回调地址固定为 http://localhost:8080/auth/callback，现在每次登录会分配一个变化的回调端口，并在登录提示里显示端口号与对应的 ssh -L 转发命令。代价是常驻的 8080 转发不再通用，每次登录都需要单独转发，文档中对此有明确说明。
PR #193775 修了另一个跨模型切换的坑：一个会话曾保存过 Daybreak Blue 后，只要把模型换成非 OpenAI 模型，每一轮对话都会失败。因为保存的会话权限选择会跨 /new、重置、分叉、子进程派生与模型切换保留，但真正执行时并没有按供应商应用它，导致三个执行点拒绝了任何非 Standard 的选择。修复后非 OpenAI 轮次按 Standard 运行并给出一次性提示，同时保留原有选择以便切回 OpenAI 模型。
研究能力：从插件化到会话内面板
研究子系统在本轮形成完整链条。PR #177232 在会话内加入原生的研究面板，提供报告、来源检视与可见的工作控制，支持取消任务、在结果存疑时原地重试而不必重新提交，并可按引用跳转；面板内容由插件拥有，外部链接限制为不含凭据的 HTTP 端点。它与 PR #173964 引入的可移植、有证据支撑的研究层配套——后者对规划、调用、检索、保留的源文本与报告生成都设了上限，会核验引用并主动报告未能解决的信息缺口，同时转义不可信的来源文本。
此外还有若干子项补齐研究链路的生命周期：保留已授权的浏览器研究状态、让研究任务在持久化唤醒后恢复、显式恢复被保留的作业，以及对外暴露已授权的作业视图。
运行时稳定性与渠道细节
进程与内存方面有两处值得注意。PR #166488 修复了会话持有的 stdio MCP 服务器填满网关共享的 256 个子进程启动额度后，命令无法启动的问题：现在主机与 worker 合计允许 512 个待处理/保留子进程，其中 MCP 子进程最多 448 个，为普通命令保留 64 个余量，容量报错也会指明应当关闭闲置的 MCP 会话还是运行中的进程。PR #194099 则避免了大型 transcript 索引修复时的 worker OOM：此前该路径会先把所有解码后的 FTS 文本装进数组，绕过既有的传输字节预算与背压机制，大体量脏投影足以在流式传输开始前就以 ERR_WORKER_OUT_OF_MEMORY 杀掉 512MiB 的 worker。
渠道侧，PR #193836 修复了 Mattermost 上带链接预览卡片的人消息被当作系统消息丢弃、且在恢复线程历史时被遗漏的问题，判断依据从消息类型改为系统事件与人员附件的区分；PR #194059 让 cron 命令在 --script、--trigger-script 或 scratch --file 指向无写入端的 FIFO 时快速失败，而不是无限等待。
控制台体验
控制台侧的性能优化密度很高，但多数指向同一个方向：减少不必要的等待与重复计算。PR #194263 让已登录的预热重载可以直接渲染缓存的 Subagents 行，不再等待实时活动观察模块加载；此外还有让 Cron 页面不再加载 transcript 运行时、会话切换时不再重建未变化的侧边栏投影、避免大体积聊天中多余的视口读取等改动，主题色回读、样式匹配与样式表失效也都被逐一处理。整体思路是把「先算再显示」的同步路径换成「先显示缓存再补齐」的渐进路径。
这批更新没有引入颠覆性变化，却把几个此前在真实规模下会暴露的问题逐个收口：远程接入有了完整入口和更严的授权模型，更新流程开始停止在读取时反复搬运整个状态库，模型输出上限也从保守估计回到了能用的量级。
评论