背景：Agent 正在成为新的”一等进程”
2026 年，AI 编程 Agent 已经从实验品变成了生产力工具。Claude Code、OpenHands、SWE-agent 等系统每天处理成千上万的软件工程任务——它们阅读代码、运行测试、安装依赖、修改文件，在沙箱容器中自主地完成复杂的多步骤工作。
然而，当这些 Agent 从单机 demo 走向云端大规模部署时，一个根本性的问题浮现了：我们的操作系统还没有为这种新型工作负载做好准备。
传统的 OS 基础设施——资源管理、进程调度、状态快照——是基于过去二十年的云工作负载（微服务、批处理、无服务器函数）设计的。AI Agent 有着截然不同的行为模式：它在几分钟内交替经历”推理静默期”和”工具执行突发期”，每次工具调用可能让内存从 200 MB 飙升至 4 GB，又在几秒后回落。它不是无状态的请求-响应，而是一个积累了文件系统、进程内存、环境配置等丰富上下文的有状态实体。
最近，一系列系统研究工作开始探索 OS 如何重新设计来支撑 AI Agent 的高效运行。这个方向可以称为 AgentFS（Agent-Friendly Systems）——构建对 Agent 友好的操作系统基础设施。本文整合该方向的最新进展，从”为什么需要”到”怎么做”，勾勒这一领域的核心图景。
为什么需要：三个根本挑战
挑战一：资源管理——“15 倍的鸿沟”
对 144 个真实软件工程任务的测量表明，Agent 工作负载的资源需求呈现出极端的波动性。它的内存使用呈现”两层结构”：约 185 MB 的稳定基线（框架运行时本身），叠加工具调用驱动的瞬时峰值。最极端的情况下，峰值内存可达均值的 15.4 倍——从 264 MB 均值飙升至 4 GB 峰值，然后在几秒内回落。
这意味着什么？在一个 128 GB 内存的服务器上，如果按峰值预留，只能运行 32 个 Agent 实例，内存利用率不到 10%；如果按均值分配，一旦多个 Agent 同时触发重型测试，就会触发 OOM Kill，而 Kill 对 Agent 来说代价极高——它丢失的不是一个无状态的请求，而是数分钟积累的 LLM 对话上下文和推理状态。
现有方案（cgroup 硬限制、K8s QoS、PSI 压力监控）都假设了一个相对稳定的需求模式，面向毫秒到分钟级的响应窗口——但 Agent 的内存突发只持续 1–2 秒，用户态反应根本来不及。
挑战二：状态管理——“75% 的检查点是浪费”
AI Agent 是有状态的。一次运行可能持续 5–11 分钟，经历上百轮交互，期间的每一次工具调用都在修改文件系统、安装软件包、启动后台进程。当故障发生时，从零开始重跑意味着浪费所有累积的上下文和计算。
但现有的 C/R（Checkpoint/Restore）方案走向了两个极端：应用层做法（如保存聊天记录）轻量但不完整，恢复成功率只有 8–13%；OS 层做法（Docker commit、VM 快照）正确但昂贵，密集部署下能让执行变慢近 4 倍。
根本问题在于一个 语义鸿沟：Agent 框架知道”调用了什么工具”，但不知道工具在 OS 层面具体产生了什么影响；OS 知道文件系统和进程的每个变化，但不知道哪些变化对恢复是必要的。而实际测量揭示了一个关键事实——超过 75% 的 Agent 轮次根本没有产生需要恢复的状态变化（比如只是读取文件或执行纯查询命令）。信息的不对称导致要么检查了不该检查的，要么漏了不该漏的。
挑战三：状态回滚——“树搜索被 IO 卡住了”
当 Agent 从简单的线性执行走向更强大的测试时搜索（MCTS、Best-of-N 采样），问题变得更加严峻。搜索意味着频繁的分叉和回溯——每一步都要保存状态，失败时需要毫秒级回滚。
一个典型的 RL 训练场景需要在每个训练步启动数十到上百个并行 rollout，每个都需要从同一个初始状态克隆。现有方案——Docker commit 几秒、Firecracker VM 快照数百毫秒——直接把搜索的步调拉慢了一个数量级。更关键的是，这些方案都在做全量复制，而 Agent 的连续检查点之间其实高度相似——只改了若干文件和少量内存页。
怎么做：三个设计原则
围绕上述挑战，最近的研究形成了一套清晰的解决思路。尽管具体实现各异，但可以提炼为三个设计原则。
原则一：内核级实时响应
用户态的监控-决策-执行回路太慢了。当内存突发在亚秒级发生，唯一有效的办法是让控制逻辑直接运行在内核里。
具体做法是借助 eBPF 在内核的 cgroup 执行点（sched_ext、memcg_bpf_ops）植入可编程的强制逻辑。当某个工具调用的内存超过阈值，eBPF 程序可以在微秒级做出反应——不是粗暴地 Kill，而是分级响应：先软限流（memory.high 延迟）、再冻结（cgroup.freeze），只有在万不得已时才终止。这保留了 Agent 的累积状态，让它在资源压力下有”优雅降级”的路径，而不是直接坠毁。
更进一步，Agent 有一个传统工作负载不具备的能力——它可以理解并表达自己的需求。Agent 知道接下来是轻量的文件读取还是重型的测试执行。通过一个简单的意图协议（Agent 在执行前声明 “这条命令预计高内存占用”），内核可以更准确地预判和调度资源。如果预估错了也没关系——系统在工具返回时把实际资源消耗反馈给 Agent，形成闭环修正。这种”双向对话”让资源管理从被动的防崩溃变成了主动的协作。
原则二：语义感知的差异化处理
既然超过 75% 的轮次不需要检查点，关键就在于识别哪些轮次需要，以及需要到什么程度。
思路是在宿主机侧部署一个轻量的 eBPF 监控器，追踪每个 Agent 沙箱的文件系统和进程内存变化——但这里的关键是”净变化”语义：忽略同一轮次内创建又删除的临时文件、忽略早已退出的短命子进程，只报告持久化的状态改变。这需要把 OS 层面的原始事件聚合为 Agent 轮次级别的语义信号。
有了这个信号，系统就可以做差异化处理：纯读轮次直接跳过；只改了文件的只做轻量的文件系统快照（ZFS snapshot，约 10 ms）；只有真正修改了进程内存状态的轮次才触发完整检查点。而检查点本身可以异步执行——Agent 在发出 LLM 请求到收到回复之间有数秒的等待窗口，检查点工作正好可以藏在这个窗口里。当 LLM 回复到达时，如果检查点还没完成，再临时阻塞；否则 Agent 完全感知不到检查点的存在。
在宿主机的全局视角上，还需要一个调度层来协调多个沙箱的检查点流量——优先执行那些”LLM 回复已到达、阻塞了 Agent 进度”的紧急任务，把仍在 LLM 等待窗口内的任务往后排，避免多个沙箱同时抢占 I/O 带宽。
原则三：增量优于全量
对于需要高频 C/R 的搜索和 RL 场景，即使选择性检查点也不够快——必须从根本上改变”状态如何保存”的方式。
两个互补的增量机制可以解决这个问题：
文件系统侧：基于 OverlayFS 的思路，把文件系统状态组织为层叠结构。检查点操作不再是”复制所有文件”，而是冻结当前可写层 + 插入新的空白可写层——一个纯元数据操作，只需要约 1.6 ms。后续写入通过 Copy-on-Write 落到新层，旧层保持不可变。回滚就是简单地切换回目标层。配合 XFS reflink，未被修改的文件块在所有检查点之间共享同一个物理副本，写放大不再随检查点数量线性增长。
进程内存侧：采用双路径策略。在检查点时，除了做一次异步的 CRIU 增量转储（写入 tmpfs，大约 10 ms），还额外 fork 一个冻结的模板进程。恢复时的快路径直接 fork 这个模板——利用操作系统的 CoW 语义，只需复制页表（约 3.7 ms），无论进程的实际内存占用多大。后台还有一个异步预热线程，在 Agent 恢复运行后悄悄遍历可写内存页，提前触发 CoW，把缺页开销从 Agent 的关键路径上吸收掉。如果模板因为长期不用被 LRU 淘汰了，就回退到 CRIU 慢路径恢复（约 8 ms），正确性不受影响。
两个机制的协同使得一次完整的 C/R 控制在 15 ms 以内，相比传统方案提升了一个数量级。对于 MCTS 搜索，状态管理开销从总执行时间的 47–77% 降到 3–6%，Agent 终于可以按照算法需要的频率随意分叉和回溯，而不再被 IO 卡住脖子。
总结
AI Agent 正在成为操作系统需要认真对待的新型一等工作负载。它的三个核心特征——极端的资源波动、有状态的长时间执行、频繁的分叉与回溯——分别挑战了 OS 在资源管理、状态保存和 IO 性能上的既有假设。
回应这些挑战的关键思路可以归结为三条：把控制逻辑移到内核里（eBPF 实时响应）、把 Agent 特有的语义信息利用起来（区分有状态和无状态轮次）、只处理和传输变化的部分（增量文件系统 + 模板 fork）。三者共同构成了 AgentFS 方向的核心方法论——让操作系统为 Agent 而生，而非让 Agent 迁就操作系统。
本文基于以下研究工作撰写：
- AgentCgroup: Understanding and Controlling OS Resources of AI Agents (UC Santa Cruz et al., 2026)
- Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes (HKUST, 2026)
- DeltaBox: Scaling Stateful AI Agents with Millisecond-Level Sandbox Checkpoint/Rollback (上海交通大学 & 华为, 2026)