被静默删除的五份交付物：智能体信任债清算日

2026年10月17日凌晨4点21分（UTC），Hermes Agent 仓库里一个编号 #132401 的 P0 issue 被维护者 teknium1 关闭，关闭理由是 completed。这个时间点很有意思：本专栏每日跟踪的开源雷达快照生成于 10 月 16 日 22:49（UTC），在那份快照里，这个 issue 还挂着 needs-decision 标签，状态是"数据丢失类 P0，等待维护者决策"。快照生成后不到六个小时，决策落地了。维护者在关闭前的最后一条评论里写明：修复已合并为提交 33beaec5700，scratch 清理机制现在会在删除前重新检查整个子树、在最终检查前测量条目大小、并为每一条被删除的条目写入审计日志。

在维护者行动之前，社区已经把这个问题的边界摸得很清。事件的技术起点可以追溯到更早的一份初始报告：报告者运营着一个多智能体平台，把 Hermes Agent 作为受管执行节点，平台用目录尺寸做资产保留策略，而这个目录恰恰就是 scratch。10 月 2 日到 3 日的夜间，自动清理循环判定其下多个子目录"连续 24 小时无写入"，直接递归删除——这就是后文那五份交付物被毁的直接现场。

这个 issue 讲的事情，是过去两周整个开源智能体生态里最刺眼的一类问题：平台自己的清理机制，在没有任何日志、任何隔离区、任何保留标记的情况下，静默删除了用户多天的智能体工作成果。而它不是孤例。同一天，另一个头部项目 OpenClaw 的社区里，讨论最热烈的 issue 之一仍然是消息通道静默丢件；一个成本观测 issue 用七台智能体、103 个会话的实测数据，量化出 254 次缓存前缀重写烧掉了 2131 万 cache-write token。把这两边的账单摊在一起看，会发现一个正在成形的共识：智能体基础设施的竞争，已经从功能竞赛转入可靠性与信任构建阶段，而"静默失败"是这一阶段最贵的一种债。

五份交付物与一个没有日志的删除：#132401 的十四天

先把 #132401 的机制讲清楚，因为它是理解这类问题分量的最佳标本。

Hermes Agent 会把每个进程的 TMPDIR、TMP、TEMP 环境变量统一指向用户主目录下的 cache/scratch 路径，而且平台给智能体的操作指引里明确写着：临时文件和探测脚本就该放在这里。问题出在保留策略上：清理循环会删除任何"整个子树连续 24 小时没有任何写入"的顶层条目——判断依据是一次深度 mtime 遍历。这个判断对垃圾文件是有效的，但对"已经写完、正在等待后续工序"的交付物是毁灭性的：一份写好之后就没人碰的报告草稿，在 mtime 的世界里和垃圾不可区分。

更糟的是删除路径本身。清理不仅删文件，还会顺带杀进程：工作目录位于被删条目下的同 uid 进程会先收到 SIGTERM，3 秒宽限期后收到 SIGKILL，被杀的进程没有任何记录。一个正在长时间计算（而不是写文件）的工作进程，恰好因为它"只算不写"，其所在目录就会被判定为闲置，然后进程本身被清理掉——从智能体的视角看，这和宿主环境崩溃无法区分。最后，删除动作本身用的是忽略错误的递归删除，返回一个没有任何消费方的计数，什么都不写进日志。

报告者给出的损失记录是具体的：2026 年 10 月 2 日 12:26 到 10 月 3 日 06:00 之间，五份交付级成果被毁——一份面向合作方的报告草稿、一份整合报告、一个垂直分析包、一次模型扫描基准测试、一套后继基准测试组件。能找回来纯属运气：当天早些时候恰好存在一份手动创建的 restic 快照。而这已经是第二次：更早的 9 月 20 日，一个兄弟机制以同样方式毁掉了 178 个文件。报告者对问题的定性很准确——这不是一个策略选择问题，而是设计冲突：平台一方面把 scratch 指定为智能体的工作区，另一方面销毁其中闲置超过一天的一切，且失败过程对所有参与者都不可见。

清理的触发面比多数人想象的宽。逐条对照报告者给出的代码位置：清理逻辑挂在获取 scratch 目录的函数里，参数默认开启，而每一个 Hermes 进程及其子进程在启动时都会走到这个函数——也就是说不是有一个后台守护进程在定期打扫，而是每一次任何入口的冷启动（CLI、桌面端、cron 任务派生）都可能成为清理的触发点，唯一的限流是一个共享的小时级时间戳门控，一小时内多个进程启动只做一次。这个设计在正常路径上是省资源的，但它意味着清理的触发时机对用户完全不可预期：你可能是在深夜顺手跑了一条命令，就成了压垮某个闲置两天的工作目录的最后一根稻草。

