O Google Deixou de Usar a Janela de Contexto

As janelas de contexto de um milhão de tokens eram supostas ser o código de trapaça para modelos de linguagem de grande porte. Fornecedores correram para anunciar prompts de 128K, 200K, até 1M de tokens, como se a simples capacidade fosse desbloquear copilotos de codificação confiáveis, agentes autônomos e bases de conhecimento totalmente pesquisáveis. A realidade tem sido menos cinematográfica: mais tokens muitas vezes significam modelos mais lentos, mais caros e ainda confusos.

A mais recente pesquisa do Google sobre engenharia de contexto desmascara a situação. A empresa argumenta que "lançar mais tokens sobre o problema compra tempo, mas não muda a forma da curva" em termos de custo, latência e confiabilidade. Você pode superar brevemente a complexidade com uma janela de 1 milhão de tokens, mas cargas de trabalho reais—resultados RAG, logs de múltiplos agentes, saídas de ferramentas e histórico de usuários—se alcançarão rapidamente.

Três limites rígidos continuam a destruir a estratégia de “apenas enfiar o comando”. O primeiro é a espiral de custo e latência: cada 100K tokens extras eleva o tempo de inferência e as contas de nuvem, muitas vezes em 2 a 3 vezes em aplicativos de escala de produção. O segundo é “perdido no meio”, um efeito documentado onde modelos ignoram instruções cruciais enterradas em comandos sobrecarregados. O terceiro é a física: até janelas de um milhão de tokens transbordam uma vez que você começa a encadear ferramentas e agentes ao longo de horas ou dias.

A resposta do Google não é "2M tokens", mas sim uma mudança arquitetônica. Em vez de tratar o contexto como um enorme registro de chat mutável, a empresa o apresenta como uma visão compilada sobre um sistema mais rico e com estado. Dados brutos — sessões, memórias, artefatos — atuam como código-fonte; um pipeline de processadores compila um contexto de trabalho mínimo e específico para cada chamada de modelo.

Essa mudança transforma o contexto de um problema de buffer de força bruta em um problema de design de sistemas. O Kit de Desenvolvimento de Agentes (ADK) do Google incorpora isso em uma pilha de quatro camadas: contexto de trabalho, sessão, memória e artefatos, cada uma com responsabilidades e ciclos de vida definidos. O contexto deixa de ser “o que cabe na janela” e se torna um produto explícito de código, políticas e escopos.

Este artigo explora como essa estrutura realmente funciona em produção. Usando o Kit de Desenvolvimento de Agentes do Google (ADK), vamos analisar a arquitetura de contexto, os diferentes objetos de contexto e permissões, além de um agente de pesquisa de documentos real que demonstra por que a era dos milhões de tokens já terminou.

Janelas de contexto maiores prometem onisciência, mas na maioria das vezes entregam choque de preços. Cada 100.000 tokens extras acrescentam dólares reais e segundos, e as equipes de produção sentem ambos. O próprio blog de engenharia de contexto do Google descreve uma espiral de custo/latência: mais tokens por chamada, multiplicados por milhares de usuários simultâneos, transforma uma “demonstração agradável” em um “orçamento estourado” rapidamente.

A latência escala de maneira igualmente brutal. Esse prompt de um milhão de tokens significa uma decodificação mais lenta, cadeias de ferramentas mais longas e uma experiência do usuário que se afasta de “assistente” para “sistema de suporte”. Em configurações de múltiplos agentes, cada chamada de agente se ramifica em mais chamadas de modelo, então um contexto inchado infecta todo o pipeline.

Em seguida vem Perdido no Meio. Os LLMs não se concentram uniformemente em grandes prompts; eles frequentemente dão mais peso ao começo e ao final, e ignoram silenciosamente o centro. O blog do Google e trabalhos subsequentes mostram que a precisão cai quando fatos importantes ficam enterrados no meio de uma longa sequência, mesmo quando o modelo tecnicamente "vê" tudo.

