最後更新於 2026 年 8 月 12 日，資料核實自 Claude Code 官方 Releases、官方 CLI 文件 與跨會話通信文件。

截至 2026 年 8 月 11 日，Claude Code v2.1.224 已加入跨會話 SendMessage 與 ListAgents，v2.1.225 再補上跨機器發起對話及無人值守消息處理修復，當時最新版本為 v2.1.227。最快、最穩妥的部署方式不是立即把多個終端接到遠端，而是在 macOS 或 Linux 同一台機器上，以獨立工作樹、清楚命名和受控入站消息完成小規模驗證。消息通道只傳遞狀態、決策與阻塞資訊，不等於共享記憶、檔案同步或權限授權。

這篇適合以下讀者：

  • 同時開啟多個 Claude Code 終端，經常手動複製任務進度的個人開發者。
  • 需要讓前端、後端與測試 Agent 並行工作的 AI 編程團隊。
  • 準備在遠端 Mac 或長時間運行環境中託管編碼會話的平台工程師。

先用版本與拓撲確認功能邊界

部署前先不要急著傳消息。Claude Code 跨會話通信涉及版本、作業系統、模型供應渠道、登入狀態和連線拓撲，任何一項不符合，表面上都可能像是 SendMessage 失效。

先在每個會話執行：

claude --version
claude doctor

需要升級時，依官方 CLI 文件使用：

claude update

官方安裝條件目前包括 macOS、Ubuntu／Debian，以及透過 WSL 或 Git for Windows 執行的 Windows 環境；但這不代表跨會話功能在原生 Windows 終端、所有 WSL 配置或第三方模型渠道上都有相同支援。部署跨會話功能時，應以相關功能文件列出的範圍為準，而不是只看 Claude Code 整體能否安裝。官方設定與安裝說明

檢查項目 你要確認的內容 不符合時的處理
Claude Code 版本 至少涵蓋 SendMessage、ListAgents 的版本 先升級，再重新開啟會話
作業系統 優先使用 macOS 或 Linux Windows 先以 WSL 拓撲測試，不直接假設原生支援
模型渠道 確認目前登入方式與供應渠道在功能文件範圍內 改用官方文件明確列出的渠道
會話狀態 兩個終端都已登入，且不是已結束或暫停的會話 重新啟動並重新命名
工作目錄 每個會話對應獨立工作樹 先建立 Git worktree，避免共享 checkout

Claude Code 跨會話通信支持哪些系統？
比較安全的說法是：Claude Code 本身可在多種環境執行，但跨會話功能的作業系統、模型渠道和跨機器條件要以官方通信文件及版本說明為準。若你使用原生 Windows、容器套疊或第三方 API 轉接渠道，應先完成最小測試，不要把其他環境的成功經驗直接複製過來。

第一小時完成同機雙會話驗證

第一個目標不是完成程式碼，而是證明兩個會話能互相看見、能接收消息，並且在拒絕或暫存時給出可辨識的介面回饋。

建議在 macOS 或 Linux 上開啟兩個終端，並用角色命名：

  • frontend-review
  • backend-api
  • test-regression

會話名稱要反映職責，不要使用「終端 1」「終端 2」這類名稱。當團隊擴展到遠端 Mac 或多人協作時，模糊名稱會直接增加誤發消息的風險。

依序操作：

  1. 在第一個終端進入專案目錄，啟動 Claude Code，將它命名為前端或協調會話。
  2. 在第二個終端啟動另一個 Claude Code，使用不同名稱和不同工作目錄。
  3. 在其中一個會話執行 /list-agents，確認另一個會話是否出現在可見清單。
  4. 只傳送一則不涉及機密的測試消息，例如「請回報目前角色與工作狀態」。
  5. 記錄畫面顯示的是已送達、等待處理、暫存、拒絕還是找不到目標。
  6. 讓接收方回覆固定格式，例如「角色／目前分支／是否空閒」，再確認發送方是否收到。
  7. 關閉其中一個終端後重試，觀察斷線時是否出現明確錯誤，而不是把無回覆誤判為工作完成。

ListAgents 只能回答「目前有哪些可見會話」，不代表那些會話共享完整對話內容。會話恢復則是以會話識別資訊重新載入既有工作脈絡，和即時跨會話通信不是同一件事；Agent Teams 是更高階的團隊協作模式，子 Agent 則通常受主會話調度，不能混為一談。官方 Agent Teams 文件

