让 Responses 调用真实浏览器驱动

变化不在模型，而在浏览器驱动

Browser Use 0.13.13 把一个可直接验证的接入点补齐了：通过 browser-use[openai-tools] 安装集成后，BrowserUse 驱动可以交给 OpenAI Python SDK 的 AsyncBrowserToolset 和 AsyncResponsesToolRunner，让 Responses 的函数调用落到 Browser Use 的本地浏览器、Browser Use Cloud，或已经连接的 BrowserSession 上。它不是 Responses API 新增了一种原生浏览器工具，也不是模型自动获得浏览器权限；应用仍需创建驱动、决定开放哪些方法，并负责密钥、会话和权限策略。

这项变化适合正在自行拼接“模型函数调用—浏览器自动化—工具结果”的开发者。过去要自己实现 SDK 约定的 driver，再处理异步调用和浏览器状态；现在可复用现成适配层，但依然要理解工具暴露范围。尤其不能把“集成提供了很多动作”误读成“这些动作都应该交给模型”。

三层关系要分清

接入由三个组件构成。Responses API 负责让模型提出函数调用；OpenAI Python SDK 的 AsyncBrowserToolset 把 driver 方法描述成可供 Responses 使用的函数工具，并处理工具调用边界；Browser Use 的 BrowserUse 才负责把被选中的操作映射到其 Actor/CDP 浏览器会话。OpenAI SDK 文档明确指出，BrowserToolset 是由应用提供的 driver 转成 Responses 函数工具，并不会替应用安装浏览器、访问浏览器配置文件或管理 driver 会话。因此，“Responses 支持浏览器”并不意味着 SDK 自带一个可随时访问用户桌面的浏览器。

Browser Use 0.13.13 的发布说明称，该驱动覆盖 18 个默认工具和 6 个可选动作，并可连接本地浏览器、Browser Use Cloud 或借用现有浏览器会话。发布说明同时列出了两个针对真实集成的修复：导航过程中云端标签页可能暂时返回空 URL；高缩放显示器上的截图像素可能与坐标操作使用的 CSS 视口不一致。这些不是模型推理能力变化，而是工具执行链路中浏览器状态和坐标的适配问题。

版本也有边界。此集成的可选依赖要求 OpenAI Python 3.31 或更新版本；Browser Use 的发布说明还特别提示 OpenAI Python 3.x 使用 httpx2，自定义 HTTP 客户端应使用 OpenAI 提供的 DefaultAsyncHttpxClient。如果项目仍锁定 OpenAI 2.x，不能只根据“核心包兼容”就推断新 openai-tools 集成可直接安装。应在单独虚拟环境中按项目实际依赖解析验证，再决定是否升级，避免为了接浏览器工具意外改变应用中其他 OpenAI 调用的依赖图。

从最小权限开始接入

先选浏览器生命周期，而不是先放开工具。需要独立、由集成创建的本地浏览器时，可以使用 BrowserUse()；需要复用已连接的会话时，将 BrowserSession 传给 BrowserUse(browser=session)。后一种情况下，浏览器不是集成独占资源，应用仍负责该会话的生命周期。把会话创建、模型请求和关闭逻辑放进明确的 try/finally 或异步上下文管理，避免一次模型异常让浏览器进程留在后台，也不要在不知情时关闭调用方借给集成的会话。

下面是结构示意，具体可用参数请以所安装版本的官方指南为准：

from openai import AsyncOpenAI
from openai.lib.browser import AsyncBrowserToolset
from openai.lib.responses_tool_runner import AsyncResponsesToolRunner
from browser_use.integrations.openai import BrowserUse

async with AsyncOpenAI() as client:
    browser = BrowserUse()  # 或传入一个由应用管理的 BrowserSession
    toolset = AsyncBrowserToolset(browser)
    runner = AsyncResponsesToolRunner(browser=toolset)
    response = await runner.run(
        client,
        {"model": "支持 Responses 函数工具的模型", "input": "读取指定页面的标题"},
        max_steps=5,
    )

