薛定谔的 Claude in Chrome 标签页：你不看它，它就不干活

AI 智能体在 Chrome 后台标签里干活，为什么会变慢、睡死，甚至把在线客服弄掉线？

我在工作的时候习惯于多任务并行。今年 7 月中旬的一个下午，我同时给 Claude in Chrome 派了三个活：第一个标签在验收我们浏览器的弹窗识别功能，第二个标签在帮我给一段视频找合拍的配乐，第三个标签在替我给 Origin 能源的客服写申诉，因为他们把我的一张电费账单算错了。三个活都开了头，我就把浏览器丢到后台，回到终端里继续用 Claude Code 管我的 AI 开发团队，这本来就是我想要的干活方式，几个智能体各干各的，我不用一个个盯着。

结果过了一会儿我切回浏览器一看，三个任务里只有一个在正常往前走，另外两个跟睡着了一样，我又等了一阵、来回切了几次标签，还是那样。

一般人碰到这种事，第一反应多半是网卡了，或者模型今天反应慢。可网和模型要是有问题，三个任务应该一起慢才对，偏偏只有一个在动，这就说不通了。我做了很多年浏览器，脑子里马上冒出另一个判断：后台标签被 Chrome 降速了。

这其实算不上 Chrome 的毛病，浏览器本来就该这么干。你不看的页面没理由占着 CPU 全速跑，一个人经常同时开着几十个标签，要是每个都不分前台后台地全速跑，笔记本的电池半天就耗光了。可问题在于，浏览器里的页面现在已经不只是给人看的了，AI 智能体也在里面干活。对人来说，后台那个标签暂时没用；可对智能体来说，那个标签可能正在替你等一个下载、办一笔退款，或者守着一个不能断线的在线客服，人不看它，不等于它不用干活。

浏览器的规矩是给人定的，智能体住进来以后就处处不合身。

7 月 16 日，我先手工测了一下，确认确实是这个问题。也正是从那天起，我们决定给 Embiody 智能体专用浏览器增加一个功能，“AI 标签”。最近我把当时的测试重新系统地做了一遍，想弄清楚三件事：Chrome 到底会把后台标签放慢到什么程度；Chrome 在什么情况下会把一个页面整个冻住；还有最麻烦的一件，页面明明还开着，智能体读到的东西会不会已经不对了。测下来的结果，比我一开始想的严重得多。

一、8 分钟过去，页面以为只过了一分半#

我先写了一个最普通的倒计时页面，每秒走一格，写法和网上抢购页、支付页的倒计时一模一样。页面每走一格，就把进度报给本机上的一个小服务器记下来，这样就算页面被浏览器冻住了，服务器那边也还记着真实发生了什么。

我同时开了两份这个页面，一份让 Claude in Chrome 打开，另一份我自己手动打开作对照，然后让这两个页面从眼前消失 8 分钟。消失的办法我试了三种，切到别的标签、拿另一个窗口把它整个盖住、把窗口最小化，三种办法的结果几乎一模一样。

页面刚消失的那一分钟里一切正常，倒计时还是每秒走一格；过了大约一分钟，倒计时就变成了每一分钟才走一格。8 分钟以后，现实里已经过了 480 秒，页面却以为只过了 90 秒左右，整整落后了 390 秒。这就好比你出门吃了顿 8 分钟的早饭，回来发现家里的钟只走了一分半，而且等你回到窗口前，倒计时虽然马上恢复成每秒一格，丢掉的那几分钟却再也补不回来了。

更要紧的是，Claude in Chrome 打开的页面和我手动打开的页面表现完全一样，前者落后 387～391 秒，后者落后 392 秒。这说明问题根本不在 Claude 身上，只要一个页面开在 Chrome 里、又没人看着，它就会变成这样，不管是谁在 Chrome 里跑智能体，都躲不开。

