Fenêtres agent
Cette page explique pourquoi dialoguer avec un agent prend cette forme-là. Pour savoir comment faire, voir Dialoguer avec un agent de code ; pour les touches et le format de fichier exacts, Agents et ACP.
Pourquoi un protocole plutôt qu'un fournisseur
Un éditeur qui voulait offrir une fenêtre de conversation avait deux façons de l'obtenir. Parler directement aux fournisseurs de modèles — un client HTTP par fournisseur, un jeu de clés d'API à stocker, une boucle d'appel d'outils à écrire, et un nouvel exemplaire de chaque dès que quelqu'un veut un fournisseur dont l'éditeur n'a jamais entendu parler. Ou parler un seul protocole au programme auquel l'utilisateur fait déjà confiance pour ce travail.
L'Agent Client Protocol est la seconde. L'agent est un processus fils ; l'éditeur lui envoie des invites et dessine ce qui revient. L'éditeur ne détient aucune clé d'API, ne connaît aucun fournisseur, et n'implémente aucune boucle d'appel d'outils — et le même code parle à docker agent devant un llama.cpp local, à un agent dans le nuage, ou à quelque chose que vous avez écrit cet après-midi.
Cela veut aussi dire que l'éditeur n'est pas l'endroit où atterrit un nouveau modèle. Sa prise en charge est une ligne dans le fichier de configuration de votre agent, un fichier que cet éditeur ne lit pas.
Pourquoi cela vit dans turbo-core
Turbo Python est une commande, un profil et un analyseur ; tout le reste est la bibliothèque que partagent tous les éditeurs Turbo. Une fenêtre agent est une fenêtre, un menu, une boîte modale et un tour de boucle d'événements — quatre choses qui appartiennent toutes à turbo-core/app. La construire ici aurait voulu dire ajouter à la bibliothèque une couture générale « laisser un éditeur ajouter une fenêtre et un menu depuis l'extérieur », puis s'en servir exactement une fois.
Le client du protocole, le modèle de conversation et la fenêtre sont donc turbo-core/acp, à côté de terminal et filetree, qui ont la même forme. Ce que Turbo Python apporte, c'est l'acp.toml de départ qu'il propose d'écrire — la seule part de tout ceci qui parle de projets Python. Turbo Rust et Turbo Golo obtiendront des fenêtres agent en écrivant un fichier de départ à eux, et rien d'autre.
Pourquoi une fenêtre, et non un panneau
Le même raisonnement que celui tranché pour l'arbre de projet. Un panneau ancré voudrait dire que le bureau acquiert la notion de bords réservés, et que fitInto, les modes d'agrandissement, la maximisation, la mosaïque et la cascade doivent tous les respecter — une modification des fondations de l'interface pour un seul widget. En tant que fenêtre ordinaire, un agent obtient F6, les Alt-chiffres, [x], [■] et Tile gratuitement.
Cela fait aussi tomber « plusieurs agents à la fois » au lieu de le concevoir : deux fenêtres sont deux processus et deux conversations, et Tile met un modèle local rapide à côté d'un modèle lent et soigneux. Un panneau aurait dû se doter d'onglets pour en faire autant.
Pourquoi un processus par fenêtre, démarré à l'ouverture
Un agent est une conversation, et une conversation a un début. Démarrer le processus avec la fenêtre fait que le dossier de travail de l'agent, son environnement et sa session appartiennent tous à cette fenêtre, et que la fermer est une fin sans ambiguïté — le même marché que passent les fenêtres terminal, et pour la même raison : ce que la fenêtre contient est un processus en cours, pas un travail non enregistré, donc la fermer ne demande rien.
L'autre solution — un agent unique et durable multiplexé sur plusieurs fenêtres — aurait voulu dire que l'éditeur décide à quelle fenêtre appartient un session/update, et quoi faire d'une fenêtre dont la session a disparu alors que le processus vit encore. Deux processus coûtent moins cher que cette comptabilité.
Pourquoi la boîte de permission est ouverte depuis la boucle d'événements, et non depuis le message
session/request_permission arrive sur la goroutine de lecture de la connexion, et la réponse vient d'une boîte de dialogue que l'utilisateur doit regarder. La réponse ne peut donc pas être faite là où la requête est traitée, et la boîte ne peut pas non plus y être ouverte : tout ce qui dessine appartient à la goroutine principale.
La requête est donc enregistrée, et la boucle d'événements la remarque à son tour suivant et ouvre la boîte. C'est la quatrième fois que ce projet arrive à la même conclusion — l'enregistrement automatique, la ré-annonce au serveur de langage et les redessins du terminal sont les autres — et la raison est toujours la même : PostEvent a le droit de jeter ce qui ne rentre pas, donc un événement peut provoquer un tour de boucle mais ne doit jamais être le seul porteur d'un fait.
C'est pourquoi la couche JSON-RPC a dû apprendre à répondre à une requête plus tard. C'est aussi toute la raison pour laquelle jsonrpc a été extrait de lsp : les questions d'un serveur de langage peuvent toutes être répondues sur-le-champ, et celles d'un agent non.
Pourquoi l'agent reçoit le tampon plutôt que le fichier
Quand l'agent lit un fichier que vous avez ouvert et pas enregistré, il reçoit le texte que vous avez sous les yeux, pas celui du disque. L'autre solution est un agent qui relit la version que vous venez de dépasser, ce qui est faux précisément au moment où vous avez le plus de chances de poser la question — vous avez changé quelque chose et vous voulez savoir ce qu'il en est.
Le coût est que l'agent voit un texte qu'aucun autre outil ne voit, donc une réponse citant un numéro de ligne peut ne pas correspondre à ce que dit uv run ruff check .. C'est accepté : c'est déjà vrai de la complétion, qui répond depuis le tampon depuis que l'éditeur sait parler à pylsp.
Les écritures suivent le même chemin, dans le tampon, marqué modifié. Un agent qui modifie un fichier laisse la modification sous vos yeux, annulable avec Ctrl-Z et non enregistrée jusqu'à ce que vous fassiez F2. Un agent réécrivant discrètement un fichier sous une fenêtre que vous avez ouverte serait la pire version possible de cette fonctionnalité.
Pourquoi les couleurs sont les classes syntaxiques, et non de nouvelles clés de thème
L'arbre de projet a eu besoin de clés de thème à lui, parce qu'il aurait sinon emprunté list.selected, une couleur choisie sur un fond de dialogue, et dessiné sa ligne sélectionnée dans la couleur qui se trouve dessous. Rien de tel ici : le corps d'une fenêtre agent est window.body, ce sur quoi les classes syntaxiques sont déjà choisies et déjà testées pour le contraste.
Le nom d'un interlocuteur est donc dessiné dans le style des mots-clés, une réflexion dans celui des commentaires, un appel d'outil dans celui des types, et le code selon ce qu'en dit son propre analyseur. Onze thèmes colorent correctement les fenêtres agent sans avoir été touchés, et un thème écrit par quelqu'un l'an dernier aussi.
Ce à quoi on renonce, c'est l'expressivité : un thème ne peut pas rendre les réflexions discrètes sans rendre aussi les commentaires discrets, puisque c'est la même clé. Si cela s'avère gênant à l'usage, des clés agent.* pourront être ajoutées plus tard — les règles de contraste et le test de complétude en sont le prix, et il ne vaut d'être payé que si quelqu'un veut la distinction.
Pourquoi la transcription est un modèle que la fenêtre se contente de dessiner
L'agent envoie des jetons : "I", " found", " agent", ".yaml". Une fenêtre qui ajouterait chacun à une liste de lignes serait une fenêtre incapable de reformater, incapable de distinguer la prose d'un bloc de code délimité, et impossible à tester sans agent vivant.
La conversation est donc une valeur — acp.Transcript — qui fusionne les fragments en entrées, replie chaque tool_call_update sur le tool_call dont l'identifiant correspond, et remet à la fenêtre une liste de blocs qui sont soit de la prose, soit du code dans un langage nommé. Elle ne sait rien d'un terminal, ce qui permet de la tester en appelant des fonctions et en comparant des valeurs, la règle d'organisation que suivent déjà buffer, lsp et syntax.
C'est aussi ce qui rend les tests de dessin déterministes. Le projet s'est déjà fait mordre par des tests qui portaient sur un écran pendant qu'un processus vivant y écrivait, et cela a caché un vrai défaut pendant toute une session ; une fenêtre dessinée à partir d'une transcription figée ne peut courir contre rien.
Ce qui a été volontairement laissé de côté
- La reprise de session.
session/loadexiste, et s'en servir voudrait dire décider où les conversations sont stockées, combien de temps elles sont gardées, et ce qui se passe quand le projet a déménagé. C'est une fonctionnalité à part entière. - L'authentification. Un agent qui a besoin d'une connexion est prié de se connecter avec sa propre CLI. Stocker un identifiant est une responsabilité que cet éditeur a jusqu'ici entièrement évitée, et une méthode de protocole n'est pas une bonne raison de commencer.
- La capacité
terminal. Un agent peut déjà avoir un shell par ses propres jeux d'outils, comme le faitdocker agent. L'annoncer voudrait dire que l'éditeur lance des commandes pour le compte de l'agent et possède la sortie — le menu des outils fait déjà cela, et mieux, pour des commandes que vous avez choisies. - Les images dans les invites. L'éditeur a du texte et des fichiers à envoyer, et un terminal pour dessiner.
Voir aussi
- Architecture — ce qui est ici et ce qui est dans la bibliothèque
- Fenêtres terminal — l'autre fenêtre qui contient un processus vivant
- Arbre de projet — là où l'argument fenêtre-et-non-panneau a été posé la première fois
Pourquoi la copie va dans deux presse-papiers
« Copie ça pour que je m'en serve ailleurs » veut généralement dire complètement ailleurs — une autre fenêtre, un navigateur, un message à un collègue. Un presse-papiers qui ne fonctionnerait qu'à l'intérieur de cet éditeur répondrait à la plus petite moitié de la demande, et à celle qu'on avait le moins de chances de poser.
Une copie part donc dans les deux : celui de l'éditeur, d'où Shift-Ins colle, et celui du système, atteint en le demandant au terminal par OSC 52. Rien ne vérifie le second, parce qu'il n'y a rien à vérifier — la séquence n'a pas de réponse, un terminal peut la refuser par sécurité, et certains demandent qu'on l'active. Un message promettant quelque chose qui n'a pas eu lieu serait pire qu'un message qui se tait : la barre d'état dit seulement combien de lignes ont été copiées, ce qui est vrai dans les deux cas.
Pourquoi copier sans rien sélectionner copie un bloc entier
Ce qu'on veut extraire d'une conversation, c'est presque toujours un bloc de code. Obliger à le sélectionner d'abord — six frappes, ou un glissement qu'il faut viser — est un travail que l'éditeur a déjà de quoi faire à votre place : c'est lui qui a mis la conversation en page, donc il sait exactement où ce bloc commence et finit.
Les lignes portent donc une région : un bloc de code délimité, un passage de prose, la sortie d'un appel d'outil. Sans rien de sélectionné, Ctrl-C copie la région sur laquelle est le curseur. Le libellé d'un interlocuteur et l'en-tête d'un appel d'outil sont du mobilier et reçoivent des régions à eux, ce qui garde ‣ Bob (llama.cpp) hors d'un bloc collé dans un fichier source.
Cette dernière partie n'a pas été conçue, elle a été trouvée. La première version copiait le libellé avec le code ; c'est en copiant depuis le vrai binaire et en relisant la charge utile OSC 52 sur le fil qu'on s'en est aperçu.
Pourquoi l'indicateur d'activité est dessiné à partir de l'horloge
Un agent qui réfléchit vingt secondes n'envoie strictement rien, et une fenêtre qui aurait l'air figée serait indiscernable d'une fenêtre réellement bloquée. L'indicateur est la réponse la moins chère possible à « est-ce que ça marche encore ? ».
C'est une fonction du temps — Spinner(now) — et non un compteur que quelque chose incrémente. Rien n'a besoin d'être remis à zéro au début d'un tour, deux fenêtres qui réfléchissent en même temps tournent en phase, et un test peut porter sur une image sans attendre qu'elle arrive — la même raison pour laquelle editor.View et app.App ont tous deux une horloge injectable.
Dessiner à partir de l'horloge veut dire qu'autre chose doit provoquer le redessin : une session en cours de tour réveille donc la boucle d'événements à la cadence de l'indicateur. Cela a le droit d'être un minuteur précisément parce qu'un battement perdu ne peut rien laisser en plan : il demande un tour de boucle et ne porte jamais de fait — la règle à laquelle ce projet est maintenant arrivé cinq fois.
Le titre de la fenêtre, lui, n'est délibérément pas animé. C'est aussi ce qu'affichent la liste des fenêtres et le menu Alt-chiffre, et un nom qui changerait huit fois par seconde les ferait scintiller sans rien apporter.
Pourquoi les commandes sont une liste dans la zone de saisie, et non un menu
Les commandes d'un agent arrivent sur le fil sous forme de liste — available_commands_update — et peuvent changer pendant la session. Un menu construit à partir d'elles devrait être reconstruit à chaque mise à jour, se trouverait loin de l'endroit où la commande se tape, et finirait quand même par mettre /web dans la zone de saisie, parce que c'est la seule chose que le protocole laisse un client envoyer : une commande est une invite texte que l'agent reconnaît à son premier mot.
La liste s'ouvre donc là où est le texte, sur le caractère qui commence une commande, et se ferme quand le mot est complet. C'est la même forme que la fenêtre de complétion au-dessus d'un fichier, pour la même raison : ce que vous choisissez est ce que vous tapez. Utiliser / et @ plutôt que des touches propres à l'éditeur est délibéré — ce sont les caractères de Zed, si bien que la documentation d'un agent est vraie ici sans table de correspondance.
Entrée a deux sens sur la liste, ordonnés par le degré d'achèvement du mot : elle complète un mot inachevé, et envoie un mot achevé. L'alternative — Entrée complète toujours, une seconde Entrée envoie — coûte une frappe à chaque commande et n'apporte rien, parce qu'un mot qui se lit déjà exactement comme une commande n'a plus rien à compléter.
Pourquoi une mention emporte le fichier, quand elle le peut
Le protocole offre deux façons de nommer un fichier dans une invite : un resource_link, qui est une URI que l'agent va chercher lui-même, et une resource incorporée, qui est l'URI et le texte. La spécification appelle la seconde « la façon préférée d'inclure du contexte », et la raison est celle qui fait répondre fs/read_text_file depuis le tampon : l'éditeur sait sur le fichier des choses que le disque ignore. Un agent qui suit un lien vers un fichier que vous avez modifié sans l'enregistrer lit la version que vous venez de quitter, ce qui est faux précisément au moment où vous êtes le plus susceptible de demander.
L'éditeur envoie donc le texte quand l'agent a déclaré promptCapabilities.embeddedContext, lu par le même chemin que fs/read_text_file, et un lien sinon — jamais rien. Un fichier qui ne peut pas être lu part aussi en lien, pour que l'agent sache au moins quel fichier était visé.
La mention remplace le nom dans le texte plutôt que de voyager à côté. Envoyer explique @main.go comme texte et comme pièce jointe donnerait à l'agent le nom deux fois en le laissant les apparier ; mettre le bloc là où était le nom lui donne le fichier là où la phrase en a besoin. La conversation, elle, garde la ligne telle que tapée : c'est ce que vous avez dit, et la fenêtre est le compte rendu de la conversation, pas du fil.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 |
|