多个浏览器智能体需要的远不止独立 profile
来源：dev.to — 2026-09-05
📋 概述
这篇是 SessionDock 项目的开发报告。作者指出两个智能体要在两个项目上并行作业、各需一个已登录的浏览器时，「独立浏览器 profile」只解决了数据隔离这一半问题——还要知道某个工作区属于哪个项目、当前由谁控制、以及控制权易手后迟到的操作该怎么办，而这些是目录结构答不了的。SessionDock 用 slot（预配的 Chromium 工作区+独立绑定）、lease（独占且限时的访问权）、epoch（单调递增的控制授权代际号，控制权一换旧代即失效）和 conflict keys 来把浏览器工作区当作受管资源治理，并明确区分浏览器本地隔离、工作区控制权与业务数据冲突三件不同的事。
🔑 核心要点
- 独立 profile 只隔离了浏览器数据：一个被委托的 agent 在任务中途被主人收回控制后，它那迟到的浏览器操作还能不能执行，目录结构根本回答不了——需要系统里有一份权威的「当前谁控制」记录
- lease 提供独占限时的访问权保证人与 agent 不同时写同一 slot；epoch 是单调递增的授权代际号，控制权易手后旧代际的迟到操作会被判定为过期而拒掉
- 两个独立浏览器仍可能改同一份服务端资源：分开的 cookie 与下载目录挡不住同一账号改同一条产品记录，故还需 conflict keys 协调已知共享资源
- 跑浏览器与显示浏览器是两件事：Chromium 跑在私有 Weston 桌面上、viewer 经用户显式动作才单独打开，让人能登录真实工作区却不必把密码和 TOTP 种子交给 agent
- 作者刻意划清边界：独立 profile 并不是对宿主机上一切本地进程的安全边界，且当前核心模型比可见应用走得远——还缺一条被完整测试过的端到端流程
💡 金句
一个浏览器智能体需要的远不止一个浏览器——它需要一个无歧义的工作区，以及一个可验证的、有限的行动权。
👍 0
👎 0
← 返回 dev.to 首页