Explicação
Engenharia de contexto para agentes de IA: um framework prático de confiabilidade
Engenharia de contexto para agentes de IA é a prática de decidir quais informações, instruções, ferramentas, estado e memória um agente recebe em cada etapa de uma tarefa. O objetivo não é preencher a maior janela de contexto possível, mas fornecer o menor conjunto suficiente de sinais para que o modelo escolha a próxima ação correta e produza um resultado verificável.
Este guia é para equipes que projetam ou avaliam agentes que pesquisam, analisam arquivos, usam ferramentas e criam entregáveis em várias etapas. Ele diferencia engenharia de prompts e de contexto, apresenta um framework prático de seleção e inclui um briefing reutilizável para testar um workflow real.
Pesquisa e transparência: A Ottermind publica este explicador. Em 28 de agosto de 2026, revisamos orientações primárias da Anthropic, da LangChain e do OpenAI Agents SDK, além do artigo de pesquisa Lost in the Middle. As cinco camadas de contexto, o Context Selection Loop, o exemplo e os modelos abaixo são frameworks editoriais originais, não benchmarks medidos da Ottermind.
Por que a engenharia de contexto importa para agentes de IA
Uma chamada única ao modelo tem uma entrada relativamente estável. Um agente pesquisa, lê arquivos, chama ferramentas, observa resultados, revisa o plano e continua por várias rodadas. Cada etapa cria mais contexto candidato para a próxima.
Esse conjunto pode conter evidências úteis, mas também planos antigos, saídas duplicadas, tentativas que falharam, instruções conflitantes e histórico irrelevante. Repassar tudo aumenta custo e latência, esconde evidências importantes e pode manter uma suposição desatualizada. A pesquisa Lost in the Middle mostra que modelos podem ter pior desempenho quando a informação relevante fica no meio de uma entrada longa.
A pergunta de engenharia não é “quanto o modelo consegue ler?”, mas: o que o agente precisa saber para a próxima decisão, qual é a fonte e o que deve ficar fora da janela?
Engenharia de contexto vs. engenharia de prompts
| Disciplina | Pergunta principal | Escopo típico | Quando muda |
|---|---|---|---|
| Engenharia de prompts | Como expressar a tarefa e o comportamento? | Instruções, exemplos, papel e formato | Quando a tarefa muda |
| Engenharia de contexto | O que o modelo deve ver nesta etapa? | Instruções, evidências, mensagens, ferramentas, estado, memória e permissões | Antes e entre chamadas |
Um prompt pode pedir um memorando de mercado com fontes. A engenharia de contexto decide quais documentos, entrevistas, resultados de busca, decisões anteriores e critérios de aceite ficam visíveis durante o planejamento, a pesquisa e a redação.
Para estruturar objetivo, materiais, restrições e critérios, consulte o guia de prompts da Ottermind. A engenharia de contexto começa quando esse briefing entra em um workflow dinâmico.
As cinco camadas do contexto de um agente
| Camada | Contém | Exemplo | Risco |
|---|---|---|---|
| Comportamental | Políticas, limites e orientações de ferramentas | Citar alegações e não publicar sem aprovação | Regras vagas ou conflitantes |
| Tarefa | Objetivo, público, entregável e definição de pronto | Criar um memorando de cinco páginas | Atividade sem condição de parada |
| Evidência | Arquivos, trechos, registros e metadados | Documentos atuais e entrevistas datadas | Fonte antiga ou sem rastreabilidade |
| Operacional | Ferramentas, esquemas, permissões e resultados | Buscar é permitido; escrever no CRM exige aprovação | Excesso de ferramentas ou acesso |
| Continuidade | Plano, decisões, estado, resumos e memória | A opção B foi aprovada | Estado antigo tratado como fato |
Nem tudo precisa ser enviado ao modelo. O OpenAI Agents SDK diferencia contexto local da aplicação e contexto visível ao LLM. IDs, conexões e segredos podem ficar no estado da aplicação, enquanto o modelo recebe apenas o necessário para a decisão atual.
Context Selection Loop
O Context Selection Loop é um framework editorial da Ottermind para decidir o que o agente deve ver antes de cada etapa importante.
1. Nomeie a próxima decisão
Defina a decisão imediata: quais fontes são confiáveis, se a evidência basta, qual ferramenta extrai os campos ou se o rascunho atende aos critérios. Se uma informação não pode mudar essa decisão, ela provavelmente não pertence à próxima chamada.
2. Reúna candidatos por camada
Liste instruções, requisitos, evidências, ferramentas e estado. Preserve origem, data e autoridade. Recuperar vinte páginas não significa que todas devem entrar no contexto.
3. Filtre com cinco testes
Verifique relevância, autoridade, atualidade, consistência e permissão. Uma informação pode ser útil, mas ainda assim vir de uma fonte fraca ou não poder ser exposta ao modelo.
4. Modele o contexto selecionado
Coloque objetivo e restrições em destaque, separe evidência de instruções, remova duplicatas, compacte históricos preservando decisões e fontes, use campos estruturados e isole subtarefas que distraiam o agente principal.
5. Observe e atualize
Depois de cada ação, registre o que mudou, quais fatos ou conflitos surgiram, o que deve ser descartado, o que vira memória e qual é a próxima decisão. Context engineering é um processo de controle contínuo.
Exemplo: de arquivos de pesquisa a um memorando de decisão
Uma equipe entrega seis páginas de produtos, três entrevistas, um deck antigo, uma planilha de pedidos e notas de roadmap. Em vez de enviar tudo de uma vez, o agente cria um contrato e mapa de fontes, extrai apenas evidências atuais, compara opções, redige a partir da decisão aprovada e valida o resultado contra os critérios.
| Etapa | Decisão | Contexto selecionado | Saída visível |
|---|---|---|---|
| Entrada | Qual é o entregável e a fonte de verdade? | Pedido, público, prazo, critérios e inventário | Contrato e mapa de fontes |
| Evidência | Quais alegações têm suporte? | Trechos atuais e decisões do roadmap | Tabela de alegações |
| Análise | Quais opções permanecem? | Evidências aprovadas e método de pontuação | Opções e incertezas |
| Redação | Como comunicar? | Opção escolhida, fontes e formato | Rascunho com fontes |
| Revisão | Está pronto? | Rascunho, critérios e riscos | Relatório de validação |
O exemplo é ilustrativo, não uma prova de que um modelo sempre terá melhor desempenho. Um teste real deve registrar precisão, intervenções, latência, custo e aceitação.
Boas práticas
Comece com o menor contexto suficiente. Mantenha fatos, instruções e estado separados. Preserve fontes e incertezas ao resumir. Dê às ferramentas contratos pequenos e resultados previsíveis. Guarde decisões úteis e corrigíveis, não cada token. Ao testar uma mudança, mantenha a tarefa e os critérios constantes e compare sucesso, rastreabilidade, chamadas, intervenções, custo e segurança.
Falhas comuns
- Despejo de contexto: envie apenas o que serve à próxima decisão.
- Compressão precoce: preserve evidências e conflitos até o momento certo.
- Memória obsoleta: use datas e deixe evidência atual substituir memória antiga.
- Excesso de ferramentas: exponha apenas ferramentas relevantes para a etapa.
- Estado invisível: registre mudanças e a evidência que as justificou.
- Sem definição de pronto: declare entregável, público, critérios e parada.
Modelo reutilizável de engenharia de contexto
Tarefa e próxima decisão:
Conclua [tarefa]. A decisão atual é [decisão].
Definição de pronto:
- Entregável: [artefato ou ação]
- Público: [pessoa ou equipe]
- Evidências: [fontes ou campos]
- Critérios: [qualidade e formato]
- Pare ou escale quando: [risco ou limite de autoridade]
Contexto comportamental:
- Siga [políticas e prioridades de fontes].
- Não [invente, envie, publique, compre, exclua ou altere registros] sem aprovação.
Contexto de evidências:
- Use [arquivos, trechos, registros ou links selecionados].
- Preserve citações e sinalize conflitos.
Contexto operacional:
- Ferramentas: [conjunto pequeno e relevante].
- Permissões: [ler, redigir, escrever, aprovar].
Contexto de continuidade:
- Estado atual: [etapas concluídas e plano].
- Decisões aprovadas: [registro].
- Perguntas abertas: [lacunas].
Depois da etapa, retorne resultado, fontes, hipóteses, falhas, mudanças de estado e próxima decisão.Como avaliar a qualidade do contexto
Avalie sucesso da tarefa, rastreabilidade das alegações, eficiência das ferramentas, taxa de intervenção, quantidade de contexto visível, continuidade entre etapas e respeito às permissões. O objetivo é o menor contexto que produz comportamento confiável, não o menor número de tokens a qualquer custo.
Comece com uma tarefa delimitada
Escolha um workflow real, como converter fontes em memorando, briefing, relatório ou apresentação. Defina critérios, aplique o Context Selection Loop e compare com uma linha de base baseada apenas em prompt. Para o modelo de execução, leia O que é um Agentic Workflow?. Para a categoria de produto, veja melhores workspaces de agentes de IA. Para pesquisa, consulte o guia de assistentes de pesquisa de IA.
No Ottermind, reúna arquivos, links, restrições e o entregável em um workspace. Peça primeiro o mapa de fontes e o plano, revise a direção e então continue até o resultado final.
