如果你也是那种把智能体当生产力工具用的人应该能懂我上个月看到 OpenClaw 账单时的感受一个开源项目居然能让我一个月花掉 600 美元。说实话一开始我是认的——毕竟每天让 AI 帮我处理邮件、整理文档、跑数据分析、自动回复这些任务全都走云端 API烧钱似乎是理所当然的。直到我偶然翻了配置才意识到这里面至少有八成是可以省下来的。这篇不是标题党。我把过去两个月的省钱折腾过程完整记录下来从 600 美元到 20 美元功能基本没缩水。无论你是刚接触 OpenClaw、还在纠结怎么部署还是已经在 Windows 上跑起来了、但账单高得离谱这篇都能给你一套可以直接抄的改进方案。1. 先看清账单600美元到底烧在哪些环节在做任何优化之前得先搞清楚钱是从哪个口子漏掉的。很多人一上来就换模型、搞本地部署折腾半天发现账单没降多少原因是根本没找到成本大头。我的做法是先跑一个星期的用量统计把 OpenClaw 每次调用的 token 日志导出按任务类型和会话维度去汇总。1.1 全API模式下最烧钱的三个场景第一个是高频轮询式任务。比如每 5 分钟检查一次邮箱、每 10 分钟抓一次网页信息、定时生成日报这类任务单次消耗不大但架不住次数多一天几百次调用叠加起来很可观。第二个是长上下文会话。OpenClaw 的特色是能在一个会话里连续处理几十步操作每一步都会把前面的历史对话一起发给模型。会话进行到一半一次请求的输入 token 可能已经超过 10 万而这 10 万 token 里可能只有几千是真正有用的新信息。第三个是并行任务。为了效率我习惯同时开七八个会话跑不同项目OpenClaw 默认是每个会话独立计费的。这看起来是并发效率但实际有一个隐含问题大量相同的历史背景被反复发送到 API等于同一份钱被重复收了好几次。1.2 用一周追踪日志找出成本黑洞我导出日志后用一个小脚本按日期、任务名、token 量做了汇总。结果让我很意外最烧钱的并不是我以为的复杂代码生成而是那些每天重复的定时任务。它们占了我总 token 消耗的 42%。为了让你有个直观概念我按当时 API 的公开定价粗算过一笔账如果一天的 token 消耗是 200 万输入加 30 万输出按主流云端模型的价格输入约 3 美元每百万 token输出约 15 美元每百万 token来算一天就是 6 加 4.5 等于 10.5 美元一个月下来就是 300 多美元。如果再算上偶尔用更强的模型上 600 美元根本不夸张。这里的关键不是模型单价而是重复发送的上下文在替你把钱烧掉。提示先看日志再动手优化永远比凭感觉换模型靠谱。OpenClaw 自带会话记录和 token 统计接口我个人是把这些记录导成 CSV 后用本地脚本聚合的不用额外花钱。2. 算力路线选择本地模型和云端API混合才是省钱的杠杆很多从官方 Demo 开始用 OpenClaw 的人脑子里会形成一个默认认知OpenClaw 必须接云端 API 才能用。其实不是至少在 2026 年的开源生态里它早就支持本地模型了。Ollama 是其中最省事的方案。这也回答了那个常见疑问OpenClaw 不是只能用 API 方式使用算力本地算力完全可以接入。2.1 为什么只用API是默认的烧钱陷阱官方 Quickstart 文档大概率会让你先填一个 API Key因为这样最快、最无脑。但代价是你每一次请求都要按 token 付费。本地模型则是一次性投入硬件成本跑的每一句话都不再额外计费。我见过不少朋友因为不想配置本地环境而坚持全云端结果月账单轻松上千。这里并不是要你放弃云端 API而是建议把两者按任务难度路由。我的个人体验是像文本分类、邮件草稿、格式化输出、数据提取这类确定性较强的任务本地 14B 模型完全够用只有真正需要复杂推理或代码生成的活才需要云端更强的大模型。2.2 在OpenClaw里配置Ollama本地模型具体操作分三步在 Windows 或 Linux 机器上安装 Ollama然后拉取一个合适大小的开源模型。个人建议先试试 14B 量级的量化版本显存占用大约 8 到 10GB大多数近几年的机器都能跑。确认 Ollama 服务地址默认是localhost:11434。在 OpenClaw 的配置文件中增加一个 provider 项。配置示例示意以你所用 OpenClaw 版本为准{ modelProvider: ollama, ollama: { baseUrl: http://localhost:11434, model: qwen2.5:14b, temperature: 0.2 } }这样你就能让 OpenClaw 的大部分基础调用直接走本地。第一次加载模型会慢一些后续推理速度会稳定很多。如果你用的是中文社区打包的 OpenClaw 版本配置项名称可能会稍有差异但结构基本一致。2.3 设定任务级路由简单任务本地、复杂任务云端OpenClaw 的 skill 机制可以给不同任务定义不同的执行策略我最后采用的路线是日常任务、定时任务、文本处理走 Ollama代码生成、多步骤网页操作、长文档分析走云端 API。这样一个简单策略就把 80% 的重复调用从付费 API 上挪走了。有个小细节要注意本地模型和云端模型的输出风格差异较大如果发现某些任务的结果不稳定不要硬撑把它切回云端。省钱的前提是任务质量不下降否则省下来的钱都会变成你重新处理烂结果的时间成本。3. 上下文与缓存的隐形开销多数人忽略的二次成本如果说切换本地模型是开源那么上下文和缓存优化就是节流。这部分容易被忽略但省下来的钱非常可观尤其是长会话重度用户。3.1 上下文Token是如何重复计费的先讲一个很多新手误解的点API 计费不是按你这次提问的字数算的而是按你发给模型的全部内容算的。OpenClaw 这类智能体会把整个会话历史打包发送所以你在一个会话里跑得越深后续每次请求的输入 token 就越多。哪怕新任务只增加了一行指令模型收到的还是几十万 token 的历史。我最早就是在这个地方吃大亏的一个会话里跑了 20 多步操作后面的每一步都在为前面所有内容掏钱。等我把会话历史导出来一看才发现单步操作的输入 token 早就超过了 8 万而真正新产生的只有几百 token。3.2 用会话摘要压缩输入Token解决办法是把完整历史替换成压缩摘要。OpenClaw 较新版本支持会话摘要机制可以在配置里打开。它会每隔若干轮把前面的对话压缩成一段结构摘要之后只发送摘要加最近几轮对话而不是全部历史。我这里给个简单的配置示意{ contextStrategy: summary, summaryTriggerSteps: 8, maxContextTokens: 64000 }含义是每 8 步触发一次摘要上下文窗口上限设为 64000 token。这样单次请求的输入 token 基本能被压在一个可控范围内。对我这种长会话重度的用户来说这步省下的钱甚至比切换本地模型还要多。开完这个功能后的第一周我的云端 token 消耗直接少了三分之一。3.3 批量合并小任务减少请求次数还有一个比较反直觉的做法把碎片化的小任务合并成批量任务。比如每天早上有 10 个不同网站要抓数据不要写成 10 个每 5 分钟跑一次的定时任务而是写成一个在固定时间统一执行的批量脚本一次性把 10 个任务的结果带回再让模型统一整理。这样既省了调用次数也避免了多个会话重复发送相近背景信息。我在优化后每天 API 调用次数从原来的 300 多次降到了 30 多次效果立竿见影。批量任务还有一个附带好处可以让模型一次性输出结构化结果后续做数据入库反而更省事。4. Windows环境部署的踩坑实录WSL 2、Companion与Node.js版本省钱的另一个前提是环境稳定。如果 OpenClaw 三天两头崩你就会想回到花钱买省心的老路上去所以这一章说说我在 Windows 上部署时踩过的坑。很多论坛上的提问都集中在几个地方。4.1 WSL 2状态异常导致OpenClaw无法安全验证在 Windows 上跑 OpenClaw大多数人是通过 WSL 2 环境来运行服务端的。但有个常见问题是Windows 和 WSL 之间的环境校验失败OpenClaw 在启动时直接提示类似无法安全验证、请检查环境的报错。我第一次遇到时以为是配置坏了折腾半天才发现是 WSL 本身状态不对。正确排查路径是打开 PowerShell建议管理员模式运行wsl --status检查当前 WSL 版本和默认状态。如果输出显示 WSL 1 或者版本混乱再运行wsl --update和wsl --set-default-version 2把环境统一到 WSL 2。之后再启动 OpenClaw报错就消失了。提示WSL 2 和 WSL 1 的差异会直接影响文件读写和网络转发所以不要图省事停留在旧版本。检查wsl --status是一个成本极低的排障动作遇到任何环境验证失败类报错都要先做这一步。4.2 Windows Companion的配置要点OpenClaw 的 Windows Companion 是负责把 Windows 上的浏览器、文件系统、剪贴板等能力暴露给服务端的辅助组件。它配置起来不算复杂但有几个细节容易翻车。首先Companion 启动后会生成一个本地端口和访问令牌默认是随机生成的。很多人忘了把这个令牌填到 OpenClaw 主配置里结果服务端一直连接不上。其次Windows 防火墙可能会拦截本地回环请求需要把对应端口加入白名单。最后如果你同时装了多个版本的 Companion端口可能冲突建议统一固定端口。我的建议是把 Companion 的端口和令牌写在一个独立配置文件中然后在 OpenClaw 主配置里引用这样重新安装或换机器时不会丢配置。4.3 Node.js版本与Ollama服务的内存分配OpenClaw 的服务端基于 Node.js所以 Node 版本必须对齐。我见过很多配置文件没问题但起不来的情况最后都发现是系统里 Node 版本太旧或太新。这里没有捷径去 nodejs.org 下载当前 LTS 版本并安装比用包管理器乱装版本要稳。装完在命令行执行node -v确认版本号再做后续操作。Ollama 的内存分配也需要单独说一句。默认情况下Ollama 会尽量占用可用显存这在同时跑 OpenClaw 和本地模型时会挤压其他程序。我用的办法是设置环境变量OLLAMA_NUM_PARALLEL1限制并发模型加载数量。如果你用 CPU 推理建议把OLLAMA_MAX_LOADED_MODELS设小一点防止一次加载多个模型把内存吃满。5. 完整省钱配置清单从600到20的实测对比前面讲了很多思路最后给你我能直接抄的配置和数字。我整个优化过程大概持续了三周每周只调整一项然后跑一周数据看效果避免同时改动太多搞不清是哪一步起了作用。5.1 每一步调整的预期节省金额我把整个优化过程拆成了几个独立的调整项每一轮调整后都跑了一周统计调整项调整前调整后月节省估算任务路由全部走云端 API80% 定时/文本任务走本地 Ollama省约 350 美元上下文策略完整历史发送摘要压缩64K 上限省约 120 美元批量任务300 多次小调用/天30 多次批量调用/天省约 60 美元模型选择全局最强模型任务级差异化选模型省约 50 美元注意这些不是精确会计数字只是按我当时用量推算的参考量级。核心结论是大头在路由第二在上下文批量任务也有不可忽视的贡献。5.2 最终配置对账调整完成后我的月度成本构成大概是这样的本地算力Ollama 模型电费加硬件折旧折算下来约 5 美元左右。云端 API只保留复杂代码生成和多步骤网页操作约 12 美元。其他偶尔测试、备用模型调用约 3 美元。合计 20 美元出头和之前的 600 美元形成了明显对比。为达到这个效果我的关键配置如下表配置项我的最终设置默认 ProviderOllama 本地模型云端 Provider仅复杂任务路由使用上下文策略summary 模式触发步数 8最大上下文64K token定时任务合并为每日批量执行模型版本本地 14B 量化 云端旗舰按需5.3 省钱之外的几条铁律最后说几条我踩坑之后总结的规矩不要追求全本地化。有些任务本地模型确实做不好硬扛只会让你觉得方案不可用最后退回全云端。每周看一次 token 账单。OpenClaw 支持导出用量日志保持这个习惯能让你在成本失控前及时介入。不要为了省钱关掉日志。日志是排障和成本分析的基础省一点存储费却可能让你多花几百美元找问题。手机端 Termux 装 OpenClaw 可以用来做远程状态检查和轻量任务调度但不要把手机当成主力算力机意义不大。整体折腾下来我最深的体会是OpenClaw 本身并不烧钱烧钱的是无差别的全量 API 调用。先把任务分类把那些重复的、确定性的、不需要顶级推理的活交给本地算力再用缓存和批量把云端请求压缩到最低这 20 美元完全养得起一套够用的自动化系统。如果你也正在为账单发愁不妨按这个路径先跑两周看看自己的成本结构多半能找到比我更大的压缩空间。
