OpenClaw十分钟烧掉200元？Agent成本失控的根因与止损指南

openclaw 突然抽风一个任务十分钟花掉 200 块人民币这种事真让我赶上了。说实话我平时用这套开源代理框架跑自动化任务少说也有大半年一直觉得它省心、透明没想到那天一次普普通通的任务直接就烧掉二百块。第一反应是怀疑被刷量了后来翻完日志才明白压根没有外部攻击全是自己的 Agent 在“自嗨式”循环一遍一遍调用模型、调用工具把成本活生生抬上去。这种问题太典型了而且说实话几乎每个玩 Agent 的人早晚都会踩一次。这篇文章我不讲虚的就把当时的现场、账单拆解、问题根因、止损步骤和后续防护全部交出来希望你能少走点弯路。1. 先复盘现场200块到底烧在了哪1.1 正常情况下OpenClaw的成本模型是什么样OpenClaw 这类代理框架的核心逻辑是把一个目标任务拆成若干个“决策—执行—观测”的循环。每循环一次框架会把当前任务描述、历史动作结果、工具返回内容都打包成消息发给大模型 API让模型决定下一步该干什么然后再去执行命令、读文件、发请求最后把结果继续塞回上下文。所以它的费用不是一次性付清而是按“计算次数”和“token 消耗”叠加的。一次正常的小任务比如“整理指定目录下的文件并生成一份报告”往往只需要十几次循环每次请求的上下文在几千到几万 token 之间总成本通常几毛钱撑死一两块。这也是为什么很多人一开始根本不会给 Agent 做成本控制——因为日常真的很便宜。我当时跑的任务也不复杂本地一个数据处理脚本跑挂了想让 OpenClaw 自己排查日志、改代码、重新执行。直觉上这个任务最多几分钟就能跑完成本应该在两块钱以内。结果它跑了整整十分钟我再看账单已经超过 200 元而且还在持续增长。1.2 一笔异常请求是怎么把费用放大的这里必须先把 token 计费逻辑讲清楚不然很多人看账单时完全一头雾水。商用大模型 API 的常规计费是按输入 token 和输出 token 分别定价的而 Agent 框架最可怕的地方在于每一轮循环都要带上“之前所有的历史消息”。也就是说输入 token 会随着执行过程一路累加。假设某家 API 的输入价格是 5 元/百万 token输出价格是 15 元/百万 token。一次请求如果输入上下文只有 2 万 token输出 1000 token那这次成本大约是 5×0.02 15×0.001 0.115 元几乎可以忽略。但同样一次请求如果上下文已经膨胀到 100 万 token输出 3000 token成本就变成 5×1 15×0.003 ≈ 5.045 元。同样是“调一次模型”价格差了 40 多倍。更现实的情况是介于两者之间。比如上下文涨到 15 万 token一次请求成本大约 5×0.15 15×0.002 0.78 元。听起来也还行但如果一秒钟调两三次十分钟下来就是几百次调用总费用自然就冲上去了。我当时翻后台的数据OpenClaw 在十分钟内发了 200 多次 API 请求平均每二十秒一次而且模型越换越贵上下文越带越长费用斜率肉眼可见地往上飙。1.3 正常任务和“抽风”任务的账单对比为了让大家有直观感受我把正常任务和这次事故账单放在一起比一比。项目正常文件整理任务事故当天的排错任务耗时约 3 分钟约 10 分钟API 请求次数12 次237 次平均上下文大小8000 token12 万 token最大单次上下文2 万 token接近 40 万 token模型档位低规格模型中间偏上规格模型总成本0.4 元203.7 元差距是五百倍。这已经不是“多跑了几步”的问题而是整个执行逻辑失控了。最离谱的是它后面很多次循环都在重复做同一件事重新读同一个日志文件给出几乎相同的修复建议然后又去执行同样的命令。模型自己并不知道已经做过了它只知道自己“被要求继续”于是不停循环。2. 为什么 Agent 会“抽风”五个隐藏雷区2.1 循环不收敛把“完成”误判成“还要继续”Agent 框架普遍通过“任务状态判断”来决定是否结束。正常情况是模型看到执行成功返回一个“任务完成”的终止信号。但在实际跑任务时只要执行结果里带了“Error”“Warning”这些字眼模型就会觉得“问题还没解决”然后继续下一步。我那次就是典型场景OpenClaw 反复修复一个脚本脚本确实被改好了但日志里还残留着早期运行时的异常堆栈。它每次读取日志都看到旧错误就认为没有修好于是继续改、继续跑。其实任务早就完成了它只是被日志里的历史错误误导卡在“重新修复—重新执行—读取日志—又看到错误”的死循环里。这种误判非常难从外部一眼看出来因为模型每一轮都表现出很强的“解决问题意愿”看起来像在认真干活。解决办法只有一个给任务设置硬性终止条件明确告诉框架“看到什么标记就结束”同时加上最大迭代次数兜底。2.2 自动重试机制引发调用风暴很多框架默认在 API 请求失败或返回异常时自动重试。这本意是增强稳定性但在 Agent 场景里特别容易引发雪崩。如果某个模型接口连续超时框架会按指数退避策略重试比如第一次等 2 秒第二次等 4 秒第三次等 8 秒。单看每次重试没什么问题可如果同时存在多个并行子任务或者主循环没有被暂停每一次重试都会叠加新的 token 消耗。更隐蔽的是有些外围工具请求也会触发重试。比如 OpenClaw 调用一个外部接口该接口超时Agent 会认为“工具执行失败”于是重新规划再次调用模型生成新的计划再调用工具。每一轮“模型规划 工具调用”都是一笔费用。我见过故意设计的任务重试三次就停住结果 20 分钟跑出 300 元账单的案例。所以一定要配置“最大重试次数”和“重试熔断”宁可任务失败也不能让重试无限继续。2.3 上下文无限膨胀token 费用指数级上涨这是 Agent 成本失控的核心原因。Agent 每循环一次就把新的工具结果追加进历史消息。历史越长下次请求的输入 token 就越多。于是出现一个恶性循环任务卡住导致循环次数变多循环次数变多导致上下文增长上下文增长导致单次费用上升费用上升反过来又让总账单大幅飙升。我有一次在日志里看到OpenClaw 执行到第 30 轮时上下文已经包含前面全部的 29 轮对话和 14 次命令输出。其中某次命令输出了一个 5 万行的 JSON 文件直接让上下文从 3 万涨到 15 万 token。之后每一轮都要重新读一遍这 15 万 token这就是纯浪费。如果不做上下文压缩你就会看到模型单次请求越来越慢、越来越贵直到打满令牌限额。对付这个问题要么做滑动窗口截断只保留最近 N 轮消息要么做摘要压缩把早期历史总结成一段短文字要么强制限制最大上下文长度超了就自动清空最老的消息。2.4 模型回退策略选了更贵的档位不少框架支持“模型回退”意思是某模型不可用时自动切换到另一个模型。本来应该从贵切到便宜但配置失误时很容易反过来主模型是便宜款超时后自动切到中档中档也超时再切到高档最后每步都跑在最高规格模型上。我那次事故里OpenClaw 默认用的模型其实很便宜但由于某个阶段它判断“需要更强的推理能力”自升级到了一个中高端模型。这个切换本身不是 bug但在循环失控的背景下每轮调用都叠加高单价费用斜率立刻变陡。后来我查配置才发现这个“自动升值”策略没有做费用上限判断模型觉得应该升级就直接升级。正确的做法是明确设置模型档位的优先级并规定“只有满足特定条件才能升级”同时每次升级前检查当前任务已消耗金额。如果已经逼近预算上限哪怕逻辑上再需要升级也直接终止。2.5 外部依赖故障引发连锁重试OpenClaw 经常要读写文件、执行脚本、请求外部服务。外部依赖一抖动代理就会把异常当作“任务未完成”继续处理。比如那次脚本本身已经跑通了但最后一步要上传结果到某个内部系统那个系统恰好挂了。OpenClaw 发现上传失败就开始重新计划回滚代码、重新运行测试、再次读取日志每一项操作都在消耗 token。这个现象特别容易和“任务本身难度高”混淆。在日志里你会看到它在做不同的事情比如改了文件、跑了命令、查了网速看似很忙其实只是在一遍遍尝试绕过同一个外部故障。解决办法是给外部调用单独设置超时和重试上限并且把“外部服务不可用”作为终止条件之一而不是作为“继续努力”的触发信号。3. 十分钟的账单怎么追查从日志到用量后台3.1 给任务加执行轨迹记录没有日志就没法定位事故发生后我第一件事不是去找客服而是把 OpenClaw 的任务日志完整导出来。这套框架支持把每一步的模型请求、工具调用都记录下来类似一个“执行轨迹”。如果你平时没开详细日志那真到出问题时会很被动。我当时翻日志的重点就三个一是每一步在调用哪个模型二是每一步的 prompt_tokens 和 completion_tokens三是外部工具的返回状态。只要这三个信息齐全就能还原出一条完整的“费用时间线”。很多 Agent 框架默认只打印一个简单的进度条不记录 token 明细。我的建议是开工前先改配置打开“debug 模式”和“token usage 输出”还要把日志写到文件。不要依赖控制台输出因为任务一长终端往往会被覆盖。一个简化的日志配置思路{ logging: { level: DEBUG, output_file: logs/openclaw_trace.log, record_tool_calls: True, record_token_usage: True, save_request_payloads: False } }需要说明的是payload 全量保存会非常占磁盘日常不必开。出错时再临时开跑一轮就能定位到问题。3.2 用量后台按时间、模型、请求数拆账单光有本地日志不够还要去大模型 API 的用量后台核对。正常情况下厂商后台会提供按小时、按模型、按请求数汇总的用量明细。事故发生时直接选对应时间段按模型分组排序一眼就能看出哪个模型消耗了绝大部分金额。我那次在后台看到中高端模型的消费占了总额的 92%而便宜的默认模型只占了不到 3%。这说明问题不在所有请求而是集中在某一个时间段内被异常切换到高规格模型上。再结合本地日志里记录的时间点就能知道从哪一步开始“跑偏”。如果后台支持导出明细务必导出 CSV 或 JSON 格式里面通常包含每个请求的 request_id、模型、输入 tokens、输出 tokens、计费金额。拿到这些数据再回到本地日志里按 request_id 关联几乎可以定位到具体是哪一轮循环造成的放量。3.3 把请求 ID 与步骤 ID 对应起来精确到“第几步翻车”OpenClaw 的日志里每个工具调用步骤一般会生成一个 step_id而每个 API 请求的响应里又会返回 request_id。只要把这两个 ID 对应起来就能画出完整的执行链路。我当时做了一个很笨但很有效的方法把日志里所有 API 请求按时序排成一行每行标出“第几轮循环”“触发工具”“输入 token”“输出 token”“累计金额”。跑完一遍后发现在第 17 轮开始模型开始反复读取同一个日志文件每一轮都带上了越来越多的历史单次请求金额从 0.3 元一路涨到 3.8 元。而第 17 轮正是外部上传接口第一次超时的时间点。这一步的价值在于你能给团队或者给自己一个明确的结论不是模型乱收费也不是平台计费出错而是外部故障触发了 Agent 的无限循环。4. 一次性堵住漏洞成本安全带配置参考4.1 设置预算硬顶、熔断和告警真正的成本防护不是靠自觉而是靠“硬性上限”。给 OpenClaw 的配置里加预算控制其实并不复杂。关键是区分两种上限软限制只告警和硬限制直接停止任务。我建议至少配置三个阈值。第一档是“提示阈值”比如单个任务累计到达 20 元立刻通过日志和通知提醒第二档是“暂停阈值”比如单个任务到达 50 元先暂停任务等待人工确认第三档是“熔断阈值”比如单个任务到达 100 元无论任务处于什么状态直接结束进程。一个通用配置骨架长这样budget: currency: CNY alert_threshold: 20 pause_threshold: 50 kill_threshold: 100 per_hour_max: 60 per_day_max: 200 execution: max_iterations: 30 stop_conditions: - success - task.completed - fatal_error max_consecutive_tool_errors: 3 context: max_history_rounds: 20 max_context_tokens: 50000 compression_enabled: true compression_method: summary compression_trigger_tokens: 40000这里注意不同的 Agent 框架配置字段名可能不一样但思路完全相同给循环、给预算、给上下文设置边界。我自己的习惯是宁可把阈值调低也不要为了“跑完任务”而放开限制。4.2 限制迭代次数与终止条件最有效的止血阀在所有参数里max_iterations 和 stop_conditions 是最保命的两个。max_iterations 就是最多循环多少轮设成 20 或 30 通常够用。一旦到 30 轮任务还没结束基本可以断定它卡死了继续跑只是烧钱。终止条件则要写清楚。不要只写“success”要把任务里常见的“完成标志”都列出来。比如我的数据处理任务终止条件包括“日志中出现 Completed”“输出文件存在”“退出码为 0”。只要这三个条件任一满足Agent 就必须停下来。还可以加一个“连续相同动作终止”如果连续 5 轮循环里Agent 调用的是同一个工具、传入的参数也相同就判定进入了重复循环直接终止。这个思路相当于给 Agent 装了一个“防抖闸”非常管用。4.3 上下文压缩滑动窗口与摘要机制上下文一次别带太多。最省钱的方案是让 Agent 只保留最近 10 轮到 20 轮的动作记录更早的历史通过摘要保存。每次触发摘要压缩时可以让模型用一小段话概括前面做了什么然后把完整历史丢弃。要注意摘要本身就是一次模型调用也会花一点钱所以触发阈值不能设太低。我一般设置在上下文到 4 万 token 时触发摘要摘要结果控制在 500 token 以内这样压缩一次成本不到 0.01 元但后续每轮能省几十倍。另一个技巧是“按工具输出裁剪”。很多工具返回的日志、JSON 特别长其实后面几轮根本用不到全部内容。可以配置工具输出只保留前 N 行或只提取关键字段。比如读取日志文件时只返回最近 200 行而不是整个文件这样上下文能维持在一个较低水位。4.4 模型分级与重试降级便宜优先贵模型限量把模型选择策略单独拿出来设计而不是依赖 Agent 自动切换。固定规则是日常任务用便宜模型复杂任务才用中高档模型如果便宜模型连续出错也不要直接升档而是先检查是任务问题还是环境问题。可以给模型调用做一个“闸门”每个任务里高档模型最多调用 3 次超过后一律强制切回便宜模型每次升档前检查已花费金额超过预算 20% 就禁止升档。重试则限制在 2 次以内并且关闭指数退避改成固定间隔重试。比如这样models: default: cheap-model reasoning: medium-model max_upgrade_count: 3 upgrade_cooldown_minutes: 10 forbid_upgrade_if_spent_percent: 20 retry: max_attempts: 2 base_delay_seconds: 1 multiplier: 1 jitter: false同时一定要开启流式输出。流式输出虽然不能降低总 token 费用但能更快发现异常——每次返回一小段如果你的代理卡在输出上你能更早看到问题及时手动打断。4.5 用沙箱和 Mock 做测试避免真实 API 费用OpenClaw 这类框架本身支持“模拟模式”或者你可以把外部 API 指向一个本地的 Mock 服务在不产生真实费用的情况下验证任务逻辑。正经做法是准备一套本地模拟环境把大模型 API 和文件系统都做成假的专门用来跑“危险任务”的回归测试。我第一次完全没做模拟直接拿真机、真 API 去跑排错任务结果翻车了。后来学乖了写了一个 Mock 大模型返回固定动作比如“完成”或“重复当前步骤”用来验证 Agent 到底会不会无限循环。只花了一个下午就模拟出三种死循环场景然后又针对性地加强了终止条件。如果你不想搭完整的 Mock也可以把 API 的 max_retries 都改成 0同时设置一个极小的 max_context_tokens比如 3000让任务很快因为上下文超限而终止。这样虽然不能验证完整逻辑但至少能防止测试时烧掉不必要的钱。5. 发生事故后的止血流程我如何以最快速度止损5.1 第一步立刻断掉执行流别心疼任务进度发现账单异常后我的第一反应不是去查日志而是先把这个任务停掉。所有排查工作都建立在“停止烧钱”的基础上。OpenClaw 进程可以直接终止如果没有权限就去后台调用管理接口或者干脆杀掉整个进程组。如果你是通过脚本启动的那就 ctrlC如果是后台进程用 kill 命令把进程 ID 干掉。不要优雅退出不要等待保存先把“漏油阀”拧死再说。任务进度损失可以在后面补救但每一秒钟的犹豫都在往账单上加钱。我在那次事故中发现异常后又犹豫了两分钟想着“可能再跑几步就能结束”结果这两分钟又烧掉 30 元。教训非常明确遇到费用异常先杀进程再谈其他。5.2 第二步轮转密钥防止恶意利用虽然这类事故大多不是黑客所致但稳妥起见还是要立刻在 API 后台吊销正在使用的密钥然后生成一个新密钥。这样即使有并发任务还挂在进程中或者有人拿到了你的密钥也无法继续调用。密钥轮转后原来跑的任务会立刻认证失败。这正是我们想要的效果所有 API 调用全部停止。然后再把新密钥更新到 OpenClaw 配置里继续排查冷静后的日志。这一步一定要做哪怕你确定没有外部泄露。因为 Agent 框架本身可能把密钥误提交到工具输出里或者写入了某个日志文件没有轮转密钥就等于一直保留了一个隐患。5.3 第三步保全现场日志和账单截图把任务日志、输出文件、API 后台的用量明细截图、请求时间线都保存下来。这些不只是用于分析也是后续申诉和复盘的重要材料。尤其要注意保存OpenClaw 的 debug 日志、命令历史、API 请求记录、用量后台按小时汇总截图、以及异常发生前后的时间戳。时间戳对不齐就无法定位所以保存日志时最好把系统时间也带上。我通常习惯把所有日志打包成一个归档目录命名为 事故日期任务名费用金额方便以后追溯。不要让日志散落在各个临时目录否则过几天自己都找不齐。5.4 第四步申诉与账单复核态度要客观如果你确认费用暴涨不是恶意消耗而是某个外部故障或 Agent 逻辑缺陷导致的可以向平台提工单说明情况请求人工复核。但注意不同平台的退款政策差异很大不要抱着“一定要退款”的心态去申诉而是抱着“核对计费是否准确”的心态。申诉时准备好三个东西本地执行日志、请求 ID 列表、时间线说明。客观描述哪些请求是异常重复调用哪些属于无效消耗。平台风控或计费团队看到清晰的请求 ID 和时间线至少能帮你复核是否有重复计费的情况。我那次经过复核平台虽然返还了一部分明显重复轮次产生的费用但并没有全退。原因是大量请求确实真实发生了责任在我这边没有配置好防护。能退一点已经是意外之喜不能退也只能当一次性学费。6. 常见问题与排错速查把它贴在工位上6.1 成本失控排错表现象可能原因快速排查方法最终解决方案单个任务费用突然暴涨Agent 进入死循环看日志里是否重复调用同一工具设置 max_iterations 与连续相同动作终止上下文越带越大没有做历史裁剪或摘要统计日志里每次 prompt_tokens 变化开启滑动窗口或上下文摘要压缩模型档位突然升高自动升级策略失控查看用量后台模型分组占比限制升级次数与升级费用闸门请求失败后反复重试外部接口抖动或超时查工具调用错误率和重试日志设置最大重试次数、禁用指数退避任务看似在干活实际没进展终止条件不清晰检查 stop_conditions 是否包含明确完成标志补充多个完成条件与失败终止条件测试环境烧掉真实费用直接连了真实 API检查当前任务 target 地址使用 Mock 服务或模拟模式这张表我打印出来贴在工位边上后来搭建新任务时都会对照着过一遍。它不能覆盖所有情况但能解决 90% 的突发问题。6.2 我私藏的三个防翻车细节第一个是“账单消费进度条”。OpenClaw 本身不显示累计费用但我写了个小脚本定时读取厂商后台的余额或用量接口把当前任务已消耗金额打印到终端。我后来把脚本做成每 5 秒刷新一次单任务超过 10 元就高亮报警。这个改动成本极低但效果立竿见影。第二个是“黄金十分钟规则”。任何长时间任务如果跑了 10 分钟还没结束我会强制做一次人工确认。自动化任务越长越容易失控10 分钟是一个比较合理的检查点。尤其涉及代码修复、日志分析这类“开放目标”任务时这条规则更重要。第三个是“先让它干一件假任务测试保险丝”。每次新写一个 Agent 任务流程前我会先跑一个只需要 1-2 个循环就能完成的小任务同时把预算阈值设到 1 元验证整套熔断开关是否真的能触发。如果连这个最简单的任务都躲不过 1 元上限那说明配置有问题绝不上生产环境。6.3 不同规模任务的预算建议简单任务文件整理、信息提取、文本改写单任务预算建议 2 元以内最大循环 15 次。中等任务代码调试、数据分析、自动化运维单任务预算建议 10 元以内最大循环 30 次并且必须开启上下文压缩。复杂任务跨系统协调、多阶段推理单任务预算建议 30 元以内但一定要设置“人工审批中断点”比如每花掉 10 元就暂停一次由人工确认是否继续。你不能从一开始就指望 Agent 绝对可靠它本质上是一个黑盒决策系统再聪明的框架也会有判断失误的时刻。最好的策略不是“追求不失误”而是“即使失误代价也有限”。这次 openclaw 十分钟烧掉 200 元的经历确实让我肉疼但也逼着我把整个成本控制体系补全了。如果你也正在跑类似的自动化任务花五分钟检查一下自己的配置里有没有迭代次数上限、有没有预算熔断、有没有上下文压缩绝对值得。钱不是大风刮来的Agent 跑一次任务可能很快但账单失控的速度比它更快。