（测试环境：Windows 11，Chrome 157.0.8103.39，Claude 扩展 1.0.106，2026 年 11 月 11 日，同一台机器，每种情况跑 1～2 次。）

可这样一来就有个说不通的地方了：Claude in Chrome 的标签几乎一直待在后台，要是后台标签一分钟才动一下，它岂不是什么活都干不成？可它明明能把活干完啊，这又是怎么回事？

二、只有智能体手上那个标签醒着#

为了弄明白这一点，我换了一个更像真实任务的测试页面，上面放了两种网站上最常见的等待。第一种是下载，页面写着“下载将在 90 秒后开始”，倒计时走到 0，下载按钮才能点；第二种是导出，页面写着“导出处理中”，每 2 秒问一次服务器好了没有，服务器在 90 秒后回答“好了”。

然后我让 Claude in Chrome 同时干两个这样的任务，一个放在标签 A，一个放在标签 B，它先去忙 A，B 就留在后台没人碰。结果是这样的：

本来 90 秒的等待，硬是拖成了六七分钟，这就是我 7 月那个下午碰到的事。智能体其实一直在干活，只不过它手上始终是 A，B 就在后台一分钟一格地慢慢挪，等它终于回头去看 B，本该早就结束的倒计时还在走。这还算运气好的，要是智能体一直不回来看 B，按每分钟一格算，这个 90 秒的倒计时得走将近半个小时。

奇怪的是，导出那一项几乎没受影响，服务器 90 秒时回答完成，智能体只晚了 3 秒就发现了。同样是在后台等，Chrome 为什么只对下载的倒计时下手，却放过了导出？

区别出在两种等待的写法上。倒计时是自己给自己定闹钟，这一秒的闹钟响了再定下一秒的，下一秒的响了再定下下一秒的，一环套一环；导出是等别人回电话，问一次服务器，等服务器回了话才约下一次，每一次都是从别人的回话重新开始的。Chrome 有一条规矩专门管一环套一环的闹钟，页面看不见一阵子以后，这种闹钟一分钟只许响一次，所以倒计时慢了，而等回电话的导出不归这条规矩管。

所以后台降速并不是让整个网页一起变慢，网页里是怎么写的，决定了它慢不慢。可这还不是最糟的。

三、20 秒后，页面整个睡死#

前面那种慢，好歹还能等，接下来这个才真把我吓了一跳。Claude in Chrome 新开的标签默认放在后台，排在你正在看的那个标签后面。我让它新开一个测试标签，打开之后谁也不去碰，结果才过了 20 秒，页面就整个停住了，倒计时不是一分钟走一格，而是一格都不走，一直到智能体回来操作它才醒过来。这种情况我前后见了四次，每次都在 20 秒左右，而且浏览器窗口明明就摆在屏幕上，既没被挡住也没最小化。

窗口就在眼前，里面的页面为什么会突然停死？我又用普通办法在后台开了同样的标签作对照，它放了 3 分钟也没停，只是降到一分钟一格，所以这 20 秒肯定和 Claude in Chrome 有关。我盯着标签栏看了一阵，终于找到了原因：智能体最后一条命令做完大约 20 秒，Claude 的那个标签组会自己折叠起来，而标签组一折叠，组里那些从来没显示过的标签就被 Chrome 冻住了。

这两件事单拎出来看都挺合理的。Claude in Chrome 不想让自己开的一堆标签一直占着你的标签栏，所以一闲下来就把组收起来；Chrome 觉得收起来的组就像收进抽屉的东西，你暂时不用，所以干脆给它断电省内存。可两条合理的规矩碰到一起，结果就是智能体在后台开的标签，它一歇口气，标签就全睡死了。

那智能体正在操作的那个标签，总该没事吧？我让智能体同时守着 A、B 两个标签，前 3 分钟每隔 30 秒读一次 A，这期间 A 一直正常在走，没人碰的 B 从第二分钟起就几乎不动了。然后我让它改成读 B，B 一下子醒了，可大概 30 秒以后，刚被冷落的 A 也被冻住了。

