Deep Agents v0.7 reduz tokens por turno em 65%

O Deep Agents v0.7 reduz em 65% os tokens básicos de entrada por turno. Isso significa menos sobrecarga fixa de prompt em cada chamada, menor gasto com API e mais espaço de contexto para as partes realmente importantes da tarefa.

Em resumo, a atualização faz o seguinte:

• Remove o prompt básico de sistema padrão
• Encurta as descrições das ferramentas integradas
• Deixa de anexar tarefas por padrão
• Permite escolher o middleware de forma intencional, em vez de incluí-lo em bloco
• Gera economia pelo harness, não pelo modelo

Em termos simples, se um agente fizer 10 chamadas, o mesmo invólucro fixo antes era enviado 10 vezes. No v0.7, esse invólucro é muito menor por padrão. Cada turno passa a produzir uma solicitação mais leve, especialmente em tarefas simples, como ler ou gravar arquivos.

Alguns pontos se destacam:

• O custo cresce de acordo com llm_calls × input_tokens_per_call
• A configuração antiga enviava textos de planejamento, sistema de arquivos e subagentes mesmo quando a tarefa não precisava deles
• A nova configuração transfere o controle para o desenvolvedor, que escolhe o prompt, as ferramentas e o middleware adequados
• As maiores reduções vêm da remoção do prompt básico e do encurtamento do texto das ferramentas
• Fluxos longos e com vários agentes ganham mais, pois a sobrecarga fixa se repete em cada etapa

Veja uma comparação simples:

Minha conclusão: o v0.7 trata menos de mudanças no modelo e mais de disciplina nos prompts. Se eu mantiver o harness leve, preservo todo o ganho de 65%. Se voltar a adicionar muitos middlewares e ferramentas, perco parte desse benefício.

Esse é o núcleo da atualização e a base para o restante do artigo.

O que mudou no harness configurável

O corte de 65% nos tokens veio da mudança no conteúdo que o harness injeta em cada turno, não do uso de um modelo mais inteligente. Em resumo, o v0.7 remove grande parte do texto padrão que acompanhava todas as solicitações.

Remoção do prompt básico de sistema e redução das descrições de ferramentas

Antes do v0.7, o harness colocava um prompt de sistema padrão, descrições longas de ferramentas, middleware de planejamento e lógica de subagentes em todas as solicitações, mesmo quando a tarefa não precisava desses elementos. O v0.7 torna o harness configurável para que os desenvolvedores decidam o que será injetado em cada turno.

As maiores fontes de sobrecarga eram o prompt básico de sistema padrão e as longas descrições das ferramentas integradas. O prompt básico incluía instruções para ferramentas de planejamento, sistema de arquivos e subagentes e era enviado em todos os turnos. No v0.7, esse prompt foi removido. Agora os desenvolvedores podem fornecer um texto adequado à tarefa.

As descrições integradas de utilitários como ls, read_file e write_file também ficaram menores. O funcionamento das ferramentas não mudou. Há apenas menos texto fixo ao redor de cada solicitação. Nenhuma das mudanças afeta o modelo subjacente; elas simplesmente reduzem a carga de tokens transportada em cada turno.

Tarefas opcionais e middleware explicitamente selecionável

Antes do v0.7, o todoListMiddleware era anexado por padrão, então o texto de planejamento era enviado em todos os turnos. No v0.7, as tarefas são opcionais. Você só as adiciona quando um planejamento de várias etapas melhora o trabalho.

A mesma mudança se aplica ao restante da pilha de middleware. FilesystemMiddleware e SubAgentMiddleware não são mais incluídos em bloco por padrão. Os desenvolvedores podem compor apenas os middlewares necessários. Uma tarefa de leitura de arquivos pode ignorar a lógica de subagentes. Um fluxo de verificação pode adicionar um middleware de checklist somente quando ele for útil.

Como a orquestração se torna mais explícita

