AI 智能体生态的常驻账单：内存泄漏、磁盘磨损与主线程卸载的三线观察

一句话结论：10 月 3 日的两份开源智能体生态日报里，最刺眼的一组数字与模型无关——一个 worker 组件每 5 分钟泄漏约 1 GiB 内存、一条 CLI 命令重写 1.1–1.4 GB 磁盘、一个 60 秒的刷新周期短于它自身的耗时。当智能体从“按需调用”走向 7×24 常驻，它开始像一个真正的长期进程那样消耗物理资源；而两个生态不约而同地把工程重心压向同一个方向：把数据库搬出主线程的重构连夜落地、把泄漏写进 P0 账本、把恢复机制设上预算。本文对 82 项关键条目做了发稿前实时复核，梳理常驻智能体的五本资源账，并给出任何自建团队明天就能开始记的三笔账。

先看三个数字。

约 1 GiB——一个模型目录（catalog）worker 组件，每 5 分钟向进程堆里放大约 1 GiB 内存，持续不断；

1.1–1.4 GB——智能体每执行一条命令行，就有 1.1–1.4 GB 数据被重写到磁盘。这是插件源码捕获功能引入的副作用，磨损的是 SSD 的寿命；

60 秒——某个刷新调度的 TTL 上限是 60 秒，而它单次刷新的实际耗时比这更长。每轮刷新还没跑完，下一轮已经到期，这个循环把一整个 CPU 核吃到满。

这三个数字来自 10 月 3 日清晨生成的两份公开生态日报（集群项目与桌面项目，覆盖其前 24 小时窗口）。它们与模型能力无关、与 token 账单无关、与推理速度无关。它们属于一个正在成形的新账本：常驻智能体的物理资源账。

过去两年，我们习惯把智能体的成本按 token 记账：输入多少钱、输出多少钱、缓存命中省多少钱。但把最近几周的日报翻下来，会看到 P0/P1 的主题已经悄悄换了——高优先级缺陷高度集中在三件事上：内存泄漏、空闲资源消耗、启动与升级耗时。10 月 3 日日报的横向对比栏目里，第一条趋势判断的原文就是：“常驻”是新的可靠性战场。智能体从“按需调用”转向 7×24 驻留之后，资源治理能力正在成为核心竞争力——因为一个常驻进程的每一个设计缺陷，都会以物理消耗的形式，按天、按周地累积。

这是系列文章的第五篇。第一篇记录升级事故的形态，第二篇观察治理动态，第三篇审计信任的兑现，第四篇追查证据的生产线。前四篇处理的是“信不信得过”这个上层问题；这一篇回到更物理的一层：当智能体变成常驻房客，它的水电煤账单长什么样、哪些设计在偷偷放大它、以及怎么还。 作为每日雷达的固定读者，你会在这篇文章里看到当天最具体的那批条目，以及它们拼起来之后的结构。

照例，我做了发稿前复核：对两份日报中本文引用的 82 项关键 issue 与 PR，在 10 月 3 日深夜（快照后约 16 小时）逐条实时核验，把快照之后的状态迁移一并整理进文内。先说结论：重构在连夜落地、泄漏仍在账上、一个治理缺口正在成型。逐层说。

五本账：常驻进程的物理消耗

把两份日报里所有资源类条目按消耗对象分类，会得到五本账：内存、CPU、磁盘、启动与进程、恢复。 它们散落在几十个工单里，有的已经挂了几个月，有的是本周新增的回归。拼起来，是一个相当完整的常驻系统画像——以及一份相当昂贵的月度预算。

每五分钟一 GiB，以及它的二次伤害

先看内存这本账里最重的一条。9.6 版本线的 catalog worker 被报告每 5 分钟泄漏约 1 GiB 内存（#160548）。但这条工单的原文里，有一句比泄漏本身更值得注意的话：内存回收（reclamation）动作会杀死所有等待中的 turn。

