Claude Code Dispatch 是一个中继层，让你能从 Telegram 等即时通讯应用控制电脑上的 Claude Code 实例。你在聊天中输入的内容，会在你的机器上运行，访问你的文件、已连接的应用和插件。agent 房间则是一个共享空间，多个人可以在这里向该 agent 发送任务，每个人拥有各自的权限，危险操作会暂停等待主人审批，并记录下所有操作。
两者都让 agent 保持在本地。不同之处在于聊天中被允许执行的操作。
Dispatch 的优势
对于习惯使用 Telegram 的单人用户来说，这是从手机直达本地会话的最短路径。无需安装新应用；聊天界面即是操作界面；机器负责干活。在火车上随手发一句“重新跑一下测试并把结果告诉我”，这种体验无可匹敌。
它的局限所在
Dispatch 将收到的消息直接视为指令。一旦除你之外的任何人可以在群里发言，就会带来三个后果。
- 群成员身份即权限模型。 只要能在聊天中发言，就能运行该 agent 能够运行的一切操作。
- 没有任何操作会暂停。 “清理旧分支”会直接变成
git branch -D，文字和命令之间没有任何人工确认。 - 没有按人区分的记录。 群聊能看到谁发了消息，但 agent 端完全不知道是谁提出的请求、谁批准的，也不清楚消耗了多少成本。
只要群里只有一个人，这些都无所谓。但一旦有了第二个人，每一项都会变成严重问题。
房间带来了什么
- 按人设定的权限。 可以给某人只读权限，给另一人编辑权限，给第三个人长期授权。
- 始终暂停的操作。 推送到共享分支、删除、产生花费、调用凭证等操作都会暂停等待主人，审批卡片会直接推送到主人的手机上。
- 每个任务都有请求 id 和时间线，房间里的所有人均可见。
- 收件箱，笔记本电脑合盖时发送的消息，会在开盖后自动执行。
- 聊天平台接入通道。 目前支持 Slack：每个 agent 拥有独立的机器人，可以直接私信或 @ 它，审批会推送到主人的私信中。随后是 Feishu/Lark 和 DingTalk，绑定至相同的房间和规则；其后是 Telegram。详见 Slack 连接器。
两者结合使用
自己用 Dispatch，团队用房间。两者并不冲突：它们都使用从机器发起的出站连接，无论 Dispatch 挂载在哪个终端上，为房间提供服务的 daemon 都作为后台服务平稳运行。
常见问题
我可以在 Dispatch 中添加审批吗？ 中继本身无法实现。Claude Code 自身的权限模式在会话内仍然有效；而房间则在此之上增加了按人和始终暂停控制层。
muti 会支持 Telegram 吗？ 我们首先支持了 Slack，接着是 Feishu/Lark 和 DingTalk，因为我们的早期用户团队都在使用这些工具。随后会支持 Telegram。所有连接器都共享同一套房间模型。
房间会比中继慢吗？ 传输路径长度相同：消息 → 服务 → 出站轮询 → 机器。区别仅在于权限检查，这只是一次数据库查询。
你自己用，选转发中继。团队协作，建一个房间。给你的 agent 开一个房间。
发布于