Tutorial de edição em várias rodadas com Nano Banana 2.1: 3 elementos a reenviar para editar imagens em 2 rodadas consecutivas sem perder detalhes

Nota do autor: com um exemplo completo de “trocar a coroa por um chapéu vermelho e depois mudar o coração rosa para azul”, explicamos o que precisa ser reenviado a cada rodada de edição com o Nano Banana 2.1: o histórico da conversa, a imagem da rodada anterior e a assinatura de pensamento. Assim, é possível fazer ajustes pontuais sem perder o que já foi feito.

Muitos desenvolvedores se deparam com o mesmo problema na primeira vez que usam o gemini-nano-banana-2.1 para editar imagens: a primeira edição fica ótima, mas, ao tentar ajustar um pequeno detalhe na segunda rodada, a alteração anterior é “sobrescrita” ou o estilo da imagem inteira é recriado. Neste artigo, vamos mostrar como reenviar corretamente os dados em edições com várias rodadas no Nano Banana 2.1, para que você faça duas edições consecutivas sem perder detalhes.

Este não é mais um artigo só de conceitos. Vamos apresentar um caso reproduzível: na primeira rodada, trocamos a coroa na cabeça do personagem por um chapéu vermelho; na segunda, mudamos apenas o coração rosa para azul, preservando o chapéu vermelho. Você verá o código completo das duas requisições e entenderá quais dados precisam ser enviados em cada rodada.

O principal benefício: ao terminar de ler, você entenderá como funcionam as edições com várias rodadas no Nano Banana 2.1, saberá quais são os 3 elementos que precisam ser reenviados em cada requisição e poderá usar o código diretamente para fazer edições pontuais em sequência.

Principais pontos da edição em várias rodadas com Nano Banana 2.1

Vamos começar esclarecendo o conceito. O que se chama de edição “nativa em várias rodadas” do Nano Banana 2.1 é, falando com mais rigor, uma “edição contínua”: cada rodada é uma solicitação de API independente. O modelo só consegue “lembrar” o que foi alterado na rodada anterior porque você inclui todo o contexto novamente na solicitação — não porque o servidor mantenha a sessão salva.

Por que a edição em várias rodadas do Nano Banana 2.1 “perde detalhes”

O erro mais comum é enviar, na segunda rodada, apenas a frase “mude o coração rosa para azul” junto com a imagem original. Nesse caso, o modelo ainda vê a imagem original com a coroa e, naturalmente, mantém a coroa — o chapéu vermelho da primeira rodada desaparece. Outro erro é enviar apenas a imagem de saída da primeira rodada, sem o histórico. O modelo recebe a versão com o chapéu vermelho, mas não sabe que ele foi “alterado de propósito agora há pouco e precisa ser mantido”. Por isso, pode acabar mudando a cor ou o formato do chapéu ao fazer a segunda edição.

A maneira realmente confiável é enviar de volta a interação completa da primeira rodada como histórico da conversa: o que o usuário disse, qual imagem o modelo retornou e qual assinatura acompanhava a resposta. A documentação oficial do Google descreve da mesma forma as edições de imagem em várias rodadas: o modelo usa a assinatura presente no histórico para dar continuidade ao contexto de raciocínio e, assim, altera apenas a área indicada.

Estrutura da solicitação para edição em várias rodadas com Nano Banana 2.1

O campo contents da segunda solicitação é um array ordenado cronologicamente que deve conter pelo menos três partes: a mensagem user da primeira rodada (imagem original e instrução), a resposta model da primeira rodada (com a imagem de saída e a assinatura) e a nova instrução user da segunda rodada. O ponto principal é reproduzir a parte da resposta model “sem alterações”. Não extraia apenas a imagem em base64 para montá-la de novo, pois o campo de assinatura pode se perder durante a conversão.

Primeiros passos com a edição em várias rodadas do Nano Banana 2.1

A seguir, vamos chamar diretamente o formato nativo generateContent do Gemini usando Python e a biblioteca requests. Não usamos o formato de chat compatível com a OpenAI porque a edição em várias rodadas exige o reenvio da assinatura de pensamento e das partes da imagem. O formato nativo preserva esses campos o máximo possível em sua estrutura original.

Lista de preparação

Exemplo simples: na primeira rodada, troque a coroa por um chapéu vermelho

