最近看到一组 Autoresearch 的运行记录1,293 个实验、779M tokens、某组 GPU 推理配置在榜单里排第 3。如果你第一眼只觉得“烧了这么多 token 才第 3 名不值”那这篇文章可能会改变你的判断。这组数字真正值得拆开的不是“有没有拿第一”而是三件事700 多万 token 被花到哪里去了、大规模实验循环是怎么设计和执行的、以及当实验量级超过一千次之后工程上哪些环节会先崩。对于正在做 AI 编程、Agent、自动评测或者任意一种“让模型自己去跑实验”的开发者来说这组数字比排行榜更值得研究。本文将围绕 Autoresearch 的实践链路展开讲清楚 token 消耗的基本计算方式、最小实验循环怎么搭、如何用代码管理和复现实验结果以及在大规模跑任务时最容易踩的坑。1. 这组数据到底说明了什么从材料看这是一次典型的 Autoresearch 大规模运行记录1,293 个实验累计消耗 779M tokensGPUMode 配置在相应榜单中位列第 3。我们可以先把这几个数字放在背景里理解。实验数量一千三百多个说明这次运行不是一个单文件、单 prompt 的玩具级场景而是一个可以批量调度、批量执行的自动化研究循环。779M tokens 则是整个循环在模型调用层产生的全部计量包含输入、输出以及可能的补全结果。做一个粗略换算779,000,000 / 1,293 ≈ 602,477也就是说平均每个实验大约消耗 60 万 tokens。这个数字远高于普通 API 对话。平时我们完成一次“给一段代码并解释”的调用通常不过几千 tokens而 Autoresearch 里的一次实验可能包含模型生成代码、运行代码、读取报错、修改代码、再次验证等多轮交互每一轮都会带来输入 token 的成倍累积。60 万 tokens 一次实验不是异常恰恰说明实验循环里触发了大量真实上下文往返。GPUMode 第 3 名的含义需要谨慎解读。在没有完整榜单的前提下第 3 名可能是多轮迭代的中间结果也可能是某个分支的最优成绩。它更像是工程过程中的一个快照而不是“最终结论”。可复现的第 3 名往往比不可复现的随机第 1 名更有价值。这组数据真正的启示是如果一开始不把 token 成本和实验管理设计好那一千多个实验只是白白烧钱。下面我们先从最基础的概念入手把 token、TPM、上下文长度这些与成本强相关的概念讲清楚再进入具体的代码实现。2. 核心概念Token 到底是怎么被消耗掉的2.1 Token 是什么Token 是模型处理文本和代码的最小单位。中文场景下一个 token 不严格等于一个字可能是一个字、一个词、一个标点或者一段代码符号。不同模型有自己的分词器但总体规律是中文字符的 token 占用通常高于英文单词的 token 占用代码结构、Markdown 标记、JSON 转义都会额外增加 token。在 Autoresearch 这类场景里token 消耗主要来自三部分系统提示词和用户提示词输入模型输出内容输出多轮对话中历史消息被反复拼接到请求里输入持续增长。其中最容易被低估的是第三部分。很多 Agent 框架会把“历史对话记录”完整保留每一轮新请求都重新发送一遍之前的全部文本。实验只跑几轮还好一旦跑上百轮输入 token 会比输出 token 高出几个数量级。2.2 TPM 与速率限制热词里有“TPM (tokens per minute) 输入 token 输出 token 的总和”的表述这也是 API 服务最常用的限速指标之一。假如模型接口的 TPM 限制是 300k而一次实验要消耗 600k tokens那么即使模型处理完全理想这次实验在速率层面也需要至少两分钟才能跑完。如果同时并发 10 个实验限速冲突会非常明显容易出现 429 限流错误。所以在大型实验调度中必须关注两个数单次实验的 total_tokens接口的 TPM 限制。2.3 什么任务消耗的 token 大从大量 Agent 实践来看以下任务最容易让 token 失控任务类型消耗原因典型控制方式多轮代码生成和修复模型每轮都要读入报错、日志、文件内容截断日志只保留最近 N 行自动评测与反思循环自我反思需要把模型自己的推理记录重新拼入上下文限制反思轮数设置最大迭代次数仓库级代码索引把整个仓库内容交给模型做分析改为摘要索引按需加载文件结构化 JSON 输出大括号、转义、字段重复使用紧凑结构减少冗余字段长上下文汇总多次读取历史结果定期做摘要压缩放弃无损保留一个典型的 Autoresearch 实验里最贵的往往不是第一次生成代码而是“运行失败后的第 3 次修复”。因为每一次修复都会把前面的错误日志、当前代码、修改思路重新发给模型token 会像滚雪球一样增长。2.4 58k tokens 大约是多少有开发者问“58k tokens 是多少”这个概念可以用体感来理解在中文技术文章场景下58k tokens 大约等于 3 万字到 5 万字的文档或者一个中等规模仓库的核心代码摘要。如果是代码密集型内容可能只够装下 10 到 20 个文件。这告诉我们一个事实模型上下文窗口看似很大但放到 Autoresearch 的多轮循环里很快就会被填满。理解了 token 成本再回头去看 779M tokens 就清楚了这等于数千次对话的量级累积背后不是简单的一次问答而是一整套实验引擎在持续调用模型。3. 环境准备与前置条件如果你打算用 Autoresearch 思路搭一个最小实验环境不需要复杂的集群。推荐先在单机环境跑通再考虑并行扩展。下面是前置条件清单。一台能运行 Python 的电脑Windows、macOS、Linux 均可。Python 3.10 及以上版本实际版本请以你本机环境为准。一个可调用的 LLM API兼容 OpenAI 格式即可方便统一客户端。本机可以执行 Python 命令用于运行模型生成的代码。准备一个隔离目录避免模型生成的代码污染工作区。接下来创建项目目录和虚拟环境。mkdir autoresearch-demo cd autoresearch-demo python3 -m venv .venv source .venv/bin/activate pip install openai pyyaml这里使用 OpenAI 官方 Python 库作为 LLM API 客户端。即使你最终使用的是其他兼容服务这一步也足够统一。我强烈建议用虚拟环境。Autoresearch 会频繁生成和运行 Python 代码如果直接跑在全局环境依赖冲突和安全隐患迟早会出现。项目目录结构建议如下autoresearch-demo/ ├── task_runner.py ├── experiments.yaml ├── estimate_tokens.py └── runs/runs目录用来存放每个实验的输出和results.jsonl记录文件。这样实验数据、代码和配置分离后续排查会比较省心。4. 核心流程拆解一个可复现的 Autoresearch 实验循环一定要拆成独立步骤。不要让“模型自己决定整套流程”而是把流程固定成模板模型只负责模板中的内容生成部分。4.1 最小闭环的四个步骤第一步读取实验配置。配置里包含 API 地址、模型名、实验列表每个实验有独立 id 和 prompt。第二步调用模型生成候选代码。这一步是典型的输入 token 消耗点模型会生成一个 Python 文件。第三步在隔离目录中运行生成代码。这一步不消耗模型 token但会产生真实实验结果包括成功、失败、退出码、stdout、stderr。第四步记录 token 与实验结果。把 prompt_tokens、completion_tokens、total_tokens 和运行状态追加到results.jsonl。这个闭环的设计核心是模型只负责“生成代码”运行和记录由本机程序负责。这样既控制了随机性也让 token 消耗可以被事后分析。4.2 为什么不能省掉记录步骤很多新手做 Autoresearch 时只关心最终代码对不对不记录 token。结果就是跑完几百个实验完全不知道哪一步开始失控。记录步骤看起来简单但它决定了你能不能回答以下问题单个实验平均消耗多少 token哪些任务类型超预算失败实验和成功实验的 token 分布是否有明显差异如果账单来了怎么核对用量所以记录 token 不是可选项而是 Autoresearch 的必备环节。4.3 GPUMode 这类分组怎么处理在实验中给不同环境打标签是常见做法。GPUMode 可以理解为一个运行环境标识用来区分“这一批实验跑在哪种推理模式下”。建议在配置和结果记录里都保留这个字段这样后续做榜单对比、模式对比时可以按字段过滤。不要只看最终排名关键是记录排名对应的配置、时间和数据版本。这会让实验具备回溯能力。5. 完整示例与代码实现下面我给出一个可以直接复制跑通的最小示例。它不追求复杂只完成“配置实验 - 调用模型生成代码 - 运行代码 - 记录 token”的闭环。5.1 实验配置experiments.yaml# 文件路径autoresearch-demo/experiments.yaml api: base_url: https://api.example.com/v1 timeout: 60 # 不要在这里写真实密钥推荐用环境变量注入 model: gpt-4o-mini temperature: 0.2 experiments: - id: 001 prompt: | 请实现一个函数 fibonacci(n: int) - int。 要求n 0 返回 0并且避免递归深度崩溃。 只输出可运行的 Python 代码不要输出解释。 - id: 002 prompt: | 当前函数在 n10000 时会栈溢出请改成迭代实现。 只输出可运行的 Python 代码不要输出解释。请注意base_url需要替换成你实际使用的 API 地址模型名也需要替换成你账号可用的模型。temperature设置为 0.2 是为了减少输出随机性适合生成代码任务。5.2 主循环task_runner.py# 文件路径autoresearch-demo/task_runner.py Autoresearch 最小实验循环示例 职责 1. 读取 experiments.yaml 2. 调用 LLM 生成候选 Python 代码 3. 在隔离目录执行生成结果 4. 记录运行状态与 token 消耗 import json import os import subprocess from datetime import datetime, timezone from pathlib import Path import yaml from openai import OpenAI class ExperimentRunner: def __init__(self, config_path: str, work_dir: str): self.work_dir Path(work_dir) self.work_dir.mkdir(parentsTrue, exist_okTrue) with open(config_path, r, encodingutf-8) as f: self.cfg yaml.safe_load(f) api_key os.getenv(OPENAI_API_KEY, ) if not api_key: raise RuntimeError(请先设置 OPENAI_API_KEY 环境变量) self.client OpenAI( base_urlself.cfg[api][base_url], api_keyapi_key, timeoutself.cfg[api].get(timeout, 60), ) self.model self.cfg[model] self.results_path self.work_dir / results.jsonl def _save_result(self, record: dict): with open(self.results_path, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) def run_one(self, experiment: dict) - dict: exp_id experiment[id] exp_dir self.work_dir / fexp_{exp_id} exp_dir.mkdir(parentsTrue, exist_okTrue) prompt experiment[prompt] resp self.client.chat.completions.create( modelself.model, messages[ { role: system, content: 你是一个严谨的代码实验助手。只输出可运行的 Python 代码不要输出解释。, }, {role: user, content: prompt}, ], temperatureself.cfg.get(temperature, 0.2), ) generated resp.choices[0].message.content usage resp.usage code_file exp_dir / main.py code_file.write_text(generated, encodingutf-8) # 运行模型生成的代码限制超时时间 proc subprocess.run( [python, str(code_file)], cwdstr(exp_dir), capture_outputTrue, textTrue, timeout120, ) record { exp_id: exp_id, status: ok if proc.returncode 0 else failed, returncode: proc.returncode, stdout: proc.stdout[-2000:], stderr: proc.stderr[-2000:], prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, generated_len: len(generated), ts: datetime.now(timezone.utc).isoformat(), } self._save_result(record) return record def main(): runner ExperimentRunner(experiments.yaml, runs) total_tokens 0 for experiment in runner.cfg[experiments]: record runner.run_one(experiment) total_tokens record[total_tokens] print( fexp {record[exp_id]} - {record[status]}, ftokens{record[total_tokens]} ) print(ftotal tokens: {total_tokens}) if __name__ __main__: main()这段代码的核心设计有几点第一通过系统提示词要求模型“只输出代码”减少 Markdown 格式代码块带来的解析问题。第二每个实验在独立子目录里运行互不干扰。即使某个实验生成的文件写死了相对路径也不会覆盖其他实验。第三运行超时设置为 120 秒避免模型生成死循环代码后整个任务卡死。第四stdout和stderr只保留最后 2000 个字符避免超大输出把记录文件撑爆。这个截断同时也在模拟“进入下一轮模型调用时只喂最近日志”的工程思路。5.3 Token 统计脚本estimate_tokens.py# 文件路径autoresearch-demo/estimate_tokens.py import argparse import json from pathlib import Path parser argparse.ArgumentParser(description统计 results.jsonl 的 token 消耗) parser.add_argument(--file, defaultruns/results.jsonl) args parser.parse_args() total 0 prompt_total 0 completion_total 0 success 0 failed 0 path Path(args.file) if not path.exists(): raise SystemExit(f文件不存在: {path}) with path.open(r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue rec json.loads(line) total rec[total_tokens] prompt_total rec[prompt_tokens] completion_total rec[completion_tokens] if rec[status] ok: success 1 else: failed 1 print(f实验总数 : {success failed}) print(f成功 / 失败 : {success} / {failed}) print(f总 token : {total}) print(f平均 token/实验: {total // max(success failed, 1)}) print(f输入 token : {prompt_total}) print(f输出 token : {completion_total})这个统计脚本是我们理解“1,293 个实验779M tokens”这类数据的基础工具。只要把results.jsonl喂给它就能立刻算出平均单次实验消耗并看出输入 token 和输出 token 的占比。对大规模 Autoresearch 来说这几项数据是后续优化预算的直接依据。5.4 运行方式与参数说明先设置 API Key然后按顺序执行export OPENAI_API_KEYyour_key_here python3 task_runner.py python3 estimate_tokens.py --file runs/results.jsonlWindows 用户可以把export换成 PowerShell 里的设置方式或者直接使用 IDE 的环境变量配置。在运行之前确保experiments.yaml里的实验 prompt 确实是“只输出代码”的类型否则生成的main.py可能包含解释文字运行时会报语法错误。6. 运行结果与效果验证如果实验配置没有问题控制台会输出类似下面的内容exp 001 - ok, tokens1845 exp 002 - failed, tokens3201 total tokens: 5046这里的total tokens只代表我们这个小示例的消耗。当你把它扩展到 1,293 个实验时单次实验如果仍保持在 5000 tokens 左右总消耗只有 6M tokens 量级但如果实验循环里加入了自动修复、历史回放、日志重读单次实验很容易跳到 500k 甚至 600k tokens。这时候统计结果就会非常接近标题里的 779M tokens 体量。验证是否成功可以从三个角度判断results.jsonl是否完整记录了每个实验的 token 明细失败实验的stderr是否被截断保存方便回看崩溃原因平均 token 是否与预期吻合如果某个实验的 total_tokens 是其他实验的 100 倍说明实验循环里出现了严重的上下文膨胀。如果第一轮跑出来失败率很高不要去改模型先看stderr。大多数情况下是生成的代码头尾包含解释性文字需要在系统提示词里进一步约束输出格式。7. 常见问题与排查思路下面整理了一份 Autoresearch 实验循环中经常遇到的问题表按严重程度排序。问题现象可能原因排查方式解决方案API 返回 429 或限流错误TPM/RPM 超过接口限制查看服务商限流日志降低并发增加 sleep或拆小实验批次生成的 main.py 运行失败模型输出包含 Markdown 或解释文字打开生成的 main.py 查看首尾在 prompt 中明确“只输出代码”保留解析器兜底token 消耗远超预期每次修复都重新发送完整历史日志查看 prompt_tokens 占比截断日志只保留最近 2000 字符同一 prompt 多次结果不一致温度过高或未固定随机种子检查 temperature 配置降到 0.2 以下必要时固定 seed排行结果无法复现评测集、版本或参数不同核对各组配置字段记录完整配置使用统一评测脚本生成代码运行死循环模型输出 while True 且无退出条件查看超时日志在 subprocess 中设置 timeout必要时用容器隔离从实际经验看最容易被忽视的是日志截断问题。模型修复代码需要“读报错”但不是读全部日志而是读关键的最后几行。很多失败实验的 token 爆炸就是因为每次修复都把 5000 行日志原封不动发给模型。另外我也建议在每个实验记录里增加config字段把模型名、温度、prompt 版本都写进去。这样当 GPUMode 这类模式排名变化时你能立刻知道是哪一版配置跑出来的结果而不是靠记忆猜。8. 最佳实践与工程建议如果你准备把 Autoresearch 从单机小实验扩展到成百上千次实验下面这些经验值得提前写进工程规范。8.1 给 token 设置硬预算不要在一个实验里让模型无限迭代。建议在每次生成后累加 tokens一旦超过设定上限就停止本轮实验标记为budget_exceeded。这样账单可控也不会因为某一条脏数据拖垮整批任务。8.2 区分“生成”和“验证”的权限模型生成的代码不应该直接拿到生产环境运行。实际项目中至少要在虚拟环境、Docker 容器或独立沙箱里执行并且只授予最小权限。严禁让模型生成的代码直接执行删库、清缓存、修改全局配置等危险操作。所有涉及安全、权限、删除类的操作都必须经过人工审批。8.3 记录比排名更重要GPUMode 第 3 名这件事提醒我们一个规律大规模 AI 实验的结果会不断变化。今天第 3明天可能是第 1后天可能因为评测集不同掉到第 10。如果只记录一个数字不记录环境、版本和配置这个数字就没有任何工程价值。所以每一次实验落地时至少要保存三样东西代码、配置、结果记录。8.4 用摘要代替全量上下文对长文档、大仓库、长日志不要直接把全文塞给模型。先把内容做成摘要再在需要时按需取用。这一步虽然会损失一些细节但能极大降低 token 消耗。8.5 并发不是免费午餐并行调用可以缩短总运行时间但 TPM 限制和 API 费率是绕不开的。建议先串行跑通 10 个实验确认单次平均 token 后再计算并发度。如果单次实验 600k tokens而 TPM 只有 300k那单次实验至少要 2 分钟强行开 20 个并发只会换来一堆 429。8.6 使用环境变量管理密钥不要把自己的 API Key 写进 YAML 或代码仓库。建议通过环境变量注入并在.gitignore中排除.env文件。团队协作时密钥由平台统一管理而不是通过聊天工具传来传去。8.7 固定依赖版本Autoresearch 生成的代码依赖环境环境变化会直接影响实验结果。建议用requirements.txt、poetry或uv固定依赖版本并把 Python 版本、操作系统记录在实验配置里。8.8 失败实验也是数据不要因为一个实验失败就直接丢进垃圾桶。失败的原因、失败时的日志、失败时的 token 消耗都是优化下一轮实验的输入。很多大规模实验的改进点恰恰藏在失败分布的规律里。9. 总结与后续实践建议回到最开始那组数字1,293 个实验、779M tokens、GPUMode 第 3。拆开来看它其实是在告诉我们三件事大规模 Autoresearch 已经可以跑起来了但成本和可复现性需要专门设计token 消耗在实验循环里会快速放大必须靠统计工具和预算机制兜住排名是相对的可复现的实验记录才是工程资产。对于下一步你可以从一个小目标开始把文章里的task_runner.py改造成自己的实验调度器先跑 10 个实验统计平均 token再逐步叠加自动修复、模型切换、多个模式对比。跑完 100 个实验后你大概率会对“怎么省 token”“怎么分配实验次数”“怎么设置失败上限”有非常具体的体感。如果你已经在跑更大规模的 Agent 或 Autoresearch 任务建议先补上 token 统计和分组建模再做并行优化。数据不会骗人先让账目清楚起来再谈算法和模型效果。