Agent时代的系统基建：第一届AgenticOS工作坊总结

Agent 正在快速渗透到我们各种场景中。随着 OpenClaw、Claude Code 等工具的普及，Agent 已经具备了在沙盒环境中自主执行的能力。长期以来，系统研究者将 AI 视为一种高密度的计算负载，核心任务是优化训练与推理的吞吐或延迟。然而，Agent 的兴起重构了这一关系：AI 不再仅是被优化的对象，而开始作为”使用者”直接与底层系统交互。 这一身份转变，要求操作系统必须重新审视其原有的抽象与假设。

在今年系统领域顶级会议 ASPLOS 举办的首届 AgenticOS Workshop 上，学术界开始集中讨论这一趋势。本文将结合会议研究成果，探讨 Agent 与底层基础设施的双重关系：Agent 既是系统的新型用户，也是系统能力的新型建造者。

作为新用户，Agent 跟人类在行为模式、信任关系、可控性上都有本质区别。这让现有系统的很多假设失效，需要我们从 Agent 的特性出发，提供不同的系统抽象和能力。

作为新建造者，Coding Agent 正在改变系统技术的经济学。大量以前工程上不可行的技术方案正在重新变得可行。

本文将首先分析需求侧的变革，即 Agent 作为用户对系统原语提出的新需求；随后转向供给侧，探讨 Coding Agent 如何拓宽系统优化的可行性边界；最后，本文总结了三个基本原则，以期为该方向的研究和实践提供参考框架。

Agent 作为新用户：哪些基本假设变了？

Agent 的出现动摇了系统设计的一个底层假设：“系统是为人构建的”。然而，Agent 和人展示出的区别，让许多系统设计的领域都需要被重新考虑。

首先，Agent 展现出长效且具有破坏性的行为特征。Agent 具备长时间持续运行的能力，并在目标驱动下穷尽所有执行路径。由于缺乏可观测性的支持，其执行过程中的逻辑错误往往具有隐蔽性与破坏性。

其次，在信任层面，传统的权责机制因 Agent 的介入而失效。Agent 作为纯粹的执行代理存在，这导致了追责链条的断裂。Agent 对待高风险操作与低风险操作表现出一致的果断，这种风险中性的决策风格要求系统必须介入干预。

最后，在安全边界上，Agent 的意图完全暴露于外部输入。提示词注入使得外部数据直接转化为控制指令。Agent 的行为空间处于完全开放状态，其攻击面从传统的接口调用延伸至自然语言文本。

副作用不可逆：为 Agent 的错误兜底

Agent 在实际场景中难以被完全信任的一个核心原因是副作用的不可逆性。Agent 调一个外部 API、发一条消息、写一笔数据，这些操作一旦完成就已经作用于外部世界了。你可以回滚内存状态，但你没办法撤回一条已经发出的消息或一笔已经完成的转账。这让 Agent 的容错变成了一个比传统程序困难得多的问题。

Cloudflare 早期工程师、Kong 创始工程师、现 Agent 基础设施项目 RUNTA 创始人 Guanlan Dai 在他的 invited talk 里围绕这个问题提出了一组原语。这三个原语分别在副作用生命周期的三个阶段做管控。

第一阶段：Effect Log——记录已经发生了什么。它记录 Agent 已经提交的所有外部效果，是 write-ahead log 的语义等价物。只有先把已经发生的事情 seal 住，形成一个确定性的历史记录，后续的约束和恢复才有据可依。

第二阶段：Capability Gateway——约束允许发生什么。它在副作用发生之前做门控，把规划和执行权限分离，通过临时的、可撤销的 token 来中介 Agent 的所有外部访问。

第三阶段：Resumability——出了错怎么回到安全状态。当 Agent 已经产生了部分副作用并且出了错，系统需要让它从一个已知的、确定性的状态安全恢复，从 sealed 的边界重新进入，而非从零开始。

这三者之间存在顺序依赖：先记录已发生的（Effect Log），再约束将要发生的（Capability Gateway），最后在出错时安全回滚（Resumability）。 对系统人来说这个结构会很熟悉——数据库的 WAL 先持久化，access control 约束操作范围，然后 crash recovery 才能正确恢复状态。Agent fault tolerance 在更高的语义层面重现了这个经典模式。

探索性执行：让试错成为一等操作

Agent 的执行过程跟传统程序有一个根本区别。传统程序的执行路径在编写时就已经大致确定了，运行时沿着预定逻辑往前走。Agent 面对一个开放式目标，需要自己决定下一步做什么，经常要同时追求多条解决路径，只保留成功的那条。

这种探索-回溯的模式在应用层实现有两个核心困难。第一是 context 的膨胀——Agent 在多条路径之间来回切换，上下文越积越长，容易 lost in the middle，推理质量随之下降。第二是环境副作用——每条探索路径都可能修改文件、启动进程、产生外部效果，不同路径之间如果缺乏隔离，一条路径的副作用会污染其他路径的状态。

