1. 从直播里的 Agentic RL 后训练切到 Prometheus 的 Token 消耗观测面在 Claude Code 里把供应商切到自建端点、在 Codex 里写错wire_api或者 Prometheus 只统计总请求数却看不到 prompt/completion 拆分时Agentic RL 的 Token 消耗观测通常会断掉。直播里小米展示 mimo-v2.6-pro 与 flash 的 Agentic RL 后训练评测表现与成本量级成为讨论点要复现这种观测先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_intro 获取 TaoToken Key请求 Base URL 设为 https://taotoken.net/api。这篇不讨论直播里的评测排名或未经核实的成本数字而是把 mimo-v2.6-pro 接入 TaoToken 端点后如何用 Claude Code、Codex、CC Switch 完成配置再用 Prometheus 记录请求数、Token 类型、延迟、错误率和 Agent 工具轮次最终得到可复现的 Token 消耗趋势。你会看到从 Key 准备、Base URL 设置、模型名确认到指标埋点、PromQL 面板、排障清单的完整路径。Agentic RL 和普通对话调用的最大区别是它的请求不是孤立的一次问答。一个 agent 轨迹里可能包含规划、选择工具、执行工具、读取观察结果、修正计划、重试、总结。每一轮都可能再次调用模型而上一轮的工具输出、错误堆栈、文件片段又会重新进入下一轮上下文。结果就是你看到的是“一个任务”但计费与限流看到的是“多次请求 不断变大的 prompt”。如果只监控 HTTP 200 数量你会得到一张很平但没用的图。真正需要拆开的是请求维度哪个模型、哪个阶段、成功还是失败Token 维度prompt、completion、total 分别增长多少延迟维度P50/P95 是否随上下文变长而上升轨迹维度工具轮次、重试次数是否异常错误维度401、404、模型名错误、流式中断是否集中出现。本文的可复现产出是一套最小可用的 Prometheus 埋点Python 侧用 OpenAI 兼容 SDK 调 TaoToken 端点指标暴露到/metricsPrometheus 抓取后用 PromQL 看 Token 消耗趋势。下面先解决接入再解决观测。2. 在 TaoToken 准备 mimo-v2.6-pro 端点Key、Base URL 与模型名准备 Prometheus 指标前先把鉴权和端点跑通。TaoToken 的 Key 获取、模型确认和控制台入口都放在官网侧不要从旧笔记里找零散配置。你可以从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_key_setup 进入官网然后按下面顺序处理打开模型对话页确认当前可用的 mimo-v2.6-pro 模型标识。不同控制台可能显示为短名或带版本后缀的 ID代码里以实际可调用名称为准。进入 API Keys 页面创建 Key。本文统一用YOUR_API_KEY作为占位符不要把真实 Key 写进博客、截图或 Git 仓库。工具配置中的 Base URL 统一填https://taotoken.net/api。注意这个地址用于 Claude Code、Codex、OpenAI 兼容 SDK 等工具配置不要额外拼接无关参数。先用本地 Python 或 curl 做一次最小请求确认 Key、模型名、网络路径都正常再进入 Prometheus 埋点。Python 侧推荐用 OpenAI 兼容客户端因为它方便读取usage字段而usage正是指标埋点的核心数据源。示例代码把 Key 放在环境变量里不要把YOUR_API_KEY硬编码到业务文件export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_MODELmimo-v2.6-proimport os from openai import OpenAI client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), base_urlhttps://taotoken.net/api, ) model os.getenv(TAOTOKEN_MODEL, mimo-v2.6-pro) resp client.chat.completions.create( modelmodel, messages[ {role: system, content: 你是一个用于连通性测试的助手。}, {role: user, content: 只回复 ok}, ], temperature0.2, ) print(resp.choices[0].message.content) print(resp.usage)这段代码能跑通说明三件事已经成立Key 有效、Base URL 正确、模型名可调用。如果这里报 401优先检查 Key 是否复制完整、环境变量是否被当前 shell 继承如果报 404 或 model not found回到模型对话页确认模型 ID如果流式请求中断先改成非流式确认基础链路再排查客户端对 SSE 的处理。在 Agentic RL 场景里建议把“连通性测试”和“业务调用”分开。连通性测试只发一条极短消息用来验证鉴权业务调用再进入多轮工具循环。否则一旦指标异常你无法判断是端点问题还是 agent 逻辑把上下文撑爆了。3. Claude Code、Codex、CC Switch 三件套配置分开协议不要串接入 TaoToken 后最常见的配置错误不是 Key 错而是把不同工具的协议混在一起。Claude Code 使用 Anthropic 风格环境变量Codex 使用config.toml和 provider 配置CC Switch 这类切换工具则要你把三套配置分别存放。记住一句话ANTHROPIC_*只给 Claude Code不要套到 Codex。3.1 Claude Codesettings.json 与 ANTHROPIC_*Claude Code 可以通过settings.json注入环境变量。下面示例中的 Base URL 保持为https://taotoken.net/apiKey 用YOUR_API_KEY占位{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: mimo-v2.6-pro, ANTHROPIC_SMALL_FAST_MODEL: mimo-v2.6-pro } }如果你使用 shell 临时覆盖也可以这样export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELmimo-v2.6-proClaude Code 的排障重点是Base URL 是否被其他配置文件覆盖、模型名是否与控制台一致、Key 是否放在ANTHROPIC_AUTH_TOKEN而不是别处。修改后重启 Claude Code 会话避免旧环境变量继续生效。3.2 Codexconfig.toml 与 providerCodex 不要使用ANTHROPIC_*。它应该走自己的config.toml把 TaoToken 作为一个 provider 配置进去。不同 Codex 版本对wire_api支持不同以下示例按常见的 chat 兼容方式写实际以你本机版本为准model mimo-v2.6-pro model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在 shell 中提供 Keyexport TAOTOKEN_API_KEYYOUR_API_KEYCodex 常见问题是把base_url写成带/v1的地址后又额外拼接路径或者把 Claude Code 的ANTHROPIC_AUTH_TOKEN填到 Codex。出现 401 时先检查env_key指向的环境变量是否存在出现 404 时检查 provider 的 Base URL出现流式协议错误时检查wire_api是否与当前 Codex 版本匹配。3.3 CC Switch 三件套Claude Code、Codex、OpenAI 兼容 CLI如果你用 CC Switch 管理多套配置建议把它当成“配置文件切换器”而不是“协议翻译器”。三件套可以这样分Claude Code 配置ANTHROPIC_BASE_URLhttps://taotoken.net/api、ANTHROPIC_AUTH_TOKENYOUR_API_KEY、ANTHROPIC_MODELmimo-v2.6-pro。Codex 配置model_providertaotoken、base_urlhttps://taotoken.net/api、env_keyTAOTOKEN_API_KEY、wire_apichat。OpenAI 兼容 CLI 配置OPENAI_BASE_URLhttps://taotoken.net/api、OPENAI_API_KEYYOUR_API_KEY、modelmimo-v2.6-pro。对应环境变量示例export TAOTOKEN_API_KEYYOUR_API_KEY # Claude Code export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_MODELmimo-v2.6-pro # OpenAI 兼容 CLI不要把这组变量填到 Codex 的 provider 里 export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY$TAOTOKEN_API_KEY切换配置后建议每个工具都用一条最小请求验证而不是直接跑完整 agent 任务。这样一旦指标里错误率上升你能快速定位是哪一套配置没有生效。4. 用 Prometheus 埋点记录 Agentic RL 的 Token 消耗指标、标签、代码接入完成后进入本文重点Prometheus 指标埋点。准备指标时你仍然需要 TaoToken Key 和 Base URL如果你还没创建 Key可以从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_prometheus 进入官网再从 API Keys 页面创建。请求端点保持https://taotoken.net/api。指标设计不要一上来就追求全量。最小可用集合如下llm_requests_total按 model、stage、status 统计请求数llm_tokens_total按 model、stage、token_type 统计 Tokentoken_type 可取 prompt、completion、totalllm_request_latency_seconds请求延迟直方图agent_tool_steps_total工具轮次计数可按 tool、stage 统计llm_errors_total如果不想把错误都塞进 requests 的 status也可以单独建一个错误计数器。标签要控制基数。不要用完整 prompt、完整 session id、完整文件路径作为标签否则 Prometheus 时间序列会爆炸。可以用有限的stage例如plan、tool_call、observe、reflect、final可以用statusok/error模型名用mimo-v2.6-pro这类有限值。轨迹 ID 更适合放日志或 tracing不要直接做 Prometheus 标签。下面是一段可本地运行的 Python 埋点示例仍然通过 TaoToken 端点调用并从响应usage中提取 Tokenimport os import time from openai import OpenAI from prometheus_client import Counter, Histogram, start_http_server MODEL os.getenv(TAOTOKEN_MODEL, mimo-v2.6-pro) client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), base_urlhttps://taotoken.net/api, ) REQUESTS Counter( llm_requests_total, LLM request count, [model, stage, status], ) TOKENS Counter( llm_tokens_total, Token usage by type, [model, stage, token_type], ) LATENCY Histogram( llm_request_latency_seconds, LLM request latency in seconds, [model, stage], buckets(0.5, 1, 2, 5, 10, 20, 60, 120), ) TOOL_STEPS Counter( agent_tool_steps_total, Agent tool step count, [tool, stage], ) def call_llm(messages, stageagent_step, toolnone): start time.time() status ok try: resp client.chat.completions.create( modelMODEL, messagesmessages, temperature0.2, ) usage resp.usage if usage is not None: TOKENS.labels(MODEL, stage, prompt).inc(usage.prompt_tokens or 0) TOKENS.labels(MODEL, stage, completion).inc(usage.completion_tokens or 0) TOKENS.labels(MODEL, stage, total).inc(usage.total_tokens or 0) if tool ! none: TOOL_STEPS.labels(tool, stage).inc() return resp except Exception: status error raise finally: REQUESTS.labels(MODEL, stage, status).inc() LATENCY.labels(MODEL, stage).observe(time.time() - start) if __name__ __main__: start_http_server(8000) prompt [ {role: system, content: 你是 Agentic RL 观测测试助手。}, {role: user, content: 只回复 ok}, ] out call_llm(prompt, stagesmoke, toolnone) print(out.choices[0].message.content)启动后本地访问http://127.0.0.1:8000/metrics应该能看到llm_requests_total、llm_tokens_total等指标。接着让 Prometheus 抓取scrape_configs: - job_name: agentic-rl-llm metrics_path: /metrics static_configs: - targets: [127.0.0.1:8000]如果你把埋点放在容器里把targets改成容器 IP 或服务名。不要在指标代码里写生产数据库连接也不要让 agent 直接操作数据库本文的命令和测试都由读者在本地执行。5. Token 消耗趋势怎么读按阶段、工具轮次和错误率拆分指标有了之后关键不是“看到总数”而是解释趋势。Agentic RL 的 Token 曲线通常有三种典型形态第一阶梯式上升。每次工具调用后观察结果被追加到上下文下一轮 prompt Token 比上一轮更高。你会看到llm_tokens_total{token_typeprompt}呈阶梯增长而 completion 相对平稳。这通常说明上下文管理策略需要优化例如裁剪旧观察、摘要工具输出、限制文件片段长度。第二尖峰式上升。某个阶段错误重试集中出现导致请求数和 Token 同时冲高。对应指标是llm_requests_total{statuserror}与llm_tokens_total同时增长。此时要看错误类型是 Key 失效、模型名错误还是流式连接中断。接入层问题不要误判为模型消耗问题。第三缓慢漂移。P95 延迟和 prompt Token 同时缓慢上升说明轨迹变长、上下文膨胀。Agentic RL 后训练早期尤其容易出现这种曲线因为模型还在探索工具使用策略重试和回退可能更频繁。常用 PromQL 如下。先看每分钟 Token 速率sum by (model, token_type) ( rate(llm_tokens_total[1m]) )再看不同阶段的 Token 增量sum by (stage, token_type) ( increase(llm_tokens_total[1h]) )平均每请求 Tokensum by (model) ( rate(llm_tokens_total{token_typetotal}[5m]) ) / sum by (model) ( rate(llm_requests_total[5m]) )P95 延迟histogram_quantile( 0.95, sum by (le, model) ( rate(llm_request_latency_seconds_bucket[5m]) ) )错误率sum(rate(llm_requests_total{statuserror}[5m])) / sum(rate(llm_requests_total[5m]))工具轮次趋势sum by (tool, stage) ( rate(agent_tool_steps_total[5m]) )看板建议分四行第一行总请求与错误率第二行 prompt/completion/total Token 速率第三行各阶段 Token 增量第四行 P95 延迟与工具轮次。这样当 Token 曲线异常时你能快速判断是上下文变长、重试变多还是某个工具阶段调用频率升高。告警可以设得克制一些错误率连续超过你本地基线、P95 延迟显著高于日常、单位时间 total Token 超过预期阈值、工具轮次异常升高。阈值不要照搬别人的数字按你自己的任务长度和模型行为调整。6. 可复现实验清单从一次调用到一张趋势面板要把本文变成可复现产出可以按下面顺序执行。每一步都只依赖本地环境和你自己的 TaoToken Key打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_repro 进入官网并创建 TaoToken Key。在模型对话页确认 mimo-v2.6-pro 的实际模型名必要时替换示例中的mimo-v2.6-pro。设置TAOTOKEN_API_KEYYOUR_API_KEY工具 Base URL 填https://taotoken.net/api。分别配置 Claude Code 的settings.json、Codex 的config.toml、CC Switch 的三套切换项。不要混用ANTHROPIC_*与 Codex provider。用 Python OpenAI 兼容 SDK 跑一次连通性测试确认usage字段有返回。启动 Prometheus 埋点服务本地访问/metrics确认指标名称存在。配置 Prometheus scrape抓取127.0.0.1:8000。跑一段 agent 回放或评测循环观察llm_tokens_total、llm_requests_total、llm_request_latency_seconds的变化。在 Grafana 或 Prometheus 表达式浏览器中执行本文 PromQL保存面板。记录一次异常例如故意填错模型名观察错误率与请求数如何变化再恢复配置。常见排障可以归纳成表401Key 缺失、复制不完整、环境变量未生效。检查YOUR_API_KEY是否被真实 Key 替换。404Base URL 或路径不对。工具配置统一用https://taotoken.net/api。model not found模型名与控制台不一致。回到模型对话页确认。流式中断先用非流式验证再检查客户端 SSE 处理。指标为空确认start_http_server已启动Prometheus 能访问目标端口。Token 为 0确认响应usage是否存在部分兼容层可能不返回 usage需要换调用方式或检查返回结构。标签基数过高不要用 session id、完整 prompt 做标签改用有限的 stage、tool、status。这套流程的重点不是“看一个总 Token 数”而是把 Agentic RL 的调用拆成可解释的维度。直播里讨论的训练早期表现和成本量级背后其实是同一件事多轮、工具化、长上下文的调用模式会让消耗从单点变成曲线。只有把请求、Token、延迟、错误、工具轮次都记录下来你才能判断曲线变化来自模型行为、接入配置还是 agent 策略。7. 下一步模型对话、Coding Plan、创建 Key 与 Claude Code 文档如果你已经跑通 Prometheus 埋点下一步可以按下面路径继续先到模型对话页确认 mimo-v2.6-pro 和其他模型的可用状态https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_chat如果要做长周期 Agentic 评测或 Coding 场景查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_coding_plan需要创建或管理 Key 时进入 API Keys 控制台https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_api_keysClaude Code 的配置细节、环境变量和 settings.json 写法参考 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_claude_code_doc完成这些步骤后你的本地环境里应该同时具备可调用的 TaoToken 端点、Claude Code/Codex/CC Switch 三套配置、Prometheus 指标暴露、Token 消耗趋势面板。后续无论你是复现 Agentic RL 后训练观测还是给普通 agent 任务做成本分析都可以从这套指标开始扩展。 看 Agentic RL 烧 Token：mimo-v2.6-pro 接 TaoToken 端点
1. 从直播里的 Agentic RL 后训练切到 Prometheus 的 Token 消耗观测面在 Claude Code 里把供应商切到自建端点、在 Codex 里写错wire_api或者 Prometheus 只统计总请求数却看不到 prompt/completion 拆分时Agentic RL 的 Token 消耗观测通常会断掉。直播里小米展示 mimo-v2.6-pro 与 flash 的 Agentic RL 后训练评测表现与成本量级成为讨论点要复现这种观测先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_intro 获取 TaoToken Key请求 Base URL 设为 https://taotoken.net/api。这篇不讨论直播里的评测排名或未经核实的成本数字而是把 mimo-v2.6-pro 接入 TaoToken 端点后如何用 Claude Code、Codex、CC Switch 完成配置再用 Prometheus 记录请求数、Token 类型、延迟、错误率和 Agent 工具轮次最终得到可复现的 Token 消耗趋势。你会看到从 Key 准备、Base URL 设置、模型名确认到指标埋点、PromQL 面板、排障清单的完整路径。Agentic RL 和普通对话调用的最大区别是它的请求不是孤立的一次问答。一个 agent 轨迹里可能包含规划、选择工具、执行工具、读取观察结果、修正计划、重试、总结。每一轮都可能再次调用模型而上一轮的工具输出、错误堆栈、文件片段又会重新进入下一轮上下文。结果就是你看到的是“一个任务”但计费与限流看到的是“多次请求 不断变大的 prompt”。如果只监控 HTTP 200 数量你会得到一张很平但没用的图。真正需要拆开的是请求维度哪个模型、哪个阶段、成功还是失败Token 维度prompt、completion、total 分别增长多少延迟维度P50/P95 是否随上下文变长而上升轨迹维度工具轮次、重试次数是否异常错误维度401、404、模型名错误、流式中断是否集中出现。本文的可复现产出是一套最小可用的 Prometheus 埋点Python 侧用 OpenAI 兼容 SDK 调 TaoToken 端点指标暴露到/metricsPrometheus 抓取后用 PromQL 看 Token 消耗趋势。下面先解决接入再解决观测。2. 在 TaoToken 准备 mimo-v2.6-pro 端点Key、Base URL 与模型名准备 Prometheus 指标前先把鉴权和端点跑通。TaoToken 的 Key 获取、模型确认和控制台入口都放在官网侧不要从旧笔记里找零散配置。你可以从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_key_setup 进入官网然后按下面顺序处理打开模型对话页确认当前可用的 mimo-v2.6-pro 模型标识。不同控制台可能显示为短名或带版本后缀的 ID代码里以实际可调用名称为准。进入 API Keys 页面创建 Key。本文统一用YOUR_API_KEY作为占位符不要把真实 Key 写进博客、截图或 Git 仓库。工具配置中的 Base URL 统一填https://taotoken.net/api。注意这个地址用于 Claude Code、Codex、OpenAI 兼容 SDK 等工具配置不要额外拼接无关参数。先用本地 Python 或 curl 做一次最小请求确认 Key、模型名、网络路径都正常再进入 Prometheus 埋点。Python 侧推荐用 OpenAI 兼容客户端因为它方便读取usage字段而usage正是指标埋点的核心数据源。示例代码把 Key 放在环境变量里不要把YOUR_API_KEY硬编码到业务文件export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_MODELmimo-v2.6-proimport os from openai import OpenAI client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), base_urlhttps://taotoken.net/api, ) model os.getenv(TAOTOKEN_MODEL, mimo-v2.6-pro) resp client.chat.completions.create( modelmodel, messages[ {role: system, content: 你是一个用于连通性测试的助手。}, {role: user, content: 只回复 ok}, ], temperature0.2, ) print(resp.choices[0].message.content) print(resp.usage)这段代码能跑通说明三件事已经成立Key 有效、Base URL 正确、模型名可调用。如果这里报 401优先检查 Key 是否复制完整、环境变量是否被当前 shell 继承如果报 404 或 model not found回到模型对话页确认模型 ID如果流式请求中断先改成非流式确认基础链路再排查客户端对 SSE 的处理。在 Agentic RL 场景里建议把“连通性测试”和“业务调用”分开。连通性测试只发一条极短消息用来验证鉴权业务调用再进入多轮工具循环。否则一旦指标异常你无法判断是端点问题还是 agent 逻辑把上下文撑爆了。3. Claude Code、Codex、CC Switch 三件套配置分开协议不要串接入 TaoToken 后最常见的配置错误不是 Key 错而是把不同工具的协议混在一起。Claude Code 使用 Anthropic 风格环境变量Codex 使用config.toml和 provider 配置CC Switch 这类切换工具则要你把三套配置分别存放。记住一句话ANTHROPIC_*只给 Claude Code不要套到 Codex。3.1 Claude Codesettings.json 与 ANTHROPIC_*Claude Code 可以通过settings.json注入环境变量。下面示例中的 Base URL 保持为https://taotoken.net/apiKey 用YOUR_API_KEY占位{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: mimo-v2.6-pro, ANTHROPIC_SMALL_FAST_MODEL: mimo-v2.6-pro } }如果你使用 shell 临时覆盖也可以这样export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELmimo-v2.6-proClaude Code 的排障重点是Base URL 是否被其他配置文件覆盖、模型名是否与控制台一致、Key 是否放在ANTHROPIC_AUTH_TOKEN而不是别处。修改后重启 Claude Code 会话避免旧环境变量继续生效。3.2 Codexconfig.toml 与 providerCodex 不要使用ANTHROPIC_*。它应该走自己的config.toml把 TaoToken 作为一个 provider 配置进去。不同 Codex 版本对wire_api支持不同以下示例按常见的 chat 兼容方式写实际以你本机版本为准model mimo-v2.6-pro model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在 shell 中提供 Keyexport TAOTOKEN_API_KEYYOUR_API_KEYCodex 常见问题是把base_url写成带/v1的地址后又额外拼接路径或者把 Claude Code 的ANTHROPIC_AUTH_TOKEN填到 Codex。出现 401 时先检查env_key指向的环境变量是否存在出现 404 时检查 provider 的 Base URL出现流式协议错误时检查wire_api是否与当前 Codex 版本匹配。3.3 CC Switch 三件套Claude Code、Codex、OpenAI 兼容 CLI如果你用 CC Switch 管理多套配置建议把它当成“配置文件切换器”而不是“协议翻译器”。三件套可以这样分Claude Code 配置ANTHROPIC_BASE_URLhttps://taotoken.net/api、ANTHROPIC_AUTH_TOKENYOUR_API_KEY、ANTHROPIC_MODELmimo-v2.6-pro。Codex 配置model_providertaotoken、base_urlhttps://taotoken.net/api、env_keyTAOTOKEN_API_KEY、wire_apichat。OpenAI 兼容 CLI 配置OPENAI_BASE_URLhttps://taotoken.net/api、OPENAI_API_KEYYOUR_API_KEY、modelmimo-v2.6-pro。对应环境变量示例export TAOTOKEN_API_KEYYOUR_API_KEY # Claude Code export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_MODELmimo-v2.6-pro # OpenAI 兼容 CLI不要把这组变量填到 Codex 的 provider 里 export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY$TAOTOKEN_API_KEY切换配置后建议每个工具都用一条最小请求验证而不是直接跑完整 agent 任务。这样一旦指标里错误率上升你能快速定位是哪一套配置没有生效。4. 用 Prometheus 埋点记录 Agentic RL 的 Token 消耗指标、标签、代码接入完成后进入本文重点Prometheus 指标埋点。准备指标时你仍然需要 TaoToken Key 和 Base URL如果你还没创建 Key可以从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_prometheus 进入官网再从 API Keys 页面创建。请求端点保持https://taotoken.net/api。指标设计不要一上来就追求全量。最小可用集合如下llm_requests_total按 model、stage、status 统计请求数llm_tokens_total按 model、stage、token_type 统计 Tokentoken_type 可取 prompt、completion、totalllm_request_latency_seconds请求延迟直方图agent_tool_steps_total工具轮次计数可按 tool、stage 统计llm_errors_total如果不想把错误都塞进 requests 的 status也可以单独建一个错误计数器。标签要控制基数。不要用完整 prompt、完整 session id、完整文件路径作为标签否则 Prometheus 时间序列会爆炸。可以用有限的stage例如plan、tool_call、observe、reflect、final可以用statusok/error模型名用mimo-v2.6-pro这类有限值。轨迹 ID 更适合放日志或 tracing不要直接做 Prometheus 标签。下面是一段可本地运行的 Python 埋点示例仍然通过 TaoToken 端点调用并从响应usage中提取 Tokenimport os import time from openai import OpenAI from prometheus_client import Counter, Histogram, start_http_server MODEL os.getenv(TAOTOKEN_MODEL, mimo-v2.6-pro) client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), base_urlhttps://taotoken.net/api, ) REQUESTS Counter( llm_requests_total, LLM request count, [model, stage, status], ) TOKENS Counter( llm_tokens_total, Token usage by type, [model, stage, token_type], ) LATENCY Histogram( llm_request_latency_seconds, LLM request latency in seconds, [model, stage], buckets(0.5, 1, 2, 5, 10, 20, 60, 120), ) TOOL_STEPS Counter( agent_tool_steps_total, Agent tool step count, [tool, stage], ) def call_llm(messages, stageagent_step, toolnone): start time.time() status ok try: resp client.chat.completions.create( modelMODEL, messagesmessages, temperature0.2, ) usage resp.usage if usage is not None: TOKENS.labels(MODEL, stage, prompt).inc(usage.prompt_tokens or 0) TOKENS.labels(MODEL, stage, completion).inc(usage.completion_tokens or 0) TOKENS.labels(MODEL, stage, total).inc(usage.total_tokens or 0) if tool ! none: TOOL_STEPS.labels(tool, stage).inc() return resp except Exception: status error raise finally: REQUESTS.labels(MODEL, stage, status).inc() LATENCY.labels(MODEL, stage).observe(time.time() - start) if __name__ __main__: start_http_server(8000) prompt [ {role: system, content: 你是 Agentic RL 观测测试助手。}, {role: user, content: 只回复 ok}, ] out call_llm(prompt, stagesmoke, toolnone) print(out.choices[0].message.content)启动后本地访问http://127.0.0.1:8000/metrics应该能看到llm_requests_total、llm_tokens_total等指标。接着让 Prometheus 抓取scrape_configs: - job_name: agentic-rl-llm metrics_path: /metrics static_configs: - targets: [127.0.0.1:8000]如果你把埋点放在容器里把targets改成容器 IP 或服务名。不要在指标代码里写生产数据库连接也不要让 agent 直接操作数据库本文的命令和测试都由读者在本地执行。5. Token 消耗趋势怎么读按阶段、工具轮次和错误率拆分指标有了之后关键不是“看到总数”而是解释趋势。Agentic RL 的 Token 曲线通常有三种典型形态第一阶梯式上升。每次工具调用后观察结果被追加到上下文下一轮 prompt Token 比上一轮更高。你会看到llm_tokens_total{token_typeprompt}呈阶梯增长而 completion 相对平稳。这通常说明上下文管理策略需要优化例如裁剪旧观察、摘要工具输出、限制文件片段长度。第二尖峰式上升。某个阶段错误重试集中出现导致请求数和 Token 同时冲高。对应指标是llm_requests_total{statuserror}与llm_tokens_total同时增长。此时要看错误类型是 Key 失效、模型名错误还是流式连接中断。接入层问题不要误判为模型消耗问题。第三缓慢漂移。P95 延迟和 prompt Token 同时缓慢上升说明轨迹变长、上下文膨胀。Agentic RL 后训练早期尤其容易出现这种曲线因为模型还在探索工具使用策略重试和回退可能更频繁。常用 PromQL 如下。先看每分钟 Token 速率sum by (model, token_type) ( rate(llm_tokens_total[1m]) )再看不同阶段的 Token 增量sum by (stage, token_type) ( increase(llm_tokens_total[1h]) )平均每请求 Tokensum by (model) ( rate(llm_tokens_total{token_typetotal}[5m]) ) / sum by (model) ( rate(llm_requests_total[5m]) )P95 延迟histogram_quantile( 0.95, sum by (le, model) ( rate(llm_request_latency_seconds_bucket[5m]) ) )错误率sum(rate(llm_requests_total{statuserror}[5m])) / sum(rate(llm_requests_total[5m]))工具轮次趋势sum by (tool, stage) ( rate(agent_tool_steps_total[5m]) )看板建议分四行第一行总请求与错误率第二行 prompt/completion/total Token 速率第三行各阶段 Token 增量第四行 P95 延迟与工具轮次。这样当 Token 曲线异常时你能快速判断是上下文变长、重试变多还是某个工具阶段调用频率升高。告警可以设得克制一些错误率连续超过你本地基线、P95 延迟显著高于日常、单位时间 total Token 超过预期阈值、工具轮次异常升高。阈值不要照搬别人的数字按你自己的任务长度和模型行为调整。6. 可复现实验清单从一次调用到一张趋势面板要把本文变成可复现产出可以按下面顺序执行。每一步都只依赖本地环境和你自己的 TaoToken Key打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_repro 进入官网并创建 TaoToken Key。在模型对话页确认 mimo-v2.6-pro 的实际模型名必要时替换示例中的mimo-v2.6-pro。设置TAOTOKEN_API_KEYYOUR_API_KEY工具 Base URL 填https://taotoken.net/api。分别配置 Claude Code 的settings.json、Codex 的config.toml、CC Switch 的三套切换项。不要混用ANTHROPIC_*与 Codex provider。用 Python OpenAI 兼容 SDK 跑一次连通性测试确认usage字段有返回。启动 Prometheus 埋点服务本地访问/metrics确认指标名称存在。配置 Prometheus scrape抓取127.0.0.1:8000。跑一段 agent 回放或评测循环观察llm_tokens_total、llm_requests_total、llm_request_latency_seconds的变化。在 Grafana 或 Prometheus 表达式浏览器中执行本文 PromQL保存面板。记录一次异常例如故意填错模型名观察错误率与请求数如何变化再恢复配置。常见排障可以归纳成表401Key 缺失、复制不完整、环境变量未生效。检查YOUR_API_KEY是否被真实 Key 替换。404Base URL 或路径不对。工具配置统一用https://taotoken.net/api。model not found模型名与控制台不一致。回到模型对话页确认。流式中断先用非流式验证再检查客户端 SSE 处理。指标为空确认start_http_server已启动Prometheus 能访问目标端口。Token 为 0确认响应usage是否存在部分兼容层可能不返回 usage需要换调用方式或检查返回结构。标签基数过高不要用 session id、完整 prompt 做标签改用有限的 stage、tool、status。这套流程的重点不是“看一个总 Token 数”而是把 Agentic RL 的调用拆成可解释的维度。直播里讨论的训练早期表现和成本量级背后其实是同一件事多轮、工具化、长上下文的调用模式会让消耗从单点变成曲线。只有把请求、Token、延迟、错误、工具轮次都记录下来你才能判断曲线变化来自模型行为、接入配置还是 agent 策略。7. 下一步模型对话、Coding Plan、创建 Key 与 Claude Code 文档如果你已经跑通 Prometheus 埋点下一步可以按下面路径继续先到模型对话页确认 mimo-v2.6-pro 和其他模型的可用状态https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_chat如果要做长周期 Agentic 评测或 Coding 场景查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_coding_plan需要创建或管理 Key 时进入 API Keys 控制台https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_api_keysClaude Code 的配置细节、环境变量和 settings.json 写法参考 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentagentic_rl_cta_claude_code_doc完成这些步骤后你的本地环境里应该同时具备可调用的 TaoToken 端点、Claude Code/Codex/CC Switch 三套配置、Prometheus 指标暴露、Token 消耗趋势面板。后续无论你是复现 Agentic RL 后训练观测还是给普通 agent 任务做成本分析都可以从这套指标开始扩展。