Google Deep Research Max aggiunge MCP e elementi visivi nativi: gli agenti di ricerca stanno diventando pipeline di creazione riutilizzabili
L'aggiornamento Deep Research di Google del 21 aprile conta meno come funzionalità di chatbot e più come mossa dei sistemi di agenti. Gemini Deep Research e Deep Research Max possono ora combinare il Web aperto con dati privati, generare grafici in linea ed eseguire lavori di ricerca in background che alimentano il modello successivo della catena.
Ciò che Google ha effettivamente fornito
Google afferma che i nuovi agenti sono basati su Gemini 3.1 Pro e ora supportano flussi di lavoro di ricerca che combinano ricerca web, server MCP remoti, file caricati, archivi di file connessi, contesto URL, esecuzione di codice e ricerca di file. L'azienda ha suddiviso il prodotto in due modalità: Deep Research standard per esperienze interattive a bassa latenza e costi inferiori e Deep Research Max per esecuzioni in background più complete che utilizzano più calcoli in termini di tempo di test.
L'annuncio ufficiale è insolitamente esplicito riguardo al flusso di lavoro target. L'esempio di Google non è una query di chat del consumatore. Si tratta di un lavoro cron notturno che genera rapporti di due diligence prima che un team di analisti si svegli. Questo è un segnale forte del fatto che gli agenti di ricerca vengono posizionati come infrastrutture per il lavoro a valle, non solo come motori di risposta.
Perché questo è importante per i costruttori
Ci sono tre cambiamenti importanti qui. Innanzitutto, Google sta trasformando la ricerca in una fase di pipeline riutilizzabile. Un team può eseguire ricerche approfondite per raccogliere e sintetizzare prove, quindi utilizzare l'API Interactions per trasferire tale stato a un altro modello Gemini tramite previous_interaction_id per il riepilogo, la riformattazione o l'esecuzione del passaggio successivo. In secondo luogo, Google sta riducendo il divario tra il contesto pubblico e quello privato consentendo all’agente di lavorare sul Web e su origini dati personalizzate. In terzo luogo, i grafici e le infografiche ora fanno parte della stessa esecuzione invece che di una fase di visualizzazione separata.
Per i costruttori, ciò significa che la "ricerca approfondita" smette di essere una funzionalità premium dell'interfaccia utente e inizia a sembrare una classe di lavoro di backend. I team di prodotto possono allegarlo a brief di ricerca, preparazione delle vendite, flussi di lavoro di conformità, analisi di mercato e indagini tecniche. Se funziona bene, riduce il tempo impiegato a mettere insieme manualmente ricerca, note, output di fogli di calcolo e riepiloghi esecutivi.
L'avvertenza importante: i documenti stanno ancora recuperando terreno
C'è un avviso utile nascosto nelle superfici di Google. Il post sul blog afferma che Deep Research ora supporta MCP remoti arbitrari e strumenti combinati, ma la pagina pubblica dei documenti dell'API Interactions mostra ancora gli avvertimenti dell'era di anteprima del 15 aprile e gli ID dei modelli precedenti. Questa mancata corrispondenza non significa che il lancio sia falso. Significa che la superficie del prodotto si sta muovendo più velocemente dei documenti stabili.
Questo è esattamente il punto in cui iniziano lo spreco di token e la confusione della squadra. Se costruisci direttamente dal testo dell’annuncio, rischi di sopravvalutare ciò che è stabile oggi. Se ignori il lancio, perdi un vero cambiamento nel flusso di lavoro. La regola pratica è trattare gli agenti di ricerca come qualsiasi altro runtime di anteprima: aggiungere l'agente esatto o l'ID modello testato, registrare quale combinazione di strumenti ha effettivamente funzionato e mantenere un percorso di fallback per quando cambia la superficie beta.
Questa è la stessa disciplina operativa che TRH introduce Realtà delle quote di Google AI Studio E Progettazione del runtime dell'SDK degli agenti OpenAI. La compressione del flusso di lavoro è utile solo se il runtime rimane leggibile.
Il punto di vista TRH: anche i gasdotti di ricerca necessitano di budget
Token Robin Hood i lettori dovrebbero prestare attenzione alla forma della fatturazione, non solo al grafico di riferimento. Deep Research Max è ottimizzato per la profondità, il che in genere significa cicli più lunghi, maggiore utilizzo degli strumenti, maggiore accumulo di contesto e artefatti di output più grandi. Può valerne la pena quando il report è riutilizzabile o collegato alle entrate. È uno spreco quando il report muore in una scheda o viene rigenerato da zero perché nessuno ha archiviato il risultato in un formato che il resto dello stack può utilizzare.
Il modello giusto è semplice. Rilegato il lavoro. Definire quali origini dati sono consentite. Salvare l'output in un formato riutilizzabile. Concatena solo il passaggio successivo del modello che deve effettivamente verificarsi. Se il report verrà sfogliato solo una volta, Deep Research Max è probabilmente l'impostazione predefinita sbagliata. Se diventa il livello di briefing per un agente di codifica, un flusso di lavoro di vendita o una nota operativa, la spesa potrebbe giustificarsi da sola.
Cosa dovrebbero fare i costruttori dopo
Inizia con un flusso di lavoro in background in cui la qualità della ricerca conta più della latenza istantanea: monitoraggio della concorrenza, due diligence, monitoraggio delle policy, analisi forense dei bug o preparazione dei partner. Confronta la ricerca approfondita regolare con Max su un'attività ripetibile. Misura il tempo di esecuzione totale, l'utilità dell'output e la frequenza con cui il risultato può essere trasferito a un secondo modello senza riaffermare l'intero problema. Quindi decidi se la versione costosa è in produzione o solo dietro un cancello umano.
Se il tuo stack utilizza già agenti, aggiungi un'altra regola: i risultati della ricerca dovrebbero diventare input, non vicoli ciechi. Perseverali, creane la versione e mantieni esplicito il passaggio a valle.