AI 编码工具遭遇浏览器自动化难题:特定页面截图与 DOM 读取频现超时

近日,有开发者在技术社区反馈,在使用集成 @browser 和 @Chrome 功能的 AI 编码工具(类似 Codex)时,遭遇了严重的浏览器自动化故障。根据详细的现象描述,该工具能够成功连接到本地 Chrome 浏览器并列出标签页,也能正确读取目标页面(如“统一登陆页”)的标题,但在执行更深层次的页面级交互时彻底失效。具体故障表现包括:页面截图超时、DOM 读取超时、以及 Playwright 的 `locator(‘body’).count()` 和 `waitForLoadState()` 等基础操作全部超时。经过排查,开发者发现 `about:blank` 和本地 `localhost` 测试页均可正常交互,排除了浏览器工具整体损坏的可能性。问题的矛头指向了特定的网络环境或页面安全策略。日志显示,虽然 macOS 系统代理显示为空,但 Codex 进程环境中存在 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 等代理变量,且开发者曾发现 Chrome 扩展宿主进程指向了旧版本的缓存目录。尽管尝试清理旧进程并重启扩展,问题依然存在,这表明 AI 智能体在处理复杂网络代理配置或特定企业级登录页面时,存在底层驱动的稳定性缺陷。

事件分析

本次事件揭示了当前 AI 编程助手(AI Agent)在从“代码生成”迈向“浏览器自动化控制”过程中面临的环境适配挑战。AI 智能体虽然能理解意图并生成调用 Playwright 或 Selenium 的代码,但在面对复杂的真实网页环境——特别是涉及企业级登录页、重定向机制以及本地代理环境变量冲突时,执行链路极易断裂。开发者提到的系统代理为空但进程内存在代理变量的情况,凸显了 AI 工具的沙箱环境与宿主机网络配置之间的交互盲区。此外,浏览器扩展的版本管理与缓存残留问题也反映出,要将 AI 无缝集成到开发者的陈旧或复杂的本地工作流中,仍需解决大量工程化细节。这并非单一工具的 Bug,而是整个 AI 编程领域在实现端到端自动化时必须克服的“最后一公里”稳定性难题。

💡 核心观点:AI 智能体在迈向浏览器自动化控制时,环境兼容性与网络代理处理已成为制约其落地稳定性的关键瓶颈。

原文链接:V2EX 分享发现

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

抢沙发

评论前必须登录!

立即登录   注册