2.3 接管真实浏览器与登录态

2.3 接管真实浏览器与登录态

本节摘要：操作需要登录的站点，正确姿势是把本机 Chrome 的用户目录交给 Browser-Use 接管：登录态住在浏览器配置文件里，密码从头到尾不经过模型。本节给出接管配置、验证方法与一条必须划清的风险边界——拿到你登录态的智能体，能做你登录后能做的一切事。

一个反例先立住风险

先讲一个真实翻车模型。有人图省事，把用户名密码直接写进任务单："打开某后台，在登录页输入账号 A、密码 B，然后查订单。"任务确实完成了，但从此密码存在于两处风险面：任务单日志里（会话记录、报错堆栈都可能带上它）、模型服务商的请求记录里（页面简报与任务描述都会上送）。更糟的是他没意识到——直到有天日志系统把明文密码推给了全组。正确做法只有一个：登录这件事发生在人机之间，智能体只借用登录后的状态。

接管本机 Chrome

思路：给 Browser-Use 指定本机 Chrome 的用户数据目录。这个目录里住着你的 cookie、localStorage、已登录会话——车厢还是那个车厢，只是钥匙换成了你日常用的那把。

from browser_use import Agent, Browser, BrowserConfig
from browser_use.browser.profile import BrowserProfile
from langchain_openai import ChatOpenAI

# 接管本机 Chrome 的用户数据目录（Windows 的典型位置）
# 注意：接管期间先退出正在运行的 Chrome，避免目录被锁
browser = Browser(
    config=BrowserConfig(
        chrome_instance_path="C:/Program Files/Google/Chrome/Application/chrome.exe",
        extra_chromium_args=[
            "--profile-directory=Default",   # 用哪个配置文件，多账号时按需换
        ],
    )
)

agent = Agent(
    task="打开公司后台首页，读出左侧菜单里有哪几个栏目，只回答栏目名",
    llm=ChatOpenAI(model="gpt-4o"),
    browser=browser,
)
result = agent.run(max_steps=10)
print(result)   # 预期：直接进入已登录的后台并列出菜单，全程没有登录动作
​

预期输出里最关键的信号是：日志中没有任何输入账号密码的动作——它一打开就是登录态。如果弹出了登录页，说明配置目录没对上（最常见原因：接管时 Chrome 没退干净，或配置文件名不是 Default）。

不想动本机 Chrome 的替代方案：让智能体用自带内核跑一次登录前的流程，到登录页停下，把控制权还给你手工登录，之后的会话继续归它。这适合调试期不想退出日常浏览器的场景，代价是每次都要人工补一脚。两种方案怎么选：日常任务高频跑，用接管；临时调试，用人工补登。

多账号与隔离

1.2 立过规矩：登录态住在 BrowserContext 层。多账号巡检两个后台的正确姿势是两个独立配置目录，各自起会话——cookie 罐子分开，账号就串不了味：

from browser_use import Agent, Browser, BrowserConfig

def make_agent(profile_dir: str, task: str) -> Agent:
    """按配置目录起一个独立会话的智能体"""
    browser = Browser(
        config=BrowserConfig(
            chrome_instance_path="C:/Program Files/Google/Chrome/Application/chrome.exe",
            extra_chromium_args=[f"--profile-directory={profile_dir}"],
        )
    )
    return Agent(task=task, llm=None, browser=browser)  # llm 按第2.1节配置填入

# 账号甲一个车厢，账号乙另一个车厢，互不可见对方的登录态
agent_a = make_agent("Profile A-工作", "检查工作后台的待办数量")
agent_b = make_agent("Profile B-店铺", "检查店铺后台的订单数")
​

风险边界：一句话与一张清单

一句话：**智能体带着你的登录态，就是带着你的身份；它能做的事，等于你被冒充时对方能做的事。**动手前的检查清单：

• 只把低敏感、可撤销的会话交给智能体：测试账号、专用小号优先于个人主号；
• 任务单里永远不写密码、验证码、支付口令——这些环节设计成人工接管；
• 高危操作（删除、支付、改绑）不放进自动化任务单，或用第 4 章的自定义动作加人工确认闸门；
• 任务跑完顺手检查会话：不认识的新设备登录提示、异常操作记录，出现了立刻改密下线；
• 内网系统、有合规红线的站点，先过安全审批——页面内容会被送往模型服务，这属于数据出境行为，第 6 章第 1 节会展开。

验收与变式

本节验收两件事：跑通一次"零登录动作直达后台"的任务；说得出多账号隔离该在哪一层做。变式留一个：把任务改成"退出登录再登录回来"你会发现它做不到（也不该做到）——想想为什么，答案藏在上面那句边界宣言里。

接管失败排查三步

接管配置没生效时，按固定顺序查三步。第一步查进程占用：本机 Chrome 没退干净，配置目录被锁，智能体实际开的是全新空白会话——任务管理器里结束所有 Chrome 进程再试。第二步查配置文件名：--profile-directory 后面的名字必须与 Chrome 实际目录一致（Default、Profile 1 之类），名字写错不报错，只是悄悄换了个空车厢。第三步查路径权限：某些公司管控软件会拦截对浏览器目录的读取，换一台机器交叉验证即可定位。

一个容易被误解的现象顺带说清：接管模式不是"共享你正在用的窗口"。它读的是同一份配置目录（所以登录态一致），但开的是独立实例，两边同时操作会互相干扰。正确用法是接管期间不手动碰浏览器——它是智能体的车厢，不是你的副驾。

一个边界情况：双因素认证

遇到登录需要短信或动态口令的站点，方案是"人在环上"：任务单设计成到登录页为止，之后人工完成认证，再由智能体接管后续流程。别试图让模型帮你收验证码——把验证码通道交给自动化，等于把最后一道门禁钥匙挂在了门把手上，6.1 的检查清单会再次把这条列为红线。

出车准备到此齐备。第 3 章进入全书主轴：把日志背后的观察、决策、动作、复核四拍拆开讲透。