系列：「邊做邊補：用一個 AI 代理 mesh 專案，補齊 AI 工程師該有的能力」— 第 7 天
紀錄日期：2026-09-19
能力區：第 12 區 多 Agent 協作（兼第 11 區 工程判斷）｜ 類型：讀

先說計畫改了

Day 06 結尾寫的是「Day 07 拿十輪紀錄對照教材裡的規劃者設計」。今天沒做那個。

今天早上做完 Day 22 那批修正之後，我把公開 repo 的 README 第一段改成了「🔧 回廠重造中」。原因不是專案壞了，是三週實測把幾條設計上的縫暴露出來的同時，我也看清楚一件事：我沒有那些開源專案的時間和錢。Orca 一個月 500 多個 commit、377 個貢獻者；Paperclip 半年 8 萬星；Omarchy 背後是一個基金會和 1,870 萬美元的認捐。我一個人、一台 M5、五台 Windows 機、兩支手機。

與其繼續一條一條補，不如先弄清楚：哪些層已經有人做得比我好、而且會一直做下去；哪些層真的沒人做、只能自己養。 這就是今天這篇——一篇「讀」，讀的不是教材，是生態。

它是什麼

教材談多 agent 協作時，講的是 agent 之間怎麼分工、怎麼溝通、怎麼合併。ai-agent-book 第 10 章講對等協作與交叉驗證；hello-agents 講 orchestrator 模式。它們都假設你要自己蓋這套東西。

但 2026 年的現實是：這一層已經長出一整個生態。光是「平行跑很多個 coding agent」這件事，awesome-agent-orchestrators 清單上就有上百個專案。教材沒教的是下一個問題：當生態已經有東西的時候，你該自己蓋還是借？借哪一層？怎麼判斷一個專案值不值得依賴？

這其實是工程判斷的能力，跟多 agent 技術本身無關。但它決定了接下來三週我的時間花在哪裡。

專案裡哪件事逼我用到

三件事疊在一起：

1. Day 22 的三個發現——planner 自己換語言、分配式拆法掛一台就缺一塊、nonce 規則和輸出上限相剋——每一個的正解都在 coordinator 側，而 coordinator 不是我一個人能改完的。
2. z13 第五天不在線，契約備註 (14)–(20) 堆著沒人接。一個兩人專案，有一半的人不在，就是一人專案。
3. 有人問我 ORCHA 這個專案能不能借力。 我去看了，6 顆星、只支援 Claude Code、單機、Docker + Postgres。不值得。但那個問題本身值得：如果不是它，是誰？

做之前我以為

我以為答案會是「找一個最像我專案的，整套搬來」。

查完 55 個之後，答案變成「沒有一個能整套搬，但每一層都有兩個以上的好選擇」。而且最讓我意外的是：我原本以為最該保留的東西，查完之後更確定要保留——因為 55 個裡面一個做的都沒有。

先切一刀：核心與商品

看候選之前，先把自己的專案切成兩堆。這一刀決定後面所有事。

核心（自己做，不借）：receipt 契約（nonce、output sha、manifest 凍結）、手機當 worker、異質艦隊的 presence roster、評估層。

商品（能借就借）：多 CLI adapter、worktree 隔離與 fan-out、桌面 cockpit、SSH 到遠端跑 agent。

判準只有一句：這東西壞了，我能不能用自己的 receipt 證明它壞了？ 能證明的是商品，換掉不痛；證明工具本身是核心，不能外包。用這句話去問每一層，答案幾乎是立刻出來的——桌面 cockpit 壞了，receipt 還在，換一個就好；receipt 壞了，什麼都證明不了。

切完之後，「借」也分三種，由便宜到貴：

原則：先試黑盒，不行才搬模組，碰到核心才抄設計。這三天最有效的工作方式——真實子任務當 fixture、上線一輪就對原始資料——在第三種完全適用。

怎麼查：先訂準則，再看專案

先寫下我專案的八條需求，每條給權重，然後才去看候選。順序不能反，反了會被星數牽著走。

每個候選八格各打 1–5 分。星數不計分，只當參考。

評比頁的結論卡。中間那張「不借」的邊框是主色，因為它才是查完 55 個之後最確定的事。

