OpenRig 中 AI Agent 的全部通信方式详解

在多 Agent 协作系统 OpenRig 的第 21 集中，内容围绕一个核心问题展开：当团队扩展到更多 pod 和更多席位（seat）时，AI Agent 之间该如何有效地沟通？随着席位增多，对话量激增，选择正确的通信方式变得至关重要。

OpenRig 把 Agent 之间的沟通类比为真实办公室里的场景——电话、群聊、正式备忘录，以及记录走廊的监控摄像头。每种方式各有用途，而选择的关键只取决于两个问题：谁需要听到这条消息？它是否需要留下持久记录？

点对点：RigSend 与它的陷阱

RigSend 相当于「打电话」，它把消息直接输入到某个 Agent 的终端中。它提供两种模式：一种会等待目标 Agent 空闲，另一种则在发送后检查屏幕以确认消息是否送达。

当界面显示 Rendered, Unconfirmed（已渲染，未确认） 时，意味着消息很可能已经到达，但在重发前应先查看屏幕状态。从纯 shell 环境发送时，系统还会警告「没有发送者」，因此 Maya 需要在消息里签上自己的名字。

这里有一个关键认知：Delivered 只代表「已输入」，并不代表「已读」。 消息本质上是一次对话，可能被错过，也不会作为记录长期留存。真正需要有人负责的工作，不应该靠 send，而应该进入队列（queue）——也就是从第 6 集就引入的团队官方「备忘录板」。send 用来询问、提醒或指引，而 queue 用来承载任何需要有人正式认领的事项。

队列（queue）作为 OpenRig 的「责任锚点」，与 send 的区别值得进一步说明。队列本质上是一个持久化的任务清单，每一条进入队列的事项都需要某个席位明确「认领」或「拒绝」，系统因此能追踪到底谁对某项工作负责、它的处理状态如何。这种设计借鉴了工单系统（ticketing system）的思路：口头或即时消息传达的内容容易丢失或被遗忘，而进入正式流程的任务则有完整的生命周期记录。在多 Agent 系统中，由于没有人类的社会压力来保证信息被认真对待，这种显式的责任归属机制尤为重要——一条 send 消息被忽略不会有任何系统级后果，但一条未处理的队列项则会持续可见。

群发：RigBroadcast 的使用与风险

要一次性通知多个 Agent，可以使用 RigBroadcast。在示例中，它被发送给某个 rig 的 dev pod，该 pod 的两个席位都会收到。

但 Broadcast 隐藏着明显的陷阱。如果忘记指定具体的 rig，广播可能会扩散到每一个 rig 上的所有会话，连 kernel 都包含在内。类似地，单独使用 --pod 也很危险，因为它会匹配每个 rig 上的 dev pod。正确做法是同时指定 rig 名称，或者用 rigsend --2 这样的方式明确列出目标席位。精确寻址在多 rig 环境中是避免「消息洪水」的必要习惯。

群聊与感知层：Chat Room

每个 rig 都有一个聊天室，这是由守护进程（daemon）持久保存的群聊。席位可以在这里发布全团队都应看到的笔记。

在示例里，Maya 从她的 server 席位发帖，笔记会带上该席位的名称标签到达。团队成员可以用 chat room watch 实时跟进，也可以稍后查看历史记录。

不过需要强调的是，聊天室服务于「感知（awareness）」，它仍然不能替代队列。 感知让团队了解正在发生什么，但不等于把责任落实到具体的人。这体现了 OpenRig 对「沟通」和「责任归属」两个概念的刻意区分。

观察而非询问：Capture、Transcript 与 Ask

有时候你想要的是「看」，而不是「问」。Rig capture 能直接展示某个 Agent 当前屏幕上的内容。示例中负责人回复了 ACK（确认）。

除此之外，OpenRig 会像行车记录仪一样滚动保存每块屏幕的副本，这就是 transcript（记录）。通过 rig transcript 可以对其进行搜索。需要注意的是，它只保留近期的历史，会丢弃最早的部分，因此并非完整录像。

Rig ask 则更进一步：它接受一个关于某 rig 的自然语言问题，然后从已保存的 transcript 中收集证据。Maya 询问负责人是否已回复，系统返回了匹配的记录行。

这里有个重要澄清：rig ask 并不调用另一个 AI，它只是在已有文本上运行纯文本搜索。 它还提供一个选项，可以唤醒已保存的会话并直接向其提问——但那会运行一个真实的 Agent，因此会消耗 token。这种「默认廉价、按需昂贵」的设计思路，对控制多 Agent 系统的成本很有参考意义。

MCP（Model Context Protocol）是 Anthropic 提出的一套开放协议，旨在为 AI 模型提供标准化的「工具调用」接口。它的作用类似于 USB 接口的标准化：无论底层工具是数据库查询、文件操作还是外部 API，模型都通过统一的协议格式来声明可用工具、发起调用并接收结果。OpenRig 通过 rig mcp serv 将自身的 18 个操作封装为 MCP 工具，这意味着任何兼容 MCP 的 AI 客户端都可以直接接入 OpenRig 的通信与任务体系，而无需为每个工具单独编写适配代码。这种标准化对多 Agent 系统尤其有价值：它让不同来源的 Agent 能以相同的方式感知和操作共享的工作环境。

无主事项与全局视图

有些想法值得记录下来，但暂时没有归属对象，比如一个「留待以后」的点子。这类内容应放进 stream（流），一个按顺序保存每条笔记的「建议箱」。此外，每个席位都有 inbox（用于接受或拒绝进入队列的请求）和 outbox（记录自己发出的内容），这两者主要由 Agent 自行使用。

当你需要宏观全貌时，可以使用 views（视图）——它们是关于团队状态的现成问题：哪些席位最近很忙？什么被搁置了？什么正在等待被认领？在这一切背后，守护进程记录着每一个事件，因此像 dashboard 这样的界面能够实时更新。

守护进程（daemon）在 OpenRig 架构中扮演着「基础设施层」的角色。它是一个在后台持续运行的进程，负责持久化聊天室记录、维护 inbox/outbox 状态、记录每个席位的事件流，以及为 dashboard 和 views 提供实时数据。与前台应用不同，daemon 不依赖用户交互保持运行，因此即使某个席位的 Agent 暂时离线或被唤醒，历史记录和队列状态依然完整保留。这种「状态由基础设施持有而非由 Agent 持有」的设计，是多 Agent 系统可靠性的关键——单个 Agent 的上下文窗口是有限且易失的，而 daemon 提供了独立于任何单一 Agent 生命周期的持久存储层。

统一命令体系与 MCP 工具带

Agent 使用的 RIG 命令与人类操作者完全相同，都直接在各自的终端里运行。OpenRig 还提供一个 MCP 服务器，通过 rig mcp serv 启动，它为 AI 提供一套标准化的 18 个工具的「工具带」。

当一个 Agent 刚唤醒或失去上下文时，它会运行 rig who am i 来确认自己的席位、pod 和 rig。整套通信哲学可以被精炼成一句话：用 send 去问，用 queue 去记录责任，用 capture 去看，用 transcript 去搜索。 下一集将把 OpenRig 连接到更多机器与更多服务。