Claude Code 的兩個終端怎麼互相發送消息？
先以 /list-agents 確認目標會話可見，再使用 SendMessage 指向明確的會話名稱。第一輪只傳遞狀態、決策或阻塞原因，不要貼整段程式碼，也不要把消息內容寫成「請直接修改某個檔案」。消息的作用是通知，不是替另一個會話取得工具控制權。

第二步用 Git worktree 隔離並行修改

兩個會話即使能互相傳消息，只要仍然共用同一個工作目錄，就可能同時改寫同一檔案。這是多 Agent 協作最容易被忽略的隱性成本：衝突不一定立即出現在 Git 狀態裡，也可能表現為測試結果前後不一致、未提交修改被覆蓋，或某個會話讀到另一個會話尚未完成的半成品。

你可以先建立獨立工作樹：

git worktree add ../project-frontend -b agent/frontend
git worktree add ../project-backend -b agent/backend
git worktree add ../project-test -b agent/test

每個 Claude Code 會話只進入自己的工作樹。消息內容則固定限制在四類：

  • API 或介面欄位變更。
  • 分支與提交狀態。
  • 測試命令及結果。
  • 需要另一個會話解除的阻塞原因。
協作方式 檔案隔離 消息適合傳遞 主要風險
同一 checkout 多會話 無 短狀態、提醒 修改同一檔案、未提交變更互相干擾
每個角色一個 Git worktree 有 介面契約、提交、測試結果 合併前仍需人工審查
跨機器加獨立 worktree 有 狀態、阻塞、交接資訊 連線中斷、目標會話名稱錯誤
Agent Teams／子 Agent 依模式而定 由主會話或團隊機制調度 權限、生命週期與上下文邊界更複雜

例如後端會話改動 user_id 欄位後，不要把整個檔案貼到前端會話，而應傳送：

「API 回應欄位由 id 改為 user_id，已提交於 agent/backend，請更新型別並執行回歸測試。」

前端完成後，再回報修改的檔案、測試結果和提交識別。這樣可以降低協調衝突，但不能代替程式碼審查；消息送達也不能證明修改正確。

更多工作樹隔離原則，可參考本站的 Git worktree 與編碼 Agent 隔離實踐文章。

第一天再擴展到跨機器與遠端 Mac

完成同機測試後，才進入跨機器階段。此時至少要分清三條傳輸路徑：

  1. 同機會話：多個終端位於同一台 macOS 或 Linux 主機，主要受本機程序、工作目錄和使用者權限影響。
  2. 本機到雲端會話：本地終端與雲端執行環境之間有額外的登入、工作階段和網路條件。
  3. 遠端控制其他機器：消息需要經過遠端連線與目標主機上的 Claude Code 會話，不能視為本機 socket 的延伸。

Claude Code 跨機器消息是否經過伺服器？
不要用「一定是本機直連」或「一定經過某個伺服器」作為部署假設。跨機器通信的實際傳輸方式、登入條件和連線生命週期應以對應版本的官方文件為準；對平台工程而言，只要消息離開本機，就應按照網路路徑處理，納入連線中斷、身份驗證、日誌與敏感資訊風險。官方 Remote Control 與會話文件

首次跨機器驗收時，請使用非敏感測試消息，並逐項確認：

  • 目標會話名稱沒有重複。
  • 發送方能辨識正確回覆地址。
  • 目標主機上的工作目錄與本機預期一致。
  • 斷開 SSH、遠端控制或網路後，發送方能區分「尚未送達」與「已送達但尚未處理」。
  • 容器內外的 Claude Code 是否能互相發現。

容器是常見陷阱。即使兩個會話使用同一份程式碼映像，容器內的程序、socket、環境變數和檔案系統可能與主機隔離，因此不能因為兩邊都看到相同 Git 儲存庫，就推論它們會自動互相可見。

上線前收緊消息入口與工具權限

跨會話通信最容易被誤解的地方，是接收消息不代表接收方會自動批准命令。消息不應繞過目標會話原有的工具權限、沙箱限制、命令審批或檔案寫入規則。

