聊天機器人有個共通點：你不傳訊息，它什麼都不會做。工程團隊 Rubric Labs 在 2026 年 11 月 5 日發表〈Designing an Always-On Agent〉，想解決的就是這件事。作者 Dexter Storey 的目標，是做出像《鋼鐵人》裡 Jarvis 那樣一直待命的 AI。
Always-on agent 是什麼
Always-on agent 可以叫它「常駐 AI 助理」。Rubric Labs 用三個特徵定義它：
- 單一對話串（single-threaded）：只跟一個 AI 講話，它記得你，所有事都交給它
- 主動（proactive）：沒人叫它，也會自己做事、傳訊息給你
- 有情境感知（situationally aware）：知道你的行程、信件和環境，不用你每次補背景
對照目前的聊天機器人和一般 AI Agent，Rubric Labs 的描述是：
| 常駐 AI 助理 | 一般聊天機器人或 agent | |
|---|---|---|
| 存在方式 | 長期一條對話串 | 短暫，用完就關 |
| 啟動方式 | 自己醒來 | 被動，你開口才動 |
| 資訊來源 | 自己掌握環境 | 只看你當下給的內容 |
單一對話串：怎麼不爆記憶
所有事塞進同一條對話，會遇到 context window（AI 一次能讀進去的文字量，滿了就讀不下）的上限。想讓它在同一條對話裡一邊排行程、一邊訂餐、一邊回信，一定得處理這件事。Rubric Labs 用兩招。
讓 agent 自己整理記憶。 業界常見做法是 compaction（壓縮）：對話太長時，把前面內容濃縮成摘要。Rubric Labs 發現，由外部程式代為壓縮會打斷節奏，就像硬生生切斷了 agent 的思緒和動能。
所以他們改成：
- 讓 agent 每一輪都看得到自己用了多少 token
- 給它
foldContext工具，把一段訊息換成自己寫的摘要 - 給它
dropContext工具，直接刪掉一段訊息
實際上，agent 通常會等到一件事做完的空檔再壓縮，丟掉不再需要的推理和工具紀錄，留下還在用的內容。想先了解 AI 的記憶怎麼運作，可以看 AI Agent 的記憶機制。
派分身去處理耗時的工作。 訂餐、掛號這類要操作瀏覽器的事很花時間。主 agent 把它們交給 sub-agent（分身），自己繼續跟你聊，主對話串也能留更多空間放整體脈絡。分身的運作可以參考 Skill、Sub-agent、Cron 三大機制。
主動：heartbeat 和傳訊息工具
一般 agent 像一個函式：你送出請求，它回傳結果。要變主動，它得能在任何時間醒來，也能不等你開口就先傳訊息。Rubric Labs 加了兩個設計。
Heartbeat（心跳）。 每隔一段時間，系統往對話裡塞一則「heartbeat」訊息，agent 就醒了。頻率可以固定，例如每小時一次，也可以讓 agent 自己排下一次醒來的時間。
把「傳訊息給你」做成工具。 在普通聊天裡，agent 每一輪的最後一句就是回覆你的話。在這個設計裡，agent 必須呼叫傳訊息工具，你才收得到。所以它醒來做完事，可以決定這次沒什麼值得說，不打擾你。最後一句話會留在對話裡，當成它給自己的備忘。
Rubric Labs 舉的例子：agent 知道你週三要飛奧斯汀，在例行心跳中發現班機資訊，派分身整理機場到住處的路線和入住資訊，再排一個接近降落時間的心跳，在你落地時把訊息送出。
情境感知：廣泛權限加通知收件匣
想讓 agent 自己找到事做，它得知道你的處境。Rubric Labs 提供兩層。
廣泛權限。 讓 agent 讀你的信箱、瀏覽器和檔案，它就能自己發現你訂的機票和住宿，找出你的偏好。Rubric Labs 認為，寫程式的 AI 靠一個「執行終端機指令」的工具就變強了，通用 agent 靠電腦操作工具也能做到類似的事。
通知系統。 光有權限不夠，agent 不知道自己不知道什麼。所以 Rubric Labs 給它一個收件匣，網路上的事件一發生就送進來。航班取消時，agent 可以立刻找替代班機並通知你，不用等一小時後才發現。
問題隨之而來：收件匣很快塞滿廣告信、不是給它的 Slack 訊息、不相關的程式專案通知。每則都叫醒 agent，可能每分鐘就醒一次，白白燒 token（AI 用量的計價單位）。Rubric Labs 提出的一種做法，是先用一個較小的模型判斷重不重要，重要的才叫醒 agent，其他的堆著，等 agent 自己有空再一次讀完。
最難的一塊：判斷力
Storey 認為，上面這些架構都是相對簡單的組合，真正的難題在模型本身：
「現在的模型非常不擅長這件事，因為它們缺乏判斷力。」
他的說明是，現在的模型在訓練階段學的都是「把任務完成」，所以訊號明確時表現很好，面對模糊的環境就會出問題。他舉的例子是 Slack：agent 會對不是給它的訊息動手，發現自己沒有權限和背景後，最後交出一份設計文件。他的評價是毫無用處又尷尬。反過來，agent 也會漏掉真正該行動的時機。太積極與太消極之間的平衡，他認為更像憑經驗摸索，無法照公式調好。
他建議的做法是讓 agent 一開始很害羞，慢慢累積信心，找到自己能發揮的範圍。具體要三件事：
- 系統提示（system prompt）寫清楚它負責什麼，並說明「什麼都不做」完全沒問題
- 不確定是不是自己的工作時，先問，不要猜
- 記住每次行動後你的反應（謝謝、糾正還是無視），下次行動前先翻這份記憶
給初學者的三個提醒
- 這是設計思路，文章沒有提供實測數據，也沒有說明效果多好。把它當成理解「常駐 AI」的地圖就好。
- 權限給得越廣，agent 能做的事越多，出錯或被操控的風險也越大，可以搭配 AI Agent 的安全風險一起看。
- 想先弄懂 agent 與語言模型的分工，可以從 AI Agent 不是 AI 開始。