1. 项目概述当 Agent 不再是单打独斗而是一支可编排的“数字特工队”OpenRig 这个名字听起来像某种工业级钻探设备但其实它指向一个更安静、更精密的方向——用纯文本定义一支 AI Agent 团队并让它们在本地终端里协同开工。我第一次看到这个项目时正卡在一个老问题上写了个数据清洗 Agent又加了个 SQL 查询 Agent再塞进一个报告生成 Agent结果三者之间靠硬编码传参、手动启停、日志对不上、出错要挨个 debug……活脱脱一场“Agent 交响乐排练现场”指挥棒一断全团跑调。OpenRig 的出现直接把这套混乱流程拉回了工程化轨道你不再写 Agent而是写一份 YAML 配置文件你不再启动服务而是敲一条openrig up命令你不再盯着三个终端窗口而是通过tmux会话统一观察整个团队的呼吸节奏。核心关键词“YAML”在这里不是装饰而是真正的契约语言——它强制你把每个 Agent 的身份name、能力tools、记忆方式memory、通信规则input/output schema、甚至失败重试策略retry_policy都白纸黑字写清楚。这不是配置文件这是团队章程。而“tmux”也不是炫技它是 OpenRig 默认的运行底座每个 Agent 占用一个独立 pane彼此隔离又共享会话上下文CtrlB 方向键就能切过去看日志CtrlB : kill-pane就能精准下线某个出问题的成员不用动整个集群。这种设计背后是对当前 Agent 开发痛点的精准打击——我们缺的不是更多模型、不是更强算力而是能让多个智能体稳定协作、可观察、可调试、可复现的轻量级编排层。它不依赖 Kubernetes不强推 Docker Compose不绑定特定云平台就守着 Linux/macOS 终端和 Python 环境用最朴素的方式解决最实际的问题。适合谁正在从单 Agent Demo 迈向多 Agent 落地的开发者、需要快速验证业务流程编排的产品经理、以及所有厌倦了“改一行代码就要重启五个服务”的技术负责人。2. 整体架构与设计逻辑为什么非得是 YAML tmux 这套组合拳2.1 拒绝过度设计从“分布式系统思维”回归“终端工作流思维”市面上不少 Agent 框架一上来就谈服务发现、消息总线、状态持久化、跨节点调度……听着很专业用起来像在搭核电站。OpenRig 的底层哲学非常务实绝大多数本地开发、POC 验证、中小规模自动化任务根本不需要分布式。你需要的是一张清晰的作战地图和一个可靠的指挥台。YAML 之所以被选为核心载体不是因为它“时髦”而是因为它天然具备三项不可替代的工程价值人类可读性即第一生产力对比 JSON 的括号嵌套和 TOML 的等号泛滥YAML 的缩进语法让“谁调用谁”、“谁传什么给谁”一目了然。比如定义一个“财务分析 Agent”调用“数据库查询 Agent”的链路只需写agents: - name: finance_analyst depends_on: [db_query] input_schema: type: object properties: period: { type: string } output_schema: type: object properties: report_pdf: { type: string }这段配置一个刚接触项目的实习生花两分钟就能看懂数据流向而等效的 JSON Schema 或 Protobuf IDL 可能需要查文档半小时。版本控制友好性即协作基石YAML 文件天生适配 Git。当你把agents.yaml提交到仓库git diff显示的不是“二进制文件已更改”而是清晰的行级差异“第47行新增了retry_policy: max_attempts: 3”“第89行将timeout_sec从 30 改为 60”。这直接解决了多 Agent 协作中最头疼的“配置漂移”问题——再也不用问“你本地跑通的版本到底和我 checkout 的分支差在哪一行”。声明式语义即安全边界YAML 本身不执行逻辑只描述状态。OpenRig 的解析器在加载时会做严格校验检查depends_on列表里的 Agent 名是否真实存在、input_schema是否与上游 Agent 的output_schema兼容、tools列表中的命令是否在 PATH 中可执行。这种“先验检查”机制把大量运行时错误如空指针、类型不匹配提前到了配置加载阶段大幅降低调试成本。提示OpenRig 并不禁止你在 YAML 中嵌入 Jinja2 模板语法如{{ env.DB_HOST }}但它默认关闭此功能。理由很实在——模板带来灵活性的同时也引入了执行环境依赖和调试复杂度。OpenRig 的设计者认为配置的确定性比动态性更重要尤其在团队协作场景下。真有环境差异化需求推荐用yq工具在 CI/CD 流程中做预处理而非在运行时解析。2.2 tmux不是“凑合用”而是“刻意选择”的运行时底座很多人看到 OpenRig 依赖 tmux第一反应是“这玩意儿太老派了吧”。恰恰相反tmux 是经过深思熟虑的战术选择。我们来拆解它不可替代的三大优势进程隔离性即稳定性保障每个 Agent 在独立的 tmux pane 中运行意味着它们拥有完全隔离的进程空间、环境变量和标准 I/O 流。一个 Agent 因内存泄漏崩溃不会影响同会话下的其他 Agent一个 Agent 执行os.system(killall python)这种危险操作也仅限于自身 pane。这种隔离粒度比单纯用subprocess.Popen启动子进程更可靠又比 Docker 容器更轻量——没有镜像构建、网络配置、存储卷挂载这些额外开销。会话持久性即调试友好性tmux 的核心价值在于detach/reattach。当你深夜跑一个耗时 2 小时的数据分析 Agent不必守着终端CtrlB D断开连接后Agent 仍在后台运行第二天早上tmux attach立刻回到原界面滚动查看完整日志。这对长周期 Agent如监控轮询、定时爬取至关重要。相比之下nohup或screen缺乏 pane 级别的精细管理能力systemd则过于重量级且调试日志分散。交互式控制即运维直觉性OpenRig 的openrig up命令本质是启动一个预设好 pane 布局的 tmux 会话。你可以用标准 tmux 快捷键实时干预CtrlB ↑/↓/←/→在 pane 间切换专注查看某个 Agent 日志CtrlB Z放大当前 pane全屏观察关键 Agent 输出CtrlB : resize-pane -U 10手动调整日志 pane 高度避免信息被截断CtrlB : send-keys curl http://localhost:8000/health Enter向特定 Agent 发送健康检查请求。这种“所见即所得”的控制感是任何 Web UI 或 CLI 监控工具都难以替代的。它把运维动作从“抽象命令”还原为“具体手势”极大降低了多 Agent 协同的决策负担。注意OpenRig 对 tmux 版本有明确要求≥3.2a。低版本 tmux 缺少pane_current_path等关键特性会导致 Agent 启动时工作目录错乱。安装时务必用brew install tmuxmacOS或sudo apt install tmuxUbuntu 22.04避免从源码编译旧版本。2.3 与主流 Agent 框架的本质分野不做“全能平台”只做“编排胶水”理解 OpenRig 的定位必须厘清它和 LangChain、LlamaIndex、AutoGen 的根本区别维度LangChain/LlamaIndexAutoGenOpenRig核心目标提供 LLM 调用、RAG、Chain 构建的 SDK实现多 Agent 对话驱动的复杂任务分解定义并启动一组职责明确、协议清晰、独立运行的 Agent 团队Agent 角色“思考单元”常需共享同一进程内存、LLM 实例“对话参与者”强依赖消息总线如 WebSocket传递上下文“服务实例”每个 Agent 是独立进程通过文件/HTTP/IPC 交换结构化数据编排方式代码内 Chain 定义SequentialChain、Orchestration 函数GroupChatManager控制发言权、ConversableAgent注册回调YAML 文件声明依赖关系、输入输出 Schema、启动参数运行时依赖Python 环境 LLM API Key同上 消息中间件可选Python tmux POSIX 兼容 Shellbash/zshOpenRig 本质上是一个“编排胶水层”。它不提供 LLM 调用封装你仍需自己写openai.ChatCompletion.create不内置 RAG 检索器你要自己集成 ChromaDB不实现对话状态机Agent 间通信靠你定义的 JSON-RPC 接口。它的价值在于当你已经有一堆功能完备的 Python 脚本db_query.py,pdf_gen.py,email_notify.pyOpenRig 能让你用 5 分钟配置把它们变成一支纪律严明、指令清晰、状态可视的团队而不是一堆散兵游勇。这种“不造轮子只拧螺丝”的思路恰恰是它能在真实项目中快速落地的关键。3. 核心细节解析与实操要点YAML 配置的每一行都在说什么3.1 YAML 结构全景从顶层agents到每个 Agent 的“身份证”OpenRig 的配置文件遵循严格的分层结构理解每一层的语义是写出健壮配置的前提。我们以一个电商售后分析场景为例逐步拆解# agents.yaml version: 1.0 # 配置格式版本目前仅支持 1.0未来可能扩展兼容性 global: timeout_sec: 120 # 全局超时所有 Agent 默认继承此值 log_level: INFO # 全局日志级别可被单个 Agent 覆盖 working_dir: ./workspaces # 所有 Agent 的默认工作目录 agents: - name: order_fetcher # Agent 唯一标识符后续所有引用均基于此 type: script # 运行类型scriptPython/Shell、httpWeb API、docker容器 path: ./scripts/fetch_orders.py # 脚本路径相对 global.working_dir args: [--days, 30] # 启动参数数组形式 env: DB_URL: postgresql://user:passdb:5432/ecommerce API_KEY: {{ secrets.ORDER_API_KEY }} # 支持 secrets 引用 input_schema: null # 此 Agent 无上游依赖不接收输入 output_schema: type: array items: type: object properties: order_id: { type: string } status: { type: string } amount: { type: number } - name: refund_analyzer type: script path: ./scripts/analyze_refunds.py depends_on: [order_fetcher] # 关键声明依赖OpenRig 保证 order_fetcher 先启动 input_schema: # 必须与 order_fetcher 的 output_schema 兼容 type: array items: { $ref: #/agents/0/output_schema/items } # 引用前一个 Agent 的 schema output_schema: type: object properties: high_risk_count: { type: integer } avg_refund_rate: { type: number } - name: report_generator type: http url: http://localhost:8001/generate method: POST depends_on: [refund_analyzer] input_schema: type: object properties: analysis_result: { $ref: #/agents/1/output_schema } output_schema: type: object properties: report_url: { type: string }关键细节解读depends_on不是简单的启动顺序而是数据依赖图。OpenRig 启动时会构建一个有向无环图DAG确保order_fetcher的输出文件默认为./workspaces/order_fetcher_output.json生成后refund_analyzer才开始读取。如果order_fetcher失败整个 DAG 会中断refund_analyzer不会启动。input_schema和output_schema的$ref引用是 OpenRig 的“类型契约”机制。它强制上下游 Agent 的数据结构保持一致。如果你修改order_fetcher的输出添加了customer_name字段但refund_analyzer的input_schema未同步更新OpenRig 在openrig up阶段就会报错“Schema mismatch: field customer_name not allowed in input”。这种静态检查把运行时的KeyError提前到了配置验证阶段。env中的{{ secrets.XXX }}语法指向secrets.yaml文件同目录。该文件永不提交到 Git内容示例ORDER_API_KEY: sk-xxx SMTP_PASSWORD: app-specific-passwordOpenRig 加载时会自动合并既保证敏感信息不泄露又避免硬编码。3.2 Agent 类型详解script / http / docker 的适用场景与陷阱OpenRig 支持三种 Agent 类型选择错误会导致整个团队“瘫痪”。以下是实战经验总结type: script—— 你的主力部队但需严守“无状态”铁律这是最常用类型适用于 Python、Bash、Node.js 等脚本。致命陷阱脚本必须是幂等的、无副作用的。例如一个send_email.pyAgent如果每次运行都真实发送邮件那么openrig restart重启整个团队就会导致重复通知。正确做法是脚本只负责生成待发送的邮件 JSON 文件如./workspaces/email_draft.json由另一个专门的email_senderAgent也是 script 类型读取该文件并执行发送。OpenRig 本身不提供“去重”或“事务”能力它假设每个 script Agent 是一个纯粹的函数。type: http—— 连接外部世界的桥梁但必须自备健康检查当你需要调用已有 Web 服务如内部报表 API、第三方天气接口时使用。url和method是必需字段。关键配置health_check。OpenRig 在启动依赖此 Agent 的下游 Agent 前会先 GEThealth_check.url期望返回 HTTP 200。例如- name: weather_api type: http url: https://api.example.com/forecast health_check: url: https://api.example.com/health timeout_sec: 10如果weather_api的健康检查失败openrig up会阻塞直到超时或人工介入。这避免了下游 Agent 因上游服务不可用而陷入无限重试。type: docker—— 隔离性最强但启动延迟最高适用于需要完整环境隔离的 Agent如运行特定 CUDA 版本的 YOLOv10 推理服务。配置示例- name: yolo_inference type: docker image: yolov10:latest ports: [5000:5000] volumes: [./data:/app/data] command: [python, inference.py, --model, yolov10s.pt]性能警告Docker Agent 启动比 script 慢 3-5 秒。在 DAG 中如果它位于关键路径如depends_on链的起点会显著拖慢整个团队启动时间。建议仅对真正需要环境隔离的 Agent 使用普通脚本优先用script类型。3.3 tmux 集成深度如何定制你的“数字作战室”OpenRig 默认的 tmux 布局是垂直分割每个 Agent 一个 pane但你可以通过.openrig.yaml项目根目录进行精细化控制# .openrig.yaml tmux: session_name: ecommerce-analytics # 自定义会话名便于 tmux list-sessions 查看 layout: even-horizontal # 布局模式even-vertical, even-horizontal, main-horizontal pane_options: - name: order_fetcher height: 20 # 固定高度避免日志刷屏 start_command: cd ./workspaces tail -f order_fetcher.log # 启动后自动执行命令 - name: refund_analyzer width: 80 # 固定宽度 default_shell: /bin/zsh # 指定 shell确保环境变量一致实操心得start_command是调试利器。对于日志密集型 Agent如实时爬虫设置tail -f *.log能让你一进入 pane 就看到最新输出无需手动cat。layout: main-horizontal会创建一个主 pane占 70% 高度和若干小 pane各占 30% 高度特别适合“一个核心 Agent 多个辅助 Agent”的场景如主 pane 显示report_generator的最终 PDF 生成进度小 pane 分别监控order_fetcher和refund_analyzer的原始数据流。default_shell必须与你的登录 shell 一致。如果系统默认是 bash但你.zshrc里设置了export PATH...而 OpenRig 用 bash 启动就会找不到poetry或conda环境。统一 shell 是避免“本地能跑OpenRig 启动失败”的关键。4. 实操过程与核心环节实现从零到一支可运行的 Agent 团队4.1 环境准备三步建立纯净的 OpenRig 基础设施Step 1安装 OpenRig 与依赖5 分钟OpenRig 是 Python 包但依赖 tmux 和 POSIX 工具链。按顺序执行# 1. 确保 Python 3.9OpenRig 使用 typing.Union 等新特性 python --version # 应输出 3.9 # 2. 安装 tmuxmacOS brew install tmux # 3. 安装 OpenRig推荐使用 pipx 隔离环境避免污染全局 Python pip install pipx pipx install openrig # 4. 验证安装 openrig --version # 应输出 v0.8.2 或更高 tmux -V # 应输出 tmux 3.2a 或更高提示不要用pip install openrig全局安装。OpenRig 会随 Python 版本升级而更新全局安装可能导致openrig up命令与新版本配置不兼容。pipx为每个 CLI 工具创建独立虚拟环境是管理 Python CLI 工具的最佳实践。Step 2初始化项目骨架2 分钟在项目根目录运行openrig init它会生成agents.yaml空模板已包含version和global段secrets.yaml空模板已添加.gitignore规则.openrig.yaml空配置文件scripts/目录存放 Agent 脚本的默认位置Step 3创建第一个 Agent 脚本10 分钟在scripts/下新建hello_world.py#!/usr/bin/env python3 Hello World Agent - 示例打印问候语并写入输出文件 OpenRig 会将此脚本的 stdout 重定向到 ./workspaces/hello_world.log 并将脚本退出码视为执行状态0成功非0失败 import json import sys from pathlib import Path # OpenRig 会设置 WORKSPACE_DIR 环境变量指向 ./workspaces workspace Path(sys.argv[1]) if len(sys.argv) 1 else Path(./workspaces) output_file workspace / hello_output.json # 生成输出数据必须符合 agents.yaml 中定义的 output_schema result { greeting: Hello from OpenRig!, timestamp: __import__(datetime).datetime.now().isoformat() } # 写入 JSON 文件OpenRig 依赖此文件作为下游输入 output_file.write_text(json.dumps(result, indent2)) # 打印到 stdout会被重定向到日志 print(f[INFO] Hello World Agent executed. Output written to {output_file}) # 退出码 0 表示成功 sys.exit(0)赋予执行权限chmod x scripts/hello_world.py4.2 编写并验证 YAML 配置15 分钟编辑agents.yaml填入以下内容version: 1.0 global: timeout_sec: 30 log_level: DEBUG working_dir: ./workspaces agents: - name: hello_world type: script path: ./scripts/hello_world.py input_schema: null output_schema: type: object properties: greeting: { type: string } timestamp: { type: string }关键验证步骤运行openrig validate检查 YAML 语法、schema 引用、路径是否存在。运行openrig dry-run模拟启动流程输出将要创建的 tmux pane、执行的命令、预期的文件路径不实际启动任何进程。这是防止配置错误导致环境混乱的黄金步骤。查看dry-run输出确认path: ./scripts/hello_world.py被解析为绝对路径且working_dir正确拼接。4.3 启动、观察与调试一条命令背后的完整生命周期Step 1启动团队openrig up你会看到终端瞬间切换到一个 tmux 会话只有一个 pane标题显示hello_world并滚动输出[INFO] Hello World Agent executed...。此时./workspaces/hello_output.json已生成。Step 2实时观察CtrlB ↑切换到hello_worldpaneCtrlB Z放大此 pane全屏查看日志CtrlB D分离会话Agent 继续后台运行Step 3触发重启与状态检查# 重新附加会话 tmux attach # 查看所有 Agent 状态OpenRig 提供的便捷命令 openrig status # 输出示例 # hello_world | RUNNING | PID: 12345 | Uptime: 42s | Log: ./workspaces/hello_world.log # 重启特定 Agent不中断其他 Agent openrig restart hello_world # 停止整个团队 openrig downStep 4深入调试技巧日志定位每个 Agent 的日志默认写入./workspaces/agent_name.log。用tail -f ./workspaces/hello_world.log实时追踪。输出文件检查cat ./workspaces/hello_output.json确认数据格式符合output_schema。进程诊断ps aux | grep hello_world查看实际运行的 Python 进程及其参数。环境变量验证在hello_world.py中临时添加print(dict(os.environ))然后openrig restart hello_world检查WORKSPACE_DIR等关键变量是否注入。4.4 扩展为多 Agent 团队电商订单分析实战现在我们将hello_world升级为真实的电商分析流水线。创建三个脚本scripts/fetch_orders.py模拟从数据库获取最近 7 天订单scripts/calculate_stats.py计算退款率、平均订单金额scripts/send_report.py生成 Markdown 报告并邮件发送对应的agents.yamlversion: 1.0 global: timeout_sec: 300 working_dir: ./workspaces agents: - name: fetch_orders type: script path: ./scripts/fetch_orders.py args: [--days, 7] output_schema: type: array items: type: object properties: order_id: { type: string } total_amount: { type: number } refund_status: { type: string } # pending, completed, failed - name: calculate_stats type: script path: ./scripts/calculate_stats.py depends_on: [fetch_orders] input_schema: type: array items: { $ref: #/agents/0/output_schema/items } output_schema: type: object properties: refund_rate: { type: number } avg_order_value: { type: number } total_orders: { type: integer } - name: send_report type: script path: ./scripts/send_report.py depends_on: [calculate_stats] input_schema: type: object properties: stats: { $ref: #/agents/1/output_schema } output_schema: type: object properties: report_sent: { type: boolean } email_id: { type: string }关键实操点fetch_orders.py必须生成./workspaces/fetch_orders_output.json内容为订单数组。calculate_stats.py读取该文件计算指标写入./workspaces/calculate_stats_output.json。send_report.py读取后者生成报告发送邮件写入./workspaces/send_report_output.json。OpenRig 自动处理文件路径传递你只需确保每个脚本的输入/输出文件名与output_schema的name字段默认为agent_name_output.json一致。运行openrig up你会看到 tmux 自动创建三个垂直 pane依次启动。fetch_orderspane 先输出日志完成后calculate_statspane 开始滚动最后send_reportpane 显示发送成功。整个流程你只敲了一条命令。5. 常见问题与排查技巧实录那些踩过的坑比文档还管用5.1 YAML 配置类问题看似简单实则最易栽跟头问题现象根本原因排查与解决openrig up报错KeyError: agentsYAML 文件为空或agents:后未正确缩进用yamllint agents.yaml检查语法确保agents:下方至少有一个- name: xxx且缩进为 2 个空格openrig validate通过但openrig up启动后 Agent 立即退出path指向的脚本不存在或无执行权限运行ls -l ./scripts/fetch_orders.py确认有x权限openrig dry-run会显示完整执行命令复制粘贴到终端手动执行看真实错误depends_on声明了 Agent A但 Agent B 启动时报错No such file or directory: A_output.jsonAgent A 执行失败退出码非 0未生成输出文件检查./workspaces/A.log看是否有异常堆栈确保 Agent A 脚本末尾sys.exit(0)OpenRig 不会重试失败的 Agent需人工修复后openrig restart Ainput_schema使用$ref报错JSON reference not found$ref路径错误或引用的 Agent 在列表中位置变动$ref必须用#/agents/N/output_schema形式N 从 0 开始计数移动 Agent 顺序后必须同步更新所有$ref实操心得永远先跑openrig dry-run再跑openrig up。dry-run输出的命令就是 OpenRig 实际要执行的。把它复制出来在终端里手动执行一遍90% 的路径、权限、环境变量问题都能当场暴露。这是最高效、最直接的调试法。5.2 tmux 运行时问题终端里的“幽灵故障”问题现象根本原因排查与解决openrig up后看不到 tmux 会话终端卡住tmux 会话已创建但被后台运行或openrig进程被信号终止运行tmux list-sessions找到会话名如openrig-12345然后tmux attach -t openrig-12345检查~/.tmux.conf是否有冲突配置如set -g default-shell某个 Agent pane 里显示command not found: pythontmux 启动的 shell 未加载你的 Python 环境如 conda/poetry在.openrig.yaml中设置default_shell: /bin/zsh并确保该 shell 的 rc 文件.zshrc中正确初始化了环境或在 Agent 脚本开头显式激活source ~/miniconda3/bin/activate python ...openrig status显示RUNNING但ps aux找不到对应进程Agent 进程已崩溃但 tmux pane 未自动关闭运行tmux list-panes -a -F #{pane_pid} #{pane_current_path}找到对应 pane 的 PID用ps -p PID确认若 PID 不存在说明进程已死openrig restart agent_name会重建 pane多个openrig up命令并发执行导致 tmux 会话混乱OpenRig 默认会话名是随机的但并发时可能冲突在.openrig.yaml中固定session_name: my-project避免命名冲突或使用openrig down清理后再启动5.3 Agent 脚本开发类问题让每个成员都“守规矩”问题现象根本原因排查与解决Agent 脚本执行成功但下游 Agent 报错JSON decode error脚本输出了非 JSON 内容到 stdout如调试print()污染了日志文件导致 OpenRig 无法解析输出文件严格约定Agent 脚本的 stdout 只用于日志所有结构化输出必须写入./workspaces/name_output.json禁用print()输出 JSON用logging模块记录日志openrig restart后Agent 读取到旧的输出文件OpenRig 不会自动清理上一次的输出文件脚本需自行处理在脚本开头添加output_file Path(...); output_file.unlink(missing_okTrue)或在global中设置cleanup_on_start: true需 OpenRig v0.8.3HTTP Agent 调用超时但openrig status显示RUNNINGhttp类型 Agent 的超时由timeout_sec控制但status命令只检查进程是否存在不检查 HTTP 请求状态在agents.yaml中为httpAgent 设置health_check并增加retry_policy或在脚本中实现重试逻辑Docker Agent 启动后立即退出docker logs显示exec: python: executable file not found in $PATHDocker 镜像内未安装 Python或command路径错误运行docker run -it your-image /bin/sh进入容器手动执行which python确保command中的路径如python inference.py在容器内有效最后一个独家技巧为每个 Agent 脚本添加--debug参数。在args中加入[--debug]并在脚本中解析import argparse parser argparse.ArgumentParser() parser.add_argument(--debug, actionstore_true) args parser.parse_args() if args.debug: import pdb; pdb.set_trace() # 启动 pdb 调试器这样openrig restart --debug agent_name就能直接在 tmux pane 中进入交互式调试比print()日志高效十倍。这是我在调试一个复杂的 SQL 生成 Agent 时熬了三个通宵后悟出的救命招数。我在实际使用 OpenRig 的半年里从最初用它跑通一个三 Agent 的数据清洗流水线到现在管理着一个包含 12 个 Agent
1. 项目概述当 Agent 不再是单打独斗而是一支可编排的“数字特工队”OpenRig 这个名字听起来像某种工业级钻探设备但其实它指向一个更安静、更精密的方向——用纯文本定义一支 AI Agent 团队并让它们在本地终端里协同开工。我第一次看到这个项目时正卡在一个老问题上写了个数据清洗 Agent又加了个 SQL 查询 Agent再塞进一个报告生成 Agent结果三者之间靠硬编码传参、手动启停、日志对不上、出错要挨个 debug……活脱脱一场“Agent 交响乐排练现场”指挥棒一断全团跑调。OpenRig 的出现直接把这套混乱流程拉回了工程化轨道你不再写 Agent而是写一份 YAML 配置文件你不再启动服务而是敲一条openrig up命令你不再盯着三个终端窗口而是通过tmux会话统一观察整个团队的呼吸节奏。核心关键词“YAML”在这里不是装饰而是真正的契约语言——它强制你把每个 Agent 的身份name、能力tools、记忆方式memory、通信规则input/output schema、甚至失败重试策略retry_policy都白纸黑字写清楚。这不是配置文件这是团队章程。而“tmux”也不是炫技它是 OpenRig 默认的运行底座每个 Agent 占用一个独立 pane彼此隔离又共享会话上下文CtrlB 方向键就能切过去看日志CtrlB : kill-pane就能精准下线某个出问题的成员不用动整个集群。这种设计背后是对当前 Agent 开发痛点的精准打击——我们缺的不是更多模型、不是更强算力而是能让多个智能体稳定协作、可观察、可调试、可复现的轻量级编排层。它不依赖 Kubernetes不强推 Docker Compose不绑定特定云平台就守着 Linux/macOS 终端和 Python 环境用最朴素的方式解决最实际的问题。适合谁正在从单 Agent Demo 迈向多 Agent 落地的开发者、需要快速验证业务流程编排的产品经理、以及所有厌倦了“改一行代码就要重启五个服务”的技术负责人。2. 整体架构与设计逻辑为什么非得是 YAML tmux 这套组合拳2.1 拒绝过度设计从“分布式系统思维”回归“终端工作流思维”市面上不少 Agent 框架一上来就谈服务发现、消息总线、状态持久化、跨节点调度……听着很专业用起来像在搭核电站。OpenRig 的底层哲学非常务实绝大多数本地开发、POC 验证、中小规模自动化任务根本不需要分布式。你需要的是一张清晰的作战地图和一个可靠的指挥台。YAML 之所以被选为核心载体不是因为它“时髦”而是因为它天然具备三项不可替代的工程价值人类可读性即第一生产力对比 JSON 的括号嵌套和 TOML 的等号泛滥YAML 的缩进语法让“谁调用谁”、“谁传什么给谁”一目了然。比如定义一个“财务分析 Agent”调用“数据库查询 Agent”的链路只需写agents: - name: finance_analyst depends_on: [db_query] input_schema: type: object properties: period: { type: string } output_schema: type: object properties: report_pdf: { type: string }这段配置一个刚接触项目的实习生花两分钟就能看懂数据流向而等效的 JSON Schema 或 Protobuf IDL 可能需要查文档半小时。版本控制友好性即协作基石YAML 文件天生适配 Git。当你把agents.yaml提交到仓库git diff显示的不是“二进制文件已更改”而是清晰的行级差异“第47行新增了retry_policy: max_attempts: 3”“第89行将timeout_sec从 30 改为 60”。这直接解决了多 Agent 协作中最头疼的“配置漂移”问题——再也不用问“你本地跑通的版本到底和我 checkout 的分支差在哪一行”。声明式语义即安全边界YAML 本身不执行逻辑只描述状态。OpenRig 的解析器在加载时会做严格校验检查depends_on列表里的 Agent 名是否真实存在、input_schema是否与上游 Agent 的output_schema兼容、tools列表中的命令是否在 PATH 中可执行。这种“先验检查”机制把大量运行时错误如空指针、类型不匹配提前到了配置加载阶段大幅降低调试成本。提示OpenRig 并不禁止你在 YAML 中嵌入 Jinja2 模板语法如{{ env.DB_HOST }}但它默认关闭此功能。理由很实在——模板带来灵活性的同时也引入了执行环境依赖和调试复杂度。OpenRig 的设计者认为配置的确定性比动态性更重要尤其在团队协作场景下。真有环境差异化需求推荐用yq工具在 CI/CD 流程中做预处理而非在运行时解析。2.2 tmux不是“凑合用”而是“刻意选择”的运行时底座很多人看到 OpenRig 依赖 tmux第一反应是“这玩意儿太老派了吧”。恰恰相反tmux 是经过深思熟虑的战术选择。我们来拆解它不可替代的三大优势进程隔离性即稳定性保障每个 Agent 在独立的 tmux pane 中运行意味着它们拥有完全隔离的进程空间、环境变量和标准 I/O 流。一个 Agent 因内存泄漏崩溃不会影响同会话下的其他 Agent一个 Agent 执行os.system(killall python)这种危险操作也仅限于自身 pane。这种隔离粒度比单纯用subprocess.Popen启动子进程更可靠又比 Docker 容器更轻量——没有镜像构建、网络配置、存储卷挂载这些额外开销。会话持久性即调试友好性tmux 的核心价值在于detach/reattach。当你深夜跑一个耗时 2 小时的数据分析 Agent不必守着终端CtrlB D断开连接后Agent 仍在后台运行第二天早上tmux attach立刻回到原界面滚动查看完整日志。这对长周期 Agent如监控轮询、定时爬取至关重要。相比之下nohup或screen缺乏 pane 级别的精细管理能力systemd则过于重量级且调试日志分散。交互式控制即运维直觉性OpenRig 的openrig up命令本质是启动一个预设好 pane 布局的 tmux 会话。你可以用标准 tmux 快捷键实时干预CtrlB ↑/↓/←/→在 pane 间切换专注查看某个 Agent 日志CtrlB Z放大当前 pane全屏观察关键 Agent 输出CtrlB : resize-pane -U 10手动调整日志 pane 高度避免信息被截断CtrlB : send-keys curl http://localhost:8000/health Enter向特定 Agent 发送健康检查请求。这种“所见即所得”的控制感是任何 Web UI 或 CLI 监控工具都难以替代的。它把运维动作从“抽象命令”还原为“具体手势”极大降低了多 Agent 协同的决策负担。注意OpenRig 对 tmux 版本有明确要求≥3.2a。低版本 tmux 缺少pane_current_path等关键特性会导致 Agent 启动时工作目录错乱。安装时务必用brew install tmuxmacOS或sudo apt install tmuxUbuntu 22.04避免从源码编译旧版本。2.3 与主流 Agent 框架的本质分野不做“全能平台”只做“编排胶水”理解 OpenRig 的定位必须厘清它和 LangChain、LlamaIndex、AutoGen 的根本区别维度LangChain/LlamaIndexAutoGenOpenRig核心目标提供 LLM 调用、RAG、Chain 构建的 SDK实现多 Agent 对话驱动的复杂任务分解定义并启动一组职责明确、协议清晰、独立运行的 Agent 团队Agent 角色“思考单元”常需共享同一进程内存、LLM 实例“对话参与者”强依赖消息总线如 WebSocket传递上下文“服务实例”每个 Agent 是独立进程通过文件/HTTP/IPC 交换结构化数据编排方式代码内 Chain 定义SequentialChain、Orchestration 函数GroupChatManager控制发言权、ConversableAgent注册回调YAML 文件声明依赖关系、输入输出 Schema、启动参数运行时依赖Python 环境 LLM API Key同上 消息中间件可选Python tmux POSIX 兼容 Shellbash/zshOpenRig 本质上是一个“编排胶水层”。它不提供 LLM 调用封装你仍需自己写openai.ChatCompletion.create不内置 RAG 检索器你要自己集成 ChromaDB不实现对话状态机Agent 间通信靠你定义的 JSON-RPC 接口。它的价值在于当你已经有一堆功能完备的 Python 脚本db_query.py,pdf_gen.py,email_notify.pyOpenRig 能让你用 5 分钟配置把它们变成一支纪律严明、指令清晰、状态可视的团队而不是一堆散兵游勇。这种“不造轮子只拧螺丝”的思路恰恰是它能在真实项目中快速落地的关键。3. 核心细节解析与实操要点YAML 配置的每一行都在说什么3.1 YAML 结构全景从顶层agents到每个 Agent 的“身份证”OpenRig 的配置文件遵循严格的分层结构理解每一层的语义是写出健壮配置的前提。我们以一个电商售后分析场景为例逐步拆解# agents.yaml version: 1.0 # 配置格式版本目前仅支持 1.0未来可能扩展兼容性 global: timeout_sec: 120 # 全局超时所有 Agent 默认继承此值 log_level: INFO # 全局日志级别可被单个 Agent 覆盖 working_dir: ./workspaces # 所有 Agent 的默认工作目录 agents: - name: order_fetcher # Agent 唯一标识符后续所有引用均基于此 type: script # 运行类型scriptPython/Shell、httpWeb API、docker容器 path: ./scripts/fetch_orders.py # 脚本路径相对 global.working_dir args: [--days, 30] # 启动参数数组形式 env: DB_URL: postgresql://user:passdb:5432/ecommerce API_KEY: {{ secrets.ORDER_API_KEY }} # 支持 secrets 引用 input_schema: null # 此 Agent 无上游依赖不接收输入 output_schema: type: array items: type: object properties: order_id: { type: string } status: { type: string } amount: { type: number } - name: refund_analyzer type: script path: ./scripts/analyze_refunds.py depends_on: [order_fetcher] # 关键声明依赖OpenRig 保证 order_fetcher 先启动 input_schema: # 必须与 order_fetcher 的 output_schema 兼容 type: array items: { $ref: #/agents/0/output_schema/items } # 引用前一个 Agent 的 schema output_schema: type: object properties: high_risk_count: { type: integer } avg_refund_rate: { type: number } - name: report_generator type: http url: http://localhost:8001/generate method: POST depends_on: [refund_analyzer] input_schema: type: object properties: analysis_result: { $ref: #/agents/1/output_schema } output_schema: type: object properties: report_url: { type: string }关键细节解读depends_on不是简单的启动顺序而是数据依赖图。OpenRig 启动时会构建一个有向无环图DAG确保order_fetcher的输出文件默认为./workspaces/order_fetcher_output.json生成后refund_analyzer才开始读取。如果order_fetcher失败整个 DAG 会中断refund_analyzer不会启动。input_schema和output_schema的$ref引用是 OpenRig 的“类型契约”机制。它强制上下游 Agent 的数据结构保持一致。如果你修改order_fetcher的输出添加了customer_name字段但refund_analyzer的input_schema未同步更新OpenRig 在openrig up阶段就会报错“Schema mismatch: field customer_name not allowed in input”。这种静态检查把运行时的KeyError提前到了配置验证阶段。env中的{{ secrets.XXX }}语法指向secrets.yaml文件同目录。该文件永不提交到 Git内容示例ORDER_API_KEY: sk-xxx SMTP_PASSWORD: app-specific-passwordOpenRig 加载时会自动合并既保证敏感信息不泄露又避免硬编码。3.2 Agent 类型详解script / http / docker 的适用场景与陷阱OpenRig 支持三种 Agent 类型选择错误会导致整个团队“瘫痪”。以下是实战经验总结type: script—— 你的主力部队但需严守“无状态”铁律这是最常用类型适用于 Python、Bash、Node.js 等脚本。致命陷阱脚本必须是幂等的、无副作用的。例如一个send_email.pyAgent如果每次运行都真实发送邮件那么openrig restart重启整个团队就会导致重复通知。正确做法是脚本只负责生成待发送的邮件 JSON 文件如./workspaces/email_draft.json由另一个专门的email_senderAgent也是 script 类型读取该文件并执行发送。OpenRig 本身不提供“去重”或“事务”能力它假设每个 script Agent 是一个纯粹的函数。type: http—— 连接外部世界的桥梁但必须自备健康检查当你需要调用已有 Web 服务如内部报表 API、第三方天气接口时使用。url和method是必需字段。关键配置health_check。OpenRig 在启动依赖此 Agent 的下游 Agent 前会先 GEThealth_check.url期望返回 HTTP 200。例如- name: weather_api type: http url: https://api.example.com/forecast health_check: url: https://api.example.com/health timeout_sec: 10如果weather_api的健康检查失败openrig up会阻塞直到超时或人工介入。这避免了下游 Agent 因上游服务不可用而陷入无限重试。type: docker—— 隔离性最强但启动延迟最高适用于需要完整环境隔离的 Agent如运行特定 CUDA 版本的 YOLOv10 推理服务。配置示例- name: yolo_inference type: docker image: yolov10:latest ports: [5000:5000] volumes: [./data:/app/data] command: [python, inference.py, --model, yolov10s.pt]性能警告Docker Agent 启动比 script 慢 3-5 秒。在 DAG 中如果它位于关键路径如depends_on链的起点会显著拖慢整个团队启动时间。建议仅对真正需要环境隔离的 Agent 使用普通脚本优先用script类型。3.3 tmux 集成深度如何定制你的“数字作战室”OpenRig 默认的 tmux 布局是垂直分割每个 Agent 一个 pane但你可以通过.openrig.yaml项目根目录进行精细化控制# .openrig.yaml tmux: session_name: ecommerce-analytics # 自定义会话名便于 tmux list-sessions 查看 layout: even-horizontal # 布局模式even-vertical, even-horizontal, main-horizontal pane_options: - name: order_fetcher height: 20 # 固定高度避免日志刷屏 start_command: cd ./workspaces tail -f order_fetcher.log # 启动后自动执行命令 - name: refund_analyzer width: 80 # 固定宽度 default_shell: /bin/zsh # 指定 shell确保环境变量一致实操心得start_command是调试利器。对于日志密集型 Agent如实时爬虫设置tail -f *.log能让你一进入 pane 就看到最新输出无需手动cat。layout: main-horizontal会创建一个主 pane占 70% 高度和若干小 pane各占 30% 高度特别适合“一个核心 Agent 多个辅助 Agent”的场景如主 pane 显示report_generator的最终 PDF 生成进度小 pane 分别监控order_fetcher和refund_analyzer的原始数据流。default_shell必须与你的登录 shell 一致。如果系统默认是 bash但你.zshrc里设置了export PATH...而 OpenRig 用 bash 启动就会找不到poetry或conda环境。统一 shell 是避免“本地能跑OpenRig 启动失败”的关键。4. 实操过程与核心环节实现从零到一支可运行的 Agent 团队4.1 环境准备三步建立纯净的 OpenRig 基础设施Step 1安装 OpenRig 与依赖5 分钟OpenRig 是 Python 包但依赖 tmux 和 POSIX 工具链。按顺序执行# 1. 确保 Python 3.9OpenRig 使用 typing.Union 等新特性 python --version # 应输出 3.9 # 2. 安装 tmuxmacOS brew install tmux # 3. 安装 OpenRig推荐使用 pipx 隔离环境避免污染全局 Python pip install pipx pipx install openrig # 4. 验证安装 openrig --version # 应输出 v0.8.2 或更高 tmux -V # 应输出 tmux 3.2a 或更高提示不要用pip install openrig全局安装。OpenRig 会随 Python 版本升级而更新全局安装可能导致openrig up命令与新版本配置不兼容。pipx为每个 CLI 工具创建独立虚拟环境是管理 Python CLI 工具的最佳实践。Step 2初始化项目骨架2 分钟在项目根目录运行openrig init它会生成agents.yaml空模板已包含version和global段secrets.yaml空模板已添加.gitignore规则.openrig.yaml空配置文件scripts/目录存放 Agent 脚本的默认位置Step 3创建第一个 Agent 脚本10 分钟在scripts/下新建hello_world.py#!/usr/bin/env python3 Hello World Agent - 示例打印问候语并写入输出文件 OpenRig 会将此脚本的 stdout 重定向到 ./workspaces/hello_world.log 并将脚本退出码视为执行状态0成功非0失败 import json import sys from pathlib import Path # OpenRig 会设置 WORKSPACE_DIR 环境变量指向 ./workspaces workspace Path(sys.argv[1]) if len(sys.argv) 1 else Path(./workspaces) output_file workspace / hello_output.json # 生成输出数据必须符合 agents.yaml 中定义的 output_schema result { greeting: Hello from OpenRig!, timestamp: __import__(datetime).datetime.now().isoformat() } # 写入 JSON 文件OpenRig 依赖此文件作为下游输入 output_file.write_text(json.dumps(result, indent2)) # 打印到 stdout会被重定向到日志 print(f[INFO] Hello World Agent executed. Output written to {output_file}) # 退出码 0 表示成功 sys.exit(0)赋予执行权限chmod x scripts/hello_world.py4.2 编写并验证 YAML 配置15 分钟编辑agents.yaml填入以下内容version: 1.0 global: timeout_sec: 30 log_level: DEBUG working_dir: ./workspaces agents: - name: hello_world type: script path: ./scripts/hello_world.py input_schema: null output_schema: type: object properties: greeting: { type: string } timestamp: { type: string }关键验证步骤运行openrig validate检查 YAML 语法、schema 引用、路径是否存在。运行openrig dry-run模拟启动流程输出将要创建的 tmux pane、执行的命令、预期的文件路径不实际启动任何进程。这是防止配置错误导致环境混乱的黄金步骤。查看dry-run输出确认path: ./scripts/hello_world.py被解析为绝对路径且working_dir正确拼接。4.3 启动、观察与调试一条命令背后的完整生命周期Step 1启动团队openrig up你会看到终端瞬间切换到一个 tmux 会话只有一个 pane标题显示hello_world并滚动输出[INFO] Hello World Agent executed...。此时./workspaces/hello_output.json已生成。Step 2实时观察CtrlB ↑切换到hello_worldpaneCtrlB Z放大此 pane全屏查看日志CtrlB D分离会话Agent 继续后台运行Step 3触发重启与状态检查# 重新附加会话 tmux attach # 查看所有 Agent 状态OpenRig 提供的便捷命令 openrig status # 输出示例 # hello_world | RUNNING | PID: 12345 | Uptime: 42s | Log: ./workspaces/hello_world.log # 重启特定 Agent不中断其他 Agent openrig restart hello_world # 停止整个团队 openrig downStep 4深入调试技巧日志定位每个 Agent 的日志默认写入./workspaces/agent_name.log。用tail -f ./workspaces/hello_world.log实时追踪。输出文件检查cat ./workspaces/hello_output.json确认数据格式符合output_schema。进程诊断ps aux | grep hello_world查看实际运行的 Python 进程及其参数。环境变量验证在hello_world.py中临时添加print(dict(os.environ))然后openrig restart hello_world检查WORKSPACE_DIR等关键变量是否注入。4.4 扩展为多 Agent 团队电商订单分析实战现在我们将hello_world升级为真实的电商分析流水线。创建三个脚本scripts/fetch_orders.py模拟从数据库获取最近 7 天订单scripts/calculate_stats.py计算退款率、平均订单金额scripts/send_report.py生成 Markdown 报告并邮件发送对应的agents.yamlversion: 1.0 global: timeout_sec: 300 working_dir: ./workspaces agents: - name: fetch_orders type: script path: ./scripts/fetch_orders.py args: [--days, 7] output_schema: type: array items: type: object properties: order_id: { type: string } total_amount: { type: number } refund_status: { type: string } # pending, completed, failed - name: calculate_stats type: script path: ./scripts/calculate_stats.py depends_on: [fetch_orders] input_schema: type: array items: { $ref: #/agents/0/output_schema/items } output_schema: type: object properties: refund_rate: { type: number } avg_order_value: { type: number } total_orders: { type: integer } - name: send_report type: script path: ./scripts/send_report.py depends_on: [calculate_stats] input_schema: type: object properties: stats: { $ref: #/agents/1/output_schema } output_schema: type: object properties: report_sent: { type: boolean } email_id: { type: string }关键实操点fetch_orders.py必须生成./workspaces/fetch_orders_output.json内容为订单数组。calculate_stats.py读取该文件计算指标写入./workspaces/calculate_stats_output.json。send_report.py读取后者生成报告发送邮件写入./workspaces/send_report_output.json。OpenRig 自动处理文件路径传递你只需确保每个脚本的输入/输出文件名与output_schema的name字段默认为agent_name_output.json一致。运行openrig up你会看到 tmux 自动创建三个垂直 pane依次启动。fetch_orderspane 先输出日志完成后calculate_statspane 开始滚动最后send_reportpane 显示发送成功。整个流程你只敲了一条命令。5. 常见问题与排查技巧实录那些踩过的坑比文档还管用5.1 YAML 配置类问题看似简单实则最易栽跟头问题现象根本原因排查与解决openrig up报错KeyError: agentsYAML 文件为空或agents:后未正确缩进用yamllint agents.yaml检查语法确保agents:下方至少有一个- name: xxx且缩进为 2 个空格openrig validate通过但openrig up启动后 Agent 立即退出path指向的脚本不存在或无执行权限运行ls -l ./scripts/fetch_orders.py确认有x权限openrig dry-run会显示完整执行命令复制粘贴到终端手动执行看真实错误depends_on声明了 Agent A但 Agent B 启动时报错No such file or directory: A_output.jsonAgent A 执行失败退出码非 0未生成输出文件检查./workspaces/A.log看是否有异常堆栈确保 Agent A 脚本末尾sys.exit(0)OpenRig 不会重试失败的 Agent需人工修复后openrig restart Ainput_schema使用$ref报错JSON reference not found$ref路径错误或引用的 Agent 在列表中位置变动$ref必须用#/agents/N/output_schema形式N 从 0 开始计数移动 Agent 顺序后必须同步更新所有$ref实操心得永远先跑openrig dry-run再跑openrig up。dry-run输出的命令就是 OpenRig 实际要执行的。把它复制出来在终端里手动执行一遍90% 的路径、权限、环境变量问题都能当场暴露。这是最高效、最直接的调试法。5.2 tmux 运行时问题终端里的“幽灵故障”问题现象根本原因排查与解决openrig up后看不到 tmux 会话终端卡住tmux 会话已创建但被后台运行或openrig进程被信号终止运行tmux list-sessions找到会话名如openrig-12345然后tmux attach -t openrig-12345检查~/.tmux.conf是否有冲突配置如set -g default-shell某个 Agent pane 里显示command not found: pythontmux 启动的 shell 未加载你的 Python 环境如 conda/poetry在.openrig.yaml中设置default_shell: /bin/zsh并确保该 shell 的 rc 文件.zshrc中正确初始化了环境或在 Agent 脚本开头显式激活source ~/miniconda3/bin/activate python ...openrig status显示RUNNING但ps aux找不到对应进程Agent 进程已崩溃但 tmux pane 未自动关闭运行tmux list-panes -a -F #{pane_pid} #{pane_current_path}找到对应 pane 的 PID用ps -p PID确认若 PID 不存在说明进程已死openrig restart agent_name会重建 pane多个openrig up命令并发执行导致 tmux 会话混乱OpenRig 默认会话名是随机的但并发时可能冲突在.openrig.yaml中固定session_name: my-project避免命名冲突或使用openrig down清理后再启动5.3 Agent 脚本开发类问题让每个成员都“守规矩”问题现象根本原因排查与解决Agent 脚本执行成功但下游 Agent 报错JSON decode error脚本输出了非 JSON 内容到 stdout如调试print()污染了日志文件导致 OpenRig 无法解析输出文件严格约定Agent 脚本的 stdout 只用于日志所有结构化输出必须写入./workspaces/name_output.json禁用print()输出 JSON用logging模块记录日志openrig restart后Agent 读取到旧的输出文件OpenRig 不会自动清理上一次的输出文件脚本需自行处理在脚本开头添加output_file Path(...); output_file.unlink(missing_okTrue)或在global中设置cleanup_on_start: true需 OpenRig v0.8.3HTTP Agent 调用超时但openrig status显示RUNNINGhttp类型 Agent 的超时由timeout_sec控制但status命令只检查进程是否存在不检查 HTTP 请求状态在agents.yaml中为httpAgent 设置health_check并增加retry_policy或在脚本中实现重试逻辑Docker Agent 启动后立即退出docker logs显示exec: python: executable file not found in $PATHDocker 镜像内未安装 Python或command路径错误运行docker run -it your-image /bin/sh进入容器手动执行which python确保command中的路径如python inference.py在容器内有效最后一个独家技巧为每个 Agent 脚本添加--debug参数。在args中加入[--debug]并在脚本中解析import argparse parser argparse.ArgumentParser() parser.add_argument(--debug, actionstore_true) args parser.parse_args() if args.debug: import pdb; pdb.set_trace() # 启动 pdb 调试器这样openrig restart --debug agent_name就能直接在 tmux pane 中进入交互式调试比print()日志高效十倍。这是我在调试一个复杂的 SQL 生成 Agent 时熬了三个通宵后悟出的救命招数。我在实际使用 OpenRig 的半年里从最初用它跑通一个三 Agent 的数据清洗流水线到现在管理着一个包含 12 个 Agent
