我们如何优化深度智能体的浏览器使用

核心要点Key Takeaways

如今，浏览器代理能够承担多步骤任务，而这些任务对人来说既费力又耗时。Instinct 等个人代理和 Meta 的 Muse 可以规划跨国公路旅行、取消不再使用的订阅，以及发布汽车出售广告，而且这一切都能在没有公共 API 的网站上完成。仅在 9 月，DataDome 观察到代理式浏览器请求量就增长了 4.7 倍。Browser agents can now take on multi-step work that's painful and time-consuming for people. Personal agents like Instinct and Meta's Muse plan cross-country road trips, cancel unused subscriptions, and list cars for sale, all on sites with no public APIs. DataDome saw agentic browser requests jump 4.7x in September alone.

浏览器使用在两种场景中很有帮助：执行 API 无法涵盖的操作，例如使用未为该智能体配置的网站；以及对编码智能体构建的 Web 应用进行端到端测试。无论哪种情况，智能体都需要两样东西：Browser use helps in two places: actions an API can't cover, like using a website the agent wasn't set up for, and end-to-end testing of the web apps coding agents build. Either way, the agent needs two things:

1. 用于操作浏览器的工具：打开网页、阅读网页并与之交互。大多数工具集通过 Chrome DevTools Protocol (CDP) 控制浏览器；该协议允许工具检查和控制 Chrome。
   Tools to drive the browser: open pages, read them, and act on them. Most toolsets control the browser over the Chrome DevTools Protocol (CDP), the protocol that lets tools inspect and control Chrome.
2. 一个可供操控的浏览器，可在本地运行，也可由托管服务提供。Managed Deep Agents 让你无需运行任何基础设施，就能在 LangSmith 中构建和部署智能体；它也可以为你的智能体运行浏览器（详情请见我们的发布公告）。像 Browserbase 这样的托管浏览器服务提供商会替你处理开放网络中的棘手问题，例如 CAPTCHA 验证码、机器人拦截，以及大规模运行多个浏览器。
   A browser to drive, either local or hosted. Managed Deep Agents lets you build and deploy agents in LangSmith without running any infrastructure, and it can run the browser for your agent too (more in our launch post). A hosted browser provider like Browserbase handles the hard parts of the open web for you, like CAPTCHAs, bot blocking, and running many browsers at scale.

这篇文章重点介绍这些工具，以及如何让它们足够好用，使智能体能够熟练地使用浏览器。This post focuses on the tools, and on making them good enough that the agent uses the browser well.

我们着手为 Managed Deep Agents 中的智能体提供浏览器。我们比较了七种工具集，并选出了最佳方案：Browserbase 提供的 Stagehand（GitHub）。随后，我们根据智能体在 LangSmith 跟踪记录中的实际表现对它进行了改进，并通过评估验证了每一项改动。最大的收获是：通过工具设计，智能体还有很大的提升空间。We set out to give agents in Managed Deep Agents a browser. We compared seven toolsets and picked the best one, Stagehand (GitHub) from Browserbase. Then we improved it based on what agents did in LangSmith traces, and validated every change with evals. The biggest lesson was how much room there is to improve an agent through tool design.

使用浏览器会带来上下文管理方面的挑战。Browser use poses context management challenges

浏览器使用工具集有几种形式：原生工具、MCP 服务器，或由智能体在 shell 中运行的 CLI。浏览器使用给这些工具带来了两个独特的挑战：Browser use toolsets come in a few forms: native tools, an MCP server, or a CLI the agent runs in a shell. Browser use poses two unique challenges for those tools:

• 任务耗时很长，需要按顺序调用大量工具。在 Playwright MCP 中，单个 WebVoyager 任务平均需要 26 轮模型交互。
  Tasks are long-running, with a lot of sequential tool calls. On Playwright MCP, a single WebVoyager task averaged 26 model turns.