Imagine um aviso de agente de produção após alguns minutos de uso. No topo: uma nova pergunta do usuário. Na parte inferior: um erro recente da ferramenta e uma instrução para tentar novamente. No meio: a real restrição da política ou a instrução crítica do sistema. O modelo otimiza alegremente nas bordas e alucina além do que realmente importa.

Cargas de trabalho reais agravam isso. Uma única interação pode incluir: - 20 a 50 trechos RAG - 5 a 10 registros de chamadas de ferramentas - Dezenas de mensagens de chat anteriores

Coloque tudo isso em um modelo "pronto para 1M tokens" e a janela de contexto ainda engasga após algumas interações ricas. Até as demonstrações do Google Agent Development Kit (ADK) mostram como rapidamente artefatos, memória e estado da sessão poderiam se descontrolar se você transmitisse ingênuamente tudo para o prompt.

Limites físicos rigorosos concluem o trabalho. A escala do comprimento do contexto cresce de forma sublinear com a computação e a memória; impulsionar de 128K para 1M de tokens já exige uma infraestrutura exótica. Aumente muito mais e você estará lutando contra a RAM da GPU, largura de banda e estabilidade de treinamento, não apenas com um design de prompt inteligente.

Esses não são curiosidades de laboratório. Eles são as razões pelas quais as equipes de produção silenciosamente limitam a história, reduzem os resultados de RAG e fazem resumos agressivos. Até que o contexto deixe de ser um fluxo bruto e se torne uma visão compilada, grandes agentes continuarão se afogando em seus próprios dados.

A nova ideia do compilador de contexto do Google desmantela o antigo modelo mental de uma janela de contexto como um log de chat sem fim. Em vez de um buffer de stream mutável, o contexto se torna uma visão compilada sobre um estado muito mais rico: sessões, memórias e artefatos que existem fora de qualquer prompt único. Cada chamada ao modelo vê apenas uma fatia cuidadosamente construída, e não todo o palheiro.

Pense como um engenheiro de compiladores, não como um ajustador de prompts. Os dados de interação brutos se tornam o código-fonte; um pipeline de processadores atua como o compilador; o prompt final enviado ao Gemini é o executável otimizado. O próprio blog do Google, Arquitetando uma estrutura multiagente eficiente e ciente do contexto para produção, deixa isso claro como um requisito indispensável para agentes em escala de produção, e não apenas uma abstração desejável.

Sob este modelo, o trabalho do desenvolvedor muda de “como eu formulo este prompt?” para “como eu arquiteturo o pipeline que constrói o contexto?” Você projeta como as sessões armazenam eventos estruturados, como as memórias codificam conhecimento de longo prazo e como artefatos como PDFs ou CSVs são referenciados por ID em vez de serem jogados na janela. Você para de curar manualmente mega-prompts e começa a definir fluxos, processadores e escopos.

O Google Agent Development Kit (ADK) incorpora isso em suas APIs. Ele expõe distintas camadas de contexto—contexto de trabalho, sessão, memória, artefatos—e exige que você as conecte por meio de processadores explícitos e prefixos de estado como `app`, `user` e `temp`. Essa separação entre armazenamento e apresentação significa que você pode registrar milhares de eventos enquanto ainda emite um prompt enxuto e direcionado com menos de 5.000 tokens.

O poder vem do escopo por padrão. Cada invocação de modelo recebe apenas o contexto mínimo necessário para sua tarefa, montado sob demanda pelo pipeline do compilador. Se um agente precisar de mais informações, ele chama ferramentas para buscar artefatos ou consultar a memória, em vez de pré-carregar tudo "apenas por precaução".

Essa abordagem de contexto compilado atinge os três pontos críticos de uma só vez. A contagem de tokens diminui, assim, os custos e a latência também caem. O "perdido no meio" encolhe porque o meio praticamente desaparece—histórias irrelevantes nunca entram no contexto de trabalho. Os limites de contexto físico deixam de ser um teto rígido e se tornam um orçamento de otimização que você controla com código.

