Google 在 2026 年 5 月 5 日发布了一篇文章：Gemini API File Search is now multimodal: build efficient, verifiable RAG。 这篇文章讲的是 Gemini API File Search 的更新：它支持多模态检索、自定义 metadata，以及 page-level citations。 如果只把它看成一个“文件搜索功能”，会有点低估它。它更重要的意义是：Agent 开发正在从临时塞上下文，走向构建可检索、可过滤、可引用的证据层。
File Search 是什么 Gemini API File Search 是 Gemini API 里的一个 RAG 工具。 开发者可以把文件上传到 File Search store。系统会把文件切分、生成 embeddings、建立索引。之后模型回答问题时，可以先从这些资料里检索相关内容，再基于检索结果生成回答。 Google 官方文档里对它的描述是：File Search 会导入、切分并索引数据，让模型基于用户问题快速检索相关信息，并把这些信息作为上下文使用。 这次更新主要有三个点。
第一，支持多模态资料。 File Search 现在可以处理文本和图片。它使用 gemini-embedding-2 来支持 image / multimodal embedding。也就是说，资料库不只可以放文本、PDF、代码文档，也可以包含架构图、流程图、截图、视觉资产等内容。
第二，支持 custom metadata。 开发者可以给文件添加 key-value 标签，比如： department: Legal status: Final project: checkout version: v2 查询时可以根据 metadata 做过滤。这个能力很重要，因为真实项目里的资料通常不是“找不找得到”的问题，而是“能不能从一堆相似资料里找到正确版本、正确范围、正确状态的资料”。
第三，支持 page-level citations。 当回答来自大型 PDF 或复杂文档时，File Search 可以把答案关联到原始来源，甚至是具体页码。这让回答更容易被验证。 所以 File Search 的关键词不是“搜索”，而是： 检索过滤引用验证
File Search 指向的解决方式是：不要把所有资料都临时塞进对话，而是把资料整理成一个可检索的知识层。 开发者提出问题时，模型先检索相关内容，再基于检索结果回答。 这改变了 agent 的基础工作方式。
过去是： 用户把上下文交给模型模型在当前对话里尽量理解 现在更像是： 用户提出目标系统从资料库检索相关证据模型基于证据回答或行动回答附带来源 这不是更花哨，而是更工程化。
对普通开发者的日常影响 这类能力会改变普通开发者和 agent 交流的方式。
以前，重点是把 prompt 写清楚。 以后，重点会变成：让 agent 能找到正确资料，并知道如何使用资料。
比如以前可能会说： 帮我解释这个接口怎么用。 更好的方式会是： 基于官方文档和当前版本的接口说明解释这个接口。如果文档里没有明确说明，请标记为不确定。回答时给出来源。
以前可能会说： 帮我修这个问题。 更好的方式会是： 先查相关错误日志、设计文档和现有测试。只基于检索到的资料和当前代码判断。如果资料之间冲突，先指出冲突。 这背后的变化是：开发者不再只是给 agent 下命令，而是在给 agent 指定资料范围、可信来源和验证方式。
文档会变成 Agent 的工作材料 这篇 File Search 文章还有一个隐含信号：文档的重要性会重新上升。 过去很多团队觉得文档是“写给人看的”。写得好当然有价值，但经常没人看，或者很快过期。 在 agent 场景里，文档还有另一层价值：它是 agent 可检索的工作材料。 未来更有价值的资料不是“很长的文档”，而是适合检索的资料： 标题清楚模块边界清楚版本状态清楚来源可信 metadata 完整过期内容可识别关键结论可引用 如果资料是混乱的，agent 检索出来的上下文也会混乱。 如果资料是结构化的，agent 就更容易找到正确依据。 所以 File Search 这类能力并不是让开发者不用写文档，而是让文档变得更像基础设施。
多模态为什么重要 多模态检索对开发者也很关键。 真实开发资料不只有文字。很多信息藏在： 架构图流程图时序图数据库关系图 UI 截图报错截图设计稿 PDF 报告 如果 agent 只能检索文本，它对项目的理解是不完整的。 File Search 支持图片和文本一起检索，意味着 agent 可以把视觉资料也纳入上下文。这对很多场景很有用： 根据架构图理解服务关系根据截图定位 UI 问题根据流程图解释业务路径根据 PDF 页面引用具体依据根据设计图辅助生成实现方案 这让 agent 的“资料室”不再只是一堆 Markdown，而是更接近真实开发环境里的混合资料库。
Agent 交流方式会怎么变 对普通开发者来说，最实际的改变是：以后和 agent 交流，要少一点“你猜一下”，多一点“你先查证”。
少说： 你觉得这个问题怎么解决？ 多说： 先查相关文档和当前版本说明。基于证据给方案。不确定的地方单独标出来。
少说： 我把背景贴给你，你记住。 多说： 相关资料在这些文档里。请先检索，再回答。回答时说明用了哪些来源。
少说： 帮我写一个实现。 多说： 先确认接口约定、设计限制和已有测试。再给最小实现方案。如果资料不足，不要补猜。 这其实是从 prompt thinking 走向 context engineering。
不是只研究一句话怎么写得漂亮，而是思考： agent 应该查哪些资料资料如何组织哪些资料可信如何过滤范围回答如何引用来源结果如何验证
这篇文章真正值得记住的点 Gemini File Search 不是在告诉我们“搜索文件很重要”。 它更像是在提醒开发者：agent 的能力边界正在变化。
早期我们关心的是模型能不能生成答案。 现在我们越来越关心： 答案有没有依据依据是不是最新来源能不能追溯资料能不能过滤上下文能不能长期维护 这对开发者是一个很现实的提醒。 未来更会用 agent 的人，不一定是 prompt 写得最长的人，而是更会组织资料、定义边界、要求证据、设计验证流程的人。
File Search 代表的方向，就是让 agent 不只会回答，而是能在一个可检索的证据环境里工作。 这也是 agent 从“聊天助手”走向“开发协作者”的关键一步。
