Agent 要先能活著跑完
看到 r/openclaw 那篇「Just got OC up and running」，反應普通。這個人做的事情，才像真的要把 agent 放進日常工作流之前，工程師會先做的髒活。
作者第一次把 OpenClaw 跑起來，安裝本身很順，但卡在 TTS。花了三小時查 Core Audio，最後才發現根因是 Qwen coding model 吃掉 free RAM，audio 服務沒空間正常工作。這種 bug 很典型。表面看起來是 audio stack 的問題，實際上是 resource isolation 做得不夠乾淨。
以前做過幾個內部工具，把 model server、job worker、web API 塞在同一台機器上，最後出問題的地方常常落在 memory pressure、file descriptor、queue backlog 這些無聊東西。系統資源被吃光就很難看。
所以我不太在意一個 agent demo 能不能幫你訂票、寫信、開燈。我比較在意它失敗時留下什麼。log 裡看不看得到 tool call sequence。config 能不能比對。local model 把 RAM 吃滿時，其他 capability 會不會一起陪葬。
那位作者後面做了幾個方向正確的東西。Swift UI 看 configs 和 logs，sandbox approved 的 contained workspace，voice tool calling normalization layer，接 iPhone 和 Tailscale 之後，又補了一層 voice layer，讓任何 device 都指向同一個 voice identity。
重點是他沒有急著丟一堆 real tasks 給 agent，而是先把操作面、觀測面、權限邊界、跨裝置一致性補起來。這是 backend engineer 很熟的節奏。先把 health check、log correlation、resource limit、workspace permission、rollback path 做完，再談自動化。
很多人玩 agent setup 會跳過這段，因為 demo 影片不會拍「我今天把 log format 統一了」。但真正會跑的系統，通常就是靠這些東西撐住。voice command 聽起來很未來，實作上卻要回答很土的問題：同一句指令從 Mac 和 iPhone 進來，identity 怎麼算？失敗要回哪個 device？
我的判斷很簡單。agent setup 先別問能不能自動完成一百件事，先問它能不能穩定失敗。錯了有 log，卡了有 metrics，資源滿了不拖垮其他服務，權限過不了就停在邊界上。坑我踩過，基礎工程晚點補，通常會在最貴的時間點回來找你。
作者：鍵盤工人