Autoresearch成本实战：1293个实验烧掉779M tokens的经验与排查指南

Autoresearch 这类自动研究任务，最让人兴奋的是“一句话需求变成一批实验”，最让人头疼的是 token 像水一样烧。最近我在 GPUMode 下跑完了第三轮自动研究批次，累计 1293 个实验，消耗 779M tokens。先给结论：它适合做广度探索，不适合当标准答案生成器。真正进入最终报告的有效实验并没有想象中多，大量 token 消耗在中间检索、上下文累积和失败重试上。

下面按实际落地顺序拆一遍。如果你也在跑多智能体自动研究，或者正准备尝试，可以直接照着这个思路做成本预估、批次规划、参数控制和问题排查。

1. 一句话需求如何变成 1293 个实验：Autoresearch 的任务切分逻辑

先说明一个很容易误解的点：Autoresearch 不是再开一个对话框和模型长聊，而是一条完整的任务流水线。输入研究目标后，系统通常会让规划智能体拆出子任务，让检索智能体去找资料和数据集，让代码智能体去写实验脚本，让评估智能体去判断结果是否有效，最后再由汇总模块整理成报告。每一步都要和模型反复交互，每一步都会消耗 token。

这套流程适合谁？适合做 AI 应用开发、做模型评测、做数据实验，以及想用多智能体自动跑实验但不知道成本怎么控制的人。不适合只想给一个 Prompt 就生成一份标准报告的场景，那种需求用普通对话模型更直接，也更省。

标题里的 Another Typical Autoresearch Post，我现在觉得 typical 不是自嘲，而是这类自动研究任务已经越来越常见。1293 个实验说明任务被切得很细；779M tokens 说明切得细并不等于算得准。实验数量看起来很多，但真正能支撑结论的，可能只是其中一小部分。

1.1 Autoresearch 不是单个模型对话，而是一条多智能体流水线

我一般会把自动研究流程拆成四类角色：

• 规划器：把研究目标改写成具体步骤和假设。
• 检索器：收集相关资料、数据集和参考实现。
• 执行器：写代码、跑实验、记录输出。
• 评估器：判断实验结果是否支持假设，决定是否继续迭代。

有的流程还会加一个调度器，负责管理任务队列、并发数量和失败重试。只要角色一多，一个问题就变得非常明显：每往下一个环节传递上下文，前面所有历史都会被重复携带。比如执行器在写代码时，不仅要看到规划器给的目标，也可能要看到检索器找到的资料；等到评估器介入时，它又要读取执行器产生的完整日志。上下文越带越长，token 消耗自然成倍上涨。

这也是为什么“什么任务消耗的 token 大”这个问题没有简单答案。看起来最长的任务不一定最费 token，真正费 token 的是那些上下文重复次数多的任务。一次普通对话大概只需要携带当前聊天记录；一次自动研究任务却可能需要把研究目标、检索结果、代码、报错信息、修复方案、实验输出全部重新读一遍。

GPUMode 第三轮里，我特别观察过这种累积效应。同一个实验如果连续失败三次，第三次请求的输入 token 可能比第一次多一大截，因为前两次失败时的日志和修复尝试都被带上了。如果这个实验只是随机种子不同，那这部分 token 基本等于浪费。

1.2 为什么一次研究会被拆出这么多实验

1293 个实验听上去很多，但拆开看其实很常见。主要来源有这么几个。

第一是假设拆解。一个研究目标往往不是单一问题。比如“比较两个模型在小样本分类任务上的表现”，这个目标本身就包含模型 A、模型 B、不同数据量、不同评估指标等多个维度。规划器把这些维度展开后，很容易得到几十甚至上百个组合。

第二是参数变体。同一个实验换一个随机种子、换一个学习率、换一段 Prompt，就被记录成一个新实验。参数变体是必要的，但也是最容易膨胀的地方。如果每个参数组合都要跑全量数据，实验数量很快会过千。

第三是数据切片。把数据按数量、比例、类别切分后，每一种切法都对应一个实验。数据量和批次不同，实验之间的结果不一定可比，所以系统可能需要额外跑一组基准确认稳定性。

第四是失败重试和回归验证。代码报错会导致重跑，结果不合理会导致再次验证。这些动作在日志里会成为多条实验记录，但本质上可能只是在重复同一件事。

更关键的一点是，实验数量与 token 消耗并不是线性关系。同一个实验跑三次，因为每次上下文里都带上了前一次的计划、代码、报错信息和修复方案，单次消耗往往会递增，而不是保持同一个数。所以不要看到实验数量没有涨多少，就觉得 token 消耗也应该稳定。

