LobsterAI 拆解：Electron 桌面殼與 OpenClaw 執行層的分工

它要解決的是「檔案在你機器上」這件事

多數雲端 AI 助理的邊界很清楚：你把內容貼進去,它把結果吐回來。問題出在中間那段。當任務需要讀取本機的 product-growth.xlsx、需要開瀏覽器看廣告後台的實際數字、需要把一個資料夾裡的履歷整理成篩選表,貼上貼下的成本就超過了 AI 省下的時間。LobsterAI 的定位就是補這段,README 把它描述成能操作「local files, terminal commands, browser workflows, documents, spreadsheets, slides, IM channels, scheduled jobs, and project workspaces」的桌面 Agent。

目標使用者不是要自己寫 agent 框架的工程師,而是每天在 Excel、Word、簡報與內部系統之間搬資料的人。README 的範例提示詞很能說明這一點：用 Excel 追蹤進銷存的人,請它「建一套本機庫存系統,記錄進出貨、算出庫存與利潤、可以在瀏覽器打開」;人資請它把整個資料夾的履歷轉成篩選表並對照 JD 排序。這些任務的共同點是輸入是本機檔案、輸出要能直接拿去用。

它同時服務第二種人：想自建 agent 但不想從零處理 Electron、權限、持久化與 IM 接入的開發者。這一層的價值在後面幾節會看得比較清楚。

Cowork 與 OpenClaw 的分工線

README 把架構講得很直接：Cowork 是產品與會話層,OpenClaw 是底下的執行與閘道層。這條分界線決定了什麼東西存在哪裡。

留在桌面程式這一側的,是本地持久化、權限、UI 狀態、產物、agents、memory 與 IM 綁定。會話與應用資料存在本機 SQLite;OpenClaw 的工作區記憶則用檔案形式保存,README 點名了 MEMORY.md、USER.md、SOUL.md 與每日筆記。這種安排讓偏好設定與專案脈絡能跨會話延續,而不是每次重開都從空白開始。

交給 OpenClaw 的是代理執行本身。中間的轉接層在 README 裡有具體名字：openclawEngineManager、openclawConfigSync、openclawRuntimeAdapter 與 coworkEngineRouter,負責把 LobsterAI 的狀態翻譯成 OpenClaw 執行時的行為。反過來說,使用者在 LobsterAI 裡設定的 MCP server 會存在本機,再把已啟用的那些同步進 OpenClaw。

Electron 這一側的切分也寫在 README 的 How It Works。Renderer 是 React、Redux Toolkit、Tailwind,加上產物渲染器、設定、agent 與會話介面、技能、MCP、排程任務與 IM 設定。Main process 管 Electron 生命週期、IPC、SQLite 持久化、認證、日誌、OpenClaw 啟動、runtime repair、技能同步、IM 閘道與產物服務。值得注意的是 runtime repair 這一項的存在本身,它暗示 OpenClaw 執行時被視為需要修復的對象,而不是一次裝好就不管的依賴。

28 個內建技能與 Expert Kits 的兩層選法

LobsterAI 出廠帶 28 個技能,設定檔在 SKILLs/skills.config.json。README 列出的範圍涵蓋網頁搜尋、Word 文件、試算表、PowerPoint、PDF 處理、Remotion 影片生成、瀏覽器自動化、圖像與影片生成、股票研究、內容寫作、email、天氣,以及技能建立本身。技能建立被放進來,意味著這份清單被當成起點而非終點。

在技能之上還有一層 Expert Kits,把能力選擇與參考資料打包成情境導向的組合。README 特別強調 kits 與直接技能是獨立選取的,所以一個工作流可以同時用策劃好的 kit 和個別工具。這個設計的實際意義是：你不需要為了用一個 PDF 技能而接受整套文件處理 kit,反過來也不會因為裝了 kit 而被迫關掉某個單項技能。

