开源AI双雄：WAL膨胀、网关合并与慢思考误杀

2026年10月16日，两个最受关注的个人AI助手开源项目同时出现在同一张数据表的两端。过去24小时，OpenClaw 的 GitHub Issue 更新量是500条，其中新开与活跃374条、关闭126条；同一天 Hermes Agent 的 Issue 更新量是466条，其中新开与活跃416条、关闭50条。两个项目都在为同一个产品形态——常驻运行、接入消息通道、跑定时任务的个人智能体——抢跑，但这一天各自的烦恼截然不同：OpenClaw 最热的 issue 已经积累了131条评论、被官方打上发布阻塞标签，一个数据库文件卡住了整个版本的发布；Hermes 刚把历时五周的统一网关运行时合进主干，正在承受架构落地后的修复洪峰。

这两个烦恼都不是孤例。把两边同一周的问题清单摊开看，会看到一种奇怪的镜像：OpenClaw 当天的三个 P0 全部压在存储与数据层——SQLite 的 WAL 日志文件无限增长卡死启动、外部插件捕获让网关阻塞数分钟、卡死的 agent 数据库资源拖垮所有 agent 回复；而 Hermes 的压力中心则在另一个方向——凭证误发、环境快照落盘、凭证存储可被 agent 自毁。一边在跟存储层搏斗，一边在跟权限边界搏斗。两边都在"单机多会话"这条架构路线上全速前进，也都在各自的地基处漏水。

这张表是当天两边核心数据并排的样子：

需要说明的是，单日快照会被窗口内是否有批量清理动作影响，前一天的 OpenClaw 关闭数还是190条，本文所有对比结论都应在这个前提下适当收敛强度。另外表里两边的"PR 更新 500 条"恰为同值，这是统计工具的单日采集上限（两边当日活动量都顶着上限跑），实际活动量只会更多，对比时应视为下限而非精确值。

先交代两个项目在赛道里的位置。OpenClaw 走的是"自研化收敛"路线：网关中心化架构、存储层迁 worker 线程、Control UI 从第三方组件栈迁向自研渲染，目标用户是重度自托管与多 agent 集群部署的生产玩家——所以它的 extended-stable 类 LTS 发布通道、CI 降本（一个 PR 每小时省约5分钟 CI 时间）这类"基建自留地"动作格外密集。Hermes Agent 走的是"统一架构落地"路线：Ink TUI 加 Desktop 双前端、多消息通道投递（Telegram、WhatsApp、Signal 类）、Plugin Catalog 社区插件目录，目标用户偏个人助手向——所以它的注意力在"一个 gateway 管所有本地会话"这种把入口收敛到极致的架构上。路线不同，这一周撞上的麻烦却呈现出跨路线的共性：常驻进程的存储层、agent 的权限边界、慢模型对超时机制的冲击——这三类问题不属于任何一条路线，属于这个产品形态本身。

一个 WAL 文件，131条评论：发布阻塞背后的存储债

OpenClaw 的 #143524 是这个社区当前愤怒值最高的 issue。标题很直白：Agent 的 SQLite WAL 文件在几天内膨胀到 1.4–2.8 GB，尽管设置了 wal_autocheckpoint=1000，checkpoint 从不真正完成，最终 Gateway 无法启动。受影响版本是 Windows 上的 2026.9.2/9.3。131条评论、9月9日开到现在，官方标签里挂着 impact:ux-release-blocker——发布阻塞级。

这个 issue 蹊跷的地方在于它的标签组合：clawsweeper:fix-shape-clear 说明社区自动分类机器人已经判断修复路径清晰，clawsweeper:no-new-fix-pr 说明修复 PR 迟迟没有出现。换句话说，不是不知道怎么修，是修的人还没腾出手。

要理解这个问题的顽固，得先看 SQLite WAL 模式的工作方式。WAL（Write-Ahead Log）把写操作先追加到日志文件、再择机合并回主库，换来读写不互斥的并发性能。合并这个动作就是 checkpoint，而 checkpoint 有一个天然的限制：它只能推进到最老的活跃读事务的快照为止。只要有一个读事务迟迟不结束，它后面的所有 WAL 帧就只能留在文件里，日志越长、新 checkpoint 要扫描的内容越多、文件继续涨。教科书里这是并发数据库的一行小注脚；在常驻运行、多线程并发读、用户从不重启的智能体网关里，它是会让发布停摆的 P0。