第一輪打完，前四名是 A2A、Orca、Gas Town、Paperclip。看起來合理。

然後我做了一件應該一開始就做的事

使用者說了一句話：「最好選熱度高還頻繁更新的，這樣我們就不用自己維護。」

這句話把我從 README 拉回到數據。我用 GitHub API 把每個候選的近 30 日 commit 數、貢獻者數、最近一次 release、最後 push 日期實際抓了一遍，不再靠 README 和二手文章：

gh api repos/$r                                # stars, pushed_at, license
gh api "repos/$r/commits?since=$(date -v-30d)"  # 30 日 commit
gh api "repos/$r/contributors?per_page=1" -i    # 從 Link header 讀總頁數
gh api "repos/$r/releases?per_page=1"           # 最近 release

結果改了兩個判斷：

• Gas Town：18k 星、241 個貢獻者，看起來很健康。近 30 日 0 commit，release 停在 6 月。它轉去做雲端版了。從「抄 merge queue 設計」降級成「只能讀，不能接」。
• ORCH：那個我原本很喜歡的 Shell adapter 設計，30 日 0 commit、3 個貢獻者。設計留著，自己寫 30 行比接它便宜。

還有一個沒改判斷但值得記的：ruflo 73k 星、37 個貢獻者。這個比例跟網路上那份「99% theater」的稽核是一致的。星數是可以買的、可以炒的；貢獻者數和 commit 頻率很難。

重打 C8 之後的排序。Gas Town 和 ORCH 的紅色標籤是「30 日 0 commit」——這兩行在第一輪還排在前面。

C8 存續風險全部依實測重打之後，Orca 和 A2A 並列第一（3.60），Paperclip 第三。Gas Town 掉到第六，ORCH 第七。

十三個候選，各一句話

按重打之後的加權分排：

1. Orca（72k、MIT、≥500 commit/月、377 人）——「Fan one prompt across five agents, each in its own isolated git worktree」，正是我的 fan-out；SSH 到遠端，手機只能監看。黑盒接。
2. A2A（26k、Apache-2、基金會）——協定不是產品：Agent Card、Task、Artifact、push notification。MONDAY-MESH-API 七節每一節都能找到對應概念，沒有簽章 receipt，那是我要加在它上面的東西。第一個要做的對照。
3. Paperclip（81k、MIT、202 人）——「If it can receive a heartbeat, it's hired.」agent 定時醒來原子領 ticket、董事會審批、每 agent 月預算、超限硬停。最接近 §6 的調度模型；3 月才上線，先抄狀態機不接系統。
4. Agent Orchestrator（Composio、12k、Apache-2、496 commit/月）——plan→spawn→CI 回饋→review→merge 的完整迴圈，kanban 有「Needs You」欄。取代原本想抄的 Gas Town。
5. Superset（14k、673 commit/月）——跨機最完整，「connect another machine … Wake offline hosts」。但 Elastic License 2.0 不是 OSI 開源，只能當工具用。
6. Gas Town（18k）——Refinery merge queue、Wasteland federation。30 日 0 commit。只讀。
7. ORCH（163）——DDD 分層、Shell adapter。0 commit、3 人。設計留著。
8. OpenHands（88k、460 人）——當 mesh 裡一種 worker 型別，不是 orchestrator。
9. OpenClaw（390k）——通道層可以整個借來當 requester 入口。LICENSE 檔格式非標準，要開來確認。
10. Goose（54k、453 人、Rust）——它是一個 agent，不是 CLI 的 harness；唯一可能「搬模組」的候選。
11. ruflo（73k、37 人）——不借。
12. ORCHA（6）——只支援 Claude Code、Docker + Postgres。唯一值得記的是三條不變式：「Agents never create other agents」「No agent self-certifies task completion」、只有人能 verify（非人類呼叫直接 403）。這三句話跟我 M1 supervised 的思路是同一件事，抄那三句，其餘略過。
13. vibe-kanban（28k）——2026-04 sunset。

Omarchy 放哪一層

