OpenRig：基于tmux与MCP的多智能体持久化编排实战

1. 从一次性对话到常驻协作OpenRig 要解决的真问题如果你用过一段时间的 AI Agent大概率经历过这种落差单次对话里它聪明得惊人能查资料、写代码、调工具可一旦任务跨天、跨会话、跨进程它就失忆了。昨天让它跟进的那个爬虫任务今天再问它一脸茫然你让它和另一个 Agent 分工协作结果两边各说各话中间没有任何交接机制。这不是模型能力的问题而是编排层缺失的问题。OpenRig 这个项目核心就干一件事把原本离散的、一次性的 AI Agent编织成一个持久化的协作系统。所谓离散指的是每个 Agent 都是独立进程、独立上下文、独立生命周期所谓持久化指的是这些 Agent 的状态、任务、通信记录不会随着一次会话结束而蒸发所谓协作指的是多个 Agent 之间能像一个小团队那样分工、交接、互相唤醒。关键词里的多智能体编排、tmux、MCP基本勾勒出了它的技术骨架——用 tmux 做进程与终端的持久化载体用 MCP 做工具与能力的标准化接入用编排逻辑把这两者串成一个能长期运转的系统。这篇文章适合谁看如果你正在做 AI Agent 相关的项目尤其是遇到Agent 跑不长多 Agent 协作乱成一锅粥任务状态没法持久化这类问题那这篇内容会对你有直接帮助。如果你只是刚接触 Agent想了解一个真实的多智能体系统是怎么搭起来的也能从里面拿到可复用的思路。我不会只讲概念会把架构取舍、tmux 会话管理、MCP 接入、并发处理、踩坑经验都摊开讲尽量让你看完能自己动手复现一个最小可用版本。先说一个反直觉的结论多智能体系统最难的部分从来不是智能而是编排。模型再强如果没有一套可靠的进程管理、消息路由和状态持久化机制多个 Agent 凑在一起只会比单个更混乱。OpenRig 的价值恰恰在于它把工程重心放在了编排层而不是又去卷模型能力。2. 为什么是 tmux MCP 这套组合拳2.1 tmux 作为 Agent 的持久化肉身很多人第一次听到用 tmux 跑 Agent 会觉得奇怪——tmux 不是终端复用工具吗跟 AI 有什么关系这里要理解一个关键点Agent 需要一个不会随 SSH 断开、不会随父进程退出而死亡的运行载体。你不可能让一个需要跑几小时的 Agent 挂在自己的交互式终端里一旦网络抖动或者你关了窗口任务就没了。tmux 解决的正是这个问题。它把每个 Agent 跑在一个独立的 pane 或 window 里会话与终端解耦。你断开连接会话还在你重新 attach能看到 Agent 的实时输出。更妙的是tmux 的 pane 天然就是一个可寻址的进程容器——你可以通过tmux send-keys往指定 pane 注入输入通过tmux capture-pane抓取它的输出。这就给了编排层一个统一的读写接口。我实测下来这套机制比自己去写一套进程守护 日志重定向要省事得多。原因有三第一tmux 本身极其稳定系统级工具几乎不会崩第二pane 的输入输出是文本流天然适合 Agent 这种读 prompt、吐结果的交互模式第三调试直观你 attach 上去就能看到每个 Agent 在干嘛不用去翻日志文件。提示用 tmux 跑 Agent 时务必给每个 pane 起有意义的名字tmux rename-window否则 Agent 一多你自己都分不清哪个 pane 是哪个角色。2.2 MCP 作为能力的标准插座MCPModel Context Protocol在这套系统里的角色是工具与能力的标准化接入层。在没有 MCP 之前你给 Agent 加一个能力往往要写一堆胶水代码这个工具用 HTTP那个用命令行另一个用 SDK每个都要单独适配。MCP 把这些统一成一种协议Agent 只要按协议去发现工具、调用工具就能接入任意实现了 MCP 的服务。这带来的直接好处是编排层与能力层解耦。OpenRig 不需要关心某个 Agent 具体能干什么它只需要知道这个 Agent 挂载了哪些 MCP server。想给某个 Agent 加能力挂一个新的 MCP server 就行编排逻辑完全不用改。这种解耦在多智能体场景下尤其重要因为不同 Agent 往往需要不同的能力组合——研究员 Agent 需要搜索和抓取编码 Agent 需要文件系统和执行环境协调 Agent 需要消息路由。2.3 两者结合后的系统形态把 tmux 和 MCP 放一起看OpenRig 的系统形态就清晰了tmux 负责活着MCP 负责能干活编排层负责怎么协作。每个 Agent 是一个跑在 tmux pane 里的常驻进程通过 MCP 接入它需要的工具编排层通过 tmux 的读写接口与它交互同时维护一张全局的任务与状态表。组件职责关键机制tmuxAgent 进程持久化与 IO 通道pane 寻址、send-keys、capture-paneMCP工具能力标准化接入工具发现、协议调用、能力隔离编排层任务分发、状态维护、协作调度任务表、消息路由、唤醒机制状态存储跨会话持久化任务记录、Agent 上下文快照这张表基本就是 OpenRig 的骨架。接下来我会逐个拆开讲重点讲那些文档里不会写、只有真正跑起来才会遇到的细节。3. 编排层的核心设计任务表、消息路由与唤醒机制3.1 任务表让 Agent 知道我该干什么离散 Agent 最大的问题是无状态——它不知道之前发生了什么也不知道接下来该做什么。OpenRig 用一个持久化任务表来解决这个问题。每个任务是一条记录包含任务 ID、描述、负责的 Agent、当前状态待处理/进行中/阻塞/完成、依赖关系、以及产出物引用。这张表是整个系统的真相来源。Agent 启动时先查表看有没有分给自己的任务完成任务后更新表里的状态编排层定期扫描表发现阻塞或超时的任务就介入处理。这样一来即使某个 Agent 进程重启它也能从表里恢复自己的上下文不会失忆。我踩过的一个坑是任务状态更新必须幂等。早期我没注意这点Agent 因为网络重试把同一个任务标记了两次完成导致下游任务被重复触发。后来改成用任务 ID 状态版本号做乐观锁重复更新直接丢弃问题才解决。3.2 消息路由Agent 之间怎么说话多 Agent 协作通信是命脉。OpenRig 的消息路由设计有几个关键决策第一消息不直接点对点而是走一个中心化的路由层。原因很简单点对点通信在 Agent 数量增加后会变成一张蜘蛛网谁跟谁通信、消息格式是什么很快就会失控。中心化路由虽然引入了一个单点但换来的是可观测性和可管理性——所有消息都过一遍路由层谁发了什么、谁该收什么一目了然。第二消息带类型和优先级。不是所有消息都一样重要。任务分派是高优先级状态同步是普通优先级日志上报是低优先级。路由层按优先级排队避免低优先级消息把关键消息堵住。第三消息持久化。Agent 可能正在忙暂时处理不了新消息。这时候消息不能丢要落到存储里等 Agent 空闲了再投递。这就是持久化协作的题中之义。3.3 唤醒机制让睡着的 Agent 重新干活Agent 不可能一直满负荷运转大部分时间它在等待任务。OpenRig 的唤醒机制负责在合适的时候把 Agent 叫醒。实现上编排层通过tmux send-keys往目标 pane 注入一条唤醒指令Agent 收到后去任务表拉取新任务。这里有个细节值得说唤醒要防抖。如果短时间内有多个任务分给同一个 Agent不能每次都发一条唤醒指令否则 Agent 会被反复打断。我的做法是维护一个待唤醒队列合并短时间内的多次唤醒请求只发一次Agent 醒来后一次性把队列里的任务都拉走。注意send-keys注入的文本如果包含特殊字符可能被 tmux 解释成快捷键。稳妥做法是用send-keys -lliteral 模式发送避免转义问题。4. 并发场景下 Agent 怎么扛住压力AI Agent 怎么扛并发是热词里高频出现的问题也是多智能体系统绕不开的坎。OpenRig 在并发处理上有几个层面的设计我结合实际经验讲。4.1 单 Agent 内部的并发串行还是并行一个 Agent 同时接到多个任务是串行处理还是并行处理答案取决于任务类型。IO 密集型任务如搜索、抓取、调用外部 API适合并行因为大部分时间在等网络计算密集型或需要独占资源的任务如写文件、跑编译适合串行并行反而会互相干扰。OpenRig 的做法是给每个 Agent 配一个任务队列队列里的任务按类型分组IO 密集的并发执行资源独占的串行执行。这个策略不是拍脑袋定的而是实测出来的——早期我让所有任务都并行结果两个任务同时写同一个文件内容直接错乱。4.2 多 Agent 之间的并发资源竞争与限流多个 Agent 同时跑会争抢系统资源CPU、内存、网络带宽、外部 API 的调用配额。如果不加控制很容易出现一个 Agent 把 API 配额用光其他 Agent 全部报错的情况。OpenRig 用令牌桶限流来管这件事。每个外部资源比如某个搜索 API配一个令牌桶所有 Agent 共享。Agent 要调用资源前先申请令牌拿不到就排队等待。这样既保证了资源不被滥用又让多个 Agent 公平地分享配额。并发场景风险OpenRig 对策单 Agent 多任务资源冲突、文件写乱按任务类型分组IO 并行、独占串行多 Agent 抢资源配额耗尽、互相拖慢令牌桶限流共享配额消息洪峰路由层过载优先级队列 背压机制任务重复触发下游重复执行幂等更新 乐观锁4.3 背压当系统扛不住时怎么办背压backpressure是个容易被忽略但极其重要的机制。当任务产生速度超过 Agent 处理速度时如果不管不顾地往队列里塞队列会无限增长最终内存爆掉。OpenRig 的做法是队列有上限满了就拒绝新任务并通知上游慢一点。这个机制在真实场景里救过我好几次。有一次上游脚本疯狂生成任务如果没有背压系统几分钟就 OOM 了。有了背压上游收到队列满的信号后自动降速系统平稳运行。5. 从零搭一个最小可用 OpenRig 的实操路径5.1 环境准备与依赖确认动手之前先把地基打好。你需要一台常驻运行的机器本地或服务器都行装好 tmux、Python 或 Node 运行时、以及你要接入的 MCP server。我建议先用最小依赖跑通别一上来就堆一堆工具。# 确认 tmux 版本建议 3.0 以上 tmux -V # 创建一个专用会话名字叫 openrig tmux new-session -d -s openrig -n coordinator # 在会话里再开几个 window 给不同角色的 Agent tmux new-window -t openrig -n researcher tmux new-window -t openrig -n coder tmux new-window -t openrig -n reviewer这几条命令跑完你就有了一个持久化的会话骨架。每个 window 就是一个 Agent 的工位。注意-d参数让会话在后台创建不占用你的当前终端。5.2 给每个 Agent 写一个常驻循环Agent 进程的核心是一个读任务-执行-写结果的循环。下面是一个极简的 Python 骨架展示这个循环的逻辑import time import json from task_store import TaskStore from mcp_client import MCPClient def agent_loop(agent_id, mcp_servers): store TaskStore() client MCPClient(mcp_servers) while True: task store.claim_task(agent_id) if task is None: time.sleep(2) # 没任务就歇会儿别空转烧 CPU continue try: result client.execute(task.tool, task.params) store.complete_task(task.id, result) except Exception as e: store.fail_task(task.id, str(e))这段代码看着简单但有几个关键点claim_task必须是原子的否则两个 Agent 会抢到同一个任务sleep(2)的轮询间隔要权衡太短浪费 CPU太长响应慢异常必须捕获并记录否则一个任务失败会把整个 Agent 循环搞崩。5.3 编排层的调度逻辑编排层是系统的大脑它定期扫描任务表做三件事分派新任务、检测超时任务、处理阻塞任务。def orchestrator_tick(): store TaskStore() # 1. 把待处理任务分给空闲 Agent for task in store.pending_tasks(): agent store.find_idle_agent(task.required_skill) if agent: store.assign(task.id, agent.id) wake_agent(agent) # 2. 检测超时任务 for task in store.running_tasks(): if task.elapsed() task.timeout: store.mark_timeout(task.id) # 3. 处理阻塞任务通知上游 for task in store.blocked_tasks(): notify_upstream(task)wake_agent就是前面说的通过tmux send-keys注入唤醒指令。整个 tick 每隔几秒跑一次形成一个稳定的调度节拍。5.4 跑通第一个协作任务环境搭好后用一个简单任务验证整条链路让研究员 Agent 去查一个主题把结果交给编码 Agent 写成一个脚本再让审查 Agent 检查。这个流程能验证任务分派、消息路由、状态流转是否都正常。我建议第一次跑的时候把每个 Agent 的输出都tmux capture-pane抓下来看确认它们真的在按预期工作。别急着上复杂任务先把最小闭环跑稳。6. 那些只有真正跑起来才会遇到的坑6.1 Agent 假死进程还在但不再响应这是最隐蔽的坑。Agent 进程没退出tmux pane 也还在但它就是不处理新任务了。原因通常是 Agent 卡在某个阻塞调用上——比如等一个永远不返回的网络请求。我的对策是加心跳机制Agent 每隔一段时间往状态表写一个心跳时间戳编排层发现某个 Agent 超过阈值没更新心跳就判定它假死强制重启它的 pane。重启用tmux respawn-pane比 kill 掉重建会话干净。6.2 上下文膨胀Agent 越跑越慢常驻 Agent 跑久了上下文会不断累积内存占用越来越高响应越来越慢。这是持久化系统的通病。解决办法是定期做上下文压缩把历史交互总结成摘要丢弃原始细节。OpenRig 里我让 Agent 每处理 N 个任务就触发一次自我总结把关键信息留下冗余的扔掉。6.3 消息乱序协作逻辑错乱分布式系统里消息乱序是常态。Agent A 发了消息 M1 和 M2Agent B 可能先收到 M2。如果 M2 依赖 M1 的结果就会出错。OpenRig 用序列号 依赖检查来处理每条消息带序列号接收方发现序列号不连续就暂存等缺失的消息到了再一起处理。6.4 tmux 输出解析的坑capture-pane抓下来的文本包含终端控制字符、换行、光标位置等直接当结果用会出问题。必须做清洗去掉 ANSI 转义序列按标记提取有效内容。我建议让 Agent 输出时用明确的分隔符比如RESULT_START和RESULT_END包裹结果解析时按标记提取比正则匹配整个输出可靠得多。提示tmux capture-pane -p -J里的-J参数会把折行的内容合并抓长输出时很有用能避免结果被硬换行切断。7. 关于持久化协作我的一些真实体会跑了一段时间 OpenRig 之后我最大的感受是多智能体系统的复杂度90% 来自编排10% 来自智能。模型能力固然重要但真正决定系统能不能长期稳定运转的是任务表设计得合不合理、消息路由可不可靠、异常处理全不全面。我见过太多项目把精力全花在调 prompt 上结果系统跑两天就崩问题全出在编排层。另一个体会是别追求一步到位。我最初想设计一个完美的编排框架结果卡在设计阶段很久。后来改成先跑通最小闭环——两个 Agent、一个任务、一条消息——再逐步加功能反而推进得快。持久化、并发、背压这些机制都是遇到具体问题后才加进去的不是一开始就设计好的。如果你也想搭类似系统我的建议是从 tmux 一个任务表开始先让两个 Agent 能协作完成一个跨会话的任务把这条链路跑稳再考虑加 MCP、加并发、加限流。每加一个机制都要有明确的、真实遇到的问题作为驱动别为了架构漂亮而过度设计。这套东西的价值不在于多复杂而在于它真的能让 Agent 长期、稳定地替你干活。