AI Agent 不可靠时长什么样：两大开源智能体生态的稳定性缺陷实证分析

导读：AI Agent 的能力演示视频遍地都是，但把它当成常驻基础设施跑起来之后，真正决定去留的往往是另一个问题——消息到底有没有送到、状态到底有没有写坏。本文基于两大开源个人智能体项目（OpenClaw 与 Hermes Agent）2026 年 9 月上旬连续两日的社区动态与缺陷追踪数据，实证拆解常驻 Agent 的四类稳定性缺陷：消息静默丢失、会话状态损坏、阻塞式架构缺陷、升级路径破坏。读完你会得到四件事：一套可直接套用的缺陷分类框架、每类缺陷的真实案例与根因、对"入流出清比"这个生态健康度指标的理解，以及选型/自建时常驻 Agent 的排查清单。

行文顺序：先讲数据来源与口径，再按四类缺陷逐个拆解真实案例与根因，然后给出缺陷分类框架与选型排查清单，最后讨论这批数据对 Agent 开发者的普遍启示。本文属生态实证分析，不涉及任何攻击 payload；引用的 Issue/PR 均来自公开仓库。

1. 数据来源与口径

本文的数据来自对两个开源项目公开仓库的连续追踪快照：

三点口径说明，直接影响后文数字的解读方式：

1. 500 是统计上限。两个项目的 Issue/PR 更新量双双触及每日抓取上限，绝对量只能说明"极高活跃"，横向比值基于截断数据，仅作方向性参考。
2. stale bot 干扰。部分仓库存在机器人批量关闭陈旧 Issue 的行为，单日"关闭数"不完全等于人工修复量，需要逐条看关闭原因。
3. Issue 是用户侧症状，PR 是修复侧动作。本文把两者交叉对照：一个只有 Issue 没有 fix PR 的 P1，与一个已有 linked PR 的 P1，风险等级完全不同。

这批数据最有价值的信号不在数字本身，而在缺陷主题的收敛程度：两个独立演进的项目，同期的头部缺陷高度趋同——会话状态管理、消息交付可靠性、升级路径安全。这说明这些不是某个项目的实现失误，而是常驻 Agent 这一类系统的共性结构难题。

2. 缺陷模式一：消息静默丢失——最摧毁信任的一类

2.1 症状与案例

OpenClaw 社区讨论量 Top 7 的 Issue 里，有 5 个直接关乎消息丢失、重复或错序。三个代表性案例：

• 可见入站消息被静默丢弃：零 payload 分发路径没有重试、没有死信队列、没有用户可见的失败提示，被标记为"恢复卡死"状态，且没有修复 PR。
• overflow-retry 假成功：多阶段文档工作流中，重试机制以工具结果"成功"收尾，但最终交付的回复静默丢失——上层看起来一切正常，用户就是收不到答案。
• 跨渠道消息重复/回放：一个伞形 Issue 统一追踪 MSTeams、WebChat、Telegram、followup 队列四条通道上的转录重复、回放与上下文组装错误，社区明确要求产品层面的统一治理而非零散修补。

Hermes Agent 侧还有一类父子会话污染：子 Agent 完成后把完整子上下文注入父会话，导致重负载下父会话被无关历史淹没——消息没有丢，但上下文被污染后，正确性等价于丢失。

2.2 根因分析

把这几个案例放在一起，能提炼出消息交付可靠性的三个缺失环节：

缺失一：没有交付语义定义。 传统消息系统（如邮件、IM 服务端）默认回答"至少一次/至多一次/恰好一次"的交付语义问题。而这批 Agent 框架的消息路径上，分发函数失败就返回空，调用方无从区分"没有消息"和"消息丢了"。数据库领域几十年前就解决的交付语义问题，在 Agent 框架里被重新踩了一遍。

缺失二：没有死信与重试兜底。 静默丢弃案例的根因是分发失败后无重试、无死信队列、无用户可见告警。消息系统的标准做法（失败 → 重试 → 超限入死信 → 告警）在 Agent 框架里普遍缺位，“失败"以"空响应"的形式被吞掉。