这说明智能体操作一个标签，只能让这个标签醒二三十秒，它一转身去忙别的，或者只是停下来多想一会儿，组一折，这个标签就跟着睡过去了。对普通人来说，这不过是浏览器替你省了点内存；可对智能体来说，这事要命得多，因为它根本不知道自己刚离开的那个页面已经不干活了。

四、客服没等到那句 YES#

倒计时被冻住，大不了晚一点；可要是在线客服被冻住，事情就直接办砸了。在线客服、网上银行、考试页面、抢票排队，这些页面都要求你一直在场，它们每隔几秒就悄悄给服务器报一声“我还在”。你设身处地想一下，假如你就是客服那头的人，对面 45 秒一点动静都没有，你会怎么想？肯定当他走了，直接把会话关掉对不对。我 7 月那次给 Origin 能源的投诉，走的就是这种在线客服。

我照这个样子做了一个客服页面，页面每 10 秒向服务器报到一次，服务器 45 秒收不到报到就结束聊天。聊天开始一分钟后，客服发来一句：“查到重复扣费了，回复 YES，今天就给你退。”

这次我还是让 Claude 管两个标签。它先在 A 里把别的活干完，用了一分半钟；然后像平时跑去终端里执行命令那样，一分半钟没碰浏览器；最后回到客服页 B，准备回复 YES。整个过程窗口一直摆在屏幕上，我自己的标签在最前面，Claude 的标签组排在后面，这就是它平时干活的样子，再普通不过。

结果智能体停下来的第 20 秒，Claude 的标签组折了起来，客服页 B 跟着被冻住，报到也就停了。一分多钟以后智能体回到 B，看到的是这么一句：

Chat ended: no check-in from this page for 83 s. Please sign in again to start a new chat.

注意，服务器看的是页面多久没报到，不是聊天开了多久，只要页面一直在报到，放多久都不会断。B 断线，是因为它被冻住以后整整 83 秒没出声。

这时输入框和发送按钮都已经灰了，那句 YES 再也发不出去，客服已经挂了，退款也就没了下文。智能体又没法替你重新登录，这事只能等你自己回来从头排队。我把同样的任务放到 Embiody 里又跑了一遍，智能体同样闲了一分半钟，那边的客服页照样每 10 秒报到一次，始终显示 Connected，YES 顺利发了出去，客服回了一句“Done, the refund is on its way.”

有人可能会问，前面不是说等服务器回话的写法不怕降速吗，客服的报到就是这种写法，怎么还会掉线？没错，光是降速的话，客服页照样能每 10 秒报到一次，真正把它弄断的是冻结。降速只是把自己定的闹钟改成一分钟响一次，冻结却是把整个页面断电，页面里的程序全部停下，闹钟也好、等回电话也好，什么写法都不会再动，报到当然也就停了。

那让扩展别折叠，不就行了吗？其实扩展也只在一种情况下折叠：窗口最前面显示的是你自己的标签。我试过把 Claude 的标签组单独挪到一个窗口里，这个窗口最前面显示的就是 Claude 自己的标签，扩展就不折叠了，客服页只是被降速，连续 11 分钟都没掉线。可平时谁会专门给它单开一个窗口呢，它的标签组就建在你正在用的那个窗口里。

替 Claude in Chrome 想一想，这是个两难。它和你共用一个浏览器、一个窗口，要是不折叠，它开的标签就一直摊在你的标签栏上，碍着你干活；要是折叠，Chrome 就按自己的规矩把里面的标签冻住。折叠是扩展自己的产品设计，冻结是 Chrome 定的规矩，扩展只能改前一个，改不了后一个，何况就算它不折叠，它的标签照样排在你的标签后面，照样看不见，照样被降速。