A engenharia de contexto começa com uma quebra limpa entre onde a informação reside e como o modelo a percebe. O Kit de Desenvolvimento de Agente (ADK) do Google incorpora isso em seu primeiro princípio: separar armazenamento da apresentação. Isso pode parecer abstrato, mas é a diferença entre um sistema que você pode evoluir e um que colapsa sob sua própria transcrição.

A ADK traça uma linha clara entre a Sessão e o Contexto de Trabalho. A Sessão atua como o livro-razão persistente e autoritário: cada mensagem do usuário, invocação de ferramenta, resultado de ferramenta e evento do sistema é registrado aqui como um estado estruturado. O Contexto de Trabalho é uma instantânea descartável construída para uma única chamada de LLM, que é então descartada.

Pense na Sessão como seu banco de dados e no Contexto de Trabalho como o resultado de uma consulta SQL. Você nunca modifica o banco de dados para corresponder a cada consulta; você altera a consulta. A mesma ideia se aplica aqui: você mantém uma Sessão completa e apenas para adição e compila diferentes Contextos de Trabalho a partir dela, dependendo da tarefa, modelo ou orçamento de latência.

Essa separação se torna crítica no momento em que seu produto muda. Quer trocar o Gemini 3 Pro por um modelo menor ou mudar de um prompt em estilo de conversa para um prompt de execução de ferramenta mais conciso? Você atualiza os processadores que constroem o Contexto de Trabalho, não o esquema de Sessão ou os dados históricos. Interações passadas permanecem intactas, mesmo enquanto você muda radicalmente a forma como as apresenta ao modelo.

Os documentos do Google Agent Development Kit (ADK) formalizam isso com objetos de contexto distintos e prefixos de estado. O estado com suporte de sessão reside sob prefixos duráveis como `app` e `user`, enquanto dados efêmeros, que existem apenas durante a invocação, estão sob `temp`. Apenas o Contexto de Trabalho lê entre esses namespaces e compila uma visão mínima para a chamada atual.

O impacto prático aparece rapidamente em sistemas multiagente. Um agente pode ver um Contexto de Trabalho com apenas as últimas 3 interações do usuário e um resumo da ferramenta; outro pode receber um resumo sintetizado de uma Sessão de 200 mensagens mais resultados RAG. Ambos derivam do mesmo registro subjacente, mas cada chamada paga apenas pelos tokens que realmente necessita.

As janelas de contexto costumavam crescer por concatenação de strings: mensagem do usuário, resposta do agente, saída da ferramenta, repetindo até que a conta exploda. O Google Agent Development Kit (ADK) remove isso e o substitui por Transformações Explícitas: um pipeline nomeado e ordenado que compila o estado bruto em um prompt funcional. O contexto deixa de ser um bloco de texto e se torna um artefato de construção.

Em vez de `prompt = history + docs + tools`, você define processadores como `sumarizar_sessão`, `selecionar_artifícios_relevantes`, `injetar_instruções` e `orçar_tokens`. Cada etapa possui um nome, um contrato e um lugar na linha de produção. Você pode registrar cada estágio, comparar saídas entre execuções e trocar processadores sem afetar o restante do sistema.

O blog de contexto do Google e a documentação do ADK descrevem isso como um fluxo de processadores que transforma quatro camadas de estado: sessão, memória, artefatos e contexto de trabalho. Um agente de pesquisa de documentos, por exemplo, pode: - Recuperar decisões anteriores da memória - Classificar PDFs candidatos a partir de artefatos - Resumir citações em um resumo de 2.000 tokens - Emitir um prompt mínimo para o Gemini 3 Pro

Como os processadores são explícitos, as equipes podem testar unidades. Você pode afirmar que `select_relevant_artifacts` nunca busca mais de 5 documentos ou que `summarize_session` permanece abaixo de 1.000 tokens. A depuração deixa de ser “por que o modelo alucina?” e passa a ser “qual processador injetou os dados errados?”

