LangChain 为 Managed Deep Agents 加入浏览器能力

Agents 已经足够强大，可以在我们工作的地方工作，而其中很多工作都发生在浏览器里。预订旅行、取消订阅或提交理赔，都发生在为人类点击页面而构建的网站上，包括 agent 原本没打算访问的网站。通常没有 agent 可以调用的 API。用 curl 抓取页面也走不远，因为它返回的是任何 JavaScript 渲染页面之前的 HTML，而且无法点击任何东西。

像 Instinct 和 Meta 的 Muse 这样的个人 agent 已经以这种方式工作。浏览器 agent 流量也在快速增长，DataDome 仅 9 月就发现 agentic 浏览器请求激增 4.7 倍。

Managed Deep Agents 让你无需运行任何基础设施即可在 LangSmith 中构建和部署 agent。你编写 agent 的指令和工具，LangSmith 运行 harness 和运行时。今天，我们为这些 agent 提供一个浏览器，这样你就可以构建自己的、能在 Web 上工作的 agent。Managed Deep Agents 也运行浏览器，并为你的 agent 提供针对它调优的工具。

在这篇文章中，我们介绍浏览器在哪些地方有帮助以及如何启用它，包括在 agent 需要时把浏览器交给人类。然后我们深入介绍它在底层是如何工作的。用开源 Deep Agents 构建的 agent 也可以使用浏览器。我们将在下周的深度文章中介绍我们如何测试和调优浏览器工具。

浏览器在哪些地方有帮助

有了浏览器和驱动它的工具，agent 可以读取页面上渲染的内容并点击浏览，就像你（人类）会做的那样。

到目前为止，已经出现了两个常见用例：

• API 无法覆盖的操作，比如预订航班或餐厅。当网站确实有用于该任务的 API 时，agent 应该使用 API。
• 端到端测试，比如在合并前检查前端更改。当拉取请求更改了注册表单时，编码 agent 可以在其沙箱中启动应用，在浏览器中打开表单，并点击浏览以检查更改是否有效。我们在编码 agent Open SWE 中使用了这一点。

添加浏览器使用能力

要添加浏览器，请在项目根目录从 browser.py 导出 browser：

# browser.py
from managed_deepagents import define_browser

browser = define_browser(
    scope="thread",
    idle_ttl_seconds=600,
)

scope 控制浏览器会话如何共享。

• scope="thread"（默认值）为每个线程提供自己的浏览器。每次对话都从一个全新的浏览器窗口开始，没有来自其他线程的 cookie 或登录信息。
• scope="user" 在已登录用户的线程之间共享一个浏览器（参见 Identity）。每个线程都有自己的窗口，因此同时运行的两个对话不会互相点击干扰，但它们共享 cookie 和其他浏览器状态。如果你在一个线程中登录了某个网站，后续线程可以接续该会话，而不必重新开始。

浏览器在 idle_ttl_seconds 无活动后停止（默认 10 分钟），因此你不会为无人使用的浏览器付费。

将浏览器交给用户

有些步骤仍然需要人，登录是最常见的一步。你不想把密码交给 agent，否则它会出现在模型的消息中、追踪记录中，以及模型提供商那里。

因此，当 agent 遇到登录页面时，它会调用 browser_handoff 并附上原因，例如“请登录 Acme Travel，以便我继续操作。”在 LangSmith Studio（用于与 agent 对话和调试的 UI）中，你会看到一张带有同一浏览器的交互式卡片。你自行登录，点击 Hand back，agent 便会从上次中断的地方继续，且已处于登录状态。Handoff 随每个托管浏览器提供，并在 Managed Deep Agents channels（如 Slack）中自动生效，因此无需额外设置。

这一点在 scope="user" 场景下最为重要。在用户作用域下，登录状态会延续到你之后的会话中，因此 agent 只需让你登录一次，就像你自己的浏览器会记住你一样。

底层工作原理

agent 要使用网络需要两样东西：一个浏览器，以及一套驱动它的工具集。Managed Deep Agents 对两者都进行管理。

浏览器。 Managed Deep Agents 在独立的 LangSmith sandbox 中运行浏览器，与 agent 分离。它是一个远程浏览器，因此你的机器上不会运行任何东西。与大多数远程浏览器不同，它还与 agent 的 sandbox 有一条私有链路，这正是端到端测试得以实现的原因（详见下文）。

工具。 Managed Deep Agents 为 agent 添加了 browser tools：

• browser_snapshot 读取页面的 accessibility tree，并用 ID 标记交互元素。
• browser_run 在页面上执行操作，可以是一批动作（如 click 和 fill），也可以是使用 Playwright 风格 page 对象的 JavaScript，Stagehand 会将其转换为自己的命令。
• browser_screenshot 捕获渲染后的页面。
• browser_handoff 将浏览器交给人工，完成后由人工交回（见上文）。

browser_run 承担了大部分工作。它接受代码，因此 agent 可以将一整串步骤（打开页面、填写字段、点击、检查结果）作为一次调用执行，并且只返回所需内容。这使长时间的浏览器任务保持快速，并使页面的大部分内容不进入 agent 的上下文。

这些工具构建在 Stagehand 之上，这是 Browserbase 用于构建浏览器 agent 的开源 SDK。我们通过 agent development lifecycle 对它们进行了测试和调优：运行浏览器基准测试、阅读 LangSmith 中的 trace，并用 eval 验证每一项更改。在来自 WebVoyager（一个针对真实网站上日常任务的基准测试）的 100 个任务中，它们以总计 1.98 美元的成本通过了 90% 的任务。这是我们测试的七套工具集中最高的通过率。最接近的是 Browserbase 的 MCP server，它以 9 倍的成本通过了 89%。

这套设置以略有不同的方式支持两种用例。

API 无法覆盖的操作

对于预订等任务，agent 只需要浏览器。其浏览器工具向浏览器 sandbox 发送命令，由后者驱动页面。

端到端测试

端到端测试还需要一个环节。被测应用运行在 agent 自己的 sandbox 中，因此浏览器必须能够访问它。两条连接使这成为可能：

• agent 通过其浏览器工具控制浏览器，如上所述。
• 浏览器通过 localhost 桥接访问应用。当浏览器打开 localhost:5173 时，请求会通过私有链路传输到 agent sandbox 中的 5173 端口。应用不需要公共 URL。此处，localhost 表示 agent 的 sandbox。

agent 用 execute 启动应用，在浏览器中打开它，点击走通注册表单等真实流程，并检查渲染结果。

一旦测试通过，你可以让智能体将其步骤保存为测试文件，因为每次 browser_run 调用都是普通 Playwright 脚本的一部分。之后的运行会重放该文件，不再调用模型，直到页面发生变化。

结论

浏览器为智能体打开了网络世界的广阔天地，从预订航班到测试编码智能体刚刚构建的应用。借助 Managed Deep Agents，为你的智能体配备浏览器只需几行代码，而且其背后的工具经过调优，速度快且上下文高效。

使用 define_browser 为托管智能体添加浏览器。若要为开源深度智能体添加浏览器，并自带浏览器（例如来自 Browserbase 的托管浏览器），请参阅浏览器使用指南。

致谢

感谢 Browserbase 的 Sean McGuire、Miguel Gonzalez 和 Kyle Jeong 对 Stagehand 及本文的帮助。