330 次合并与关闭，三个仍开着的 P0

2026 年 10 月 26 日 23 点 50 分（UTC），两份自动生成的生态日报同时落盘。OpenClaw 那份给出一份相当漂亮的读数：过去 24 小时 Issue 更新 500 条（新开与活跃 397，关闭 103），PR 更新 500 条（合并或关闭 330，待合并 170）；隔壁 Hermes Agent 的读数也不逊色：Issue 更新 445 条，PR 更新 500 条。单日数百条的活动量，放在任何一个开源项目里都算得上热火朝天。

但同一份日报的故障区里躺着另一个世界。三个 P0 级问题在快照时点全部挂着「无修复 PR 在途」的标记：网关被大型插件拖住导致事件循环阻塞数分钟的 #160959，内存以每小时四到五 GB 速度流失的 #159662，以及 Windows 上重启与更新极不可靠的 #170956。而当天被合并进主干的，是编号从 d625 排到 d640 的测试瘦身批次和一串性能优化——日报自己的评估原话是「无用户可见变化的内部改进」。

我写作时把这几十条关键 issue 和 PR 逐条调出来复核了一遍，发现的图景比日报的粗颗粒更细，也比「没人管 P0」这种结论更微妙：三个 P0 的 issue 本体确实都还开着，但它们周边的子症状修复，还有两个安全边界修复 PR，在快照之后陆续落了地——最早的一条距快照不到两小时，最晚的一条隔了十五个多小时。fsPolicy 传导修复在 27 日 3 点 55 分（UTC）合并，cron 运行时绑定修复在当天 1 点 23 分合并，updater 运行时保留中止修复在 15 点 22 分合并——全部发生在那份「无修复在途」的日报生成之后。

这样的错位不能当成开源社区的日常噪音轻轻放过。因为这一天的读数里藏着一个所有智能体用户都躲不开的问题：当你决定把一个框架放进生产环境，你读到的每一份报告都是快照，而快照的每一个字段都有不同的腐烂速度。活跃度数字腐烂得最快，故障区的状态断言次之，只有「用户在痛什么」这条线索的半衰期最长。要判断哪部分值得当成决策依据，就得把这三种腐烂速度不同的信息分开摆放。

所以今天真正值得写的不是「智能体生态很活跃」这种废话，而是那条缝：合并清单与故障清单之间的错位。吞吐量巨大的机器在运转，但它加工的方向和用户最痛的地方对不上；而日报这种快照式读数，还会让读者比现实慢半拍。两条生态线这一天的样本摆在一起，错位发生在哪、为什么发生、想在这两个生态里做生产部署的人该怎么读这些数字，答案都藏在清单的缝里。

三个高声量的 P0，和一份不对齐的合并清单

先说最响的那一个。#160959 是 9 月 29 日开立的 issue，报告的是 2026.9.6 版本引入的回归：当网关去捕获一个外部大型插件时，事件循环被同步任务拖住，整个网关阻塞数分钟。日报快照时它的标签里挂着「无新修复 PR」，评论数 57。我复核时 issue 仍然开着，评论还是 57 条——顺着引用关系往下挖，能看到两个仍然打开的关联 PR：一个做的是启动性能优化（针对安装了大依赖插件的场景），另一个修的是插件启动之后网关在十几秒内拒绝新连接的子症状。值得留意的是时序：这两个 PR 分别开立于 9 月 21 日和 9 月 25 日，都早于 issue 本身，开立后一个多月再无更新——缓解的通道早就铺好了，只是一直没人往前推。用户在评论区表达不满的点其实很精确：不是没人动，而是动的地方不是最痛的地方。

第二个是 #159662，9 月 27 日开立，26 条评论。报告的是一个无界内存泄漏：模型目录的 worker 进程在冷启动下就能复现每小时四到五 GB 的增长，且与具体 Provider 无关。这个数字的可怕之处在于它直接判了长会话部署的死刑——按这个速率，任何一台 16 GB 内存的机器跑不满一个工作日。日报的判断是「无直接关联修复 PR」，但复核的结果更有意思：这个 issue 名下挂着四个关联 PR，其中三个已经合并——一个阻止目录刷新时重复重建已知的 Provider 归属，一个修复 cron 初始化期间 thinking 目录注水导致的超时，一个阻止目录刷新重复持有原生插件图；第四个（修 CPU 攀升的）被关闭未合并。把这四个动作连起来读，维护者的策略是清晰的：把泄漏的几个具体源头逐个堵上，而不是赌一个一次性修好主病灶的大补丁。只是到现在为止，泄露本体没有被消除，issue 开着，用户机器上的内存曲线也没有变平。