还有一个容易被忽略的连带伤害：当被删除的目录里曾有 git worktree（一种让多个工作分支共享同一对象库的轻量检出机制），清理器会顺带执行 worktree 清除，把这些 worktree 从所属仓库的注册表里静默注销。文件没了可以理解成清理，但仓库元数据被改写属于典型的越界副作用——用户在主仓库里留下的配置，被一个完全无关目录的清理动作破坏了。

报告者并非只报问题。他们带着一个完整可工作的修复方案来：闲置条目不再直接删除，而是移入同级的隔离区目录，宽限窗口默认 72 小时并以时间戳锚定，到期才最终清除，全程可审计。方案自带 24 项测试全部通过。社区后来的实际落地路径与此不完全相同（日志能力先行，隔离区方案未被采纳），但"隔离区而非直接删除"这个核心思路，正是前文那三个词里"可恢复"的具体形态——它把删除从单向不可逆操作，变成了有时限、有退路的两段式操作。

这个 issue 的后续推进过程，本身就是一个高质量社区取证的样本。10 月 11 日，另一位用户在第二台安装（macOS 27.0.1、arm64、Python 3.11.15、源码安装跟踪上游 v0.21.6）上确认了删除可复现，并带来新信息：在当时的 main 分支上，清理已经会写日志了——每删除一个条目，就在用户主目录的 logs/scratch-prune.log 里写一行路径加字节数，这位用户的日志里已经积累了 211 条删除记录，时间跨度从 10 月 9 日 14:20 到 10 月 11 日 15:33。原始报告者据此核对时间线并做了归属修正：逐条日志能力是通过另一个 PR 在 10 月 6 日合入的，它取代了报告者自己更早提交的方案，后者在同一个小时被关闭未合并。

到 10 月 16 日 21:46（UTC），维护者合并了最终修复并留下关闭说明：清理机制现在在删除前重新检查整个子树，在最终检查前测量条目大小，并为每一条删除写入审计行。但同一个评论里也明确了边界——issue 关闭了，两件事没有做：活进程的工作目录守卫（防止清理器杀掉 cwd 位于待删条目里的存活进程）和保留标记文件（让智能体能主动声明"这个目录别动"）这两项政策级设计，仍然挂着 needs-decision 等维护者拍板。换句话说，审计可见性已经落地，但"防误杀"和"用户可控保留"这两层防护还没有承诺。

十四天，从一个"五份交付物无声消失"的事故报告，走到"每次删除都有审计行"的落地，中间隔着社区两次独立取证、一次方案竞争和一次归属修正。这个节奏在开源项目里不算慢，但它暴露的结构性问题值得每个自建智能体系统的团队记住：当你给智能体指定了一个"工作区"，同时又对这个工作区执行任何形式的自动清理，你就欠下了一笔信任债——这笔债的利息，以"用户永远不知道东西是什么时候、被谁、为什么删掉的"方式计价。

同一天的镜像：静默丢件与 2131 万 token 的账单

把视线移到同一天生态的另一端。OpenClaw 在 10 月 17 日的雷达快照里同样维持着极高活跃度：过去 24 小时 Issue 更新 500 条（新开与活跃 377，关闭 123），PR 更新 500 条（待合并 235，已合并或关闭 265），并发布了新版本 v2026.10.4。但快照同时记录着另一个事实：P0 列表里 8 项问题全部没有修复 PR，社区最热的 issue 已经积累了 131 条评论——SQLite 的 WAL 日志文件在 Windows 上数天内膨胀到 1.4 至 2.8 GB，自动检查点失效并阻塞网关启动。

而在"信任型 bug"这个类别里，OpenClaw 有一件与 #132401 精确镜像的事：#112259，一条对用户可见的入站消息（报告场景是 iMessage 私聊，但路径是通道无关的）可以被消息通道内核接受，然后被静默丢弃——分发执行了但回复载荷为零，没有智能体运行被创建，没有内容被写入会话记录，发送方收不到任何回复也收不到任何错误。整个过程留给运维的唯一痕迹，是一行警告日志。没有重试，没有死信队列，没有用户可见的失败提示。