你可以按三種執行場景設定策略：

  • 互動式會話：可以接受一般狀態通知，但涉及修改、部署或憑證操作時保留人工審批。
  • 繞過權限提示的會話：不建議直接接受跨機器消息；若必須使用，先縮小工作樹、命令範圍和可寫路徑。
  • 無人值守任務：預設採用 hold 或 refuse，只有在任務邊界、輸入來源與停止條件都明確時才考慮 accept。

敏感專案可直接禁止 ListAgents 與 SendMessage，或只允許固定會話名單。設定檔的具體鍵名和優先順序要對照官方設定文件，避免把社群範例當成穩定 API。官方 Settings 文件

會話類型 建議入站策略 必須驗收的條件
本機互動式開發 accept 或 hold 消息來源、目標名稱、工作樹一致
跨機器開發 hold 額外身份確認、斷線行為、敏感資料過濾
CI／無人值守 hold 或 refuse 固定任務、可追溯日誌、明確停止條件
生產或含憑證專案 refuse 或白名單 禁止未審批消息觸發工具操作

第一週用記錄判斷是否值得擴大

跨會話功能是否值得長期使用，不應只看「消息有沒有送到」。第一週應記錄以下項目：

  • 消息送達或失敗的結果。
  • 人工審批次數。
  • 重複通知和過期狀態。
  • 兩個會話修改同一檔案的次數。
  • 由於等待另一會話回覆而產生的空閒時間。
  • 最終仍需人工重新說明上下文的比例。

若任務高度串行、頻繁修改同一檔案，或消息往返次數已經接近實際工作量，就應退回單一會話、子 Agent 或一般會話恢復。跨會話通信真正適合的是「前端已完成介面變更，後端需要知道」「測試發現阻塞，請通知負責人」這類短距離協調，而不是把完整需求、所有檔案內容和長期記憶拆成大量消息。

你可用以下清單作為首次上線門檻：

  • [ ] 所有會話版本已核對，且每個會話都能正常執行 claude doctor
  • [ ] macOS 或 Linux 同機雙會話已完成 /list-agents 可見性測試
  • [ ] 每個角色已使用獨立 Git worktree
  • [ ] 測試消息不包含 API 金鑰、個人資料或原始碼機密
  • [ ] 已驗證消息送達、暫存、拒絕與斷線回饋
  • [ ] SendMessage 只傳遞狀態、決策、提交和阻塞資訊
  • [ ] 跨機器連線已用非敏感內容完成雙向測試
  • [ ] 容器內外的會話發現限制已被記錄
  • [ ] 無人值守任務已設定 hold 或 refuse 策略
  • [ ] 團隊已訂出回退條件：衝突增加時改用單會話或子 Agent

如果第一週記錄顯示多個會話需要持續在線、跨時區接力，或會話不應佔用個人開發機，才值得進一步規劃固定工作樹、會話恢復和遠端 Mac 容量。你可以先從本站的 遠端 Mac 部署與 AI Coding 多會話容量文章了解環境規劃，再按照會話數量與在線週期估算資源。

目前環境與遠端 Mac 的取捨

把多個 Claude Code 會話放在個人 Mac 上，優點是檔案和終端都在手邊；但長時間運行時，睡眠、重啟、網路切換、使用者離開和本機其他工作都會影響會話穩定性。直接使用一般雲端主機，則可能遇到 macOS 工具鏈不完整、遠端互動體驗不一致，以及檔案與憑證管理更複雜等問題。

因此，如果你的任務只需短時間並行修改，本機 macOS 加 Git worktree 通常更簡單；若需要多個會話長時間在線、交接或透過遠端控制維持環境，租用獨立的遠端 Mac 往往比持續佔用個人設備更容易管理。你可再查看 kvmsync 的方案與租用資訊，按工作樹數量、在線週期和是否需要跨時區接力作決定；不需要長期運行、也不需要 macOS 專屬工具鏈的任務，則不必為了跨會話通信額外租用環境。

延伸閱讀

kvmsync M4 遠端節點

為多 Agent 協作打造穩定的遠端 Mac 環境

使用 kvmsync 租用遠端 Mac，讓不同開發會話各自擁有獨立且可控的工作環境。

立即租用 Mac mini M4 對比 M4 套餐