手机GUI Agent双通道感知：无障碍树与投屏像素融合方案-北京尧图网络

1. 为什么手机 GUI Agent 需要双通道感知做过手机端自动化的人都有一个共识单靠一种感知方式Agent 迟早会在某个场景里翻车。我最早做 GUI Agent 的时候只用了无障碍树AccessibilityService来获取界面元素跑通了一些常规 App 的点击、输入、滑动流程感觉还挺顺。但一遇到游戏界面、Flutter 自绘控件、WebView 里的混合内容无障碍树直接变成一片空白或者只给几个毫无意义的容器节点Agent 瞬间变成瞎子。后来我尝试纯靠投屏像素做视觉识别用 MediaProjection 抓屏幕帧然后跑 OCR 和图标检测。这条路在无障碍树失效的场景下确实能兜住但代价也很明显每一帧都要做图像处理延迟高、耗电快而且纯像素方案对文字输入的定位精度远不如无障碍树给出的坐标来得直接。踩了几次坑之后我确定了一个思路以无障碍树为主通道投屏像素为兜底通道两者互补而不是互斥。无障碍树能拿到结构化信息的时候优先用它速度快、精度高、语义清晰无障碍树拿不到或者信息不完整的时候自动降级到像素通道用截图加视觉分析来补位。这套双通道架构在我后续的项目里跑了很长时间稳定性比单通道方案高出一个量级。这篇文章我会把整套方案的设计思路、核心实现细节、实操步骤、参数选择依据、以及我在实际调试中踩过的坑全部拆开讲。适合正在做移动端自动化、GUI Agent、RPA 工具、或者任何需要让程序“看懂手机屏幕”的开发者参考。不管你是刚接触 AccessibilityService 的新手还是已经在用 MediaProjection 做投屏的老手应该都能从里面找到一些可以直接抄作业的东西。2. 双通道感知的整体架构设计2.1 主通道与兜底通道的职责划分双通道的核心设计原则是主通道优先、兜底通道补位、融合层决策。无障碍树通道负责处理绝大多数标准控件场景它通过 AccessibilityService 拿到当前窗口的节点树每个节点包含类名、文本、内容描述、边界坐标、可点击状态等属性。这些信息是结构化的Agent 可以直接根据文本或 ID 定位目标元素不需要做任何图像处理。投屏像素通道则是在无障碍树无法提供有效信息时启动。它通过 MediaProjection 获取屏幕实时画面然后对帧图像做 OCR 文字识别、图标模板匹配、颜色区域分析等处理最终输出可操作的坐标和语义标签。这条通道的优势是“所见即所得”不管界面是什么技术栈渲染的只要人眼能看到像素通道就能处理。融合层的职责是先问无障碍树“你能不能搞定”如果能直接用如果不能或者置信度低再问像素通道。两条通道的输出最终统一成同一种数据结构交给上层的决策模块使用。2.2 为什么不是二选一而是双通道有人可能会问既然像素通道什么都能做为什么不干脆只用像素通道答案很简单成本和精度。无障碍树获取节点信息的耗时通常在 50 到 200 毫秒之间而一次完整的截图加 OCR 加图标匹配在中等性能手机上可能要 500 毫秒到 1.5 秒。对于需要快速连续操作的 Agent 来说这个延迟差距是致命的。另外无障碍树提供的语义信息是像素通道很难精确还原的。比如一个输入框无障碍树直接告诉你它的类名是 EditText、是否可编辑、当前内容是什么、最大长度是多少像素通道只能看到一块矩形区域和里面的文字至于这块区域能不能输入、输入后会发生什么它不知道。反过来说像素通道能覆盖无障碍树完全失效的场景。我遇到过不少 App 用了自定义渲染引擎整个界面在无障碍树里只有一个根节点所有内容都是画上去的。这种情况下像素通道就是唯一的救命稻草。所以双通道不是冗余设计而是用最低的综合成本覆盖最全的场景。2.3 通道切换的触发条件通道切换不能靠猜必须有明确的触发条件。我在实际项目里总结了以下几种必须从主通道降级到兜底通道的情况无障碍树返回的节点总数少于 3 个且没有可点击节点。这通常意味着界面是自绘的无障碍树拿不到有效信息。目标元素在无障碍树中找不到但通过像素分析能定位到相似区域。这说明无障碍树的语义信息不完整。无障碍树返回的节点边界坐标全部为 0 或者超出屏幕范围。这是某些 App 故意屏蔽无障碍服务的表现。当前界面被判定为游戏、视频播放器、或者全屏画布类应用。这类场景无障碍树基本无效可以直接走像素通道。无障碍树连续多次获取失败或者超时。这时候需要临时切换到像素通道同时后台继续尝试恢复主通道。这些触发条件不是拍脑袋定的是我在不同 App 上反复测试后总结出来的经验值。比如“节点总数少于 3 个”这个阈值我试过 5 和 10发现 5 会误判一些简洁的登录页面10 会漏掉一些自绘界面最后定在 3 比较稳。3. 无障碍树通道的核心实现细节3.1 AccessibilityService 的配置与启动无障碍树通道的基础是 AccessibilityService。这个服务需要在 Android 系统的无障碍设置里手动开启或者通过 adb 命令授权。在配置文件里你需要声明服务能接收的事件类型和能获取的窗口信息。service android:name.MyAccessibilityService android:permissionandroid.permission.BIND_ACCESSIBILITY_SERVICE android:exportedtrue intent-filter action android:nameandroid.accessibilityservice.AccessibilityService / /intent-filter meta-data android:nameandroid.accessibilityservice android:resourcexml/accessibility_config / /service对应的accessibility_config.xml里关键配置项包括accessibility-service android:accessibilityEventTypestypeAllMask android:accessibilityFeedbackTypefeedbackGeneric android:accessibilityFlagsflagDefault|flagReportViewIds|flagRetrieveInteractiveWindows android:canRetrieveWindowContenttrue android:notificationTimeout100 android:packageNames /这里有几个参数值得展开说。accessibilityEventTypes设成typeAllMask是为了接收所有类型的事件包括窗口变化、内容变化、滚动等。flagReportViewIds让你能拿到每个节点的资源 ID这对精确定位非常有用。flagRetrieveInteractiveWindows允许你获取多个窗口的内容比如弹窗和主窗口同时存在的情况。notificationTimeout设成 100 毫秒是一个折中值太短会导致事件风暴太长会漏掉快速变化的界面。3.2 节点树的遍历与信息提取拿到 AccessibilityNodeInfo 之后需要递归遍历整棵树提取每个节点的关键属性。我通常会提取以下字段属性名获取方法用途类名getClassName()判断控件类型文本getText()文字定位内容描述getContentDescription()图标按钮的语义资源 IDgetViewIdResourceName()精确定位边界坐标getBoundsInScreen()点击坐标计算可点击isClickable()判断是否可交互可编辑isEditable()判断是否输入框可滚动isScrollable()判断是否列表层级深度递归时记录过滤冗余节点遍历的时候有一个坑某些 App 的节点树非常深递归遍历可能耗时几百毫秒甚至更久。我的做法是设置一个最大深度限制比如 30 层超过就不再往下遍历。同时设置一个最大节点数限制比如 2000 个超过就截断。这两个阈值需要根据目标 App 的复杂度调整。另一个坑是getText()和getContentDescription()可能返回 null必须做空值判断。还有getBoundsInScreen()返回的 Rect 可能是空矩形需要检查宽高是否大于 0。3.3 节点过滤与有效元素判定原始节点树里包含大量无意义的容器节点比如 FrameLayout、LinearLayout 这些布局容器它们本身不可点击也没有文本但会占据大量节点数量。如果不做过滤后续的匹配和决策会被噪声淹没。我的过滤规则是这样的一个节点被认为是“有效元素”需要满足以下至少一个条件有非空的文本内容有非空的内容描述是可点击的是可编辑的是可滚动的是 CheckBox、RadioButton、Switch 等有状态的控件同时如果一个节点满足以下条件会被标记为“容器节点”并降低优先级类名包含 Layout 且没有文本和内容描述边界坐标覆盖超过屏幕面积的 80% 且没有交互属性过滤之后一个典型界面的有效元素数量通常在 10 到 50 个之间比原始节点树少了一个数量级。这大大加快了后续的匹配速度。3.4 主通道的失效场景与识别方法无障碍树通道不是万能的我总结了以下几类典型失效场景以及对应的识别方法场景一自绘界面。整个屏幕在无障碍树里只有一个根节点所有内容都是 Canvas 画上去的。识别方法是检查节点总数是否小于阈值且根节点的子节点数为 0 或 1。场景二WebView 混合内容。部分 WebView 内容会出现在无障碍树里但结构混乱文本可能被拆分到多个节点。识别方法是检查是否存在类名包含 WebView 的节点且其子节点结构异常。场景三游戏引擎渲染。Unity、Cocos 等引擎渲染的界面无障碍树基本为空。识别方法是检查当前前台应用包名是否在游戏白名单里或者节点总数是否极少。场景四安全键盘。某些输入场景会弹出安全键盘无障碍树无法获取按键信息。识别方法是检查是否存在类名包含 SecurityKeyboard 或类似关键词的窗口。场景五系统权限弹窗。某些系统级弹窗不在无障碍树的服务范围内。识别方法是检查当前活动窗口的包名是否为 system_server 或类似系统进程。针对这些场景我的策略是一旦识别到主通道失效立即切换到像素通道同时在后台保持无障碍服务的监听等待界面变化后重新尝试主通道。4. 投屏像素通道的核心实现细节4.1 MediaProjection 的申请与帧获取投屏像素通道的基础是 MediaProjection。这个 API 需要用户手动授权一次授权之后可以持续获取屏幕画面。申请流程是先通过 MediaProjectionManager 创建一个 Intent启动系统授权界面用户同意后拿到 resultCode 和 data再用它们创建 MediaProjection 实例。MediaProjectionManager manager (MediaProjectionManager) getSystemService(Context.MEDIA_PROJECTION_SERVICE); Intent intent manager.createScreenCaptureIntent(); startActivityForResult(intent, REQUEST_CODE);在 onActivityResult 里MediaProjection projection manager.getMediaProjection(resultCode, data); ImageReader reader ImageReader.newInstance(width, height, PixelFormat.RGBA_8888, 2); projection.createVirtualDisplay(screen, width, height, density, DisplayManager.VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR, reader.getSurface(), null, null);这里有几个关键参数需要仔细选择。width和height建议用屏幕实际分辨率的一半或三分之一而不是全分辨率。原因是全分辨率的图像处理耗时太长而 OCR 和图标匹配在降采样后的图像上依然能保持不错的精度。我通常用 720p 或者 540p 作为处理分辨率。PixelFormat.RGBA_8888是通用性最好的格式虽然内存占用比 RGB_565 大但兼容性问题少。maxImages设成 2 是为了避免缓冲区堆积如果设得太大图像处理跟不上帧率时会导致内存暴涨。4.2 帧图像预处理与降噪从 ImageReader 拿到的原始帧不能直接丢给 OCR需要先做预处理。我的预处理流程包括灰度化把 RGBA 转成灰度图减少后续计算量。OCR 和模板匹配在灰度图上都能正常工作。降采样如果原始帧是 1080p降采样到 540p。这一步能减少 75% 的像素数量处理速度提升明显。二值化对灰度图做自适应二值化把文字区域和背景分离。这一步对 OCR 精度提升很大尤其是深色背景上的浅色文字。去噪用中值滤波或者高斯模糊去掉细小的噪点避免 OCR 把噪点识别成文字。预处理之后的图像OCR 的识别速度和准确率都会有明显提升。我实测下来预处理能让 OCR 耗时降低 40% 左右准确率提升 10 到 15 个百分点。4.3 OCR 文字识别与坐标映射OCR 是像素通道的核心能力之一。我常用的方案是 Tesseract 或者 PaddleOCR 的移动端版本。Tesseract 集成简单但中文识别效果一般PaddleOCR 效果好但包体积大。如果目标场景以中文为主建议用 PaddleOCR 的轻量模型。OCR 返回的结果通常是一组文本块每个文本块包含文字内容和边界框。边界框的坐标是基于处理后的图像尺寸的需要映射回原始屏幕坐标。映射公式是screenX imageX * (screenWidth / imageWidth) screenY imageY * (screenHeight / imageHeight)这里要注意MediaProjection 获取的图像可能包含状态栏和导航栏而实际可操作区域不包含这些。所以映射之后还需要减去状态栏高度和导航栏高度才能得到准确的点击坐标。另一个细节是 OCR 的置信度过滤。PaddleOCR 会返回每个文本块的置信度分数我通常把阈值设在 0.7 左右低于这个值的文本块直接丢弃避免误识别导致误点击。4.4 图标模板匹配与颜色区域分析除了文字界面上还有大量图标按钮比如返回箭头、菜单按钮、关闭按钮等。这些图标没有文字OCR 处理不了需要用模板匹配来解决。模板匹配的基本思路是预先截取常见图标的图像作为模板然后在当前帧上滑动窗口计算相似度找到匹配位置。常用的相似度算法是归一化互相关NCC或者结构相似性SSIM。NCC 计算量大但精度高SSIM 速度快但精度略低。我通常用 NCC 的简化版本在降采样后的图像上做匹配。模板库的维护是一个持续的工作。我建议按 App 分类维护模板库每个 App 的常见图标单独存一组模板。模板图像要包含不同状态下的样子比如按钮的普通态、按下态、禁用态。模板数量控制在每个 App 20 到 50 个之间太多会导致匹配耗时过长。颜色区域分析主要用于处理纯色按钮或者色块。比如一个绿色的“确认”按钮可以通过颜色阈值分割找到它的位置。这种方法的优点是速度快缺点是对颜色变化敏感不同主题下可能需要调整阈值。4.5 像素通道的性能优化策略像素通道最大的问题是性能。我在这方面做了不少优化效果比较明显的几个策略是策略一按需截图。不要持续不断地截图而是在需要的时候才截一帧。比如 Agent 决定要操作界面了先截一帧分析分析完就停止截图等下一次需要时再截。这样能把 CPU 和内存占用降低一个数量级。策略二区域裁剪。如果已知目标元素大概在屏幕的某个区域只截取那个区域进行分析而不是全屏。比如输入框通常在屏幕下半部分可以只截下半屏。策略三多分辨率处理。先用低分辨率做粗定位找到候选区域后再用高分辨率做精定位。这样兼顾了速度和精度。策略四结果缓存。如果连续多帧的界面没有变化直接复用上一次的分析结果不需要重新处理。判断界面是否变化可以用简单的帧差法计算两帧之间的像素差异。策略五异步处理。图像处理放在独立线程里做不阻塞主线程。Agent 的决策逻辑可以先用无障碍树的结果等像素通道的结果出来后再补充。这些策略组合使用之后像素通道的平均耗时能从 1.5 秒降到 300 到 500 毫秒基本能满足大多数场景的需求。5. 双通道融合与决策逻辑5.1 统一数据结构的定义两条通道的输出需要统一成同一种数据结构才能交给上层决策模块使用。我定义的元素结构包含以下字段class UIElement { String text; // 文本内容 String description; // 内容描述 String className; // 控件类名 String resourceId; // 资源 ID Rect bounds; // 屏幕坐标 boolean clickable; // 是否可点击 boolean editable; // 是否可编辑 float confidence; // 置信度 String source; // 来源通道accessibility 或 pixel }confidence字段很关键它表示这个元素的可靠程度。无障碍树来的元素置信度通常在 0.9 以上像素通道来的元素置信度根据 OCR 分数或匹配分数来定通常在 0.6 到 0.9 之间。决策模块在多个候选元素之间选择时会优先选置信度高的。source字段用于追溯和调试。当 Agent 操作出错时可以通过 source 快速定位是哪条通道出了问题。5.2 元素匹配与优先级策略当 Agent 需要找一个目标元素时融合层的匹配流程是这样的先在无障碍树通道的结果里找。匹配依据是文本、内容描述、资源 ID 的组合。如果找到唯一匹配且置信度高于 0.9直接返回。如果无障碍树里找到多个匹配或者置信度不够高再在像素通道的结果里找。匹配依据是 OCR 文本和图标模板。如果两条通道都找到了候选元素比较它们的置信度和位置重叠度。位置重叠度高且置信度接近的认为是同一个元素合并结果。如果只有一条通道找到直接用那条通道的结果但置信度会打一个折扣。如果两条通道都没找到返回空Agent 进入等待或重试逻辑。这个流程的关键是优先级和置信度的平衡。不能无脑信无障碍树也不能无脑信像素通道要根据具体场景动态调整。5.3 冲突消解与置信度计算两条通道的结果偶尔会冲突。比如无障碍树说某个按钮在坐标 (100, 200)像素通道说在 (105, 195)。这种小偏差通常没关系取平均值或者取置信度高的那个就行。但如果偏差很大比如无障碍树说在 (100, 200)像素通道说在 (500, 600)那就需要判断哪个更可信。我的做法是检查无障碍树节点的边界坐标是否合理。如果坐标超出屏幕范围或者宽高为 0判定为无效采信像素通道。检查像素通道的 OCR 置信度。如果低于 0.6判定为不可靠采信无障碍树。如果两者都合理检查当前界面类型。标准控件界面优先信无障碍树自绘界面优先信像素通道。如果还是无法判断两个都保留让 Agent 先试一个失败了再试另一个。置信度的计算是一个加权公式finalConfidence w1 * sourceConfidence w2 * matchScore w3 * positionScore其中sourceConfidence是通道本身的置信度matchScore是匹配算法的分数positionScore是位置合理性的分数。权重w1、w2、w3根据实际测试调整我目前用的是 0.5、0.3、0.2。5.4 动态权重调整与自适应机制固定的权重在不同场景下表现不一样。比如在标准 App 里无障碍树的权重应该高一些在游戏里像素通道的权重应该高一些。所以我加了一个动态权重调整机制。调整的依据是历史成功率。系统会记录每条通道在过去一段时间内的操作成功率成功率高的通道权重自动提升。比如无障碍树连续 10 次操作都成功它的权重从 0.5 提升到 0.6像素通道连续 3 次失败它的权重从 0.5 降到 0.35。这个机制让系统能自适应不同 App 的特点不需要人工为每个 App 单独调参。实测下来动态权重比固定权重的综合成功率高 15 到 20 个百分点。6. 实操过程中的常见问题与排查技巧6.1 无障碍服务被系统杀死的处理Android 系统在内存紧张时会杀掉后台服务无障碍服务也不例外。服务被杀之后Agent 会突然失去主通道所有操作都会失败。我的处理方案是在 Agent 的主循环里加一个健康检查每隔几秒检查一次无障碍服务是否还活着。检查方法是调用getRootInActiveWindow()如果返回 null 或者抛出异常说明服务可能已经失效。这时候需要重新启动服务或者提示用户手动重新授权。另外可以在 Application 里注册一个 ServiceConnection监听无障碍服务的连接状态。服务断开时立即触发重连逻辑。还有一个坑是某些国产 ROM 会在息屏后自动杀掉无障碍服务。这种情况下需要引导用户把 App 加入电池优化白名单或者保持屏幕常亮。6.2 投屏授权失效与重连机制MediaProjection 的授权在以下情况下会失效用户手动停止投屏、系统重启、App 被杀死后重新启动。授权失效后createVirtualDisplay会抛出异常或者 ImageReader 不再产生新帧。我的处理方案是在帧获取的循环里加超时检测如果超过 2 秒没有新帧判定为投屏失效。然后触发重新授权流程弹出一个提示让用户重新同意投屏。为了减少用户打扰我会尽量复用已有的授权。MediaProjection 的授权在同一个 App 生命周期内是有效的只要不主动停止可以一直用。所以 App 启动时申请一次授权之后尽量保持。6.3 坐标偏移与分辨率适配问题坐标偏移是双通道方案里最常见的问题之一。典型表现是Agent 明明找到了正确的元素但点击位置偏了点到了旁边的元素或者空白区域。造成坐标偏移的原因通常有这几个状态栏和导航栏的高度没有正确扣除。不同手机的状态栏高度不一样有的 24dp有的 48dp需要动态获取。屏幕旋转后坐标系没有更新。横屏和竖屏的坐标系原点不一样需要重新计算。投屏图像的分辨率和实际屏幕分辨率不一致映射公式用错了。某些 App 使用了自定义的窗口偏移实际可操作区域和屏幕区域不一致。排查方法是在调试模式下把 Agent 计算出的点击坐标画在截图上人眼检查是否对准了目标元素。如果偏了逐步检查上述几个原因。我通常会在代码里加一个校准流程在屏幕上显示几个已知位置的标记点让 Agent 去点击根据点击结果反推坐标偏移量然后把这个偏移量应用到后续的所有点击上。6.4 高频操作下的性能瓶颈排查当 Agent 需要快速连续操作时性能瓶颈会暴露出来。常见的表现是操作延迟越来越大最终卡死或者超时。排查思路是从上到下逐层检查排查层级检查项常见问题应用层Agent 主循环耗时决策逻辑太复杂融合层元素匹配耗时候选元素太多无障碍通道节点遍历耗时节点树太深像素通道图像处理耗时分辨率太高系统层CPU 和内存占用资源竞争我遇到过的典型瓶颈包括无障碍树遍历没有深度限制遇到超深节点树时耗时超过 1 秒OCR 模型加载在每次识别时都重新初始化浪费了大量时间图像处理没有用线程池串行执行导致排队。对应的优化手段是加深度限制和节点数限制OCR 模型只加载一次全局复用图像处理用固定大小的线程池并发执行。6.5 常见问题速查表问题现象可能原因排查方法解决方案无障碍树返回空服务未开启或被杀死检查服务状态重新授权或重启服务节点坐标全为 0App 屏蔽无障碍检查节点属性切换到像素通道OCR 识别率低图像质量差查看预处理结果调整二值化参数点击位置偏移坐标映射错误可视化点击点校准偏移量投屏无画面授权失效检查帧超时重新申请授权操作延迟高性能瓶颈逐层计时优化耗时环节元素匹配错误置信度阈值不当查看匹配分数调整阈值界面变化后未更新缓存未失效检查帧差强制刷新缓存7. 实际项目中的经验总结与扩展思路7.1 双通道方案的适用边界双通道方案不是银弹它有明确的适用边界。适合的场景包括标准 App 的自动化操作、跨 App 的流程编排、需要处理多种界面类型的通用 Agent。不适合的场景包括对延迟极度敏感的操作比如游戏内的实时操作、对精度要求极高的操作比如绘图应用、以及资源极度受限的设备。在这些不适合的场景里可能需要更专门的方案。比如游戏内操作可以用图像识别加固定坐标的方式绘图应用可以用坐标映射加轨迹规划的方式。双通道方案的价值在于通用性和鲁棒性而不是极致的性能。7.2 从双通道到多通道的扩展双通道是一个基础框架可以很方便地扩展到多通道。比如加入一个“布局文件通道”通过解析 APK 的布局文件来获取元素信息或者加入一个“网络请求通道”通过拦截 App 的网络请求来获取数据。每个通道负责一种感知方式融合层负责统一调度。扩展的关键是保持接口一致。每个通道都实现同一个接口输入是当前界面状态输出是统一格式的元素列表。融合层不需要知道具体有哪些通道只需要按优先级和置信度做决策。7.3 模型化决策的尝试目前融合层的决策逻辑是基于规则的规则的好处是可解释、易调试缺点是难以覆盖所有情况。我最近在尝试用一个小型模型来做决策输入是两条通道的输出特征输出是最终的元素选择。模型化的好处是能自动学习不同场景下的最优策略不需要人工写规则。缺点是需要大量标注数据而且模型的可解释性差出问题时不好排查。目前的进展是在标准场景下模型和规则的效果差不多在复杂场景下模型略好一些。后续还需要更多数据来验证。7.4 我在实际调试中的几个心得第一个心得是日志要足够详细。双通道方案涉及的信息很多如果日志只记录最终结果出问题时根本不知道是哪一步错了。我的做法是每个通道的输出都单独打日志融合层的决策过程也打日志这样出问题时可以快速定位。第二个心得是可视化调试工具很重要。我写了一个简单的调试界面能把无障碍树的结构、像素通道的识别结果、最终的点击坐标都画在截图上。人眼一看就知道哪里不对比看日志快得多。第三个心得是不要追求一次完美。双通道方案涉及的技术点很多想一次把所有场景都覆盖是不现实的。我的做法是先覆盖最常见的 80% 场景剩下的 20% 边跑边补。每遇到一个新问题就加一条规则或者一个模板慢慢积累。第四个心得是性能优化要趁早。我一开始觉得性能不是问题结果跑到复杂界面时直接卡死。后来花了不少时间做优化才发现如果一开始就注意性能能省很多事。建议在架构设计阶段就把性能纳入考虑比如限制节点数、降采样图像、异步处理等。这套双通道方案我用了挺长时间中间迭代了很多版从最初的粗糙实现到现在相对稳定踩过的坑不计其数。如果你也在做类似的事情希望这些经验能帮你少走一些弯路。后续我还会继续优化融合层的决策逻辑以及探索更多通道的扩展可能性。

手机GUI Agent双通道感知：无障碍树与投屏像素融合方案

相关推荐

AutoGen源码静态审计：多Agent协作框架的架构设计与核心实现解析

手机GUI Agent双通道感知：无障碍树与投屏像素融合实战

工业空预器高效换热技术与工程实践解析

更多资讯

基于YOLOv5的道路坑洼检测系统设计与实现

基于多目标粒子群算法的水下图像增强技术

EECS designlab7 光敏电阻机器人实验：从分压电路到CMax仿真与负载效应排查

多线程编程核心概念与实践指南

AI Agent如何优化项目结构管理与Vibe Coding实践

鲲鹏ARM64麒麟V10源码编译安装Argon2与调参实战

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？