社区花了一个多月把这条因果链钉死。10月3日的 #164294 指出第一环：WAL auto-checkpoint 永不完成，因为进程内有一个长驻 reader 把 WAL 钉住了。10月14日的 #172091 补上第二环：一个 worker 线程的 SQLite 事务在一个永远无人应答的跨线程 admission 等待后面保持打开状态，把共享状态的 WAL checkpoint 永久阻塞。三个 issue，三个表面症状（文件膨胀、checkpoint 失败、事务挂起），一条因果链：长事务钉住 WAL。把这条链连起来看，#143524 里 wal_autocheckpoint=1000 设置失效就不神秘了——参数本身没错，是它的工作前提被破坏了。

发布节奏也受到牵连。10月15日发布的 v2026.10.10-beta.1 的 release notes 里专门提到，chat turn、会话列表、启动和空闲 Gateway 的 SQLite 与主线程工作被大幅削减、更多数据库操作迁移至 worker 线程，并建议多 agent 部署用户优先验证。同日合入的 #173415 优化了 dashboard 深链刷新风暴下的配对队列，PR 描述里记录了优化前后的实测：浏览器 attach 的 p90 从 703.0 毫秒降到 16.1 毫秒，node 进程的 p50 从 1197.9 毫秒降到 462.9 毫秒——campaign 证据里报告的 attach p90 是 12.4 秒。这是对 WAL/checkpoint 问题族的首批系统性回应——把数据库操作从事件循环里挪走，釜底抽薪。但最热的 #143524 本身，截至今日快照仍无对应 fix PR。除它之外，#160959（外部插件捕获阻塞事件循环）同样处于无 fix PR 状态；第三个 P0 #157325（卡死的 agent 数据库资源让所有 agent 回复失败直至重启）有一条在途修复 PR #157693 尚未合入——三个 P0 全部压在存储与数据层，其中两个还在裸奔。

这个月的演进轨迹里还有一条暗线：beta.1 的 release notes 出现了完整的 PostgreSQL 兼容层描述——从 SQLite 规范生成 PostgreSQL DDL、带能力准入和精确 schema 漂移检查的迁移路径。等于在 SQLite 后面垫了一层逃逸出口。当单机文件数据库的物理极限被多 agent 负载顶穿时，这是基础设施软件的标准动作：先做缓解（worker 线程化），再做替代路线（可迁移的存储引擎）。

每次命令重写1.4GB：为安全审计付出的SSD寿命

存储债的第二张面孔在 #157989：插件源捕获机制每次 CLI 命令执行都重写约 1.1–1.4 GB 数据，每次 Gateway 启动约 6.5 GB，无任何复用，对 SSD 造成严重磨损。18条评论，P1，挂着 needs-maintainer-review。

社区的不满在于这个机制的实现选择本身。插件源捕获是2026.9.5 起引入的供应链安全机制：把外部插件源完整捕获存档、做全量哈希，确保运行时插件源与声明一致。方向没有问题——智能体框架加载第三方代码，完整性校验是应有之义。问题在执行频率：字节级拷贝加全量 SHA-256 哈希，每次 CLI 命令执行都全量重做一遍，即使插件一个字节都没变。对一个每天执行数百条命令的重度用户，这意味着每天几百 GB 的无谓写入。SSD 磨损成了安全审计的隐性成本，而审计对象——插件源二进制——大多数时间纹丝未动。缓存一个"源未变更"的判定，本可以把这笔成本砍掉三个数量级。

同一机制还引出了另一条 P0 回归。#160959：2026.9.6 起，捕获大型外部插件会让 Gateway 阻塞数分钟，启动即卡死，25条评论。捕获发生在主线程还是后台、大插件（issue 标题点名 bundled native binaries，捆绑原生二进制的大型插件）的捕获为何不增量——这两个问题叠加，让"装了外部插件"的用户每次启动都要赌一次 Gateway 是否还活着。

