OpenAgent 自架評測：Go 單一二進位檔的代理迴圈與 RAG 知識庫
⚡️next-generation personal AI assistant powered by LLM, RAG and agent loops, supporting computer-use, browser-use and coding agent, demo: https://demo.openagentai.org
秒懂
- 它是什麼？
- OpenAgent 把 LLM 供應商、RAG 知識庫與代理迴圈收進一個 Go 單一二進位檔，預設開在 14000 埠。本文依 README 與 release 資訊，檢視它的機制、安裝方式、MCP 工具邊界，以及在什麼情況下你根本不該選它。
- 適合誰用？
- 如果你要的是一個能自己架、用 Go 編譯、把模型供應商與 MCP 工具集中管理的個人助理，OpenAgent 的安裝路徑短到只要一行 curl，值得在隔離環境先跑起來驗證。若你的場景需要跨節點的水平擴展、或必須審計每一次 shell 執行，先確認 INSTALL_DIR 與 BIN_DIR 指向哪裡、Docker 映像檔的資料落地位置，再決定是否導入。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
OpenAgent 想解決的是「工具散落各處」這件事
多數人在 2026 年使用 LLM 的方式，是同時開著聊天視窗、一個本機 RAG 腳本、一個瀏覽器自動化框架，再加上幾支自己寫的 shell 包裝。OpenAgent 的定位就是把這四件事收斂成一個自架服務：模型供應商可切換、知識庫可上傳文件、代理迴圈可以呼叫瀏覽器與 shell、外部工具走 MCP 協定接入。README 把它描述為「next-generation personal AI assistant powered by LLM, RAG and agent loops」，並強調「ships as a single binary, no installation needed」。目標讀者不是要訓練模型的研究團隊，而是想在自己機器或內網跑一套助理、又不想維護四套相依性的工程師。Apache-2.0 授權讓它可以進公司內部環境，這一點對比只提供雲端服務的產品是實際差異。
代理迴圈與 MCP：工具是怎麼被掛上去的
README 的 Features 章節把能力列成表格：Browser-Use 負責導航、點擊、填表、擷取與截圖；Web Search & Fetch 把即時頁面內容拉進代理上下文；Shell Execution 直接從代理迴圈執行指令與腳本；Office Automation 讀寫 Word、Excel、PowerPoint。這些不是各自獨立的微服務，而是同一個迴圈裡可被呼叫的工具。外部擴充走 MCP，README 明列支援 SSE、Stdio 與 StreamableHTTP 三種傳輸，掛上一個 MCP 伺服器就等於把它的工具暴露給代理。文件同時強調 Transparent Tool Calls，也就是每一次工具呼叫的參數與回傳值都逐步可見。這個設計對除錯是必要的，因為當代理同時能開瀏覽器又能跑 shell，出錯時你必須知道是哪一步、帶了什麼參數。至於迴圈本身的終止條件、步數上限與並行策略，README 沒有給出細節，這部分需要看原始碼或實際跑一遍才能確認。
RAG 知識庫：上傳之後發生什麼
知識庫路徑相對單純。README 寫的是上傳 PDF、Word、Excel 等文件後，系統會自動切塊、產生嵌入並建立索引，之後以語意搜尋取出最相關的片段餵給模型。這裡值得注意的是它與代理迴圈的關係：檢索結果是進到代理的上下文，而不是另外開一條問答管線。也就是說，同一個對話可以先用知識庫回答內部文件問題，再讓代理去瀏覽器查外部資料。切塊策略、嵌入模型選擇、向量儲存後端這三件事在 README 中都沒有著墨，只寫了「chunked, embedded, and indexed automatically」。對要導入的人來說，這意味著你無法從文件判斷更換嵌入模型時是否需要重建整個索引，也無法預估大量文件下的檢索延遲。這些是評估階段就該在測試環境量測的項目，不是上線後才發現的問題。
安裝：一行指令與幾個環境變數
README 給的安裝路徑很短。macOS、Linux、WSL 用 curl 把 install.sh 抓下來執行，Windows 用 PowerShell 的 irm 管線執行 install.ps1，安裝程式會下載最新 release 並在 14000 埠啟動，完成後開 http://localhost:14000。Windows 是原生執行，README 明確寫了不需要 WSL 也不需要 Docker，這對內網 Windows 機器的部署是實際利多。可選的環境變數有三個：OPENAGENT_VERSION 指定版本、INSTALL_DIR 指定安裝目錄、BIN_DIR 指定二進位檔目錄。從原始碼建置則需要 Go 1.25.0 以上，前端要 Node.js 20 以上與 Yarn 1.x，後端執行 go build，前端進 web 目錄跑 yarn install 與 yarn start。Docker 路線是 docker-compose up，容器起來後同樣開 14000 埠。這幾條路徑都指向同一個埠號，部署時要留意與既有服務的衝突。
Shell 執行與瀏覽器操作是最大賣點，也是最大風險面
README 把 Shell Execution 列為代理迴圈的一項能力，意思是模型可以決定執行哪些指令。這在自架個人助理的場景下很方便，但對多人共用或內網部署就是明確的攻擊面：提示注入若成功，代理手上的工具就是使用者的權限。文件沒有描述沙箱機制、權限降級或指令白名單，也沒有說明工具呼叫是否需要人工確認。同樣的顧慮適用於 Browser-Use，代理能填表與點擊，就代表它能對已登入的網站做出實際操作。這不是說設計有錯，而是採用時必須自己補上邊界：在容器裡跑、限制網路出口、把 INSTALL_DIR 與資料目錄放在可丟棄的檔案系統上。若你的場景無法接受模型自主執行 shell，那 OpenAgent 的代理迴圈對你而言就是過大的工具，應該只使用它的 RAG 與對話部分。
與 LangChain 類框架的差別：成品與零件
常被拿來對比的是 LangChain 這類函式庫。兩者解決的問題不同層次。LangChain 給你的是零件：鏈、檢索器、工具包裝，你要自己組裝成服務，也要自己處理前端、使用者管理與部署。OpenAgent 給的是已經組好的成品：一個跑在 14000 埠的服務，內建對話介面、知識庫上傳、工具管理頁與日誌頁，模型供應商清單直接列在 README 裡，涵蓋 OpenAI、Azure OpenAI、Anthropic Claude、Google Gemini、DeepSeek、Mistral、Grok、Qwen、Ollama 等三十多個。差別在控制權與彈性：用 LangChain 你可以決定每一個檢索步驟與重試邏輯，代價是你得自己寫；用 OpenAgent 你得到的是可運作的系統，代價是當它的切塊策略或迴圈終止條件不符合你的需求時，你得改 Go 原始碼或等上游。選哪一邊取決於你要的是能動的服務，還是能完全掌控的管線。
版本節奏與維護成本
release 記錄顯示 v2.90.0 與 v2.90.1 都在 2026-09-05 發布，v2.91.0 在 2026-09-07 發布，主分支最後推送時間是 2026-09-09。兩天內三個版本、且包含一次 patch，說明專案處於高頻迭代階段。這對採用者有兩個實際含義：好處是問題修得快，壞處是設定格式或 API 可能在 minor 版本間變動，而 README 沒有提供相容性承諾或升級指南。搭配 OPENAGENT_VERSION 環境變數可以把安裝鎖在特定版本，這是控制升級節奏最直接的手段。授權是 Apache-2.0，允許商用與修改，但條款細節與你既有依賴的相容性仍需自行確認，本文不構成法律意見。若你打算長期運行，先把版本固定、把資料目錄獨立出來，會比每次跟著最新版跑來得穩定。
編輯結論
如果你要的是一個能自己架、用 Go 編譯、把模型供應商與 MCP 工具集中管理的個人助理，OpenAgent 的安裝路徑短到只要一行 curl，值得在隔離環境先跑起來驗證。若你的場景需要跨節點的水平擴展、或必須審計每一次 shell 執行，先確認 INSTALL_DIR 與 BIN_DIR 指向哪裡、Docker 映像檔的資料落地位置，再決定是否導入。文件沒有交代的並行模型與沙箱邊界，應以你實際部署的版本為準。
社群筆記