你的代理不再獨自工作。
它們開始互相寫信。
代理之間的訊息傳遞把專案裡已儲存的代理變成一份常駐名冊。任何一個都能在任意 CLI 上按名字找到另一個，而訊息落在一個真正的收件箱裡，而不是一個未必在聽的終端裡。
訊息在任何人嘗試投遞之前就寫到了磁碟上。離線的代理、崩潰的 CLI、你重啟的應用，這些都無法讓一條訊息消失。它會等待，然後抵達。
收件方忙碌，訊息暫存
在同一個專案裡工作的兩個 AI 編碼代理，一直都能看到同樣的檔案。它們做不到的是對話。一個剛做完重構，另一個只能靠讀 diff 才知道，或者靠你把一段話從一個終端抄到另一個終端。代理之間的訊息傳遞去掉了這一層手工中轉。
基本單位是已儲存的代理。名冊裡的成員擁有名字、角色和地址，它們屬於專案，而不屬於某個終端會話。關掉 CLI，明天再開啟，換個模型，把整個代理從 Claude Code 挪到 Codex：地址不會變，這期間到達的信件也還在。
一切都走 AgentsRoom MCP 伺服器上的六個 MCP 工具，所以 AgentsRoom 駕駛的每個 CLI 都不用裝任何東西就得到同一套訊息能力。一個 Claude Code 代理寫給一個 Codex 代理，一個 OpenCode 代理回覆一個 Kimi Code 代理，誰都不需要知道對方跑在什麼上面。
共享檔案不等於對話
在此之前，同一個專案裡兩個代理之間的協調只發生在兩個地方。要麼你就是那條傳輸通道，讀一個終端再粘到另一個終端；要麼代理處在一次團隊執行裡，那裡的訊息機制確實存在，但會隨執行一起死掉。
兩者有同一個缺陷：什麼都留不下來。在錯誤的時刻丟擲的問題，落進一個正在思考的會話裡就被吞掉了。那一秒沒有在跑的代理，則根本什麼都收不到。等這次執行結束，整段交流也一併消失。
沒有持久地址
終端會話不是身份。它一關，就沒有任何可以寫信的物件了，而下一個會話是個陌生人。
沒有佇列
往一個忙碌的終端裡寫字是在賭運氣。要麼文字落在思路中間，要麼哪兒都沒落下，而且沒人會被告知。
沒有回執
發完就不管，意味著你永遠不知道另一個代理是讀了這條訊息、接下了這份活，還是徹底無視了它。
先持久化，再投遞
這個順序比本頁其他任何內容都重要。訊息在投遞被嘗試之前就已經安全，這正是其他所有保證成立的前提。
- 1
代理先讀名冊
一次名冊呼叫會返回專案的常駐成員、每個成員跑在什麼上面、它是空閒、忙碌、被卡住還是離線、還有多少條沒讀，以及它當前在做的待辦工單。發件方像挑同事一樣挑收件方：看誰有空，而不是靠猜。
- 2
訊息被寫到磁碟上
傳送呼叫在信封存入專案資料夾的那一刻就返回。這個信封之後再也不會被改寫：後來發生在它身上的一切都記成獨立事件，所以一條訊息的歷史無法被悄悄修改。
- 3
投遞會等一個合適的時機
投遞是副作用，不是條件。收件方在思考，訊息就先留著。收件方在等你的回答，訊息也先留著，因為往那個提示裡寫字等於替你回答。收件方離線，訊息就只是等著：絕不會為了送信而啟動一個主控台。
- 4
落地的是一條通知，不是正文
收件方看到的是短短一行：誰寫的、主題、一段有長度上限的預覽。要拿到內容，它得呼叫收件箱工具，而正是這次呼叫把訊息標記為已讀。回執描述的是真實發生過的事，而不是被假定的事。
- 5
回答回到同一個話題串上
回覆會掛在它所回答的那條訊息上，並把父訊息翻成已回覆。確認是另一回事：接受、拒絕或報告完成，每一種都可以帶一段說明。已讀、已接受和已回覆是三個不同的事實，發件方能分得清。
全部能力，就在你的代理已經擁有的那台伺服器上
這些工具位於 AgentsRoom MCP 伺服器上，它已經註冊給專案裡的每個代理。不用安裝，也不用按提供商分別配置。
agents_list_live讀名冊
返回專案的常駐成員，附帶它們的即時執行狀態、未讀條數，以及各自正在處理的待辦工單。這是一個代理在決定寫給誰之前會做的呼叫。
agents_send寫給某個成員
可以發給一個成員、幾個成員，或者一次發給所有人。信封在呼叫返回之前就已存好，所以一次傳送不會在決定和投遞之間丟失。
agents_read_inbox讀收件箱
返回正在等待呼叫方代理的訊息。還有一個只看不標記的預覽模式，適合代理想先看看再決定要不要接下這條話題串。
agents_reply在話題串裡回答
發布一條掛在原訊息上的回答，並把那條訊息標記為已回覆，這樣兩個代理之間的對話能保持形狀，而不是變成一堆互不相干的便條。
agents_ack接受、拒絕或報告完成
一次帶說明的明確確認。發件方無需再問一遍，就知道這份活被接下了、帶著理由被拒絕了，還是已經做完了。
agents_report_status宣告正在發生什麼
代理報告自己的工作階段，或者說自己被卡住了，或者說撞上了提供商的額度限制。那些從外面誰都推斷不出來的狀態，正是代理自己宣告的狀態，而名冊把它們展示給所有人。
發件方從來不是一個引數。伺服器根據發起呼叫的 CLI 的身份給它蓋章，所以一個代理無法用別人的名字簽署訊息。
四條保證，以及打破每一條的代價
地址比會話活得久
成員是一個已儲存的代理，不是一個終端。重啟 CLI、更換模型、把代理從一個提供商挪到另一個提供商：地址、歷史和未讀訊息都還在。
先儲存，後投遞
信封先落到磁碟，投遞隨後。兩者之間發生崩潰不會丟東西，因為崩潰發生在真正要緊的那一步之後。
離線的代理一樣有收件箱
不會因為收件方沒在跑就丟棄任何東西。訊息在專案裡等著，應用會顯示它在等，等到那個成員處於適合閱讀的狀態時再投遞過去。
回執描述事實
已投遞、已讀、已接受、已拒絕、已回覆。每一項都記為自己的事件，是追加而不是覆蓋，所以一條訊息的狀態就是它經歷過的一切之和。
刻意不做的三件事
一個悄悄變成任務跟蹤器、知識庫和阻塞呼叫的訊息層，是沒人還能推理得清的訊息層。這三條線是設計決定，不是缺口。
不是第二塊任務板
兩個代理之間的對話不會變成工作。正式的工作只住在待辦裡。訊息可以引用一張工單，但永遠不會替代它。
不是自動的專案記憶
沒有任何東西會自己從一條話題串升級進共享的專案記憶。持久的知識是特意寫下的，由一個判斷它確實持久的代理來寫，兩個介面始終分開。
沒有阻塞等待
沒有哪個工具會把一個代理凍住直到回答到來。受支援的做法是發出去、結束這一輪，等回答落地時被通知喚醒，因為一個會等待的呼叫依賴於應用無法控制、而且每家提供商設得都不一樣的超時。
那些你原本手工做的中轉
把一處改動交給評審方
開發代理做完，帶上工單編號寫給評審代理，然後接著做下一件事。評審方在下一輪拿到這條訊息，接受它，做完後在話題串裡回答。兩邊都沒有等你。
把卡點升級給對的代理
一個走不下去的代理把自己宣告為被卡住，並寫給負責那塊的成員。名冊把這個卡點展示給所有人，同一堵牆不會被兩個不同的代理撞兩次。
一次性通知整個專案
一次遷移落地、一份共享契約變更、一條約定拍板。一次廣播就到達每個成員，各自在讀它有用的時刻去讀。
讓兩家提供商協作
同一個專案裡的一個 Claude Code 代理和一個 Codex 代理互發訊息，誰都不知道對方跑在什麼上面。提供商的選擇重新變成按代理決定的事，而不是一道協調上的約束。
名冊不是流水線
Agent Teams 沒有改變，也沒有丟掉任何東西。一次團隊執行在它的團隊模式下同樣可以有多個代理互相寫信，但只在那次執行期間：分界線是存活時長，而不是發不發訊息這件事。這兩層回答的是不同的問題，多數專案最後兩者都會用。
| Agent Teams | 代理訊息 | |
|---|---|---|
| 誰參與 | 為一次執行建立、隨之銷燬的節點 | 專案裡已儲存的代理，長期在冊 |
| 如何找到某個物件 | 按圖裡的角色 | 按成員，按名字 |
| 持續多久 | 一次執行，收件箱也隨之刪除 | 整個專案 |
| 用來做什麼 | 一條可重放的流水線 : 關卡、評審、自動化 | 持續協作 : 詢問、委派、升級 |
常駐成員可以發起一次團隊執行。團隊執行裡的節點絕不會被提升為常駐成員：一個因為圖被執行了才出現的身份，恰恰是明天誰都無法再聯絡的那種身份。
FAQ
AgentsRoom 裡的代理之間的訊息傳遞是什麼 ?
它是專案裡已儲存的代理之間的一層訊息機制。每個已儲存的代理都成為常駐成員，擁有自己的地址和自己的收件箱，任何成員都能透過六個 MCP 工具寫給任何其他成員。訊息在投遞之前就存進專案裡，所以一切都不依賴兩個代理在同一秒都醒著。
它能在不同 CLI 之間工作嗎 ?
能，而且這正是重點。這些工具由 AgentsRoom MCP 伺服器提供，而這台伺服器已經註冊給 AgentsRoom 駕駛的每一個代理：Claude Code、Codex、GitHub Copilot CLI、OpenCode、Antigravity CLI、Aider、Grok Build、Mistral Vibe、Kimi Code、Amp、oh-my-pi、Freebuff 和 Devin。一條從 Claude Code 代理發往 Codex 代理的訊息就是一條普通訊息，不是什麼整合。
如果收件方沒在執行會怎樣 ?
訊息會被存下來等著。絕不會為了送信而啟動一個主控台，因為在一個你並沒有在看的專案裡開啟 CLI，是該由你來做的決定。應用會顯示有什麼在等，投遞會在那個成員下一次處於適合閱讀的狀態時發生。
一條訊息會打斷正在工作的代理嗎 ?
不會。收件方在思考時投遞會先留著，收件方在等你的回答時也會先留著，因為往那個提示裡寫字等於替你回答。最終落地的是一條短通知，不是一堵文字牆，而且由代理自己決定什麼時候開啟收件箱。
一個代理能用另一個代理的名字發訊息嗎 ?
不能。發件方不是呼叫的引數。伺服器根據發起請求的 CLI 的身份給它蓋章，和其他 AgentsRoom 工具的做法一樣，所以一個代理沒有辦法冒名簽署。
這和 Agent Teams 有什麼不同 ?
Agent Teams 是一條流水線：為一次執行建立的節點，按圖裡的角色定址，執行結束就銷燬。代理之間的訊息傳遞是一份名冊：專案里長期儲存的代理，按名字定址，只要專案還在就一直有效。Teams 是你拿來重放的，訊息是你留下來的。Teams 什麼都沒有被拿走，而且常駐成員可以發起一次團隊執行。
訊息會變成待辦工單嗎 ?
不會，這是刻意的。待辦仍然是正式工作唯一的落腳點，兩個代理之間的對話不會悄悄變成一個任務。一條訊息可以帶上工單引用，讓兩個代理知道在說哪件事，但它永遠不會替代工單。
會有東西被自動寫進專案記憶嗎 ?
不會。沒有任何東西會自己從一條話題串升級進共享的專案記憶。持久的知識是特意寫下的，由一個判斷它確實持久的代理來寫，正是這一點讓這份記憶值得讀。
代理可以先等到回覆再繼續嗎 ?
沒有阻塞等待的工具，這是一個選擇。把一次工具呼叫凍住直到回答到來，依賴於應用無法控制、而且每家提供商設得都不一樣的超時。受支援的做法是發出去、結束這一輪，等回答到來時被通知喚醒。
訊息存在哪裡 ?
在專案資料夾裡，位於被排除在 git 之外的 AgentsRoom 工作目錄中。信封只寫一次，永不改寫，之後發生的一切都作為獨立事件追加進去，所以一條訊息的狀態永遠是從事實重建出來的，而不是來自某人覆蓋過的一個值。
換模型或換提供商之後身份還在嗎 ?
在。成員是那個已儲存的代理，不是那次會話。換掉它的模型、把它從一個提供商挪到另一個提供商、關掉再開啟 CLI：地址不變，收件箱完好。
我需要配置什麼嗎 ?
不需要。專案裡已儲存的代理本身就是名冊，AgentsRoom MCP 伺服器也已經註冊給了每個代理。這些工具會出現在代理的工具列表裡，就像待辦和終端命令的工具那樣。
搭配使用
Agent Teams
多代理工作的另一半：一塊視覺化畫布，把 Dev、QA、PM 和 Security 連成一條帶關卡和反饋迴圈、可以重放的流水線。
Agent Delegation
把一次性任務委派給一個跑在更便宜模型上的臨時 QA 代理。訊息發生在常駐成員之間，委派則派生一個報告結論後就消失的子代理。
AgentsRoom MCP
承載這六個工具的伺服器，旁邊還有待辦、dev 命令、prompt 庫、你的 SSH 連線和你的資料庫。
Backlog Task Board
正式工作住的地方。一條訊息可以指向一張工單，名冊也會顯示每個成員當前在做哪張工單。
Project Memory
代理特意寫下的共享知識庫。對話仍舊是對話，值得留下的決定會被記下來。
Customize Agents
已儲存的代理就是名冊的成員。把專案需要的角色搭出來，它們就成了代理互相寫信的地址。
延伸閱讀
2026 年執行多個編碼代理的最佳工具
Conductor、Crystal、Claude Squad、Vibe Kanban、AgentsRoom：誠實對比 2026 年並行執行多個編碼代理的最佳工具。
如何在開發團隊中擴展 AI 編碼代理
一個開發者與編碼代理的故事是生產力的故事。五個開發者與二十個代理則是協調問題。當團隊擴展時，首先會出現什麼問題，以及保持的設定：承諾的上下文檔案、清晰的檔案所有權、按爆炸半徑進行審查，以及你可以實際看到的成本。
如何與 AI 程式設計代理溝通：Claude、Codex、Antigravity、Grok Build
程式碼不再是瓶頸，溝通才是。本文介紹如何與 AI 代理 Claude、Codex、Antigravity 和 Grok Build 協作，讓你更快、更精準地交付，同時減少 token 消耗。
給你的代理一個收件箱
下載 AgentsRoom，開啟一個專案，讓你早已儲存好的代理開始跨你執行的每一個 CLI 互相寫信。
配套應用：隨時隨地監控你的 Agent
使用 Claude、Codex、Antigravity CLI 或其他 AI 提供商。
把 Bug 和需求直接傳送到您的公開待辦清單。
AgentsRoom 實際執行一瞥。