把 #143524、#157989、#160959 三个存储层相关 issue 放在一起看，结论比单个 issue 清楚得多：当"个人智能体"从演示产品变成常驻基础设施，存储层的设计欠账会最先暴雷，而且暴雷的方式不是性能慢慢变差，是文件膨胀阻塞启动、写入放大磨损硬件、主线程卡死这类直接影响可用性的硬故障。这也是为什么这三个 issue 全都挂着 needs-maintainer-review——社区诊断已经完成，等待的是架构级的裁决：捕获机制要不要缓存、checkpoint 要不要强制、数据库操作要不要整体迁出事件循环。这类决策没有社区补丁的腾挪空间。

统一网关落地两天后：修复洪峰与两条安全旧账

Hermes Agent 这边的头条是架构。PR #106742——统一网关运行时，目标是"一个 gateway 拥有所有本地会话"，classic CLI、TUI、Desktop、API、ACP、bots、cron 全部收编——10月14日合进主干，9月9日开出，历时五周，合并时已积累82条评论。配套的跟踪 issue #134889 在10月8日建立，到10月16日快照已积累148条评论，标签 P0，是当前全项目注意力中心。

148条评论的跟踪帖意味着什么？意味着架构合并不是终点，而是新一轮问题的起点。当日活跃的修复 PR 清单能看出洪峰的形状：会话 checkpoints 与仓库信任 skills 的 slash 命令遵循（#139483）、后台插件发现保持在所属 profile 上下文以修复 ContextVars 丢失（#139484）、Bedrock thinking prefix 绑定拒绝的恢复处理（#139482）、503/529 配额墙从退避改为 fallback 以改善多凭证网关体验（#136726）、限制后台 review 的 replay 上限并禁止与活跃 turn 重叠（#124836，源于一起 205k token 的成本事故）。这些修复指向同一个事实：一个 gateway 接管一切，也就意味着一切问题都会汇聚到这个 gateway 上——上下文传递、插件隔离、配额路由、后台任务对活跃会话的干扰，每一类边界都要在新架构下重新画一遍。

但这边更值得盯的是两条从7月挂到今天的安全旧账。#62336：终端环境快照会把含凭证的环境变量写入磁盘，13条评论，needs-decision，7月10日开。#70942：auth.json 不在构建的写拒绝路径里，agent 自己的 write_file/delete/move 操作可以摧毁它的凭证存储，8条评论，7月24日开。两条都是"agent 的权限边界应该止于何处"这个问题在两个具体文件上的投影——一个问"agent 能不能看"，一个问"agent 能不能毁"。三个月的积压时长说明这个问题的答案并不便宜：写拒绝路径清单每加一项，就要有人论证 agent 在什么正当场景下需要写这个文件的邻居；环境快照要脱敏，就得先定义哪些变量名该被视为凭证——这些都是策略决定，不是一个补丁能带过的。

10月15日新报的 #138843 把这个主题又加深了一层：会话级 provider 覆盖保留了 profile 里过期的 model.base_url，导致新 provider 的密钥被发往旧 provider 的端点，401 报错。这是一个凭证误发问题——密钥没有泄漏给攻击者，但发给了不该收的第三方服务。如果旧端点属于一个不再受信任的归属方，性质就从 bug 升级为安全事件。这个 issue 的结局是个小亮点：10月15日开出，10月16日关闭，state_reason 为 completed，一天内闭环。对比前面两条7月旧账，能看到这个项目在"新问题响应"与"旧账偿还"之间的速度差——日结能力已经具备，欠账的利息还在滚。

版本故事也是同一个主题的重复。v0.22.1 因为从一个错误的 commit 构建——误带了未发布的 gateway 改动——被 v0.22.2 在一天内取代，v0.22.2 就是 v0.22.1 本应发布的版本，官方建议所有用户跳过 v0.22.1。发布工程的脆弱性（哪个 commit 进了构建、构建后能否回滚）和存储层的 WAL 问题一样，都属于"功能跑得越快、地基越要响"的债务类型。对照组是 OpenClaw 的三通道发布：beta 快车道、beta 修复版、extended-stable 类 LTS 通道（含9月底代码加关键安全更新，仅 Gateway），生产用户有平滑升级路径。版本通道分层与可回滚，正在从加分项变成生产级智能体项目的必备能力。