A mudança prática é simples: a configuração passa de padrões implícitos para uma composição explícita. Em vez de deixar o harness decidir quais ferramentas ficam visíveis, qual middleware será executado e o que o prompt de sistema diz, os desenvolvedores tomam essas decisões. Agora eles controlam a montagem do prompt, a visibilidade das ferramentas e o middleware de cada tarefa.

Essas mudanças aparecem na pilha de agente padrão abaixo. ^[2]

Uso de tokens antes e depois

As mudanças no harness aparecem imediatamente na carga enviada em cada turno. A economia vem da redução do invólucro fixo da solicitação, não de uma alteração no prompt do usuário ou no modelo.

Turno do agente padrão antes do v0.7

Antes do v0.7, cada turno incluía estruturas de planejamento, sistema de arquivos e subagentes mesmo quando nenhuma delas era usada. Textos de tarefas e prompts de middleware também eram incluídos por padrão. Com isso, uma grande carga fixa se repetia em todos os turnos.

Turno do agente padrão depois do v0.7

Depois do v0.7, uma tarefa simples de leitura de arquivo envia apenas as ferramentas e os middlewares de que precisa. Assim, a sobrecarga adicional deixa de se repetir entre os turnos. O prompt básico de sistema é removido, as descrições das ferramentas ficam menores e uma tarefa de leitura não carrega textos de planejamento ou subagentes sem uso.

Como observa Aaron Jewitt, o custo do agente cresce de acordo com llm_calls × input_tokens_per_call.^[1]

De onde vem a economia de tokens

Veja a origem da redução de 65%.

As maiores economias vêm da remoção do prompt básico e da redução das descrições das ferramentas. Por isso, um middleware seletivo e uma visibilidade menor das ferramentas fazem uma diferença tão clara nos fluxos diários.

A próxima seção mostra como os desenvolvedores preservam esses ganhos escolhendo apenas os elementos do harness necessários para cada tarefa.

Padrões de configuração do harness para desenvolvedores

Depois de garantir a economia de tokens, o próximo passo é escolher um perfil leve de harness para cada tarefa. Os ganhos vêm de prompts menores e padrões mais enxutos. No Deep Agents v0.7, o harness — e não o modelo — responde pela maior parte da sobrecarga de tokens por turno. Isso significa que a otimização no Deep Agents v0.7 depende menos da escolha do modelo e mais da forma como o harness é montado.

Escolha apenas o middleware necessário para a tarefa

Use middleware apenas quando a tarefa exigir controle, planejamento ou gerenciamento de estado. Em tarefas curtas, essas camadas adicionais só aumentam a sobrecarga.

A regra é simples: comece com a menor pilha de middleware necessária para a tarefa. O mesmo vale para as ferramentas. Exponha apenas aquelas de que o trabalho atual realmente precisa.

Limite a visibilidade das ferramentas e reduza as descrições

Mostrar todas as ferramentas em todos os turnos é uma das maneiras mais rápidas de aumentar a entrada. Limitar a visibilidade ajuda a manter o prompt pequeno.

Descrições menores reduzem ainda mais o tamanho do prompt. Textos curtos e precisos também facilitam a escolha da ferramenta correta pelo modelo sem exigir muito contexto adicional.

Use tarefas opcionais e padrões baseados em perfis

O gerenciamento de tarefas ajuda em trabalhos de longo prazo nos quais o agente precisa acompanhar o progresso por muitas etapas. Em uma tarefa curta e única, ele adiciona sobrecarga sem retorno.

Torne as tarefas opcionais em trabalhos longos e defina padrões leves ou completos por classe de agente. Padrões leves preservam o ganho de 65% em agentes simples, enquanto perfis mais completos ficam reservados para fluxos que exigem muito planejamento.

Essas escolhas determinam se a redução de 65% se transforma em menor custo e iterações mais rápidas no uso diário.

O que a atualização v0.7 significa para custo, velocidade e escala

Menores custos de inferência e ciclos de iteração mais rápidos

