1. 从"一次性对话"到"持久化协作"：OpenRig 要解决的真问题

大多数人第一次接触 AI Agent，体验路径都差不多：打开一个对话框，输入任务，等它跑完，拿到结果，关掉窗口。下一次再想让它干点活，上下文没了，状态没了，之前踩过的坑还得重新踩一遍。这种模式我称之为"一次性 Agent"——它像个临时工，干完一单就消失，你没法指望它记住昨天做过什么，更没法让它和另一个 Agent 接力完成一件跨天、跨步骤的复杂任务。

OpenRig 这个项目标题里最关键的词不是"AI Agent"，而是**"持久化协作系统"和"多智能体编排"**。它想做的事情，是把那些原本各自为战、跑完即散的离散 Agent，编织成一个能长期存活、彼此协作、状态可追溯的系统。这个定位和市面上大量"套壳对话"类工具完全不在一个层面——前者是玩具，后者是基础设施。

我先把结论摆出来：多智能体编排的难点从来不在"让多个 Agent 同时跑"，而在于"让它们跑完之后还能接着跑，并且互相知道对方干了什么"。这句话是理解 OpenRig 全部设计取舍的钥匙。你去看热词里那些高频词——tmux、MCP、并发、中台——它们其实都在回答同一个问题：怎么让 Agent 从"进程"变成"常驻服务"，从"单机脚本"变成"协作网络"。

这篇文章适合三类人：一是已经用 LangChain、LangGraph 之类框架搭过单 Agent、现在想往多 Agent 方向走的开发者；二是正在做 AI Agent 中台、需要给团队提供统一编排能力的技术负责人；三是单纯好奇"多智能体到底怎么落地"、想看清底层机制的学习者。我会从架构动机讲到具体实现，把 tmux 会话管理、MCP 协议接入、并发控制、状态持久化这些核心环节拆开揉碎，中间穿插我自己踩过的坑和实测数据。

先说一个反直觉的判断：持久化不是"把状态存数据库"这么简单，它的本质是"给每个 Agent 一个稳定的身份和可寻址的会话"。没有稳定身份，Agent 之间就没法互相调用；没有可寻址会话，人类就没法在任意时刻介入、检查、纠偏。OpenRig 选择用 tmux 作为会话底座，正是因为它天然提供了"命名会话 + 可附着 + 可分离"这三件套，这是很多重量级框架反而忽略的工程细节。

2. 为什么是 tmux：会话持久化的底层选型逻辑

2.1 进程会死，会话不会：tmux 提供的核心抽象

要理解 OpenRig 为什么把 tmux 放在架构核心位置，得先想清楚一个朴素的问题：一个 Agent 进程跑起来之后，怎么保证它不因为终端关闭、网络抖动、SSH 断连而挂掉？

常规做法是把它做成 systemd 服务或者 Docker 容器，但这两者都有个共同缺陷——它们是"黑盒进程"，你很难在运行中途"钻进去"看它当前在干什么、手动敲一条命令干预它。而 Agent 恰恰是最需要中途干预的东西：它可能卡在一个循环里、可能误解了任务、可能需要人类补一句关键信息。这时候你需要的不是日志，而是一个能直接附着的活终端。

tmux 解决的正是这个问题。它把"进程"包装成"会话"，会话独立于你的终端连接存在。你关掉笔记本，会话还在服务器上跑；你第二天重新连上，tmux attach -t agent-worker-01一敲，Agent 的完整终端现场原封不动地回来了，包括它正在等待的输入提示符。

提示：tmux 的会话名就是 Agent 的"身份证"。OpenRig 里每个 Agent 实例都绑定一个唯一会话名，命名规范建议是{角色}-{任务ID}-{序号}，比如researcher-task42-01。这个名字后面会被 MCP 工具、调度器、监控面板反复引用，命名混乱会直接导致编排逻辑失控。

2.2 会话命名与寻址：多 Agent 协作的"通讯录"

单 Agent 用 tmux 只是图个方便，多 Agent 用 tmux 就变成了架构刚需。原因很简单：Agent A 要调用 Agent B，前提是 A 能"找到"B。在 OpenRig 的设计里，这个"找到"就是通过会话名完成的。

