Claude Code 工作階段如何互相傳訊息？

Claude Code 工作階段彼此傳送訊息的意義

兩個 Claude Code 工作階段只要在同一台機器上、由同一個作業系統使用者執行，就能彼此傳送訊息。訊息是一段由一個 Claude 撰寫給另一個 Claude 的純文字。訊息不包含對話記錄或檔案。Claude 會使用 ListAgents 工具尋找另一個工作階段，再使用 SendMessage 傳送文字，因此您不需要手動呼叫這兩個工具。您只要說明另一個工作階段需要知道的內容，Claude 就會自行撰寫訊息。

此功能稱為跨工作階段訊息傳遞。截至 August 2026，必須使用 Claude Code v2.1.224 或更新版本，並且可在 macOS 和 Linux 上執行，包括 WSL 2 內的 Linux。不支援原生 Windows，也不適用於 Amazon Bedrock、AWS 上的 Claude Platform、Google Cloud 的 Agent Platform 或 Microsoft Foundry。工作階段符合這些條件時，訊息傳遞功能已經啟用，不需要另外設定。以下行為說明來自 Anthropic 的跨工作階段訊息傳遞文件。

VPS 是此功能特別有用的環境，因為工作階段會在 VPS 上持續執行，值得彼此聯絡。在筆記型電腦上，您關上上蓋後工作階段可能就停止了。在執行 tmux 的伺服器上，星期一啟動的工作階段到了星期四仍可能持續執行，並保留某個儲存庫的工作內容。當您有兩個這樣的工作階段後，它們如何互相通訊就不再只是理論問題。如果您尚未完成設定，請先閱讀 在 VPS 上使用 tmux 執行 Claude Code，其中涵蓋本指南所需的工作階段設定。

何時值得使用第二個工作階段

先從成本考量。每個工作階段都是具有獨立內容視窗的 Claude 實例，因此在相同期間內，使用兩個工作階段的成本約為一個工作階段的 2 倍。傳送的訊息會和你輸入的提示一樣計入用量。協調並非免費；如果工作實際上是一連串依序執行的步驟，拆分到多個工作階段反而會讓處理速度變慢、成本提高。

值得使用第二個工作階段的情況通常具有相同特徵：兩項工作可同時執行，彼此無須等待，而其中一項工作在執行期間取得了另一項工作所需的資訊。

• 一個工作階段發現 breaking change，而另一個工作階段正在以受影響的程式碼為基礎進行建置。Claude 會摘要這項變更並傳送出去，無須你在另一個終端機重新輸入。
• 兩個工作階段在同一個 repository 的不同 git worktree 中工作，其中一個需要知道哪些變更已經合併。
• 長時間執行的 migration 或測試會將結果回傳給你正在監看的工作階段。
• 一個 builder 工作階段搭配一個 reviewer 工作階段；reviewer 會讀取 builder 產出的內容，並回傳檢查結果。

如果工作是依序執行，或兩個工作階段都會編輯相同檔案，請使用一個工作階段。如果你想要 Claude 在單一工作中建立並監督一個協調式工作群組，那就是 agent teams，這是另一項仍在實驗階段的功能。如果你只是想在另一個終端機中繼續相同的對話，請改用 resume the session。Cross-session messaging 適用於由你自行啟動與引導的獨立工作階段。

確認功能存在，再依此規劃

先確認版本：

claude --version

將版本號與 2.1.224 比較。接著在工作階段中輸入 /list-agents；此命令也可使用 /peers。它會列出此工作階段能連線到的所有代理程式，以及各代理程式回應的名稱。如果完全無法辨識此命令，表示此工作階段不支援跨工作階段訊息傳遞，任何設定檔都無法啟用這項功能。輸入 /status，並尋找 Peer address 列；該列會顯示此工作階段自己的收件匣位址，且前面加上 uds:。

