Notes de version d’Eigent v1.0.4 : tableaux de bord Skills et Connectors, exécutions multitours fiables

Eigent v1.0.4 est une version consacrée à la lisibilité du workspace. Skills et Connectors étaient auparavant des cartes de réglages empilées ; ce sont désormais des tableaux de bord façon bibliothèque, avec de véritables vues de collection, des pages de détail et une coquille de page partagée qu’utilisent Home, Skills et Connectors.

Sous cette surface, cette version comble un ensemble précis de manques apparus lorsque les tâches ont commencé à durer plus longtemps : des instructions perdues entre deux tours enchaînés du modèle, des points de contrôle en échec dès qu’une tâche clonait un dépôt dans un Space, des connecteurs affichant un état différent de celui du runtime qui allait réellement les exécuter, et l’application qui ne s’arrêtait pas complètement à la fermeture de sa dernière fenêtre.

---

🧩 Skills et Connectors comme tableaux de bord de gestion

Gérer une Skill ne devrait pas consister à faire défiler une page de réglages jusqu’à trouver la bonne carte.

Merci à @Douglasymlai d’avoir reconstruit Skills et Connectors en surfaces de collection et de détail dans la PR #1896, et à @4pmtong pour la relecture.

Skills est maintenant un tableau de bord façon bibliothèque. Chaque Skill s’ouvre dans une vue de détail dédiée qui montre son origine, les accès dont elle dispose, si elle est activée et quels fichiers elle contient. Connectors suit le même modèle : une vue d’ensemble de la collection, un parcours d’ajout et d’exploration, et un en-tête de profil avec l’icône, le nom, la source et l’action d’installation ou d’enregistrement.

Nouveautés :

• Tableau de bord de la bibliothèque de Skills — parcourez vos Skills comme une collection, et non comme une pile de cartes de réglages
• Vues de détail des Skills — étiquettes de source et d’accès, état d’activation et explorateur de fichiers au même endroit
• Collection et découverte des Connectors — un chemin plus clair entre l’exploration des connecteurs disponibles et leur configuration
• En-tête de détail du connecteur — icône, nom, source et action d’installation ou d’enregistrement présentés comme un profil
• Barres latérales de détail — le contexte d’appui reste à côté de la ressource que vous inspectez

La différence concrète, c’est l’inspection. Vous pouvez répondre à « d’où vient cette Skill, à quoi peut-elle accéder et que contient-elle » sans quitter la page où vous avez commencé.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1896

---

🏠 Une coquille de page unique pour Home, Skills et Connectors

La cohérence devient une fonctionnalité quand on parcourt la même application tous les jours.

v1.0.4 unifie Home et Réglages dans une seule coquille de page, bâtie sur des primitives partagées : une barre d’outils de collection, un fil d’Ariane, un rail de contenu et un en-tête de retour dans la barre latérale. Les listes du hub Home, les états vides et les onglets de détail des Spaces s’alignent désormais sur la mise en page de collection utilisée par Skills et Connectors.

Améliorations :

• Mises en page partagées — le même en-tête, le même fil d’Ariane et le même rail de lecture dans Home, Skills et Connectors
• Listes de collection cohérentes — les listes du hub et les onglets de détail des Spaces suivent un seul modèle de mise en page
• États vides plus clairs — une surface non configurée s’explique au lieu d’afficher un panneau blanc
• Navigation prévisible — fils d’Ariane et en-têtes de retour se comportent partout de la même façon

Une fois la coquille partagée, passer de Home à un Space, à une Skill puis à un Connector n’oblige plus à réapprendre la page à chaque fois.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1896

---

🔁 Un travail multitours qui conserve ses instructions

Une tâche longue est une chaîne de tours, et chaque tour a besoin des mêmes instructions de confiance.

Merci à @4pmtong d’avoir corrigé les échecs de Prompt Guard sur les requêtes enchaînées de la Responses API dans la PR #1883.

La première requête de la chaîne réussissait, et c’est pourquoi la régression est restée invisible. Les requêtes suivantes réutilisaient previous_response_id, mais les instructions de premier niveau n’étaient pas reportées automatiquement — le prompt d’agent de confiance disparaissait donc silencieusement en cours d’exécution.

Corrections :

• Des instructions à chaque requête — le prompt d’agent de confiance est envoyé dans les instructions de la Responses API à chaque tour, et pas seulement au premier
• Plus de contenu de prompt dupliqué — les éléments system et developer sont retirés de l’entrée une fois promus en instructions, ce qui évite jetons et facturation en double
• Prompt Guard intact — le message de rejet existant pour les prompts non fiables est conservé

C’est le genre de bogue qui n’apparaît qu’avec la durée. Les tâches courtes semblaient correctes ; la panne se logeait au troisième tour.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1883

---

🧰 Des outils aux schémas de paramètres dynamiques

Tous les outils n’ont pas une forme figée, et une validation stricte des schémas ne devrait pas rejeter ceux qui n’en ont pas.

Merci à @fengju0213 d’avoir fait passer camel-ai[eigent] en 0.2.91a7 et rafraîchi le lockfile du backend dans la PR #1897.