我实测过一套最小可用的寻址方案，核心就三条命令：

# 列出所有活跃 Agent 会话 tmux ls | grep -E '^(researcher|writer|reviewer)-' # 向指定 Agent 会话发送指令（不附着） tmux send-keys -t researcher-task42-01 'analyze the dataset' Enter # 抓取指定 Agent 会话的最近输出 tmux capture-pane -t researcher-task42-01 -p -S -50

这三条命令组合起来，就构成了一个极简的"Agent 消息总线"。send-keys是发消息，capture-pane是收消息，tmux ls是服务发现。你不需要引入 Redis、RabbitMQ 这些重型中间件，就能让多个 Agent 互相通信。当然，生产环境里你会在这之上再包一层，但底层逻辑就是这么朴素。

这里有个容易踩的坑：send-keys默认是"模拟键盘输入"，如果目标 Agent 当前不在等待输入状态（比如它正在跑一个长任务），你发过去的字符会被当成任务输出的一部分，直接污染它的上下文。正确做法是先检测会话状态，确认它处于空闲提示符再发送。我的经验是让每个 Agent 在空闲时打印一个约定好的标记（比如[IDLE]），调度器用capture-pane抓取最后一行判断，只有看到[IDLE]才发下一条指令。

2.3 会话生命周期管理：别让僵尸 Agent 拖垮系统

持久化带来一个副作用：Agent 会"活着"，但可能活成了僵尸。一个任务早就完成了，会话还挂在那里占资源；或者一个 Agent 卡死了，会话还在但进程已经无响应。OpenRig 必须有会话回收机制。

我建议的生命周期策略是这样的：

这张表是我在实际运维中总结出来的，比任何框架自带的健康检查都实用。关键点是**"空闲"和"卡死"必须区分开**——空闲是正常的，卡死是异常的，如果一刀切地把长时间无输出的会话都杀掉，你会误杀那些正在等待人类输入的正常 Agent。

3. MCP 接入：让 Agent 的手伸向真实世界

3.1 MCP 到底解决什么问题：从"能说"到"能做"

热词里 MCP 出现的频率极高，很多人问"MCP 是软件协议还是硬件协议"。这里先给个明确答案：MCP（Model Context Protocol）是一套软件层的通信协议，它规范的是"AI 模型/Agent 如何调用外部工具和数据源"。你可以把它类比成 USB-C——USB-C 不关心你插的是硬盘还是显示器，它只规定接口形状和通信规则；MCP 也不关心你接的是数据库还是浏览器，它只规定 Agent 怎么"发现工具、调用工具、拿回结果"。

没有 MCP 之前，每接一个工具你都得写一套适配代码：接数据库写一套、接浏览器写一套、接文件系统再写一套。MCP 的价值在于把"工具接入"标准化，工具提供方实现一个 MCP Server，Agent 侧实现一个 MCP Client，双方按协议对话，从此接入新工具不用改 Agent 核心逻辑。

在 OpenRig 的语境下，MCP 是 Agent 与外部世界交互的"标准接口层"。一个 Agent 会话里跑着推理逻辑，它需要查数据库、需要操作浏览器、需要读写文件，这些能力全部通过 MCP 工具暴露进来。

3.2 在 tmux 会话中挂载 MCP 工具的实操路径

把 MCP 和 tmux 结合起来，有个很自然的思路：每个 Agent 会话启动时，同时拉起它需要的 MCP Server 进程，通过本地 stdio 或本地端口通信。这样 Agent 的工具集就是"随会话走"的，会话销毁，工具进程也跟着回收，不会留下孤儿进程。

具体操作上，我习惯在会话启动脚本里做三件事：

# 1. 创建命名会话，启动 Agent 主进程 tmux new-session -d -s researcher-task42-01 -x 220 -y 50 # 2. 在会话内启动 MCP Server（以文件系统工具为例） tmux send-keys -t researcher-task42-01 'npx -y @modelcontextprotocol/server-filesystem /data/workspace' Enter # 3. 等待 MCP Server 就绪后，启动 Agent 主逻辑并注入工具配置 sleep 3 tmux send-keys -t researcher-task42-01 'python agent_main.py --mcp-config ./mcp.json' Enter

