1. 问题与动机

传统网页搜索型智能体通常把页面访问结果直接塞进对话上下文：搜索接口返回摘要，访问工具再返回经过截断或摘要化的正文。这个设计看似简单，却把“获取证据”和“决定哪些证据值得推理”绑在同一步里。长网页会迅速消耗上下文，摘要可能提前丢掉数字、限定条件和跨段关系；当智能体后续发现某段很关键时，又只能重新访问网页。论文将这一矛盾概括为瞬时浏览（transient browsing）的瓶颈：工具调用产生的信息只短暂存在于轨迹中，模型既无法低成本回看全文，也缺少像人在本地文件中检索、定位和反复核对的操作面。

Fetch-then-Explore 的核心问题是：在不增加模型参数、不训练专用浏览器策略、也不把完整网页注入上下文的前提下，能否仅改变工具接口，让通用大模型更有效地完成长时程、证据密集的深度搜索任务。作者把每次成功抓取的网页正文保存到当前问题专属的文件系统缓存中，模型只收到文件路径、字符数和状态等简短元数据，然后通过 grep 与 read 主动探索。这样，信息获取从一次性的“读完即丢”变成持久、可寻址的外部工作记忆。

这项工作对搜索与推荐团队的价值在于，它没有把收益归因于更大的模型或更长的上下文，而是直接研究工具抽象本身。许多生产 Agent 已经接入搜索、网页读取、内部知识库和文档系统，但仍将全文回灌进 prompt；一旦任务跨越几十个来源，token 成本、注意力稀释和重复请求会同时上升。论文试图证明，先把原始证据可靠落盘，再让模型按需检索局部片段，是一种模型无关、成本相对可控的系统级改进。

2. 方法详解

方法为每个问题创建独立缓存 Cq。fetch(url) 抓取网页并将规范化正文完整写入缓存，而返回给模型的不是正文，而是可追踪的文件路径、字符规模和抓取状态。文件名由主机名与 URL 的 SHA-256 前缀组成，并在文件头记录来源 URL 等 provenance 信息，既降低同名覆盖风险，也让引用可追溯。一次推理轨迹结束后缓存即删除，所以它是任务内记忆，不是跨用户、跨任务的长期知识库。

模型在缓存上拥有两个主要探索工具。grep 接收字符串或正则模式，可跨文件定位命中项，最多返回 20 个匹配，并默认携带命中位置前后各 3 行上下文；工具把搜索结果控制在小窗口内，避免一次查询重新灌入整篇文档。read 按行读取指定文件，单次最多 200 行且受 50KB 上限约束，适合在 grep 定位后展开邻近证据。作者还保留普通 search 工具，因此典型轨迹变成“搜索候选 URL—抓取并持久化—跨缓存定位实体或数字—按需读取上下文—综合答案”。

实验刻意保持其余条件一致：不同浏览设置使用相同系统提示、相同搜索后端和尽量相同的工具 schema，仅改变页面内容如何进入上下文。搜索由 Serper 提供，网页抽取使用 crawl4ai。评测模型包括 Qwen3.5-35B、Qwen3.5-122B 与 DeepSeek-V4-Pro，解码温度为 1、top-p 为 0.95、最大输出 16,384 tokens，每个问题最多允许 300 个交互轮次，不启用额外上下文管理机制。这个设置使结果更能反映持久缓存和工具可寻址性的贡献，而不是某种隐藏压缩器或人工编排策略。

对照组包括 VisitSnippet、VisitSummary 与 OpenFind。VisitSnippet 只把访问页面的片段送回模型，成本低但细节覆盖有限；VisitSummary 在访问时生成摘要，能压缩正文，却可能在尚不知道后续推理需要什么时提前丢失证据；OpenFind 提供面向打开页面的查找操作，已经允许一定程度的局部定位，但页面状态与跨来源复查仍弱于文件缓存。Fetch-then-Explore 的关键差别不是单次返回更多，而是把完整内容移出上下文并保留为可反复检索的外部状态。

3. 核心技术贡献

第一，论文把网页访问重新定义为“持久化写入”而不是“文本返回”。fetch 只回传轻量元数据，正文存在上下文之外，因此抓取更多来源不会线性挤占模型窗口。模型仍能在需要时通过路径、行号和匹配模式精确取回证据。这个接口把原始资料与工作记忆分离，也让系统可以记录来源、字符数和失败状态，便于审计与故障诊断。

