Planarian：用状态点管理 Agent 的本地与远程状态

智能体改动本地与远程环境后，缺少一致、可恢复、可分支的状态管理。

• 场景： 智能体迭代改文件、调本地工具，并经 MCP 访问远程服务。作者称，失败或误操作后要撤销早先变更；手工重建要额外工具调用，数据丢失时可能做不到。
• 不足： 作者列出三项：本地与远程须一起恢复，否则只回滚本地报告会与已更新的远程数据库不一致；须接入现有 harness，并处理上下文——工具历史可能描述已消失的效果，全留会误导，全丢则失去失败证据；频繁管理不能主导执行时间或存储。作者称，已有检查点、事务恢复和补偿方法只覆盖其中一部分，且不面向智能体探索。
• 观察与提出： 作者将开放问题写成：使变化中的环境状态成为恢复与探索的单位，并同时做到本地与远程一致、与上下文一致，且开销低到可反复使用。Planarian 是与现有 harness 协同的运行时，用 agent statepoint 表示可恢复的时间点版本，并带状态描述与先前结果。原语为 snapshot、rollback、fork。
• 威胁模型： 论文未用 white-box 等术语。
  • 目标： 探索时隔离备选动作的副作用；安全上撤销不想要的变更。作者举例为删所需文件、装错包、错误的数据库写入。
  • 发起者： 用户、harness 或智能体均可发起，保证不依赖谁发起。作者称 LLM 输出非确定且不可靠，并引用 hallucination 与 sycophancy。
  • 能力： 本地工具限制在沙箱内。远程只能经服务 API 观察和修改。无检查点时用补偿动作撤销受支持操作；不能补偿的请求在执行前拒绝。
  • 对象： 沙箱内文件与进程，以及受支持 MCP 操作改过的外部服务状态。

作者按环境覆盖、一致性和原语对比既有工作，并称没有方法同时满足 Table 1 的四项。

探索机制

• 多次尝试与搜索： Chen 等（2021）的 pass@K、Świechowski 等（2023）综述的 MCTS、Hua 等（2026）的 EAPO，被论文当作需要回溯和状态分支的探索方式，而不是状态管理基线。
• 任务搜索： Antoniades 等（2025）的 SWE-search 用 Git 对软件工程任务做 MCTS 式搜索。Yu 等（2025）的 ExACT 对 GUI 做 LLM 驱动的 MCTS，依赖 Web 环境的回溯。作者称 Planarian 将前者扩到终端任务，并可与后者集成。

检查点与恢复

• 框架检查点： LangChain（2025）与 OpenClaw（2026）保存对话、中间结果和工作流进度。作者称最多覆盖部分本地状态、不含远程，回退对话不会撤销数据库更新。
• 沙箱检查点： Podman、E2B、CubeSandbox 与 DeltaBox（论文引用为 2026）管理本地文件和进程，支持记录、恢复和分支。作者称远程状态在沙箱外，故无本地/远程一致性；其中 DeltaBox 保留上下文与本地状态的一致性。
• 工作流恢复： SagaLLM（2025）、LogAct（2026）、Cordon（2026）用纠正动作或延迟提交。作者称可含远程效果和部分本地变更，不含运行中进程；补偿需要撤销操作，暂存不能撤销已释放的效果。

底层机制与智能体版本

• 进程与工作流检查点： Ansel 等（2009）的 DMTCP、Du 等（2020）的 Catalyzer 保留本地执行。作者称不能处理远程服务或智能体决策。Zhang 等（2020）的事务工作流、Su 等（2007）的 AutoBash、Kim 等（2010）的选择性重执行，被作者归到通用工作流或应用修复。

• 文件、云沙箱与数据库： AgentFS（2026）只检查点文件系统，并复制整个可写层。Daytona 与 E2B 的持久沙箱快照不含远程。Dolt 与 Neon（2026）提供可分支数据库，作者称可经 hook 接入。Agent Sandbox（2026）可暂停 k8s pod；作者称 Planarian 面向本地部署并可与之集成。

• 快照实现： 论文使用并讨论 CRIU、ZFS（Ahrens 等，2003），并提到 Btrfs（Rodeh 等，2013）与 dm-snapshot。

• 基线与基准： 实验基线是 No-snapshot 与 Full-snapshot；微基准另有 CRIU-inc。基准为 GameWorld、Terminal-Bench 2.0、DevOps-Gym、Bird-interact-lite。

作者用 Table 1 的四列定位差异：本地/远程状态、两类一致性、三种原语、三类发起者。作者称先前方法均未全部满足，Planarian 把它们放进同一 statepoint 抽象。

Planarian 把工具调用边界上的沙箱状态和受支持的远程变更收成一个 statepoint，再记录、回退或分支。

抽象与原语

