Skip to content

Releases

csagent-apiaudio

csagent-apiaudio Latest
Latest

Choose a tag to compare

View all tags
@artydev artydev released this 31 Oct 08:13
0.9.15
e126206

CsAgent 0.9.15 — notes de version

La version 0.9.15 expose la transcription audio (parole vers texte) dans le mode --api, jusque-là réservée à la Web UI. Un programme, par exemple CSFlow, peut envoyer un enregistrement à CsAgent et recevoir le texte. Elle fait suite à la 0.9.14.

Résumé

Domaine Ce qui change
--api Trois points d'accès audio : POST /api/audio/start, POST /api/audio/{id} et POST /api/audio/{id}/transcribe (flux SSE)
Code ApiHost.cs appelle MapAudioEndpoints() ; la bannière de démarrage annonce POST /api/audio/… (speech to text)
Documentation README, guide et page d'accueil décrivent les trois points d'accès
Tests 310 tests, inchangés : aucun test n'a été ajouté pour cette version

Aucun argument ni variable d'environnement n'est ajouté.

Notes de mise à jour

  1. Rien à faire : les points d'accès apparaissent avec --api. Les autres routes ne changent pas.
  2. CSFlow : le nœud user_input avec micro (saisie vocale) a besoin de cette version. Avec une version plus ancienne, CSFlow signale que CsAgent est trop ancien (réponse 404 sur /api/audio/start).
  3. La clé d'API (--api-key) protège ces routes comme les autres. Sans clé, elles sont ouvertes sur la machine locale, comme le reste de --api.
  4. Les fichiers sont écrits dans recordings/ (audio) et transcripts/ (texte), dans le dossier de travail de CsAgent.

Les points d'accès

Appel Rôle
POST /api/audio/start?type=<mime> Ouvre un enregistrement. Répond {"id","path"}
POST /api/audio/{id} Ajoute des octets d'audio, dans l'ordre (corps brut)
POST /api/audio/{id}/transcribe?lang=fr Lance la transcription. Flux SSE : progress, puis done (text, path) ou error

lang prend un code à deux lettres ; sans lui, la langue est détectée. Ce sont les mêmes routes que celles de la dictée de la Web UI.

Exemple

curl -X POST "http://localhost:8080/api/audio/start?type=audio/wav" -H "Authorization: Bearer demo-secret"
curl -X POST "http://localhost:8080/api/audio/<id>" -H "Authorization: Bearer demo-secret" --data-binary @entretien.wav
curl -N -X POST "http://localhost:8080/api/audio/<id>/transcribe?lang=fr" -H "Authorization: Bearer demo-secret"

Limites

  • Essayé en partie seulement : le démarrage d'un enregistrement (/api/audio/start) a été vérifié sur un binaire compilé sous Windows. L'envoi des octets et la transcription par le point d'accès configuré (Albert) restent à vérifier de bout en bout.
  • ffmpeg est nécessaire, sauf pour un fichier .wav ou .mp3 de 24 Mo au plus. Un enregistrement est limité à 100 Mo.
  • Le modèle de transcription est celui du point d'accès configuré : OpenRouter n'en propose pas.
  • L'audio part vers ce point d'accès : choisissez un point d'accès local s'il ne doit pas quitter la machine.

Tests

310 tests (dotnet run --project Tests -c Release), sans nouveau test. Les points d'accès audio existaient déjà pour la Web UI ; cette version ne change que leur exposition en --api.

Assets 3
Loading

csagent-gitready

csagent-gitready

Choose a tag to compare

View all tags
@artydev artydev released this 23 Oct 17:20
v0.9.14
6882267

CsAgent 0.9.14 — notes de version

La version 0.9.14, csagent-gitready, rassemble trois apports de Virgile Jarrige : la lecture d'un gros fichier par tranches, cinq nouveaux outils git, et un client Python pour piloter CsAgent depuis des scripts. Deux garde-fous ont été ajoutés aux outils git à la relecture. Elle fait suite à la 0.9.13.

Résumé

Domaine Ce qui change
read_file Deux paramètres facultatifs, start_line et end_line : on lit une fenêtre de lignes d'un fichier volumineux (2 000 lignes au plus par appel)
Git Cinq outils : git_add, git_fetch, git_pull, git_push, git_checkout. 43 outils au total (38 avant)
Python python/csagent_client.py, un client de l'API SSE en bibliothèque standard seule, avec son README et ses tests
Garde-fous git_checkout ne prend plus un nom de fichier pour une branche ; git_add lit -- avant le nom
Tests 310 tests C# (22 de plus), plus 12 tests Python

Aucun argument ni variable d'environnement n'est ajouté.

Notes de mise à jour

  1. Rien à faire : les outils s'ajoutent d'eux-mêmes. read_file sans paramètre se comporte comme avant.
  2. Trois outils git demandent confirmation : git_pull, git_push et git_checkout (sauf avec --yes). git_add et git_fetch n'en demandent pas.
  3. Les cinq outils sont dans le groupe git : ils ne sont décrits au modèle que si la demande parle de git. La description des 43 outils pèse environ 28 000 caractères (20 000 avant), renvoyés à chaque étape avec --all-tools.
  4. Le client Python se copie avec le dépôt : il n'y a rien à installer.

read_file par tranches

  • start_line (1 par défaut) et end_line (fin du fichier par défaut), en numéros de ligne à partir de 1, bornes comprises.
  • Le résultat commence par Lines 10-40: pour dire ce qui est rendu. Le fichier est lu ligne à ligne : il n'est jamais chargé entier en mémoire.
  • Une fenêtre est limitée à 2 000 lignes ; au-delà, la fin est coupée avec une note.
  • Sans ces paramètres, la limite de 512 Ko s'applique encore, et le message d'erreur propose maintenant de lire par fenêtres. Avec eux, un fichier de plus de 512 Ko se lit.
  • Une plage inversée, ou un début après la fin du fichier, donne une erreur claire (avec le nombre de lignes).

Cinq outils git

Outil Ce qu'il fait Confirmation
git_add Indexe un fichier (spec), ou tout sans spec non
git_fetch git fetch --prune : récupère sans toucher au dossier de travail non
git_pull git pull --ff-only : refuse de fusionner un historique divergé oui
git_push git push vers la branche suivie, jamais en force oui
git_checkout Change de branche, ou de commit par son SHA oui

Tous refusent un chemin hors du dossier de travail.

Client Python

python/csagent_client.py pilote un serveur csagent --api (ou la Web UI, qui parle le même protocole). Bibliothèque standard uniquement (http.client, json, urllib). Il lit le flux SSE événement par événement, répond aux confirmations et rend la réponse finale. Le mode d'emploi est dans python/README.md. C'est l'élément « Scripts Python » de la liste des fonctionnalités à venir, qui disparaît du README.

Corrections à la relecture

Deux défauts ont été trouvés en relisant les outils git, et corrigés avec un test chacun :

  • git_checkout pouvait effacer un travail en cours. Le nom de la « branche » notes.md est accepté par le contrôle, et git checkout notes.md restaure le fichier depuis l'index : les modifications non enregistrées sont perdues sans message. La commande se termine maintenant par --, ce qui force git à lire le nom comme une branche ou un commit : un nom de fichier donne invalid reference et rien n'est touché.
  • git_add laissait passer une option cachée. spec ne devait pas commencer par -, mais a.txt --dry-run passait ce contrôle et était lu par git comme une option. La commande est maintenant git add -- <spec> : tout ce qui suit est un chemin.