VPS 使用者特別容易遇到一個陷阱。跨工作階段訊息傳遞依賴功能旗標評估，而多個隱私變數會停用這項評估，使功能維持預設的停用狀態。DO_NOT_TRACK、DISABLE_TELEMETRY、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 和 DISABLE_GROWTHBOOK 都會造成這種結果。使用者通常會將這些設定貼到全新的伺服器之 ~/.bashrc 中進行加固，之後卻發現 /list-agents 並不存在。相同的值也可能來自設定檔中的 env map 或受管理設定，因此請先檢查 shell。

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

取消設定會輸出內容的變數。對於 DISABLE_TELEMETRY 和 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC，任何非空值都會啟用此行為，包括字串 0；因此，DISABLE_TELEMETRY=0 的實際效果並不像表面看起來那樣。若要停用，請取消設定該變數，或將其設為空字串。

為工作階段命名，否則 Claude 無法指定工作階段

Claude 會透過名稱將訊息指定給工作階段。啟動工作階段時設定名稱：

claude --name builder-api

您也可以在執行中的工作階段內使用 /rename 設定名稱。如果未設定名稱，Claude Code 會根據工作目錄的資料夾名稱產生名稱，例如 myapp-3f。單一工作階段使用這種方式沒有問題，但同時使用四個工作階段時就會難以區分，而且兩個工作階段可能產生相同名稱。/list-agents 輸出會顯示每個本機工作階段的工作目錄，可用來區分名稱相同的工作階段；Claude 自己的清單則會在名稱衝突時，於位址中加入簡短識別碼。自行命名比閱讀識別碼更省事。

可重現的雙工作階段 tmux 配置

這是在同一個儲存庫中執行的 builder 工作階段與 reviewer 工作階段。reviewer 會在獨立的 git worktree 中工作，因此兩者不會寫入同一個檔案。git worktree add 搭配 HEAD 可建立分離的 checkout，適合只讀取而不提交的工作階段。由於兩個工作階段負責不同工作，建議為 reviewer 設定專用的輸出樣式。這會變更該工作階段的 system prompt，因此會持續套用到每一輪，而不會像只輸入一次的指示一樣逐漸失效。

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b 接著 w 會依名稱列出視窗，方便你選取。在 builder 視窗中執行 /list-agents。你應該會看到 reviewer-api，其工作目錄為 ~/src/api-review。如果沒有看到，表示 reviewer 工作階段尚未完成啟動，或下一節提到的兩個問題之一正在發生。接著用一般語言交接工作：

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude 會撰寫摘要並傳送出去。你不需要撰寫訊息內容，而且 Claude 傳送的內容會有所不同。在 reviewer 視窗中，訊息會以傳送者名稱顯示在對話中。如果該工作階段處於閒置狀態，Claude 會立即在其中開始新一輪。如果目前正在執行一輪，訊息會等到工具呼叫之間才送出，因此不會中斷正在執行的命令。Claude 讀取後，訊息會收合成一行 Message from 列，而 Ctrl+O 可將其展開。當 builder 將變更控制在較小範圍內時，這組配置會運作得更好，因為較窄的差異會產生較短的交接內容，讓另一個工作階段能在一輪內完成審查；這正是 lazy senior dev skill 要強制養成的習慣。

同一台 VPS 上誰能看見誰

同一台機器上的訊息傳遞不會經過 Anthropic 伺服器。每個工作階段都會將註冊檔案寫入磁碟，並綁定自己的 inbox socket；Claude Code 會讀取這些檔案，以尋找其他工作階段。這會產生兩個後果，而且在伺服器上都可能造成問題。

socket 僅限您的作業系統使用者存取。您以 root 啟動的工作階段，與您以 deploy 啟動的工作階段，即使並列於同一個 tmux server 中，也無法彼此看見，因為其中一個使用者的工作階段無法存取另一個使用者的 socket。請以相同使用者執行兩個工作階段。