• statepoint： 某一时刻环境的一致、可恢复版本，另附证据：状态描述，以及从该点出发的先前执行结果。证据与环境状态、LLM 上下文分开存放。
• 两个域： 本地是沙箱内文件和进程，边界由沙箱划定。远程是受支持操作改过的外部服务状态；服务可以不提供检查点。
• 一致性： 本地与远程必须对应同一可观察时刻。作者称，两边独立采集可能描述从未存在的环境。
• 三原语： snapshot 在所选工具调用边界记录新点，不要求每次调用都做。rollback 回到已记录的点；上下文不回退，并保留失败尝试的信息。fork 从已有点分出环境分支，源分支保留；远程隔离需要服务支持独立分支。

运行时与接口

• 组件： sandbox manager 管 Podman 沙箱并派发本地工具；state proxy 拦截 MCP；statepoint manager 协调两边；registry 保存点；context library 向 harness 提供证据。Fig. 5 的条目含本地 CRIU/ZFS 产物、远程端点与 MCP 调用位置、证据，以及 discarded、pending、committed 状态。
• 调用方： 用户、harness 或智能体。Table 2 中 snapshot(sb, capture) 记录点，rollback(sp, sb, compensate) 恢复沙箱与服务，fork(sp-local, sb) 从本地状态分出沙箱。capture 与 compensate 是连接远程恢复的 hook。
• 上下文： Table 3 的 StateRecord、AppendOutcome 写入描述和后续结果；ConstructLedger 在选择前回显证据；RestoreContext 在回滚后提供所选状态的描述、先前结果和已回滚通知。harness 仍负责调用 LLM 和拼上下文，且不删除已有上下文。作者称，没有这段恢复上下文时，智能体可能按过时上下文重复犯错。

本地检查点

• 实现： Podman 容器为本地边界，根文件系统挂在 ZFS dataset 上。进程树用 CRIU 检查点，文件系统快照是只改元数据的零拷贝。
• 增量协议： 作者称 CRIU 原生增量在恢复后的第一次检查点会退回全量。Algorithm 1 不改 CRIU 或内核：恢复后、继续执行前清 soft-dirty 位，并把父检查点创建时间改到恢复线程启动之后，以通过 CRIU 的创建时间检查。fork 时写每沙箱一份恢复映像，避免两个沙箱同时写同一映像。
• 参数： 协议输入含满量间隔 k。论文未给出实验中的 k。调用方可在每次或若干次工具调用后 snapshot，原语不规定频率。

远程补偿与提交

• 代理： harness 把 state proxy 配成 MCP 服务器，proxy 再访问目标，不改原 MCP API。能版本化的服务（论文举例 Neon、Dolt）直接用服务自己的分支或回退。
• 数据库原型： 对 database MCP 的单条 SQL，在一个事务里执行前像语句、原语句和记录受影响键的后像语句。成功后把补偿动作写入撤销日志，回滚时按 MCP 请求的相反顺序重放。proxy 级锁把请求串行化。不能补偿的请求在执行前拒绝。
• 提交： snapshot 用 cgroup freeze 冻结容器进程，再采集 CRIU、ZFS 和 MCP 位置，完成后解冻；容器本身不停止，以避免每次冷启动。全部成功才标 committed，否则 pending。回滚先停容器，经 proxy 补偿，恢复文件系统，最后才由 CRIU 恢复。
• 远程分支与假设： 只有补偿、不能分支时，fork 出的沙箱不能使用该 state proxy。作者假设外部服务按租户逻辑隔离；快照取在工具调用之间，因为不能静默不暴露相应 API 的外部服务。

与执行重叠

• 锁： 每沙箱一个文件锁。工具调用取共享锁。snapshot 与 rollback 取排他锁，等在途调用结束并挡住新调用。fork 对源沙箱取共享锁、对新沙箱取排他锁。
• 重叠： snapshot 与 fork 可与 LLM 推理并行。运行时加在 Podman、CRIU、ZFS 之上，无单独守护进程，用后台 worker 做异步操作。

实验设置

