1. 从一批格式异常的文件说起探测型智能体为什么要拆 Key前阵子圈里在传一件事有研究团队披露某个自动化智能体在没人盯着的情况下把第三方模型托管平台的接口当成了自己的练兵场用一批格式异常的文件反复撞边界。这类消息看看就好但它顺手暴露了一个纯工程问题——当智能体的任务从对话变成探测时它手里的那把 Key 就不再是背书凭据而是一张通行证。通行证给多大范围得有人管。我最近在做的一件事是把手上几个负责接口自检的智能体收敛到统一入口顺手把 Key 分级和 Token 审计重做了一遍。触发点很具体之前所有探测任务共用一个 Key跑了两天日志里 429 和 401 交替出现rate limit exceeded和invalid api key混在同一条重试链路里排查的时候根本分不清是哪类任务把额度打满的。更糟的是有一次我们把 L0 的轻量探针和 L2 的深度推理放在同一个 Key 下深度任务把限额吃干净之后轻量探针集体 429整条巡检链路停摆。所以这篇文章不讲新闻只讲接入和排障。整篇的落点是三份产出物一张 Key 分级表、一套结构化探测日志、一份 Token 用量对照。所有配置都用 TaoToken 做统一请求入口官网地址放在这里后文步骤都从这里开始https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentkey_tier_intro先说明本文的边界免得被误读下面出现的探测指的是对你自己拥有授权的接口做契约自检——校验响应结构、字段类型、错误码是否符合约定再把异常样本交给模型做分类和归因。不是让你去扫别人的站也不是拿模型 Key 去打第三方未授权目标。这一点在配置层面会落实成 Key 分级低级 Key 连发起重试的权限都不给。2. Key 分级表三种探测强度三把不同的钥匙分级的第一原则是按爆炸半径分不按任务名字分。很多人习惯按爬虫 Key / 分析 Key / 对话 Key来切结果一上新任务就要新建一把三个月后控制台里攒了二十把没人敢删的 Key。正确做法是先定义爆炸半径的等级再把任务往等级里塞。我最终的落点是三级外加一条永远不进自动化的旁路等级Key 用途命名典型任务模型档位速率策略日志要求L0tt-probe-l0接口存活检查、响应结构比对、错误码归档小体量快速模型低速率、长间隔全量落盘L1tt-agent-l1常规智能体任务、结果分类、格式归因中档模型中速率摘要 异常全量L2tt-agent-l2复杂推理、多轮重试、跨库关联分析高能力模型高速率但需预算封顶全量 人工抽查L9手工 Key不写入任何自动化配置控制台操作、临时验证按需不限不参与统计L0 的关键设计是只读且不可重试。它的调用链里不包含任何写动作脚本层面把重试次数硬编码成 0遇到 5xx 直接记日志退出交给 L1 去决定要不要再来一次。这样即使 L0 被某个循环 bug 卡死最坏结果也只是浪费一点额度不会形成探测 → 失败 → 重试 → 更大流量的雪崩。L1 是唯一允许做有限重试的等级指数退避上限我设成 3 次且重试必须换请求 ID 重新落日志不能复用原记录。这样用量账本上能看出一次请求实际消耗了几次额度。L2 最危险也最需要审计。它跑的是花钱最多的推理任务所以一定要给预算封顶并且在 Key 命名里带上用途比如tt-agent-l2-schema、tt-agent-l2-rootcause方便在用量报表里按用途下钻。命名里带用途还有一个隐性好处等你哪天要吊销能一眼看出谁会受影响。分级表定完之后判断标准就变成了一句可以写进代码评审的话如果这个任务的失败会导致对第三方产生不可控流量它就不该拿到 L1 以上的 Key。这句话比任何规范文档都好用。3. 在 TaoToken 控制台把三把钥匙做出来分级不是画在纸上的要落到控制台里。先到官网入口进控制台登录后进 API Keys 页面https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentkey_tier_console创建 Key 的实际路径控制台左侧进入 API Keys点新建命名按上一节的规范来建议带上环境和日期例如tt-probe-l0-dev-0912。三把 Key 分别创建不要图省事用同一把改名字——Key 的权限和额度是跟具体那一串字符绑定的改名不改变已泄露凭据的风险面。创建完成后的操作要点我按踩坑顺序列一遍第一创建后立刻复制并落到密钥管理里控制台一般只在创建时完整展示一次。别贴在聊天工具、别写进仓库、别放到前端构建产物里。本地开发用.envCI 用平台的密钥变量容器里用挂载的 secret 文件。第二给每把 Key 绑定明确的用途标签。标签是后面做用量对照的分组维度现在偷懒后面报表就做不出来。我的标签约定是tier:l0|tier:l1|tier:l2加owner:team-xxx。第三先做一次探活再接入智能体。探活用 curl 走一遍确认 Key 和 Base URL 是对得上的别等接完一堆工具再回头找问题# 只用环境变量传 Key不要写进命令行历史 export TAOTOKEN_API_KEYYOUR_API_KEY curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ | head -c 400如果这里返回 401先别改代码按第七节的排查表走一遍。探活通过之后再往下做工具侧配置。第四建立轮换节奏。L0 因为调用频次高、暴露面大我设的是 30 天一换L1 是 60 天L2 因为涉及高成本推理用多少天换一次取决于审计要求但一定要留一条疑似泄露立即吊销的操作路径。吊销这件事要提前演练一次确保吊销之后智能体能优雅降级到 L0而不是直接抛异常把巡检链路打死。4. 统一请求入口Base URL 一次改到位所有工具都指向同一个入口这是后面能做用量对照的前提。Base URL 固定为https://taotoken.net/api这个地址不加任何查询参数工具配置里原样填。Key 一律用占位符YOUR_API_KEY表示实际值从环境变量或本地密钥文件读取。4.1 Claude Code走 settings.json 和 ANTHROPIC_*Claude Code 的配置放在settings.json通过env段注入环境变量。注意 Claude Code 这套变量名是ANTHROPIC_前缀不要和下面 Codex 的配置混用{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5, ANTHROPIC_SMALL_FAST_MODEL: claude-haiku-4-5 } }几个容易翻车的点ANTHROPIC_AUTH_TOKEN填的是完整 Key不要自己加Bearer前缀客户端会拼。如果同时存在系统级环境变量和项目级settings.json以项目级为准但排查时记得两边都看一眼。L0 的轻量探针建议把ANTHROPIC_MODEL指向小模型不要图省事复用默认模型否则分级表就是摆设。4.2 Codex走 config.toml不要套 ANTHROPIC_*Codex 是另一套体系配置写在config.toml里走model_providers段落。把ANTHROPIC_*变量塞给 Codex 是不会生效的这是我在接入初期浪费了半小时的地方model gpt-5 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responsesenv_key指向的是环境变量名不是 Key 本身这一点和 Claude Code 的写法不同。运行时把 Key 通过环境变量喂进去export TAOTOKEN_API_KEYYOUR_API_KEY如果客户端版本要求 Base URL 带版本后缀请以本地实际报错为准在base_url后面补路径不要靠猜改动前先用第 3 节的 curl 探活确认服务端可达。4.3 CC Switch三件套一次配齐如果你在多套配置之间来回切用 CC Switch 会省很多事。它的核心就是三件套供应商名称、Base URL、API Key部分版本还会让你补模型名。三件套一一对应字段填什么供应商名称TaoToken-L1按分级命名便于人眼识别Base URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY从密钥管理粘贴不要手打我的做法是给三级各建一个 CC Switch 配置项TaoToken-L0、TaoToken-L1、TaoToken-L2。切换配置就等于切换权限等级肉眼可见比在代码里改环境变量安全得多。切换后建议立刻跑一次探活确认当前生效的是哪把 Key。5. 探测日志把每一次调用写成可审计的一条记录Key 分级解决的是给多少权限日志解决的是实际用了多少、干了什么。我的日志字段清单如下字段不多但每个都有用途字段说明trace_id单次任务的全局 ID跨重试保持不变attempt第几次尝试用来识别重试放大key_tierL0 / L1 / L2用量对照的分组键key_aliasKey 的别名不是 Key 本体target被自检的接口标识自有资产status_codeHTTP 状态码prompt_tokens/completion_tokens用量原始值latency_ms端到端耗时anomaly_type异常分类如 schema_mismatch、type_errordecisioncontinue / retry / halt最重要的一条纪律日志里永远不写 Key 本体。写别名写等级写指纹比如前 6 位加后 4 位绝不写全串。这条纪律要靠代码评审守不能靠自觉。下面是一个自检脚本的骨架做三件事对自有接口做结构比对、异常样本交给模型归因、全过程落结构化日志。为了可以本地直接跑存储用 SQLite命令和 SQL 都由你自己在本地执行import json import os import sqlite3 import time import uuid from typing import Any import requests BASE_URL https://taotoken.net/api API_KEY os.environ[TAOTOKEN_API_KEY] KEY_TIER os.getenv(TAOTOKEN_KEY_TIER, L0) KEY_ALIAS os.getenv(TAOTOKEN_KEY_ALIAS, tt-probe-l0) MODEL os.getenv(TAOTOKEN_MODEL, claude-haiku-4-5) # L0 不允许重试L1 最多 3 次L2 由上层调度控制 MAX_ATTEMPTS {L0: 1, L1: 3, L2: 3}.get(KEY_TIER, 1) DDL CREATE TABLE IF NOT EXISTS probe_audit ( trace_id TEXT, attempt INTEGER, key_tier TEXT, key_alias TEXT, target TEXT, status_code INTEGER, prompt_tokens INTEGER, completion_tokens INTEGER, latency_ms INTEGER, anomaly_type TEXT, decision TEXT, ts INTEGER ); def init_db(path: str audit.db) - sqlite3.Connection: conn sqlite3.connect(path) conn.execute(DDL) return conn def classify(anomaly: dict[str, Any]) - tuple[str, str]: 把异常样本交给模型归因返回 (类型, 决策)。 prompt ( 你是接口契约自检助手。下面是一段自查得到的异常样本 请只输出 JSON{\type\: \...\, \decision\: \continue|retry|halt\}。\n f样本{json.dumps(anomaly, ensure_asciiFalse)[:2000]} ) resp requests.post( f{BASE_URL}/v1/messages, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json, }, json{ model: MODEL, max_tokens: 256, messages: [{role: user, content: prompt}], }, timeout30, ) resp.raise_for_status() usage resp.json().get(usage, {}) text resp.json()[content][0][text] parsed json.loads(text) return parsed[type], parsed[decision], usage def log_call(conn, trace_id, attempt, target, status, usage, latency, atype, decision): conn.execute( INSERT INTO probe_audit VALUES (?,?,?,?,?,?,?,?,?,?,?,?), ( trace_id, attempt, KEY_TIER, KEY_ALIAS, target, status, usage.get(input_tokens, 0), usage.get(output_tokens, 0), int(latency * 1000), atype, decision, int(time.time()), ), ) conn.commit() def probe_once(target: str, anomaly: dict[str, Any]) - None: conn init_db() trace_id str(uuid.uuid4()) attempts MAX_ATTEMPTS for attempt in range(1, attempts 1): started time.time() usage, atype, decision {}, none, halt status 0 try: atype, decision, usage classify(anomaly) status 200 except requests.HTTPError as exc: status exc.response.status_code # 401/403 一定 halt429 交给上层降级处理 decision halt if status in (401, 403, 404) else retry except Exception: status -1 decision halt log_call(conn, trace_id, attempt, target, status, usage, time.time() - started, atype, decision) if decision ! retry: break time.sleep(min(2 ** attempt, 8)) if __name__ __main__: # anomaly 来自你自己的接口契约比对结果不要指向未授权目标 probe_once(targetself://api/contract/check, anomaly{field: id, expect: str})这段脚本里有三个刻意的设计。第一日志在 finally 语义之后落盘无论成功失败都写一条不会出现失败没记录的黑洞。第二决策由模型给出但由代码兜底401/403/404 一律 halt不给模型再试一次的机会。第三重试次数由 Key 等级决定L0 恒为 1 次从机制上消除探测任务的流量放大。6. 用量对照Key × 模型 × 任务的三维账本日志写进去之后用量对照就是几条 SQL 的事。在本地对刚才生成的audit.db执行-- 1) 各 Key 等级的调用量与 Token 消耗 SELECT key_tier, COUNT(*) AS calls, SUM(prompt_tokens) AS in_tokens, SUM(completion_tokens) AS out_tokens, SUM(prompt_tokens completion_tokens) AS total_tokens FROM probe_audit GROUP BY key_tier ORDER BY total_tokens DESC; -- 2) 重试放大率实际调用次数 / 唯一任务数 SELECT key_tier, COUNT(*) AS calls, COUNT(DISTINCT trace_id) AS tasks, ROUND(COUNT(*) * 1.0 / COUNT(DISTINCT trace_id), 2) AS retry_factor FROM probe_audit GROUP BY key_tier; -- 3) 异常类型分布用于判断哪类契约问题最费钱 SELECT anomaly_type, COUNT(*) AS cnt, SUM(prompt_tokens completion_tokens) AS total_tokens, MAX(latency_ms) AS max_latency_ms FROM probe_audit WHERE anomaly_type none GROUP BY anomaly_type ORDER BY total_tokens DESC; -- 4) 按小时看尖峰识别是不是某个定时任务把额度打满 SELECT strftime(%Y-%m-%d %H, ts, unixepoch) AS hour_bucket, key_tier, SUM(prompt_tokens completion_tokens) AS total_tokens FROM probe_audit GROUP BY hour_bucket, key_tier ORDER BY hour_bucket DESC;这四条查询对应四类决策第 1 条回答钱花在哪个等级。如果 L0 的 Token 占比超过两成说明轻量探针用了大模型回去改ANTHROPIC_MODEL或对应工具里的模型名。第 2 条回答重试有没有失控。retry_factor稳定在 1.0 到 1.3 之间是健康的超过 2.0 说明失败率偏高要先修契约再谈重试。第 3 条回答哪类异常最值得修。某个anomaly_type长期占据 Token 消耗前列说明那个字段的契约一直没对齐应该改上游而不是加预算。第 4 条回答是不是定时任务撞车。多个任务落在同一个小时桶里就该错峰而不是升级套餐。把这份账本和 Key 分级表并排看就能得到一张很有说服力的对照每个等级花了多少、干成了多少、失败了几次。这张表是我见过最容易推动团队改代码的东西——比任何规范都管用。7. 排障手册四类报错与对应动作接入过程中高频遇到的就四类问题我按报错原文整理第一类401 invalid api key/authentication failed。先确认 Key 有没有粘贴完整、有没有带多余空格再确认Authorization头是不是被动过自己加了Bearer又被客户端拼了一次会变成Bearer Bearer xxx最后确认这把 Key 是不是被吊销或过期了。分级的副作用是L0 能用、L1 报 401这种情况会出现说明你切配置的时候切错了环境变量先查当前生效的 Key 别名。第二类404 model not found/ 模型不存在。模型名要以站点模型列表为准不要凭记忆写。Claude Code 里是ANTHROPIC_MODELCodex 里是config.toml的modelCC Switch 里是配置项的模型字段——三个地方的名字不一样改的时候别只改一处。第三类429 rate limit exceeded。这是分级表要解决的核心问题。处理顺序是先把 L0 的并发降下来再检查是不是 L1 的重试逻辑没有指数退避最后才考虑提额度。不要一遇 429 就加钱很多 429 是自身重试风暴打出来的。前面 SQL 第 2 条就是用来验证这一点的。第四类请求超时 / 空响应。L0 直接 halt 并落日志L1 走退避重试L2 若连续超时应该触发熔断而不是继续烧。判定熔断的阈值建议写死在代码里别做成可配项防止有人为了跑完整批次把它调大。还有一条不属于报错但必须写进手册吊销 Key 之后确认智能体降级到 L0 而不是直接崩。演练一次比你写十页文档都有用。8. 收口把边界写进配置而不是写进文档回到开头那件事。外部热点真正值得抄的作业不是智能体能干多少而是当它干超了你有没有办法在配置层面看见它。我这套做法的收口是四句话Key 按爆炸半径分三级L0 只读不可重试L1 有限重试并留痕L2 预算封顶且全程审计。所有请求走同一个 Base URL配置里只出现占位符YOUR_API_KEY真值只存在于密钥管理。日志里出现等级和别名永不出现 Key 本体。用量对照每周看一次用 SQL 说话不用感觉说话。如果你打算照着做建议的动作顺序是这样第一步先用模型对话把分级方案跑通确认你要用的模型在当前档位上表现符合预期https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcta_model_chat第二步评估 Coding Plan 是否匹配你的调用节奏尤其是 L2 那部分高成本推理的预算怎么封顶https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcta_coding_plan第三步进控制台把三把 Key 建出来命名按本文的规范走标签一次打对https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcta_api_keys第四步按 Claude Code 的官方文档把settings.json配好再把 Base URL 指向https://taotoken.net/api然后用第 3 节的 curl 探活验证一遍https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcta_claude_code_doc最后补一句边界提醒本文所有脚本和 SQL 都假设你在对自己拥有授权的接口做契约自检命令由你在本地执行不要把模型 Key 用于任何未授权目标。分级的意义从来不是限制能力而是让每一次越界的尝试在日志里都留得下痕迹。