很多人第一次接触 OpenClaw，担心的不是能不能装起来，而是装好之后会不会一路烧 API 费。

如果你刚接触它，可以把 OpenClaw 理解成一个能接消息、调模型、跑工具和自动化任务的 AI Agent 框架。问题在于，只要默认把所有请求都丢给最贵的云模型，账单通常会比预期涨得更快。

但另一边，所谓“零成本方案”也很容易被说过头。真正实用的思路从来不是追求绝对免费，而是让不同层级的模型各做各擅长的事：

• 免费模型负责试跑和轻任务
• 本地 Ollama 承接高频日常流量
• 付费模型只在复杂任务和关键场景里出场

这篇文章想讲清楚的，就是这套低成本思路为什么成立、适合什么人，以及更稳妥的落地顺序。

与其追求“零成本”，不如先看清成本从哪来

社区里常说的 “$0 setup”，更准确地说，其实是“尽量不为大模型 API 持续付高额账单”，而不是系统真的完全没有成本。

现实里，OpenClaw 的成本通常来自三部分：

• 云模型调用费：这是最显眼、也最容易失控的一项
• 本地运行成本：包括设备、电费、折旧和你花在维护上的时间
• 后台常驻任务：例如定时摘要、心跳检测、自动巡检和消息处理

所以更合理的目标不是追求“绝对 0 成本”，而是把平均请求成本压下来，同时别把可用性也一起压没了。

第一条路线：先用免费云模型验证值不值得继续投入

如果你还没确认 OpenClaw 是否适合自己的工作流，其实没必要一开始就去买很多额度，也不必先把本地部署折腾得很复杂。

这时候最适合的，是先用免费云模型把流程跑通。到 2026 年 3 月，比较常见的入口包括：

• OpenRouter 免费模型路由：可以直接用 openrouter/free，也可以使用带 :free 的免费模型变体，适合快速试不同模型
• Gemini API 免费层：适合轻量问答、摘要和基础文本处理，但要注意速率和配额限制
• Groq 免费计划：适合对响应速度比较敏感的轻任务，可以拿来做试跑或补位

这条路线的优点很明显：启动快、试错便宜、几乎没有本地维护负担。

但它的上限也同样明显。免费层适合验证工作流、做低风险实验，或者承担用量不大的轻任务；一旦你开始跑高频消息、长期在线代理、定时自动化或者长链工具调用，单靠免费模型通常不够稳。

第二条路线：用 Ollama 把高频日常任务迁回本地

对多数人来说，真正能把成本明显压下来的，不是一直蹭免费额度，而是让 Ollama 本地模型吃掉那些量大、重复、但单次价值没那么高的请求。

比较适合本地模型的任务包括：

• 日常聊天和简单问答
• 文本整理、摘要、分类和改写
• 固定格式输出
• 低风险的例行任务和自动检查
• 允许先出草稿、再由人复核的流程

本地模型最重要的价值，不是“完全离线”这件事本身，而是它能显著降低系统的平均调用成本。只要大部分高频请求能在本地消化，云端账单就不会随着使用量线性增长。

如果 Ollama 和 OpenClaw 都在本机，最简单的方式其实不复杂。先给 OpenClaw 一个非空的 OLLAMA_API_KEY：

export OLLAMA_API_KEY="ollama-local"

然后把默认模型指向本地 Ollama 模型：

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/gpt-oss:20b"
      }
    }
  }
}

如果你是 Docker 部署，或者 Ollama 不在本机默认地址，那才需要显式写 models.providers.ollama。这里有几个很关键、也最容易配错的点：

• api 要写成 ollama
• baseUrl 要写原生 Ollama 地址，不要带 /v1
• apiKey 只需要一个非空占位值即可
• 如果你显式配置了 models.providers.ollama，自动发现会关闭，这时模型列表需要你自己定义