第三个 #170956 是 10 月 13 日开立的 Windows 三重叠加问题：启动慢、插件关停不干净、计划任务权限报错，叠在一起让重启和更新变得极不可靠，被标了发布阻断标签。复核时它的主 issue 开着，21 条评论；但名下四个子症状修复全部已合并——权限被拒时的提权指引、荷兰语环境下的权限拒绝识别、全语言环境的权限拒绝识别、以及 Doctor 恢复之后对网关就绪状态的校验。四条分支都通了，主干还堵着：Windows 用户真正想要的「一次升级一次成功」，依然没有着落。

这三个还只是冰山露出水面的部分。把当天的故障清单往下翻，能看到 P0 和 P1 层级的完整家族谱系：崩溃恢复之后 agent 永久卡在不可用状态的 #166634（被标记为主干上无法复现）、更新后置健康检查假阴性导致网关停摆的 #139082（等用户提供更多信息）、基线常驻内存从 300 MB 涨到 1.9 GB 的 #181432（维护者自己标注可能与 #159662 相关）、Windows 更新修复流程报状态租约丢失的 #182476、升级流程卡在查询一个已停止的网关进程的 #183786、以及一天内出现至少 28 次完整性准入错误的 #177656。这份清单的形状比任何单一条目都更有信息量：内存问题在两条线上并行发酵（worker 泄漏与基线增长），Windows 问题在三条线上并行发酵（升级、修复、启动），存储问题在两条线上并行发酵（WAL 膨胀与事务挂起）。每一个方向都不是孤立故障，是一个子系统在整体呻吟。

对生产部署者来说，这份家族谱系的具体含义值得翻译一下。事件循环阻塞意味着你的自动化管线会在某个无法预测的时刻整体冻结几分钟——如果那时正有定时任务、消息桥接或者长会话在跑，全部排队。内存泄漏意味着容量规划失效：你以为机器还能撑一周，实际余量按小时烧。Windows 升级链不可靠意味着运维窗口不可预测：升级动作本身成了最大的停机风险源。这三类问题没有一个是「体验瑕疵」，全部是部署决策的直接否决项。这也是为什么当天的合并清单会让人着急——不是那些 perf 和测试批次不该做，而是读着清单的人，机器正在按 GB 烧内存。

最微妙的是 #143524。这个 9 月 9 日开立、139 条评论的 P0 报告的是 SQLite 的 WAL 文件在几天内膨胀到 1.4 到 2.8 GB、直接导致网关无法启动——存储层的硬阻断。它在 10 月 26 日 14 点 02 分（UTC）被关闭，和同根源的 #172091（跨线程准入等待未应答导致事务永久挂起、阻断检查点）在同一分钟被关闭。但两个 issue 的标签里都还挂着「无新修复 PR」和「待维护者复核」。关闭不是修复落地，是清理动作。社区对「关闭即解决」的疑虑不是情绪化表达，标签系统自己就把这个状态说清楚了。

这里其实藏着一个容易被忽略的正面样本。139 条评论的爆炸性 issue 被关闭，通常是一个社区情绪最紧张的时刻，而这次关闭之所以没有演变成信任事故，恰恰是因为自动化标签系统在关闭动作上留下了诚实的痕迹——「没有新的修复 PR」这个事实被机器钉在了元数据里，任何人都能看见。对比一下另一种做法：关闭 issue、留下一句「已在新版本中修复」的空泛回复、不留任何可验证的指向——短期看风平浪静，长期看每一次都会积累成下一次爆发的燃料。治理自动化工具的真正价值不在清理效率，在于它把维护者没办法撒谎这件事变成了默认设置。一个每天要处理几百个 issue 的项目，人和人之间的口头承诺早就不可扩展了，可扩展的是机器打的标签——前提是标签诚实。