缺失三：跨通道幂等缺失。 重复/回放类缺陷的共性是通道各自维护投递状态，没有统一的幂等键。A2A 协作场景下回调导致请求方渠道重复消息，说明多 Agent 协作语义需要显式的防回环设计，而不是靠"应该不会重发"的乐观假设。

2.3 一个反直觉观察

社区最痛的不是功能缺失，而是"消息到底有没有送到"这个基本问题。这印证了一个工程判断：Agent 系统的可靠性瓶颈已经从模型层转移到基础设施层。模型答错了还能追问，消息根本没送到连追问的机会都没有。

3. 缺陷模式二：会话状态损坏——常驻进程的阿喀琉斯之踵

3.1 症状与案例

• Hermes Agent 的 state.db 损坏：用户报告 4 天内 7 次状态数据库结构性损坏，且与多 profile、多进程并发写入的场景强相关。这是同期该项目的最高风险信号——会话状态是常驻 Agent 的"事实源”，事实源损坏意味着历史、记忆、任务队列全部不可信。
• watchdog 与 transport 结算竞态：Telegram 通道上，watchdog 释放的持久更新在传输层结算前被误标为墓碑（tombstone），停机窗口内的私信消息丢失。本质是两个组件对同一状态记录的所有权没有仲裁机制。
• 修复引入新缺陷的链式反应：一个"中断的自动更新永久滞留旧代码"的修复落地后，又被新 Issue 报告存在"陈旧回执导致无限重启"——修复链在延伸，说明状态机本身缺少不变式（invariant）约束。

3.2 根因分析

根因一：多写入者无仲裁。 state.db 损坏与"多 profile / 多进程并发写入"强相关，这是典型的单写者原则（Single Writer Principle）缺失。SQLite 本身支持并发，但"WAL 模式 + 多进程同时写 + 崩溃窗口"的组合下，若没有显式的写锁层或队列化写入，损坏只是时间问题。

根因二：状态机没有不变式校验。 “修复 A 引入缺陷 B，修 B 又引出 C"的链式反应，说明状态转换缺少形式化约束——每个修复只堵住观察到的漏洞，而状态机允许的组合空间里还藏着没堵住的路径。传统嵌入式软件的常见做法（状态转换表 + 不变式断言 + 恢复路径测试）在 Agent 框架里几乎没有看到。

根因三：持久化与运行时的耦合。 案例中"同步持久化阻塞事件循环”（下节展开）与"watchdog 与传输层结算竞态"共享同一个结构性原因：持久化逻辑内嵌在消息处理主路径里，没有独立的状态服务层。两个组件同时操作同一状态记录时，谁的写入优先、如何回滚，全靠隐式约定。

3.3 对自建者的启示

如果你的 Agent 用 SQLite 存会话状态，三个低成本动作能显著降低损坏概率：所有写入走单一队列化入口（哪怕只是一个带锁的写线程）；启动时做一次完整性校验（SQLite 的 PRAGMA integrity_check 成本极低）；对"更新中"状态写显式的事务标记，避免半写状态被当作合法状态加载。

4. 缺陷模式三：阻塞式架构缺陷——事件循环上的同步债

4.1 症状与案例

• 同步持久化阻塞 Gateway 事件循环：OpenClaw 的长期 P1 问题，症状是会话交互卡顿，根因是持久化与转录维护在事件循环线程上同步执行。该问题的修复跨越多个版本：第一批补丁合入后，事件循环上的残余热点又由后续两个 PR 继续收敛——这是一场持续数月的"移出热路径"战役。
• memoryFlush 阻塞主处理车道 10 分钟：记忆刷盘期间 Telegram 全部消息排队。刷盘本是后台事务，却因为共享主处理车道而具备了"冻结所有通道"的能力。
• followup 队列独占会话车道：入站分发阻塞 20-30 分钟。同一车道被长任务独占后，其他消息全部排队。

4.2 根因与工程解法

这类缺陷的根因高度一致：同步 I/O 与异步事件循环混布。Node.js/asyncio 生态的经典陷阱——事件循环线程上任何一个同步操作（磁盘写、大 JSON 解码、SQLite 事务）都会冻结全部并发会话。

工程上的标准解法在生态内逐步落地，方向清晰：

