首先，本文不是安裝教程，其次，我用的是 imessage📩
我最近試了 Clawdbot（已經改名 Moltbot）。下面我們直接使用
這篇記錄的是一個律師視角的第一手體驗：它到底是什麼、值不值得現在折騰，以及它把我推回了哪些更重要的基本功。
一、它是什麼，以及我為什麼暫時不建議安裝
Moltbot 是一套偏自託管的個人助理執行底座：
你在自己的機器上跑一個常駐的中控程序，把多個訊息渠道當作統一入口，再把訊息路由給不同的 agent / tools 去處理，最後把結果回到原渠道。
我比較喜歡它的記憶實現：用幾份 Markdown 檔案當作長期上下文（IDENTITY / USER / TOOLS / HEARTBEAT / SOUL）。改動這些檔案，就等於改了它的風格、邊界和持續性。
我自己的一個小技巧是：把任務輸出目錄放到堅果雲同步資料夾裡。
它在小主機上跑完任務，我在主力機開啟同步目錄就能看到結果，也能直接看到它自動整理出來的分類資料夾。
像是在團隊合夥辦公了。
它的熱度一度讓 Mac mini 出現了「洛陽紙貴」的行情，二手價也被帶動。
但我現在不太建議大多數律師立刻安裝。
它是一個助理版的雛形，能力還在補充中，安裝與運維的摩擦也不少。
雖然有 UI，但是頁面、配置都還不是很友好。
另外，改名與遷移也帶來了一段混亂期：專案從 Moltbot 改為 Moltbot，生態遷移過程中，npm 包名一度出現被搶佔或誤導的風險。
還有人用它的名字去發比特幣... 略顯魔幻。
想試的話，建議走官方指令碼或直接從原始碼安裝，但會更麻煩一些。
更重要的是，如果你還沒把自己的流程、模板和材料沉澱成上下文資產，常駐、多渠道、自動化只會把「garbage in, garbage out」放大。
帶著這個前提試用，關心的不是某個功能點，而是它把助理做成常駐、多渠道、可自動化的形態之後，個人工作的路由與上下文治理會怎麼變化。
二、在 Moltbot 之前：我的路由實驗
在 Moltbot 出現之前，我也一直在探索一種更個人化的工作路由機制。
實現思路很簡單：用一個統一的 CLI 入口承接所有任務，然後讓一個路由 agent 基於常規工作資料夾與組織規範來做判斷。
我手搓的 Vibe Working System 雛形（我的個人介紹是真的）
比如我丟給它一個檔案，它先決定要不要做預處理，再判斷後續要 cd 到哪個目錄裡繼續處理。
而那個目錄的配置裡，放的就是對應專案的 skill 配置與預設規則，然後靠 Claude Agent SDK 來接入 AI Agent 的能力。
這類工作看起來像折騰系統，但並不白做。本質依然是上下文工程與上下文治理。
把結構、邊界和預設動作想清楚，換什麼工具都能很快上手，因為底層邏輯是相同的。
三、Agent 助理的演變線
Manus 這類雲端虛擬機器，把執行環境放在雲上。它擅長把任務跑完，但上下文與許可權被隔離在沙盒裏。
Claude Code 這類本地終端形態，把執行環境拉回本機。
它能貼著你的檔案、專案、目錄結構做事，上下文厚度立刻不一樣。我現在常規的工作都是在 VS 裡面配合 Claude Code 來完成的，當然更多的還是檔案的收集、整理與輸出。
再往後走到 Cowork，這條線開始更關注如何更好地組織與處理內容，以及讓更多人不靠終端也能用起來，這是形態上易用性的轉變。
Moltbot 站在另一側：它把入口從你開啟它變成它隨時接應你（穩穩地接住你🫴）。
你在不同渠道發一句話，它都能當作同一條工作流的入口。
而所謂常駐加多渠道加自動化的形態，落到工程上，要靠一箇中控來協調。
在這套形態裡，Gateway 是一個常駐的中控程序。
外部的訊息渠道都連到它，內部的 agent、工具、事件排程也圍著它轉。你看到的多渠道互通、自動觸發、持續執行，背後都在靠它把鏈路兜住。
它屬於個人智慧終端的控制麵，而非單點功能。
四、為什麼它現在還不是很好的形態
我對它的評價是：趨勢感強，但現在還早期。
不要因為 FOMO 而強上，我已經踩坑了。
一個原因是功能還不夠完善，很多環節需要你自己補，安裝和運維成本不低，故障點也多。甚至連 MacOS 的 app 也要自己編譯。
不過大部分人更常見的問題是：需求還沒到要上常駐閘道器的那一步。
你真正缺的往往不是入口，而是先把本機的終端與檔案系統用順。
如果你本機的 Claude Code 還沒用熟，終端習慣、檔案組織、專案結構都沒跑順，工作中的 skill / 上下文也沒有總結出來，那麼終端主機與常駐閘道器的收益很難兌現，複雜度反而會壓過收益。
本機終端是用好的第一層槓桿，常駐與多渠道纔是第二層。
貪多嚼不動。
五、常駐與自動化的前提，是你能給它足夠多的上下文
這類工具最容易讓人誤判的一點是：以為入口升級了，生產力就會自動升級。
恰恰相反，過於追求工具的前沿，反而會讓你忽略真正重要的事。
Moltbot 是，釦子的 skill 也是（後者我會單獨寫文章批評
）。
你如果沒有把自己工作流程總結出來，沒有把常用材料、模板、要點沉澱成上下文資產，那麼你讓它生成合同、寫委託材料，也只是「garbage in, garbage out」。
產出了一堆內容，沒有意義，回頭你還要花很多的時間去篩選。
給它更大許可權、更多空間只有在一個條件下才有意義：你已經知道它該沿著什麼流程走，產出該落在哪，哪些環節必須人工複覈。
六、「本地賈維斯」的判斷
Moltbot 確實可能是更接近個人智慧終端的形態。
本地 agent 天然能接觸更多上下文，尤其是檔案與專案結構，這對我們律師工作還是很友好的。再疊加大模型能力提升、引數量下降（但願），本地部署會越來越現實。
畢竟像 Mac Studio 512G 這種硬體已經能跑一些強模型的量化版本，比如 MiniMax 的 M2.1 量化版，而且能力不弱。
這會把全本地化的想象從口號拉回到工程問題，而不是存在在筆者的嘲諷中😅。
但它也會把一個問題推到臺前：當能力越來越接近真實作業系統，治理能力就不能缺席。
這正是很多習慣了刀耕火種的律師缺少的。
以後的工作方式都需要面向 agent，而不是人，所以上下文的交付很重要。
Skills Instead Of Agents：不做智慧體，先把你的專業能力寫成 Skills
你再也不能讓助理猜你想要什麼，回頭產出不合格又罵人家一頓，因為這本質上是你自己任務交代（上下文交付）的問題。
七、最終帶來的，是一次回看
Moltbot 這次體驗，最有價值的部分不是「我又多了一個工具」。
它像一個提醒：
你的系統裡到底有什麼能被自動化？
你自己的流程有沒有被寫下來？
你有沒有可授權的上下文資產？
大模型和工具是水，上下文是你造的船。
如果你什麼都沒有，先別急著追常駐閘道器——先把 Claude Code 用熟，把工作流沉澱成可複用的上下文/Skill。
這纔是真正能撬動槓桿的地方。