Scoped by Default ataca a outra metade da confusão: quem vê o que. Em vez de despejar todo o transcrito multiagente em cada chamada de ferramenta, o ADK roteia contexto mínimo e específico de papel por meio de objetos de contexto tipados. Ferramentas, callbacks e provedores de instruções recebem cada um uma visão restrita.

As funções da ferramenta recebem um ToolContext que pode ler e escrever o estado da sessão, salvar ou carregar artefatos e buscar na memória. Os manipuladores de callback recebem um CallbackContext com estado e artefatos, mas sem busca na memória, prevenindo o caos de canais secundários. Os provedores de instruções veem um contexto somente leitura, de modo que não podem alterar secretamente o estado enquanto geram prompts do sistema.

Contexto delimitado transforma sistemas multi-agente em uma linha de montagem de IA. Uma etapa lê artefatos e produz um resumo estruturado; outra etapa, com um escopo mais restrito, transforma esse resumo em prosa voltada para o usuário; uma terceira etapa registra os resultados de volta na memória. Nenhum agente único carrega toda a história de 50.000 tokens.

Juntas, Transformações Explícitas e Escopadas por Padrão produzem fluxos de contexto que são previsíveis sob carga. Você sabe exatamente quais processadores são executados, qual estado eles podem acessar e quantos tokens eles emitem. Essa disciplina é o que torna um modelo de um milhão de tokens opcional em vez de obrigatório.

Agentes conscientes do contexto no Kit de Desenvolvimento de Agentes do Google (ADK) operam em uma pilha de quatro camadas que trata o contexto como um produto, não como um efeito colateral. Cada camada responde a uma pergunta diferente: o que o modelo vê agora, o que realmente aconteceu, o que deve persistir e onde os ativos pesados estão localizados.

No topo está o contexto de trabalho. Este é o conjunto temporário e restrito de dados que o ADK compila e envia ao Gemini para uma única chamada de modelo: mensagens selecionadas, saídas de ferramentas, trechos da memória e algumas referências a artefatos. O ADK descarta isso imediatamente após a invocação, portanto, nada no contexto de trabalho é autoritativo por si só.

Abaixo disso está a sessão, o registro canônico de longa duração de uma interação. Cada mensagem do usuário, resposta do modelo, chamada de ferramenta e resultado de ferramenta é registrada aqui como um objeto de evento estruturado, não como uma transcrição simples. Quando o ADK reconstrói um contexto de trabalho, ele consulta essa linha do tempo da sessão e aplica processadores que filtram, resumem ou reorganizam eventos para a tarefa atual.

O conhecimento de longa duração se transfere para a memória. A memória armazena preferências do usuário (tom, idiomas, hábitos de notificação), fatos duráveis (políticas da empresa, especificações de produtos) e decisões condensadas que devem sobreviver a qualquer conversa individual. O ADK revela isso por meio de APIs de pesquisa na memória, permitindo que um agente traga apenas os 3 a 10 itens que importam, em vez de reproduzir 10.000 tokens de histórico.

Artefatos resolvem o problema do “arquivo gigante no prompt”. Artefatos são objetos binários ou de texto grandes—PDFs, CSVs, imagens, arquivos de áudio—armazenados uma única vez e acessados por nomes ou IDs estáveis, não colados no prompt. Ferramentas leem e escrevem artefatos, e o contexto de trabalho carrega apenas referências leves e partes extraídas quando necessário.

Juntas, essas quatro camadas formam um pipeline de contexto, não um monólito. Um agente de pesquisa de documentos, por exemplo, poderia: ler a sessão para encontrar a última pergunta do usuário, pesquisar na memória por decisões anteriores, carregar um artefato em PDF por ID e, em seguida, compilar um contexto de trabalho com apenas alguns parágrafos e citações relevantes. O custo e a latência escalam com essa fatia compilada, não com o corpus bruto.

