L'interface utilisateur de chat grandit : mise en page redimensionnable, appels d'outils imbriqués, cartes de sous-agents

Une visible, une silencieuse : l'interface utilisateur grandit tandis que le backend jette les bases

Le travail de la journée était divisé en une moitié visible et une moitié invisible. La moitié visible : l’interface de chat a mûri d’un cran – c’est ce à quoi les utilisateurs sont confrontés chaque jour, où chaque progrès se voit immédiatement. La moitié invisible : le backend a discrètement jeté une base de grande envergure, un environnement d'exécution qui permet "d'installer en toute sécurité des fonctionnalités tierces en tant que plugin". Cette dernière n'a livré presque rien qu'un utilisateur puisse percevoir ce jour-là, mais elle décide si la plate-forme peut passer d'une "application avec des fonctionnalités codées en dur" à "une plate-forme qui peut être étendue à l'infini, même construite par les utilisateurs". Vus le même jour, les deux incarnent un équilibre : continuer à peaufiner l’expérience disponible tout en misant sur l’extensibilité à long terme.

Le chat mûrit : mise en page redimensionnable + appels d'outils imbriqués sous leur tâche

Les progrès de l'interface ce jour-là se sont concentrés sur "une organisation plus claire des informations". Premièrement : la barre latérale, la zone de discussion et le panneau inférieur sont tous redimensionnables, vous pouvez donc allouer de l'espace sur l'écran à tout ce que vous faites : réduisez la discussion lors de la lecture du code, augmentez le bas lorsque vous regardez la sortie. Deuxièmement, et plus important encore : les appels d'outils s'imbriquent désormais sous l'élément de tâche auquel ils appartiennent, plutôt que de se disperser dans une longue liste plate. Lorsqu'un agent exécute une tâche en plusieurs étapes, vous pouvez clairement voir « quels outils il a appelés pour terminer cette étape », avec une hiérarchie évidente en un coup d'œil. Ce que les longues conversations et les tâches en plusieurs étapes redoutent le plus, ce sont les informations qui se fondent en une masse qui cache les progrès ; ces deux changements permettent de « voir clairement qui fait quoi et jusqu'où » est réel.

Les sous-agents reçoivent leurs propres cartes

À mesure que la collaboration multi-agents devenait courante, « un agent principal déléguant à plusieurs sous-agents » est devenu un scénario quotidien. Cette journée a donné à l'activité des sous-agents sa propre carte de présentation : les sous-tâches ne se mélangent plus au flux texte de la conversation principale mais reçoivent chacune une carte pliable avec son propre contexte. Cela permet de distinguer instantanément « qui travaille pour qui et comment chacun progresse ». Pour une plate-forme qui considère « une personne dirigeant une équipe d'IA » comme un scénario de base, cette façon de « donner au travail de chaque membre sa propre place » est essentielle – sinon, à mesure que l'équipe grandit, l'écran devient un ragoût illisible. La carte de sous-agent est la première étape pour transformer le « multi-agent » abstrait en une image que vos yeux peuvent lire directement.

Live et replay unifiés dans un seul pipeline

Avant cela, « regarder l'agent en direct » et « rejouer l'historique par la suite » étaient probablement deux chemins de rendu distincts. Ainsi, pour le même contenu, ce que vous voyiez en direct et ce qui était rejoué étaient souvent en désaccord dans les détails. Aujourd'hui, ils les ont unifiés sur un seul pipeline partageant les mêmes rappels de traitement : que le contenu soit diffusé en direct ou relu à partir du registre historique, il parcourt exactement le même chemin d'analyse et de présentation. L’importance est la cohérence : rouvrez une partie de l’histoire et vous voyez exactement ce qui s’est réellement passé, sans qu’aucun détail ne soit déformé. Cette conception de « chemin de source unique de vérité » supprime à la fois le fardeau du maintien de deux logiques et élimine à la racine la classe de bugs la plus déroutante : « le désaccord en direct et en relecture ».

Une base d'exécution de plugin backend : bus, autorisations, bac à sable