只要智能体还借住在给人设计的浏览器里，这就是一个死局。可智能体又离不开浏览器，因为网站本来就是给人用的，人和智能体在同一个浏览器里、用同一批网站一起干活，已经是一个趋势了。

（2026 年 11 月 12 日，Chrome 157.0.8103.51，扩展 1.0.106，各跑 1 次。）

五、页面以为有人在看，其实没人在画#

如果事情到这儿就完了，问题已经够大了，可我还发现了一个更隐蔽的。这一回页面没被冻住，计时器一秒不差，页面自己也认为自己是可见的，可它的画面几乎就没在动。

我做了一个带两根进度条的页面，绿色那根按时间走，每秒走一格，红色那根按浏览器实际画出来的画面帧走，每画出一帧就前进一点。我让 Claude 在后台标签里操作这个页面两分钟，先点一下播放音乐，然后每隔 10 秒往下滚一次列表、读一次页面，最后我把这个标签切到前台来看。

切到前台那一刻，绿条已经走满，红条才走了一小截。计时器显示过了 184 秒，画面只画了 600 来帧，正常按每秒 60 帧算，应该画出一万一千帧左右；其中开头 100 秒只画了 387 帧，平均每秒不到 4 帧，人看着就跟放幻灯片差不多。页面以为自己被看着，其实渲染进程没有在画它。

画面画得慢，又能有多大事？很多网站喜欢用动画来展示数据，比如企业官网上那个“已服务 98,765 家企业”，一打开就从 0 一路往上滚，两三秒才停在最终的数上。可要是智能体在后台打开这种页面，画面根本没在画，数字就可能卡在半路上。

我照这个样子做了一个 3 秒从 0 滚到 98,765 的页面，让 Claude 在后台新开它，先去忙别的，10 秒以后再回来读这个数。结果是这样的：

Chrome 那边三次读到三个不同的数，原因是这个页面一直藏在后台，一帧都没画过，数字始终停在 0；等智能体回来读的那一刻，扩展把页面弄成了“看得见”，数字这才开始往上滚，可智能体又不会等它滚完，读到的自然是滚到一半的数。这就好比你给一个正在跑步的人拍照，咔嚓一下，拍到的永远是他跑在半路上的样子。

最麻烦的是，**智能体不会告诉你它读到的数可能不对。**它不会报错，也意识不到自己看到的是一个还没走完的动画，在它看来页面打开了、数字也读到了，一切正常，只要它只读一次，就会把这个错的数当成事实交给你。这还只是我自己写的测试页面，可想而知，要是让智能体在后台替你抢票、抢秒杀商品，会是什么结果。

（2026 年 11 月 12 日，Chrome 157.0.8103.51，扩展 1.0.106。）

六、薛定谔的标签页#

说到这儿，我想起了薛定谔的猫。在那个有名的思想实验里，盒子打开之前，谁也说不准猫是死是活，Chrome 里智能体的标签也差不多是这样：你看着它，它就好好干活；你不看它，它可能一分钟才动一下，也可能已经被冻住了。智能体操作它的时候，算是打开盒子看了一眼，标签暂时醒过来，智能体一走开，盒子又合上了，而且这一回连盒子都看得见，就是那个会自己折起来的标签组。

智能体同时跑好几个任务的时候，一次只能操作其中一个标签，剩下的都关在盒子里，有的只是变慢，有的已经冻住，有的看着正常、其实连画面都没在动，它们到底处在什么状态，智能体自己并不知道。所以这事不光是快一点慢一点的问题，它关系到智能体交给你的结果到底靠不靠得住。

为了弄清楚背后是怎么回事，我把 Chromium 156 版的源码（表现和我实测的 157 版一致）和 Claude in Chrome 1.0.106 版扩展的代码对着翻了一遍，发现是七条规矩叠在了一起。

七、这七条规矩，到底是怎么说的#

