深度解析：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” 基础设施标准。