Google Deep Research Max 添加了 MCP 和原生视觉效果：研究代理正在成为可重用的构建器管道
谷歌 4 月 21 日的深度研究更新不再是作为聊天机器人功能，而是作为代理系统的移动。 Gemini Deep Research 和 Deep Research Max 现在可以将开放网络与私有数据混合，生成内联图表，并作为后台研究作业运行，为链中的下一个模型提供数据。
Google 实际发货的内容
谷歌表示，新代理基于 Gemini 3.1 Pro 构建，现在支持结合了网络搜索、远程 MCP 服务器、上传文件、连接文件存储、URL 上下文、代码执行和文件搜索的研究工作流程。该公司将该产品分为两种模式：标准 Deep Research 提供更低延迟、更低成本的交互体验，而 Deep Research Max 提供更高综合性的后台运行，需要更多的测试时间计算。
官方公告对于目标工作流程异常明确。谷歌的例子不是消费者聊天查询。这是一个每晚在分析师团队醒来之前生成尽职调查报告的 cron 作业。这是一个强烈的信号，表明研究代理被定位为下游工作的基础设施，而不仅仅是答案引擎。
为什么这对建筑商很重要
这里有三个重要的转变。首先，谷歌正在将研究转变为可重复使用的管道阶段。团队可以运行深度研究来收集和综合证据，然后使用交互 API 通过以下方式将该状态传递给另一个 Gemini 模型： previous_interaction_id 用于总结、重新格式化或下一步执行。其次，谷歌正在通过让代理在网络和自定义数据源上工作来缩小公共和私人环境之间的差距。第三，图表和信息图表现在是同一运行的一部分，而不是单独的可视化步骤。
对于构建者来说，这意味着“深入研究”不再是高级 UI 功能，而是开始看起来像后端工作类别。产品团队可以将其附加到研究简报、销售准备、合规工作流程、市场扫描和技术调查中。如果效果良好，就会减少手动拼接搜索、注释、电子表格输出和执行摘要所花费的时间。
重要的警告：文档仍在迎头赶上
谷歌自己的界面中隐藏着一个有用的警告。博客文章称 Deep Research 现在支持任意远程 MCP 和组合工具，但公共 Interactions API 文档页面仍然显示 4 月 15 日预览时代的警告和旧模型 ID。这种不匹配并不意味着此次发布是假的。这意味着产品表面的移动速度比稳定文档更快。
这正是令牌浪费和团队混乱开始的地方。如果您直接根据公告文案进行构建，您可能会高估当前的稳定情况。如果您忽略启动，您就会错过真正的工作流程转变。实际规则是像对待任何其他预览运行时一样对待研究代理：固定您测试的确切代理或模型 ID，记录实际有效的工具组合，并在 Beta 表面发生变化时保留后备路径。
这与 TRH 推行的操作纪律相同 Google AI Studio 配额现实 和 OpenAI Agents SDK 运行时设计。仅当运行时保持清晰时，工作流压缩才有价值。
TRH 角度：研究管道也需要预算
Token Robin Hood 读者应该关注账单形状，而不仅仅是基准图表。 Deep Research Max 针对深度进行了优化，这通常意味着更长的运行时间、更多的工具使用、更多的上下文积累和更大的输出工件。当报告可重复使用或与收入挂钩时，这可能是值得的。当报表在选项卡中消失或从头开始重新生成时，这是一种浪费，因为没有人将结果存储在堆栈的其余部分可以使用的表单中。
正确的模式很简单。束缚了工作。定义允许哪些数据源。以可重复使用的格式保存输出。仅链接实际需要发生的下一个模型步骤。如果只浏览一次报告，Deep Research Max 可能是错误的默认设置。如果它成为编码代理、销售工作流程或操作备忘录的简报层，那么支出可能会证明是合理的。
建设者下一步应该做什么
从一个后台工作流程开始，其中研究质量比即时延迟更重要：竞争监控、尽职调查、政策跟踪、错误取证或合作伙伴准备。在一项可重复任务上比较常规 Deep Research 与 Max。测量总运行时间、输出有用性，以及在不重述整个问题的情况下将结果传递给第二个模型的频率。然后决定昂贵的版本是否属于生产阶段或仅在人为控制之下。
如果您的堆栈已经使用代理，请再添加一项规则：研究输出应该成为输入，而不是死胡同。保留它们，对它们进行版本控制，并保持下游切换的明确性。