第二，作者证明简单的文件工具足以形成有效的探索策略。模型没有接受额外训练，却会自然组合 search、fetch、grep 和 read：先宽搜，后缓存，再围绕实体、数值或关系做跨文件定位。行为分析显示，BrowseComp 中 12%–20% 的问题发生重访，而瞬时浏览基线只有约 3%–10%；在需要汇总大量实体的 WideSearch 上，重访比例达到 67%–76%，是瞬时设置的约 8–12 倍。这说明缓存不是被动存储，模型确实把它当作可操作记忆。

第三，论文用受控实验展示了该抽象在不同规模模型上的稳定增益。它没有引入额外训练数据或专用规划器，因此可以作为模型和搜索供应商之外的一层基础设施优化。对于已有 Agent 平台，这比替换底座模型更容易灰度：可以让同一请求同时运行旧式正文返回与缓存式访问，比较正确率、token、网页重抓率和延迟。

第四，工作提供了细粒度工具消融。完整方案之外，作者分别移除跨缓存搜索、grep 或 read，观察准确率与搜索调用变化。结果显示这些能力互补：grep 负责快速缩小证据区域，read 负责恢复局部语境，跨缓存能力则支持在多个来源间对照。即使全缓存 grep 只在少数问题中出现，它在需要跨文档核对时仍可能决定成败，不能仅凭调用频率判断价值。

4. 实验结果分析

论文在 BrowseComp 与 WideSearch 上评测。BrowseComp 使用固定抽样的 200 个问题，关注多步网页调查后的最终准确率；WideSearch 同样评测 200 个任务，更强调跨大量来源收集实体与属性，使用 Row F1 衡量表格型结果。每个模型与设置运行 3 次并报告最佳结果，最终答案由 DeepSeek 系列模型判分。

Fetch-then-Explore 在三个模型上都取得最高 BrowseComp 准确率。相对最弱的 VisitSnippet，提升为 7–14 个绝对百分点；相对已经能局部查找的 OpenFind，仍提高 2–4.5 个百分点。增益并未随着模型扩大而消失：DeepSeek-V4-Pro 从 66.0 提升到 70.5，说明强模型同样受益于可靠的外部证据工作区，而不是只有较小模型需要这种支撑。

WideSearch 上，完整方法在 Qwen3.5-35B、Qwen3.5-122B 和 DeepSeek-V4-Pro 的 Row F1 分别达到 34.3、39.1 和 51.4。该任务的高重访率尤其能解释收益：当答案需要把多个网页的条目合并成结构化结果时，模型经常必须回到早先页面补字段、去重或验证边界条件。瞬时摘要很难保证第一遍就保留后续需要的每个属性，而文件缓存允许在答案结构逐渐成形后重新查询。

Qwen3.5-35B 的消融最有诊断性。完整方法 BrowseComp 为 44.5；移除跨缓存搜索后降至 39.5，移除 grep 后降至 37.0，移除 read 后降至 39.5。WideSearch 中，移除跨缓存能力使 Row F1 从 34.3 降到 29.2。能力缺失还会增加约 6–8.3 次搜索调用，说明模型不能在已有证据中定位时，会转而重新上网搜索，既增加外部请求又可能引入来源漂移。

工具日志进一步说明策略并不复杂但有效。每个 BrowseComp 问题通常缓存 5–11 篇文档，WideSearch 为 11–15 篇；74%–92% 的 grep 模式是正则表达式，88%–99.7% 的检索针对单个文件，表明模型通常先选定来源再精确定位。对全缓存执行 grep 的比例只有约 1%–10.5%，但它适合寻找跨来源共同实体。重复 fetch 低于 5%，最强设置不超过约 1.4%，支持“持久化缓存能减少无意义重抓”的解释。

这些结果仍需谨慎解读。BrowseComp 与 WideSearch 都只使用 200 个样本，置信区间未成为主要呈现形式；每个单元格取三次运行中的最佳值，会高估典型部署表现并弱化方差。答案依赖 LLM judge，DeepSeek-V4-Pro 条件还存在同系列模型参与判分的潜在偏差。实验主要证明准确率与行为变化，没有同时给出端到端墙钟时间、磁盘 I/O、总 token 成本或搜索 API 费用，因此不能直接断言所有场景都更便宜。

