AgentCgroup论文学习：AI Agent为什么需要新的OS资源控制

写在前面博文内容为AgenticOS 2026论文AgentCgroup: Understanding and Controlling OS Resources of AI Agents的学习笔记论文地址https://os-for-agent.github.io/papers/AgenticOS_2026_paper_10.pdf这篇文章不只是讲AI Agent更是在讨论一个非常具体的问题传统 Linux / cgroup / Kubernetes 的资源控制方式为什么开始不适合智能体理解不足小伙伴帮忙指正 ,生活加油我看远山远山悲悯持续分享技术干货感兴趣小伙伴可以关注下_一句话先说结论这篇论文最有价值的地方不是单纯提出了一个叫AgentCgroup的新机制而是先用实验把一个长期被忽略的问题讲清楚了对于AI coding agent这类工作负载真正拖慢任务完成时间、真正限制并发密度、真正导致资源治理失效的已经不只是模型推理本身而是Agent 在沙箱里不断调用工具、启动子进程、运行测试、安装依赖、反复重试这一整套OS execution path。换句话说Agent 问题已经不是“只要把模型换强一点就行”而是“执行系统本身已经成为瓶颈”。论文里给出的一个非常抓人的数据是在他们观察的 144 个 SWE-rebench 任务里OS 级执行开销初始化 工具调用占到了端到端任务时延的56%~74%LLM reasoning只占26%~44%这个结论很重要因为它直接改变了我们看待 Agent 基础设施的方式。名词解释AI coding agent能自主读代码、调工具、运行命令和测试的智能体cgroupLinux 用来限制和统计进程组 CPU、内存等资源的机制memcgmemory cgroup专门负责内存资源控制的 cgroup 子系统eBPFLinux 内核中的可编程机制可在很靠近内核执行点的位置插入观测和控制逻辑sched_extLinux 中可扩展调度框架允许用 BPF 定制 CPU 调度策略memcg_bpf_ops在 memory cgroup 路径上挂接 BPF 策略的接口PSIPressure Stall InformationLinux 用来观测资源压力和阻塞情况的指标systemd-oomd用户态的 OOM 管理守护进程基于压力和策略做杀进程决策soft limit / hard limit软限制通常允许短时超用并触发节流硬限制则越界即触发更强约束tool-call boundary一次工具调用的起止边界也是论文认为更合理的资源控制粒度Podman container论文用来运行独立 Agent 沙箱的容器环境SWE-rebench软件工程 Agent 常用评测任务集用来测试真实修复与执行能力论文到底在研究什么论文研究对象不是通用聊天机器人而是AI coding agents例如Claude Code、OpenHands、SWE-agent这一类能在沙箱环境中自主调用工具的系统。这类 Agent 的典型执行过程是模型先读上下文做一轮推理发出结构化的工具调用请求Agent 框架在容器里拉起一个子进程执行命令把结果再喂回模型重复多轮直到任务结束表面看这像是“模型 工具”的组合实际上落到系统层以后会变成大量非常动态的进程、内存、I/O 和容器资源变化。论文的核心问题就是这类 Agent 工作负载的OS 资源行为到底是什么样的传统cgroup / memory.max / memory.high / oomd / VPA / K8s QoS为什么在这里开始不灵了能不能做一个更贴近 Agent 执行语义的资源控制机制实验是怎么做的作者在单机环境上跑了144个SWE-rebench软件工程任务用的是Claude Code这个 agent framework底层模型分别是Claude Haiku 4.5走云端 APIGLM-4.7-Flash本地 GPU 推理环境里每个任务都在独立Podman container中执行不预先加资源限制。作者记录了CPU 利用率内存使用情况每次工具调用的类型和时间戳工具调用阶段与模型思考阶段的时间占比这套方法的优点是比较“系统味”不是只看 token、成本、准确率而是直接看Agent 在操作系统里到底做了什么。论文最重要的四个发现1. 任务时间里大头不是模型而是 OS 执行路径论文发现完整任务生命周期里容器和 Agent 初始化占31%~48%工具执行大约占26%模型推理只占26%~44%也就是说用户感知到的任务完成时间超过一半其实消耗在“把 Agent 运行起来并让它不断执行工具”上。这和很多人直觉不一样。大家平时谈 Agent 性能往往先想到模型速度、上下文长度、token 成本但这篇论文指出了另一个现实一旦 Agent 真正进入软件工程、代码修复、测试执行这类场景系统级执行开销会迅速上升为主导因素。这也是为什么文章标题里强调的是OS Resources of AI Agents而不是单纯讨论 inference serving。2. 多租户并发的主要瓶颈不是 CPU而是内存论文给出的平均 CPU 使用率并不高Haiku 平均13.2%GLM 平均7.6%这里的百分比是按单核归一化的说明整体 CPU 远没有打满。但内存不是这样。单任务峰值内存可以到2~4 GB。在128 GB内存机器上如果按峰值来估算并发实例数只能支持大约32~64个而此时 CPU 还远没到瓶颈。这个发现非常有现实意义如果你做的是 Agent 平台不能再沿用“CPU 是主要瓶颈”的习惯性判断对 Agent 来说更先撞墙的通常是memory headroom调度器真正要精细治理的也首先应该是memory burst3. Agent 的内存呈现“两层结构”这是我觉得论文里最有启发性的观察之一。作者发现Agent 的内存不是随机乱跳而是有很明显的两层结构第一层是相对稳定的框架基线平均大约185 MB第二层是由工具调用触发的瞬时突发常见会冲到500 MB~2 GB这意味着什么这意味着Agent 本体和工具子进程在资源语义上其实不是一回事。框架基线部分通常对应Node.js / Python 等运行时已加载的上下文解析工具结果所需的进程状态一些缓存、堆、JIT 数据而突发部分则主要来自pytest/unittest安装依赖编译、脚本执行大量文件扫描论文进一步指出98.5%的内存突发都发生在工具调用期间。这就很关键了因为它直接说明资源控制的最小有效粒度已经不是整个 container而是更细的tool-call boundary。4. 资源需求极不稳定历史统计很难预测传统云平台很喜欢做历史预测比如看过去的 P95、看过去的资源曲线再给实例配额。但 Agent 工作负载有几个很反常的地方同一个任务多次运行执行时间能相差1.8x不同任务的峰值内存可以相差20x峰值内存和“对话轮数”“输出 token 数”等 LLM 可见指标几乎没什么相关性论文举了一个例子同一个任务iterative/dvc#777连跑三次时长分别是402、222、259秒而且三次走出的解决路径还不一样。这说明 Agent 的资源消耗并不是“推理规模越大资源越多”这么简单而是更依赖它最终选了什么工具工具内部干了什么事是否进入重试循环是否加载了更重的测试集、依赖树和运行时所以对 Agent 来说历史资源画像远没有传统服务那么可靠。传统资源控制为什么开始失效论文把问题总结成三个 mismatch我觉得这个总结很到位。1. Granularity mismatch控制粒度不对现有机制大多是container-level policy比如整容器设置一个memory.max或memory.high。但 Agent 的资源变化发生在工具调用粒度上。于是就会陷入两难限额设高绝大多数时间都在浪费内存限额设低一遇到pytest这种大命令就 OOM论文里最典型的数据是最极端任务峰值内存4060 MB平均内存只有264 MB峰值与平均值比值达到15.4x如果按峰值配就等于大部分时间把资源空放着如果按平均值配1 到 2 秒的瞬时突发就可能把整个 Agent 杀死。2. Responsiveness mismatch反应速度不够现有很多控制机制依赖用户态守护进程或平台级控制器例如systemd-oomdPSI 驱动的回收Kubernetes VPA问题是 Agent 的突发常常只有1~2 秒内存变化速率最高能到3 GB/s。这种情况下用户态感知、决策、回写控制文件往往已经慢了。作者的判断很明确如果资源突发既快又不可预测那么控制逻辑就必须尽量贴近内核执行点而不是等用户态反应过来。3. Adaptability mismatch历史经验不再可靠传统工作负载通常更稳定重启代价也更低所以很多系统默认可以根据历史数据估计未来顶不住时 kill 掉再拉起来但 Agent 恰恰不适合这样处理。因为一旦 OOM 或被驱逐代价至少有三层冷启动很慢容器镜像平均就有3.5 GB当前轮已经积累的LLM context会丢再跑一遍也未必走回原来的解题路径所以对 Agent 来说kill-and-restart不是普通降级手段而更像一次“任务记忆擦除”。AgentCgroup 设计到底做了什么论文提出的AgentCgroup本质上是在 Linux 现有能力上做一层更贴近 Agent 语义的资源控制。它的设计核心可以概括成三点。1. 用分层 cgroup 把 Agent 和工具调用拆开传统做法是一个容器一个 cgroup。AgentCgroup则把层次继续往下细分每个 Agent 工作负载对应一个 cgroup 节点每次工具调用再映射成子 cgroup这样做的意义是总预算依然能在 Agent 级别控制但瞬时资源约束可以落在单次工具调用上某个重工具超限时不必连整个 Agent 一起粗暴处理这一步其实就是把“调度单位”从容器提升成了“Agent tool-call语义层次”。2. 用 eBPF 把控制逻辑下沉到内核这是这篇论文最“OS 论文”的部分。作者没有只停留在概念而是明确绑定了 Linux 里的两个能力sched_ext做 CPU 侧调度扩展memcg_bpf_ops做 memory cgroup 侧的自定义控制他们的目标很直接把控制反应时间压到微秒级避免用户态轮询和回调带来的延迟。这里最好先把“为什么一定要下沉”说清楚。论文认为Agent 的资源突发通常只有1~2 秒而传统用户态控制器的反应时间常常是毫秒到分钟级别。对普通 Web 服务来说这种延迟也许还能接受但对会突然拉起pytest、安装依赖、扫描大量文件的 Agent 来说等用户态先观测、再决策、再回写 cgroup 配置往往已经慢了一拍。也就是说问题不只是“策略写得对不对”而是控制逻辑离资源事件发生点太远中间要经过用户态调度、采样、回调和再次进入内核对秒级甚至子秒级突发来说这条路径太长所以 AgentCgroup 的思路不是在用户态写一个更聪明的 controller而是直接把关键决策点挂到内核已有的 cgroup enforcement point 上。你可以把它理解成传统方案先上报再判断再控制AgentCgroup在资源即将越界的地方直接判断并控制这就是论文反复强调的microsecond-level reaction。在这个框架里CPU 侧可以根据 workload / tool-call 元数据做优先级调度内存侧可以在超过soft limit或hard limit时触发自定义 throttle delay当内存压力上升时可以优先throttle、freeze而不是直接杀进程如果再细一点看它其实做了两套下沉。CPU 侧用sched_ext在调度点直接看 Agent 元数据论文里提到sched_ext会在 BPF map 里维护per-workload 元数据per-tool-call 元数据这样调度器看到的就不再只是“这是一个普通进程”而会额外知道它属于哪个 Agent它属于哪个工具调用当前工具调用是不是更偏 latency-sensitive于是 CPU 调度就能从“进程级公平”稍微升级成“面向 Agent 执行语义的优先级调度”。这里还有一个很重要的点论文提到sched_ext出错时可以fail-safe reversion也就是自动退回 Linux 默认调度行为。这个细节非常关键因为它说明作者不是在做“全盘替换内核调度器”的冒险实验而是在利用 Linux 已有的可编程扩展点把自定义逻辑插进去同时保留兜底路径。内存侧用memcg_bpf_ops把“超限后怎么办”改成可编程行为传统memcg更像是给你一组固定语义memory.high开始施加 reclaim / throttle 压力memory.max超过就触发更强硬限制严重时可能进 OOM 路径而论文想改写的恰恰是“超过阈值之后的动作”。它特别提到了memcg_bpf_ops提供的钩子例如get_high_delay_ms这个钩子的意义是内核在处理memory.high压力时不再只能走固定逻辑而是可以由 BPF 程序动态给出 throttle delay。于是 AgentCgroup 能做的事情就变成某个 tool-call child cgroup 刚越过 soft limit先轻度延迟它如果是低优先级工具调用可以延迟更久如果是高优先级调用尽量避免粗暴终止只有在真的扛不住时才进入更强硬的处理这种做法和传统“一旦冲过线就直接杀”的差别非常大。从单一动作变成分级响应论文里把这一层说成graduated responses based on priority核心是按优先级做渐进式退化而不是统一 OOM。大致顺序可以理解为先通过memory.high相关 delay 做节流压力再上升时使用cgroup.freeze暂停某些子树只有最后才考虑终止这个顺序的本质是优先保住 Agent state优先保住已经积累的上下文优先保住主任务不要让一个重工具把整个 Agent 一起拖死这正是 Agent 工作负载和传统 batch job 的巨大差异。运行时观测也一起下沉了论文这里还有一个很容易被忽略但其实很关键的点AgentCgroup 不只是把 enforcement 下沉了它还把高频观测也尽量放进了内核侧作者提到它会用 eBPF 在内核里跟踪process creationmemory allocation changes目的是实时识别tool-call boundary当前资源动态每个 tool call 应该采用什么控制行为这样做的好处是控制逻辑不再依赖用户态定时轮询。用户态 daemon 只保留两类职责cgroup 生命周期管理策略配置与 BPF map 交互换句话说用户态从“高频闭环控制器”退成了“低频配置面”而真正需要快反应的部分留在了内核里。这和传统的“超过就 OOM”相比思路明显更适合有上下文状态的 Agent。3. 不再依赖历史预测而是做运行时自适应论文对“预测式资源治理”其实挺不客气的。作者的观点是既然 Agent 行为高度非确定而且重试过程会带来渐进式内存累积那么更合理的路线应该是在运行时实时观测按当前工具调用和实际内存压力做决策优先采用平滑退化而不是终止恢复实现上他们用 eBPF 跟踪进程创建和内存分配变化识别工具调用边界和资源动态用户态只保留一个轻量 daemon负责 cgroup 生命周期和策略配置不再承担高频控制闭环。论文实验结果怎么看这篇论文不是完整工业系统论文更接近“问题定义 原型验证”。所以它的评估也比较克制重点是验证这个方向有没有意义。作者做的是trace replay把真实 Agent 内存轨迹以50x加速回放在多租户内存争抢场景下打开 AgentCgroup 的 BPF enforcement对比无隔离基线结果主要有两个在总内存1100 MB、总需求大约1233 MB的压力场景下无隔离基线只能做到66%存活率而 BPF 控制能让所有进程100%完成在1300 MB内存场景下高优先级任务的P95分配时延从70.97 ms降到50.14 ms下降约29%同时论文声称额外开销很小P50延迟只增加0.3%总完成时间反而下降1.1%这个结果说明哪怕只是 PoC 级别的内核侧资源控制只要粒度和时机选对收益也已经很明显。我对这篇论文的几个理解下面这部分是我自己的理解不是论文原文结论。1. Agent 基础设施的关键矛盾正在从“推理”转向“执行”过去做大模型平台很多优化围绕模型吞吐KV cachebatchGPU 利用率但如果是coding agent这类强工具调用场景真正影响体验的往往变成命令执行慢不慢测试是否频繁拉高内存容器初始化是否过重重试循环是否越跑越臃肿所以 Agent 平台要往下沉必须看到 OS 层。2. “工具语义”会成为下一代调度输入传统调度器看的是CPUmemoryIOhistorical metrics但 Agent 时代可能还要看这是pytest还是git status这是package install还是read file这是高优先级主任务还是低优先级辅助任务也就是说未来资源调度很可能要从“按进程/容器资源统计”走向“按任务语义理解资源意图”。这也是这篇论文最前沿的地方。3. 对 Agent 来说保住上下文比快速重启更重要在传统微服务里重启往往是廉价恢复手段。但在 Agent 里当前进程里可能塞着已经积累了几十轮的上下文当前任务的中间判断刚产生但还没外化的推理状态一旦因为资源控制失误被 OOM这些东西可能全部消失。所以从系统设计上看throttle / freeze / graceful degradation的优先级确实应该高于kill-and-restart。对工程实践有什么启发如果我们今天就在做 Agent 平台这篇论文至少给了几个很实在的提示。1. 不要只监控容器平均值要监控工具调用边界如果你只盯着容器维度的平均 CPU / memory很容易把真正的问题抹平。更有价值的指标应该是哪一类工具最容易打出峰值峰值发生在任务的哪个阶段峰值持续多久是单次突发还是重试累积2. 把“Agent 本体”和“工具子进程”分开看论文揭示的“两层内存结构”非常适合指导工程拆分。至少在观测和治理上可以尝试区分Agent framework baselinetool subprocess burst只要两者不分开调度和限流策略就很容易误伤真正该保留的上下文。3. 对强状态 Agent谨慎把 OOM 当成正常恢复手段如果任务具备明显状态性资源治理策略最好优先考虑降速排队延迟分配冻结低优先级子任务而不是一上来直接 OOM 或驱逐。4. 未来的 Agent 平台可能需要“语义感知型调度器”这点是我的推断。随着 Agent 越来越多地调用测试器、编译器、浏览器、沙箱、数据库、搜索接口平台最终可能不只需要一个“资源公平分配器”而是需要一个能够理解任务语义、优先级和上下文价值的调度器。AgentCgroup这篇论文我认为就是这个方向上的一个很好的起点。总结如果只用一句话概括这篇论文我会这样说它告诉我们AI Agent的系统问题已经不是传统容器工作负载的小修小补而是因为高状态性 强工具调用 非确定性 秒级突发这几个特征叠在一起逼着资源控制从“面向容器平均值”转向“面向工具调用语义和运行时动态”。这篇论文目前还不是一个完全成熟的工业答案但它已经把问题刻画得很清楚Agent 的资源变化比传统服务更剧烈Agent 的恢复成本比传统服务更高Agent 的行为预测比传统服务更难因此Agent 平台真正需要的不只是更强模型也是不再把它当普通容器来管的操作系统与运行时能力。参考论文 PDFhttps://os-for-agent.github.io/papers/AgenticOS_2026_paper_10.pdfAgenticOS 2026 Workshophttps://os-for-agent.github.io/博文部分内容参考© 文中涉及参考链接内容版权归原作者所有如有侵权请告知 © 2018-至今 liruilongergmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)