维护吞吐的差距也在拉大另一个方向的注意。同日 OpenClaw 合并/关闭了286个 PR，Hermes 是123个，前者约为后者的2.3倍；Hermes 侧待合并 PR 高达377个，其中大量是长期挂起的社区 PR——例如8月开出、已 rebase 到最新 main 的工具输出引用链 #78090，8月起的 child lineage 清理 #87668。更棘手的是 #131859：外部贡献者通过 API 创建 PR 时被 CreatePullRequest 权限错误挡住，42条评论，标记 blocked——贡献通道本身被阻塞，这是比单个 bug 更伤生态的问题。评审带宽是串行的人力瓶颈，这个问题两个项目都逃不掉，只是在合并洪峰里的 Hermes 侧显得更尖。

token 成本是两条路线共同的第四条暗线。Hermes 侧 #124836 的直接起因就是一起 205k token 的后台 review 成本事故——后台重放的 review 与活跃 turn 重叠，一次性烧掉一个中型项目一个月的用量预算；OpenClaw 侧的对应物是 #67419：会话引导文件每轮重新注入，白白消耗 20 到 30 个百分点的 token，12条评论的讨论里社区反复在问"为什么 bootstrap 内容不能跨轮复用"。同一个问题的第三张脸是 #101929：上下文溢出预检的估算器把计费用量高估了约 2.3 到 2.6 倍——估算器按每字符两 token 折算未截断的完整转录，而计费用的是截断后的实际内容，结果是预检频繁误判"上下文快满了"并触发不必要的压缩。三个 issue 指向同一个结构性事实：智能体框架的 token 消耗不再只由对话长度决定，还被框架自身的机制设计（重放、注入、预检）放大或虚增，成本可观测性正在成为框架的基本功，而不是锦上添花。

多 agent 协作是问题清单之外最亮的一条功能线。Hermes 侧当天新开了 #139479 walkie-talkie 插件：允许一个 Hermes 会话向另一个既有会话——Telegram topic、群线程、私聊——发送消息并唤醒对方携带完整历史的执行，已进入 Plugin Catalog 流程；配套的还有 #87668（owner 启动时清理继承的 child lineage 标记，修复委派子进程误判）。OpenClaw 侧的对应物是记忆子系统重构：#173468 消除共享 memory 目录的重复扫描以降低空闲网关的事件循环压力，加上 per-agent dreaming 配置的诉求 #67413（解决全工作空间同时 dreaming 导致内存耗尽）。两条线合起来看，“多个 agent 共存于一台主机"已经从演示走入了工程现实：谁跟谁说话（会话互唤）、谁的记性归谁管（记忆隔离）、谁清理谁的痕迹（lineage 回收），每一问都同时是功能问题和资源问题。这也是为什么网关统一化在两个项目里同步推进——多 agent 的前提是多会话有一个共同的归属点，而归属点本身，又回到了存储层和权限边界这两个本周的主角。

30秒watchdog误杀慢思考：推理模型倒逼超时机制重构

两个项目共享的第三类烦恼，是深度推理模型对既有超时机制的冲击。OpenClaw 的 #68596 是个4月份就开出的 feature request：流式 watchdog 超时阈值硬编码为30秒、写死在客户端 UI，无法在服务端配置。当模型——issue 里点名 kimi-k2.5、DeepSeek-R1——进入深度思考阶段、30到60秒以上不产出流式输出时，watchdog 就会告警：流式 watchdog 已30秒无更新，正在重置状态，后端可能已静默丢弃此次运行，请发送新消息以重新同步。用户被引导去 resync，结果打断正在进行的推理、触发重复查询、破坏会话上下文。

报告者已经把能试的绕路都试了：把 agents.defaults.timeoutSeconds 配到 1200 秒（20分钟的 agent 总超时）、把 reasoningDefault 设为 stream（流式输出推理内容）、把 blockStreamingChunk.minChars 调到 20（更细的分块粒度）——客户端 watchdog 依然独立触发。因为这三个参数分别管总超时、推理流、分块字符数，没有一个能碰到 watchdog 阈值本身。issue 请求的方案也很克制：在 openclaw.json 里加一个 noOutputTimeoutMs 配置项，默认 30000，允许调高；再加一个 enabled 开关，允许纯回环可信环境直接关掉。

