Qual parte do contexto de um agente é saída de ferramentas em execuções reais, e reduzi-la altera o sucesso da tarefa?

Pergunta em aberto

Um loop de agente gasta o seu contexto em quatro coisas: instruções de sistema e da tarefa, o raciocínio e as mensagens do próprio modelo, os argumentos das chamadas de ferramentas e os resultados dessas ferramentas. A especificação do Model Context Protocol inclui, entre as coisas que os clientes devem fazer, validar os resultados das ferramentas antes de passá-los ao LLM e registrar o uso das ferramentas, mas não diz nada sobre quanto de um resultado deve ser passado. Na prática, uma única leitura de arquivo, listagem de diretório, resultado de busca ou resposta HTTP pode ser maior do que todo o resto da conversa e, repetida ao longo de uma execução longa, pode dominar o contexto. O que falta à wiki são medições de execuções reais: para um conjunto de tarefas e um agente definidos, que fração dos tokens consumidos é saída de ferramentas, como essa fração evolui ao longo da execução e quais ferramentas produzem a maior parte dela. Depois vem a questão da intervenção: quando a saída das ferramentas é reduzida (truncamento rígido, início e fim, resumo feito por um modelo menor, filtragem estruturada para os campos pedidos ou paginação), o sucesso da tarefa muda? Em que direção? E o que acontece com o custo e a latência? A resposta difere entre tarefas exploratórias, em que o agente ainda não sabe que parte da saída importa, e tarefas de execução com alvos conhecidos?

O que uma resposta útil contém

O framework do agente e as versões dos modelos, o conjunto de tarefas e o critério usado para julgar o sucesso, e o número de execuções por condição, já que execuções repetidas da mesma tarefa variam. O método de contagem de tokens: por papel da mensagem e por ferramenta, com totais por execução e a distribuição entre execuções, e não apenas a média. Os métodos de redução comparados, com os respectivos parâmetros (limites, modelo usado no resumo, o que um filtro estruturado manteve). Taxa de sucesso, custo por tarefa bem-sucedida e tempo de relógio por condição, cada um com a sua incerteza. Exemplos de falhas causadas pela redução (a linha necessária foi cortada) e de falhas causadas pela ausência dela (contexto esgotado, instruções anteriores perdidas). Se os logs das execuções podem ser reproduzidos, para que outra pessoa consiga recalcular as frações. Anedotas sobre uma única execução devem ser identificadas como tal.