• 网页包含大量内容，但通常只有一小部分与任务相关。通过 Browserbase 托管的 MCP 服务器进行一次导航，返回的内容中位数约为 17,000 个字符。
  Web pages carry a lot of content, and only a fraction of it is usually relevant to the task. One navigation through Browserbase's hosted MCP server returns a median of about 17,000 characters.

两者都意味着浏览器工具必须高效地管理上下文。Both mean browser tools have to manage context efficiently.

我们如何测试这些工具How we tested the tools

我们按照智能体开发生命周期反复迭代：在基准测试上运行智能体，在 LangSmith 中查看它的执行轨迹，找出它在哪些地方浪费了步骤或 token，然后修改工具，并运行评估来确认改动是否有效。每次运行都是一次 LangSmith 实验，因此我们可以并排比较不同配置，也可以点击任意数值，查看其背后的执行轨迹。We iterated with the agent development lifecycle: run the agent on a benchmark, read its traces in LangSmith to see where it wasted steps or tokens, change the tool, and run evals to check that the change helped. Every run was a LangSmith experiment, so we could compare setups side by side and click from any number into the trace behind it.

我们使用了三个针对实时网站任务的基准测试：We used three benchmarks of tasks on live websites:

• WebVoyager：涵盖 Allrecipes、Amazon 和 Google Flights 等热门网站上的 100 项日常任务，使用 Claude Sonnet 5.5 执行，并由 Jev judge 评分。这个基准测试已经相当饱和，因此很适合用来清晰地比较上下文使用情况、成本和速度。
  WebVoyager: 100 everyday tasks across popular sites like Allrecipes, Amazon, and Google Flights, run with Claude Sonnet 5.5 and graded by a Jev judge. It's fairly saturated, which made it a clean way to compare context use, cost, and speed.
• HardBench：来自 Browserbase 的 102 项更高难度任务，由其自有验证器评分，大多使用 Claude Opus 5.5 运行。
  HardBench: 102 harder tasks from Browserbase, graded by its own verifier and run mostly with Claude Opus 5.5.
• WebTailBench：来自微软的真实世界“长尾”任务，每项都根据简短的评分标准进行评分。我们使用 Stagehand 评测运行了其中 150 项。
  WebTailBench: real-world "tail" tasks from Microsoft, each scored against a short rubric. We ran 150 of them through the Stagehand evals.

我们让每个测试框架都返回结构化输出（JSON 答案）。这样，格式上的小失误（例如任务要求表格，却只回复一行）就不会影响它的浏览能力评分。我们也将这一选项贡献回上游，纳入 Browserbase 的评测中。We had every harness return structured output (a JSON answer). That way a formatting slip, like a one-line reply to a task that asks for a table, didn't count against its browsing. We upstreamed that option to Browserbase's evals.

工具设计……非常重要Tool design is… so important

我们首先固定模型和任务，只改变工具集。这七种工具集在智能体调用它们的方式上各不相同：We first held the model and tasks fixed and changed only the toolset. The seven toolsets differ in how the agent calls them:

• 原生工具：每次操作调用一个工具，例如点击或导航（Playwright MCP、browser-use 和 Browserbase MCP）。
  Native tools: one tool per action, like click or navigate, called one at a time (Playwright MCP, browser-use, and Browserbase MCP).
