上周二，你的 computer-use 智能体表现出色。它登录了供应商门户，点击了五层嵌套菜单，导出了报告，将其附加到工单中，并在不到两分钟内完成了任务。你保存了轨迹。你赞美了模型。你发布了工作流。然而，在那个成功的轨迹中，智能体记住了一个信息：“导出 CSV”操作位于 div.toolbar > div:nth-child(2) > button.btn-secondary:nth-child(4)。
到了周五，供应商推送了重新设计。工具栏现在是一个 flex 容器，次要按钮被放进了下拉菜单，而“导出”这个动作被一个下载图标取代了。你智能体记下的路径现在指向空——或者更糟，它指向了一个现在显示为“删除账户”的按钮。智能体无法分辨其中的区别。两者都是按钮。两者都在同一个选择器位置。周二留下的轨迹不再是记忆，而是一颗地雷。
一个计算机使用智能体拍摄了一张截图，对其进行推理，决定点击像素点 (840, 612) 处的“确认”按钮，并发送了点击指令。当光标落下时，一个弹窗出现了。三秒钟前还是“确认”的像素点，现在变成了“删除”。该智能体完全按照计划执行了操作。但它的计划是针对一个已不再存在的屏幕制定的。
这不是定位（grounding）错误。模型正确识别了按钮。这也不是推理错误，计划本身是合理的。这是一个时序错误（timing error）——这是 GUI 自动化中监测最不足的失败类别——而你的测试套件几乎肯定没有覆盖它，因为你的测试环境在观察和行动之间从未发生过变化。
一个令人不安的测量结果：最近一项针对真实 Ubuntu 工作负载下的桌面智能体的研究发现，从智能体观察屏幕到基于该观察采取行动之间，平均存在 6.51 秒 的间隔。对于 UI 来说，6.5 秒是漫长的永恒。通知会弹出，懒加载列表完成加载，动画趋于稳定，焦点发生转移。智能体对屏幕的心理模型是有保质期的，但几乎没有智能体框架会这样对待它。
一个计算机使用型智能体（computer-use agent）在客户的 CRM 上完成了一项任务，工作线程池将浏览器返回到空闲环中，几百毫秒后下一个请求到达，仪表板导航成功——唯一的问题是，它是作为错误的用户登录成功的。前一个会话的 OAuth cookie 仍留在配置文件（profile）中。追踪记录显示 navigation succeeded（导航成功）、screenshot captured（截图已捕获）、action performed（操作已执行）。运行日志中没有任何内容表明，智能体正在以一个从未授权过它的用户身份进行操作。
这是浏览器智能体从其构建所用的库中悄然继承的一类故障。无头浏览器（headless browser）框架被设计为每个配置文件仅供一个用户使用，因为这是浏览器三十年来的工作方式。当工作池为了摊销全新的 Chromium 实例长达八秒的冷启动时间而重用配置文件时，这种“单用户”假设就破裂了，而且这种破裂对于团队通常信任的每一层遥测数据来说都是不可见的。
一个日历日期选择器让一个生产环境浏览器 Agent 连续失效三天，无人察觉。设计师在一次小型 UI 改版中，将原生 <input type="date"> 替换为自定义 React 组件。没有 API 变化，没有内容移动，只是新布局中 24px 的单元格——而此前一直可靠点击正确日期的视觉模型，现在偏移了一格，悄悄地把预约订在了错误的日期。
这就是 DOM 脆弱性税：在从未为机器操作而设计的 Web 之上构建自动化 Agent，所持续付出的运营成本。与大多数基础设施税不同，它会复利累积。Web 在变化，反爬虫防御在进化，SPA 越来越动态，而你的 Agent 在悄然退化。
大多数 AI agent 通过结构化 API 与世界交互 —— 干净的 JSON 输入，干净的 JSON 输出。但有一类日益增多的 agent 完全抛弃了这种约定。计算机使用 (Computer use) agent 查看截图，对所见内容进行推理，并像人类操作员一样操作鼠标和键盘。当唯一的集成界面是屏幕时，像素就变成了 API。
这听起来像是个花招，直到你意识到有多少企业软件根本没有 API。遗留的 ERP 系统、内部管理面板、专有的桌面应用程序 —— GUI 是唯一的接口。多年来，机器人流程自动化 (RPA) 通过脆弱的、基于选择器 (selector) 的脚本来处理这些问题，只要按钮移动了三个像素，脚本就会失效。计算机使用 agent 承诺了一些不同的东西：像人类一样适应 UI 变化的视觉理解能力。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