A própria orientação do Google incentiva as equipes a tratar essas camadas como superfícies de design de primeira classe. A Documentação do Contexto ADK detalha como contexto de trabalho, sessão, memória e artefatos se relacionam a tipos concretos, permissões e processadores, para que os sistemas multiagentes permaneçam rápidos, econômicos e estáveis à medida que as cargas de trabalho crescem.

O State faz com que uma IA se sinta persistente em vez de ter a mente de um peixe parede, e o Google Agent Development Kit (ADK) incorpora isso diretamente em sua API de contexto com um sistema de prefixos enganosamente simples. Em vez de entregar aos agentes uma massa amorfa de “memória”, o ADK divide o estado em namespaces temp:, user: e app: que se mapeiam de forma limpa para como o software real realmente opera.

Comece com temp:, o bloco de rascunho. Qualquer coisa que você escreva sob `temp:` vive por uma única invocação e depois desaparece. Uma ferramenta pode armazenar um CSV analisado sob `temp:parsed_doc`, outra ferramenta pode lê-lo 200 ms depois, e uma vez que o agente responde, o ADK o limpa—sem risco de poluir a história de longo prazo com lixo intermediário.

Suba um nível e user: se torna a verdadeira memória do agente sobre uma pessoa. Chaves como `user:nível_de_leitura`, `user:últimos_projetos` ou `user:fontes_bloqueadas` persistem entre as sessões, desde que você conecte o ADK a um armazenamento de suporte. Um assistente de pesquisa construído na demonstração pode lembrar quais artigos um usuário já resumiu na semana passada e evitar retornar ou reexplicar esses conteúdos.

No topo está app:, o estado global para toda a implantação. As bandeiras de recursos (`app:enable_vision`), limites de taxa em todo o sistema ou referências de índices de embeddings compartilhados estão todos aqui. Cada instância de agente e cada usuário podem ler esses valores, permitindo que você altere uma configuração uma vez e observe a mudança de comportamento em centenas de sessões concorrentes.

Juntos, esses três prefixos oferecem uma hierarquia de estado concreta sem a necessidade de inventar uma estrutura personalizada. Você obtém: - temp: para cabeamento por turnos entre ferramentas - user: para memória por identidade - app: para configuração entre usuários

Essa hierarquia codifica diretamente os princípios de design da ADK. Separar armazenamento da apresentação: o estado vive sob `temp:`, `user:` ou `app:`, enquanto o contexto de trabalho é uma fatia compilada dessas chaves. Transformações explícitas: ferramentas e processadores leem e escrevem prefixos específicos em vez de modificar um grande prompt. Escopado por padrão: `temp:` nunca vaza além de uma interação, `user:` nunca se torna acidentalmente global, e `app:` nunca se transforma silenciosamente em comportamento específico do usuário.

O Kit de Desenvolvimento de Agentes do Google (ADK) transforma toda essa teoria de contexto em um bot de pesquisa funcional. A demonstração do Yeyu Lab cria um assistente de documentos que pode pesquisar, abrir e analisar arquivos sem precisar inserir PDFs inteiros no prompt. Em vez disso, ele compila contexto suficiente para cada chamada do Gemini 1.5 ou Gemini 2.0.

O núcleo do design é um padrão de carregamento sob demanda. A ferramenta `list_documents` retorna apenas metadados leves: IDs de documentos, títulos, talvez tamanhos em bytes e timestamps. O modelo vê uma tabela compacta de opções, não 200 páginas de texto bruto.

Quando o usuário seleciona algo como “analisar o relatório trimestral”, o agente chama `analyze_document`. Essa ferramenta puxa o arquivo completo do armazenamento de artefatos, realiza a segmentação ou resumo e, somente então, apresenta os resultados destilados ao modelo. O LLM nunca recebe o documento original em linha; ele recebe apenas os trechos processados que solicitou.

