当我们谈论 coding agent 的内存问题时，通常关注的是上下文窗口的扩展或向量检索的效率。然而，有一类更隐蔽但危害更大的问题正在困扰长时间运行的自主系统 ——Remoroo 这样的 autonomous experimentation engine 需要连续运行数小时甚至整晚，在此期间内存泄漏、状态膨胀、checkpoint 失效等问题会逐一浮现。与传统的需求分页机制不同，本文聚焦应用层的内存状态恢复：从增量状态清理策略到 checkpoint 重载机制，再到运行时内存阈值的动态调整，提供一套可落地的工程参数清单。
问题的本质：长时间尺度下的状态衰减
Remoroo 的核心设计目标是让 AI 在本地运行自主研究 —— 凌晨启动，一觉醒来看到实验结果。这种运行模式带来了与传统 coding agent 截然不同的挑战：时间尺度从秒级延伸到小时级，任务粒度从修复一个 bug 变成执行 30 次实验迭代，每次迭代都可能产生新的文件状态、模型输出和评估指标。
在这种模式下，内存问题不再是简单的上下文溢出，而是演变为多层次的复合故障。首先是状态泄漏：每次实验的中间结果、工具调用历史、临时文件句柄如果不被妥善清理，会在内存中累积。其次是 checkpoint 膨胀：频繁的全量状态保存会导致存储成本激增，而间隔过长则在故障恢复时丢失大量进度。第三是阈值僵化：静态的内存上限无法适应实验早期的轻量探索与后期大量评估数据并存的不同阶段。
理解这三个层面的差异是设计恢复机制的前提。需求分页机制解决的是操作系统层面的虚拟内存管理问题，而应用层的内存状态恢复需要在业务逻辑层面感知哪些状态是「可重建的」，哪些是「必须保留的」，以及如何在二者之间找到动态平衡。
增量状态清理：基于生命周期的多层剪枝
增量状态清理的核心思想是将内存状态按照生命周期划分为多个层次，对每个层次应用不同的保留策略和清理触发条件。在 Remoroo 这样的自主研究引擎中，状态可以分为四类：当前实验的即时工作区、最近 N 次实验的结果摘要、已验证的完整实验记录、以及历史实验的元数据。这四类状态的访问频率依次降低，但对恢复过程的重要性却并非简单递减 —— 最近实验的摘要用于快速继续中断的任务，而已验证的记录则是回滚决策的依据。
工程实现中，推荐采用基于 TTL（Time-To-Live）的分层过期策略。具体参数为：即时工作区不设过期但限制最大条目数（例如最近 200 次工具调用），最近实验结果保留最近 5 次的完整状态，历史元数据仅保留最近 20 次实验的关键指标。这些数字并非固定值，而是需要根据单次实验的平均内存占用和总可用内存动态调整。一个实用的经验法则是：任何层的内存占用都不应超过总可用内存的 30%，当某一层突破这个阈值时，优先清理该层中最老的那批条目。
更精细的实现会引入访问频率权重。不仅仅是时间戳，状态对象可以记录过去 24 小时内的访问次数。每当内存压力上升时，优先释放那些长时间未被访问但仍然驻留在内存中的状态块。这种策略在实验进入新阶段时尤其有效 —— 早期实验的中间结果在后期实验中的引用频率显著降低，但它们的完整恢复对理解实验演进历史仍然有价值。因此，清理算法需要区分「可重建状态」和「不可重建状态」，前者可以简单地从源文件重新执行，后者则需要持久化存储。
Checkpoint 重载：全量 + 增量的混合策略
Checkpoint 机制是恢复能力的基石，但简单的全量快照在长时间运行场景下会产生两个严重问题：快照体积随时间线性增长，导致存储成本和恢复时间同步膨胀；频繁的全量写入会与实验执行争抢 I/O 资源，影响整体吞吐。解决思路是采用全量 checkpoint 加上增量日志的混合策略，类似数据库的检查点机制。
具体实现上，建议以下参数配置：每完成 3 次实验执行或每过 15 分钟（以先到者为准）执行一次增量 checkpoint，记录自上次 checkpoint 以来的所有状态变更增量。每完成 20 次实验执行或每过 2 小时，执行一次全量 checkpoint，将当前状态完整写入持久化存储。增量 checkpoint 以追加日志形式存储，每次写入前先做日志截断 —— 当累计增量超过 50MB 时，自动触发一次全量 checkpoint 来压缩日志链。
恢复过程则采用反向策略：首先加载最近的全量 checkpoint，然后依次重放后续的增量日志直到恢复到中断前的状态。这个过程的关键优化点在于增量日志的格式设计 —— 每个增量条目应包含变更类型（新增、更新、删除）、变更对象的关键标识、以及变更前后的状态差异而非完整状态副本。这样做可以将单个增量条目的平均大小控制在 1KB 以下，使得每次实验的增量日志通常只有几十 KB 级别。
还有一个容易被忽视的细节是 checkpoint 的一致性保证。在实验执行过程中，状态变更可能发生在多个模块 —— 文件系统的修改、内存中的推理中间结果、外部 API 的调用历史。如果在 checkpoint 写入过程中发生崩溃，可能导致状态不一致。推荐的解决方式是使用写前日志（WAL）机制：所有状态变更先写入日志，再应用到内存状态，checkpoint 操作本身也作为一条日志条目写入。只有当 checkpoint 完整写入成功后，才在日志中标记该 checkpoint 为「可恢复」。这样恢复时可以从标记点直接加载，无需处理写到一半的状态。
运行时内存阈值的动态调整机制
静态内存阈值的问题在于它无法适应任务执行的不同阶段。在 Remoroo 的典型工作流程中，前几次实验主要是探索性尝试，代码改动频繁但评估数据较少；中期的实验会积累大量的中间结果；后期的验证阶段则需要同时保留所有历史数据以支持对比分析。如果使用固定的 2GB 上限，在探索阶段会浪费大量可用内存，而在后期则可能频繁触发清理导致重要状态丢失。
动态阈值调整的核心是根据当前任务阶段和系统健康状态自动调整内存分配策略。一个实用的实现方案是引入三个阈值参数：警告阈值（默认 60% 内存使用率）、干预阈值（默认 75%）、紧急阈值（默认 90%）。当内存使用率处于警告阈值以下时，系统正常运行，不做任何干预。超过警告阈值时，触发增量 checkpoint 并启动增量清理流程，优先释放过期状态。超过干预阈值时，暂停新实验的执行，将当前实验的所有状态序列化到磁盘，然后进行更激进的历史数据压缩。超过紧急阈值时，立即中止当前实验，保存尽可能完整的状态快照，然后触发完整的内存回收流程。
动态调整的另一个维度是「软上限」与「硬上限」的区分。软上限是建议性阈值，触发温和的清理和 checkpoint 操作；硬上限是刚性边界，一旦触及则强制进入只读模式并等待外部干预。在实现中，软上限可以根据最近 10 分钟的内存增长速度自动调整 —— 如果发现内存增长速度超过每分钟 50MB，说明可能存在异常泄漏，此时将软上限下调 10 个百分点以提前触发保护；反之如果内存稳定，则可以适当放宽上限以提升性能。
可观测性设计：让恢复过程可预测可干预
任何恢复机制的有效性都取决于运维人员能否及时发现问题并做出正确决策。针对长时间运行的 agent，需要构建三层监控指标：状态健康度、恢复能力、干预有效性。
状态健康度指标包括当前内存使用量及趋势、各状态层的条目数量和平均大小、最近一次 checkpoint 的时间戳和大小、增量日志的累积体积。这些指标通过定期采样（建议每分钟一次）并记录时序数据，可以直观展示内存是否处于健康增长通道。
恢复能力指标关注的是「假如现在崩溃，需要多长时间恢复到当前状态」。这个指标的计算方式是：最近全量 checkpoint 的大小除以磁盘顺序写入速度，加上增量日志的总大小除以读取速度，再加上状态重放的单次实验平均时间。理想情况下，这个恢复时间应该控制在 30 秒以内，如果超过 2 分钟，说明 checkpoint 策略需要优化。
干预有效性指标则记录每次清理或 checkpoint 操作后内存释放的比例、操作耗时、以及对后续实验执行的影响。通过这些数据，可以验证当前策略参数是否合理，并在异常情况下快速定位问题根源。
资料来源
本文的技术参考来自 Remoroo 官方文档及其在 Hacker News 上的讨论线程。Remoroo 作为 autonomous experimentation engine，其设计理念展示了长时间尺度下 agent 内存管理的独特挑战。增量 checkpoint 和分层状态清理的工程实践则借鉴了分布式流处理系统中的成熟模式，并根据 agent 场景的特殊性做了针对性适配。