1. 移出热路径：把 durable history 读取、全量 saved-prompt 解码等重操作移到工作线程/进程，事件循环只做调度。
2. 车道隔离：不同类型的任务（入站分发、followup、memoryFlush、压缩）走独立队列，任何一类都不具备独占全局的能力。
3. 增量计算：会话条目 patch 后复用已提交的 identity，跳过整段解码——从算法层面削减同步工作量，而不只是挪线程。

一个对照信号：最新版本发布说明里"durable history 读取移出 Gateway 事件循环"被列为核心特性——性能优化在这类系统里就是可靠性优化，事件循环卡 10 秒与消息丢失 10 秒，对用户是同一件事。

5. 缺陷模式四：升级路径破坏——被低估的风险面

5.1 症状与案例

• P0 回归挂起 6 个月：特定 provider 下嵌入式 agent 全量报错"Cannot convert undefined or null to object"，2026 年 3 月开出的发布阻塞级回归至今没有修复 PR。
• 升级致 macOS 网关不可恢复：一次小版本升级导致 LaunchAgent 网关进入不可恢复状态，用户需要 Time Machine 整机还原。
• 修复工具本身破坏数据：doctor --repair 被报告损坏认证状态；预置身份文件导致 bootstrap 被误判完成，并删除用户提供的启动文件——修复路径自己成了数据丢失源。
• 间歇性参数解析失败：升级后 claude-sonnet-5 间歇性报"malformed JSON arguments"，非工具特定，无 fix PR，当日评论仍在增长。

5.2 根因分析

根因一：升级测试矩阵覆盖不足。 provider × 渠道 × 操作系统的组合空间爆炸，而升级路径（尤其带修复工具的路径）往往只在主流组合上验证。嵌入式 agent 全量失败的回归能存活 6 个月，说明该 provider 组合根本不在回归测试矩阵里。

根因二：修复工具缺乏破坏性操作防护。 --repair 类工具天然具备写权限，但没有"先备份、后修改、可回滚"的三段式设计。对比数据库领域的迁移工具（预检查 → 备份 → 迁移 → 校验 → 失败自动回滚），Agent 框架的自修复工具还停留在"直接改"阶段。

根因三：bootstrap 流程的状态误判。 删除用户文件的事故源于"检测到预置文件 → 判定 bootstrap 已完成 → 清理启动材料"的推理链，其中"判定"环节把"文件存在"等同于"流程完成"。状态推断类逻辑的错误成本应该设计为零副作用——宁可漏判（用户手动清理），不可误判（自动删除）。

5.3 用户的现实防御

在这些修复到位之前，用户的现实防御只有一条：升级前完整备份状态目录，并暂缓执行任何 --repair 类操作。这不高雅，但在"修复工具可能删数据"的现状下，这是唯一可靠的回滚手段。

6. 缺陷分类框架：常驻 Agent 可靠性四象限

把两日快照里的全部头部缺陷归类，可以得到一个可复用的分类框架。任何常驻 Agent 系统（自建或选型）都可以拿这四类做检查清单：

框架的使用方式：对目标系统逐格提问"这一格的检查要点满足几条"。四格全绿的系统不存在——两个头部开源项目加起来也只能做到"每格都有已知问题但修复在途"。这个结论本身就是有价值的信息：不要期待开箱即用的可靠性，要把可靠性当成需要持续投入的工程属性。

7. 生态健康度：入流出清比的警示

除了缺陷本身，快照数据还揭示了一个生态层信号——Issue 入流远超出清：

• OpenClaw：新开/活跃 407-441 条/日，关闭 59-93 条/日，比值约 4.4:1 至 7.5:1。
• Hermes Agent：新开/活跃 282-315 条/日，关闭 24-73 条/日，比值约 4:1 至 13:1。

两个项目的维护者产出都极高（OpenClaw 核心维护者单日推进十余个修复/重构 PR），但社区热情跑得更快。这个比值不能简单读作"质量差"——它同时说明用户基数在快速膨胀；但积压持续膨胀意味着 P1 的平均修复时间会变长，选型时应当把"这个项目的 P1 挂起时长"作为比 star 数更真实的健康度指标。

