一、为什么要把个人 Agent 搬上边缘云
过去半年，关于 OpenClaw 的讨论几乎都集中在”它有多能干”上：能帮你读邮件、盯网页、整理文件、跑脚本、在多个工具之间来回切换。但真正把 OpenClaw 长期跑起来的人会遇到另一个问题——它住在哪里。
大多数人的第一版是：在自己笔记本上跑，或者租一台 $5 的 VPS，nohup 一个进程或者挂一个 pm2。能用，但用三天就开始烦：笔记本合盖就断线，VPS 的时区、证书、系统升级、日志轮转都要自己管，公网 IP 暴露还需要额外做一道鉴权，一个不小心 Agent 的接口就挂在互联网上裸奔。
Moltworker 就是 Cloudflare 对这个问题的回答。它是 Cloudflare 开源的一个参考实现（Proof of Concept，概念验证），用 Cloudflare 全家桶把 OpenClaw 托管起来：Workers 做入口与编排、Sandbox Containers 跑 Agent 本体、R2 存会话与文件、Browser Rendering 提供真实浏览器、AI Gateway 做模型请求的统一出口、Zero Trust 做访问控制。
1.1 三个朴素但真实的动机
我不打算把”上云”说得多么高大上。把 OpenClaw 搬到 Cloudflare 上，能解决的其实是三个很具体的问题。
第一，无服务器意味着不用管机器。没有 SSH、没有系统补丁、没有 systemd、没有磁盘打满。对于一个”7×24 跑着但大部分时间闲着”的个人 Agent 来说，运维成本其实是最大的一块隐性支出。你不用维护，就是省钱。
第二，边缘节点带来更低的往返延迟。Cloudflare 的 Workers 跑在离用户最近的节点上，Agent 的入口层（接收消息、鉴权、转发）在全球任意位置都能在很低的延迟内响应。对个人用户来说，这一条的意义不如企业大，但如果你常出差、常在海外，感受会很明显。
第三，安全边界是内置的。这一点最容易被忽略，但在我看来最重要。个人 Agent 天然有很高的权限：它能读写你的文件、调用你的账号、执行你的命令。把它随手绑在一个公网 IP 上，风险极高。而 Moltworker 的参考架构里，Zero Trust 是标配，不是选配。
1.2 先泼一盆冷水：这仍然是 PoC
在往下讲部署之前，我必须把一句判断放在最前面：Moltworker 是参考架构，不是开箱即用的商业产品。它的价值在于”告诉你这条路可以怎么走”，而不是”给你一个按钮就能上线”。
具体表现是：你需要自己读 wrangler 配置、自己接 R2 的 bucket、自己在 AI Gateway 里建网关、自己在 Zero Trust 里建应用和策略。文档给你的是路径，不是成品。如果你期待”部署完就能用”，大概率会失望；如果你期待”用一份干净的可控架构学习如何托管 Agent”，那它非常合适。
1.3 一个容易踩的坑：$5 不等于 $5
另一个必须提前说清的事是价格。Workers Paid 计划是 $5/月起，这是真的。但”$5 起”和”持续运行要多少钱”是两个完全不同的问题。按标准的持续运行形态计算，Moltworker 的月度成本大约在 $34.50 左右，主要来自沙箱容器长时间占用、Browser Rendering 的调用、R2 存储与出站、AI Gateway 的请求以及模型本身的费用。
我在后面的成本拆解里会把它逐项展开。这里先把结论放出来：$5 是门票，$34.50 才是账单。很多教程只讲前者，这是不负责任的。
二、Moltworker 的六大组件：逐个拆开讲
理解 Moltworker 的最好方式，不是从部署命令开始，而是从架构开始。它的六个组件各自解决一个明确的问题，理解了这个分工，后面的配置项就都顺理成章了。
2.1 Workers：入口与编排层
Workers 是整个 Moltworker 的门面。它负责接收外部请求（Webhook、HTTP 调用、定时触发事件）、做初步的鉴权与路由、再把具体任务下发到沙箱容器里执行。它不跑 Agent 本体，这一点很关键——Workers 的运行环境是有资源上限的，不适合长时间驻留的重任务。
Worker 的角色更像是”调度员”：来了一个任务，它决定把哪个容器实例唤醒、用什么参数、结果写回哪里。这种入口与执行分离的设计，是从 Serverless 的经验里长出来的，好处是入口层可以无限横向扩展，坏处是多了一层状态传递的复杂度。
2.2 Sandbox Containers：真正跑 OpenClaw 的地方
沙箱容器是 Moltworker 里最”重”的部分，也是成本的主要来源。OpenClaw 需要一个完整的运行环境：Node 运行时、文件系统、可以执行命令的 shell、可能还有浏览器。这些都不能在 Worker 隔离环境里跑，必须落到容器里。
Cloudflare 的 Sandbox Containers 提供了带生命周期管理的容器能力：可以按需启动、闲置回收、状态挂载。这正好匹配个人 Agent 的使用特征——短时高并发、长时低占用。
2.2.1 为什么沙箱而不是”自己的 Docker 主机”
你可以自己在 VPS 上跑 Docker，效果差不多。区别在于：沙箱容器把”隔离、回收、调度”这三件事变成了平台职责，你不用写任何容器生命周期管理代码。代价是你被绑定在 Cloudflare 的容器模型里，控制粒度不如自建。
2.3 R2：会话、文件与快照的家
Agent 是有记忆的。OpenClaw 的会话历史、上传的文件、生成的产物、临时快照，都需要一个持久化存储。Moltworker 用 R2 来承担这一层。
选择 R2 的逻辑很直接：它和 Workers 在同一个平台，绑定配置只有几行；它没有传统云存储那种高额出站费用，对”读多写少、出站不少”的 Agent 场景更友好；它还天然可以作为沙箱容器的持久化挂载点。
2.4 Browser Rendering：给 Agent 一双真实的浏览器
OpenClaw 的很多能力依赖真实浏览器：打开网页、点击、截图、抓取需要 JS 渲染的内容、处理登录态。Browser Rendering 提供了托管的无头浏览器池，Agent 不用自己装 Chromium、不用管版本、不用处理内存泄漏。
这一项在成本上容易被低估。浏览器会话是按时间的，不是按请求的。一个没有及时关闭的页面，会持续计费。这是后面我要专门提醒的一个细节。
2.5 AI Gateway：模型请求的统一出口
Agent 的大脑是模型。AI Gateway 位于 Agent 和模型供应商之间，做三件事：统一路由（一个入口对接多家模型）、缓存与重试、观测（记录每次调用的延迟、token、错误率）。
对个人部署者来说，最实用的价值是可观测。当你发现账单超预期时，第一件事就是看 AI Gateway 的日志——是哪个任务在疯狂调用模型、是不是缓存失效了、是不是某个循环没退出。没有这层，你就是在盲猜。
2.6 Zero Trust：把 Agent 关进门内
最后一个组件是访问控制。Zero Trust 负责在 Worker 前面加一道身份验证：只有通过身份验证的请求，才能到达 Agent 的入口。
这一步在参考架构里是必做项，而不是可选项。因为个人 Agent 的权限边界很宽，一旦暴露在公网且没有鉴权，攻击者可以直接让它执行命令。Zero Trust 提供的是”身份 + 策略”的最小闭环，配合 Cloudflare Access 可以对应用做邮箱域限制、一次性 PIN、SSO 等方式的访问控制。
2.7 六大组件职责一览
把上面的六个组件压缩成一张表，方便你在配置时对照检查。
| 组件 | 在 Moltworker 中的角色 | 关键配置项 | 成本特征 | 常见坑 |
|---|---|---|---|---|
| Workers | 入口、鉴权转发、任务编排、定时触发 | wrangler.toml 的 routes、compatibility_date、绑定 | 按请求数与 CPU 时间，属于基础计划覆盖范围 | 把重任务写进 Worker 导致 CPU 超限 |
| Sandbox Containers | 运行 OpenClaw 本体与命令执行环境 | 容器规格、闲置超时、挂载点 | 按容器运行时长，是账单大头 | 闲置回收没配好，空跑烧钱 |
| R2 | 会话历史、文件、快照持久化 | bucket 名称、绑定名、生命周期规则 | 按存储量与操作次数 | 生命周期没设，快照无限累积 |
| Browser Rendering | 托管无头浏览器，供 Agent 操作网页 | 浏览器会话数、超时设置 | 按会话时长与并发 | 页面未关闭导致持续计费 |
| AI Gateway | 模型请求统一出口、缓存、观测 | 网关 ID、提供商凭据、缓存策略 | 网关本身低，模型费用另计 | 把模型密钥直接写进 Worker 环境变量 |
| Zero Trust | 访问控制与身份验证 | Access 应用、策略、身份源 | 小团队通常落在免费额度 | 策略写成 “Everyone”，等于没设 |
三、开工前的准备：账号、计划与本地环境
部署 Moltworker 的第一步不是敲命令，而是把账号和环境理顺。这一步做扎实，后面会少踩很多坑。
3.1 Cloudflare 账号与 Workers Paid 开通
Moltworker 需要 Workers Paid 计划，$5/月起。免费计划的 Workers 无法支撑沙箱容器和 Browser Rendering 这套组合，所以必须升级。
操作路径大致是：登录 Cloudflare Dashboard → 进入 Workers & Pages → 在计划页选择 Workers Paid → 绑定支付方式 → 确认升级。升级是按账号生效的，不是按单个 Worker 生效的，所以一个账号下所有 Worker 共享这个 $5 基础费。
需要提醒的是：$5 只是基础订阅，超出部分按用量计费。沙箱容器、Browser Rendering、R2 这些服务的用量都会脱离基础费单独结算。你可以在 Dashboard 的 Billing 里设置用量告警，这是防止账单失控的第一道保险。
3.2 需要提前开通的服务
把以下服务在 Dashboard 里逐个确认开通，避免部署到一半才发现某个服务没启用：
- R2：首次使用需要在 R2 页面同意条款并创建 bucket。R2 有免费额度，但需要显式开通。
- Browser Rendering：在 Workers & Pages 的 Browser Rendering 页面申请开通，通常需要等待审核或直接可用。
- AI Gateway：在 AI → AI Gateway 里创建一个网关，记下网关 ID。
- Zero Trust：首次进入需要设置团队域名（team domain），这个域名会成为你访问应用的子域前缀。
3.3 本地环境准备
本地需要 Node.js（建议 20 以上）、npm 或 pnpm、git，以及 wrangler CLI。wrangler 是 Cloudflare 的官方命令行工具，几乎所有操作都通过它完成。
# 1. 检查本地环境
node -v
npm -v
git --version
# 2. 安装 wrangler（全局或项目内皆可，建议锁定版本）
npm install -g wrangler
# 3. 登录 Cloudflare 账号（会打开浏览器授权）
wrangler login
# 4. 确认登录状态与账号信息
wrangler whoamiwrangler whoami 会输出当前账号的 ID 与邮箱，把 Account ID 记下来，后面配置文件里会用到。如果你在 CI 或服务器上部署，可以用 CLOUDFLARE_API_TOKEN 环境变量替代交互式登录，Token 需要在 Dashboard 里创建，权限选择 Workers、R2、AI Gateway 等相关项。
四、克隆仓库与部署流程
环境就绪后，进入真正的部署环节。Moltworker 的仓库托管在 Cloudflare 的 GitHub 组织下，克隆后用 wrangler 部署。
4.1 克隆与依赖安装
# 1. 克隆 Moltworker 参考实现
git clone https://github.com/cloudflare/moltworker.git
cd moltworker
# 2. 查看目录结构，重点看 wrangler 配置与 src
ls -la
cat README.md
# 3. 安装依赖（以 npm 为例）
npm install
# 4. 如果是 monorepo 结构，注意进入对应的子目录
# cd packages/worker克隆之后第一件事是读 README 和 wrangler 配置文件，而不是急着 deploy。Moltworker 作为参考实现，配置文件里预留了大量占位符，你需要逐个替换成自己的资源 ID。直接 deploy 十有八九会因为绑定缺失而报错。
4.2 创建资源：bucket 与网关
配置文件里的绑定依赖真实存在的资源，所以要先创建它们。
# 创建 R2 bucket（名称与 wrangler.toml 中保持一致）
wrangler r2 bucket create moltworker-data
# 查看已创建的 bucket
wrangler r2 bucket list
# 列出当前账号下的 AI Gateway（需在 Dashboard 先创建）
wrangler ai-gateway list 2>/dev/null || echo "请在 Dashboard → AI → AI Gateway 创建网关"
# 查看当前账号下的容器/沙箱相关资源
wrangler containers list 2>/dev/null || echo "若该子命令不可用，请以当前 wrangler 版本帮助为准"注意：wrangler 的子命令会随版本演进，部分命令（如容器、AI Gateway 的管理命令）在不同版本里名称或可用性不同。遇到命令不存在时，以 wrangler --help 和官方文档为准，不要照抄过时的教程。
4.3 配置与首次部署
资源就绪后，填写配置（下一节给出模板），然后先做一次 dry-run，再正式部署。
# 1. 本地类型检查与打包，不真正上传
npx wrangler deploy --dry-run --outdir dist
# 2. 本地开发预览（会用本地模拟绑定，便于调试）
npx wrangler dev
# 3. 正式部署
npx wrangler deploy
# 4. 查看部署状态与最近日志
npx wrangler deployments list
npx wrangler tailwrangler tail 是排查问题的主力工具，它会实时输出线上 Worker 的日志。首次部署后建议开着它，用浏览器访问一次入口，确认请求链路是否正常。
4.4 部署后的验证清单
部署成功不等于可用。按下面的顺序逐项验证，任何一项失败都要停下来定位：
- 访问 Worker 的默认域名，确认返回的是预期的入口页面，而不是 500 或 1101 错误。
- 在 Dashboard 的 Workers 日志里查看是否有绑定错误（比如 R2 binding not found）。
- 触发一次简单的 Agent 任务，确认沙箱容器被拉起，任务能返回结果。
- 检查 R2 bucket 里是否写入了会话记录，确认持久化链路通。
- 在 AI Gateway 的日志里确认有请求记录，确认模型调用确实走了网关。
- 最后才配置 Zero Trust，避免在调试阶段被自己的策略挡在门外。
五、wrangler 配置模板：逐字段讲清楚
Moltworker 的配置集中在 wrangler.toml（或 wrangler.jsonc）。下面给出一份注释充分的模板，字段名以你本地仓库的实际版本为准，写法可能随版本演进略有差异。
5.1 基础配置与绑定
# wrangler.toml —— Moltworker 部署配置模板
name = "moltworker"
main = "src/index.ts"
compatibility_date = "2024-11-01"
# 新版运行时如需 Node 兼容能力，按仓库 README 启用对应 flag
# compatibility_flags = ["nodejs_compat"]
account_id = "你的_ACCOUNT_ID"
# 入口路由：自定义域名比 workers.dev 更适合生产
routes = [
{ pattern = "agent.example.com/*", zone_name = "example.com" }
]
[vars]
# 非敏感配置放 vars，敏感信息用 secret
ENVIRONMENT = "production"
AGENT_NAME = "openclaw"
# R2 绑定：bucket_name 必须与已创建的 bucket 一致
[[r2_buckets]]
binding = "MOLT_DATA"
bucket_name = "moltworker-data"
# AI Gateway 绑定：gateway id 与 provider 按实际填写
[ai]
binding = "AI"
# 沙箱容器相关配置（字段名以仓库实际结构为准）
# [containers]
# class_name = "AgentSandbox"
# max_instances = 2
# idle_timeout_seconds = 300
# 可观测性：开启日志与采样，便于排查
[observability]
enabled = true
head_sampling_rate = 1.0几个需要额外解释的点：
5.1.1 compatibility_date 不要随手写
compatibility_date 决定了 Workers 运行时采用哪一版的兼容行为。写一个未来的日期会导致部署失败；写一个太旧的日期，可能拿不到新特性。稳妥做法是保留仓库里给的日期，或者使用 wrangler 提示的当前推荐值。不要为了”看起来新”而写一个没验证过的日期。
5.1.2 容器配置是成本闸门
如果你的仓库版本支持容器配置，max_instances 和 idle_timeout_seconds 就是控制成本的两把闸。max_instances 限制同时存在的沙箱数量，防止突发流量把账单顶穿；idle_timeout_seconds 控制空闲多久后回收。个人使用场景下，闲置超时设短一点（比如 5 分钟）能省下不少钱。
5.2 环境变量与密钥
敏感信息绝不能写进 wrangler.toml 提交到 git。正确做法是用 wrangler secret put 写入。这是 Moltworker 部署里最容易被忽视的安全细节——很多人在配置文件里直接贴模型 API Key，仓库一公开，密钥就泄露了。
# 写入密钥（交互式输入，不会出现在 shell 历史里）
npx wrangler secret put MODEL_API_KEY
npx wrangler secret put OPENCLAW_ADMIN_TOKEN
npx wrangler secret put AI_GATEWAY_URL
# 批量写入（适合 CI，从文件读取）
# echo "$MODEL_API_KEY" | npx wrangler secret put MODEL_API_KEY
# 查看已配置的密钥名称（不会显示值）
npx wrangler secret list
# 删除不再使用的密钥
npx wrangler secret delete OLD_KEY
# 本地开发时用 .dev.vars 放同样的变量，并加入 .gitignore
cat > .dev.vars <<'EOF'
MODEL_API_KEY=local-dev-key
OPENCLAW_ADMIN_TOKEN=local-dev-token
AI_GATEWAY_URL=https://gateway.ai.cloudflare.com/v1/<account_id>/<gateway_id>
EOF
echo ".dev.vars" >> .gitignore环境变量的分工建议这样划：wrangler.toml 的 [vars] 只放非敏感的开关和标识；所有密钥、Token、网关完整 URL 都用 secret；本地开发用 .dev.vars 且确保被 git 忽略。这三层分清楚，后面就不会出现”测试环境能跑、线上报 401″的情况。
5.3 配置自检的几个动作
配置写完，先跑一遍本地开发环境和一次 dry-run。如果 dry-run 能通过，说明绑定声明在语法和类型上是正确的，剩下的就是资源是否存在、权限是否足够。
# 检查配置语法与绑定是否可解析
npx wrangler deploy --dry-run
# 本地起服务，模拟绑定行为
npx wrangler dev --local
# 检查当前账号与计划，确认 Paid 已生效
npx wrangler whoami六、R2 与 AI Gateway 的接线
六大组件里，R2 和 AI Gateway 是两个最需要”接线”的部分。它们的配置正确与否，直接决定 Agent 能不能记住上下文、能不能正常调用模型。
6.1 R2：会话与文件的持久化
R2 在 Moltworker 里承担的不只是”存文件”，更关键的是让无状态的 Worker 有状态。容器可以被回收重建，但会话历史在 R2 里，Agent 下次醒来还能接上上下文。
6.1.1 目录结构建议
建议在 bucket 里用前缀把不同类型的数据分开，方便后续做生命周期规则和成本分析：
sessions/{user}/{sessionId}/：会话历史与消息记录files/{user}/{uuid}/：用户上传的文件artifacts/{date}/：Agent 生成或抓取的产物snapshots/{date}/：容器快照与临时状态
6.1.2 生命周期规则是省钱的关键
快照和日志类数据会无限增长。给它们配上生命周期规则，比事后清理要省心一百倍。在 Dashboard 的 R2 → bucket → Settings → Object lifecycle rules 里新增规则，例如让 snapshots/ 前缀在 7 天后自动删除，让 artifacts/ 在 30 天后转存或删除。
# 查看 bucket 目录内容，确认写入是否正常
npx wrangler r2 object list moltworker-data --prefix sessions/ 2>/dev/null || \
echo "以当前 wrangler 版本的 r2 子命令为准"
# 下载一个对象用于核对内容
npx wrangler r2 object get moltworker-data/sessions/<user>/<id>/history.json --file ./history.json6.2 AI Gateway：让模型调用可观测
AI Gateway 的接线分两步：在 Dashboard 创建网关，然后让 Agent 的模型请求走网关地址，而不是直连供应商。
6.2.1 创建网关与拿到网关地址
在 Dashboard 的 AI → AI Gateway 里创建网关，取一个可识别的名字（比如 moltworker-openclaw），然后记下网关 ID。通用的网关地址形态是：
https://gateway.ai.cloudflare.com/v1/<account_id>/<gateway_id>
# 针对具体提供商的路径通常是：
# https://gateway.ai.cloudflare.com/v1/<account_id>/<gateway_id>/<provider>把供应商凭据（API Key）存到网关侧或作为请求头透传，取决于你选择的管理方式。推荐把凭据存在网关侧，Worker 里只持有网关地址，这样密钥轮换只需要改一处。
6.2.2 缓存与限流策略
AI Gateway 支持缓存与限流。对个人 Agent 来说，缓存策略的收益取决于任务重复度：如果你经常让它读同一批网页、做相似总结，开缓存能明显省钱；如果任务高度一次性，缓存反而会带来”回答过时”的问题。建议先开观测，跑一周看命中率，再决定是否启用缓存。
6.2.3 用日志反查账单
这是我最看重的用法。当月底账单比预期高时，打开 AI Gateway 的请求日志，按 token 数排序，你会立刻看到是谁在烧钱。绝大多数超支都是两三个具体任务造成的：一个没有设置上限的循环、一个每次都重新拉取长文档的流程、一次忘记关掉的浏览器会话。没有网关日志，你只能靠猜。
七、用 Zero Trust 把 Agent 关进门内
前面说过，个人 Agent 的权限边界很宽。把入口暴露在公网而不加鉴权，等于把自己的电脑挂在互联网上。Zero Trust 是 Moltworker 参考架构里给这件事上的锁。
7.1 建立团队域名与身份源
首次进入 Cloudflare Zero Trust 需要设置团队域名（team domain），它会成为你在 Access 里配置应用的域名前缀。身份源（IdP）可以选择邮箱一次性 PIN（最简单，适合个人）、Google/GitHub 登录、或企业 SSO。
对个人部署，我最推荐”邮箱一次性 PIN + 邮箱白名单”。配置成本最低，安全性对个人场景足够：只有你绑定的邮箱能收到验证码，别人即使知道入口地址也进不去。
7.2 为 Worker 挂上 Access 应用
在 Zero Trust → Access → Applications 里新建一个 Self-hosted 应用，域名填你自己绑定的 agent.example.com，然后新建策略：动作选 Allow，条件选 Emails，把你自己（以及需要共享的人）的邮箱加进去。
7.2.1 最常见的两个配置错误
错误一：策略写成 Everyone。这会让你以为配了访问控制，实际上是全开。安全配置里，”看起来配了”比”没配”更危险。
错误二：忘了给 Webhook 或 API 路径放行。如果你的 Agent 需要接收外部平台的回调，这段路径不能走浏览器登录流程。正确做法是用 Access 的 Service Token（CF-Access-Client-Id / CF-Access-Client-Secret）给机器访问单独开一条通道，而不是把整个应用放开。
7.3 Zero Trust 与成本的关系
这一层还顺带解决了成本问题：不该来的请求根本到不了 Worker。没有鉴权时，爬虫和扫描器会不断打你的入口，每一次都可能触发容器唤醒。加了 Access 之后，未验证请求在边缘就被挡下，容器的空跑次数会明显下降。安全与成本在这里是一件事，不是两件事。
八、成本拆解：$5 与 $34.50 之间的距离
现在进入这篇文章最实在的部分。$5/月的 Workers Paid 是入场券，但它不包含 Moltworker 需要的全部服务用量。按标准持续运行形态估算，月度总成本在 $34.50 左右。下面逐项拆开。
8.1 先看整体结构
下表是示意性的结构拆解，用于说明”钱花在哪”，而非报价单。实际金额会随用量、模型选择、容器规格、汇率与官方价格调整而变化，请以 Cloudflare 官方定价页与你账号账单为准。
| 成本项 | 计费方式 | 是否含在 $5 内 | 在 $34.50 中的大致占比 | 控制手段 |
|---|---|---|---|---|
| Workers Paid 基础订阅 | 按账号按月 | 是 | 基础部分 | 无需控制，固定支出 |
| Workers 请求与 CPU | 按请求数、CPU 时间 | 超出部分另计 | 较小 | 把重任务下沉到容器 |
| Sandbox Containers | 按实例运行时长与规格 | 否 | 最大一块 | 缩短闲置超时、限制最大实例数 |
| Browser Rendering | 按浏览器会话时长/并发 | 否 | 中等 | 任务结束即关闭页面，设会话上限 |
| R2 存储与操作 | 按存储量、读写操作 | 否 | 较小 | 生命周期规则、快照自动过期 |
| AI Gateway | 网关请求（低价） | 否 | 很小 | 开启缓存降低重复请求 |
| 模型 API 调用 | 按 token | 否 | 可变，取决于模型 | 短上下文、小模型分流、缓存 |
| Zero Trust | 按席位 | 个人通常免费额度内 | 接近零 | 控制用户数 |
8.2 沙箱容器：为什么它是大头
容器的计费逻辑是”占着就在计费”，而不是”干活才计费”。OpenClaw 这种 Agent 的典型特征是：一天里可能只有几次真正需要执行任务，但为了保证随时可响应，容器容易长时间驻留。驻留时长乘以单价，就是账单的主体。
所以优化容器成本的核心不是”少用”，而是”快回收”。把闲置超时从 30 分钟压到 5 分钟，效果立竿见影；再配合 Worker 侧的按需唤醒，用户体验几乎不受影响。
8.3 Browser Rendering：容易被忽略的隐形支出
浏览器会话是按时长计的。一个很常见的写法是：打开页面、抓内容、忘了关闭。单次看不出来，但如果这个流程每天跑几十次，月末的账单会非常刺眼。养成”用完即关”的编码习惯，是控制这一项最有效的手段。
8.4 模型费用：不可预测的那一块
$34.50 这个数字里，模型费用是最多变的部分。同一套架构，用不同的模型，账单可能差出几倍。建议的做法是分层：日常简单任务走便宜的小模型，复杂推理才切到大模型，并在 AI Gateway 里配置路由规则。这样既控制成本，也控制延迟。
8.5 $34.50 什么时候值
我的判断是，下面这几种情况，$34.50/月是花得值的：
- 你把它当成一个真实在用的个人助理，每天至少调用十几次，省下的时间价值远超这个数字。
- 你不具备运维能力，也不想学。自己维护一台 VPS 的时间成本（系统更新、证书、监控、故障恢复）折算下来，往往高于这个差价。
- 你在做原型验证或团队内部分享。Moltworker 的架构本身就是一份高质量参考，部署一次学到的东西，比省下的钱更值钱。
- 你需要随时随地访问，且对安全有要求。Zero Trust 这套访问控制，自己搭一套同等水平的，成本和精力都不低。
8.6 什么时候自建更划算
反过来，下面这些情况，我更建议你自建 VPS：
- 你对成本极度敏感，且用量很小。一台 $5 的小 VPS 挂一个 Agent，完全够用，月度支出可以压到个位数。
- 你需要长期驻留的重任务。比如持续抓取、批处理训练、频繁读写大文件，这类负载在按量计费的云上非常贵，包月的 VPS 反而更便宜。
- 你需要对运行时做深度定制。装特定的系统包、改内核参数、跑非标准依赖，沙箱容器会给你加上一层说不清的束缚。
- 你有现成的 Linux 运维经验，并且愿意为可控性花时间。
8.7 一张对比表看清差距
| 维度 | Moltworker（Cloudflare 全家桶） | 自建 VPS |
|---|---|---|
| 起步成本 | Workers Paid $5/月起 | 通常 $5 左右/月 |
| 持续运行月成本 | 约 $34.50（含沙箱、浏览器、存储、网关、模型） | 基础机器费 + 模型 API 费用，通常更低 |
| 运维负担 | 几乎为零，平台负责补丁与可用性 | 系统更新、证书、监控、备份全自理 |
| 弹性能力 | 强，按需拉起与回收 | 弱，受机器规格限制 |
| 访问控制 | 内置 Zero Trust，开箱可用 | 需自行配置 Nginx + 鉴权 + 证书 |
| 可控性 | 受平台模型约束，粒度较粗 | 完全可控，任意定制 |
| 适用负载 | 短时、突发、间歇型任务 | 长期驻留、持续占用型任务 |
| 成熟度 | PoC 参考架构 | 成熟方案，社区经验多 |
| 迁移成本 | 较高，深度绑定平台 | 低，随时换机器 |
这张表的核心结论是：Moltworker 卖的不是便宜，是省心与弹性。你用每月约 $30 的差价，买掉了运维负担、买到了全球入口、买到了一套带 Zero Trust 的安全边界。这笔交易值不值，取决于你的时间值多少钱。
8.8 一份可执行的降本清单
如果你决定用 Moltworker，但想把 $34.50 压下来，按下面的顺序做，收益最大：
- 把容器闲置超时调到 5 分钟以内，观察一周的任务成功率是否受影响。
- 限制最大容器实例数为 1 到 2 个，个人使用几乎不会需要更多。
- 给 R2 的
snapshots/前缀配 7 天过期规则。 - 审查所有浏览器调用代码，确保每个会话都有关闭路径。
- 在 AI Gateway 里做模型分层路由，简单任务走便宜模型。
- 在 Dashboard 里设置账单告警，阈值设在你心理预期的 1.2 倍。
九、PoC 定位的限制与生产化差距
Moltworker 是一个非常好的学习样本，但如果你要把它当成生产系统，必须清楚它离”生产可用”还差什么。这一段是我认为整篇文章里最该被认真读的部分。
9.1 缺少什么：从五个角度看
9.1.1 可靠性与容错
参考实现默认不会覆盖所有失败路径：容器启动失败、任务中途崩溃、模型调用超时、R2 写入失败。生产系统需要重试、幂等、死信队列、任务状态机。这些在 PoC 里通常只做了最简处理，甚至没有。
9.1.2 多用户与隔离
个人用的 Agent 不需要多租户。但如果你打算给团队用，就要面对会话隔离、配额、权限分级、审计日志。Moltworker 的参考架构没有为这些预留完整的模型，你需要自己设计。
9.1.3 可观测性
Workers 的日志、AI Gateway 的请求记录能解决一部分问题，但完整的可观测需要指标、追踪、告警三件套。PoC 给你的是”能看日志”，不是”能定位问题”。
9.1.4 数据治理
会话历史里可能包含敏感信息。生产系统需要考虑加密、保留策略、导出与删除能力（合规要求里常有”可删除”这一条）。R2 的生命周期规则只能解决过期，解决不了”按用户删除”。
9.1.5 版本与升级
Cloudflare 的平台能力在快速演进，wrangler 的子命令、容器模型、绑定方式都可能变化。参考实现不会跟着你的业务节奏升级，你需要自己维护一份”跟随上游”的成本预算。
9.2 生产化的最短路径
如果你真要往前走，我建议按这个顺序补：先补任务状态机与重试（解决”任务丢了”），再补配额与限流（解决”账单失控”），然后补审计日志（解决”出问题查不到”），最后补多租户隔离。这个顺序是按”出问题的概率 × 后果严重度”排的，不是按技术优雅度排的。
9.3 一个务实的结论
我的建议是：把 Moltworker 当作个人 Agent 的最佳起点，而不是团队产品的底座。个人场景下，它的限制几乎都不构成问题；而它带来的省心与安全边界，恰好是个人最需要的。等到你真的要服务多用户、要 SLA 的时候，你大概率已经把架构摸清，那时候再决定是继续在 Cloudflare 上加厚，还是搬去自建，都会比现在盲选更靠谱。
十、写在最后：一份可复现的落地顺序
把全文压缩成一条可执行的路径，方便你照着做：
第一步，开通 Workers Paid，确认 R2、Browser Rendering、AI Gateway、Zero Trust 全部可用；第二步，本地装好 wrangler 并登录，记下 Account ID；第三步，克隆 Moltworker 仓库，读完 README 与配置；第四步，创建 R2 bucket 与 AI Gateway，记下标识；第五步，按模板写配置，密钥走 secret，不写进仓库；第六步，dry-run 与本地 dev 验证，再正式 deploy；第七步，用 wrangler tail 验证链路，确认 R2 写入与网关日志；第八步，最后配置 Zero Trust，策略不要写成 Everyone。
部署 Moltworker 本身不难，难的是三件事：理解六个组件为什么这样分工、把成本从 $5 的心态调整到 $34.50 的现实、以及清楚 PoC 与生产之间的那道沟。这三件事想明白了，剩下的都是操作。
十一、常见问题（FAQ）
11.1 Moltworker 部署一定要升级到 Workers Paid 吗？免费计划行不行？
是的，必须升级到 Workers Paid，$5/月起。原因不在于 Worker 本身，而在于 Moltworker 依赖的整套能力——沙箱容器、Browser Rendering、R2 的大量操作——都超出了免费计划的覆盖范围。免费计划可以用来跑一个纯文本的演示 Worker，但无法承载 OpenClaw 的完整运行环境。需要强调的是，$5 是订阅门票，沙箱容器、浏览器会话、R2、模型调用这些都会在基础费之外按用量结算，所以在做 Moltworker 部署预算时，应该按 $34.50 这个持续运行量级来规划，而不是按 $5 来规划。
11.2 部署完成后访问返回 500 或 1101 错误，怎么排查？
先分清是哪一类错误。1101 通常意味着 Worker 代码抛出了未捕获异常，最有效的办法是开一个终端跑 npx wrangler tail，然后复现一次访问，直接在日志里看堆栈。500 则更可能是配置问题，比如绑定名和代码里引用的一致但资源不存在、compatibility_date 与实际能力不匹配、或者密钥没配置导致下游调用鉴权失败。检查顺序建议是：先用 npx wrangler deploy --dry-run 确认配置可解析，再在 Dashboard 确认 R2 bucket 和 AI Gateway 确实存在且名称一致，最后核对 secret 是否全部写完（npx wrangler secret list 只显示名称不显示值，能确认存在性）。
11.3 $34.50 的账单里，最大的变量是什么？怎么控制？
最大的变量有两个：沙箱容器的驻留时长和模型调用量。前者是”占着就在计费”，后者是”说多少字就收多少钱”。控制容器成本的有效手段是缩短闲置回收时间、限制最大实例数；控制模型成本的手段是做分层路由（简单任务用便宜模型）并在 AI Gateway 里开缓存。第二大的变量是 Browser Rendering，它的计费按会话时长，最容易出问题的是”打开页面忘了关”。建议在 Moltworker 部署完成后的第一周，每天都看一下 Dashboard 的用量曲线，把异常峰值和具体任务对应起来，这样你才知道自己的钱到底花在哪。
11.4 能不能不用 Cloudflare 的 AI Gateway，直接让 Agent 调模型 API？
技术上可以，Agent 只要能访问模型接口就行。但从 Moltworker 部署的实践经验看，我强烈建议保留 AI Gateway。原因有三：第一，它是你唯一能看清”模型调用账单”的窗口，没有它，超支之后只能盲猜；第二，它把供应商凭据集中管理，密钥轮换只需要改一处，而不是去翻每个 Worker 的环境变量；第三，它提供了重试与路由能力，后面想切换模型或做降级时不用改业务代码。去掉它省下的钱很少，失去的可观测性代价很大，这笔账不划算。
11.5 Zero Trust 配好之后，外部平台的 Webhook 回调进不来怎么办？
不要为了省事把 Access 策略改成 Everyone，那等于放弃了这层保护。正确做法是给机器访问单独开通道：在 Zero Trust 里创建一个 Access Service Token，拿到 Client ID 和 Client Secret，让调用方在请求头里带上 CF-Access-Client-Id 与 CF-Access-Client-Secret。然后在应用策略里增加一条允许该 Service Token 的规则，且只作用于 Webhook 所在的路径。这样浏览器访问仍然需要人身份验证，机器回调走的是另一条受控通道。这是 Moltworker 部署中安全配置最容易做错的一处，务必在联调阶段就把它验证通。
11.6 如果只是自己一个人用，Moltworker 和自建 VPS 到底怎么选？
给你一个可以直接套用的判断标准：如果你每天调用 Agent 十几次以上、不想花时间管服务器、并且在意入口安全，选 Moltworker，$34.50 花得值；如果用量很小（一天几次）、你能接受偶尔折腾一下 Linux、并且对成本敏感，选一台 $5 的 VPS 更划算。还有一个中间路线值得考虑：先用 Moltworker 做一次 Moltworker 部署，把六个组件的分工、Zero Trust 的配置、AI Gateway 的观测都摸一遍，再决定最终形态。因为这套架构知识是通用的，你学到的东西搬到自建环境里同样有效，而部署一次的成本只有一个月账单。对大多数认真使用 OpenClaw 的人来说，这是性价比最高的路径。
暂无评论内容