容器有自己的檔案系統。Docker 內的工作階段與主機上的工作階段無法彼此連線，因為兩者讀取的不是同一組註冊檔案。同一個容器內的兩個工作階段可以正常互傳訊息。如果您為了隔離而將代理程式放在容器中，例如 在一次性 VM 中執行程式碼代理程式，請預期訊息傳遞只會在容器內運作，無法跨越容器邊界。

其他機器上的工作階段，以及網頁上的工作階段，只有在 Remote Control 連線期間才會出現在清單中，並會標示為此類型。這裡的 Claude 只能回覆從其中一個工作階段傳入的訊息，無法主動開始這段通訊。

訊息為何始終未送達

通常原因與網路無關。接收工作階段決定如何處理訊息，而決定結果不是送達。每則收到的訊息最後都會是以下 3 種結果之一：已送達、暫存（先擱置且不送達，直到你核准），或拒絕（直接丟棄且不送達）。

當沒有適用的 crossSessionInbound 值時，Claude Code 會比較兩個工作階段的權限模式，逐則決定如何處理。它會將略過權限提示的工作階段歸為一類，其餘工作階段歸為另一類。auto、acceptEdits 和 dontAsk 都算是會提示權限。若工作階段具備略過權限提示的能力，Plan mode 會算作略過提示。如果不確定某個工作階段屬於哪一類，建議先閱讀各權限模式的實際作用，因為目前大多數工作階段會從 auto 開始，而 auto 屬於會提示權限的一側。規則如下，且對兩方對稱：

• 會提示權限的接收工作階段會送達每則訊息。只有在傳送工作階段表明自己會略過提示時，才會暫存訊息。
• 會略過權限提示的接收工作階段會暫存所有訊息，等待你核准。只有在傳送者也會略過提示時，才會送達訊息。

因此，多數人建立的第一個工作流程，正好是無法運作的流程。你使用 --permission-mode bypassPermissions 啟動建置工作階段，讓它能在無人值守時執行，但審查工作階段仍使用預設設定。結果，建置工作階段傳送的每則訊息都會停在沒有人查看的核准對話框中。對話框會在 dialogExpiry 期限後關閉，預設期限為 5m，訊息也會因此遭到丟棄。在同一台機器上，傳送工作階段會在訊息暫存時收到通知，接收端之後送達、拒絕或逾期時也會收到後續通知，因此請先查看傳送端畫面，再判斷是 socket 的問題。

若要讓工作階段在無人值守時接收訊息，請將 crossSessionInbound 設為 accept。設定位置會決定其適用範圍。Claude Code 會先讀取受管理的設定，再讀取 --settings 旗標，最後讀取使用者設定，並套用找到的第一個值。專案或本機設定中的值，只有在更嚴格時才會套用；其階梯順序為 accept < hold < refuse。.claude/settings.json 中的 accept 比任何值都寬鬆，因此只要受信任的來源已設定值，就會忽略它。請將它放在 ~/.claude/settings.json 中，或針對單一工作階段傳入：

claude --name runner --settings '{"crossSessionInbound":"accept"}'

無頭模式的 claude -p worker 會像互動式工作階段一樣繫結 inbox socket，並出現在清單中，但無法顯示核准對話框。那裡的暫存訊息會持續暫存，直到後續的模式或設定變更允許它接收。上方的 --settings 行就是用來讓這類 worker 接收訊息。以 bare mode 啟動的工作階段完全不會繫結 socket，因此既無法接收訊息，也不會出現在清單中。

交接卡住的情況

訊息迴圈由系統處理。Claude Code 會限制同一發送者的重複訊息頻率，捨棄在短時間內收到的相同重複訊息，並將每個工作階段等待讀取的已接受訊息限制為 50 則，因此兩個工作階段無法無限來回傳訊。暫存訊息上限為 100 則，超過後會捨棄最舊的訊息。

