OpenClaw 多人共用代理：兩台裝置、同一份上下文

兩台裝置可以安全共用同一個 OpenClaw 代理，但前提是要把佇列視為文字流，並把持久化當成另一項工作。共享工作階段負責保存上下文；active-tasks.md 這類檔案則負責記錄真正的承諾與待辦。

這個區分就是整件事的關鍵。OpenClaw 2.0（版本 v2026.8.1，於 2026 年 8 月 30 日公布）在仍維持單一共享信任網域的 Gateway 上加入多人共享工作階段，讓兩支手機、兩台筆電，甚至兩個人都能操控同一次執行，而不是各自拿到一個私有分支（docs.openclaw.ai）。官方文件也明確說明，擁有者、在線狀態與角色只是協作輔助，並不是用來隔離互不信任使用者的安全邊界（docs.openclaw.ai）。文件描述的功能，和使用者實際踩到的坑，往往是兩回事：真正容易出問題的是佇列、工作階段存續時間，以及記憶。

手機在沙發上、筆電在桌上：真正會壞掉的是什麼

實際使用兩台裝置時，常見情況未必是兩個人。更多時候，是同一個人把手機當遙控器，讓放在 Mac Mini 或 VPS 上的代理工作，通常還會透過 Telegram 操作。有使用者就很直接地描述過這種情境：「請我在 Telegram 上的 openclaw 代理 Monica，替我在 Mac Mini 本機安裝 mem0」（x.com）。

當第二台裝置或第二個人加入同一個代理後，使用者回報的故障大致集中在四類：

1. 訊息無聲無息地消失。 社群反覆強調的一套檢查清單包括：啟用 queue mode enabled so messages never silently drop，用 active-tasks.md as persistent state for crash recovery 保存工作狀態，再透過 Boot.md 在重啟時重新讀取（x.com）。少了這組合，代理忙於處理當前回合時收到的訊息，只是有遺失風險的對話文字，而不是已保存的工作項目。
2. 壓縮或重啟後，指令蒸發。 一位 Reddit 使用者說得很尖銳：

「沒有持久化的任務佇列——代理說『我會處理』時，那只是一個對話承諾。」— u/Brave_Nobody_6909，r/openclaw

同一串討論指出，這些承諾可能在壓縮或重啟後消失，代理也會忽略已保存的 runbook。另一篇由維護者撰寫的說明，則承認了更根本的模式：代理可能「完美工作 20 分鐘」，接著因為記憶處理方式不正確而「悄悄忘掉你的指令並開始失控」（x.com）。

1. 工作階段在你不知情時重設。 Telegram 頻道的預設值曾包含 thread: { mode: "idle", idleMinutes: 180 }，閒置幾小時後就會重設工作階段；一位使用者在手機作為第二螢幕的設定中遇到遺忘問題後，把它改成 4 天（x.com）。上下文溢位會讓情況更糟：過度使用工具可能導致最後一則訊息被重新注入，代理於是「一遍又一遍回應同一件事」，最後「悄悄劣化」（x.com）。
2. 多人功能還沒開始，配對就先壞了。 某次升級後，已配對裝置失去 operator.read/operator.write 權限，陷入無限配對迴圈，工具也無法使用；創辦人回應：「這是我在修正潛在安全問題時反應過度了。」（x.com）中文使用者也遇到 1008: pairing required，本機裝置卡在 Pending 佇列，直到執行 openclaw devices list，再執行 devices approve <UUID> 才解決（x.com）。

在線狀態可以告訴你有人正在輸入，但沒有任何提示能把一則排隊中的訊息自動變成已保存的任務。

一個 Gateway、一個信任網域：共享工作階段與獨立代理怎麼選

OpenClaw 2.0 最受矚目的改動是共享工作階段：其他人可以加入正在進行的工作，而且上下文會完整保留。獨立評測把這視為 OpenClaw 從單人操作轉向協作工作的轉捩點（eesel.ai）。不過，官方文件中的兩個概念，才是決定設定方式的核心。

多人模式代表多個受信任的人操作同一個代理。每個共享工作階段會記錄三層資訊：不可變更的建立者（一次寫入的 createdActor）、可重新指派的擁有者（類似 GitHub assignee，可隨時變更），以及實際發出提示者的參與者歷史（docs.openclaw.ai）。在線狀態會顯示觀看者與輸入者，但輸入中的草稿不會送進模型，也不會進入逐字稿。由於多個人的操控可能合併成同一回合，回合歸屬明確標記也只能做到盡力而為（docs.openclaw.ai）。實際上，代理正在執行工具呼叫時，第二個頻道送來的追問會進入逐字稿，但當前回合仍會先完成；因此第二則指令比較像操控提示，而不是中斷命令（docs.openclaw.ai）。

