AI Agent 开发｜如何将 LLM、VLM 技术落地操作系统业务

一、开篇：操作系统正在经历第三次跃迁

如果你还在把 AI 当成操作系统上的一个“应用”，那你可能已经落后了。2026 年，操作系统正在经历一次根本性的范式转变——从“运行应用的平台”变成“调度智能体的舞台”。

回顾历史，操作系统经历了两次重大跃迁：最早的指令型操作系统要求人类强迫自己理解机器；后来的图形化界面（GUI）操作系统大大简化了人机交互，催生了繁荣的终端生态。而如今，我们正在迎来第三次跃迁——操作系统通过设备主动服务用户，迈向以智能体为核心的 Agentic OS 时代。

这一判断正在被产业界迅速验证。微软正式确认 Windows 11 将演进为“智能体操作系统”，用户未来通过“Hey Copilot”语音指令，就能让 PC 自主理解并执行跨应用的复杂任务。阿里云发布了首款 AI 智能体电脑 Qwen Book，基于“OS as Harness”核心理念，让 AI 从“普通专家”变成主动理解、始终在场、持续进化的“专属专家”。荣耀则提出了将 MagicOS 升维成“伙伴型多模态智能体操作系统”的战略，把硬件层、系统层、生态层等六层技术栈进行全面重构。

这些动作的背后，是一个核心命题：如何将 LLM 和 VLM 的技术能力真正落地到操作系统业务中？ 本文将从技术架构、关键路径、工程实践和落地路线图四个维度，系统性地回答这个问题。

二、技术全景：LLM 与 VLM 在操作系统中的能力定位

2.1 两种模型，两种使命

要在操作系统层面落地 AI Agent，首先需要理解 LLM 和 VLM 各自扮演的角色。

LLM（大语言模型） 负责的是“认知层”的工作——理解用户意图、拆解复杂任务、进行逻辑推理和规划。它是 Agent 的“大脑”，决定了 Agent 能否正确理解用户想要什么，以及能否制定出合理的执行计划。

VLM（视觉语言模型） 负责的是“感知层”的工作——理解屏幕上的视觉信息、定位可交互元素（按钮、输入框、菜单等）、识别界面状态变化。它是 Agent 的“眼睛”，决定了 Agent 能否准确定位操作目标并感知执行结果。

这两者的协同关系可以用一个简单的公式概括：

Agent 能力 = LLM（理解 + 规划） + VLM（感知 + 验证） + 执行引擎（操作 + 反馈）

在传统的应用层 AI 助手中，这三者往往被割裂在不同模块中。而在操作系统层面，它们需要被深度整合，形成统一的认知回路。

2.2 从“AI on OS”到“AI for OS”

openKylin 社区提出了一个很有价值的概念转换：从“AI on OS”（在操作系统上运行 AI）到“AI for OS”（AI 作为操作系统的核心能力）。

这个转换的实质区别在于：

• AI on OS：AI 是一个独立的应用或服务，通过 API 调用操作系统功能。这种模式下，AI 的能力受限于预定义的接口，无法灵活应对复杂的跨应用场景。
• AI for OS：AI 被嵌入操作系统的底层架构中，AI 模型成为与内存、算力并列的系统资源，由操作系统统一调度和管理。这意味着 Agent 可以直接访问系统级的感知和操作能力，实现真正的端到端任务执行。

荣耀产品线总裁方飞对此有一个精辟的观察：“操作系统的资源管理对象正在从内存和算力，扩展到模型与智能体。”这句话点明了 Agentic OS 的本质——操作系统需要像管理进程和内存一样，管理 AI 模型的调度、Agent 的生命周期和任务执行。

三、核心架构：系统级 Agent 的技术栈设计

3.1 Agent Harness：操作系统与模型之间的“黏合层”

在将 LLM/VLM 落地操作系统的工程实践中，一个关键问题是：模型的理解能力和操作系统的执行能力之间，存在巨大的“鸿沟”。模型知道用户想要什么，但不知道如何通过操作系统的 API 来实现；操作系统知道怎么执行，但不理解自然语言指令。

荣耀打造的系统级 Agent Harness 架构正是为了弥合这一鸿沟。该架构把模型与感知、规划、工具调用和执行组织起来，让 Agent 从“能理解”进一步走向“能稳定执行”。

从工程视角看，Agent Harness 的核心职责包括四个层面：

第一层：模型路由与调度。 不同任务需要不同规模和能力的模型。简单的意图识别用 4B 小模型，复杂的多步推理用 27B 大模型，屏幕元素定位用专门的 VLM 模型。Harness 需要根据任务类型和系统资源状态，动态选择最合适的模型。