这个 issue 从 7 月 21 日报告至今仍然 open，挂着 P1 和"影响：消息丢失"标签。它的存在说明静默失败不是某一个项目的实现疏漏，而是这类"常驻运行、接入消息通道"的智能体系统的共性风险敞口：消息管道越长（通道接入、会话路由、智能体调度、回复分发），“某一环吞掉了消息但没人知道"的组合空间就越大。

值得注意的是这条路径上"接受"与"丢弃"之间的落差。报告描述的失效形态是：通道轮次内核接受了这条入站消息——它通过了通道层的校验、进入了分发——但分发执行后回复队列为零载荷，于是没有任何智能体运行被创建，也没有任何会话记录被写入。对系统内部而言，这是一次"成功执行的分发”；对发送方而言，这是一次石沉大海。这类失效最阴险的地方在于它不会触发任何告警阈值：没有错误码、没有重试计数上涨、没有失败率指标波动，唯一的痕迹是日志级别里最低调的那一行警告。运维侧的常规监控对此完全失明。

与它同族的还有并发场景下的丢回复。同一天雷达快照的社区热点区里，另一个 issue 记录着：同一会话内并发发起的多个运行，会产生"没有活跃的工具授权快照"错误，最终表现为回复直接丢失。消息丢失类问题在两个项目里都不是新面孔，但它们在这一周期集中浮现，与统一网关架构的落地节奏直接相关——当所有本地会话收敛到一个网关进程统一管理，任何会话状态机的并发缺陷都会被放大到所有接入面。

如果说消息丢失伤害的是信任，那么另一类静默失败直接伤害钱包。OpenClaw 的 #143017 是成本观测类 issue 里数据论证最扎实的一个：报告者在 2026 年 9 月 2 日之前的三天窗口里，对一个七智能体舰队做了全量测量——103 个会话、4373 次 API 调用，发生了 254 次缓存前缀重写，总共烧掉 2131 万 cache-write token，而同期全部缓存写入总量是 5206 万。也就是说，超过四成的缓存写入花费在了"重写本可复用的前缀"上。测量方法是逐调用日志：记录整个系统提示的 SHA-256 摘要和实际提交的工具名列表，按会话拼接比对。Anthropic 的缓存按"工具定义、系统提示、消息历史"的顺序逐级命中，所以会话历史一旦发生前缀重写，整段活会话的消息历史都要重新计费写入。

这类问题的意义在于度量单位的变化：在传统软件里，bug 的代价是功能错误；在智能体系统里，bug 的代价可以直接换算成美元——一次投递逻辑错误等于一批配额蒸发，一次前缀重写等于整段会话历史重新计费。快照对这一趋势的概括很精辟：成本即正确性。当缺陷直接体现在账单上，成本遥测就不再是可选项，而是智能体基础设施的标配组件。

把两个项目同期的"信任型"问题并排放着看，模式会浮现得更清楚：

五个问题横跨两个项目、三种子系统（存储、消息、成本），但共享同一个失效模式：某一步操作失败了、或者做了不该做的事，而系统里没有任何一个角色能看见。这就是"信任债"的技术定义——不是错误本身有多严重，而是错误的发生、过程和后果全部不可观测。修复它们的方式也高度一致：可审计（每次删除写日志）、可恢复（隔离区代替直接删除）、可声明（保留标记让用户能说不）。这三个词值得写在每一个准备自建智能体系统的团队的白板上。

时钟跳变两连修：从心跳判定到单调时钟的系统性防御

雷达快照记录的第三个收敛方向，藏在一个看起来很底层的话题里：时钟。

OpenClaw 在 10 月 17 日发布的 v2026.10.4，头条修复就是时钟问题：电脑休眠或系统时钟跳变后，网关不再因为所有权心跳判定过期而自我重启，改为持续运行。对应的 PR #170790 在 10 月 13 日合并，修复说明写得很清楚：宿主机休眠或时钟向后跳变后，网关的所有权状态曾被永久锁死，数据库支撑的工作全部不可用，而健康检查却仍然报绿。这个修复一口气关掉了三个关联 issue。