这里-x 220 -y 50指定了会话的虚拟终端尺寸，别小看这个参数——很多 Agent 的输出解析依赖终端宽度，宽度太小会导致长行被截断，capture-pane抓回来的内容就是残缺的。我踩过一次坑，Agent 返回的 JSON 因为终端只有 80 列被折成好几行，解析器直接报错，排查了半天才发现是 tmux 尺寸问题。

mcp.json里配置的就是这个 Agent 能用的工具清单，大致长这样：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data/workspace"] }, "database": { "command": "python", "args": ["-m", "mcp_server_sqlite", "--db", "/data/app.db"] } } }

3.3 工具权限隔离：别让一个 Agent 拿到所有钥匙

多 Agent 系统里有个安全原则必须强调：每个 Agent 只应该拿到完成它任务所需的最小工具集。研究型 Agent 需要读文件、查数据库，但不需要写文件、不需要执行 shell；执行型 Agent 需要写文件和执行命令，但不需要访问敏感数据库。

我在 OpenRig 的实践里，把工具权限按角色做了硬隔离：

这张表的价值在于，它把"权限"从"代码里的 if 判断"提升到了"架构层面的物理隔离"。审核者 Agent 就算被提示词注入攻击，它也物理上拿不到写权限，破坏半径被锁死了。

4. 并发编排：多 Agent 同时跑起来之后的一地鸡毛

4.1 并发不是"多开几个会话"那么简单

"AI Agent 怎么扛并发"是热词里被问得最多的问题之一。很多人以为并发就是多开几个 tmux 会话，让它们各跑各的。真跑起来你会发现，问题全在"共享资源"上：多个 Agent 同时写同一个文件、同时调用同一个有速率限制的 API、同时抢同一个数据库连接。

OpenRig 作为编排系统，必须处理这些竞争。我的经验是把并发控制分成三层：

• 会话层：tmux 天然隔离，每个 Agent 有独立终端，这层不用操心。
• 资源层：文件、数据库、API 配额这些共享资源，必须加锁或排队。
• 调度层：谁先跑、谁等谁、谁依赖谁，这是编排逻辑的核心。

资源层的锁，我推荐用最简单的文件锁起步，别一上来就上分布式锁。flock命令在单机多 Agent 场景下足够用：

# Agent 写共享文件前先抢锁，抢不到就等待 ( flock -w 30 200 || { echo "LOCK_TIMEOUT"; exit 1; } echo "writing to shared resource..." # 实际写操作 ) 200>/var/lock/openrig-shared.lock

-w 30表示最多等 30 秒，超时就放弃并报错。这个超时值很关键——不设超时的锁在多 Agent 系统里就是死锁制造机。我见过一个 Agent 拿到锁之后自己卡死了，其他所有 Agent 全部饿死，整个系统瘫痪。

4.2 依赖编排：DAG 还是状态机

多 Agent 协作的任务，本质上是一张有向无环图（DAG）：研究员产出数据，写作者基于数据写稿，审核者审稿，审核不通过打回重写。OpenRig 需要把这张图变成可执行的调度逻辑。

我对比过两种实现方式：

方式一：DAG 调度器。把任务拆成节点，节点间定义依赖，调度器按拓扑序执行。优点是结构清晰，适合流程固定的场景。缺点是遇到"审核不通过要回退"这种带环的逻辑就不好表达——DAG 本身不允许环。

方式二：状态机。每个 Agent 是一个状态，状态间定义转移条件。优点是天然支持回退和循环，适合有反复迭代的场景。缺点是状态多了之后转移图会爆炸。

我的实际选择是混合：主流程用 DAG 保证整体有序，局部迭代用状态机。比如"写稿-审核"这个小循环内部用状态机（草稿→审核中→通过/打回），而"研究→写作→发布"这个大流程用 DAG。这样既保证了宏观可控，又保留了微观灵活。

4.3 实测：10 个 Agent 并发时的资源画像

我做过一组实测，在一台 8 核 16G 的机器上跑 10 个 Agent 会话，每个会话挂 2 个 MCP Server。资源占用大致如下：

