Apache Maka : un espace de travail d'agents auditable où le journal d'événements en ajout seul est le moteur d'exécution
Apache Maka (en incubation) est un espace de travail d'agents haute performance qui écrit chaque message du modèle, appel d'outil, décision de permission et fin d'exécution comme un RuntimeEvent en ajout seul. L'interface, le prochain prompt et la reprise après incident sont des projections de ce journal. Bureau, TUI, CLI et Eval partagent un seul Runtime Host, les données restent locales et le modèle est au choix. La version actuelle est la 0.2.0, Windows et Linux restent en préversion. Le README précise aussi les prérequis de compilation : Node.js 22.19 ou plus récent, npm, Git et ripgrep. Les fonctions Direct Peer ajoutent une chaîne Rust. L'accès aux modèles se règle dans les réglages, avec API, modèle local ou passerelle, ce qui permet aux équipes soumises à des règles strictes de garder code et traces dans leur réseau.
Apache Maka (en incubation) est un espace de travail pour agents, conçu pour la performance, avec une promesse unique : conserver une trace complète de tout ce que l'agent a fait. Ce n'est pas une énième interface de discussion.
C'est une conception d'ingénierie qui sépare un moteur d'exécution d'agent et des clients légers. Ce rapport s'appuie sur le README du projet et sur ses descriptions publiques. Il couvre l'architecture, le mécanisme, l'intérêt pour les équipes et les limites.
Le problème visé
Un harnais d'agent existe pour terminer des tâches. Le README ne retient que deux mesures : combien de tâches sont menées à bien, et à quel coût. Maka rend ces deux mesures publiques.
Le projet affirme comparer son harnais à d'autres, avec le même modèle et le même vérificateur officiel, et publier les résultats tâche par tâche avec chaque rapport, dans le dossier docs/eval du dépôt. On passe de « nous sommes meilleurs » à « lisez le résultat de chaque tâche ». La plupart des projets d'agents ne publient qu'un score agrégé, cette pratique est donc peu courante.
Idée centrale : le journal est le moteur d'exécution
Le choix de conception majeur est que le journal est le moteur d'exécution. Chaque message du modèle, chaque appel d'outil, chaque décision de permission et chaque fin d'exécution est écrit comme un RuntimeEvent, en ajout seul. L'interface, le prochain prompt et la reprise après incident sont des projections de ce journal. Aucune n'est l'unique exemplaire de la vérité.
Cette approche rappelle l'event sourcing et apporte trois avantages. D'abord, la reprise après incident est simple, car l'état se rejoue depuis le journal. Ensuite, l'interface et la construction du prompt ne gardent pas chacune un état privé, ce qui limite les divergences. Enfin, et c'est le point le plus utile pour un agent : une ancienne sortie d'outil peut quitter le prochain prompt sans quitter le journal. Dans les tâches longues, les sorties d'outils saturent vite la fenêtre de contexte. Maka peut les retirer du prompt pour économiser des tokens, tout en gardant la piste d'audit complète sur le disque. La gestion du contexte et l'auditabilité s'opposent d'ordinaire. Maka les place dans deux couches distinctes, et chacune peut donc être satisfaite.
Un seul hôte d'exécution
Maka possède un unique Runtime Host, qui est l'autorité d'exécution. L'application de bureau, le TUI et la CLI, ainsi que l'outil d'évaluation Eval, sont des clients légers de cet hôte.
Eval ne possède que l'expérience et ses scores. Grâce à cette séparation, le comportement observé sur le bureau vient du même chemin d'exécution que celui des résultats de benchmark. Il n'existe pas de second chemin de code pour l'évaluation, et l'écart habituel entre « ce que l'on mesure » et « ce que l'on livre » a moins de place pour se creuser.
Local d'abord, votre propre modèle
Les sessions, les réglages et les enregistrements d'exécution restent sur votre machine. Maka n'embarque pas de compte de modèle partagé. Au premier lancement, on ouvre Réglages, puis Modèles, on ajoute une API, un modèle local ou une connexion de compte prise en charge, on la teste et on choisit un modèle par défaut. L'application distingue trois états de connexion : configurée, prête à envoyer et expérimentale.
Un flux de compte qui n'est pas relié au moteur d'exécution n'est pas présenté comme un modèle utilisable. Ce choix est sobre et honnête, car il évite d'exagérer la compatibilité. Le modèle peut être une API cloud, un modèle local ou une passerelle compatible. Une équipe qui manipule du code sensible peut donc utiliser un modèle local et garder le code et la trace dans son réseau.
Construire et lancer le projet
La compilation depuis les sources demande Node.js 22.19 ou plus récent (la CI utilise Node.js 24), npm, Git et ripgrep, dont dépend l'outil Grep du moteur d'exécution. Après npm ci, la commande npm run dev lance l'environnement de développement du bureau avec rechargement à chaud. Dans le terminal, npm run cli:dev ouvre le TUI et npm run cli:dev -- run exécute un seul tour.
Une option --graph existe pour les tâches en graphe. Les fonctions Direct Peer et Peer Mesh exigent Rust stable 1.98 ou plus récent et un éditeur de liens de la plateforme, avec des commandes dev:peer dédiées. Côté plateformes, macOS est la cible principale, tandis que Windows et Linux sont en préversion.
État du projet et portée pour l'écosystème
Maka est un projet en incubation à l'Apache Software Foundation. La dernière version Apache est la 0.2.0 (en incubation).
L'archive source signée est la version officielle. Les paquets distribués ailleurs sont des artefacts de confort, et les builds de développement ne sont pas des versions Apache approuvées. La licence Apache 2.0 et la gouvernance de la fondation aident l'adoption en entreprise : la licence est claire et le processus communautaire est documenté.
Limites et risques
Premièrement, l'extrait du README ne donne ni score de benchmark ni chiffre de coût. Il faut ouvrir docs/eval pour lire les résultats par tâche, et ce rapport ne reprend aucun chiffre qu'il n'a pas pu vérifier. Deuxièmement, le projet est encore en incubation. La version est 0.2.0 et deux plateformes sur trois sont en préversion : un déploiement en production demande du temps de validation.
Troisièmement, un journal complet en ajout seul pose des questions d'espace disque et de confidentialité. Il conserve les messages du modèle et les sorties d'outils, qui peuvent contenir des secrets ou du code privé. Les équipes doivent donc définir leurs règles de conservation et de masquage. Quatrièmement, toute promesse de haute performance doit être reproduite sur vos propres tâches, car un benchmark public ne remplace pas votre charge de travail.
Perspectives
Les agents auditables prendront de l'importance. Quand un agent peut modifier des fichiers et lancer des commandes, chaque décision de permission et chaque maillon de la chaîne de causes doivent rester traçables.
Maka traite cette chaîne comme un élément de premier rang du moteur d'exécution, et non comme une fonction de journalisation ajoutée après coup. C'est l'aspect le plus intéressant du projet. Si la pratique d'évaluation ouverte tient sur la durée des versions, elle pourrait aussi pousser les harnais d'agents vers des comparaisons plus transparentes.