FMOS论文学习：为什么基础模型需要一个自进化的操作系统层

这篇文章基于 AgenticOS 2026 论文《It is Time to Virtualize Foundation Models with a Self-evolving Operating System Layer》整理，重点讨论一个非常“系统派”的观点：基础模型应该像 CPU、内存一样被虚拟化，并由 OS 风格的系统层统一管理。

写在前面

---

• 博文内容为 AgenticOS 2026 论文 It is Time to Virtualize Foundation Models with a Self-evolving Operating System Layer 的学习笔记
• 论文地址：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_26.pdf
• 这是一篇明显的 position paper
• 它不主打某个 benchmark 提升多少，而是在系统抽象层提出一个非常大的命题：Foundation Model Operating System（FMOS）
• 理解不足小伙伴帮忙指正 :),生活加油

我看远山，远山悲悯

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

---

一句话先说结论

这篇论文的核心主张是：

基础模型不应该再被当成一个个孤立 API 来使用，而应该像 CPU、内存、加速器一样，被一个系统层统一虚拟化、调度、治理和自进化。

作者为此提出：

• FMOS
• VFM（Virtual Foundation Model）

简单理解就是：

• 应用不再直接依赖具体物理模型
• 而是依赖一个稳定的“虚拟模型接口”
• 底层由系统决定该用什么模型、什么记忆、什么检索、什么信任机制、什么推理强度

名词解释

• FMOS：Foundation Model Operating System，基础模型操作系统层
• VFM：Virtual Foundation Model，对上暴露稳定接口的虚拟模型实例
• trap：在满足特定条件时，从轻量快路径切换到更重控制逻辑的触发机制
• fast path：默认的低延迟执行路径
• Data Agent：负责上下文、长期记忆和数据工作集管理的子系统
• FM Composition Optimizer：负责把虚拟模型请求映射到具体物理模型和资源组合的子系统
• Trust & Reasoning Agent：负责风险控制、验证和推理预算分配的子系统
• non-parametric memory：不存储在模型参数里，而放在外部系统中的记忆
• episodic / procedural / semantic artifacts：分别指事件记忆、过程知识和语义知识这几类外部记忆资产
• model routing：根据质量、时延、成本和策略把请求发给不同模型
• canary deployment：先小范围试运行新策略，再逐步扩大范围的发布方法
• self-evolution：不重训底层模型，而在系统层持续优化 memory、policy 和 orchestration 的能力
• hypervisor-like layer：像虚拟机监控器一样，为上层屏蔽底层异构性的系统中间层

论文到底想解决什么问题

作者认为，今天的 Agent / LLM 生态虽然已经有了：

• MCP
• A2A
• 各种 agent framework

但底层运行时还是很碎片化。

很多能力都散落在不同框架里，各自私有实现：

• state
• memory
• budget
• trust
• reasoning control
• model routing

这会导致几个问题：

• 应用行为不可移植
• 同样能力重复实现
• 治理策略很脆弱
• 模型升级会牵一发动全身

作者把这种状态类比成：

计算机在操作系统出现之前，每个程序都自己重新实现一遍基础能力。

所以他们主张，现在该把基础模型重新“操作系统化”了。

什么是 FMOS

论文提出一个系统层：

• Foundation Model Operating System

它位于：

• 上层应用 / agent framework
• 下层物理 foundation models

之间。

FMOS 的关键抽象叫：

• Virtual Foundation Model

VFM 的目标是给应用一种“错觉”：

• 我面对的是一个稳定、可信、能力足够的模型实例

但实际上，FMOS 在背后动态决定：

• 该路由到哪个物理模型
• 该加载哪些上下文与长期记忆
• 该启用何种推理与校验机制
• 该如何执行预算与信任策略

论文最核心的三个设计点

1. 把模型调用变成稳定语义接口，而不是固定后端绑定

作者强调，应用应该依赖稳定的 VFM contract，而不是依赖某个具体模型的偶然行为。

这意味着：

• 物理模型可以替换
• 框架可以升级
• memory / retrieval / verification 可以演化

只要 VFM 暴露的语义契约不变，应用就不需要大改。

这其实非常像传统系统里：

• 应用依赖虚拟内存，而不是物理页框
• 应用依赖文件接口，而不是磁盘块布局

2. fast path + trap-based slow path

这部分是整篇论文最有味道的系统设计。

FMOS 不是每次都强行套复杂 orchestration，而是：

• 默认走 fast path
• 只做轻量 accounting 和 tracing

当某些条件触发时，再进入更重的慢路径。

论文把这些触发称为：

• traps

触发 trap 的条件可能包括：

• 上下文不足
• 风险升高
• 预算紧张
• 不确定性提升
• 异常信号出现

一旦 trap 触发，FMOS 才启用对应能力，例如：

• 增强检索
• 模型切换
• 更强验证
• 更深推理

这和传统 OS / hypervisor 的 trap 思想很像，只不过这里 trap 的判定不是指令级，而是语义级、策略级的。