2. 779M tokens 到底烧在哪：成本分布比总数更重要

很多人看到 779M tokens 会下意识问一句：怎么这么高？但只看总数没有意义，更值得关心的是这些 token 到底被谁吃掉了。同样一组实验，如果消耗集中在检索环节，和消耗集中在评估环节，优化方式完全不同。

从我这轮复盘的观察来看，Autoresearch 的成本大头通常不是最终生成报告那一段，而是中间环节的反复读取和重试。你在最终报告里看到的可能只有几千字，但为了得到这几千字，系统可能已经把几十份资料、几十段代码、几十个报错日志都读了一遍。

2.1 四个主要消耗环节：规划、检索、代码执行、评估汇总

下面这张表是我在 GPUMode 第三轮里用来对账的框架，按环节拆分后，很多问题会清楚很多。

这里最容易被忽略的是代码执行环节。很多人以为 AI 编程只是让模型写一段代码，输出量不大。但自动研究里的代码执行不是一次写完就结束，而是写完要跑，跑完要看结果，结果不对要改，改完要重跑。每一次循环，输入里都会带上之前的代码和错误信息，输出量看起来不大，输入量却会越来越高。

检索环节也容易失控。检索器找到一个网页或一份文档后，如果直接把全文塞给模型，一个资料可能就消耗上万 token。如果检索器没有按章节截断，没有只取关键段落，那么检索几个资料后，后续任务还没开始，上下文就已经很臃肿了。

2.2 输入 token、输出 token 与 tpm：怎样判断烧钱速度

token 的计量方式需要先搞清楚。大多数平台会把输入 token 和输出 token 分开看，最终账单是两者之和。tpm 也就是 tokens per minute，按分钟统计输入 token 加输出 token 的总和。tpm 不只决定费用速度，还会影响接口限流。如果一分钟内请求太密集，模型服务端可能直接拒绝新请求，任务就会开始重试，重试又会继续消耗 token。

有一个常见误区是只看生成结果长度。有朋友看到 58k tokens 不觉得多，其实 58k 已经相当于中英文混合的几万字文本，具体字数取决于 tokenizer。但在多智能体流程里，一次工具调用返回十几页资料，加上历史上下文，58k 可能只够两三轮动作，还没正式开始跑实验就已经用完了。

GPUMode 第三轮里，我特意盯过 tpm 曲线。峰值不是出现在生成报告时，而是出现在多智能体并行检索结束、执行代码开始前。因为这个时候，每个实验的上下文里都塞进了规划结果和检索资料，输入 token 被撑到很大。如果此时并发还高，tpm 很容易突破限流阈值，任务开始排队或重试。

所以要判断一个任务烧不烧钱，不能只看最终报告字数，也不能只看实验数量。要看单次请求的输入 token 是否持续上涨，以及每分钟请求总量是否稳定。

2.3 送的 token 额度为什么扛不住自动研究

很多平台注册后会送一些体验 token，我自己也领过几次。做普通对话或者写一段测试代码，送的额度确实够用。但放到 Autoresearch 这种任务里，情况就不一样了。

自动研究的消耗模型是“多智能体多次往返”。一个完整流程可能包括几十次模型调用，而不是一次。送的 token 也许能支撑一两个实验，但很难支撑完一轮完整的多智能体闭环。不是说免费额度没用，而是应该先用它做小样本验证，把单次实验的 token 成本测出来，再决定要不要继续投入。

更需要注意的是一些平台送的 token 可能有有效期、速率限制或模型限制。直接拿大任务去跑，很可能跑到一半被限流，触发重试后 token 消耗反而更大。我的建议是：免费额度只用来做链路验证，不做全量实验。

3. GPUMode 第三轮复跑：我的批次流程和参数控制

第三轮我不再像前面那样直接把任务扔进去就跑，而是把流程拆成了四个阶段：目标压缩、单任务验证、小批次试跑、全量批次。这样做的原因很简单：自动研究最大的风险不是跑不出来，而是跑到一半才发现成本失控或输出完全不可用。

很多项目第一次跑都能跑通一两个实验，于是觉得全量也没问题。这是最容易踩坑的地方。单任务能跑通只说明链路完整，不代表大批量稳定。批量任务会遇到更多并发、限流、日志累积和输出冲突问题。

3.1 先把研究目标压缩成可验收的假设列表

