Nanobot 与 OpenClaw：运行时、提供商与运营成本

如果你想要一个小型的自托管 Python 进程和单一 JSON 配置文件，请选择 nanobot；如果你需要由基金会支持的网关、更多聊天渠道、可选择的代理运行时以及第一方支出报告，请选择 OpenClaw。 两者都采用 MIT 许可证、自托管且免费下载，因此真正的决策因素是你将运维的运行时、需要手写的供应商块，以及你需要为其后台频率支付 token 的成本。

于 2026 年 9 月 21 日核对的版本：nanobot v0.3.5，发布于 2026 年 9 月 15 日；OpenClaw v2026.9.5，发布于 2026 年 9 月 19 日。OpenClaw 的 npm 记录显示，在本次核对前十天内，其稳定版和扩展稳定版分支共发布了四次，因此应查看发布信息流和 npm 记录，而不是依赖任何对比页面引用的版本号，包括本页面。

首先，确认你正在安装的是哪个 nanobot

本页面讨论的是HKUDS/nanobot，这是香港大学数据智能实验室开发的 Python 个人助手框架，其文档位于 nanobot.wiki。两个名称相近的项目会将购买者引向错误的软件：

• obot-platform/nanobot 位于 nanobot.ai，是一个独立的 Go 项目，采用 Apache-2.0 许可证，用于构建 MCP 代理。它的功能声明并不描述 HKUDS 的助手。
• 名为 nanobot 的 PyPI 包是一个无关的机器人导航库。正确的安装方式是 pip install nanobot-ai，版本为 0.3.5，采用 MIT 许可证，按照PyPI 记录要求 Python 3.11 或更高版本。快速入门还提供了一个安装脚本，可安装或升级同一个包。

还存在逐字复制描述和主页的分支；nanobot 的部署指南警告说，第三方命名空间下的 Docker Hub 镜像并非由该项目维护或验证，因此除非你信任发布者，否则不要将 API 密钥或机器人 token 挂载到其中。对于 OpenClaw，官方入口是 docs.openclaw.ai、openclaw.ai、openclaw.org 和 GitHub 仓库；如果你在其他地方看到下面的配置键，请对照这些官方来源进行核查，因为副本可能恰好在这些键上已经过时。

应该选择哪一款

如果工作流是一个人、一台机器、一个配置文件，请选择 nanobot。它的全部配置位于 ~/.nanobot/config.json，使用 camelCase 键；其持久状态位于代理工作区中，默认路径为 ~/.nanobot/workspace/，以 SOUL.md、USER.md 和 memory/MEMORY.md 的形式保存，具体见其记忆参考。如果你希望在将它交给消息账户使用前了解每个组成部分，更小的功能面是真正的优势。它自己的OpenAI 兼容服务器也使其成为其他工具的有用后端，默认绑定到 127.0.0.1，并且没有 API 密钥时拒绝在 0.0.0.0 上启动。

如果工作流是需要运维的部署，请选择 OpenClaw。其渠道目录列出 32 个渠道，其中少数随核心安装包提供，大多数作为官方或外部插件安装；它将代理工作区与状态目录分开，因此你可以分别重新定位两者，并提供带有 使用量跟踪的 /status、/usage cost 和 openclaw status --usage。它还将模型引用与代理运行时分开，因此一次部署可以并行驱动 API 密钥路由和供应商 CLI 席位。

在执行和权限模型方面，两者都需要完成相同的工作。两者都维护一个负责后台交付的长时间运行网关，并且都将自定义端点视为明确的信任决策：OpenClaw 将自定义 baseUrl 视为针对确切方案、主机和端口范围授予的网络信任；如果没有明确选择加入，元数据、链路本地和本地使用的 NAT64 源仍会被阻止，而其他私有地址或 CGNAT 地址范围则需要 request.allowPrivateNetwork: true，其默认值为 false。

