Hotdry.
归档
ai-systems

Moltworker 架构解析：无服务器环境下的 AI Agent 持久化执行模型

深入分析在 Cloudflare Workers 无服务器环境中运行 AI Agent 的工程挑战，涵盖 Sandbox 隔离执行、R2 状态持久化与 AI Gateway 集成策略。

在过去的几年里，自托管 AI Agent 领域经历了一场硬件「军备竞赛」。以 Moltbot 为代表的个人助理型 Agent 需要 24/7 运行在用户自己的服务器上，这直接催生了大量用户购买 Mac mini 来承载这些工作负载。然而，有没有可能摆脱对专用硬件的依赖，在云端无服务器环境中同样实现可靠的 Agent 持续运行？Moltworker 项目给出了答案 —— 它是一套中间件 Worker 和适配脚本的组合，允许在 Cloudflare Sandbox SDK 和开发者平台 API 上运行完整的 Moltbot 实例。本文将从工程实现角度剖析其核心架构，重点讨论无服务器环境下的持久化执行模型、状态管理策略以及各组件的协同机制。

无服务器运行时约束与架构选型

Cloudflare Workers 的执行模型与传统服务器存在本质差异。每个请求触发一个短暂的执行上下文，请求结束后相关资源即被回收。这种 ephemeral 特性与 AI Agent 需要维护长周期状态的需求形成了根本矛盾。Moltworker 的解决方案是引入多层架构分解：将入口路由、身份验证、API 代理等功能放在传统 Worker 中执行，而 Agent 核心运行时则运行在 Sandbox 容器内。这种分层带来了几个关键优势：入口层可以充分利用 Workers 的全球边缘网络实现低延迟接入；Sandbox 容器则提供完整的 Node.js 运行时环境，不受 Workers 10ms CPU 限制的约束。

根据 Cloudflare 官方数据，当前 Workers 对 NPM 最流行 1000 个包的支持率已达到 98.5%，仅 15 个包因涉及构建工具、CLI 工具或纯浏览器依赖而无法运行。这意味着绝大多数传统 Node.js 应用无需重大重构即可迁移至 Workers 生态。Moltbot 本身并不强制依赖这些兼容性特性，因为它的大部分代码本来就在容器内运行，但这一进展为从零构建新的 AI Agent 应用提供了坚实基础 —— 开发者可以将更多业务逻辑直接放在 Workers 层执行，而将沙箱环境留给真正需要隔离或持久化的组件。

Sandbox 隔离执行与容器生命周期管理

Sandbox SDK 是 Moltworker 架构的核心基础设施。它建立在 Cloudflare Containers 之上，但封装了底层的容器生命周期管理细节，提供了一套开发者友好的 API 用于执行命令、管理文件、运行后台进程以及暴露服务。典型的使用模式如下：首先通过 getSandbox() 获取一个沙箱实例，然后可以使用 mkdir() 创建项目结构、exec() 执行系统命令、runCode() 直接运行代码片段。以下是一个简化的初始化流程示例：

import { getSandbox } from '@cloudflare/sandbox';

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const sandbox = getSandbox(env.Sandbox, 'moltbot-instance');
    
    // 挂载 R2 存储桶作为持久化文件系统
    await sandbox.mountBucket('moltbot-state', 'state-bucket');
    
    // 初始化 Moltbot 工作目录
    await sandbox.mkdir('/workspace/moltbot', { recursive: true });
    
    // 启动 Moltbot Gateway 进程
    await sandbox.exec('node moltbot-gateway.js', {
      detached: true
    });
    
    return new Response('Moltworker initialized');
  }
};

Sandbox 容器本质上仍然是短暂的 —— 容器删除后内部数据即会丢失。这是无服务器架构的固有特性，但通过 sandbox.mountBucket() 方法，可以将 R2 存储桶挂载为容器的文件系统分区。这样就获得了一个保证跨越容器生命周期的本地目录，Moltbot 可以安全地在其中存储会话记忆文件、历史对话记录以及其他需要持久化的资产。工程实践中建议将挂载点设为 Agent 的唯一标识路径，避免不同实例之间的状态混淆。