也就是说，这份报告里实际写了两个事故：泄漏是一个缓慢的事故，而“为泄漏设计的回收”是一个瞬时的事故——回收动作执行的瞬间，所有正在排队的用户请求被一并清掉。资源问题就这样转化成了交付问题：用户看到的不是“内存涨了”，而是“我的任务莫名其妙没了”。

这还不是孤立事件。同一个组件在 9 月末就出现过一代报告：每小时泄漏 4–5 GB（#159662），并牵连到一个疑似修复（#162226）。复核结果是：修复至今仍停在评审队列里（仍开放），而新一代泄漏报告已经就位。 同一组件的两代泄漏报告间隔不到两周，修复还没有合上——这是“债”这个词在本系列里最具体的形态。

桌面项目有一本对称的账：Dashboard 的内存增长到 5.2 GB 被系统 OOM 杀掉（#46082），从 6 月开放至今，仍在账上。而设计层的问题在另一个维度上挂着：实时语音会话对 provider 状态“无界保留”（#116201），59 条评论，无修复 PR。这不是实现错误，是资源限制模型的缺失——一个长会话把外部资源句柄一直持在手里，没有任何回收约定，谁也不知道它该在什么时候放手。

把这几条并排放，能提炼出一个观察：泄漏有两种节律。一种是“定时器式”——按固定节奏增长，比如每 5 分钟 1 GiB，规律得像心跳；另一种是“斜坡式”——随会话长度、时间慢慢爬升，比如“用久了就这样”的 Dashboard。前者容易被监控抓住（因为它规整），后者容易被习惯原谅（因为它温和）——而两者都会在某一天，以 OOM 或回收事故的形式集中结账。

六十秒，与它追不上的那个循环

CPU 这本账上，10 月 3 日有一条近乎教科书级的条目：catalog 刷新循环打满一个 CPU 核（#161379），根因是 TTL（60 秒）短于单次刷新的实际耗时。

两个配置数字，各自都合理，放在一起构成了一台永动机：刷新还没完成，下一轮已经到期。这类缺陷有一个共同的形状——它不是“某个值是错的”，而是“两个都对的值之间的距离是错的”。 它调参调不出解法（无论把哪个数字往哪边调，都只是换一种坏法），必须改结构：把“到点就触发”改成“完成驱动的节拍”。判断一个团队有没有踩过这类坑，只要问一句：你的定时任务，有没有“上一次还没跑完”的检测？

同一本账上还有一条“修复的账”。9.7 的一条修复落地后，每个 turn 的资源加载器要烧 80–150 秒 CPU（#163566）。修复通告里写的是“问题已解决”，用户的机器上出现的是新的常量开销。修复本身也是要记账的：修掉一个问题所引入的开销，如果不进账本，它就会以“系统好像变慢了”的模糊抱怨形式，在几周后回来。

长期样本也不能漏：主循环的稳态 CPU 开销从 5 月挂到现在（#84037），状态是“等待产品决策”——挂着不动也在烧 CPU，但优先级排在功能之后。以及规模样本：632 个 agent 的集群，Gateway 就绪后事件循环饥饿（#149538）。当负载从“一个助手”走向“一支舰队”，事件循环的调度预算就从性能话题变成了可用性话题。

磁盘：最不设防的一本账

磁盘是五本账里最被低估的一本——因为它不会当场崩，它安静地磨。

10 月 3 日最值得记录的条目是一条回归：插件源码捕获功能让每条 CLI 命令重写 1.1–1.4 GB 数据（#157989）。这条设计的出发点是可审计性（保留插件源码快照），实现方式却是每命令重写一遍。审计能力用写放大支付，写放大用 SSD 寿命支付——而这笔账不出现在任何报表里。 按每天一百条命令计算，这就是 110–140 GB 的日写入量。

另一条从 9 月 9 日挂到现在：Agent 的 SQLite WAL 数天内膨胀到 1.4–2.8 GB 并阻塞 Gateway 启动（#143524），105 条评论，是社区情绪的最大燃点之一，复核时仍无修复 PR。记忆库一侧则更根本：记忆的 SQLite 没有保留策略，“将慢性填满磁盘”（#114612）。两条合起来，是持久化层的同一句话——“只增不减”。

