LUMOS：面向无障碍 AI 智能体的语义操作系统层 LUMOS: A Semantic Operating-System Layer for Accessibility-Grounded AI Agents
将操作系统可访问性 API 转换为机器可读语义蓝图，实现高效的 AI 代理-操作系统交互
前置知识
UI Automation (UIA)
Microsoft 提供的可访问性框架，将桌面 UI 元素表示为树形结构，每个元素暴露名称、角色、控制类型、值、边界矩形和支持的交互模式等属性。UIA 为辅助技术和测试脚本提供程序化访问，使自动化客户端能够检查和操作界面元素
LUMOS 的核心思想就是重用 UIA 等可访问性基础设施作为 AI 代理的语义接口层，理解 UIA 树结构和元素属性是理解 LUMOS 如何提取语义蓝图的基础
Observe-Plan-Act 循环
强化学习和智能体系统中的经典决策模式，代理首先观察环境状态（Observe），然后制定行动计划（Plan），最后执行动作（Act），如此循环往复。在 LUMOS 中，观察是从 UIA/DOM 提取语义蓝图，计划是 LLM 根据蓝图选择单个 JSON 动作，执行是通过可见 UI 原语执行该动作
这是 LUMOS 的核心交互范式，与传统的脚本自动化不同，LUMOS 强调每次行动后重新观察而非假设成功，这种设计使系统能够适应动态变化的环境
Semantic Grounding
将抽象的语言指令或概念映射到具体的、可执行的操作或现实世界中的实体。在 LUMOS 中，语义定位指的是将 LLM 生成的抽象动作（如 'click A2'）映射到具体的 UI 元素和坐标，通过稳定标识符（如 A2、W3）而不是临时坐标来建立这种映射
这是 LUMOS 与基于截图的视觉代理的关键区别，通过语义定位避免了从像素推断 UI 语义的昂贵和不稳定过程
ElementFromPoint 查询
Windows UI Automation 提供的一种 API，给定屏幕坐标 $(x, y)$，返回该坐标下方的 UI 元素及其语义属性。LUMOS 使用这种机制实现实时语义指针定位，将物理输入坐标映射到机器可读的接口语义
这是 LUMOS 实现实时指针定位的核心技术，使代理能够像人类一样通过光标位置来定位目标元素，但通过语义查询而非视觉裁剪
研究动机
当前操作系统为人类用户优化的界面（像素、图标、窗口、视觉分组、鼠标移动、键盘快捷键）并不适合 AI 代理。AI 代理需要紧凑的语义状态、有根据的行动和可靠的反馈，但现有的计算机使用代理（如 Operator、Claude computer use、UI-TARS）被迫解释截图、OCR 输出和视觉裁剪，这引入了高 token 成本、视觉模糊性、延迟和坐标不确定性。例如，当光标在按钮上时，操作系统和应用框架已经知道元素边界、可访问名称、角色、状态和支持的交互模式，但代理必须通过视觉模型从像素重新推断这些信息。现有基准测试显示，开放性计算机任务对最先进的代理仍然困难，尤其是当任务跨越桌面应用、操作系统状态和长时程工作流时
本文的目标是本文的目标是提出 LUMOS（Language-Model Unified Machine-Readable Operating-System Semantics），一个语义交互层，将原生可访问性元数据和浏览器 UI 结构转换为机器可读的语义蓝图，包含稳定标识符、角色、名称、值、边界和行动能力。系统支持通过操作系统自动化 API 查询光标下方或附近的 UI 元素实现实时语义指针定位。LLM 通过受约束的可见 UI 原语而非应用特定脚本进行可访问性驱动的观察-行动循环。LUMOS 并不声称要取代视觉代理，而是在操作系统已经提供语义结构时减少对截图的依赖，从而为 AI 原生操作系统和机器可读交互层提供路径
与已有工作不同的是，本文的独特切入角度是将可访问性基础设施重新定位为 AI 代理的认知层，而不是为辅助技术开发的设计。现有的计算机使用代理主要依赖视觉方法（截图 + OCR + 视觉语言模型），但操作系统已经通过 UIA、DOM 和可访问性树暴露了机器可读的界面描述。LUMOS 没有试图替代操作系统内核或绕过可见接口，而是在以人为本的软件上添加机器面向的交互平面。系统观察当前原生或 Web UI，提取紧凑蓝图，分配稳定的元素标识符，询问 LLM 单个有效动作，通过可见 UI 机制执行该动作，然后再次观察。这种定位与传统的机器人流程自动化（RPA）不同，RPA 通常依赖预设计的工作流或脆弱的 UI 脚本，而 LUMOS 针对的是 LLM 可以动态使用的语义观察和可见行动原语
核心方法
LUMOS 采用分层观察-计划-执行系统架构，默认模式下运行时观察语义 UI 状态，暴露通用可见行动原语，并要求 LLM 选择下一步而非调度预写工作流。感知层读取当前系统状态和活动界面，对于原生 Windows 应用查询前景窗口和 UIA 树，对于网页查询浏览器会话并提取 DOM/可访问性信息，结果被归一化为包含元素标识符、角色或控制类型、可访问名称和当前值、边界矩形或屏幕坐标、窗口标题和 URL、焦点上下文以及可选语义提示的蓝图。规划器是一个 LLM，使用用户目标、最近记忆和当前蓝图作为提示，必须从受约束的模式发出单个 JSON 动作，这种单步纪律避免了幻觉的长脚本并强制代理在每个动作后重新观察，就像人类点击或输入后检查屏幕一样。执行器通过可见 UI 机制执行动作，然后系统进入下一次观察
核心创新在于将操作系统可访问性基础设施（Windows UI Automation、浏览器 DOM 和可访问性树）直接重用为 AI 代理的语义接口层，而不是让代理从像素重新推断 UI 语义。这实现了从视觉/坐标基定位到直接语义查询的转变：传统方法需要截图裁剪 → OCR/视觉 → 猜测目标标签 + 坐标，而 LUMOS 路径只需要指针坐标 → 元素 UIA 命中测试 → 语义 ID、角色、名称、值 → 有根据的 ElementFromPoint 风格语义查询。另一个关键创新是显式的完成动作，使代理能够声明可见状态满足用户目标，而不是无休止地修改、重输或追加内容。系统还区分字面文本输入目标和生成文本目标，对于生成文本目标，模型必须自己生成内容，同时 LUMOS 跟踪内容是否已输入
方法步骤详情
LUMOS 方法步骤完整描述如下：（1）感知：系统读取当前系统状态，对于原生 Windows 应用通过 UIA 查询前景窗口和元素树，对于网页通过浏览器自动化提取 DOM/可访问性信息，输出包含元素 ID、角色、名称、值、边界、上下文的语义蓝图；（2）记忆：系统跟踪最近的行动、失败和已输入文本，记录生成的文本何时输入到目标，可以引导模型完成或使用 set_text 进行修正，还稳定 Windows Search 交接：当模型打开 Search 时有挂起查询如 'outlook'，LUMOS 确保下一步在 Search 覆盖层中输入该查询而非意外地将电子邮件内容输入到陈旧的网页字段；（3）规划：LLM 根据用户目标、最近记忆和当前蓝图发出单个 JSON 动作，从受约束的模式中选择如 observe、click、type_text、set_text、press_key、finish 等原语；（4）验证：系统通过模式和安全检查验证动作，例如通过允许列表和确认策略处理发送电子邮件、删除数据或使用破坏性热键等潜在风险操作；（5）执行：系统通过可见 UI 机制执行验证后的动作；（6）重新观察：系统在动作后重新观察而非假设成功，进入下一次循环
技术新颖性
LUMOS 的技术新颖性体现在多个方面。首先，它提出了双接口平面的概念：人类接口平面（窗口、按钮、像素、颜色、布局、鼠标移动、键盘输入、触摸和语音）和代理接口平面（语义、可访问性树、结构化状态、元素角色、值、行动能力、安全策略和机器可读完成反馈）。LUMOS 是第二个平面的早期原型，不要求应用为 AI 代理重写，而是重用操作系统和浏览器已经暴露的语义元数据。其次，它实现了实时语义指针定位，通过 ElementFromPoint 风格查询将物理输入坐标映射到机器可读的接口语义，使光标本身成为语义交互平面的一部分。第三，它提出了通用行动模式，包括 observe、open_windows_search、open_app、click、double_click、drag、type_text、set_text、press_key、finish 等应用中性原语，目标如 '起草电子邮件' 被表示为观察控件上的可见 UI 动作，而非后端邮件 API 调用。最后，它实现了三规则设计：LLM 决定任务策略，运行时仅暴露通用感知和行动原语，系统在动作后重新观察而非假设成功
实验结果
本文通过案例研究和回归测试验证了 LUMOS 架构的有效性，但未提供完整的基准测试结果。在记事本案例研究中，早期运行显示字面指令复制、追加式修正、重复片段和长散文的字符级输入问题。LUMOS 将这些问题诊断为语义桥接失败：拒绝非内容、用替换而非追加、要求显式完成、通过稳定的文本输入路径粘贴长或多行内容。诊断日志显示了失败信号（蓝色）和桥接修复（绿色）的计数，包括字面复制、追加风险、重复块、finish 修复等。在 Windows Search 交接案例中，系统展示了如何处理通过 Search 打开 Outlook 查询的工作流，当模型发出 {"action":"open_windows_search","text":"outlook"} 时，运行时打开 Search 并保留挂起查询，如果下一次观察仍显示 Search，系统确保在进入下一步之前输入并提交查询 'outlook'。这保留了 LLM 意图同时防止陈旧的网页上下文劫持下一个动作。当前原型通过行动模式强制、生成文本处理、文本替换、Windows Search 交接、安全检查和蓝图刷新行为的回归测试验证
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Vision vs Semantic grounding | Success, latency, tokens | Blueprint+LLM pipeline | Screenshot+OCR+LLM | 待测量（论文提出实验计划但未提供结果） |
| Blueprint compression | Observation size, token count | Semantic blueprint | Screenshot/OCR text/vision-generated screen description | 待测量（论文提出实验计划但未提供结果） |
| Semantic pointer latency | Identification latency, accuracy | UIA ElementFromPoint query | Cursor crop vs UIA | 待测量（论文提出实验计划但未提供结果） |
| Multi-step desktop tasks | Completion, steps, recovery | Notepad, Settings, browser, File Explorer | 待定义 | 待测量（论文提出实验计划但未提供结果） |
局限与改进
LUMOS 存在多个局限性。首先，它依赖于暴露的 UI 语义质量，一些应用提供不完整的可访问性树、模糊名称、重复控件或自定义渲染表面。动态界面可能在观察和动作之间变化。LLMs 可能仍选择不正确的动作、误解任务完成或需要多次恢复轮次。其次，原型不声称人类水平的自主性，打开记事本和输入文本只是交互模型的小演示，并非证明所有桌面工作流已解决。第三，当前实现对简单文本输入和启动任务最强，可以打开 Windows Search、执行挂起查询（如应用名称）、提交并重新观察结果 UI，但其余工作流仍受下一个蓝图质量和 LLM 选择正确可见动作能力的限制。第四，系统级操作仍然受限：直接后端音量和亮度 API 被有意移除，LUMOS 必须打开可见设置 UI，然后识别和操作暴露的滑块或控件，对风险调整动作需要确认。最后，安全性仍然是中心关注点：AI 控制的 UI 层必须防止非预期提交、删除、凭据暴露或权限升级。视频编辑器、邮件客户端和自定义渲染专业工具等复杂应用尚未被演示为端到端解决
独立分析的弱点
LUMOS 的主要弱点包括：（1）语义质量依赖：系统完全依赖应用暴露的可访问性元数据质量，对于提供不完整或模糊语义的应用，LUMOS 无法有效工作，改进方向是实现更强的语义恢复机制和降级策略；（2）动态界面处理：动态界面可能在观察和动作之间变化，导致行动定位失效，改进方向是实现更鲁棒的状态验证和变化检测机制；（3）复杂应用支持不足：当前实现仅演示了简单的文本输入和启动任务，对于视频编辑器、邮件客户端等专业工具的支持有限，改进方向是扩展对复杂控件模式（如滑块、画布、时间轴）的支持；（4）系统级操作受限：直接后端 API 被有意移除，必须通过可见 UI 操作系统设置，这增加了复杂性和延迟，改进方向是在可见性和效率之间找到更好的平衡，可能通过部分暴露安全系统操作；（5）安全性设计保守：允许列表和确认策略可能限制有用性，改进方向是实现更细粒度的安全策略和风险评估机制；（6）缺乏大规模评估：论文仅提供案例研究和回归测试，缺乏与视觉代理的系统性比较，改进方向是在 WebArena、OSWorld、Mind2Web 等基准上进行全面评估
未来方向
未来研究方向包括：（1）更丰富的可访问性恢复：开发从模糊或不完整的可访问性树推断语义的技术，结合视觉方法作为回退；（2）更好的状态验证：实现更鲁棒的机制来验证动作效果，特别是对于不可见的系统状态变化；（3）更强的滑块/控件操作：扩展对复杂控件模式的支持，如滑块、画布、时间轴、菜单等；（4）更广泛的多应用工作流评估：在包括记事本、设置、浏览器搜索、文件资源管理器和邮件客户端的跨应用工作流上进行评估；（5）AI 原生操作系统设计：未来操作系统可能直接暴露更丰富的语义状态，包括应用意图、可用命令、可逆操作、安全边界、用户批准要求和任务进度，而不是要求 AI 从像素推断一切；（6）双平面操作系统设计：操作系统可能暴露两个协调的平面（人类接口平面和代理接口平面），使相同接口能够支持人类感知和机器认知。作者还提出了四个实验家族：视觉 vs 语义定位、蓝图压缩、语义指针延迟和多步骤桌面任务
复现评估
LUMOS 仓库已在 GitHub 开源（https://github.com/thotayogeswarreddy/Lumos.git），原型在 Windows 上用 Python 实现，用于原生桌面 UI 控制，支持浏览器进行网页表面交互。原生观察使用通过 Python 自动化库的 Windows UI Automation，网页观察使用浏览器自动化提取页面结构。模型客户端支持本地或兼容的 LLM 后端。运行时为网页任务维护持久浏览器会话，为桌面窗口维护原生蓝图，以及用于行动定位的共享 ID 映射。仓库还包括可选的确定性脚手架，由 LUMOS_FAST_PATHS=1 控制，包括预启动、后启动、后输入、finish-after-text 和 search-overlay 辅助函数，默认禁用，这些函数被记录为消融旋钮而非隐藏的任务绕过。论文和代码明确区分了默认 observe-LLM-act 模式和快速路径模式。复现难度中等，需要 Windows 环境、Python 环境、浏览器自动化库和 LLM 后端。论文提供了详细的方法描述和案例研究，但缺乏完整的基准测试结果和超参数细节
论文图表
该图展示了 LUMOS 的概念动机，描述了如何将面向人类的可视化接口平面转换为机器可读的代理接口平面，而无需重新设计应用。图中显示人类 UI 平面包括像素、窗口、控件、鼠标和键盘，通过提取语义和 UIA/DOM 元数据，转换为 LUMOS 语义层，再通过验证的可见行动，最终输出稳定的元素 ID、角色、名称、值、边界和行动等代理接口平面的内容
这张图对理解论文至关重要，它清晰地展示了 LUMOS 的核心思想：不重新设计应用，而是在现有人类面向的软件上添加机器面向的交互平面。这是理解 LUMOS 与传统方法区别的关键
该表定位了 LUMOS 相对于视觉驱动的计算机使用代理的位置。比较了四类系统：视觉驱动的代理（Operator、Claude computer use、UI-TARS）、屏幕解析器（OmniParser、ScreenAI）、代理编排（AutoGen、Agent-S）和语义驱动的代理（LUMOS）。比较维度包括交互方式（截图/浏览器或桌面控制）、语义访问（从像素推断 vs 原生角色、值、边界、状态）、OCR（通常有用或隐含 vs 否，当语义 API 可用时）、像素（高 vs 默认低）和光标定位（通常视觉/坐标基 vs 直接 ElementFromPoint 风格语义查询）
这个表格对理解 LUMOS 在研究 landscape 中的位置至关重要，它清晰地对比了 LUMOS 与现有方法在多个维度上的差异
该表比较了 AI 计算机交互的四种交互策略。截图/VLM 代理的优势是一般视觉覆盖，弱点是 token 重的坐标不确定性，LUMOS 定位是仅在语义状态不可用时使用。RPA 脚本的优势是可靠固定工作流，弱点是脆弱和任务特定，LUMOS 定位是避免脚本化任务逻辑。直接 API 的优势是高效和精确，弱点是并不总是可用且绕过可见 UI，LUMOS 定位是优先可见用户等效行动。语义蓝图的优势是紧凑和有根据，弱点是依赖于可访问性质量，LUMOS 定位是主要交互基底
这个表格系统地比较了不同交互策略的优劣，帮助理解 LUMOS 的设计选择和定位策略
该表提出了评估任务和指标。包括四个实验：视觉 vs 语义定位（任务：跨应用桌面任务，指标：成功、延迟、tokens，比较：Screenshot+OCR+LLM vs Blueprint+LLM，改进：待测量）、蓝图压缩（任务：观察大小、token 计数，比较：截图/OCR 文本/视觉生成的屏幕描述 vs 语义蓝图，改进：待测量）、语义指针延迟（任务：标识延迟、准确性，比较：光标裁剪 vs UIA ElementFromPoint 查询，改进：待测量）、多步骤桌面任务（任务：完成、步骤、恢复，环境：记事本、设置、浏览器、文件资源管理器，改进：待测量）
这个表格概述了论文提出的评估计划，帮助理解如何系统地验证 LUMOS 的优势，虽然实际结果未提供