OM1 的 Go 執行環境：把機器人 HAL 拆成可換的插件管線
Modular AI HAL (Hardware Abstraction Layer) for Robots
秒懂
- 它是什麼？
- OM1 是 OpenMind 的模組化 AI 執行環境，用 Go 重寫後以單一二進位檔部署，靠插件接上 ROS2、Zenoh 與 CycloneDDS。它的價值在於把感知、LLM、動作拆成可替換的環節，代價是 Go 版仍有部分能力落後於已停止維護的 Python 版。
- 適合誰用？
- 如果你要的是一台能跑語音加視覺對話、而且硬體層可以日後替換的機器人，OM1 的 Go 版值得先做一次五分鐘的 conversation agent 驗證，確認 config/conversation.json5 裡 ASR 與 TTS 都設定完成、OM_API_KEY 有效、Zenoh 的 libzenohc 能正確載入。若你的需求是底層即時控制迴路，或你不想被 OMCU 計費與 OpenMind Portal 綁住，就別從這裡開始，直接用 ROS 2 原生節點。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
OM1 想解決的是硬體換代時整包重寫的問題
機器人專案最常見的死法是：上層的對話與決策邏輯寫得不錯，但換一顆馬達、換一台底盤、換一套中介軟體，整條管線就得重接。OM1 把這件事切開，README 的說法是讓開發者建立「multimodal AI agents across digital environments and physical robots」，並且把目標寫成「easy to upgrade and (re)configure to accommodate different physical form factors」。
它鎖定的對象很具體：做人形機器人、四足機器人、TurtleBot 4 這類教育機器人，或是在 Gazebo、Isaac Sim 裡做模擬的團隊。這些團隊的共同點是硬體還沒定型，但上層的感知與語言能力已經要開始疊。OM1 也支援手機 App 這種沒有實體底盤的環境，所以它本質上不是機器人作業系統，而是一層把輸入、模型、動作串起來的執行環境。
如果你只是要一個穩定的導航堆疊，OM1 不是那個東西。它不負責 SLAM，也不負責運動控制本身，它負責的是「誰在什麼時候被呼叫、資料往哪裡流」。
執行環境從 Python 換到 Go：理由與未還的債
OM1 原本是 Python 專案。README 直接寫出遷移理由：lower latency、better performance、efficient concurrency、edge device 上更小的記憶體足跡，以及單一 Go 二進位檔的部署方式。最後一點在機器人上很實際，因為部署現場通常不適合處理虛擬環境與相依套件版本衝突。
但同一段文字也承認代價：Go runtime 只覆蓋核心 agent pipeline，Python runtime 有「several capabilities」還在開發中。這句話的份量比它看起來重。它意味著兩邊不是等價的，而 README 沒有給出缺哪一些的清單，只留下一句「For most new development we recommend the Go runtime」。
更關鍵的是 Python 版的位置。README 說它「is now deprecated and will not be maintained」，放在 python 分支。所以這不是兩條並行的路線讓你慢慢挑，而是一條已經停止維護的舊路，和一條功能尚未補齊的新路。要採用的人得接受這個中間狀態。
Go 二進位檔也不是完全自足：它把 Zenoh 的 C 函式庫一起打包，所以啟動時要處理動態連結路徑，這是單一二進位檔說法背後的例外。
插件、端點與資料流：OM1 的實際骨架
從 README 能確認的架構輪廓有三層。最底層是硬體與中介軟體連接，透過插件支援 ROS2、Zenoh 與 CycloneDDS，README 明確建議新開發一律用 Zenoh。中間層是模型端點，已經預先配置好 Text-to-Speech、多家 LLM（OpenAI、xAI、DeepSeek、Anthropic、Meta、Gemini、NearAI，以及本機的 Ollama），以及多個 Visual Language Model。最上層是資料輸入，README 說「Easily handles new data and sensors」，來源涵蓋 web data、social media、camera feeds 與 LIDAR。
動作端則是 motion、autonomous navigation 與 natural conversations。把這三層接起來的就是 agent pipeline，而 README 對它的描述是「input-LLM-action flow」，並且說快速開始的設定會在終端機視覺化 state updates。這是整份材料裡最具體的行為敘述：狀態更新會被印出來，可以肉眼追蹤一個輸入怎麼走到 LLM 再走到動作。
需要說清楚的是，README 只給了架構圖的圖片連結，沒有文字化的模組清單、沒有事件匯流排的說明、沒有 pipeline 各階段的命名。所以「插件怎麼註冊」「一個新的感測器要實作哪些介面」這類問題，這份材料回答不了，得去看 docs.openmind.com。
可觀測性倒是給得比多數同類專案明確：內含預先配置的 Prometheus 與 Grafana，README 舉的指標例子是 LLM 與 ASR 的延遲。這暗示 pipeline 的每個階段會吐時間量測，對於抓「到底是模型慢還是語音辨識慢」這種問題有直接用處。
五分鐘跑起來：實際指令與必要的環境變數
系統相依先裝。macOS 用 brew install portaudio ffmpeg；Linux 用 sudo apt-get install -y portaudio19-dev ffmpeg pkg-config。portaudio 是音訊，ffmpeg 是影音處理，這也側面說明預設的 conversation agent 是真的會碰麥克風與攝影機。
取得執行檔有兩條路。README 推薦下載預編譯版本，目前提供 linux-amd64、linux-arm64、darwin-arm64、darwin-amd64 四種。解壓後執行 chmod +x om1，macOS 若被 Gatekeeper 擋下，用 xattr -d com.apple.quarantine om1 2>/dev/null || true 解除。發行壓縮檔已包含 config/、knowledge_base/ 與 libzenohc，所以跑 runtime 不需要 clone 整個 repo。
從原始碼建置則需要 Go 1.25.0 以上與 make，流程是 git clone、cd OM1、make deps、make build。
金鑰從 OpenMind Portal 取得，設成環境變數 OM_API_KEY。從原始碼建置的人另外可以用專案內的 .env，做法是 cp .env.example .env 然後把 OM_API_KEY 填進去。
啟動前要先處理動態函式庫路徑，macOS 是 export DYLD_LIBRARY_PATH="$PWD:$DYLD_LIBRARY_PATH"，Linux 是 export LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH"，然後 ./om1 -config ./config/conversation.json5。從原始碼建置的人改用 CONFIG=conversation make run，要 debug log 則用 make dev。
README 對「跑成功」的定義有三項：終端機顯示 agent 啟動成功、看得到輸入處理與 LLM 回應的日誌、agent 對語音與攝影機輸入以語音回應。這三項裡前兩項是日誌層級，第三項才是端到端。
要監控就 docker-compose up -d grafana prometheus，瀏覽器開 localhost:3000，預設帳密 admin/admin，OM1 Latency Monitoring 儀表板會自動佈建。
故障排除列了四種：Authentication 錯誤要確認 OM_API_KEY 存在且未過期；Build 錯誤要確認 Go 版本並先跑 make deps；Camera 存取問題要去系統設定給終端機或 IDE 攝影機權限；metrics 埠 9090 的 Address already in use 要停掉佔用的行程，例如另一個 Prometheus。最後這條暗示 metrics 服務預設綁在 9090，跟 Prometheus 自己的預設埠相同，同一台機器上跑兩個就會撞。
OMCU 與 Portal：免費額度是天花板，不是背景資訊
OM1 的模型端點雖然列出十幾家供應商，但計費走的是 OpenMind 自己的單位 OMCU，README 稱它為「the computational unit for billing on OpenMind's platform」。免費方案每月給 50 OMCU，每月重置，要更多得去 portal.openmind.com 升級。
這件事對評估的影響比它佔的篇幅大。50 OMCU 對一個每天開著麥克風與攝影機、持續呼叫 LLM 與 VLM 的 conversation agent 來說，是一個很快就會見底的數字。README 沒有說明 OMCU 如何換算成 token、請求數或秒數，所以無法從這份材料推估實際能跑多久。
對自架的團隊來說，Ollama 被列在本機選項裡，這是一條繞開計費的路，但 README 沒有說明走 Ollama 時是否仍需要 OM_API_KEY 才能啟動，也沒有說明哪些 pipeline 元件會強制走 OpenMind 的端點。這是採用前必須自己驗證的一點。
換句話說，OM1 的開源授權與它的託管服務是兩件事。程式碼是 MIT，但預設路徑會把你導向一個有免費額度上限的計費平台。
什麼時候不該用 OM1
第一個明確的排除條件是底層即時控制。OM1 的 pipeline 是 input、LLM、action 的順序結構，中間夾著模型推論。這種結構的延遲由模型決定，不適合放在需要固定週期、需要硬即時保證的控制迴路上。要做關節層級的力矩控制，該寫的是 ROS 2 的 controller，不是 OM1 的插件。
第二個是版本狀態。目前最新的正式標籤是 v1.0.2-beta.2，前一個是 v1.0.2-beta.1，再上面是 nightly 開發建置。全部停在 beta。搭配前面提到的 Go 版功能缺口與 Python 版停止維護，這是一個還在移動的專案。要放進已經出貨的產品，得先確認你依賴的每一個能力都在 Go 版裡。
第三個是相依性。portaudio、ffmpeg、pkg-config 是系統層套件，libzenohc 是隨附的 C 函式庫，還要處理 DYLD_LIBRARY_PATH 或 LD_LIBRARY_PATH。README 自己把「單一 Go 二進位檔」當成賣點，但實際啟動指令裡有兩行是為了動態連結。這不衝突，只是「單一二進位」不等於「零相依」。
第四個是文件深度。這份 README 給的是快速開始與故障排除，不是架構規格。插件介面、pipeline 階段命名、狀態更新的資料結構，都要另外去 docs.openmind.com 找。如果你的團隊需要先讀規格再決定，這裡的資訊不夠。
替代路線：ROS 2 原生堆疊與 Nav2
最直接的替代是把 OM1 換成 ROS 2 原生節點組合，導航用 Nav2，語音與視覺各自寫成獨立節點，用 topic 與 service 串起來。差別在控制權與抽象層級：OM1 幫你決定 pipeline 的形狀，並且把 LLM 與 VLM 端點預先接好；ROS 2 原生路線不幫你決定任何事，你得自己選模型、自己寫推論節點、自己處理非同步與背壓。
反過來說，ROS 2 原生路線沒有 Go 版與 Python 版的能力落差問題，因為根本沒有兩套實作。你用的是社群長期維護的元件，生態系裡的驅動與工具也都在同一套抽象上。代價是整合工作量，尤其是多模態輸入與 LLM 呼叫這一段，OM1 已經先做完了。
OM1 在傳輸層其實沒有跟 ROS 2 對立，它透過插件接上 ROS2、Zenoh 與 CycloneDDS。所以更準確的說法是：OM1 是蓋在這些中介軟體之上的一層 agent runtime。你如果只需要中介軟體本身，就不需要這一層；你需要的是「輸入進來、模型判斷、動作出去」這段編排，那才是 OM1 的位置。
Zenoh 值得單獨提一句，因為 README 明確建議新開發一律用它。它同時出現在 OM1 的插件清單與隨附的 libzenohc 裡，代表這條路徑是被當作預設來對待的。
維護成本與授權的實際含義
授權是 MIT，預編譯二進位檔、config/、knowledge_base/ 與 libzenohc 都在發行壓縮檔裡。這對商業使用是寬鬆的，但要注意兩件事：隨附的 libzenohc 是獨立的 C 函式庫，它的授權與 OM1 的 MIT 是分開的，README 沒有說明版本與授權條款，這點要自己查。模型供應商的服務條款也不在 MIT 的範圍內。
升級成本主要來自版本節奏。nightly 開發建置與 beta 標籤並存，代表介面可能還在動。config 檔是 json5，啟動時以 -config 指定路徑，所以不同 agent 可以各自帶一份設定，這是把升級風險隔離在單一設定的可行做法。
真正難估的是 Go 版補齊 Python 版能力的時間表。README 沒有給，release notes 也沒有出現在這份材料裡。如果團隊的計畫依賴某個目前只在 Python 版存在的功能，那就得在 deprecated 的 Python 分支與等待之間選一個，而這兩條路都不輕鬆。
最後一個具體的檢查點：README 特別提醒，要做語音互動就得確認 config/conversation.json5 裡 ASR 與 TTS 都已設定。這是預設設定不一定完整、需要動手改的訊號，也是第一次啟動最可能卡住的地方。
編輯結論
如果你要的是一台能跑語音加視覺對話、而且硬體層可以日後替換的機器人，OM1 的 Go 版值得先做一次五分鐘的 conversation agent 驗證，確認 config/conversation.json5 裡 ASR 與 TTS 都設定完成、OM_API_KEY 有效、Zenoh 的 libzenohc 能正確載入。若你的需求是底層即時控制迴路，或你不想被 OMCU 計費與 OpenMind Portal 綁住，就別從這裡開始，直接用 ROS 2 原生節點。決定採用前，第一個要驗證的不是功能清單，而是 Go 版還缺哪些 Python 版已有的能力，因為 README 只說「several capabilities」仍在開發中，沒有列出清單。
社群筆記