La nouvelle version de CAMEL inclut le repli de schéma strict nécessaire aux paramètres d’outil contenant des correspondances ouvertes. Grâce à lui, PlanningWorktreeToolkit.planning_exit_plan_mode conserve son additionalProperties à valeur de schéma et est émis avec strict: false, ce qui évite une réponse 400 côté fournisseur tout en préservant les champs de dictionnaire dynamiques dont l’outil a réellement besoin.

Les outils dotés de paramètres ouverts fonctionnent désormais avec les fournisseurs qui imposent des schémas stricts, au lieu d’échouer au moment de l’appel.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1897

---

🌿 Dépôts imbriqués dans les Spaces adossés à Git

v1.0.3 a doté les Spaces d’un historique de versions adossé à Git. v1.0.4 fait en sorte que cet historique survive à une tâche qui clone un dépôt à l’intérieur d’un Space.

Merci à @4pmtong d’avoir pris en charge les dépôts imbriqués dans les points de contrôle du workspace dans la PR #1902.

Git signale un dépôt imbriqué non suivi comme une seule entrée de répertoire, du type ?? child-repository/. Le pipeline de points de contrôle normalisait ce chemin en child-repository, ce qui faisait échouer la validation des chemins alors que le clonage était déjà terminé : le résultat de l’outil était marqué comme inconnu et l’exécution échouait.

Corrections :

• Les dépôts imbriqués sont des frontières indépendantes — une racine Git imbriquée, non suivie et vérifiée est exclue du point de contrôle et du statut du dépôt parent
• Ni gitlink implicite ni modification des fichiers d’exclusion — le dépôt parent n’est pas restructuré en silence pour accueillir l’enfant
• L’état du parent reste inchangé — HEAD, jeton d’état et chemins suivis restent intacts à la fin du point de contrôle
• Le contenu de l’enfant reste intact — le dépôt imbriqué et ses commits sont préservés
• La sûreté du worktree est maintenue — les worktrees isolés ne sont pas nettoyés tant qu’ils contiennent un dépôt imbriqué non fusionné

Cloner un dépôt dans un Space est un travail d’agent tout à fait ordinaire. Depuis cette version, cela ne met plus fin à l’exécution.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1902

---

🔌 Des états de connecteur fidèles au runtime

Un connecteur qui annonce un état erroné est pire qu’un connecteur qui n’annonce rien.

Deux correctifs de @4pmtong traitent les deux faces du même problème.

La recherche web se cachait précisément quand il fallait la configurer. Pour les personnes dont le modèle par défaut est personnalisé, la recherche web était considérée comme déconnectée tant que Querit n’était pas activé ou que les identifiants Google Search n’étaient pas renseignés — et la vue d’ensemble des Connectors filtrait tous les connecteurs intégrés déconnectés. Or cette ligne est aussi le point d’entrée vers son panneau de réglages : les utilisateurs concernés n’avaient donc aucun moyen de la configurer. La recherche web reste maintenant visible et affiche son état réel, Non connecté, tandis que les modèles gérés conservent leur état Connecté. Le filtrage reste inchangé pour tous les autres connecteurs intégrés déconnectés.

Slack s’affichait comme connecté alors qu’il ne l’était pas. En mode hébergé, l’interface de réglages traitait la présence d’un groupe de configuration Slack local comme une connexion valide, alors que les tâches hébergées exécutent les actions Slack via Connector Gateway — où la même personne peut n’avoir aucune connexion Slack. Résultat : un badge « connecté » suivi d’une erreur de connexion introuvable à l’exécution. Les connecteurs intégrés dont le parcours de première connexion relève de Connector Gateway suivent désormais une politique centralisée : Gateway activé, le Slack intégré est masqué de la page Connectors, du sélecteur de connecteurs du chat et de la sélection d’outils d’un nouveau Worker. Gateway désactivé, le Slack intégré reste disponible pour les runtimes purement locaux.

Dans les deux cas, l’exécution du toolkit Slack, la configuration enregistrée, la compatibilité des Workers sauvegardés et les identifiants des déclencheurs Slack continuent de fonctionner.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1890

🔗 PR : https://github.com/eigent-ai/eigent/pull/1892

---

🖥️ Un arrêt propre à la fermeture de la dernière fenêtre

Fermer l’application devrait mettre fin à l’application.

Merci à @4pmtong d’avoir corrigé le cycle de vie d’arrêt dans la PR #1891. Fermer l’unique fenêtre quitte désormais Eigent proprement sur toutes les plateformes, et arrête le backend local avec elle.

Corrections :

• Un seul chemin de sortie — la fermeture native de la fenêtre, l’IPC de fermeture et la commande de menu Fermer la fenêtre passent tous par le même flux protégé quit-app
• macOS quitte aussi à la dernière fenêtre — window-all-closed provoque maintenant la sortie sur macOS comme sur Windows et Linux, si bien que before-quit nettoie le backend local
• Démontage sûr — la référence liée à webContents est conservée au lieu d’être lue depuis un BrowserWindow déjà détruit
• Les objets détruits sont ignorés — le retrait des écouteurs est sauté pour les fenêtres et web contents détruits, et les références du coordinateur sont libérées avant le démontage

