Deep Agents v0.7 reduce los tokens por turno un 65%

Deep Agents v0.7 reduce los tokens de entrada base por turno un 65%. Esto significa menos sobrecarga fija del prompt en cada llamada, menor gasto de API y más espacio de contexto para las partes importantes de la tarea.

La actualización se puede resumir así:

• Se ha eliminado el prompt base del sistema predeterminado
• Las descripciones de las herramientas integradas son más breves
• Las tareas pendientes ya no se adjuntan de forma predeterminada
• El middleware se elige de manera intencionada, en lugar de incluirse en un paquete
• El ahorro procede del harness, no del modelo

En términos sencillos: si un agente realiza 10 llamadas, antes se enviaba el mismo envoltorio fijo 10 veces. En v0.7, ese envoltorio es mucho más pequeño de forma predeterminada. Por tanto, cada turno contiene una solicitud más ligera, especialmente en tareas sencillas como leer o escribir archivos.

Hay varios puntos destacados:

• El coste se escala según llm_calls × input_tokens_per_call
• La configuración anterior enviaba texto de planificación, sistema de archivos y subagentes incluso cuando la tarea no lo necesitaba
• La configuración nueva me da el control para elegir el prompt, las herramientas y el middleware adecuados para el trabajo
• Las mayores reducciones proceden de eliminar el prompt base y acortar el texto de las herramientas
• Los flujos de trabajo largos con varios agentes obtienen el mayor beneficio porque la sobrecarga fija se repite en cada paso

Esta es una vista sencilla del antes y el después:

Mi conclusión: v0.7 se centra menos en cambios del modelo y más en la disciplina de los prompts. Si mantengo ligero el harness, conservo toda la mejora del 65%. Si vuelvo a acumular middleware y herramientas, pierdo parte de esa ventaja.

Ese es el núcleo de la actualización y la base del resto del artículo.

Qué ha cambiado en el harness configurable

La reducción de tokens del 65% procede de cambiar lo que el harness inserta en cada turno, no de usar un modelo más inteligente. En pocas palabras, v0.7 elimina gran parte del texto predeterminado que antes acompañaba cada solicitud.

Eliminación del prompt base del sistema y reducción de las descripciones de herramientas

Antes de v0.7, el harness incluía en cada solicitud un prompt del sistema predeterminado, descripciones largas de herramientas, middleware de planificación y lógica de subagentes, incluso cuando la tarea no necesitaba nada de ello. v0.7 cambia esta configuración al hacer que el harness sea configurable, para que los desarrolladores decidan qué se inserta en cada turno.

Las principales fuentes de sobrecarga eran el prompt base del sistema predeterminado y las largas descripciones de las herramientas integradas. El prompt base incluía instrucciones para herramientas de planificación, herramientas del sistema de archivos y subagentes, y se enviaba en todos los turnos. En v0.7, ese prompt se ha eliminado. Ahora los desarrolladores pueden proporcionar un texto de prompt adaptado a la tarea.

También se han acortado las descripciones integradas de utilidades como ls, read_file y write_file. Las herramientas siguen funcionando de la misma manera. Simplemente hay menos texto fijo alrededor de cada solicitud. Ningún cambio afecta al modelo subyacente; solo reduce la carga de tokens que antes llevaba cada turno.

Tareas pendientes opcionales y middleware seleccionable de forma explícita

Antes de v0.7, todoListMiddleware se adjuntaba de forma predeterminada, por lo que cada turno incluía texto de planificación. En v0.7, las tareas pendientes son opcionales. Esto significa que solo se añaden cuando una tarea mejora con una planificación de varios pasos.

El mismo cambio se aplica al resto de la pila de middleware. FilesystemMiddleware y SubAgentMiddleware ya no se incluyen de forma predeterminada. Los desarrolladores pueden montar únicamente el middleware que necesitan. Una tarea de lectura de archivos puede omitir la lógica de subagentes. Un flujo de verificación puede añadir middleware de lista de comprobación solo cuando resulte útil.

Cómo se vuelve más explícita la orquestación

El cambio práctico es sencillo: la configuración pasa de valores predeterminados implícitos a opciones explícitas. En lugar de dejar que el harness decida qué herramientas son visibles, qué middleware se ejecuta y qué contiene el prompt del sistema, los desarrolladores toman esas decisiones. Ahora controlan el montaje del prompt, la visibilidad de las herramientas y el middleware para cada tarea.

Estos cambios aparecen en la siguiente pila del agente predeterminado. ^[2]

Uso de tokens antes y después

Los cambios del harness se reflejan inmediatamente en la carga enviada en cada turno. El ahorro procede de reducir el envoltorio fijo de la solicitud, no de cambiar el prompt del usuario ni el modelo.

Turno del agente predeterminado antes de v0.7

Antes de v0.7, cada turno incluía estructuras de planificación, sistema de archivos y subagentes aunque no se utilizaran. El texto de tareas pendientes y los prompts del middleware también se incluían de forma predeterminada. Esto hacía que una gran carga fija se repitiera en cada turno.

Turno del agente predeterminado después de v0.7

Después de v0.7, una tarea sencilla de lectura de archivos solo envía las herramientas y el middleware que necesita. La sobrecarga adicional deja de repetirse entre turnos. Se elimina el prompt base del sistema, las descripciones de herramientas son más breves y una tarea de lectura de archivos ya no contiene texto de planificación o subagentes sin utilizar.

Como señala Aaron Jewitt, el coste de un agente se escala según llm_calls × input_tokens_per_call.^[1]

De dónde procede el ahorro de tokens

Así se consigue la reducción del 65%.

El mayor ahorro procede de eliminar el prompt base y reducir las descripciones de herramientas. Por eso el middleware selectivo y una visibilidad limitada de las herramientas marcan una diferencia tan clara en los flujos cotidianos.

La siguiente sección explica cómo conservar ese ahorro eligiendo únicamente los componentes del harness necesarios para cada tarea.

Patrones de configuración del harness para desarrolladores

Después de asegurar el ahorro de tokens, el siguiente paso consiste en elegir un perfil de harness ligero para cada tarea. Ese ahorro procede de prompts más pequeños y valores predeterminados más ajustados. En Deep Agents v0.7, el harness, y no el modelo, genera la mayor parte de la sobrecarga de tokens por turno. Por tanto, optimizar Deep Agents v0.7 depende menos de elegir el modelo y más de cómo se monta el harness.

Elegir solo el middleware necesario para la tarea

Usa middleware únicamente cuando una tarea necesite controles, planificación o gestión de estado. En tareas breves, esas capas adicionales solo añaden sobrecarga.

La regla es sencilla: empieza con la pila de middleware más pequeña que necesite la tarea. Lo mismo se aplica a las herramientas. Expón únicamente las que la tarea actual necesite de verdad.

Limitar la visibilidad de herramientas y acortar las descripciones

Mostrar todas las herramientas en cada turno es una de las formas más rápidas de inflar la entrada. Mantener limitada su visibilidad ayuda a reducir el prompt.

Las descripciones más breves disminuyen aún más su tamaño. Una descripción concisa y precisa reduce el prompt y facilita que el modelo elija la herramienta correcta sin una gran cantidad de contexto adicional.

Usar tareas opcionales y valores predeterminados basados en perfiles

La gestión de tareas pendientes resulta útil en trabajos de largo alcance donde el agente debe seguir el progreso a través de muchos pasos. En tareas breves de un solo paso, las tareas pendientes añaden sobrecarga sin aportar nada.

Haz que las tareas pendientes sean opcionales en trabajos de largo alcance y establece valores ligeros o completos según la clase de agente. Los valores ligeros por clase de agente conservan la mejora del 65% en agentes sencillos, mientras que los perfiles completos se reservan para flujos con mucha planificación.

Estas decisiones determinan si la reducción del 65% se traduce en un coste menor y una iteración más rápida durante el uso diario.

Qué significa la actualización v0.7 para el coste, la velocidad y la escala

Menores costes de inferencia y ciclos de iteración más rápidos

Ese envoltorio más pequeño se acumula en cada turno de un flujo largo. El coste de tokens aumenta en ejecuciones multivuelta, por lo que un harness ligero no solo ahorra dinero en el primer turno. Mantiene un punto de partida menor en todos los turnos posteriores y la diferencia aumenta a medida que crece la conversación.

Así se refleja la reducción en la práctica:

Las cargas más pequeñas también aceleran los ciclos de iteración. Si estás probando un cambio de prompt o una nueva configuración de herramientas, las solicitudes ligeras regresan antes. Esto elimina gran parte de la fricción del trabajo diario de desarrollo.

Mejor escalabilidad en flujos largos y con varios agentes

El mismo ahorro de tokens importa todavía más cuando varios agentes comparten el presupuesto de un flujo. La sobrecarga fija consume presupuesto de forma silenciosa en sistemas multiagente. Si cada agente lleva un harness sobredimensionado, esa sobrecarga se multiplica en cada turno coordinado.

Un paquete de harness más ligero reduce la huella de cada agente. Esto mejora el rendimiento y disminuye la probabilidad de alcanzar los límites de contexto o de velocidad en mitad del flujo.

A medida que se llenan las ventanas de contexto, el rendimiento puede disminuir. Un harness ligero deja a cada agente más espacio de contexto útil para los datos reales de la tarea. En términos sencillos, los flujos de larga duración pueden mantener la precisión durante más tiempo, sin necesidad de que la lógica de compactación o resumen intervenga demasiado pronto.

Una menor sobrecarga por llamada es especialmente importante en flujos con muchos turnos, muchos agentes o ambos. La reducción de tokens del 65% disminuye el coste por llamada. Sin embargo, el mayor beneficio de escala procede del modelo de orquestación explícita de v0.7. Con criterios de parada claros en lugar de bucles abiertos, los agentes realizan menos llamadas en total para completar una tarea.

Conclusiones principales del lanzamiento de Deep Agents v0.7

Deep Agents v0.7 mejora el coste y la calidad al hacer configurable el harness. La selección del middleware, la visibilidad de las herramientas y los valores basados en perfiles deciden ahora si un flujo mantiene todo el ahorro o pierde gran parte debido a la sobrecarga adicional.

La configuración es la principal palanca de optimización. Es especialmente importante en flujos con muchos turnos, muchos agentes o ambos.

Preguntas frecuentes

¿Cómo conservo todo el ahorro de tokens del 65% en flujos reales?

Trata la configuración del harness como un sistema vivo, no como una tarea que se ajusta una vez y se olvida. Empieza midiendo el uso de tokens y el número de llamadas al LLM. Después, usa el harness para fijar reglas de comportamiento estrictas.

Usa PreCompletionChecklistMiddleware para detener ciclos de razonamiento redundantes. Usa LocalContextMiddleware para proporcionar únicamente el contexto y las herramientas que necesita el modelo. Añade almacenamiento en caché de prompts para mantener estables las instrucciones del sistema entre distintas ejecuciones.

Cuando aumente el uso de tokens, busca desviaciones y ajusta las reglas del harness.

¿Qué tareas deberían seguir usando listas de tareas o middleware adicional?

Usa todoListMiddleware cuando el agente trabaje en un problema complejo de varias partes. Le ayuda a seguir qué está terminado y qué queda pendiente a medida que avanza el trabajo.

Cuando solicitas mediante un prompt el uso de la herramienta write_todos, el agente puede actualizar el progreso conforme aparezcan nuevos detalles. Esto facilita el seguimiento de flujos largos y difíciles y ayuda al agente a mantener el rumbo.

¿Afecta un harness más pequeño a la calidad o fiabilidad del agente?

No de forma predeterminada. Un harness más pequeño y ajustado puede mantener o incluso mejorar la fiabilidad al reducir los tokens por turno mediante una mejor gestión del contexto, descarga de trabajo en herramientas y empaquetado estructurado de prompts.

La calidad se mantiene cuando ese ahorro se combina con barreras deterministas, como ciclos de verificación y listas previas a la finalización. Esto ayuda al agente a concentrarse en los datos importantes y revisar su trabajo antes de responder.