深入 Clawdbot的底層運作原理
每個人都在談 Clawdbot，但真正了解其內部運作的人並不多。我花了一些時間研究 Clawdbot（又稱 Moltbot）的架構，發現它在 Agent 執行、工具使用與瀏覽器自動化方面有著相當精妙的設計。對 AI 工程師而言，這裡有許多關於打造可靠、生產級 AI 系統的寶貴經驗。
從根本層面理解 Clawdbot 的運作方式，不僅能掌握它的功能，更重要的是能看清它的強項與侷限。這趟探索始於一個簡單的問題：Clawdbot 是如何處理記憶的？這套系統又有多可靠？
讓我們一層層剝開來看。
Clawdbot 到底是什麼？
Clawdbot 這幾天實在是火到人盡皆知，它是一款個人助理，可以在本機執行或透過模型 API 存取，就像滑手機一樣方便，但它的底層究竟是如何拼接起來的？
從核心來看，Clawdbot 是一個 TypeScript CLI 應用程式。
不是 Python、不是 Next.js、也不是網頁應用程式。
它是一支在你電腦上執行的程式，會開放一個 Gateway Server 處理所有互動渠道連線（Telegram、WhatsApp、Slack 等），對 LLM API 發送請求（Anthropic、OpenAI、本機模型等），在本機執行工具，並在你的電腦上完成任何你需要的工作。
透過本機 CLI 應用程式的形式執行，Clawdbot 能直接存取你的檔案系統、執行 Shell 命令、控制瀏覽器，這些都是純雲端方案難以企及的能力。
架構解析：一則訊息的旅程
為了理解整體架構，讓我們追蹤一則訊息從輸入到輸出的完整流程。
第一階段：Channel Adapter
Channel Adapter 負責接收訊息，並進行正規化與附件擷取等處理。不同的通訊平台與輸入來源各有專屬的 Adapter。這層抽象讓 Clawdbot 無論你是透過 Telegram、Slack 或其他頻道傳訊，內部都使用相同的語言溝通。
第二階段：Gateway Server
Gateway Server 扮演任務與工作階段的協調中心，負責接收訊息並分派到正確的 Session。可以把它想成 Clawdbot 的心臟，將訊息傳送到正確的目的地，同時處理多個重疊的請求。
為了將操作序列化，Clawdbot 採用以 Lane 為基礎的命令佇列。每個 Session 有專屬的 Lane，而低風險、可並行的任務（如 cron jobs）則可在平行 Lane 中執行。
這種做法與散落在程式碼各處的義大利麵式 async/await 寫法形成鮮明對比。過度並行化會損害可靠性，並帶來一大堆除錯噩夢。
設計哲學：預設串行，刻意並行
如果你有開發 Agent 的經驗，應該對此深有體會。這個觀點也與 Cognition 在 2025 年中發表的《Don’t Build Multi-Agents》一文不謀而合。
如果每個 Agent 都用簡單的 async 設定，最後只會得到一堆交錯混亂的垃圾。Log 變得難以閱讀，若 Agent 之間共享狀態，Race Condition 就會成為開發過程中揮之不去的陰影。
Lane 是佇列之上的抽象層，讓序列化成為預設架構，而非事後補救。身為開發者，你只需正常寫程式碼，佇列會幫你處理 Race Condition。
思維模式從「我需要鎖定什麼？」轉變為「什麼東西可以安全地並行？」
這是一個深刻的思維轉換。不是從並行出發再加上限制，而是從安全出發，只有在確認安全後才明確選擇並行。
第三階段：Agent Runner
這裡是 AI 真正登場的地方。Agent Runner 會判斷該使用哪個模型、選擇 API Key（若目前的 Key 都無法使用，會將該設定檔標記為冷卻中並嘗試下一個），並在主要模型失敗時回退到其他模型。
Agent Runner 會動態組裝 System Prompt，納入可用工具、技能與記憶，再加上來自 .jsonl 檔案的 Session 歷史紀錄。
接著，這些組裝好的內容會傳給 Context Window Guard，確認是否有足夠的上下文空間。若上下文接近滿載，系統會透過摘要壓縮 Session，或優雅地終止。
第四階段：LLM API Call
LLM 呼叫本身會串流回應，並對不同供應商維持一層抽象。若模型支援，還可以請求 Extended Thinking。
這層供應商抽象對系統韌性是關鍵性的！若某個 API 掛掉或達到速率限制，系統能無縫切換到替代方案，使用者完全不會察覺任何中斷。
第五階段：Agentic Loop
若 LLM 回傳工具呼叫，Clawdbot 會在本機執行該工具，並將結果加回對話。這個流程會反覆進行，直到 LLM 回傳最終文字，或達到最大回合數（預設約 20 回合）。
這就是神奇之處：Computer Use
代理迴圈是現代 AI 助理強大能力的核心，它不只是回答問題，而是採取行動、驗證結果，並持續迭代直到任務完成。
第六階段：Response Path
這部分相當標準，回應會透過頻道回傳給你，Session 以基本的 JSONL 格式持久化，每一行都是一個 JSON 物件，包含使用者訊息、工具呼叫、執行結果、回應等。這就是 Clawdbot 記憶的方式：基於 Session 的記憶。
Clawdbot 如何記憶
沒有完善的記憶系統，AI 助理就跟金魚差不多。Clawdbot 透過兩套系統來解決這個問題：
第一，如前所述的 JSONL Session 記錄。
第二，以 Markdown 格式儲存的記憶檔案，位於 MEMORY.md 或 memory/ 資料夾。
搜尋功能採用向量搜尋與關鍵字比對的混合機制，兼具兩者優點。
因此，搜尋「authentication bug」時，既能找到提及「auth issues」的文件（語意匹配），也能找到完全符合的詞組（關鍵字匹配）。
向量搜尋使用 SQLite，關鍵字搜尋則使用 FTS5（同為 SQLite 擴充功能）。Embedding 供應商可自行設定。
系統還具備智慧同步功能，當 File Watcher 偵測到檔案變更時自動觸發。
這些 Markdown 記憶檔是由 Agent 本身透過標準的「write」檔案工具產生的。沒有特殊的記憶寫入 API，Agent 就只是寫入 memory/*.md。
每當新對話開始時，會有一個 Hook 擷取前一次對話，並將摘要寫入 Markdown。
出乎意料的簡單
Clawdbot 的記憶系統出奇地簡單，沒有記憶合併，沒有每月或每週的記憶壓縮。
這種簡單性可能是優勢，也可能是隱患，就看你從哪個角度看。但我始終偏好可解釋的簡單，而非複雜的義大利麵。
記憶會永久保存，舊記憶與新記憶的權重基本相同，可以說完全沒有遺忘曲線。
這個設計選擇有其影響。一方面，重要資訊不會遺失；另一方面，過時的資訊與當前知識具有相同權重，在長期運行的系統中可能導致混淆。
Clawdbot 如何使用你的電腦？
這是 Clawdbot 的護城河之一：你把電腦交給它，讓它自由使用。那它到底怎麼操作電腦？基本上跟你想像的差不多。
Clawdbot 賦予 Agent 相當大的電腦存取權限，風險由使用者自行承擔。它使用 exec 工具在以下環境執行 Shell 命令：
Sandbox（沙盒）：預設模式，命令在 Docker 容器中執行以確保隔離。
Host（主機）：直接在你的電腦上執行，適用於需要完整系統存取權限的任務。
Remote（遠端）：在遠端裝置上執行，適用於分散式工作流程。
除了 Shell 存取，Clawdbot 還具備檔案系統工具，可讀取、寫入與編輯檔案。
基於 Playwright 的瀏覽器工具能提供網頁的語意快照。
程序管理工具（Process Tool）可執行背景長時間命令、終止程序等。
安全性（？）
與 Claude Code 類似，系統提供允許清單，讓使用者決定哪些命令需要核准，選項包括：允許一次、永遠允許、拒絕並提示使用者。
安全命令（如 jq、grep、cut、sort、uniq、head、tail、tr、wc）已預先核准。
危險的 Shell 結構則預設封鎖
安全機制與 Claude Code 的設計非常相似
核心理念是：給予使用者允許範圍內最大程度的自主權。
這種做法將重大責任交給使用者。他們必須清楚自己在核准什麼，並了解授予廣泛權限的潛在後果。
瀏覽器：語意快照
瀏覽器工具的主要方式並非使用螢幕截圖，而是採用語意快照（Semantic Snapshot），也就是頁面無障礙樹（ARIA）的文字表示。
這種做法帶來以下幾個顯著優勢：
大幅縮小的資料量：螢幕截圖可能高達數個MB，但語意快照是以KB為單位，Token 成本也只是圖片的一小部分。
確定性互動：透過無障礙角色識別元素，比依賴像素座標更可靠。
無需視覺模型：基於文字的處理比圖像理解更快、更便宜。
與無障礙標準一致：使用與螢幕閱讀器相同的結構，確保元素定位的穩健性。
對 AI Agent 而言，瀏覽網站未必需要依賴視覺。語意結構已提供導航、表單填寫與資料擷取所需的一切。
給我的啟發？
擁抱刻意的序列化
以 Lane 為基礎的佇列架構告訴我們：並行性應該是爭取來的，而非預設假設。從串行執行出發，再明確選擇並行，能打造更可預測、更易除錯的系統。
保持記憶系統的可解釋性
Clawdbot 記憶系統出乎意料的簡單，證明了複雜的 AI 不需要複雜的基礎設施。JSONL 檔案與 Markdown 提供的透明度，是帶有自動壓縮功能的複雜向量資料庫所無法比擬的。
給 Agent 真正的工具
「Computer Use」能力顯示，真正的 Agent 力量來自實際的系統存取，而非只是 API 封裝。一個能讀取檔案、執行命令、控制瀏覽器的 Agent，可以解決純靠提示詞無法觸及的問題。
為優雅降級而設計
整體架構在每個層級都包含回退機制：API 失敗時切換模型、Context Window 將滿時壓縮上下文、多種執行環境可供選擇。生產系統需要這種韌性。
語意優於視覺
瀏覽器的語意快照方法展現出了一個有趣的實務：許多我們認為是視覺的任務，實際上是結構性的。擷取這種結構比處理像素更可靠、更高效。
這意味著？
Clawdbot 的架構代表了一種關於 AI 助理的特定哲學：它們應該是本機的、有能力的、透明的。在你電腦上執行、具有直接檔案系統存取權限的 TypeScript CLI，與只能看到你貼上內容的純雲端方案有著根本差異。
這種本機優先的做法有其取捨。設定更複雜，安全責任落在使用者身上。但換來的能力相當可觀。
隨著 AI 助理持續演進，我們很可能會看到本機與雲端方案之間、簡單與複雜記憶系統之間、串行與並行架構之間的持續辯論。Clawdbot 在這些面向上的選擇提供了一個連貫的答案，優先考量可靠性、可解釋性與使用者控制。
這個架構並非完美。缺乏記憶壓縮可能在極長時間範圍內造成問題。安全模型需要熟悉技術的使用者。語意快照方法在結構不良的網站上會失效。
但理解這些取捨，能幫助我們對於該使用哪些工具、如何打造自己的系統做出明智決策。這才是研究底層運作原理的真正價值。