首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >网页Agent卡在第9步,桌面Agent走完14步|PRIVO AI智能操作助手 三合一·网页+桌面+IDE

网页Agent卡在第9步,桌面Agent走完14步|PRIVO AI智能操作助手 三合一·网页+桌面+IDE

原创
作者头像
用户12722577
发布于 2026-11-06 16:53:40
发布于 2026-11-06 16:53:40
370
举报

把一张 47 行的报销明细从 PDF 抄进财务系统,这件事我交给过两类 Agent 各做一遍。网页版走到第 9 步就断了——表格是 canvas 渲染的,DOM 里只有一层空 div,取不到任何单元格文本;桌面版从打开 PDF 到点完「提交」,14 步全部走完,代价是全程靠坐标点击,换台机器就得重标一遍。

这个对比不是要论证谁更强,而是想把「网页 Agent」和「桌面 Agent」的能力边界拆成可量化的三层,方便在选型时判断某类任务到底该交给谁。

三层能力,边界在第二层和第三层之间

Agent 操作一个界面,可用的通道只有三种,从稳到脆依次是:

层级

通道

稳定性

典型失效场景

可迁移性

L1 语义层

DOM / 无障碍树,按 role、label、text 定位

高,页面改版仍能命中

元素在 iframe 或 shadow DOM 里;虚拟列表未渲染

跨机器直接可用

L2 接口层

直接调后端 API,绕开界面

最高,但需要鉴权

签名参数、CSRF token、风控校验

需要拿到凭据

L3 像素层

截屏 + 坐标点击 + OCR 回读

低,但覆盖面最广

DPI 缩放、窗口位置漂移、远程会话锁屏

几乎不可迁移

网页 Agent 的默认通道是 L1,能力强一点的会补上 L2。桌面 Agent 天生只有 L3,因为屏幕上的像素对进程来说没有语义。

那次报销单任务卡住的原因很具体:财务系统用了一个基于 canvas 的表格组件,滚动时只重绘可视区域。DOM 树里 47 行数据对应 0 个可读文本节点,document.querySelectorAll('td') 返回空数组。这时候 L1 完全失效,L2 又拿不到登录态之外的接口签名,只能降级到 L3。

把「能不能做」变成一个可计算的分数

选型时最有用的不是定性描述,而是给每个步骤打分。我后来写了个探测函数,对目标页面的每一步判断可用的最高层级:

代码语言:python
复制
def anchor_score(el):
    """返回该元素可用的最高定位层级,数字越小越稳。"""
    if el.get_attribute("data-testid") or el.get_attribute("name"):
        return 1, "稳定属性"
    if el.inner_text().strip() or el.get_attribute("aria-label"):
        return 1, "可见文本"
    if el.tag_name in ("input", "textarea") and not el.is_visible():
        return 9, "隐藏域,需先触发渲染"
    box = el.bounding_box()
    if box and box["width"] > 4 and box["height"] > 4:
        return 3, f"仅坐标 {box['x']:.0f},{box['y']:.0f}"
    return 9, "无可定位锚点"

跑完 47 行录入,结果是:31 步落在 L1,5 步落在 L2(可以直接构造请求写入),11 步落在 L3。也就是说,纯网页方案的理论上限是 36/47,剩下 11 步必须靠像素级点击补。这 11 步集中在三类控件上——canvas 表格、富文本编辑器、日期选择器。

反过来说,如果一个任务里 L3 步骤占比低于 20%,网页 Agent 的总体成功率会明显高于桌面 Agent,因为 L1 定位不怕分辨率、不怕窗口遮挡、也不怕你中途把鼠标拿走。

桌面端的真实代价不是「不准」,是不稳定

桌面 Agent 的失败很少是「点错」,更多是「点空」。我第一次做这个流程时,按截图里的坐标硬编码了一套点击序列,本机跑得通,换到一台 125% 缩放的机器上,所有 y 坐标累计偏移了 60 多像素,点「保存」点到了「取消」上,一批数据白填。

后来改成每次动作前重新截屏、用 OCR 回读按钮文字再反算坐标,偏移问题解决了,但引入了新的不稳定源:

  • 窗口被其他程序遮挡时,截到的是遮挡物的画面,坐标反算全错;
  • 远程桌面断开后会话锁屏,点击事件发出去但没有接收方,脚本却返回成功;
  • 页面加载慢时截图早于渲染完成,OCR 读到的是骨架屏。

这三条里第二条最阴险,因为它不报错。我当时的处理是每步之后校验页面上出现预期文本,超时就整体回滚重跑,代价是单次任务耗时从 40 秒涨到 90 秒左右。

选型时我用的判据

任务特征

建议通道

理由

目标站点有稳定 testid 或语义化标签

网页

L1 命中率高,改版容忍度好

目标是 canvas / 自绘控件 / 桌面客户端

桌面

没有别的路

单次步骤 > 30 且需要跨系统

桌面为主 + 关键步骤人工确认

L3 步骤越多,累积成功率下降越快

需要定时无人值守

网页优先,或走 L2 接口

桌面方案受锁屏、遮挡影响太大

需要读本地文件、操作 Excel、批量重命名

桌面

网页沙箱没有文件系统权限

累积成功率的算法很朴素:单步成功率 0.97,14 步串行就是 0.97^14 ≈ 65%。这也是为什么跨系统长链路必须设计检查点和人工兜底,而不是指望模型一次跑完。

现在我的做法

日常任务里,能用 L1 就不用 L3。能在同一次会话里把网页端和桌面端接起来的,就按步骤分配——网页端负责取数、填表、抓结果,遇到 canvas 或本地文件再把控制权交给桌面端。

这条路子在 PRIVO 上省了不少事:它在同一个工作台里既开网页窗口又接管本机桌面,报销单这种一半网页一半本地文件的活,不用我手动在两个工具之间倒腾中间结果。不过它的坐标点击同样受缩放影响,第一次用时我忘了改系统缩放,前两步就偏了。

回到最初的问题:不要问「网页 Agent 和桌面 Agent 哪个强」,要问「这个任务里有多少步只能靠像素解决」。低于 20%,选网页;高于 50%,别犹豫,选桌面,并且给它配检查点。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 三层能力,边界在第二层和第三层之间
  • 把「能不能做」变成一个可计算的分数
  • 桌面端的真实代价不是「不准」,是不稳定
  • 选型时我用的判据
  • 现在我的做法
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档