CodingAgent dans Kavor : votre harness préféré au sein d'un graphe
Un CodingAgent est votre agent de programmation exécuté dans l'interface native de son provider, désormais visible comme participant du Canvas.
Kavor ne remplace pas chaque harness par un chat générique. Il conserve l'expérience du provider et ajoute une structure autour d'elle : responsabilité explicite, contexte accessible, outils, autres CodingAgents et limites que vous pouvez inspecter.
Voyez le choix du provider en vidéo → (s’ouvre dans un nouvel onglet)
Ce que possède un CodingAgent
Chaque CodingAgent représente une session distincte. Le Node conserve la configuration et l'état nécessaires à ce rôle, notamment le provider choisi et, lorsque celui-ci les propose, le modèle, le niveau d'effort, les permissions et la session native.
Le provider est un réglage du CodingAgent, pas un autre type de Node. Le sélecteur comprend :
- Anthropic Claude Code ;
- OpenAI Codex ;
- Google Antigravity ;
- xAI Grok ;
- SST OpenCode.
Quand vous ajoutez un CodingAgent depuis la toolbar, vous choisissez d'abord le provider. Vous configurez ensuite la session pour le travail. Les options peuvent différer, car Kavor préserve les capacités réelles de chaque harness au lieu de prétendre qu'ils partagent tous le même contrat.
Ce qu'il peut faire seul
Sans Connection, un CodingAgent reste une session provider-native dans le Workspace. Vous pouvez dialoguer, utiliser les outils du harness et choisir son répertoire de travail. Ce répertoire peut se trouver hors de la racine du Workspace lorsque le rôle exige un autre dépôt ou worktree ; l'association reste explicite dans la session.
Le Node aide déjà à séparer les contextes : une session peut enquêter pendant qu'une autre implémente. Sans graphe, le contexte partagé dépend toutefois encore de ce que vous fournissez dans chaque conversation.
La Connection transforme la session isolée en participant d'un système de travail.
Fournir un fichier ou une capture dans la saisie
Dans une session ouverte, vous pouvez coller des fichiers du presse-papiers système ou des images PNG/JPEG. Kavor insère une référence sans créer de File ni de Connection sur le Canvas. Vérifiez le chemin et rédigez la demande avant de l'envoyer ; interpréter l'image dépend toujours du harness.
Le guide Terminal explique la procédure, les limites et la différence entre une référence collée et une ressource conservée dans le graphe.
Ce qu'il gagne dans le graphe
Un CodingAgent peut travailler avec tout Node accessible par un chemin de Connections valides dans son composant. Chaque ressource n'a pas besoin de lui être directement reliée.
Les Connections directes impliquant un CodingAgent ont des rôles précis :
| Connection | Ce qu'elle ajoute |
|---|---|
| CodingAgent+Specification | Place intention, périmètre et critères durables dans le graphe. Elle peut porter specification_read_only. |
| CodingAgent+Sticky Note | Ajoute une mémoire informelle partagée pour décisions ouvertes, progression et findings. Elle peut porter sticky_note_read_only. |
| CodingAgent+File | Rend explicite une source canonique du filesystem. Elle peut porter file_read_only. |
| CodingAgent+Terminal | Permet d'exécuter des commandes, suivre des processus et consulter les preuves du shell. Elle peut porter terminal_read_only. |
| CodingAgent+WebBrowser | Permet d'observer et d'utiliser les pages réelles de ce WebBrowser dans le même état visible par l'humain. |
| CodingAgent+CodingAgent | Réunit les participants dans un même composant. Les CodingAgents accessibles peuvent échanger des messages asynchrones et consulter le contexte nécessaire à leur coordination. |
| Trigger+CodingAgent | Sélectionne cette session active comme cible directe d'un prompt planifié. Un Trigger ne démarre pas une session que vous avez fermée. |
L'accessibilité n'efface pas les contrats directs. Si la Connection exacte entre un CodingAgent et une ressource possède un Guardrail, cette restriction continue de régir la paire même si un autre chemin existe dans le graphe.
Schémas utiles
Implémenter à partir d'un contrat
Reliez une Specification, un CodingAgent au rôle d'Implementer et un Terminal. L'agent lit le contrat à sa source, ne modifie que le périmètre nécessaire, exécute les vérifications et enregistre les outputs dans la Specification.
L'intention reste ainsi hors de l'historique de conversation et les preuves demeurent dans le Workspace.
Séparer implémentation et revue
Utilisez des sessions distinctes pour l'Implementer et le Reviewer. Tous deux accèdent à la même Specification et aux mêmes preuves, mais reçoivent une question différente.
L'Implementer demande « comment respecter le contrat ? ». Le Reviewer demande « le résultat respecte-t-il vraiment le contrat et quels risques subsistent ? ». Cette séparation réduit le risque que la revue hérite automatiquement des hypothèses de l'auteur.
Combiner des providers sans créer un concours
Des providers différents peuvent participer au même graphe. Combinez-les lorsqu'une autre interface, un autre modèle ou une autre approche de raisonnement améliore une responsabilité concrète.
N'ajoutez pas un provider uniquement pour augmenter le nombre d'agents. Définissez d'abord le rôle, le résultat attendu et la condition d'arrêt, puis choisissez le harness qui sert le mieux le travail.
Travailler avec une page active
Connectez un WebBrowser lorsque la tâche dépend d'une véritable interface web. Vous continuez à voir et utiliser les mêmes onglets ; le CodingAgent peut naviguer, interagir, attendre des changements et capturer des preuves sans reconstruire la page à partir de texte copié dans le chat.
Le WebBrowser peut rester actif lorsque vous changez de Workspace et revenir dans le même état. L'agent poursuit ainsi un travail déjà autorisé sans recharger la page à chaque changement de contexte visuel.
Voyez le CodingAgent et le WebBrowser travailler ensemble → (s’ouvre dans un nouvel onglet)
Consulter la session actuelle d'un autre CodingAgent
Un CodingAgent accessible peut parcourir passivement, page par page, les tours terminés de la session provider-native actuelle d'un autre CodingAgent. Cette lecture récupère le raisonnement, les preuves et le contexte qui ne sont pas encore devenus un message ou un output durable.
Elle n'envoie aucune entrée au provider, n'active pas la session consultée et ne remplace pas un message lorsque l'autre agent doit agir, décider ou répondre. Si la session change pendant la pagination, l'ancienne continuation est refusée ; le lecteur doit recommencer pour ne pas mélanger des historiques différents.
Un graphe pratique
Specification — Implementer — Reviewer
│ │
Terminal Sticky Note
│
File
Les lignes représentent des Connections sans direction persistée. Tous les Nodes appartiennent au même composant accessible. L'Implementer exécute le contrat, le Reviewer produit une évaluation indépendante et la Sticky Note garde les questions ou findings visibles pour la décision humaine.
Ce schéma n'est pas une séquence automatique. Les messages coordonnent les handoffs ; les Specifications et autres ressources préservent ce qui doit survivre aux sessions ; vous décidez quand le travail est accepté.
Un meilleur prompt initial
Pour un Implementer :
Implémente uniquement le périmètre défini dans la Specification accessible. Avant de modifier le code, identifie les Files et vérifications pertinents. Utilise le Terminal pour produire des preuves, enregistre le résultat comme output de la Specification et demande au Reviewer une évaluation indépendante. Arrête-toi si une décision nécessaire sort du contrat.
Pour un Reviewer :
Compare l'implémentation et les preuves aux critères de la Specification. Recherche les comportements incorrects, scénarios manquants, régressions et risques opérationnels. Enregistre des findings concrets avant de proposer des changements et n'approuve pas seulement parce que les tests existants ont réussi.
Exemple : un handoff que le Reviewer peut vérifier
Imaginez une correction du formulaire d'inscription. La Specification exige qu'un e-mail invalide affiche un message, que l'envoi soit bloqué et qu'un e-mail valide continue de fonctionner. Utilisez le graphe ci-dessus et gardez Builder et Reviewer dans des sessions distinctes.
Demande au Builder :
Implémente la validation définie dans la Specification. Préserve le comportement du parcours valide. Exécute les tests pertinents dans le Terminal et consigne les fichiers modifiés, commandes et résultats. Envoie ensuite au Reviewer le handle de la Specification et le commit ou diff exact à revoir. Signale les points en suspens et arrête-toi avant de publier.
Un handoff utile identifie la livraison plutôt que de copier toute la conversation :
L'implémentation se trouve dans le commit indiqué dans les outputs de la Specification. Les tests d'e-mail invalide, vide et valide ont réussi dans le Terminal Checks. Examine les critères et les parcours d'échec dans ce commit. Consigne les findings avec fichier, scénario et preuve ; réponds lorsque tu as terminé. Ne modifie pas le code pendant cette revue.
Demande au Reviewer :
Lis le contrat et examine la livraison référencée. Vérifie chaque critère, reproduis les scénarios pertinents et ajoute tes conclusions à la Sticky Note. Distingue un défaut démontré d'une hypothèse. Si tu trouves un blocage, explique quel comportement échoue et renvoie le travail au Builder pour correction.
Le résultat attendu est un changement identifiable, une revue indépendante et votre décision fondée sur des preuves. Si le Builder modifie encore la livraison, attendez qu'il stabilise le résultat ou délimitez explicitement ce qui est prêt à être revu. Deux agents examinant des révisions différentes du code n'évaluent pas la même livraison.
Limites importantes
- Un CodingAgent n'obtient pas d'accès par proximité visuelle ; un chemin de Connections doit exister.
- Référencer un Node dans un message ne lui accorde pas l'accès.
- La lecture passive de la session d'un autre CodingAgent ne l'active pas et ne transfère pas une décision durable dans la Specification.
- Un Guardrail limite la paire directe à laquelle il appartient ; ce n'est pas une politique globale du Workspace.
- Les messages coordonnent le travail, mais ne doivent pas être le seul lieu d'une décision durable.
- Les providers ne proposent pas nécessairement les mêmes modèles, permissions, événements ou opérations de session.
- Un Trigger remet un prompt à une session active ; il n'étend pas les permissions et ne garantit pas qu'un effet externe se produise exactement une fois.
- Autoriser l'édition du Canvas n'autorise ni la suppression de Nodes ni la modification de Guardrails ; ces limites restent humaines.
Avant de démarrer la session
Vérifiez :
- la responsabilité de ce CodingAgent ;
- le résultat observable qu'il doit produire ;
- les Nodes qui doivent être accessibles ;
- les Guardrails nécessaires sur les Connections directes ;
- si provider, modèle et effort correspondent au risque de la tâche ;
- où préserver décisions, progression et preuves ;
- avec qui il doit communiquer et quand il doit s'arrêter.
Un CodingAgent ne devient pas puissant grâce à un prompt plus long. Il devient plus utile quand responsabilité, contexte, outils, collaboration et limites forment un ensemble cohérent.
Poursuivez avec Comment choisir les CodingAgents et définir les rôles, découvrez comment les CodingAgents voient et construisent le Canvas ou consultez la matrice des Connections prises en charge.