Claude Code Dispatch 是一個中繼層，讓你透過 Telegram 等通訊軟體控制電腦上的 Claude Code 實例。你在聊天視窗輸入的內容，都會在你的電腦上直接執行，並存取你的檔案、已連線的應用程式和外掛。agent 房間則是一個共享空間，讓多個人將工作發送給該 agent，每個人都擁有各自的權限；遇到危險操作時會暫停並等待主人審批，且一切都有完整記錄。
兩者都能將 agent 保留在本機。真正的差別在於聊天視窗被允許做什麼。
Dispatch 的強項
對於已經習慣在 Telegram 上的個人來說，這是從手機連到本機工作階段最短的路徑。不需要安裝新軟體；聊天視窗就是介面；電腦負責執行工作。在火車上發出「重新跑測試並向我回報」，這種體驗幾乎無可挑剔。
它的局限在哪裡
Dispatch 會直接把訊息當作指令。一旦有你以外的人可以發布訊息，就會產生三個後果：
- 以群組成員資格作為權限模型。 任何可以在聊天室打字的人，都可以執行該 agent 能執行的任何指令。
- 沒有任何操作會暫停。「清理舊的分支」會直接變成
git branch -D，文字與指令之間沒有任何人工確認。 - 沒有針對個人的記錄。 群組聊天會顯示是誰輸入的，但 agent 端完全不知道是誰提出的要求、誰批准的，或是產生了多少成本。
當聊天室只有一個成員時，這些都不是問題。但只要加入第二個人，每一點都很關鍵。
房間額外提供了什麼
- 針對個人的權限。 一個人是唯讀權限，另一個人可以編輯，第三個人則擁有常態授權。
- 一律暫停的操作。 推送到共享分支、刪除、花費、存取憑證等操作都會等待主人確認，主人的手機上會收到審批卡片。
- 每個任務都有請求 ID 與時間線，房間內的所有人都看得到。
- 收件匣，即使在筆電闔上時送出的訊息，也會在打開筆電時繼續執行。
- 通訊平台入口。 目前已支援 Slack：每個 agent 都有專屬的 bot，可私訊或 mention 它，審批通知會直接發到主人的私訊。接著會支援 Feishu/Lark 和 DingTalk，並綁定相同的房間與規則；隨後則是 Telegram。請參閱 Slack 連接器。
兩者搭配使用
自己使用 Dispatch，其他人使用房間。兩者並不衝突：它們都是使用從電腦發起的對外連線，而且提供房間服務的 daemon 是作為背景服務執行，與 Dispatch 連接到哪個終端機無關。
常見問題
我可以為 Dispatch 加上審批機制嗎？ 中繼層本身無法做到。Claude Code 本身的權限模式在工作階段內依然有效；房間則是在其之上額外增加依個人區分與一律暫停的控制層。
muti 會支援 Telegram 嗎？ 我們優先推出了 Slack，接著是 Feishu/Lark 和 DingTalk，因為這是我們早期使用者的團隊所在之處。隨後會支援 Telegram。所有的連接器都共用相同的房間模型。
房間會比中繼層慢嗎？ 路徑長度完全相同：訊息 → 服務 → 對外輪詢 → 電腦。唯一的差別在於權限檢查，而那只是查詢一次資料庫而已。
你自己用，選中繼。給團隊用，選房間。為你的 agent 建立一個房間
發布於