• CLI：智能体在 shell 中运行浏览器命令（agent-browser 和 Browserbase 的 browse CLI）。
  CLI: the agent runs browser commands in a shell (agent-browser and Browserbase's browse CLI).
• 代码模式：智能体编写调用浏览器的代码，因此一次调用就能执行多个步骤（Stagehand 工具，以及通过代码调用的 Browserbase MCP）。
  Code mode: the agent writes code that calls the browser, so one call can run many steps (the Stagehand tools, and Browserbase MCP called from code).

每套工具在 78% 到 90% 的任务中通过了测试，但成本和速度差异很大。Stagehand 工具的通过率最高（90%），总成本为 1.98 美元，每项任务的中位耗时为 17.4 秒。Playwright MCP 的通过率为 78%，成本为 26.71 美元，约为前者的 13 倍，而且每项任务耗时是其三倍（完整结果）。Every toolset passed between 78% and 90% of tasks, but cost and speed varied widely. The Stagehand tools passed the most (90%) for $1.98 in total, at a median 17.4 s per task. Playwright MCP passed 78% for $26.71, about 13x the cost, and took three times as long per task (full results).

Stagehand 为代理提供了三个工具：Stagehand gives the agent three tools:

• snapshot 会读取页面的无障碍树，并为交互元素标注 ID。
  snapshot reads the page's accessibility tree and labels interactive elements with IDs.
• run 在页面上执行操作，可以是一批操作（例如点击和填写），也可以是使用 Playwright 风格页面对象的 JavaScript 代码。
  run acts on the page, either with a batch of actions like click and fill or with JavaScript that uses a Playwright-style page object.
• 屏幕截图捕获了渲染后的页面。
  screenshot captures the rendered page.

在更难的任务上，这一差距依然存在。在 HardBench 的 38 项核心任务中，Deep Agents 使用 Stagehand 的代码编写运行工具通过了 30 项；使用 Browserbase 的命令式浏览 CLI 则通过了 21 项，且每项任务的成本是前者的三倍。The gap held on harder tasks. On HardBench's 38 core tasks, Deep Agents passed 30 with Stagehand's code-writing run tool and 21 with Browserbase's command-style browse CLI, at three times the cost per task.

Stagehand 专为智能代理打造Stagehand is built for agents

早期的浏览器工具改造了 Playwright 这类测试 SDK。正如 Browserbase 所说：“Playwright 是为测试而构建的，我们则为你的智能体打造了 Stagehand。”在 Browserbase 发布 Stagehand v4 时提到的设计选择中，有三项对我们的影响最大：Early browser tooling repurposed testing SDKs like Playwright. As Browserbase puts it, "Playwright was built for testing, we built Stagehand for your agent." Three of the design choices from Browserbase's Stagehand v4 announcement made the most difference for us:

• 代码模式，因此一次工具调用即可执行多个浏览器操作。
  Code mode, so one tool call can run many browser steps
• 快照：页面交互元素的精简文本视图
  Snapshots, a compact text view of the page's interactive elements
• 通过在浏览器中运行，减少往返次数
  Fewer round trips, by running inside the browser

代码模式可保持上下文精简Code mode keeps context lean

在代码模式下，智能体编写代码来调用工具，而不是逐个调用工具（Browserbase 认为代码模式就已足够，并介绍了如何通过代码让计算机操作不断进化）。它同时应对了这两项挑战：In code mode, the agent writes code that calls the tools instead of calling them one at a time (Browserbase makes the case in Code mode is all you need and Evolving computer use with code). It answers both challenges:

• 调用之间无需等待模型。浏览器步骤是顺序执行的，因此使用 run 时，智能体会将整个操作链（打开页面、填写字段、点击、检查）写成一个代码片段，并在执行过程中不必在每一步之间等待模型做出决策。
  No waiting on the model between calls. Browser steps are sequential, so with run the agent writes the whole chain (open a page, fill a field, click, check) as one snippet, and it runs without a model decision between each step.
• 中间过程中的上下文不会进入上下文窗口。代码片段在执行过程中接触到的所有内容都会留在其变量中，只有代理在浏览器交互后返回的内容才会进入上下文。
  Intermediate context stays out of the window. Everything the snippet touches along the way stays in its variables, and only what the agent returns after the browser interaction lands in context.

在选择 Stagehand 之前，我们就看到了这种效果。通过解释器中的代码调用 Browserbase 的 MCP 工具，而不是一次调用一个，成本降至原来的四分之一（从 17.87 美元降至 4.52 美元）。We saw the effect before we picked Stagehand. Calling Browserbase's MCP tools from code in an interpreter, instead of one at a time, cut their cost 4x ($17.87 to $4.52).

Stagehand 的 run 工具原生接收代码。每项任务平均需要 10 个步骤，而 Playwright MCP 需要 26 个；一次导航返回的字符数中位数为 117 左右，而 Browserbase 托管的 navigate 工具约为 17,000 个。Stagehand's run tool takes code natively. It averaged 10 steps per task against 26 for Playwright MCP, and a navigation sent back a median 117 characters against about 17,000 from Browserbase's hosted navigate tool.

run 也接受 Playwright 风格的代码。模型接受过大量 Playwright 代码的训练，因此最擅长编写这类代码，而 Stagehand 的翻译器会将其编译成 Stagehand 命令。我们尝试让 run 改用 Stagehand 原生 API 后，完成的任务减少了 5.3 个百分点，而且每个成功完成的任务成本高出 19%，即使工具描述准确也是如此。run also takes Playwright-style code. Models are trained on tons of Playwright, so that's the code they write best, and Stagehand's translator compiles it into Stagehand commands. When we tried a run that takes Stagehand's native API instead, it passed 5.3 points fewer tasks and cost 19% more per passed task, even with an accurate tool description.

快照表示交互元素Snapshots represent interactive elements

读取页面是浏览器代理执行的最耗资源的操作之一。snapshot 会返回页面的无障碍树，裁剪掉代理不需要的部分，并为每个交互元素标注 ID。这样，代理就能直接理解页面并据此采取操作，例如在 run 中使用 {"op": "click", "id": "0-7"}，完全不必读取原始 HTML，也不必编写选择器来点击按钮。Browserbase 报告称，v4 的令牌效率比 Playwright 高约 80%。Reading a page is one of the most expensive things a browser agent does. snapshot returns the page's accessibility tree, trimmed to the parts an agent needs, with an ID on each interactive element. This gives the agent a view of the page that it can understand and act on directly, like {"op": "click", "id": "0-7"} in run, so it never has to read raw HTML or write a selector to click a button. Browserbase reports v4 is about 80% more token efficient than Playwright.

读取页面时，主要使用快照而不是截图，是上下文工程上的一大优势。树形结构是精简的文本，智能体可以据此执行操作；而截图是模型必须解读的图像。在我们的 WebTailBench 测试中，每次调用的截图大小中位数为 89 KB。不过，精简必须从源头做起。事后将快照限制在 8,000 个字符时，智能体只会重新获取页面，而每个通过任务的成本仍然没有变化。Reading pages mostly through snapshot instead of screenshot is a big win for context engineering. The tree is compact text the agent can act on, while a screenshot is an image the model has to interpret, at a median 89 KB per call in our WebTailBench runs. Trimming has to happen at the source, though. When we capped snapshots at 8,000 characters after the fact, agents just fetched the page again, and cost per passed task stayed flat.

浏览器往返次数已降至最低Browser round trips are minimized

一次 Playwright 点击需要调用 5 次 CDP：将元素滚动到视口内、读取其位置，然后依次移动鼠标、按下并释放（来源）。Playwright 会等待每次响应后再发送下一条命令，因此一次点击就会让智能体与浏览器之间产生 5 次往返通信。随着浏览器离智能体越来越远，这种开销也会不断增加——从笔记本电脑到沙箱，再到云端。A single Playwright click is five CDP calls: scroll the element into view, read its position, then mouse move, press, and release (source). Playwright waits for each response before sending the next, so one click costs five round trips between the agent and the browser. That cost adds up as the browser gets farther from the agent, from a laptop to a sandbox to the cloud.

Stagehand v4 作为扩展在浏览器内运行，因此这些底层调用会在页面旁执行，而 run 会在一次往返中发送整批操作。Browserbase 报告称，在其基准测试中，v4 的运行速度比 Playwright 快 2 倍。Stagehand v4 runs inside the browser as an extension, so those low-level calls happen next to the page, and run sends a whole batch of actions in one round trip. Browserbase reports v4 runs 2x faster than Playwright in its benchmarks.

探索其他优化方式Exploring other optimizations

选定 Stagehand 后，我们继续调整测试框架。最大的改进来自修复智能体等待页面加载的方式。With Stagehand chosen, we kept tuning the harness. The biggest win came from fixing how agents wait for pages to load.

查看 LangSmith 中的追踪记录时，我们发现代理会写入像 page.waitForTimeout(8000) 这样的固定等待，来等页面加载完成。大多数页面早在计时结束前就已准备就绪，因此代理在每次运行中都有相当多的时间什么也不做。Reading traces in LangSmith, we saw agents writing fixed sleeps like page.waitForTimeout(8000) to wait for a page to load. Most pages were ready long before the timer ran out, so agents spent a lot of each run doing nothing.

因此，我们修改了 run：在页面静默 500 毫秒后就结束每次 sleep，并且最迟不超过 agent 请求的时间。在一次测量中，原本 8 秒的 sleep 在 0.6 秒后就返回了。随后，我们通过 evals 检验了这项改动。在 HardBench 上，配合结构化答案和模型调用超时设置，这项改动将 agent 的耗时中位数从 182 秒降至 124 秒，准确率则保持在误差范围内。So we changed run to end each sleep once the page has been quiet for 500 ms, and never later than the time the agent asked for. In one measurement, an 8-second sleep returned in 0.6 s. Then we checked the change with evals. On HardBench, together with structured answers and a model-call timeout, it cut median agent time from 182 s to 124 s, with accuracy within noise.

Stagehand 此后已将该修复合并到上游。Stagehand has since upstreamed the fix.

结论Conclusion

浏览器任务对智能体上下文的消耗，超过了大多数其他工作。我们发现，最大的提升来自工具，主要取决于它们向模型返回的信息量以及所需的交互轮数。Browser tasks stretch an agent's context more than most work. The biggest gains we found came from the tools, mostly from how much they send back to the model and how many turns they take.

你可以对任何智能体采用相同的流程。了解你的使用场景会产生怎样的上下文，然后通过追踪记录和评估不断迭代。追踪记录能显示智能体在哪些地方浪费了步骤和令牌，评估则能告诉你某项改动是否有所帮助。You can use the same process on any agent. Understand the context your use case produces, then iterate with traces and evals. Traces show where the agent wastes steps and tokens, and evals tell you whether a change helped.

这些是 Managed Deep Agents 中浏览器背后的工具。为你的智能体配备浏览器功能——我们上周刚刚推出了 Managed Deep Agents。These are the tools behind the browser in Managed Deep Agents. Give your agent a browser in Managed Deep Agents, which we launched last week.

要在开源 Deep Agents 中使用相同的工具，请将 langchain-stagehand 中的 StagehandMiddleware 添加到你的智能体中：To use the same tools in open source Deep Agents, add StagehandMiddleware from langchain-stagehand to your agent:

from deepagents import create_deep_agent
from langchain_stagehand import StagehandMiddleware
from stagehand import Stagehand, local_browser

browser = await local_browser.launch(headless=True)
stagehand = await Stagehand.create(browser=browser)

agent = create_deep_agent(
    model="openai:gpt-5.5",
    middleware=[StagehandMiddleware(stagehand=stagehand)],
)

对于需要大规模浏览开放网络的智能体，请改用 Browserbase，通过 browserbase.launch() 启动浏览器。浏览器使用指南涵盖了其余内容，包括浏览器作用域以及如何在沙盒中测试应用。试试看吧，欢迎告诉我们你构建了什么！For agents that browse the open web at scale, launch the browser on Browserbase with browserbase.launch() instead. The browser use guide covers the rest, including browser scope and testing an app in a sandbox. Give them a try, and let us know what you build!

致谢Acknowledgements

感谢 Baihao Wang 主导 HardBench 相关工作，为贡献到 Stagehand 的优化提供支持；也感谢 Browserbase 的 Sean McGuire、Miguel Gonzalez 和 Kyle Jeong 对 Stagehand 的帮助。Thanks to Baihao Wang for leading the HardBench work backing the optimizations upstreamed to Stagehand, and to Sean McGuire, Miguel Gonzalez, and Kyle Jeong from Browserbase for their help with Stagehand.