也有方向正确的动作：增量页回收（#163105）已经合入——这条修复把“增长”翻译成了“回收”。以及“更新器不再复制繁忙数据库”这类修复（#162268，上期复核已合并）——都是在把磁盘从“只写不提”改造成“有进有出”。判断一个常驻系统在这本账上是否健康，方法很朴素：问它一个月要写多少 GB，再问它删多少 GB。如果第二个数字是零，账就是在为未来积攒一次事故。

启动的预算，与不回收的进程表

常驻系统有一个被默认的前提：启动一次，运行很久。但这个前提在两种场景下失效——升级和崩溃恢复，都要重启。于是“启动耗时”变成了可用性的一部分。

10 月 3 日的条目是：Gateway 启动耗时随插件数线性增长，120 秒的启动预算被 discord、codex、weixin 三个插件吃尽（#155859）。插件生态的增长速度和启动预算的固定值之间，存在一个结构性的赛跑：只要“每个插件都可以在启动路径上做一点事”这个机制不变，预算被吃尽只是时间问题——今天吃尽预算的是三个插件，明天就是五个。修复的方向不是删插件，而是把启动路径切成“必须完成的”和“可以后台完成的”两段。

进程表一侧则是另一个经典的“垃圾回收缺位”：hook/tool 子进程未被 reap，僵尸进程持续累积导致运行时劣化（#97616）。内存有 GC，文件描述符有配额，唯独 wait() 这件事经常没有人负责。 对常驻系统来说，“别人拉出来的子进程谁负责收尸”是一个必须先写进设计文档的问题。

当恢复成为放大器

最后一本账，是把前四本放大成事故的那一本。

10 月 3 日的样本是：V8 heap OOM 之后，restart-recovery 机制把单次崩溃放大为 7 次 core dump 循环（#115424）。恢复的目标是回到可用状态；但没有预算、没有退避策略的恢复，是一台放大器——每一次失败都生产出更多次失败。 把它和前面的条目串起来看会更清楚：回收动作（#160548 的 reclamation）杀死等待中的请求、恢复动作（#115424）放大崩溃次数、修复的动作（#163566）引入新的常量开销——三本不同的账，同一个设计盲区：这些机制都是按照“资源应该被释放/系统应该被恢复”的直觉写的，而不是按照“动作本身要花多少代价”写的。

常驻系统的三类“善意破坏者”——回收、重启、重试——都需要各自的预算与退避。判断标准很直接：你的回收机制会不会伤到在途请求？你的恢复机制有没有次数上限？你的重试有没有指数退避？三个问题里任何一个答不上来，账本就少了一页。

五本账的合并报表

把上面这些条目整理成一张表（状态列为 10 月 3 日深夜复核的实时结果）：

这张表有两个读法。按项目读：集群项目承担了其中九条——它的规模，使它必然先撞上这些墙；剩下的一条来自桌面项目（Dashboard 的内存账），指向消费级硬件上的体验问题。 按时间读：其中至少六条是 9 月以后挂上的新账——这不是陈年积债，而是一个高速演进系统在“常驻化”过程中，新功能欠下的当代账。

而这批当代账，恰好出现在项目开始做另一件大事的同一个窗口里——把数据库搬出主线程。那是本文的第二条线。

把数据库搬出主线程：重构的深水区

如果只看功能公告，你几乎不会注意到这件事：一条安静的旧性能工单，突然开始被一串重构 PR 反复引用。但在工程视角里，这是 10 月 3 日日报里最重的动作——集群项目正在把自己最核心的一条 I/O 路径，从主线程上整体卸下来。

一条被反复引用的源头工单

这条主线的源头是一条编号 #117262 的工单：SQLite 事件循环卡顿。评论不多（复核时 11 条），但它是这批重构的“出师之名”——所有卸载 PR 都在直接回应它。

