Agentlas OS：把專職 agent 留在 hub，每個任務再開一個臨時 orchestrator

它想解決的是「專職角色每次重寫」這件事

多數人用 LLM 做重複性工作時，會反覆貼同一段角色設定：一個負責寫 migration 的、一個負責讀 log 的、一個負責審 PR 的。這些設定的內容變動很小，卻每次都要重建。Agentlas OS 的作法是把這些角色留在一個 hub 裡，README 稱之為 public Agentlas Hub 與私有的 owner-scoped Agent Cloud，任務進來時不直接叫用某個固定 agent，而是生成一個臨時的 orchestrator 去調度它們。

目標讀者寫得很明確：已經在用 Claude Code、Codex、Gemini CLI、Antigravity 或 Cursor 的人。README 的 badge 把支援的 LLM 列成一行，包含 Claude Code、Codex、Gemini、Antigravity、Cursor、DeepSeek、GLM、Ollama。它不打算取代這些宿主，而是掛在宿主裡面，多出一層 /agentlas build 之類的指令介面。

這裡有個定位上的取捨值得講清楚。它自稱 Agent OS，但 README 描述的實際行為比較接近「agent 套件的產生器加上路由層」：把自然語言請求分類、跑一輪訪談與研究關卡、生成 package、驗證、然後問你要只留在本機還是存進 Cloud。這不是一個排程系統，也不是一個常駐的服務網格。

Hephaestus 是引擎，orchestrator 是消耗品

README 把 Hephaestus 描述為「the open-source engine underneath」，安裝腳本也叫 install-all-runtimes.sh，環境變數前綴是 HEPHAESTUS_。也就是說，對外品牌是 Agentlas OS，實際執行層是 Hephaestus，而 repo 本身同時承載這兩者。

資料流大致是這樣：使用者在宿主 LLM 裡下一個自然語言請求，Agentlas 先分類，再跑訪談與研究關卡（README 用 interview and research gate 這個詞），接著生成 agent package、驗證，最後詢問保存位置。專職 agent 是長期存在的，orchestrator 是為這次任務生成的，任務結束後它的價值就結束了。

這個切法跟常見的 multi-agent 框架不同。常見做法是先把一個固定的協作圖定義好，節點與邊都寫死在程式裡，執行時照著圖跑。Agentlas 反過來：專職 agent 是資產，拓撲是每次現算的。好處是面對沒見過的任務時不必先改圖；代價是同一個任務跑兩次，中間的調度路徑可能不一樣，可重現性較低。README 沒有描述 orchestrator 的生成邏輯或它如何選擇 hub 裡的 agent，這部分在現有材料裡是空白的。

安裝被設計成「先讀再跑」

這個專案在安裝流程上做了一個不常見的選擇：README 的第一個安裝方法不是給人看的，是給 LLM 看的。它提供一段可以直接貼進 Claude Code、Codex、Gemini CLI、Antigravity 或 Cursor 的文字，內容要求宿主先去抓 scripts/install-all-runtimes.sh 讀過，確認它只寫入 ~/.agentlas、~/.local/bin 以及宿主自己的 plugin/command-adapter 目錄（例如 Claude Code 的 ~/.claude），確認後才執行。

實際指令是：

curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 bash

那個環境變數不是裝飾。加上 HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1，安裝程式會額外把一段 routing block 寫進宿主的全域指令檔，README 舉的例子是 ~/.claude/CLAUDE.md，作用是讓「substantial tasks」可以由 Agentlas 的 agent network 來配置人員。README 明說這段內容不是機密，可以讀出來、可以引用回去。不想現在加的人就拿掉這個變數，之後再用 hephaestus global install 補上。

文件對 Windows 使用者的處理是要求開 Git Bash，並附上從搜尋列找 git bash、必要時先裝 Git for Windows 的步驟；macOS 則是開 Terminal，並提醒首次執行 curl 或 git 可能跳出 Command Line Tools 安裝。安裝完要關掉再重開 AI 工具，讓它載入新指令。

把安裝腳本設計成「由 LLM 讀過再執行」，在供應鏈層面是誠實的作法，但它同時意味著一件事：真正決定你機器被寫入什麼的，是那個腳本當下的內容，而不是 README 的敘述。README 自己也建議有安全顧慮的人先在瀏覽器打開該連結看過。

全域 router 是這套設計裡最需要警覺的一步

HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 做的事，是在宿主 LLM 的全域指令檔裡插入一段路由規則。以 Claude Code 為例就是 ~/.claude/CLAUDE.md。這個檔案的性質是：每次對話都會被讀進去，影響的不是某個專案，而是你在這台機器上的所有工作階段。

README 的說法是「lets substantial tasks be staffed from Agentlas' agent network」，並強調內容可讀、可引用。這解決了一個實際問題：如果 routing block 只寫在專案層級，換個目錄就失效。但代價是範圍從專案擴大到整台機器。如果你同時在多個客戶的 repo 之間切換，這段規則會跟著你進到每一個工作階段。

README 給了退路，就是先不加這個變數，之後再跑 hephaestus global install。這其實是比較合理的預設順序：先讓 /agentlas build 這類指令介面在宿主裡可用，確認它對你的工作流真的有幫助，再決定要不要讓它參與任務分派。反過來先加 router 再評估，等於在還沒驗證價值之前就改變了全域行為。

