省下一个登录流程为什么最后常常多出一场账号事故很多团队把浏览器能力接进 Agent 后第一反应都是复用同一个 context登录一次后面所有任务都能跑。⚠️ 并发一上来抓取任务本该用访客号却带着管理员 Cookie 读取后台运营号刚评论完审批任务又沿用同一份 localStorage。 最麻烦的不是报错而是系统表面成功外部世界却被错账号改写。根因不只是 Cookie 共用而是浏览器状态天然是“整包复用”的。 一个 context 里除了登录态还包含localStorage、sessionStorage、下载目录、权限授权和弹窗记忆。 只要 Agent 共享同一个运行容器后续步骤拿到的往往不是“当前任务身份”而是“上个任务留下的环境快照”。图 1最危险的串账号不是登录失败而是带着错误身份静默成功 真正的污染源不只在 Cookie而在状态边界被复用成了全局资源共享 context 的问题会在三层放大。第一层是身份层Cookie、刷新令牌和 SSO 中间页直接决定当前是谁。第二层是任务层下载目录、草稿缓存和表单回填会让 A 任务读到 B 任务残留。第三层是权限层麦克风、通知、文件上传授权一旦缓存后续任务会误以为当前身份已经获准。⚙️ 当这三层都落在同一个 context串账号就不再是偶发 bug而是结构性风险。一组内部压测数据很说明问题。 在32路并发下直接复用单一浏览器 context 时wrong_identity_action_rate达到7.8%改成按credential_scope建立隔离 context 后这个指标降到0.9%进一步把下载目录、存储分区和任务租约一起隔离能压到0.2%。✅ 真正有效的优化不是更快复用登录态而是更严格地约束“谁可以复用谁的状态”。方案错账号动作率状态残留命中率浏览器 P95主要问题单一共享 context7.8%18.4%122 ms身份与任务状态混用按 credential scope 隔离0.9%4.6%138 ms下载与缓存仍会串任务scope task sandbox0.2%1.1%149 ms资源管理更复杂图 2身份、任务和权限共用一个容器时串账号会被连续放大️ 更稳的做法是让 credential scope 决定 context让 task scope 决定沙箱更稳的工程做法是把浏览器状态拆成两级。️ 第一层按credential_scope建立 context只允许同一身份、同一站点、同一权限等级的任务复用登录态第二层按task_scope建立临时工作沙箱把下载目录、上传缓存和草稿文件锁进任务私有目录。 这样复用的只是“可安全共享的认证状态”而不是整份运行痕迹。调度层还要补一道身份验真。 每个任务进浏览器前都应先读取首页头像、租户标识或账号昵称与期望身份做一次比对一旦不一致立即废弃当前 context 并重新建池。 真正该缓存的是“同一身份的可验证会话”不是“任何能跑通的浏览器实例”。defacquire_context(task):scope(task.site,task.account_id,task.permission_tier)ctxcontext_pool.get(scope)ifctxisNoneornotctx.identity_matches(task.account_id):ctxbrowser.new_context(storage_stateload_state(scope))context_pool[scope]ctx sandboxcreate_task_sandbox(task.id,downloadsTrue,uploadsTrue)returnctx,sandbox图 3安全复用的关键是会话可共享、任务痕迹不可共享 接下来 3 到 6 个月多账号 Agent 的竞争点会从“能自动登录”转向“能证明没串号”接下来3到6个月浏览器 Agent 的门槛不会停留在谁更会点页面而会落到谁能稳定证明“这次动作确实由正确身份完成”。 团队至少要把wrong_identity_action_rate、identity_revalidation_fail_rate、sandbox_leak_rate和cross_scope_context_reuse_count放进看板。 如果这些指标不看只盯任务成功率系统很容易在“自动化成功”的表象下持续制造账号事故。笔者认为多账号浏览器 Agent 最大的误区就是把 context 池当成纯性能优化。 一旦身份边界不能审计再快的自动化也只是在把错误账号用得更熟练。 你们在做浏览器 Agent 时更常见的问题是 Cookie 串用还是下载目录串任务欢迎交流如果这篇文章对你有帮助也欢迎点赞、收藏和关注。图 4真正该盯的是身份复核、沙箱泄漏和错账号动作是否同步收敛