状态持久化的分层存储策略

Moltworker 采用分层存储架构来平衡性能与持久性需求。在最底层，R2 对象存储承载大体积、非结构化的状态数据，包括对话历史存档、会话快照、文件附件等。R2 的优势在于其 S3 兼容的 API 设计以及无出口带宽费用的计费模型 —— 这对需要频繁读取状态的 Agent 尤为重要。配置 R2 存储时需要定义绑定名称（通常为 R2_BUCKET）、存储桶名称以及访问凭证。在 wrangler.toml 中的典型配置如下：

[[r2_buckets]]
binding = "R2_BUCKET"
bucket_name = "moltbot-state"

[vars]
MOLTBOT_STORAGE_PATH = "/workspace/moltbot/.state"

对于结构化查询需求，D1 数据库承担元数据索引和配置管理的职责。D1 是 Cloudflare 提供的 SQLite 边缘数据库，支持标准 SQL 语法和 ACID 事务。一个典型的 Agent 状态表结构可能包含会话标识符、创建时间戳、最近活跃时间、状态快照引用以及扩展配置字段。工程实践中建议为高频查询路径（如按会话 ID 查找）创建索引，同时利用 D1 的 Prepared Statement 机制防止 SQL 注入。

在内存层面，Worker 自身的 KV Namespace 可以缓存热点数据，如用户偏好设置、速率限制计数器等。这种多层架构的设计原则是：热数据尽可能靠近执行层（内存 / KV），温数据使用 D1 结构化查询，冷数据归档至 R2 对象存储。开发者需要根据 Agent 的具体行为模式设计数据流转策略，例如在每次长轮询周期结束后将内存状态同步至 R2，在容器重启时从 R2 恢复至内存。

AI Gateway 与模型路由的工程配置

AI Gateway 在 Moltworker 架构中扮演统一入口和智能路由的角色。它位于 Agent 运行时与各 AI 提供商之间，提供集中式的可见性、成本控制和故障切换能力。Moltbot 默认支持 Anthropic Claude 模型，而通过 AI Gateway 可以实现零代码变更的模型切换。部署流程分为几个步骤：首先在 Cloudflare 控制台创建新的 Gateway 实例，然后启用 Anthropic 提供商并配置 API 密钥或统一账单信用点，最后将 ANTHROPIC_BASE_URL 环境变量指向 Gateway 端点即可。

AI Gateway 的真正价值在于其内置的模型回退机制。当主模型因速率限制、临时不可用或响应超时而失败时，Gateway 可以自动切换至备用模型，确保 Agent 的持续运行。配置回退策略时需要指定模型优先级列表和故障阈值。以下是一个典型的 Gateway 配置示例，展示了如何在请求失败时从 Claude 3.5 Sonnet 回退至 GPT-4：

{
  "name": "moltbot-gateway",
  "provider": "anthropic",
  "api_secret": "ANTHROPIC_API_KEY",
  "fallbacks": [
    {
      "provider": "openai",
      "model": "gpt-4",
      "max_retries": 3,
      "timeout_ms": 30000
    }
  ],
  "caching": {
    "ttl_seconds": 300,
    "similarity_threshold": 0.85
  }
}

统一账单模式进一步简化了多模型场景下的财务管理。用户只需在账户中充值信用点，AI Gateway 即可自动处理与各提供商的结算，避免了管理多组 API 密钥的复杂性。对于日均调用量在数千次级别的个人 Agent 实例，统一账单的成本通常低于单独采购各提供商的 API 配额。

浏览器渲染与 MCP 技能注入

现代 AI Agent 的一个核心能力是 Web 自动化 —— 浏览网页、填写表单、捕获截图。Moltworker 通过 Cloudflare Browser Rendering 实现这一能力，而无需在 Sandbox 容器内自建 Chromium 实例。技术实现上采用 CDP（Chrome DevTools Protocol）代理架构：在 Sandbox 容器与 Moltbot Worker 之间建立一个 CDP 转发通道，将容器内的浏览器控制请求代理至 Cloudflare 边缘运行的 Browser Rendering 服务。

