Como combinar o Chrome Summarizer e o Gemini em um assistente React

Um assistente React pode usar o Chrome Summarizer para resumir o briefing no dispositivo e reservar uma chamada separada ao Gemini para propor alterações. Mantenha o texto original como referência, vincule cada proposta à versão atual do rascunho e só salve depois da revisão. Esse fluxo aparece no Trip Workbench, exemplo descrito por Raju Dandigam em um artigo publicado em 28 de outubro de 2026.

Neste guia

• Confira os requisitos antes de integrar
• Separe o resumo local da proposta de Gemini
• Trate disponibilidade, cancelamento e textos longos
• Vincule cada proposta ao rascunho atual
• Mostre as mudanças antes de salvar
• Teste o ciclo de vida, não só a resposta

Confira os requisitos antes de integrar

A página do Chrome sobre o Summarizer, atualizada em 30 de julho de 2025, identifica o Chrome 138 estável como ponto de partida e especifica os seguintes requisitos:

Esses são os critérios descritos naquela página, não uma checagem do dispositivo de cada usuário. Antes de tornar o resumo local obrigatório no seu produto, considere o conjunto de sistemas e equipamentos que você pretende atender.

Separe o resumo local da proposta de Gemini

No fluxo descrito por Dandigam, o resumo local e a proposta na nuvem são ações distintas. O Chrome Summarizer transforma o briefing original em texto para a pessoa consultar. Essa etapa não inicia a solicitação ao Gemini. Quando a pessoa pede uma proposta, o briefing original segue para o backend da aplicação, que faz a chamada ao Gemini e recebe sugestões de alterações estruturadas e perguntas para esclarecer detalhes.

O Chrome afirma que o uso do modelo integrado não envia dados ao Google nem a terceiros. Depois do download inicial, o Summarizer pode funcionar sem conexão. Essa afirmação se refere ao uso do modelo local. A chamada separada do Trip Workbench envia o briefing ao backend da aplicação; por isso, apresente a ação na nuvem como um fluxo próprio, com sua finalidade explícita.

Aplique a proposta por meio da rota normal de atualização do backend, só depois que a pessoa a revisar. No Trip Workbench, aplicar alterações salva o rascunho; enviar o pedido e reservar a viagem são ações separadas.

Trate disponibilidade, cancelamento e textos longos

Antes de criar uma sessão, chame Summarizer.availability() com as mesmas opções que serão usadas na criação. O Chrome descreve quatro estados: available, downloadable, downloading e unavailable. Se for necessário baixar o modelo, a criação da sessão exige uma interação da pessoa. A conexão inicial deve ser sem limite de dados; depois que o modelo é baixado, o uso local não precisa de rede. A documentação do Chrome para o Summarizer reúne esses requisitos e a interface da API.

Passe um AbortSignal para Summarizer.create() para que a aplicação também possa cancelar uma criação ainda pendente. Se o sinal for acionado antes de a promessa ser resolvida, a criação é cancelada. Se a sessão já foi criada, o cancelamento libera a instância e as chamadas ao Summarizer passam a rejeitar com AbortError.

Não fixe um limite de tokens universal. O valor de inputQuota depende da implementação; consulte a cota da sessão e use measureInputUsage() para avaliar o texto específico antes de enviá-lo. Se o conteúdo for longo demais, o Chrome recomenda dividi-lo em trechos por parágrafo ou assunto, resumir cada trecho e depois resumir os resultados combinados. Repetir resumos pode reduzir a precisão e aumentar a latência, então mantenha o briefing original disponível.

Vincule cada proposta ao rascunho atual

Uma resposta do Gemini pode chegar depois que alguém já editou o documento. Para evitar aplicar sugestões sobre uma versão antiga, vincule cada solicitação à identidade do rascunho e da sessão, à revisão salva e às versões locais do briefing e das edições. O coordenador descrito por Dandigam verifica se o resultado continua atual quando a geração termina e novamente no momento de aplicar; também impede a aplicação enquanto há edições locais pendentes.

Trate o retorno do modelo como uma proposta, não como uma atualização pronta. No adaptador analisado por Dandigam, a solicitação pede uma resposta JSON, mas a aplicação ainda faz o parsing e valida os campos. A resposta não substitui as verificações de formato, domínio e autorização da rota normal do backend.

Mostre as mudanças antes de salvar

Na interface, apresente os valores atuais junto dos propostos e deixe explícito quando uma sugestão apaga um campo. Assim, a pessoa pode conferir cada alteração e as perguntas de esclarecimento antes de aplicar o patch. Se o rascunho ou o briefing mudou durante a geração, descarte a proposta desatualizada e solicite outra com o contexto atual.

Teste o ciclo de vida, não só a resposta

Dandigam relata oito verificações controladas com um Summarizer falso para exercitar o ciclo de vida do adaptador. Entre os problemas que encontrou no adaptador candidato estavam uma rejeição de disponibilidade sem tratamento, a criação de sessão mesmo após um pedido já cancelado e a falta de encaminhamento do sinal de cancelamento para a chamada de criação.

Essas verificações não testaram o comportamento do modelo nativo, a qualidade dos resumos, o desempenho ou o conteúdo das solicitações de rede. Dandigam também informa que a extensão React não foi montada nem verificada com o TypeScript.