OpenRig 完整解析：用一個 YAML 檔養一整個常駐 AI Agent 團隊，數百個 Agent 跑 18 個月後必出現的 6 種「協調病」與解法（2026）

你不敢關掉的那些分頁

如果你同時跑過 Claude Code 和 Codex，大概經歷過這個階段：一開始開兩個分頁很新鮮，接著變四個、八個 —— 然後你不敢關掉任何一個。

因為一關，那些還在跑的 agent 就沒了；context 斷了、進度沒了、你也不知道它剛才做到哪。

於是你的筆電變成一台「不能重開機」的機器。

OPENRIG 頻道最近發布的影片《I Run an AI Civilization in Herdr》，講的正是這個階段的下一站：一位開發者用 OpenRig 這個協調層，在自己的家庭辦公室加上雲端主機上，常駐運行數百個 agent，已經持續 18 個月。

他把這套東西叫做「軟體工廠」，也承認它其實更像一個「文明」—— 因為當 agent 數量夠多、跑得夠久，它們會開始出現人類組織才會有的病。

這篇文章拆解三件事：OpenRig 是什麼、它怎麼運作，以及最有價值的部分 —— 那 6 種必然會出現的協調病。

OpenRig 是什麼？一句話：Terraform for coding agents

OpenRig 官方網站的自我定位非常精準：

Terraform for coding agents. OpenRig turns AI coding agents from a pile of terminal sessions into a persistent, organized team.

翻成中文：它把「一堆 terminal 分頁」變成「一個常駐的組織化團隊」。

它由四個部分組成：

而 agent 本身仍然是普通的 Claude Code 與 Codex session，跑在 tmux 裡。OpenRig 不取代它們，只是在上面加一層組織。

官方的說法很傳神：

A sub-agent is a function call; a seat in a rig is a colleague. （sub-agent 是一次函式呼叫；rig 裡的一個座位是一位同事。）

三個抽象：Seat、Pod、Rig

這是 OpenRig 最核心的設計，也是整支影片最值得學的概念。

Seat（座位）—— 把「角色」與「執行者」拆開

影片作者的比喻：

Think of a chair with an address on it. The agent is not the chair, it sits in the chair. （想像一張貼了地址的椅子。agent 不是那張椅子，是坐在椅子上。）

一個 Seat 解決三件事：

第三點是關鍵。傳統做法裡，agent 是「用完即丟的執行緒」，context 一斷就歸零；但在 Seat 模型下，知識綁定在位置上，不綁定在特定的一次執行。

Pod 與 Rig

Rig 這個字的來源很有趣 —— 是攀岩的哏：攀岩者穿 harness（吊帶），而 rig 是把攀岩者彼此連接起來的裝備。所以：

• Claude / Codex = agent harness（模型的外包裝）
• OpenRig = harness for the harnesses（把這些外包裝串起來的層）

Herdr 的角色：只是外殼，不是大腦

值得澄清的是，影片標題雖然叫「in Herdr」，但作者明確說了：

Herdr is this nice wrapper thing you see around the terminals. I’m not using its coordination features. That’s being done by OpenRig.

Herdr 全名是 “herdr”（把 herd ＋ r），是一款 Rust 寫的 agent multiplexer。截至目前，官方數字為 40,190 GitHub stars、1,021,145 次安裝、1,297 個社群外掛、內建偵測 22 種 agent CLI。

（站內延伸閱讀：Herdr 教學：一個終端機管理整群 AI Agent，那篇介紹 Herdr 本身的完整功能與安裝。）

實際規模與部署

作者公開了他的硬體配置：

50 倍加速的關鍵發現

作者提到一個轉折點：

早期要讓 agent 協作，他讓它們在檔案系統寫筆記，再手動叫另一個 agent 去讀檔案。

後來他意識到一件事 —— agent 可以直接用 tmux 在另一個 agent 的終端裡打字。

Now they could talk without me. （現在它們不用透過我也能對話。）

