深度解析：Moltbot 底層架構

讓我們先來看張截圖（GitHub README）：

截圖裏作者列了一長串開源項目，第一眼很容易以為只是“堆料”或者“太卷”。但真去看 Moltbot 的依賴和調用關係，你會發現這些東西不是裝飾品，而是地基。更直白點說，沒有這套依賴生態，就不會有 Moltbot 現在的形態。

Moltbot 的“縫合”不是隨便粘一粘，而是帶着明確目標做的系統整合：用一套自己的控制面把不同軟件服務串起來，把原本互不相通的數據和操作通道打通，然後逐步 “Agent 化”——讓它們從“只能人點來點去”變成“可以被模型調度執行”的能力模塊。

1. 設計哲學

Moltbot^[1]（前身為 Clawdbot）的出現，並非僅僅是為了在日益擁擠的 AI 助手市場中增加一款競品，而是為了構建一種全新的技術範式——主權 AI (Sovereign AI) 與操作系統即界面 (OS-as-Surface) 。這種設計哲學深刻地影響了其底層架構的選擇，使其從根本上區別於依賴雲端 API 的傳統 SaaS 模式 AI。

1.1 Moltbot 是什麼

Moltbot 是一個“長期運行的 Gateway 控制面”：它統一接入多種消息渠道（WhatsApp / Telegram / Discord / Slack / …），並通過 WebSocket 控制平面協議把 UI/CLI/自動化/移動節點連接起來；在 Gateway 內部運行（或調用）一個 agent runtime（Pi 系列），把“消息 → 上下文 → 工具調用 → 回覆/動作 → 持久化”串成可觀察的 agent loop。架構總覽：

         Chat Channels (WhatsApp/Telegram/Discord/Slack/…)
                            │
                            ▼
                    Moltbot Gateway (daemon)
     - owns channels connections
     - WS control plane + HTTP surfaces (Control UI, Canvas host)
     - agent loop execution + queues + session storage
     - tools router (browser/nodes/exec/cron/…)
                            │
        ┌───────────────────┼─────────────────────┐
        ▼                   ▼                     ▼
   Operator Clients        Nodes              Plugins/Skills
 (CLI / Web UI /      (iOS/Android/      (channels/tools/ui
  macOS app /         macOS/headless)     schema/hooks/skills)
  automations)

可以從四個“設計取向”理解 Moltbot：

1. 控制面優先（Gateway-first）：把多渠道/多客戶端/多節點統一到一個可觀測的 control plane（WS + 事件流 + 策略），讓 UI/CLI/自動化都圍繞同一協議演進。
2. 本地優先（Local-first）：會話與狀態以本地文件/本地存儲為主；模型既支持雲端 provider，也支持本地 provider（例如 Ollama），並提供 failover/輪換機制。
3. 主機能力即工具面（OS-as-surface）：把“本機/某台設備才能做的事情”抽象為 node command，並用權限與審批把安全邊界前置：例如 macOS app 作為 node 暴露 system.run、Canvas、Camera、Screen Recording，並可選託管 PeekabooBridge。
4. 技能與外部工具生態（Poly-tools）：大量能力通過“外部 CLI + Skills 指導”方式接入（例如 imsg、peekaboo、bird、gog、gifgrep、sonos 等），Moltbot 負責能力編排、門控（能力准入控制）、審批與審計。

1.2 數據主權與本地優先的架構命令

Moltbot 架構的首要原則是“主權”。在 Peter Steinberger 的構想中，真正的個人助理必須擁有對用戶生活的最深層理解——從財務記錄、私人通信到情感狀態——而這些數據絕不能流向由大型科技公司控制的雲端服務器。這一原則在技術上體現為本地優先 (Local-First) 的強制性約束。

為了實現這一點，Moltbot 被設計為一個在用戶自有硬件（如 Mac Studio、Linux 服務器或 Raspberry Pi）上運行的持久化進程，而非僅僅是一個無狀態的客戶端 。其“記憶”系統不依賴於向量數據庫服務的遠程託管，而是直接以 Markdown 文件（如 USER.md、SOUL.md）的形式存儲在本地文件系統中。這種架構決策帶來的技術後果是：