它的分量，要把事件循环的架构讲清楚才看得见。绝大多数常驻智能体网关跑在单线程事件循环模型上：所有消息处理、状态更新、插件调度共享同一个线程。设计者的如意算盘是“每个操作都很快，快到来不及互相阻塞”。而 SQLite 的读写是同步的——于是数据库不再是一个“外部依赖”，而是事件循环的亲兄弟：同一条线程上的时间竞争者。 一条慢查询的整个执行期里，整条消息管道都在等它——语音会话卡顿、渠道回话延迟、巡检任务排队。数据库文件越大、并发会话越多、历史越长，等待就越频繁。

这就是为什么“数据库卡顿”值得一次线程模型级的重构：它不是性能优化题，它是**“整个 Gateway 的呼吸节奏被最慢的一条 SQL 决定”**的结构题。它曾经只是一条安静的工单；现在，它被做成了主线。

第一批卸载动作，与一个深夜的合并窗口

当天的日报记录了这条主线的第一批动作：

• #163605：把 durable transcript 的异步读取移出 Gateway 线程——先修最重的一条读取路径；
• #163496：workspace 状态操作整体迁入 shared-state workers；
• #163819：placement 结果结算迁入 workers；
• #163834：修复长期运行 Gateway 对已完成 chat 注册、usage 报告、prompt 文本的主线程堆保留——直接对着 OOM 类问题去的“释放”动作。

而发稿前复核给出了本篇最有意思的一个迁移：这批卸载 PR 在快照生成之后的两个小时里密集合入主干。 #163834 合于 10-02 23:53 UTC、#163819 于 23:59 UTC、#162669 于 10-03 00:46 UTC、#163605 于 01:19 UTC、#163558 于 01:43 UTC——五个动作、不到两小时，全部落地。 从日报的坐标看是“在途”，从深夜仓库的坐标看是“一夜之间”。这正是为什么要做发稿前复核：快照与事实之间，隔着一整个深夜的工作量。

搬走之后，更贵的问题是所有权

把 I/O 挪个线程，听起来是标准工程操作。但这批 PR 里真正的水深，写在另一个关键词里——所有权（ownership）与生命周期（lifecycle）：

• #163558（P1）：停止 Swarm 时“过早释放子代理生命周期所有权”——什么时候可以宣布一个子代理“死了”，谁有权宣布；
• #163835：ACP source ownership 跨重启保留——进程重启之后，谁还记得上一世代的资源归属；
• #162669：给插件 SDK 引入版本化的 scheduler 能力，把插件定时器与 service/account 生命周期统一绑定——定时器不能比它服务的对象活得更久。

三个方向，一个命题：搬迁只是工程活；搬迁之后的权责划分，才是设计活。 更有意思的是，把 #163558 和 #163834 并排读——一个是“释放得太早”（生命周期被提前掐断，P1），一个是“释放得太晚”（已完成对象的主线程堆保留不放，OOM 之源）。早释放是崩溃，晚释放是泄漏，而所有权模型是同时治愈两者的唯一解药。 垃圾回收领域积累了几十年的这条教训，现在以并发场景的形式，在智能体运行时里重新交一遍学费。

这条线对自建者也有一份直接的映射：你的系统里，谁“拥有”一个会话？它在什么时候可以被回收？进程重启后它还归谁管？——这三个问题的答案如果不在设计文档里，那么线程搬一百次也只是治标。 因为触发问题的从来不是“在哪个线程”，而是“谁负责”。

双线并行：稳定票与高速票的另一面

上期文章提过：集群项目走出了“双通道发布”——扩展稳定线（等效长期支持通道），基于一个冻结的时间点持续回填关键修复。这期日报让这条线的意义以另一种方式被看见：dev 线的回归簇，反向证明了稳定线的价值。