这一轮跑之前，我做的第一件事是把研究目标改写成假设列表。不要只写“对比模型效果”，而是写“模型 A 在数据量 500 条时准确率是否高于模型 B”“加入某种提示词后能否减少无效输出”。每个假设对应一组实验，实验数量可预期，token 预算也好算。

别小看这一步。没有可验收的假设，规划器会把同一个问题反复拆成不同写法，等于用更多 token 制造重复工作。我见过一个没有压缩目标的任务，规划器连续生成几版计划，实验数量没有增加，但规划环节已经消耗了大量 token。

假设列表还有一个作用：它让后续的实验命名和结果判断更清晰。比如假设编号 H1，实验可以叫 H1_data500_seed1。输出结果一出来，直接对应到假设上的哪一个维度。不这样做，最后面对上千个实验结果时，根本分不清哪个实验回答的是哪个问题。

3.2 三步走：单任务验证、小批次试跑、全量批次

我不会直接把 1293 个实验全部丢进队列。流程分三步。

第一步，单任务验证。选一个最简单、最接近现有经验的假设，跑通输入、输出、日志整条链路。这一步要确认的是：任务能不能启动、输出目录能不能写、日志能不能正常记录、最后结果文件长什么样。

第二步，小批次试跑。选 10 到 30 个实验，观察单任务平均 token、失败率、运行时间、资源占用。这一步最关键。如果平均每个实验消耗 30 万 token，那么一千个实验就是几亿 token。小批次数据会让你提前发现预算问题。

第三步，全量批次。根据小批次数据估算总成本，再决定全量跑还是继续缩减。如果估算结果超出预期，不要硬跑。先把假设列表压窄，把数据量调小，把重试次数降下来，然后再试。

这里有个判断标准可以记住：小批次试跑阶段，如果失败率高于 30%，或者单任务平均 token 消耗比预估值高出一倍以上，就不要开全量。全量只会把小问题放大，不会自动修正。

3.3 控制 token 的五个关键参数

GPUMode 第三轮里，我主要控制五个参数：上下文窗口上限、输出 token 上限、并发数、重试次数、中间结果保存策略。下面是一个示例配置，具体数值要按你的实际任务调整。

{ "research_goal": "比较两个模型在小样本分类任务上的差异", "context_window_limit": 64000, "max_output_tokens": 2048, "max_parallel_experiments": 1, "max_retries": 2, "save_intermediate_results": true, "log_level": "INFO" }

为什么先小并发？因为很多耗时不是模型算不动，而是并发任务同时读取上下文，显存、内存占用和接口限流会叠加。开 8 个并发不一定比 2 个并发快 4 倍，反而容易触发超时重试。每次重试都在重复消耗 token，最终成本可能翻倍。

我见过有人把 max_parallel_experiments 拉到很高，GPU 利用率确实上去了，但输出文件开始乱写，日志顺序错乱，失败任务反复重启。最后查下来，真正能用的实验结果反而不如低并发时多。

3.4 中途检查日志和资源占用

批量任务跑起来之后，不要放着不管。至少每隔一段时间看一眼日志和输出目录。

tail -f logs/autoresearch_round3.log

检查内容主要有四个：

• 当前在跑哪个实验，是否和预期顺序一致。
• 上一次工具调用返回是否为空，有没有连续重试。
• 输出目录里有没有新增结果文件，文件命名是否冲突。
• 日志里 token 消耗是否出现异常上涨。

资源占用方面，主要看显存和内存。GPUMode 下如果 GPU 利用率长期很低，多半是卡在检索或等待接口响应，不是模型推理慢。如果内存持续上涨，可能是某个评估器把大量日志一次性读进了内存。

判断标准可以这样设：连续 20 分钟没有新的实验输出，或者重试次数超过设定值，就应该停掉检查。不要等到所有任务跑完再看结果，那时发现问题，前面烧掉的 token 已经收不回来了。

4. 1293 个实验的结果怎么判断：有效实验、重复实验和无效消耗

实验跑完只是第一步，真正难的是从一千多个实验里筛出有效结论。如果只看“有没有输出文件”，很多失败实验和重复实验会被误当成有效结果。第三轮复盘时，我给自己定了三个筛选指标。

如果你也是第一次跑大批量实验，建议先不要追求自动化，手动抽 50 个实验看看输出质量。知道什么样算好，什么样算坏，再交给程序去批量筛。

4.1 判断实验有效性的三个指标

完成率解决的是“能不能跑完”的问题。如果大量实验没有输出文件，或者日志停留在中间步骤，说明链路还不稳定。这时不要急着分析结果，先去修流程。

