cerebro-vip INEMA.CLUB
início › INEMA.VIBE

Conteúdo educativo sobre Context Engineering para agentes de IA,…

INEMA.VIBE · 2026-01-10 · ~11 min · ver no Telegram ↗

INEMA

ali no faixa de Audio

voce vai na engrenagem

Diferencas entre Agentes e LLMs

🤖 LLM (Large Language Model)⌗

O que é: 👉 Um modelo que recebe texto → gera texto.

Características:⌗

  • Uma chamada → uma resposta
  • Não tem objetivo próprio
  • Não usa ferramentas sozinho
  • Não mantém estado real
  • Não decide próximos passos

Exemplo:⌗

Usuário → "Resuma este texto" LLM → "Resumo gerado"

Uso ideal:⌗

  • Classificação
  • Extração de dados
  • Resumo
  • Tradução
  • Geração de texto
  • Workflows simples

➡️ Mais previsível, barato e confiável

🧠 Agente de IA⌗

O que é: 👉 Um sistema que usa um LLM para agir, não só responder.

Características:⌗

  • Tem um objetivo
  • Decide o próximo passo
  • Usa ferramentas
  • Executa ações em loop
  • Lê resultados e continua
  • Pode falhar em silêncio 😅

Exemplo:⌗

```Objetivo: "Resolver este problema"

LLM:

  • → pensa
  • → chama ferramenta
  • → recebe resultado
  • → chama outra ferramenta
  • → decide finalizar```

Uso ideal:⌗

  • Exploração
  • Pesquisa aberta
  • Coding assistivo
  • Chat interativo
  • Quando há humano no loop

➡️ Mais flexível, mas menos previsível

🔑 Diferença central (como ele explica no vídeo)⌗

LLM Agente
Responde Decide
Uma chamada Múltiplas iterações
Sem ferramentas Usa ferramentas
Determinístico Não determinístico
Fácil de controlar Difícil de controlar

🚨 Erro comum (que ele critica)⌗

👉 Usar agente quando um LLM simples em workflow resolveria melhor.

“Nem tudo precisa ser um agente.”

🧩 Regra prática (do vídeo)⌗

Use LLM simples quando:⌗

  • Processo é conhecido
  • Fluxo é previsível
  • Backend / automação
  • Zero humano no loop

Use Agente quando:⌗

  • Problema é aberto
  • Exploração é necessária
  • Há humano no loop
  • Correção é possível

🎯 Frase que resume tudo⌗

LLMs respondem bem. Agentes agem — e por isso quebram mais.

dublada

youtube.com/watch ↗

Na prática, os pontos realmente importantes (aquilo que muda projeto de verdade) são estes 👇

Sem teoria, só o que você deve marcar como essencial:

✅ 1. O problema quase nunca é o modelo⌗

👉 É o contexto ruim

  • Informação demais
  • Informação errada
  • Informação desatualizada
  • Informação contraditória

✅ 2. Contexto é um recurso finito⌗

👉 Mais tokens ≠ melhor resultado

  • Trate contexto como orçamento
  • Sempre pergunte: isso é realmente necessário agora?

✅ 3. Prompt engineering sozinho não resolve⌗

👉 O erro está no sistema inteiro, não no texto do prompt

  • Histórico
  • Tools
  • RAG
  • Memória
  • Estado

✅ 4. Prompts quebram quando ficam grandes⌗

👉 Se o prompt está virando um “manual”:

  • você já perdeu controle
  • não escala
  • começa a ser ignorado pelo modelo

✅ 5. Exemplos positivos > regras negativas⌗

👉 Ele fala isso várias vezes de forma implícita e explícita:

  • “não faça isso” funciona mal
  • “faça assim” funciona muito melhor

✅ 6. Dividir o problema funciona melhor que um super-agente⌗

👉 Use:

  • routers
  • subagentes
  • prompt chaining
  • workflows

Menos contexto por vez = mais confiável.

✅ 7. Nem tudo precisa ser um agente⌗

👉 Ponto MUITO importante:

  • Workflows determinísticos > agentes livres
  • Especialmente para backend e automações
  • Agente só faz sentido quando há humano no loop

✅ 8. Histórico longo é um inimigo silencioso⌗

👉 Falhas aparecem no turno 10, 20…

  • Precisa resumir
  • Precisa podar
  • Precisa controlar

✅ 9. Estado vence histórico⌗

👉 Em fluxos (onboarding, avaliação, suporte):

  • salve estado fora do LLM
  • injete apenas o necessário
  • mude o prompt conforme a fase