Limites

  • git_push pousse la branche courante vers sa branche suivie ; sans branche suivie, git refuse et le message l'explique. Aucun moyen de forcer.
  • git_checkout ne crée pas de branche (-b) et ne restaure pas de fichier : c'est volontaire.
  • Les paramètres start_line et end_line doivent être des entiers ; une valeur textuelle donne une erreur.
  • Le client Python n'est pas empaqueté (pas de pip install) : on ajoute son dossier au sys.path.

Tests

310 tests C# (dotnet run --project Tests -c Release) et 12 tests Python (python python/test_csagent_client.py). Nouveaux : 10 pour read_file (ReadFilePaginationTests.cs), 12 pour les outils git (GitVerbTests.cs, dont les 2 des corrections ci-dessus).

Loading

csagent-proxyready

csagent-proxyready

Choose a tag to compare

View all tags
@artydev artydev released this 21 Oct 14:19
v0.9.13
03d8c3a

CsAgent 0.9.13 — notes de version

La version 0.9.13 permet à CsAgent de passer derrière un proxy d'entreprise qui demande une authentification Windows (erreur HTTP 407). Tous les accès HTTP de l'agent sont désormais créés au même endroit. Elle fait suite à la 0.9.12.

Résumé

Domaine Ce qui change
Proxy d'entreprise Les identifiants Windows de la session sont donnés au proxy (DefaultProxyCredentials) : un proxy qui répond 407 ne bloque plus l'agent
Code Un seul endroit crée les clients HTTP : HttpClients.Create(délai) dans Shared/HttpClients.cs. Le client LLM, le catalogue de modèles, download_file, les outils réseau, système et audio, et le transport MCP en HTTP l'utilisent
Tests 288 tests (3 de plus)

Aucun argument, variable d'environnement ni fichier de configuration n'est ajouté. Les délais d'attente ne changent pas.

Notes de mise à jour

  1. Rien à faire : sans proxy, ou avec un proxy qui n'exige pas d'authentification, le comportement est identique.
  2. Les identifiants vont au proxy seulement, jamais aux serveurs : UseDefaultCredentials n'est volontairement pas utilisé, car il enverrait ces identifiants à tout serveur qui les demande.
  3. Un code qui crée lui-même un new HttpClient( échoue désormais au test « no source file makes an HttpClient by itself any more » : il faut passer par HttpClients.Create.

Le problème

Derrière un proxy d'entreprise qui exige l'authentification intégrée de Windows, chaque requête de CsAgent (modèle, pages web, téléchargement, serveurs MCP, audio) recevait une erreur 407 « Proxy Authentication Required », parce que le client HTTP ne présentait aucune identité au proxy. Les clients étaient en outre créés à neuf endroits différents : corriger l'un d'eux laissait les autres en échec.

Le correctif

  • HttpClients.Create(délai) fabrique le client avec DefaultProxyCredentials = CredentialCache.DefaultCredentials : l'identité de la session Windows est présentée au proxy.
  • Les neuf endroits qui créaient un client directement passent par cette fonction.
  • Un test vérifie que plus aucun fichier du code de l'application ne crée un client par lui-même.

Sous Linux et macOS

  • Le proxy est choisi par les variables HTTP_PROXY, HTTPS_PROXY et NO_PROXY (pas par un réglage du système).
  • Pour un proxy qui demande un identifiant et un mot de passe, le plus simple est de les mettre dans la variable : HTTPS_PROXY=http://utilisateur:motdepasse@proxy:3128.
  • L'authentification intégrée (Kerberos) ne fonctionne que si un ticket valide existe (kinit) et que la bibliothèque libgssapi est installée. Sinon, aucune identité n'est envoyée : l'erreur 407 reste, sans autre effet.

Limites

  • Pas essayé avec un vrai proxy d'entreprise : l'environnement de développement est sous Linux, sans domaine ni proxy authentifié. Les tests couvrent la configuration du client et un échange avec un serveur local, pas l'authentification elle-même. À vérifier sur une machine Windows de domaine.
  • Un proxy qui demande un identifiant et un mot de passe distincts de la session Windows n'est pas pris en charge sous Windows (aucun argument pour les saisir) ; sous Linux et macOS, mettez-les dans HTTPS_PROXY.
  • Les serveurs MCP lancés en local (--mcp-stdio) ne passent pas par HTTP : ils ne sont pas concernés.

Tests

288 tests (dotnet run --project Tests -c Release), dont les 3 nouveaux (HttpClientsTests.cs) :

  • le gestionnaire donne les identifiants par défaut au proxy et ne les donne pas aux serveurs ;
  • Create applique le délai d'attente, et le client joint un serveur local ;
  • aucun fichier du code de l'application ne crée un HttpClient par lui-même.
Loading

csagent-excelfix

csagent-excelfix

Choose a tag to compare

View all tags
@artydev artydev released this 15 Oct 20:58
v0.9.12
68ed161

CsAgent 0.9.12 — notes de version

La version 0.9.12 corrige un faux blocage du filtre de commandes : excel_command refusait $ws.Range("E2:E31").NumberFormat = "0.00" comme « potentiellement dangereux ». Elle fait suite à la 0.9.11.

Résumé

Domaine Ce qui change
Filtre des commandes Un motif ne compte qu'en début de mot : NumberFormat n'est plus pris pour format, git add n'est plus pris pour dd
Messages de refus Ils nomment le motif bloqué (blocked pattern 'format') dans sh, run_terminal et excel_command
Tests 285 tests (4 de plus)

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

Notes de mise à jour

  1. Le filtre est moins strict sur un point précis : un motif qui commence par une lettre n'est plus cherché au milieu d'un mot. Tous les motifs de la liste restent bloqués quand ils sont utilisés comme commande ou comme argument.
  2. La liste des motifs ne change pas. Les motifs qui commencent par un séparateur de chemin (\windows\system32\, /etc/…) restent cherchés n'importe où dans le texte.
  3. Le message de refus change de forme : Error: excel_command - command contains the blocked pattern 'format' (potentially dangerous operations) and is not allowed. Rewrite the command…. Le début (Error: <outil> -) et les mots « not allowed » sont conservés.

Le problème

Sous Windows, le filtre cherchait le texte format n'importe où dans la commande, en minuscules, pour bloquer format c:. Or .NumberFormat = "0.00" contient format (le mot est suivi d'un espace). Mettre un format de nombre sur des cellules Excel était donc refusé, quelle que soit la façon d'écrire la commande (guillemets simples ou doubles : l'agent essayait les deux, sans effet). Le message ne disait pas quel motif posait problème, donc l'agent ne pouvait pas deviner.

Le même défaut existait sous Linux et macOS : git add fichier contient dd et était refusé par sh.

Le correctif

  • Un motif qui commence par une lettre ne compte qu'au début d'un mot : le caractère qui le précède ne doit être ni une lettre, ni un chiffre, ni _, ., $ ou -.
  • format c:, echo x & format c:, cmd /c format e: restent bloqués ; .NumberFormat = "0.00" et .Cells.NumberFormat.ToString() passent.
  • Le message nomme le motif trouvé.

Limites

  • Le filtre lit toujours le texte de la commande, y compris entre guillemets. Une cellule Excel dont la valeur est "format c:" reste bloquée, puisqu'elle ressemble à la commande. Le message le dit : il faut reformuler. Ignorer le texte entre guillemets dans excel_command a été envisagé puis écarté : il ajoute du code de sécurité et une liste noire de lanceurs pour un cas qui ne s'est pas présenté. À reprendre si le cas se présente.
  • Le filtre n'est pas un analyseur de commandes : il ne protège pas contre une commande volontairement obfusquée. C'est un garde-fou contre les erreurs, pas une barrière de sécurité.
  • Non corrigé, car hors du sujet : sous Linux et macOS, /bin/ est aussi cherché dans un chemin comme ./bin/Debug/app.dll, qui est donc refusé par sh.
  • Pas essayé avec un vrai Excel : l'environnement de développement est sous Linux. Les tests couvrent le filtre, pas l'appel COM.

