TAKT—TAKT Agent Koordination Topology : est une CLI d'orchestration open source permettant d'exécuter des agents de codage via des workflows explicites et versionnés. Plutôt que de demander à un agent de décider quand la planification, la mise en œuvre et la révision sont terminées, un workflow YAML définit les étapes, les personnages, les autorisations, les transitions et les états terminaux. Les surfaces de fournisseur actuelles incluent Claude, Codex, OpenCode, Cursor, GitHub Copilot CLI et Kiro, avec une configuration variant entre SDK/API-key et external-CLI. intégrations.
La valeur de TAKT est la répétabilité du processus, et non l'intelligence supplémentaire du modèle. Il peut rendre visibles les boucles de révision, isoler les tâches dans les arbres de travail Git et conserver les enregistrements d’exécution, mais il ne peut pas garantir que le jugement sur le statut d’un agent est vrai ou qu’un test réussi prouve que le logiciel est correct. Les équipes possèdent toujours les spécifications, les autorisations des outils, la validation indépendante, les secrets, les contrôles de fusion et le coût opérationnel de plusieurs appels de modèles.
De la demande de chat au changement gouverné
utilisateur/problème
|
v
TALK : affiner la portée
|
QUEUE : enregistrement de tâche immuable
|
EXÉCUTER dans un arbre de travail isolé
|
.----+---------+----------.
v v v
planifier ------> mettre en œuvre --> revoir
^ | |
| v +--> COMPLET
'----------- correction de la boucle +--> ABORT
|
v
tests indépendants + fusion humaine
Le projet décrit un modèle Talk-Queue-Run. Le chat interactif affine une tâche ; la file d'attente l'enregistre ; l'exécution exécute le flux de travail configuré dans un arbre de travail de clone partagé isolé. Les modes direct, issue et pipeline raccourcissent ce chemin. Ignorer le raffinement n'est judicieux que lorsque l'entrée comporte déjà des critères d'acceptation vérifiables par machine.
Concepts de base sans la métaphore musicale
| Notion TAKT | Signification de l'ingénierie | Question de contrôle |
|---|---|---|
| Workflow (anciennement « pièce » dans les matériaux plus anciens) | Machine à états YAML | Chaque chemin peut-il se terminer en toute sécurité ? |
| Pas/mouvement | Unité délimitée de travail d'agent | Quels fichiers et outils peut-il utiliser ? |
| Personnalité | Facette d'invite spécifique au rôle | Est-ce que cela change l’autorité ou seulement la perspective ? |
| Politique/connaissance/instruction | Facettes de contexte composables | Quelle source gagne en cas de conflit d’instructions ? |
| Règle | Transition conditionnée par le statut | La condition est-elle observable de manière indépendante ? |
| Routage du fournisseur | Associer une étape, une balise ou un personnage à un modèle/fournisseur | Le coût, les données et les capacités sont-ils acceptables ? |
| Trouver un contrat | Cycle de vie structuré de la recherche d’avis | Les résultats peuvent-ils être supprimés silencieusement ou fermés automatiquement ? |
La documentation et les versions ont évolué de la terminologie « pièce/mouvement » à « flux de travail/étape ». Épinglez la version npm installée et lisez ses documents correspondants au lieu de copier un ancien exemple YAML. Comme examiné, npm a signalé la version 0.52.0 et les exigences de nœud de ^20.20.0 ou >=22.22.0; confirmez le package live avant l’installation.
Un flux de travail minimal est un graphique, pas une liste de contrôle
nom : plan-mise en œuvre-révision
étape_initiale : plan
max_steps : 10
étapes :
- nom : plan
personnage : planificateur
modifier : faux
règles :
- état : Planification terminée
suivant : mettre en œuvre
- nom : mettre en œuvre
personnage : codeur
modifier : vrai
règles :
- condition : Mise en œuvre terminée
suivant : revue
- nom : avis
personnage : critique
modifier : faux
règles :
- état : Approuvé
suivant : COMPLET
- état : à réparer
suivant : mettre en œuvreCe modèle illustratif nécessite des fronts de défaillance, des limites d'itération et des contrôles déterministes. « Planification terminée » et « Approuvé » sont des interprétations de modèles à moins qu'elles ne soient étayées par un schéma, des tests ou une décision humaine. Ajoutez un comportement ABORT explicite en cas de statut non valide, d'échec du fournisseur, d'épuisement du budget et de violation de la portée. Exécutez la commande officielle workflow validation/doctor prise en charge par votre version installée.
Concevoir des transitions autour des preuves
| Transition | État faible | Des preuves plus solides |
|---|---|---|
| Planifier → mettre en œuvre | L'agent dit que le plan est bon | Acceptation requise, fichiers, risques et champs de test validés |
| Mettre en œuvre → réviser | L'agent dit que le codage est terminé | La différence existe, les chemins modifiés sont autorisés, les commandes de construction/test exécutées |
| Révision → correction | Critique libre | La découverte comporte un identifiant, une gravité, un fichier/une ligne, des preuves et un statut. |
| Révision → terminé | Aucun problème mentionné | Ledger n'a aucun résultat de blocage ouvert et les portes passent |
| Tout → abandonner | Le mannequin décide d'abandonner | Incendies liés au budget, à la sécurité, à un état invalide ou à des échecs répétés de politiques |
| Terminer → fusionner | Fusion automatique des relations publiques | Contrôles de succursale protégés et approbation humaine responsable |
Les autorisations doivent suivre l'étape, pas la marque du fournisseur
Un planificateur a normalement besoin d'un accès en lecture/recherche, pas de modifications. Un implémenteur peut modifier un arbre de travail délimité et exécuter des vérifications du référentiel. Un réviseur doit être en lecture seule afin de ne pas pouvoir « corriger » les preuves avant de les approuver. Une étape de publication nécessite une porte humaine explicite et un jeton de référentiel étroit. La sophistication du modèle ne justifie pas une large autorité.
| Capacité | Position par défaut | Contrôle |
|---|---|---|
| Modifier le système de fichiers | Uniquement les étapes de mise en œuvre/correction | Racines autorisées et inspection du différentiel post-étape |
| Coquille | Bac à sable/arbre de travail uniquement | Politique de commande, délai d'attente, limite CPU/disque |
| Réseau | Refuser ou autoriser | Bloquer les métadonnées/hôtes internes et les destinations des journaux |
| Git push/PR | Branche de tâches et projet de PR | Jeton d'application limité et principal protégé |
| Secrets | Injecté uniquement lorsque cela est nécessaire | Informations d'identification et rédaction de courte durée par étape |
| Installation du package | Limité au fichier de verrouillage | Registres approuvés, analyse de l’intégrité et des dépendances |
| Déploiement | Flux de travail de codage externe initialement | Système de libération indépendant et approbation humaine |
Isolation Worktree : utile mais incomplète
L'arbre de travail Git/clone partagé isolé de TAKT protège les fichiers actifs du développeur et facilite l'inspection des branches de tâches. Il n'isole pas les processus, le réseau, les informations d'identification, les fichiers personnels des utilisateurs ou les comptes externes. Un agent disposant d'un accès shell peut toujours lire des variables d'environnement, contacter des hôtes arbitraires ou appeler des CLI authentifiées globalement.
Pour les problèmes ou les référentiels non fiables, exécutez l'intégralité de la tâche dans un conteneur jetable ou une VM avec un répertoire personnel propre, une sortie restreinte et des quotas de ressources. Montez uniquement le référentiel de tâches. Utilisez un jeton d'application GitHub/GitLab dédié. Détruisez l'environnement après avoir exporté le diff, les journaux et les preuves requises.
Le routage des fournisseurs crée un routage des coûts et des politiques
Acheminer un planificateur vers un modèle et la mise en œuvre/révision vers d’autres peut améliorer la spécialisation et éviter une monoculture de modèle unique. Cela signifie également que le code source et les invites peuvent atteindre plusieurs fournisseurs selon des conditions de rétention, de région et de compte différentes. Conservez une liste blanche par classe de données du référentiel et enregistrez le fournisseur/modèle résolu pour chaque étape.
| Objectif de routage | Expérience raisonnable | Garde-corps |
|---|---|---|
| Coût de planification réduit | Petit modèle sur les plans structurés à faible risque | Escalader le travail d'ambiguïté/de sécurité |
| Mise en œuvre solide | Modèle axé sur le code avec outils d'édition | Limites des jetons, des fichiers et des commandes |
| Examen indépendant | Famille de fournisseurs/modèles différente | Lecture seule et recherche de schéma |
| Résidence des données | Fournisseur agréé pour les dépôts sensibles | Bloquer le recours à un fournisseur non approuvé |
| Disponibilité | Modèle de repli en cas de panne passagère | Revalidez le comportement, n’étendez jamais silencieusement le partage de données |
Les boucles de révision nécessitent des règles d'arrêt strictes
L'examen des agents peut osciller : une passe modifie un API, une autre le restaure ; un modèle ajoute des tests, un autre les supprime. Définissez le nombre maximum d'étapes, de tentatives, de temps passé sur le mur, de dépenses de modèle, de fichiers modifiés et de taille de différence. Hachez les résultats et les correctifs pour détecter les états répétés. Transférez-le à un humain lorsque le même résultat réapparaît, qu'aucun test ne s'améliore ou que la portée ne s'étend.
- Ne laissez jamais le responsable de la mise en œuvre marquer que son propre résultat de sécurité est résolu sans la preuve de l'examinateur.
- Ne fermez pas une conclusion simplement parce que la ligne a bougé.
- Conservez les changements de gravité et les renonciations attribuables à une personne ou à une politique.
- Exiger une validation finale de vérification propre, pas seulement les commandes à l’intérieur d’une session d’agent modifiée.
Risque lié à la chaîne d'approvisionnement en matière d'invite et de flux de travail
TAKT peut utiliser des flux de travail/facettes intégrés ou éjectés et peut installer des packages de répertoire à partir de GitHub. Ces fichiers influencent le comportement et les outils des agents ; traitez-les comme des dépendances exécutables. Épingler les commits, examiner les différences, éviter de flotter principal références dans les packages CI et scan avant l’activation.
Les fichiers du référentiel, les problèmes, les résultats du compilateur et les pages Web récupérées sont des contenus d'invite non fiables. Un problème malveillant peut demander à l'agent d'imprimer des clés ou de modifier des workflows. La politique système et l’application des autorisations doivent se situer en dehors de ce texte. Ne laissez pas une tâche modifier le contrôle de qualité qui évalue la même tâche sans examen séparé.
Déploiement CI/CD
TAKT documente le mode pipeline et une action GitHub. Commencez par une analyse en lecture seule ou une création de brouillon de relations publiques. Les actions GitHub déclenchées par des forks peuvent être dangereuses lorsque des secrets et des jetons inscriptibles sont disponibles ; suivez les directives de sécurité spécifiques aux événements de GitHub. Épinglez les actions de tiers par un commit immuable SHA et utilisez-en un minimum autorisations.
| Élément CI | Réglage initial sûr | Raison |
|---|---|---|
| Déclencheur | Envoi manuel ou étiquette de confiance | Empêche tout auteur de numéro de dépenser/agir |
| Jeton de référentiel | Contenu lu ; PR écrire uniquement si nécessaire | Limite le compromis |
| Secrets du fournisseur | Portée sur l'environnement et masquée | Réduit l’exposition à la fourchette/bûche |
| Sortie | Projet de PR et artefact de preuve | Garde la fusion responsable |
| Concurrence | Plafonds par dépôt et par tâche | Contrôle les branches et les dépenses en conflit |
| Délai d'attente | Budget de travail et de flux de travail fini | Arrête les boucles et les CLI bloquées |
Que mesurer dans un pilote
Sélectionnez 20 tâches représentatives et délimitées et un groupe témoin comparable humain/mono-agent. Suivez le taux de tâches acceptées, la première réussite indépendante du CI, les minutes des réviseurs, les défauts rouverts, les résultats de sécurité, les délais d'exécution, le coût du modèle et les échecs de flux de travail. Les lignes modifiées et le nombre d'étapes de l'agent sont une activité et non une valeur.
Mesurez également les frais d'orchestration : maintenance YAML, configuration du fournisseur, faux résultats d'examen, nettoyage des conflits et temps de diagnostic des transitions. Un flux de travail structuré est justifié lorsqu'il augmente suffisamment la qualité acceptée ou la prévisibilité pour dépasser cette surcharge.
Quand TAKT convient
| Situation | Ajustement | Pourquoi |
|---|---|---|
| Maintenance répétée avec des tests clairs | Pilote fort | Flux de travail réutilisable et portes d'objectifs |
| Plan/construction/révision multimodèle | Bon | Routage des fournisseurs et rôles explicites |
| Une conception de produits inédite et ambiguë | Conditionnel | Les décisions humaines dominent les premiers travaux |
| Une petite modification déterministe | Faible | Un script direct ou un agent supervisé est plus simple |
| Réponse aux incidents de production | Mauvais démarrage autonome | L'autorité en direct et la pression du temps amplifient les erreurs |
| Dépôt non fiable avec de vastes secrets | Dangereux sans sandboxing | Worktree seul ne constitue pas une limite de sécurité |
Alternatives
| Options | Meilleur ajustement | Compromis par rapport à TAKT |
|---|---|---|
| TAKT | Workflow de codage multi-fournisseurs local/CI dans YAML | Nouveau langage d’orchestration et maturité du projet |
| Direct Codex/Claude Code | Un développeur supervisant une tâche | Routage multi-étapes moins reproductible |
| Flux de travail agentiques GitHub | Automatisation du référentiel natif GitHub | Exécution/gouvernance spécifique à la plateforme |
| Open SWE | Problème asynchrone interne/plateforme de discussion en relations publiques | Service plus lourd et intégration sandbox |
| LangGraph | Applications d'agent avec état programmatique personnalisées | Plus de code et de généralité, moins de packaging de workflow de codage |
| Scripts CI ordinaires | Transformations déterministes connues | Un raisonnement moins flexible, souvent plus sûr et moins cher |
Questions fréquemment posées
TAKT est-il un modèle de codage ?
Non. Il orchestre les fournisseurs d’agents de codage et les flux de travail pris en charge.
Est-ce open source ?
Le référentiel actuel et le package npm identifient une licence MIT. Vérifiez la version installée et les dépendances groupées.
Isole-t-il l’exécution des agents ?
Il utilise des arbres de travail/clones de tâches Git isolés, qui protègent l’état de l’arbre de travail. Une isolation solide des processus, du réseau et des secrets nécessite un conteneur ou une VM.
Peut-il fonctionner en CI ?
Oui, via le mode pipeline et l’intégration d’actions documentées. Commencez avec des autorisations minimales et des projets de PR.
YAML garantit-il la qualité ?
Non, cela rend le processus explicite. La qualité nécessite des transitions fondées sur des données probantes, des contrôles indépendants et un examen responsable.
Quels fournisseurs sont pris en charge ?
Liste des matériaux actuels Claude, Codex, OpenCode, Cursor, GitHub Copilot CLI et Kiro. La prise en charge et l'authentification changent selon la version.
Quand un flux de travail doit-il s’arrêter ?
Sur le succès soutenu par les portes requises, l'abandon explicite ou les budgets stricts pour les étapes, le temps, les dépenses et les résultats répétés.
Sources primaires
- Dépôt officiel TAKT et README
- Métadonnées officielles du package npm
- Référence CLI officielle
- Guide de configuration officiel
- Guide officiel du flux de travail
- Journal des modifications officiel
- Dépôt officiel GitHub Action
- Renforcement de la sécurité des actions GitHub
- Conseils d’injection rapide OWASP
Dernière révision le 25 juillet 2026. TAKT sera publié rapidement ; épinglez le package npm, le schéma de workflow et les versions du fournisseur, puis réexécutez les tests de sécurité et de comportement après les mises à niveau.
