當 AI 不再等你開口

多數 AI 產品長得差不多：左邊一串 chat history，中間一個空白輸入框，右邊偶爾冒出一點 side panel。

你問一句，它答一句。關掉分頁，這段關係就結束了。明天再開，通常又是一次新的開始。

SpaceXAI 最近的 Designing Grok Bot for a world of persistent agents，講的卻是另一種關係：agent 不該只活在一次 session 裡。它要有名字、有記憶、有自己的電腦，甚至能在你還沒開口之前就開始做事。

讀完之後，我覺得這篇比較不像產品發表，而像一份設計宣言——當模型真的開始「負責」一件事，介面該怎麼跟著改。

⸻

▍聊天紀錄本來就該被忘掉

文章一開始就戳破一件很平常、但很少被當設計問題處理的事：

Chats are disposable.

我們開一段對話，解決一個問題，它就被往下推。一週後再開一段。真正會回頭看的，大概只剩最近五則。

這在「單位是問題」的時候完全合理。但當另一邊是一個該認識你、記得上次做到哪、還能跨天負責的 agent，繼續用 chat history 當產品主軸，就會變得很怪。

所以 Grok Bot 把主要物件從 conversation 換成 Bot。

Bot 有名字、avatar、title。它記得跟你的對話，有自己的 tools，也有自己的 computer。你明天回來，不是再開一個新 session，而是回來找同一個 Bot。

❖ 產品的組織原則變了：不是「我跟 AI 聊過什麼」，而是「我委派給誰」。

這聽起來像命名遊戲，但其實會一路改到 sidebar、狀態提示、甚至使用者對自己角色的想像。你不再是一直餵 prompt 的操作者；你比較像在管一組會做事的同事。

⸻

▍先砍掉一堆詞彙，只留下五個 primitives

AI 產品最近累積了很多名詞：session、context window、memory、system prompt、project、skill、connector、sandbox、permission、automation……每一個都真實存在，但不見得都該暴露給使用者。

Grok Bot 的做法很乾脆：先問「一個人要跟 agent 一起工作，到底需要懂哪些東西？」

他們留下五個：

1. Bots — 有身分、記憶、runtime 和工具的 persistent agents
2. Chats — 跟 Bot 工作的對話介面
3. Prompts — 給 Bot 的上下文或指令；可以一次性用，也可以存成 Skills，或排成 Routines
4. Tools — Bot 存取資訊、採取行動的能力
5. Artifacts — Bot 產出或修改的文件、設計、code、資料

其餘的，先藏起來，等使用者真的有理由關心再出現。

我很喜歡這個順序。很多 AI 產品是反著做的：先把系統裡所有真實概念攤開，再叫使用者自己組裝。結果介面變成一張工程師的心智模型圖，而不是一份可以委派的工作關係。

前陣子看 OpenAI 設計主管 Ian Silber 的訪談，他也提到 ChatGPT 那個強大卻空白的輸入框：對熟手是自由，對新手只是不知道該輸入什麼。Grok Bot 這邊更進一步——他們不只想解決「空白框不知道寫什麼」，而是想把產品從「你必須先開口」移到「有些工作本來就不該等你開口」。

⸻

▍Presence 比 progress bar 更像同事

一旦 Bot 變成長期維護的對象，介面就要同時回答三個問題：

1. 這是誰？
2. 他在做什麼？
3. 我現在需要知道多少？

他們把答案壓進 avatar。

休息時看起來平靜、有點好奇；接到工作會先 acknowledge；開始做事時動作變了；卡住或等你時又換成另一種姿態；做完再安靜下來。狀態不再是旁邊多一顆灰點、三個跳動的點，而是角色本身在告訴你現在發生什麼。

研究也顯示，使用者想看細節，很多時候不是真的想當 debugger，只是想確認：「它還活著嗎？它走在對的路上嗎？」

所以最後的設計是分層的：avatar 的 motion 先給第一層安心感；真的想看細節，再 hover 出當下動作。不是把整條 execution log 一直攤在臉上。

這對我來說是很重要的設計判斷。Agent 產品很容易掉進兩種極端：

• 太少資訊：只剩 loading dots，你不知道它卡死還是在想
• 太多資訊：把每一次搜尋、每一次編輯、每一次測試都播給你看，把你拉回監工模式

好的 presence，是讓你知道它在工作，卻不強迫你盯著它工作。

⸻

▍那台電腦是它的，不是你的遠端桌面

每個 Bot 都有自己的 computer：可以瀏覽、處理檔案、跑軟體。這立刻帶來一個介面問題——這台電腦該多明顯？使用者什麼時候該伸手進去？

他們試過 floating window、並排、modal、全螢幕。結論很清楚：電腦越顯眼，產品就越鼓勵使用者去監督。

最後留下三層：

• Status：電腦在動時，標題列圖示變色
• Preview：需要時打開側欄，跟著看，不必離開對話
• Takeover：Bot 需要幫忙時，你才進去全螢幕接手，做完再還回去

甚至連 wallpaper 都會隨時間變亮變暗，讓這台電腦感覺有自己的一天，而不是你桌面上多開的一個遠端視窗。

❖ 目標不是「讓你更方便操作 AI 的電腦」，而是「讓你更像在跟同事協作」。

你可以感覺到他在忙，需要時瞄一眼螢幕，真的卡住了再坐過去。這跟「我租了一台 VPS，自己在上面下指令」是完全不同的心理模型。

⸻

