你的 AI 應該在你睡覺時工作

先看清楚時間花在哪裡

一輪 CLI agent 的工作，節奏幾乎都是同一個樣子：

你講 30 秒 → 它跑 5–20 分鐘 → 它需要你決定一件事 → 重複

把一整天的比例攤開來看，結論會有點反直覺：真正吃掉時間的不是打字。你描述需求那 30 秒是全程最短的一段，之後就是純粹的等——等它讀完專案、等它改完十幾個檔案、等測試跑完。等到它停下來問「這個 migration 要不要順便處理？」，你回一句話，又是下一個五分鐘、二十分鐘。

一天下來，你真正輸出的內容可能不到十分鐘，但被佔掉的是好幾個小時。那幾個小時不是工作，是待命：你什麼都沒做，但你不能走開，因為它隨時會需要你回答一句話。

傳統做法把待命綁死在一台筆電上

問題在於，這種「待命」在預設的做法裡是有實體位置的。agent 跑在你筆電的終端機視窗裡，那個視窗連著那個 shell，那個 shell 連著那台開著的機器。於是你只有兩個選擇：

坐著等。人留在椅子上，眼睛盯著一個大部分時間什麼都不會發生的畫面，只為了在它問問題時能在三十秒內回答。你付出的是一小時，換到的是三句回覆。

或者關掉筆電。合上蓋子，process 被停掉或直接死掉，session 沒了，agent 累積的脈絡——它讀過哪些檔案、改到哪一步、為什麼選了這個做法——一起消失。晚點回來只能重新開一個，把整段重講一次，然後從頭跑。

兩個選擇都是在付同一筆代價。你不是被工作綁住，是被那台機器的所在位置綁住了。

三個零件，各解開一個綁定

這個綁定不是一整塊，它是三層疊起來的，而每一層都有一個已經存在幾十年的標準工具可以拆掉。這三樣東西單獨看都很普通，疊在一起才是重點：

拆解的順序有意義。先有 CLI，agent 才可能離開你的筆電，搬到家裡那台從來沒關過的 Mac mini 上；有了 tmux，那個 session 才會釘在那台機器上，你的連線斷掉它照樣跑；有了 SSH 加 Tailscale，你才能從捷運上、從公司、從別人家的 Wi-Fi 安全地接回同一個 session，而且不用在路由器上開任何一個對外的 port。

少任何一個都不成立。只有 CLI 沒有 tmux，斷線 agent 就死；有 tmux 沒有安全的連外方式，你就只能在家裡的 Wi-Fi 下用它。

結論：待命的成本被壓到幾乎為零

三層都拆掉之後，「待命」這件事的代價從一台筆電加一個固定位置，降到口袋裡的手機加十五秒。

這個差距不是量的差距，是質的差距。當接回來只要十五秒，你就不需要「安排一段時間來顧它」了：排隊的時候看一眼、走路等紅燈看一眼、睡前看一眼，回一句「用第二個方案」，然後把手機收回口袋。agent 繼續跑，你繼續過你的生活。

而且既然待命不再需要你在場，工作就可以放到你本來就不在場的時間去做。丟一個重構任務給它，去吃晚餐；睡前開一個測試修復的 session，早上起來看結果。你那台一直開著的機器本來整晚都閒著，現在它整晚都在替你工作。

那其他做法呢？

要遠端碰到自己的 agent，能走的路不只一條。把它們放在同一組標準底下比，差別會很清楚——尤其是最後一欄，那是最多人事後才發現被卡住的地方。

最後一欄是分水嶺。跑在別人雲端沙箱裡的 agent，改的永遠是一份副本：你的 .env 不在那裡、你剛裝的那個內部套件不在那裡、你那個只有本機跑得起來的資料庫也不在那裡。而 SSH 加 tmux 這條路，agent 就坐在你自己的機器上，用你自己的環境，改你自己的檔案——差別只在於，這次是你的手機在看著它。