8 月 11 日我让 AI 帮我登录 5 个 AI 平台千问、硅基流动、智谱、商汤、腾讯云查免费额度。那天一切顺利AI 打开浏览器我输验证码登录AI 接管查数据全程只花了 45 分钟。我把这套流程写成了一个 skill标题就叫「浏览器登录态复用」。8 月 15 日我想再查一次硅基流动的额度。打开同一个持久化浏览器档案页面直接跳回登录页。4 天前写进去的登录态没了。我花了 70 分钟排查挖出三个根因每一个都跟最初以为的不一样。三个根因session cookie 的设计就是关闭即清。腾讯云的登录态 cookie 叫nodesess它的is_persistent字段是 0意思是「浏览器关闭时清除」。这是浏览器标准行为不是 bug。我之前以为「持久化档案」能保住所有 cookie错了。Chrome 自动升级会换掉 cookie 加密密钥。8 月 14 日 Chrome 升级了一次二进制文件修改时间 07:45升级后加密密钥变了8 月 11 日写入的 cookie 用旧密钥加密新版本解不开。WorkBuddy 的「完全磁盘访问」权限会影响 headed 窗口持续性。我为了排查问题预防性放开了这个权限结果 headed 浏览器窗口 20 秒就被系统回收。回退权限后窗口持续 180 秒不消失。修复方案用 playwright 的storageStateAPI。登录后手动导出登录态到 JSON 文件下次打开时注入。这个方案绕过了 session cookie 的关闭即清限制也不受 Chrome 升级影响JSON 文件不涉及加密。腾讯云实测通过跨会话直接进控制台。一句话结论「登录态复用」这件事不能指望浏览器的持久化档案。session cookie 的设计就是关了就清Chrome 升级会换密钥这两个是系统性问题不是偶发 bug。真正可靠的方案是把登录态导出成文件自己管。一、4 天前跑通过的流程先说清楚 8 月 11 日那天发生了什么。我有个项目要实测 5 个 AI 平台的免费 Token 额度。每个平台都要登录控制台查数据手动操作很烦。我想让 AI 替我干。用的工具是 playwright-cli一个浏览器自动化 CLI。核心思路很简单AI 打开一个持久化浏览器档案--persistent我在弹出的窗口里登录一次登录态就存到本地磁盘了。之后 AI 关掉浏览器再重开直接带着登录态不用我再登录。那天下午5 个平台连续登录成功。千问、硅基流动、智谱、商汤、腾讯云每个平台我只需要在输验证码的时候动一下手其余全是 AI 操作。查额度、截图、确认防扣费开关全程 45 分钟。我把这套流程写成了一个 skill叫browser-login-reuse版本 1.0.2。skill 里写了一句核心承诺「登录一次关闭重开登录态仍在」。二、4 天后突然失效8 月 15 日下午 6 点我想再查一次硅基流动的额度。打开同一个持久化档案导航到cloud.siliconflow.cn。页面跳转到了登录页。我第一反应是登录态过期了。但查了一下 cookie 数据库__SF_auth.session-token还在有效期到 2026 年 9 月 10 日。cookie 在但浏览器读不出来。然后我试了腾讯云。同一个档案导航到console.cloud.tencent.com/tokenhub。也跳登录页。5 个平台全试了全跳登录页。4 天前还好好的今天全废了。三、第一个错误归因以为是权限问题我注意到一个变化8 月 11 日之后我预防性放开了 WorkBuddy 的「完全磁盘访问」权限。当时想的是放开权限可能让浏览器跑得更顺。但实际情况反过来。放开权限后headed 浏览器窗口就是有界面的那种需要我在里面输验证码只能持续 20 秒就消失了。窗口一消失我根本来不及登录。8 月 11 日窗口能持续几分钟不消失今天 20 秒就没。中间唯一的变量是权限设置。我回退了权限设置。重试窗口持续 180 秒不消失。问题解决了一半。但这里我犯了一个错误。我当时跟用户说「权限放开后 playwright 能用了」把所有改善都归因于权限回退。后来审查结论时发现这个归因是错的。headless 模式无窗口在权限放开之前就能跑真正让 headless 稳定的是--no-sandbox --use-mock-keychain --password-storebasic这组参数跟权限无关。权限回退只解决了 headed 窗口的持续性问题。教训多个变量同时变化时别急着把所有改善归因到最近改的那一个。时间先后不等于因果关系。四、第二个根因Chrome 升级换密钥窗口能持续了但登录态还是读不出来。cookie 在数据库里但浏览器解不开。我查了 Chrome 二进制文件的修改时间。/Applications/Google Chrome.app/Contents/MacOS/Google Chrome mtime: Aug 14 07:45:36 2026 当前版本: 151.0.7922.1388 月 14 日早上Chrome 自动升级了。Chrome 的 cookie 加密密钥是跟版本绑定的升级后密钥重新生成。8 月 11 日写入的 cookie 用旧密钥加密8 月 15 日的新版本用新密钥解密钥匙对不上。这解释了为什么 8 月 11 日当场登录当场操作成功。同一个会话、同一个 Chrome 版本、同一把密钥加密解密匹配。跨会话 4 天后Chrome 升级了密钥换了旧 cookie 解不开。Chrome 大约每 4 周自动升级一次。也就是说持久化档案里的 cookie 最长只能活 4 周。这不是偶发 bug是可预期的周期性问题。五、第三个根因session cookie 关闭即清Chrome 升级的发现解释了持久化 cookie 为什么解不开。但还有一个问题没回答为什么有些 cookie 明明没有加密问题跨会话也丢了我查了腾讯云的 cookie 属性。真正的登录态 cookie 叫nodesessconsole.cloud.tencent.com | nodesess | is_persistent0 | expires1601-01-01is_persistent0意思是「非持久化」也就是 session cookie。expires1601-01-01是 Chrome 表示「永不过期」的方式但 session cookie 的「永不过期」有个前提浏览器不关闭。浏览器一关闭session cookie 按标准被清除。这是浏览器标准行为不是 bug也不是配置问题。腾讯云的登录态设计就是「关了就得重新登录」。那 8 月 11 日为什么「close → reopen」还能用只有一个解释那次的close没有真正杀掉 Chrome 进程。playwright 的close可能只是关了页面Chrome 后台还在session cookie 在内存里还在。8 月 15 日我用ctx.close()是真正退出了 Chrome 进程session cookie 被清除了。这是最关键的发现。我之前以为「持久化档案」能保住所有登录态实际上 session cookie 从设计上就不持久化。很多平台的登录态 cookie 都是 session 类型的--persistent方案对它们无效。六、修复方案storageState三个根因都找到了。Chrome 升级换密钥session cookie 关闭即清权限影响窗口持续性。前两个是系统性问题不能靠改参数解决。playwright 有一个官方 API 叫storageState。它的作用是把当前浏览器的所有登录态cookie localStorage导出成一个 JSON 文件。下次打开浏览器时把这个 JSON 注入回去就直接是登录状态。这个方案绕过了所有三个问题session cookie 被导出到 JSON 文件里不受浏览器关闭影响JSON 文件是纯文本不涉及加密Chrome 升级不影响注入时用 headless 模式不需要窗口不受权限影响实测验证。我打开腾讯云 TokenHub登录导出 storageState。然后关掉浏览器用 headless 模式重新打开注入 storageState导航到 TokenHub。URL 直接是/tokenhub/models没跳登录页。标题是「模型广场 - TokenHub - 控制台」。控制台内容读到了。跨会话登录态复用跑通了。七、这个过程中学到的几件事第一时间先后不等于因果关系。权限回退后窗口恢复持续我立刻下结论「权限放开导致窗口消失」。但 headless 模式在权限放开前就能跑说明真正起作用的是参数组合不是权限。多个变量同时变化时得拆开测才能归因。第二浏览器标准行为不是 bug。session cookie 关闭即清是浏览器标准不是配置问题也不是工具问题。我花了很久才意识到这一点之前一直在找「为什么 cookie 没落盘」实际上 session cookie 从设计上就不落盘。第三「持久化档案」这个名字有误导性。--persistent持久化的是浏览器档案设置、书签、持久化 cookie不包括 session cookie。但「持久化」这个词容易让人以为所有东西都保住了。实际上 session cookie、sessionStorage 这些「关闭即清」的东西--persistent根本不管。第四Chrome 自动升级是一个被忽视的系统性风险。平时不会注意到 Chrome 升级但它会换掉 cookie 加密密钥。如果你的自动化方案依赖持久化档案里的 cookie每次 Chrome 升级后都会失效。这个问题大约每 4 周发生一次可预期但不可预测具体时间。第五playwright 的 close 行为不等于杀进程。8 月 11 日的close没有真正退出 Chromesession cookie 在内存里还在所以「close → reopen」能用。8 月 15 日的ctx.close()真正退出了 Chromesession cookie 被清。同样是 close行为不同结果不同。不能假设 close 一定杀进程也不能假设它一定不杀。八、踩坑清单5 个全部实测#坑现象解决/结论1session cookie 关闭即清ctx.close()后重开跳登录页cookie 数据库里有但浏览器读不到用storageState手动导出/注入不依赖浏览器的 session cookie 持久化2Chrome 升级换加密密钥持久化 cookie 在数据库里但升级后解不开storageState 是 JSON 文件不受影响用 persistent profile 的需升级后重新登录3WorkBuddy 完全磁盘访问权限影响 headed 窗口放开权限后 headed 窗口 20 秒消失回退后持续 180 秒如遇窗口消失先检查是否放开了该权限推断未做 A/B 对照4--headed是全局选项必须前置agent-browser open --headed不生效窗口仍 headless正确写法是agent-browser --headed open放在 open 前面5AGENT_BROWSER_HEADED1环境变量是错误写法设了环境变量 Chrome 仍 headless正确是--headed命令行标志环境变量写法不知哪来的但没用九、能力边界清单8/15 实测确认能力状态说明headless 浏览器无窗口✅ 可用playwright-core --no-sandbox --use-mock-keychain --password-storebasic --disable-gpu稳定启动headed 浏览器有窗口需要登录✅ 可用默认权限下回退 WorkBuddy 完全磁盘访问权限后窗口持续 180 秒单会话内登录→操作✅ 可用单脚本模式打开→检测登录→操作→关闭跨会话登录态复用storageState✅ 腾讯云实测通过导出 JSON → 注入 → 直接进控制台跨会话登录态复用其他平台❓ 待验证机制通用但平台差异未测Chrome 升级后旧 storageState❓ 未跨升级实测理论不受影响JSON 文件不涉及加密十、成本与数据项数据排查时间约 70 分钟18:02-19:13费用0 元成果确诊 3 个根因 storageState 修复方案 skill 重构 v2.0.0实测验证腾讯云 TokenHub 跨会话 storageState 注入成功判断标准这次「跑通了」 登录态失效根因全部确诊 修复方案实测通过 skill 更新到 v2.0.0。三者齐了才算。十一、诚实的说明这次排查过程中我有过两次错误归因都被审查纠正了。第一次是说「权限放开后 playwright 能用了」。实际上 headless 在权限放开前就能跑参数组合才是关键。权限回退只解决了 headed 窗口持续性。第二次是说「cookie 没落盘」。实际上 cookie 写入了只是写到了 Profile 1 不是 Default而且 session cookie 的设计就是关闭即清不是「没落盘」而是「设计上不落盘」。这两次错误归因的共同点现象观察是对的权限回退后确实改善了、cookie 确实读不到但归因太快了。没有拆开变量、没有查证机制直接把最显眼的相关性当成了因果。报错和现象不是结论是诊断信息。遇到「不能用」把现象原样记下来逐层排除比急着下结论有用得多。这句话 8 月 13 日那篇手记里也写过这次又犯了一遍。十二、skill 更新browser-login-reuseskill 从 v1.0.3 重构到 v2.0.0。主要改动主方案从playwright-cli --persistent改为playwright-core storageState两层方案同会话用--persistent跨会话用storageState三个确诊根因写入排查表标注置信度新增模式 A/B/C 完整代码示例安全红线补充storageState 文件含 session cookie不提交 Git已 push 到 GitHubcommit 3e005df。所有结论均有工具实证支撑标注了置信度。跨会话复用方案仅腾讯云实测通过其他平台待验证。Chrome 升级对 storageState 的影响未跨升级实测理论推断不受影响。本文使用 AI 辅助创作AIGC 辅助所有技术结论均经工具实测验证。