▍回答的形狀，也是答案的一部分

早期的 Grok Bot 幾乎什麼都用散文回。五天天氣預報用文字描述，一組任務用口語敘述。使用者拿到答案之後，還得自己重新整理一次。

所以他們開始把 response form 當成答案本身：能用 prose 就 prose，該是 email draft、看板、設定變更、Routine 建立事件，就直接用 inline card / widget 出現在 transcript 裡。

結果是一條 heterogeneous transcript：對話、系統事件、可互動物件、視覺化，共用同一條時間軸。

這對設計師其實很刺眼。我們習慣把「對話」和「介面」分開想——左邊聊天，右邊面板。但 agent 產品越來越不像聊天室，而像一條持續發生事情的工作紀錄。訊息不只是文字，也可能是一個待你確認的動作、一份可以送出的草稿、一次已經跑完的 Routine。

如果未來的 AI 產品還堅持所有能力都從同一個空白框長出來，使用者最後還是得自己猜：現在這句話會變成什麼？

⸻

▍能力可以共享，脈絡最好跟著角色走

人一旦開始養多個 Bot，下一個問題就來了：誰該知道什麼？誰跟誰協作？使用者要不要自己當 dispatcher？

文章裡有個很實際的觀察：有些人會自己長出一個 Chief of Staff Bot，專門協調其他 specialist。方向下給一個，而不是每個都檢查、每件事都自己路由。

更關鍵的是邊界：

• Tools 和 Skills 放在 account 層，因為很多 Bot 都可能需要瀏覽、處理文件、寄信
• Memory 和 Routines 屬於個別 Bot，因為那反映這個角色長期知道什麼、負責什麼

法律 Bot 需要爭議歷史，財務 Bot 需要多年帳目。硬塞進同一個大 memory，反而讓每個角色更難拿到對自己有用的東西。

跨角色的工作，則用 group chat 提供共享情境，同時保留各自的 specialized memory。協調仍然盡量交給 coordinating Bot，使用者只在需要判斷時被叫進來。

這讓我想到系統設計裡很老的一句話：抽象邊界決定複雜度落在誰身上。Grok Bot 選擇把複雜度往 agent 那邊推，而不是往使用者的 dashboard、assignment board、handoff control 推。

老實說，這很誘人，也很危險。做得好，你真的在委派；做得不好，你只是把「管理一堆聊天室」換成「管理一堆看起來很像同事的黑盒子」。

⸻

▍Routines：工作開始不必從 prompt 開始

大多數 agent session，還是等人送出一句 prompt 才活過來。就算 Bot 本身是 persistent 的，它在產品裡的行為，往往還是「待命」。

Routines 把這件事改了。你可以給 Bot 一個 standing responsibility：每天早上做 briefing、平日晚上清 inbox、某個事件發生時去檢查。工作被定義一次，之後由 schedule 或 event 啟動。

對話的角色也跟著變。Prompt 可以開始一段工作，但 schedule、event、另一個 Bot，也可以。久了之後，越來越多事情會在你不在場的時候開始。

這大概是整篇文章最尖銳的轉向：

介面不再預設「使用者是第一個動作的發起者」。

對設計師來說，這會改很多假設。Onboarding 不能只教人怎麼寫第一句 prompt。Empty state 也不該只是一個更大的輸入框。你得開始設計：當工作自己跑起來時，結果怎麼回來？例外怎麼打斷你？信任感從哪裡來？

⸻

▍最後，設計工作很多時候是在拿掉東西

文章收尾那句，我覺得是整篇最像設計原則的地方：

Did this help someone delegate, or did it give them one more thing to manage?

他們拿掉很多 window control、panel option、agent metadata，也設了實際上限：大概 50 個 Bot、group chat 最多六個。每一個決定都回到同一個問題——這是在幫人委派，還是又多給人一件要管的事？

這跟 Ian Silber 說的 just do less，其實是同一條線。AI 讓產出變便宜之後，介面最容易犯的錯，不是做得不夠華麗，而是把每一個系統真實性都暴露出來，逼使用者重新當一次操作員。

❖ 當 agent 承擔更多責任，介面應該問人更少的事。

操作 AI，和委派給同事，中間那條線會一直移動。Grok Bot 現在押的位置很明確：少一點監工 UI，多一點身份、狀態、例外處理，以及「你可以暫時不管」的空間。

⸻

▍給還在做 AI 產品的設計師

讀完這篇，我會帶走四個問題，之後自己做 agent 相關介面時拿來問：

1. 主物件是什麼？ 如果你的 sidebar 還是 chat history，使用者心智模型大概還停在問答，而不是委派。
2. 哪些概念真的需要被看見？ 系統裡有二十個真實名詞，不代表產品裡該有二十個入口。
3. 進度要給多少才剛好？ 夠讓人安心，但不要把人拉回盯梢。
4. 工作能不能在使用者不在場時開始？ 如果永遠要等人開口，你設計的仍然是工具，不是同事。

當然，這些都還很早期。Persistent agent 好不好用，最後不一定取決於 avatar 漂不漂亮，而取決於信任能不能累積：它會不會亂寄信、會不會改錯檔、卡住時會不會好好叫你。

但至少這篇文章把設計問題講對了。

不是「怎麼讓 chatbot 更好看一點」，而是：當另一邊開始持續負責，我們要不要還假裝一切都從一句 prompt 開始。

來源：Designing Grok Bot for a world of persistent agents，SpaceXAI，2026 年 9 月 3 日。