这一节把前面故事里碰到的七条规矩，一条条对着 Chromium 源码讲清楚，写给想刨根问底、或者想自己去源码里核对的朋友。要是你只关心现象，知道“后台标签会被降速、冻住、不画”就够了，这一节可以直接跳过，从第八节“把 Chrome 的限制关掉，行不行”接着往下看，不耽误读懂后面的内容。

1. 隐藏页面里一环套一环的计时器，过了宽限期，一分钟只许醒一次。 Chrome 源码里管这个叫 intensive wake-up throttling，直译过来是“密集唤醒节流”。这是什么意思？就是前面说的自己给自己定闹钟：计时器响了，在回调里再定下一个计时器，Chrome 会数这一串套了多少层，套到第 7 层以后，只要页面已经隐藏了一阵子，这种闹钟就一分钟只许响一次。倒计时正好是这种写法，所以中招；而等服务器回话之后再定的计时器，会从第 1 层重新数起，所以导出和客服报到都不受影响。页面隐藏以后的宽限期一般是 60 秒，智能体在后台新开、从来没显示过的标签也是 60 秒，切到别的标签、窗口被整个盖住、窗口最小化，都算隐藏。另外还有两条轻一些的限制：所有计时器一秒最多醒一次；隐藏 10 秒以后，所有计时器的回调加起来只能用 1% 的 CPU，只有在回调里干重活的页面才会碰上。（third_party/blink/renderer/platform/scheduler/main_thread/page_scheduler_impl.cc；层数在 third_party/blink/renderer/core/scheduler/dom_timer.cc）

2. 标签组一折叠，组里的标签就会被冻结。 组一折叠，Chrome 就替组里每个标签投一票“冻结”，最近 5 分钟内显示过的标签受保护，从来没显示过的当场冻住。冻结的意思是整个页面的程序全部停下来，不是变慢，是不动了，就像前面说的给抽屉断电。（chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc 投票；components/performance_manager/freezing/freezing_policy.cc 决定）

3. Claude in Chrome 闲下来 20 秒左右，就把自己的标签组折起来。 前提是窗口最前面显示的不是它的标签，等下次要干活了，扩展再先把组展开。第 3 条加上第 2 条，就是前面看到的“20 秒睡死”：扩展把组一折，Chrome 就把组里的标签冻住。

4. 扩展会让正在操作的标签以为“有人在看它”。 每次操作之前，扩展都会通过调试协议打开一个叫焦点模拟（Emulation.setFocusEmulationEnabled）的开关。这是什么意思？就是告诉 Chrome“这个标签正被人看着”，于是页面的 visibilityState 变成了 visible，计时器也就不按隐藏页面的规矩降速，哪怕整个窗口是最小化的。操作结束大约 20 秒以后，扩展再把这个开关关掉。

第 3 条和第 4 条放在一起，还能解释一件怪事：智能体最后操作过的那个标签，组折起来的时候怎么有时候没被冻住？我原以为是扩展特意护着它，翻了代码才发现完全是碰巧。组一折，Chrome 给组里的标签挨个发冻结命令，最后操作过的那个标签这时候焦点模拟还开着，它以为自己正被人看着，就把命令拒了；可 Chrome 那头没发现被拒，照样在账上记了一笔“已冻结”，之后再也不发第二次。等焦点模拟一关，这个标签真的看不见了，却再也没人来冻它。

换一种更好懂的说法：宿管晚上查房要求熄灯，你在屋里喊了一声“还有人呢”，宿管在本子上记了“已熄灯”就走了，之后再也不来；等你真睡着了，灯却一直亮着。这个标签能醒着，靠的就是“组折起来”和“焦点模拟关掉”这两件事恰好是这个先后顺序，扩展和 Chrome 谁都没这么设计过。前面智能体从 A 转去读 B 的时候，A 碰上的就是反过来的顺序：A 的焦点模拟先关了，等组折起来，A 已经看不见了，冻结命令一到就生效。