As ferramentas se comunicam através do estado `temp:` em vez de arrastar cargas úteis pela rede. `list_documents` escreve `temp.current_doc_id = "report_q2_2024"`; `analyze_document` lê essa mesma chave e sabe exatamente qual artefato carregar. Sem blobs em base64, sem JSONs de 50.000 tokens pulando entre as ferramentas.

Esse escopo `temp:` vive por uma única invocação, o que mantém o contexto de trabalho minimal. Um turno típico pode incluir a solicitação do usuário, um breve prompt do sistema, uma lista de documentos compacta e uma string `current_doc_id`, mas ainda assim parecer um fluxo de trabalho rico e de múltiplas etapas. O Kit de Desenvolvimento de Agentes do Google (ADK) cuida da infraestrutura para que o modelo se concentre no raciocínio.

O comportamento a longo prazo depende do estado de `user:`. Quando alguém diz: “Eu prefiro resumos curtos”, uma ferramenta ou callback grava `user.summary_style = "curto"`. Chamadas futuras — amanhã, na próxima semana, em um dispositivo diferente — podem ler essa chave e produzir automaticamente resumos de 3 frases em vez de análises de 3 páginas.

As preferências podem se acumular sem sobrecarregar os prompts. Você pode rastrear: - `user.domain_focus = "finanças"` - `user.citation_format = "APA"` - `user.summary_style = "breve"`

Cada invocação compila apenas o subconjunto relevante no contexto de trabalho. Ninguém replays um registro de chat de 200 interações apenas para se lembrar de que o usuário odeia tópicos em bullet points.

A inteligência deste agente vem do uso eficiente de ferramentas, não de uma janela de contexto monstruosa. O modelo emite chamadas de ferramentas precisas, navega pelos estados `temp:` e `user:`, e acessa artefatos apenas quando necessário. O Google Agent Development Kit (ADK) efetivamente elimina a ideia de que é preciso reler todo o seu histórico a cada vez só para agir de forma inteligente.

A engenharia de prompts costumava significar feitiços inteligentes e gambiarras frágeis. A Engenharia de Contexto, conforme abordada no blog de contexto do Google e no Kit de Desenvolvimento de Agentes (ADK) do Google, eleva esse papel a algo mais próximo da arquitetura de sistemas distribuídos para modelos de linguagem.

Em vez de se obsessar com um único mega-prompt, os desenvolvedores agora desenham pipelines: como sessões, estado, memória e artefatos fluem através de processadores em um contexto de trabalho compilado. A pilha de quatro camadas da ADK—contexto de trabalho, log de sessão, memória de longo prazo e artefatos externos—transforma “o que está no prompt?” em “que sistema produziu esta visão e por quê?”.

Essa mudança marca uma clara maturação do desenvolvimento de IA. Você define: - Quais dados vivem onde - Quais transformações são executadas quando - Qual agente ou ferramenta vê qual escopo

Resultado: o comportamento deixa de parecer mágico e passa a parecer depurável.

A confiabilidade aumenta porque cada fatia de contexto tem uma receita explícita. Se um agente tiver uma alucinação, você inspeciona os processadores e prefixos que construíram sua visão, e não um bloco de 40.000 tokens. Os prefixos de estado do ADK (`app`, `user`, `temp`) e contextos delimitados (ferramenta, callback, invocação) oferecem alavancas para reproduzir bugs, escrever testes e raciocinar sobre modos de falha.

A previsibilidade melhora porque os agentes não consomem mais todo o histórico. Eles solicitam artefatos por ID, pesquisam na memória com consultas controladas e escrevem em segmentos de estado restritos. Os custos também diminuem: você transmite apenas o contexto compilado mínimo por chamada em vez de reproduzir semanas de registros em uma janela de um milhão de tokens.

Para equipes que visam a produção, isso se assemelha a um projeto para backends multi-agente. Um agente orquestra, agentes especialistas controlam ferramentas e memórias, e o framework de contexto da ADK garante que cada chamada veja apenas as informações necessárias. Os próprios documentos do Google, incluindo Introdução ao Contexto Conversacional: Sessão, Estado e Memória, leem menos como dicas de prompt e mais como um guia de design de API.