工程配置的关键在于 CDP 代理路由和技能注入。代理模块位于 src/routes/cdp.ts，负责监听容器内的 CDP 连接并转发至正确的 Browser Rendering 端点。技能注入则在 Sandbox 启动时完成，通过加载一个预置的 Browser Rendering 技能模块，使 Moltbot 运行时能够识别本地的 CDP 端口并执行浏览器任务。从 Moltbot 的视角来看，它只看到了一个本地的 Chrome Debugging Port，整个代理过程完全透明。

MCP（Model Context Protocol）支持是另一个重要的集成点。通过 MCP，Agent 可以动态加载外部工具能力，而浏览器渲染 MCP 允许 Agent 直接调用 Cloudflare 提供的浏览器自动化 API。配置 MCP 客户端时需要指定服务器端点、认证方式以及超时参数。对于需要在多个平台（Telegram、Discord、Slack）间切换的多通道 Agent，MCP 提供了一种标准化的工具发现与调用机制。

身份验证与访问控制的零信任实践

将 Agent API 和管理界面暴露在公网需要严格的安全防护。Moltworker 采用 Cloudflare Zero Trust Access 实现身份验证和访问控制，无需编写任何认证逻辑代码。Zero Trust Access 的工作原理是：在用户请求到达原点之前，Cloudflare 首先拦截并要求用户通过预设的登录方式完成身份验证，验证通过后会在请求中注入 JWT 令牌，原点 Worker 只需验证令牌有效性即可确认请求来源。

配置 Zero Trust Access 涉及定义应用程序策略、选择登录方法（支持邮箱验证码、OAuth、SSO 等多种方式）以及设置可访问的路由。生产环境中建议至少启用双因素认证，并限制管理界面的访问来源 IP 范围。Zero Trust Access 还提供详细的访问日志和用户行为分析，这对于审计 Agent 操作记录、检测异常行为模式非常有价值。

从架构安全性的角度评估，Moltworker 的分层设计本身也体现了纵深防御理念：最外层是 Cloudflare 的 DDoS 防护和 WAF，中间层是 Zero Trust Access 的身份验证，入口层 Worker 负责 API 路由和速率限制，Sandbox 容器则通过进程隔离限制恶意代码的影响范围。这种多层次的安全边界大大提高了部署在公网的 Agent 系统的抗攻击能力。

生产部署的参数调优建议

将 Moltworker 投入生产使用时，需要关注几个关键参数的调优。首先是 Sandbox 容器的资源配置：默认的 CPU 和内存限制可能无法支撑复杂的长时间 Agent 会话，建议根据实际负载逐步调整容器规格，并设置内存使用上限告警。其次是 R2 存储的生命周期策略 —— 配置合适的对象过期规则可以有效控制存储成本，同时避免历史数据无限膨胀。

对于 24/7 持续运行的 Agent 实例，需要特别关注容器保活机制。Cloudflare Sandboxes 目前不提供内置的自动重启策略，实践中可以结合 Workers 的 Cron 触发器实现健康检查与自动恢复：每 5 分钟发起一次内部心跳请求，检测 Agent 响应状态；若连续多次无响应，则触发容器重建流程。

监控层面建议开启 AI Gateway 的详细日志记录，跟踪模型调用延迟、Token 消耗、错误率等指标。R2 和 D1 的使用量可以通过 Cloudflare 仪表板或 API 定期拉取。对于多用户共享部署的场景，还需要在 D1 中实现租户隔离表前缀，确保不同用户的状态数据互不干扰。

资料来源

本文核心架构参考自 Cloudflare 官方博客《Introducing Moltworker: a self-hosted personal AI agent, minus the minis》（2026 年 1 月 29 日）以及 Moltworker 开源仓库。Node.js 兼容性数据来源于 Cloudflare 内部 NPM 包支持实验，AI Gateway 配置参数参考官方开发者文档。

查看归档