GoClaw：把 OpenClaw 重寫成 Go 的多租戶代理閘道，值得換嗎
GoClaw - GoClaw is OpenClaw rebuilt in Go — with multi-tenant isolation, 5-layer security, and native concurrency. Deploy AI agent teams at scale without compromising on safety.
秒懂
- 它是什麼？
- GoClaw 用單一 Go 二進位檔取代 Node.js 執行環境，把多租戶隔離、三層記憶與八階段代理管線塞進一台 5 美元 VPS。它的賣點是隔離與併發，代價是 PostgreSQL 依賴與極高頻的 beta 發版節奏。
- 適合誰用？
- 如果你要的是一個能同時服務多個使用者、每個使用者有獨立工作區與加密 API 金鑰的自架代理閘道，而且團隊本來就維運 PostgreSQL，GoClaw 的 Standard 版對應的正是這個場景。若你只是想在筆電上跑幾個本地代理，Standard 版會逼你多養一套資料庫與容器，此時 Lite 版的 SQLite 路徑更合理，代價是代理上限 5 個、團隊 1 個、沒有通道整合。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
GoClaw 要解決的不是「跑一個代理」，而是「同時跑很多人的代理」
多數自架代理框架的預設假設是單一操作者：一組 API 金鑰、一份對話歷史、一個工作目錄。一旦要讓十幾個同事共用同一套部署，問題就從模型呼叫變成租戶邊界。誰的金鑰被誰用到、誰的對話歷史會被誰的檢索撈出來、誰能觸發哪些工具，這些在單人框架裡通常沒有對應的抽象層。
GoClaw 的定位寫得很直白：Multi-Tenant AI Agent Platform，多租戶 AI 代理平台。README 列出的多租戶 PostgreSQL 一項包含 per-user workspaces、per-user context files、AES-256-GCM 加密的 API 金鑰、RBAC 與 isolated sessions。這幾項合起來回答的是同一個問題：把代理平台當成內部共用服務，而不是個人工具。
目標讀者因此相當具體。要嘛是公司內部要給多個團隊開代理入口的平台工程師，要嘛是產品要對外提供代理功能、需要按使用者切分資料的後端團隊。相反地，一個人想在本機試提示詞，GoClaw 的 Standard 版是過重的選擇，README 自己也提供了 Lite 桌面版走 SQLite 路線。
它同時宣稱是 OpenClaw rebuilt in Go。重寫的動機在 README 的單一二進位段落裡：約 25 MB 的靜態 Go 二進位、不需要 Node.js 執行環境、啟動低於 1 秒、可跑在 5 美元 VPS 上。這是把執行環境成本換成編譯期成本的老套路，效果取決於你是否真的在意那個 Node 執行環境。
八階段管線與三層記憶：機制看得到，但參數要自己驗
GoClaw 的代理執行被切成固定八個階段：context、history、prompt、think、act、observe、memory、summarize。README 強調 stages 可插拔且 always-on execution，意思是每個階段都會被執行，插拔的是實作而非開關。這種固定管線的好處是行為可預期，除錯時你知道請求一定會經過哪幾站；壞處是階段之間的耦合被寫死，想在中途插入自訂步驟得順著它的介面走。
提示詞系統提供四種模式：Full、Task、Minimal、None，搭配 section gating、cache boundary optimization 與 per-session mode resolution。這裡真正有工程意義的是 cache boundary optimization，因為 Anthropic 的原生整合在 README 裡被描述為 HTTP+SSE with prompt caching。提示詞快取要命中，前綴必須穩定，而模式切換會改變前綴內容。哪種模式配哪種快取邊界最划算，README 沒有給數字，這是必須自己量測的地方。
記憶分成三層：Working 對應對話、Episodic 對應 session summaries、Semantic 對應知識圖譜，並以 L0/L1/L2 漸進載入。漸進載入的用意是避免每次呼叫都把所有歷史塞進上下文，但代價是多了一次檢索決策，檢索錯了代理就會在錯誤的前提上推理。Semantic 層依賴 pgvector，這也是 Lite 版與 Standard 版在能力上的分水嶺：Lite 只有 FTS5 文字搜尋，沒有知識圖譜。
知識庫部分以文件註冊表加 [[wikilinks]] 組織，檢索走 FTS 與 pgvector 的混合搜尋，並支援 filesystem sync。檔案系統同步聽起來方便，實際上意味著磁碟上的檔案與資料庫裡的註冊表存在兩個真相來源，同步策略與衝突處理是部署時要問清楚的細節。
啟動路徑分成兩條：桌面版一行指令，伺服器版要自己備妥 PostgreSQL 18
Lite 桌面版是安裝成本最低的入口。macOS 用 curl 抓 install-lite.sh 後接 bash，Windows 用 PowerShell 的 irm 接 iex。README 說明它是一個 Wails v2 加 React 的原生應用，約 30 MB，內建 SQLite，包含串流對話、工具、媒體、檔案附件、代理管理（上限 5 個）、provider 設定、MCP servers、skills、cron，以及帶看板的團隊任務，並從 GitHub Releases 自動更新。
要自己編譯桌面版，前置條件是 Go 1.26 以上、pnpm，以及 Wails CLI，安裝方式是 go install github.com/wailsapp/wails/v2/cmd/wails@latest。之後的建置目標是 make desktop-build 產出 .app 或 .exe，make desktop-dmg VERSION=0.1.0 產出 .dmg（僅 macOS），make desktop-dev 進開發模式並支援熱重載。桌面版走獨立版本號，用 lite-v* 標籤觸發，例如 git tag lite-v0.1.0 再 push，GitHub Actions 會建出 macOS 的 .dmg 與 .tar.gz、Windows 的 .zip，並建立 Release。
Standard 伺服器版的路徑在 README 裡被截斷了，只留下 Quick Start 的開頭，因此我無法從手上材料確認它的實際啟動指令或環境變數名稱。可以確定的是它依賴 PostgreSQL 18，README 的徽章明確標示這個版本，且多租戶、RBAC、pgvector 語意記憶、知識圖譜與七種通道都只存在於 Standard 版。若你要評估伺服器版，請直接看 docs.goclaw.sh 的 Quick Start 章節，不要靠 README 推測。
通道整合列了七個：Telegram、Discord、Slack、Zalo OA、Zalo Personal、Feishu/Lark、WhatsApp。Lite 版在對照表中這一欄是空的，代表桌面版沒有這些接入能力。如果你的使用情境是讓代理在 Slack 裡回答同事問題，桌面版直接出局。
Lite 與 Standard 的差距不是效能，是能力清單
README 給了一張對照表，把它當成選型的第一道篩子最有效率。Lite 的代理上限 5 個、團隊上限 1 個且成員 5 人，Standard 兩者皆無上限。資料庫一邊是本地 SQLite，一邊是 PostgreSQL。記憶一邊是 FTS5 文字搜尋，一邊是 pgvector 語意檢索。通道、知識圖譜、RBAC 與多租戶這三列，Lite 全部是空的。
這張表透露的設計取向是：Lite 不是 Standard 的縮小版，而是拿掉所有需要伺服器基礎設施的功能後剩下的單機形態。它保留的是對話、工具、MCP、skills、cron 與看板任務，也就是個人或小團隊的日常使用面。一旦你需要跨使用者的資料隔離、需要語意檢索、需要把代理接進既有通訊軟體，就只能走 Standard。
反過來說，如果你的需求剛好落在 Lite 覆蓋的範圍內，硬上 Standard 只是多背一個 PostgreSQL 實例與容器編排。README 對 Standard 的描述提到 Docker 與 binary 兩種更新方式，這暗示它至少支援容器化部署，但具體映像檔名稱與 compose 檔內容不在我手上的材料裡。
還有一個容易被忽略的細節：兩者用不同的版本線。桌面版走 lite-v* 標籤，伺服器版走 v3.15.0-beta.* 這條線。這意味著升級節奏與相容性問題要分開追蹤，不能假設桌面版的更新會連帶修好伺服器版的問題。
五層權限與 beta 發版節奏，是這個專案最需要壓力的兩個地方
安全性方面，README 列出五層權限系統、速率限制、提示詞注入偵測、SSRF 防護與 AES-256-GCM 加密。這些名稱本身沒有問題，問題在於它們全部是行銷層級的列舉，沒有任何一項附上實作說明、繞過條件或誤判率。提示詞注入偵測尤其如此：這類偵測器天生在誤擋與漏擋之間取捨，README 沒有說它偏向哪一側，也沒有說偵測到之後是拒絕、降級還是記錄。要把它放進生產環境，這些行為必須從原始碼或文件確認。
發版節奏是第二個要正視的點。近期三個版本分別是 v3.15.0-beta.208、v3.15.0-beta.207、v3.15.0-beta.206，日期落在 2026 年 9 月 8 日到 9 日之間，也就是一天內推進多個 beta 序號。預設分支是 dev。這種節奏對早期採用者意味著修得快，對要跑生產的團隊意味著版本號幾乎不能當相容性承諾。若你要採用，請鎖定一個具體 tag 並自行驗證，不要讓部署跟著 dev 浮動。
授權是第三個，而且是最硬的一個。儲存庫的 License 欄位標示為 NOASSERTION，README 的徽章則寫 CC BY-NC 4.0。CC BY-NC 的 NC 指非商業性使用，這與一個主打多租戶、面向團隊部署的平台放在一起是矛盾的訊號。NOASSERTION 代表 GitHub 無法自動識別授權檔，可能只是檔案格式問題，也可能是授權本身尚未定案。兩種讀法都指向同一個動作：在投入整合之前，向維護者確認商用授權條件。我不是律師，這不構成法律意見，但把 CC BY-NC 當成寬鬆開源授權來規劃產品是明確的風險。
維護成本上，Go 單一二進位確實降低了執行環境的負擔，但多租戶 PostgreSQL、pgvector 擴充、知識圖譜與七種通道的憑證管理並沒有因此消失，只是從 Node 生態搬到 Go 與資料庫維運。README 提到內建 LLM 呼叫追蹤與可選的 OpenTelemetry OTLP 匯出，這對已經有 OTLP 收集端的團隊是好消息，但前提是那個收集端已經存在。
替代方案要看你缺的是哪一層：多租戶抽象，還是代理編排
GoClaw 自稱是 OpenClaw 的 Go 重寫，因此最直接的比較對象就是 OpenClaw 本身。差別不在功能清單，而在執行模型：OpenClaw 走 Node.js 執行環境，GoClaw 編譯成約 25 MB 的靜態二進位，README 稱啟動低於 1 秒。如果你的痛點是容器映像檔太大、冷啟動太慢、或不想在生產機上維護 Node 依賴樹，這個差異是實質的。如果這些都不是你的痛點，重寫本身不構成換過去的理由，因為功能面兩者高度重疊。
另一個方向是走通用代理編排框架，自己接資料庫與通道。這條路換來的是彈性，代價是你得自己實作多租戶隔離、金鑰加密與會話切割，而這正是 GoClaw 花力氣的地方。判斷標準很簡單：如果你的租戶邊界可以用「一個部署服務一個團隊」打發，通用框架加幾個實例就夠了；如果你需要單一部署內的使用者級隔離，GoClaw 現成的 per-user workspaces 與 RBAC 省下的是設計與實作時間。
還有一條路是自己寫一層薄閘道，把請求轉給各家模型 API。這在單一供應商、單一通道的情境下完全可行，而且維運面積最小。它會失效的時刻是當你需要跨供應商切換、需要提示詞快取、需要把對話歷史與知識檢索串進管線，這些正是八階段管線與三層記憶在處理的事。
值得注意的是，GoClaw 的差異化主要落在隔離與併發這兩個詞上，而不是模型能力。它支援 20 多個供應商，包含 Anthropic 的原生 HTTP+SSE 與 prompt caching、OpenAI 相容端點、以及 Claude CLI、Codex、ACP 這類本機代理路徑。供應商數量本身不是護城河，隔離機制才是它相對同類專案值得被單獨評估的部分。
編輯結論
如果你要的是一個能同時服務多個使用者、每個使用者有獨立工作區與加密 API 金鑰的自架代理閘道，而且團隊本來就維運 PostgreSQL，GoClaw 的 Standard 版對應的正是這個場景。若你只是想在筆電上跑幾個本地代理，Standard 版會逼你多養一套資料庫與容器，此時 Lite 版的 SQLite 路徑更合理，代價是代理上限 5 個、團隊 1 個、沒有通道整合。採用前先確認兩件事：儲存庫的 LICENSE 標示為 NOASSERTION，但 README 徽章寫的是 CC BY-NC 4.0，商用前必須向維護者確認實際授權；其次，預設分支是 dev，近期發版全部是 beta 序號，請確認你要鎖定的具體 tag 而非跟隨 dev。
社群筆記