A Engenharia de Contexto, conforme implementada no Google Agent Development Kit (ADK), transforma aplicativos LLM em sistemas que você projeta, não em feitiços que você ajusta. Essa é a condição prévia para implantações sérias, regulamentadas e com múltiplos agentes.

Pronto para experimentar isso de verdade? Comece instalando o Kit de Desenvolvimento de Agentes do Google (ADK), obtendo uma chave de API do Gemini e lendo a explicação sobre engenharia de contexto no blog de Desenvolvedores do Google: Arquitetando uma estrutura multi-agente eficiente e consciente do contexto para produção. Esse post define a pilha de quatro camadas—contexto de trabalho, sessão, memória, artefatos—e os três princípios que seu código deve refletir.

Em seguida, vá direto para a documentação oficial do contexto ADK em google.github.io/adk-docs/context. Foque em como `InvocationContext`, `ToolContext` e `CallbackContext` controlam o acesso à sessão, memória e artefatos, e como os prefixos `app:`, `user:` e `temp:` implementam o estado escopado. Trate essas APIs como a fronteira do seu sistema, e não apenas como classes auxiliares.

Em seguida, baixe a demonstração do Yeyu Lab do GitHub: context_demo. Execute o assistente de documentos, observe como os artefatos são salvos e referenciados por ID em vez de serem incorporados nos prompts, e acompanhe como as ferramentas leem/escrevem o estado por meio de prefixos, em vez de ocultar dados em texto livre. Esta é sua implementação de referência para um fluxo de trabalho Consciente do Contexto com múltiplos agentes.

Para um primeiro projeto, refatore um aplicativo RAG existente para corresponder a este padrão. Substitua sua lógica de “enfiar tudo no prompt” por:

• 1Um registro de sessão de eventos estruturados
• 2Armazenamento de artefatos para PDFs, CSVs e documentos longos
• 3Busca na memória em vez de reenviar os mesmos fatos.
• 4Estado `temp:` para passar resultados intermediários entre ferramentas

Você não está apenas ajustando prompts; você está projetando sistemas distribuídos que se comunicam em linguagem natural. Desenvolvedores que internalizam o contexto como uma visão compilada—e que arquitetam em torno de estado, artefatos e transformações explícitas—serão aqueles que entregarão IA pronta para produção enquanto todos os outros continuam perseguindo uma janela de contexto maior.

O que é Engenharia de Contexto?

O Context Engineering é um novo padrão arquitetônico do Google para agentes de IA. Ele trata o contexto não como um único fluxo de texto, mas como uma 'visão compilada' criada a partir de várias fontes de dados, como histórico de sessão, memória e arquivos externos, otimizada para cada chamada específica de modelo.

Por que janelas de contexto grandes são um problema para agentes de IA?

Embora pareçam poderosos, grandes janelas de contexto levam a um espiral de altos custos e latência lenta. Elas também sofrem do problema de "perdido no meio", onde os modelos têm dificuldade em encontrar informações relevantes em um mar de ruído, limitando, em última análise, a escalabilidade e a confiabilidade.

Como o Kit de Desenvolvimento de Agentes (ADK) do Google implementa essas ideias?

ADK fornece uma estrutura com primitivas integradas para Engenharia de Contexto. Ela separa o armazenamento persistente (Sessão, Memória, Artefatos) do 'Contexto de Trabalho' temporário enviado ao LLM, utilizando ferramentas e gerenciamento de estado para carregar apenas o que é necessário, quando é necessário.

A Engenharia de Contexto substitui a Geração Aumentada por Recuperação (RAG)?

Isso complementa e refina. RAG se trata de recuperar dados; Engenharia de Contexto se refere a como esses dados recuperados (e todo o restante do contexto) são estruturados, gerenciados e apresentados ao modelo. Isso proporciona um sistema mais robusto e escalável para fluxos de trabalho no estilo RAG.