你的智能体不再独自工作。
它们开始互相写信。
智能体之间的消息传递把项目里已保存的智能体变成一份常驻名册。任何一个都能在任意 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 实际运行一瞥。