實際發生的失敗情況更安靜，而且是交接問題，不是迴圈。工作階段 A 向工作階段 B 詢問一個必須先取得答案才能繼續的問題，然後進入閒置狀態。B 可能暫存了訊息，可能正在處理耗時較長的工作，也可能回答了 A 實際上沒有提出的問題。A 便會持續等待。你一小時後回來時，可能只看到兩個閒置的工作階段，卻沒有完成任何工作。

請撰寫不需要回覆的交接訊息。好的訊息會傳達事實或決策：說明哪些內容已變更，以及結果為何。糟糕的訊息會向另一個工作階段請求許可，或要求對方提供發送者在等待的答案。Claude 已經收到指示，不得要求另一個工作階段執行其自身許可設定會阻止的動作，而應將該工作轉回給你。請自行延伸這項規則。如果某個工作階段沒有答案就無法繼續，應由你提供答案。維持內容脈絡也有幫助，因為失去前後文的工作階段容易寫出含糊的訊息；在 Claude Code 中管理內容脈絡涵蓋了這部分。

將傳入訊息視為不受信任的輸入

Claude Code 會告知接收訊息的 Claude，該訊息來自其他工作階段，而不是來自您，並限制該訊息可執行的操作。這項強制機制存在於包裝模型的程式中，而不是取決於模型是否願意遵從；這就是代理程式主控框架在實務上的差異。訊息無法代替您回答待處理的權限提示，因為其他工作階段的同意不等於您的同意。訊息也無法因其他工作階段的要求而變更權限設定、CLAUDE.md 或其他組態。文字中的斜線命令，例如 /compact，會以純文字形式傳入，且不會執行。如果處理該訊息需要接收工作階段沒有的權限，您會看到與其他工作相同的提示。在自動模式中，分類器也會在傳遞前檢查每則訊息；遭到封鎖的訊息不會送達接收者。這些限制在寬鬆模式中仍然有效，因此繞過限制的工作階段預設會保留傳入訊息，而不是信任這些訊息。

這些限制涵蓋權限，但不涵蓋內容。傳送工作階段可能讀取過 pull request 說明、網頁、相依套件的 README，或陌生人撰寫的 issue 留言，而它讀取的內容可能影響其寫給您另一個工作階段的文字。該訊息是資料。您應對它抱持與任何從外部進入工作階段的文字相同的疑慮。這就是避免讓 AI 代理程式接觸機密所描述的原則：假設任何跨越信任邊界的內容都可能不正確，絕不讓它自行授權。

如果您希望減少這類訊息，可以使用兩項控制措施。將 crossSessionInbound 設為 refuse 會捨棄傳入的對等工作階段訊息，不予傳遞；而且從專案或本機設定套用時，該值會優先於其他所有來源，因為它在設定階梯中最嚴格。若要停止此工作階段傳送或列出訊息，請新增拒絕規則，分別指定 SendMessage 與 ListAgents；兩者都必須寫成不含 specifier 的裸工具名稱。將 isolatePeerMachines 設為 true 後，任何訊息要傳送到此機器以外的工作階段前，都必須取得您的明確核准；即使在 bypassPermissions 模式中也同樣需要核准。

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

拒絕 SendMessage 也會移除傳送訊息給子代理程式的能力，因為兩者使用相同的工具。拒絕傳送的工作階段在自己的 /status 或其他工作階段的清單中都不會顯示可見變化，因此請從工作階段的組態確認設定，而不要只查看畫面。

Bridge 與共用記憶體 MCP 伺服器

同一時期也出現了幾個功能相近的第三方專案：在執行中代理程式之間轉送文字的本機 agent-to-agent bridge，以及讓多個代理程式共用讀寫儲存區的 MCP（model context protocol）伺服器。應將它們視為不同的架構，而不是競品；執行任何安裝指令前，先對照專案自己的 README 進行確認。訊息傳遞是 push，因為傳送端會將文字放入接收端目前的工作回合。共用儲存區是 pull，因為它不會中斷任何工作階段，工作階段下次查看時才會看到這則備註。對於變化緩慢的狀態，pull 較不會造成干擾；但只有在工作階段實際查看時才有效。