Le travail le plus lourd du backend à ce jour consistait à créer une base d'exécution de plug-in, visant à permettre « aux capacités tierces d'être installées et exécutées en toute sécurité en tant que plug-in ». Il est composé de pièces maillées : un bus d'événements en cours de processus pour que les composants communiquent librement via la publication/l'abonnement ; analyse et validation des manifestes de plugin, avec anti-contrefaçon sur la "portée" déclarée par un manifeste (afin qu'un plugin ne puisse pas mentir sur ses autorisations) ; un moteur d'autorisation qui contraint par des règles ce que chaque plugin peut et ne peut pas toucher ; une API de fichiers en bac à sable avec des verrous de fichiers coopératifs afin que plusieurs plugins en lecture et en écriture ne se corrompent pas ; plus un registre de fichiers en annexe uniquement enregistrant ce qui s'est passé. Cet ensemble complet n'a livré presque rien pour l'utilisateur ce jour-là, mais c'est le véritable point de départ de la direction à long terme "tout est un plugin" - avec lui, de nouveaux outils, de nouveaux ateliers ou de nouveaux agents peuvent ensuite se connecter de manière unifiée, contrôlée et en bac à sable, sans réécrire le noyau pour chaque ajout.

Moteur : un vocabulaire de composants étendu + des ressources de scène

Le moteur n'a cessé d'élargir le « vocabulaire » avec lequel il décrit un monde de jeu. Le système de composants prend en charge les formes de données telles que les chaînes et les tableaux de longueur fixe/variable, ainsi qu'un composant « nom » intégré — de sorte que chaque objet d'une scène peut avoir un nom lisible plutôt qu'un simple numéro interne, ce qui est bien plus pratique pour le débogage et pour une visualisation ultérieure dans un éditeur. Plus important encore, des « actifs de scène » ont été introduits : gérer une scène entière comme un objet d'actif référençable et instanciable, avec un mécanisme pour instancier une scène dans le monde. Cela signifie que les scènes peuvent désormais être enregistrées, référencées et réutilisées structurellement, tout comme les modèles et les textures – la condition préalable sous-jacente à toutes les capacités ultérieures telles que « construire des scènes dans un éditeur, assembler des scènes en niveaux ».

Un portail qualité moteur : contrôle à deux canaux

Le moteur a également mis en place aujourd'hui un contrôle de qualité à deux canaux, vérifiant automatiquement la qualité du code sous deux angles complémentaires : un canal effectue des contrôles de style et de convention conventionnels, l'autre surveille spécifiquement les limites d'utilisation des "interfaces internes" - garantissant que les éléments destinés à un usage interne uniquement ne sont pas involontairement exposés au public. Les deux canaux fonctionnent en intégration continue, automatiquement à chaque validation. Sa valeur est à l'image de la référence de rendu précédente : transformer "la qualité du code est-elle correcte" de l'examen humain et de l'autodiscipline en une porte automatique, objective et inévitable. Un moteur destiné à évoluer sur le long terme et à faire face à toujours plus de collaborateurs s'appuie porte après porte automatique pour itérer rapidement sans pourrir lentement.

Ce que signifie cette journée

Les deux lignes du jour représentent exactement les deux objectifs qu'un produit mature doit atteindre à la fois : l'une est la sensation actuelle de l'utilisateur, l'autre le squelette à long terme de la plateforme. La maturation de l'interface de chat la rend plus confortable à utiliser pour le moment, tandis que le runtime de plugin presque invisible du backend plante la graine de "si cette plate-forme peut être étendue sans limite ultérieurement". Prendre soin du présent et investir sur le long terme le même jour nécessite une division claire du travail et un jugement sur les priorités – qui sont des expériences qui doivent porter leurs fruits immédiatement et qui méritent d’être posées solidement, même si plus lentement. C'est une expérience qui mérite d'être conservée pour un développement futur : ne vous contentez pas d'empiler sur des fonctionnalités visibles et ne vous enfouissez pas uniquement dans des fondations invisibles ; ce qui est vraiment difficile, c'est de ne négliger ni l'un ni l'autre.