企业官网建设流程全解析

很多浏览器 Agent 在演示环境里很稳，一进多租户后台就开始出现“登的是 B 账号，提交的却是 A 组织草稿”的事故。⚠️ 问题不在 DOM 识别，而在浏览器本地状态没跟任务边界一起清空。Cookie 已刷新，页面却仍会从旧的localStorage、IndexedDB和草稿缓存里恢复出旧租户上下文。🧠

这类问题容易误导排障团队。🔍 日志里常见的是按钮点对了，真正写入数据时才暴露组织选错和草稿串用。对浏览器 Agent 来说，本地存储不是辅助信息，而是与账号同等级的执行前提。🔁

浏览器本地存储为什么会把 Agent 带进串租户事故

很多执行器只会清 Cookie，却默认同域下的其他状态天然安全。📌 现实正好相反：localStorage会记住组织、筛选器和草稿 ID，IndexedDB会保留离线数据，Cache Storage还可能回放旧接口结果。复用同一个 browser context 时，新租户就会踩着旧状态继续执行。🧩

更麻烦的是，这种污染通常不会立刻报错。🚨 页面标题、URL 和按钮文本都可能正确，只有进入编辑、审批或导出阶段时，残留状态才把任务拐弯。很多团队以为是模型理解错页面，实际是工程层没有证明“当前状态属于当前租户”。🛡️

一组回放实验把 Cookie 清理和状态隔离的差距拉开

这次回放了48条真实浏览器任务，覆盖文章发布、审批处理和报表导出。🧪 基线方案只清 Cookie；方案二为每个任务新建 context；方案三复用 context，但为每个租户分配独立storage namespace，并只恢复白名单快照。📊 结果说明，账号切换成功不等于状态已经隔离成功。✅

真正有效的不是“清得更猛”，而是“恢复得更准”。🛠️ 全量清空会把登录后必须保留的偏好一起抹掉；只清 Cookie 又会留下最危险的同域残影。把状态分成租户级、任务级和临时态，再按白名单恢复，成功率和时延才能站住。📦

typeSnapshot={tenantId:stringlocal:Record<string,string>}functionrestoreSnapshot(currentTenantId:string,snapshot:Snapshot){if(snapshot.tenantId!==currentTenantId){thrownewError('tenant mismatch')}localStorage.clear()for(const[key,value]ofObject.entries(snapshot.local)){if(key.startsWith('draft:')||key.startsWith('tenant:')){localStorage.setItem(key,value)}}}

工程上真正该补的是 Storage Namespace 和 Session Snapshot

更稳的做法，是把浏览器状态治理成显式契约。⏱️Storage Namespace回答“数据属于哪个租户、哪个任务”；Session Snapshot回答“哪些状态允许恢复”。进入关键动作前，执行器至少要校验一次租户徽标、草稿 ID 和页面回显是否与快照一致，否则宁可回退重开，也不要带着脏状态继续提交。📍

另一个常被忽略的点，是清理动作也需要生命周期管理。⭐ 用户取消任务、浏览器崩溃重连或人工接管后，旧快照如果没有及时失效，下一次恢复仍会复活过期状态。更成熟的链路会给快照附上tenant_id、task_id和过期时间，并把“命中过期快照率”纳入监控。这样浏览器 Agent 才具备可审计的状态边界。📈

未来 3 到 6 个月 浏览器 Agent 会更依赖状态快照治理

接下来更值得投入的，不是继续给模型塞更多页面截图，而是把账号、页面和本地状态收敛成同一条证据链。📌 一旦系统能回答“当前租户是谁、当前草稿从哪来、当前缓存是否仍有效”，浏览器 Agent 的可用性才会跨过演示阶段。串租户事故的根因不是模型不会点，而是工程层没把本地状态当成一等公民。你们的浏览器 Agent，会在恢复草稿前校验storage fingerprint和租户回显吗？