API 发现
Agent 如何通过网络检查发现内部 API，以实现 100 倍更快的数据提取
Agent 通过网络检查发现内部 API，从而实现 100 倍更快的数据提取
这是最强大的浏览器模式之一。Agent 不是一个一个地点击网页 UI，而是检查页面在后台调用了哪些 API，然后直接调用这些 API —— 通常可以实现 100 倍更快 的数据提取。
核心思想#
现代 Web 应用是通过单页应用（SPA）构建的，它们与后端 API 通信。当你在 Web UI 中点击员工、工单或订单列表时，页面实际上是在幕后发起 fetch() 或 XHR 请求到内部 API 端点。Agent 可以观察这些网络请求，识别 API 模式，然后直接调用那些端点 —— 完全绕过缓慢的 UI。
你不需要明确地要求这个功能。当 Agent 注意到自己在一个接一个地点击许多类似项目时，它通常会自动切换到这个方式。
为什么这很重要#
| 通过 UI 点击 | 直接调用 API | |
|---|---|---|
| 每项速度 | 5–10 秒 | 约 100 毫秒 |
| 并行处理 | 一个接一个 | 所有项目同时 |
| 数据格式 | 从页面抓取的文本 | 结构化的 JSON 或 XML |
| 可靠性 | UI 变化就会失效 | 稳定的 API 合约 |
| 认证 | 已经登录 | 复用浏览器会话 |
对于“获取 25 名员工的病假数据”这样的任务，这意味着从~4 分钟的点击时间瞬间缩减到~2 秒的并行 API 调用。
它是如何工作的#
浏览并交互一次#
Agent 加载 Web 应用，并正常点击一个项目 —— 只是足够让页面发起其 API 调用。
检查网络流量#
通过网络检查，Agent 看到页面发出的所有 HTTP 请求。它寻找返回结构化数据的 REST 或 GraphQL 端点。
GET /api/v1/employees/132/time-off?end=2026-12-31 → 200 (JSON, 1.2KB)
GET /api/v1/employees/132?fields=department,jobTitle → 200 (JSON, 0.4KB)
识别 API 模式#
Agent 识别出 URL 模式 — /api/v1/employees/{id}/time-off — 并理解如何为任意员工构建请求。
先用单个调用测试#
在大规模操作之前，Agent 会在浏览器内发起一次直接 API 调用以验证其可用性：
fetch('/api/v1/employees/132/time-off?end=2026-12-31', { credentials: 'include' })
credentials: 'include' 选项复用了浏览器的会话 Cookie —— 无需额外认证。
并行请求所有项目#
确认后，Agent 会同时请求所有项目的数据：
Promise.all(employees.map(emp =>
fetch(`/api/v1/employees/${emp.id}/time-off?end=2026-12-31`,
{ credentials: 'include' })
.then(r => r.json())
.then(data => ({ name: emp.name, sickDays: data.sickDaysUsed }))
))
25 个请求同时发出，并在 1–2 秒内完成。
收集并格式化结果#
Agent 获取结构化结果并按需格式化 —— 比如表格、电子表格、摘要或原始数据等。
实际示例#
以下是使用该模式的任务：
“进入我们的 HR 门户，对所有员工点击查看，获取他们过去 12 个月的病假天数，并导出为电子表格。”
没有 API 发现： Agent 逐个点击 25 名员工，依次进入个人资料，找到病假部分，读取数字。约 4 分钟。使用 API 发现： Agent 点击第一名员工，发现页面调用了 /api/v1/employees/132/time-off/calculator，而后发现员工目录端点，并并行获取所有 25 名员工的数据。约 2 秒，并额外返回包含部门和职位的数据。最终结果是一个完整的电子表格，列包括员工姓名、部门、职位、2025 年病假天数以及 2026 年截至目前的病假天数 —— 所有这些在 UI 中需要点击多个标签页才能获取。
核心技巧#
| 技巧 | 原因 |
|---|---|
credentials: 'include' | 复用浏览器的会话 Cookie —— 无需额外认证 |
Promise.all() | 同时发出所有请求，实现巨大的速度提升 |
将结果存入 window.__ 变量 | 将异步 fetch 结果桥接回 Agent 以便检索 |
对 XML 响应使用 DOMParser | 某些内部 API 返回的是 XML 而非 JSON |
| 对大型数据集分批请求 | 避免在请求 50+ 项目时压垮服务器 |
关于认证#
由于 Agent 在浏览器页面上下文中运行 JavaScript，它继承了浏览器的 Cookie 和会话。如果你已经登录了 Web 应用，通过 fetch() 发出的 API 调用就会自动通过认证 —— 无需令牌或 API 密钥。
支持 GraphQL 吗？#
支持。GraphQL 应用通常只使用一个 /graphql 端点。Agent 需要检查网络流量以查看查询结构，然后使用正确的查询体和变量去复现。相同的 credentials: 'include' 模式也适用。
关于速率限制#
如果你需要获取数百个项目的数据，Agent 会将请求分成批次（例如每批 20–50 个）并在批次之间加入短暂延迟，以避免压垮服务器或触发速率限制。
若 API 返回 XML 呢？#
某些企业应用（如 BambooHR、SAP 等）返回 XML 而非 JSON。Agent 会使用浏览器内置的 DOMParser 来解析 XML，并通过 querySelector 和 getAttribute 提取值。
我可以要求 Agent 使用这种模式吗？#
当然。如果你知道某项任务涉及重复性数据提取，可以直接提示 Agent：“检查网络流量以找到 API 端点，并使用它而不是点击 UI。”Agent 将优先采用 API 发现方式。
CORS 限制怎么办？#
不成问题。由于 JavaScript 是在页面自己的上下文中运行（通过 browser_evaluate），所有请求都是同源的。无需担心跨域限制。