Markdown en tant que protocole pour les interfaces agentiques avec exécution en flux continu

Un développeur a construit un prototype explorant comment combiner une interface utilisateur générative avec l'exécution de code pour les agents d'IA en utilisant Markdown comme protocole unifié. Le système diffuse du texte, du code exécutable et des données dans une seule réponse, le code s'exécutant de manière incrémentielle à mesure qu'il arrive.

Le Protocole : Markdown avec Trois Types de Blocs

L'approche utilise la syntaxe Markdown standard que les LLM comprennent déjà, évitant ainsi d'avoir à enseigner de nouveaux formats. Elle définit trois types de blocs :

• Blocs de texte : Un formatage Markdown simple qui est diffusé à l'utilisateur
• Clôtures de code : ```tsx agent.run exécute du code TypeScript/JSX sur le serveur dans un contexte persistant
• Clôtures de données : ```json agent.data => "id" diffuse des données JSON dans les composants d'interface utilisateur

Ces blocs peuvent être entrelacés dans n'importe quel ordre au sein d'une seule réponse. L'analyseur les traite de manière incrémentielle à mesure que les tokens arrivent du LLM.

Exécution en Flux

Le code s'exécute instruction par instruction à mesure que le LLM le génère, sans attendre la fermeture complète de la clôture de code. Cela permet aux appels d'API de démarrer, à l'interface de s'afficher et aux erreurs de remonter pendant que le LLM envoie encore des tokens. Le développeur a construit bun-streaming-exec pour gérer cela, en utilisant vm.Script avec un enrobage personnalisé car l'exécution en flux n'est pas une primitive standard du runtime.

Interface Agentique avec la Primitive mount()

Le système utilise React pour la génération d'interface car les LLM ont une grande exposition aux composants React et au JSX. La primitive centrale est mount() :

mount({
  ui: () => <Card>Bonjour de la part de l'agent !</Card>
});

Lorsque le LLM génère ce code et que le serveur l'exécute, mount() sérialise le composant React et l'envoie au client pour qu'il soit rendu dans l'interface de chat.

Modèles de Flux de Données

Le prototype implémente quatre modèles distincts pour le mouvement des données :

1. Client → Serveur (formulaires) : L'agent peut attendre une saisie utilisateur via des formulaires
2. Serveur → Client (données diffusées) : Les clôtures de données diffusent du JSON directement dans les interfaces montées
3. Serveur → LLM (console.log) : La sortie de console.log et les exceptions sont renvoyées au LLM comme un nouveau tour
4. LLM → Serveur → Client (boucle complète) : Des cycles complets où le LLM génère du code qui récupère des données et affiche une interface avec ces données

Boucle de Rétroaction

Le système utilise console.log comme mécanisme pour que l'agent se parle à lui-même. Lorsque le LLM génère du Markdown avec des blocs de code, le texte est diffusé à l'utilisateur tandis que le code s'exécute de manière incrémentielle. Toute sortie console.* ou exception est renvoyée au LLM comme un nouveau tour. S'il n'y a pas de sortie ou d'exception, le système attend une nouvelle requête utilisateur.

Cela permet à l'agent de réagir à sa propre exécution, par exemple en vérifiant le nombre de messages ou en faisant une pause pour attendre une saisie utilisateur avant de continuer.