• 零延遲的上下文訪問：Agent 可以毫秒級讀取本地狀態，無需等待網絡 I/O。
• 物理級的數據控制：用戶可以通過系統級權限控制 Agent 對文件的讀寫，甚至直接通過刪除文件來“遺忘”記憶，實現了數據治理的物理閉環。
• 去中心化的身份認證：身份驗證邏輯下沉至 Gateway 層，而非依賴 OAuth 提供商，確保了系統即便在斷網狀態下（Localhost）也能維持基本的控制平面功能。

1.3 操作系統即界面 (OS-as-Surface)

傳統的 AI 代理往往被封裝在瀏覽器插件或獨立的 Electron 應用中，其操作邊界被限制在應用的沙箱內。Moltbot 則提出了 OS-as-Surface 的概念，即操作系統本身就是 AI 的交互界面。

這一理念在架構上表現為對 CLI (Command Line Interface) 的極度推崇。Peter Steinberger 認為，相比於構建複雜的 GUI 或死板的 API（如 Model Context Protocol），Unix 風格的命令行接口是 AI 代理最自然的語言。因為 LLM (Large Language Model) 在預訓練階段已經接觸了海量的 Shell 腳本和系統文檔，它們天生就能理解如何組合 grep、awk、curl 等工具來解決未曾預設的問題。

因此，Moltbot 的底層架構並未試圖構建一個全能的“上帝應用”，而是構建了一個能夠靈活調用系統工具鏈的編排引擎。它通過子進程生成 (spawn) 和標準輸入/輸出 (stdio) 管道，賦予了 Agent 直接操作底層的能力。例如，處理音頻文件時，Agent 不會調用一個內部的音頻庫，而是直接在 Shell 中執行 ffmpeg 命令。這種設計極大地降低了系統的耦合度，使得 Moltbot 具備了類似生物體的“自愈”和“進化”能力——如果缺少某個功能，它甚至可以編寫並執行一個新的腳本來填補空白。

1.4 應用消融 (The Melting Away of Apps)

Moltbot 架構的長遠目標是促成“應用消融”的趨勢。隨着 Agent 能夠直接操作數據和邏輯層，傳統的圖形界面應用程序將逐漸退化為單純的數據 API 或完全消失。

在 Moltbot 的生態中，這一趨勢通過 Skills (技能) 系統得以實現。一個 Skill 本質上是一份標準化的描述文件 (SKILL.md)，它指導 Agent 如何使用特定的 CLI 工具來完成任務。這意味着，用戶不再需要打開“天氣應用”來查看天氣，也不需要打開“圖片編輯器”來調整尺寸；Agent 會根據 SKILL.md 的指示，直接調用 curl wt.tr 或 imagemagick^[2] 來完成任務。這種架構將計算還原為最本質的“輸入-處理-輸出”過程，剝離了冗餘的交互層。

2. Gateway 協議設計 & 通信架構

Moltbot 的技術心臟是 Gateway (網關)。它不僅僅是一個簡單的消息轉發器，而是一個功能完備的控制平面 (Control Plane)，負責協調分佈式的節點、管理異構的通信信道，並維護系統的全局狀態。

2.1 Hub-and-Spoke 網絡拓撲

Gateway 採用經典的 Hub-and-Spoke (輪輻式) 網絡拓撲結構。

• Hub (Gateway 進程): 通常運行在用戶的核心計算設備上（如 Mac Studio 或 Linux 服務器），監聽默認端口 18789。它是唯一的真理來源 (Single Source of Truth)，維護着所有活躍會話 (Session) 的狀態機、消息隊列以及設備節點的註冊表。
• Spokes (客戶端與節點): 所有的交互表面——無論是 WhatsApp/Telegram 的消息輪詢進程、移動端的 iOS/Android 應用，還是 Web 控制枱——都作為客戶端連接到 Gateway。