✅ 10. Documentos grandes NUNCA entram direto⌗

👉 Sempre:

  • chunking
  • busca
  • reranking
  • poucos trechos finais

✅ 11. Tools também consomem contexto⌗

👉 Erro comum:

  • muitas tools
  • descrições longas
  • tools confusas

Menos tools, mais claras.

✅ 12. Trace tudo desde o início⌗

👉 Sem observabilidade você está cego

  • quando vê o contexto real, o erro aparece
  • quase sempre o LLM “está certo” dado o contexto ruim

✅ 13. Testar curto engana⌗

👉 O sistema precisa funcionar:

  • depois de 1 mensagem ✔
  • depois de 20 mensagens ✔✔✔

🎯 A FRASE-CHAVE DO VÍDEO⌗

AI agents fail because they reason over bad context, not because they are dumb.

🔥 HACKS DE CONTEXT ENGINEERING⌗

1) Context Budget Fixo⌗

  • Defina um limite de tokens por categoria:

  • system prompt

  • memória
  • documentos
  • tools
  • Nunca deixe uma parte “crescer sem dono”.

2) Prompt Curto + Exemplos⌗

  • Corte regras longas.
  • Use 2–3 exemplos positivos.
  • Se precisar de mais que isso → o problema é grande demais.

3) Troque “NÃO FAÇA” por “FAÇA ASSIM”⌗

  • ❌ “Não seja prolixo”
  • ✅ “Responda em até 5 bullets objetivos”

LLMs aprendem melhor por imitação, não por negação.

4) Router antes do Agente⌗

  • Um prompt pequeno decide:

  • qual fluxo seguir

  • qual subagente usar
  • Evita um “prompt monstro”.

5) Resumo Progressivo de Memória⌗

  • A cada N mensagens:

  • resume

  • substitui o histórico antigo
  • Nunca deixe o chat crescer indefinidamente.

6) Estado > Histórico⌗

  • Guarde o estado em banco (fase, passo, status).
  • Injete só o contexto daquela fase.
  • Histórico vira apoio, não fonte de verdade.

7) RAG em 2 Etapas⌗

  1. Busca ampla (30–50 chunks)
  2. Reranker → top 5–8
  3. Só esses entram no contexto

Menos tokens, mais sinal.

8) Tools Curta e Sem Sobreposição⌗

  • Se duas tools fazem quase a mesma coisa → erro.
  • Descrição longa = contexto poluído.
  • Melhor 3 tools claras do que 10 genéricas.

9) Subagente como Tool⌗

  • Em vez de muitas tools:

  • crie um subagente especialista

  • exponha ele como uma única tool

10) Trace First, Debug Later⌗

  • Sempre olhe o contexto real (trace completo).

  • 90% dos bugs ficam óbvios quando você vê:

  • prompt + histórico + tools + outputs

11) Teste Turno 20⌗

  • Se só testa 2–3 mensagens → está enganando a si mesmo.
  • Bugs reais aparecem em conversas longas.

12) Workflow antes de Agente⌗

  • Se o problema é previsível:

  • use workflow determinístico

  • Agentes livres só quando humano está no loop.

13) Prompt ≠ Código⌗

  • Não jogue feedback direto no prompt.

  • Primeiro:

  • entenda o erro

  • crie exemplo correto
  • Depois ajuste o prompt.

14) Contexto Velho é Veneno⌗

  • Informação desatualizada no contexto
  • Contradições entre mensagens
  • Instruções antigas esquecidas ➡️ pior que pouco contexto

15) Regra de Ouro⌗

Se você acha o contexto confuso, o modelo acha 10× pior.