另外一個被問到的是 Omarchy——DHH 的 Arch + Hyprland 發行版，4.0.4，自稱「the malleable OS for the age of agents」，42k 星、443 人、基金會。對我有用的是：十個 coding agent 出廠預接（等於 adapter 層做掉一半）、整個環境是文字設定（agent 可以自己改系統）。

限制也清楚：官方 ISO 只有 x86-64；Apple Silicon 走社群的 Asahi 路線，M1/M2 穩，我的 M5 目前不可能。所以 Omarchy 不是「整個艦隊換 OS」，是「把五台 Windows worker 統一成同一個文字設定、同一組 agent、同一套更新的 Linux 節點」——剛好是我艦隊裡最不整齊的那一半。

還有一個要知道自己買的是哪一半：Omarchy 是桌面，我的 worker 大多無頭。裝了之後會關掉桌面自動登入、用 SSH 跑——它的價值在 agent 預接和設定，不在 Hyprland。

再往外查一圈：從 agent 到智慧機器

評比做完，我派了一個子 agent 去查一個更大的問題：如果目標不只是「調度 coding agent」，而是「讓一台機器本身變成 agent」，甚至「實體的智慧機器」，開源生態現在有什麼？ 要求它每個專案都用 API 查證，不准憑記憶寫數字。

它回來 42 個專案，分兩節。

A 節「機器本身變成 agent」24 個。 我漏掉了幾個很大的：

• Hermes Agent（Nous Research）：247k 星、MIT、400 人，會隨使用者成長的常駐個人 agent，有 Desktop。
• ZeroClaw：33k、Rust、420 人，極小體積、全平台。
• OpenClaw 現在 390k 星，基金會治理。它的架構寫著「trusted gateway ／ untrusted execution ／ deterministic policy」——跟我的 mesh + receipt 幾乎是同一張圖。這是 55 個裡第一個讓我覺得「receipt 可以掛在別人的架構上，不用自己養 coordinator」的候選。

還有一個趨勢：Codex CLI 是 Rust（474 人），Open Interpreter 整個重寫成 Rust（舊 Python API 不相容），Goose 是 Rust，ZeroClaw 是 Rust，IronClaw 是 Rust。這一層正在變成 Rust 的主場，對我有利。

B 節「實體智慧機器」18 個。 誠實結論是：LLM 和機器人之間的橋很薄。 唯一專門的 LLM↔ROS 橋是 NASA JPL 的 ROSA，8 個人、半年沒動。實務做法是把 LLM agent 接到 LeRobot（Hugging Face，28k、267 人、內建 Pi0／GR00T／SmolVLA 這些 VLA policy）的 policy 層，或者用 MCP／A2A 把 ROS 2 節點包成一個 worker。後者剛好是我 mesh 的形狀：一台機器人就是一個 worker，receipt 證明它真的動過。

子 agent 查回來的 42 個，每個都附 stars、最近 push、release、貢獻者、授權、維護方。右邊那張「避開」卡裡的 Daytona 有 71k 星。

避開的：Daytona 71k 星，2026-06 核心轉閉源、repo 凍結，README 明寫；Screenpipe 商業授權；OmniParser 是 CC-BY-4.0，那不是軟體授權。還有一整串改名搬家會斷連結的：basecamp→omacom、block→aaif-goose、All-Hands-AI→OpenHands。借力帳要記 org，不能只記專案名。

查完之後，架構長什麼樣

用「每天有 push、破百貢獻者、有組織背書、release 在一週內」這條線篩，每一層都有現成的：

手機（iOS/Android）     自己的 app：§6 pull／執行／receipt        ← 不借
桌面 cockpit            Orca（MIT）；Superset 動能更高但 ELv2
任務／審批／預算         Paperclip：heartbeat 領 ticket、董事會審批、月預算
常駐 agent 層           OpenClaw 或 Hermes
節點 runtime            Goose 或 ZeroClaw（都 Rust）
plan→merge 迴圈         Agent Orchestrator（Composio，取代原本想抄的 Gas Town）
協定                    A2A，receipt 當 extension
節點 OS（x86 五台）      Omarchy：十個 agent 預接
網路                    Tailscale（已在用）