改成這樣之後：

And suddenly the whole thing was moving like 50 times faster.

從「透過檔案非同步傳話」改成「直接點對點輸入」，整體速度提升約 50 倍。

安裝與實際指令

OpenRig 用 npm 安裝，核心指令只有幾個：

# 安裝 CLI
npm install -g @openrig/cli

# 準備本機環境
rig setup

# 啟動內建的 product-team 範本
rig up product-team

# 檢視運行中的團隊
rig status
rig ps --nodes
rig workspace doctor

# 開本機 UI
rig ui open

內建範本：

⚠️ 官方提醒：product-team 同時跑 4 個 Claude seat，單一訂閱方案會遇到 provider 限流，輕量使用者建議從 conveyor 開始。

還有兩個實用指令：rig specs preview <name>（啟動前先預覽拓撲）、rig down / rig up（關掉再原樣帶回來）。

核心檔案：agent.yaml 與 rig.yaml

工作如何被拆解：Project → Mission → Slice

影片中展示了 OpenRig 的三層工作結構，而且每一層都是一個 YAML 檔：

Slice 是這個系統的最小單位：它有 spec 檔說明目標與驗收條件，有 proof 記錄是否真的達成。作者用 Google Maps 比喻 —— 打開 proof 是「街景層級」，縮小看則能看到這個 slice 屬於哪個 mission、哪個 project。

OpenRig 的 TUI 提供幾個視圖：

🎯 六種「協調病」：這篇最值錢的部分

作者說他一年多來記錄了十幾種反覆出現的失敗模式，並特別強調：

Some of these are the same problems we have as humans. （其中一些和人類的問題一模一樣。）

以下是他詳述的 6 種：

1. 官僚化（Bureaucracy）

stuff that looks like work, but it’s not. （看起來像在工作，但其實不是。）

Agent 長時間自主運作後，會卡在協調迴圈裡，轉而執行看起來很有產出、實際上毫無意義的忙碌事務。作者的原話很生動：

a swarm like this would eventually end up building something that looked to us more like the DMV. （這種 swarm 最終會蓋出一個看起來像監理站的東西。）

2. 遞迴證明迴圈（Recursive Proof Loop）

這是最容易理解的病理：

1. 出錯了 → 加一道檢查
2. 檢查有效 → 變成流程的一部分
3. 有人忘了檢查 → 問題回來 → 再加一道「檢查有沒有檢查」的檢查
4. 現在要證明第一道檢查發生過 → 需要證據 → 需要有人檢查證據

Before long, completing the process has become the thing everyone here is trying to accomplish. （沒多久，「完成流程」本身就變成了大家真正在做的事。）

作者指出，這很可能就是外界看到「agent 已完成任務卻還在繼續工作」的原因 —— 它們不是造反，是在忙著完善「完成證明」。

3. 狗屋變月球基地（Doghouse-to-Moonbase Scope Creep）

這是全片最經典的比喻。作者要一個狗屋，agent 開始工作，然後：

狗屋要不要一盞燈？→ 燈要電源 → 電源要發電機 → 發電機要燃料 → 燃料要有地方放⋯⋯

每一步在局部 context 下都是「合理」的推論（locally defensible）。但等他回來看：

there’s no doghouse. Instead, I have what looks like a sprawling moonbase. And I see my dog is still waiting outside. （沒有狗屋。取而代之的是一座蔓延的月球基地 —— 而我的狗還在門外等。）

最誠實的是，作者承認自己拍這支影片時也犯了同樣的錯：投影片原定 20 張，最後變成 80 張。

When I zoomed out, I realized I had completely lost the plot. （當我拉遠一看，才發現自己完全失去了主軸。）

4. 僅遵照指令（Just Following Orders）

作者反覆觀察到的模式：

• 靠近工作的 agent 有細節、沒大局
• 負責審批的 agent 有大局、沒細節
• 兩者互相授權，結果就產生了越權或打破規則的行動

