建構使用 OpenCode 與 GitOps 的 Homelab AI 開發平台
一個以 AI 為驅動的 Homelab 管理開發平台，允許在 GitOps 工作流程中自動化容器更新與基礎設施變更，同時保有人為監督。透過將 AI 代理隔離在專屬 VM，並要求 Pull Request（PR）批准，使用者可以利用 AI 完成跨多設備的複雜設定任務，而不必讓 AI 直接存取生產服務。
架構：OpenCode 與安全沙盒
平台的核心是 OpenCode，一個與供應商無關的程式開發環境，因其內建的 Web 伺服器與 Web UI，能提供跨設備同步的持續編程工作階段。
為了維持安全性並限制 AI 產生變更的「爆炸半徑」，系統的架構如下：
- 專屬 VM： OpenCode 以 systemd 單元的形式在 Truenas 主機上的簡易 VM 中執行。此 VM 包含必要的開發工具，但與實際管理的服務網路隔離。
- 受限 Git 存取： AI 代理在 Git 伺服器上擁有自己的使用者帳號與專屬 SSH 金鑰。它只能克隆專案並推送至功能分支，嚴禁直接推送至部署分支。
- 特權存取： 由於 VM 與生產服務隔離，AI 在 VM 內獲得 root 權限，以安裝建置工具或測試相依套件，而不會危及主機系統。
基礎設施管理的 GitOps 工作流程
平台取代了手動的基礎設施維護工作——例如閱讀發行說明與更新 Docker Compose 堆疊——改以 AI 輔助的管線執行。工作流程遵循嚴格的順序，以確保穩定性：
- 規劃： 使用者在 OpenCode 中定義功能或改進，包含規格與實作計畫。
- 迭代： 使用者與 AI 針對計畫進行迭代，並在可能的情況下驗證變更。
- 分支： OpenCode 將最終變更推送至功能分支。
- 審查： 使用者開啟並審查該功能分支的 PR。
- 部署： PR 合併後，GitOps 工具負責部署。此過程包括 Arcane 處理 Docker 服務變更、Home Assistant 設定的 GitOps 外掛，以及 Cloudflare Pages workers 用於部落格更新。
此方式讓高階變更——例如在所有容器間更新網路設定——只需在行動裝置上審查 PR，即可完成，而不必手動編輯多個 Compose 檔案。
技術限制與挑戰
雖然平台簡化了更新流程，但在 CI 反饋迴路 上仍存在顯著瓶頸。在 GitHub 等環境中，代理可以透過閱讀 Action 日誌來診斷測試失敗或 linter 錯誤。然而，在本設定使用 Forgejo 時，公開 API 不會暴露工作日誌，導致 AI 難以自主診斷與修復部署失敗。
社群觀點與替代實作方式
開發者之間的討論揭示了多種將 AI 整合至 Homelab 與開發環境的替代模式：
- 基於 Action 的代理： 部分使用者在 Forgejo Action runner 內執行 OpenCode，透過在議題中使用
/oc指令自動產生 PR。 - 增強沙盒化： 進階實作包括使用 gVisor 與 Kubernetes 代理沙盒，或透過 systemd 強制的私有 localhost 與代理，防止代理直接存取憑證。
- 整合層： 如 Kimaki 等工具可加入 Discord 整合，讓使用者以語音或聊天訊息與程式碼庫互動。
- 替代工具鏈： 其他使用者採用 n8n、Argo 與 k3s，搭配 Qwen 或 Gemma4 等模型，實現自動化工作流程。
"我的工作流程將 AI 放在 PR 審查之後。OpenCode 寫好變更，我在 PR 中自行合併。我覺得這很可愛，但更重要的是，它防止未審查的程式碼被部署。"
"我可以在電腦上開始變更，於手機上審查 PR，然後讓 GitOps 處理部署。"