Tests

285 tests (dotnet run --project Tests -c Release), dont les 4 nouveaux (CommandFilterTests.cs) :

  • Windows : .NumberFormat (guillemets simples et doubles, plusieurs instructions), .Font.Bold et .Cells.NumberFormat.ToString() passent ;
  • Windows : format c: est bloqué au début, après & ou ;, dans cmd /c, ou entre guillemets ; ainsi que reg delete, net user, shutdown, del /f et \windows\system32\ ;
  • Linux et macOS : git add passe, dd if=…, sudo, chmod, /etc/, mkfs et reboot restent bloqués ;
  • le refus nomme le motif dans excel_command, sh et run_terminal, et garde les mots « not allowed » ;
# CsAgent 0.9.12 — notes de version

La version 0.9.12 corrige un faux blocage du filtre de commandes : excel_command refusait $ws.Range("E2:E31").NumberFormat = "0.00" comme « potentiellement dangereux ». Elle fait suite à la 0.9.11.

Résumé

Domaine Ce qui change
Filtre des commandes Un motif ne compte qu'en début de mot : NumberFormat n'est plus pris pour format, git add n'est plus pris pour dd
Messages de refus Ils nomment le motif bloqué (blocked pattern 'format') dans sh, run_terminal et excel_command
Tests 285 tests (4 de plus)

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

Notes de mise à jour

  1. Le filtre est moins strict sur un point précis : un motif qui commence par une lettre n'est plus cherché au milieu d'un mot. Tous les motifs de la liste restent bloqués quand ils sont utilisés comme commande ou comme argument.
  2. La liste des motifs ne change pas. Les motifs qui commencent par un séparateur de chemin (\windows\system32\, /etc/…) restent cherchés n'importe où dans le texte.
  3. Le message de refus change de forme : Error: excel_command - command contains the blocked pattern 'format' (potentially dangerous operations) and is not allowed. Rewrite the command…. Le début (Error: <outil> -) et les mots « not allowed » sont conservés.

Le problème

Sous Windows, le filtre cherchait le texte format n'importe où dans la commande, en minuscules, pour bloquer format c:. Or .NumberFormat = "0.00" contient format (le mot est suivi d'un espace). Mettre un format de nombre sur des cellules Excel était donc refusé, quelle que soit la façon d'écrire la commande (guillemets simples ou doubles : l'agent essayait les deux, sans effet). Le message ne disait pas quel motif posait problème, donc l'agent ne pouvait pas deviner.

Le même défaut existait sous Linux et macOS : git add fichier contient dd et était refusé par sh.

Le correctif

  • Un motif qui commence par une lettre ne compte qu'au début d'un mot : le caractère qui le précède ne doit être ni une lettre, ni un chiffre, ni _, ., $ ou -.
  • format c:, echo x & format c:, cmd /c format e: restent bloqués ; .NumberFormat = "0.00" et .Cells.NumberFormat.ToString() passent.
  • Le message nomme le motif trouvé.

Limites

  • Le filtre lit toujours le texte de la commande, y compris entre guillemets. Une cellule Excel dont la valeur est "format c:" reste bloquée, puisqu'elle ressemble à la commande. Le message le dit : il faut reformuler. Ignorer le texte entre guillemets dans excel_command a été envisagé puis écarté : il ajoute du code de sécurité et une liste noire de lanceurs pour un cas qui ne s'est pas présenté. À reprendre si le cas se présente.
  • Le filtre n'est pas un analyseur de commandes : il ne protège pas contre une commande volontairement obfusquée. C'est un garde-fou contre les erreurs, pas une barrière de sécurité.
  • Non corrigé, car hors du sujet : sous Linux et macOS, /bin/ est aussi cherché dans un chemin comme ./bin/Debug/app.dll, qui est donc refusé par sh.
  • Pas essayé avec un vrai Excel : l'environnement de développement est sous Linux. Les tests couvrent le filtre, pas l'appel COM.

Tests

285 tests (dotnet run --project Tests -c Release), dont les 4 nouveaux (CommandFilterTests.cs) :

  • Windows : .NumberFormat (guillemets simples et doubles, plusieurs instructions), .Font.Bold et .Cells.NumberFormat.ToString() passent ;
  • Windows : format c: est bloqué au début, après & ou ;, dans cmd /c, ou entre guillemets ; ainsi que reg delete, net user, shutdown, del /f et \windows\system32\ ;
  • Linux et macOS : git add passe, dd if=…, sudo, chmod, /etc/, mkfs et reboot restent bloqués ;
  • le refus nomme le motif dans excel_command, sh et run_terminal, et garde les mots « not allowed » ;
Loading

csagent-downloder

csagent-downloder

Choose a tag to compare

View all tags
@artydev artydev released this 15 Oct 20:53
v0.9.11
f400cb0

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é

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é

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 ...
Read more
Loading

csagent-calendar

csagent-calendar

Choose a tag to compare

View all tags
@artydev artydev released this 15 Oct 20:06
v0.9.10
61d00a1

CsAgent 0.9.10 — notes de version

La version 0.9.10 ajoute l'agenda Outlook : l'agent lit les rendez-vous d'une période et en crée, sans inscription Azure ni jeton. Elle fait suite à la 0.9.9.

Résumé

Domaine Ce qui change
Nouveaux outils read_calendar (lecture seule) et create_appointment (demande confirmation) : 37 outils au total
Groupe d'outils calendar, allumé par agenda, calendrier, rendez-vous, réunion, créneau, meeting… (voir 0.9.8)
Prompt système Nouvelle section 19 (agenda)
Tests 274 tests (10 de plus)

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

Notes de mise à jour

  1. Windows seulement, avec Outlook classique installé et configuré, comme send_email. Sous Linux et macOS, les deux outils répondent par une erreur claire.
  2. Rien n'est créé sans relecture. create_appointment demande confirmation, puis affiche le rendez-vous dans Outlook sans l'enregistrer. save: true l'enregistre ; send: true l'enregistre et envoie les invitations (irréversible, exige des participants).
  3. Aucune invitation par défaut. Donner des attendees fait du rendez-vous une réunion, mais rien ne part sans send: true.
  4. L'agent connaît la date du jour par read_calendar : la première ligne du résultat la donne avec le jour de la semaine. Le prompt système ne la contient pas (il est construit une fois par session et serait périmé le lendemain).
  5. Le test --no-compact supposait une taille exacte du prompt système : il accepte maintenant 6 à 8 résultats conservés.

Les deux outils

