csagent-downloder

CsAgent 0.9.11 — notes de version

La version 0.9.11 ajoute l'outil download_file, qui enregistre une réponse HTTP directement dans un fichier. Il supprime l'attente de plusieurs minutes quand on demande à l'agent de récupérer des données sur le web et de les écrire dans un fichier. Elle fait suite à la 0.9.10.

• Résumé
• Notes de mise à jour
• Le problème
• L'outil
• Limites
• Tests

Résumé

Domaine	Ce qui change
Nouvel outil	download_file (groupe web, demande confirmation) : 38 outils au total
Prompt système	Section 5 : les données destinées à un fichier ne passent pas par le modèle ; http_request renvoie vers download_file
Tests	281 tests (7 de plus)

Aucun argument, variable d'environnement ni fichier de configuration n'est ajouté.

Notes de mise à jour

1. download_file demande confirmation, comme write_file, puisqu'il écrit un fichier. --yes supprime la question.
2. Le comportement par défaut de l'agent change pour ce cas : « récupère X sur le web et écris-le dans un fichier » fait un seul appel à download_file, au lieu de http_request puis write_file.
3. Rien n'est écrit si la requête échoue, et un fichier existant n'est alors pas touché.
4. http_request et write_file ne changent pas : ils servent toujours quand le modèle doit lire la réponse ou produire lui-même le contenu.

Le problème

Demande : « récupère 30 produits sur dummyjson et écris-les dans products.json ».

• La récupération prend une seconde.
• Mais avec http_request puis write_file, le modèle reçoit les 30 produits (environ 40 Ko), puis doit les réécrire en entier dans l'argument content de write_file.
• Un modèle produit sa sortie un jeton à la fois : une dizaine de milliers de jetons à recopier prennent des minutes, et comptent comme jetons de sortie. D'où l'attente entre « les données sont là » et « le fichier est écrit ».

L'outil

download_file — url et destination obligatoires ; json_path (ne garder que cette partie d'une réponse JSON, par exemple products), pretty, method, headers, body, timeoutMs.

Les octets vont du réseau au disque. Le modèle ne reçoit qu'un résumé :

OK: saved 38211 bytes to 'C:\work\products.json' (HTTP 200, application/json). JSON: array of 30 object(s); keys of the first: id, title, description, category, price, … The content was not returned to the conversation; use read_json or read_file only if you need to look at it.

• Sans json_path ni pretty, les octets sont enregistrés tels qu'ils arrivent : JSON, CSV, image, archive.
• Avec json_path (même syntaxe que read_json), seule cette partie est enregistrée, indentée. Pour dummyjson, products laisse de côté total, skip et limit.
• Si json_path n'existe pas, l'erreur liste les clés disponibles.
• Le fichier doit être dans le répertoire de travail ; les dossiers manquants sont créés.

Limites

• Mesure de temps non faite : dummyjson n'est pas joignable depuis l'environnement de développement. Le gain vient de la suppression de la réécriture par le modèle ; il sera d'autant plus net que le modèle est lent. Essayez avec votre demande d'origine.
• Le modèle doit choisir download_file : le prompt le lui demande, mais un modèle peut encore enchaîner http_request et write_file. Si cela arrive, lui dire « utilise download_file » suffit.
• Les données ne sont pas relues : si l'agent doit en extraire ou en transformer une partie, il lit le fichier avec read_json.
• Limite de 20 Mo par téléchargement. Pas d'authentification interactive ni de cookies ; les en-têtes fixes passent par headers.
• Le groupe web est allumé par les mots de la demande (web, site, URL, fetch, download…). Une demande sans aucun de ces mots obtient l'outil par enable_tools au prix d'une étape de plus.

Tests

281 tests (dotnet run --project Tests -c Release), dont les 7 nouveaux (DownloadTests.cs, petit serveur HTTP local) :

• octets enregistrés tels quels, résultat court qui ne contient pas les données ;
• json_path : seul products est gardé, indenté ; forme décrite sans données ;
• sans json_path, JSON identique octet pour octet ; pretty ;
• erreurs qui n'écrivent rien et laissent un fichier existant intact : json_path introuvable (avec les clés), réponse qui n'est pas du JSON, HTTP 404, réponse de plus de 20 Mo ;
• refus avant tout appel réseau : schéma d'URL, URL invalide, chemin hors du dossier de travail, dossier comme destination ;
• outil du groupe web, confirmation requise, http_request et le prompt renvoient vers lui ;
• appel complet de l'agent : un seul appel remplit products.json et le modèle reçoit moins de 600 caractères au lieu de 40 Ko.

# CsAgent 0.9.11 — notes de version

La version 0.9.11 ajoute l'outil download_file, qui enregistre une réponse HTTP directement dans un fichier. Il supprime l'attente de plusieurs minutes quand on demande à l'agent de récupérer des données sur le web et de les écrire dans un fichier. Elle fait suite à la 0.9.10.

• [Résumé](#résumé)
• [Notes de mise à jour](#notes-de-mise-à-jour)
• [Le problème](#le-problème)
• [L'outil](#loutil)
• [Limites](#limites)
• [Tests](#tests)

Résumé

Domaine	Ce qui change
Nouvel outil	download_file (groupe web, demande confirmation) : 38 outils au total
Prompt système	Section 5 : les données destinées à un fichier ne passent pas par le modèle ; http_request renvoie vers download_file
Tests	281 tests (7 de plus)

Aucun argument, variable d'environnement ni fichier de configuration n'est ajouté.

Notes de mise à jour

1. download_file demande confirmation, comme write_file, puisqu'il écrit un fichier. --yes supprime la question.
2. Le comportement par défaut de l'agent change pour ce cas : « récupère X sur le web et écris-le dans un fichier » fait un seul appel à download_file, au lieu de http_request puis write_file.
3. Rien n'est écrit si la requête échoue, et un fichier existant n'est alors pas touché.
4. http_request et write_file ne changent pas : ils servent toujours quand le modèle doit lire la réponse ou produire lui-même le contenu.

Le problème

Demande : « récupère 30 produits sur dummyjson et écris-les dans products.json ».

• La récupération prend une seconde.
• Mais avec http_request puis write_file, le modèle reçoit les 30 produits (environ 40 Ko), puis doit les réécrire en entier dans l'argument content de write_file.
• Un modèle produit sa sortie un jeton à la fois : une dizaine de milliers de jetons à recopier prennent des minutes, et comptent comme jetons de sortie. D'où l'attente entre « les données sont là » et « le fichier est écrit ».

L'outil

download_file — url et destination obligatoires ; json_path (ne garder que cette partie d'une réponse JSON, par exemple products), pretty, method, headers, body, timeoutMs.

Les octets vont du réseau au disque. Le modèle ne reçoit qu'un résumé :

OK: saved 38211 bytes to 'C:\work\products.json' (HTTP 200, application/json). JSON: array of 30 object(s); keys of the first: id, title, description, category, price, … The content was not returned to the conversation; use read_json or read_file only if you need to look at it.

• Sans json_path ni pretty, les octets sont enregistrés tels qu'ils arrivent : JSON, CSV, image, archive.
• Avec json_path (même syntaxe que read_json), seule cette partie est enregistrée, indentée. Pour dummyjson, products laisse de côté total, skip et limit.
• Si json_path n'existe pas, l'erreur liste les clés disponibles.
• Le fichier doit être dans le répertoire de travail ; les dossiers manquants sont créés.

Limites

• Mesure de temps non faite : dummyjson n'est pas joignable depuis l'environnement de développement. Le gain vient de la suppression de la réécriture par le modèle ; il sera d'autant plus net que le modèle est lent. Essayez avec votre demande d'origine.
• Le modèle doit choisir download_file : le prompt le lui demande, mais un modèle peut encore enchaîner http_request et write_file. Si cela arrive, lui dire « utilise download_file » suffit.
• Les données ne sont pas relues : si l'agent doit en extraire ou en transformer une partie, il lit le fichier avec read_json.
• Limite de 20 Mo par téléchargement. Pas d'authentification interactive ni de cookies ; les en-têtes fixes passent par headers.
• Le groupe web est allumé par les mots de la demande (web, site, URL, fetch, download…). Une demande sans aucun de ces mots obtient l'outil par enable_tools au prix d'une étape de plus.

Tests

281 tests (dotnet run --project Tests -c Release), dont les 7 nouveaux (DownloadTests.cs, petit serveur HTTP local) :

• octets enregistrés tels quels, résultat court qui ne contient pas les données ;
• json_path : seul products est gardé, indenté ; forme décrite sans données ;
• sans json_path, JSON identique octet pour octet ; pretty ;
• erreurs qui n'écrivent rien et laissent un fichier existant intact : json_path introuvable (avec les clés), réponse qui n'est pas du JSON, HTTP 404, réponse de plus de 20 Mo ;
• refus avant tout appel réseau : schéma d'URL, URL invalide, chemin hors du dossier de travail, dossier comme destination ;
• outil du groupe web, confirmation requise, http_request et le prompt renvoient vers lui ;
• appel complet de l'agent : un seul appel remplit products.json et le modèle reçoit moins de 600 caractères au lieu de 40 Ko.