尧图网页设计 
1. 项目缘起当自动化任务撞上用户隐私的“墙”最近在折腾一些桌面自动化脚本想实现类似“崩铁每日任务自动化”那种效果用程序自动点点按钮、填填表单。这听起来是个很酷的想法对吧用Python写个脚本调用pyautogui或者更高级的Playwright、Selenium来控制浏览器或桌面应用理论上就能解放双手。但当我真正开始动手时立刻撞上了一堵无形的“墙”——用户敏感界面。什么叫用户敏感界面简单说就是那些屏幕上显示着你不该看、也不该让程序去“看”的内容。比如你正在开发的这个自动化Agent智能体它的任务是帮用户自动填写某个办公系统的周报。理想情况下它应该只聚焦在周报填报的那个网页表单上。但现实是用户的电脑屏幕上可能同时开着很多窗口私人聊天软件的对话框、网银的余额页面、包含个人健康信息的文档或者仅仅是浏览器地址栏里那个显眼的个人邮箱主页。这就引出了一个核心矛盾一个功能强大的GUI Agent图形用户界面智能体它需要“看见”屏幕才能执行操作但同时它必须对屏幕上的绝大部分内容“视而不见”尤其是那些与当前任务无关且包含用户隐私的部分。传统的屏幕捕捉screenshot加OCR光学字符识别或基于坐标的点击是一种“盲操作”。它不管屏幕上是什么只要找到了预设的按钮位置或文本特征就执行动作。这种方式在受控的测试环境里或许可行一旦放到真实的、复杂的用户桌面环境中风险极高。你的Agent可能会误读敏感信息甚至更糟将这些信息作为上下文的一部分发送给后台的大语言模型LLM进行处理造成隐私泄露。因此“Guided Exploration”引导式探索这个概念就显得至关重要。它意味着我们的GUI Agent不能像无头苍蝇一样在用户的屏幕像素里乱撞而必须在一个明确的、安全的边界内进行感知和操作。这个项目要解决的就是如何为GUI Agent构建这样一套“导航系统”和“行为准则”让它既能高效完成任务又能绝对尊重用户的隐私边界。这不仅仅是技术问题更是一个涉及产品设计、用户体验和伦理信任的核心问题。2. 核心架构为GUI Agent装上“隐私感知”的眼睛要实现引导式探索我们不能让Agent直接面对原始的、充满噪声的屏幕像素流。我们需要一个分层的处理架构在原始屏幕输入和Agent的决策模块之间建立多道“过滤网”和“导航信标”。2.1 从“像素驱动”到“语义驱动”的范式转变传统的自动化脚本是“像素驱动”或“坐标驱动”的click(1250, 430)。这种方式极其脆弱屏幕分辨率一变、窗口位置一挪、UI主题一换脚本就失效了。更重要的是它毫无语义可言根本不知道自己在点什么。现代基于AI的GUI Agent尤其是结合了LLM和计算机视觉CV的智能体目标是实现“语义驱动”。它需要理解“我现在要找到一个‘提交’按钮”或者“我需要在这个标有‘用户名’的输入框里填入信息”。要实现这一点我们需要对屏幕内容进行结构化理解。第一步也是基础的一步是屏幕的语义分割与元素识别。这不仅仅是OCR识别文字而是要将整个UI界面解析成一个结构化的树类似于HTML DOM。每个节点代表一个UI元素按钮、输入框、标签、列表等并包含其属性类型、文本内容、位置、可能的状态如是否禁用、是否被选中。目前有一些开源工具和模型正在朝这个方向努力例如微软的ScreenAI或一些基于LayoutLM改进的模型它们试图从截图或UI描述文件中重建出UI元素树。有了这颗“语义树”Agent的世界就从混沌的像素变成了有组织的对象集合。这是引导探索的数据基础。2.2 定义“任务上下文”与安全边界仅仅有语义树还不够。我们需要告诉Agent“你本次的任务上下文Task Context是什么”以及“你的安全操作边界Safe Boundary在哪里”任务上下文是一个明确的、由用户或系统发起的指令描述。例如“请帮我登录公司OA系统并进入‘请假申请’页面。” 这个上下文限定了Agent应该关注哪些应用、哪些窗口、以及大致的工作流程。安全边界则是根据任务上下文动态划定的“可操作区域”。这是引导探索的核心机制。我们可以通过多种技术组合来定义这个边界进程与窗口聚焦通过操作系统API将Agent的“视线”严格锁定在与任务相关的特定应用程序窗口上。例如只允许捕捉名为“企业OA - Chrome”的窗口内容忽略其他所有窗口。这解决了跨应用隐私泄露的问题。界面元素白名单在锁定的窗口内部进一步通过语义树只将与当前任务步骤相关的UI元素暴露给Agent。例如在登录步骤只暴露“用户名输入框”、“密码输入框”、“登录按钮”以及必要的提示文本如“忘记密码”链接应被过滤。其他如浏览器书签栏、扩展图标、无关的广告横幅等都应从Agent可感知的元素列表中移除。动态模糊与掩码对于无法完全过滤、但又可能包含敏感信息的区域例如浏览器地址栏可能显示历史记录任务栏可能弹出消息预览可以采用实时视觉处理技术在将画面提供给Agent分析前对这些区域进行高斯模糊或像素化处理。这确保了即使有信息残留也无法被OCR或视觉模型有效识别。这个“安全边界”就像一个不断变化的聚光灯只照亮当前任务所需的那一小块屏幕区域其余部分均置于黑暗或模糊之中。Agent的探索行为被严格限制在这个聚光灯范围内。2.3. LLM作为“任务规划器”与“意图理解器”在这个架构中大语言模型LLM扮演着“大脑”的角色但它不直接处理屏幕像素。它的输入是经过安全边界过滤后的、结构化的UI语义描述例如“当前界面包含以下元素一个文本为‘用户名’的标签一个空的输入框一个文本为‘密码’的标签一个类型为‘password’的输入框一个文本为‘登录’的按钮。”。LLM的核心职责是任务分解将用户的高层指令“申请请假”分解成一系列原子操作步骤“1. 找到并点击‘人力资源’菜单2. 找到并点击‘请假申请’子项3. 在‘开始日期’输入框点击并选择日期...”。意图到动作的映射根据当前步骤和感知到的UI状态决定下一个具体动作。例如理解到当前步骤是“填写用户名”感知到有“用户名输入框”则生成动作{“action”: “type”, “target_element_id”: “username_input”, “value”: “zhangsan”}。状态验证与异常处理判断上一步操作是否成功例如点击后是否出现了预期的下一个界面如果失败或出现意外弹窗如“验证码错误”能重新规划或触发纠错流程。关键在于LLM所接收和处理的“上下文”始终是经过清洗和脱敏的。它永远不会接触到“张三的银行卡号是6225...”这样的原始敏感文本它接触到的可能是“一个包含16位数字的输入框”这样的抽象描述或者干脆这个输入框在提供给LLM的语义树中就被标记为[SENSITIVE_FIELD]而被跳过由本地加密模块直接处理。3. 关键技术实现与选型考量搭建这样一个系统需要一系列技术组件的选型和整合。这里没有银弹需要根据具体场景权衡。3.1 UI元素识别CV模型 vs. 可访问性接口获取屏幕语义树主要有两条技术路径计算机视觉CV模型路径对屏幕截图进行端到端的元素检测与识别。优点是通用性强理论上能处理任何显示在屏幕上的内容包括那些无法通过编程接口访问的古老桌面应用或自定义绘制的UI。缺点是对计算资源要求高识别精度和速度受模型性能影响且需要大量标注数据训练。对于需要高实时性的交互这可能成为瓶颈。实操心得对于现代主流应用如Web应用、Electron应用、Qt/WPF应用纯CV方案有点像“用大炮打蚊子”。更高效的混合方案是优先使用可访问性接口对无法通过接口获取的“顽固”区域或非常规应用再启用CV模型进行补足识别。可访问性Accessibility接口路径操作系统如Windows的UI Automation macOS的Accessibility API Linux的AT-SPI和浏览器如Chrome DevTools Protocol提供了丰富的编程接口可以直接获取UI元素的层级结构、类型、名称、状态等信息。这相当于直接从应用内部“读取”UI树精度近乎100%速度极快且不依赖视觉。这是实现引导探索的推荐首选方案。因为它天然地、精确地提供了我们需要的结构化语义信息。许多自动化框架如Playwright、Selenium、pywinauto底层都依赖这些接口。选型建议优先探索和利用目标应用的可访问性接口。对于需要支持的平台和应用列表先调研其可访问性支持情况。将CV模型作为降级方案或对特定复杂控件如游戏内UI、自定义图表的增强识别手段。3.2 Agent框架与LLM集成你需要一个框架来编排感知、决策、执行这个循环。你可以从头构建但更高效的是基于现有Agent框架。通用AI Agent框架如LangChain、LlamaIndex、AutoGen。它们提供了与LLM交互、管理记忆、工具使用Tools的成熟范式。你可以将“分析当前UI”、“执行点击操作”等封装成Tool让LLM来调用。这类框架灵活生态丰富适合研究或构建复杂逻辑的Agent。垂直的GUI自动化Agent框架/项目社区已经出现了一些专门针对GUI自动化的项目它们集成了UI识别、LLM驱动等模块。例如一些开源项目尝试将Playwright等自动化库与LangChain结合。你需要评估这些项目是否已经考虑了隐私过滤的架构或者其架构是否易于嵌入我们上述的“安全边界”机制。轻量级自研如果任务场景非常固定你也可以不用重型框架。核心就是一个循环1. 通过安全接口获取当前UI状态描述2. 将状态描述和任务历史发送给LLM API如OpenAI GPT Claude 或本地部署的Llama模型3. 解析LLM返回的JSON格式动作指令4. 通过自动化库执行动作5. 等待状态变化回到步骤1。关于LLM选型如果涉及的数据可能敏感务必慎重考虑云API。即使你发送的是脱敏后的UI描述从隐私合规角度任何用户数据离开本地环境都需要评估。因此在本地部署一个能力足够的开源模型如Qwen2.5-7B-Instruct、Llama-3.2-3B-Instruct往往是更稳妥的选择。这些模型经过精调Fine-tuning后在理解UI指令和规划简单任务链方面表现已经相当不错。3.3 “引导”的具体实现策略与启发式规则“引导”不仅体现在数据输入层面也体现在Agent的行为逻辑层面。基于状态的探索策略Agent不应该盲目尝试所有可能的操作。它应该有一个基于有限状态机FSM或行为树Behavior Tree的导航逻辑。例如在“登录”状态它只寻找与登录相关的元素一旦检测到登录成功如URL变化或出现特定欢迎语就切换到“主导航”状态。这大大缩小了探索空间。元素操作优先级在同一个界面可能有多个可操作元素。应定义优先级规则例如有明确标识的按钮如‘下一步’ 输入框 模糊的图标按钮。这可以减少无效尝试。安全超时与中断必须为每个操作步骤设置超时。如果Agent在某个状态停留过久或尝试了过多无效操作应自动暂停并上报“需要人工干预”而不是无限循环。同时必须设计一个用户随时可以中断Agent操作的机制如全局热键这是建立用户信任的基石。4. 实战中的挑战与避坑指南理论很美好但实际开发中会遇到一堆“坑”。以下是我在类似项目中踩过的一些雷区。4.1 动态内容与延迟加载的陷阱现代Web应用大量使用异步加载和动态渲染。你让Agent点击一个按钮脚本立刻去查找结果DOM树里还没有这个按钮导致失败。解决方法是引入稳健的等待策略。不要用固定的sleep(2)而是使用显式等待Explicit Wait。以Playwright为例应该这样写# 错误示范盲目等待 page.click(“button#submit”) time.sleep(5) # 魔法数字不可靠 # 正确示范等待元素达到可操作状态 page.wait_for_selector(“button#submit:not([disabled])”, state“visible”, timeout10000) page.click(“button#submit”)在引导探索架构中你的“状态感知”模块在向LLM报告UI状态前必须确保它等待到了稳定的、任务相关的关键元素出现。这需要将显式等待的逻辑嵌入到UI信息获取环节中。4.2 “同形异义”与“异形同义”的元素识别这是UI自动化永恒的痛苦。一个经典的“坑”是页面上有多个“确定”按钮你要点的是第二个但Agent总是点到第一个。纯文本匹配在这里会失败。解决方案是使用复合选择器。不要只依赖text‘确定’要结合其位置、附近的兄弟元素、父容器的属性等来精确定位。在语义树中这意味着我们需要提取更丰富的上下文特征。例如“位于‘请假类型’下拉框右侧的‘确定’按钮”“class属性包含primary且> GUI Agent引导式探索：在自动化任务中守护用户隐私的架构设计
1. 项目缘起当自动化任务撞上用户隐私的“墙”最近在折腾一些桌面自动化脚本想实现类似“崩铁每日任务自动化”那种效果用程序自动点点按钮、填填表单。这听起来是个很酷的想法对吧用Python写个脚本调用pyautogui或者更高级的Playwright、Selenium来控制浏览器或桌面应用理论上就能解放双手。但当我真正开始动手时立刻撞上了一堵无形的“墙”——用户敏感界面。什么叫用户敏感界面简单说就是那些屏幕上显示着你不该看、也不该让程序去“看”的内容。比如你正在开发的这个自动化Agent智能体它的任务是帮用户自动填写某个办公系统的周报。理想情况下它应该只聚焦在周报填报的那个网页表单上。但现实是用户的电脑屏幕上可能同时开着很多窗口私人聊天软件的对话框、网银的余额页面、包含个人健康信息的文档或者仅仅是浏览器地址栏里那个显眼的个人邮箱主页。这就引出了一个核心矛盾一个功能强大的GUI Agent图形用户界面智能体它需要“看见”屏幕才能执行操作但同时它必须对屏幕上的绝大部分内容“视而不见”尤其是那些与当前任务无关且包含用户隐私的部分。传统的屏幕捕捉screenshot加OCR光学字符识别或基于坐标的点击是一种“盲操作”。它不管屏幕上是什么只要找到了预设的按钮位置或文本特征就执行动作。这种方式在受控的测试环境里或许可行一旦放到真实的、复杂的用户桌面环境中风险极高。你的Agent可能会误读敏感信息甚至更糟将这些信息作为上下文的一部分发送给后台的大语言模型LLM进行处理造成隐私泄露。因此“Guided Exploration”引导式探索这个概念就显得至关重要。它意味着我们的GUI Agent不能像无头苍蝇一样在用户的屏幕像素里乱撞而必须在一个明确的、安全的边界内进行感知和操作。这个项目要解决的就是如何为GUI Agent构建这样一套“导航系统”和“行为准则”让它既能高效完成任务又能绝对尊重用户的隐私边界。这不仅仅是技术问题更是一个涉及产品设计、用户体验和伦理信任的核心问题。2. 核心架构为GUI Agent装上“隐私感知”的眼睛要实现引导式探索我们不能让Agent直接面对原始的、充满噪声的屏幕像素流。我们需要一个分层的处理架构在原始屏幕输入和Agent的决策模块之间建立多道“过滤网”和“导航信标”。2.1 从“像素驱动”到“语义驱动”的范式转变传统的自动化脚本是“像素驱动”或“坐标驱动”的click(1250, 430)。这种方式极其脆弱屏幕分辨率一变、窗口位置一挪、UI主题一换脚本就失效了。更重要的是它毫无语义可言根本不知道自己在点什么。现代基于AI的GUI Agent尤其是结合了LLM和计算机视觉CV的智能体目标是实现“语义驱动”。它需要理解“我现在要找到一个‘提交’按钮”或者“我需要在这个标有‘用户名’的输入框里填入信息”。要实现这一点我们需要对屏幕内容进行结构化理解。第一步也是基础的一步是屏幕的语义分割与元素识别。这不仅仅是OCR识别文字而是要将整个UI界面解析成一个结构化的树类似于HTML DOM。每个节点代表一个UI元素按钮、输入框、标签、列表等并包含其属性类型、文本内容、位置、可能的状态如是否禁用、是否被选中。目前有一些开源工具和模型正在朝这个方向努力例如微软的ScreenAI或一些基于LayoutLM改进的模型它们试图从截图或UI描述文件中重建出UI元素树。有了这颗“语义树”Agent的世界就从混沌的像素变成了有组织的对象集合。这是引导探索的数据基础。2.2 定义“任务上下文”与安全边界仅仅有语义树还不够。我们需要告诉Agent“你本次的任务上下文Task Context是什么”以及“你的安全操作边界Safe Boundary在哪里”任务上下文是一个明确的、由用户或系统发起的指令描述。例如“请帮我登录公司OA系统并进入‘请假申请’页面。” 这个上下文限定了Agent应该关注哪些应用、哪些窗口、以及大致的工作流程。安全边界则是根据任务上下文动态划定的“可操作区域”。这是引导探索的核心机制。我们可以通过多种技术组合来定义这个边界进程与窗口聚焦通过操作系统API将Agent的“视线”严格锁定在与任务相关的特定应用程序窗口上。例如只允许捕捉名为“企业OA - Chrome”的窗口内容忽略其他所有窗口。这解决了跨应用隐私泄露的问题。界面元素白名单在锁定的窗口内部进一步通过语义树只将与当前任务步骤相关的UI元素暴露给Agent。例如在登录步骤只暴露“用户名输入框”、“密码输入框”、“登录按钮”以及必要的提示文本如“忘记密码”链接应被过滤。其他如浏览器书签栏、扩展图标、无关的广告横幅等都应从Agent可感知的元素列表中移除。动态模糊与掩码对于无法完全过滤、但又可能包含敏感信息的区域例如浏览器地址栏可能显示历史记录任务栏可能弹出消息预览可以采用实时视觉处理技术在将画面提供给Agent分析前对这些区域进行高斯模糊或像素化处理。这确保了即使有信息残留也无法被OCR或视觉模型有效识别。这个“安全边界”就像一个不断变化的聚光灯只照亮当前任务所需的那一小块屏幕区域其余部分均置于黑暗或模糊之中。Agent的探索行为被严格限制在这个聚光灯范围内。2.3. LLM作为“任务规划器”与“意图理解器”在这个架构中大语言模型LLM扮演着“大脑”的角色但它不直接处理屏幕像素。它的输入是经过安全边界过滤后的、结构化的UI语义描述例如“当前界面包含以下元素一个文本为‘用户名’的标签一个空的输入框一个文本为‘密码’的标签一个类型为‘password’的输入框一个文本为‘登录’的按钮。”。LLM的核心职责是任务分解将用户的高层指令“申请请假”分解成一系列原子操作步骤“1. 找到并点击‘人力资源’菜单2. 找到并点击‘请假申请’子项3. 在‘开始日期’输入框点击并选择日期...”。意图到动作的映射根据当前步骤和感知到的UI状态决定下一个具体动作。例如理解到当前步骤是“填写用户名”感知到有“用户名输入框”则生成动作{“action”: “type”, “target_element_id”: “username_input”, “value”: “zhangsan”}。状态验证与异常处理判断上一步操作是否成功例如点击后是否出现了预期的下一个界面如果失败或出现意外弹窗如“验证码错误”能重新规划或触发纠错流程。关键在于LLM所接收和处理的“上下文”始终是经过清洗和脱敏的。它永远不会接触到“张三的银行卡号是6225...”这样的原始敏感文本它接触到的可能是“一个包含16位数字的输入框”这样的抽象描述或者干脆这个输入框在提供给LLM的语义树中就被标记为[SENSITIVE_FIELD]而被跳过由本地加密模块直接处理。3. 关键技术实现与选型考量搭建这样一个系统需要一系列技术组件的选型和整合。这里没有银弹需要根据具体场景权衡。3.1 UI元素识别CV模型 vs. 可访问性接口获取屏幕语义树主要有两条技术路径计算机视觉CV模型路径对屏幕截图进行端到端的元素检测与识别。优点是通用性强理论上能处理任何显示在屏幕上的内容包括那些无法通过编程接口访问的古老桌面应用或自定义绘制的UI。缺点是对计算资源要求高识别精度和速度受模型性能影响且需要大量标注数据训练。对于需要高实时性的交互这可能成为瓶颈。实操心得对于现代主流应用如Web应用、Electron应用、Qt/WPF应用纯CV方案有点像“用大炮打蚊子”。更高效的混合方案是优先使用可访问性接口对无法通过接口获取的“顽固”区域或非常规应用再启用CV模型进行补足识别。可访问性Accessibility接口路径操作系统如Windows的UI Automation macOS的Accessibility API Linux的AT-SPI和浏览器如Chrome DevTools Protocol提供了丰富的编程接口可以直接获取UI元素的层级结构、类型、名称、状态等信息。这相当于直接从应用内部“读取”UI树精度近乎100%速度极快且不依赖视觉。这是实现引导探索的推荐首选方案。因为它天然地、精确地提供了我们需要的结构化语义信息。许多自动化框架如Playwright、Selenium、pywinauto底层都依赖这些接口。选型建议优先探索和利用目标应用的可访问性接口。对于需要支持的平台和应用列表先调研其可访问性支持情况。将CV模型作为降级方案或对特定复杂控件如游戏内UI、自定义图表的增强识别手段。3.2 Agent框架与LLM集成你需要一个框架来编排感知、决策、执行这个循环。你可以从头构建但更高效的是基于现有Agent框架。通用AI Agent框架如LangChain、LlamaIndex、AutoGen。它们提供了与LLM交互、管理记忆、工具使用Tools的成熟范式。你可以将“分析当前UI”、“执行点击操作”等封装成Tool让LLM来调用。这类框架灵活生态丰富适合研究或构建复杂逻辑的Agent。垂直的GUI自动化Agent框架/项目社区已经出现了一些专门针对GUI自动化的项目它们集成了UI识别、LLM驱动等模块。例如一些开源项目尝试将Playwright等自动化库与LangChain结合。你需要评估这些项目是否已经考虑了隐私过滤的架构或者其架构是否易于嵌入我们上述的“安全边界”机制。轻量级自研如果任务场景非常固定你也可以不用重型框架。核心就是一个循环1. 通过安全接口获取当前UI状态描述2. 将状态描述和任务历史发送给LLM API如OpenAI GPT Claude 或本地部署的Llama模型3. 解析LLM返回的JSON格式动作指令4. 通过自动化库执行动作5. 等待状态变化回到步骤1。关于LLM选型如果涉及的数据可能敏感务必慎重考虑云API。即使你发送的是脱敏后的UI描述从隐私合规角度任何用户数据离开本地环境都需要评估。因此在本地部署一个能力足够的开源模型如Qwen2.5-7B-Instruct、Llama-3.2-3B-Instruct往往是更稳妥的选择。这些模型经过精调Fine-tuning后在理解UI指令和规划简单任务链方面表现已经相当不错。3.3 “引导”的具体实现策略与启发式规则“引导”不仅体现在数据输入层面也体现在Agent的行为逻辑层面。基于状态的探索策略Agent不应该盲目尝试所有可能的操作。它应该有一个基于有限状态机FSM或行为树Behavior Tree的导航逻辑。例如在“登录”状态它只寻找与登录相关的元素一旦检测到登录成功如URL变化或出现特定欢迎语就切换到“主导航”状态。这大大缩小了探索空间。元素操作优先级在同一个界面可能有多个可操作元素。应定义优先级规则例如有明确标识的按钮如‘下一步’ 输入框 模糊的图标按钮。这可以减少无效尝试。安全超时与中断必须为每个操作步骤设置超时。如果Agent在某个状态停留过久或尝试了过多无效操作应自动暂停并上报“需要人工干预”而不是无限循环。同时必须设计一个用户随时可以中断Agent操作的机制如全局热键这是建立用户信任的基石。4. 实战中的挑战与避坑指南理论很美好但实际开发中会遇到一堆“坑”。以下是我在类似项目中踩过的一些雷区。4.1 动态内容与延迟加载的陷阱现代Web应用大量使用异步加载和动态渲染。你让Agent点击一个按钮脚本立刻去查找结果DOM树里还没有这个按钮导致失败。解决方法是引入稳健的等待策略。不要用固定的sleep(2)而是使用显式等待Explicit Wait。以Playwright为例应该这样写# 错误示范盲目等待 page.click(“button#submit”) time.sleep(5) # 魔法数字不可靠 # 正确示范等待元素达到可操作状态 page.wait_for_selector(“button#submit:not([disabled])”, state“visible”, timeout10000) page.click(“button#submit”)在引导探索架构中你的“状态感知”模块在向LLM报告UI状态前必须确保它等待到了稳定的、任务相关的关键元素出现。这需要将显式等待的逻辑嵌入到UI信息获取环节中。4.2 “同形异义”与“异形同义”的元素识别这是UI自动化永恒的痛苦。一个经典的“坑”是页面上有多个“确定”按钮你要点的是第二个但Agent总是点到第一个。纯文本匹配在这里会失败。解决方案是使用复合选择器。不要只依赖text‘确定’要结合其位置、附近的兄弟元素、父容器的属性等来精确定位。在语义树中这意味着我们需要提取更丰富的上下文特征。例如“位于‘请假类型’下拉框右侧的‘确定’按钮”“class属性包含primary且>