为AI Agent探索式执行设计新的OS原语,上下文分支

这篇文章基于 AgenticOS 2026 论文《Fork, Explore, Commit: OS Primitives for Agentic Exploration》整理，重点讨论 AI Agent 在“并行试错”时，为什么会逼着操作系统重新提供更细的分支执行原语。

写在前面

---

• 博文内容为 AgenticOS 2026 论文 Fork, Explore, Commit: OS Primitives for Agentic Exploration 的学习笔记
• 论文地址：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_8.pdf
• 论文提出了一个新抽象：branch context
• 它针对的是 agent 非常典型的一类行为：同时探索多条解决路径，只提交成功分支，丢弃失败分支
• 理解不足小伙伴帮忙指正 :),生活加油

我看远山，远山悲悯

持续分享技术干货，感兴趣小伙伴可以关注下 ^_^

---

一句话先说结论

这篇论文最核心的观点是：

对 AI Agent 来说，fork-explore-commit 正在变成一种常见执行模式，但现有 Linux 机制很难同时满足“文件状态隔离 + 进程状态隔离 + 原子提交/回滚 + 兄弟分支互斥 + 无 root 轻量创建”这些要求。

所以作者提出了一个新的 OS 抽象：

• branch context

并给了两个实现方向：

• BranchFS
• branch() syscall

名词解释

• branch context：同时隔离文件状态和进程状态的执行分支环境
• copy-on-write：写入时复制，未修改的数据继续共享
• delta layer：当前分支相对于父分支新增或修改的数据层
• tombstone：表示“这个文件在当前分支已被删除”的标记
• BranchFS：论文实现的基于 FUSE 的分支文件系统原型
• FUSE：用户态文件系统框架，允许在用户空间实现文件系统逻辑
• syscall：系统调用，用户态请求内核服务的接口
• first-commit-wins：多个兄弟分支里最先提交成功的分支获胜，其它分支失效
• sibling invalidation：一个分支成功提交后，其它兄弟分支会被自动判定失效
• atomic commit / abort：提交要么完整生效，要么完全不生效；放弃则快速回滚
• OverlayFS：Linux 常见联合挂载文件系统，支持上层写时复制
• CRIU：Checkpoint/Restore In Userspace，用于进程状态保存与恢复的机制

论文在解决什么问题

今天很多 agent 不再沿着单一路径执行，而是会：

• 并行尝试多个修复方案
• 分支执行多个实验
• 选出最优结果再提交

这类模式在 coding agent、系统调优、自动实验场景里都很常见。

但一旦走到真正执行层面，就会遇到几个问题：

• 分支 A 改了文件，不能影响分支 B
• 分支 A 启动的测试进程，不能干扰分支 B
• 只有成功分支可以提交结果
• 被淘汰分支应该能快速丢弃
• 最好还支持嵌套分支

传统做法当然能拼出来一些近似方案，比如：

• OverlayFS
• Btrfs/ZFS snapshot
• cgroup
• PID namespace
• CRIU

但论文的结论是：这些机制各自解决一部分问题，却没有一个能完整覆盖 agentic exploration 的需求。

branch context 到底是什么

论文定义的 branch context 是一个隔离执行环境，包含两部分：

• 一个隔离的文件系统视图
• 一个受控的进程组

它要同时满足几类能力：

• copy-on-write 状态隔离
• atomic commit / abort
• first-commit-wins
• sibling invalidation
• hierarchical nesting
• lightweight unprivileged creation

简单理解就是：

给 agent 一个可以低成本开分支、独立试错、最后原子提交的系统级“沙箱分支”。

为什么现有机制不够

论文专门做了对比，这部分非常有系统味。

文件系统分支侧的问题

论文认为现有机制存在这些短板：

• OverlayFS/UnionFS 没有原生 commit-to-parent，也没有 sibling invalidation，而且通常需要 root 挂载
• Btrfs/ZFS 虽然有 clone/subvolume，但绑定特定文件系统，也没有原生 commit-to-parent
• device-mapper snapshot 需要块设备级支持，复杂度和开销都不合适
• VM snapshot 粒度太粗
• CRIU 需要序列化完整状态，太重

进程管理侧的问题

论文也对比了：

• process group
• session
• cgroup
• PID namespace

结果是：

• process group 和 session 里的进程可能逃逸
• cgroup 虽然终止可靠，但需要额外设置，而且通常要 root 或预配置
• PID namespace 隔离强，但会引入 PID 1 复杂度

作者总结得很直接：

没有现成 OS 机制能把 agent 需要的这组语义一次性提供出来。

论文提出的两个实现

1. BranchFS

BranchFS 是一个基于 FUSE 的文件系统实现。

它为每个 branch context 提供：

• 独立 copy-on-write workspace
• O(1) 级别的 branch 创建
• 对父分支的原子提交
• 自动 sibling invalidation
• 不需要 root

在实现上，它采用“基目录 + delta layer”的方式。

一个分支里的文件查找链路是：

1. 先查当前 branch 的 delta
2. 没有再查祖先 branch
3. 还没有再回落到底层 base directory
4. 如果遇到 tombstone，就表示该文件在当前语义下已删除