第二层：工具调用与执行。 操作系统提供了大量的系统 API、应用接口和设备控制能力。Harness 需要将这些能力封装为 LLM 可调用的“工具”，并通过标准化的函数调用协议（如 OpenAI Function Calling 或 MCP）暴露给模型。微软在 Windows 11 中正是通过引入模型上下文协议（MCP）来实现 Agent 对原生应用的安全访问。

第三层：状态管理与记忆。 Agent 执行多步任务时，需要维护任务进度、历史操作记录、上下文信息等。这些状态需要在模型切换、进程调度等场景下保持一致性。

第四层：安全与权限控制。 Agent 的操作涉及文件读写、应用启动、网络访问等敏感行为，必须有完善的权限管理机制。

3.2 五大垂域模型：按认知回路切分角色

在模型层面，荣耀与阿里合作构建的五大垂域模型提供了一个非常清晰的架构参考：

模型	职责	关键特性
端侧 Omni	多模态感知融合	端侧部署，低功耗
端侧 VLM	屏幕视觉理解	实时截图分析，元素定位
GUI Agent	界面操作执行	精确点击、滑动、输入
Agentic Fast	快速意图响应	低延迟，简单任务
Agentic Pro	复杂推理规划	长链路任务分解

这种设计的核心思想是“按智能体的认知回路切分角色”——Pro 负责复杂推理，Fast 负责快速响应，GUI Agent 负责具体执行。五个模型相互协同，覆盖从感知、理解、规划到执行的完整链路。

从工程实践角度看，这种分工模式有两个关键优势：

一是延迟优化。 用户说一句话，意图理解可能只需要 200ms（Fast 模型），但如果用 Pro 模型来处理，可能需要 3-5 秒。通过合理的任务分流，可以在保证质量的前提下大幅降低响应延迟。

二是资源优化。 不是所有任务都需要大模型。将轻量任务交给小模型，可以让大模型专注于真正需要深度推理的复杂场景，从而在有限的端侧算力上实现更好的整体表现。

3.3 认知分片：在消费级硬件上运行 Computer-Use Agent

五大模型的分工模式在端云协同场景下表现出色，但对于完全本地化部署的 Computer-Use Agent，业界探索了另一种架构范式——认知分片。

认知分片的核心思路是将 Computer-Use Agent 所需的多种认知功能，分配给不同的专家模型，而不是让一个大型多模态模型承担所有任务。参考实现使用了三个模型：Bonsai 2 27B 负责深思熟虑的推理和规划，Kev 4B 负责快速的 System 1 决策，UI-Mate 9B 负责视觉定位。这些模型通过一个代码拥有的控制平面进行协调，管理状态、路由、执行、验证和恢复。

这种架构与传统的单一模型方案相比，优势在于：每个交互只付出其实际需要的计算成本，而不是每次都付出最复杂交互的内存和延迟代价。同时，不同模型的失败模式被隔离，不会因为一个模型的错误而影响整个 Agent 的行为。

该架构可以在一台 16GB 内存的消费级电脑上本地运行，这对于将 AI Agent 落地到普通用户的 PC 和笔记本上具有重要的实践意义。

四、关键技术路径

4.1 屏幕理解与元素定位（VLM 核心能力）

VLM 在操作系统中最核心的能力是 GUI Grounding——将自然语言描述映射到屏幕上的具体坐标位置。例如，用户说“点击登录按钮”，Agent 需要知道“登录按钮”在屏幕上的精确位置。

当前主流的 GUI Grounding 方法包括：

基于坐标回归的方法：直接让 VLM 输出目标元素的坐标。这种方法简单直接，但精度受限于 VLM 的空间理解能力。

基于区域提议的方法：先用分割模型（如 SAM）生成候选区域，再让 VLM 判断哪个区域是目标元素。R-VLM 提出的区域感知视觉语言模型就是这种思路，通过引入区域提议和 IoU 感知机制，显著提升了 grounding 精度。

蒙特卡洛定位方法：将坐标估计问题转化为排序问题，通过在屏幕区域放置确定性的七点六边形模板，让 VLM 判断“哪个点最接近目标”，从而在多次探测中逐步逼近精确位置。

从工程落地的角度，一个实用的建议是：不要依赖单一的 grounding 方法，而是构建多层次的元素定位流水线。第一层用轻量级方法快速缩小范围，第二层用高精度 VLM 精确定位，第三层用执行反馈进行验证和修正。

4.2 任务规划与执行（LLM 核心能力）

LLM 在操作系统 Agent 中的核心任务是：将用户的自然语言需求，转化为可执行的操作序列。

