Cortar histórico pode invalidar estados de cache e forçar recomputação. A otimização que falta costuma estar abaixo do prompt.
A intuição mais comum ao controlar custo de agentes é simples: mande menos texto. Resuma o histórico. Descarte respostas antigas de ferramentas. Mantenha só as últimas N rodadas. Em vários benchmarks isso até enxuga o payload. Em outros, a fatura sobe.
O paper Cache Engineering for Agents (Tsinghua e CUHK, arXiv 2610.28577, 20 out 2026) formaliza o mecanismo. Quando o sistema edita o prefixo do histórico — remove ou resume trechos anteriores —, estados de key-value (KV) cache já calculados para o que vinha depois deixam de ser válidos. Para continuar a trajetória, o motor precisa fazer re-prefill: processar de novo tokens que, no texto final, ainda estão presentes. Menos caracteres enviados não implica menos trabalho de atenção. Em um experimento diagnóstico com GPT-OSS-120B em tarefas do BrowseComp-Plus, uma política que mantinha só as doze rodadas mais recentes de ferramentas custou cerca de 1,85 vez o baseline de contexto completo. O agente não "escreveu mais"; o sistema reprocessou o que o cache tinha perdido.
Os autores propõem tratar o cache ativo como objeto de engenharia, não só o texto da trajetória. Operações como drop (excluir trechos selecionados da atenção futura sem reescrever o histórico lógico) e repos (ajustar encodings de posição do que permanece) permitem controlar o KV sem disparar re-prefill do que foi mantido. O serving co-desenhado (AKV) expõe interface compatível com APIs existentes e gerencia reuso, eviction e restauração por baixo. Nos experimentos reportados, uma política de rolling-drop em respostas de ferramenta melhorou a média dos scores em 1,7 ponto e reduziu o custo médio em 27,7% frente a sumarização disparada por limiar de tokens. Há ganho de throughput e de latência P95 no setup deles; política refinada por self-improvement cortou mais 7,1% de custo em relação ao desenho manual.
No mesmo período a AWS publicou padrões de prompt caching para agentes em Bedrock (26 out 2026). O ângulo é complementar: prefixos estáveis (instruções, definições de tools) marcados de forma explícita ou implícita deixam de ser reprocessados a cada turno, com redução de custo e latência de input quando o prefixo de fato reutiliza. A condição prática é a mesma do paper acadêmico sob outro nome — o que muda no meio do prompt quebra o reuso a partir dali. Timestamp, ID de sessão ou tool list reordenada no bloco "estável" invalida o que vinha depois.
Para quem opera agentes em produção, a leitura útil não é "sempre mantenha o contexto inteiro" nem "sempre resuma". É medir onde a edição do histórico está gerando re-prefill, e separar o que pode cair do cache sem reprocessar o restante. Políticas de drop seletivo em tool results, breakpoints de cache em instruções e tools, e observação de custo por turno (não só tokens enviados) passam a fazer parte do desenho. Em stacks que ainda só oferecem sumarização por limiar, o trade-off documentado no paper — texto menor, conta maior — continua no caminho crítico.
O texto do prompt é só uma camada. O custo mora no que o runtime recalcula quando essa camada mexe no prefixo.
Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.
Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada do contexto à governança de agentes consultando a série clicando na imagem abaixo:
- Cupom de 30% OFF:
LEIA30 - Disponível também no Kindle Unlimited
Referências
- Fu et al., Cache Engineering for Agents, arXiv:2610.28577 (20 out 2026) - Tsinghua / CUHK; AKV; rolling-drop vs. sumarização.
- AWS Machine Learning Blog, Groundhog Day for AI agents: Prompt caching patterns... on Amazon Bedrock (26 out 2026).
Tags
#EngenhariaDeSoftware #IA #AgentesDeCodigo #Cache #KVCache #PromptCaching #LLM #SoftwareEngineering #AI #CustoDeAgentes #Bedrock
Top comments (0)