把上面四条线放回当天的合并清单里看，错位就非常具体了：那一天被合并的，是测试瘦身批次（系统性移除低价值重复测试、保留边界行为覆盖、零生产代码变更）和一组性能优化（GitHub 轮询复用未变更响应、会话重载共享常驻字符串、cron 搜索文本复用）。这些工作本身没有一项是错的——测试瘦身是还质量债，性能优化是降运行开销，都是正经工程。问题在于优先级的构图：用户的火焰烧在存储层、内存和 Windows 升级链上，而合并清单上最密集的产物是测试和剖析。维护者用自己的节奏在还自己认定的债。吞吐是真实的，方向是错位的。

活跃度读数不等于健康度：两条生态线的结构对比

把同一天的 Hermes Agent 摆在旁边，对比会更有意思。Hermes 的 392 个待合并 PR 这个数字乍看吓人——接近 400 个变更在排队，任何一个都可能带着回归进主干。但拆开结构看，这更像一次社区驱动的修复洪峰：终端工具的安全加固、vault 认证链路修补、上下文压缩架构提案、插件目录扩充，方向分散但供给充足。

两张表的读法完全不同。OpenClaw 是「维护者主导的质量工程」：吞吐第一，方向由核心维护者的优先级决定，产出密集但对齐度存疑。Hermes 是「社区驱动的修复洪峰」：积压大，但对回归的响应速度肉眼可见——Linux 桌面透明度问题（#143426）从报告到确认关闭非常快，12 个赞是当天用户反应最正面的一条；统一网关合并后的回归问题有一个专门的追踪帖（#143547，我复核时已经涨到 25 条评论）在持续汇聚桌面会话、cron、Windows、profile 多个面的问题，是全网关回归的收敛点。而单日合并或关闭的 PR 只有 108 个，和 OpenClaw 的 330 差着三倍——供给洪峰与消化速度之间的落差，就是那 392 个待合并的由来。

这个追踪帖值得展开看一眼，因为它记录的正是架构大迁移的典型代价。Hermes 前不久把多路会话统一进了单一网关架构，随后回归群就开始显形：远程后端的桌面会话无法本地恢复，会话恢复接口返回找不到目标（#139818）；本地看板的通知与唤醒动作永远到不了会话队列，因为本地适配器缺一个网关运行器的挂载（#143268）；共享主 profile 上的所有窗口级请求集体超时（#142849）；更麻烦的是跨 bot 串扰——多路复用的 secondary profile 把流式进度经 primary bot 投递出去，一条消息走错了门（#143364），这一条被直接标了安全相关。再加上 Linux 桌面二次启动污染沙箱回退标记、把浏览器拖进渲染器崩溃循环的 #131055，和 macOS 网关反复以退出码 75 结束、存活探针一直失败的 #137838——六个面的问题指向同一个根源：统一网关的抽象还没把所有旧路径的假设都接住。日报里那句「合并后进入密集回归修复期」，落到清单上就是这六条。

最后那一行值得单独说。按日报口径，两个生态「新开与活跃」的 issue 都接近关闭数的四倍——积压在同一个方向上走。这个数字的机制值得拆开：智能体框架的用户已经在做生产部署，生产部署者的 issue 有两个特点，一是报告质量极高（源码级复现、对照实验、版本定位精确），供给端涌入选题的速度天然快；二是消化端的门槛整体偏硬——多数 issue 要「问题在主干上消失」才算闭环，虽然也有 #143524 那样标签未清就关闭的个案。报告涌得快、消得慢、清理动作又混在关闭里，三个因素叠加，积压走高是这一阶段的写照，而不是哪家管理不善。靠日常清扫追不上，Hermes 侧已经在探索机制化的解法：风险标签体系、定期 needs-decision 裁决、sweeper 自动化；OpenClaw 侧也有 clawsweeper 在跑。但机制能管住标签和分类，管不住修复排期——排期是维护者注意力的函数，而注意力是所有资源里最不能并发的那一种。这是两个生态共同的债，是不是常数，要看两周后这个比值往哪走。

