做GUI自动化的朋友，这几年应该都有同感：底层的活越来越难干。以前写个脚本，录个坐标，跑个点击，能应付一阵子；现在应用界面动辄几百个控件，布局动态变化，主题深浅切换，分辨率忽高忽低，再碰上要操作的系统压根不开放接口，传统那套脚本录制和固定流程的方法论，基本走到头了。
我一直在琢磨另一条路：如果把工具本身该有的能力，比如识别对话框、填表单、翻下一页、拖文件，像人的技能一样拆开，交给Agent去编排组合，效果会怎样。这就是CUA-Skill框架的由来。CUA，Computer Use Agent，简单说就是让AI直接操作电脑图形界面，像人一样看屏幕、点按钮、打字。而Skill，就是把这种操作能力沉淀成可复用、可组合的基本动作单元。这篇是CUA-Skill框架的完整实战复盘，从设计思路到落地代码，再到我踩过的坑，一次性写清楚。适合做RPA、做自动化测试、研究GUI Agent的开发者参考，也能给准备入行的朋友一个清晰的技术路线。
1. 为什么GUI自动化需要“技能”这件事
1.1 传统GUI自动化的三个死穴
老玩家都知道，传统GUI自动化大致分两派：一是录制回放，记录鼠标键盘操作序列然后回放；二是基于控件树编程，通过UI Automation这类接口拿控件属性然后写死流程。
这两派都有一个共同的底层假设：界面是稳定的。问题是，现在的软件界面从来不按这个假设来。我实测过一个数据录入系统，同一台机器隔一天打开，一个下拉框的位置因为顶部提示条的出现整体下移了40像素，录好的坐标脚本全部失效，基于控件属性的脚本也会因为控件标题从“确认”变成“确定”直接崩溃。这是第一个死穴：界面一变，脚本就要重写。
第二个死穴是跨应用能力。传统方案想打通两个应用，通常靠剪贴板、窗口切换、键盘模拟，脆得像纸糊的。一旦目标窗口失去焦点，或者中间弹出一个系统级弹窗，整条流程就断了。
第三个死穴是维护成本。功能逻辑越复杂，脚本状态就越多，分支、重试、异常处理、超时判断全都要人肉维护。到我实际维护一个中等规模的流程时，光处理环境差异和偶发弹窗的代码就占了总代码量一半还多。
1.2 CUA视角：让Agent像人一样看屏幕、按步骤操作
CUA派的核心思路是完全换一个角度：不再假设界面不变，而是让Agent实时观察界面，理解当前状态，再决定下一步做什么。人是怎么操作软件的？人看到弹窗，知道它提示什么，然后点击“确定”。这个过程中人依赖的是语义理解，而不是某个坐标值。CUA-Skill框架就是把这种语义理解能力正式引入自动化流程。
具体来说，Agent的每一步操作都包含四个环节：感知当前界面状态（截图或读取控件树）、理解状态含义（这是什么窗口、有哪些可操作元素）、决策下一步动作（符合当前技能定义且状态允许）、执行并验证（模拟输入然后确认预期结果出现）。
这套流程听起来不复杂，难点在于：感知和理解环节如果每次都从头做，成本和延迟都太高，Agent就会变得又慢又笨。这就需要把操作过程拆成技能。
1.3 技能化到底解决什么问题
把“点击保存按钮”封装成一个技能，而不是一段写死的脚本，区别在哪？区别在于技能带上了三样东西：前置条件、执行策略、后置校验。
比如“保存当前文档”这个技能，前置条件是“存在一个可编辑文档且修改未保存”，执行策略是“定位保存按钮并点击，如果按钮不可见则尝试快捷键或菜单项”，后置校验是“确认保存成功提示出现，且文档标题栏的未保存标记消失”。
技能的本质是把不确定性封装起来。传统脚本面对界面变化会直接崩掉，技能则是根据界面实时状态动态调整策略，换来的是稳定性和可复用的效率。一个技能可以在不同的应用、不同的流程里反复调用，就像人的能力一样可以迁移。
2. CUA-Skill框架的核心设计
2.1 一个Skill由哪几部分组成
我设计的Skill定义包含五个核心字段：元信息、输入参数、触发条件、执行体、验证规则。下面是一份实际在用的Skill定义示例，用JSON Schema描述，方便框架做校验和检索：
{ "skill_name": "app.save_document", "skill_version": "1.2.0", "description": "保存当前活动文档，支持快捷键、菜单和按钮三种路径", "inputs": [ { "name": "save_strategy", "type": "enum", "values": ["auto", "keyboard", "menu", "button"], "default": "auto" } ], "trigger": { "element": "window.active", "conditions": [ {"if": "content_modified", "then": "proceed"}, {"else": "skip_and_report_success"} ] }, "actions": [ { "step": 1, "method": "perceive", "target": "get_active_window_screenshot", "then": ["detect_save_button", "detect_menu_bar", "detect_modified_flag"] }, { "step": 2, "method": "dispatch", "strategy_from_input": "save_strategy", "fallback_order": ["keyboard", "menu", "button"] }, { "step": 3, "method": "verify", "check": ["save_success_toast", "modified_flag_cleared"], "timeout_ms": 5000 } ], "verification": { "pass": "modified_flag == false OR success_toast.visible == true", "fail": "timeout OR error_dialog.visible == true" }, "recovery": [ {"on": "timeout", "try": "press_escape", "then": "retry_actions"}, {"on": "error_dialog", "try": "read_message", "then": "log_and_abort"} ] }触发条件说明这个技能在什么状态下生效，执行体描述具体动作序列，验证规则判断操作是否真的成功。这个设计里最重要的是最后那个recovery字段，它决定了技能在遇到异常时是自动恢复还是安全退出。技能必须有明确的自救能力，而不是像传统脚本一样一旦出错就停在原地，这种设计在实践中能解决大部分偶发弹窗问题。
2.2 技能注册与编排：从意图到动作序列
单看一个技能都是简单的，复杂的是把这些技能串起来解决一个完整任务。我在这套框架里做了一个技能注册表，所有技能统一登记，注册表会维护技能之间的依赖关系，我不允许技能之间存在隐性依赖，一切都得显式声明。
整体流程是用LLM作为编排核心。Agent先接收用户意图，拆解为一个任务图，然后逐个匹配技能。比如“把这份报表导出成PDF然后通过邮件发送”这个任务，会被拆成：打开报表应用、定位报表、导出PDF、打开邮箱客户端、新建邮件、添加附件、输入收件人、发送。每个节点都能在注册表里找到对应的技能，节点之间的数据传递也靠技能的输出定义来衔接。
这套编排设计的好处是：新任务不需要写新代码，只需要重新组合已有技能。我维护这个项目一段时间后，技能库从最初的十几个增长到四十多个，但新任务的平均开发时间反而越来越短，因为绝大多数流程都可以复用，需要新增的只是一些特定于业务场景的细节技能。
2.3 界面感知的三种核心技术路线
技能执行第一步是“感知界面”，这一步的技术选型直接决定整个框架的上限。我实测下来有三条路线，各有取舍：
路线一：系统辅助功能接口。这是最精准的路线，读的是应用暴露出来的控件树，能拿到控件类型、名称、状态、位置等结构化数据。它的致命弱点是，很多应用的自定义控件没法通过标准接口读取，尤其是那些用Canvas自绘界面的应用，控件树往往是一片空白。
路线二：视觉识别与OCR。截图之后用目标检测模型识别按钮位置，用OCR读取文本内容。这条路线的优势是和应用具体实现无关，不管什么界面框架都能处理；缺点是精确度受画质影响，文字识别偶尔会出错，并且对视觉模型的推理资源要求较高。
路线三：混合感知。这是CUA-Skill框架实际采用的方案。先尝试读控件树，拿到可靠的结构化信息；读不到时再降级到视觉识别。两条路都走不通的时候，技能会主动报告“当前界面状态未知”，而不是盲目尝试操作。
2.4 为什么选择语义化定位而不是纯坐标
传统GUI自动化对坐标的依赖太重，这是我觉得最需要摆脱的一件事。坐标天然脆弱，分辨率一变、窗口一移、分栏一拖，坐标就全错了。CUA-Skill框架里，定位全部基于语义描述，比如“当前窗口右上角的关闭按钮”“列表第一行第三个单元格”。
坐标这个维度只在动作执行的最底层才出现，它由“感知模块”实时计算出来，整个Skill定义里不存任何硬编码坐标。我实际验证过，把窗口从一个显示器拖到另一个显示器，或者分辨率从1080P切换到4K，技能依然能正常执行，因为动作层是在感知之后即时生成坐标，而不是从历史数据里读坐标。
3. 实操：从零构建一个可用的GUI操作技能
3.1 环境准备与权限配置
动手之前先说环境，这套框架主要用Python搭建。感知层用到了系统辅助功能API（Windows平台通过pywinauto或UIAutomation库，macOS通过pyobjc访问AXUIElement接口），视觉识别层用了一套轻量级目标检测模型做按钮定位，OCR用通用文本识别引擎。
最麻烦的是权限配置。macOS上要开启终端或主程序所在应用的“辅助功能”权限，否则任何AX调用都拿不到数据；Windows上虽然权限限制相对宽松，但以管理员身份运行的系统和普通用户态运行的系统，UIA的权限边界也不一致，目标应用以管理员运行时，非管理员态的Agent去读取UIA数据会直接失败。
注意：权限问题是最容易让人误判为代码Bug的地方。如果你发现某个技能在自己的机器上跑得正常，换一台机器却无法感知任何控件，优先检查辅助功能权限有没有被系统重置，别一上来就查代码逻辑。
3.2 Skill定义的完整示例
我拿一个真实场景来演示：自动翻页读取网页内容。假设在一个不支持键盘操作的自定义浏览器内核中翻页，我们需要定义技能webpage.next_page：
skill_name: webpage.next_page version: 1.0.0 description: 翻到下一页并等待内容加载完成 inputs: - name: max_retry type: int default: 3 trigger: element: window.active conditions: - if: "next_button.visible == true OR scroll_container.visible == true" then: "proceed" - else: "report_no_next_page" actions: - step: 1 method: perceive target: "page_container" wait_for: "content_loaded" timeout_ms: 8000 - step: 2 method: locate strategy: "hybrid" candidates: - "//button[contains(@aria-label, '下一页')]" - "//*[@data-testid='next-page']" - "visual_find: bottom_right_region" - step: 3 method: click element: "located_element" click_mode: "human_like" post_wait: 500 - step: 4 method: verify check: "page_content_changed OR scroll_position_increased" timeout_ms: 5000 - step: 5 method: extract target: "new_page_content" save_as: "content_snapshot" recovery: - on: "element_not_found" try: "visual_find_retry" max_retry: 3 - on: "content_not_changed" try: "scroll_container_to_bottom" then: "re_verify"这个示例里最值得关注的是candidates字段，它体现了语义化定位的精髓。定位按钮时，优先按可访问性标签找，不行就按DOM测试标识找，再不行才降级到视觉识别。三条候选路径是串行尝试的，每一条失败后都会记录失败原因，最终即使技能无法完成目标，也能留下“尝试了哪些路径、在哪个环节失败”的排查日志，而不是一个笼统的“出错”。
3.3 技能调用的核心逻辑
光有Skill定义，还不算跑通的框架。Agent侧需要一套执行引擎来驱动整个流程。核心循环可以抽象为下面的逻辑：
def execute_skill(skill_definition, context): # 阶段一：触发判断 if not check_trigger(skill_definition["trigger"], context): return SkillResult(skipped=True, reason="trigger_not_met") # 阶段二：步骤执行 for step in skill_definition["actions"]: for attempt in range(1, max_retry + 1): try: step_result = run_step(step, context) if step_result.success: break recovery = get_recovery_for(step, skill_definition) if recovery: apply_recovery(recovery, context) continue return SkillResult(failed=True, step=step, error=step_result.error) except PermissionError: return SkillResult(failed=True, error="permission_denied") # 阶段三：最终校验 if verify_skill(skill_definition["verification"], context): return SkillResult(success=True) else: return SkillResult(failed=True, error="verification_failed")执行引擎除了顺序执行步骤之外，还要维护一个全局的界面状态缓存。这个缓存很关键，它保存的是上一次感知到的窗口信息、控件位置和内容摘要，并行执行的多个技能会共享这份缓存。我实测过，有了缓存，一个流程里的连续多个技能，感知次数能减少约40%，每次感知都涉及截图或控件树读取，省下来的是立竿见影的速度提升。
还要补充一个调度逻辑：技能之间是顺序还是并发，由编排层根据任务图决定。并发执行时必须隔离各自的界面状态上下文，一旦两个技能同时去操作同一个窗口，轻则操作互相覆盖，重则一个技能等另一个技能的窗口出现，直接死锁。所以我在框架里做了窗口锁，窗口级互斥，宁可牺牲一点并发度，也不能让界面状态错乱。
3.4 正确率与效率的平衡技巧
技能设计里有一个很现实的矛盾：验证步骤越严格，越不容易误判成功，但耗时也越长。我在实际项目中总结了一套分级策略。
轻量验证只检查操作是否执行成功，比如按钮点击后焦点是否变化、是否出现预期的小组件状态变化，耗时可以压到1秒以内。标准验证是在轻量验证基础上再检查关键结果，比如保存后检查未保存标记是否消失，耗时2到3秒。完整验证则是做内容层的比对，比如导出的文件和源数据是否一致，耗时可能长达10秒，只在关键节点使用。技能定义里配置成可调的，Agent在编排时根据任务的复杂程度自动选择合适的验证级别，这个折中真的很重要，一直跑完整验证，整个流程会慢到让人想放弃。
4. 常见问题与排查实录
4.1 界面轻微变化导致定位失败
我实际跑的时间久了之后，最常见的失败场景就是目标元素的属性值发生轻微偏移。比如一个按钮的标题从“查询”变成了“查 询”，中间多了个空格，基于精确文本匹配的选择器就会失效。
解决办法是给选择器加上模糊匹配机制。文本匹配改用空格归一化后再比对，控件类型匹配允许泛化，比如Button和CustomButton认为是同一类。视觉识别兜底策略在这时也很有用，控件树里的属性对不上，就切到视觉识别按形状和相对位置找按钮。加了这些机制之后，技能面对界面微调的容错能力明显提升。
4.2 动态加载与异步渲染的等待问题
动态内容是最容易把自己坑了的场景。传统脚本喜欢固定等待几秒，我见过有人因为网速波动，把整个流程的等待时间拉到20秒，效率极低。CUA-Skill框架里采用的方案是轮询式状态检测，循环检查某个目标状态是否出现，而不是固定等待。
def wait_for(condition_fn, timeout_ms=5000, interval_ms=200): deadline = time.time() + timeout_ms / 1000 last_state = None while time.time() < deadline: state = condition_fn() if state.is_achieved: return state last_state = state time.sleep(interval_ms / 1000) raise TimeoutError(f"condition not met. last state: {last_state}")这套轮询逻辑的核心是先判断目标状态是否已经满足，如果已满足就直接继续，不再傻等，能省下不少等待时间。对动态渲染的内容，我都是先等主框架元素出现，再等内部数据元素出现，分阶段等待，避免一上来就等一个靠后的元素导致前端一直不渲染就超时。
4.3 权限与系统级拦截
macOS升级某个大版本后，辅助功能权限经常被重置，这是系统级行为，不是代码能决定的。遇到这种情况没有捷径，只能加一个启动自检模块，启动时做一个最小权限探活测试，比如尝试读取当前前台的窗口标题，拿不到就直接提示权限异常，并给出打开系统设置的具体路径，而不是等到流程跑到一半才报一堆莫名其妙的错。
Windows上还会遇到另一种权限场景：目标应用高权限运行，Agent低权限访问。这种情况下UIA的查询接口经常返回空数据。我的建议是尽量让Agent和目标应用保持同一权限级别，如果实在做不到，就主动降级走视觉识别路线，别在控件树数据上死磕。
4.4 技能组合执行时的状态依赖
技能之间的状态传递是另一个高频出问题的点。比如“导出Excel”这个技能结束后，“发送邮件”这个技能需要读取到导出文件的路径。如果这两个技能之间没有显式约定，运行时会经常出现文件还没落盘就触发邮件附件的错误。
解决这个问题的方案是技能的输出协议。每个技能的输出参数必须明确声明，并且写清楚有效条件的定义。导出技能的输出文档路径必带一个file_ready标记，这个标记由“文件大小稳定且文件可打开”来确定。下游技能接收到这个参数后，必须先检查标记再继续，只要输出协议清晰，技能之间的组合就能做到高可靠。
4.5 性能与资源占用控制
视觉识别模型跑在CPU上时，单次识别的延迟可能在几百毫秒到几秒不等，整个流程里如果有大量视觉识别步骤，性能会很难看。我的经验是：能不截图就不截图，优先走控件树读取；必须走视觉识别时，缩小检测区域。不要对全屏做识别，先根据窗口位置估算一个包含目标元素的小区域，再在小区域内检测，识别耗时会大幅下降，实测能从一两秒降到两三百毫秒。
缓存也值得一提。目标应用短时间内界面不会变化，缓存上一次的控件树数据和截图结果，直接命中缓存，就能跳过整个感知环节。
5. 经验心得与可扩展的方向
这套框架我前后迭代了几个月，最大的体会是：不要把GUI自动化当脚本写，要当系统来设计。脚本是给特定界面量身定做的，系统是为一类界面场景提供通用能力。Skill就是中间那层“通用能力”的载体，它把感知、决策、执行、验证四个环节固化成模板，让Agent能站在语义层面思考，而不用陷在坐标和控件ID里。
我还在摸索的方向有三个。第一个是技能之间的动态组合，目前编排主要靠LLM根据任务图选择技能，接下来想尝试让Agent在技能执行中途，根据实际界面反馈临时切换其他技能，这更像人的操作方式。第二个是跨设备联动，同一个技能定义能否直接从桌面端迁移到移动端，比如“点击登录按钮”这个技能，在PC上靠鼠标坐标，在手机上靠触摸坐标，语义是一样的。第三个是把技能定义本身用自然语言生成，我做过一个实验，描述一个操作流程，让LLM生成对应的Skill定义，正确率大概在七成左右，继续优化后这个方向应该能大幅降低技能开发成本。
最后分享一个小技巧：给每个技能加上一个“成功率自评”字段，每次执行完由验证模块自动评估，定期统计那些成功率低于阈值的技能，重点去排查它们的定义或者感知策略。这个做法能帮你持续发现框架的薄弱环节，很多人忽略了这个数据驱动的迭代方式，实际用起来效果相当好。
GUI自动化这个领域，正在从“跑一遍能用就行”走向“面对未知界面也能靠谱干活”。CUA-Skill框架的探索还远谈不上终点，但这条技术路线值得更多实践者加入进来。如果你也在做类似的方向，欢迎把你在技能拆解和界面感知上的经验沉淀下来，这条路一本书都写不完。
