做 OpenClaw 智能体实战最让我肉疼的从来不是服务器内存也不是半夜告警声响个没完而是每天早上打开 API 账单的那一刻。我自己踩过一回真实的坑挂了个长期任务让智能体每隔半小时抓一次数据并总结结果第二天早上发现账单比预期翻了三倍。问题不是模型变贵了而是智能体在循环里反复重试同样的请求日志里还不断追加历史上下文每一次重试都在为前面所有内容重新付费。那时候你才会意识到Token 消耗失控不是玄学是缺一套“看得见、算得清、刹得住”的监控体系。这篇文章是 OpenClaw 企业级智能体实战系列的第 7 篇聚焦一件事终结 Token 消耗失控。我会完整拆解两套治理方案方案一是基于 Agent Dashboard 的可视化账本让你把每一笔 Token 花销摊开看方案二是基于阿里云 SLS 的实时日志监控与告警让消费异常在第一时间触发通知。两套方案都会给完整可落地的代码最后还会讲一个我自己在用的 Token 消耗预测与突增检测算法。适合已经在跑 OpenClaw、或者准备把它当成生产级工具的同学也适合被“月底开盲盒式账单”折磨过的所有人。1. 先搞清楚 Token 到底消耗在哪了1.1 失控的三种典型场景Token 消耗失控不是突然发生的它是一个缓慢积累、然后某个瞬间爆发的量变过程。我复盘过自己那次三倍账单也帮几个同行排查过类似问题发现失控案例基本都落在三种场景里。第一种是循环重试。智能体在执行任务时如果调用外部接口返回了错误或者 LLM 返回的格式不符合解析预期它可能会自动重试。问题是很多框架的重试策略会把完整的历史对话上下文一起带上而不是只带出错的那一步。一次重试的 Token 成本和第一次调用差不多重试十次就是十倍。而且如果错误不是立即暴露而是经过好几轮工具调用之后才被发现重试时甚至会重复执行前面所有工具调用消耗量直接滚雪球。第二种是上下文膨胀。OpenClaw 这类智能体框架默认会把系统提示词、历史消息、工具定义、中间输出全部拼进每一次 LLM 请求里。单看一次请求可能就几千 Token感觉不多但如果你让它跑一个需要持续数小时的批量任务每轮对话都会把之前的对话摘要、原始数据片段重新塞进上下文。到任务后半段单次请求的 Token 消耗可能是任务刚开始时的好几倍。这就等于你每次和人聊天都要把前面所有聊过的内容重新复述一遍。第三种是多智能体互调。企业级场景下很少有人只跑一个智能体通常是主 Agent 调度几个子 Agent每个子 Agent 负责不同业务线。如果设计得不够精细子 Agent 之间会反复传递同一批大文本主 Agent 还要把所有子 Agent 的中间结果再汇总一次。原本一个模型调用就能解决的问题被拆成了五六次调用而且中间数据在多个会话之间来回拷贝Token 消耗呈指数级上升。这三种场景的共同特点是只看总量你根本不知道问题出在哪。所以我一直坚持一个观点Token 治理的第一步不是优化而是记账。明细都看不清所有的优化动作都是盲人摸象。1.2 记录是第一步找到开销明细的源头OpenClaw 默认会把消息和调用记录存在本地 SQLite 数据库里数据目录一般在~/.openclaw/下。不同版本的存储结构可能有差异但思路是一致的框架每次调用 LLM 之后都会生成一条包含模型、输入 Token 数、输出 Token 数、总 Token 数、会话 ID、时间戳的使用记录。我先用命令行看一眼表结构这是最稳妥的做法别直接照抄网上代码sqlite3 ~/.openclaw/data/openclaw.db .tables .schema usage_events在我的环境里usage_events表的字段大概是这样的字段名含义id主键session_id会话 IDmodel模型名称如 gpt-4o-miniprompt_tokens输入 Token 数completion_tokens输出 Token 数total_tokens总 Token 数timestamp调用时间戳毫秒如果你用的版本里表名不一样也可以用PRAGMA table_info(表名)查看实际字段。这里要多说一句我见过不少人把“计费 Token”和“登录鉴权 Token”搞混。网上搜 OpenClaw Token跳出来一大堆token exchange failed、sign-in could not be completed那是 OAuth 登录认证的问题跟账单飞涨没有关系。如果登录报错去查凭证配置如果账单飞涨来看本文的监控方案。这两件事从根上就不是一回事。有了明细表下一步就是把它变成能指导决策的指标。2. 方案一Agent Dashboard自己动手把账本摊开2.1 仪表盘的数据从哪来Agent Dashboard 是 OpenClaw 生态里配套的可视化面板默认绑定本地数据目录能展示消息流、会话列表、任务状态这些基础信息。它的价值在于开箱即用部署完 OpenClaw 就能看到智能体在干什么。但说实话它默认的统计页面偏“展示”适合看过程和状态不适合深入做成本分析。要看透 Token 消耗核心是把原始明细变成三张表按天汇总、按模型汇总、按会话汇总。这三张表不仅能回答“花了多少”还能回答“花在哪了”和“哪一笔最可疑”。Agent Dashboard 通常支持自定义面板我们可以把聚合结果同步进去实现可视化看板。这里要提醒一下如果你的 Agent Dashboard 只是连接了本地 SQLite最好的做法不是直接改它的底层数据而是新建一张独立的汇总表。这样既不影响原有功能又能让 Dashboard 读取到成本数据。如果你和我一样用 Docker 部署 OpenClaw数据库文件在宿主机挂载目录里路径可能是/data/openclaw.db先确认挂载配置再操作。2.2 用 Python 把 OpenClaw 的 Token 账本算清楚我的做法是写一个 Python 脚本直接从 SQLite 读数据用 Pandas 做聚合。脚本的核心逻辑很简单读取usage_events表按天、按模型、按会话分别聚合总 Token 数然后输出统计结果。import sqlite3 import pandas as pd from datetime import datetime DB_PATH /data/openclaw.db conn sqlite3.connect(DB_PATH) df pd.read_sql_query( SELECT strftime(%Y-%m-%d, datetime(timestamp/1000, unixepoch, localtime)) AS day, model, session_id, prompt_tokens, completion_tokens, total_tokens FROM usage_events , conn) conn.close() # 按天汇总 daily df.groupby(day)[total_tokens].sum().reset_index() print( 每日 Token 消耗 ) print(daily) # 按模型汇总 by_model df.groupby(model)[total_tokens].sum().reset_index().sort_values(total_tokens, ascendingFalse) print(\n 按模型 Token 消耗 ) print(by_model) # 按会话汇总取 TOP 10 top_sessions ( df.groupby(session_id)[total_tokens] .sum() .reset_index() .sort_values(total_tokens, ascendingFalse) .head(10) ) print(\n 会话 TOP 10 ) print(top_sessions)这段代码跑完之后你手里就有了最核心的成本账本。按天汇总用于看趋势按模型汇总用于评估模型选型是否划算按会话汇总用于揪出“哪个任务在偷偷烧钱”。我曾经靠这张按会话的 TOP 10 表定位到一个非常隐蔽的问题有个会话的 Token 消耗占了全天的 40%点进去一看原来是任务配置里的轮询间隔写错了导致智能体每 10 秒就调用一次 LLM 做状态判断而不是按预期等待 5 分钟。这种问题不按会话拆开根本发现不了。如果你想把结果直接同步到 Agent Dashboard可以在数据库里新建一张token_daily_summary表把聚合结果写进去然后在 Dashboard 里配置 SQL 查询读取这张表。示例写入逻辑如下daily.to_sql(token_daily_summary, conn, if_existsreplace, indexFalse)注意to_sql需要 Pandas 的 SQLAlchemy 支持如果没有安装可以改用insert语句手动写入。这里不展开思路就是把聚合结果落库供 Dashboard 查询。2.3 在 Dashboard 上建立“预算警戒线”账本摊开之后下一步是设定预算警戒线。我建议别只盯着“花了多少钱”要建立一个比例指标当日消耗占当日预算的百分比。当这个比率超过 80% 时图表颜色就要变提醒你该踩刹车了。在 Agent Dashboard 里可以用一段 SQL 直接实现这个指标。假设我在数据库里维护了一张daily_budget表里面有日期和预算金额再结合token_daily_summary表就可以算出消耗占比SELECT s.day, s.total_tokens, b.budget_tokens, ROUND(s.total_tokens * 100.0 / b.budget_tokens, 2) AS consume_percent FROM token_daily_summary s LEFT JOIN daily_budget b ON s.day b.day WHERE s.day CURRENT_DATE ORDER BY s.day DESC;这里有个细节预算单位要统一。我习惯把 Token 数量和金额分开管理因为不同模型单价不一样。更精确的做法是先在明细表里增加一列cost用模型单价乘以 Token 数得到每次调用的金额然后再按天汇总。这样 Dashboard 里既能看 Token 趋势也能看真实成本。在 Dashboard 上设完警戒线之后有一个认知必须建立起来Agent Dashboard 方案的本质是“事后看清楚”。它的优点是无侵入、部署快、代码量小特别适合个人项目和刚起步的小团队。它的缺点是只负责展示不会主动喊你。如果预算是一天一崩等你早上打开 Dashboard 看到警戒线变红时钱已经花出去了。所以我一直把 Dashboard 称作“账本”它解决的是糊涂账问题解决不了“失控瞬间”的实时拦截。这也正是我引入第二套方案的直接原因。3. 方案二阿里云 SLS把 Token 账本变成实时监控3.1 为什么要用 SLS 而不是本地看板本地看板能解决“事后看账”但解决不了“事中感知”。阿里云 SLS日志服务能补上三个 Dashboard 做不到的能力。第一是实时采集。每次 LLM 调用一结束就把用量上报到 SLS日志从产生到可查询的延迟通常在秒级。这意味着你能看到“刚刚过去 5 分钟花了多少 Token”而不是“昨天花了多少”。第二是集中查询。如果你用 OpenClaw 部署了多个实例比如开发环境一个、生产环境一个本地 SQLite 各自为政没法统一看总账。SLS 可以把所有实例的 Token 用量汇总到同一个 Logstore按环境、按业务线任意切分。第三是托管告警。SLS 自带告警能力查询结果超过阈值就触发通知支持钉钉、企业微信、邮件、Webhook 等多种渠道。你不用自己写 Cron 脚本轮询账单不用自己维护告警服务SLS 帮你把这些都托管了。用一句话概括我的选型逻辑Agent Dashboard 适合回答“昨天花了多少”SLS 适合回答“现在正在花多少是否正常”。两套方案不是二选一而是互补。3.2 日志采集与上报代码要用 SLS前置条件是有一台阿里云账号、开通日志服务、创建一个 Project 和一个 Logstore。Project 相当于日志项目容器Logstore 是具体的日志库。创建过程在控制台点几下就能完成不再赘述重点说代码。我用的上报方式是阿里云官方 Python SDK叫aliyun-log-python-sdk。安装命令如下pip install aliyun-log-python-sdk然后写一个上报函数。核心是把每次 LLM 调用的用量信息构造成 LogItem调用PutLogsRequest发送到指定 Logstoreimport os import time from aliyun.log import LogClient, PutLogsRequest, LogItem ENDPOINT cn-hangzhou.log.aliyuncs.com PROJECT openclaw-token-monitor LOGSTORE token-usage ACCESS_KEY_ID os.getenv(ALIBABA_CLOUD_ACCESS_KEY_ID) ACCESS_KEY_SECRET os.getenv(ALIBABA_CLOUD_ACCESS_KEY_SECRET) client LogClient(ENDPOINT, ACCESS_KEY_ID, ACCESS_KEY_SECRET) def report_usage(session_id, model, prompt_tokens, completion_tokens): total prompt_tokens completion_tokens log_item LogItem() log_item.set_contents( session_idstr(session_id), modelstr(model), prompt_tokensstr(prompt_tokens), completion_tokensstr(completion_tokens), total_tokensstr(total), timestampstr(int(time.time() * 1000)), envos.getenv(OPENCLAW_ENV, dev), ) req PutLogsRequest(PROJECT, LOGSTORE, topicopenclaw, log_items[log_item]) client.put_logs(req)这里有几个细节值得展开。第一set_contents的参数都是字符串SDK 的日志格式要求这样。数值类字段先转成字符串查询时再用 SLS 的sum、avg函数做计算。第二LOGSTORE的名称只允许小写字母、数字和短横线命名时注意避开大写。第三上报时机很关键。我是在 OpenClaw 的调用回调里上报。如果框架支持事件钩子就在 LLM 响应事件里调用report_usage如果不支持可以在包装层加一个中间件统一接收所有 LLM 请求的响应体。还有一种更简单的手段定期扫描本地 SQLite把新增记录增量同步到 SLS。这个方案对框架无侵入实时性差一些但实现成本最低。下面这段代码展示增量同步的思路import sqlite3 import time LAST_ID_FILE /tmp/openclaw_last_sync_id def sync_since(last_id): conn sqlite3.connect(DB_PATH) rows conn.execute( SELECT id, session_id, model, prompt_tokens, completion_tokens, total_tokens, timestamp FROM usage_events WHERE id ? ORDER BY id ASC , (last_id,)).fetchall() conn.close() for row in rows: report_usage( session_idrow[1], modelrow[2], prompt_tokensrow[3], completion_tokensrow[4], ) last_id row[0] with open(LAST_ID_FILE, w) as f: f.write(str(last_id)) return last_id last_id 0 try: with open(LAST_ID_FILE, r) as f: last_id int(f.read().strip()) except FileNotFoundError: pass while True: last_id sync_since(last_id) time.sleep(10)增量同步的好处是不用改动 OpenClaw 内部逻辑把 SLS 当“下游数据仓库”缺点是节点宕机或重启时可能有几秒延迟。实时性要求严格的生产环境我还是推荐用回调直报。3.3 查询分析与告警配置数据进了 SLS接下来就是查询和告警。SLS 的查询语法类似 SQL但融合了日志检索和统计分析。我先给几个最常用的分析语句。按天汇总 Token 消耗* | SELECT date_format(__time__, %Y-%m-%d) AS day, sum(total_tokens) AS tokens GROUP BY day ORDER BY day查询最近 5 分钟的总消耗* | SELECT sum(total_tokens) AS tokens WHERE __time__ now() - 300按模型统计消耗占比* | SELECT model, sum(total_tokens) AS tokens, ROUND(sum(total_tokens) * 100.0 / sum(sum(total_tokens)) OVER (), 2) AS percent GROUP BY model ORDER BY tokens DESC LIMIT 10这三条语句基本覆盖了日常监控的 80% 场景看趋势、看实况、看分布。告警配置我建议这样做。在 SLS 控制台进入告警设置新建一个告警监控规则查询语句用“最近 5 分钟总消耗”触发条件设成tokens 200000检查间隔设成 1 分钟通知渠道选钉钉机器人。这样设计的意图是5 分钟消耗超过 20 万 Token说明当前的运行速率异常高需要人工介入。这个阈值不是拍脑袋定的我经历过一次教训。一开始我设的是“每分钟超过 5 万 Token”结果正常的批量任务在高峰期持续触发告警五分钟内收到十几条通知群里直接刷屏。后来我做了调整先跑一周积累基线数据算出一个 P95 值也就是 95% 的情况下每分钟消耗不超过多少再把告警阈值设在 P95 的 1.5 倍到 2 倍之间。这样既能捕捉异常又不会被正常波动淹没。提示SLS 告警里的“触发条件”和“恢复通知”要分开配置。触发条件负责发出“出事了”的信号恢复通知负责发出“已恢复”的信号。如果只配了触发通知异常期间告警会每隔一个检查周期就重复触发一次造成轰炸效果。建议开启“静默期”功能避免重复告警。4. 终结失控的核心Token 消耗算法构建4.1 滑动平均预测法提前估算今日开销有了实时数据下一个问题自然浮现能不能预测今天总共要花多少 Token如果早上九点就能预测出今天会超预算就可以提前干预而不是等晚上账单出来再捶胸顿足。我采用的预测算法是指数加权移动平均EWMA核心思想非常简单今天的预测消耗由“今日已经消耗的实际值”和“昨天的预测值”共同决定。公式如下预测值 α × 今日实际消耗 (1 - α) × 昨日预测值参数 α 取值在 0 到 1 之间它控制了预测对近期数据的敏感度。α 越大预测越跟随昨天的实际值α 越小预测越平滑。我自己实践下来智能体负载比较稳定的场景α 取 0.7 左右效果不错如果业务波动大α 可以调高到 0.9让预测更快响应近期变化。Python 实现非常简单def ewma_predict(daily_usage, alpha0.7): 输入每日 token 消耗列表返回今天结束时的预测总消耗 pred daily_usage[0] for v in daily_usage[1:]: pred alpha * v (1 - alpha) * pred return pred用法也很直白读取最近 7 天的每日消耗传入函数得到一个预测值。然后把这个预测值和今日预算放在一起比较。但这里有个坑EWMA 预测的是“全天总消耗”而一天还没过完预测值应该用“今日已消耗 剩余时间预测增量”来修正。完整逻辑是today_consumed 80000 # 今日已消耗从 SLS 实时查询 daily_budget 150000 # 今日预算 # 最近 7 天每日消耗 history [120000, 110000, 135000, 140000, 125000, 145000, 130000] predicted_total ewma_predict(history, alpha0.7) # 预计剩余消耗 remaining_pred predicted_total - today_consumed # 判断是否超预算 if today_consumed remaining_pred * 0.5 daily_budget: # 如果按当前速率进行半天就会超预算触发预警 print(预警今日预计超预算)补充一句在很多场景下一天的 Token 消耗并不是均匀分布的白天业务高峰消耗快凌晨任务少消耗慢。如果要做更精细的预测可以把“一天 24 小时”按时间段切分分别统计各时段的历史消耗均值再结合当前时段做修正。这个思路相当于把 EWMA 升级成“分时段 EWMA”代码量不大但准确率提升比较明显。4.2 突增检测识别失控的瞬间预测解决的是“今天会不会超”突增检测解决的是“现在是不是失控”。两者场景不同算法也不同。我用的突增检测方法是滑动窗口 Z-score。原理是维护一个最近 N 次调用的消耗速率序列计算它们的均值和标准差。如果当前速率比均值高出 2 个标准差以上就认为出现了异常突增。为什么选 2 个标准差在正态分布假设下大约 95% 的正常数据点落在均值 ±2 个标准差范围内。也就是说当前速率超过均值加 2 倍标准差意味着它比 95% 的历史情况都要高是一个小概率事件。这样设置既能捕获真正的异常又不会因为偶发的正常波动而误报。代码实现如下import numpy as np def detect_anomaly(rate_history, current_rate, k2.0): arr np.array(rate_history) mean arr.mean() std arr.std() if std 0: return False, mean threshold mean k * std return current_rate threshold, threshold用的时候每隔 5 分钟计算一次“最近 5 分钟的 Token 消耗量 / 300 秒”得到一个速率值放进窗口数组。窗口大小我建议取 12 个点也就是最近 1 小时的数据。窗口太短统计不稳定窗口太长反应迟钝异常维持很久才被识别。突增检测还有一个容易被忽略的细节要区分“单次调用量突增”和“调用频率突增”。前者是某一次请求带了超大上下文后者是短时间内调用次数暴增。这两种情况对应的优化手段不同单次调用量突增要从上下文管理入手检查是不是历史消息无限累积调用频率突增要从任务逻辑入手检查是不是重试循环或轮询间隔过短。所以我在上报日志时会同时记录total_tokens和request_count两个指标检测时分别做 Z-score效果更清晰。4.3 成本分摊与配额控制最后一块拼图是成本分摊与配额控制。企业级场景下OpenClaw 往往不是一个人在跑研发、运营、数据分析几个团队可能共用一个实例。如果总账单异常第一步要分清楚是哪个业务线烧的。我的做法是在上报日志时增加两个字段business和cost_model。business标识业务线cost_model标识成本模型比如按部门、按项目、按任务类型。上报代码在原有的report_usage函数里扩展一下def report_usage(session_id, model, prompt_tokens, completion_tokens, businessdefault, cost_modelNone): total prompt_tokens completion_tokens log_item LogItem() log_item.set_contents( session_idstr(session_id), modelstr(model), prompt_tokensstr(prompt_tokens), completion_tokensstr(completion_tokens), total_tokensstr(total), businessstr(business), timestampstr(int(time.time() * 1000)), ) req PutLogsRequest(PROJECT, LOGSTORE, topicopenclaw, log_items[log_item]) client.put_logs(req)对应地SLS 查询语句就能按业务线切分成本* | SELECT business, sum(total_tokens) AS tokens, ROUND(sum(total_tokens) * 100.0 / sum(sum(total_tokens)) OVER (), 2) AS percent GROUP BY business ORDER BY tokens DESC有了成本分摊配额控制才能落地。我设计的配额状态机很简单只有四个状态正常 → 预警 → 熔断 → 恢复。正常状态不做干预。当预测当日消耗将达到预算的 80% 时进入预警状态通过 SLS 告警发送通知提醒负责人检查近期任务。当预测消耗超过预算的 100% 时进入熔断状态暂停新任务调度只允许紧急任务通过。等消耗回落到安全水位且当前速率低于正常阈值才恢复执行。熔断的执行方式有两种。一种是直接改 OpenClaw 调度配置暂停任务队列另一种更温和是在 OpenClaw 入口前加一个拦截器拦截新任务请求返回“预算已用尽请明日再试”。我个人更推荐拦截器方案因为它不阻塞已经运行的任务避免把正在执行的关键流程拦腰截断。5. 实战避坑我踩过的五个坑5.1 表字段不同版本差异大OpenClaw 迭代速度很快SQLite 表名和字段名在不同版本之间可能变化。我一开始照着一个旧版本的文章写查询 SQL结果在新版本上跑直接报错no such table: usage_events。排查了半天才发现是表名改成了llm_usage。所以不管代码从哪来第一件事永远是PRAGMA table_info(表名)确认字段名。5.2 同步上报日志会卡主流程这是我踩过最疼的坑。第一次接入 SLS 时我直接在 LLM 回调里同步调用了put_logs。结果 OpenClaw 的响应延迟从 1 秒涨到了 3 秒因为每次请求都要等 HTTP 上报完成才返回。解决办法是改成异步上报Python 里可以用ThreadPoolExecutor或者消息队列。from concurrent.futures import ThreadPoolExecutor executor ThreadPoolExecutor(max_workers2) def report_usage_async(session_id, model, prompt_tokens, completion_tokens): executor.submit(report_usage, session_id, model, prompt_tokens, completion_tokens)把上报逻辑丢到线程池里主流程立刻恢复丝滑。有一点要注意线程池的max_workers不宜过大2 到 4 个就够避免上报线程抢占智能体主进程的 CPU 资源。5.3 时区问题导致“按天汇总”数据错位SLS 查询语句里用date_format(__time__)做按天聚合但__time__是 SLS 服务端收到日志的时间写日志时它按 UTC 存储而 OpenClaw 本地时间用的是东八区。如果你在凌晨 0 点到 8 点之间产生日志SLS 按天聚合会把这些日志算到前一天。这个问题很隐蔽我会在图表上看到“每天 0 点消耗清零、早上 8 点突然多出来一堆消耗”的怪象。解决办法有两个一是在上报时把本地时间转换成 UTC 字符串后塞进字段二是在查询语句里手动加时区偏移。我的习惯是上报时直接带一个local_time字符串字段查询时优先用这个字段做聚合。5.4 告警阈值设太小收到“狼来了”免疫阈值设太小的后果我已经在前面说了。这里再补充一个经验告警阈值不是一次性设置就完事要随着业务变化定期调整。我每个月会看一次过去 30 天的 Token 消耗 P95 值如果业务量涨了P95 也会涨阈值就跟着往上调。5.5 只监控总量不拆维度等于白监控只看“今日总消耗 50 万 Token”这个数字你无法判断它是否正常。50 万可能对 A 业务是正常水平对 B 业务就是失控级。所以我的监控面板永远会放三个视图总量趋势、按业务线拆分的占比、按模型的单价分析。任何一个视图单独看都有局限三个放在一起异常才会清晰暴露。6. 最后分享一点我的实际运行体会两套方案配合起来跑了一个季度之后我最大的感受是Token 消耗这个事终于从“月底开盲盒”变成了“每天看盘”。Agent Dashboard 负责给我一本清清楚楚的账SLS 负责在账目出问题的时候第一时间拍我肩膀。算法不是花哨的摆设它解决的是“等到人来看的时候已经晚了”这个核心问题。如果让我给一个最直接的落地建议那就是别追求一步到位。先跑 Agent Dashboard 方案用 Python 脚本把账算清楚坚持一周你一定会发现至少一个可以优化的点。优化完之后再上 SLS 监控和告警最后再让预测算法接管“提前预警”这件事。这个顺序每一步都能独立产生价值不会让人觉得白折腾。下一步我打算做两件事一是把预测算法做成定时任务每天早上 9 点把当日预算预估推到企业微信群让团队自己心里有数二是在熔断的拦截器里加上细粒度的控制比如允许“低优先级任务”在预算超限后继续执行但限制它的并发数。这个扩展做通了OpenClaw 的 Token 治理就算真正闭环了。