这里的示意代码刻意没有把密钥写入代码，也没有启用写操作。实际程序应从环境或密钥管理服务读取凭证，并先用只读能力验证从请求到工具结果的完整链路。随后逐项评估是否开放点击、输入、脚本执行等会改变页面状态的能力。模型输出是对不可信页面内容的响应，页面上也可能出现诱导模型执行无关动作的文字；浏览器工具权限应按任务收窄，不能把模型可见范围等同于应用授权范围。

若要直接控制暴露集合，应阅读当前 AsyncBrowserToolset 的成员配置，而非仅凭工具数量推断其语义。OpenAI SDK 对可选动作设有显式启用方式，部分修改动作要求 confirm 回调；具体动作和默认值以对应 SDK 版本文档为准。把确认回调接到应用自己的授权决策上，记录调用者、目标站点、动作类型和结果。不要把一个永远返回 True 的回调当作安全校验，也不要把浏览器 Cookie、原始网络头或页面上的秘密返回给模型。

两个修复各自解决什么

第一个修复处理导航期间的瞬时状态：云浏览器的标签页可能在导航提交前暂时报告空 URL，而 OpenAI Python 3.31 会在动作之后检查浏览器状态，空值可能使工具执行链中断。Browser Use 的修正是在未提交 URL 的窗口以 about:blank 表示尚未提交的页面；URL 提交后仍报告真实地址。排查类似失败时，应区分“导航还没提交”和“导航到了错误地址”，不要在所有异常上盲目重试，更不要把 about:blank 当作导航成功的证明。

第二个修复处理截图和指针坐标的坐标系不一致。屏幕缩放或设备像素比大于一时，截图像素尺寸可能是 CSS 视口尺寸的倍数；如果截图用于模型判断，而点击按 CSS 坐标执行，模型看见的位置和点击落点就会偏移。0.13.13 将截图对齐到 CSS 视口像素，让截图、裁切和坐标动作在同一坐标空间中工作。集成自己的验收测试应至少覆盖缩放显示环境，并验证截图中目标元素中心点对应的点击实际落在同一元素；只检查图片能否生成不足以发现坐标偏移。

上游的 PR 说明还指出，修复加入了对应的真实浏览器回归用例：一项覆盖导航时空 URL 经过真实工具集的路径，另一项覆盖双倍缩放截图和指针点击。发布页记录 11 个 driver 测试通过。它们说明维护者针对这两个回归场景加了检查，不代表所有网站、远程浏览器服务或缩放配置都已被穷举验证。应用仍需针对自身驱动模式和目标页面做验收。

生产化前的检查清单

第一，固定并记录组合版本：Browser Use、OpenAI Python、浏览器运行时和部署镜像都应进入锁文件或构建清单。升级时先在隔离环境重跑导入、工具注册、一次只读导航和关闭流程。0.13.13 替代了未获批准发布到 PyPI 的 0.13.12，因此安装时应按官方安装文档与包索引确认实际拿到的版本，而不是照搬旧文章中的固定版本号。

第二，检查工具面和数据边界。确认模型能够调用哪些浏览器方法，是否包括点击、填写、脚本或文件操作；确认模型收到的页面文本、截图和工具结果是否包含个人信息；对目标域名、下载、上传和跨站导航设置应用级策略。仅仅复用 SDK 的工具定义不等于完成了站点授权或隐私过滤。

第三，区分会话归属。由集成创建的浏览器与调用方传入的会话有不同所有权。测试成功、异常退出、任务取消和应用关闭时分别检查清理行为；借用的会话应由所有者关闭，专用会话则应由创建它的应用路径可靠清理。云端浏览器还要把创建失败、动作失败和清理失败分开记录，以便确认资源是否释放。

第四，建立可定位的日志。保留请求关联 ID、工具名、目标域名、浏览器会话标识和失败阶段，但不要记录密钥、Cookie 或完整敏感页面内容。对空 URL 问题，记录导航前后状态；对坐标问题，记录视口尺寸、截图尺寸、缩放信息和目标坐标。这样才能判断是模型选错元素、driver 状态异常，还是截图坐标映射出了偏差。

如果你还在比较 API 供应商或工具入口，可从平台目录核对项目所需能力；若需补充 AI 工具链的其他接入案例，可参阅Codex MCP 服务的配置说明。这些目录信息不替代对具体 SDK、driver 版本和权限策略的验证。