À propos du projet

Agent Fleet est une console auto-hébergée permettant d'exécuter des agents de codage IA sous forme de flotte. Son argument principal est que vous pouvez fermer votre ordinateur portable et que les agents continuent de travailler : une équipe partage des agents depuis une console de navigateur, et les membres vérifient la progression ou envoient l'instruction suivante via Discord, Slack ou un téléphone au lieu de rester devant un terminal. Les CLI d'agents supportées mentionnées dans le README sont Claude Code, Codex CLI, GitHub Copilot CLI, Antigravity CLI, Cursor CLI, Kiro et OpenCode. Chaque membre de l'équipe dispose d'un environnement isolé par utilisateur — un conteneur Docker avec des quotas CPU et mémoire cgroup, ou un bac à sable bubblewrap dans l'édition native sans Docker — avec un répertoire personnel persistant et ses propres copies de travail git. Les sessions sont lancées, suivies et pilotées depuis le navigateur. Comme il est auto-hébergé, une entreprise exécute un seul déploiement sur sa propre infrastructure, afin que les identifiants, le code source et les conversations restent au sein de l'organisation. Le même cœur fonctionne aussi bien sur un hôte Linux unique avec Docker Compose que sur AWS ECS. Capacités de la console décrites dans le dépôt : - Un dialogue de lancement qui sélectionne la CLI de l'agent, le modèle, l'effort de raisonnement, le mode de démarrage, et s'il faut exécuter dans un worktree git vierge ou une copie de travail existante. - Un miroir de chat dans lequel les questions, les plans et les demandes d'autorisation de l'agent apparaissent sous forme de cartes pouvant être répondues sur place. - Des volets divisés : le miroir de chat, un terminal en direct attaché à une session shell via un PTY, et les modifications de l'arbre de travail côte à côte ; les volets peuvent être détachés dans leurs propres onglets. - Des outils Git dans la console : un graphe de commit à côté du diff du commit sélectionné, ainsi que le staging et le commit, par copie de travail et par worktree. - Un onglet d'utilisation avec un graphique de jetons empilés par fonctionnalité sur 24h / 7j / 30j, des tuiles KPI pour les jetons, les appels, les lectures de cache, le coût équivalent API et les appels non mesurés, ainsi que des ventilations par fonctionnalité, agent et modèle. Les appels ne rapportant pas de jetons sont comptés séparément plutôt que comme zéro. L'interface est disponible en anglais ou en japonais, commutable par utilisateur dans les paramètres ; des captures d'écran existent pour les deux. Les options de déploiement sont documentées comme une décision de vingt minutes : compose (le défaut, une équipe sur un hôte Linux avec Docker), native (sans Docker, utilisateur unique, ex: WSL2 ou une machine Linux personnelle), ecs / ecs-ec2 (AWS avec isolation au niveau des tâches), et ec2-single (AWS, petite équipe, Compose sur une VM). Les bundles publiés récupèrent des images épinglées depuis GHCR et sont publiés vers un dépôt de distribution séparé ; les procédures de commande se trouvent à côté de ce qu'elles opèrent (deploy/compose, deploy/native, deploy/aws/ecs). La construction à partir de l'arbre implique la copie de .env.example, la génération de secrets tels que AF_MASTER_KEY, la construction de l'image de l'espace de travail par utilisateur et l'exécution de docker compose. Caddy gère le TLS via Let's Encrypt, et la connexion utilise l'OAuth propre au plan de contrôle. La documentation est divisée par lecteur : guide/ explique comment faire les choses et est livré dans chaque conteneur d'espace de travail, ouvert depuis l'entrée "User guide" de la Console ; docs/ explique comment le code fonctionne et pourquoi. Le code source est organisé en workspace/ (l'agent et son image), control-plane/ et console/, avec une pile de développement locale lancée via deploy/local/run-dev.sh (local = Docker, wsl, native, reset). Le README précise également la terminologie : un Workspace est l'environnement de conteneur persistant pour un utilisateur avec un volume personnel et des processus en cours ; une Working copy est le répertoire de travail d'un dépôt git cloné à l'intérieur d'un Workspace ; une Session est l'unité logique d'une conversation, ses paramètres et son état d'exécution, liée à une copie de travail. Les sessions n'impliquent pas nécessairement un terminal — Codex, OpenCode, Copilot, Cursor et Kiro utilisent par défaut une méthode d'exécution gérée pilotée depuis la vue chat (Codex et OpenCode s'exécutent sur un runtime partagé sans processus CLI par session), tandis que Claude, Antigravity et les sessions shell / SSM classiques utilisent un terminal. Le projet est sous licence Apache License 2.0, et le README note que la publication du code source d'un outil de gestion d'identifiants, afin que chaque entreprise puisse auditer l'implémentation du chiffrement et de l'isolation, fait partie de la proposition. Les directives de contribution se trouvent dans CONTRIBUTING.md, et les rapports de vulnérabilité ainsi que le modèle de menace sont dans SECURITY.md.