這種拓撲結構的關鍵優勢在於狀態的一致性。無論用戶是通過 WhatsApp 發送消息，還是通過終端輸入指令，所有的請求都會匯聚到 Gateway 進行統一的路由和處理。這解決了多端同步的難題，使得用戶可以在手機上開始一段對話，回到電腦前無縫繼續，因為對話的上下文 (Context) 駐留在 Hub 端，而非分散在各個客戶端。

2.2 WebSocket 協議與雙向通信

Gateway 放棄了傳統的 RESTful API，轉而採用全雙工的 WebSocket (WS) 協議作為核心通信機制。這一選擇是由 Agent 系統的實時性需求決定的。

2.2.1 協議握手與認證 (Handshake & Auth)

連接建立的過程經過了嚴格的安全設計。

• 連接發起：客戶端（如 Android 節點）向 ws://<gateway-ip>:18789 發起連接請求。
• 令牌驗證：在握手階段，客戶端必須提供預先生成的 auth token。這個 Token 是在系統初始化的“孵化 (Hatching)” 階段生成的，並存儲在受保護的配置文件中。
• 設備配對 (Pairing Flow): 對於無法直接複製 Token 的移動設備，Moltbot 實現了一套類似藍牙配對的流程。設備請求配對並展示短碼，管理員通過 CLI 工具 (moltbot pairing approve) 授權該請求。這一過程利用了帶外驗證 (Out-of-Band Verification)，確保了即使在不安全的局域網環境中也能建立受信任的連接。
• TLS Pinning: 為了防禦中間人攻擊 (MitM)，特別是在公共 Wi-Fi 環境下使用 Tailscale 穿透時，移動節點實現了 TLS Pinning，強制驗證 Gateway 證書的指紋，確保通信鏈路的絕對私密性。

2.2.2 節點能力廣播 (Node Advertisement)

連接建立後，Gateway 協議定義了一套能力發現機制。客戶端不會被動等待，而是主動聲明其作為“節點 (Node)” 的能力 。

• node.list & node.describe: 客戶端發送包含自身能力清單的 JSON Payload。例如，一個 iPhone 節點可能會廣播它擁有 ["camera.snap", "location.get", "notification.send"] 等能力。
• 能力映射: Gateway 內部維護一張動態路由表，將特定的功能映射到對應的 WebSocket 連接 ID。當 Agent 決定“拍一張照片”時，Gateway 能夠根據這張路由表，精確地將指令推送給擁有攝像頭的 iPhone 節點，而不是發送給沒有攝像頭的 Linux 服務器。

2.2.3 消息路由與 TypeBox 模式

為了保證消息結構的嚴謹性，Moltbot 廣泛使用了 TypeBox^[3] 庫來定義和驗證 JSON Schema。

• 結構化負載: 所有的 WebSocket 消息——無論是聊天文本、工具調用請求還是系統事件——都必須符合預定義的 TypeBox Schema。這消除了動態類型語言中常見的運行時錯誤，確保了 Gateway 在處理高併發消息時的穩定性。
• 事件總線: Gateway 內部實現了一個事件總線，負責將入站消息 (Inbound Messages) 路由到正確的 Session Lane，並將出站事件 (Outbound Events) 廣播給所有訂閲的客戶端。

Client                    Gateway
  |----- req:connect -------->|
  |<---- res:hello-ok --------|
  |<---- event:tick ----------|
  |----- req:health --------->|
  |<---- res:health ----------|

2.3 遠程訪問與 Tailscale 集成

在“本地優先”的前提下，Moltbot 如何解決遠程訪問問題？架構明智地選擇了與 Tailscale^[4] 進行深度集成，而不是重新發明輪子。