结论很明确：内存和文件句柄是主要瓶颈，不是 CPU。每个 Agent 加上它的 MCP Server，内存开销接近 1G，10 个就是 10G。所以规划容量时，别按 CPU 核数算，按内存算——每 G 内存大约能养 1 个 Agent 会话，这是我在多个项目里验证过的经验值。

文件句柄的问题更隐蔽。每个 MCP Server 会开若干连接，10 个 Agent 乘以每个 2 个 Server 再乘以每个 Server 的连接数，很容易撞上系统的ulimit -n默认值 1024。上线前务必调大文件句柄限制，否则你会看到 Agent 莫名其妙地连不上工具，报的错还特别含糊。

5. 状态持久化与故障恢复：Agent 挂了之后怎么办

5.1 会话状态、任务状态、上下文状态要分开存

"持久化"这个词很容易被笼统理解成"存数据库"。但在 OpenRig 里，我把它拆成三种状态，分别用不同方式存：

• 会话状态：Agent 进程是否活着、终端现场是什么。这个由 tmux 自己维护，不用额外存。
• 任务状态：任务进行到哪一步、依赖是否满足、产出物在哪。这个存数据库（SQLite 起步就够）。
• 上下文状态：Agent 的对话历史、推理链、工具调用记录。这个存文件，按会话名归档。

分开存的好处是恢复时可以分级处理。会话挂了但任务状态还在，重启会话后从任务状态恢复即可；上下文丢了但任务状态在，可以让 Agent 重新推理，损失可控。如果全揉在一起，一处损坏全盘皆输。

5.2 断点续跑：让 Agent 从中断处接着干

故障恢复的核心是"断点续跑"。我的实现思路是在每个关键步骤后写检查点：

def execute_step(agent_id, step_name, payload): checkpoint = load_checkpoint(agent_id) if checkpoint and checkpoint["step"] == step_name: # 该步骤已完成，直接返回上次结果 return checkpoint["result"] result = do_actual_work(payload) save_checkpoint(agent_id, { "step": step_name, "result": result, "timestamp": time.time() }) return result

这段代码看着简单，但它是整个系统可靠性的基石。没有检查点，任何一次故障都意味着从头再来；有了检查点，故障只是"暂停"，不是"重来"。我在一个跑了 6 小时的长任务上验证过，中途人为 kill 掉 Agent，重启后从最近的检查点恢复，只损失了不到 2 分钟的工作量。

注意：检查点要写"幂等"的步骤。如果一个步骤有副作用（比如发了邮件、扣了款），恢复时必须先判断这个副作用是否已经发生，否则会重复执行。我的做法是给每个有副作用的步骤分配唯一 ID，执行前先查这个 ID 是否已记录。

5.3 会话归档：别让历史会话无限堆积

持久化的另一个坑是"只增不减"。跑上一个月，你会攒下几千个已完成的会话，tmux ls输出长到没法看，磁盘也被日志塞满。

我的归档策略是：任务完成后，先把会话的完整输出capture-pane下来存成文件，然后 kill 会话。归档文件按日期/任务ID/会话名.log组织，需要复盘时直接读文件，不需要保留活会话。

# 归档并销毁已完成会话 SESSION="researcher-task42-01" mkdir -p /archive/$(date +%Y%m%d)/task42 tmux capture-pane -t $SESSION -p -S - > /archive/$(date +%Y%m%d)/task42/$SESSION.log tmux kill-session -t $SESSION

这套流程跑顺之后，系统里永远只有"活跃"和"空闲"的会话，历史全部沉淀成文件，既省资源又便于检索。

6. 从单机到中台：OpenRig 的扩展边界与我的实践体会

6.1 什么时候该从 tmux 升级到真正的分布式

tmux 方案在单机上是优雅的，但它有个硬边界：所有 Agent 必须在同一台机器上。当你的 Agent 数量超过单机承载能力（按前面 1G 内存 1 个 Agent 算，16G 机器大约 10-12 个），就必须考虑分布式。

升级路径我建议分两步走，别一步到位：