我自己剩四塊：receipt 驗證、presence roster、手機 worker、評估層。coordinator 從「派工的人」退成「驗證的人」。

這四塊之所以留下，不是因為我捨不得，是因為 55 個專案裡沒有一個做：所有專案的手機端都是監看和追問，沒有一個讓手機當 worker；Orca 和 Superset 的 README 裡「receipt」「audit」零字；沒有人在量「子任務的文字有多少進了最終答案」。這才是「讀生態」真正的收穫——它不只告訴你能借什麼，它告訴你你做的東西裡哪些是真的稀缺。

拼裝的兩個真正風險

「每層都用現成的」聽起來很美，有兩個地方會摔。

一，真相來源只能有一個。 Paperclip 有自己的 Postgres、Orca 有 worktree 狀態、Omarchy 每台有自己的設定、我有 task record。四個都當真相就是四份互相不一致的狀態，而且每一份都很有信心。我的決定：任務狀態以 Paperclip 為準，我的 receipt 掛在它的 ticket 上當 metadata。 接受這點，spectyn coordinator 就可以退役一大半；不接受，接入會比自己寫還貴。這也是 README 上那句「回廠重造」的具體形狀——不是重寫，是降級自己的位置。

二，版本翻動。 Omarchy 一年內 3→4 把桌面整個重寫；Paperclip 才六個月；Orca 天天出版。動能第一梯隊裡有一半不到一年。這個風險沒辦法消除，只能管理：全部釘 commit，升級當 spike 做，每次升級先跑同一組真實 fixture。借來的東西如果一次升級把三個 spike 的驗收打壞，那就是它告訴你「我還沒穩到能當你的地基」。

還有一種最便宜的維護方式，是讓上游幫你維護。MIT 專案接受 PR。我需要的東西如果對他們也合理——Orca 接受「agent 可以是會分身到別台機器的東西」、A2A 加一個 execution_location 欄位——以後那個接口就不用我養。我手上有他們沒有的：手機 worker、receipt、十輪真實量測。這是換取上游接受的籌碼，比星數有用。

一個持續的方法

查一次不夠，這個圈子一年內改名、合併、棄坑很常見。所以訂一個一週一輪的迴圈：

1. 掃（30 分鐘，交給艦隊）：watchlist 每週抓一次 stars、commit、release、改名。
2. 對缺口（30 分鐘）：對的是我的契約備註和「還缺什麼」清單，不是「有什麼好玩」。
3. 試（半天硬上限）：一個候選一個 spike 一個可量驗收。到時沒過就停。
4. 記：借力帳一行（專案、釘住的 commit、授權、借哪塊、邊界測試在哪、怎麼退場）＋ m5.md ＋ 這個系列一篇。

升級規則：只釘 commit 不追 main，升級是一次有意識的 spike。這是唯一能防上游把你拖下水的方法。

今天真正學到的

三件，都是工程判斷，不是技術：

一，先訂準則再看候選，不然會被星數帶走。 我第一輪還是被帶走了一點——Gas Town 排第三是因為 README 寫得好；第二輪拿數據一對，它一個月沒動。

二，貢獻者數和 commit 頻率比星數誠實。 星數可以買可以炒；每天有人送 PR、每週有人剪 release，那是真的有人在。ruflo 73k 星 37 人、Gas Town 18k 星 0 commit，這兩個例子夠了。

三，讀生態最大的價值不是找到能借的，是確認不能借的。 我原本擔心「手機當 worker」和「有契約的 receipt」是我一個人的固執。查完 55 個之後，這兩件事變成了整個專案裡最有理由繼續做的部分。

明天

Day 08｜多 Agent｜做。四個 spike 的第一個：acer 那台小主機裝 Omarchy、進 tailnet、跑現有的 spectyn worker，驗收是手機發一輪 fan-out、這台接到 attempt 並回 receipt。這一步最便宜也最能證偽——一台 Omarchy 節點接不到 attempt，後面都不用談。

參考：ai-agent-book 第 10 章多 Agent 協作；hello-agents 的 orchestrator 一節；awesome-agent-orchestrators（andyrewlee）清單；各專案數據以 GitHub API 於 2026-09-19 查證，完整表在評比頁。