• Tailscale Serve: Gateway 可以通過 Tailscale Serve 暴露在用戶的私有 Tailnet 網絡中。這意味着 Gateway 依然綁定在安全的 Loopback 接口上，但通過 Tailscale 的虛擬網卡被遠程設備訪問。這種方式利用了 Tailscale 的 WireGuard 隧道，無需在防火牆上開放端口，極大地收斂了攻擊面。
• Tailscale Funnel: 對於必須通過公網訪問的場景（例如接收 GitHub Webhook 回調），Gateway 支持 Tailscale Funnel，將其安全地通過 HTTPS 暴露給公網，同時支持基於密碼的訪問控制。

3. Agent Loop 運行機制

如果說 Gateway 是身體，那麼 Agent Loop (代理循環) 就是 Moltbot 的大腦。它負責接收輸入、執行推理、調用工具並生成輸出。這一過程並非線性的，而是一個遞歸的、狀態驅動的循環。

3.1 Pi Runtime 與 RPC 架構

Agent Loop 的核心運行時環境被稱為 Pi（源自 @mariozechner/pi-agent-core^[5]）。為了保證系統的健壯性，Pi Runtime 採用了 RPC (Remote Procedure Call) 模式與 Gateway 通信。

• 進程隔離: Pi Runtime 作為一個獨立的進程運行，通過 RPC 接口與 Gateway 交換數據。這種解耦設計意味着即使 Agent 的推理邏輯因為處理超大文件而崩潰，Gateway 依然能夠保持存活，並能重啓 Agent 進程，實現了類似 Erlang 系統的容錯能力。
• 塊流式傳輸 (Block Streaming): 與傳統的“一次性生成”不同，Pi Runtime 支持塊流式傳輸。它能夠將推理過程中的“思考 (Thoughts)”、“工具調用 (Tool Calls)” 和“最終回覆 (Final Response)” 作為獨立的數據塊實時流式傳輸給 Gateway。這使得用戶能夠實時看到 Agent 的思維過程（Internal Monologue），極大地提升了交互的透明度和信任感。

3.2 思考層級 (Thinking Levels)

Moltbot 引入了 Thinking Levels (思考層級) 的概念，允許用戶動態調整 Agent 的認知深度。

• 多級調節: 系統支持從 off（關閉思考，直接回復）到 xhigh（極高深度思考）的多個層級。
• 模型路由: 不同的思考層級可能會觸發不同的模型路由策略。低層級可能路由到響應速度快的模型（如 Claude Haiku 或本地量化模型），而高層級則會調用推理能力更強的模型（如 Claude Opus 4.5、GPT-5.2 等），並在 Prompt 中注入更復雜的思維鏈 (Chain-of-Thought) 指令。
• 持久化配置: 這一配置是基於 Session 持久化的，意味着用戶可以為處理複雜代碼的 Session 設置 high 級別，而為日常閒聊的 Session 設置 low 級別，系統會自動記憶這些偏好。

3.3 自適應壓縮保障 (Adaptive Compaction Safeguard)

長上下文遺忘 (Context Amnesia) 是所有基於 LLM 的 Agent 面臨的共同難題。Moltbot 通過 Adaptive Compaction Safeguard 機制，在架構層面解決這一問題。這一機制不僅僅是簡單的消息截斷，而是一套複雜的內存管理策略：

• 動態分塊 (Adaptive Chunking): 當任務上下文接近模型窗口限制時，系統會自動將大型任務拆解為更小的原子單元。
• 遞歸摘要: 系統會對歷史對話進行遞歸式的摘要處理，保留關鍵的決策節點和事實信息，同時丟棄冗餘的對話噪音。
• 內存刷寫 (Memory Flush): 在執行壓縮之前，Agent 會觸發 before_compaction 鈎子，提示模型將當前上下文中的重要信息寫入長期存儲（如 memory/ 目錄下的 Markdown 文件），確保關鍵知識不會因壓縮而丟失。
• UI 反饋: 壓縮過程的狀態會實時推送到 UI，避免用戶在 Agent 進行後台維護時感到困惑。

3.4 語音交互循環 (Voice Loop)

