企业官网建设流程全解析

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 作为能力的"标准插座"

MCP（Model 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 的读写接口与它交互，同时维护一张全局的任务与状态表。

这张表基本就是 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 -l（literal 模式）发送，避免转义问题。

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 公平地分享配额。

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 和 M2，Agent 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 长期、稳定地替你干活。