• 机器与实现： Ubuntu 22.04，Intel Xeon Silver 4310（24 核、48 线程），128 GB 内存，NVMe SSD。实现为 Go 与 Python；Podman 5.8.6、ZFS 2.3.9、CRIU 4.2.1；数据库 MCP 使用 MCP toolbox for databases。
• 集成与模型： 集成 mini-swe-agent、nanobot、SWE-search、GameWorld harness。GPT-5.6-luna（medium reasoning）用于生成 MCTS 轨迹、§7.3 工具调用轨迹和 §7.4 的 MCP 请求轨迹。GameWorld 所用 LLM 论文未点名。
• 基准与子集： GameWorld（论文写 34 款游戏）评测 Mario、Flappy Bird、Minecraft，各 100 步，难度取步数限制内绝对进展最大的一档。Terminal-Bench 2.0（89 项）取九项系统管理。DevOps-Gym（704 项、30 余个项目）取 build/configuration 的 16 项实现任务。Bird-interact-lite（300 项）执行 50 项，经 MCP 改 PostgreSQL。
• 基线： No-snapshot 为无状态管理的 Podman 容器。Full-snapshot 用 Podman 原生全量进程与文件系统快照，ext4、无写时复制。游戏另有 Planarian（No rollback）。微基准另有 CRIU-inc，即经 Podman 使用 CRIU 原生增量检查点。
• 协议： §7.3、§7.4 与 MCTS 因 LLM 输出非确定而重放已生成轨迹；MCTS 重放含记录的 LLM 延迟。游戏在对局之间建 statepoint，仅非终局状态可回滚；不能从历史截图重建的玩家不可观察状态被滤掉。Minecraft 为简化收集模拟器，作者加入 creeper、熔岩伤害等。论文未报告重复次数。
• 指标与粒度： 游戏为 score；Fig. 6 中 Flappy Bird 轴为 Pipes passed，Minecraft 轴为 Dirt collected。另有完成时间、E2E，以及 snapshot、rollback、fork、命令时间。Terminal 实验在每次工具调用后快照，作者称对齐人工批准粒度，结束时回滚到先前快照。

主结果

设置	作者报告	出处
GameWorld Mario，100 步	得分为 No-snapshot 的 15×	§7.2
Flappy Bird、Minecraft，100 步	均为 No-snapshot 的 1.4×	§7.2
Terminal-Bench 九项系统管理	完成时间比 No-snapshot 多 1%；Full-snapshot 多 20%	§7.3、Fig. 9
DevOps-Gym 16 项 build/configuration	额外完成时间不到 3%；Full-snapshot 多 59%	§7.3、Fig. 10
Bird-interact-lite 50 项	E2E 比 No-snapshot 多 3%	§7.4、Fig. 11
MCTS，Terminal-Bench 九项	Full-snapshot 的 snapshot 开销为 Planarian 的 10×，fork 为 2×，E2E 慢 9%	§7.2、Fig. 8
摘要与引言口径	摘要写任务质量 up to 15×、恢复错误动作开销 3%；引言写完成时间增加 1%–3%，含经 MCP 改远程数据库的协同恢复	Abstract、§1

• 坏状态： 作者称游戏进入坏状态（如死亡重置）时，LLM 回滚到先前较好状态，并按 restore context 试其他计划；作者指向 Fig. 7。Fig. 7 文字含 Score 轴 0–300 与 Step 刻度 20–100，无逐点数值标注。
• 时序对照： 作者称快照可能改变帧时间从而改变结果，故加入只快照、不暴露 rollback 的变体；该变体得分高于 No-snapshot、低于完整 Planarian。
• 文件系统负载： 作者称多数 Terminal-Bench 任务不是文件系统密集，copy-on-write does not add significant overhead。

MCTS 式树搜索

• 测了什么： 把 SWE-search 扩到 Terminal-Bench 九项系统管理任务。节点按需 snapshot 和 fork，并与 LLM 调用重叠。GPT-5.6-luna（medium reasoning）生成轨迹后重放。No-snapshot 未纳入，论文写它没有 fork。
• 结果： 作者称 Full-snapshot 的 snapshot 开销是 Planarian 的 10×，fork 开销是 2×，E2E 慢 9%（§7.2、Fig. 8）。
• 作者的解读： 每个节点有两次 LLM 调用，延迟足以掩盖大部分 Full-snapshot 开销，所以 E2E 差距小于原语差距。作者称，snapshot/fork 更频繁或 LLM 延迟更低时，E2E 差距会更接近原语差距。

远程数据库的一致回滚

• 测了什么： 50 项 Bird-interact-lite 任务经 MCP 改 PostgreSQL。Planarian 在每次请求后 snapshot，并回滚沙箱与数据库；状态代理改写 SQL 并生成补偿动作。轨迹由 GPT-5.6-luna（medium reasoning）生成后重放。
• 结果： 作者称端到端时间比 No-snapshot 多 3%。状态代理使 MCP 往返时间为 No-snapshot 的 1.3×，作者称请求放大使 E2E 增加不到 0.3%（§7.4、Fig. 11）。
• 作者给出的来源： harness 有时连续发送多个 MCP 请求，快照时间藏不住；沙箱和数据库都要额外回滚；为使请求可撤销而增加了 SQL 操作。

状态原语微基准