成功率解决的是“结果能不能用”的问题。一个实验可能成功结束，但输出是一个空列表，或者代码执行报错但没有触发重试。这类实验看起来完成了，实际没有意义。

结果变化率是我最看重的指标。自动研究如果跑了一大堆实验，结果都差不多，说明当前实验设计缺少区分度。要么是参数范围没有拉开，要么是评估指标不敏感，要么是任务本身不适合这个模型。结果变化率太低时，继续增加实验数量没有意义。

4.2 重复实验从哪来，怎么识别

重复实验是 token 消耗的隐形杀手。常见来源有三种。

第一种，输入近似。两个实验只是随机种子不同，或者数据切片方式稍微不同，结果很可能没有实质差异。这种实验不是完全没用，但不需要跑几十次。

第二种，失败重试。每次重试都会重新提交一次完整上下文，失败日志本身可以说明问题，但如果系统把每次重试都记成一个独立实验，统计时就要把它们合到一起看。否则实验数量看着很多，有效信息很少。

第三种，全量回归。每改一个参数，都把之前所有结果重新评估一遍。评估器的消耗经常超过实验本身。特别是当评估器把全部日志读进上下文时，一次回归可能比真正跑实验还贵。

识别重复实验最简单的方法是看输入列表。如果同一模型、同一数据集、同一提示词，只是某个数值不同，那么它们大概率是同一族实验。统计时可以按“实验族”聚合，而不是按单个实验计数。聚合之后再看哪些族贡献了主要结果，哪些族基本可以忽略。

4.3 探索型任务和稳定型任务要分开验收

自动研究里有两类实验，验收标准完全不同。

探索型任务，比如看不同提示词对输出风格有什么影响、不同数据规模对模型能力有没有非线性变化。这种任务适合多跑，结论是“发现了什么差异”。它的价值在于覆盖足够多的组合，结果变化率越高越说明有发现。

稳定型任务，比如看模型在固定测试集上的准确率、固定输入下是否复现同样的代码输出。这种任务重复次数越多越好，结论是“结果是否可靠”。它更看重稳定性，而不是多样性。

把两类实验混在一起统计，会带来两个问题：一是探索型实验里大量的不稳定输出会被当成错误，二是稳定型实验里正常的小波动会被夸大。第三轮跑完以后，我把两种任务分开标记，再做综合报告，才终于能比较清楚地看到每个假设的结论。

4.4 低配置环境的取舍

如果 GPU 显存或内存不足，不建议直接跑全量批次。低配置能跑通一个实验，不代表能稳定跑完一千个实验。我在本地和 GPUMode 上都跑过，感受很直接：资源不足时，最先出问题的不是模型推理，而是并发任务的内存占用和日志读写。

低配置环境可以这样降成本：

• 用小规模数据代替全量数据，先看趋势，再决定是否加量。
• 降低 max_output_tokens，让单次请求输出更短。
• 关掉非必要评估器，只保留一个核心结果判定模块。
• 把中间结果及时写盘，不长期保留在内存里。

不要指望低配置跑大批量还能和完整环境一样稳定。先跑小批次，用数据说话。

5. token 超支、任务卡住、输出不稳定：我的排查链路

自动研究跑久了，一定会遇到 token 超支、任务卡住、输出不稳定这三类问题。很多人的第一反应是调并发、调重试、调模型参数，但我更建议先定位再优化。大多数问题的根源不在参数，而在输入准备和任务设计。

下面这条排查链路是我的固定顺序。不管问题表现是什么，都按这个顺序过一遍，通常能找到原因。

5.1 先看 token 账单，再改业务参数

遇到 token 超支，先拉账单，别急着把并发调低。账单会告诉你大头在规划、检索、代码执行还是评估汇总。如果大头在检索，查是不是重复抓取；如果大头在评估，查是不是把所有日志都塞进了最终总结；如果大头在重试，查是不是接口限流或超时导致同一批任务反复执行。

改参数之前先定位，很关键。有人发现 token 消耗高，直接把 max_tokens 调低。结果输出被截断，代码执行失败，重试次数增加，总消耗反而更高。这就是典型的没看账单就改参数。

要看几个维度：

• 输入 token 和输出 token 的占比。
• 单任务平均消耗有没有随时间上升。
• 失败重试带来的额外消耗占比。
• 并发高峰期的 tpm 是否接近限流阈值。

这些数据不一定都在账单里，有些需要从日志重新算。如果日志里没有记录单次请求 token 数，建议从下一轮开始补上。没有这个数据，后面很难做成本优化。

