48个技能，46个只增不减

2026 年 10 月 29 日 03 点 34 分（UTC），OpenClaw 仓库里一个编号 #186861 的拉取请求被合并。这个请求做的事情听起来有点朴素：给「技能工作坊」加上一套让习得技能「减肥」的机制。它的动机来自一次对生产环境智能体的实测——那个智能体身上挂着四十八个习得技能，其中四十六个处于「只增不减」的状态：装上之后从未被清理、从未被合并、从未被判定过还有没有用，随着运行时间一路堆积。合并进来的修复方案是给这堆技能加一个每日维护收缩的环节，让系统每天自己问一遍：这些东西还都要吗。

同一份日报的另一个角落里，记着两件和记忆直接相关的事。一个讨论了二十一轮的开放议题说，短期记忆的夜间驱逐机制会让梦境整理管线的 deep 阶段永远等不到该晋升的记忆；另一个十轮讨论的议题说，记忆系统里的打分模块和应用模块陷入了永久分歧——系统每轮都给一批记忆打出了排名，然后一条都没有应用上去，字面意义上的「排名了 N 条，应用了零条」。再往下翻，还有一条十三轮讨论的议题：一些用户的核心记忆文件被一个来源追溯机制静默地、永久地剔除了初始化注入，没有诊断信息，没有恢复手段。

这三件事加上开头那个技能减肥的修复，拼出来的是同一个信号：当智能体被当成常驻服务长期运行之后，它的记忆和技能不再是「装进去就行」的静态资产，而是会长胖、会腐烂、会互相打架的活物。行业对记忆系统的关注点，正在从「怎么记住更多」转向「怎么治理已经记住的东西」。本文基于 2026 年 10 月 29 日的 OpenClaw 与 Hermes Agent 生态日报快照展开，文末附复核口径。

记不住也瘦不下来：记忆管线卡在三个环节上

先把记忆系统的问题拆开看。从日报快照里能拎出三类故障，它们分别卡在记忆生命周期的三个不同环节：晋升环节、裁决环节和存续环节。

第一类卡在晋升环节。议题 #150635 描述的故障链条是这样的：智能体的记忆系统里有一套梦境整理机制（dreaming pipeline），它会在夜间把短期记忆往长期记忆里晋升，其中 deep 阶段承担着把重要记忆固化下来的职责。问题在于短期召回侧有一个夜间驱逐机制，会在梦境管线运转之前就把一批记忆驱逐出去——于是 deep 阶段每次醒来，发现自己要整理的材料已经被清走了，晋升动作永远没有对象。系统不是没在整理，是整理的对象在整理完成之前就消失了。这个议题挂了二十一轮讨论，标签是「等待产品决策」，也就是说技术社区已经把病灶描述清楚了，但「驱逐和晋升谁先谁后」这件事在产品层面还没有人拍板。

第二类卡在裁决环节。议题 #121232 的症状用报告者自己的话说就是「排名了 N 条，应用了零条」：记忆系统里的 ranker（打分排序模块）每轮都认真给候选记忆排序，applier（应用模块）每轮都拒绝采用排序结果，两个模块之间形成了永久性的分歧。这不是某一次的偶发失灵，而是结构性的——打分的标准和应用的门槛对不上，而且没有任何机制去调和这个对不上。十轮讨论，同样挂着「等待产品决策」。把它和 #150635 放在一起看会发现一个共同点：两条议题都是管线内部两段逻辑各说各话，一段在做自己的本职工作，另一段在做自己的本职工作，合起来却是一个永远不产出的循环。

第三类卡在存续环节，也是这三条里最让用户不安的一条。议题 #153426 报告：用户的核心记忆文件——MEMORY.md 和 USER.md——被一个叫 provenance ratchet（来源追溯棘轮）的机制从初始化注入中静默剔除，而且是永久性的。棘轮机制的本意是防止低质量来源的内容反复回流，但它的执行是单向的：一旦剔除，没有诊断信息告诉用户「你的记忆文件被剔了、为什么被剔」，也没有任何恢复手段。十三轮讨论，安全评审状态还停在待定。对个人助手类产品来说，记忆是信任的基石；当记忆可以无声消失而且查不到原因时，用户失去的不是几条笔记，而是「这个系统还记得我」这个前提本身。

这三类故障摆在一起，可以列成一张表：

（评论数为日报快照值，2026 年 10 月 29 日晚经接口复核，三个议题状态均仍为开放。）