5. 没被真正画到屏幕上的页面，画面帧会降到一秒一次。 焦点模拟能骗过页面，让它以为自己被看着，却骗不了负责画画面的那部分。Chrome 里有个合成服务叫 viz，它按显示器的节奏给每个标签发“开始画下一帧”的信号（BeginFrame），要是一个标签交上来的画面连续 3 帧都没被任何窗口真正画到屏幕上，这个信号就降到一秒一次，源码注释写得很直白：“we throttle BeginFrames to 1 per second”（components/viz/service/frame_sinks/compositor_frame_sink_support.h，kUndrawnFrameLimit = 3）。所以排在后面的标签、最小化窗口里的标签，就算计时器照常在走，页面里的 requestAnimationFrame（网页用来画动画的那个函数）也只能一秒跑一两次。这就像一台摄像机对着舞台，台上演员照演，可摄像机发现没人看直播，就改成一秒拍一张。我测到的每秒不到 4 帧，多出来的那两三帧，应该是扩展截图时顺手画的。

6. 窗口被盖住、被最小化，也算看不见。 在 Windows 上，Chrome 会自己算一个窗口是不是被别的窗口整个挡住了，挡住了就把里面的标签按看不见处理（ui/aura/native_window_occlusion_tracker_win.cc，默认开启）；窗口最小化的时候，整个窗口的合成区域直接变成 0×0（desktop_window_tree_host_win.cc）。

7. 后台的渲染进程也会被降级。 一个渲染进程里要是一个看得见的标签都没有，Chrome 会把它的优先级降到最低，还向 Windows 申请 EcoQoS，也就是让 CPU 用最省电的频率去跑它、把它的活儿排到效率核上，代价就是跑得慢（base/process/process_win.cc，kUseEcoQoSForBackgroundProcess 默认开启）。这一条看的是窗口真实的可见状态，焦点模拟骗不过它。

这七条单看哪一条都合理，可叠在一起，一个智能体的标签就落进了很别扭的处境：页面以为自己看得见，计时器却可能被限着；智能体刚操作过它，过一会儿它却可能被冻住；页面没被冻住，画面却几乎不动。哪个标签醒着、哪个睡了，连写扩展的人也未必说得清。说到底，还是那句话，浏览器的规矩是给人定的。

八、把 Chrome 的限制关掉，行不行？#

有人会想，既然是 Chrome 的规矩惹的祸，那用启动参数把这些限制关掉不就行了？行倒是行一部分，比如 --disable-background-timer-throttling、--intensive-wake-up-throttling-policy=0、--disable-renderer-backgrounding、--disable-backgrounding-occluded-windows，这几个参数能关掉计时器降速和进程降级。但画面帧那一条是关不掉的，一个没被画到屏幕上的标签，不会因为你关了计时器降速，就重新得到正常的画面帧，读到滚一半的数这种事照样会发生。

九、同样的测试，在 Embiody 里是什么样#

我们正在做 Embiody，这是一个专门给 AI 智能体用的 Windows 浏览器，智能体通过专用 MCP BrowserDo 在里面操作网页，Claude Code 和 Codex 一行命令就能接上，Cursor 和 Claude Desktop 加几行配置也能接上。我们给它加 AI 标签这个功能，起点就是 7 月那个下午：我想让智能体同时干好几件事，而我自己该干嘛干嘛。

所以上面这些测试，我在 Embiody 里也按同样的条件跑了一遍，只是把浏览器换成 Embiody、把操作工具换成 BrowserDo，结果是这样的：

在 Embiody 里，任务 B 就算排在后面、没人碰、窗口还最小化着，也照样准时；智能体在后台操作的页面，画面照常在画；统计数字一次就读对了，客服也一直在线。不过这份“不降速”只给智能体正在用的标签，你自己开的那些标签，放到后台照样按原来的节能规矩降速，所以并不会因为装了智能体就让电脑多耗电。盒子里的猫，一直是醒着的。当然，这次只测了一台 Windows 机器，Embiody 每组跑了 1～2 次，算不上大规模的测试，但至少在这几个场景里，差别已经很清楚了。