Fluxo Prático que dá pra seguir. Em sequência, seria assim:

  1. Defina o objetivo do agente
  • Qual resultado você quer maximizar (tarefa, formato, critérios de sucesso).
  1. Mapeie tudo que pode virar contexto
  • System prompt, instruções, docs, ferramentas, outputs de tools, memória, histórico, estado etc.
  1. Trate contexto como recurso finito
  • Não “entupa” o modelo. Busque o menor conjunto de informação de alto sinal.
  1. Ajuste o system prompt com equilíbrio
  • Nem vago demais, nem “if/else” gigante.
  • Estruture em seções (markdown/XML): contexto, instruções, ferramentas, formato de saída.
  1. Troque “não faça X” por exemplos positivos
  • Em vez de listas de proibições, mostre como a resposta ideal deve ser (few-shot).
  1. Se o prompt começar a inflar, divida o problema
  • Use roteador + subprompts/subagentes (prompt chaining / workflows) ao invés de um “agente monolítico”.
  1. Documentos grandes: use RAG
  • Não coloque documento inteiro no contexto.
  • Recupera muitos trechos → reranking → envia só os melhores (top N).
  1. Ferramentas: reduza e simplifique
  • Poucas tools, descrições curtas, sem sobreposição/confusão.
  • Se ficar grande, crie subagente e exponha como uma tool.
  1. Memória/histórico: controle em produção

  • Quando o chat cresce, faça:

  • pruning (remover partes antigas) e/ou

  • sumarização (resumir e reinserir)
  • Isso evita falhar no “turn 10/20”.
  1. Use “estado” (state machine) quando existir um fluxo

  • Em vez de depender do histórico inteiro:

  • salva o estado (fase do usuário) no banco

  • injeta só o contexto daquela fase
  • muda instruções conforme o estado
  1. Instrumente com tracing (observabilidade)

  • Use uma ferramenta tipo Langfuse para ver:

  • o prompt completo + histórico + tool calls

  • Normalmente o erro fica óbvio olhando o trace.
  1. Teste em conversas longas
  • Não basta funcionar 1 vez.
  • Precisa funcionar no turno 10, 20… (onde o contexto acumulado quebra tudo).

1. Por que agentes de IA falham na prática⌗

  • Falham em produção, apesar de funcionarem bem em demos
  • O problema não é o modelo
  • O problema não são as ferramentas
  • O principal problema é context engineering mal feito

2. O que é Context Engineering⌗

  • Curadoria do conjunto ideal de tokens enviados ao LLM
  • Vai além de prompt engineering
  • Envolve tudo que entra no contexto durante a inferência

3. O que compõe o contexto de um agente⌗

  • System prompt
  • Instruções
  • Mensagem do usuário
  • Histórico de conversa
  • Documentos (RAG)
  • Conhecimento de domínio
  • Ferramentas (descrições)
  • Outputs de ferramentas
  • Memória de longo prazo
  • Estado da aplicação
  • Feedback do ambiente

4. Prompt Engineering vs Context Engineering⌗

  • Prompt engineering → foco em uma interação
  • Context engineering → foco no sistema inteiro ao longo do tempo
  • Context engineering é iterativo e contínuo

5. Contexto é um recurso finito⌗

  • Mais contexto ≠ melhor resultado
  • Performance degrada com excesso de tokens
  • Efeito “agulha no palheiro”
  • Tratar contexto como recurso escasso

6. Objetivo central do Context Engineering⌗

  • Encontrar o menor conjunto de tokens de alto sinal
  • Maximizar a chance do resultado desejado
  • Remover ruído, redundância e informação obsoleta

7. Problemas comuns em prompts⌗

  • Prompts longos e rígidos
  • Muitos “não faça isso”
  • Excesso de exceções e regras
  • If/else embutido em texto
  • Crescimento não escalável do prompt

8. Boas práticas de prompts⌗

  • Ser específico, mas não rígido
  • Deixar o modelo raciocinar
  • Usar exemplos positivos
  • Evitar exemplos negativos

  • Estrutura clara (markdown ou XML):

  • contexto

  • instruções
  • ferramentas
  • formato de saída

9. Dividir problemas grandes⌗

  • Não resolver tudo com um único agente
  • Criar subagentes
  • Usar roteadores
  • Prompt chaining
  • Workflows em vez de agentes únicos

10. Uso correto de agentes vs workflows⌗

  • Nem tudo precisa ser um agente

  • Workflows determinísticos são:

  • mais confiáveis

  • mais previsíveis

  • Agentes são úteis quando:

  • usam ferramentas em loop

  • há humano no loop
  • Backend e automações → evitar agentes livres

11. Gerenciamento de documentos (RAG)⌗

  • Não colocar documentos grandes direto no contexto
  • Usar chunking
  • Recuperar muitos trechos
  • Aplicar reranking
  • Enviar apenas os melhores chunks

12. Gerenciamento de ferramentas⌗

  • Não exagerar no número de tools
  • Evitar descrições longas
  • Evitar tools sobrepostas
  • Tools claras, curtas e específicas
  • Possível uso de subagentes como tools

13. Gerenciamento de memória e histórico⌗

  • Histórico cresce silenciosamente
  • Problemas aparecem em turnos longos (10+)

  • Técnicas:

  • pruning (remoção)

  • sumarização
  • compressão
  • Histórico grande = contexto ruim