多 Agent 是第三層。每個自訂 Agent 有自己的身份、模型選擇、技能、工作目錄、啟用狀態與 IM 綁定。Main Agent 留給一般工作,專門化的 Agent 對應可重複的角色。多實例的 IM 平台可以把不同帳號或頻道綁到不同 Agent,這是把「哪個 agent 在回答我」變成可設定項,而不是靠提示詞猜。

從原始碼跑起來的實際門檻

桌面安裝檔可以從官網或 GitHub Releases 取得,支援 macOS 與 Windows。想從原始碼跑,README 給的條件比一般前端專案多一項。

Node.js 必須落在 >=24.15.0 <25 這個區間,不能是 22 LTS,也不能是 25。npm 是基本。第三項是關鍵：需要 git 與 pnpm,「needed on the first run to build the pinned OpenClaw runtime from the sibling ../openclaw checkout」。也就是說 OpenClaw 不是從 npm registry 拉下來的依賴,而是必須存在於 LobsterAI 上一層目錄的同層 checkout,首次執行時由 pnpm 建置。

流程是：

git clone https://github.com/netease-youdao/LobsterAI.git cd LobsterAI npm install

首次開發執行用 npm run electron:dev:openclaw。等 pinned OpenClaw runtime 建好之後,日常開發改用 npm run electron:dev。Renderer 的 dev server 在 http://localhost:5175。

其餘指令在 README 的 Developing 段落：npm run build 產出正式 renderer bundle,npm run compile:electron 編譯 Electron 的 main 與 preload TypeScript,npm test 是 CI 用的 Vitest 入口,npm run lint 對整個 src 跑 ESLint。README 對 lint 的說明很坦白：「may expose existing legacy debt」,所以把 lint 接進 CI 之前要有心理準備。

審批關卡與 IM 遠端控制的張力

README 說 LobsterAI 在敏感動作前會要求批准,點名的是檔案操作、終端機指令與網路存取。這個機制對本機 agent 是必要的,因為它動的是你真正的檔案系統,而不是沙箱。

但同一份 README 也列出 IM 遠端控制,可從微信、企業微信、釘釘、飛書、QQ、Telegram、Discord、網易 IM、網易蜂、POPO 與 email 下指令。這兩件事放在一起就產生一個需要自己想清楚的問題：當你在手機上發一句話,而 agent 要改本機檔案時,審批對話框出現在哪裡。資料裡沒有描述遠端情境下的審批流程,所以我無法確認它是把請求推回 IM、是預先授權某類操作、還是等使用者回到桌面再處理。這是採用前應該實際驗證的行為,不是文件讀一讀就能回答的。

排程任務有類似的性質。README 說可以透過對話或排程任務 UI 建立週期性工作,用途包括每日新聞摘要、收件匣摘要、網站監控與週報。一個每天早上九點自動跑、會碰網路與本機檔案的任務,它的權限邊界怎麼設,README 沒有展開。

什麼情況下不該選它

第一個不適合的情境是工作全部發生在瀏覽器 SaaS 裡。如果你的資料在雲端試算表、文件在雲端硬碟、溝通在雲端 IM,那 LobsterAI 的桌面殼沒有著力點,它最有價值的部分,也就是本機檔案、終端機與瀏覽器工作流,你根本用不到。

第二個是只需要一次性問答的人。這類需求用網頁版助理就好,裝一個 Electron 40 應用程式、讓它常駐、還要處理 OpenClaw runtime 的啟動與修復,成本明顯不划算。

第三個是想把 agent 嵌進自己服務的後端開發者。LobsterAI 是桌面產品,它的會話、權限與產物都綁在 Electron 這一側;要的是可程式化的執行層,直接看 OpenClaw 本身會比透過 LobsterAI 的轉接層更直接。README 描述的 openclawEngineManager、openclawConfigSync、openclawRuntimeAdapter、coworkEngineRouter 這四個元件,存在的目的正是把桌面狀態餵給 OpenClaw,對後端整合來說這是多出來的一層。

