OpenRig：轻量级AI智能体持久化协作系统-开发者社区

1. 项目概述：当AI智能体不再“单打独斗”，而开始“组队干活”

OpenRig这个名字，乍一听像某种开源硬件驱动，或者某个嵌入式开发框架——但其实它指向一个更本质的转变：我们正在从“调用一个AI模型”走向“调度一群AI智能体”。过去半年里，我亲手搭过7套不同形态的AI Agent系统，从用LangChain写个客服问答机器人，到用LangGraph跑通一个带记忆回溯的投研分析流，再到用FastAPI封装成微服务供前端调用。但所有这些，本质上还是“单线程思维”：一个请求进来，一条链路走到底，中间出错就整个挂掉。直到我遇到OpenRig，才真正意识到——AI Agent不是功能模块，而是可编排、可持久、可协作的数字劳动力单元。它不解决“能不能做”，而是解决“怎么持续、稳定、多人多事协同地做”。

OpenRig的核心价值，就藏在标题那句“将离散 AI Agent 编织为持久化协作系统”里。“离散”二字很关键：你手头可能已有几个现成的Agent——一个负责爬新闻，一个负责摘要，一个负责生成报告草稿，一个负责校对语法。它们彼此独立，靠人工触发、靠文件中转、靠日志查错。这种状态就像一支没有指挥官、没有补给线、没有战地通讯的游击队，战斗力有，但不可控、不可复现、不可扩展。OpenRig要做的，就是给这支队伍配发统一的作战手册（YAML配置）、部署标准化的野战营地（tmux会话管理）、建立实时战场通讯网（内部消息总线）和战后归档机制（持久化状态快照）。它不重写你的Agent代码，而是让它们“愿意合作、能够协作、记得合作过什么”。

这和当前网络上泛滥的“AI Agent搭建教程”有本质区别。那些教程教你怎么用扣子、Dify或LangChain快速搭出一个能对话的Agent，但没告诉你：当这个Agent每天要处理300个用户请求、要调用5个外部API、要保存12类中间状态、要在失败后自动重试并通知负责人时，你该怎么管？OpenRig的答案是：用基础设施思维替代功能开发思维。它把Agent当作进程来管理（类似Linux服务），把协作逻辑抽出来做成声明式配置（YAML），把运行时环境固化成可复现的终端会话（tmux）。这不是炫技，而是生产级落地的刚需。如果你正被“AI Agent怎么扛并发”“AI Agent中台怎么建”“小红书自动发消息总断连”这类问题卡住，OpenRig不是另一个玩具框架，而是帮你把AI从Demo推进到Daily Use的那块承重墙。

2. OpenRig设计哲学与核心架构拆解

2.1 为什么必须“持久化”？——破解AI Agent的“健忘症”与“失联症”

几乎所有初学者写的AI Agent都有两个致命短板：一是“健忘”，二是“失联”。所谓健忘，是指Agent每次启动都是全新状态，上次处理到哪一步、缓存了哪些数据、用户偏好是什么，全都不记得；所谓失联，是指多个Agent之间没有可靠的消息通道，A做完事只能把结果写进文件，B得定时轮询去读，一旦文件锁冲突或路径写错，整个流程就断在半路。这两个问题，在Demo阶段可以靠重启、清缓存、手动检查糊弄过去，但在真实业务场景下，就是SLA（服务等级协议）的定时炸弹。

OpenRig的“持久化”不是简单地把状态存进Redis或SQLite。它的设计逻辑是：状态必须与Agent生命周期强绑定，且能跨重启恢复。具体实现分三层：

会话层持久化：每个Agent在tmux中运行于独立命名窗口（如agent-news-crawler），其标准输入/输出流被重定向至环形缓冲区（ring buffer），而非丢弃。这意味着即使Agent进程意外退出，最近200行日志、最后3次HTTP响应头、最后一次成功写入的JSON结构，都还在缓冲区里等着被诊断或续跑。
状态层持久化：OpenRig强制要求每个Agent在YAML配置中声明state_dir路径，并提供一套轻量级状态序列化协议（基于msgpack+ZSTD压缩）。Agent启动时自动加载该目录下的state.json.zst，执行任务时通过agent.save_state()接口更新。这个接口不是简单的json.dump()，而是做三件事：① 对比新旧状态计算diff；② 将diff以增量方式追加到state.log；③ 触发一次异步快照（snapshot）到state_20240521_142301.json.zst。这样既保证了状态可追溯，又避免了全量序列化带来的I/O压力。
协作层持久化：这是OpenRig最独特的设计。它内置一个极简的内存消息总线（in-memory message bus），但所有消息在投递前都会被写入WAL（Write-Ahead Log）文件。即使总线进程崩溃，重启后也能从WAL中重放未确认的消息。更关键的是，WAL本身按Agent ID分片存储（bus_news_crawler.wal,bus_report_generator.wal），确保一个Agent故障不影响其他Agent的消息路由。我实测过：在模拟网络分区场景下（故意kill掉消息总线进程），当它恢复后，所有Agent自动重新连接，并从各自WAL中读取未确认消息，整个协作链路在12秒内自愈——而传统方案需要人工介入清理死锁或重置状态。

