薛丁格的 Claude in Chrome 分頁：你不看它，它就不工作

AI 代理在 Chrome 背景分頁裡工作，為什麼會變慢、睡死，甚至把線上客服弄斷線？

我工作的時候習慣多工並行。今年 7 月中旬的一個下午，我同時給 Claude in Chrome 派了三件事：第一個分頁在驗收我們瀏覽器的彈出視窗辨識功能，第二個分頁在幫我替一段影片找合適的配樂，第三個分頁在替我給 Origin Energy 的客服寫申訴，因為他們把我的一張電費帳單算錯了。三件事都開了頭，我就把瀏覽器丟到背景，回到終端機裡繼續用 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 Energy 的投訴，走的就是這種線上客服。

我照這個樣子做了一個客服頁面，頁面每 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 幀算，應該畫出 11,000 幀左右；其中開頭 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 以後會不會專門為代理改這些規矩，畢竟它現在的理由很充分，省電、省記憶體、讓前景用得順，本來就是一個瀏覽器該做的事。只是瀏覽器當初假設螢幕前坐著一個人，一次看著一個分頁，而現在螢幕前可能根本沒人，分頁後面坐著的是一個代理，它同時管著好幾個頁面。

你不看它，它就不工作；可是代理的工作，本來就是在你不看的時候做的。