5. 局限与未来方向

作者没有设置单独的 Limitations 章节，但结论明确提出两个扩展方向。其一是跨轨迹记忆：当前缓存随问题结束删除，无法复用重复查询、团队共享资料或长期研究项目中的证据；未来可以在权限、版本和失效策略可控的前提下，将高质量页面转为跨任务资产。其二是在 fetch 阶段建立实体或结构索引，使模型不仅依赖词法 grep，还能按表格、标题层级、实体关系或语义邻近检索。

当前方案对网页抓取质量高度敏感。crawl4ai 能处理常见 HTML，但动态渲染、登录墙、反爬、扫描 PDF、脚本生成表格和多媒体内容都可能丢失；错误正文一旦被持久化，后续精确 grep 只会更稳定地检索错误。系统也没有系统评估 prompt injection：网页中的恶意指令被完整保存后，模型在 read 时仍可能执行它们。因此生产实现需要把网页内容标记为不可信数据，做内容净化、域名策略、文件权限隔离与引用核验。

文件系统缓存本身带来新的治理问题。任务结束即删除在实验上简单，却未说明异常退出、并发请求、租户隔离、敏感数据、磁盘配额和审计留存。URL 哈希可减少命名冲突，但不能替代内容去重、版本控制和访问控制。若扩展为跨轨迹记忆，还必须处理页面更新、删除请求、个人信息和许可证。搜索型 Agent 的风险不只在答案错误，也在把本不该长期保存的网页或内部文档变成持久副本。

评测覆盖也较窄。两个基准偏向英文公开网页研究，尚未证明中文网页、移动端内容、站内搜索、商品详情、论坛评论和企业内部知识库具有同样收益。最长 300 轮的设置适合研究上限，却未对应生产 Agent 的预算约束；更有价值的后续实验应给定搜索次数、总 token、P95/P99 延迟与美元成本，在同一成功率下比较不同工具协议。还应报告三次运行均值与方差，而不只是最佳值。

6. 工业实践意义

对搜索 Agent 平台，最直接的落地方式是把网页访问服务拆成“抓取存储层”和“证据读取层”。抓取层输出稳定 document_id、原始 URL、抓取时间、内容哈希、字符数与状态；读取层提供受限的关键词/正则定位和分页读取。模型默认只看到元数据，只有在明确提出模式或行区间时才取回正文。这样既能降低上下文膨胀，也为缓存命中率、重访率、证据引用和失败原因建立可观察性。

灰度验证不能只看最终回答分。建议同时统计任务成功率、事实引用覆盖、搜索次数、重复 fetch 比率、读入 token、缓存文档数、grep/read 调用链、磁盘峰值与端到端延迟。论文中移除工具会额外触发 6–8.3 次搜索，这是很实用的线上指标：如果新协议没有降低重复外部请求，可能是模型没有理解路径语义、文档抽取质量差，或工具描述不足。对同一问题做成对回放，比单看离线平均分更容易定位收益来源。

面向企业或社区搜索，应增加三层安全边界。第一，缓存按请求和租户隔离，采用不可猜测标识，并设置 TTL 与配额；第二，所有网页正文都视为数据而非指令，对提示注入、脚本、隐藏文本和下载附件单独过滤；第三，答案中的关键事实必须回链到 URL、文档版本与行区间，必要时由独立验证器复查。若缓存包含登录态页面或内部资料，还需要访问控制继承与删除审计。

对于推荐与电商场景，这一模式同样可用于商品比较、竞品调研、用户长问题解析和运营知识问答。页面或内部文档先落入短期证据仓，Agent 再围绕品牌、规格、价格、地区和时间条件检索局部片段。结构化字段适合在抓取时额外建立索引，叙述性证据仍保留原文供 read。相比一开始就让摘要器决定保留什么，这种延迟选择更能适应后续出现的新约束。

总体而言，Fetch-then-Explore 的贡献不是一种复杂的新推理算法，而是一个足够小、可替换且被实验验证的工具接口原则：完整证据留在上下文之外，检索决策留给执行中的模型。它在三个模型、两个基准和多组消融中表现一致，适合作为长时程搜索 Agent 的基础设施基线。但上线前必须补齐成本分解、安全隔离、抓取鲁棒性和真实流量 A/B，不能把离线准确率提升直接等同于生产收益。