OpenRig

守护进程（daemon）在 OpenRig 架构中作为基础设施层持久化聊天室记录、维护 inbox/outbox 状态、记录席位事件流并为 dashboard 和 views 提供实时数据

rig ask 并不调用另一个 AI，它只是在已保存的 transcript 文本上运行纯文本搜索，但提供唤醒已保存会话直接提问的选项，后者会运行真实 Agent 并消耗 token

OpenRig 的 transcript 像行车记录仪一样滚动保存每块屏幕的副本，但只保留近期历史会丢弃最早部分，并非完整录像

OpenRig 的通信哲学可精炼为：用 send 去问，用 queue 去记录责任，用 capture 去看，用 transcript 去搜索

OpenRig 中 Agent 使用的 RIG 命令与人类操作者完全相同，都直接在各自的终端里运行

OpenRig 选择通信方式的关键取决于两个问题：谁需要听到这条消息，以及它是否需要留下持久记录

RigSend 是点对点通信方式，将消息直接输入到某个 Agent 的终端中，提供等待目标空闲和发送后检查屏幕确认两种模式

在 OpenRig 中 Delivered 只代表消息已输入，并不代表已读

queue（队列）是 OpenRig 从第 6 集引入的团队官方备忘录板，作为责任锚点，每条事项都需要某个席位明确认领或拒绝

RigBroadcast 用于一次性通知多个 Agent，若忘记指定具体 rig 会扩散到每个 rig 上的所有会话包括 kernel，单独使用 --pod 会匹配每个 rig 上的 dev pod

每个 rig 都有一个由守护进程持久保存的聊天室（Chat Room），服务于感知而不能替代队列

坏主意会像思维病毒一样在智能体间传播，作者借鉴流行病学做'接触追踪'和给智能体'接种模因疫苗'来阻止传播

OpenRig的核心目标是让Claude Code、Codex等现有智能体框架能够协同工作，是一个'框架的框架'

作者运行着六个OpenRig实例，三个跑在家里的Mac Mini上，另外三个部署在OVH云的VPS上，通过Tailscale网络互相通信

一个智能体可以用tmux的send-keys命令直接在另一个智能体的终端里注入按键输入，从而使协作速度提升约50倍

OpenRig最关键的抽象是'席位'（seat），席位定义角色、技能、模型设置，提供稳定地址（如builder@workshop），并实现知识继承

OpenRig把工作组织成项目-任务-切片的分层结构，一个任务通常对应一个完整发布版本，波形图显示哪些切片可并行或需顺序执行

官僚主义是智能体群体的典型故障模式：不断添加检查以防止错误，最终'完成流程'本身变成所有人忙碌的目标，规则变得比其服务的事务更重要

范围蔓延是智能体群体的故障模式：每个局部决策看似合理，但累积结果是没人想要的，智能体越多发生越快

OpenRig有一个叫'重聚焦'（refocus）的功能，追踪每个层级的意图链，在压缩后或按间隔向智能体发送该意图链以检查是否与大局一致