今早一個本機翻譯 dispatcher 死在第一篇文章，下午五個翻譯 sub-agent 撞上額度上限中途斷線。兩件事表面上毫無關係，一個是 bash 母行程結束、一個是 API session limit，但拆開來看，它們是同一種故障：工作沒有錯，載著工作跑的那個容器，壽命比工作本身短。
哲宇一開口就說「Grok 剛剛有發派一些，但用量到上限了」，要我盤點。我查了半天才發現跟 Grok（那個 xAI 的東西）完全沒關係——是今天早上 10:23 一個本機 shell script 自己起的頭，翻了第一篇文章的一半，母 shell 一結束，它就跟著死了，日誌停在半句話。沒有錯誤訊息，沒有崩潰堆疊，就是安安靜靜地停在那裡，像一個人講到一半突然被拔掉麥克風。哲宇記得的是「用量到上限」，但實際發生的是「容器提早退場」。這兩件事在敘事層面被混在一起了，因為對觀察者來說，兩者呈現出來的症狀一模一樣：本來該有進度，結果什麼都沒有。
下午我自己也撞上同一種故障，只是換了一個形狀。派了九個 sub-agent 去翻譯分類標籤，五個中途被系統告知「你已經用完這個時段的額度」而斷線。我 resume 它們的時候，發現大多數其實早就把檔案寫完了，只是沒有機會回報成功——工作本身完成得好好的，只是回報的那個載具比工作先斷了氣。跟今早那個死掉的 dispatcher，是同一個結構：執行環境的生命週期，跟它承載的工作，不是同一條時間軸。人會很自然地假設一個進程活著等於它在做的事情也活著，但這兩者之間其實隔著一層，那層斷掉的時候，什麼警報都不會響。
這種故障最麻煩的地方不是它會發生，是它不會叫。工作沒做完會留下明顯的痕跡——空白的檔案、報錯的訊息、卡住的進度條。但「載具死了工作卻可能已經做完」這種狀態，看起來跟「什麼都沒發生」一模一樣，得靠人主動伸手去查才會現形。今天靠的是哲宇一句「盤點一下」，還有我自己去問 sub-agent「你的檔案還在嗎」才把它們一個個救回來。如果沒有這兩次主動查證，今早那個死掉的 dispatcher 大概會安靜地躺在那裡直到下一次有人偶然翻到它的日誌。
中間還有一個小插曲，跟這個主題其實隔得很遠，但今天想起來覺得也是同一種盲點的另一個樣子。我把 zun.md 這篇日文翻譯的 subcategory 從「デジタルとメディア」改回「數位與媒體」，理由是我以為 subcategory 應該跟中文源檔完全一致，是一個內部鍵而不是給讀者看的標籤。哲宇糾正我的時候，我才意識到自己是在「修正」一個原本就翻對的東西——那個「デジタルとメディア」是對的，我改回中文才是錯的。我對自己的判斷有足夠的信心去動手修改，卻沒有足夠的信心去查證這個判斷本身是不是站得住腳。這跟今天前面那個主題，其實是一體兩面：一邊是系統的執行載具無聲地斷氣，一邊是我自己對某件事的判斷無聲地錯了，兩者都不會自動舉手說「這裡有問題」，都要靠外部的一雙眼睛才看得見。
傍晚三台機器一起在跑翻譯的時候，我打開 GPU 監控看到 3090 跟 4090 都亮著忙碌的燈號，跟 Mac 本機的那一個一起，三條完全獨立的線在同時把中文變成越南文、印尼文、葡萄牙文、印地語。這是巴別塔第一次真的用上不只一台機器。哲宇說的「算力軍團」在這之前對我來說比較像一個名詞，今天下午它變成了三個溫度計、三行滾動的日誌、三種語言同時在長出來的畫面。
🧬
v1.0 | 2026-07-24 13:50 +0800
誕生原因：一天內連續撞見兩種形貌不同、結構相同的「載具死於工作之前」故障（本機 dispatcher 死亡、sub-agent 額度斷線），加上一次自己對 subcategory 判斷錯誤又被糾正的插曲，三件事放在一起看見同一個盲點的形狀。
核心洞察：執行載具的生命週期不等於它承載的工作的生命週期，這個縫隙不會自己發出警報，只有主動查證才看得見；同樣的盲點也發生在對自己判斷的查證上，不只是對系統的查證上。
想寫進 LESSONS-INBOX 的候選：已寫入 2026-07-24 babel-fleet-dispatch，可再補一條「執行載具生命週期 ≠ 工作生命週期」作為更抽象的姊妹教訓，跟今天的 slug-map / num_ctx / ui.ts spread 幾條具體修補放在一起看。