OS Agent技术解析：让AI通过视觉与操作系统交互，实现自动化操作
1. 从“能看”到“能干”：OS Agent如何让AI真正学会使用电脑和手机
如果你关注AI领域，最近一年肯定被各种“智能体”刷屏了。从能写代码的Devin，到能帮你订机票、查邮件的AI助手，似乎AI离“数字打工人”的梦想越来越近。但不知道你有没有发现，很多所谓的“智能体”其实还停留在“聊天”层面——它们能理解你的指令，也能生成看似合理的计划，但真要让它们去操作一个真实的软件、完成一个跨应用的复杂任务，比如“帮我把微信里收到的PDF文件用WPS打开，提取第三页的表格，然后发到我的邮箱”，它们往往就“掉链子”了。
这背后的核心瓶颈，就是操作系统的交互鸿沟。人类通过图形界面（GUI）、命令行（CLI）与计算机交互，而AI模型，尤其是大语言模型（LLM），本质上处理的是文本序列。让一个“文本大脑”去理解屏幕上复杂的图标、按钮、菜单层级，并精准地执行点击、拖拽、输入等操作，这中间差了不止一个维度。
这正是“OS Agent”（操作系统智能体）这个新兴领域要解决的根本问题。简单来说，OS Agent就是基于多模态大语言模型（MLLM），能够像人类一样，通过视觉感知和理解操作系统环境（桌面、手机、浏览器），并执行具体操作来完成任务的AI智能体。它不只是一个聊天机器人，而是一个能真正“上手”干活的数字助手。
我最近深入研读了ACL 2025 Oral论文《OS Agents: A Survey on MLLM-based Agents for Computer, Phone and Browser Use》及其维护的庞大资源库，感触颇深。这个领域的发展速度远超想象，从2023年底的零星探索，到2024年呈井喷之势，各大研究机构和公司都在争相布局。这篇综述论文及其配套的GitHub仓库，可以说是目前最全面、最及时的OS Agent“技术地图”和“论文年鉴”。
在这篇文章里，我不打算简单复述论文内容，而是想结合我自己的理解和行业观察，为你拆解OS Agent的技术内核、发展脉络、核心挑战以及未来的可能性。无论你是研究者、开发者，还是对AI应用前景感兴趣的观察者，相信都能从中获得启发。
2. OS Agent全景解析：它到底是什么，又为何如此重要？
2.1 重新定义“智能体”：从文本规划到具身交互
传统基于LLM的智能体，其工作流可以概括为：接收文本指令 -> 进行任务分解和规划（Think）-> 调用工具API（Act）-> 返回结果。这里的“Act”往往是通过预定义的函数调用（Function Calling）来实现，比如调用搜索引擎API、计算器API等。这种模式的局限非常明显：它严重依赖于预先封装好的、结构化的API。世界上有数以百万计的软件和应用，每个软件的界面、功能、交互逻辑都不同，为每一个都开发一套API是不现实的。
OS Agent的突破在于，它试图让AI直接与最通用的人机交互接口——即操作系统提供的图形界面（GUI）和命令行界面（CLI）——进行交互。这就好比教会AI“看”屏幕、“动”鼠标和键盘，而不是为它准备一堆专用的“遥控器”。其核心范式转变如下：
- 感知模态的升级：从纯文本输入，升级为多模态输入，特别是屏幕视觉信息。智能体需要理解截图或实时视频流中的UI元素（按钮、输入框、菜单）、布局、文字内容及其状态（是否可点击、是否已勾选）。
- 动作空间的统一：将复杂的软件操作，抽象为一套基础的、跨平台的原子动作。例如：
click(x, y)（点击坐标）、type(text)（输入文本）、scroll(direction)（滚动）、press(key)（按键）。这样，无论面对的是Chrome浏览器还是Photoshop，智能体执行的都是同一套基本操作。 - 决策逻辑的闭环：智能体需要根据任务目标、当前屏幕状态和历史操作记录，动态决定下一步执行哪个原子动作。这形成了一个“观察-思考-行动-再观察”的闭环。
一个生动的类比：想象教一个从没接触过电脑的人使用Excel。传统API智能体就像给他一本写满了“求和用=SUM()”、“排序点数据选项卡”的说明书（API文档），他只能照章办事。而OS Agent则是让他坐在电脑前，看着屏幕，你告诉他“把这份销售数据按金额从高到低排个序”。他需要自己观察菜单栏、找到“数据”选项卡、在下拉菜单里找到“排序”、在对话框里选择列和顺序，最后点击“确定”。后者显然更通用，也更接近人类的学习方式。
2.2 核心价值：通向通用人工智能（AGI）的关键拼图
为什么OS Agent被寄予厚望？因为它解决的是AI落地“最后一公里”的普适性问题。
- 无限的技能扩展性：一旦一个OS Agent学会了通过GUI操作一个软件（比如Word），那么理论上，它就能操作任何具有GUI的软件，无需为每个软件单独训练或开发接口。这为AI技能的指数级扩展提供了可能。
- 降低自动化门槛：目前的企业自动化（RPA）需要专业人员编写脚本，流程僵硬，维护成本高。OS Agent有望让普通用户通过自然语言描述就能创建自动化流程，实现“所说即所得”的自动化。
- 弥合数字鸿沟：对于不熟悉复杂软件操作的用户（如老年人），OS Agent可以充当“数字领航员”，帮助他们完成在线政务办理、医疗预约、金融操作等任务。
- 成为真正的个人数字助理：未来的个人AI助手不应只是一个问答盒子，而应该能真正接管你的手机和电脑，帮你处理日常琐事：整理文件、回复消息、管理日程、订购商品、创作内容等。OS Agent是实现这一愿景的核心技术。
从产业角度看，这也是各大科技巨头（如谷歌、微软、Meta）以及国内头部公司（如OPPO、字节跳动）积极投入的原因。谁先掌握了成熟可靠的OS Agent技术，谁就可能在下一代人机交互和操作系统生态中占据主导地位。
3. 技术架构深潜：一个OS Agent是如何工作的？
要构建一个能用的OS Agent，远不是“截图喂给GPT-4V然后让它输出坐标”那么简单。它是一个复杂的系统工程。根据综述论文的梳理，一个典型的OS Agent框架通常包含以下几个核心模块：
3.1 感知模块：让AI“看懂”屏幕
这是OS Agent的“眼睛”。其目标是将像素级的屏幕图像，转化为智能体能够理解的结构化环境状态表示。目前主流的方法可以分为几类：
端到端视觉语言模型（VLM）：这是目前最主流、效果也最好的方向。代表工作如CogAgent、Ferret-UI系列。这些模型在大量网页和移动端UI截图数据上进行训练，学会了将UI元素（如按钮、图标、文本框）与自然语言描述关联起来。它们可以直接接收屏幕截图和用户指令，输出对UI的理解（如“这是一个搜索框”）或直接输出动作（如“点击右上角的蓝色按钮”）。
- 优势：能力强，能处理复杂、动态的界面。
- 挑战：需要海量高质量的标注数据（图片+标注）进行训练，成本高昂；模型较大，推理速度可能成为瓶颈。
基于UI结构树的解析：这种方法不直接处理像素，而是先通过工具（如Android的
uiautomator、网页的DOM）提取当前界面的UI元素树（Accessibility Tree）。每个元素都有类型、坐标、文本、可操作属性等信息。智能体接收的是这份结构化的文本描述。- 优势：信息精确、结构化，无需视觉模型，处理速度快。
- 挑战：严重依赖于系统提供的可访问性接口，不同平台、不同应用的支持程度不一；无法处理纯图片或自定义绘制的控件；丢失了视觉上下文（如图标含义、布局美感暗示的优先级）。
混合感知（Dual Grounding）：结合上述两者，既利用视觉模型理解整体布局和图标语义，又利用结构树获取精确的坐标和属性。例如AppAgent、OSCAR就采用了这种策略。视觉模型负责“找大概位置”，结构树负责“精确定位”，两者互补，鲁棒性更强。
实操心得：感知模块的选型陷阱在实际开发或研究中，选择哪种感知方案需要权衡。如果你的目标环境是标准化的Web应用或主流移动App，基于UI结构树的方法性价比最高，速度快且稳定。但如果你要处理老旧桌面软件、游戏界面或高度自定义的UI，视觉模型几乎是唯一选择。混合感知是方向，但会引入额外的复杂度和延迟。一个实用的技巧是：可以先尝试用开源工具（如
playwright、appium）获取结构树，如果获取失败或信息不全，再fallback到视觉模型。
3.2 规划与决策模块：让AI“想清楚”再动手
这是OS Agent的“大脑”。它需要根据任务目标（“预订明天北京到上海的机票”）和当前环境状态，生成一系列原子动作。单纯的“一步一步来”是不够的，高效的规划需要更高级的策略：
- 任务分解与子目标规划：将复杂任务拆解为可执行的子步骤。例如，“订机票”可以分解为：打开浏览器 -> 导航到航司官网 -> 选择出发/到达城市和日期 -> 筛选航班 -> 选择航班 -> 填写乘客信息 -> 支付。LLM在此处扮演了“项目经理”的角色。
- 探索与回溯：智能体在操作中可能会走入死胡同（比如点错了按钮进入无关页面）。它需要有能力识别当前状态偏离了目标，并执行回溯（undo）或尝试其他路径。这通常需要维护一个历史状态栈或利用强化学习来学习在失败时如何调整策略。
- 上下文学习与Few-shot提示：为了让LLM更好地理解GUI操作，可以在提示词（Prompt）中提供少量示例（Demonstration）。例如，给出“如何点击登录按钮”的一两个截图和动作序列，模型就能举一反三。Synatra、NNetscape Navigator等工作就专注于如何高效生成或利用这些演示数据。
- 程序合成：对于一些重复性高、逻辑固定的任务（如数据清洗、报表生成），让智能体直接生成可执行的脚本（如Python +
pyautogui、AppleScript）可能比一步步模拟点击更高效。SheetCopilot（操作Excel）就是这方面的典型。
3.3 记忆与状态管理模块：让AI“记住”发生了什么
GUI交互是状态ful的。点击一个按钮后，整个界面可能完全改变。智能体必须有能力跟踪和管理这些状态变化。
- 短期记忆/工作记忆：记录当前任务执行到哪一步，刚刚执行了什么操作，以及操作的结果是什么。这通常通过在LLM的对话上下文中维护一个动作历史列表来实现。
- 长期记忆/经验记忆：存储跨任务、跨会话的有用经验。例如，智能体在操作某个特定软件（如Slack）时，学会了“发送消息需要先点击输入框”。当下次再遇到Slack时，它可以直接调用这个经验，无需重新探索。这可以通过向量数据库存储成功的轨迹（Trajectory）来实现，如Synapse框架所做的那样。
- 状态差异检测：为了减少不必要的截图和推理，智能体需要能判断界面是否发生了“有意义”的变化。简单的像素对比不行（因为可能有动画），更高级的方法是比较UI结构树的前后差异，或使用视觉模型判断“语义变化”。
3.4 执行模块：从指令到真实操作
这是OS Agent的“手”。它负责将规划模块输出的原子动作（如click(‘登录’, ‘button’)），转化为操作系统级别的真实事件。
- 动作映射：需要将抽象的指令映射到特定平台的API。在Windows上，
click(x, y)可能调用pyautogui.click()；在Android上，可能调用adb shell input tap；在浏览器中，可能通过playwright的API来执行。 - 坐标计算：如果感知模块输出的是元素标识符（如
id或text），执行模块需要查询UI结构树获取其精确坐标。如果是视觉模型直接输出的坐标，则需要考虑屏幕分辨率缩放等问题。 - 操作延迟与可靠性：模拟人类操作时，需要在动作之间加入合理的延迟，等待界面加载稳定。同时，要有重试和异常处理机制，比如点击后元素没反应，是应该等待、重试还是报告失败？
注意事项：执行阶段的“魔鬼细节”执行阶段最容易出问题，且问题最隐蔽。例如：
- 焦点问题：点击输入框前，可能需要先点击一下窗口激活它。
- 弹窗拦截：操作可能意外触发浏览器弹窗，遮挡目标元素。
- 网络延迟：网页加载速度不确定，固定的等待时间可能不够。
- 跨平台兼容性：在macOS和Windows上，一些快捷键（如复制粘贴）是不同的。 一个健壮的OS Agent执行器，必须包含大量的条件判断和容错逻辑，这部分代码往往比核心算法更“脏”，但也更关键。
4. 核心挑战与前沿突破：当前的研究热点在哪里？
通过对综述中近百篇论文的梳理，我发现当前OS Agent领域的研究主要围绕以下几个核心挑战展开，并涌现出了一批有代表性的解决方案：
4.1 挑战一：如何获得海量、高质量的GUI交互数据？
监督学习需要数据，而GUI交互数据（屏幕截图+对应动作序列）的标注成本极高。研究者们想出了各种办法：
- 合成数据（Synthetic Data）：这是目前的主流方向。EDGE、Synatra等工作利用现有的LLM（如GPT-4）或规则，自动生成大量的（指令，截图，动作）三元组。例如，让LLM描述一张截图，再让它根据描述生成可能的操作指令和动作。虽然数据质量可能不如人工标注，但量足够大，能有效提升模型的泛化能力。
- 从教程和视频中学习：AgentTrek等研究尝试从互联网上海量的软件教程网页、视频中提取操作步骤。这相当于让AI“看”人类的教学视频来学习，是非常有潜力的数据来源。
- 自我探索与强化学习：让智能体在模拟环境（如AndroidWorld、WebArena）中自己尝试，通过奖励信号（是否完成任务）来学习。AutoWebGLM、WebAI就采用了RL来优化智能体的策略。这种方式数据获取自动，但探索效率低，训练不稳定。
4.2 挑战二：如何提升长程、复杂任务的规划能力？
很多任务不是一两次点击就能完成的，可能需要几十甚至上百步，跨越多个应用。
- 分层规划（Hierarchical Planning）：先进行高层规划（“先写邮件，再添加附件，最后发送”），再对每个子任务进行细粒度规划。这能避免智能体在细节中迷失。
- 反思与修正（Reflection & Replanning）：框架如OSCAR、RCI强调在行动后对结果进行“反思”。如果发现状态不符合预期（比如点击后没反应，或进入了错误页面），就触发重新规划。这赋予了智能体从错误中恢复的能力。
- 利用外部知识：当任务涉及专业知识（如“用Photoshop给图片去背景”）时，让智能体具备搜索能力或调用知识库至关重要。PUMA（个性化Web智能体）就探索了如何结合用户的历史行为和偏好来辅助规划。
4.3 挑战三：如何让模型更精准地“指哪打哪”（GUI Grounding）？
即使模型知道要“点击登录按钮”，但屏幕上可能有多个类似按钮，或者按钮的位置表述模糊（“右上角”）。精准的视觉定位（Grounding）是关键。
- 高分辨率视觉理解：UI元素通常很小，需要模型能处理高分辨率图片并关注细节。CogAgent采用了特殊的视觉编码器来处理高清截图。
- 指代表达（Referring Expression）：训练模型理解更复杂的描述，如“点击标题栏下面第二个选项卡”、“双击那个最大的图片”。Ferret-UI系列模型在此方面做了重点优化。
- 多轮对话式交互：当指令模糊时，智能体应该能像人类一样发起澄清询问。例如，用户说“删除它”，智能体可以反问“您指的是‘报告.pdf’这个文件吗？”
4.4 挑战四：如何构建真实、可复现的评估基准？
没有好的评估，就无法衡量进步。OS Agent的评估极具挑战性，因为任务开放，环境动态。
- 仿真环境（Simulated Environments）：如WebArena、AndroidWorld，它们提供了可控、可复现的虚拟环境来运行和测试智能体。优点是评估稳定、自动化；缺点是环境可能与真实世界有差距。
- 真实环境测试（Real-World Testing）：如WindowsAgentArena、LlamaTouch，直接在真实的操作系统或设备上部署智能体进行评估。结果最可信，但成本高、难以规模化，且存在安全风险。
- 评估指标：除了最终的任务成功率，还需要关注路径效率（用了多少步完成）、人类干预频率、执行速度等。B-MoCA等基准测试开始关注智能体在不同设备配置（屏幕尺寸、分辨率）下的鲁棒性。
5. 实战指南：如果你想入门或开发一个OS Agent
看完了理论和研究前沿，如果你摩拳擦掌想自己动手试试，这里有一些基于当前最佳实践的实操建议。
5.1 技术选型与工具链
对于初学者或快速原型开发，我推荐以下分层策略：
原型验证层（快速启动）：
- 核心模型：直接使用现成的、支持视觉问答的API，如GPT-4V(ision)、Claude 3 Opus、或开源的CogAgent、Ferret-UI。这是最快验证想法的方式。
- 框架：使用成熟的Agent框架，如LangChain、AutoGPT的变体，或OS Agent专用框架如Cradle、OS-Copilot。它们提供了记忆、规划、工具调用等基础组件。
- 环境控制：对于桌面自动化，
pyautogui+Pillow（截图）是最简单的组合。对于浏览器，playwright或selenium是行业标准。对于手机，appium是首选。
深度定制层（追求性能与可控）：
- 感知模型：如果对精度和速度要求高，可以考虑微调一个开源的VLM。LLaVA是一个不错的基底模型，可以在自己的GUI数据上继续训练。
- 规划模型：使用更强的LLM作为“大脑”，如GPT-4、Claude 3或开源的Qwen 2.5 72B。通过精心设计的提示词工程（Prompt Engineering）来提升其规划能力。
- 自定义框架：当现有框架无法满足需求时，需要自己搭建。核心是设计好状态管理、动作执行和错误处理的流水线。
5.2 数据准备：你的第一个GUI数据集
哪怕只是做微调，你也需要数据。可以从简单的开始：
- 录制与标注：使用
pyautogui录制你自己的操作过程，同时保存屏幕截图。然后，手动或半自动地为每一帧截图标注你执行的动作（类型、坐标或目标元素）。这是一个笨办法，但能获得高质量、贴合你需求的数据。 - 利用现有数据集：综述论文的GitHub仓库里列出了大量相关数据集，如AITW（Android in the Wild）、Mind2Web。你可以下载这些公开数据集进行学习或微调。
- 合成数据：学习EDGE或Synatra的思路，用GPT-4V API批量分析一批UI截图，让它生成可能的指令和动作，作为弱监督数据。
5.3 开发流程与避坑指南
- 从简单、封闭的任务开始：不要一开始就挑战“管理我的整个电脑”。从“在记事本里写一首诗并保存”或“在电商网站搜索特定商品”这样的单一、目标明确的任务开始。
- 建立强大的日志和可视化系统：这是调试的生命线。记录下每一步的截图、模型接收的提示词、模型的输出、执行的动作。最好能有一个界面回放整个执行过程，像看录像一样找出问题所在。
- 重视异常处理：你的代码中，异常处理的部分应该和核心逻辑一样多。网络超时、元素未找到、弹窗出现、权限问题……都需要有相应的应对策略（重试、跳过、上报人工）。
- 安全第一：OS Agent拥有很高的权限。务必在沙箱环境（虚拟机、容器）中进行开发测试。绝对不要让它直接操作存有重要资料的生产环境。
- 性能优化：截图、调用大模型都很耗时。考虑使用缓存（界面未变化时不重复截图）、异步操作、以及使用更小更快的本地模型来处理一些简单判断（如“界面加载完成了吗？”）。
5.4 常见问题排查实录
在实际开发中，你肯定会遇到下面这些问题，以下是我的排查思路：
问题：模型总是点错地方。
排查：首先检查截图是否清晰、完整。然后检查传递给模型的提示词：是否包含了足够的上下文？是否明确要求输出坐标或元素标识？最后，检查坐标映射是否正确（屏幕分辨率、缩放比例）。
解决：尝试在提示词中加入1-2个正确操作的示例（Few-shot）。或者，换用GUI Grounding能力更强的专用模型（如Ferret-UI）。
问题：任务执行到一半卡住了，好像“死机”了。
排查：查看日志，检查模型最后输出的动作是什么？执行是否成功？当前屏幕状态是否和模型“想象”的状态不一致？
解决：这通常是状态管理出了问题。增加“超时与心跳”机制：如果一段时间没有新动作，主动截一张图，让模型重新分析当前状态并决策。或者，在规划时强制加入“确认状态”的步骤。
问题：在A电脑上运行良好，在B电脑上完全失效。
排查：这是环境差异的典型表现。检查屏幕分辨率、缩放比例、系统主题、默认字体大小。这些都会影响UI元素的视觉呈现和坐标。
解决：让感知模块更具鲁棒性。不要过度依赖绝对坐标，而是依赖元素的相对位置或视觉特征。如果使用结构树，确保在不同环境下都能稳定获取。
问题：处理弹窗、通知等意外中断。
排查：这是真实环境与仿真环境的最大区别。你的智能体需要有“背景意识”。
解决：设计一个“守护”进程，定期检查屏幕是否有预料之外的弹窗（可以通过检测固定区域像素变化，或用小模型快速分类）。一旦发现，优先处理弹窗（如点击“确定”或“忽略”），再回到主任务。
6. 未来展望：OS Agent将走向何方？
基于当前的研究趋势和我的判断，OS Agent在未来1-3年可能会在以下几个方向取得突破：
- 模型小型化与专用化：像TinyClick这样的工作表明，专门为GUI操作设计的小模型，在特定任务上可以媲美甚至超越通用大模型，且延迟和成本低得多。未来可能会出现一系列轻量级、垂直领域的OS Agent模型。
- 多模态交互的融合：未来的OS Agent可能不仅会“看”和“点”，还能“听”和“说”。结合语音识别与合成，实现真正的自然语言交互。甚至结合AR/VR，在三维空间中进行操作。
- 与操作系统的深度集成：目前的OS Agent大多是“外挂”式的。未来的操作系统可能会原生集成AI智能体层，提供更稳定、高效、安全的API和运行时支持，让智能体成为系统的一部分。
- 从“自动化”到“智能化”：当前的OS Agent主要还是在模仿人类预设的操作流程。下一步是让它们具备真正的“理解”和“创造”能力。例如，看到一份杂乱的数据，不仅能应要求生成图表，还能主动分析并指出：“这份数据第三季度有异常下降，建议重点关注。”
- 安全、伦理与可控性：能力越强，责任越大。如何防止OS Agent被恶意利用？如何确保它的行为符合用户意图（对齐问题）？如何设计“急停”开关？这些将成为产品化过程中必须解决的首要问题。
OS Agent正在将AI从“世界的观察者”转变为“世界的操作者”。这条路充满挑战，从精准的视觉理解到复杂的任务规划，从可靠的动作执行到安全的风险控制，每一个环节都需要深耕。但它的潜力是巨大的——它有望彻底改变我们与数字世界交互的方式，让每个人都能拥有一个不知疲倦、无所不能的数字分身。
这篇综述及其背后的社区，为我们点亮了前进路上的灯塔。剩下的，就是结合具体的场景，去动手构建、测试、迭代。无论是想做一个帮你自动整理照片的桌面助手，还是一个能处理客服工单的流程机器人，现在都是最好的起点。技术已经铺就了跑道，是时候让你的创意起飞了。