以 Agent S 框架为例，它引入了经验增强的层次化规划方法，通过外部知识搜索和内部经验检索，在多个层次上促进高效的任务规划和子任务执行。同时，它还设计了 Agent-Computer Interface（ACI），更好地激发 GUI Agent 基于多模态大语言模型的推理和控制能力。

从实际操作系统的落地角度看，任务规划需要解决几个具体问题：

跨应用编排：用户说“帮我把这个网页的内容整理成一份报告发到邮箱”，这涉及浏览器、文本编辑器、邮件客户端三个应用。LLM 需要理解每个应用的能力边界，并规划出合理的调用顺序。

动态适应：界面可能因应用版本更新而发生变化，网络请求可能超时，弹窗可能意外出现。Agent 需要具备实时调整计划的能力。

执行验证：每一步操作执行后，Agent 需要验证操作是否成功。这通常需要 VLM 再次“看”屏幕，判断界面状态是否符合预期。

4.3 记忆与上下文管理

操作系统级 Agent 与普通对话式 AI 的一个重要区别是：Agent 需要维护长期记忆。用户今天让 Agent 整理了一份文档，明天可能说“把昨天那份文档再改一下”。Agent 需要记住“昨天那份文档”是什么。

EverMemOS 提出了一个自组织记忆操作系统的概念，将记忆建模为动态生命周期：情节轨迹形成 → 语义整合 → 重构回忆。这种设计让 Agent 能够在长期交互中积累对用户的理解，变得越来越“懂你”。

在工程实现上，记忆系统通常分为三层：短期记忆（当前任务的上下文）、工作记忆（近期任务的摘要）和长期记忆（用户偏好、常用操作模式等）。操作系统层面对记忆的管理，还需要考虑隐私和安全——用户的个人数据应该存储在本地还是云端？不同应用的记忆是否需要隔离？

五、端侧部署：让 LLM 和 VLM 真正“跑在设备上”

5.1 模型压缩：量化、剪枝与蒸馏

将 LLM 和 VLM 部署到端侧设备（手机、PC）上，面临的最大挑战是资源约束——内存容量、带宽、延迟和功耗都成为系统行为的决定性因素。

当前主流的压缩技术包括：

量化：将模型权重从 FP16 压缩到 INT8、INT4 甚至更低精度。一篇综述论文建议，应优先应用量化来优化内存占用和首 token 时间，然后将结构化剪枝与可合并的低秩补偿配对使用。

剪枝：去除模型中不重要的连接或结构，减少参数量和计算量。

知识蒸馏：用大模型“教”小模型，让小模型获得接近大模型的性能。

KV Cache 管理：将 KV Cache 作为一等子系统来对待，通过分页、压缩和驱逐策略进行管理。

5.2 端云协同推理

并非所有任务都适合在端侧运行。Agentic Pro 级别的复杂推理任务，在端侧运行可能需要数十秒，用户体验不可接受。因此，端云协同是务实的选择。

荣耀与阿里的合作正是这一思路的体现：双方根据端侧功耗、内存和时延要求，共同决定模型的参数规模和能力边界。并非所有能力都要放在端侧，也并非所有任务都依赖云侧，而是根据实际场景进行端云分工。

从工程角度看，端云协同的关键是智能路由——系统需要根据任务复杂度、网络状态、隐私要求和用户偏好，自动决定任务在端侧还是云侧执行。例如，简单的意图识别和屏幕元素定位可以在端侧完成（保护隐私、降低延迟），而复杂的多步推理和知识密集型任务则交给云侧大模型。

5.3 实际落地数据

荣耀披露的数据显示，在新模型和解决方案支持下，新一代 YOYO 综合任务准确率达到 91.8%，GUI 平均操作耗时 3.6 秒，最大可操作步数超过 100 步，端到端任务闭环率达到 90%。这些数据说明，经过系统级优化的端云协同方案，已经能够达到用户可接受的体验水平。

六、安全与权限：不可忽视的工程基石

当 Agent 获得了操作系统的深层控制能力——读写文件、启动应用、访问网络——安全就成为一个无法回避的问题。

6.1 分层安全架构

阿里云发布的 Agentic OS 采用了基于 Bubblewrap 和 seccomp 的运行时行为管控与沙箱隔离技术，实时监控 Agent 操作行为，自动拦截危险指令（如非法删除、越权访问），并为每个 Agent 进程启用进程级轻量化容器沙箱，实现多 Agent 间的资源隔离。

学术界的 AgenticOS 研究进一步提出了 Intent-Oriented 的安全架构，包含三个核心组件：Logic Shutter（逻辑快门）、Agent Capsule（Agent 胶囊）和 Semantic Boundary Gateway（语义边界网关）。

