1. 从一次上千子代理的 Python 重构说起为什么计量要压在 Key 上最近 AI 工程圈在讨论一次规模相当夸张的自动化重构一个 Agent harness 驱动上千个子代理并行处理一个约百万行的 Python 代码库把清理、拆分、去重、接口收敛这类工作拆成大量原子任务分发下去。Elvis Saravia 转发了这件事并给出两点判断一是自进化技能能不能沉淀成真正的工程复利二是这种打法未必能平移到其他 harness他甚至反过来问——如果用更少的子代理是不是能更省地完成同样的活。这两个问题都很关键但作为要动手的人我更关心第三个问题这么多子代理跑完token 账单到底怎么算清楚。先说结论子代理数量越多计量越不该分散在业务代码里而应该收敛到统一的出口上。原因很朴素——每个子代理最终都要发一次模型请求只要所有这些请求走同一个 Base URL、带同一个 Key计量点就是天然唯一的。这也是我把 TaoToken 放在这套流程最前面的原因先到 TaoToken 官网 拿一个 Key再把所有子代理客户端的 Base URL 统一设为https://taotoken.net/api后面无论是 10 个子代理还是 1000 个子代理账单都从同一个入口出。本文不复述那条行业新闻而是把它拆成一份可跟做的工程流程怎么拿到 Key、怎么把 Hermes Agent 这类 harness 的客户端接上去、怎么把每次子代理调用的usage字段落成本地 JSONL、怎么用一段脚本聚合出「按子代理 / 按文件 / 按任务」三层的 token 账单以及并发跑起来之后最常见的几类报错怎么排。全程你只需要在本地执行命令不需要把任何 Agent 指到线上业务库。2. 拿 Key 与首次握手确认https://taotoken.net/api真的通第一步不是在 harness 里改配置而是先用最笨的 curl 把链路打通。顺序上我建议访问 TaoToken 官网进控制台创建 API Key模型 ID 从控制台的模型列表里挑不要凭记忆瞎填。Key 到手之后先在 shell 里把两个变量立起来注意不要写进任何会被提交的脚本# 不建议写进 .bashrc子代理批量拉起时会继承到子进程环境 export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后打一次最小的请求重点是看响应体里有没有usage字段——它是后面所有计量工作的原子数据curl -sS ${TAOTOKEN_BASE_URL}/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { model: REPLACE_WITH_MODEL_ID, messages: [{role: user, content: reply with the single word: pong}], max_tokens: 16 } | jq {model, usage, finish_reason: .choices[0].finish_reason}如果客户端要求 OpenAI 兼容路径注意 Base URL 和端点路径的拼接关系Base URL 是用https://taotoken.net/api具体端点按客户端文档要求补/v1/...。这一步确认无误之后再往 harness 里塞配置否则你会在一个上千并发的场景里同时面对「Key 不对」「路径不对」「模型名不对」三类问题排查成本会翻好几倍。还有一个容易被忽略的点先记录你这次请求返回的usage结构长什么样。不同供应商对缓存命中、推理 token 的字段命名并不一致有的放在prompt_tokens_details.cached_tokens有的直接给cached_tokens有的用input_tokens/output_tokens。你的聚合脚本要按实际返回的字段来写而不是按你记忆里的字段来写。3. 把 Hermes Agent 这类 harness 接到 TaoTokenClaude Code / Codex / CC Switch 三件套真正的子代理重构任务通常不会手写 curl而是跑在 Claude Code、Codex 这类命令行 Agent 上由 harness 负责把任务拆给子代理。这三种接入方式的环境变量和配置文件格式完全不同混用会直接导致请求打到错误的地方。3.1 Claude Code用settings.json承载ANTHROPIC_*Claude Code 读的是settings.json推荐放在项目级或用户级配置里避免依赖 shell 里的临时 export{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: REPLACE_WITH_MODEL_ID, ANTHROPIC_SMALL_FAST_MODEL: REPLACE_WITH_SMALL_MODEL_ID } }两个实践建议。第一ANTHROPIC_SMALL_FAST_MODEL一定要显式指定因为子代理跑重构时会有大量「读文件、判类型、生成摘要」的轻量调用如果不指定这些调用可能落到主力模型上账单会莫名其妙地膨胀。第二settings.json属于敏感文件别提交到仓库本地权限收到 600。如果你同时跑多个 harness用 TaoToken 官网 控制台里的 Key 做区分会更省事重构任务用一个专用 Key日常问答用另一个这样后面看账单时能直接按 Key 分账不用再靠日志猜。3.2 Codex用config.toml不要套ANTHROPIC_*Codex 走的是完全不同的配置体系。它不认ANTHROPIC_*系列变量你把 Claude Code 的环境变量复制过去只会得到连接失败。正确姿势是写~/.codex/config.toml用 provider 段声明一个自定义供应商# ~/.codex/config.toml model REPLACE_WITH_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY # 具体 wire 协议按客户端文档选择如 responses / chat wire_api responses配合在 shell 里导出TAOTOKEN_API_KEYCodex 启动时会把 Key 注入到 provider 配置声明的那个环境变量里。切换模型时只改model一行不要去动base_url——Base URL 一旦被打散到多处你就再也无法用一个出口统一计量了。3.3 CC Switch 三件套Base URL、API Key、模型名如果你用 CC Switch 这类供应商切换工具管理多套配置本质上要填的就三样东西我把它叫「三件套」字段值说明Base URLhttps://taotoken.net/api所有供应商配置里的这一项必须一致API KeyYOUR_API_KEY重构任务建议单独建一个 Key默认模型从控制台模型列表选取主力模型与轻量模型分开配三件套里最容易出错的是第一项很多人会在切换工具里给不同模型配不同 Base URL结果请求被分到两三个不同的出口上。一旦出口分散你在第 4 节做的本地计量就只能覆盖其中一部分账单永远对不上。所以从接入的第一天起就把「Base URL 全局唯一」当成一条硬性规则。4. 子代理并发下的计量从usage字段到分代理账单这一节是本文的核心。目标很明确任务跑完之后你能回答三个问题——哪个子代理最费 token、哪类文件最费 token、整次重构一共花了多少。4.1 计量口径设计三层聚合不要一上来就统计总量总量没有优化价值。建议按三层设计第一层是请求级每次模型调用记一条记录字段包括时间戳、子代理 ID、模型名、输入 token、输出 token、缓存命中 token。第二层是子代理级把同一个子代理 ID 的所有请求加总用来看哪个角色最贵。第三层是任务级按你给子代理分配的文件路径或模块前缀聚合用来看哪块代码最难啃。这里有一个关键设计子代理 ID 必须由 harness 侧传入而不是从返回体里猜。多数 API 响应里并不包含「这是哪个子代理发的请求」这个信息只有你自己的调度代码知道。所以每条记录都要带上它。4.2 采集把每次调用追加成 JSONL如果你的 harness 支持自定义 HTTP 层最简单的做法是在中间加一层薄包装把响应里的usage落盘。用 curl 演示就是这样#!/usr/bin/env bash # meter_call.sh —— 单次调用并落盘一条计量记录 set -euo pipefail SUBAGENT_ID${1:?usage: meter_call.sh subagent_id payload.json} PAYLOAD${2:?usage: meter_call.sh subagent_id payload.json} LOGsubagent_calls.jsonl resp$(curl -sS ${TAOTOKEN_BASE_URL}/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d ${PAYLOAD}) echo ${resp} | jq -c \ --arg sid ${SUBAGENT_ID} \ --arg ts $(date -u %Y-%m-%dT%H:%M:%SZ) \ {ts: $ts, subagent_id: $sid, model: .model, usage: .usage} \ ${LOG}注意这里有个坑如果响应体不是合法 JSON比如被网关拦截返回了 HTMLjq会报错而set -e会让脚本直接退出导致整批子代理中断。生产里更稳的写法是先判断响应是否可解析解析失败时把原始响应单独写到一个errors.jsonl而不是让采集脚本崩掉if echo ${resp} | jq -e . /dev/null 21; then echo ${resp} | jq -c --arg sid ${SUBAGENT_ID} \ {ts: now | todate, subagent_id: $sid, model: .model, usage: .usage} ${LOG} else echo ${resp} | jq -Rs --arg sid ${SUBAGENT_ID} \ {subagent_id: $sid, raw: .} errors.jsonl fi4.3 聚合脚本把 JSONL 变成分代理账单拿到subagent_calls.jsonl之后下面这段脚本就能产出按子代理聚合的账单。单价留成常量你自己从控制台页面抄进来不要在脚本里硬编码来源不明的价格#!/usr/bin/env python3 meter_subagents.py —— 从 subagent_calls.jsonl 聚合成分代理 token 账单 import json import sys from collections import defaultdict from pathlib import Path # 单价请以控制台实际计费口径为准单位每 100 万 token PRICE_IN 0.0 PRICE_OUT 0.0 def iter_records(path: Path): with path.open(r, encodingutf-8) as fh: for line in fh: line line.strip() if not line: continue try: yield json.loads(line) except json.JSONDecodeError: continue def pick_usage(usage: dict) - tuple[int, int, int]: 兼容不同字段命名返回 (输入, 输出, 缓存命中) u usage or {} tin u.get(prompt_tokens, u.get(input_tokens, 0)) or 0 tout u.get(completion_tokens, u.get(output_tokens, 0)) or 0 details u.get(prompt_tokens_details) or {} cached details.get(cached_tokens, u.get(cache_read_input_tokens, 0)) or 0 return int(tin), int(tout), int(cached) def main(log_path: str) - None: agg defaultdict(lambda: {calls: 0, tin: 0, tout: 0, cached: 0}) for rec in iter_records(Path(log_path)): sid rec.get(subagent_id) or unknown tin, tout, cached pick_usage(rec.get(usage)) row agg[sid] row[calls] 1 row[tin] tin row[tout] tout row[cached] cached total_in sum(r[tin] for r in agg.values()) total_out sum(r[tout] for r in agg.values()) total_cached sum(r[cached] for r in agg.values()) total_calls sum(r[calls] for r in agg.values()) cost total_in / 1_000_000 * PRICE_IN total_out / 1_000_000 * PRICE_OUT print(f{subagent:28}{calls:8}{in:12}{out:12}{cached:12}) for sid, r in sorted(agg.items(), keylambda kv: -(kv[1][tin] kv[1][tout])): print(f{sid:28}{r[calls]:8}{r[tin]:12}{r[tout]:12}{r[cached]:12}) print(- * 72) print(f{TOTAL:28}{total_calls:8}{total_in:12}{total_out:12}{total_cached:12}) ratio total_cached / total_in if total_in else 0.0 print(fcache_hit_ratio{ratio:.2%} est_cost{cost:.4f}) if __name__ __main__: main(sys.argv[1] if len(sys.argv) 1 else subagent_calls.jsonl)跑起来就是一行命令python3 meter_subagents.py subagent_calls.jsonl输出会是一张按 token 消耗降序排列的表。这张表直接回答了我们最开始的问题上千个子代理并不是均匀烧钱的通常前几个「擅长读大文件」的子代理就会吃掉相当比例的成本。4.4 按文件维度再切一刀子代理级账单告诉你「谁在花钱」文件级账单告诉你「花在哪」。如果你的 harness 在 payload 里带了目标文件路径可以在采集阶段把它一并记下来jq -c --arg sid ${SUBAGENT_ID} --arg file ${TARGET_FILE} \ {ts: now | todate, subagent_id: $sid, target_file: $file, model: .model, usage: .usage} subagent_calls.jsonl然后在聚合脚本里把聚合键从subagent_id换成target_file就能看出哪些模块的输入 token 明显偏高。偏高的原因通常有三类文件本身太长、子代理反复重读同一段代码、任务边界切得太粗。这三类问题的解法完全不同前者要拆文件中者要加缓存后者要改调度策略——所以这一刀必须切。5. 一次重构任务的 token 账单模板把上面的采集和聚合跑通之后你得到的产物应该长这样。下面这份模板可以直接抄成 CSV作为每次重构任务的交付物之一subagent_role,requests,input_tokens,output_tokens,cached_tokens,notes scan-inventory,1,0,0,0,只做本地扫描不调模型 split-module,42,0,0,0,按依赖图切分子任务 refactor-core,188,0,0,0,核心逻辑重写 refactor-tests,96,0,0,0,同步更新测试 dedup-imports,57,0,0,0,轻量任务走小模型 verify-and-fix,73,0,0,0,回归失败修复 summary-report,1,0,0,0,汇总产出这份模板有两个刻意的设计。第一scan-inventory和split-module这类真正「不花钱」的阶段也保留在表里请求数为 0 时它提醒你重构任务的成本大头往往不在扫描而在反复的验证与修复循环。第二notes列必须写因为一个季度之后你回看这张表时唯一能让你想起当时为什么这么切分的就是这一列。成本估算的公式很简单但有一个前提必须说清楚任务总成本 ≈ (输入 token / 1e6) × 输入单价 (输出 token / 1e6) × 输出单价缓存命中的部分是否单独计价、按什么折扣计价以控制台展示的计费口径为准不要按经验值反推。另外输出 token 的波动通常比输入 token 大得多——同一类重构任务模型多说几句解释输出量就可能翻倍。所以如果你的目标是控制成本优先盯输出侧。6. 排障清单并发跑起来之后最常撞到的四件事上千个子代理并发时问题不是「会不会出错」而是「同时出几种错」。下面四类是实测高频的。第一类429 限流。症状是部分子代理请求被拒采集日志里出现空usage。处理原则是给调度层加指数退避而不是无限重试。重试次数建议封顶在小个位数因为一次失败的重试本身就是一条新的 token 消耗记录无限重试会把排障变成烧钱。第二类超时与半截响应。大文件重构任务里输出被截断是很常见的。判断方法看finish_reason如果是长度截断要改的是任务切分粒度而不是超时时间。把超时从 60 秒调到 300 秒通常只能让你更晚地发现输出还是被截断。第三类上下文漂移。同一个子代理连续处理多个文件时前面文件的结论会污染后面的判断。表现是「明明已经改过的模式它在下一个文件里又改回去了」。解法是让子代理尽量无状态——一个子代理只负责一个明确边界内的任务需要跨文件的知识用显式输入传进去而不是指望它记得。第四类计量本身出错。最常见的两种一是采集脚本因为响应不是合法 JSON 而整批中断二是不同客户端的usage字段命名不一致导致你只统计到了一半流量。第一种用第 4.2 节的容错写法解决第二种的排查方法是把聚合脚本对每个子代理的请求数和 harness 侧的任务派发数做一次对账两者不一致就说明有流量没被采集到。7. 复现清单与下一步如果你打算把这套流程搬到自己项目里按这个顺序走一遍最省时间先做一次单请求握手确认返回体里有usage并且结构和你预期的字段对得上。把 Claude Code 或 Codex 的配置按第 3 节改好Base URL 全局只留一个值。给重构任务单独建一个 Key让账单天然按 Key 分账。把采集逻辑加到 HTTP 层先跑 10 个任务验证 JSONL 格式正确再放大到全量。用聚合脚本产出三层账单把 CSV 和任务产出一起归档。需要动手的时候这几个入口按顺序用就够了先到 模型对话 手动发一次请求核对响应里的usage字段结构如果是要长期跑子代理 harness看 Coding Plan 更适合这种高频、长周期的调用模式准备正式开跑前去 API Keys 把重构任务的专用 Key 建出来避免和日常 Key 混用Claude Code 的具体接法参考 Claude Code 文档里面有settings.json的完整字段说明官网入口在这里TaoToken。最后回到那位点评者提出的问题用更少的子代理能不能更省地完成。这件事没法靠直觉回答只能靠计量数据回答。当你手里有了分代理、分文件、分任务三层账单「把 20 个子代理砍到 8 个」这种调整才有可比较的基线——否则你只是在换一种方式猜。