A primeira rodada é uma solicitação comum de edição de imagem: uma mensagem do usuário com a imagem original e a instrução. O mais importante é salvar o conteúdo completo retornado pelo modelo, pois ele será usado na próxima rodada.

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # Interface unificada da APIYI; consulte a documentação para saber o caminho no formato nativo
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "Troque a coroa na cabeça do personagem por um chapéu vermelho, mantendo todo o resto igual."}]}

resp = requests.post(URL, headers=HEADERS, json={
    "contents": [user1],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]}}).json()
model1 = resp["candidates"][0]["content"]  # Salve o objeto completo, incluindo a imagem e o thoughtSignature

O ponto mais importante está na última linha: model1 recebe diretamente o objeto completo de candidates[0].content, e não apenas os dados da imagem. As partes desse objeto podem incluir texto, imagem e o campo thoughtSignature. Salvando tudo sem alterações, você não corre o risco de deixar nada de fora.

Exemplo completo: na 2ª rodada, mude apenas o coração rosa para azul e mantenha o chapéu vermelho

O ponto principal da segunda rodada é montar contents assim: [user1, model1, user2]. O código completo abaixo inclui as duas chamadas, a verificação da assinatura e o salvamento das imagens. Você pode executá-lo diretamente.

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # 通过 APIYI 调用，原生格式路径以 docs.apiyi.com 为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
GEN_CONFIG = {"responseModalities": ["TEXT", "IMAGE"]}


def call(contents):
    """发送一次 generateContent 请求，返回 model 回复的完整 content 对象"""
    r = requests.post(URL, headers=HEADERS,
                      json={"contents": contents, "generationConfig": GEN_CONFIG},
                      timeout=180)
    r.raise_for_status()
    return r.json()["candidates"][0]["content"]


def save_image(content, path):
    """从 model 回复中取出图片并保存"""
    for part in content.get("parts", []):
        data = part.get("inlineData") or part.get("inline_data")
        if data:
            open(path, "wb").write(base64.b64decode(data["data"]))
            return True
    return False


def has_signature(content):
    """检查回复中是否带有思维签名"""
    return any("thoughtSignature" in p or "thought_signature" in p
               for p in content.get("parts", []))


# ---------- 第 1 轮：皇冠 → 红帽 ----------
img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

model1 = call([user1])
save_image(model1, "round1_red_hat.png")
print("第 1 轮签名存在:", has_signature(model1))

# ---------- 第 2 轮：粉心 → 蓝心，保留红帽 ----------
user2 = {"role": "user", "parts": [
    {"text": "在上一张图的基础上，只把胸前的粉色爱心改成蓝色。"
             "红色帽子和其他所有细节保持不变。"}]}

# 关键：完整历史 + 原样回传的 model1（含上一轮图片与签名）
history = [user1, model1, user2]
model2 = call(history)
save_image(model2, "round2_blue_heart.png")
print("第 2 轮签名存在:", has_signature(model2))

# 如需第 3 轮，继续追加：history += [model2, user3]

🚀 Comece rápido: recomendamos testar primeiro o código das duas rodadas no APIYI, em apiyi.com, usando os créditos de teste gratuitos. Confirme que o chapéu vermelho continua na imagem da segunda rodada e que apenas a cor do coração mudou. Depois, integre o fluxo ao seu próprio processo.

Dicas para escrever a instrução da segunda rodada

Para que a edição contínua altere “apenas uma parte”, não basta retornar a estrutura correta: a forma de escrever a instrução também faz diferença. Na segunda rodada, recomendamos deixar três pontos claros: qual imagem usar como base, o que alterar e o que deve permanecer igual. Por exemplo, “Com base na imagem anterior, mude apenas o coração rosa para azul e mantenha o chapéu vermelho e os outros detalhes como estão” tende a funcionar muito melhor do que simplesmente dizer “Mude para azul”.

Além disso, não anexe a imagem original novamente na segunda rodada. Ela já está em user1. Se você também a incluir em user2, o modelo pode interpretá-la como uma nova referência e acabar voltando à versão com coroa.

Comparação de três formas de enviar o histórico de edição em várias rodadas no Nano Banana 2.1

Para mostrar por que é essencial incluir os “três elementos”, vamos comparar três formas comuns de fazer isso. A tabela a seguir descreve, de forma qualitativa, o comportamento de cada uma para ajudar você a identificar rapidamente qual delas seu código está usando.