Hermes 的结构性软肋也在这一天露了出来。#135487 是个 P1：重启安全的 cron worker 在认领任务执行时遇到数据库锁就直接退出，任务丢失，且没有任何重试逻辑。这个问题的性质比崩溃恶劣——崩溃用户能看见，静默的任务丢失用户看见的时候已经是后果了。定时任务在个人智能体的使用场景里往往是自动化管线的骨架，骨架上的数据可靠性缺陷，比界面上的任何回归都伤。同一天，外部贡献者无法通过 API 开 PR 的 #131859（被标记为上游原因阻塞）已经积累到 52 条评论、持续三周；OpenClaw 那边也有对应的样本——一个 7 月开立的社区 PR（#101441）挂了近四个月，仍没有等到维护者的明确反馈，表格里那句「搁置近 4 个月」说的就是它。修复洪峰的前提是贡献通道畅通，通道自己堵住了，洪峰会先从上游变细。

还有一个所有读日报的人都该记住的发现：快照有半衰期。那份日报生成于 26 日 23 点 50 分，我复核在十几个小时之后，中间隔着的正是变化最快的时间窗——fsPolicy 和 cron 绑定两个安全相关修复在这个窗口里合并，updater 保留中止修复也在这个窗口里合并，追踪帖涨了 2 条评论，Windows P0 涨了 1 条。如果照抄日报的「无修复在途」写一篇分析，写出来的每一个字在发布那一刻就已经过期。这不是日报工具的缺陷——快照天然如此——而是读者的功课：任何「无修复」类的否定性断言，都值得花十分钟去源头逐条复核，因为快照与现况的缝隙里，可能正好躺着你要的答案。

Token 账单从抱怨单变成架构提案

如果说清单的错位是节奏问题，那两个生态真正同频的地方，是 token 成本。这一天里，OpenClaw 侧有三个 issue 共同构成一份扎实的成本账单：#67419 从 4 月开立到现在超过六个月，指出 bootstrap 文件在每一轮对话都被重新注入，白白吃掉百分之二十到三十的上下文预算；#143017 的报告者拿出了更狠的证据——prompt 缓存的前缀被五种不同的方式反复改写，按其自述口径累计造成约两千一百三十万 cache-write token 的浪费；#146902 则指出同一个会话里工具集漂移，缓存前缀说破就破。三个问题指向同一个命门：上下文前缀的稳定性。缓存的折扣价建立在「同样的开头」之上，任何一处无序变更——注入顺序变了、工具列表变了、系统提示的拼接方式变了——都会把这一轮的折扣价打回全价。

Hermes 侧给出的不是抱怨，是两份架构级响应。其一是 #133625 提出的压缩热交接机制：提供关闭、开启、自动三档，让压缩摘要在主模型的缓存提示上生成，目标是把压缩之后第一个请求的延迟和成本都压下来。其二是 #138273：在提交选择之前就拒绝低于 64k token 上下文的模型，防止压缩逻辑反复选中装不下的小上下文模型、陷入死循环。我复核时这两个 PR 都还在评审队列里，未合并。加上一份关于文档链基底的 RFC，上下文压缩与溯源基本锁定了下一版本的重点方向。

为什么这两份 PR 的设计思路值得细看？因为它们各自卡住了成本失控的一端。热交接卡的是「压缩发生的那一刻」：长会话一旦触发上下文压缩，紧接着的请求面对的是一段刚刚拼好的新前缀，缓存完全失效，这一轮要按全价重新计费——热交接的做法是让摘要在主模型的缓存提示上生成，把新旧前缀的接缝做得平滑，压缩税从「一次性全款」变成「小额过路费」。拒绝机制卡的是「压缩反复发生的那一刻」：如果一个模型装不下压缩后的上下文，下一轮又会触发压缩，如此循环，每一圈都在烧钱——提前拒绝装不下的选择，等于在死循环的入口设了闸。两个 PR 一个管压缩的出口，一个管压缩的入口，合起来才是完整的成本防线，这也解释了为什么社区对这两个尚未合并的 PR 保持着持续的注视。

