OpenLobster 出現了：有人把 OpenClaw 的架構從頭重寫了一遍
昨天在 Reddit r/openclaw 看到一篇帖子，OpenLobster 團隊出來解釋為什麼要 fork OpenClaw——措辭很有意思，他們特別強調「這不是在批評 OpenClaw」，但洋洋灑灑列了一堆 OpenClaw 解決不好的問題。
先說他們指出的幾個核心痛點：
多使用者環境下的 MEMORY.md 衝突。 這個我其實深有體會。OpenClaw 的記憶體設計本來就是單人、單機的思路，MEMORY.md 是純文字檔，沒有任何 concurrent write 保護。如果你在同一個 instance 上跑多個 agent task，寫入邏輯很容易互相踩踏。
heartbeat-scheduler 的局限性。 OpenClaw 的定時任務機制設計偏輕量，對需要精確調度的生產環境不夠友好。
MCP 的 production readiness。 MCP 還很新，生產化部署的細節還在打磨中。
安全預設過於寬鬆。 開源工具為了降低使用門檻，預設配置往往犧牲安全性——這在 OpenClaw 身上也有體現。
OpenLobster 的解法是：用 graph memory 取代平鋪的 MEMORY.md、加入 RBAC 權限管理、cron scheduler、加密的 secrets 管理，然後整個用 Go 重寫，聲稱啟動速度更快、記憶體佔用更低，還附上了 dashboard setup wizard 和多資料庫支援。
如果拉長時間線來看，這個 fork 的出現很有意義。
OpenClaw 從一開始就定位成「個人 AI 助理」，設計哲學是讓一個人、一台電腦有一個強大的 AI 夥伴。這套邏輯在個人使用情境下很好——輕量、上手快、社群活躍。
但當有人想把它用在團隊或企業環境，問題就出現了。多使用者、權限管理、高可用、audit log——這些不是 OpenClaw 不在乎，而是它根本沒有設計成要解這些問題。
OpenLobster 的出現，某種程度上讓我想到 WordPress 跟 Ghost 的關係：一個是給所有人的，一個是給有明確需求的人的。兩者定位截然不同，但不見得互斥。
有意思的是，他們選擇用 Go 重寫，而不是在原本的 Node.js 基礎上改。這不只是技術偏好，更是一種信號——Go 的生態本來就更靠近後端和 infra 工程師，他們想吸引的用戶群體跟 OpenClaw 的核心社群不一樣。
這個 fork 最後能不能活下去，很大程度上取決於它能不能找到夠多「需要規模化、又想留在 OpenClaw 生態」的用戶。AI agent 工具的 fork 成功率歷來不高，但如果企業採用真的起來，這個需求缺口是真實存在的。
大家有沒有在用 OpenClaw 跑多使用者或團隊協作的場景？遇到了什麼架構上的問題？
作者：搖擺熊