2. branch() syscall

这是论文更前沿的部分。

作者提出一个新的 Linux syscall：

• branch()

它的目标不是再拼装一堆用户态脚本，而是把以下动作原子化：

• 创建多个分支
• 给每个分支建立自己的挂载命名空间
• 创建/绑定文件系统分支
• 建立受控进程组
• 提供 sibling isolation
• 提供 first-commit-wins 协调

论文强调，之所以要 syscall，不是单纯为了“更优雅”，而是因为：

• 用户态多步组合会有 race window
• 中途失败清理复杂
• 顺序依赖很脆弱

这和当年为什么需要 clone()，而不是手写 fork + unshare 的组合，逻辑是类似的。

BranchFS 的关键语义

这篇论文里我最喜欢的是它把提交和终止语义说得很清楚。

1. Commit

一个分支提交时：

• 先收集当前分支的修改文件和 tombstone
• 先应用删除
• 再把修改内容拷贝到父分支 delta
• 父分支 epoch 增加
• 兄弟分支自动失效

这就是 first-commit-wins 的核心。

2. Abort

如果分支放弃：

• 直接丢弃 delta layer
• 基本没有额外成本

这就非常适合 agent 做大规模试错。

论文实验结果怎么看

论文当前真正实现并评估的是 BranchFS，branch() 还处于设计阶段。

实验机器不是特别夸张，但结果已经很能说明问题。

1. Branch 创建延迟几乎不受基目录大小影响

论文给出的数据是：

• 基目录 100 个文件时，创建延迟 292 μs
• 1,000 个文件时，317 μs
• 10,000 个文件时，310 μs

也就是说，branch creation 基本稳定在 350 μs 以内，符合 O(1) 级别预期。

2. Commit 开销跟修改量相关，不跟整个文件系统大小相关

论文给出的 commit 延迟：

• 修改 1 KB 时，commit 317 μs
• 修改 100 KB 时，514 μs
• 修改 1 MB 时，2100 μs

作者因此认为：

• 小改动提交可以控制在 1 ms 内
• abort 也很快

3. 吞吐开销在可接受范围内

顺序 I/O 测试里：

• 原生文件系统读 8800 MB/s
• BranchFS 常规 FUSE 读 1655 MB/s
• BranchFS passthrough 读 7236 MB/s

这个结果说明，如果路径走对，FUSE 开销并没有不可接受。

我对这篇论文的几个理解

下面是我自己的理解。

1. 这篇论文抓住了 agent 执行的一个“真需求”

很多 Agent 研究还停留在：

• 推理
• 工具调用
• 轨迹优化

但这篇论文关注的是更底层、也更工程的问题：

当 agent 开始真正并行探索时，操作系统能不能给它一个原生的“试错分支”执行模型？

我觉得这个问题非常实在。

2. 它本质上是在把 Git/事务/进程隔离三种思想揉到一起

如果从工程直觉看，branch context 有点像：

• Git branch 的提交/回滚语义
• 数据库事务的原子提交
• 操作系统 namespace/cgroup 的隔离

但它又不是这三者的简单拼接，因为 agent 需要的是“执行中的多分支世界”，不是静态代码分支。

3. first-commit-wins 很适合 Agent 场景

很多 agent 分支探索其实只需要一个成功答案。

所以：

• 一条分支成功提交
• 其他兄弟分支自动失效

这是一个非常贴近场景的语义，而不是泛用系统里常见的复杂合并。

论文的局限

1. branch() syscall 还没有完整实现

目前真正落地的是 BranchFS，系统调用级方案还是 proposal。

2. 评估还比较初步

当前更多是在验证：

• 创建快不快
• 提交快不快
• I/O 开销大不大

还没有看到更复杂真实 agent 工作负载下的大规模评估。

3. 目前更偏文件和进程侧

如果后续 agent 越来越依赖：

• 长生命周期内存状态
• 嵌入缓存
• 浏览器会话

那么 branch context 后面可能还要进一步扩展。

对工程实践的启发

1. Agent 平台的并行试错，不应该只靠临时目录硬拼

如果探索分支越来越多，靠脚本手动复制目录、追踪 PID、失败后清理，会越来越脆弱。

2. 文件隔离和进程隔离必须一起考虑

只隔离文件不隔离进程，或者只隔离进程不隔离文件，最终都会出问题。

3. 未来 Agent Runtime 很可能需要更原生的 OS 原语

这篇论文说明，Agent 并不只是“会调用 shell 的应用”，它已经开始对操作系统提出新的原语需求。

总结

如果只用一句话总结这篇论文，我会这样说：

它把 Agent 的并行探索执行，正式上升成了一个 OS 级问题，并提出 branch context 作为一种更贴近 Agent 试错模式的系统抽象。

我觉得这篇论文很有代表性，因为它说明：

• Agent 不是只需要更多工具
• 它也需要操作系统愿意给它更合适的执行语义

而 fork, explore, commit，很可能就是未来 agent runtime 非常重要的一类底层原语。

参考

• 论文 PDF：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_8.pdf
• AgenticOS 2026 Workshop：https://os-for-agent.github.io/

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :)

---

---

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)