企业官网建设流程全解析

1. 为什么单兵作战的 AI Agent 总是“用完即忘”

1.1 从一次真实的翻车现场说起

去年年底我接了个私活，帮一个做跨境电商的朋友搭一套自动化的商品文案生成流水线。需求听起来不复杂：抓取竞品页面、提取卖点、生成多语言文案、审核敏感词、最后推送到他们的 CMS。我当时的思路很“标准”——写一个主控脚本，按顺序调用几个独立的 AI Agent，每个 Agent 负责一个环节，跑完就退出。

第一版跑通了，我挺得意。结果第二天朋友打电话过来，说系统“疯了”。我一看日志，问题出在第三步：文案生成 Agent 在生成德语版本时，把上一步提取的“防水等级 IPX7”理解成了“价格 7 欧元”，因为它在启动时是全新的上下文，根本不知道前面发生了什么。更离谱的是，审核 Agent 因为拿不到原始卖点列表，把一段完全合规的文案标记成了“含医疗宣称”。

这就是离散 AI Agent的典型病症：每个 Agent 都是孤岛，状态不共享，记忆不延续，协作靠主控脚本硬编码。你写十个 Agent，就有十份重复的上下文初始化逻辑，十套各不相同的错误处理，以及十个“用完即忘”的失忆症患者。

我后来花了整整一周重构，才把这条流水线救回来。也正是那次踩坑，让我开始认真思考一个问题：能不能把离散的 Agent 编织成一个有记忆、能协作、可持久化的系统？这就是 OpenRig 这个项目要解决的核心命题。

1.2 OpenRig 到底是个什么东西

先把话说清楚，OpenRig 不是一个具体的软件产品，而是一套多智能体编排（Multi-Agent Orchestration）的实践方法论与参考架构。它的目标很明确：把那些各自为战、跑完即死的 AI Agent，组织成一个像团队一样工作的持久化协作系统。

你可以把它理解成一个“Agent 的操作系统”。在这个系统里：

• 每个 Agent 是一个有明确职责的“员工”，而不是一次性脚本；
• Agent 之间有共享的持久化状态层，谁做了什么、产出了什么，所有人都能查到；
• 任务的流转由编排器统一调度，而不是靠主控脚本里一堆 if-else 硬串；
• 整个系统可以长时间运行，中途重启、扩容、替换某个 Agent，都不会导致状态丢失。

它适合谁？如果你正在做 AI Agent 相关的项目，尤其是那种“多个 Agent 协同完成一个复杂任务”的场景，比如自动化内容生产、代码审查流水线、数据分析管道、客服工单处理，那 OpenRig 这套思路你大概率用得上。哪怕你只是刚入门想搞个练手小项目，理解这套编排逻辑也能让你少走很多弯路。

1.3 关键词背后的技术地图

在深入之前，先把几个核心概念的关系理清楚，不然后面容易晕。

AI Agent是基本单元，一个能感知输入、做出决策、执行动作的智能体。多智能体编排是让多个 Agent 协同工作的调度艺术。持久化解决的是状态存储和恢复问题。而tmux和MCP是 OpenRig 实践中最常被用到的两个具体工具——tmux 负责给每个 Agent 一个独立的、可长期存活的运行环境，MCP（Model Context Protocol）负责让 Agent 与外部工具、数据源之间建立标准化的连接。

这四个词串起来，就是 OpenRig 的完整技术图景：用 tmux 给 Agent 安家，用 MCP 给 Agent 接上手脚，用编排器给 Agent 排班，用持久化层给 Agent 装上记忆。

2. 整体架构设计：把 Agent 当成团队来管

2.1 为什么不能用“主控脚本 + 顺序调用”的老路子

我见过太多项目，多 Agent 协作的实现方式就是一个 Python 脚本，里面按顺序调用各个 Agent 的函数。这种写法在 Demo 阶段没问题，一旦上生产就原形毕露。

第一个致命问题是状态耦合。所有中间结果都存在主控脚本的局部变量里，一旦脚本崩溃，全部丢失。你想加个断点续跑？对不起，得从头再来。第二个问题是扩展性差。你想让两个 Agent 并行跑？得手动改代码引入线程或异步。你想动态增加一个 Agent？得改主控逻辑。第三个问题是可观测性差。Agent 之间传了什么、哪个环节慢了、哪个 Agent 出错了，全靠打日志，排查起来像大海捞针。

