使用受控浏览器配置 browser-use Agent

browser-use 可以规划浏览器任务，但它的 agent 循环不会替你选择可信的可执行文件，也不会判断关键操作是否安全。BotBrowser 可以为授权流程提供带 profile 的 Chromium；操作员仍需选择 executable 和 profile、核对实际启动结果，并在账户、资金或数据会被改变时审批。 浏览器自动化入门地图介绍一般的首次运行；browser-use 的交接边界需要额外验证。

对于 browser-use，BotBrowser 支持显式 Chromium 启动和 --bot-profile 参数；它不提供 agent framework，不选择任务策略，也不保证站点分类结果。

TL;DR

• 把 browser-use 当作规划器和浏览器控制层，而不是 profile 或策略的权威来源。
• 通过底层 Playwright 启动参数传入明确的 Chromium executable 和 profile 参数。
• 在交给 agent 真实任务前读取运行进程，并访问自有 fixture 页面。
• 遇到凭据、购买、删除、权限或不可逆提交时暂停并请求人工审批。
• 启动正确只证明配置正确，不承诺检测器或站点结果。

内容

• 分开规划、启动和审批
• 配置明确的 executable 和 profile
• 验证进程和页面可见 fixture
• 用决策表交给操作员
• 失败 fixture 与有界恢复
• 常见问题
• 实践结论

分开规划、启动和审批

当 Agent 通过 MCP 服务器而非直接启动 Chromium 时，无头浏览器归属指南说明了哪个组件控制启动参数，并将 tools/list 与 executablePath 的归属区分开来。

browser-use 把自然语言任务变成浏览器动作。它的文档和公开仓库描述了基于 Playwright 的 agent framework；这并不使它成为浏览器供应商、profile 签发方或授权系统。让三方责任在代码中保持清楚：browser-use 负责规划，launcher 负责进程和 profile，操作员负责关键步骤审批。Playwright profile 启动指南介绍底层启动契约。

任务完成只表示 agent 到达页面或点击了控件，并不能证明启动的是目标 binary、profile 已加载，或远程服务接受了 session。这些是不同观察，需要分别核验。

首次运行应使用团队拥有的 staging 路由。自有 fixture 可以提供固定 build 标识、consent 状态和无副作用按钮；第三方页面可能在两次运行之间改变布局或策略。进程和 fixture 检查一致之前，保持任务范围很小。

配置明确的 executable 和 profile

browser-use 的 Python 配置最终会传到 Playwright 浏览器启动。构造函数名称可能随版本变化，因此要锁定版本并查看对应配置文档。稳定不变的契约是：executable_path 指向批准的 BotBrowser binary，profile 作为浏览器参数传入，而不是依赖 bundled browser 或页面脚本。

import asyncio
from browser_use import Agent, Browser, BrowserConfig

async def main():
    browser = Browser(
        config=BrowserConfig(
            headless=True,
            executable_path="/opt/botbrowser/chrome",
            args=["--bot-profile=/srv/profiles/approved.enc"],
        )
    )
    agent = Agent(
        task="Open the owned staging fixture and report its build identifier. Do not sign in or submit anything.",
        browser=browser,
    )
    await agent.run()

asyncio.run(main())

示例展示的是边界，不是对所有 browser-use 版本 API 名称的承诺。请用锁定的版本核对选项名称。profile 是 BotBrowser 的命令行输入，应该放在 args 中，并在首个页面打开前使用绝对路径。BotBrowser CLI flags 参考说明旗标写法和等级限制。

不要安装会悄悄下载另一个 Chromium 的完整框架包，然后假设 profile 已生效。应关闭 bundled browser 或使用兼容的 core launcher。把 executable、profile 标识、框架版本、浏览器版本和 runId 放入一份脱敏记录，绝不要写入 cookies、token、profile 内容或代理凭据。

将任务文本与启动策略分开

prompt 只能描述自有页面和无副作用观察，不应包含新的 executable、secret 或削弱策略的指令。启动配置应该留在经过审核的部署代码中。

验证进程和页面可见 fixture

验证需要两次独立读取。先检查 Playwright 启动的进程，把 executable 路径和参数与声明值比较；再从自有 fixture 读取稳定且不敏感的字段。页面无法证明启动它的进程，进程也无法证明应用渲染了预期状态，因此两者都要保留。