值得注意的不是任何一条孤立的 bug，而是三条议题共同的解决形态：全都卡在「需要有人做产品决策」的位置上。驱逐和晋升的时序可以有很多种排法，打分和应用的标准可以有很多种对齐方案，棘轮机制可以加诊断、加申诉、加冷却期——每一种都不难，难的是项目得先回答「记忆系统应该以什么为准」。这大概就是记忆系统从堆积走向治理的第一个代价：治理不是修 bug，是定规则；定规则不能靠合并请求，只能靠决策。

这个判断不只在 OpenClaw 一侧成立。同一份快照里，Hermes Agent 的社区正在讨论一个编号 #143379 的架构级提案——一个叫「文档链底座」的征求意见稿，二十九轮讨论，核心诉求用社区自己的话说，是「持久记录应该带着溯源信息在会话压缩之后存活」。它回应的是上下文压缩这个所有长期运行智能体都绕不开的环节：会话被压缩时，哪些东西有资格活下来、活下来之后还能不能查到它是从哪来的、由谁在什么时候写入。把这条线索和 OpenClaw 的三条议题并排放，两个项目各自演化出的记忆架构撞向了同一堵墙：OpenClaw 的问题是没有裁决规则，记忆的生杀被分散在驱逐、打分、棘轮几个互不通气的机制手里；Hermes 的问题是压缩这一刀下去没有溯源账本，活下来的记录说不清自己的出身。两侧的应对也异曲同工——一侧在讨论给记忆管线加产品决策层，一侧在提案里直接把「可溯源、可治理、可重读」写进了架构目标。

还有一层更物理的证据来自前一天（10 月 28 日）的快照，它说明「不治理」的账单会涨到多大：记忆用的 SQLite 表没有任何保留策略，磁盘无限增长，这条议题挂了很久没人接；有用户的记忆索引在处理到恰好两个文件后永久卡死；还有一个孤儿临时数据库膨胀到十九个 GB 的案例。这三条和 10 月 29 日的三条管线议题是同一枚硬币的两面——10 月 28 日的快照记录的是记忆「占地方」的账，10 月 29 日的快照记录的是记忆「不听话」的账。占地方可以用磁盘价格消化，不听话不能：一个晋升失灵的记忆系统不会报错，它只是安静地变成一个越来越不可信的助手。

谁在生产记忆，谁在消化记忆：两条修复流水线的对照

把镜头从记忆系统拉远一点，看整个生态怎么消化它每天产出的海量输入。这一段需要先交代两个项目的活动基数。

OpenClaw 在 10 月 29 日的快照里，过去二十四小时议题更新五百条——新开或活跃四百零四、关闭九十六；拉取请求更新五百条——待合并二百八十二、已合并或关闭二百一十八。Hermes Agent 同日议题更新三百六十二条——活跃三百二十八、关闭三十四；拉取请求更新五百条——待合并四百一十、合并或关闭九十。前一天的快照也差不多是同样的量级：OpenClaw 五百条议题（关闭九十三）加五百条拉取请求（合并关闭二百六十二，单日发了三个版本）；Hermes 四百五十九条议题（关闭七十八）加五百条拉取请求（合并关闭一百三十七）。

两个项目的输入管道质量在日报里都被评为 A 级——用户提供的报告带着源码级复现、提供商二分定位、量化数据，社区甚至出现了智能体代替用户提交高质量缺陷报告的案例。但输入的 A 级和消化的健康是两回事。把两个日期的快照并排放，结构就出来了：

（数据为两日日报快照值，评论数与关闭率受数据窗口限制；趋势判断需多日观察。）

这张表里有两条线索值得盯住。第一条是 Hermes 侧的待合并请求从三百六十三涨到了四百一十，关闭率只有百分之九左右——项目刚完成统一网关和网页版两大架构合并，正处在「扩张优先、质量追赶」的阶段，评审带宽是明确的瓶颈。第二条是 OpenClaw 侧，合并吞吐看起来健康，甚至被日报判断为「约为 Hermes 的二点四倍」（按 10 月 29 日单日合并关闭比口径），但它的严重问题积压在另一个层面：按 10 月 29 日的统计，七项最高优先级（P0）问题里几乎全部没有对应的修复请求。