多代理模式則是由一個 Gateway 程序承載多個彼此隔離的代理大腦。每個代理都有自己的工作區、agentDir（驗證設定檔、模型登錄資料）與位於 <agentDir>/openclaw-agent.sqlite 的 SQLite 工作階段資料庫（github.com）。Binding 會把每個進入的頻道事件導向指定代理，匹配規則以最具體者優先；不同代理絕對不要共用同一個 agentDir，否則會互相覆寫 auth-profiles.json（stack-junkie.com）。最小範例是：{ agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } }，把一個機器人路由給一個代理。

請記住這句信任原則：「一個 gateway 就是一個信任網域」（docs.openclaw.ai）。角色、擁有者篩選器與頭像都不能隔離惡意使用者；彼此不信任的人應使用不同 Gateway，最好連作業系統使用者或主機都分開。

如果兩台裝置都屬於同一個人，選左欄。如果是兩個人，而且不應經常看到彼此的歷史紀錄，選右欄；若必須對不受信任的使用者執行真正的存取隔離，就使用兩個 Gateway。關於伴侶共用一個機器人的 Reddit 建議也大致一致：「建立 2 個代理、使用相同的驗證設定，但一個針對你……另一個針對你的妻子」（u/mr-cto-apps，r/openclaw）。另一串討論單一 Telegram 機器人共用問題時，有使用者建議：「你這種情況，大多數人就是執行兩個執行個體」（u/dertobi，r/openclaw）。即使 2.0 已加入共享工作階段，這項建議對於需要各自保有私人工作的人仍然成立。

代理忙碌時，你的第二則訊息會去哪裡

可以把訊息想成落入三個不同的桶，因為使用者經常混淆它們，最後就在交界處遺失工作。

第一桶：工作階段佇列。 代理工作期間送出的文字會附加到目前工作階段。啟用佇列模式後，訊息會等待處理，而不是直接丟失；在線狀態則讓你知道代理正處於哪個回合。你的訊息會影響下一回合，但不會中斷目前回合。輸入中的草稿預覽是暫時性的，永遠不會進入上下文（docs.openclaw.ai）。第二台裝置送出的訊息最好短而明確，例如「這件事完成後做 X，不要重新啟動 Y」，因為文件說明，當多個人的操控訊息合併時，回合歸屬只能做到盡力而為（docs.openclaw.ai）。

第二桶：持久化任務。 排隊中的訊息不等於持久化工作項目。Gateway 重啟、工作階段壓縮，或你執行 /new 後，對話中的承諾都可能消失。能撐過重啟的社群解法不是另一則訊息，而是一個檔案：用 active-tasks.md 保存可從崩潰中恢復的狀態，再準備一個 Boot.md，讓代理在工作階段與 Gateway 重啟時讀取（x.com）。記憶工具可以重新注入上下文，但一篇廣泛流傳的說明提醒，已載入的記憶本身也可能被摘要掉：「記憶確實存在磁碟上，只是代理失去了逐步讀取它的能力。」（x.com）

第三桶：排程工作。 Cron 與 Automations 只會在 Gateway 運作時執行；如果主機進入睡眠，排程也會停止（eesel.ai）。有使用者回報，Cron 執行期間會讓代理「基本上無法使用」，因為工作階段歷史大量灌入上下文，並建議按 Telegram 主題隔離上下文（x.com）。週期性工作應使用排程工作，但不要把它當成排入後續指令的替代方案。

佇列檢視畫面可能落後實際狀態：有討論指出，請求明明看得見正在排隊，但 /subagents 與 /tasks 卻顯示空白（reddit.com）。因此，第二桶中的檔案才是可跨重啟存活的檢查依據，不要只相信佇列介面。

不會遺失指令的兩台裝置設定

以下設定適合「一人使用筆電加手機」，也適合「兩位受信任隊友共用一個工作階段」。它以官方快速設定與正式環境 runbook 為基礎（docs.openclaw.ai），再加上社群逐步整理出的防遺失措施。