一个积极信号是维护者的治理动作：伞形 Issue 统一归类散点 bug、批量关闭 stale Issue 清理噪音、核心回归一日内响应修复。出清速度跟不上不等于失控，看的是趋势和治理动作。

8. 选型与自建排查清单

如果你在选型常驻 Agent 框架或自建类似系统，从这批实证数据可以提炼出一份直接可用的排查清单。

消息路径（优先级最高）：

1. 构造一条会失败的消息（如断网时发送），观察系统的行为——是重试、排队、还是静默吞掉。
2. 确认幂等设计：同一条消息被处理两次，用户会收到几条回复。
3. 查找死信/失败可见性：失败的处理有没有任何用户可感知的痕迹。

状态层：

1. 状态文件的写入是单入口还是多处直写；多进程并发场景下有没有写仲裁。
2. 强杀进程后重启，状态能否自愈；有没有半写状态被当合法状态加载的路径。
3. 状态损坏后的恢复手段是什么——有没有自动备份或导出工具。

调度层：

1. 制造一个慢操作（大文件解码、慢磁盘），观察是否冻结其他会话。
2. 后台任务（记忆刷盘、压缩、索引）与用户消息是否共享队列。

升级路径：

1. 升级前有没有自动备份；升级失败能否一键回滚。
2. 自修复/doctor 类工具是否具备删除能力，删除前是否确认。
3. 查该项目的 Issue 列表：搜"upgrade"，看升级类缺陷的密度与修复速度。

这份清单不能替你做决定，但能把"演示很酷"与"值得托付常驻运行"这两类系统区分开。

9. 讨论：这批数据对 Agent 开发者的普遍启示

三点超出单一项目的启示。

启示一：Agent 的可靠性竞争进入基础设施层。 能力层（模型、工具、编排）的同质化速度远快于基础设施层（消息交付、状态管理、升级安全）。两个项目同期的头部缺陷高度趋同且集中在基础设施层，说明差异化竞争的重心正在下移。对开发者的含义：在 prompt 工程上的边际收益递减时，把一次"消息静默丢失"修好的用户价值可能大于加十个新工具。

启示二：静默失败是 Agent 时代的新一类敌手。 传统软件的失败有堆栈、有日志、有退出码；Agent 系统的失败形态是"看起来成功但没有结果"——重试以成功收尾但交付丢失、修复完成但数据被删。这类失败的检测难度远高于崩溃式失败，因为系统没有进入错误状态，而是进入了"假正常"状态。设计层面需要显式引入交付确认（delivery acknowledgment）：每个关键动作的完成必须有独立的、可校验的回执，而不是以"函数返回了"作为完成依据。

启示三：入流出清比是生态的隐藏负债表。 用户看到的是功能更新频率，看不到的是 Issue 积压里沉没的 P0/P1。对项目方，这个比值是扩张速度与工程消化能力的张力表；对用户，它决定了你踩到的坑要等多久才有人修。

边界说明：本文数据是两日快照而非长期追踪，缺陷状态以快照时点为准（部分 Issue 在成文时可能已有修复）；两个项目均为快速迭代期项目，今天的缺陷清单不代表其长期质量水平；“四象限框架"来自对这两个项目的归纳，推广到其他类型 Agent 系统（如一次性任务型 Agent）时需要重新校验适用性。

10. 总结

两大开源智能体生态的连续快照给出了一份罕见的"Agent 不可靠性实证标本”：消息静默丢失、会话状态损坏、事件循环阻塞、升级路径破坏，四类缺陷在两个独立项目上同期趋同——这不是巧合，是常驻 Agent 这一类系统的结构性难题清单。

对使用者，排查清单（第 8 节）可以直接拿去测任何候选框架；对开发者，四象限框架（第 6 节） + 交付确认设计（第 9 节）是两个可以立刻落地的动作；对观察者，入流出清比提供了一个比 star 数诚实得多的健康度视角。

Agent 的能力上限由模型决定，但能不能被托付常驻运行，由这四类基础设施缺陷的决定性细节决定。

关键词：AI Agent 可靠性、消息交付语义、会话状态管理、事件循环阻塞、升级路径安全、agent-ops