AI 到底是怎么访问网页的？从爬虫、Browser Agent 到 Computer Use

文章背景最近在使用codex app的时候让它访问网页有时候会出错为此彻底了解一下AI访问Web的底层实现。希望对你有所帮助少走一些弯路。很多人第一次用 ChatGPT、Codex、Claude Code 这类工具时都会有一个很自然的感觉它们好像“会自己上网”。你给它一个链接它能总结网页你让它查资料它能给你结果你让它操作一个页面它甚至能点击按钮、填写表单、下载文件。于是很容易产生一个判断这些 AI 应用底层是不是就是一套更高级的爬虫这个理解有一半是对的。更准确地说AI 访问网页不是一种技术而是一整套分层体系。从最传统的搜索检索、HTTP 抓取到浏览器自动化、内置浏览器、Chrome 插件再到现在的 Computer Use它们解决的问题不一样拿到信息的方式不一样面对反爬和登录态时的表现也完全不同。这篇文章就把这件事讲清楚。目录LLM 本身不会上网Search Retrieval搜索检索HTTP Fetch程序化抓取Browser Automation浏览器自动化In-App Browser内置浏览器Chrome Extension浏览器插件Computer UseGUI Agent6 种方式对照表为什么反爬越来越难简单判断真正的趋势从爬互联网到接管工作环境最后怎么理解这件事LLM 本身不会上网无论是 GPT、Claude还是其他大语言模型本质上都不是浏览器也不是网络程序。模型本身不会发 HTTP 请求执行 JavaScript打开网页点击按钮读取你的浏览器 Cookie它真正擅长的是根据输入的上下文生成下一步该说什么、该调用什么工具、该怎么理解返回结果。所以所谓“AI 会访问网页”本质上是LLM 外部工具也就是用户提出需求 ↓ LLM 判断需要访问网页 ↓ 调用搜索、HTTP、浏览器、插件或电脑控制工具 ↓ 工具返回网页内容或操作结果 ↓ LLM 总结、分析、继续下一步这也是 Agent 的核心模型不是直接做所有事情而是学会调度工具。下面我们按技术演进顺序拆开看。Search Retrieval搜索检索这是很多 AI 搜索产品最常见的路径。比如你问一个问题AI 返回一堆带引用来源的回答。很多时候它并不是实时打开每一个网页而是先调用搜索系统。它的流程大概是用户问题 ↓ 搜索引擎或检索系统 ↓ 已有网页索引、摘要、缓存正文 ↓ LLM 阅读并总结这一层的本质不是“浏览网页”而是“检索已经被搜索系统处理过的网页”。它解决什么问题Search Retrieval 适合解决公开信息查询。比如查某个产品的官方文档找新闻、博客、论文、论坛内容对多个公开来源做总结快速获得带出处的答案它的优势很明显。第一速度快。因为很多内容已经被搜索引擎提前爬取、索引和缓存。第二成本低。不需要启动浏览器也不需要真的渲染页面。第三相对稳定。搜索引擎已经帮你处理了大量网页结构差异。第四不太容易触发普通网站反爬。很多网站本来就允许 Googlebot、Bingbot 这类搜索爬虫访问。它的局限是什么问题也很明显。它只能处理“能被索引”的内容。如果一个页面没有被搜索引擎收录或者内容藏在登录后页面、企业后台、私有文档里这一层基本就无能为力。另外搜索索引有延迟。你今天刚改的页面搜索系统不一定马上知道。还有一种常见情况是现代网站大量使用 JavaScript 动态渲染搜索索引拿到的内容可能不完整。所以 Search Retrieval 更像是 AI 的“公共资料库入口”不是万能浏览器。HTTP Fetch程序化抓取再往下一层就是传统意义上的爬虫。比如requests.get(https://example.com)或者curlhttps://example.comAI Agent 可以通过工具发起 HTTP 请求拿到 HTML、JSON、RSS 或 API 返回值然后再交给模型阅读。流程是LLM ↓ HTTP 工具 ↓ GET / POST 请求 ↓ HTML / JSON / XML ↓ LLM 解析内容这一层就是你直觉里说的“AI 驱动的爬虫”。它解决什么问题HTTP Fetch 非常适合结构清晰、无需复杂交互的网站。比如文档站博客新闻页RSS开放 API返回 JSON 的接口它的优点也很工程化。实现简单速度快成本低可批量处理也方便做自动化任务。对于很多内容抓取任务这一层已经够用了。它的局限是什么最大问题是现代网页很多已经不是传统网页了。很多页面打开后初始 HTML 可能只有一个壳dividroot/div真正内容要等浏览器执行 JavaScript 后前端框架再动态生成。这时单纯 HTTP 请求拿到的不是页面内容而是一个空壳。第二个问题是反爬。网站可能检测IP 地址请求频率User-AgentHeaderCookieTLS 指纹请求行为是否像真人第三个问题是登录态。HTTP 工具当然可以带 Cookie但真实系统里的登录状态、验证码、二次验证、风控跳转、前端状态管理往往不是简单复制一段 Cookie 就能稳定解决的。所以 HTTP Fetch 很快但它更适合“内容直接暴露在网络请求里”的场景。Browser Automation浏览器自动化当 HTTP 抓取不够用时就进入浏览器自动化阶段。典型技术包括PlaywrightCloakBrowser这一层的核心变化是不再只是请求网页而是控制一个真实浏览器。它可以打开页面等待 JavaScript 加载点击按钮输入文字滚动页面上传文件读取渲染后的 DOM流程大概是LLM 规划任务 ↓ 自动化工具启动浏览器 ↓ 浏览器加载网页并执行 JS ↓ 工具点击、输入、等待、读取 DOM ↓ 结果返回给 LLM它解决什么问题它解决的是现代网页的动态渲染问题。对于 React、Vue、Next.js 这类前端应用HTTP 请求可能拿不到正文但浏览器可以真正运行页面。所以浏览器自动化适合需要执行 JS 的网站需要点击后才展示内容的页面需要登录后才能访问的系统需要完成表单、翻页、筛选、下载的任务这也是很多 Agent 能“操作网站”的基础能力。它的局限是什么第一成本高。启动完整浏览器比发一个 HTTP 请求重太多。第二速度慢。页面加载、等待动画、点击、滚动都需要时间。第三稳定性一般。网页结构一变selector 可能就失效。今天按钮叫.submit-btn明天改成另一个类名脚本就可能挂。第四它很容易被现代反爬盯上。很多网站重点检测的就是webdriverheadless browser自动化浏览器指纹过于规律的点击和输入行为所以 Browser Automation 很强但它仍然像一个“外部操作者”需要小心处理风控和页面变化。In-App Browser内置浏览器再往前一步就是很多 AI 应用正在采用的内置浏览器能力。比如某些桌面 AI 应用里自带一个浏览器视图或者让 AI 直接读取当前应用里的网页状态。这一层和传统 Browser Automation 最大的区别是传统自动化AI 自己启动一个浏览器 内置浏览器AI 和用户共享同一个应用里的浏览器上下文这就很关键了。因为网页本来就是用户打开的里面天然有登录态CookieSessionLocalStorage当前页面状态用户已经授权过的上下文AI 不一定需要重新登录也不一定需要绕过一堆风控。它解决什么问题它解决的是“用户上下文”问题。很多时候AI 不是不知道怎么抓网页而是缺少你的身份。比如你登录后的 Notion 页面企业后台私有文档个人账户里的订单、数据、设置传统爬虫看不到这些内容因为它不是你。但 In-App Browser 里AI 操作的是用户当前环境它更接近“帮你看你已经打开的页面”。它和截图识别不一样这里要注意一个细节。In-App Browser 通常不是靠截图猜按钮在哪而是可以读取 DOM、页面结构、选中文本、当前 URL甚至通过浏览器 API 操作元素。也就是说它更像DOM-Level Agent而不是纯视觉 Agent。它知道“这个元素是按钮”也知道“这段文字在哪个 DOM 节点里”。它的局限是什么第一权限边界更复杂。AI 能不能读当前页面能不能操作能不能访问 Cookie这些都涉及隐私、安全和产品设计。第二它不是绝对绕过反爬。网站仍然可能检测异常脚本、插件行为、自动化节奏或特殊 API 调用。更准确的说法是In-App Browser 不再容易被传统爬虫检测识别但不代表完全不可检测。Chrome Extension浏览器插件Chrome Extension 是另一条很重要的路线。它的本质是AI 不再模拟浏览器而是成为浏览器的一部分。浏览器插件可以根据权限读取当前页面 DOM用户选中的文本当前 Tab 信息页面 URLLocalStorage某些网络请求页面内可注入脚本的上下文这就是为什么很多 AI 浏览器助手、网页总结插件、网页自动化插件都选择 Chrome Extension。它解决什么问题它解决的是“真实用户浏览器环境接入”的问题。网站看到的是你的真实浏览器、真实 IP、真实登录态、真实 Cookie。AI 工具则通过插件权限获得页面信息并执行一定范围内的操作。对很多网站来说这已经不是传统爬虫访问了。它的优势是什么第一登录态天然存在。你已经登录的网站插件在授权范围内就可以读取或辅助操作。第二页面理解更直接。它可以读 DOM而不是 OCR 截图。第三和用户工作流更近。比如你正在浏览一个网页插件可以直接总结、提取、翻译、填表而不需要你把链接复制给另一个工具。它的局限是什么核心问题还是权限和安全。插件权限太大用户会担心隐私权限太小又做不了复杂任务。另外浏览器插件仍然主要适合网页环境。遇到原生 App、远程桌面、虚拟机、特殊客户端它就不一定有办法了。Computer UseGUI Agent最后就是现在很热门的 Computer Use。这一层的思路和前面完全不同。前面几层无论是 HTTP、浏览器自动化、内置浏览器还是插件本质上大多还在处理HTML / DOM / Browser API而 Computer Use 处理的是屏幕它的核心循环是截图 ↓ 视觉模型理解界面 ↓ 决定下一步操作 ↓ 移动鼠标、点击、输入键盘 ↓ 再次截图 ↓ 继续推理这更像一个真正坐在电脑前的人。它解决什么问题它解决的是“没有 DOM 的世界”。比如原生桌面 AppElectron 应用远程桌面Citrix虚拟机某些只能靠界面操作的系统这些地方没有标准网页 DOM浏览器插件也帮不上忙。Computer Use 可以通过屏幕理解和鼠标键盘操作继续完成任务。它的优点是什么最大优点是通用。只要人能在屏幕上看懂并操作理论上它就有机会操作。它不依赖页面结构也不依赖网站是否暴露 API。这也是它被认为很重要的原因。它的局限是什么第一非常慢。人看一眼页面就知道点哪里但 AI 要截图、识别、推理、行动、再截图。第二成本高。视觉理解比读取 DOM 贵得多。第三容易误操作。按钮位置、弹窗、遮挡、滚动状态、分辨率变化都可能影响判断。第四稳定性不如结构化接口。如果能用 API 或 DOM通常不应该优先用 Computer Use。它更适合处理那些没有更好接口的场景。6 种方式对照表阶段本质获取信息方式操作方式适合场景Search Retrieval搜索检索搜索索引、缓存正文基本不操作网页公开资料查询HTTP Fetch程序化请求HTML、JSON、RSS、APIHTTP 请求文档、博客、接口数据Browser Automation控制浏览器渲染后 DOM点击、输入、滚动、等待JS 网站、复杂交互In-App Browser共享浏览器上下文DOM、当前页面状态浏览器 API 操作用户已登录页面Chrome Extension浏览器插件能力DOM、Tab、部分浏览器数据插件注入与 API 操作网页助手、当前页面处理Computer Use图形界面 Agent截图、OCR、视觉元素鼠标键盘原生 App、远程桌面、无 DOM 系统为什么反爬越来越难简单判断早期反爬主要防 HTTP 爬虫。比如你请求太快、Header 不像浏览器、Cookie 不对、IP 异常网站就能识别你。后来浏览器自动化出现后网站开始检测 headless browser、webdriver、浏览器指纹和自动化行为。但现在情况变复杂了。因为 AI Agent 越来越多地进入用户自己的浏览器环境In-App Browser 用的可能是用户已经打开的页面Chrome Extension 直接运行在用户浏览器里Computer Use 甚至通过真实鼠标键盘操作界面这时网站看到的可能不再是一个传统爬虫而是一个真实用户环境里的自动化助手。所以“AI 会不会被反爬拦住”不能一概而论要看它到底用的是哪一层技术。如果是 HTTP Fetch很容易被拦。如果是 Browser Automation也可能被检测。如果是用户侧浏览器插件或内置浏览器传统反爬会弱很多但仍然存在权限、安全和行为检测问题。如果是 Computer Use它甚至不一定通过网页接口操作而是直接看屏幕、点鼠标。真正的趋势从爬互联网到接管工作环境这件事最有意思的地方不是“AI 爬虫越来越强”。真正的趋势是AI 正在从访问互联网走向进入用户的工作环境。过去我们以为 AI 要解决的是怎么抓到网页内容现在更关键的问题变成了AI 如何在用户授权下理解并操作用户已经拥有权限的环境这就是 Browser Agent、Chrome Extension、Computer Use 快速发展的原因。用户环境里天然有登录态权限本地文件浏览器上下文企业系统访问能力真实工作流AI 只要能安全地接入这些环境就不只是“总结网页”的工具而会变成真正的工作助手。最后怎么理解这件事如果用一句话总结LLM 本身不会上网真正让 AI 访问网页的是工具系统而这些工具正在从“抓网页内容”逐步演进到“操作用户环境”。所以以后看到某个 AI 工具说自己能访问网站不要只问“它是不是爬虫”更应该问它是搜索检索还是实时抓取它拿的是 HTML还是渲染后的 DOM它有没有登录态它是在自己的浏览器里操作还是在用户浏览器里操作它是读 DOM还是看截图它的权限边界在哪里把这些问题分清楚你就能看懂大部分 AI Agent 产品底层到底在做什么。也能更清楚地判断什么时候该用搜索什么时候该用爬虫什么时候该用浏览器自动化什么时候才真的需要 Computer Use。这才是理解 AI Agent 的关键。