Google Deep Research Max fügt MCP und native Visuals hinzu: Forschungsagenten werden zu wiederverwendbaren Builder-Pipelines
Das Deep Research-Update von Google vom 21. April ist weniger als Chatbot-Funktion, sondern eher als Agentensystem-Aktion von Bedeutung. Gemini Deep Research und Deep Research Max können jetzt das offene Web mit privaten Daten mischen, Diagramme inline generieren und als Hintergrundforschungsjobs ausführen, die das nächste Modell in der Kette versorgen.
Was Google tatsächlich geliefert hat
Laut Google basieren die neuen Agenten auf Gemini 3.1 Pro und unterstützen jetzt Forschungsworkflows, die Websuche, Remote-MCP-Server, hochgeladene Dateien, verbundene Dateispeicher, URL-Kontext, Codeausführung und Dateisuche kombinieren. Das Unternehmen teilte das Produkt in zwei Modi auf: Standard-Deep Research für interaktive Erlebnisse mit geringerer Latenz und geringeren Kosten und Deep Research Max für umfassendere Hintergrundläufe, die mehr Testzeit-Rechenleistung erfordern.
Die offizielle Ankündigung äußert sich ungewöhnlich deutlich zum Ziel-Workflow. Bei dem Beispiel von Google handelt es sich nicht um eine Verbraucher-Chat-Anfrage. Es ist ein nächtlicher Cron-Job, der Due-Diligence-Berichte erstellt, bevor ein Analystenteam aufwacht. Das ist ein starkes Signal dafür, dass Forschungsagenten als Infrastruktur für nachgelagerte Arbeiten und nicht nur als Antwortmaschinen positioniert werden.
Warum das für Bauherren wichtig ist
Hier gibt es drei wichtige Veränderungen. Erstens verwandelt Google die Forschung in eine wiederverwendbare Pipeline-Phase. Ein Team kann Deep Research durchführen, um Beweise zu sammeln und zu synthetisieren, und dann die Interaktions-API verwenden, um diesen Zustand an ein anderes Gemini-Modell weiterzuleiten previous_interaction_id zum Zusammenfassen, Neuformatieren oder zur nächsten Schrittausführung. Zweitens verringert Google die Kluft zwischen öffentlichem und privatem Kontext, indem es den Agenten im gesamten Web und in benutzerdefinierten Datenquellen arbeiten lässt. Drittens sind Diagramme und Infografiken jetzt Teil desselben Durchlaufs und nicht mehr ein separater Visualisierungsschritt.
Für Entwickler bedeutet das, dass „Deep Research“ keine Premium-UI-Funktion mehr ist und wie eine Backend-Jobklasse aussieht. Produktteams können es an Forschungsberichte, Vertriebsvorbereitungen, Compliance-Workflows, Marktscans und technische Untersuchungen anhängen. Wenn es gut funktioniert, verringert sich der Zeitaufwand für das manuelle Zusammenfügen von Suche, Notizen, Tabellenausgaben und Zusammenfassungen.
Der wichtige Vorbehalt: Die Dokumente holen immer noch auf
In Googles eigenen Oberflächen versteckt sich eine nützliche Warnung. In dem Blogbeitrag heißt es, dass Deep Research jetzt beliebige Remote-MCPs und kombinierte Tools unterstützt, aber auf der öffentlichen Seite mit den Interactions-API-Dokumenten werden immer noch Vorbehalte für die Preview-Ära vom 15. April und ältere Modell-IDs angezeigt. Diese Nichtübereinstimmung bedeutet nicht, dass der Start gefälscht ist. Dies bedeutet, dass sich die Produktoberfläche schneller bewegt als die stabilen Dokumente.
Genau hier beginnen Token-Verschwendung und Team-Verwirrung. Wenn Sie direkt auf der Ankündigungskopie aufbauen, besteht die Gefahr, dass Sie überschätzen, was heute stabil ist. Wenn Sie den Start ignorieren, verpassen Sie eine echte Workflow-Veränderung. Die praktische Regel besteht darin, Forschungsagenten wie jede andere Vorschau-Laufzeitumgebung zu behandeln: Fixieren Sie den genauen Agenten oder die Modell-ID, die Sie getestet haben, protokollieren Sie, welcher Tool-Mix tatsächlich funktioniert hat, und behalten Sie einen Fallback-Pfad für den Fall bei, dass sich die Beta-Oberfläche ändert.
Dies ist die gleiche Betriebsdisziplin, die TRH vorantreibt Realität der Google AI Studio-Quoten Und OpenAI Agents SDK-Laufzeitdesign. Die Workflow-Komprimierung ist nur dann sinnvoll, wenn die Laufzeit lesbar bleibt.
Der TRH-Aspekt: Forschungspipelines brauchen auch Budgets
Token Robin Hood Leser sollten auf die Abrechnungsform achten, nicht nur auf das Benchmark-Diagramm. Deep Research Max ist auf Tiefe optimiert, was in der Regel längere Durchläufe, mehr Tool-Nutzung, mehr Kontextakkumulation und größere Ausgabeartefakte bedeutet. Das kann sich lohnen, wenn der Bericht wiederverwendbar oder umsatzgebunden ist. Es ist verschwenderisch, wenn der Bericht in einem Tab verschwindet oder von Grund auf neu generiert wird, weil niemand das Ergebnis in einer Form gespeichert hat, die der Rest des Stapels nutzen kann.
Das richtige Muster ist einfach. Den Job gebunden. Definieren Sie, welche Datenquellen zulässig sind. Speichern Sie die Ausgabe in einem wiederverwendbaren Format. Verketten Sie nur den nächsten Modellschritt, der tatsächlich ausgeführt werden muss. Wenn der Bericht nur einmal überflogen werden soll, ist Deep Research Max wahrscheinlich die falsche Standardeinstellung. Wenn es zur Briefing-Ebene für einen Coding-Agenten, einen Vertriebsworkflow oder eine Betriebsnotiz wird, können sich die Ausgaben rechtfertigen.
Was Bauherren als nächstes tun sollten
Beginnen Sie mit einem Hintergrund-Workflow, bei dem die Forschungsqualität wichtiger ist als die sofortige Latenz: Wettbewerbsüberwachung, Due Diligence, Richtlinienverfolgung, Fehlerforensik oder Partnervorbereitung. Vergleichen Sie reguläres Deep Research mit Max bei einer wiederholbaren Aufgabe. Messen Sie die Gesamtlaufzeit, den Ausgabenutzen und wie oft das Ergebnis an ein zweites Modell übergeben werden kann, ohne das gesamte Problem erneut zu formulieren. Dann entscheiden Sie, ob die teure Variante in die Produktion gehört oder nur hinter ein menschliches Tor.
Wenn Ihr Stack bereits Agenten verwendet, fügen Sie eine weitere Regel hinzu: Forschungsergebnisse sollten zu Eingaben werden und nicht zu Sackgassen. Behalten Sie sie bei, versionieren Sie sie und sorgen Sie dafür, dass die Downstream-Übergabe explizit bleibt.