News Hacker|极客洞察

265 5 小时前 reflex.dev
🤨computer use 比结构化 API 贵45倍,a11y 与 legacy 场景成焦点
既然有 API,为什么还要花 45 倍的钱点鼠标?

🎯 讨论背景

这篇文章比较的是两种让模型操作软件的路线:一种是 vision-based computer use(通过截图、鼠标和键盘直接操控界面),另一种是 structured APIs(结构化接口)或可编程工作流。评论里提到的 benchmark 显示,前者在同一任务上大约慢到 17 分钟,而后者只要 0.5 到 2.8 秒,差距主要来自反复截图、等待界面状态和靠视觉猜测位置。很多人把话题延伸到 browser-use、Claude、Codex、Playwright(Web 端到端测试框架)和 macOS accessibility API(辅助功能接口),因为这些工具代表了把 UI 变成机器可用层的不同办法。讨论真正争的不是“AI 能不能点按钮”,而是当应用没有公开 API、或者遗留系统太多时,究竟该用哪一层把人类界面转成可复用的程序接口。

📌 讨论焦点

结构化 API / CLI 明显更快更稳

很多人觉得这个结论并不意外:给模型看截图、让它靠鼠标键盘试错,本来就比直接调用结构化 API 更慢、更贵。评论里反复提到,真正能落地的方案通常是严格 JSON schema、CLI、或把浏览器访问包装成可编程流程,而不是让模型每次从零摸索界面。有人用 17 分钟对比 0.5 到 2.8 秒的例子强调 wall-clock time 的差距,也有人说 computer use 更像“最后一公里”而不是首选。整体共识是:能走 API 就别走 vision agent,除非根本没有别的接口可用。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]

a11y / accessibility 可能被 agents 倒逼改善

另一条线认为,agent 时代可能会倒逼网站和应用把 accessibility 做好。有人指出,Playwright(Web 端到端测试框架)在配合 accessibility locators 时体验非常好,而像 invoke 这种基于 macOS accessibility API(辅助功能接口)的方案,本质上就是把结构化信息暴露给自动化层。也有人担心反方向的激励:开发者为了防 AI,可能故意做得更不 accessible,这会直接伤害屏幕阅读器用户和视障用户。支持者则强调,agents 对车祸式手部劳损、ADHD、临时状态不佳的人也有帮助,改善 a11y 并不只是为了机器。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

旧系统、无 API 和逆向工程仍是核心场景

不少评论把这件事落回现实:很多真正有价值的系统根本没有可用 API,或者 API 不开放、太老、太碎。大家举了酒店 PMS、医疗 EHR、Google Calendar widget、老式 SaaS 之类的例子,认为此时最实用的办法往往是逆向 traffic、从事件处理器生成接口,或者把 UI 流程录成可重复 workflow。围绕 webmcp、AppFunctions、Prism、reverse-api 工具的讨论也说明,问题不是“要不要 API”,而是“怎么从既有系统里榨出可复用的程序化层”。在这个语境下,computer use 的价值更多是补齐历史包袱,而不是创造新范式。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]

OS / 平台要不要为 agents 重构

有人进一步把问题上升到操作系统层:如果未来真是 agentic world,那么每个应用功能都该能被 API 化,同时仍然对人类友好。乐观派设想的是 headless 的 AI-first OS,人类反而成了第二级用户;悲观派则说这只是把整个软件栈推倒重来,像重设计纽约城或给自驾车重铺全世界道路一样不现实。评论里还提到 Wayland(Linux 现代显示协议)偏像素、DBus(Linux 进程间通信总线)和 Android AppFunctions(Android 的 AI 应用函数接口)这类现成积木,暗示真正可行的路更像渐进式加层,而不是从头再造。还有人直接把 OpenAI 做手机、重做平台的想法归为泡沫期的幻想。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15]

安全、权限与反制激励

安全和权限是另一条高频担忧,尤其是浏览器里的 PII、密码和敏感操作。有人提到厂商对 AI 访问浏览器已经有“lethal trifecta”式警告,也有人说 SecureTextField(安全文本输入字段)在 OS 层面能挡住部分泄漏,但这并不能解决 agent 乱点、乱填、乱买的责任归属问题。更尖锐的观点是,网站方会因为广告、锁定和反爬而故意让 AI 难用,甚至通过登录墙、captcha、暗黑模式来逼退 agent。于是讨论最后落到一个很现实的结论:机器可用性和平台利益往往天然冲突。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]

token / 运行成本与模型经济性争论

对“45 倍”这个数字本身,评论区也在争论它到底是结构性差距还是暂时性差距。有人认为数据中心建设完成后、推理优化继续推进,token 价格会下降;也有人反驳说,VC 补贴结束后价格未必更低,而且运行多个模型并行、图像和屏幕截图本身都很耗资源。还有人指出,开放模型和 OpenRouter(模型聚合调用服务)之类的替代方案已经足够便宜,至少能支撑一些不那么关键的任务。反方则补充说,除了 token 价,还有训练成本、电力和水资源成本,这些都不该从账本里消失。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]

agent 真正适合做什么

关于用途,评论呈现出很明显的分裂:支持者觉得它很适合那些你懒得手工做、或者容易卡在奇怪边角条件里的任务。例子包括本地调试、批量整理用户流程、补全一个网站的质量检查、以及在遗留 SaaS 上做背景操作;这些场景里,agent 作为“后台实习生”确实省时间。怀疑者则说,大家最想外包的往往是税务、背景调查、LLC 申请、购物和社交媒体,而这些恰恰是最敏感、最不能出错、也最容易被商业激励扭曲的任务。于是很多人对 agent 的定位仍然很保守:能辅助,但很难成为值得完全信任的代理人。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

📚 术语解释

a11y: accessibility 的常用缩写,指让屏幕阅读器和自动化工具更容易理解与操作界面。

Playwright: Web 端到端测试框架,可通过 accessibility locators 和脚本稳定驱动浏览器。

MCP: Model Context Protocol,把工具、数据源或动作以统一协议提供给模型的接口层。

DOM: 网页的结构树,结构化自动化通常直接利用它,而不是只看像素。

Wayland: Linux 现代显示协议,更偏向像素输出,天然语义信息较少。