OpenRig 的设计哲学是：把 Agent 之间的协作关系从代码里抽出来，变成可配置、可观测、可持久化的编排层。主控脚本不再关心“谁调用谁”，它只负责把任务丢进编排器，剩下的交给系统。

2.2 三层架构：运行层、编排层、状态层

OpenRig 的架构我习惯分成三层来讲，这样最清晰。

运行层是每个 Agent 实际跑着的地方。这里我强烈推荐用 tmux 会话来承载。为什么是 tmux 而不是简单的子进程？因为 tmux 会话是可分离、可重连、可持久存活的。你的 Agent 跑在一个 tmux window 里，即使你的 SSH 断了、终端关了，Agent 依然在跑。你想看它的实时输出，随时 attach 回去。你想给它发个指令，直接 send-keys 就行。这比用 nohup 挂后台、用日志文件看输出要灵活得多。

编排层是系统的“大脑”，负责决定任务怎么流转。它维护一个任务队列，每个任务包含输入、期望的输出格式、以及一个“路由规则”——根据当前状态决定下一步交给哪个 Agent。编排器本身不执行具体逻辑，它只做调度。这样做的好处是，你想改协作流程，只改编排配置，不用动任何 Agent 的代码。

状态层是系统的“记忆”，通常用一个持久化的键值存储或数据库来实现。每个 Agent 完成任务后，把产出写入状态层，并附带元数据（谁写的、什么时候写的、依赖了哪些前置状态）。下一个 Agent 启动时，从状态层读取它需要的输入。这样即使某个 Agent 崩溃重启，它也能从状态层恢复上下文，继续干活。

2.3 状态层的设计细节：别小看“记忆”这件事

状态层听起来简单，做起来坑最多。我踩过的坑包括：状态格式不统一导致 Agent 之间互相看不懂、状态无限增长导致查询变慢、并发写入导致数据覆盖。

我的经验是，状态层至少要有这几个设计：

• 统一的信封格式。每条状态记录都包含task_id、agent_id、timestamp、payload、dependencies这几个字段。payload 里才是具体内容。这样任何 Agent 读状态时，先看信封就知道这条记录是谁写的、能不能用。
• 版本化。同一个 task_id 下，状态可以有多个版本。Agent 更新状态时不是覆盖，而是追加新版本。这样出问题时可以回溯到任意历史版本。
• TTL 与归档。不是所有状态都需要永久保留。完成的任务状态可以归档到冷存储，活跃状态层只保留最近 N 天的数据，保证查询性能。

提示：状态层选型上，小规模用 Redis 就够了，它的 Hash 结构和过期机制天然适合。规模大了再考虑 PostgreSQL 或专门的向量数据库（如果状态里包含语义检索需求）。

2.4 tmux 在架构中的真实角色

很多人第一次听到“用 tmux 跑 Agent”会觉得奇怪，tmux 不是终端复用工具吗？怎么跟 AI Agent 扯上关系了？

关键在于 tmux 提供的会话隔离和持久化能力。每个 Agent 跑在独立的 tmux window 里，意味着：

• 它的标准输出、错误输出是独立的，不会和其他 Agent 混在一起；
• 它的工作目录、环境变量可以独立配置；
• 它可以长时间运行，不受父进程生命周期影响；
• 你可以随时 attach 进去，像操作一个真实终端一样和它交互。

我实测下来，用 tmux 管理 10 个以内的 Agent 非常稳。启动脚本大概长这样：

# 创建一个名为 openrig 的会话 tmux new-session -d -s openrig -n orchestrator # 为每个 Agent 创建一个 window tmux new-window -t openrig -n agent-fetch tmux send-keys -t openrig:agent-fetch 'python agent_fetch.py' C-m tmux new-window -t openrig -n agent-generate tmux send-keys -t openrig:agent-generate 'python agent_generate.py' C-m tmux new-window -t openrig -n agent-review tmux send-keys -t openrig:agent-review 'python agent_review.py' C-m

这样一套下来，整个 Agent 团队就在一个 tmux 会话里跑起来了。想看哪个 Agent 的状态，tmux attach -t openrig然后切 window 就行。

3. MCP 协议：给 Agent 接上标准化的手脚

3.1 MCP 到底解决了什么问题

MCP 全称 Model Context Protocol，是一个让 AI 模型与外部工具、数据源之间建立标准化连接的协议。在 OpenRig 的语境下，它的价值在于：让 Agent 不用为每个外部工具写一套适配代码。

