AgentCgroup: AI Agent 的 OS 资源控制新范式

论文: arXiv:2602.09345
作者: Yusheng Zheng 等 (eunomia-bpf)
开源代码: github.com/eunomia-bpf/agentcgroup

研究背景与动机

随着 Claude Code、OpenHands、SWE-agent 等 AI 编程 Agent 的兴起，这些系统越来越多地部署在多租户云环境中。它们在沙盒容器内执行多样化的工具调用（编译器、测试运行器、包管理器），每个调用都有独特的资源需求和快速波动。

核心问题: 现有资源控制机制无法有效管理 AI Agent 工作负载，因为缺乏对 Agent OS 级资源动态的系统化表征。

四大关键发现

研究团队基于 144 个 SWE-rebench 软件工程任务（覆盖 Claude Haiku 4.5 和 GLM-4.7-Flash 两个模型）进行了系统测量，揭示出四个关键发现：

1. OS 级执行占端到端延迟的 56-74%

执行阶段	占比范围	说明
OS 级执行	56-74%	工具调用 + 容器/Agent 初始化
LLM 推理	26-44%	模型推理时间

细分数据:

容器和 Agent 初始化：29-45%
工具执行：约 26%（占活跃时间的 36-43%）

洞察: 用户感知的大部分延迟并非来自模型推理，而是来自操作系统层面的执行开销。

2. 内存（而非 CPU）是并发瓶颈

传统认知可能认为 CPU 是多租户并发的主要限制，但研究发现：

内存才是限制多租户并发密度的真正瓶颈
每个任务需要稳定的基础内存 + 工具调用驱动的突发内存

3. 内存呈现双层结构：15.4 倍峰值平均比

内存使用呈现明显的两层结构：

总内存 = 框架基线 (~185MB) + 工具调用突发

稳定基线: ~185MB（Agent 框架常驻内存）
突发峰值: 工具调用驱动，峰值平均比高达 15.4 倍

这种极端的波动性使得静态资源分配策略效率低下。

4. 资源需求高度不可预测

资源需求在多个维度上表现出不可预测性：

维度	变化范围	说明
跨任务	20 倍差异	不同任务间资源需求差异巨大
同任务不同运行	1.8 倍差异	即使是相同任务，多次运行也有显著波动

关键挑战: 基于历史预测的传统方法在此失效。

三大资源控制不匹配

将 Agent 工作负载与现有资源控制机制对比，研究发现了三个根本性不匹配：

1. 粒度不匹配 (Granularity Mismatch)

现有机制	Agent 需求
容器级策略	工具调用级动态

问题: 容器级策略要么浪费大部分分配的内存，要么触发 OOM 杀死。

2. 响应性不匹配 (Responsiveness Mismatch)

现有机制	Agent 需求
用户空间反应（毫秒-分钟级）	亚秒级不可预测突发

问题: 用户空间反应太慢，无法应对 Agent 工作负载的快速波动。

3. 适应性不匹配 (Adaptability Mismatch)

现有机制	Agent 需求
基于历史的预测	非确定性状态化执行

问题: 基于历史的预测不适合非确定性执行。杀死重启会销毁累积的 LLM 上下文。

AgentCgroup 解决方案

核心洞察

Agent 工作负载有一个传统工作负载不具备的关键属性：Agent 能够理解和适应自身的资源行为。

系统架构

AgentCgroup 是一个基于 eBPF 的意图驱动资源控制器，结合了：

┌─────────────────────────────────────────┐
│         Intent-Driven Controller        │
│    (Agent 声明资源需求 + 重构执行策略)   │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│    Hierarchical cgroup v2 Structure     │
│    (与工具调用边界对齐的层级结构)        │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│        In-Kernel Enforcement            │
│    sched_ext + memcg_bpf_ops            │
│    (微秒级响应的内核级执行)              │
└─────────────────────────────────────────┘

关键技术

层级 cgroup 结构: 与工具调用边界对齐
内核级执行: 通过 sched_ext 和 memcg_bpf_ops 实现
运行时自适应策略: 优雅降级而非强制杀死

初步评估结果

指标	改进
高优先级任务 P95 延迟	降低 29%（在多租户内存竞争下）
多租户隔离	显著改善
资源浪费	显著减少

与传统工作负载对比

特性	Serverless	Microservice	Batch	AI Agent
执行时间	100ms-2s	持续运行	分钟-小时	5-11 分钟
状态	无状态	有状态	无状态	有状态多轮
资源波动	低	中等	低	极高 (15.4x)
可预测性	高	中等	高	低 (20x 跨任务)
延迟敏感性	高	中等	低	高 (亚秒级)

实践启示

对 Agent 开发者

关注 OS 开销: 56-74% 的延迟来自 OS 级执行，优化容器启动和工具调用效率可能比换模型更有价值
内存管理优先: 设计多租户系统时，内存而非 CPU 是首要约束
拥抱意图驱动: 让 Agent 参与资源决策，利用其自我理解和适应能力

对基础设施提供者

细粒度控制: 需要工具调用级别的资源控制，而非容器级
内核级响应: 用户空间反应太慢，需要 eBPF 等内核级机制
预测失效: 不要依赖历史预测，需要运行时自适应策略

总结

AgentCgroup 代表了 AI Agent 基础设施演进的重要一步。它揭示了 Agent 工作负载与传统工作负载的根本差异，并提出了 意图驱动、内核级、细粒度 的资源控制新范式。

随着 AI Agent 从实验走向生产，这类基础设施层面的创新将成为决定规模化成败的关键。

整理时间: 2026-02-28
来源: arXiv 论文解读

AgentCgroup 论文解读：AI Agent 的 OS 资源控制新范式