Workshop 上的论文《Fork, Explore, Commit: OS Primitives for Agentic Exploration》提出把探索和回溯下沉到 OS 层。核心抽象叫 branch context，为每条探索路径提供隔离的文件系统视图和进程组，支持 fork、explore、commit/abort 的完整生命周期。多条分支之间互不干扰，采用 first-commit-wins 的策略来解决冲突，成功的分支 commit，其余分支自动失效。

论文在 Linux 上做了两个实现：BranchFS 是一个基于 FUSE 的文件系统，为每个 branch context 提供 copy-on-write 的隔离工作空间，创建开销在 350 微秒以内；branch() 是一个提议的 Linux syscall，在内核层面提供进程隔离和分支协调。

这跟前面讨论的 fault tolerance 形成互补：Fault tolerance 是事后兜底，错了怎么恢复；探索性执行是事前支持，让 Agent 可以低成本地尝试和丢弃，降低犯错的代价。

隔离与资源管控：现有机制为什么不够用

Agent 在生产环境中运行，隔离和资源管控是绕不过去的基础问题。以 Lovable、Manus 这类产品为例，它们在云端同时运行大量 coding agent，每个 agent 跑在独立的沙盒容器里，既需要很高的部署密度来控制成本，又需要严格的隔离来保证安全。这个模式表面上看跟 serverless 或者微服务有些像，但 agent workload 的资源消耗特征完全不同。

我参与的 AgentCgroup 这篇工作对沙盒化的 AI coding agent 做了系统性的资源画像，在 SWE-rebench benchmark 上分析了 144 个软件工程任务。几个关键发现值得注意：OS 层面的执行（工具调用和容器初始化）占了端到端延迟的 56–74%；并发的瓶颈是内存而非 CPU；内存的峰值和均值之间差了 15.4 倍，而且这些 spike 是由工具调用驱动的，高度不可预测，跨任务、跨运行、跨模型都不一样。

论文把这些特征跟 serverless、微服务、批处理三种传统 workload 做了对比，识别出三个错配：

• 粒度错配：现有的资源控制策略作用在容器级别，但 agent 的资源波动发生在工具调用级别。
• 响应速度错配：用户态的资源调整跟不上亚秒级的不可预测 burst。
• 适应性错配：传统方法基于历史数据做预测，但 agent 的执行是非确定性的有状态过程，历史数据参考价值有限。

针对这些错配，论文提出了 AgentCgroup，一个基于 eBPF 的资源控制器。核心思路是利用 agent 自身的能力：agent 可以声明资源需求，也可以在资源不足时重新规划执行策略。AgentCgroup 用跟工具调用边界对齐的层级化 cgroup 结构做隔离，通过 sched_ext 和 memcg_bpf_ops 在内核层面做实时 enforcement。

Agent 作为建造者：系统技术的可行性边界在移动

上文介绍了 Agent 作为系统的新用户，在 fault tolerance、执行模型、资源管理几个维度上都提出了全新的要求。另一个方面，Agent 也在改变 infrastructure 本身的建造方式：它们降低了系统层面定制化和智能决策的成本，让一些以前工程上不可行的技术路径重新变得可行。

Specialized 软件复活

当 Coding Agent 让生成和适配代码的成本趋近于零，系统领域很多长期受制于人力成本的技术路径会被重新打开。这是本次 workshop keynote speaker、Virginia Tech 的 Dan Williams 教授的核心判断。Dan 长期研究操作系统和虚拟化，对 unikernel、系统安全、内核架构都有很深的积累。

系统领域里长期存在一个矛盾：最优的方案往往是高度定制化的，但定制化的人力成本太高，所以通用方案胜出。 Linux 生态里大量的设计选择反映的就是这种经济学约束——大家都在用 POSIX API、通用文件系统、标准网络栈、统一的内核配置。

Unikernel 是这个矛盾最典型的案例。Unikernel 在技术上非常优美，裁剪内核、缩小攻击面、显著提升性能。但它始终停留在小规模的应用，因为每一个应用都需要单独适配，导致工程成本极高，且不支持 POSIX API，无法复用 Linux 已有的生态。Coding Agent 的到来改变了这个等式。 如果生成和适配代码的成本显著降低，那么这类系统可以重新焕发生机。

直觉上，Coding Agent 可以直接为每个应用从零生成一套定制化的系统。但使用过 Coding Agent 的人都有体会，虽然编码的成本降低了，但对于大型系统项目，架构设计、准确描述需求，这些工作的成本无法避免。一个更可行的路径是提供 extension 和专门的 interface，在一个通用系统上挂载定制化的逻辑，而非替换整个系统。

Extension 在 kernel 层面已经有了成功实践。eBPF 让你可以在内核的关键路径上插入自定义逻辑，同时 verifier 保证代码的安全性。这个模式对 Coding Agent 时代有两层价值：第一层是安全性，Agent 生成的代码你未必信任，但 verifier 可以在加载前做静态检查，保证满足某种安全规约；第二层是接口约束，明确的 hook point、受限的数据访问、有限的操作集合，Agent 在这样的接口下犯错的空间被压缩，更容易生成正确的代码。

eBPF 证明了这种**“受限、可验证的 extension”**模式是可行的。但它目前局限在 kernel 层面。如果 Coding Agent 要驱动更广泛的系统定制化，每一层系统组件都需要类似的 extension 接口。这个方向仍然亟需探索。

