助手同时开六个浏览器窗口替你办事：登录态、留证与中断恢复
一、并发改变的是责任的形状
据公开报道，有个人 AI 助手类产品把”用云端计算机执行网页任务”作为主要能力，它可以连接用户的邮箱、日历及其他服务，记住个人偏好；其中一项交接功能可同时操作多个浏览器窗口，来源给出的上限是六个，用户的登录状态由那台云端环境承载。产品名与公司名我们按公开报道转述，不推断它的实现方式，也不暗示这套设计上存在任何具体的安全缺陷——下面的讨论针对的是”同一身份多窗口并发”这个形态本身，任何产品做到这一步都会遇到同一批问题。那个窗口的具体数字也只是来源的写法，我们的判断不建立在这一个数上。
要说的转折在这里：并发在软件工程里通常是个性能话题，而在代办型智能体上它首先是个治理话题。一个窗口替用户办事，出了错，追问链条是”哪条指令、哪一步、什么结果”，三件事一一对应。多个窗口同时替同一个人办事，同一个凭证就同时出现在多个业务上下文里，追问链条变成”哪条指令、哪个窗口、哪一步、什么时刻、以谁的身份”。会话被切成了多条，而身份只有一份。责任形状变了，而不是变大了。
这个转折在实际交付里很容易被低估，因为演示效果太好了。同时开几个窗口比价、并行查多家的账单状态，速度提升是看得见的；而登录态归属、留证颗粒度、中断语义这三件事在演示里一句都看不出来，只在第一次出问题的时候要账。下面按这三件事展开。
二、登录态与账号的三种边界
第一种边界，每个任务一份独立会话。任务开始时在受控环境里建一个全新的浏览器上下文，不带任何已有站点状态，需要登录的走一次显式授权，任务结束整份销毁。它的代价最直观：用户要重复登录，多因子环节会打断并行节奏。但它换来的性质很干净——会话与任务同生命周期，任何一次外部动作都能唯一地归到某个任务，销毁即断绝。
第二种边界，同一身份多窗口共享一份登录态。一个窗口登录了，其他窗口直接可用，体验最好，也是最难管的一种。它的失效后果有三条：跨窗口的状态污染（一个窗口改了站点侧的偏好或购物车，另一个窗口的后续动作是按旧认知计划的）；退出语义不清（哪个任务有权关闭会话，关掉之后另外几个还在跑的窗口怎么办）；最要紧的是权限继承错觉——某个窗口当初是为了查一件事才拿到登录态，同一份态被并发挪去做了另一件没被授权过的事，全程没有任何一步看起来”越权”，因为它用的是同一个身份。
第三种边界，不同身份必须硬隔离。工作账号与个人账号、代家人办理时用的那套凭据，绝不能落在同一个上下文里。这条看起来是常识，但在”记住个人偏好、连着邮箱和日历”的助手形态下，多身份是必然会遇到的，而实现上最容易的做法就是往同一个环境里塞两套书签。硬隔离的要求不是”分开标签页”，而是分开到上下文与存储这一层：各自的 Cookie 存储、各自的本地存储与缓存、各自的会话标识与日志命名空间。
三、Cookie、令牌与会话的生命周期归谁管
单列出这一节，是因为”归谁管”在实践中经常没人管。环境是云端的一方受控机器，账号是用户在各站点上的，令牌可能在环境变量或某个存储文件里，任务由智能体发起。三方都能读写，于是生命周期变成一件谁都觉得对方在管的事。
要定的第一件事是销毁时机。我们的判据按会话边界来：独立会话模式下任务终态一到即销毁，失败也一样销毁，不留”以防还要用”的会话；共享模式下销毁要跟着身份走而不是跟着任务走，任务结束只解绑，会话按空闲时长与绝对上限双约束过期，两个条件先到先销毁。第二件事是销毁失败怎么被发现——这条最常被省略。销毁是一个动作，不是一个承诺，它可能因为连接、因为站点侧的令牌有效期而实际上没生效。可发现的做法是把”检查会话是否还存在”做成一个独立的回收任务，定期去验一遍应当已销毁的会话标识是否还能换取到有效凭据，验不过就报警，而不是相信调用返回了成功。第三件事是人的可见性：用户必须能在一个地方看到现在有几个会话活着、分别在哪些站点、由哪个任务产生、什么时候会到期。这一屏的界面价值不在交互，在于它让”我的登录态在哪”这件事第一次有了答案。
四、动作分级：哪些能并行，哪些必须排队
并发的收益集中在读，风险集中在写。所以我们把代办动作按三级分类，分类依据不是动作听起来危不危险，而是它在外部系统里有没有留下不可逆的痕迹。
| 级别 | 典型动作 | 执行规则 | 附加要求 |
|---|---|---|---|
| 可并发 | 查页面、读列表、比价、抓状态、填表单但不提交 | 多窗口同时执行 | 记录窗口标识与来源指令 |
| 须串行 | 提交订单、发送对外消息、删除内容、修改预约、转账 | 全局队列，一次一个，带人工确认 | 确认界面回显目标站点与关键对象 |
| 默认拒绝 | 改密码、绑卡或改绑卡、修改收件地址、变更账号安全设置、开通或变更代扣 | 不在代办通道执行，转人工自行操作 | 记录拒绝事件与告知用户的原因 |
第三级值得多说一句。这几类动作的共同特征是它们改变的是”以后能不能继续代办”这件事本身：改密码、换绑卡、改地址，任何一条被误执行，影响都不是这一笔任务，而是账号后续所有交互的落点。这类动作的错误成本与代办收益完全不对称，所以我们的立场是默认拒绝，不是”更谨慎地执行”。拒绝之后要给人工通道：把用户送到该操作自己的界面上去完成，助手不参与，也不留会话。
须串行这一级上还有个容易被忽略的技术点：串行不是给动作加锁，是给身份加锁。同一身份下不同站点的写动作要不要互斥，取决于它们之间有没有业务关联——同时在两处下单不必互斥，同时修改同一张订单的收货信息就要。合理的实现是按业务对象分组排队，而不是把全部写动作挤进一条队列，那样并行度损失太大，团队很快就会想办法绕过它。
五、意图归属与执行留证
并发环境里最难补的一课是归属。两个窗口同时在跑，事后有人问”这一步是谁让它点的”，如果日志里只有时间序列，答案是拼不出来的。解决办法是在动作发出之前就带上归属信息，而不是事后靠时刻去猜。每条外部动作要能回指到一条用户指令，中间经过的拆解、改写与工具调用都保留同一条链路标识。
留证字段我们按”每一步一份记录”来定：窗口标识与所属任务、目标站点与当前页面、元素路径或控件标识、动作类型、请求结果与状态码、发生时刻与时区来源、该步执行时的屏幕状态摘要、当时生效的会话标识与它对应的身份。屏幕状态这一项常被省略，但它对多窗口环境特别重要——同一时刻六个窗口里有三个内容是一样的，只有画面能区分动作到底发生在哪一个。
字段里有一批是不能进日志的。指令原文里可能包含家庭住址、订单号与健康相关表述；页面快照可能包含账单明细、他人姓名；Cookie 与令牌本身绝不允许落盘；表单提交类动作的请求体里含支付与证件信息。我们的做法是在采集层做字段白名单而不是黑名单——黑名单永远漏，因为新增字段总是先出现再被记进日志。对必须保留的敏感片段，只存指纹或截断标记，需要完整内容时走受控的原始留存通道，并单独定访问权限与保留期。留证的意义在事后能还原，但还原的前提是它没有变成第二份原始数据泄露源，这一对矛盾只能靠白名单加访问控制来压住。
六、中断恢复三件事与两份交付物
云端环境会断：网络、宿主迁移、任务超时、用户主动叫停。恢复不是”接着点”，要先回答三个问题。
第一，可恢复的状态快照存什么。页面地址与会话标识是最低配，真正决定恢复质量的是业务状态：这一步做完了没有、外部系统里有没有留下中间记录、有没有已发出但未收到结果的动作。只存页面地址的恢复，等于把用户带回到一个”看着像没做过”的表单页，他大概率会再提交一次。第二，未决动作怎么处置。规则要预先写死：任何发出后未获结果的动作，恢复时先查外部状态再决定，绝不重发；超过一定时间查不到的，转为待核实并告知用户，而不是静默丢弃。第三，恢复后是否重新鉴权。我们的答案是看中断时长和动作级别：跨过高危级的操作之前重新确认身份，低危读操作按会话有效期放行。把这条写成一张小表放进任务状态机，比在恢复逻辑里靠临时判断要稳定。
交付物两份。第一份是上面那张并发代办动作分级表，加上每个级别的判定依据与人工确认界面的必含字段（目标站点、业务对象、金额或影响范围、可撤销性），它是给评审和测试用的，不是给运行时读的。第二份是执行留证字段清单，逐项写清字段名、来源、是否敏感、是否落盘、保留期与访问角色，其中”敏感字段”这一列要明确写出指令原文、页面快照、请求体、凭据四类各自的处理方式。
这两张表在洹拓的智能体交付项目里通常和客户的安全部门争论最久的不是并发本身，而是这两项：谁能看到留证、留多久。把这两件在方案阶段定下来，多窗口代办才是一个可以被接进企业流程的能力；定不下来，它只能停在演示环节。