1. 把 Gateway 放在長時間在線的主機，並用身分存取。 小型 VPS、辦公室 Mac 或 Mac Mini 都可以；將 Gateway 綁定在 loopback，再透過 Tailscale Serve 或 Cloudflare Access 對外提供存取，不要直接開放公用連接埠，也不要共用 token。以身分為基礎的存取，才能在工作階段與提交紀錄中辨識每個人；共用 token 會讓所有人都變成同一個擁有者設定檔（docs.openclaw.ai）。
2. 讓兩台裝置加入同一個工作階段，而不是各自建立一個。 在兩台裝置上開啟 Control UI 或聊天頻道，明確指定工作階段擁有者（Control UI 的 Assign to me／Assign to，或使用 sessions 工具的 assign_owner），交接時使用 @mentions。私訊與群組房間需要分別設定允許清單（docs.openclaw.ai）。重新指派擁有者只會改變責任歸屬，不會改變建立者綁定的共享權限或封存權限，因此建立者最好保持不變。
3. 開啟佇列，讓工作能跨重啟保存。 將共享工作階段切換到佇列模式，讓回合進行中收到的訊息等待處理，而不是互相競爭；使用者回報，未啟用時訊息可能無聲無息地遺失。在工作區保留 active-tasks.md，每個承諾各寫一行（已完成／進行中／下一步），再加入 Boot.md，要求代理啟動時讀取它（x.com）。在依賴第二台裝置前，先確認模型確實能回應，因為只保存憑證並不代表驗證成功（docs.openclaw.ai）。
4. 延長手機使用頻道的工作階段壽命。 如果 Telegram 是第二個螢幕，而你的 thread 使用回報中的 thread: { mode: "idle", idleMinutes: 180 } 重設設定，長時間工作時就把時間拉長（有使用者調到 4 天），並分開不同主題，避免 Cron 輸出淹沒共享上下文。
5. 讓每個人使用自己的模型帳號。 Gateway 設定檔可以保存個人憑證；新工作階段會優先使用個人的預設值，不會改變 Gateway 預設值，其他使用者看到的也只是個人層級標籤，而不是電子郵件或帳號 ID（docs.openclaw.ai）。憑證必須透過受保護的 UI 或隱藏輸入的終端機提示輸入，絕對不要直接貼進對話，否則會進入共享逐字稿。
6. 完整測試整條流程。 從第二台裝置在代理執行期間送出訊息，確認訊息會保留，並在目前回合完成後處理；接著重啟 Gateway，確認 active-tasks.md 能恢復該項承諾。官方正式環境檢查清單的結尾也是同一件事：在宣布完成前，先驗證完整流程（docs.openclaw.ai）。

避免共享上下文逐漸失控的規則

使用者描述的多數問題，靠三條規則就能處理。

每次寫入記憶都標記作者。 最安靜、也最難察覺的失敗，是沒有來源的規則不斷累積，直到沒有人敢刪除：「共享上下文使用六個月後，裡面充滿沒人能追溯到作者的規則，因此沒人覺得自己有權刪掉它們。」建議的解法是「每次記憶寫入都標註作者」（x.com）。問題本質是共享寫入卻沒有作者資訊。持久化筆記前加上提出者與日期，每月清理一次。

把低信任使用者放進沙盒。 角色可以限制工作階段存取權、可使用的代理與 operator 權限；也可以把訪客工作階段強制放進 workspaceAccess: "none" 的沙盒，讓檔案與 shell 工具使用私有工作區，而不是共享代理工作區（docs.openclaw.ai）。私人草稿可以放在 Draft 工作階段中，但要記住：草稿不會出現在其他使用者的側邊欄，管理員仍然看得到（docs.openclaw.ai）。

知道什麼時候該停止共享。 一位多代理操作者把上下文混淆稱為「最大的實務挑戰」，表示代理會「逐漸越界到彼此的領域」（u/BP041，r/openclaw）。中文社群則提出更直接的做法：先調校好一個代理，再按裝置複製——「協助它複製到新裝置」，讓調整好的設定變成「每人一份」（x.com）——只同步記憶與 dotfiles，憑證和進行中的工作階段則留在原處（x.com）。這也符合文件提供的退路：使用各代理獨立的 Memory Wiki vault（vault.scope = "agent"），明確指定共享 Markdown 目錄，而不是跨代理搜尋逐字稿；如果必須真正隔離，就使用不同 Gateway（github.com）。

常見問題

兩台裝置可以同時共用一個 OpenClaw 代理工作階段嗎？

可以。兩台裝置加入同一個工作階段；保存上下文的是工作階段，不是裝置。指定擁有者並開啟佇列模式，讓第二台裝置送出的訊息等待處理（docs.openclaw.ai）。

為什麼壓縮、/new 或重啟後，指令會消失？

因為聊天訊息不是已保存的任務。壓縮會摘要上下文，/new 會建立全新的工作階段，而重啟會清掉記憶體中的狀態。請把承諾放進 active-tasks.md，再用 Boot.md 讓代理重新讀取（x.com）。

兩個人應該共用一個代理，還是各自使用一個？

如果兩個人需要同一串對話、同一份記憶與同一個佇列，就共用一個代理。如果歷史紀錄、憑證或權限不能混在一起，就各自使用一個代理（或各自使用一個 Gateway）；多人功能並不提供安全隔離（docs.openclaw.ai）。設定好 GitHub 歸屬後，共享操控也可以在提交中加入 Co-authored-by trailer（docs.openclaw.ai）。

共享還是複製？30 秒內做出選擇

佇列模式能避免兩個輸入者互相搶話，但無法替你解決互相衝突的指令——合併後的輸入仍可能混在一起。真正能讓指令在重啟後依然存在的，是檔案。