Le même bénéfice vaut côté développement : npm run dev se termine désormais au lieu de laisser un backend tourner derrière une fenêtre fermée.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1891

---

🧹 Des tâches de génération web qui se terminent vraiment

Certaines tâches de génération web ne se terminaient pas. La cause s’est révélée double.

Merci à @4pmtong pour le correctif sûr pour la version dans la PR #1907.

Eigent n’a plus besoin d’envoyer le contenu généré vers l’ancien service de déploiement distant : Web Deploy Toolkit est donc retiré de l’assemblage du Developer Agent de Workforce et de l’agent unique, et les mentions de déploiement disparaissent du prompt du Developer Agent, de la description du coordinateur Workforce et des listes de capacités des workflows. Les configurations héritées qui réclament encore web_deploy.enabled=true sont ignorées. web_deploy_toolkit.py et sa prise en charge historique du rendu restent dans le code pour un usage futur éventuel.

La seconde cause tenait au minutage. Le budget de point de contrôle du nettoyage en arrière-plan du terminal passe de 5 à 30 secondes, laissant à un serveur de prévisualisation arrêté le temps de libérer son bail d’écriture et d’achever le point de contrôle Git du workspace avant la finalisation de l’exécution.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1907

---

⚙️ Des garde-fous plus rapides pour les contributions

Une CI lente est un impôt prélevé sur tous ceux qui ouvrent une pull request.

Le job de garde-fous du frontend prenait couramment 20 à 30 minutes : il exécutait la suite Vitest complète pour le commit de base et celui de la pull request, cache désactivé, puis relançait les échecs face à une référence contenant déjà des échecs connus et des délais de 29 secondes.

Merci à @4pmtong d’avoir remplacé cette comparaison de suite complète par un exécuteur ciblé dans la PR #1898.

Améliorations :

• Exécuteur des tests modifiés — seuls les fichiers de test frontend ajoutés ou modifiés par le changement sont exécutés
• Vérifications rapides d’abord — types, Electron, système de design et formatage passent avant Vitest
• Annulation des exécutions dépassées — un nouveau push annule l’exécution précédente du workflow Test pour la même pull request ou branche
• Délai réduit — le budget des garde-fous frontend passe de 30 à 15 minutes

Lors d’un rejeu sur le changement fusionné par la PR #1891, l’exécuteur des tests modifiés a traité 4 fichiers de test et 134 tests en 1,07 seconde.

🔗 PR : https://github.com/eigent-ai/eigent/pull/1898

---

🔁 Compatibilité avec le travail existant

Les Spaces, Sessions, tâches, réglages de Skills, Workers sauvegardés et configurations de connecteur existants restent disponibles après la mise à jour vers v1.0.4. L’expérience par défaut ne demande aucune configuration supplémentaire.

Les intégrations purement locales sont explicitement préservées. Connector Gateway désactivé, le Slack intégré, les Workers sauvegardés et les déclencheurs Slack continuent de fonctionner, et la configuration Slack enregistrée reste intacte dans les deux modes.

---

❤️ Un workspace qui s’explique de lui-même

Eigent v1.0.4 apporte :

• Skills sous forme de tableau de bord bibliothèque, avec vues détaillées de source, d’accès, d’activation et de fichiers
• Connectors sous forme de parcours collection, découverte et détail de profil
• Une coquille de page partagée offrant fils d’Ariane, barres latérales, rails de contenu et états vides cohérents dans Home, Skills et Connectors
• Des instructions d’agent de confiance conservées entre les tours enchaînés de la Responses API, sans contenu de prompt dupliqué
• Une compatibilité avec les schémas stricts pour les outils aux paramètres dynamiques
• Des dépôts Git imbriqués traités comme des frontières indépendantes lors des points de contrôle du workspace
• Une recherche web qui reste visible tant qu’elle attend une configuration
• Slack présenté par le chemin de connecteur qui l’exécutera réellement
• Un arrêt propre de l’application et du backend local à la fermeture de la dernière fenêtre
• Une fin plus fiable des tâches de génération web et un meilleur nettoyage des processus d’arrière-plan
• Un garde-fou CI frontend qui s’exécute en minutes plutôt qu’en une demi-heure

Le thème de cette version, c’est la lisibilité. Un tableau de bord vous dit ce qu’une Skill peut atteindre. Un état de connecteur vous dit quel runtime l’exécutera. Un point de contrôle vous dit quel dépôt possède un changement. Et une tâche qui tourne longtemps garde les instructions avec lesquelles elle a commencé.

Le travail que l’on peut inspecter est le travail auquel on peut se fier.

🔗 Version : https://github.com/eigent-ai/eigent/releases/tag/v1.0.4

🔗 Journal complet : https://github.com/eigent-ai/eigent/compare/v1.0.3...v1.0.4

Continuons à construire.