当天日报的版本建议写得很直白：生产环境用户应停留或升级至扩展稳定线；2026.9.x 开发线当前存在多个 P0 崩溃循环问题，不建议生产采用。对照两边：稳定线基于 8 月底的快照，只回填安全与可靠性修复（月初连发两个维护版）；而开发线在 9.5 之后接连欠下插件源码重写（1.1–1.4 GB / 命令）、catalog worker 泄漏、工具组装崩溃循环等一批当代账。

这是发布工程成熟的标志——把“稳定”和“高速”做成两个产品，而不是让所有用户替开发线当小白鼠。 但它也有另一面：双线并行意味着维护成本翻倍，而愿意留在开发线的用户，恰恰是最活跃、最能贡献缺陷报告的那批人——回归的压力集中到了最能忍的人身上。 长期看，这条开发线的回归收敛速度，决定了它下一版能不能赢回主流用户。这也回答了一个常被问起的问题：为什么一个项目的“大重构期”总是故障密度最高的时候？因为快照式的稳定线只保护了过去，重构永远只能向前欠账、向前还。

把这条主线的动作清单也整理成表（时间为 UTC，状态为复盘时点）：

怎么判断一次重构走到了深水区还是浅水区？给一个可操作的观察：浅水区的修复，修的是“行为”——更快的读取、更小的延迟、更少的卡顿；深水区的修复，修的是“协议”——谁拥有什么、什么时候释放、跨重启怎么恢复。 上面这张表的第六到第八行，关键词全部是 ownership 与 lifecycle 这类词——它们开始成批出现在一个项目的 PR 标题里时，它就是在修协议了。修协议比修行为慢得多、贵得多，但修完之后，之前修不动的东西会自己变好。 这是重构最公平的地方。

对使用者，这条线的启示同样直接：如果你的智能体系统还在“所有东西一个线程、数据库想读就读”的阶段，那这笔债早还比晚还便宜——因为事件循环是最诚实的放大器：它把你每一个偷懒的同步调用，都换算成用户可感知的卡顿。

未收敛的簇：修复的供给与 review 的带宽

两个生态的第三条线，不在“单个缺陷”层面，而在“缺陷的队形”和“修复的吞吐”层面。这里浮现的问题比任何单条 P0 都更值得盯——因为它决定的是：前面那些账，要排队多久才能被还上。

四个分身：一次关闭、一次重开

桌面项目最典型的样本，是“助手回复重复渲染”缺陷簇：数据库里只存了一行，UI 上渲染出两行。同一条症状以至少四个独立工单出现：#127665（复核时 45 条评论，为簇内最高）、#123801（24 条评论）以及 #122167、#129993 两条同族工单。日报的描述一针见血：涉及服务端 display projection，多个 P1/P2 工单指向同一处会话状态根因。

但更有信息量的是这个簇的“组织状态”：没有统一的跟踪 issue、没有明确的负责人、没有统一的修复 PR。 用一句话概括这个局面：bug 成簇了，人还没成队。

而发稿前复核显示，这个簇并非静止：#123801 在复核时已关闭（completed）；#122167 的状态是“重新打开”——它曾被关闭，又因问题复现被拉回队列。一个簇里有条目关闭、有条目重生、有条目还在讨论——这就是“未收敛”的精确形状：动，但没有队形。

对照另外两个样本，能看出“队形”的价值。好的样本是桌面项目的空闲资源追踪 issue（#127647）：28 条评论，含完整的分诊计划与机制归因，社区协作质量高——它把“现象聚类”升级成了“机制归因”，后者才是可修复的形态。 差的样本是集群项目的 WAL 膨胀工单（#143524）：105 条评论、数周的用户数据补充、仍无修复 PR——它不是没人管，而是没有任何一个时刻被收敛成“单一问题+单一负责人+单一修复路径”。热度最高的工单，恰恰是最需要被“降噪”的工单。

292 与 348：修复供给不缺，缺的是吞吐

两条硬数字：集群项目待合并 PR 292 个、桌面项目 348 个；当日合关数是 208 与 152。把它们并排放，结论很清楚——修复的“供给”（社区提交新 PR 的速度）健康甚至过剩；“吞吐”（review 带宽）才是真正的瓶颈。