在没有 MCP 之前，你想让 Agent 读数据库，得写数据库连接代码；想让它调浏览器，得写 Playwright 脚本；想让它操作某个桌面软件，得写对应的自动化代码。每个工具一套接口，Agent 的代码里塞满了各种 SDK 调用。

有了 MCP，这些外部能力都被抽象成统一的“工具”，Agent 只需要知道工具的名字和参数格式，具体的连接细节由 MCP Server 负责。这就像给 Agent 配了一套标准化的“手脚”，不管是接数据库、接浏览器、还是接某个专业软件，接口都是一样的。

3.2 MCP Server 的接入方式与实操

MCP Server 的接入通常有两种模式：本地进程模式和远程服务模式。

本地进程模式适合那些需要访问本地资源的工具，比如文件系统、本地数据库、桌面软件。你启动一个 MCP Server 进程，Agent 通过标准输入输出和它通信。这种模式延迟低、部署简单，但受限于单机。

远程服务模式适合那些需要共享的工具，比如团队共用的知识库、云端 API。MCP Server 跑在远程，Agent 通过网络连接。这种模式扩展性好，但要注意网络延迟和认证安全。

实操上，接入一个 MCP Server 的典型流程是：

1. 确认 MCP Server 已经启动，拿到它的连接地址或进程句柄；
2. 在 Agent 的配置里声明这个 Server 提供的工具列表；
3. Agent 在需要时调用工具，传入参数，等待返回结果；
4. 处理返回结果，写入状态层。

注意：MCP Server 的日志管理是个容易被忽视的点。默认日志往往直接打到标准输出，和 Agent 自己的输出混在一起，排查问题时非常痛苦。我的做法是给每个 MCP Server 配置独立的日志文件，并在日志里带上请求 ID，方便和 Agent 侧的日志做关联。

3.3 工具选型的取舍：Playwright MCP 还是 Browser Use MCP

在浏览器自动化这个场景下，经常有人纠结用 Playwright MCP 还是 Browser Use MCP。我的经验是看你的需求侧重。

Playwright MCP 更偏向确定性操作。你告诉它点哪个按钮、填哪个输入框、等哪个元素出现，它精确执行。适合那些流程固定、需要稳定复现的任务，比如定时抓取某个页面的数据、自动化填表。

Browser Use MCP 更偏向探索性操作。你给它一个目标，比如“找到这个网站上最便宜的商品”，它自己决定怎么点、怎么翻页。适合那些流程不固定、需要一定智能判断的任务。

在 OpenRig 的编排体系里，我通常两个都接。确定性环节用 Playwright，探索性环节用 Browser Use，编排器根据任务类型路由到不同的 Agent。

3.4 MCP 与状态层的协同

MCP 负责“做事”，状态层负责“记事”，两者必须协同好。我的做法是：每次 MCP 工具调用完成后，Agent 不仅要把结果写入状态层，还要把调用的元信息也写进去——调了哪个工具、传了什么参数、耗时多少、是否成功。

这样做的好处是，当后续环节出问题时，你可以完整回溯整个执行链路。比如文案生成 Agent 说“我拿到的卖点数据是空的”，你查状态层就能看到，是抓取 Agent 没抓到，还是 MCP 工具调用失败了，还是状态写入时出了问题。没有这层元信息，排查就是盲人摸象。

4. 从零搭建：一个可复现的 OpenRig 最小实践

4.1 环境准备与依赖清单

在动手之前，先把环境理清楚。以下是我实测下来最稳的一套组合：

依赖装好后，先验证 tmux 和 Redis 都能正常工作。tmux -V看版本，redis-cli ping看是否返回 PONG。这两个基础不牢，后面全是坑。

4.2 定义 Agent 的职责边界

搭建之前，最重要的一步是把每个 Agent 的职责想清楚。职责不清，后面状态层就会变成一锅粥。

我以内容生产流水线为例，拆成四个 Agent：

• Fetch Agent：负责从外部数据源获取原始素材，输出结构化的原始数据；
• Extract Agent：负责从原始数据中提取关键信息（卖点、参数、关键词），输出结构化字段；
• Generate Agent：负责基于提取的信息生成目标内容，输出草稿；
• Review Agent：负责审核草稿的合规性和质量，输出审核结果和修改建议。

每个 Agent 的输入和输出都必须是明确的结构化格式，这是状态层能正常运转的前提。我通常用 JSON Schema 来约束，写清楚每个字段的类型、是否必填、取值范围。

4.3 编排器的核心逻辑实现

编排器不需要很复杂，核心就是一个“读状态、判断、派任务”的循环。下面是我常用的一个简化版实现思路：

