作者：Jimmy Liao（Google AI / Cloud GDE & Microsoft AI MVP）｜2026-11-09
過去十年，我們花了無數週末微調 .dotfiles。我們挑選順眼的 Nerd Font、設定 Shell alias、把視窗快捷鍵磨到肌肉記憶裡。這整套工程哲學叫做 DX (Developer Experience)——一切為了討好「人類的眼睛與手指」。
但到了 2026 年，如果你打開我的 16GB M1 MacBook 與跨雲端 Ubuntu Dev-Box（橫跨 Google Cloud Compute Engine 與 Azure Linux VM / WSL2），會發現這兩台機器上最操勞的使用者根本不是我。
那上面常駐著一整支 AI Coding Agent 艦隊：以具備 Gemini 2.5 Pro 1M 長上下文與 Context Caching 的 Google Antigravity (agy / Gemini CLI) 為首，搭配 OpenAI Codex (codex / GitHub Copilot CLI)、Claude Code (claude) 與 OMP (omp)。它們在數十個 tmux pane 裡平行跑測試、透過 Chrome DevTools MCP 開瀏覽器抓 DOM、建置 Docker image、讀寫上百 MB 的 .jsonl 狀態檔。
這件事很有趣：人類覺得「還算順、能動就好」的系統預設值，對高頻自動化的 AI Agent 來說，往往是一堵直接撞死的牆。
在籌備接下來 Build with Gemini Taipei (Google Developer Groups / GDE) 的《AI-Native Ops》技術分享時，我把日常開發環境裡所有讓 Agent 卡住、把 16GB 記憶體凍死、甚至在雲端 VM 重開機時瞬間毀掉所有對話紀錄的「隱形陷阱」全部量測並拆解了一遍。這篇文章不談空泛的趨勢，只看我們實際量出來的數據、底層根因，以及為什麼你現在需要一套專門給 Agent 的系統工程——AX (Agent Experience)。
案例一：8 秒的瀏覽器黑洞，與偷偷吃掉 12GB 的 APFS 幽靈分身
我常拿 agy、OMP、Puppeteer 或 Chrome DevTools MCP 讓 Agent 自己去操作 Chrome Dev 驗證前端畫面。剛開始我每次看 Agent 跑測試都覺得慢——不是網路慢，而是跑一個幾秒鐘的檢查，光開關瀏覽器就卡掉十幾秒；更詭異的是，升級 Chrome 136+ 之後，原本能動的 CDP 設定突然全部連不上。
我實際把它量出來，發現兩個連環坑：
1. Chrome 136+ 的預設 Profile 封鎖與「肥 Profile 拖延症」
從 Chrome 136 開始，為了防止本機惡意程式直接掛載接走你的日常 Cookie 與已登入 Session，Chromium 強制在預設目錄（如 ~/Library/Application Support/Google/Chrome 或 Chrome Dev）上忽略或拒絕 --remote-debugging-port。
就算你硬是把日常 Profile 複製一份出來給 Agent 用，那個累積了 878MB+ 快取、裝了 11 個擴充功能、還帶著一堆 Service Worker 的肥 Profile，對 Agent 來說簡直是災難。我在 M1 16GB（Chrome Dev 159）上實測了三種模式的延遲：
2. 藏在 /private/var/folders 裡的 12GB Gatekeeper 幽靈
在排查 Chrome 啟動延遲時，我順手查了一下 APFS 磁碟空間，結果在系統暫存區挖出一個大驚喜。
每當 Agent 高頻啟動、或 Chrome Dev（單一 .app bundle 高達 1.5GB）在背景更新與 CDP 除錯途中被中斷時，macOS 的 Gatekeeper（syspolicyd）會在 /private/var/folders/.../X/com.google.Chrome.dev.code_sign_clone/ 下建立驗證用的 APFS Copy-on-Write 副本。
一旦驗證逾時或程序被強殺，這些副本就會變成沒人認領的孤兒。我的機器上足足躺了 8 個孤兒 .app.bundle，一聲不響地吃掉 12.0 GB！再加上 Chrome Framework 預設保留的上一版雙版本殘留（745 MB）與膨脹的 Service Worker/CacheStorage（5.3 GB），光一個瀏覽器就偷偷吞了 18 GB。
AX 解法：雙實例隔離架構
安全與速度在這件事上完全同方向。我把瀏覽器徹底拆成兩軌：
人類日常 Chrome：裝滿擴充功能、保留 Keychain 與同步，不開 CDP。
Agent 專屬 Chrome（
--user-data-dir隔離 + 常駐 Warm Daemon）：給它獨立的翡翠綠CDPDock 圖示避免Cmd+Tab誤關，關掉背景網路、同步與 Phishing 檢查。當agy或 Chrome DevTools MCP 連續工作時直接走459 ms的熱 Attach；需要乾淨環境時走chrome-dev-fast，用完92 ms瞬間收工。
案例二：16GB Apple Silicon 生存戰——WindowServer 假死與零磁碟成本的內建模型
很多人問我：2026 年一邊把長上下文重活交給雲端的 Gemini 2.5 Pro (agy)，一邊在本機跑多路 Agent，16GB 的 M1 Mac 還活得下去嗎？
答案是：活得下去，但前提是你得幫 macOS 補上它沒針對 Agent 設計的護欄。
在 16GB Unified Memory 上同時開數十個 pane，我們撞過三個最痛的系統瓶頸：
1. 為什麼一個失控的 node 子程序會把整台 Mac 的 WindowServer 凍死？
大家以為 macOS 記憶體不夠時，Kernel 的 Jetsam 機制會自動殺掉吃最兇的程序。但實務上有個致命例外：當你使用帶有 com.apple.security.get-task-allow 開發權限（entitlement）的終端機（如開發版 cmux）時，它衍生出來的子程序會逃過一般 Jetsam 的優先回收順序。
當某個 Agent 背後的 node 或是 MCP server 發生記憶體洩漏、RSS 暴衝超過 4 GB 時，macOS 來不及殺它，WindowServer 就會因為拿不到記憶體而直接失去回應——你的滑鼠還能動，但整個畫面徹底凍結，只能長按電源鍵重開。
AX 解法（cmux-rss-guard）：寫一個極輕量的 LaunchAgent，每 30 秒巡檢終端機程序樹下的 node 子程序。只要發現單一子程序 RSS > 4 GB (4,194,304 KB)，不等系統卡死，直接發送 SIGKILL (kill -9) 精準斷尾，保全主會話與 WindowServer。
2. Spotlight mds_stores 的無效狂飆
人類一天建一個專案資料夾；但一隊 Agent 一小時可以建出五個 Git worktree、產生幾萬個 node_modules 與 .venv 小檔案。如果你放任 macOS 預設的 Spotlight 去索引它們，mds_stores 會把你的 CPU 和 SSD I/O 吃乾抹淨。
AX 解法：將 Spotlight 降級為 Apps-Only（僅索引應用程式與系統設定），並在所有高頻開發與快取目錄（~/workspace、~/.cache、~/.npm、~/.cargo 等）自動打上 .metadata_never_index。
3. 實測 Gemma 4 / Phi-4-mini 後，砍掉 14.3GB 重複權重改用 0 磁碟成本的內建 fm
先前在測試 Google Gemma 4 E2B、Microsoft Phi-4-mini 與 Qwen 3.5 等本機小模型時，~/.cache/huggingface 不知不覺塞了高達 14.3 GB 的 3B/4B 實驗權重。為了讓 16GB Mac 保持最純粹的反應速度，我把長上下文推理全面收斂給雲端的 Gemini (agy)，並清掉重複權重，改用 macOS 26/27 原生內建的 /usr/bin/fm（Apple Foundation Models, AFM 3 Core）處理極輕量本機任務。
它直接住在系統卷宗裡（0 額外磁碟開銷），隨叫隨到。我在 M1 上實測本機 --model system 的短摘要表現，TTFT（首字延遲）中位數只要 0.69s ~ 0.76s，完整回覆不到 1 秒。再搭配一個 848 MB 的 whisper.cpp（ggml-breeze-asr-26-q4_0.bin）負責中英夾雜語音轉錄，16GB Mac 就能用最小的空間跑出最俐落的本機 AI 管線。
（順帶一提：如果你在背景 Agent 腳本裡呼叫 fm 的雲端 --model pcc，Apple 會因為 TCC 權限檢查直接回你 HTTP 503 ("Please use the Terminal app")；背景自動化記得一律指定 --model system。）
案例三：雲端 Ubuntu Dev-Box 的重開機陷阱，與 Terminal Type-Ahead 的底層差異
除了隨身的 Mac，我還有一台 24×7 運行的雲端 Ubuntu Dev-Box（這套架構同樣適用於 Google Cloud Compute Engine 與 Azure Linux VM / WSL2），上面常駐 10+ 個 tmux sessions、跑著超過 20 個頂層 Agent 與累積 34MB+ 的 .jsonl 對話歷史。
為了怕雲端 VM 遇到硬體維護或 Spot 搶佔重開機，很多人第一個反應是：「設一個每 15 分鐘跑一次的 crontab，把 tmux 狀態存成快照腳本不就好了？」
千萬別這麼做。這正是我們差點毀掉整個工作區的「快照自殺陷阱」。
1. 當 15 分鐘 Cron 遇上無預警重開機
想像一下這個時序：
凌晨 3:02，雲端 Ubuntu Dev-Box 因為宿主機維護重開機了。
凌晨 3:15，你還在睡覺，還沒連進去還原
tmux（或者某個自動化腳本剛連進去開了 1 個空白的 session）。此時，每 15 分鐘一次的 Cron 準時觸發。它看了一眼現在的
tmux，開心地用這個「空白狀態」直接覆蓋掉重開機前那份包含 20 個活躍 Agent 的健康快照。
等你早上醒來，重開機前的快照已經灰飛煙滅。更別提傳統的 tmux-resurrect 只認得 zsh 空殼，根本不知道每個 pane 裡跑的是 agy、omp、claude 還是 codex，還會誤把 OMP 內部的 __omp_worker 當成互動式對話。
AX 解法：boot_id 防護狀態機 + 跨 Runtime JSONL 精準反查
我們寫了一支跨平台的 tmux-agent-checkpoint.sh，用三道防線徹底解決這個問題：
Kernel
boot_id比對：每次執行時先讀 Linux 的/proc/sys/kernel/random/boot_id（macOS 則是sysctl -n kern.bootsessionuuid）。一旦發現boot_id變了（代表剛重開機），在動任何檔案之前，強制把重開機前最後一份健康快照封存為preboot-<timestamp>.sh，且永久豁免於自動清理。TTY +
/proc/<pid>/fd+ Lockfile 雙向反查：自動爬每個 pane 的子程序樹，精準過濾掉__omp_worker或 MCP server 等背景 helper，找出每個互動式 Agent 實際打開的.jsonl檔案、AGY Presence Lock 與 Claude PID Registry，自動產出cd <cwd> && <agent> --resume <exact-uuid>的一鍵還原腳本。flock -n與原子替換：全程用flock防重疊執行，先寫入暫存檔並通過bash -n語法檢查後，才用mv -f原子替換。
Bonus 觀察：為什麼 Agent 忙的時候，有的 CLI 能「預先打字 (Type-Ahead)」，有的卻把你鎖死？
在長時跟這四套 Agent CLI 相處時，我注意到一個極度影響 DX × AX 協作節奏的細節：當 Agent 正在執行工具或串流輸出時，我腦中已經想到下一步指令了——這時候我能不能直接打字？
我拆了 OMP (omp) 與 Google Antigravity (agy) 的底層架構，發現這完全取決於它們怎麼處理 Terminal stdin：
為什麼
OMP支援流暢的 Type-Ahead？OMP 把底層的 Raw
stdin讀取迴圈 與模型的 Agent Turn 執行狀態機 徹底解耦。就算 Agent 正在忙，你的按鍵事件依然即時進到獨立的輸入緩衝區；按下送出後，訊息會進入steer（即時轉向）或follow-up（下一輪佇列），一點都不會打斷你的思緒。為什麼
AGY在忙碌時會鎖住輸入？AGY的 TUI 是用 Go + Bubble Tea v2 寫的。在它的 Elm Architecture 狀態迴圈裡，當狀態切入 busy/streaming turn 時，輸入框元件會被設為非焦點或忽略按鍵訊息，直到整個回合結束才重新開放輸入。因此我們在艦隊分工裡，讓搭載 Gemini 1M 長上下文的AGY專門負責大型研究、跨檔案審計與非同步 Subagent 派工，而讓OMP擔任人類互動的第一線入口。
這再次證明：在 2026 年，一個工具好不好用，看的早就不只是模型聰不聰明，而是這些底層 I/O、狀態機與系統資源有沒有把「人機並行」放在心上。
開源 ax-playbook：從 .dotfiles 進化到給 Agent 讀的 @AGENTS.md
把這整套在 Apple Silicon Mac 與多雲 Ubuntu Dev-Box（GCP / Azure）上踩坑、量測、驗證過的雙軌調校架構整理完後，我決定把它完整開源出來：
👉 GitHub：jimmyliao/ax-playbook
這個 repo 分成兩個實戰章節：
macos/(Lean Agent Mac)：Chrome 136+ CDP 11.6x 加速與雙實例隔離（完美支援 Chrome DevTools MCP）、APFScode_sign_clone12GB 幽靈回收、Spotlight 降噪、16GBcmux-rss-guard防凍死、以及 macOS 26/27 內建/usr/bin/fm解鎖指南。ubuntu/(Resilient Agent Dev-Box for GCP / Azure / Linux)：跨AGY/OMP/Claude Code/Codex的 Tmux × JSONL 精準快照、boot_id防重開機覆蓋、Dockercandidate磁碟水位治理、以及對外 Tunnel 的 HTTP 401 零信任護欄。
最棒的是，在 AX 時代，你甚至不需要自己一行行敲 bash script。
我們在 repo 根目錄放了一份嚴格定義三階段安全護欄（Phase 1: 100% 唯讀診斷 → Phase 2: 預估效益與風險表格 → Phase 3: 使用者明確授權後才執行）的 @AGENTS.md。
你只要把 repo clone 下來，打開你手邊的 Google Antigravity (agy)、Claude Code、Codex 或 OMP，貼上這一句話：
請讀取 @AGENTS.md，先自動偵測我的作業系統（uname -s）並執行對應的 100% 唯讀診斷腳本（macOS 跑 ./macos/scripts/audit-macos.sh，Linux 跑 ./ubuntu/scripts/audit-ubuntu.sh），整理出目前可優化的 DX × AX 項目與預估效益表格，並在取得我明確同意後再逐項套用。讓你的 Agent 自己去體檢它居住的環境，把那 8 秒的瀏覽器等待、12GB 的幽靈快取和重開機失憶症一次修好。畢竟在 2026 年，對你的 Agent 好一點，就是對你自己的下班時間好一點。
作者後記（Google AI / Cloud GDE & Microsoft AI MVP 雙視角筆記）：本文實測數據與開源腳本整理自籌備 Build with Gemini Taipei《AI-Native Ops》演講期間的真實生產環境調校——涵蓋 Google Antigravity (agy / Gemini 2.5 Pro 1M Context)、Chrome 136+ DevTools MCP、Gemma 4 與 Phi-4-mini 本機模型評測，以及跨 Google Cloud 與 Azure Linux VM 的多雲 Agent 艦隊維運實踐。