尤其要注意 baseUrl 这一点。OpenClaw 官方文档明确提醒：如果你把 Ollama 写成 OpenAI 兼容地址，比如 http://host:11434/v1，工具调用会变得不可靠，模型甚至可能把工具 JSON 当普通文本吐出来。如果 OpenClaw 跑在 Docker 里，常见的地址通常是 http://host.docker.internal:11434。

第三条路线：大多数人最适合的是混合架构

真正实用的答案，通常既不是“全本地”，也不是“全免费云”，而是混合架构。

一套比较稳的分层方式是：

1. 本地模型做默认入口，先接住大部分普通请求
2. 免费云模型做补位，在本地模型效果不稳或容量不够时接手
3. 付费模型只处理高价值任务，比如复杂调试、长链推理、关键改动和高风险输出

这套思路之所以成立，是因为 Agent 系统里的请求从来都不是平均分布的。最复杂的任务其实只占少数，数量最多的往往是重复、轻量、流程化的动作。把所有请求一股脑交给最贵的模型，本质上就是在用高成本处理低价值流量。

哪些任务适合放在哪一层

如果你想快速做决策，可以按下面这条简单规则来分：

• 本地模型：高频、低风险、可容忍偶尔失误的任务
• 免费云模型：试运行、轻量实验、临时补位和草稿生成
• 付费模型：难度高、返工成本高、必须尽量一次做对的任务

再展开一点，大概可以这样理解：

• 适合放在本地或免费层的，通常是摘要、改写、分类、消息路由、简单脚本样板和低风险自动化
• 适合交给付费模型的，通常是跨文件代码修改、复杂排障、长上下文分析、关键业务文案和高风险操作前的判断
• 法律、医疗、财务、生产环境改动、真实数据库或权限操作这类场景，不适合只靠便宜模型直接拍板

便宜模型最适合承担“先产出第一版”的责任，不适合承担“最后签字”的责任。

低成本方案里最容易踩的 4 个坑

1. 后台任务才是真正的隐性成本

很多人以为自己没怎么用 OpenClaw，结果最持续烧钱的，往往是那些在后台长期运行的 cron、heartbeat、自动摘要和监控任务。

如果这些任务默认挂在高价模型上，账单通常会比预期长得更快。真正要盯紧的，不是你手动发了多少次消息，而是那些一直在背后跑的请求。

2. 能本地跑，不代表所有任务都应该本地跑

本地模型的意义是降低平均成本，不是证明所有任务都能离线搞定。遇到复杂推理、质量要求高、返工代价大的任务时，直接升级到更强模型，往往反而更省时间。

3. 一开始不要把系统叠得太复杂

更稳妥的方式是先跑通最小闭环，再慢慢加复杂度。先确认消息能进来、模型能响应、工具能调用、Fallback 能工作，再继续加自动化、加长期任务、加更多能力层。

如果模型、配置、工具链同时出问题，排错成本会迅速上升。

4. 本地模型“看起来不正常”时，先查配置

很多本地体验异常，最后不是模型太差，而是配置没有配对。除了 baseUrl 和 api 之外，还有一个经常被忽略的点：OpenClaw 自动发现只会列出声明支持工具调用的模型。如果你发现模型没出现在列表里，不一定是 Ollama 没连上，也可能是这个模型没有上报 tools 能力，这时就需要手动显式配置。

更稳妥的落地顺序

如果你准备从零开始搭，比较推荐按这个顺序来：

1. 先用免费云模型把 OpenClaw 跑起来，确认消息、模型和工具链都通了
2. 再接入 Ollama，把高频日常流量迁回本地
3. 最后只给复杂任务保留付费模型出口

这样做的好处是，你不会在一开始就投入太多预算，也不会为了追求“绝对免费”把系统压到一个既不稳定也不好用的状态。

说到底，这不是一篇“白嫖教程”，而是一套更可持续的成本分层方法。真正值得讨论的，不是能不能把 OpenClaw 永久跑成 0 美元，而是能不能把不同模型放在最合适的位置上，让每一分成本都花在真正需要的地方。

📬 关注我获取更多资讯

📢 公众号

💬 个人号