O invólucro menor da solicitação acumula benefícios em todos os turnos de um fluxo longo. Os custos de tokens aumentam em execuções com várias interações, portanto um harness leve não economiza apenas no primeiro turno. Ele mantém um ponto de partida menor em todos os turnos seguintes, e a diferença aumenta à medida que a conversa cresce.

Na prática, a redução aparece aqui:

Cargas menores também aceleram as iterações. Se você estiver testando uma mudança no prompt ou uma nova configuração de ferramentas, as solicitações leves retornam mais rápido. Isso elimina boa parte da lentidão no desenvolvimento diário.

Melhor escalabilidade para fluxos longos e com vários agentes

As mesmas economias ficam ainda mais importantes quando vários agentes compartilham o orçamento de um fluxo. A sobrecarga fixa consome silenciosamente os recursos de sistemas multiagente. Se cada agente transporta um harness grande demais, essa carga se multiplica em todos os turnos coordenados.

Um harness mais leve reduz a ocupação de cada agente. Isso melhora a vazão e diminui a probabilidade de atingir limites de contexto ou de requisições no meio de um fluxo.

À medida que as janelas de contexto se enchem, o desempenho pode cair. Um harness leve deixa mais espaço utilizável para os dados reais da tarefa. Em termos simples, fluxos longos conseguem manter a precisão por mais tempo sem que mecanismos de compactação ou resumo precisem agir cedo demais.

A menor sobrecarga por chamada importa mais em fluxos com muitos turnos, muitos agentes ou ambos. O corte de 65% nos tokens reduz o custo de cada chamada. Porém, o maior benefício em escala vem do modelo explícito de orquestração do v0.7. Com critérios claros de parada em vez de loops abertos, os agentes fazem menos chamadas no total para concluir uma tarefa.

Principais conclusões da versão Deep Agents v0.7

O Deep Agents v0.7 melhora o custo e a qualidade ao tornar o harness configurável. A seleção de middleware, a visibilidade das ferramentas e os padrões baseados em perfis determinam se um fluxo preserva toda a economia ou perde grande parte dela por causa de uma sobrecarga adicional.

A configuração é a principal alavanca de otimização. E ela importa mais em fluxos com muitos turnos, muitos agentes ou ambos.

Perguntas frequentes

Como manter toda a economia de 65% dos tokens em fluxos reais?

Trate a configuração do harness como um sistema vivo, não como uma tarefa feita uma única vez. Comece medindo o uso de tokens e a quantidade de chamadas ao LLM. Depois, use o harness para impor regras estritas de comportamento.

Use o PreCompletionChecklistMiddleware para interromper ciclos redundantes de raciocínio. Use o LocalContextMiddleware para fornecer apenas o contexto e as ferramentas necessárias ao modelo. Adicione cache de prompts para manter as instruções de sistema estáveis entre as execuções.

Quando o uso de tokens aumentar, observe possíveis desvios e restrinja as regras do harness.

Quais tarefas ainda devem usar listas ou middleware adicional?

Use o todoListMiddleware quando o agente estiver trabalhando em um problema complexo e composto por várias partes. Ele ajuda o agente a acompanhar o que já foi concluído e o que ainda precisa de atenção.

Ao solicitar o uso da ferramenta write_todos, o agente pode atualizar o progresso conforme novas informações aparecem. Isso facilita o acompanhamento de fluxos longos e difíceis e ajuda o agente a permanecer no caminho correto.

Um harness menor afeta a qualidade ou a confiabilidade do agente?

Não por padrão. Um harness menor e bem ajustado pode manter ou até melhorar a confiabilidade ao reduzir os tokens por turno com melhor gerenciamento de contexto, delegação para ferramentas e organização estruturada dos prompts.

A qualidade permanece quando essa economia é combinada com proteções determinísticas, como ciclos de verificação e checklists antes da conclusão. Assim, o agente continua concentrado nos dados relevantes e revisa o próprio trabalho antes de responder.