这个信号不止属于这两个项目，两条清单之外的同一天，整个工具带都在报警——下面的数字来自同批雷达日报的编码 CLI 横评与趋势榜部分（同样生成于 10 月 26 日 23 点 50 分 UTC）。七款主流编码 CLI 里有四款爆发了计费类问题：一款在零请求状态下耗尽了五小时配额，一款在剩余配额高达八成多的情况下继续收到限流，一款免费额度的误判多到官方开了汇总帖，还有一款空回合照常计费。子代理的上下文膨胀则在三个工具里被独立报告——一个单条指令注入约 12k token，一个单轮基线约 36.6k，一个从 42k 涨到 105k。这三处样本各自量纲不同，但都指向同一个方向：多智能体架构的实际 token 成本显著高于预期，两到三倍是本文据此做出的推断量级。GitHub 趋势榜上，砍掉六成五 token 的「原始人说话法」、进模型前压缩工具输出的 headroom、跨会话持久记忆的 claude-mem，三件套已经组成了一个独立品类。横向佐证与两条生态线的内部证据指向同一个方向：token 成本不是哪一家的 bug，它是这一代智能体框架共同的下一张故障清单，也可能成为下一张合并清单。

把五条线索连起来读，方向已经清楚：用户已经从「报 bug」升级到「拿账单说话」，需求方在倒逼供给侧把 token 当成架构议题，而不是计费附录。智能体框架的竞争力坐标正在换轴——从「能做什么」转向「每 token 产出什么」。对重度用户来说，前者决定上限，后者决定能不能活到上限。

值得一提的是，这条主线上还叠着一层治理维度的故事。当同类改进的 PR 开始在队列里堆积时，Hermes 社区的反应不是催合并，而是要求先定接口：两份分别积累了 31 条和 28 条评论的 RFC 提出，观察者钩子、双工语音这类方向已经有四五个竞争 PR 在排队，逐个合并只会让后到的推倒重来，正确的做法是先裁决出统一的抽象基类和编排器，再让各家的实现落座。这套思路和项目规则里的足迹阶梯相互呼应——先声明你要动哪一层，再谈怎么动。成本问题把治理问题带了出来，因为每一处 token 开销的优化都动上下文构造的核心路径，而核心路径上的合并顺序错误，代价是全员的缓存失效。token 经济学最终比拼的不是谁的补丁先落地，是谁的接口设计让后来者的补丁不再互相拆台。

「宁可报错，不要假成功」正在成为公共诉求

这一天的故障区里还有一类问题，性质上比内存泄漏更值得警惕，因为它们攻击的是信任本身。#178300：模型的输出被一个 token 的长度截断之后，框架仍然把这次调用报告为成功——用户拿到的是一份被悄悄剪掉结尾的摘要，而界面上的状态是绿的。#126906：写入工具被拒绝之后，记忆持久化被静默禁用，agent 却向用户报告保存成功——数据没存进去，对话记录里却是一句完成确认。

两个 issue 的共性可以一句话说完：故障不可怕，故障被包装成成功才可怕。在智能体只能聊天的年代，假成功的代价是返工；在智能体已经拿到执行权的今天——写文件、跑命令、发消息、管定时任务——假成功的代价变成了静默的数据丢失和边界失守。同一批报告里还有一个隔离性样本：多路复用的 secondary profile 把流式进度经 primary bot 投递出去，跨 bot 串扰直接进了安全相关分类。用户的原话级诉求就是那句话：宁可报错，不要假成功。

把镜头拉远一点，这类信任缺口在当天的清单上不止两处。并发会话交叉污染的问题（#46303）从 6 月开立至今没有实质修复——共享记忆注入加上工作树复用，让两个会话可能互相看见不该看见的上下文；内部上下文泄漏为用户可见消息的问题（#129314）挂着需要更多信息的状态躺了两个多月——用户在对话窗口里看到了本应只在内部流转的构造细节。单看每一条都不算惊天动地，放在一起看，指向的是同一个尚未完成的功课：智能体框架对「边界」的实现还远没有跟上它对「能力」的实现。文件有权限模型，会话有隔离设计，记忆有生命周期，但这些机制里的每一个都有静默失效的路径，而其中好几个失效路径的当前表现是「装作无事发生」。

这正是「宁可报错」成为公共诉求的深层原因。信任类缺陷的杀伤力遵循一个不对称规律：十次诚实的失败，伤害远小于一次被粉饰的失败——前者让用户校准预期，后者让用户拆除防备。一个会明明白白报错的框架，用户会围绕它的报错设计兜底；一个偶尔把失败说成成功的框架，用户没法设计任何兜底，因为兜底的触发条件（报错）本身不可靠。所以这个诉求本质上是用户在替框架做可靠性工程的最关键一步：先把「失败可见」这条性质钉死，其他一切可靠性改进才有地基。

