NVIDIA和MIT最近联手放出来的东西让“自动研究循环”和“Token省近半”这两个关键词在我朋友圈里炸了一轮。我第一反应是又有人拿标题党骗我搭Agent?结果自己把方案的核心思路拆了一遍又在自己项目里实测了两周发现这条思路确实是现阶段把Agent成本打下来最值得参考的方向之一。这篇文章不讨论那些包装后的产品只讲清楚两个问题自动研究循环到底是怎么让Token消耗砍掉近一半的以及你在自己的代码里能不能复现出同样的效果。如果你和我一样平时要跑研究型Agent、资料汇总Agent或者做竞品分析Agent那你看到的就是当前最实用的成本优化方案之一。1. 项目概述先回答三个最常被问的问题1.1 这个项目解决的到底是什么问题我用一个真实场景开头。上个月接了个需求让Agent自动收集某行业近半年的融资事件整理成结构化报告。传统做法很简单就是一个对话循环让LLM自己决定搜什么然后把搜索结果全部塞回上下文里再让它继续思考下一步。这种方式能跑但账单一出来吓一跳一个任务消耗了130多万Token里面有接近90万是重复阅读和无效推理。NVIDIA和MIT这次放出来的自动研究循环方案核心就是改变这个“把对话历史当输入磁带”的模式。它把任务从一层层问答改成了“研究—记录—再研究—再记录”的闭环。模型每一次决策前读到的不是之前的原始结果而是一份经过压缩、去重、带引用的研究笔记。说白了就是把模型从“每次从头把书再看一遍”变成“只看自己的读书笔记和索引”。1.2 为什么说这是“炼”出来的高效Agent标题里的“炼”字我觉得不是修辞而是实打实的训练与调优过程。同一个循环如果终止条件写得不好、摘要粒度不对、笔记结构混乱Token不但省不下来还会因为多跑几轮反而更贵。我实测的第一版就比传统方案多花了20%的Token原因就是减少了上下文读取却增加了检索轮次。后面把问题定位清楚了发现省Token的关键不单单是“压缩内容”而是“控制模型重复消耗Token的行为”。当Agent决定了读取、过滤、记录、停止四个动作之后Token消耗才有机会稳定在传统方案的50%到60%。所以这篇文章接下来会详细拆这几个动作给出可以复现的设计和踩坑记录。1.3 适合谁哪些项目能吃到这波红利先说结论最适合的是研究型、汇总型、调研型的Agent任务。这类任务有几个共同特点需要多次外部检索、结果可被结构化组织、输出不需要逐字保留原始文本。反过来说如果你的Agent是客服对话、代码生成、多轮交互那这套方案更多是参考价值不要照搬。读者画像上我觉得给下面三类人帮助最大一是已经在用LLM API做Agent被Token成本困扰的工程师二是刚接触Agent开发想找一个性价比最高的工作流模板的产品或技术负责人三是被各种“Agent框架”绕晕想知道底层逻辑的爱好者。我自己属于第一类所以文章里用的都是工程视角不会把原理讲得很玄。1.4 为什么是NVIDIA和MIT两家机构关注Token效率的动机有不少朋友问我为什么这种方案不是某个Agent平台先做出来而是NVIDIA和MIT来推。我的理解是Token效率对这两家的价值都不在于“省API费用”而在于算力利用效率。Token消耗降低了单位算力可以支撑更多Agent任务这对云端集群调度和硬件利用率是实打实的收益。MIT那边关注的是自动化科研方向研究型Agent每天要读大量论文、网页、数据集Token开销比普通业务场景大好几个量级。如果一篇文章综述能省一半Token意味着同样的预算能多跑一倍的自动化实验。所以这个方案天然带着“研究场景”的基因这也解释了为什么它在调研类任务上效果最明显。2. 核心设计拆解自动研究循环凭什么能省近半Token2.1 先看看传统Agent的Token到底花在哪了与其说省Token不如说先搞清楚Token都浪费在哪里。我把自己之前的日志拉出来统计过传统研究型Agent的Token去向大概是这样的消耗项占比原因工具返回的原始内容约45%搜索引擎、网页、文档直接被塞进上下文重复阅读历史约25%每次推理都要带上之前的全部对话任务指令与工具描述约10%系统提示词和工具schema模型自身推理与输出约20%思考过程、最终报告列这个表不是做统计报告而是为了说明一个反直觉的点模型“思考”花的Token其实占比不高大头是被迫“阅读”的内容。很多人以为Agent贵是因为模型推理贵实际是喂进去的冗余信息贵。自动研究循环的核心就是在“阅读”这个环节动手术。2.2 自动研究循环的四个关键设计第一个设计是“先规划再检索最后阅读”。在接到任务后Agent先输出一份研究计划把大问题拆成子问题比如“行业背景”“主要公司”“融资数据”“政策风险”。这一步看着多花了几百Token但换来的好处是后续每轮检索都有明确目标不会在无关页面上浪费查询和阅读。第二个设计是“检索结果先摘要再进上下文”。这是省Token最狠的一刀。搜索引擎返回的10条链接和网页摘要可能有5000到8000 Token传统Agent会原样塞进去自动研究循环里这个结果先交给一个轻量模型用固定模板压缩成300到500 Token的结构化事实只有这些事实会进入主模型的上下文。十几倍的压缩比Token就是这么省下来的。第三个设计是“研究笔记替代对话历史”。整个Agent不把之前的搜索和思考当作连续对话而是维护一份“研究笔记”包含已确认的关键信息、待核实问题、引用来源。后面的每一轮推理主模型只读这份笔记和最新一轮的摘要结果。上下文长度从“线性增长”变成了“近似恒定”。第四个设计是“有界迭代与显式终止”。传统Agent经常会陷入“再搜一次看看”的循环。自动研究循环设置了几个硬性停止信号计划中的子问题全部处理完、连续两轮没有新增事实、全局Token预算触顶。其中一个生效循环就结束进入报告生成阶段。这个设计对成本的贡献经常被低估实际上它防住的是最不可控的“长尾消耗”。2.3 为什么能省这么多一笔账算明白拿一个典型任务来估算。假设某个研究任务需要进行5轮检索每轮检索结果约4000 Token。传统做法里第一轮消耗任务描述500 搜索查询100 原始结果4000 模型回复800约5400 Token。第二轮开始要把第一轮对话追加进去约5400550010900第三轮再追加约55001090016400。5轮下来累计会在5万Token左右还没算最终报告。自动研究循环的做法完全不同。每一轮只管三样东西已有的笔记摘要、当前轨迹的结果摘要、主模型的新决策。每轮大约查询100 轻量摘要400 主模型阅读笔记与摘要1000 笔记更新300合计1800 Token左右。5轮下来约9000 Token加上初始计划和最终报告也就是2到3万Token的量级。两相对比节省一半是很保守的说法。需要注意这种粗算是为了直观实际的API计费还有输入输出单价差异但量级关系是真实的。如果你自己跑一版核心观察指标应该是“主模型输入Token”是不是从线性增长变成了接近常量。经常有朋友问我“省Token是不是要牺牲效果”我的观点是它不是牺牲效果而是把模型从“重读垃圾信息”中解放出来效果反而更稳。2.4 和其他省钱思路的区别缓存、蒸馏与换小模型讨论自动研究循环时总有人会提“直接用prompt caching不就行了”“蒸馏一个小模型不就行了”“换成便宜的小模型不就行了”。这些方案确实都能省Token或省单价但和自动研究循环解决的不是同一个问题。Prompt caching解决的是重复前缀的计费问题如果你的Agent每轮对话都共享同一个系统提示词缓存确实有效。但研究型Agent的大头是搜索引擎返回的动态内容每一轮都不一样缓存基本帮不上忙。模型蒸馏解决的是单次推理成本但你的工作流如果还在反复阅读原文小模型只会更快地漏掉关键信息。换便宜模型同理单价降了总量没变。自动研究循环的价值在于数据结构和工作流重组不在于模型本身。它通过“计划、摘要、记录、终止”四步把喂给主模型的材料从“原始语料”换成了“精炼情报”让Token总量结构性下降。我自己的体会是这几个手段不是互斥的先用自动循环把结构搭好再叠加缓存和廉价摘要模型成本还能再往下压一截。3. 从零搭建高效研究Agent实操全过程3.1 整体架构与工具选型我落地这套方案的架构可以概括成六个模块任务入口、计划器、检索器、摘要器、笔记存储、终止判定。这里不需要一上来就上多复杂的框架我甚至不推荐直接引入重型的Agent编排框架先自写一个状态机逻辑最清楚。等跑通之后再用框架重构也不迟。工具选型这块主角有两类模型。主模型我选一个推理能力强的旗舰LLM负责计划、决策、生成报告它的调用次数不多但单次质量要求高。摘要模型则完全不同我用的是一个便宜到几乎可以忽略的本地小模型或者API里的低价档负责把原始检索结果压缩成结构化摘要。很多朋友低估了摘要模型的角色其实它才是每天跑几十轮的那个“体力劳动者”成本必须压住。检索层我用的方案是组合式一个通用搜索API为主一个自建爬虫为辅。自建爬虫不追求大而全只处理那些指定要看的页面。笔记存储开始用的是本地JSON文件后来规模上来才换成向量库。我的建议是不要为了“架构完整”而上向量库前期一个文件足够后面再平滑迁移。3.2 关键模块的实现要点我把最核心的循环代码用Python伪代码写出来。这里的重点是结构不是具体依赖。def research_loop(task, budget80000): plan planner.brief(task) # 先产出研究计划 notes NoteStore(plan) # 初始化笔记 last_gain 0 while not should_stop(plan, notes, last_gain): sub_question notes.next_question() # 笔记决定下一步问什么 raw retriever.search(sub_question) # 拿到原始结果 summary summarizer.compress(raw) # 轻量模型压缩 new_facts extract_facts(summary) # 抽取增量事实 notes.update(sub_question, summary, new_facts) last_gain len(new_facts) # 记录本轮新增量 # 主模型只在需要调整方向时才介入 if notes.need_replan(): plan planner.replan(plan, notes) return reporter.generate(plan, notes)这一段里有几个容易写错的细节。should_stop里写“连续两轮没有新增事实”时要小心最后一轮算不算建议把“至少完成任务计划中80%的子问题”作为第一优先级避免出现计划没做完就提前停止。extract_facts不要用正则硬抽最好让摘要模型直接输出三元组和引用链接结构化程度越高后面主模型读起来越省Token。终止判定我建议用“预算触顶”而不是“轮数触顶”。轮数多不等于信息多但预算能直接兜住成本。要注意预算按Token算不是按轮数算因为摘要模型和主模型的价格差很多。3.3 Token成本的估算与控制搭建完成后必须给系统装上“成本仪表盘”。最简单的方式是在每次API返回时记录usage字段分主模型和摘要模型两个维度写日志。不要只记总额要把“主模型输入、主模型输出、摘要模型输入、摘要模型输出”拆开否则你不知道哪一边在失控。我常用的预算是这样设定的根据任务难度给一个总Token上限比如8万。自动研究循环里主模型单次输入要控制在一个稳定区间比如6000 Token以内。超出这个值笔记压缩策略就要加强或者把笔记里的过时信息做一次归档。另外一个经验摘要模型建议用同一个供应商的低价模型但prompt一定要固定否则每次压缩格式不一样主模型解析时又多花Token。有一个细节值得单独说很多API的“输入Token”价格高“输出Token”价格更高所以让主模型少写长回复也很关键。我的做法是在研究阶段要求主模型只输出结构化JSON每个字段限制字数真正的长文本只让它在最终报告阶段输出一次。3.4 一次真实运行日志快照拿“某行业融资事件盘点”这个任务举例我把日志简化后大概是这个样子的[plan] 拆出4个子问题行业背景 / 头部公司 / 融资事件 / 趋势判断 [round 1] sub_question行业背景 retriever响应 5条结果, 原始约4200 token summarizer压缩后 486 token, 提取7个事实, 相关度阈值通过5个 notes大小: 1200 token, 主模型输入: 1800 token [round 2] sub_question头部公司 retriever响应 8条结果, 原始约6800 token summarizer压缩后 512 token, 提取9个事实, 通过6个 notes大小: 2400 token, 主模型输入: 3100 token [round 3] sub_question融资事件 retriever响应 10条结果, 原始约9000 token summarizer压缩后 601 token, 提取12个事实, 通过8个 notes大小: 3800 token, 主模型输入: 4600 token [round 4] sub_question趋势判断 retriever响应 3条结果, 原始约2100 token summarizer压缩后 320 token, 提取4个事实, 通过3个 notes大小: 4200 token, 主模型输入: 5200 token [stop] 计划完成度100%, 进入报告生成注意这个日志里原始结果总计约2.2万Token但进入主模型上下文的只有摘要和笔记最后一轮的输入也只有5200 Token。整套流程跑下来主模型输入Token总数大概1.5万加上摘要环节的输出和报告阶段总消耗不到3万。对比传统方案动不动10万以上效果肉眼可见。4. 实验数据与效果验证4.1 我跑的对比实验三组任务我挑了三类有代表性的任务做对比实验行业研究报告、竞品功能盘点、技术选型调研。每类任务跑3次取平均记录的内容包括主模型输入Token总数、总Token消耗、完成轮数、最终报告的字数以及一个“关键信息覆盖率”的评分怎么评呢就是人工检查报告里是否覆盖了预先准备的知识点清单。三组任务跑下来结果和方案预期基本一致。行业研究报告这类任务提升最大传统方案平均消耗13.8万Token自动研究循环是7.4万左右节省幅度约46%。竞品功能盘点幅度差不多在44%上下。技术选型调研的节省稍微少一点约38%原因是这个任务每个候选方案都要求保留较多细节摘要压缩时我刻意下调了压缩比牺牲了一点Token来保准确率。这里有个在我看来更重要的结果关键信息覆盖率不但没降反而从71%提高到了83%。原因是传统方案里模型经常被海量原始文本干扰容易漏掉分散在各处的关键数字自动研究循环的摘要流程相当于做了一轮“信息去重重点抽取”送到主模型面前的信息密度高得多。4.2 结果怎么解读别只盯着一个数字省Token的比例当然亮眼但我希望把三个指标一起看总Token、完成时间、关键信息覆盖率。只盯着Token容易把系统压到阉割版摘要太激进最后报告空洞。我的经验是以“关键信息覆盖率”为主指标Token是次要指标。如果覆盖率掉到70%以下了先不要继续压Token回去调摘要模板。再补充一点运行时间。自动循环由于摘要环节是调用一个廉价小模型整体时间并不长三组任务平均每轮耗时反而比传统方案略高但总轮数明显下降所以整体完成时间基本持平甚至略快。如果摘要模型是本地GPU跑的速度优势会更明显。4.3 边界与不足这套方案不适用哪些场景有收益就有边界。我自己碰到的第一类边界是任务需要保留原始引文比如写学术综述时要求“这句话必须出自某篇文章原文”。摘要流程会损失逐字措辞所以这类任务不能直接套用。第二类是高频多轮人机对话Agent和历史紧密频繁换人设和语气一次性压缩笔记的思路会丢失谈话风格。第三类是高度非结构化的问题比如“帮我想一个广告slogan”这类任务没有检索和研究过程谈不上省Token。另外一个不足是笔记更新的二义性问题。两轮搜索得到的事实可能冲突比如两家网站对同一家公司的融资额说法不一致。传统方案让主模型自己看到原文进而判断自动循环里的摘要模型不一定能识别冲突。我目前的解法是在笔记里保留一个“冲突列表”让主模型在最终报告前专门处理一次。这算是一个workaround不算完美。5. 常见问题与排查实录避坑指南5.1 循环失控Agent无限搜索怎么办我遇到的第一类典型故障就是循环失控。表现是计划里的子问题早就处理完了但Agent还在不断产生新的搜索请求。查下来发现是终止判定里“连续两轮没有新增事实”这个条件被绕过了每一轮摘要里都提取到一个新的、没用的边缘事实比如某公司某年某月注册了一个商标这类信息对报告毫无贡献但确实属于“新事实”。解决的思路是不再用“有没有新事实”作为唯一依据而是改成“有价值的新事实”。我在提取事实时让摘要模型额外输出一个“相关度分值”只有超过阈值才计入增量。同时把“计划完成度”设为硬指标不管还有多少新事实计划完成100%就进入收尾。这两条加一起循环失控基本绝迹。5.2 摘要丢关键信息压缩太狠反而亏第二类问题是摘要丢关键信息。有一版为了追求Token极限把摘要prompt压缩得很短结果是数字和名字被大量丢掉比如“融资额2.5亿”变成“融资额较高”“某大厂”变成“某平台”。这种信息丢失是隐性的最终报告看起来还行但一核对原始数据就对不上。我的调整是给摘要器一条铁律数字和专有名词必须原样保留不允许口语化改写。具体实现是把prompt改成三段式关键实体、关键数字、一句话结论。同时保留原文的链接和标题用于后续验证。这样摘要从300 Token涨到了400 Token但覆盖率显著回升长期看反而是省钱的。5.3 上下文窗口管理为什么笔记越写越长第三个坑是笔记越写越长。前期我用“新增事实追加”的方式维护笔记任务跑到一半笔记已经3000 Token主模型还要再读一轮摘要单次输入涨到6000 Token以上。这违背了设计的初衷因为笔记已经从“恒定大小外部记忆”变成了“第二个对话历史”。后来我加了“笔记归档”机制当笔记超过阈值时把最久远、最基础的信息压缩成一段更短的背景小节。比如前面已经核实的公司基本信息可以从“公司全称、成立时间、地址、创始人”压缩成“主体公司某公司”。另外子问题处理完毕后直接把该子问题的所有笔记片段合并成一个结论条目避免零散条目堆叠。这个机制上线后主模型单次输入稳定回到了6000 Token以内。5.4 独家避坑清单最后给一份我按严重程度排的清单每一条都是真金白银买回来的教训不要一开始就上重量级Agent框架自写状态机跑通核心循环再考虑框架。摘要模型不要只图便宜它每次调用都影响后续主模型的阅读成本要选推理稳定、格式固定的模型。搜索API的返回内容里有大量重复和导航噪音先做一次规则去噪再交给摘要模型能省一点是一点。成本日志从第一天就开始记录不然后期对比实验时没有基准数据。终止判定里一定要有“预算触顶”兜底防止某个异常任务把整月预算烧掉。最终报告单独跑一轮不要复用研究阶段的上下文否则报告里会混进研究过程中的试探性内容。概念上把“LLM的Token”和“登录认证的Token”分开成本统计只用API返回的usage字段避免被其他场景的报错干扰判断。6. 一点个人体会我自己在这两周的实践中最大的体会是省Token不是一个压缩动作而是一个工作流重组动作。把“重读原文”换成“精读笔记”把“无限搜索”变成“有界迭代”这才是自动研究循环真正值钱的地方。NVIDIA和MIT这次把方案框架摆出来了具体怎么落到自己项目里还是要根据自己的任务类型不断调整摘要粒度、终止条件和笔记结构。最后分享一个小经验不要急着让整个Agent变“自动”。先把研究笔记的生成和读取单独抽出来做手工验证确认摘要质量能打再把循环合上。这样即使某一天Token暴涨你也知道问题大概率出在哪个环节。这套思路后续还可以扩展到多Agent协作比如让两个Agent分别负责“收集”和“挑战结论”但那是另一个话题了等我把冲突处理机制再调稳一点再单独写一篇。