Hermes Agent 走得更远，也更未竟。PR #134672 提出把分发路径上所有的时间测量从墙上时钟迁移到单调时钟：退避等待（中断式退避睡眠）、流式响应的存活检测（流停滞探测器）、非流式请求的看门狗（首字节超时和进度超时杀）、以及 Codex 运行时的停滞计时——全部改用单调时钟基准。动机是结构性的：墙上时钟会被 NTP 前跳或回拨、会被宿主机休眠打断，任何用墙上时钟做超时判定的机制，在时钟跳变瞬间都会产生错误判定——要么把活着的连接判死，要么把死掉的连接判活。值得注意的是这个 PR 的覆盖面设计：它没有挑一两个最痛的路径修，而是把"所有用时间差做判定的分发路径"一次列全，属于典型的根因级修复提案——这也是它值得单独观察的原因，即便合并时点仍不确定。

同一个项目里，时钟问题的另一种形态刚刚以事故收场。#138343 是一个两段式事故报告：第一段，宿主机网关被 SIGKILL 后（不干净死亡），重启的网关撞上了一个已被系统回收再利用的进程号，守卫机制把这个回收 pid 误判为"前一个实例还活着"，于是拒绝启动，进入永久重启循环；第二段，循环期间陈旧的异步委派投递仍在发生，持续烧掉供应商配额。报告时间 10 月 14 日，对应修复 PR 在处理路径上，issue 已于 10 月 16 日 21:46 关闭。这个事故把时钟与身份两个主题拧在了一起：pid 是身份，心跳是时钟，两者在异常路径下的组合误判，足以让一个守护进程陷入自我否定的循环。它也再次印证了上一节的判断——智能体基础设施里的"信任"不仅指对数据的信任，也指系统对自身状态的正确认知。

这里需要一段诚实的勘误。雷达快照在横向对比一节里写"Hermes 同期已系统性落地单调时钟迁移消除同类时钟跳变问题"，本文写作时对该 PR 做了实时核验：截至发稿，#134672 仍处于 open 状态，尚未合并。快照的说法超前于事实——迁移提案存在、方向正确、与多个历史停滞类 bug 相关联，但它还没有落地。智能体生态的观测数据本身就带着时滞和误差，这是读任何日报快照都该保留的清醒。

时钟问题家族在两个项目里的分布，可以列成一张小表：

这类问题的共同教训是：常驻运行的智能体系统，必须按分布式系统的标准对待时间。一台每天合盖休眠的笔记本电脑，对软件来说就是一个会随机暂停又随机快进的世界；一次 NTP 校时，就是一次所有基于时间差的判定都要重新审视的事件。心跳、租约、超时、看门狗——这些分布式系统里打磨了二十年的机制，移植到个人设备上时，还要额外对抗"宿主机会睡着"这个数据中心里不存在的变量。

修复债务的两种消化法：campaign 批量推进与 needs-decision 队列

快照里还有一个值得展开的对照：两个项目各自怎么消化积压的修复债务。

OpenClaw 的答案是个性化 campaign。核心贡献者以近乎工业化的节奏批量提交重构与性能优化 PR，大量标注 campaign batch 字样。效果有实测数字背书：其中一个 UI 性能 PR 让控制界面关闭菜单后的聊天重载阻塞实测降低 34%。这种模式的优点是密度高、可复制——同一 subsystem 的一族问题在几天内被成批处理；快照的评价是它证明了"批量专项"这种工程管理形式有效。但它同时暴露了资源错配：性能 campaign 跑得飞起的同时，8 项 P0（几乎全部集中在 Windows 平台、更新路径、SQLite 存储层）没有任何修复 PR，其中多项还挂着自动化巡检打上的"无新修复 PR"标签。一个未被消化的最热 issue 是 #143524：SQLite WAL 膨胀，131 条评论，讨论量是第二名的近五倍，报告者提供了完整的 WAL 取证，社区技术素养极高——但修复供给没有跟上。快照给这个项目开出的健康度评级是黄：交付速度极高，修复债务结构性累积。

Hermes Agent 的答案是一个显式的决策队列。三个挂着 needs-decision 的重量级 issue 排在队列里：P0 数据丢失（就是本文第一节那个，现已关闭）、P1 看板调度卡死、安全类凭证落盘。决策流程本身是透明的——任何人在 issue 列表里都能看到哪些事在等谁拍板——但队列的存在本身就说明吞吐受限：Issue 开关闭比约为 4.4 比 1（368 条新开活跃对 83 条关闭），新问题涌入速度超过修复速度。快照同样给出黄评级，但理由不同：修复 PR 补给充足、决策管道清晰，可发版纪律拖了后腿——v0.22.x 系列带着已知问题连续发版，更新链路的 404 和挂起问题让源码安装用户反复受挫。