第一步：多机 + SSH 隧道。每台机器上跑一批 tmux 会话，用 SSH 把tmux send-keys和capture-pane远程化。这个阶段你还是在用 tmux 的抽象，只是加了一层网络转发。改动小，见效快。

第二步：引入消息队列。当 Agent 数量到几十上百，SSH 轮询就不够用了，这时候把"发消息/收消息"换成 Redis Pub/Sub 或 NATS。tmux 退化成"本地执行器"，跨机通信走消息队列。这个阶段架构复杂度上来了，但扩展性也上来了。

我的判断标准是：Agent 数量在 20 个以内，tmux 单机方案完全够用，别过度设计；超过 50 个，再考虑消息队列。中间这段可以用多机 SSH 顶着。

6.2 中台化要考虑的三件事

如果 OpenRig 要往"AI Agent 中台"方向走，给团队提供统一编排能力，有三件事必须提前想清楚：

第一，Agent 的注册与发现。新 Agent 上线怎么被系统知道？我的做法是维护一张 Agent 注册表，每个 Agent 启动时向注册表报到，声明自己的角色、能力、所需工具。调度器只从注册表里找 Agent，不硬编码。

第二，任务的提交与追踪。用户提交一个任务，系统要能告诉他"现在跑到哪了、卡在哪了、预计还要多久"。这需要任务状态对用户可见，而不是黑盒。我习惯给每个任务生成一个追踪页面，实时展示各 Agent 的状态。

第三，配额与计费。中台意味着多用户共享资源，必须有配额机制防止一个用户的任务吃光所有 Agent 槽位。简单的做法是按用户分配最大并发会话数，复杂的做法是按 token 消耗计费。

6.3 我踩过的三个印象最深的坑

坑一：Agent 之间的"死锁等待"。Agent A 等 Agent B 的输出，Agent B 等 Agent A 的输出，两个都卡住。根因是依赖关系没做环检测。修复方案是在编排层加 DAG 环检测，提交任务时就拒绝有环的依赖图。

坑二：MCP Server 泄漏。Agent 会话被 kill 了，但它拉起的 MCP Server 进程没跟着死，成了孤儿进程，越积越多。修复方案是用进程组管理，kill 会话时连带 kill 整个进程组，或者用pkill -P按父进程清理。

坑三：终端输出解析的编码问题。Agent 输出里混了 ANSI 颜色码，capture-pane抓回来带着一堆\x1b[32m之类的转义序列，解析器直接崩。修复方案是启动 Agent 时设置TERM=dumb禁用颜色，或者在解析前先 strip 掉 ANSI 码。

这三个坑有个共同点：它们都不是"AI 问题"，而是"系统工程问题"。多智能体编排的难点，八成在工程细节上，两成在 AI 能力上。把工程做扎实，AI 的能力才能稳定发挥出来。

6.4 给不同阶段实践者的建议

如果你刚开始接触多智能体，我的建议是先用 tmux 手动管理两三个 Agent，把"会话持久化"和"消息传递"这两件事跑通，别急着上框架。手动跑一遍，你会对"Agent 是什么、会话是什么、状态在哪"有肌肉记忆般的理解，这比看十篇架构文章都管用。

如果你已经在用 LangGraph 之类的框架，我建议你把 tmux 会话层加进去。框架负责推理逻辑，tmux 负责进程持久化和人类可介入，两者不冲突，反而互补。框架让你写得快，tmux 让你跑得稳。

如果你在做中台，我建议你先把单机方案做到极致，再考虑分布式。我见过太多团队一上来就搞 K8s + 消息队列 + 微服务，结果连"Agent 挂了怎么恢复"都没解决。单机 tmux 方案虽然朴素，但它把最核心的问题——持久化、可寻址、可介入——解决得很干净。等这套跑顺了，再往上加分布式组件，每一步都有明确的收益，而不是为了架构而架构。

最后分享一个我一直在用的小技巧：给每个 Agent 会话配一个"心跳文件"，Agent 每隔 30 秒往文件里写一次时间戳。监控脚本读这个文件，超过 90 秒没更新就告警。这比任何复杂的健康检查都可靠，因为它检测的是"Agent 是否真的在干活"，而不是"进程是否还在"。进程活着但卡死的 Agent，只有心跳能发现。