OOM

核心观点：OpenClaw并非“开箱即稳”，其宣称的生产就绪性存在显著预期差——稳定性幻觉源于测试场景窄、监控缺位与社区支持断层 在SkillsHub团队将OpenClaw v0.4.1接入智能工单路由Agent流水线的第37分钟，系统首次崩溃——Killed process (python3) total-vm:5212348kB, anon-rss:4721924kB。此后3小时内，我们复现了5次完全一致的OOM终止（间隔均值37±4分钟），全部发生在多工具链深度调用阶段。这组实测数据，直接锚定了一个被厂商白皮书刻意模糊的关键事实：OpenClaw的“高可用”承诺，仅成立在单轮Demo、无状态Mock、CPU负载<30%的真空环境中。 我们将其定义为——稳定性幻觉（Stability Illusion）：一种由文档完备性、Demo流畅度与Benchmark分数共同构建的认知偏差。当开发者看到《OpenClaw Architecture Guide》中详尽的状态机图、quickstart.py里3秒完成天气+股票+翻译三跳调用、以及MLPerf-Agents榜单上亮眼的89.2分吞吐时，极易误判其在真实业务流中的鲁棒性。这种幻觉不是偶然疏忽，而是系统性验证缺位的结果。 为剥离幻觉、回归工程本质，我们在完全一致的硬件环境（AWS c6i.4xlarge, 16vCPU/32GB RAM, Ubuntu 22.04）下，对三大主流LLM编排框架进行同负载压力对照测试（模拟客服对话Agent：每轮触发2–4个外部Tool，含HTTP调用、JSON解析、异步状态同步）： 框架 版本 测试时长 崩溃次数 典型故障现象 OpenClaw 0.4.1 3h 5 Killed process, JSONDecodeError, RuntimeError: Event loop is closed LangChain v0.1.20 3h 0 稳定运行，RSS波动<8%，P99延迟≤1.2s LlamaIndex 0.10.42 3h 1 软故障：TimeoutError后自动重试恢复，无进程退出 这一结果绝非偶然。它揭示了一个残酷现实：框架的“生产就绪”不能由功能完备性背书，而必须由故障耐受性定义。当LangChain在同等压力下零崩溃，而OpenClaw每37分钟必然倒下一次时，“开箱即稳”已不再是营销话术，而是需要被严肃质疑的技术债务信号。 实测复盘：5次崩溃的根因图谱（非随机故障，而是系统性设计缺陷） 我们对5次崩溃日志、/proc/[pid]/status快照、py-spy record火焰图及strace -e trace=memory输出进行了交叉溯源，发现所有故障均可归入三类可复现、可预防的设计缺陷，而非偶发环境异常： ▪️ 内存泄漏型（3次）：Agent调度器的“渐进式窒息” 当Agent执行>12轮连续多工具调用（如：查订单→调物流API→解析轨迹→生成摘要→发送通知），agent_scheduler.py 中的 _schedule_next_step() 方法持续向 self._pending_tasks 列表追加未清理的 asyncio.Task 对象。更致命的是，其 ToolExecutor 缓存机制未实现LRU淘汰，导致每个工具实例（含完整HTTP Session、Response Body副本）被永久驻留内存。 ...