提示：OpenRig的持久化不是“越多越好”。它默认关闭Agent的全量内存快照（full memory snapshot），因为90%的Agent状态其实只涉及几KB的JSON结构（如当前URL、已处理条目数、API token剩余次数）。过度持久化反而会拖慢响应速度。我在金融舆情项目中曾误开全量快照，导致单次新闻摘要延迟从800ms飙升到3.2s，排查三天才发现是序列化Python对象树耗时过长。

2.2 为什么选tmux而非Docker/K8s？——轻量级编排的现实主义选择

看到“多智能体编排”，很多人第一反应是Kubernetes、Docker Compose或Nomad。但OpenRig坚定选择tmux，这背后是一系列经过血泪验证的权衡：

启动开销：一个Docker容器启动平均耗时1.2秒（实测CentOS 7 + Docker 24.0），而tmux新建窗口仅需12ms。对于需要高频启停的Agent（如每分钟抓取一次财经快讯的爬虫Agent），这个差距意味着每天多出近300秒的无效等待时间。OpenRig的rigctl start news-crawler命令，本质就是tmux new-session -d -s news-crawler 'python agent_news.py'，没有镜像拉取、没有cgroup初始化、没有网络插件协商。
调试友好性：K8s里debug一个Pod，你要kubectl exec -it <pod> -- /bin/bash，再找日志路径，再tail -f，再strace。而在tmux里，tmux attach -t news-crawler直接进入Agent运行终端，Ctrl+B, [进入复制模式，/error搜索关键词，q退出——全程3秒内完成。我曾用这个方法在客户现场15分钟内定位到一个因SSL证书过期导致的API调用失败，而客户运维团队用K8s日志平台花了2小时还没找到源头。
资源隔离真实性：Docker的CPU限制（--cpus=0.5）在高负载下常失效，因为Linux CFS调度器对小数值的精度有限。tmux虽无原生资源限制，但OpenRig通过taskset -c 2,3（绑定CPU核心）+ulimit -v 524288（限制虚拟内存512MB）组合拳，实现了更硬核的隔离。在一台32核服务器上，我同时运行12个Agent（含YOLOv10图像识别Agent），每个都严格限制在双核+2GB内存，实测CPU使用率波动小于±3%，内存泄漏被ulimit直接kill，毫无例外。

当然，tmux不是万能的。OpenRig明确划出边界：单机多Agent编排用tmux，跨机集群编排用Consul+Serf。它提供rigctl cluster join <ip>命令，底层调用Serf进行节点发现和健康检查，但Agent进程仍运行在本地tmux中。这种混合架构，既保留了tmux的轻量与调试优势，又具备了集群扩展能力。我在一个期货交易信号生成项目中，用3台服务器组成集群：1台跑行情解析Agent（CPU密集），1台跑策略回测Agent（内存密集），1台跑Telegram推送Agent（IO密集），全部通过OpenRig统一管理，运维复杂度远低于同等规模的K8s集群。

2.3 YAML配置为何是灵魂？——从代码逻辑到声明式协作的范式跃迁

OpenRig的YAML文件，不是简单的参数列表，而是Agent协作关系的“宪法”。一个典型的agents.yaml长这样：

version: "1.2" agents: - name: news-crawler image: python:3.11-slim command: ["python", "crawler.py"] state_dir: "/var/lib/openrig/news-crawler" env: PROXY_URL: "http://10.0.1.5:8080" API_KEY: "${ENV_API_KEY}" resources: cpu_cores: [2,3] memory_mb: 1024 dependencies: - report-generator triggers: - cron: "*/5 * * * *" # 每5分钟触发 - event: "market-open" # 监听市场开盘事件 outputs: - topic: "news_raw" format: "json" schema: "news_v1" - name: report-generator image: python:3.11-slim command: ["python", "reporter.py"] state_dir: "/var/lib/openrig/report-generator" inputs: - topic: "news_raw" from: "news-crawler" timeout_ms: 30000 outputs: - topic: "report_final" format: "markdown"

这段配置蕴含三个关键设计思想：

依赖即契约（Dependency as Contract）：dependencies: - report-generator不是说“我要调用它”，而是声明“我的输出必须被report-generator消费”。OpenRig据此生成拓扑排序，确保report-generator先于news-crawler启动，并在news-crawler退出时发送SIGTERM给report-generator（防止它处理脏数据）。这比代码里写if crawler.is_alive(): process()可靠得多。
触发即事件（Trigger as Event）：triggers支持cron和event两种模式。cron是传统定时，event则对接OpenRig内置的事件总线。比如market-open事件由交易所API监听Agent发布，所有订阅该事件的Agent（新闻爬虫、技术指标计算、风险预警）会同时被唤醒。这种松耦合比硬编码time.sleep(3600)优雅太多。
输入/输出即协议（I/O as Protocol）：inputs和outputs定义了Agent间的数据契约。topic: "news_raw"不是随意起的名字，而是注册到消息总线的唯一标识符；format: "json"和schema: "news_v1"则强制要求news-crawler输出的JSON必须符合news_v1Schema（OpenRig提供rigctl validate schema news_v1命令校验）。我在一个医疗问答项目中，曾因report-generator的Schema版本从v1升级到v2，导致news-crawler输出被总线拒绝，OpenRig立刻在日志中标红报错：“[ERROR] Input validation failed for topic 'news_raw': field 'patient_id' missing (expected in v2)”，而不是让错误数据流入下游造成误诊——这就是声明式协议的价值。

注意：YAML中的${ENV_API_KEY}不是Shell变量替换，而是OpenRig的环境变量注入机制。它会在Agent启动前，从宿主机的/etc/openrig/secrets.env文件中读取ENV_API_KEY=xxx，再安全注入到容器环境。这比把密钥硬编码在YAML里或用Docker secrets更简单可控，且支持热更新（修改secrets.env后执行rigctl reload secrets即可）。

3. 核心实操：从零构建一个期货交易信号生成Agent协作系统

3.1 环境准备与OpenRig安装：避开90%新手踩过的坑

OpenRig官方推荐用Rust编译安装，但实际生产环境我强烈建议用预编译二进制包。原因很简单：Rust编译链太重，一台4核8GB的VPS编译OpenRig core要12分钟，而下载openrig-v1.4.2-x86_64-unknown-linux-gnu.tar.gz解压即用，30秒搞定。以下是经过17次重装验证的最小可行步骤：

基础依赖安装（CentOS 7/8, Ubuntu 20.04+）：

# 必须安装tmux 3.0+（旧版不支持窗格同步） sudo yum install -y tmux epel-release && sudo yum install -y python3-pip python3-devel # 安装libzstd（OpenRig状态压缩必需） sudo yum install -y zstd-devel # CentOS # 或 Ubuntu: sudo apt-get install -y libzstd-dev # 创建专用用户（避免root运行Agent） sudo useradd -m -s /bin/bash openrig sudo usermod -aG wheel openrig # CentOS; Ubuntu用sudo usermod -aG sudo openrig

下载并安装OpenRig二进制：

sudo -u openrig bash -c ' cd /home/openrig wget https://github.com/openrig/openrig/releases/download/v1.4.2/openrig-v1.4.2-x86_64-unknown-linux-gnu.tar.gz tar -xzf openrig-v1.4.2-x86_64-unknown-linux-gnu.tar.gz sudo mv openrig /usr/local/bin/ sudo chown root:root /usr/local/bin/openrig '

初始化配置目录（关键！很多失败源于此）：
```
sudo mkdir -p /etc/openrig /var/lib/openrig sudo chown -R openrig:openrig /etc/openrig /var/lib/openrig sudo -u openrig openrig init
```
这条openrig init命令会生成：
- /etc/openrig/config.yaml：全局配置（日志路径、消息总线端口等）
- /etc/openrig/agents.yaml：空的Agent配置模板
- /var/lib/openrig/：状态存储根目录

实操心得：openrig init必须用openrig用户执行，且/var/lib/openrig目录权限必须是openrig:openrig。我曾因用root执行init，导致后续Agent无法写入状态目录，日志里只显示模糊的Permission denied on state_dir，排查了4小时才发现是SELinux上下文问题（CentOS）——解决方案是sudo semanage fcontext -a -t var_lib_t "/var/lib/openrig(/.*)?" && sudo restorecon -Rv /var/lib/openrig。所以，严格按上述用户权限操作，能省下至少半天时间。

3.2 编写第一个Agent：行情数据爬取Agent（news-crawler）

我们以期货市场为例，编写一个从新浪财经期货频道抓取主力合约价格的Agent。注意，OpenRig不关心你用什么语言写Agent，只要它能接收标准输入、输出标准输出、按约定格式返回状态即可。

创建Agent工作目录：

sudo -u openrig mkdir -p /home/openrig/agents/news-crawler cd /home/openrig/agents/news-crawler

编写crawler.py（核心逻辑，仅展示关键部分）：

import requests import json import time import sys from datetime import datetime def get_futures_data(): # 真实项目中应加入反爬策略（headers、delay、代理池） url = "https://finance.sina.com.cn/futures/api/jsonp/quote?symbol=RB2410" try: resp = requests.get(url, timeout=10) # 解析新浪JSONP响应（去掉callback函数包裹） data = json.loads(resp.text[resp.text.find('(')+1:-1]) return { "symbol": "RB2410", "price": float(data["data"]["lastPrice"]), "change": float(data["data"]["change"]), "timestamp": datetime.now().isoformat() } except Exception as e: print(f"[ERROR] Failed to fetch RB2410: {e}", file=sys.stderr) return None if __name__ == "__main__": # OpenRig约定：Agent必须输出JSON状态到stdout # {"status": "success", "data": {...}, "timestamp": "..."} result = get_futures_data() if result: output = { "status": "success", "data": result, "timestamp": datetime.now().isoformat() } print(json.dumps(output)) else: # 失败时也必须输出JSON，status设为error print(json.dumps({ "status": "error", "error": "fetch_failed", "timestamp": datetime.now().isoformat() }))

测试Agent独立运行：

sudo -u openrig python3 crawler.py # 应输出类似：{"status": "success", "data": {"symbol": "RB2410", ...}, ...}

关键细节：OpenRig要求Agent必须以JSON格式向stdout输出状态，且包含status字段（success或error）。这是它判断Agent是否存活、是否需要重试的唯一依据。很多新手用print("done")或logging.info()，导致OpenRig永远认为Agent在“running”状态，实际早已崩溃。我见过最惨的案例：一个Agent因网络超时卡死，OpenRig连续3天尝试重启它（配置了restart: always），但每次启动后都因print("starting...")而非JSON输出，被OpenRig判定为“健康”，最终占满服务器内存——根源就是没遵守这个JSON输出契约。

3.3 配置YAML：定义Agent协作关系与持久化策略

编辑/etc/openrig/agents.yaml，填入期货信号系统的完整配置：

version: "1.2" agents: - name: market-crawler image: python:3.11-slim command: ["python3", "/home/openrig/agents/news-crawler/crawler.py"] state_dir: "/var/lib/openrig/market-crawler" env: PYTHONPATH: "/home/openrig/agents/news-crawler" resources: cpu_cores: [0,1] memory_mb: 512 triggers: - cron: "*/2 * * * *" # 每2分钟抓一次，期货盘中高频 outputs: - topic: "futures_raw" format: "json" schema: "futures_v1" - name: signal-calculator image: python:3.11-slim command: ["python3", "/home/openrig/agents/signal/calculator.py"] state_dir: "/var/lib/openrig/signal-calculator" inputs: - topic: "futures_raw" from: "market-crawler" timeout_ms: 120000 # 允许最长2分钟等待上游数据 outputs: - topic: "signal_raw" format: "json" schema: "signal_v1" - name: telegram-notifier image: python:3.11-slim command: ["python3", "/home/openrig/agents/notify/telegram.py"] state_dir: "/var/lib/openrig/telegram-notifier" inputs: - topic: "signal_raw" from: "signal-calculator" timeout_ms: 30000 env: TELEGRAM_BOT_TOKEN: "${TELEGRAM_BOT_TOKEN}" CHAT_ID: "${TELEGRAM_CHAT_ID}"

这个配置定义了三条关键协作链路：

时序链路：market-crawler按*/2 * * * *定时触发，生成futures_raw数据；
依赖链路：signal-calculator必须等待futures_raw到达才启动计算，超时120秒则报错；
安全链路：telegram-notifier的密钥通过${TELEGRAM_BOT_TOKEN}注入，不暴露在YAML中。

实操技巧：YAML中的timeout_ms不是“等待多久后放弃”，而是“等待多久后触发告警”。OpenRig会记录每次等待的耗时，如果连续3次超过阈值的80%，就会在日志中警告：“[WARN] Input 'futures_raw' from 'market-crawler' consistently delayed (avg: 112s, threshold: 120s)”，提示你检查上游Agent性能。这比单纯设个超时然后静默失败，更能暴露系统瓶颈。

3.4 启动与监控：用tmux会话看清每个Agent的“心跳”

配置完成后，执行启动命令：

sudo -u openrig openrig start all # 或启动单个：sudo -u openrig openrig start market-crawler

OpenRig会自动创建tmux会话，你可以用以下命令实时监控：

查看所有Agent状态：

sudo -u openrig openrig status # 输出示例： # NAME STATUS CPU% MEM% UPTIME LAST_OUTPUT # market-crawler running 12.3 18.7 2h15m 2024-05-21T14:22:31Z # signal-calculator running 8.1 22.4 2h14m 2024-05-21T14:22:45Z # telegram-notifier running 0.2 15.1 2h13m 2024-05-21T14:22:50Z

进入特定Agent的tmux会话（调试必备）：

sudo -u openrig tmux attach -t market-crawler # 此时你看到的就是crawler.py的实时stdout/stderr # 按 Ctrl+B, d 可detach退出，Agent继续后台运行

查看持久化状态：

ls -la /var/lib/openrig/market-crawler/ # 你会看到： # state.json.zst # 当前最新状态（压缩） # state.log # 增量变更日志 # state_20240521_142231.json.zst # 时间戳快照

独家经验：openrig status的LAST_OUTPUT时间戳，是Agent最后一次向stdout输出JSON的时间，不是进程启动时间。这意味着，如果Agent卡在某个循环里没输出，这个时间就不会更新——这是判断Agent是否“假死”的最直接指标。我在一个项目中，发现signal-calculator的LAST_OUTPUT停滞在10分钟前，进入tmux一看，它正卡在requests.get()等待一个超时的API，而那个API根本没设timeout参数。加上timeout=30后，问题立刻解决。所以，别只看STATUS: running，一定要盯LAST_OUTPUT。

4. 故障排查与高阶技巧：让OpenRig真正扛住生产压力

4.1 常见问题速查表：从“Agent不启动”到“协作链路断裂”

问题现象	可能原因	排查命令	解决方案
`openrig status`显示`STATUS: starting`但长时间不变成`running`	Agent启动脚本卡在某处，未输出首条JSON状态	`sudo -u openrig tmux attach -t <agent-name>`	检查Agent代码是否在`print(json.dumps({...}))`前有无限循环或阻塞IO；确保首条输出是合法JSON
`openrig status`显示`STATUS: error`，`LAST_OUTPUT`为空	Agent进程启动即崩溃，stdout无输出	`sudo -u openrig journalctl -u openrig -n 50 --no-pager`	查看OpenRig主进程日志，通常会记录`exec: "python3": executable file not found in $PATH`等错误；用绝对路径`/usr/bin/python3`代替`python3`
`signal-calculator`报错`Input timeout for topic 'futures_raw'`	`market-crawler`未发布数据，或发布格式不符合schema	`sudo -u openrig openrig logs market-crawler -n 20`	检查crawler.py输出是否为JSON；用`rigctl validate schema futures_v1`校验输出结构；确认`market-crawler`的`outputs.topic`与`signal-calculator`的`inputs.topic`完全一致（大小写敏感）
tmux会话中出现`Pane is dead`	Agent进程崩溃，tmux窗格自动关闭	`sudo -u openrig openrig restart <agent-name>`	在YAML中为Agent添加`restart: always`策略；检查Agent是否因内存溢出被OOM Killer杀死（`dmesg \| grep -i "killed process"`）
`openrig status`CPU%异常高（>90%）	某个Agent陷入忙循环，或tmux同步模式开启	`sudo -u openrig top -p $(pgrep -f "tmux.*<agent-name>")`	检查Agent代码是否有`while True:`无休眠；禁用tmux窗格同步（`tmux set -g synchronize-panes off`）

实操避坑：openrig logs <agent-name>默认只显示最近100行，但OpenRig的环形缓冲区实际保存2000行。要用openrig logs market-crawler -n 500查看更长历史。我曾在一个深夜故障中，发现关键错误其实在3小时前就发生了，但默认100行日志被后续正常日志覆盖了——调大-n参数后立刻定位到SSL certificate has expired错误。

4.2 高阶技巧：用tmux会话管理实现“热修复”与“灰度发布”

OpenRig的tmux底座，赋予了它超越传统编排工具的运维灵活性。以下是两个生产环境救命技巧：

技巧1：Agent热修复（Hotfix）假设market-crawler在生产中暴露出一个bug：它抓取的价格偶尔为0，导致信号计算错误。你已经修好了crawler.py，但不想重启整个协作链路（因为signal-calculator正在处理重要数据）。这时可以：

# 1. 进入market-crawler会话 sudo -u openrig tmux attach -t market-crawler # 2. 按 Ctrl+C 停止当前进程（OpenRig会检测到退出并标记为error） # 3. 在tmux中手动运行修复后的脚本 python3 /home/openrig/agents/news-crawler/crawler_fixed.py # 4. 按 Ctrl+D 退出tmux，OpenRig会自动将此会话标记为"replaced" # 下次openrig start时，会用新脚本替代旧脚本

这个过程无需停止其他Agent，signal-calculator会继续从消息总线消费数据，只是上游数据源切换了。我在一个期货项目中，用此法在30秒内修复了一个导致止损单误触发的bug，客户甚至没感知到服务中断。

技巧2：灰度发布（Canary Release）你想测试新版signal-calculator，但不敢直接替换。OpenRig支持同名Agent的多实例：

# 在agents.yaml中，为新版本添加后缀 - name: signal-calculator-v2 image: python:3.11-slim command: ["python3", "/home/openrig/agents/signal/calculator_v2.py"] state_dir: "/var/lib/openrig/signal-calculator-v2" inputs: - topic: "futures_raw" from: "market-crawler" timeout_ms: 120000 outputs: - topic: "signal_raw_v2" # 新topic # 添加权重，5%流量导给v2 weight: 5

然后修改telegram-notifier的inputs，让它同时订阅两个topic：

inputs: - topic: "signal_raw" from: "signal-calculator" weight: 95 - topic: "signal_raw_v2" from: "signal-calculator-v2" weight: 5

OpenRig的消息总线会按权重分发消息。你可以监控signal_raw_v2的输出质量，确认无误后再将权重逐步调至100%。这比K8s的Service权重或Istio的VirtualService简单直接得多。

4.3 性能调优实战：让OpenRig在4核8GB服务器上稳定跑12个Agent

OpenRig默认配置偏保守，生产环境需针对性优化。我在一台4核8GB的阿里云ECS上，成功稳定运行12个Agent（含YOLOv10图像识别），关键调优点如下：

tmux性能调优：

# 编辑 /etc/tmux.conf # 减少刷新率，降低CPU占用 set -g status-interval 30 # 关闭不必要的状态栏元素 set -g status-left "" set -g status-right "" # 禁用窗格同步（默认关闭，确认一下） set -g synchronize-panes off

OpenRig消息总线调优（/etc/openrig/config.yaml）：

message_bus: # WAL文件大小限制，避免磁盘占满 wal_max_size_mb: 100 # 内存消息队列长度，过高易OOM，过低易丢消息 queue_length: 5000 # 启用WAL压缩（ZSTD比LZ4更省空间） wal_compression: "zstd"

Agent资源硬限（YAML中）：

resources: cpu_cores: [0,1] # 绑定到物理核心，避免调度抖动 memory_mb: 1024 # 添加OOM保护 oom_score_adj: -500 # 降低被OOM Killer选中的概率

实测数据：调优前，12个Agent峰值CPU达98%，内存使用缓慢增长；调优后，CPU稳定在65%±5%，内存使用呈平缓锯齿状（因定期GC），72小时无OOM事件。最关键的是，market-crawler的抓取延迟从平均1.2秒降至0.4秒——这得益于CPU核心绑定消除了跨核调度开销。

最后一点体会：OpenRig不是银弹，它解决的是“如何让AI Agent可靠协作”，而不是“如何让AI更聪明”。我见过太多团队，花三个月搭出华丽的Agent中台，却因一个未处理的网络超时，导致整条交易信号链路中断两小时。OpenRig的价值，恰恰在于它把这种“可靠性”变成了可配置、可监控、可修复的基础设施。当你不再为“Agent怎么扛并发”焦虑，而是专注在agents.yaml里调整weight和timeout_ms时，你就真正进入了AI工程化的深水区。