逐条看这七项是什么。一个无界内存泄漏，报告者用冷启动加提供商二分的方式复现了每小时四到五个 GB 的泄漏速度，从 9 月 27 日提出至今一个月，二十七轮讨论，没有修复请求；那个六十二轮讨论的全库最热议题——大型外部插件让网关的事件循环阻塞数分钟，源自 9 月 6 日引入的插件捕获机制——复核时评论已经涨到六十四条，仍然没有修复请求；一个 SQLite 数据库腐坏问题，在全新重建的数据库上十五到二十四小时内必然复发，用户五天遇到五次，还包括「系统瘫痪但进程不退出」这种最难缠的模式，从 8 月 20 日挂到现在；还有崩溃恢复后代理永久不可用的一条、三点五个 GB 数据库让启动变成四到六分钟赌博的一条，以及两条 Windows 平台问题。日报把这组现象总结为一句话：多个最高优先级问题标记着「等待维护者复审」，却没有对应的修复。

但把 OpenClaw 说成「只堆积不修复」并不公平，快照里同一天的真实修复动作也不少，而且状态都在发稿前经接口逐条核实过：修复网关被强杀后排队消息永久卡住的请求（日报写「已关闭」，接口显示实为已合并，合并时间 10 月 28 日 23 点 58 分）；修复插件重载期间根会话消息发送丢失的请求（超大改动、标记安全敏感，10 月 29 日 05 点 15 分合并）；两个降低普通消息路径开销的性能优化（分别于 28 日 23 点 55 分和 29 日 00 点 11 分合并）；把会话聚合与审批查询限定在成员范围内、堵住信息越权泄露的安全边界修复（29 日 03 点 03 分合并）；修复草案会话委托产生共享辅助进程导致访客可读结果的隐私泄漏修复（29 日 00 点 51 分合并）。加上开头那个技能减肥请求，一天之内七个实质修复落地，节奏并不慢。

慢的不是修复，是修复的分布。这七个修复里，消息可靠性、插件重载、安全边界、权限隐私各占其一，性能优化两个——集中在用户可感、边界清晰、局部可验证的中低危和高显眼度问题上。而内存泄漏、数据库腐坏、事件循环阻塞这一族需要跨模块重构、需要长期验证的问题，全部排在队列里不动。日报的判断是「修复吞吐集中在界面与中低危问题，P0 稳定性主线消化偏慢」，数据支持这个判断。这里有一个在开源维护中反复出现的结构性规律：能被一个拉取请求在一天内闭环的问题会源源不断地被消化，因为它给贡献者确定性；需要专项、需要设计决策、需要回归矩阵的问题会持续沉积，因为没有单个贡献者能背着它们跑到终点。

沉积到一定程度，会开始反噬输入管道本身。快照里记录了几个这样的信号：一个高价值的定时任务与工具目录相关议题（#120385）已经因为长期无人处理而进入过期状态，和那两条记忆管线议题一起，挂在「过期加等待产品决策」的双重标签下——不是没人关心，是关心的人也在等；一个讨论过 Codex 消息工具协议问题的修复请求，因为不活跃在 10 月 15 日被自动关闭，技术方案就此悬置；Hermes 侧更直接，一位活跃贡献者因为平台侧的权限错误连拉取请求都无法创建，五十三轮讨论过去仍被标记为上游问题，而另一批 8 月就提交的高质量修复（包括计划重启前等待最终投递、修复插件发现未完成导致的误报）已经悬置了两个月。日报把这组现象归结为一句生态级的判断：维护者带宽是瓶颈，社区质量即护城河——但护城河的另一个读法是，如果高质量报告和高质量修复持续得不到回应，最先干涸的就是这两条供给线。

带宽问题的有趣之处在于，它正在催生自己的缓解机制。快照里有两个值得单独记下的细节：一个是用户侧的工单看板上出现了「接受三百二十七、丢弃三百二十七」这样的量化对账数据——用户开始像审生产系统一样审议题处理流水线；另一个更有意味，10 月 28 日的快照记录了一份由智能体代替用户提交的缺陷报告，质量高到被社区单独点名表扬。输入端在自动化，triage（分诊）端有社区机器人做分类，唯独中间那段需要判断力的评审和决策，仍然只能靠人。智能体生态现在最真实的稀缺资源不是算力，不是社区热情，是那段无法自动化的评审带宽。

还有一个发布侧的细节值得放在这一段里。快照指出，多个已经合并进主干的修复——比如那个会话历史恢复的修复——截至当前的两个发布版本都还没有带着它们出厂，用户要等到下一个 tagged release 才能用到。修复已经完成、主干已经验证、用户仍然在旧版本上受影响，这是「输入大于消化」的第三种形态：消化了，但消化结果没有送达。日报给维护者的第一条建议就是优先发版——对一个稳定线加测试线的双轨项目来说，主干上的修复不等于用户手里的修复，中间还隔着一次发布决策。

