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 必须有会话回收机制。我建议的生命周期策略是这样的状态判定条件处理动作活跃最近 5 分钟内有输出保持正常调度空闲输出[IDLE]超过 10 分钟保留会话释放计算配额疑似卡死超过 30 分钟无任何输出且非空闲抓取最后 100 行日志告警已完成输出[DONE]标记归档日志后 kill 会话孤儿任务已取消但会话仍在强制 kill 并记录这张表是我在实际运维中总结出来的比任何框架自带的健康检查都实用。关键点是**空闲和卡死必须区分开**——空闲是正常的卡死是异常的如果一刀切地把长时间无输出的会话都杀掉你会误杀那些正在等待人类输入的正常 Agent。3. MCP 接入让 Agent 的手伸向真实世界3.1 MCP 到底解决什么问题从能说到能做热词里 MCP 出现的频率极高很多人问MCP 是软件协议还是硬件协议。这里先给个明确答案MCPModel Context Protocol是一套软件层的通信协议它规范的是AI 模型/Agent 如何调用外部工具和数据源。你可以把它类比成 USB-C——USB-C 不关心你插的是硬盘还是显示器它只规定接口形状和通信规则MCP 也不关心你接的是数据库还是浏览器它只规定 Agent 怎么发现工具、调用工具、拿回结果。没有 MCP 之前每接一个工具你都得写一套适配代码接数据库写一套、接浏览器写一套、接文件系统再写一套。MCP 的价值在于把工具接入标准化工具提供方实现一个 MCP ServerAgent 侧实现一个 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 的实践里把工具权限按角色做了硬隔离Agent 角色允许的 MCP 工具禁止的工具研究员文件读、数据库读、搜索文件写、shell 执行执行者文件写、shell 执行数据库写、外部网络审核者文件读、日志读任何写操作、任何执行协调者会话管理、消息发送直接操作业务数据这张表的价值在于它把权限从代码里的 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。资源占用大致如下指标空闲时10 Agent 满载瓶颈点CPU5%78%推理调用密集时飙到 95%内存1.2G9.4G每个 Agent 约 800M文件句柄2003200MCP Server 连接数网络连接10180API 调用并发结论很明确内存和文件句柄是主要瓶颈不是 CPU。每个 Agent 加上它的 MCP Server内存开销接近 1G10 个就是 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组织需要复盘时直接读文件不需要保留活会话。# 归档并销毁已完成会话 SESSIONresearcher-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 时设置TERMdumb禁用颜色或者在解析前先 strip 掉 ANSI 码。这三个坑有个共同点它们都不是AI 问题而是系统工程问题。多智能体编排的难点八成在工程细节上两成在 AI 能力上。把工程做扎实AI 的能力才能稳定发挥出来。6.4 给不同阶段实践者的建议如果你刚开始接触多智能体我的建议是先用 tmux 手动管理两三个 Agent把会话持久化和消息传递这两件事跑通别急着上框架。手动跑一遍你会对Agent 是什么、会话是什么、状态在哪有肌肉记忆般的理解这比看十篇架构文章都管用。如果你已经在用 LangGraph 之类的框架我建议你把 tmux 会话层加进去。框架负责推理逻辑tmux 负责进程持久化和人类可介入两者不冲突反而互补。框架让你写得快tmux 让你跑得稳。如果你在做中台我建议你先把单机方案做到极致再考虑分布式。我见过太多团队一上来就搞 K8s 消息队列 微服务结果连Agent 挂了怎么恢复都没解决。单机 tmux 方案虽然朴素但它把最核心的问题——持久化、可寻址、可介入——解决得很干净。等这套跑顺了再往上加分布式组件每一步都有明确的收益而不是为了架构而架构。最后分享一个我一直在用的小技巧给每个 Agent 会话配一个心跳文件Agent 每隔 30 秒往文件里写一次时间戳。监控脚本读这个文件超过 90 秒没更新就告警。这比任何复杂的健康检查都可靠因为它检测的是Agent 是否真的在干活而不是进程是否还在。进程活着但卡死的 Agent只有心跳能发现。