模型操作系统之争：谁来做模型之上的调度层

模型之上为什么需要一层「操作系统」

大模型本身只是一台「推理机器」：输入 token、输出 token，不会自己选择用哪个模型、不会记住上次的对话、不会主动调用工具。要把模型变成可用的系统，中间必然要长出一层调度设施——就像操作系统之于硬件：把裸机的算力抽象成进程、内存、文件与系统调用，让应用不必关心底层细节。这层正在成形的「模型操作系统」（业界也称之为 AI 中间件、推理平台或 Agent 基础设施）承担四类统一抽象：路由、上下文管理、工具调用与记忆。

路由（Routing）解决「该用哪个模型」。多模型并存已经是现实：旗舰模型与轻量模型的价格差着一个数量级（库内价格战与 MaaS 选型两篇都算过这笔账），应用的不同请求（简单改写 vs 复杂推理）理应落在不同档位的模型上。路由层按请求的复杂度、延迟要求、成本预算动态分发——简单问题走小模型、难题升级到旗舰、专业任务走领域模型。路由做得好，同样的用户体验可以省下大半推理成本；做得差，要么浪费要么降智。库内推理优化篇讲过推理侧的成本结构，路由是应用侧最立竿见影的成本杠杆——这就是为什么每个 serious 的 AI 应用背后都藏着一层自建或采购的路由逻辑。

上下文管理（Context）解决「该记住什么」。模型的上下文窗口有限（再长也有成本与注意力衰减问题，库内长上下文篇讲过注意力稀释），而真实应用的对话与任务横跨数小时、数周。上下管理层负责在窗口里装最值钱的东西：对话历史的压缩与摘要、相关知识的检索注入（RAG 是它的一个子集）、多任务之间共享的状态。上下文工程（context engineering）作为一门显学浮出水面，正是这层抽象重要性的直接证据——提示词不再是单次的咒语，而是随任务演化的动态资产管理。

工具调用（Tool Use）解决「怎么动手」与记忆（Memory）解决「长期沉淀。模型要查数据库、调 API、执行代码，需要一套标准的调用协议（function calling 的规范、MCP 这类开放协议的兴起）；用户与任务的长期信息（偏好、历史决策、项目状态）需要一个独立于模型窗口的持久层。四类抽象合起来，就是应用开发者真正需要的「模型操作系统界面」——谁把这层抽象做得最标准、最完整，谁就握住了应用生态的入口**。这是卡位之争的根本逻辑。

三类竞争者：模型厂向上、云向下、创业公司卡中间

调度层的竞争者来自三个方向，各自的动机与禀赋差异极大。

基础模型厂商在向上长。OpenAI、Anthropic 与各大模型厂都在把自己的 API 从「文本补全」升级为「任务平台」：助手 API（threads、runs、tools 的抽象）、批处理接口、文件与代码执行环境、Computer Use 类的操控能力——模型厂想把操作系统层内置在自己的 API 里，让应用开发者除了模型之外也需要它们的平台设施。模型厂向上长的优势是天然掌握「模型的真实能力边界」（路由所需的能力画像只有模型厂自己最清楚），劣势是中立性：应用开发者把记忆、上下文、工具全部托付给某一家模型厂，等于把应用的核心资产押在对方的定价与战略善意上——库内基础模型公司商业模式篇讲过平台化的动机，向上长本质是模型厂在推理商品化时代寻找第二收入曲线（从卖 token 转向收平台费）。

云平台在向下伸。AWS Bedrock、Azure AI Foundry、Google Vertex 这类托管平台的定位本就是「多模型的统一入口」：模型可插拔（同一平台托管多家模型）、企业治理（权限、审计、合规）、成本管理与路由。云厂的优势是企业信任与算力底座（推理基础设施与调度天然相连），劣势是模型前沿能力的滞后——最新模型的独特能力总是先在模型厂自己的 API 里可用，云平台的抽象层永远在追赶模型层的演进。云向下伸的战略动机同样清晰：守住云计算的下一代负载入口——AI 时代的「云使用量」由推理与 Agent 负载构成（库内云三强战略篇的延长线），谁控制调度层，谁就控制下一代的云账单。

中间件创业公司卡在中间，也是过去两年融资最密集的赛道之一。它们的切入点各不相同：有的专攻路由与网关（开源的 LiteLLM、Portkey、 Martian 类的路由与网关产品——把「多模型切换」做成基础设施）、有的专攻记忆层（Mem0、Zep 类的持久记忆产品——把「用户与任务的长期状态」做成数据库）、有的专攻 Agent 编排（LangChain 与 LangGraph、CrewAI 类的框架——把「任务分解与工具调用」做成开发框架）、有的做可观测与评测（LangSmith、Braintrust 类——把「AI 应用的监控与质量」做成 DevOps 工具）。创业公司的共同赌注是：在模型厂与云厂的夹缝里，「跨模型的中立性」是它们唯一的护城河——应用开发者不愿意被单一模型锁定，中立的调度层因此有了存在理由。