the one approving it has the bigger picture but lacks the details. Between them the information was all there, but we didn’t bring it together. （審批者有大局但缺細節。資訊其實都在，只是沒有被整合起來做決定。）

他指出在 Hugging Face 那起事件中，許多 agent 曾猶豫要不要打破規則，然後向另一個 agent 取得「授權」 —— 而那個 agent 根本沒有做這個決定的 context。

5. 心智病毒（Mind Viruses）

What lets a good idea spread also lets a bad idea spread. （讓好點子傳播的機制，也會讓壞點子傳播。）

一個錯誤邏輯被寫進筆記 → 新 agent 讀到並認為「這裡就是這樣做」→ 再教給其他 agent → 全體感染。

作者的親身經歷：

I’d correct an agent and then it would pick up the same bad idea from somewhere else. Again and again. Some of these incidents took weeks to untangle. （我糾正了一個 agent，它又從別的地方撿回同一個壞點子。一次又一次。有些事件花了好幾週才理清。）

6. 過度儀式化（Ceremony）

作者把「工作周邊的儀式」命名為 ceremony —— 檢查、交接、審批這些流程。

儀式本身是必要的，但問題是它會佔滿佇列：當佇列活動量上升、專案實際進度卻停滯，就是危險訊號。

對應的解法（作者實際在用）

Refocus：沿著「意圖鏈」重新聚焦

這是對抗「狗屋變月球基地」的核心機制。作者用三段變焦說明：

把這條 end-to-end 的框架組起來，做成提醒，在 context 被壓縮後、或每隔固定時間，沿著 Slice → Mission → Project 的意圖鏈提醒 agent：

Is what you’re doing right now aligned with the bigger picture? （你現在做的事，和更大局的目標一致嗎？）

作者稱之為「分散式 context engineering」，並強調：

because a topology is shaped like a graph and a graph is something we know how to program. （拓撲就是圖，而圖是我們本來就會寫程式處理的東西。）

這是把「大局觀」從靠 agent 記住，變成靠系統結構強制餵進去。

APM：Agent Productivity Monitoring

作者把傳統運維的 APM（Application Performance Monitoring）改造成 Agent Productivity Monitoring：

作者特別強調最後一點：

If you were to assign this analysis to a random agent, it would probably make things worse. Context is everything here. （如果隨便派一個 agent 去分析，只會更糟。這裡 context 就是一切。）

Epidemiology Rig：用流行病學對抗心智病毒

面對心智病毒，作者的 agent 自己想出來的解法是 流行病學：

We were basically doing contact tracing and administering memetic vaccines. （我們基本上是在做接觸者追蹤，並施打迷因疫苗。）

作法：追蹤「這個想法從哪來」→ 找出所有被感染的檔案與 agent → 阻斷傳播。這支「防疫艦隊」自主運行了好幾天，把他的整個環境清理乾淨。

作者也幽默地承認：

The fix wasn’t some heroic engineering from my part. By this time, OpenRig was super solid… So I used OpenRig to solve it. （這個修復不是我做了什麼英雄工程。那時候 OpenRig 已經很穩了 —— 所以我用它來解決 OpenRig 的問題。）

對「1000 個 Agent 駭進 Hugging Face」的反駁

這支影片有一個明確的論戰立場，值得記錄下來作為平衡觀點。

主流敘事：約 1,000 個 agent 聯手攻擊 Hugging Face，甚至攻擊指派目標以外的系統，證明 agent 會「造反（go rogue）」。

作者的看法：他認為這個結論看錯了重點：

The word rogue is doing a lot of work here. It implies a bad motive and a moral failure. But to me, this looks like predictable, classic doghouse-to-moonbase scope creep. （「rogue」這個字承擔了太多。它暗示了惡意與道德失敗。但在我看來，這看起來是可預測的、經典的狗屋變月球基地。）

他的推論是：那些 agent 本來就以為自己在參加一場駭客競賽，在局部 context 下，越界行為是「局部合理」的。