两个消化法没有优劣，只有适配。campaign 模式适合债务同族、可批量复用上下文的场景（性能优化、API 迁移）；决策队列适合需要产品判断的场景（数据保留政策、安全边界、破坏性变更）。真正的风险是把两者混用错位——用 campaign 的速度标准去要求决策类问题（会逼出仓促拍板），或者用决策队列的严谨去堵 campaign 的流水（会让批量效率归零）。快照给两边维护者的建议是同一个句式：把 campaign 模式复制到 Windows 可靠性与存储治理两簇债务上。这个建议背后的判断值得记住：修复债务本身也可以被工程化管理，前提是先承认它是债务、给它分簇、给它指定消化方式。

还有一个信号值得补进这幅图景：记忆子系统。两个项目在这一周期同时出现了"让智能体在空闲时自动整理记忆"的需求——一边是 5 月提出至今仍在活跃讨论的后台记忆整合提案（受生物睡眠周期启发，让短期会话记忆在安静时段整合为长期记忆），另一边是记忆文件写入的预算与验收管线讨论。同一个方向在两个独立社区并行涌现，通常意味着这是一个真实且尚未被满足的产品需求。但快照同时记录了它的反面教材：一边的"记忆整理运行"被报告会把网关主线程钉死约十分钟、期间零日志输出、通道全部掉线，外部看门狗在多次运行中观察到 566 到 679 秒不等的无响应时长，且因为运行永远无法完成，短期记忆存储从未成功持久化——一个为提升记忆质量而生的功能，落地成了记忆永远丢失的机制。这几乎是对"后台整合"这个方向最精准的风险预告：任何在事件循环里做重活的子系统，都会成为下一个 P1。

两项目当日活跃度数据并排如下，作为本节的证据锚点：

写在最后：当地基竞赛进入深水区

三个方向的材料摆完，可以收拢成这一天生态快照的完整判断了。

个人智能体赛道已经进入平台化深水区。两个头部项目都完成了或正在完成统一网关运行时级别的架构重构，日常以每日数百条 Issue 和 PR 的节奏迭代。功能层面的竞赛基本结束——多平台消息接入、插件生态、多端界面、任务编排，两边都有。接下来的分水岭是可靠性，而可靠性问题的分布高度收敛：持久会话状态一致性、跨平台可靠性（尤其 Windows）、存储层治理、静默数据丢失，四个方向占了压倒性多数的高优问题。

在这些收敛的方向里，最值得单独强调的是"静默失败"这个类别，因为它惩罚的不是系统而是信任。一个删除用户工作成果但不留日志的清理器，一条吞掉消息但不报错的管道，一次烧掉配额但不留痕的投递——这些问题的修复成本未必最高，但它们造成的损害最深，因为用户失去的不是某次结果，而是"系统行为可预期"这个前提。#132401 十四天的完整弧线——从无声事故，到社区两次独立取证，到日志落地，到删除前重查与审计行合并，再到两项政策级防护留待决策——可以当作这类问题从爆发到收口的参照模板。模板的核心一课：先补可见性，再补防护性。日志先行的价值在于它把"不可见的伤害"变成"可统计的伤害"，而后者的优先级才有机会被正确评估。

对准备自建或已在使用智能体系统的读者，这一天的材料指向几个可立即执行的检查项，它们不需要等待任何上游修复。检查你的系统里智能体的工作区是否有自动清理策略，清理是否留日志；检查消息通道有没有死信或重试机制，还是静默吞掉失败；检查缓存计费异常是否有遥测，前缀重写率能不能被观测到；检查所有超时判定用的是墙上时钟还是单调时钟，宿主机休眠后租约类机制的行为是否经过验证。这些问题在两个最活跃的开源项目里都以真实事故的形态出现过，自建系统没有任何理由假定自己免疫。

最后交代本文的证据边界。主体素材来自 2026 年 10 月 17 日雷达快照（GitHub API 采集窗口 10 月 16 日至 10 月 17 日），涉及的关键 issue 与 PR 状态在发稿前做了实时核验：#132401 已于 10 月 17 日 04:21（UTC）关闭，关闭时点的修复合入信息以维护者评论为准；#134672 截至发稿仍为 open，快照中"已系统性落地"的表述与实时状态不符，本文已按实时状态修正；OpenClaw 各 P0 的修复状态以快照时点为准，其后可能已有变化。开源仓库的每小时都在移动，任何快照都是切片而非全景——读快照的意义不在于记住数字，而在于从数字里认出自己系统里正在发生的同一类事。