async def verify(page, browser, expected_executable, expected_profile):
    process = browser.playwright_browser.process
    observed_executable = process.args[0] if process and process.args else None
    observed_args = process.args if process else []
    fixture = await page.evaluate("""() => ({
      build: document.querySelector('[data-build]')?.dataset.build ?? null,
      consent: document.querySelector('[data-consent]')?.dataset.consent ?? null,
      userAgent: navigator.userAgent
    })""")
    return {
        "executableMatches": observed_executable == expected_executable,
        "profileArgumentPresent": any(expected_profile in arg for arg in observed_args),
        "fixture": fixture,
    }

fixture 预期结果可以是 staging-2026-11-06、not-requested consent，以及非空 user-agent。user-agent 是观察值，不是检测器结论。任一 executable 或 profile 比对失败，都应在交给真实任务前停止，并把问题归类为启动配置。 profile 管理文章解释了如何分开记录 profile 标识和内容。

{
  "runId": "browser-use-check-20261106-01",
  "declared": {
    "executable": "/opt/botbrowser/chrome",
    "profile": "approved.enc",
    "fixture": "staging-2026-11-06"
  },
  "observed": {
    "executableMatches": true,
    "profileArgumentPresent": true,
    "fixtureBuild": "staging-2026-11-06",
    "consent": "not-requested"
  },
  "firstFailure": null
}

launch_record = {"executable": "/opt/botbrowser/chrome", "profile": "approved.enc", "fixture": "staging-2026-11-06"}
assert launch_record["executable"].startswith("/opt/")

扩大范围前比较基线

在扩大任务前记录 executable、profile、版本和 fixture。一次只改变一个变量，合同改变时重新请求审批。

将凭据留在 Agent 循环之外

凭据和私密代码必须通过审核的 secret 流程输入，不能放进 prompt 或 Agent 记录。

用决策表交给操作员

只有声明配置与观察结果一致，且下一步可逆时，agent 才能继续。凭据、consent、付款、删除、授权和不确定的远程写入都必须由操作员负责。

观察结果	Agent 可以继续	操作员动作
executable 与 profile 一致；自有 fixture 只读	读取下一页 staging	审核任务范围
executable 不同或缺少 profile 参数	否	修复启动配置并重新跑 fixture
fixture 要求登录或权限	否	通过批准流程提供凭据或 consent
即将购买、删除、发布或提交	否	检查最终参数后单次审批
可能写入后发生超时	不得盲目重试	查询幂等状态或交给负责人

这是运行边界，不是对模型行为的保证。请在外围应用实现明确的 pause 或 approval callback，不要把真实账户的保护寄托在 prompt 一句话上。

失败 fixture 与有界恢复

使用故意缺少 build 标记的 fixture 测试停止路径。agent 应报告标记缺失并停止，而不是继续点击直到另一页面恰好出现标记。

async def read_build(page):
    value = await page.locator("[data-build]").get_attribute("data-build")
    if value is None:
        raise RuntimeError("owned fixture missing data-build; stop delegation")
    return value

按顺序恢复：缺少进程参数是 launcher 问题；缺少 fixture 标记是 fixture 或部署问题；登录页是审批边界；写入后超时是远程结果不确定。四种情况都重启 agent，可能造成重复写入。

常见问题

browser-use 会让 session 无法被检测吗？

不会。它只协调浏览器动作。明确的 executable 和 profile 可以让启动可复现，但 browser-use 和 BotBrowser 都不保证第三方检测器或站点的结论。

Agent 可以在运行时自由选择 profile 吗？

不应从无限制目录选择。应在部署代码中解析批准的 profile，记录选择规则，并由操作员决定何时更换账户或区域。

找到商品后，Agent 应该直接提交购买吗？

没有明确人工审批就不应提交。Agent 可以准备可复核的购物车或表单，操作员确认收件人、金额、consent 和最终提交。

页面可见的 user-agent 足以证明启动正确吗？

不足。应同时读取进程、检查 profile 参数，并验证固定 fixture 结果。

实践结论

把 browser-use 组织成三部分契约：经过审核的启动配置、自有验证 fixture，以及人工审批边界。用批准的 profile 启动明确 executable，比较进程参数和 fixture，在任何不一致或关键操作前停止。这样可以审计 agent 运行，同时不承诺绕过、成功率或远程决定。

来源

• browser-use 仓库
• browser-use 文档
• Playwright Python BrowserType API
• BotBrowser Playwright 配置
• BotBrowser CLI flags
• NIST AI Risk Management Framework