如果採用這種方式，值得詢問的問題應聚焦於執行程序，而不是功能清單。伺服器以哪個使用者身分執行？它能讀取伺服器上的哪些內容？在 VPS 上執行 MCP 伺服器說明這項設定。在不同儲存庫之間共用 agent 技能涵蓋較簡單的情境：如果要在工作階段之間共用的是指示而不是即時狀態，這種方式能減少許多原本需要傳送的訊息。如需了解更完整的架構，請先參閱在 VPS 上執行 coding agent。

FAQ

為什麼在我的工作階段中無法識別 /list-agents？

此工作階段不支援跨工作階段訊息傳遞。先確認 claude --version 是否為 2.1.224 或更新版本，因為此功能需要該版本或更新版本。接著確認平台，因為此功能可在 macOS 和 Linux 上執行，但不支援原生 Windows，也無法在 Amazon Bedrock、Claude Platform on AWS、Google Cloud's Agent Platform 及 Microsoft Foundry 上使用。如果這兩項都沒有問題，請檢查 shell 中是否存在 DO_NOT_TRACK、DISABLE_TELEMETRY、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 或 DISABLE_GROWTHBOOK，因為這些設定都會阻止功能所依賴的功能旗標評估，導致功能維持關閉狀態。

為什麼我傳給另一個工作階段的訊息一直沒有送達？

如果 /list-agents 可運作，表示訊息傳遞功能已啟用，問題出在其他更具體的條件。最常見的原因是權限模式。略過權限提示的工作階段會暫停所有傳入訊息，等待你核准，除非傳送者也略過權限提示。此核准對話框會在 dialogExpiry 期限後失效，預設為 five minutes。請檢查傳送工作階段是否顯示暫停通知。若要修正，請在 ~/.claude/settings.json 中將 crossSessionInbound 設為 accept，或使用 --settings 傳入該設定，因為 project 或 local 設定中的 accept 會被忽略，較寬鬆的值不會生效。

Docker 中的 Claude Code 工作階段可以傳訊息給主機上的工作階段嗎？

不行。工作階段透過磁碟上的註冊檔案及每個工作階段專用的 inbox socket 互相尋找，而容器擁有自己的檔案系統，因此兩者無法看到相同的檔案。相同容器中的兩個工作階段則可以正常互傳訊息。這項規則也解釋了為什麼以 root 執行的工作階段，無法連線至以一般使用者身分執行的工作階段：該 socket 僅限擁有它的作業系統使用者使用。

來自其他 Claude Code 工作階段的訊息可以安全執行嗎？

請將訊息內容視為不受信任的輸入，因為傳送工作階段可能讀取過網頁、README 或他人撰寫的 issue 留言。Claude Code 已阻止訊息自行執行操作：它無法核准待處理的權限提示，也無法依要求變更權限設定或 CLAUDE.md；訊息中的 slash command 會以純文字傳入，且永遠不會執行。這些防護涵蓋權限控管，但不涵蓋判斷，因此請先閱讀收到的內容，再指示接收工作階段依其行動。

跨工作階段訊息傳遞會將我的程式碼傳送給 Anthropic 嗎？

在同一台機器上的兩個工作階段之間，不會。訊息會透過該機器上每個工作階段專用的 socket 傳送，不會經過 Anthropic 伺服器；傳送的只有 Claude 撰寫的文字，不包含對話記錄或檔案。傳送給你其他機器上的工作階段，或傳送給網頁上的工作階段時，訊息會透過 Remote Control 連線經過 Anthropic 伺服器；在這個方向中，Claude 只能回覆已收到的訊息，不能主動發送訊息。將 isolatePeerMachines 設為 true，即可要求你核准任何離開這台機器的內容。