0.6% 的覆盖率，和三条静默消失的消息

第三个主题块是两条互相咬合的线索：一条是 Windows 平台的质量债务，一条是消息投递的可信度。它们看起来不相干，底下是同一个问题——系统失败时，用户能不能知道。

先看 Windows。议题 #126874 给出的数字是整个快照里最刺眼的一个：Windows 环境的持续集成只运行了一万零九百七十九个测试文件中的六十六个，覆盖率百分之零点六，而且被跳过的门禁会计作通过。这个数字放在那里，Windows 用户的许多抱怨突然都有了统计学解释。快照里 Windows 相关的议题是一条链：升级流程在安装暂存成功之后仍然反复查询一个已经停止的网关进程号，挂起十五分钟以上（这条有四十七轮讨论，后被关闭）；重启或更新「要试很多次才成功」的长期抱怨；新用户快速上手时激活直接失败（标记为主分支上无法复现——也就是说修复可能依赖尚未发布到稳定版的变更，稳定版用户只能等下一个版本）。两个项目在这一点上高度一致：日报的横向对比里，「Windows 是双方共同的二等公民」是被原样写进结论的判断。覆盖率百分之零点六的门禁不是「覆盖不全」，是「实际上没有覆盖」——一个平台的工程质量上限，很大程度上在持续集成配置写下去的那一刻就定了。

再看消息投递。快照里的用户反馈段落有一句被反复强调的底线诉求：高价值消息静默丢失、无告警，不可接受。支撑这句诉求的是三个具体案例：一条 Telegram 消息在单次投递尝试失败后直接进入死信状态，没有重试（8 月中旬至今）；一条标记为持久化投递的消息卡在「投递尝试已开始」的状态上不再前进；一条回调消息被静默丢弃。三条议题的共同点不是「消息丢了」——分布式系统里消息丢失本来就需要按概率设计——而是丢了之后系统装作 nothing happened：没有死信可见性，没有告警，没有用户可查的投递状态。对比之下，同日合并的那个「网关强杀后排队消息不再永久卡死」的修复之所以重要，就是因为它把失败暴露了出来——排队消息会在启动时通过现有分类被展示，用户至少知道有东西没送到。

把两条线索拧在一起看，会看到一个对长期运行的智能体服务来说非常根本的分野：功能是可以补的，渠道是可以加的，但「失败可见性」是架构决定——要么在设计的每一条路径上都有失败出口，要么就是没有。快照里的功能请求段落还给出了这个判断的需求侧证据：用户对飞书渠道的请求不是「接一下飞书」，而是「让飞书获得和 Telegram 等六个渠道一致的流式进度模式」——已有渠道的失败可见性标准在抬高，新渠道必须按这个标准进来。同一份快照里还有成本侧的类似信号：有用户报告某提供商的缓存每轮重建约三十八万 token，有用户抱怨同一个嵌入向量在数据库里存了三份、把数据库撑到三点五个 GB——用户不再只看功能清单，他们在把智能体当长期运行的服务来审资源账单。

好消息是 Windows 这条线的修复动作最近确实在加密，只是发生在另一个项目里。Hermes 侧的同日快照记录了两个连续合并的修复：给 Windows 启动器的进程重生风暴加刹车——实测某环境下六十九秒之内出现了三代网关进程，也就是启动器在以每二十秒一代的速度拉起又拉垮自己；紧接着的第二个修复补上了「旧安装的任务模板收不到刹车」的缺口。两连发的节奏说明维护者在认真收敛这个平台，但也从侧面说明了债务的厚度：一个刹车修完马上发现旧路径够不着，这种「修一处、露一处」的形态正是覆盖率不足平台的典型症状。OpenClaw 侧同期的 Windows 动作则集中在时钟健壮性上——两个单调时钟修复消除了网络时间跳变和虚拟机暂停导致的用量预算损坏，这类问题的共同点是平时代价隐形、坏起来不可解释，属于最容易被「以后再说」的那一种。

失败可见性还有一个容易被忽略的灰区：诊断信息本身的可信度。10 月 28 日的快照里有一条精彩的案例——一个配置读取命令因为自动掩码了敏感值，导致用户把故障误诊了四个小时，用户事后提出的诉求被日报概括为「可观测的诚实」：掩码要打，但要告诉用户「这里被掩了」。这条和消息静默丢弃是同一类问题的两个极端：一个是失败被伪装成成功，一个是信息被伪装成缺失。两者的修复方向却是一致的——系统对用户说话的方式，必须能区分「没有发生」和「发生了但不能告诉你」。