供给侧的回应在两个生态里各自成形，方向却不约而同。OpenClaw 侧，文件系统策略传导修复（针对审批与媒体工具未继承工作区限制的安全边界缺口）在快照后合并落地，主机级预执行授权守卫的讨论也挂着安全评审标签在推进。Hermes 侧，sudo 检测精细化成对出现——一个把提权检测限定到 sudo 自身的选项段以减少误报，一个在后端根本没有 sudo 可执行文件时直接跳过密码提示——两个 PR 都还在队列里。加上 Hermes 已成体系的风险标签与 issue 模板，能看出共识正在收敛：准入与最小权限不是功能清单里的一项，而是平台的地基。安全边界的收紧是确定性方向，这一点上，两个生态没有错位。

写在最后

回到开头那条缝。合并清单与故障清单的错位，本质上是两种节奏的错位：质量工程的节奏由维护者的工程判断驱动，测试瘦身、性能剖析这类工作不依赖任何单一用户的痛点；而修复的节奏由故障的分布驱动，存储、内存、Windows 升级链这几个 P0 需要的是排期和 owner，不是更多测试。两种节奏都在产出，但只有一种被用户感知。OpenClaw 的健康度小结里那句「建议为三个 P0 建立修复排期」，翻译过来就是：错位可以理解，但不能无限期。

对正在这两个生态里做选型或生产部署的人，这一天的样本给得出几条具体的读法。看健康度别只看活跃度——合并吞吐、P0 的修复排期、贡献通道的通畅度、积压走势，四个口各看一眼再下结论，任何单一读数都会骗人。用 OpenClaw 跑生产的人，眼下最务实的动作不是等修复，而是给自己的存储层加监控：盯住 WAL 体积、内存增速和磁盘水位，把备份节奏提到故障前面，因为按每小时几 GB 的泄漏速率，事后处置永远追不上。用 Hermes 的人，值得盯住 cron 数据可靠性问题的修复进展和网关回归群的收敛速度——任务丢失这类缺陷，值得在它修好之前给自己的定时任务加对账。自己动手搭框架的人，这一天的错位其实是四份免费的需求清单：存储健康监控要内建、上下文前缀稳定性要内建、profile 隔离要内建、失败必须响亮地失败——最后这一条，是两个生态的用户用几百条评论换来的共识。

还有一层判断值得摆在明处：错位本身并不可怕，可怕的是错位之后没有纠偏机制。维护者按自己的节奏还债，是所有大型开源项目的常态；真正区分生态质量高下的，是当错位被指出来之后，系统用什么速度回到对齐。OpenClaw 的两个安全修复在快照之后的一天里陆续合并，说明纠偏的通道是通的，缺的只是把存储和内存的 P0 纳入同样的通道；Hermes 的回归追踪帖在持续消化、桌面问题当天关闭，说明它的洪峰模型在回归场景下运转良好，缺的是给 cron 数据可靠性这类静默缺陷更高的位阶。两周后回头看这两个缺口有没有补上，比今天下任何结论都有价值。

最后交代边界。本文的生态数字基于 10 月 26 日 23 点 50 分 UTC 生成的雷达日报，加上写作时点（北京时间 10 月 27 日深夜）对全部关键 issue 与 PR 的逐条实时复核；正文引用的外部工具带数字（编码 CLI 计费问题、子代理上下文膨胀、GitHub 趋势榜项目）来自同批生成的 CLI 横评与趋势榜简报，未逐条复核到原始仓库；文中评论数为复核时点的值，会继续增长；合并状态以仓库为准，随时可能再变；「两千一百三十万 cache-write token」为 issue 报告者的自述口径，未经独立审计。生态在快速变化，今天所有结论都有保质期——两周后再回头看这三个 P0 有没有拿到排期，会是检验「错位是否会转化为信任损耗」的最好时点。数字会过期，但读数的方法不会：永远拆开结构看活跃度，永远到源头复核否定性断言，永远把用户的痛放在合并清单旁边对一遍。