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

文章背景：最近在使用codex app的时候，让它访问网页，有时候会出错，为此彻底了解一下AI访问Web的底层实现。

希望对你有所帮助，少走一些弯路。

很多人第一次用 ChatGPT、Codex、Claude Code 这类工具时，都会有一个很自然的感觉：

它们好像"会自己上网"。

你给它一个链接，它能总结网页；你让它查资料，它能给你结果；你让它操作一个页面，它甚至能点击按钮、填写表单、下载文件。

于是很容易产生一个判断：

这些 AI 应用底层是不是就是一套更高级的爬虫？

这个理解有一半是对的。

更准确地说，AI 访问网页不是一种技术，而是一整套分层体系。从最传统的搜索检索、HTTP 抓取，到浏览器自动化、内置浏览器、Chrome 插件，再到现在的 Computer Use，它们解决的问题不一样，拿到信息的方式不一样，面对反爬和登录态时的表现也完全不同。

这篇文章就把这件事讲清楚。

目录

1. LLM 本身不会上网
2. Search Retrieval：搜索检索
3. HTTP Fetch：程序化抓取
4. Browser Automation：浏览器自动化
5. In-App Browser：内置浏览器
6. Chrome Extension：浏览器插件
7. Computer Use：GUI Agent
8. 6 种方式对照表
9. 为什么反爬越来越难简单判断？
10. 真正的趋势：从爬互联网到接管工作环境
11. 最后怎么理解这件事？

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")

或者：

curl https://example.com

AI Agent 可以通过工具发起 HTTP 请求，拿到 HTML、JSON、RSS 或 API 返回值，然后再交给模型阅读。

流程是：

LLM
↓
HTTP 工具
↓
GET / POST 请求
↓
HTML / JSON / XML
↓
LLM 解析内容

这一层就是你直觉里说的"AI 驱动的爬虫"。

它解决什么问题？

HTTP Fetch 非常适合结构清晰、无需复杂交互的网站。

比如：

• 文档站
• 博客
• 新闻页
• RSS
• 开放 API
• 返回 JSON 的接口

它的优点也很工程化。

实现简单，速度快，成本低，可批量处理，也方便做自动化任务。

对于很多内容抓取任务，这一层已经够用了。

它的局限是什么？

最大问题是：现代网页很多已经不是传统网页了。

很多页面打开后，初始 HTML 可能只有一个壳：

<div id="root"></div>

真正内容要等浏览器执行 JavaScript 后，前端框架再动态生成。

这时单纯 HTTP 请求拿到的不是页面内容，而是一个空壳。

第二个问题是反爬。

网站可能检测：

• IP 地址
• 请求频率
• User-Agent
• Header
• Cookie
• TLS 指纹
• 请求行为是否像真人

第三个问题是登录态。

HTTP 工具当然可以带 Cookie，但真实系统里的登录状态、验证码、二次验证、风控跳转、前端状态管理，往往不是简单复制一段 Cookie 就能稳定解决的。

所以 HTTP Fetch 很快，但它更适合"内容直接暴露在网络请求里"的场景。

Browser Automation：浏览器自动化

当 HTTP 抓取不够用时，就进入浏览器自动化阶段。

典型技术包括：

• Playwright
• CloakBrowser

这一层的核心变化是：

不再只是请求网页，而是控制一个真实浏览器。

它可以：

• 打开页面
• 等待 JavaScript 加载
• 点击按钮
• 输入文字
• 滚动页面
• 上传文件
• 读取渲染后的 DOM

流程大概是：

LLM 规划任务
↓
自动化工具启动浏览器
↓
浏览器加载网页并执行 JS
↓
工具点击、输入、等待、读取 DOM
↓
结果返回给 LLM

它解决什么问题？

它解决的是现代网页的动态渲染问题。

对于 React、Vue、Next.js 这类前端应用，HTTP 请求可能拿不到正文，但浏览器可以真正运行页面。

所以浏览器自动化适合：

• 需要执行 JS 的网站
• 需要点击后才展示内容的页面
• 需要登录后才能访问的系统
• 需要完成表单、翻页、筛选、下载的任务

这也是很多 Agent 能"操作网站"的基础能力。

它的局限是什么？

第一，成本高。

启动完整浏览器比发一个 HTTP 请求重太多。

