始終在線的 AI 代理，是在沒有任何對話開啟時，仍然能為工作負責的 AI 代理。它可以儲存一項任務的狀態，等待時間推移或外部世界發生變化，在合適的環境裡恢復工作，並在下一個決定屬於某個人時把控制權交還。
「始終在線」並不意味著大語言模型在不停思考。它不意味著一台電腦必須晝夜不停地滿負荷消耗資源。它也不應該意味著 AI 代理不停地發訊息，或在沒有許可的情況下行動。真正有用的承諾是連續性：即使系統的大部分都在休眠，責任依然存在。
定時執行一條提示詞，或保留聊天記錄，並不能回答那些實際的問題：重啟後還剩下什麼？什麼會喚醒 AI 代理？它在哪裡繼續工作？使用者怎樣才能讓它停下？對這些問題的回答，才會把「24/7」從一句口號變成系統的一種屬性。
始終在線關乎連續性，而不是正常執行時間
正常執行時間描述的是一個程序是否在執行。連續性描述的是工作是否仍然有人負責，以及是否有一個有效的下一步。
設想你讓一個 AI 代理盯著一份簽好的合約，等合約回來後更新發布清單，並為你準備下一個決定。合約可能明天回來，也可能下週才回來。在等待期間，並沒有有用的推理在發生。AI 代理不需要一個開著的聊天視窗、一個保持熱狀態的模型工作階段，或一個每分鐘重新整理收件匣的瀏覽器。它需要的是這份責任的持久記錄，以及一種可靠的方式，讓相關事件能把這份責任重新推動起來。
在出故障時，這個區別就一目了然了。一個程序可以一直執行，卻在崩潰後丟掉任務。另一個系統可以縮容到零好幾個小時，然後在事件到來時重建狀態並正確恢復。後者才更稱得上始終在線。
這就是為什麼持久化 AI 代理的基礎架構會把等待和計算分開。比如 Microsoft 當前的 Agent Framework 持久擴充功能 描述了這樣的 AI 代理：在多次 worker 執行之間儲存狀態，暫停時不消耗計算資源或模型 token，並由外部事件恢復。Google 關於 以事件驅動方式恢復的長時間執行 AI 代理 的指南，用持久檢查點和 webhook 示範了同樣的原則。實作細節各不相同，但架構上的經驗是一致的：一份始終在線的責任，並不需要一個始終在執行的模型。
可信的始終在線 AI 代理背後的六個條件
沒有哪一個單獨的功能能讓 AI 代理始終在線。這種屬性是在六個條件共同起作用時出現的。
一個持續的身份承擔這份責任
系統需要一個穩定的身份，讓訊息、事件、權限、任務和使用者的預期都能掛在它上面。如果每次對話都建立一個毫不相干、沒有共享執行脈絡的 AI 代理，那麼後來的事件就無從喚醒任何人，也沒有誰對繼續這項工作負責。
持續的身份並不需要無限的記憶。它意味著使用者可以回到同一個 AI 代理，系統也知道哪些責任屬於它。個人資訊、對話歷史和任務狀態仍然可以有不同的生命週期和控制方式。
工作狀態能熬過空閒時間
一項任務需要保留的不只是最初的提示詞。恢復所需的狀態可能包括預期結果、已完成的操作、工作中的產物、約束條件、當前的阻礙，以及下一個有效步驟。
這種狀態應當足夠持久，能扛過日常的中斷：關掉的瀏覽器、休眠的電腦、一次上線更新、一次 worker 重啟，或者幾天時間的流逝。對話記錄可以幫助重建發生過的事，但重建不等於恢復。可信的系統知道哪份狀態是權威的，而不是每次醒來都讓模型從一長串對話裡推斷真相。
更深入的 如何讓一項任務跨越各種依賴持續推進 的機制，是另一個話題，不屬於這個類別的定義。在這一層，檢驗標準更簡單：系統能否儲存足夠的有效狀態，不需要重新交代一遍就能繼續？
時間和事件可以重新進入系統
外部世界的工作，並不只在使用者發訊息時才推進。截止日期會到來。檔案會變化。回覆會送達。一台裝置會重新上線。一項核准會被記錄在另一個應用程式裡。
因此，始終在線的 AI 代理需要的不只是一個互動輸入框。它需要一條路徑，讓定時器或外部事件能到達它所影響的那份責任。這條路徑可以是 webhook、訊息佇列、排程、連接器，或一個範圍很窄的監視程序。關鍵在於，事件能和正確的 AI 代理、正確的狀態關聯起來。
這並不意味著每個事件都值得進行一次完整的推理。事件驅動的執行之所以有價值，恰恰是因為系統的大部分可以在有工作要評估之前保持安靜。判斷某個事件是否應該喚醒主要 AI 代理，以及這次喚醒是否應該打擾某個人，是一個獨立的策略問題，與定義始終在線的系統本身是兩回事。
工作恢復時有可用的執行環境
如果 AI 代理沒有地方去執行，記住下一步也不夠。有些工作可以透過 API 完成。另一些工作需要瀏覽器、雲端電腦、本機機器或專門的 AI 代理執行環境。當這份責任再次變得活躍時，環境必須可用，並且具備下一步所需的檔案、工具和權限。
「可用」不等於一直在執行。雲端電腦可以在儲存保留的同時休眠，需要時再喚醒。本機機器可以一直斷開連線，直到某個任務需要它。重要的是，AI 代理能識別出所需的環境，並誠實地處理它不在的情況。
環境的邊界也是正確性的一部分。Comma 的 裝置文件 說明，Salix 不會悄悄把工作從一台離線裝置轉移到另一台電腦上。請求可以失敗，等那台裝置回來後再重試。這比假裝每台電腦都可以互換要少一些「魔法」，但它保留了這項工作所依賴的位置、存取權限和執行條件。
恢復是正常執行的一部分
始終在線的系統遲早會遇到重啟、重複事件、不可用的服務、過期的憑證或斷開的連線。因此，可靠性不能依賴於某個程序永遠完美。
系統需要一條恢復路徑：持久狀態、檢查點或等價的事實來源；有上限的重試；避免重複執行外部操作的方法；以及在自動恢復不再安全時一個看得見的失敗狀態。悄悄忘掉已經確認過的事情的重啟不叫恢復。消耗資源卻不改變結果的無限重試迴圈也不叫恢復。
Comma 的 Loop 文件 提供了一個具體的例子。一個 Loop 可以儲存檢查點，並在再次啟動時拿到它。出現故障後，Salix 會在有上限的重試策略內從該檢查點重啟它；反覆失敗會讓 Loop 停止，並通知 AI 代理。完整的實作，包括持久事件、去重、排程位置和能力限制，在 為分散式 AI 代理框架打造的可程式化事件迴圈 裡有詳細介紹。評估一個產品時，看看中斷和恢復是否是計畫中的狀態，而不是意外。
使用者能看見並約束這種連續性
持續存在讓掌控變得更加重要。一次性的聊天會自然結束。一份背景的責任則需要一個容易理解的範圍、一個看得見的狀態，以及一個真正有效的關閉開關。
使用者應當能看出 AI 代理在負責什麼、它在盯著哪些來源、它能用哪個環境，以及它在那裡有什麼權限。使用者應當能暫停或結束這份責任、撤銷存取權限，並取回已經產出的工作。系統應當把失敗和有後果的決定擺出來，而不是把沉默當成一切正常的證據。
這也是為什麼始終在線和自主不是同義詞。持續存在說的是系統可以保持可用。自主描述的是哪些決定或動作它可以不經詢問就採取。一個 AI 代理可以非常持久，同時刻意保持保守：它可以準備、核實、整理和等待，同時把對外承諾或不可撤回的選擇交還給使用者。
四種執行模式，而不是一次無盡的執行
「始終在線」這個說法讓人聯想到一種單一的連續活動。實際上，一個有用的 AI 代理會在幾種不同的模式之間切換。
它可能在工作，模型和工具在積極推進一項任務。它可能在等待，因為某個時間、事件、環境或人的決定還沒有到來。一個輕量的監視器可能在監控一個範圍很窄的條件，而不喚醒主要 AI 代理。或者這份責任已經停止，因為使用者結束了它，或者故障超出了安全恢復策略的範圍。
這些模式對成本和注意力的重要性，不亞於對可靠性。模型推理、雲端計算、事件接收、儲存和第三方 API 的計費方式可能各不相同。產品不應該把它們混成一句不加限定的「AI 代理 24/7 執行」。一份安靜的背景責任可能在使用儲存和監控資源的同時完全不用大型模型 token；一個活躍的任務可能同時消耗模型和計算資源；一份已停止的責任除了保留的狀態之外，兩者都不應該消耗。
Comma 在自己的執行環境裡體現了這種區分。Salix 讓 AI 代理執行在一個始終保持熱狀態的沙箱之外。需要用電腦工作時，它可以喚醒一台雲端虛擬機器，這台虛擬機器的儲存在兩次使用之間保留。對於持續的關注，小型 Loop 可以盯著事件，而不必讓主要 AI 代理迴圈保持活躍。只有當某個 Loop 判斷需要 AI 代理時，主迴圈才會執行。
這種架構是 Comma 的實作方式，而不是通用的定義。別的產品可能用持久化工作流程、佇列、無伺服器函式或長時間執行的 worker。檢驗的標準是整個系統能否在空閒期間保住責任，而不是它是否用了某種特定的執行環境。
始終在線、定時執行和長時間執行是不同的承諾
定時自動化在已知的時間執行一條指令。它可能非常有用，卻不需要維護一個持續的 AI 代理身份，也不需要回應計畫之外的變化。如果一個每日任務根據固定輸入生成報告，那麼一個排程可能就是系統需要的全部。
長時間執行的工作流程可以跨越多個步驟儲存狀態，並等待某個訊號。當模型參與解讀資訊、選擇工具或調整計畫時，它就具備了 AI 代理的特徵。當這個持久化工作流程屬於一個持續的 AI 代理，能接收新的相關事件，並在使用者管控的邊界內行動時，它才真正稱得上始終在線。
聊天機器人也可以記住過去的對話並提供提醒。這些功能提升了使用者的連續性，但它們本身並不能證明工作在聊天之外持續存在。決定性的問題不是系統是否記得關於你的某些事。而是一份活躍的責任能否等待、恢復、從故障中復原，並到達一個經授權的環境，而無需手動重新建立。
這個區別也能防止過度建設。並不是每個請求都需要一個始終在線的 AI 代理。一次性的解釋、改寫、計算或腦力激盪，往往由一個互動式模型來完成更好。只有當結果取決於時間、外部變化、多個工作環境，或者一份在當前對話結束後仍未完成的責任時，始終在線的執行才值得它帶來的複雜性。
一個實用的連續性測試
要評估一個「始終在線」的產品，就給它一份包含空檔的真實責任。讓它監控一個定義好的條件、準備下一步，並在有後果的動作之前停下。
然後看看這個產品能給你看什麼。關掉介面之後，任務存在哪裡？到底是什麼條件讓它重新動起來？它知道哪個環境存放著工作材料嗎？它能在重啟後恢復，而不重複已完成的操作嗎？事件重複了，或所需裝置離線了，會發生什麼？你能否暫停監視、撤銷存取權限，或結束這項任務，而不刪除你所有的歷史？
最後，看看有什麼到達了你這裡。一個轉發每個事件的系統，搭建的是一條通知管道，未必是一個 AI 代理。一個對每個事件都採取行動的系統，把可用性和權限混為一談了。一個有用的始終在線 AI 代理，會把變化與已有的責任連結起來，完成已經獲准的工作，並只在你的關注能改變結果時才請求你的關注。
Comma 如何保持可用而不吵鬧
Comma 是一個免費、開源的個人 AI 代理，圍繞一個跨越對話和裝置的持續 AI 代理來設計。快速的問題可以留在聊天裡，較大的責任會成為 Task。Comma 可以在已連線的應用程式和檔案中工作，在接入的 Mac 或 Linux 裝置上工作，也可以在需要時被喚醒的雲端電腦上工作。
它始終在線的這一層是 Salix。Comma AI 代理可以建立一個 Loop，去盯著一個有邊界的來源，比如收件匣、程式碼儲存庫、訂閱源、API 或 webhook。Loop 與主推理迴圈分開執行，可以維護一個小小的檢查點，並在工作需要時通知 AI 代理。因為主要 AI 代理不需要檢查每一段安靜的時間，「始終可用」就不會變成「始終在消耗模型 token」。Loop 仍然可能呼叫一個快速決策模型或其他服務，所以背景工作並不自動免費；成本取決於 Loop 實際做了什麼。
同樣的連續性仍然受使用者掌控。接入的電腦一開始是唯讀的，直到使用者允許操作，裝置存取權限也可以撤銷。Loop 有能力和喚醒次數的限制。當某個決定屬於使用者時，較大的 Task 可以回到 待審核。Comma 也可以 自行託管，不過那樣營運者就要負責可用性、升級、備份、模型設定以及維持該執行個體執行所需的其他基礎架構。
Comma 的做法是對這個類別核心問題的一種回答：讓責任持續存在，同時讓昂貴的計算、模型和使用者的注意力保持空閒，直到真正需要它們。
常見問題
始終在線的 AI 代理會 24/7 執行模型嗎？
不會。設計良好的系統可以在主模型不活躍時儲存狀態，並監聽定時器或事件。只有當系統需要推理或生成時，模型才會執行。AI 代理等待期間，輕量的監控、儲存和外部服務仍然可能消耗資源。
始終在線的 AI 代理和自主 AI 代理是一回事嗎？
不是。始終在線描述的是跨越時間的連續性和可用性。自主描述的是 AI 代理可以不經人核准就決定或做什麼。一個始終在線的 AI 代理可以在很窄的權限下執行，並把有後果的決定交還給使用者。
定時執行的 AI 任務算是始終在線的 AI 代理嗎？
不一定。一個排程可以在固定時間啟動一條無狀態的提示詞。始終在線的 AI 代理還會儲存這份責任和相關狀態，能回應合適的外部事件，能從中斷中恢復，並在持續的使用者控制範圍內繼續工作。
AI 代理的電腦需要一直開著嗎？
這取決於所需的環境。雲端或伺服器端的工作可以在個人筆電合上時繼續。依賴只存在於某台本機裝置上的檔案或應用程式的工作，必須等那台裝置。有些雲端環境可以在兩次操作之間休眠，同時保留儲存。
始終在線的 AI 代理出故障時會怎樣？
系統應當從已知的檢查點或持久狀態恢復，避免重複已完成的外部操作，並使用有上限的重試。如果無法安全恢復，它應當以看得見的方式停下，告訴 AI 代理或使用者哪裡失敗了，而不是無休止地重試，或悄悄放棄這份責任。
我能關掉始終在線的 AI 代理嗎？
你應該能暫停或結束一份背景責任，並撤銷它使用的存取權限。「始終在線」應當意味著在獲得授權時可用，而不是無法停止。在 Comma 裡，Loop 可以被暫停或刪除，已連線裝置的存取權限也可以撤銷。
AI 代理可以休眠，責任不能消失
始終在線的 AI 代理不是靠持續的模型活動來定義的。它由一條連續的責任鏈來定義：一個穩定的負責者、持久的狀態、一條讓時間和事件發揮作用的路徑、一個可用的執行環境、可恢復的執行，以及始終留在使用者手裡的控制。
當這些部分都具備時，系統的大部分在大部分時間裡都可以保持安靜。模型可以停下。雲端電腦可以休眠。使用者可以關掉應用程式。工作之所以能恢復，是因為責任依然完好，而不是因為有人記得輸入「繼續」。