針對語音場景，Agent Loop 實現了特殊的 Talk Mode。

• VAD 集成: 利用本地的語音活動檢測 (Voice Activity Detection) 算法，Agent 能夠精準判斷用戶的語音結束點，從而實現類似人類對話的“插話”和“輪替”機制，無需反覆喚醒。
• Voice Wake: 在 macOS 和移動節點上，系統支持低功耗的 Voice Wake（語音喚醒），通過設備端的本地模型監聽喚醒詞，保護隱私的同時提供 Always-on 的體驗。

4. 會話模型 (Session Model) & 併發控制

Moltbot 的強大之處在於它不僅僅是一個單線程的聊天機器人，而是一個支持多任務併發和多 Agent 協作的系統。這依賴於其精細設計的 Session Model。

4.1 會話泳道 (Session Lanes) 與隊列機制

為了在異步的 Node.js 環境中保證數據的一致性，Moltbot 引入了 Session Lanes (會話泳道) 的概念。

• 互斥鎖機制: 架構保證在同一時間，只有一個 Agent 實例能夠操作同一個 Session Lane。這通過純 TypeScript 實現的 Promise 隊列來管理，避免了引入 Redis 等外部依賴，保持了架構的輕量化。
• 請求排隊: 如果用戶在 Agent 尚未完成上一個任務時發送了新消息，新消息會自動進入該 Session 的隊列中等待 (queued for X ms)。這種機制防止了競態條件 (Race Conditions)，確保 Agent 不會在處理 A 任務的中途被 B 任務打斷而導致狀態錯亂。

4.2 Agent-to-Agent (A2A) 協作

Moltbot 的 Session 模型原生支持 Agent-to-Agent (A2A) 通信，這是實現複雜工作流的關鍵。通過 sessions_* 工具集，Agent 獲得了“感知”和“交互”其他 Agent 的能力：

• sessions_list: 允許 Agent 查詢當前系統中還有哪些活躍的 Session，以及它們的元數據（如運行的模型、當前的上下文摘要）。
• sessions_history: 允許 Agent 讀取其他 Session 的歷史記錄，從而獲取上下文信息，實現知識共享。
• sessions_send: 這是一個極其強大的原語，允許 Agent A 向 Agent B 發送消息。它支持 Ping-Pong 模式，即 Agent A 發送消息後掛起，等待 Agent B 處理完畢並返回結果。

應用場景推演：這種架構支持了“分層指揮”模式。主會話 (Main Session) 中的 Agent 可以作為“指揮官”，當接到“分析全網輿情”的任務時，它可以生成三個子 Session，分別指派不同的角色（如“推特分析員”、“新聞聚合員”、“數據清洗員”），並通過 sessions_send 下發指令。子 Agent 在獨立的沙箱中並行工作，最後將結果彙總回主 Session。這種設計不僅提高了效率，還增強了安全性，因為高風險操作可以被限制在低權限的子 Session 中。

4.3 狀態持久化

Gateway 負責 Session 狀態的持久化。所有的會話配置——包括 thinkingLevel、verboseLevel、sendPolicy 以及當前使用的模型——都會通過 WebSocket 的 sessions.patch 方法實時同步並寫入磁盤 (sessions.json) 。這確保了即使系統重啓，Agent 也能“記得”它之前的性格設定和工作模式。

5. 協議集成 & 生態擴展

Moltbot 的開放性體現在其對標準化協議的支持上，特別是 ACP^[6] (Agent Client Protocol) 和 A2UI^[7] (Agent-to-User Interface)。

5.1 ACP Bridge：連接 IDE 的橋樑

ACP 是一個旨在標準化 IDE 與編碼 Agent 之間通信的開放協議。Moltbot 通過 ACP Bridge 實現了這一協議，使其能夠被 VS Code、Zed 等編輯器直接驅動。