这解释了几个此前散落的现象：为什么一个“ready for review”的可观测性 PR（#141004，运行时技能使用记录）会长期停在队列里；为什么 XL 级重构（本周合入的那批卸载 PR 里，多个曾是 XL 级）需要等上一个深夜窗口才集中落地；为什么“证据完备的提交走得快”这个规律在经济上如此合理——给 reviewer 省时间，就是给整个生态提速。 每一个差着复现步骤、差着测试、差着说明的提交，都在占用一份本可以分给下一个修复的带宽。

顺带记录一条复核时的好消息：Webhook 隐式端口退役（#162759）——一个被标记为“下版本可能的破坏性变更点”的兼容性迁移——已在复核前完成合入。兼容性迁移能顺利走完，说明队列里躺着的不全是坏消息，只是队列确实很长。

下一站：从功能竞赛到物业竞赛

把当天所有的方向性信号并排放在一起看，会看到一幅相当一致的图景：

• 跨网关智能体协作（#97681，33 条评论）——跨机器、跨所有者的个人智能体协作，官方口径是“先跨机器、后跨所有者”，路线图级；
• 远程 Agent + 本地工具执行（#18715，36 个赞、22 条评论、挂了五个月）——“模型跑在远程、工具留在我机器上”的部署形态，是呼声最高的未落地需求；
• 技能懒加载（#2045）——87 个内置技能全量注入系统提示词带来的 token 浪费，与另一条日报主推的“上下文经济学”（压缩、预索引、剪枝）精准合流；
• 本地模型 fallback 的真正可用（#131795 已合并）——修复“本地模型作为回退时被误报未配置”之后，云端限额→本地降级的链路才算通了；配套的 prefill 成本上限（#123450）仍在途；
• 容器化部署（#118785）——被官方列为 QA 重点方向。

这些信号指向同一个下一站：个人智能体正在从“功能竞赛”进入“物业竞赛”。 功能是房子的装修——模型多聪明、插件多丰富、界面多好看；物业是房子的水电煤——消息会不会丢、内存会不会漏、升级会不会把家拆了、磁盘会不会被写爆。房子的装修决定你想不想住，物业决定你能不能住下去。 前面五本账里每一条还开着的条目，都是物业欠费单。

这也给选型提供了一份新检查单。过去我们比功能清单、比基准分数；现在值得把“资源账本透明度”提升为一等指标：它有没有公开的空闲资源追踪？它的泄漏修复有没有被写成 P0？它有没有稳定通道（比如扩展稳定线）？它产出的 bug 簇有没有“队形”（统一跟踪项与负责人）？——这几个问题比任何跑分都更能预测：你未来一年会不会在半夜被系统叫醒。

三笔账：从明天开始记的

如果你正在自建或重度运营一个常驻智能体系统，从日报里这几十条工单可以提炼出一份极简的自检——先记三笔账。

第一笔：内存增速。 给你的常驻进程做一个最朴素的监控：每小时采样一次内存，算斜率。健康系统的斜率在空闲期应当趋近于零；任何“空闲期也在涨”的斜率都是一条定时泄漏。判断危险不用等到 OOM——斜率乘以你预估的最长连续运行时间，超过物理内存的一半，就该修了。 这条规则的目的，是把泄漏从“某天突然 OOM”变成“几周前就能排进修复计划”。

第二笔：磁盘的写删比。 统计单日写入量与删除/回收量。写放大（比如每条命令重写 GB 级数据）和只增不减（WAL、无保留策略的记忆库）是两种不同的病，对应两种修法：前者要去掉重复写，后者要补保留策略。只要“删”这一栏长期是零，无论当前磁盘多空，系统都在为未来积攒一次事故。

第三笔：启动与恢复预算。 给“启动到可用”设定一个硬预算（比如 60 秒），给“崩溃后恢复”设定次数上限与退避策略。启动路径要区分“必须完成”与“可后台完成”；恢复机制要回答三个问题——会不会伤到在途请求？有没有次数上限？有没有指数退避？没有预算的恢复机制，是事故的放大器，不是解药。