三类竞争者的格局可以概括为一句话：模型厂想把中间层吃进模型里，云厂想把中间层吃进云里，创业公司想证明中间层值得独立存在。这场三角拉锯的胜负，取决于「模型能力的商品化速度」：模型越同质化，跨模型中立层越有价值；模型越差异化，模型厂的平台引力越强。

与 Agent 中间件的关系：调度层的 Agent 化

模型操作系统与 Agent 基础设施的关系，是理解这个赛道演化方向的钥匙。Agent（自主调用工具、多步执行任务的 AI 系统）对基础设施的要求，恰好是模型操作系统四类抽象的放大版：Agent 的多步执行把上下文管理的压力放大数倍（每一步都要携带与更新状态）、把工具调用的频率放大数倍（每次任务几十次函数调用）、把路由的粒度做细（每一步用不同模型）、把记忆的要求从「对话历史」升级为「任务状态与经验沉淀」（库内 Agent 计费篇与推理优化篇的两条线在此汇合）。

换句话说：Agent 不是模型操作系统的邻居应用，而是它的目标形态。传统聊天应用只需要四类抽象的简化版，而 Agent 应用把每一类抽象都推向工程极限——长任务的状态持久化（跨小时的会话恢复）、工具调用的权限与审计（企业 Agent 的合规底线）、多 Agent 的协作协议（A2A 类协议的兴起）、执行环境的沙箱隔离（代码执行与浏览器操作的容器化，库内 Agent 沙箱相关篇讲过 E2E 沙箱的形态）。这些 Agent 时代的基础设施需求，正在反向定义模型操作系统的功能清单——今天争论的「这层要不要独立存在」，在 Agent 负载规模化之后会变成「这层由谁来承载」，因为届时没有任何应用团队能够裸写这些设施。

这个视角也解释了当前格局里最活跃的并购与产品动作：云厂收购编排框架与记忆公司（把 Agent 基础设施并入托管服务）、模型厂把 Agent 产品内置（OpenAI 的 Agent SDK 与 Responses API、Anthropic 的 MCP 与 Claude Agent SDK——MCP 的开放协议战略正是「用标准抢占工具调用抽象」的经典卡位）、创业公司向垂直场景下沉（通用编排难收费，垂直 Agent 平台先赚到钱）。调度层的卡位战已经从「概念之争」进入「协议之争」——谁的抽象成为行业标准，谁就赢得这层。

开放与封闭：路线之争与协议卡位

调度层的路线之争，本质是「抽象的所有权」之争——开放协议与封闭平台的两条路线各有拥趸。

开放路线的代表是 MCP（Model Context Protocol）与 A2A。MCP 由 Anthropic 发起并开源，把「模型与外部工具、数据源的连接」标准化为统一的协议（服务器与客户端的架构、工具描述的规范），迅速获得 OpenAI、Google 等主要玩家的跟进支持——一个协议成为事实标准的速度前所未有。开放协议的战略价值在于：它把工具生态的所有权从任何单一模型厂手中解放出来（同一个 MCP 服务器可以被所有模型调用），应用开发者因此敢于在协议之上投入长尾建设——生态的正循环由此启动。开放路线的弱点是：协议只定义接口，不锁定用户，竞争又回到「谁的实现最好」——协议层面的中立性不能自动转化为商业护城河。

封闭路线的代表是各家模型厂与云厂的托管平台。封闭平台的逻辑是纵向整合的最优体验：模型、编排、记忆、工具、执行环境在同一平台内闭环，开发者获得开箱即用的完整能力，代价是单厂商锁定。封闭路线的优势在体验与变现速度（企业客户偏好一站式），弱点在中立性的缺失——应用的记忆与工具资产沉淀在单一平台，切换成本既是平台的护城河，也是开发者的心病。

两条路线并非零和：现实里正在形成「开放协议做接口、封闭平台做实现」的分层均衡——就像 HTTP 之上仍有封闭的应用商店与开放的自建服务并存。对创业公司，均衡里的生存位置是「协议之上的最佳实现」：路由网关、记忆数据库、评测可观测这些单品类的最佳实现，可以同时服务开放与封闭两个世界的客户。对应用开发者，均衡意味着一份务实的架构守则：接口层永远用开放协议与开源框架（MCP、开源编排库），实现层可以暂用托管平台，资产层（记忆、数据、工具定义）永远自持——锁定可以发生在实现，不能发生在资产。