这个 issue 拿了8个赞同、17条评论，从4月18日开到现在，当前标签是 stale。一个与深度推理模型普及直接相关的可用性诉求，在 staleness 机制下慢慢沉底。它不是一个孤立的体验抱怨——Hermes 那边同一天合入的 #139482（Bedrock thinking prefix 绑定拒绝的恢复）处理的是同一族问题的另一面：模型思考时间变长之后，思考内容的前缀绑定被拒绝时如何恢复。OpenClaw 的 issue 列表里还有同主题的第三条线索：#121953，DeepSeek 的 cron 任务因思考前缀被降优先级导致任务卡顿。这条 issue 的细节几乎像个黑色幽默：OpenClaw 给每条 cron 任务的 agentTurn 用户消息加了 [cron:<jobId> <jobName>] 形式的前缀用于路由和溯源，而 DeepSeek 的 API 边缘节点会把以此前缀开头的消息降入低优先级队列——结果就是用 DeepSeek 跑定时任务的用户，任务卡顿数十秒到数分钟，而罪魁祸首是一个本意用于可观测性的消息前缀。社区验证过不触发降级的替代写法（比如把前缀换成 [Cron:...] 或 [job:...]、或挪到消息尾部），但修一个消息格式要过兼容性测试，8月11日开的 issue，14条评论，仍在等维护者拍板。框架的路由约定与模型的边缘节流策略在应用层相撞——这种跨系统边界的故障，单看任何一侧的文档都解释不了，也正是智能体工程独有的问题形态。

当推理模型把"30秒无输出"从异常变成常态，所有为快模型设计的超时假设都在失效。

watchdog 的本意是检测静默失败——后端进程死了、连接断了、运行被丢弃了，30秒无输出确实是最直接的信号。但在慢思考场景里，它误杀的恰恰是最有价值的推理过程。这类问题的工程解法在两个项目的 issue 轨迹里已经显形：把超时阈值做成可配置只是止血，真正的方向是心跳与输出解耦——用带外的存活信号证明模型还在想，而不是用无输出推断已死亡。#68596 报告者请求的 enabled 开关，本质上就是给这条原则留的活口：在可信部署里，宁可放弃这层保护，也不要它打断合法的长推理。

把这个现象放回更大的背景里，它是整个智能体生态与新一代模型磨合的缩影。深度推理模型改变的不只是回答质量，还有运行时假设：首 token 延迟从秒级放宽到分钟级、流式输出的语义从"持续有字"变成"长时间静默后突然成段”、超时参数从全局常量变成需要按模型族配置的变量。框架侧每一处写死的阈值，都会在某个新模型发布的那天变成一批误报。这不是哪一个项目的问题，是所有常驻智能体框架的公共考题。

当周问题清单的结构对照：债务分布的镜像

把两个项目这一周的核心问题并排放好，能看清各自的债务分布：

Windows 是两个项目共同的欠账名单。OpenClaw 侧，#143524 的主受害平台就是 Windows，受影响版本 2026.9.2/9.3 均为 Windows 部署；#170956 记录的是另一幅图景：启动慢、插件关闭不干净、schtasks 权限报错三症并发，让重启和更新在 Windows 上变得极不可靠，9条评论，P1，10月13日新开。#164799 则是 Windows 更新体验的第三连击：版本变更后 agent 逐个 admit 需要数分钟，readyz 健康检查一直 503 直到重启，10月4日开，10条评论，已有部分相关修复 PR #173482 在途（关闭临时 SQLite reader 保持响应）。Hermes 侧，#122935 是 hermes update 在 Windows 上留下的 DACL 硬化后遗症：更新后 tools 目录的自主访问控制列表被收紧，非提权登录进程执行 python 和 node 直接报 WinError 5 拒绝访问，9月25日开，11条评论，暂无修复 PR；7月20日开的 #68128（WhatsApp 桥接进程在 no-breakaway job object 里 spawn 失败，同样是 WinError 5）至今13条评论悬而未决。把这几条 issue 摆在一起，能看出 Windows 欠账的两种成因：一种是平台差异带来的真实工程量（DACL、job object、schtasks 这些 Windows 原生机制与开源工具链的磨合），另一种是测试覆盖缺口——CI 矩阵里 Windows 的权重，直接决定了这些 issue 的发现时机是发布前还是发布后。