第二，速度慢。

页面加载、等待动画、点击、滚动都需要时间。

第三，稳定性一般。

网页结构一变，selector 可能就失效。今天按钮叫 .submit-btn，明天改成另一个类名，脚本就可能挂。

第四，它很容易被现代反爬盯上。

很多网站重点检测的就是：

• webdriver
• headless browser
• 自动化浏览器指纹
• 过于规律的点击和输入行为

所以 Browser Automation 很强，但它仍然像一个"外部操作者"，需要小心处理风控和页面变化。

In-App Browser：内置浏览器

再往前一步，就是很多 AI 应用正在采用的内置浏览器能力。

比如某些桌面 AI 应用里自带一个浏览器视图，或者让 AI 直接读取当前应用里的网页状态。

这一层和传统 Browser Automation 最大的区别是：

传统自动化：AI 自己启动一个浏览器
内置浏览器：AI 和用户共享同一个应用里的浏览器上下文

这就很关键了。

因为网页本来就是用户打开的，里面天然有：

• 登录态
• Cookie
• Session
• LocalStorage
• 当前页面状态
• 用户已经授权过的上下文

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 信息
• 页面 URL
• LocalStorage
• 某些网络请求
• 页面内可注入脚本的上下文

这就是为什么很多 AI 浏览器助手、网页总结插件、网页自动化插件都选择 Chrome Extension。

它解决什么问题？

它解决的是"真实用户浏览器环境接入"的问题。

网站看到的是你的真实浏览器、真实 IP、真实登录态、真实 Cookie。

AI 工具则通过插件权限获得页面信息，并执行一定范围内的操作。

对很多网站来说，这已经不是传统爬虫访问了。

它的优势是什么？

第一，登录态天然存在。

你已经登录的网站，插件在授权范围内就可以读取或辅助操作。

第二，页面理解更直接。

它可以读 DOM，而不是 OCR 截图。

第三，和用户工作流更近。

比如你正在浏览一个网页，插件可以直接总结、提取、翻译、填表，而不需要你把链接复制给另一个工具。

它的局限是什么？

核心问题还是权限和安全。

插件权限太大，用户会担心隐私；权限太小，又做不了复杂任务。

另外，浏览器插件仍然主要适合网页环境。遇到原生 App、远程桌面、虚拟机、特殊客户端，它就不一定有办法了。

Computer Use：GUI Agent

最后就是现在很热门的 Computer Use。

这一层的思路和前面完全不同。

前面几层，无论是 HTTP、浏览器自动化、内置浏览器还是插件，本质上大多还在处理：

HTML / DOM / Browser API

而 Computer Use 处理的是：

屏幕

它的核心循环是：

截图
↓
视觉模型理解界面
↓
决定下一步操作
↓
移动鼠标、点击、输入键盘
↓
再次截图
↓
继续推理

这更像一个真正坐在电脑前的人。

它解决什么问题？

它解决的是"没有 DOM 的世界"。

比如：

• 原生桌面 App
• Electron 应用
• 远程桌面
• Citrix
• 虚拟机
• 某些只能靠界面操作的系统

这些地方没有标准网页 DOM，浏览器插件也帮不上忙。

Computer Use 可以通过屏幕理解和鼠标键盘操作继续完成任务。

它的优点是什么？

最大优点是通用。

只要人能在屏幕上看懂并操作，理论上它就有机会操作。

它不依赖页面结构，也不依赖网站是否暴露 API。

这也是它被认为很重要的原因。

它的局限是什么？

第一，非常慢。

人看一眼页面就知道点哪里，但 AI 要截图、识别、推理、行动、再截图。

第二，成本高。

视觉理解比读取 DOM 贵得多。

第三，容易误操作。

按钮位置、弹窗、遮挡、滚动状态、分辨率变化，都可能影响判断。

第四，稳定性不如结构化接口。

如果能用 API 或 DOM，通常不应该优先用 Computer Use。它更适合处理那些没有更好接口的场景。

6 种方式对照表

阶段	本质	获取信息方式	操作方式	适合场景
Search Retrieval	搜索检索	搜索索引、缓存正文	基本不操作网页	公开资料查询
HTTP Fetch	程序化请求	HTML、JSON、RSS、API	HTTP 请求	文档、博客、接口数据
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 的关键。