5.2 排查顺序：输入、上下文、并发、重试、输出目录

我自己固定用六步排查，顺序如下：

1. 看现象：是直接报错、卡住不动、没有输出，还是输出结果为空。
2. 看输入：文件路径、编码、格式、数据切片是否完整，有没有路径权限问题。
3. 看上下文：日志里请求 token 是否持续上涨，有没有因为超长而被截断。
4. 看并发：同时跑的任务数量、接口限流、GPU 和内存占用是否异常。
5. 看重试：同一实验是否被反复提交，失败原因是不是网络或接口返回错误。
6. 看输出目录：结果文件是否生成，命名是否冲突，目录是否可写。

这个顺序能覆盖大多数问题。很多人一上来就改 max_tokens 或者换模型，问题可能仍然存在，是因为根因没有被处理。比如输入文件编码错误导致代码报错，代码报错导致重试，重试导致 token 暴涨。这时改模型没用，直接把文件编码转换掉就够了。

5.3 三个典型坑

第三个批次里，我踩过几个很典型的坑，列出来给你参考。

第一个坑是网络超时导致的重复提交。任务系统没有做幂等控制，同一个实验因为一次接口超时被重新提交。第一次其实可能已经成功了，但客户端没收到响应，于是又跑了一遍。最终账单里出现了大量重复实验，实验数量虚高，token 消耗翻倍。

第二个坑是评估器吃满上下文。评估器负责读取实验日志并生成结论。如果某个实验日志特别长，评估器一次性把所有内容读进上下文，单次请求直接超过上下文上限。系统以为请求失败，触发重试，重试时又继续读那段日志。结果评估环节的 token 消耗甚至比实验本身还高。

第三个坑是日志缺失。没有记录每次输入摘要、输出文件路径和重试次数，失败时只能靠猜。等你发现某个实验有问题，日志里只写了“报错”，没有具体原因，那这次实验的 token 就白白烧掉了。第三轮里我把日志改成结构化格式，每一条都带上任务 ID、环节、输入 Token、输出 Token、重试次数，问题定位速度快了很多。

6. 下一轮再跑 Autoresearch，我会先做这三件事

1293 个实验跑完以后，我对 Autoresearch 的判断没有变：它能解决部分探索性问题，但必须把成本控制和结果筛选当作一等公民对待。如果再来一轮，我大概率会先做三件事，而不是直接把目标交给系统。

6.1 缩小目标，减少自由探索

下一轮我不会再让规划器自由发挥，而是先把研究目标人工切成 3 到 5 个可验证假设，每个假设只允许 1 到 2 种数据规模和参数变体。自动研究应该做的是把假设跑出结果，而不是自己发明假设。发明假设越多，token 越不可控，结果也越难收束。

判断标准是：如果每个假设需要超过 50 个实验才能回答，说明这个假设仍然太大。先把它拆到可以用 10 到 20 个实验回答，再考虑是否合并。

6.2 中间结果落盘，别让长上下文替你做记忆

多智能体最费 token 的地方，是为了让后续步骤记住前面步骤，不断把历史塞进上下文。改成中间结果落盘后，每个环节只读取自己需要的文件，不再携带全部历史。这个改动比任何模型调参都省 token。

具体做法是：规划器输出的计划保存成计划文件，检索器保存资料摘要，执行器保存代码和结果，评估器只读取结果文件。这样即使某一个环节发生上下文截断，后续也能从文件里恢复，不需要重新生成全部上下文。

如果你现在正在跑自动研究，第一步就把“保存中间结果”打开。这个开关通常不会影响输出质量，但对 token 消耗影响很大。

6.3 把人工检查点放到批次中间

我会在每 100 到 200 个实验后插入一个人工检查点，检查完成率、成功率、结果变化率和 token 消耗。如果某一项明显异常，先处理再继续。检查点会打断自动化，但能避免后面几十万 token 被无效浪费。

检查点是一种必要损耗。不设检查点，可能等全部跑完才发现某个阶段出了问题，然后整个批次推倒重来。设了检查点，最多损失 100 个实验的 token，远比全部重跑便宜。

GPUMode 第三轮跑完，我最大的感受是：自动研究不缺实验数量，缺的是从实验数量里筛出有效结论的判断力。779M tokens 不是用来证明“跑了很多实验”的，而是用来回答少数几个值得回答的问题。只要目标足够聚焦，哪怕实验数量少一半，最终结论质量反而可能更高。