把这个现象说得更直白一点：两个项目的核心维护者和重度贡献者大多在 macOS 与 Linux 上开发，Windows 用户却是安装量的重要组成部分。贡献结构与用户结构的错位，是开源桌面软件的经典困境，智能体框架把它继承了下来。率先补齐 Windows 体验的项目，会拿到一波可观的用户迁移——这不是猜测，#143524 里131条评论中大量受影响用户明确表示正在评估替代方案。

对照之下还有一类反差值得写：哪些问题被快速关掉了。Hermes 的 #137646（update 稳定通道解析失败，git merge-base 探测超时）当日报当日关；OpenClaw 的 #136262（流式 text_delta 导致消息内容翻倍）也已关闭。快速关闭的共同点是单点、可复现、修复路径唯一；长期积压的共同点则是要么涉及架构裁决（存储层），要么涉及策略定义（安全边界），要么需要跨版本数据迁移（更新链路）。一个项目的 issue 年龄结构，比它的 issue 总量更能说明它处在哪个阶段。

回到这张表本身，还有一个方法论层面的提醒。表里的"最热 P0"两栏，评论数都在一百条以上，但热度与严重度并不等价：#143524 的131条评论里有大量受影响用户的复现报告，而 #134889 的148条评论里很大一部分是修复进度的跟踪讨论——前者是痛的共鸣，后者是修的协作。同样，“维护吞吐"一栏的25%对11%，前文已经说过受窗口影响，这里再补一层：关闭率高也可能意味着问题浅（好关），关闭率低也可能意味着问题深（难关），数字背后的 issue 年龄分布、reopen 率、带 fix PR 的比例，才是判断健康度的下一个粒度。把 GitHub 活动数据当体检报告用，最忌讳的就是只看单日单项指标下结论——这张表的价值在结构对照，不在任何单独一格。

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

这一周的信号足够清晰。第一，存储层是下一个竞争焦点：OpenClaw 用三条 P0 证明了常驻智能体对存储引擎的要求——WAL 管理、checkpoint 策略、状态迁移原子性——远超普通桌面应用，beta.1 的应对是把数据库操作迁出主线程并准备 PostgreSQL 逃逸出口；率先做出 agent 原生存储引擎的项目会拿到差异化能力。第二，权限边界必须前置设计：Hermes 的两条7月安全旧账和一条新闭环的凭证误发 issue 说明，agent 能读什么、能写什么、能毁什么，这些边界如果不在第一版架构里就画好，后面每一版都在还债。第三，慢思考模型是所有框架的公共考题：30秒 watchdog 从合理默认变成误杀之源，超时可配置只是止血，心跳与输出解耦才是解法。

这些判断的边界也要说清。本文所有数字来自 2026-10-16 GitHub 公开快照，issue 评论数、状态、标签都以快照时点为准，几条主线 issue 的评论数在写作期间还在增长——#143524 在前一天的数据里还是125条，本文采用的是当日核实值131条；两个项目都处于高速迭代期，今天的债务结构明天就可能因一次集中修复行动改变。单日窗口的关闭率对比不构成选型依据——它是一个观测方法，不是一个结论。如果你要使用这套方法，把同样的统计窗口连续跑两周再下判断，单日数字只配当线索，不配当证据。

还有一个视角值得留给读者自己去跟踪：两家对同一类问题的应答速度差。#68596（4月的 watchdog 请求）挂上 stale 标签沉底的同一天，Hermes 把同类问题的修复合进了主干；Hermes 的 #138843 式一天闭环在这边是常态，在 OpenClaw 那边是新闻。应答速度不等于工程质量——前者反映维护带宽的分配，后者反映架构决策的成熟——但两个速度放在同一张时间线上看，比任何单点的 bug 对比都更能说明两个社区的运营风格差异。这个差异会决定它们各自吸引到什么样的贡献者与用户，而这个选择又会反过来塑造项目本身。

个人智能体这个品类正在集体穿越窄门：从"能做什么"到"能不能一直稳定地做”。数据库、容器编排这些上一代基础设施软件都走过同一段路，最终活下来的项目有一个共同点——它们把偿还工程债的速度，做成了组织的核心能力。这一周的两个项目，一个在展示怎么还债，一个在展示怎么不欠新债，都值得放进观测清单持续跟踪。两周之后的同一张统计表，会直接告诉我们这笔债各自还清了多少。