• 協議轉換層: moltbot acp 進程充當了轉換網關。它在標準輸入/輸出 (stdio) 上講 ACP 的 JSON-RPC 語言，而在 WebSocket 端講 Moltbot 的 Gateway 協議。
• 會話映射: 為了解決 IDE 會話（臨時）與 Gateway 會話（持久）之間的生命週期差異，Bridge 維護了一張映射表。它將 IDE 生成的 ephemeral session ID 映射到 Gateway 內部持久的 session key（如 agent:main:main）。這意味着用戶關閉 IDE 再重新打開，Agent 依然保留着之前的上下文記憶，這是傳統 LSP (Language Server Protocol) 難以實現的。

5.2 A2UI：生成式用戶界面

為了突破純文本交互的限制，Moltbot 集成了 A2UI 協議，允許 Agent 實時生成圖形界面。

• Canvas Host: Gateway 內置了一個輕量級的 Web 服務器 (Canvas Host，默認端口 18793)，專門用於渲染 A2UI 組件。
• 聲明式 UI: Agent 不直接生成 HTML/JS（這存在安全風險且難以維護），而是生成描述 UI 意圖的 JSON Payload（例如：“我需要一個包含日期選擇器和提交按鈕的表單”）。
• 原生渲染: Canvas Host 接收到 Payload 後，將其渲染為原生組件（如 Web Components、React、Flutter、SwiftUI 等）。這種架構使得 Agent 可以在對話中即時構建“微應用 (Micro-Apps)”，例如一個臨時的投票界面或數據可視化儀表盤，極大地擴展了交互的維度。

# Canvas Host Server：從 canvasHost.root 目錄提供靜態的 HTML/CSS/JS 資源
# Node Bridge：將 Canvas URL 發送/同步給已連接的各個節點
# Node Apps：在 WebView 中渲染這些內容

┌─────────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Canvas Host    │────▶│   Node Bridge    │────▶│  Node App   │
│  (HTTP Server)  │     │  (TCP Server)    │     │ (Mac/iOS/   │
│  Port 18793     │     │  Port 18790      │     │  Android)   │
└─────────────────┘     └──────────────────┘     └─────────────┘

6. 工具鏈 & 生態系統

Moltbot 的強大能力在很大程度上歸功於其創造者 steipete 開發的一系列配套工具鏈。這些工具不僅僅是插件，而是構成了 Agent 感知世界的“器官”。

6.1 Peekaboo：機器視覺與無障礙控制

Peekaboo 是 Moltbot 的視覺中心，它利用 macOS 的原生 API 為 Agent 提供了“看”和“操作” GUI 的能力。

• 混合枚舉策略: 為了解決截圖延遲問題，Peekaboo 採用混合枚舉策略。它優先使用 ScreenCaptureKit 進行高性能的屏幕捕獲，同時利用 CGWindowList 快速定位窗口座標。
• 無障礙 API (Accessibility API): Agent 通過 node.invoke 調用 Peekaboo，利用 macOS 的 Accessibility API (AXUIElement) 遍歷 UI 樹。peekaboo see 命令會返回一個經過剪枝的 JSON 結構，描述當前屏幕上的按鈕、輸入框及其座標。
• 操作閉環: Agent 解析 JSON 後，發出 peekaboo click 或 peekaboo type 指令，從而能夠操作那些沒有 CLI 接口的遺留軟件。這種設計讓 Moltbot 的能力邊界拓展到了整個 GUI 桌面。

6.2 bird 與 sweet-cookie：身份與社交

為了讓 Agent 在互聯網上擁有“真實”的身份，steipete 開發了配套的身份驗證工具。

• sweet-cookie^[8]: 這是一個瀏覽器 Cookie 提取庫。它能夠繞過瀏覽器運行時的數據庫鎖定，直接從 Chrome/Safari 的加密存儲（如 macOS Keychain）中解密並提取認證 Cookie。這使得 Moltbot 能夠繼承用戶在瀏覽器中已經登錄的會話，無需用戶手動複製粘貼 API Key 或 Token，極大降低了使用門檻。
• bird: 一個基於 GraphQL 的 Twitter/X 客戶端。結合 sweet-cookie，它允許 Moltbot 以用戶的身份瀏覽推文、發佈內容，甚至進行社交互動，完全模擬人類用戶的行為模式。