import redis import json import time r = redis.Redis(host='localhost', port=6379, decode_responses=True) def get_task_state(task_id): raw = r.hgetall(f"task:{task_id}") return {k: json.loads(v) for k, v in raw.items()} def route_task(task_id): state = get_task_state(task_id) if 'fetch' not in state: return 'agent-fetch' if 'extract' not in state: return 'agent-extract' if 'generate' not in state: return 'agent-generate' if 'review' not in state: return 'agent-review' return None # 任务完成 def dispatch(task_id, agent_name): # 通过 tmux send-keys 把任务派给对应 Agent cmd = f"python run_agent.py --task {task_id}" import subprocess subprocess.run([ 'tmux', 'send-keys', '-t', f'openrig:{agent_name}', cmd, 'C-m' ]) def main_loop(): while True: pending = r.smembers("pending_tasks") for task_id in pending: next_agent = route_task(task_id) if next_agent: dispatch(task_id, next_agent) else: r.srem("pending_tasks", task_id) r.sadd("completed_tasks", task_id) time.sleep(2) if __name__ == '__main__': main_loop()

这段代码的核心思想是：编排器不关心 Agent 怎么干活，它只关心状态层里有没有对应的产出。有就跳过，没有就派任务。这种“状态驱动”的调度方式，天然支持断点续跑和幂等重试。

4.4 Agent 的标准化模板

每个 Agent 的代码结构应该高度一致，这样才好维护。我的模板大致是这样：

import redis import json import sys import time r = redis.Redis(host='localhost', port=6379, decode_responses=True) def read_input(task_id, required_keys): state = r.hgetall(f"task:{task_id}") inputs = {} for key in required_keys: if key not in state: raise ValueError(f"Missing required state: {key}") inputs[key] = json.loads(state[key]) return inputs def write_output(task_id, agent_id, payload, dependencies=None): record = { 'agent_id': agent_id, 'timestamp': time.time(), 'payload': payload, 'dependencies': dependencies or [] } r.hset(f"task:{task_id}", agent_id, json.dumps(record)) def main(task_id): # 1. 读取输入 inputs = read_input(task_id, ['fetch']) # 2. 执行核心逻辑 result = do_work(inputs) # 3. 写入输出 write_output(task_id, 'extract', result, dependencies=['fetch']) if __name__ == '__main__': task_id = sys.argv[sys.argv.index('--task') + 1] main(task_id)

这个模板的价值在于一致性。所有 Agent 都遵循同样的读写模式，状态层的信封格式统一，编排器不用为每个 Agent 写特殊逻辑。

4.5 启动与验证：让整个系统跑起来

启动流程分三步：

第一步，启动 Redis 和 tmux 会话，创建各个 Agent 的 window。

第二步，在每个 window 里启动 Agent 的常驻进程。注意，Agent 不是跑一次就退出，而是常驻监听。它监听一个任务队列，有新任务就处理，没有就等待。这样才能实现持久化协作。

第三步，往pending_tasks里塞一个测试任务，观察编排器是否正常派发，各个 Agent 是否按顺序执行，状态层是否正确累积。

验证的关键指标是：任务从进入队列到完成，状态层里应该依次出现 fetch、extract、generate、review 四条记录，且每条记录的 dependencies 字段正确指向了前置状态。

5. 实操中踩过的坑与排查技巧

5.1 状态竞争：两个 Agent 同时写同一条记录

这是并发场景下最容易出的问题。比如 Fetch Agent 因为重试机制，同时跑了两个实例，都往task:123的fetch字段写数据，后写的覆盖了先写的，导致数据不一致。

我的解决方案是写入前检查。Agent 在写状态前，先读一下目标字段是否已存在。如果存在且内容不同，说明有竞争，此时要么放弃写入，要么写入到带版本号的新字段。Redis 的HSETNX命令（只在字段不存在时设置）在这种场景下很好用。

5.2 Agent 假死：进程还在但不再处理任务

tmux 里的 Agent 进程有时候会“假死”——进程还在，但卡在某个网络请求或死循环里，不再响应新任务。

排查方法是看 Agent 的日志时间戳。如果最后一条日志是十分钟前的，但队列里明明有它的任务，那大概率是假死了。解决方法是给 Agent 加心跳机制：每隔一段时间往状态层写一个心跳记录，编排器发现某个 Agent 心跳超时，就重启它的 tmux window。

5.3 MCP 工具调用超时导致整条链路卡住