如果你不是自建者而是使用者，这份账本也可以反过来用：把你的智能体的资源面板翻出来，把上面三个问题问给你的工具团队。供应商对这种问题的回答质量，就是它物业水平的直接读数。

边界

数据口径与复核声明。 本文所有案例、编号与数字，来自 2026 年 10 月 3 日生成的两份公开社区日报（快照生成于 10 月 2 日 23:45 UTC，覆盖其前 24 小时窗口），以及我在发稿前（10 月 3 日深夜，快照后约 16 小时）对 82 项关键 issue/PR 的逐条实时复核；文中“已合并”“仍开放”等状态断言，均以复核时点的实时返回为准，合并时间戳保留 UTC 口径。复核覆盖被选入本文的条目，是抽样而非全量；公开条目的状态仍在持续演化——你复核时看到的数字很可能与本文不同，这本身就是快照半衰期的实证，请以你复核时的实时状态为准。 另需说明：两个项目的日报统计存在 500 条/窗口的上限截断，所有“500”均为触顶值而非真实全量。

未复测声明。 我没有独立复现文中的任何一个缺陷；所有根因描述（如“TTL 短于刷新耗时”“回收杀死在途 turn”“恢复放大崩溃次数”）都来自公开报告者的分析记录，我未做源码级独立验证。文中“五本账”“深水区信号”“物业竞赛”等提法，属于基于公开记录、标签与讨论质量的分析性归纳，不是官方口径，也不构成对任何项目的质量裁决。

匿名化说明。 按本站惯例，两个开源项目以“集群项目 / 桌面项目”指代；所有编号均可通过公开仓库检索复核。行业与商业动态仅作背景引用，我未对其做独立事实核查。

后续追踪方向。 四件事值得在两周后回看：9.x 开发线的 P0 回归簇收敛速度（#160548 泄漏与 #162031 崩溃循环的修复何时落地）；主线程卸载的下一步（#163835 的跨重启所有权仍开放）；重复渲染簇是否出现统一的跟踪项与负责人；以及扩展稳定线是否保持承诺的回填节奏。账单已经摊开——接下来看谁先把它还上。

写在最后

第一，常驻是新的可靠性战场，而且它不是比喻：两个生态的高优先级缺陷已经高度集中在物理资源上——内存、CPU、磁盘、启动、恢复，五个账本各自都有一批现成的条目。资源治理正在从“优化项”变成“一等正确性需求”：一个会杀在途请求的回收机制，和一个会丢消息的传输层，对用户来说是同一件事。

第二，主线程卸载提供了判断“重构深水区”的现成标尺：当一个项目的修复开始批量修改“所有权与生命周期”而不是“性能数字”时，它修的就不再是行为，而是协议。修协议慢、贵、不产生炫目的发布公告——但修完之后，之前修不动的东西会自己变好。 与此配套的双通道发布（稳定线与开发线），则是一个成熟项目对“想稳的人”和“想快的人”的第一次分开结账。

第三，治理带宽是容易被忽略的隐形瓶颈：bug 会成簇，但队伍不会自动成队；PR 的供给不缺，缺的是消化它的深夜窗口。每个生态的真实速度，不看它的提交频率，看它把一条工单从“被发现”推到“被核销”的中间那段路要走多久。

最后说两句心里话。这份账单读起来可能有些压抑：一边是连夜落地的重构，一边是越积越多的条目，还有一堆“讨论了上百条但没人认领”的队列。但换个角度看——一个社区能在公开频道里把“每 5 分钟泄漏 1 GiB”写成一行工单，这件事本身就是希望：看不见的账最贵，能记账的系统已经赢了一半。 剩下的那一半，是把账本摊开给所有人看之后，仍然选择一行一行地还。这就是这个生态此刻在做的事。

下一篇，我们去看看那批 P0 修复，在这两周里落了几张。