OpenClaw成本控制与安全加固实操

OpenClaw 是免费开源项目，安装过程不复杂。上线后，账单主要来自模型API调用。即使没有人主动提问，定时检查也会带着上下文反复调用模型，待机时同样会产生费用。下面先讲费用来自哪里，再讲控费方法，最后列出安全检查项。

一、Token费用通常从哪里来

每次模型调用都要为输入计费，输入包括系统提示词、历史对话和工具返回的内容。模型生成的输出也要计费。因此，输入上下文越长，调用越频繁，费用越高。

成本来源	产生机制	控制方向
上下文累积	历史对话每轮都会重新计入输入	设置轮数或Token上限，超出后摘要化
工具输出	工具返回的长文本留在上下文中，被反复计费	设置输出截断长度，完整内容存入文件
系统提示词	每次请求都会重复发送	精简指令，避免把说明文档整段粘贴进去
多轮推理	链式思考和多步Agent循环增加调用次数	限制最大步数，简单任务不启用多步流程
模型单价	旗舰模型单价通常远高于轻量模型	按任务难度分流
心跳任务	定时检查反复调用模型	拉长间隔，使用轻量模型并限制上下文

不同模型和场景下，各项费用的比例差异很大。与其套用固定比例，不如用日志统计自己的调用分布，找出花钱最多的环节。

二、用估算模型算清待机成本

待机成本容易被低估，因为单次调用很便宜，但次数很多。下面用一组假设值说明计算方法。

假设条件如下：

• 心跳每30分钟触发一次，每天48次，每月按30天计算，共1440次。
• 每次心跳的输入为20,000 Token（系统提示词加上下文），输出为200 Token。
• 假设轻量模型输入单价为每百万Token 3美元，输出单价为每百万Token 15美元。

单次调用费用为：输入 20,000 × 3 / 1,000,000 = 0.06 美元，输出 200 × 15 / 1,000,000 = 0.003 美元，合计约 0.063 美元。

按这三种方案对比：

方案	每次输入Token	每天次数	每月估算
30分钟一次，完整上下文	20,000	48	约90.7美元
180分钟一次，完整上下文	20,000	8	约15.1美元
180分钟一次，精简上下文	1,000	8	约1.4美元

上表的价格和Token数都是假设值。替换为你实际使用的模型单价和日志中的真实数据后，结果会随之变化，但比较方法不变。通常，降低心跳频率和缩小心跳上下文，两项措施带来的节省最明显。

三、四项控费措施

1. 会话重置

不要让会话无限增长。为会话设置最大轮数或Token阈值，超过后摘要化历史，或直接截断旧消息。

两种方式各有取舍。摘要能保留信息，但生成摘要本身需要一次模型调用。截断成本最低，但旧信息会丢失。摘要时应保留用户目标、已做出的决定和未完成事项。对于需要长期跟踪的任务，可以把状态写入文件，只在需要时读取片段，而不是把全部历史保留在提示词中。

2. 模型分级路由

按任务复杂度分流，让轻量模型处理大部分请求，只把复杂任务交给旗舰模型。

任务类型	示例	默认模型	升级条件
简单问答、格式整理	翻译短句、整理列表	轻量模型	输出明显不完整，或用户要求更深入的分析
单步工具调用	查询一条记录、读取一个文件	轻量模型	同一工具连续报错两次
复杂推理、多步规划	跨多个文件的代码修改、需要权衡的方案设计	旗舰模型	无需升级

回退规则如下：轻量模型失败或结果置信度低时，升级到旗舰模型，且每个任务最多升级一次。升级后的任务不再降级，避免来回切换造成额外调用。复杂度评分可以由规则或一个小模型给出，阈值需要用过去一周的真实任务校准，不能直接套用某个固定数值。

3. 工具输出截断

工具返回的整段日志或网页内容会被反复计费。为工具输出设置最大长度，超出部分保存到文件，只把摘要或文件路径带入上下文。

截断时要注意保留关键信息。报错日志的关键内容通常出现在末尾，因此截断时应保留末尾部分，而不是只保留开头。

4. 本地模型回退

对隐私敏感的任务，或者对质量要求不高、调用频繁的任务，可以配置本地模型作为回退路径。这样能降低API费用，也减少对外部服务的依赖。

本地模型的能力通常弱于云端模型，上线前需要用真实任务测试输出质量。此外，本地部署还需要硬件和运维成本。心跳状态检查、简单分类和格式转换比较适合放在本地模型上运行。

四、心跳任务的设置

心跳是待机成本的主要来源，建议从三个方面调整。

间隔。 关键业务可以保留较短的间隔。非关键场景可设为2到6小时一次。间隔越长，节省越多，但异常发现的时间也会相应变长，需要根据业务容忍度决定。

模型与工具。 心跳应使用最轻量的模型，只做状态检查，不调用会产生额外费用的工具。

上下文。 心跳使用独立的精简上下文，不携带完整会话历史。

预算告警需要两层配合。第一层是在模型服务后台设置每日硬限额，这是最后的保险，即使程序出现循环调用，费用也有上限。第二层是在OpenClaw侧记录每次心跳的Token数，当某天的心跳用量超过近期日均值的两倍时发出提醒。第二层用于尽早发现问题，第一层用于限制损失。

五、示例配置

下面的配置用于说明思路。字段名为示例，需要对照你所用版本的文档确认。数值是起点，应根据日志统计结果调整。

session:
  max_turns: 20                 # 超过轮数后触发重置
  max_context_tokens: 8000      # 历史超过此值时摘要化，取值参考日常任务的平均输入量
  reset_strategy: summarize     # summarize保留关键信息；truncate成本更低但会丢失上下文
routing:
  default_model: haiku          # 默认使用轻量模型
  complex_model: flagship       # 仅在复杂任务时使用
  complexity_threshold: 0.7     # 复杂度评分高于此值才升级，用历史任务校准
tools:
  output_max_chars: 2000        # 超出部分保存到文件，只把摘要带入上下文
heartbeat:
  interval_minutes: 180         # 非关键场景的参考区间为120到360分钟
  model: haiku
  max_context_tokens: 1000      # 心跳使用精简上下文
budget:
  daily_limit_usd: 2            # 本地提醒阈值，平台侧硬限额为准
  alert_at_percent: 80

六、部署与安全检查清单

成本问题和安全问题往往同时出现。调用量异常时，如果没有权限隔离和日志，很难判断原因，也很