read_calendar — start (aujourd'hui par défaut), end (7 jours après start, 366 au plus ; une date seule inclut tout ce jour), query (objet ou lieu), max_items (50, 200 au plus). Les rendez-vous récurrents sont développés. Une ligne par rendez-vous :

2026-10-16 14:00-15:00 | Point d'équipe | Salle 3 | organizer: Marie Durand [meeting]

create_appointment — subject et start obligatoires ; end ou duration_minutes (60 par défaut) ; all_day ; location, body, attendees, reminder_minutes (0 : pas de rappel) ; save, send. Les chevauchements avec l'agenda sont signalés (« Warning: overlaps with … »), sans bloquer.

Les dates sont des heures locales ISO-8601 sans fuseau (2026-10-16T14:00). Elles sont renvoyées à PowerShell dans un format fixe : la langue de la machine ne change pas leur sens. Le texte (objet, lieu, notes) est transmis entre apostrophes, donc $(...) n'est jamais interprété. Le contenu de l'agenda est marqué comme donnée non fiable.

Limites

  • Non essayé avec un vrai Outlook : l'environnement de développement est sous Linux. Les tests couvrent les arguments, les dates et le PowerShell généré, pas l'appel COM lui-même. À vérifier sur Windows avant de s'y fier : le filtre de période (Restrict avec le format de date de la machine), les réunions avec participants, les journées entières.
  • Seul l'agenda par défaut est lu : ni calendriers partagés, ni boîtes de collègues, ni autres agendas du profil.
  • Pas de modification ni de suppression de rendez-vous, pas de réponse à une invitation.
  • Pas de gestion des fuseaux horaires : les heures sont celles de la machine.
  • Le résultat de read_calendar se limite à 200 rendez-vous.

Tests

274 tests (dotnet run --project Tests -c Release), dont les 10 nouveaux (CalendarTests.cs) :

  • les deux outils existent ; create_appointment demande confirmation, pas read_calendar ;
  • groupe calendar : mots déclencheurs en français et en anglais, pas de faux positif, reste actif une fois utilisé ;
  • hors Windows : erreur claire ;
  • dates ISO lues, fuseaux et textes libres refusés ;
  • période invalide, rendez-vous incohérent (fin avant début, durée, rappel, send sans participants, journée entière) refusés avant d'appeler Outlook ;
  • PowerShell de lecture : dates à format fixe, requête entre apostrophes, limites, marqueurs de donnée non fiable, aucune écriture ;
  • PowerShell de création : affichage par défaut, save, send, réunion sans invitation, journée entière, objet qui contient $(calc) ou une apostrophe, chevauchements non bloquants ;
  • section 19 du prompt système.
# CsAgent 0.9.10 — notes de version

La version 0.9.10 ajoute l'agenda Outlook : l'agent lit les rendez-vous d'une période et en crée, sans inscription Azure ni jeton. Elle fait suite à la 0.9.9.

Résumé

Domaine Ce qui change
Nouveaux outils read_calendar (lecture seule) et create_appointment (demande confirmation) : 37 outils au total
Groupe d'outils calendar, allumé par agenda, calendrier, rendez-vous, réunion, créneau, meeting… (voir 0.9.8)
Prompt système Nouvelle section 19 (agenda)
Tests 274 tests (10 de plus)

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

Notes de mise à jour

  1. Windows seulement, avec Outlook classique installé et configuré, comme send_email. Sous Linux et macOS, les deux outils répondent par une erreur claire.
  2. Rien n'est créé sans relecture. create_appointment demande confirmation, puis affiche le rendez-vous dans Outlook sans l'enregistrer. save: true l'enregistre ; send: true l'enregistre et envoie les invitations (irréversible, exige des participants).
  3. Aucune invitation par défaut. Donner des attendees fait du rendez-vous une réunion, mais rien ne part sans send: true.
  4. L'agent connaît la date du jour par read_calendar : la première ligne du résultat la donne avec le jour de la semaine. Le prompt système ne la contient pas (il est construit une fois par session et serait périmé le lendemain).
  5. Le test --no-compact supposait une taille exacte du prompt système : il accepte maintenant 6 à 8 résultats conservés.

Les deux outils

read_calendar — start (aujourd'hui par défaut), end (7 jours après start, 366 au plus ; une date seule inclut tout ce jour), query (objet ou lieu), max_items (50, 200 au plus). Les rendez-vous récurrents sont développés. Une ligne par rendez-vous :

2026-10-16 14:00-15:00 | Point d'équipe | Salle 3 | organizer: Marie Durand [meeting]

create_appointment — subject et start obligatoires ; end ou duration_minutes (60 par défaut) ; all_day ; location, body, attendees, reminder_minutes (0 : pas de rappel) ; save, send. Les chevauchements avec l'agenda sont signalés (« Warning: overlaps with … »), sans bloquer.

Les dates sont des heures locales ISO-8601 sans fuseau (2026-10-16T14:00). Elles sont renvoyées à PowerShell dans un format fixe : la langue de la machine ne change pas leur sens. Le texte (objet, lieu, notes) est transmis entre apostrophes, donc $(...) n'est jamais interprété. Le contenu de l'agenda est marqué comme donnée non fiable.

Limites

  • Non essayé avec un vrai Outlook : l'environnement de développement est sous Linux. Les tests couvrent les arguments, les dates et le PowerShell généré, pas l'appel COM lui-même. À vérifier sur Windows avant de s'y fier : le filtre de période (Restrict avec le format de date de la machine), les réunions avec participants, les journées entières.
  • Seul l'agenda par défaut est lu : ni calendriers partagés, ni boîtes de collègues, ni autres agendas du profil.
  • Pas de modification ni de suppression de rendez-vous, pas de réponse à une invitation.
  • Pas de gestion des fuseaux horaires : les heures sont celles de la machine.
  • Le résultat de read_calendar se limite à 200 rendez-vous.

Tests

274 tests (dotnet run --project Tests -c Release), dont les 10 nouveaux (CalendarTests.cs) :

  • les deux outils existent ; create_appointment demande confirmation, pas read_calendar ;
  • groupe calendar : mots déclencheurs en français et en anglais, pas de faux positif, reste actif une fois utilisé ;
  • hors Windows : erreur claire ;
  • dates ISO lues, fuseaux et textes libres refusés ;
  • période invalide, rendez-vous incohérent (fin avant début, durée, rappel, send sans participants, journée entière) refusés avant d'appeler Outlook ;
  • PowerShell de lecture : dates à format fixe, requête entre apostrophes, limites, marqueurs de donnée non fiable, aucune écriture ;
  • PowerShell de création : affichage par défaut, save, `...
Read more
Loading

csagent-mcpstdio

csagent-mcpstdio

Choose a tag to compare

View all tags
@artydev artydev released this 15 Oct 19:42
v0.9.9
35e2793

CsAgent 0.9.9 — notes de version

La version 0.9.9 étend le support MCP : serveurs locaux en stdio, plusieurs serveurs à la fois, en-têtes d'authentification. Elle fait suite à la 0.9.8.

Résumé

Domaine Ce qui change
Transports Streamable HTTP (comme avant) et stdio : CsAgent démarre le programme et échange des messages JSON, un par ligne
Plusieurs serveurs --mcp et --mcp-stdio sont répétables ; connexion en parallèle ; un serveur en panne donne un avertissement et les autres restent utilisables
Authentification --mcp-header "Nom: valeur" ; ${VAR} est remplacé par la variable d'environnement
Configuration --mcp-config (ou CSAGENT_MCP_CONFIG) : fichier JSON mcpServers
Tests 264 tests (17 de plus)

Nouvelle variable d'environnement : CSAGENT_MCP_CONFIG.

Notes de mise à jour

  1. Un seul serveur : rien ne change. Ses outils gardent le nom mcp_<nom>.
  2. Plusieurs serveurs : les outils s'appellent mcp_<serveur>_<nom>. Le nom du serveur vient du fichier de configuration, ou est déduit de l'URL (hôte) ou du programme (server-filesystem pour npx -y @modelcontextprotocol/server-filesystem).
  3. Une panne n'arrête plus l'exécution tant qu'au moins un serveur répond. Avant, un serveur injoignable arrêtait tout.
  4. Aucun chargement automatique. Un serveur stdio est un programme lancé avec vos droits : seuls --mcp-stdio et --mcp-config, que vous écrivez vous-même, en démarrent un. Aucun fichier du dossier de travail n'est lu.
  5. Les valeurs des en-têtes et de env ne sont jamais affichées (bannière, erreurs).
  6. Chaque appel MCP demande toujours confirmation, sauf avec --yes.

Brancher des serveurs

csagent --mcp https://api.exemple.com/mcp --mcp-header "Authorization: Bearer ${MCP_TOKEN}"
csagent --mcp-stdio "npx -y @modelcontextprotocol/server-filesystem ."
csagent --mcp-config mcp.json

{
  "mcpServers": {
    "fichiers": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "."] },
    "wiki":     { "url": "https://wiki.exemple.com/mcp", "headers": { "Authorization": "Bearer ${WIKI_TOKEN}" } }
  }
}
  • Chaque serveur a soit url (et headers), soit command (et args, env, cwd), jamais les deux.
  • Commentaires et virgules finales acceptés dans le fichier.
  • --mcp-header s'applique aux URL de --mcp ; sans URL, c'est une erreur.
  • Sous Windows, une commande sans extension (npx) passe par cmd.exe /c.
  • À la fin de l'exécution, CsAgent ferme l'entrée du programme, attend 500 ms, puis arrête le processus et ses enfants.

Limites

  • Outils seulement (ni ressources ni prompts) ; pas d'OAuth, seulement des en-têtes fixes.
  • Une demande à un serveur stdio dure 60 secondes au plus ; une demande à la fois par serveur.
  • Vérifié avec un faux serveur de test et avec le vrai @modelcontextprotocol/server-filesystem (Linux). Pas essayé sous Windows, ni avec ryaker/outlook-mcp, ni en publication native (AOT).

Tests

264 tests (dotnet run --project Tests -c Release), dont les 17 nouveaux (McpStdioTests.cs, faux serveur stdio lancé par les tests avec --mcp-echo) :

  • démarrage, échange et arrêt du programme ;
  • lignes parasites et notifications ignorées, requêtes du serveur refusées proprement ;
  • serveur qui se ferme, commande introuvable : erreur claire ;
  • plusieurs serveurs HTTP et stdio : noms mcp_<serveur>_<outil>, appel routé au bon serveur ;
  • un serveur en panne : avertissement, les autres restent utilisables ; tous en panne : erreur ;
  • en-têtes envoyés à chaque requête, ${VAR} développé, secrets absents des messages ;
  • fichier de configuration : formats valides et erreurs (ni url ni command, les deux…) ;
  • noms déduits de l'URL et du programme.
# CsAgent 0.9.9 — notes de version

La version 0.9.9 étend le support MCP : serveurs locaux en stdio, plusieurs serveurs à la fois, en-têtes d'authentification. Elle fait suite à la 0.9.8.

Résumé

Domaine Ce qui change
Transports Streamable HTTP (comme avant) et stdio : CsAgent démarre le programme et échange des messages JSON, un par ligne
Plusieurs serveurs --mcp et --mcp-stdio sont répétables ; connexion en parallèle ; un serveur en panne donne un avertissement et les autres restent utilisables
Authentification --mcp-header "Nom: valeur" ; ${VAR} est remplacé par la variable d'environnement
Configuration --mcp-config <fichier> (ou CSAGENT_MCP_CONFIG) : fichier JSON mcpServers
Tests 264 tests (17 de plus)

Nouvelle variable d'environnement : CSAGENT_MCP_CONFIG.

Notes de mise à jour

  1. Un seul serveur : rien ne change. Ses outils gardent le nom mcp_<nom>.
  2. Plusieurs serveurs : les outils s'appellent mcp_<serveur>_<nom>. Le nom du serveur vient du fichier de configuration, ou est déduit de l'URL (hôte) ou du programme (server-filesystem pour npx -y @modelcontextprotocol/server-filesystem).
  3. Une panne n'arrête plus l'exécution tant qu'au moins un serveur répond. Avant, un serveur injoignable arrêtait tout.
  4. Aucun chargement automatique. Un serveur stdio est un programme lancé avec vos droits : seuls --mcp-stdio et --mcp-config, que vous écrivez vous-même, en démarrent un. Aucun fichier du dossier de travail n'est lu.
  5. Les valeurs des en-têtes et de env ne sont jamais affichées (bannière, erreurs).
  6. Chaque appel MCP demande toujours confirmation, sauf avec --yes.

Brancher des serveurs

csagent --mcp https://api.exemple.com/mcp --mcp-header "Authorization: Bearer ${MCP_TOKEN}"
csagent --mcp-stdio "npx -y @modelcontextprotocol/server-filesystem ."
csagent --mcp-config mcp.json

{
  "mcpServers": {
    "fichiers": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "."] },
    "wiki":     { "url": "https://wiki.exemple.com/mcp", "headers": { "Authorization": "Bearer ${WIKI_TOKEN}" } }
  }
}
  • Chaque serveur a soit url (et headers), soit command (et args, env, cwd), jamais les deux.
  • Commentaires et virgules finales acceptés dans le fichier.
  • --mcp-header s'applique aux URL de --mcp ; sans URL, c'est une erreur.
  • Sous Windows, une commande sans extension (npx) passe par cmd.exe /c.
  • À la fin de l'exécution, CsAgent ferme l'entrée du programme, attend 500 ms, puis arrête le processus et ses enfants.

Limites

  • Outils seulement (ni ressources ni prompts) ; pas d'OAuth, seulement des en-têtes fixes.
  • Une demande à un serveur stdio dure 60 secondes au plus ; une demande à la fois par serveur.
  • Vérifié avec un faux serveur de test et avec le vrai @modelcontextprotocol/server-filesystem (Linux). Pas essayé sous Windows, ni avec ryaker/outlook-mcp, ni en publication native (AOT).

Tests

264 tests (dotnet run --project Tests -c Release), dont les 17 nouveaux (McpStdioTests.cs, faux serveur stdio lancé par les tests avec --mcp-echo) :

  • démarrage, échange et arrêt du programme ;
  • lignes parasites et notifications ignorées, requêtes du serveur refusées proprement ;
  • serveur qui se ferme, commande introuvable : erreur claire ;
  • plusieurs serveurs HTTP et stdio : noms mcp_<serveur>_<outil>, appel routé au bon serveur ;
  • un serveur en panne : avertissement, les autres restent utilisables ; tous en panne : erreur ;
  • en-têtes envoyés à chaque requête, ${VAR} développé, secrets absents des messages ;
  • fichier de configuration : formats valides et erreurs (ni url ni command, les deux…) ;
  • noms déduits de l'URL et du programme.
Loading

csagent-onlytools

csagent-onlytools

Choose a tag to compare

View all tags
@artydev artydev released this 15 Oct 17:01
v0.9.8
055a2c9

CsAgent 0.9.8 — notes de version

La version 0.9.8 envoie au modèle la description des seuls outils utiles à la demande, au lieu des 35 à chaque étape. Cela réduit les jetons d'entrée, donc la consommation du quota. Elle fait suite à la 0.9.7.

Résumé

Domaine Ce qui change
Outils décrits au modèle core (fichiers, recherche, shell) toujours ; git, web, courrier, audio, Excel, presse-papiers, archives, terminal, modèles seulement quand la demande en parle. Une demande de code ordinaire envoie environ 6 800 caractères d'outils au lieu de 20 400 (67 % de moins)
Nouvel outil enable_tools : l'agent rallume un groupe qui manque
Réglages Nouvel argument --all-tools : rétablit l'envoi de tous les outils
Tests 247 tests (9 de plus)
  • Les mots sont cherchés, en français et en anglais, dans le dernier message de l'utilisateur.
  • Un groupe dont un outil a déjà servi dans la conversation reste actif, même pour une relance courte (« et le deuxième ? »).
  • Un outil d'un groupe éteint, appelé quand même, rallume son groupe pour la suite de la demande.
  • Serveur MCP : ses outils sont tous envoyés tant que leurs descriptions tiennent en 4 000 caractères. Au-delà, ils ne le sont que si la demande dit « MCP » ou contient un mot du nom de l'un d'eux, ou après enable_tools avec le groupe mcp.
  • Un outil absent de la liste des groupes (par exemple un futur outil) est classé dans core, donc toujours envoyé.

Limites

  • La mesure (6 781 caractères au lieu de 20 420 pour une demande de code) est en caractères, pas en jetons, et n'a pas été faite sur le vrai serveur Albert.
  • Le choix repose sur des mots-clés : une demande qui n'en contient aucun mais a besoin d'un groupe coûte une étape de plus (enable_tools). Un mot courant peut aussi allumer un groupe inutilement (« modèle de données » allume models), ce qui coûte seulement des jetons.
  • Le prompt système (sections sur le courrier, l'audio, Excel…) n'est pas allégé : c'est un autre chantier.
  • La publication native (AOT) de cette version n'a pas été essayée dans l'environnement de développement.

Tests

247 tests (dotnet run --project Tests -c Release), dont les 9 nouveaux :

  • chaque outil est dans core ou dans un seul groupe, et --all-tools est lu sans être pris pour un nom de mémoire ;
  • une demande de code ordinaire n'envoie que core (67 % de caractères en moins) ;
  • les mots de la demande allument les bons groupes, en français et en anglais, sans faux positif sur une demande neutre ;
  • un groupe déjà utilisé reste actif pour une relance courte ;
  • enable_tools : listé tant qu'un groupe est éteint, allume un groupe, refuse un groupe inconnu, absent quand tout est allumé ;
  • outils MCP : envoyés s'ils sont peu nombreux, sinon seulement si la demande les nomme ou dit « MCP » ;
  • requêtes réelles : la première ne contient que core, la suivante contient le groupe allumé par enable_tools ;
  • un outil appelé alors que son groupe était éteint garde le groupe allumé ;
  • avec --all-tools, les 35 outils sont envoyés et enable_tools n'apparaît pas.
# CsAgent 0.9.8 — notes de version

La version 0.9.8 envoie au modèle la description des seuls outils utiles à la demande, au lieu des 35 à chaque étape. Cela réduit les jetons d'entrée, donc la consommation du quota. Elle fait suite à la 0.9.7.

Résumé

Domaine Ce qui change
Outils décrits au modèle core (fichiers, recherche, shell) toujours ; git, web, courrier, audio, Excel, presse-papiers, archives, terminal, modèles seulement quand la demande en parle. Une demande de code ordinaire envoie environ 6 800 caractères d'outils au lieu de 20 400 (67 % de moins)
Nouvel outil enable_tools : l'agent rallume un groupe qui manque
Réglages Nouvel argument --all-tools : rétablit l'envoi de tous les outils
Tests 247 tests (9 de plus)

Aucune variable d'environnement ni fichier de configuration n'est ajouté.

Notes de mise à jour

  1. Le comportement par défaut change. Une demande qui ne parle ni de git, ni du web, ni d'e-mails, d'audio, d'Excel, du presse-papiers, d'archives, de terminal ou de modèle ne décrit plus ces outils au modèle. --all-tools rétablit l'ancien envoi.
  2. Rien n'est interdit. Un outil qui n'est pas décrit reste exécutable s'il est appelé ; le groupe de l'outil appelé est alors rallumé pour les étapes suivantes.
  3. enable_tools apparaît dans la liste tant qu'un groupe est éteint. Sa description nomme les groupes éteints et leurs outils.
  4. Le prompt système, lui, cite toujours tous les outils par leur nom : ce texte n'a pas changé.

Les outils envoyés à chaque étape

À chaque étape, CsAgent renvoie au modèle la conversation, mais aussi la description de tous les outils (environ 20 000 caractères). Une demande de correction de code n'a pas besoin de lire des .msg ni de piloter Excel.

Groupe Outils Envoyé
core read_file, write_file, edit_file, copy_file, move_file, delete_file, read_json, parse_output, list_dir, tree, search_files, sh toujours
git git_status, git_diff, git_log, git_branch, git_commit git, commit, branche, diff…
web web_search, fetch_url, http_request web, URL, recherche, actualités…
mail read_msg, save_attachment, group_msg_by_sender, send_email e-mail, Outlook, .msg, expéditeur…
audio transcribe_audio audio, enregistrement, transcription…
office excel_command, close_excel Excel, tableur, .xlsx…
clipboard read_clipboard, write_clipboard presse-papiers, « ce que j'ai copié »…
archive zip, unzip archive, zip…
terminal run_terminal, close_terminal terminal, serveur de dev…
models switch_model, list_models modèle, LLM…
  • Les mots sont cherchés, en français et en anglais, dans le dernier message de l'utilisateur.
  • Un groupe dont un outil a déjà servi dans la conversation reste actif, même pour une relance courte (« et le deuxième ? »).
  • Un outil d'un groupe éteint, appelé quand même, rallume son groupe pour la suite de la demande.
  • Serveur MCP : ses outils sont tous envoyés tant que leurs descriptions tiennent en 4 000 caractères. Au-delà, ils ne le sont que si la demande dit « MCP » ou contient un mot du nom de l'un d'eux, ou après enable_tools avec le groupe mcp.
  • Un outil absent de la liste des groupes (par exemple un futur outil) est classé dans core, donc toujours envoyé.

Limites

  • La mesure (6 781 caractères au lieu de 20 420 pour une demande de code) est en caractères, pas en jetons, et n'a pas été faite sur le vrai serveur Albert.
  • Le choix repose sur des mots-clés : une demande qui n'en contient aucun mais a besoin d'un groupe coûte une étape de plus (enable_tools). Un mot courant peut aussi allumer un groupe inutilement (« modèle de données » allume models), ce qui coûte seulement des jetons.
  • Le prompt système (sections sur le courrier, l'audio, Excel…) n'est pas allégé : c'est un autre chantier.
  • La publication native (AOT) de cette version n'a pas été essayée dans l'environnement de développement.

Tests

247 tests (dotnet run --project Tests -c Release), dont les 9 nouveaux :

  • chaque outil est dans core ou dans un seul groupe, et --all-tools est lu sans être pris pour un nom de mémoire ;
  • une demande de code ordinaire n'envoie que core (67 % de caractères en moins) ;
  • les mots de la demande allument les bons groupes, en français et en anglais, sans faux positif sur une demande neutre ;
  • un groupe déjà utilisé reste actif pour une relance courte ;
  • enable_tools : listé tant qu'un groupe est éteint, allume un groupe, refuse un groupe inconnu, absent quand tout est allumé ;
  • outils MCP : envoyés s'ils sont peu nombreux, sinon seulement si la demande les nomme ou dit « MCP » ;
  • requêtes réelles : la première ne contient que core, la suivante contient le groupe allumé par enable_tools ;
  • un outil appelé alors que son groupe était éteint garde le groupe allumé ;
  • avec --all-tools, les 35 outils sont envoyés et enable_tools n'apparaît pas.
Loading

csagent-mailgrouper

csagent-mailgrouper

Choose a tag to compare

View all tags
@artydev artydev released this 14 Oct 12:29
v0.9.7
877a000

CsAgent 0.9.7 — notes de version

La version 0.9.7 ajoute l'outil group_msg_by_sender, qui range des e-mails Outlook .msg par expéditeur après avoir renommé les fichiers en noms ASCII. Elle fait suite à la 0.9.6.

Résumé

Domaine Ce qui change
Nouvel outil group_msg_by_sender : renomme les .msg d'un dossier en noms ASCII (sans accents, espaces ni caractères spéciaux), puis les range dans un sous-dossier par expéditeur. 35 outils au lieu de 34
Documentation README, docs/index.html, docs/guide-csagent.html et docs/slides.html : 35 outils, description de l'outil. Le numéro de version de l'interface web (qui affichait encore v0.9.5) est corrigé
Tests 238 tests (7 de plus)

Aucune variable d'environnement, aucun argument et aucun fichier de configuration ne sont ajoutés.

Notes de mise à jour

  1. Un outil de plus. group_msg_by_sender demande confirmation (comme save_attachment), sauf avec --yes. L'agent ne l'utilise que si la demande parle de ranger des .msg.
  2. Le reste du comportement est inchangé : --prompt garde le mode script de la 0.9.6.

L'outil group_msg_by_sender

csagent --prompt "range les .msg de ce dossier par expéditeur" --yes

Les noms de fichiers d'e-mails contiennent souvent des accents, des espaces et des caractères spéciaux, ce qui gêne les outils et les scripts. L'outil procède donc en deux étapes, dans cet ordre :

  1. Renommage. Chaque .msg reçoit un nom sans accents, espaces ni caractères spéciaux : Rapport trimestriel é.msg devient Rapport_trimestriel_e.msg. Les lettres latines accentuées sont ramenées à leur forme simple (é → e, ß → ss, Œ → OE), tout autre caractère devient _.
  2. Rangement. L'expéditeur est lu dans le message et le fichier est déplacé dans un sous-dossier à son nom, lui aussi en ASCII (Jérôme Dupont → Jerome_Dupont). Sans expéditeur : UnknownSender.
  • Paramètres : directory (par défaut le dossier courant), group_by (name par défaut, ou email pour distinguer deux personnes de même nom), rename (false garde les noms d'origine).
  • Seuls les .msg placés directement dans le dossier sont traités ; 5 000 fichiers au plus par appel.
  • Rien n'est écrasé : un nom déjà pris reçoit (1), (2)… Deux fichiers dont les noms deviennent identiques sont donc tous deux conservés.
  • Un fichier illisible reste en place (renommé) et est signalé ; le compte rendu indique les fichiers renommés et déplacés, et le nombre de messages par expéditeur.
  • C'est du C# pur : il fonctionne sur tous les systèmes et ne nécessite pas Outlook.

Limites

  • Les lettres latines (Europe occidentale et centrale) sont ramenées à l'ASCII ; les autres écritures (cyrillique, grec, chinois…) deviennent _, et un expéditeur écrit uniquement ainsi va dans UnknownSender.
  • L'outil n'a pas été essayé avec un vrai modèle sur de vrais .msg, seulement par les tests.
  • La publication native (AOT) de cette version n'a pas été essayée dans l'environnement de développement.

Tests

238 tests (dotnet run --project Tests -c Release), dont les 7 nouveaux :

  • les noms sont ramenés à l'ASCII (accents, espaces, caractères interdits, noms réservés, longueur, accent séparé) ;
  • l'outil demande confirmation ;
  • les fichiers sont renommés puis rangés dans un dossier ASCII par expéditeur ;
  • les noms devenus identiques sont conservés tous les deux, et un fichier illisible reste en place avec une erreur signalée ;
  • un fichier déjà présent dans le dossier de l'expéditeur n'est jamais écrasé ;
  • rename=false garde les noms, group_by=email sépare deux personnes de même nom ;
  • un dossier hors du répertoire de travail, absent ou sans .msg, et une valeur de group_by invalide, sont refusés ou signalés.
# CsAgent 0.9.7 — notes de version

La version 0.9.7 ajoute l'outil group_msg_by_sender, qui range des e-mails Outlook .msg par expéditeur après avoir renommé les fichiers en noms ASCII. Elle fait suite à la 0.9.6.

Résumé

Domaine Ce qui change
Nouvel outil group_msg_by_sender : renomme les .msg d'un dossier en noms ASCII (sans accents, espaces ni caractères spéciaux), puis les range dans un sous-dossier par expéditeur. 35 outils au lieu de 34
Documentation README, docs/index.html, docs/guide-csagent.html et docs/slides.html : 35 outils, description de l'outil. Le numéro de version de l'interface web (qui affichait encore v0.9.5) est corrigé
Tests 238 tests (7 de plus)

Aucune variable d'environnement, aucun argument et aucun fichier de configuration ne sont ajoutés.

Notes de mise à jour

  1. Un outil de plus. group_msg_by_sender demande confirmation (comme save_attachment), sauf avec --yes. L'agent ne l'utilise que si la demande parle de ranger des .msg.
  2. Le reste du comportement est inchangé : --prompt garde le mode script de la 0.9.6.

L'outil group_msg_by_sender

csagent --prompt "range les .msg de ce dossier par expéditeur" --yes

Les noms de fichiers d'e-mails contiennent souvent des accents, des espaces et des caractères spéciaux, ce qui gêne les outils et les scripts. L'outil procède donc en deux étapes, dans cet ordre :

  1. Renommage. Chaque .msg reçoit un nom sans accents, espaces ni caractères spéciaux : Rapport trimestriel é.msg devient Rapport_trimestriel_e.msg. Les lettres latines accentuées sont ramenées à leur forme simple (é → e, ß → ss, Œ → OE), tout autre caractère devient _.
  2. Rangement. L'expéditeur est lu dans le message et le fichier est déplacé dans un sous-dossier à son nom, lui aussi en ASCII (Jérôme Dupont → Jerome_Dupont). Sans expéditeur : UnknownSender.
  • Paramètres : directory (par défaut le dossier courant), group_by (name par défaut, ou email pour distinguer deux personnes de même nom), rename (false garde les noms d'origine).
  • Seuls les .msg placés directement dans le dossier sont traités ; 5 000 fichiers au plus par appel.
  • Rien n'est écrasé : un nom déjà pris reçoit (1), (2)… Deux fichiers dont les noms deviennent identiques sont donc tous deux conservés.
  • Un fichier illisible reste en place (renommé) et est signalé ; le compte rendu indique les fichiers renommés et déplacés, et le nombre de messages par expéditeur.
  • C'est du C# pur : il fonctionne sur tous les systèmes et ne nécessite pas Outlook.

Limites

  • Les lettres latines (Europe occidentale et centrale) sont ramenées à l'ASCII ; les autres écritures (cyrillique, grec, chinois…) deviennent _, et un expéditeur écrit uniquement ainsi va dans UnknownSender.
  • L'outil n'a pas été essayé avec un vrai modèle sur de vrais .msg, seulement par les tests.
  • La publication native (AOT) de cette version n'a pas été essayée dans l'environnement de développement.

Tests

238 tests (dotnet run --project Tests -c Release), dont les 7 nouveaux :

  • les noms sont ramenés à l'ASCII (accents, espaces, caractères interdits, noms réservés, longueur, accent séparé) ;
  • l'outil demande confirmation ;
  • les fichiers sont renommés puis rangés dans un dossier ASCII par expéditeur ;
  • les noms devenus identiques sont conservés tous les deux, et un fichier illisible reste en place avec une erreur signalée ;
  • un fichier déjà présent dans le dossier de l'expéditeur n'est jamais écrasé ;
  • rename=false garde les noms, group_by=email sépare deux personnes de même nom ;
  • un dossier hors du répertoire de travail, absent ou sans .msg, et une valeur de group_by invalide, sont refusés ou signalés.
Loading

csagent-scriptmode

csagent-scriptmode

Choose a tag to compare

View all tags
@artydev artydev released this 14 Oct 06:24
v0.9.6
55184dd

CsAgent 0.9.6 — notes de version

La version 0.9.6 rend csagent --prompt "…" utilisable dans un script : seule la réponse finale est écrite sur la sortie standard, de sorte qu'elle peut être redirigée vers une autre commande. Elle fait suite à la 0.9.5.

Résumé

Domaine Ce qui change
--prompt Seule la réponse finale est écrite sur la sortie standard : plus de bannière, de ligne de version, d'étapes, d'appels d'outils, de résultats, de modèle ni de jetons
Erreurs Avertissements et erreurs vont sur la sortie d'erreur ; code de sortie 1 si l'agent signale une erreur
Confirmations Si l'entrée est redirigée, un outil qui demande confirmation est refusé (utilisez --yes)
Réglages Nouvel argument --verbose : avec --prompt, rétablit l'affichage complet
Documentation README, --help, docs/index.html, docs/guide-csagent.html et docs/slides.html mis à jour
Corrections Le projet de tests compile ScriptObserver.cs ; le script de docs/guide-csagent.html ne produit plus d'erreurs de typage dans Visual Studio
Tests 231 tests (7 de plus)

Aucune variable d'environnement ou fichier de configuration n'est ajouté.

Notes de mise à jour

  1. La sortie de --prompt change. Un script qui lisait la bannière, les étapes ou la ligne du modèle ne les trouvera plus. --verbose rétablit l'ancien affichage.
  2. --quiet n'a plus d'effet par défaut avec --prompt, puisque le mode est déjà réduit à la réponse ; il agit de nouveau avec --verbose.
  3. Une confirmation est refusée si l'entrée est redirigée (… | csagent --prompt …, < fichier). Sans clavier, personne ne peut répondre : l'action est refusée et un message sur la sortie d'erreur indique --yes.

Les modes interactif, --ui, --leanui et --api ne changent pas. Les fichiers de mémoire, LLMRoutingRules et skills/ non plus.

Le mode script de --prompt

csagent --prompt "liste les fichiers ici" --yes | clip
  • Sortie standard : la réponse finale de l'assistant, en texte brut. Les messages intermédiaires (« Je regarde… ») ne sont pas écrits.
  • Sortie d'erreur : les erreurs, les avertissements, les alertes de danger, les appels d'outils en échec (une ligne), les notes de routage et la clé API manquante. Les avis de routine « Session summary updated / unchanged / loaded » ne sont plus affichés ; un échec de la mise à jour du résumé reste signalé.
  • Code de sortie : 1 si l'agent signale une erreur (par exemple le nombre maximal d'étapes atteint) ou si la demande échoue, sinon 0. Sans texte, --prompt affiche l'usage (code 2), comme avant.
  • Avec un clavier, la question de confirmation est posée sur la sortie d'erreur.
  • La conversation est enregistrée dans le dossier de mémoire comme d'habitude.

Limites

  • Seule la réponse finale est écrite : si l'agent produit plusieurs messages de réponse au fil des étapes, les premiers ne sont pas conservés.
  • Le mode script n'a pas été essayé avec le vrai serveur Albert, seulement avec un faux serveur.
  • La publication native (AOT) de cette version n'a pas été essayée dans l'environnement de développement.

Tests

231 tests (dotnet run --project Tests -c Release), dont les 7 nouveaux :

  • --verbose est lu, désactivé par défaut, et n'est pas pris pour un nom de mémoire ;
  • la sortie standard ne contient que la réponse finale ;
  • un appel d'outil en échec va sur la sortie d'erreur, jamais sur la sortie standard ;
  • une erreur va sur la sortie d'erreur et demande le code de sortie 1 ;
  • les échecs de mémoire sont signalés, les avis de routine non ;
  • la confirmation est refusée si l'entrée est redirigée ;
  • la confirmation est posée sur la sortie d'erreur quand un clavier est là.
# CsAgent 0.9.6 — notes de version

La version 0.9.6 rend csagent --prompt "…" utilisable dans un script : seule la réponse finale est écrite sur la sortie standard, de sorte qu'elle peut être redirigée vers une autre commande. Elle fait suite à la 0.9.5.

Résumé

Domaine Ce qui change
--prompt Seule la réponse finale est écrite sur la sortie standard : plus de bannière, de ligne de version, d'étapes, d'appels d'outils, de résultats, de modèle ni de jetons
Erreurs Avertissements et erreurs vont sur la sortie d'erreur ; code de sortie 1 si l'agent signale une erreur
Confirmations Si l'entrée est redirigée, un outil qui demande confirmation est refusé (utilisez --yes)
Réglages Nouvel argument --verbose : avec --prompt, rétablit l'affichage complet
Documentation README, --help, docs/index.html, docs/guide-csagent.html et docs/slides.html mis à jour
Corrections Le projet de tests compile ScriptObserver.cs ; le script de docs/guide-csagent.html ne produit plus d'erreurs de typage dans Visual Studio
Tests 231 tests (7 de plus)

Aucune variable d'environnement ou fichier de configuration n'est ajouté.

Notes de mise à jour

  1. La sortie de --prompt change. Un script qui lisait la bannière, les étapes ou la ligne du modèle ne les trouvera plus. --verbose rétablit l'ancien affichage.
  2. --quiet n'a plus d'effet par défaut avec --prompt, puisque le mode est déjà réduit à la réponse ; il agit de nouveau avec --verbose.
  3. Une confirmation est refusée si l'entrée est redirigée (… | csagent --prompt …, < fichier). Sans clavier, personne ne peut répondre : l'action est refusée et un message sur la sortie d'erreur indique --yes.

Les modes interactif, --ui, --leanui et --api ne changent pas. Les fichiers de mémoire, LLMRoutingRules et skills/ non plus.

Le mode script de --prompt

csagent --prompt "liste les fichiers ici" --yes | clip
  • Sortie standard : la réponse finale de l'assistant, en texte brut. Les messages intermédiaires (« Je regarde… ») ne sont pas écrits.
  • Sortie d'erreur : les erreurs, les avertissements, les alertes de danger, les appels d'outils en échec (une ligne), les notes de routage et la clé API manquante. Les avis de routine « Session summary updated / unchanged / loaded » ne sont plus affichés ; un échec de la mise à jour du résumé reste signalé.
  • Code de sortie : 1 si l'agent signale une erreur (par exemple le nombre maximal d'étapes atteint) ou si la demande échoue, sinon 0. Sans texte, --prompt affiche l'usage (code 2), comme avant.
  • Avec un clavier, la question de confirmation est posée sur la sortie d'erreur.
  • La conversation est enregistrée dans le dossier de mémoire comme d'habitude.

Limites

  • Seule la réponse finale est écrite : si l'agent produit plusieurs messages de réponse au fil des étapes, les premiers ne sont pas conservés.
  • Le mode script n'a pas été essayé avec le vrai serveur Albert, seulement avec un faux serveur.
  • La publication native (AOT) de cette version n'a pas été essayée dans l'environnement de développement.

Tests

231 tests (dotnet run --project Tests -c Release), dont les 7 nouveaux :

  • --verbose est lu, désactivé par défaut, et n'est pas pris pour un nom de mémoire ;
  • la sortie standard ne contient que la réponse finale ;
  • un appel d'outil en échec va sur la sortie d'erreur, jamais sur la sortie standard ;
  • une erreur va sur la sortie d'erreur et demande le code de sortie 1 ;
  • les échecs de mémoire sont signalés, les avis de routine non ;
  • la confirmation est refusée si l'entrée est redirigée ;
  • la confirmation est posée sur la sortie d'erreur quand un clavier est là.
Loading