为什么这一层会被反复洗牌

模型操作系统最大的结构性风险，藏在它名字的前半截：模型在快速迭代，而操作系统想追求稳定。这层被反复洗牌的机制有三个。

第一个机制是模型能力对中间层的吸收。中间层的每一项功能都在被模型迭代「原地吃掉」：曾经需要外部检索增强的长上下文任务，被上下文窗口的扩大直接吸收（库内长上下文篇讲过百万级窗口的进展）；曾经需要精心设计的 few-shot 提示，被推理模型的原生能力取代；曾经需要外部记忆层的部分场景，被模型原生的持久对话能力覆盖。模型每前进一代，中间层的功能清单就被削掉一截——中间件公司的功能护城河存在天然的保质期，只有「模型永远做不好」的功能（跨应用的中立记忆、企业级治理、多模型路由）才是持久的位置。

第二个机制是范式切换对抽象的重定义。调度层的抽象是围绕当前范式（LLM+工具调用）设计的，而范式本身在变：推理模型改变了路由的度量衡（复杂度判断不再可靠，成本结构剧变）、多模态把「上下文」从文本扩展到全模态流、Computer Use 把工具调用从 API 扩展到屏幕像素——每次范式切换，先前的最优抽象就要重写一遍。这层的「操作系统」属性决定了它必须跟随硬件（模型）的每一代升级重装，这与传统操作系统数十年不变的稳定契约完全相反。

第三个机制是头部玩家的一体化引力。模型厂的平台化让「用一家」越来越顺手：路由、记忆、工具在单平台内天然协同，跨平台的组合方案（开源框架+多模型网关+自建记忆）虽然中立但集成成本更高。引力与反引力的长期拉锯，决定中间件创业公司是「被吸干」（功能被平台内置、客户被平台收编）还是「站稳」（在治理、中立性、垂直深度上建立平台做不到的价值）。给从业者的判断框架：这层的价值不在今天的功能清单，在「模型做不了、平台不愿做、客户离不了」的三重过滤之后剩下的位置——治理与合规（企业的权限审计需求平台不会优先）、跨模型中立（多模型是客户的真实需求而非过渡状态）、垂直场景的深度（医疗、金融的专用编排与评测），是三个过滤后仍然坚韧的位置。

给从业者的观察清单

第一，盯 MCP 生态的规模指标（服务器数量、官方 SDK 覆盖、企业采纳案例）：协议的生态规模是调度层权力分布最直接的投票器。第二，盯模型厂平台功能与中间件创业公司功能的重叠速度：重叠即吸收，被吸收的品类估值需要立即重估。第三，盯云厂商的 AI 平台收入披露口径：托管推理与 Agent 服务的收入增速，是「调度层归云」假设的实证检验。第四，盯推理模型的成本结构变化对路由逻辑的冲击：复杂度路由的前提（成本差数量级）正在被推理模型的统一化削弱，路由层的商业模式需要跟踪验证。第五，盯企业客户在采购 AI 平台时的决策重心：从「模型效果」转向「治理与审计」的转折点，是中立中间层（合规治理方向）价值的先行信号。

小结

模型操作系统是大模型之上正在成形的调度层：路由、上下文、工具调用与记忆四类统一抽象，决定应用的成本效率与能力上限。这层的卡位逻辑清晰而残酷——基础模型厂商向上长（把平台内置进 API）、云平台向下伸（守住下一代云负载入口）、中间件创业公司卡在中间（中立性是唯一护城河），三方拉锯的胜负手是模型能力的商品化速度：模型越同质，中立层越有价值。

Agent 负载的兴起正在把这层从「可选优化」推向「必需设施」：多步执行放大每一类抽象的工程压力，今天的概念之争正在变成明天的协议之争——MCP 的快速标准化证明了协议卡位的速度与价值。开放与封闭的路线之争大概率收敛为「开放协议做接口、封闭平台做实现」的分层均衡，开发者的自保守则是资产层永不锁定。

而这一层最深的结构性风险是名字里的「模型」二字：模型迭代持续吸收中间层功能、范式切换反复重定义抽象、头部平台的一体化引力不断抽干夹缝——中间件的位置需要靠「模型做不了、平台不愿做、客户离不了」的三重过滤持续验证。调度层的战争才刚开局，它的终局形态很可能不是一家独大的「操作系统」，而是一个协议开放、实现分层、治理为王的设施集合——盯协议生态与功能重叠速度，比盯任何一家公司都更能看清这场战争的走向。