智能决策：LLM 理解程序语义辅助系统管理

LLM 的语义理解能力正在给系统管理带来新的可能性。程序的源码、文档、报错信息、配置说明，这些信息一直都存在，但传统的系统管理工具无法理解它们的含义，只能退而求其次，跑 benchmark、看历史数据、拟合黑盒模型。LLM 可以直接理解这些信息，把语义层面的知识转化为系统决策的依据。

论文《Fuyun: Bridging the Semantic Gap in Serverless Resource Provisioning via LLM Agents》展示了这个思路在 resource provisioning 场景下的实践。Serverless 平台需要为每个函数预分配资源，传统方法用贝叶斯优化或强化学习来做，本质上把函数当黑盒，样本复杂度高，在生产环境的预算约束下很难落地。Fuyun 让 LLM agent 直接阅读函数源码，生成一个可验证的参数化策略。比如一个图像处理函数，LLM 读完源码后可以判断出它的执行时间大致是输入图像的长、宽、色彩通道数的函数，并给出一个具体的表达式。实验结果显示 Fuyun 只需要贝叶斯优化四分之一的 profiling 样本就能达到同等可靠性，同时相比静态分配减少了 44 个百分点的资源浪费。

类似的思路也出现在安全领域。论文《Toward LLM-Driven Rule Generation for Enforcement Systems: An Exploratory Study on WAF》探索了用 LLM 来生成 WAF 规则。传统的规则维护依赖安全专家手动编写和更新，速度慢且对专业知识要求高。该论文采用了一个混合架构：快速的规则引擎处理已知的攻击模式，LLM 分析规则引擎未能匹配的流量并生成新规则，反哺到规则引擎中覆盖未来的类似请求。这个反馈循环收敛到 88% 的规则命中率，平均延迟从 6.5 秒降到 400 毫秒以内。

这两篇论文解决的是不同的问题，但背后的范式是共通的：LLM 负责理解和决策，传统系统组件负责高效执行。

三个 Principle 和它们指向的未来

AgenticOS 2026 是第一届专门讨论 OS for Agent 的 workshop，很多工作还处于早期阶段。但从这些早期工作中，我们已经可以看到一些清晰的趋势正在浮现。我们尝试把这些趋势提炼为三个 principle。

Principle 1：从 Agent 的本质出发设计，而非从人类用户的经验出发做修补

Agent 跟人的区别是性质上的。Effect Log、Capability Gateway、Resumability 这组原语之所以成立，是因为它们从副作用的不可逆性这个 Agent 特有的问题出发来设计。Branch context 之所以成立，是因为它从 Agent 天然包含探索和回溯这个事实出发来设计。这些抽象都来自对 Agent 行为模式的深入观察，而非对现有系统抽象的修补。

对系统设计者来说，这意味着需要大量地使用 Agent、观察 Agent、在真实场景中跟 Agent 协作，从一手经验中建立对 Agent 行为模式的直觉。Agent 本身还在快速演化，这种直觉需要持续更新。

Principle 2：重新审视那些被经济学杀死的好技术

Unikernel、per-application 的系统定制化，这些方向以前被搁置是因为适配成本太高，技术本身是好的。Coding Agent 让这些成本大幅下降，经济学约束正在松动。

这个逻辑可以推广到更多方向。Formal verification 是一个典型的例子。seL4 对一个微内核做了完整的 formal verification，但投入的人力极其巨大，推广到更复杂的系统几乎不可能。瓶颈在于代码本身缺乏足够的 annotation、type hint、invariant，验证工具缺少可用的信息。如果代码是由 LLM 生成的，让它在生成代码的同时产出这些辅助信息，边际成本几乎为零。 更多的系统组件可以被验证，更多的 concurrency bug 可以在编译期被捕获。

值得对那些因为人力或适配成本太高而被放弃的方案做一次全面回顾。 每一个这样的方向，都应该在 Coding Agent 的背景下重新评估。

Principle 3：Agent 和 infrastructure 正在 co-evolution，设计时要为演化留出空间

整篇文章的双向框架本身就在说这件事。Agent 作为用户推动 infrastructure 演化，需要新的 fault tolerance、执行模型、资源管理。Agent 作为建造者又加速了这个演化，让 customization、智能决策变得可行。这两者互相强化，形成一个正反馈循环。 一旦这个循环转起来，Agent 能力的增长速度可能会超出我们基于当前经验的预期。

这意味着今天设计的 infrastructure 要为这种加速演化留出空间。过于僵化的抽象会在 Agent 能力跃升时成为瓶颈。Extension 模式之所以重要，部分原因正是它为 co-evolution 提供了灵活性——系统的核心保持稳定，定制化的部分可以随着 Agent 能力的增长不断迭代。

Infrastructure for agent 是一个刚刚展开的领域。这三个 principle 是我们当前的判断，随着 Agent 能力的演进，这些判断本身也会被修正。但有一件事不会变：Agent 正在成为计算的主体，而非计算的对象。围绕这个转变构建基础设施，是我们系统研究者和开发者面临的重要挑战。