另一個沒有在材料裡回答的問題是卸載。README 描述了安裝會寫入哪三個位置，但沒有描述如何把 routing block 從 ~/.claude/CLAUDE.md 移除。要採用的人應該自己先確認這一點。

「agent 不綁定單一模型工作區」的實際含義與限制

README 反覆強調一句話：agent 不是你建立它的那個模型工作區或那台電腦的附屬品。要從別的地方取回它，就在支援的宿主上安裝 Agentlas OS 並登入。這是它跟「把 prompt 存在某個 IDE 的 snippet 裡」最實質的差別：agent 定義被抽離出宿主，放進 owner-scoped 的 Agent Cloud。

這個設計有明確的適用邊界。第一，跨機器取回需要登入，也就是說這條路徑經過 Agentlas 的雲端服務，不是純本機。專案自稱 local-first，這在「執行」層面成立，但在「保存與取回」層面不成立。第二，README 提到可以從 public Agentlas Hub 借用 specialist，借用來的東西能不能被你修改、能不能脫離 hub 獨立存在，材料裡沒有交代。第三，agent 是資產這個說法預設了它有長期價值，但如果你建立的 agent 是綁在特定 repo 的特定慣例上，換個專案就失效，那資產化的收益有限。

還有一個容易忽略的點：它支援的模型清單裡同時有 Ollama。如果你的動機是「不想讓 agent 定義離開本機」，那 Ollama 這條路徑跟 Agent Cloud 的取回機制是兩種不同的信任模型，README 沒有說明兩者如何並存。

版本節奏與維護成本

從 release 紀錄看，v1.2.42、v1.2.43、v1.2.44 三個版本分別在 2026-09-05 與 2026-09-06 發布，其中 v1.2.43 到 v1.2.44 相隔約一小時二十分。這個節奏說明專案還在快速迭代期。

快速迭代對採用者的具體影響是：安裝腳本會變。README 的安裝方式是用 curl 抓 main 分支上的 scripts/install-all-runtimes.sh 直接執行，而不是抓某個 release tag 底下的腳本。這代表你每次重跑安裝，拿到的都是當下的 main。對願意先讀腳本的人來說這不是問題，對想凍結版本的人來說就不是理想路徑。

授權是 Apache-2.0，允許商用與修改，並包含專利授權條款。這裡只陳述授權識別，不構成法律意見；如果你的情境涉及把 agent 定義散布給外部或嵌入產品，應該自己確認 Apache-2.0 的條款與你既有的授權政策是否衝突。

維護成本還有一塊來自宿主。Agentlas OS 掛在 Claude Code、Codex、Cursor 這些工具上，這些宿主自己的 plugin 機制與全域指令檔格式一旦改變，安裝腳本寫入的內容就可能失效。這是所有「寄生在別的 LLM 宿主上」的工具共有的風險，不是這個專案獨有，但它確實把風險集中在那幾個寫入路徑上。

替代方案：LangGraph 走的是完全相反的路

如果你要的是多 agent 協作，LangGraph 是最直接可以拿來對比的選項，而兩者的差異不在功能清單，在控制權放哪裡。

LangGraph 的模型是：你把 agent 與它們之間的轉移定義成一個 graph，寫在程式碼裡，進到你的 repo，跟著你的版控走。執行路徑是事先決定的，可重現，可測試，可以對特定節點寫單元測試。

Agentlas OS 的模型是：專職 agent 放在 hub，拓撲在任務當下由一個臨時 orchestrator 生成。你得到的是對未見過任務的適應性，失去的是執行路徑的事前可見度。README 沒有描述 orchestrator 的生成邏輯，也沒有描述如何重播某次執行。

這不是誰比較好的問題，是兩種不同的問題。如果你的任務類型穩定、需要稽核軌跡、需要對失敗路徑做處理，LangGraph 這種把圖寫死的做法更合適。如果你的任務類型發散、你主要想省下反覆描述角色的時間、而且你能接受每次調度路徑不同，那 Agentlas 的 hub 加臨時 orchestrator 才對得上。

中間還有一種情況值得指出：如果你只是想要一組可重用的 system prompt，那不需要 agent OS，把 prompt 存成檔案搭配版控就夠了。Agentlas 的價值在於它還處理了跨模型、跨機器的取回與調度，如果你不需要這兩件事，它的複雜度就是多餘的。

編輯結論

如果你的團隊已經在用 Claude Code、Codex 或 Cursor，而且痛點是「每次都要重新描述同一批專職角色」，Agentlas OS 值得先在單一機器上試：跑 install-all-runtimes.sh，先不加 HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1，確認 /agentlas build 在宿主裡真的可用，再決定要不要讓它改寫 ~/.claude/CLAUDE.md 這類全域指令檔。反過來說，如果你需要的是可審計的固定 workflow、或者你無法接受 agent 定義與執行紀錄經過第三方雲端（Agent Cloud、Agentlas Hub），那這套 hub 加上臨時 orchestrator 的模型並不對應你的需求，應該先看 LangGraph 這類把 graph 定義留在自己 repo 裡的方案。驗證順序建議是：先讀 install-all-runtimes.sh 確認它只寫入 ~/.agentlas、~/.local/bin 與宿主的 plugin 目錄，再看 hephaestus global install 實際產生什麼內容，最後才把 agent 存進 Cloud。

官方來源

1. agentlas-ai/Agentlas-OS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases