OpenClaw 24h 更新快报（2026-06-27）：Telegram 投递修复、内存嵌入裁剪、Feishu 二维码显示
过去24小时，OpenClaw 合并了多个涉及核心渠道稳定性和运行时性能的改动。其中 Telegram 入站投递机制迎来一次重要修复，解决了长耗时对话场景下的重复投递问题；内存模块新增嵌入向量维度裁剪，避免大模型输出不必要的内存开销；Feishu 渠道的终端二维码登录也得到显示优化。以下是详细整理。
渠道投递稳定性
PR #96962 修复了 Telegram spooled claim 在长耗时对话中过期被重复领取的问题。当 Telegram 消息触发模型推理后，入站事件会被放入共享队列并标记为 claimed 状态；若模型处理时间超过 stale-claim 恢复窗口，另一个轮询循环可能将该 claim 判定为过期并重新分发，导致消息被重复投递或卡死。
此次修改在 ingress-queue 层新增了 token 保护的 claim 刷新机制，并在 Telegram polling-session 处理期间主动刷新活跃与延迟 claim 的时间戳，使长耗时对话的入站事件在模型运行期间始终保持有效。修复后，即使一轮 Telegram 对话耗时超过五分钟，ingress 行也会持续刷新而不进入 stale 回收。Telegram 用户若遇到消息卡死或重复推送的问题，升级至此版本应可解决。
内存与嵌入性能
PR #96952 对本地内存嵌入的向量拷贝逻辑做了优化。此前标准化向量时使用 Array.from(vector).slice(0, outputDimensionality)，会先完整读取并拷贝原始向量，再丢弃尾部维度，对于高维嵌入（如 1024 维）而言徒增一次完整拷贝成本。
修改后使用 bounded 向量拷贝，仅在实际需要的维度范围内进行读取和拷贝，大幅降低了高维嵌入场景下的内存读写压力。对于配置了 outputDimensionality 参数的用户收益最明显；默认输出完整维度的语义不受影响。
Google Meet 启动配置
PR #96908 统一了 Google Meet 插件中 Chrome 与 chrome-node 的启动参数来源，修正了 macOS 上 chrome-node 启动时 Meet URL 和 Chrome profile 参数的顺序问题。以往本地 Chrome 用户和 chrome-node 用户各自使用不同的 profile 来源，且参数顺序不一致，可能导致 Meet 标签页恢复失败或音频配置不生效。修改后两类用户均可继续使用原有配置，Meet 的 transcribe 和 agent talk-back 路径不再因此失效。
Feishu 终端二维码显示
PR #97087 修复了执行 openclaw channels login --channel feishu 时终端二维码过宽无法扫描的问题。Feishu 注册 URL 较长，调用默认全尺寸 QR 渲染器时二维码宽度约为终端一半，在普通窗口中会发生换行，导致无法扫码。修复方案参照 WhatsApp 渠道已有的做法，改用紧凑型半块 QR 渲染模式，视觉尺寸缩小约一半，显示行数从75行降至38行，最大可见列宽从150列缩至75列，扫码体验恢复正常。
本次更新整体以稳定性修复为主线，渠道投递和会话状态管理是本周期重点关注方向。
评论