还得说清楚一点，这些问题不只是 Claude in Chrome 一家的事。不管用哪个扩展、哪个自动化工具，只要智能体在 Chrome 里干活，就得守 Chrome 的这套规矩，开头那个倒计时实验里，我手动打开的普通标签和 Claude 的标签一样，8 分钟都落后了 390 多秒。另外还有两条规矩这次没碰上：一条是电脑内存吃紧的时候，Chrome 会把最久没看过的后台标签整个卸掉，回来要重新加载；另一条是笔记本拔了电源、电量掉到 20% 以下的时候，比较费 CPU 的后台标签会被冻住。人离开一会儿碰上了，回来刷新一下就好；可智能体一跑就是一下午，还同时管着好几个页面，这些事它迟早都会碰上。

十、AI 得有自己的浏览器#

用 AI 干活这几年，我越来越确定一件事：AI 得有自己的浏览器，拿 Chrome 凑合，只是权宜之计。

注意我的用词，我不是说 Chrome 做得不好，恰恰相反，Chrome 这些规矩都是多年打磨出来的，目的就是让坐在屏幕前的人用得更舒服：人看不见的标签就该少占资源，人看不到的动画就没必要一直画，长期不用的页面就该冻住甚至卸掉。扩展能做的，只是在这些规矩外面再糊一层，比如用焦点模拟让页面以为有人在看，用折叠标签组让智能体的标签别挡着你。可规矩是 Chrome 的，Chrome 的架构底子是给人设计的，不从底层改，扩展只能缝缝补补。

前面那个“宿管记了已熄灯”的标签，就是缝补出来的效果，它能醒着，全靠两件事碰巧按这个顺序发生。Chrome 哪天换个版本，这个顺序说变就变，这种碰巧既躲不开，也没法提前知道下一个会出在哪儿，因为 Chrome 压根就不是给智能体设计的。

想不靠碰巧，浏览器的规矩本身就得替智能体着想。对人来说，一个标签看不看得见，决定了它该不该继续占资源；可对智能体来说，一个没人看的标签，可能正在替你办一件停不得的事，屏幕前有没有人，它都该照常干活。这一点只能在浏览器内核里定下来，Embiody 的 AI 标签就是按这个原则做的。

（Embiody 每组跑了 1～2 次，2026 年 11 月 11～12 日，同一台机器。）

我没测到的#

• 只测了一台 Windows 机器、一个 Chrome 版本。7 月手工测的时候，我印象里是 5 分钟后才明显变慢，这次（Chrome 157）是 1 分钟左右，不知道是 Chrome 改了，还是我当时记得不准。
• 没测 Mac 和 Linux，也没测打开“节省内存”之后的情况。
• 内存吃紧时卸掉标签、低电量时冻住标签，这两条只在源码里看到，没有实测。

两分钟自己试一下#

打开 https://embiody.com/lab/background-tab/ ，页面一打开就开始一个 15 分钟的倒计时。你切到别的标签（拿别的窗口盖住它、或者把窗口最小化也行），两分钟后再切回来，看页面上“Behind by”那一栏，就是你不在的这段时间里倒计时丢掉了多少秒；要是显示 0 s，说明页面一直准时在走。测试页是英文的。

最后#

我不知道 Chrome 以后会不会专门为智能体改这些规矩，毕竟它现在的理由很充分，省电、省内存、让前台用得顺，本来就是一个浏览器该干的事。只是浏览器当初假设屏幕前坐着一个人，一次看着一个标签，而现在屏幕前可能根本没人，标签后面坐着的是一个智能体，它同时管着好几个页面。

你不看它，它就不干活；可智能体的活，本来就是在你不看的时候干的。