Vibe Coding 这个词从 Andrej Karpathy 嘴里说出来之后，几个月内就变成了开发者圈子里的日常用语；用自然语言描述需求、让 AI 生成代码、跑起来看效果------整个编程工作流正在被重新定义。但有一件事在 Vibe Coding 的叙事里被跳过了：开发者每天的工作不只是写代码，还有大量时间花在操作各种桌面应用上，从 Figma 里复制设计规范、到 Jira 里更新任务状态、到 Slack 里同步进度、再到各种内部系统里翻数据。这些操作不涉及代码，却占据了工作日的相当比例。
一个自然的延伸方向出现了：如果 AI 能"写"应用，它能不能直接"操作"应用？
这个方向在技术社区里被越来越多的人称为 Vibe Operating------让 AI 像人一样看着屏幕、理解界面、执行操作。它和 Vibe Coding 的区别在于，后者改变了应用的创建方式，前者改变的是应用的使用方式。两者并不矛盾，甚至在某些场景下会形成互补：AI 写好一个应用，然后另一个 AI Agent 去操作它完成业务流程。
从概念到工程：AI 操作桌面应用需要什么
把一个"AI 操作桌面应用"的想法变成可用的工程系统，需要解决三个层面的问题。
第一层是视觉理解。AI 需要看懂屏幕上正在显示什么------按钮在哪里、输入框是什么状态、当前页面和上一步相比发生了什么变化。这和计算机视觉里的目标检测有交集，但复杂度更高，因为 GUI 界面的元素密度远大于自然场景，一个复杂的企业软件界面上可能同时存在数百个交互元素，而且布局和样式在不同应用之间差异巨大。
第二层是动作规划。看懂了界面之后，AI 需要决定下一步该做什么。这涉及到任务分解------一个"帮我从这个系统里导出上季度的销售数据"的指令，可能需要拆解成登录、导航到报表页面、选择时间范围、点击导出、等待下载完成等多个步骤。每个步骤的执行都依赖对上一步结果的判断，形成一条有状态依赖的操作链。
第三层是环境交互。AI 需要真正把"点击这个按钮""在这输入这段文字"的意图转化为操作系统层面的鼠标和键盘事件，并且能够感知操作是否成功------按钮是否真的被点击了、输入框里的内容是否正确、页面是否跳转到了预期的位置。
这三个层面的技术选型组合起来，就构成了一个 GUI Agent 的完整技术栈。
三条技术路线的分野
目前业界在视觉理解这个层面，走出了三条不同的路线。
第一条是 API 驱动路线，通过系统级 API 或辅助功能接口获取界面元素的结构化信息。这条路线的优势是获取的信息精确------每个元素的类型、位置、状态都能拿到确定性的数据。局限在于它强依赖操作系统提供的辅助功能接口，很多应用并不完整支持这些接口，跨平台兼容性也是个问题。传统 RPA 工具（UiPath、Automation Anywhere）走的基本是这条路。
第二条是浏览器协议路线，通过 Chrome DevTools Protocol 等浏览器调试协议获取网页 DOM 结构。这条路线在 Web 应用场景下非常高效，能精确操作页面元素。但它的天花板也很明显------只能覆盖浏览器里的 Web 应用，桌面原生应用、专业软件、游戏界面这些场景完全触达不到。
第三条是纯视觉路线，AI 直接接收屏幕截图作为输入，像人一样"看"屏幕来理解界面和操作。这条路的好处是场景覆盖最广------只要人能看到的界面，AI 都能处理，不受 API 兼容性和协议支持的限制。难点在于纯靠视觉理解来定位和操作的精度要求很高，对模型的视觉推理能力有很强的要求。
明略科技开源的 Mano-P（https://github.com/Mininglamp-AI/Mano-P）走的就是第三条路。这个端侧 GUI-VLA 智能体模型通过纯视觉驱动的方式实现桌面应用操作，它的核心设计理念是让 AI 像人一样通过"看屏幕"来理解和操作界面，不依赖任何 API 或协议层面的辅助，因此可以覆盖桌面应用、Web 应用、专业软件等各种类型的 GUI 界面。
端侧部署和云端部署的工程取舍
GUI Agent 的运行位置是另一个关键技术决策。
云端部署的优势很明显：算力不受限，可以跑更大的模型，推理精度更高。但它的问题也同样突出------Agent 在执行任务时需要把屏幕截图持续发送到云端服务器，这意味着用户在屏幕上看到的一切（包括敏感数据、内部系统界面、个人信息）都在网络上传输了。对于金融、医疗、政务等对数据安全要求高的行业，这基本是不可接受的。
端侧部署走的是相反的路：模型跑在用户自己的设备上，截图和操作数据完全不离开本机。好处是数据安全性达到了物理隔离的级别，延迟也更低（不需要网络往返）。挑战在于端侧设备的算力有限，需要把模型压缩到能在消费级硬件上流畅运行的尺寸，同时保持足够的操作精度。
Mano-P 在这个问题上的做法是用 4B 参数量的量化模型配合 Cider 推理加速 SDK，在 Apple M4 芯片 + 32GB RAM 的 Mac 上实现全本地运行。在 100 个真实 macOS GUI 任务的测试中，4B 本地模型（Mano-CUA-Thinking-4B）达到了 56% 的任务通过率，超过了云端通用视觉模型 Qwen3-VL-Plus 的 39%；配合 Bash 工具链的 Mano-CUA 1.1+Bash 配置更是达到了 90% 的通过率。这个数据说明端侧部署在合理的工程设计下，是可以达到实用级别的。
评测体系：怎么衡量一个 GUI Agent 的真实能力
GUI Agent 的评测和传统 NLP/CV 模型有本质区别------它不是在一个静态数据集上算准确率，而是需要在真实的操作系统环境中端到端地完成任务。
目前比较有代表性的评测基准是 OSWorld，它定义了一系列需要在真实操作系统中完成的任务，涵盖文件管理、Web 浏览、办公文档编辑等场景，通过检查任务完成后的系统状态来判定是否成功。Mano-P 的 72B 模型在 OSWorld 专项模型评测中达到了 58.2% 的成功率，排名第一，领先第二名 opencua-72b（45.0%）13.2 个百分点。
另一个值得关注的基准是 WebRetriever Protocol I，侧重评测 Agent 在 Web 导航场景下的能力。Mano-P 在这个基准上拿到了 41.7 的 NavEval 分数，超过了 Gemini 2.5 Pro Computer Use（40.9）和 Claude 4.5 Computer Use（31.3）。
这些评测数据的意义不在于"谁比谁高几个点"，而在于它们为 GUI Agent 这个新兴领域建立起了可量化、可复现的能力衡量标准。随着基准测试的完善和更多团队的参与，整个领域的技术迭代会变得更有方向感。
落地场景和实际价值
从实用角度看，AI 操作桌面应用最直接的价值集中在几个方向。
重复性高的跨系统数据搬运是典型场景。很多企业的数据散落在多个内部系统里，没有统一的 API 接口，员工每天需要在不同系统之间手动复制粘贴。GUI Agent 可以像人一样在各个系统界面上操作，完成数据的提取、整合和录入，而且不需要等 IT 部门开发集成方案。
长链路的业务流程自动化也适合。一个涉及十几个步骤、跨越多个应用的业务流程（比如从 CRM 系统里提取客户信息、到 ERP 里查询库存、再到邮件系统里生成报价单发给客户），用传统自动化方案需要为每个系统单独开发适配，GUI Agent 则可以用统一的视觉理解能力覆盖所有界面。
软件测试也是一个天然契合的场景。Mano-P 生态里的 Mano-AFK 组件就实现了从 PRD 到代码、部署、E2E 测试的全自动流程，其中 E2E 测试环节就是由 GUI Agent 在真实界面上执行操作来验证功能是否正确。
技术栈的成熟度决定了 Vibe Operating 目前还处于早期阶段，但从趋势上看，AI 操作桌面应用正在从实验性的 demo 走向可落地的工程系统。端侧推理能力的提升、视觉理解模型的进步、以及评测基准的完善，都在推动这个方向往前走。
如果你对端侧 GUI Agent 的技术细节感兴趣，Mano-P 的完整代码和 4B 模型权重已在 GitHub 开源（https://github.com/Mininglamp-AI/Mano-P），欢迎⭐、Issue、PR~