MCP 工具调用如果没有超时控制，一个慢请求就能把整个 Agent 卡死。我踩过一次坑，某个 MCP Server 因为网络问题响应极慢，导致 Generate Agent 卡了半小时，整条流水线停摆。

后来我给所有 MCP 调用都加了超时和重试：单次调用超过 30 秒就中断，重试最多 3 次，3 次都失败就写入错误状态，让编排器决定是跳过还是人工介入。

5.4 常见问题速查表

5.5 几个让我少走弯路的经验

第一，状态层的 Schema 一定要先定死再动手。我一开始图快，边写边改字段名，结果三个 Agent 用了三套不同的字段命名，最后花了一天统一。

第二，Agent 的日志要带 task_id。不然多个任务并行时，日志混在一起根本没法看。我现在的做法是每条日志前面都拼上[task_id]，grep 一下就能捞出整个任务的全链路日志。

第三，tmux 会话命名要有规范。我用openrig:<agent-name>的格式，一眼就能看出哪个 window 是哪个 Agent。别用默认的 0、1、2，过两天你自己都忘了谁是谁。

第四，先跑通两个 Agent 的协作，再扩展到四个。我见过有人一上来就设计十个 Agent 的复杂编排，结果调试成本爆炸。先用两个 Agent 把状态读写、编排派发的闭环跑通，再逐步加人。

6. 系统扩展：从四个 Agent 到生产级编排

6.1 水平扩展：同一职责多个实例

当某个环节成为瓶颈时，最直接的扩展方式是给这个 Agent 起多个实例。比如 Generate Agent 因为要调用大模型，单实例吞吐有限，那就起三个实例，编排器轮询派发。

实现上，把 tmux window 命名改成agent-generate-1、agent-generate-2、agent-generate-3，编排器维护一个实例列表，派发时轮询选择。状态层不需要改，因为多个实例写的是同一个 task 的不同字段，只要做好并发控制就行。

6.2 引入优先级队列

生产环境里，任务是有优先级的。VIP 客户的任务不能和普通任务排一个队。我的做法是在状态层给每个任务打上 priority 标记，编排器优先处理高优先级任务。Redis 的 Sorted Set 天然适合做优先级队列，score 就是优先级。

6.3 可观测性建设

系统跑起来之后，你需要知道它跑得好不好。我通常关注这几个指标：

• 任务吞吐量：单位时间完成的任务数；
• 各环节耗时：每个 Agent 处理一个任务的平均耗时；
• 失败率：任务失败的比例，以及失败集中在哪个环节；
• 队列积压：pending_tasks 的数量，持续增长说明有瓶颈。

这些指标可以从状态层的记录里算出来，也可以接入专门的监控系统。我一开始用最简单的方案——写个脚本定时统计，输出到终端。后来任务量大了，才换成 Grafana 看板。

6.4 与现有系统的集成

OpenRig 不是孤岛，它通常要和企业现有的系统对接。比如任务来源可能是某个工单系统，产出要推送到 CMS。这些对接点，我建议都通过 MCP 来做，保持接口的统一性。

如果现有系统没有 MCP Server，那就自己写一个薄薄的适配层，把现有 API 包装成 MCP 工具。这层适配代码不涉及业务逻辑，只是协议转换，维护成本很低。

7. 关于这套编排思路，我个人的几点体会

搞了这么久多智能体编排，我最大的体会是：技术难点从来不在 Agent 本身，而在 Agent 之间的“关系”上。单个 Agent 的智能程度再高，如果协作机制没设计好，整体表现还不如一个单体脚本。

OpenRig 这套思路的核心价值，是把“协作”这件事从代码里抽出来，变成可配置、可观测、可持久化的系统能力。tmux 解决了运行环境的持久化，MCP 解决了工具接入的标准化，状态层解决了记忆的延续，编排器解决了调度的灵活性。四者缺一不可。

如果你正准备从零搭建 AI Agent 系统，我的建议是：别急着写 Agent 的业务逻辑，先把编排骨架搭起来。用两个最简单的 Agent（比如一个读、一个写）把状态流转跑通，确认编排器、状态层、tmux 环境都工作正常，再往里填真正的业务逻辑。这个顺序反过来，后面返工的成本会高得让你怀疑人生。

最后分享一个小技巧：调试多 Agent 系统时，我习惯在状态层里额外写一个debug_trace字段，记录每个 Agent 的关键决策点。这个字段不参与业务逻辑，纯粹为了排查问题。等系统稳定了再把它关掉。这个习惯帮我省下了无数个加班的夜晚。