3. self-evolution 不是附加功能，而是核心原则

论文明确说，FMOS 不只是一个稳定层，还是一个 self-evolving 系统。

它会根据长期运行痕迹持续优化：

• prompt
• memory
• policy
• reasoning budget

而且作者强调，这种演化不依赖重新训练底层模型，而是通过：

• versioning
• canary deployment
• rollback

在系统层逐步改进。

FMOS 的三个核心子系统

论文把 VFM 背后拆成三个合作子系统。

1. Data Agent

论文把它类比成“虚拟内存子系统”。

它负责：

• 管理上下文
• 管理非参数化记忆
• 决定什么进入 active context
• 决定什么留在长期存储

论文还特别强调一种分层记忆思想：

• 小而快的工作集放在 prompt context
• 更大的 episodic / procedural / semantic artifacts 放在文件、向量库、图数据库等低层存储

也就是说，Data Agent 在做的事，其实很像把 LLM 的上下文窗口变成一套“需求分页”系统。

2. FM Composition Optimizer

这个模块负责把 VFM 调用映射到具体物理模型资源。

它关注的目标是：

• quality
• latency
• cost
• policy

论文把它描述为一种 scheduler + hypervisor 风格的能力层。

也就是说，它不仅做路由，还要决定：

• 什么时候换模型
• 什么时候组合多个模型
• 什么时候重用已有结果
• 什么时候在多租户约束下做资源折中

3. Trust & Reasoning Agent

这个模块负责：

• 推理深度分配
• 验证与护栏
• 风险分级
• 信任策略执行

论文甚至举了一个很具体的 API 例子：

• set_reasoning_level()

作者认为，FMOS 可以把不同模型各自混乱的“推理开关”抽象成统一接口，再根据运行反馈在线调整预算。

这篇论文和普通“模型网关”有什么区别

很多人看到这里可能会说：

• 这不就是 model gateway 吗
• 或者只是一个更强的 agent orchestration layer

但论文想做得更深一层。

普通网关更像：

• 请求转发
• 配额控制
• 简单路由

FMOS 想强调的是：

• 它有稳定虚拟化边界
• 它管理 memory/state/trust/budget
• 它可以跨应用共享可演化机制
• 它的目标是让应用摆脱对具体模型实现的绑定

所以它更像是“foundation model 时代的系统抽象”，而不只是一个统一入口。

我对这篇论文的几个理解

下面是我自己的理解。

1. 这篇论文真正想解决的是“系统碎片化”

今天 Agent 生态的问题，不只是模型多，而是：

• 每个框架都在自己做 memory
• 每个产品都在自己做 guardrail
• 每个应用都在自己做 routing
• 每次升级模型都可能打破原有行为

FMOS 想做的，是把这些零散能力提升成共享系统能力。

2. VFM 这个概念非常关键

如果以后真的进入多模型、多记忆层、多验证链路并存的时代，那么应用直接绑死某个物理模型会越来越痛苦。

VFM 的价值就在于：

• 让应用依赖语义契约
• 让系统去管理底层异构性

这和虚拟化思维高度一致。

3. trap-based orchestration 比“每次都全套编排”更现实

很多 agent 系统现在的问题是慢路径太重，导致：

• 成本高
• 延迟高
• 工程复杂度高

FMOS 的 fast-path / trap-path 思路更像操作系统的常识：

• 大多数请求走便宜路径
• 少数高风险或高不确定请求再升级处理

我觉得这是非常合理的。

论文的局限

1. 这是 position paper，不是完整实现论文

它的贡献主要是：

• 提出抽象
• 定义边界
• 组织系统问题

不是给出成熟 FMOS 产品。

2. 很多设计还停留在原则层

例如：

• trap 如何学习
• VFM 合同如何形式化
• 不同框架如何统一接入
• self-evolution 的评估基准是什么

这些都还需要更多后续工作。

3. 落地会牵涉非常多生态协同

如果没有：

• 统一接口
• 参考实现
• 社区共识

FMOS 很容易停留在概念上。

对工程实践的启发

1. 设计 Agent 平台时，可以先把“应用接口”和“物理模型接口”拆开

哪怕现在还做不到完整 FMOS，也可以先避免把业务代码深度绑定到某个具体模型行为。

2. 把 memory、verification、routing 看成系统层，而不是业务层细节

这会让平台更容易演进。

3. 优先做 fast path，再按需 trap 升级

对大多数线上系统来说，这比默认把每个请求都送进重型 agent pipeline 更现实。

总结

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

它试图把基础模型从“API 服务”重新定义成“可虚拟化的系统资源”，并主张用一个可自进化的 OS 风格层，把模型、记忆、预算、信任和推理强度统一收进稳定接口之下。

这篇论文未必已经给出了最终答案，但它确实把一个大方向讲清楚了：

• Agent 时代，问题不只是模型够不够强
• 更关键的是，我们是否有一层足够稳定、可治理、可演化的系统边界去承载这些模型能力

参考

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

博文部分内容参考

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

---

---

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