6.2 权限模型设计

在操作系统层面，Agent 的权限模型需要解决几个新问题：

Agent 身份识别：传统操作系统通过 PID 和 UID 识别进程，但多个 Agent 可能运行在同一个进程中。DROS 提出将执行身份与底层 FFI 执行期绑定，弥合应用层语义与系统层强制力之间的鸿沟。

细粒度权限控制：Agent 不应该拥有“全有或全无”的权限，而应该根据任务上下文动态授予最小必要权限。

人机协同审批：对于敏感操作（如删除文件、发送邮件），系统应该暂停执行并等待用户确认，而不是让 Agent 自主决策。

七、落地路线图：从简单到复杂的四阶段实践

基于以上技术分析，我建议将 LLM/VLM 在操作系统业务中的落地分为四个阶段：

阶段一：单点能力嵌入（1-3 个月）

目标：在操作系统的一个具体功能中嵌入 LLM 能力。

实践建议：从系统搜索开始。将传统的关键词搜索升级为语义搜索，让用户可以用自然语言描述需求。例如，用户说“帮我找一下上周修改过的那份关于预算的文档”，系统通过 LLM 理解意图后，结合文件元数据和内容进行检索。

技术栈：LLM（意图理解）+ 向量数据库（语义检索）+ 系统 API（文件系统）。

阶段二：跨应用任务执行（3-6 个月）

目标：让 Agent 能够跨应用执行简单的多步任务。

实践建议：从“打开应用 + 执行操作”的二步任务开始。例如，“打开浏览器搜索今天的天气”或“在备忘录里新建一条笔记”。

技术栈：LLM（任务规划）+ VLM（界面理解）+ GUI Agent（操作执行）。

关键挑战：界面变化的鲁棒性。建议构建 UI 元素的多模态表示（视觉特征 + 文本标签 + 层级结构），而非仅依赖坐标定位。

阶段三：系统级 Agent Harness（6-12 个月）

目标：建立系统级的 Agent 调度框架，支持多模型协同和长链路任务执行。

实践建议：参考荣耀的 Agent Harness 架构，实现模型路由、工具注册、状态管理和安全沙箱四大核心模块。同时建立 Agent 能力的评估体系，持续追踪任务成功率、执行效率和用户满意度。

技术栈：多模型推理框架 + 工具调用协议（MCP/Function Calling）+ 沙箱隔离 + 记忆系统。

阶段四：Agentic OS 生态（12 个月以上）

目标：操作系统从“支持 Agent 运行”升级为“以 Agent 为核心设计”。

实践建议：重新设计系统交互入口（从 GUI 到 NUI）、重新定义应用形态（从 App 到 Agent 可调用的 Skill）、建立 Agent 生态的分发和治理机制。

参考范式：阿里 Qwen Book 的“OS as Harness”理念，以及荣耀提出的六层技术栈全面重构方案。

八、总结与展望

将 LLM 和 VLM 技术落地操作系统业务，本质上是解决一个系统级协同问题：模型的能力如何与操作系统的资源管理、应用生态和安全机制深度融合。

从当前产业实践来看，几个趋势已经明确：

第一，模型分工细化。 不再追求“一个大模型解决所有问题”，而是按认知回路切分角色，让合适的模型做合适的事。这是端侧资源约束下的必然选择。

第二，架构从“模型中心”转向“系统中心”。 竞争焦点正从模型参数比拼转向系统能力竞争——感知、记忆、推理、规划和执行的协同演进，才是决定体验的关键。

第三，安全是底线，不是附加项。 Agent 获得的操作系统权限越大，安全设计的挑战就越大。分层沙箱、细粒度权限、人机协同审批，这些机制需要在架构设计阶段就纳入考虑。

第四，端云协同是务实路径。 完全端侧部署在短期内难以达到云端大模型的推理能力，完全依赖云端又面临延迟和隐私问题。根据任务特性动态分配端云资源，是当前最优解。

展望未来，操作系统与 AI Agent 的融合将走向更深层次。当操作系统能够原生理解用户意图、自主编排跨应用工作流、持续学习用户偏好时，“操作系统”这个概念本身将被重新定义——它不再是一个被动的资源管理器，而是一个主动的、个性化的智能伙伴。

对于开发者而言，现在正是进入这个领域的最佳时机。工具链在快速成熟（AIOS、Agent S、GUI-Owl 等开源框架），硬件在持续进化（端侧 NPU 算力逐年提升），用户需求也在被逐步验证。抓住这一波浪潮，你不仅是在开发一个 AI 应用，而是在参与定义下一代操作系统的形态。