6.3 SKILL.md 標準與 Nix 集成

Moltbot 的擴展性建立在 SKILL.md 標準之上。

• 自然語言編程: Skill 的定義不再是複雜的代碼，而是一份 Markdown 文檔。其中的 YAML Frontmatter 定義元數據（依賴、權限），而正文則是用自然語言描述“如何使用這個工具”。Agent 在運行時讀取這些文檔，通過語境學習 (In-Context Learning) 掌握新技能。
• Nix Flakes: 為了解決依賴地獄問題，Moltbot 引入了 Nix。Skill 可以被打包為 Nix Flake，確保其依賴的二進制工具（如 summarize、imsg 等）在一個隔離的、可復現的環境中運行，不會污染宿主系統。

以下是通過 Nix 打包的工具，提供給 Moltbot（nix-moltbot^[9]），這些都是文章開頭截圖中出現的項目：

• summarize^[10]：總結 URL、PDF、YouTube 視頻內容
• Peekaboo^[11]：屏幕截圖，它的內部依賴了多個項目，比如 AXorcist^[12]、Tachikoma^[13]、TauTUI^[14]、Commander^[15]、Swiftdansi^[16]
• oracle^[17]：網頁搜索
• Poltergeist^[18]：點擊、輸入、控制 macOS UI
• sag^[19]：文本轉語音（TTS）
• camsnap^[20]：從已連接的攝像頭拍照
• go-cli^[21]：集成 Google 日曆
• bird^[22]：集成 Twitter/X
• sonoscli^[23]：控制 Sonos 音箱
• imsg^[24]：發送/讀取 iMessage 信息
• ...

7. 安全架構 & 防禦縱深

給予 AI 如此高的系統權限，必然伴隨着巨大的安全風險，Moltbot 構建了多層防禦體系。

7.1 最小權限原則與 TCC 映射

在 macOS 上，Moltbot 嚴格遵循 TCC (Transparency, Consent, and Control) 機制。Gateway 能夠感知並廣播當前的權限狀態。如果 Agent 試圖執行一個需要屏幕錄製權限的操作（如 peekaboo see），而該權限未被授予，協議層會直接返回 PERMISSION_MISSING 錯誤，而不是靜默失敗或嘗試繞過。

7.2 Docker 沙箱隔離

對於非主會話（如來自 Discord 羣組的請求）或執行不受信代碼，Moltbot 支持 Docker 沙箱。

• 隔離環境: Agent 在一個臨時的 Docker 容器中運行，擁有容器內的 root 權限，但無法訪問宿主機的文件系統或網絡（除非顯式透傳）。
• 臨時性: 會話結束後，容器即被銷燬，確保沒有任何惡意狀態殘留。

7.3 嚴格的 DM 策略

針對外部消息渠道，Moltbot 默認採用 DM Pairing 策略。這意味着任何未知的 Direct Message 都會被攔截，系統僅向用戶展示一個配對碼。只有當擁有者在受信任的控制枱手動輸入該配對碼並授權後，外部用戶才能與 Agent 進行交互。這有效地防止了提示注入攻擊 (Prompt Injection) 和垃圾信息的騷擾。

8. 結語

Moltbot 的技術架構展示了一種成熟且極具前瞻性的 AI 系統設計。它並沒有跟隨主流去構建另一個聊天機器人，而是試圖構建一個 AI 原生的操作系統層。通過 Gateway 實現控制平面的統一，通過 OS-as-Surface 理念打通系統底層，再通過 A2UI 和 ACP 連接上層應用，Moltbot 實際上定義了一套完整的“主權 AI” 基礎設施標準。

技術交流羣：公眾號發送 “molt” 可獲取二維碼

References