Agent Chat UI : une interface de chat pour n'importe quel serveur LangGraph

Le problème : voir un graphe LangGraph sans écrire d'interface

Un graphe LangGraph s'exécute côté serveur. Pour l'observer en train de répondre, il faut un client qui ouvre un flux, envoie des runs et affiche les messages. Agent Chat UI est ce client. L'application est décrite dans le README comme une application Next.js permettant de dialoguer avec n'importe quel serveur LangGraph exposant une clé messages. Le périmètre est donc volontairement étroit : pas de tableau de bord, pas d'édition de graphe, une fenêtre de conversation et un panneau latéral pour les artefacts. Le public visé est l'équipe qui développe le graphe, en Python ou en TypeScript, et qui veut un banc d'essai maniable. Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation et la modification, y compris dans un produit propriétaire, à condition de conserver la notice de licence. Rien dans le matériel fourni ne permet de dire si le projet est maintenu activement au-delà de la date du dernier push.

Ce que l'application attend de votre serveur

Le contrat est réduit à une convention de forme. Le serveur doit exposer une clé messages : c'est la seule exigence que le README formule explicitement. L'interface lit les événements de streaming du modèle, en particulier on_chat_model_stream, pour afficher le texte au fil de sa génération. Ce détail importe, car il détermine la manière dont on masque un message. Le graphe peut aussi publier un champ thread.meta.artifact, que l'interface présente dans un panneau à droite de la conversation. Le README fournit un hook useArtifact construit sur useStreamContext, avec un type de métadonnée qui décrit un composant et un objet d'état comportant open, setOpen, context et setContext. Autrement dit, l'artefact n'est pas un composant rendu par le serveur : c'est un composant React que vous écrivez et que le contexte du thread vient alimenter. Cette séparation est saine pour la sécurité, puisque le serveur ne pousse pas de HTML, mais elle déplace tout le travail de rendu dans votre code client.

Démarrage local et variables d'environnement

Le README donne deux chemins. Le premier passe par npx create-agent-chat-app. Le second par un clone classique : git clone https://github.com/langchain-ai/agent-chat-ui.git, puis cd agent-chat-ui, pnpm install et pnpm dev. L'application écoute alors sur http://localhost:3000. Au premier lancement, un formulaire demande quatre valeurs : l'URL de déploiement du serveur LangGraph, l'identifiant d'assistant ou de graphe, la clé API LangSmith, et une bascule Built with Agent Builder qui, activée, force le schéma d'authentification à langsmith-api-key. La clé LangSmith n'est requise que pour les serveurs déployés. Pour éviter ce formulaire, on copie .env.example vers .env et on renseigne NEXT_PUBLIC_API_URL, NEXT_PUBLIC_ASSISTANT_ID et NEXT_PUBLIC_AUTH_SCHEME. Le README précise que pour un déploiement LangSmith Agent Builder, il faut poser NEXT_PUBLIC_AUTH_SCHEME=langsmith-api-key. Un redémarrage est nécessaire après modification du fichier. Ces clés portent le préfixe NEXT_PUBLIC_, donc elles sont intégrées au bundle client : n'y mettez pas de secret.

Masquer un message : deux mécanismes, deux portées

Le premier mécanisme agit sur le direct. En ajoutant le tag langsmith:nostream à la configuration du modèle, on empêche l'émission des événements on_chat_model_stream pour ce modèle, et l'interface n'affiche donc plus le texte pendant sa génération. Le README donne l'exemple Python avec ChatAnthropic().with_config(config={"tags": ["langsmith:nostream"]}) et l'équivalent TypeScript avec .withConfig({ tags: ["langsmith:nostream"] }). Attention au piège signalé dans le README lui-même : si le message est ensuite enregistré dans l'état du graphe sans autre modification, il réapparaîtra une fois l'appel terminé. Le second mécanisme est définitif. Avant d'ajouter le message à l'état, on préfixe son identifiant par do-not-render-, et on ajoute le tag langsmith:do-not-render au modèle. L'interface filtre tout message dont l'id commence par ce préfixe. C'est une convention de nommage, pas une barrière de sécurité : un identifiant réécrit par un autre chemin de code contourne le filtre. Le README l'assume et parle de garantie d'affichage, pas de confidentialité.

Le passage en production n'est pas inclus par défaut

C'est la limite la plus nette du projet, et le README la formule sans détour. Par défaut, l'application est configurée pour le développement local et se connecte au serveur LangGraph directement depuis le client. En production, ce montage suppose que chaque utilisateur possède sa propre clé LangSmith et configure lui-même LangGraph. Le README propose deux voies d'authentification. La plus rapide consiste à proxifier les requêtes vers le serveur via le paquet langgraph-nextjs-api-passthrough, qui attache la clé LangSmith côté serveur afin que les utilisateurs n'en aient jamais besoin. Le matériel fourni s'interrompt au milieu de cette phrase et ne décrit pas la seconde voie. Il faut donc lire la suite du README avant de choisir. Un point est certain : tant que ce proxy n'est pas en place, l'application n'est pas un produit multi-utilisateurs, c'est un outil interne.

Face à une interface maison ou à LangSmith Studio

Deux alternatives se dessinent. La première est l'interface que votre équipe écrirait elle-même : même flux, même clé messages, mais vous gardez la main sur l'authentification, le routage et le rendu des artefacts. Le coût est réel, et Agent Chat UI existe précisément pour l'éviter. La seconde est l'outil d'observation fourni avec la plateforme LangSmith, qui sert à inspecter des traces et des exécutions plutôt qu'à offrir une fenêtre de conversation à des utilisateurs finaux. La différence d'approche tient au public : Agent Chat UI s'adresse à la personne qui va parler au graphe, l'outil de traces à celle qui le débogue. Le choix dépend donc de qui doit voir la conversation. Si c'est un utilisateur final, il faut finir le travail de production. Si c'est vous, la configuration locale du README suffit.

Ce que coûte la maintenance

Le projet est une application Next.js avec un gestionnaire de paquets imposé par le README, pnpm. Les dépendances suivent le rythme de Next.js et de React, ce qui implique des montées de version régulières sous peine de dériver. Le matériel fourni ne mentionne aucune publication de version, donc aucun canal de mise à jour documenté : la référence est la branche main. Le contrat avec votre serveur est mince, une clé messages et un identifiant de graphe, ce qui limite la casse en cas de changement. La licence MIT s'applique au code du dépôt. Elle ne dit rien des services auxquels l'application se connecte : l'usage d'un serveur LangGraph déployé et d'une clé LangSmith relève des conditions de la plateforme, pas de la licence. Sur ce point, le README ne se prononce pas et il faut se référer aux conditions du service concerné.

Conclusion éditoriale

Agent Chat UI convient à qui développe un graphe LangGraph et veut le voir répondre dans un navigateur sans écrire d'interface. Ceux qui n'ont pas de serveur LangGraph compatible, ou qui attendent une application multi-utilisateurs prête à déployer, doivent passer leur chemin. Avant d'adopter, vérifiez que votre serveur expose bien une clé messages et testez le chemin de production décrit dans le README, car la configuration par défaut connecte le client directement au serveur avec la clé LangSmith de chaque utilisateur.

Sources officielles

1. Issues
2. langchain-ai/agent-chat-ui on GitHub
3. License: MIT
4. Project website
5. README