還有一個實務上的限制：從原始碼建置需要 ../openclaw 這個同層 checkout。如果你只拿到 LobsterAI 這一個 repo,首次執行會卡在 pinned runtime 這一步。

替代路線：直接面對 OpenClaw 或留在終端機

既然 LobsterAI 的執行層就是 OpenClaw,最直接的替代方案是繞過桌面殼,直接使用 OpenClaw。差別在於你放棄了什麼：本機 SQLite 的會話歷史、產物渲染與管理、多 Agent 的身份與工作目錄設定、MCP server 的本機儲存與同步、以及那一整套 IM 閘道。這些在 LobsterAI 裡是設定畫面,在純 OpenClaw 路線裡要自己接。反過來你換到的是更少的活動零件,沒有 Electron 主程序的啟動與修復流程,也沒有 renderer 與 main process 之間的 IPC 邊界。

另一條路線是留在終端機型 agent。這類工具的形狀是：你在 shell 裡跑,它讀寫當前目錄,輸出回到終端機。它的優勢是進入成本低、可腳本化、容易放進既有的自動化流程。LobsterAI 相對多出來的是產物預覽與管理,README 列的 HTML、SVG、圖片、影片、Mermaid 圖、程式碼、Markdown、文字、文件與本機服務產物都能在桌面程式裡預覽。對要產出簡報或影片的人來說,這一層不是裝飾;對只要文字輸出的人來說,它是多餘的。

選擇的判斷點其實是產物形態。產出是檔案、圖表、簡報、影片,而且需要反覆檢視與調整,LobsterAI 的桌面殼有正當性。產出是文字或程式碼變更,終端機路線更省事。

授權、維護與版本節奏

LobsterAI 採 MIT 授權,README 的 badge 連向 LICENSE 檔案。MIT 允許商用與修改,但這只是對程式碼授權條款的描述,不構成法律意見;實際採用時要看的還有它同步進 OpenClaw 的那些 MCP server 與技能各自的上游條款,以及你透過 IM 閘道接入的平台本身的服務條款。

維護成本有幾個可觀察的來源。README 把 OpenClaw 描述成 pinned runtime,並在 main process 職責裡列了 runtime repair,這表示 OpenClaw 的版本與 LobsterAI 是綁定的,升級其中一邊可能需要另一邊跟著動。Node.js 被限制在 >=24.15.0 <25 這個窄區間,也意味著環境升級不會自動跟著社群走。

版本節奏從 release 清單看得出來相當密集：2026.9.4 與 2026.9.3 都落在 2026-09-04 同一天,前一版 2026.8.28 在一週前。這種頻率對想跟版的人是負擔,但對還在觀望的人是好消息,因為修正通常來得快。

最後一個要自己確認的點：README 沒有說明 OpenClaw 這個同層 checkout 應該對應哪個 commit 或版本。文件只說首次執行會建置 pinned runtime,沒有給出如何取得那個 checkout 的步驟。這是採用前必須先問清楚的缺口,因為它決定了 npm run electron:dev:openclaw 能不能跑完。

編輯結論

LobsterAI 適合手上有一批本機檔案與重複性辦公流程、願意接受 Electron 桌面程式常駐、並且需要從手機 IM 下指令的人；如果你的工作全在瀏覽器 SaaS 裡、或你只想在終端機跑一個輕量 agent,它的桌面殼與 OpenClaw 綑綁反而是負擔。動手前先確認三件事：Node.js 是否落在 >=24.15.0 <25 這個區間、../openclaw 這個同層 checkout 是否拿得到,以及 npm run electron:dev:openclaw 首次建置能否走完。這三項任一不成立,後面的功能都無從驗證。

官方來源

1. License: MIT
2. netease-youdao/LobsterAI on GitHub
3. Project website
4. README
5. Releases