在成本路径上，差异在于可见性，而不是价格。两个程序都是免费的。OpenClaw 会报告 API 密钥会话的会话 token 和估算成本，并隐藏按套餐计费会话的每 token 美元估算。nanobot 的 WebUI 会显示每轮 token 和缓存图表，并明确说明这些数字不是账单；其 CLI 参考中没有汇总支出的命令。HKUDS/nanobot 中关于成本跟踪的公开请求 issue #1193（最后更新于 2026 年 2 月 25 日）和 #2020（最后更新于 2026 年 3 月 16 日）目前仍处于开放状态——但不要将这些标题理解为今天的功能集，因为每轮显示功能确实存在。缺少的是汇总功能。

关于迁移成本，应按重写而非导入来规划。 OpenClaw 的记忆导入器支持 Codex、Claude Code 和 Hermes，而两个项目都没有记录如何将另一个项目的内容向任一方向导入。提供商配置块、预设、频道凭据、计划任务和记忆文件都需要手动重新创建。

有一点不能作为任何一个选择的依据：没有共享基准测试，两个项目都没有发布任务质量数据。nanobot 的 README 声称拥有“精简、易读的核心”，但完全没有公布代码行数，因此其他地方引用的任何具体行数都不是供应商声明。代码规模无法预测任一方向上的任务质量。

nanobot 与 OpenClaw 一览

Star 数量衡量的是某一天的关注度，而不是成熟度或支持情况，并且每天都会变化——应从两个代码仓库读取，而不是从二手页面读取。在许可证一行存在已记录的分歧：GitHub API 元数据显示 openclaw/openclaw 没有许可证声明，而LICENSE 文件包含 MIT 文本，没有商标或命名条款，后面仅指向 THIRD_PARTY_NOTICES.md。发布任何基于它构建的内容前，请阅读该文件并自行确认。

提供商配置才是真正的差异

两个客户端都可以调用兼容 OpenAI 或兼容 Anthropic 的端点。它们采用不同方式决定使用哪一个，而这一点正是可运行配置无法在两者之间直接转换的原因。

nanobot 根据你写入的提供商键来决定。根据其提供商参考，你在 providers 下创建的任何键都会被视为直接兼容 OpenAI 的提供商；由于 nanobot 无法知道端点 URL，因此必须设置 apiBase，而 apiKey 为可选。对于兼容 Anthropic 的网关，你必须改为保留提供商为 anthropic，并覆盖其 apiBase：文档说明，任意自定义提供商名称仅兼容 OpenAI，不会使用 Anthropic Messages 请求格式。这是此比较中最大的配置陷阱。

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    },
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "openaiShaped": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    },
    "anthropicShaped": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "openaiShaped"
    }
  }
}

这里名称会产生两重影响。避免与 openai、openai-codex、github-copilot 或 lm-studio 等内置名称冲突，也不要在自定义键上设置 apiType——该字段仅适用于 providers.openai。对于明确命名的自定义提供商，模型 ID 会按原样发送，因此 model 必须与端点要求的 ID 完全一致；只有在 provider: "auto" 下才会去除匹配的前缀。该覆盖会直接修改 anthropic 提供商配置块本身，因此对于所有指向该提供商的预设，网关会取代直接 Anthropic，而不是与其并列。另请注意，为兼容性接受 snake_case 键，但 nanobot 写回磁盘时会使用 camelCase。

OpenClaw 通过一个字段来决定。其自定义提供商参考将所有内容统一放在 models.providers 下的一个配置块中，其中 api 用于选择请求适配器。该参考列出了 11 个值，包括 openai-completions、openai-responses、anthropic-messages、google-generative-ai、ollama 和 bedrock-converse-stream；OpenClaw 在 v2026.9.7 的配置架构中接受第十二个值 google-interactions，该值于 2026 年 9 月 25 日加入，目前仅在其Google 提供商页面上记录。没有 api 的 baseUrl 默认使用 openai-completions。

