AI Agent的检索税：多跳搜索为何让token成本暴增4倍

Andrej Karpathy曾把大模型比作患有“顺行性遗忘症”的同事——它保留旧记忆却无法形成新记忆。对Agent来说这种遗忘体现在两个层面跨对话不记得用户以及训练截止后发生的一切它一无所知。Memory机制能缓解第一种遗忘而第二种遗忘的修复主要靠实时Web检索。市场波动、人员变动、价格更新、突发新闻……Agent要想处理当下问题检索质量几乎决定了整个系统的可用性。很多人给Agent接上搜索工具后就以为“它现在能看到互联网了”。实际跑几轮trace后却发现绝大多数token都花在了处理原始网页文本上只有极小一部分用于真正回答问题。每次搜索循环都在支付“检索税”问题不在Agent搜索能力差而在于标准搜索API返回的格式。典型搜索调用只返回链接 30字左右的snippet。Agent拿到后必须自己抓取完整页面、剥离HTML、提取正文才能开始真正工作。单次查询时这个开销还不明显。但在需要多次搜索的研究型任务或简报生成 pipeline 中每一跳都要重复支付这笔“检索税”——抓取、清洗、塞进上下文。我们把同一个问题用三种检索方式跑通并统计token消耗。问题选了“What was Y2K?”因为模型训练时已经知道答案这样能把思考成本控制一致额外token几乎全部来自检索过程。纯记忆回答约600 tokens基准预建索引提前爬取并清洗好的owned index约6,900 tokens标准Web搜索单跳约3,750 tokens标准Web搜索三跳循环约28,700 tokens是预建索引的4倍以上三跳循环的成本之所以暴增是因为每一跳都要把之前已经读过的页面内容重新塞进不断增长的上下文窗口。Agent其实在为“已经知道的内容”重复付费。预建索引则完全跳过了这个过程完整文档在查询到达前就已经准备好一次调用直接返回可用内容。好的检索应该返回文档而不是方向检索税的根源在于返回格式。SERP标准搜索结果页只给URL列表让Agent自己去读网页。普通抓取工具返回原始HTML或MarkdownAgent仍需清洗。预建owned index提前完成所有清洗和结构化一次调用返回可直接推理的完整文档。同一个查询在三种方式下的体验差异极大。以搜索“Christoph Molnar”《Interpretable Machine Learning》作者为例SERP返回一堆标签页Agent几乎得不到答案。神经搜索能定位到人但只返回高亮片段仍需额外调用拿完整记录。预建索引一次返回完整结构化记录Agent直接进入推理阶段。像Seltz这类为Agent设计的索引会提前把网页处理成结构化文档并提供不同scopePeople scope返回完整职业档案角色、时间、公司、教育等News scope返回日期窗口内的完整文章正文Wiki scope返回干净的维基百科文档这些都不是简单替换开放搜索而是针对“需要深度内容”的查询场景。有些答案只存在于记录的交叉中全文档检索带来的不止是成本降低还解锁了snippet无法回答的问题类型。考虑一个GTM团队真实会问的问题“过去一个季度里哪些目标账户新聘用了数据或AI领导角色”回答需要同时满足两个条件完整角色历史判断何时入职 近期新闻确认触发事件。snippet或单次搜索做不到跨记录join。正确做法是先用People scope找出近期入职相关角色的人再用News scope交叉验证触发事件最终输出带上下文的warm account列表并附上可用于首封邮件的个性化切入点。这种答案在网上不存在单一页面它只存在于多条记录的交集里。而只有持有完整记录时join才可能发生。发现与深度检索的合理链式使用开放Web搜索适合发现类问题谁当前担任某个职位、上周刚发布的新闻、今天刚上线的页面。一旦知道要找什么owned index就能一跳返回完整记录而不是标题链接。很多pipeline对所有查询都用同一种搜索工具结果发现类和深度类查询都支付了不必要的检索税。把两者链起来使用发现阶段用开放搜索深度阶段切换到预建索引每一轮迭代的成本都会显著下降。这才是Agent循环成本的真正杠杆点——不是模型本身而是每次搜索调用返回的内容形态。当你构建的研究型、简报型或需要跨记录推理的Agent循环时检索返回“完整文档”而非“指向文档的指针”是目前降低token消耗最直接有效的手段。在你当前构建的Agent循环里研究或信息收集类任务占多大比例你是否已经测量过多跳检索带来的实际token开销本文基于Akshay Pachaar的技术分享重构致敬他对Agent检索效率的系统性拆解。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。