Entendendo a comparação

Análise da forma A: a vantagem da forma A é ser a mais simples de implementar: cada rodada é uma solicitação independente. Porém, o modelo não consegue ver o resultado da primeira rodada, então é como se a edição fosse refeita do zero em uma única rodada. Já o envio do histórico completo permite que a segunda rodada continue a edição a partir do resultado da primeira.

Análise da forma B: a forma B economiza no tamanho da solicitação, pois envia apenas uma imagem. Mas, sem o contexto de que “o chapéu vermelho foi alterado intencionalmente”, o modelo também não recebe a assinatura, o que deixa a consistência dos detalhes sem garantia. Para cenários que exigem refinamento contínuo, como layouts de design e imagens principais para e-commerce, a forma C continua sendo a opção mais confiável.

💡 Sugestão: se o seu negócio precisa de mais de duas rodadas consecutivas de edição, recomendamos adotar diretamente a forma C. Você pode executar as três formas com o mesmo código na APIYI apiyi.com e comparar as imagens geradas. A diferença fica bem evidente.

Como escolher entre o Nano Banana 2.1 e outros modelos da mesma série

A série Nano Banana disponível na APIYI tem vários modelos. A edição contínua é um uso mais avançado dos recursos de edição. A tabela abaixo ajuda você a escolher o modelo mais adequado da série.

Problemas comuns em edições em várias rodadas com o Nano Banana 2.1

Na prática, a maioria dos casos em que algo “se perde” pode ser atribuída a algumas causas recorrentes. A lista abaixo está organizada por frequência; confira cada item durante a investigação.

1. Assinatura perdida: depois de converter a resposta do modelo para uma estrutura de dados própria e montá-la novamente, os nomes dos campos podem mudar de maiúsculas e minúsculas ou de nível de aninhamento. Com isso, thoughtSignature não é enviado. Para evitar o problema, salve e envie de volta diretamente o objeto content original.
2. Papel incorreto: se a resposta do modelo da primeira rodada for marcada com o papel user, o modelo poderá interpretar a própria saída como uma nova imagem enviada pelo usuário. A resposta do modelo deve manter role: model.
3. Ordem invertida: contents precisa seguir a ordem cronológica: user1, model1, user2, nessa sequência. Não coloque a nova instrução no início.
4. Formatos misturados: se a primeira rodada usar o formato compatível com OpenAI e a seguinte mudar para o formato nativo, a conversão dos campos no meio do processo poderá descartar a assinatura. Recomendamos usar o formato nativo do Gemini em todo o fluxo de várias rodadas.
5. Histórico muito longo: quanto mais rodadas, mais imagens a solicitação carrega, aumentando o tamanho e o tempo de processamento. Em fluxos longos, com mais de duas ou três rodadas, considere usar o resultado atual como uma nova imagem original em um ponto-chave e começar um novo histórico.

🎯 Dica técnica: durante a investigação, você pode começar imprimindo a estrutura de parts de model1 e confirmar se o campo thoughtSignature está presente. Depois, confira se o corpo da solicitação da segunda rodada o inclui sem alterações. O centro de documentação da APIYI, em apiyi.com, traz exemplos de montagem no formato nativo do Gemini e de conversas em várias rodadas para ajudar na conferência.

Perguntas frequentes (FAQ)

Principais conclusões sobre a edição em várias rodadas com o Nano Banana 2.1

• Na prática, é uma edição contínua: cada rodada é uma solicitação independente, e o contexto é mantido pelo cliente ao enviá-lo de volta
• Os três elementos são indispensáveis: histórico completo da conversa, imagem gerada na rodada anterior e assinatura de pensamento
• Envie o conteúdo de model exatamente como foi recebido: salve candidates[0].content diretamente para evitar perder a assinatura
• Use o formato nativo: a estrutura contents de generateContent é a mais adequada para enviar imagens e assinaturas de volta
• Deixe claro o que deve ser preservado: na segunda rodada, especifique “o que mudar e o que manter”; isso torna as edições localizadas mais confiáveis
• Não anexe a imagem original novamente: incluí-la na segunda rodada pode fazer o modelo voltar à versão anterior à edição
• Valide sem gastar muito: use os créditos gratuitos da APIYI em apiyi.com para testar duas rodadas antes de colocar em produção

Resumo

Pontos principais da edição em várias rodadas com o Nano Banana 2.1:

1. Mecanismo: a chamada edição em várias rodadas é, na verdade, uma edição contínua baseada no envio do contexto pelo cliente. Ainda não foi verificado se o servidor mantém a memória automaticamente, então não dependa disso
2. Conteúdo a enviar de volta: a segunda solicitação precisa incluir user1, model1 exatamente como foi recebido (com a imagem e a assinatura de pensamento) e user2
3. Dicas práticas: use sempre o formato nativo do Gemini, especifique nas instruções o que deve ser preservado e não anexe a imagem original novamente na nova rodada

Com esses três pontos em mente, é possível reproduzir de forma consistente edições em duas rodadas, como “trocar a coroa por um chapéu vermelho e depois mudar o coração rosa para azul”. A mesma estrutura também pode ser ampliada para mais rodadas.

Para testar os resultados rapidamente, recomendamos usar a APIYI em apiyi.com. A plataforma oferece interfaces compatíveis com OpenAI e no formato nativo do Gemini. Com uma única chave API, você pode acessar a série Nano Banana e outros modelos populares. A cobrança é por uso, o que facilita começar com testes em pequena escala e, depois, integrar a solução à produção.

📚 Referências

1. Documentação da API Google Gemini para geração e edição de imagens: explicação oficial sobre edição de imagens em várias etapas
2. Link: ai.google.dev/gemini-api/docs/image-generation

3. Descrição: apresenta a estrutura das solicitações de edição de imagens e como fazer edições consecutivas em uma conversa

4. Documentação da API Google Gemini sobre assinaturas de pensamento: explicação do mecanismo de thought signature

5. Link: ai.google.dev/gemini-api/docs/thought-signatures

6. Descrição: explica a função das assinaturas e como enviá-las de volta em solicitações com várias etapas

7. Central de documentação da APIYI: guias de desenvolvimento da linha Nano Banana, implementação de conversas com várias etapas e chamadas no formato nativo do Gemini

8. Link: docs.apiyi.com
9. Descrição: reúne endpoints de integração, caminhos para usar o formato nativo e exemplos de montagem do histórico, servindo como referência para implementar o código deste artigo

Autor: equipe técnica da APIYI
Contato técnico: fale conosco pela página inicial do site da APIYI. Para mais materiais de integração da linha Nano Banana, acesse a central de documentação em docs.apiyi.com

Artigos relacionados

• Renderização de texto no Nano Banana 2 vs. 2.1: comparação prática de 5 conjuntos de pôsteres e lista de verificação para escolha do modelo: Todos dizem que o Nano Banana 2.1 renderiza melhor o texto; por que algumas pessoas acham que a versão 2 é mais precisa? Explique, com 5 cenários de pôster reproduzíveis, critérios de aceitação e preços por chamada, quando vale a pena mudar e quando não é necessário.
• O que o Nano Banana 2.1 melhorou? Análise das 6 principais melhorias e comparação de desempenho com o Nano Banana Pro: O Nano Banana 2.1 é uma versão aprimorada do Nano Banana 2 e já superou o Nano Banana Pro nas pontuações oficiais de benchmark, mas será que realmente vence na geração de imagens? Este artigo analisa 6 melhorias, dados de avaliações oficiais e de terceiros e recomendações para escolher entre o Nano Banana 2.1 e o Pro em diferentes cenários.
• Análise completa dos preços do Nano Banana 2.1: 5 diferenças principais em relação ao Nano Banana 2 e cálculo de economia: Análise dos preços do Nano Banana 2.1 com base na página oficial de preços do Google: o custo unitário das imagens geradas cai pela metade, mas os tokens de entrada e de raciocínio ficam mais caros, o consumo em 4K aumenta e a opção de 0,5K é removida; inclui custos por imagem em 1K/2K/4K, preços Batch, ponto de equilíbrio e recomendações de migração.
• Uma única imagem enganou 3 milhões de pessoas? Tutorial em 2 passos para criar imagens de viagem satíricas em estilo pseudodocumental com IA usando o GPT Image 2.5: Desconstrua o vídeo satírico de Wytse Koetse sobre Paris: primeiro, use o GPT para escrever comandos estruturados e, em seguida, use o gpt-image-2.5-sunburst ou o gemini-nano-banana-2.1 para criar em lote imagens estáticas pseudodocumentais com um tom de “anúncio turístico falso”.