14. Uso de estado (state machine)⌗

  • Não depender só do histórico
  • Guardar estado em banco de dados
  • Carregar apenas o contexto relevante
  • Usar prompts diferentes por etapa
  • Reduz drasticamente o contexto

15. Tracing e observabilidade⌗

  • Integrar tracing desde o início

  • Visualizar:

  • prompt completo

  • histórico real
  • tool calls
  • Ferramentas como Langfuse
  • Erros ficam óbvios quando o contexto é visível

16. Erro comum de engenheiros⌗

  • Ignorar dados reais de uso
  • Não analisar histórico completo
  • Ajustar prompt “no escuro”
  • Confiar demais no modelo
  • Pouca experiência com software não determinístico

17. Testar além do “funciona uma vez”⌗

  • Não basta funcionar no turno 1
  • Precisa funcionar no turno 10, 20, 30
  • Contexto acumulado muda o comportamento
  • Escala revela os problemas reais

18. Mensagem central do vídeo⌗

Agentes de IA não falham por falta de inteligência, mas por raciocinarem sobre contexto mal engenheirado.

Effective Context Engineering for AI Agents (por que agentes falham na prática):

  • Agentes de IA parecem impressionantes em demos, mas falham em produção principalmente por causa de context engineering mal feito, não por limitação do modelo ou das ferramentas.
  • Context engineering é o conjunto de estratégias para selecionar, organizar e manter o melhor conjunto de informações (tokens) que entram no modelo a cada inferência — indo muito além de prompt engineering.
  • Contexto inclui: instruções do sistema, documentos, ferramentas, outputs de ferramentas, memória, histórico de conversa, conhecimento de domínio e estado da aplicação.
  • Contexto é um recurso finito: quanto mais informação irrelevante ou excessiva, pior o desempenho (efeito “agulha no palheiro”).
  • O objetivo é sempre encontrar o menor conjunto de tokens de alto sinal que maximize o resultado desejado.

  • Muitos sistemas falham porque:

  • prompts ficam grandes, rígidos e cheios de exceções (“não faça isso”);

  • usam exemplos negativos, que LLMs lidam mal — exemplos positivos funcionam muito melhor;
  • acumulam histórico sem resumir ou podar;
  • usam agentes quando workflows simples e determinísticos seriam mais confiáveis.

  • Boas práticas:

  • Prompts claros, curtos e bem estruturados (markdown ou XML).

  • Preferir exemplos positivos ao invés de listas de proibições.
  • Dividir problemas grandes em subproblemas (roteadores, múltiplos prompts ou agentes especializados).
  • Usar RAG com chunking e reranking, em vez de inserir documentos grandes inteiros.
  • Limitar e simplificar descrições de ferramentas.
  • Gerenciar memória com resumos, pruning e controle de estado.
  • Integrar ferramentas de tracing (ex: Langfuse) para visualizar todo o contexto real em produção.

  • Nem todo problema precisa de um agente:

  • Workflows estruturados são mais confiáveis para automações e backend.

  • Agentes com loop de ferramentas funcionam melhor quando há humano no loop (ex: ChatGPT, Cursor).
  • O grande desafio é que erros de contexto só aparecem em interações longas (turn 10, 20…), algo que muitos engenheiros não testam.
  • Context engineering é criativo, iterativo e central para escalar IA de forma confiável em produtos reais.

👉 Em resumo: agentes não falham por falta de inteligência, mas por raciocinarem sobre contexto ruim.

Resumo (Prompt engineering vs. Context engineering):

  • Prompt engineering foca em escrever um bom prompt para uma única interação, usando basicamente o system prompt e a mensagem do usuário dentro da janela de contexto.

  • Context engineering é mais amplo e iterativo, especialmente para agentes. Envolve selecionar, organizar e atualizar continuamente tudo o que vai para o modelo: instruções, ferramentas, memória, conhecimento de domínio, histórico de mensagens e resultados de ferramentas.

  • A principal diferença é que o context engineering inclui uma fase de curadoria constante do contexto, enquanto o prompt engineering trata uma tarefa mais pontual e discreta.

Em resumo: prompt engineering é escrever melhor o pedido; context engineering é gerenciar inteligentemente todo o contexto que o modelo recebe ao longo do tempo.

Master de Engenharia de Contexto

chatgpt.com ↗

1

Recursos

↑ voltar ao topo · ver no Telegram ↗