另外，Hermes 侧的快照里还有两条同主题的开放问题可以补进这条线：中途插话不可靠——排队不送达、界面上显示已发送但实际没有到达执行层、催促按钮点了没有任何反应（#141973）；本地看板的定时唤醒通知永远到不了会话队列，根因是本地会话适配器缺了网关运行器这个环节（#143268）。加上前述三条 OpenClaw 的消息案例，五个案例横跨两个项目、五种表现形态，指向同一个结论：投递链路的每一跳都可能成为静默丢失点，而用户视角只有一句话——我以为它知道，它其实不知道。

记忆账本和维护账本是同一本账

回过头把三个主题块串起来，会发现它们其实是同一本账的三个分栏。

技能减肥那个修复回答的是「已经学的东西要不要清理」；梦境管线的两个死结回答的是「值得留的东西怎么晋升、谁说了算」；来源棘轮的静默剔除回答的是「留下来的东西凭什么可信」。这是记忆这本账的三个分栏——堆积、晋升、溯源。而维护带宽的对照表和那三条静默消失的消息，是另一本账：系统的修复能力账和失败可见性账。这两本账在结构上是同构的。记忆系统的问题全是「只增不减」——记忆只增不减、技能只增不减、待决策的议题只增不减；维护系统的问题全是「流入大于消化」——每天几百条输入，消化管道的截面是固定的。两边的解法也只能是同一种：给增长装上节律。技能减肥用的是每日收缩，消息可靠性用的是死信分类，而议题堆积那一边，缺的恰好是一个「每日收缩」——日报给维护者的三条建议（优先发版携带已合修复、针对数据库与事件循环两族问题设专项、补齐 Windows 覆盖率）本质上都是在给消化管道扩截面。

有几条边界需要交代清楚。本文引用的全部数据来自 2026 年 10 月 28 日与 29 日两份自动生成的生态日报快照，评论数、关闭率都是窗口内的统计值，会随时间变化——事实上发稿前的接口复核就已经抓到一处偏差：一个被日报写为「已关闭」的修复请求，接口显示实际状态是已合并，合并时间精确到 10 月 28 日 23 点 58 分；全库最热那条议题的讨论数也从六十二涨到了六十四。快照和事实之间总是隔着一小段正在流逝的时间，引用自动汇总类数据必须逐条回到源头核对，这本身就是本文讨论的主题——治理——在写作层面的一次自我应用。另外，七项无修复请求的统计口径是快照时点的「无直接对应修复请求」，不排除存在缓解性提交或相关讨论在进行中；「修复吞吐集中在 UI 与中低危」是日报基于样本分布的判断，不是对维护者优先级的指控——评审带宽不足是两个项目共同的、被公开承认的结构性约束。

还有一条关于概括本身的边界。把两个项目四十多条议题浓缩成「记忆治理」「消化带宽」「失败可见性」三个主题，是写作者的分析框架，不是项目方的自我表述——真实的缺陷清单要扁平得多，也琐碎得多。框架的价值是把可迁移的判断从个案里拎出来，代价是必然丢掉一部分上下文：比如那七项最高优先级问题里有两条标记着「主分支上无法复现」，它们可能是修复已就位只差发版，也可能是环境相关的疑难杂症，本文按保守口径计入积压，读者引用时应当意识到这个口径的不确定性。同理，「维护者带宽是瓶颈」这句话来自日报原文，但带宽应该往哪个方向扩——多招维护者、自动化决策、还是砍掉长尾功能——快照里没有任何证据，本文也不猜。

对正在运行或打算长期运行智能体服务的人来说，这份快照给出的指向是具体而不是抽象的。选型时把「记忆有没有治理机制」从加分项挪到必答项：技能会不会收缩、晋升有没有裁决规则、记忆被剔除时有没有诊断——这三个问题的答案比记忆容量的宣传数字更能预测半年后的使用体验。部署时把「失败可见性」当作架构审查的第一项：消息投递有没有死信状态、崩溃恢复有没有可观测的中间态、资源账单能不能按组件拆开——静默失败很少在第一周出现，它往往在你开始依赖这个系统之后才暴露。至于那四十六个只增不减的技能，它们最好的去处不是被某个大版本一次性清理，而是从今天起每天被问一次「你还有用吗」——治理从来不靠一次性的大扫除，靠的是把收缩变成和增长同样日常的节律。