{
  "models": {
    "mode": "merge",
    "providers": {
      "kunavo": {
        "baseUrl": "https://api.kunavo.com",
        "apiKey": "${KUNAVO_API_KEY}",
        "api": "anthropic-messages",
        "authHeader": true,
        "models": [
          {
            "id": "claude-sonnet-5",
            "name": "Claude Sonnet 5",
            "input": [
              "text"
            ],
            "contextWindow": 1000000,
            "maxTokens": 1024
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "kunavo/claude-sonnet-5"
      }
    }
  }
}

仅在 agents.defaults 下添加模型引用并不会注册该模型：models.providers.<id>.models[] 中必须存在一个具有相同 id 的匹配条目。上面的 1024 是为首次试用而有意设置的较小输出上限，并非模型的最大值；对于你路由的任何模型，应从模型页面获取 contextWindow 和 maxTokens。Kunavo 尚未让任一客户端连接其端点运行测试——这些配置块是在 2026 年 9 月 21 日从两个项目自己的配置参考中读取的，在将计划任务迁移到这些配置上之前，需要你自行进行范围受限的试用。

第三方端点无法访问的内容

两个项目都记录了自定义端点会失去的具体功能。这些是价格比较通常跳过的部分，但它们会改变一条廉价路由的实际成本。nanobot 的各行来自上面链接的提供商参考；OpenClaw 的各行来自同一配置参考及其自定义提供商概念页面，后者记录了请求头被丢弃的行为。

有两个后果值得提前规划。第一，在 OpenClaw 中，对于指向非原生主机的兼容 OpenAI 路由，客户端提示缓存提示会按设计被丢弃，同时丢弃 service_tier、store 和归属请求头；而 anthropic-messages 路由会丢失隐式测试版请求头。这改变的是客户端请求的内容，而不是端点本身是否缓存——自行缓存的端点仍然可以缓存，OpenClaw 的文档没有另作说明。因此不要假定任一结果：在将周期性任务按缓存处理进行预算前，请核实返回的使用量。我们的提示缓存指南说明缓存正常工作时使用量字段应是什么样子。

第二，在 OpenClaw 中，运行时与提供商同样重要。运行时参考会在解析提供商和模型之后解析运行时，并允许使用 models.providers.<provider>.agentRuntime 为每个提供商固定运行时：内置的 openclaw 运行时会自行执行准备好的回合，而 codex、claude-cli 和 copilot 会通过携带各自订阅凭据的供应商后端执行。这些后端是否支持自定义 baseUrl 并无明确文档，因此应将 Kunavo 风格的密钥视为属于 openclaw 运行时，不要假设可以重定向 CLI 后端。在 nanobot 中，对应的边界是订阅账户属于独立的 OAuth 提供商，并通过 nanobot provider login 登录；其提供商参考指出，OAuth 提供商不能作为有效的自动回退，而网关密钥不会继承这些特性。OpenClaw 的 README 声明它没有付费层、托管服务或令牌，nanobot 的文档也未描述任何付费层，因此两者都没有记录软件方案门槛。

运营成本：软件是 $0，但运行频率不是

nanobot 根据其仓库许可证采用 MIT 许可证，OpenClaw 的README声明其没有付费层、托管服务或令牌。两者都没有发布使用量基准，因此下面的内容只是根据已声明假设进行的算术计算，不是实测结果，也不是账单上限。

假设一个助手每天处理30 轮、连续 30 天，并假定每轮有 6,000 个未缓存输入令牌和 400 个输出令牌——每月为 5.4M 个输入令牌和 360,000 个输出令牌。按照当前的Kunavo 目录价格，Claude Sonnet 5列出的每百万输入令牌价格为 $1.40，每百万输出令牌价格为 $7.00；Claude Haiku 4.5列出的价格分别为 $0.70 和 $3.50。

心跳行使用 OpenClaw 自己的数据：其心跳参考说明，心跳会运行完整的代理回合；API 密钥身份验证的默认间隔为 30 分钟，OAuth 的默认间隔为 1 小时；isolatedSession 会将每次心跳的令牌消耗从约 10 万个降至约 2,000 至 5,000 个。这是整个比较中最大的可控成本项，与选择哪个客户端无关。这些是在所述假设下进行的令牌算术估算，不包括缓存费用、心跳回合的输出、外部工具和托管成本。

有两处信息缺口需要坦诚说明。尚未验证在不存在 agents.defaults.heartbeat 配置块时，OpenClaw 是否会运行心跳——文档给出了默认执行间隔，却未说明该功能是否开箱即用——因此，请将上表各行理解为你自行配置的心跳所产生的成本。而 nanobot 的配置参考确实默认启用网关心跳，每 1800 秒运行一次，常规结果会被“静默跳过”；同一份参考文档还将心跳评估列为会开启模型流的内部任务之一，因此，被跳过的心跳不一定不产生费用。它没有公布每次心跳的 token 数量，因此无法根据 nanobot 自身的文档确定其空闲成本。在确定执行计划之前，先用一天没有其他活动的时间分别测量两者。

OpenClaw 默认启用的是记忆整合，每天 03:00 按 cron 运行，使用代理的默认模型，除非设置 dreaming.model——将其指向更便宜的模型只需修改一行。nanobot 也有同类任务：其记忆参考说明 Dream 默认按 cron 计划运行，并接受一个指定更便宜预设的 modelOverride，因此双方都应为此预留预算。它单独的 idleCompactAfterMinutes 默认值为 15，这是压缩计时器，而不是计划中的模型调用；文档将该默认值与典型的 KV 缓存过期窗口相关联。两个项目都没有发布每次整合处理的令牌数据，而且这两个系统彼此无关——不要将一个项目的数据套用到另一个项目上。

除令牌之外，还要为维持网关运行的机器以及任何付费频道或工具账户预留预算：OpenClaw 的 SMS 频道需要配置 Twilio，Signal 频道则通过 signal-cli 运行，可以是本地守护进程或容器，并且需要自己的号码；nanobot 的转录选项以及任何图像或搜索工具也都是独立账户。

如果你想用预付余额而不是订阅来支付模型费用，Kunavo 的最低充值额为$10 预付余额，余额不会过期。请先阅读计费指南：目录估算不是上限，因为当上游成本计费超过该金额时，实际收费可能更高。准备在所选客户端中运行范围受限的试用时，请创建 Kunavo 账户。

在两者之间迁移，无论哪个方向

不要假设任何内容会自动迁移。提供商配置块需要手动改写为另一种结构；nanobot 的 modelPresets 条目与 OpenClaw 的 models.providers.<id>.models[] 没有直接对应关系，反之亦然。频道凭据需要按频道重新签发。计划任务迁移的是定义，而不是状态：nanobot 将 cron 状态保存在 <workspace>/cron/jobs.json，并且两种产品都要求网关进程持续运行，计划任务才能触发。

记忆是值得有意导出的部分。nanobot 的持久知识位于工作区中的 SOUL.md、USER.md 和 memory/MEMORY.md，工作区默认路径为 ~/.nanobot/workspace/。OpenClaw 默认将工作区保存在 ~/.openclaw/workspace，与保存配置、凭据和会话的 ~/.openclaw/ 分开；根据其代理工作区参考，可使用 OPENCLAW_WORKSPACE_DIR 覆盖默认工作区路径。复制文件后，还要在目标位置读取它们——带过去一个文件并不能证明下一次会话能检索到正确事实。

先迁移一个周期性任务，并保留旧安装，直到替代方案完成该任务且能够在重启后正常运行。如果候选名单实际上是 OpenClaw 与 nanobot 以外的其他产品，请按工作流比较替代方案；如果你已经选择 OpenClaw，只需要了解模型路由，那么提供商比较和运营成本分析会比本页面深入。

常见问题

已核查的源文档（2026 年 9 月 21 日）：两个代码仓库、它们发布的文档、nanobot-ai 的 PyPI 记录和 openclaw 的 npm 记录。2026 年 10 月 1 日，根据其网关配置参考、Google 提供商页面及 v2026.9.7 的配置架构，重新核查了 OpenClaw 的 api 值和 openai-completions 默认值。Kunavo 未对任一客户端进行运行时测试；配置块均读取自供应商文档。Kunavo 价格来自实时目录，总额是在所述假设下进行的令牌算术计算，并非实测任务成本。