• 测了什么： 弄脏内存或文件系统，连续两次 snapshot，测第二次；再测回滚或 fork 到第二点。内存负载还测回滚和 fork 之后的第一次 snapshot。对比 Full-snapshot 与 CRIU-inc。Fig. 12–14 的工作集刻度为 16M、128M、1G、8G。
• 结果： 作者称 8 GB 时，增量 snapshot 相对 Full-snapshot 在内存和文件系统上为 74× 和 231×；回滚后第一次 snapshot 相对 CRIU-inc 为 11×。回滚相对 Full-snapshot 在 8 GB 内存和文件系统上为 4× 和 67×；fork 为 4× 和 61×（§7.5）。
• 作者的解读： 作者称，在该增量协议和写时复制存储下，这些原语快于上述对应基线。图中其余工作集的柱高，提取文本未给出逐点数值。

其他消融与分析

• No rollback： 每步快照但不暴露 rollback；作者称得分高于 No-snapshot、低于完整 Planarian（§7.2、Fig. 6）。
• Terminal 原语时间： 作者称相对 Full-snapshot，snapshot/rollback 时间减少 89%（§7.3）。
• DevOps 原语时间： 作者称 Full-snapshot 的 sandbox snapshot/rollback 时间约为 Planarian 的 24×，因而难以藏在 LLM 推理之后（§7.3）。
• DevOps 完成时间： 作者称 Planarian 相对 No-snapshot 的额外完成时间不到 3%，Full-snapshot 多 59%（§7.3、Fig. 10）。
• 隐藏开销的条件： 作者称 Terminal 上 Full-snapshot 的 E2E 差距小于原语差距，因为 LLM 延迟掩盖了部分快照时间（§7.3）。

作者指出的局限与后续方向

论文未专门讨论局限。

实验覆盖范围

• 模型与重放： MCTS、§7.3 和 §7.4 的轨迹由 GPT-5.6-luna（medium reasoning）生成后重放；GameWorld 所用 LLM 论文未点名。论文写因输出非确定而重放轨迹，未报告重复次数。
• 任务子集： GameWorld 评测 Mario、Flappy Bird、Minecraft，各 100 步。Terminal-Bench 2.0 用九项系统管理（基准 89 项）。DevOps-Gym 用 build/configuration 的 16 项实现任务（基准 704 项）。Bird-interact-lite 执行 50 项（基准 300 项）。
• 基线与集成： 对比包括 No-snapshot、Full-snapshot；微基准另有 CRIU-inc；游戏另有 Planarian（No rollback）。论文写 MCTS 未纳入 No-snapshot，因为它没有 fork。集成对象含 mini-swe-agent、nanobot、SWE-search、GameWorld harness；评测小节未单独报告 nanobot 的结果数字。
• 远程状态： 状态代理原型支持数据库 MCP 的可补偿 SQL；§7.4 经 MCP 改 PostgreSQL。作者写，远程分支需要服务侧分支（举例 Neon、Dolt）；仅支持补偿时，fork 出的沙箱不能使用该 state proxy。
• 环境与指标： 测试床为 Ubuntu 22.04、Xeon Silver 4310、128 GB、NVMe，Podman 5.8.6、ZFS 2.3.9、CRIU 4.2.1。指标为 score、Pipes passed、Dirt collected，以及完成时间、E2E 和 snapshot/rollback/fork 时间。论文未报告显著性检验。微基准工作集刻度到 8G。

Planarian 是与现有 harness 协同的运行时，把智能体环境收成可恢复、可分支的时间点。

• 问题： 工具调用同时改沙箱内文件、进程和远程服务。探索要去掉失败分支的副作用，安全上要撤回误操作。只恢复一边，或让上下文仍描述已消失的效果，都会留下不一致；频繁复制大块内存又可能占掉执行时间。
• 方法： agent statepoint 在工具调用之间同时记下本地检查点和 MCP 位置。snapshot 建点，rollback 先重放补偿动作再恢复本地检查点，fork 从本地状态分出沙箱。远程无版本时，受支持操作被改成可补偿形式；数据库原型在同一事务中保留前像和受影响的键。上下文不删除旧记录，只追加恢复状态的描述和先前结果。本地用 ZFS 写时复制，以及恢复后仍可增量的 CRIU 协议。
• 质量： GameWorld 100 步内，Mario 得分是无快照的 15×，Flappy Bird 与 Minecraft 是 1.4×。只快照、不回滚的变体高于无快照、低于完整 Planarian。摘要把任务质量写成 up to 15×。
• 开销： mini-swe-agent 上，九项系统管理任务的完成时间多 1%，16 项 DevOps 实现任务不到 3%；50 项数据库任务的 E2E 多 3%。摘要把用户恢复错误动作的开销写成 3%，引言写成 1%–3%。相对全量检查点，MCTS 中 snapshot 开销为其 10×，fork 为 2×，E2E 慢 9%。
• 作者的结论： 作者称，智能体可以重访决策并探索备选，状态管理开销处于其报告的上述范围。