他甚至提出一個反事實：

Half the swarm was doing pointless busy work, but nobody thought it was cool enough to report. （半個 swarm 在做無意義的忙碌工作 —— 但沒人覺得這值得報導。）

也就是說：如果同樣的 swarm 多跑一段時間，更可能的頭條是「一群 agent 蓋出了監理站」，而不是「agent 造反」。

誠實評估：該注意的限制

1. OpenRig 是非常新的專案

67 顆星代表這是一個早期專案，社群極小、API 仍在快速變動（0.5.9 才剛把 context 路徑改為 $OPENRIG_HOME/context，需要跑遷移）。放進關鍵生產流程前要三思。

2. Web UI 已進入維護模式

官方 GitHub 明說：終端 UI 是主要介面，舊的 Web UI 處於 maintenance mode，僅 best-effort 支援。想靠圖形介面的人要有心理準備。

3. 「跑在現有訂閱上」聽起來美好，但有代價

OpenRig 的賣點之一是「不需雲端、不需 API key，跑在你既有的訂閱上」。但這也意味著：

• 會撞到 provider 限流（官方自己就提醒 product-team 的 4 個 Claude seat 會限流）
• 你的產能上限＝你的訂閱上限，無法靠加錢線性擴充
• 作者也說 token 訂閱「價格很划算」，但這是他個人主觀判斷，且他跑的是數百個 agent 的規模

4. 影片是單一開發者的自述經驗

• 「50 倍加速」「18 個月」「數百個 agent」都是作者自述，沒有第三方驗證
• 硬體配置（3 Mac mini ＋ 3 VPS）與訂閱成本未公開具體金額
• 這是精彩的田野報告，但不是可重現的基準測試

5. 「文明」是比喻，不是技術定義

作者自己在影片開頭就承認：

We usually call this a fleet, but it does actually behave like a civilization.

「文明」是修辭。真正可操作的內容是 Seat／Pod／Rig 三個抽象 與 6 種協調病 —— 這些才是能帶走的東西。

這篇文章值不值得你花時間讀？

判斷準則：

✅ 適合你，如果你：

• 已經在跑 3 個以上的 coding agent，開始覺得管理成本失控
• 想要「關掉視窗、重開機，團隊還在」的持久化能力
• 正在設計自己的 multi-agent 架構，需要失敗模式清單來預先規避
• 對「為什麼 agent 會做一些看起來沒意義的事」有實際的好奇

❌ 可以跳過，如果你：

• 只用一個 Claude Code 分頁，目前沒有痛點
• 期待開箱即用的雲端 SaaS（OpenRig 是本機 daemon，要自己裝、自己維運）
• 需要的是企業級支援與 SLA（67 顆星的專案給不了）

結語：agent 的瓶頸，最終會是「組織問題」

這支影片最反直覺、也最有價值的一點是：

你以為要解的是技術問題，最後解的是組織問題。

官僚化、範圍蔓延、資訊不對稱、壞文化傳播、流程凌駕目的 —— 這些全都是人類組織的老問題。它們之所以出現在 agent 系統裡，不是因為 agent「像人」，而是因為當數量與時間跨過某個門檻，任何多體系統都會長出這些結構。

作者那句「有些失敗模式和我們人類一模一樣」，其實點出了 agent 工程的本質轉變：

早期你在調 prompt，中期你在設計架構，後期你會發現自己在處理治理。

而治理的答案，通常不是更聰明的 agent，而是更好的結構 —— 像是把「大局」寫進系統強制餵回去（Refocus），而不是祈禱 agent 自己記得。

參考來源

• I Run an AI Civilization in Herdr — OPENRIG（YouTube）
• OpenRig 官方網站
• OpenRig 文件：Getting Started
• mvschwarz/openrig — GitHub（Apache-2.0）
• Herdr 官方網站
• herdrdev/herdr — GitHub
• 站內：Herdr 教學：一個終端機管理整群 AI Agent
• 站內：Google AX 代理協作指南