Comment construire un harnais d'entreprise ?
Nous avons développé des agents internes dans LangChain dans les domaines du marketing, des ventes et de l’ingénierie, et ils ont complètement transformé le fonctionnement de ces équipes. Ce n’était pas facile de les mettre en place correctement. Nous avons passé beaucoup de temps à résoudre les problèmes liés à un système multijoueur, et chaque équipe s’est retrouvée sur les mêmes primitives fondamentales :
- Il existe là où les gens travaillent déjà (pour nous, c’est Slack)
- Il sait qui demande et agit en tant que cette personne pour certains services, tout en conservant son propre identité pour d'autres
- Il possède une mémoire, ciblée au niveau global et/ou au niveau utilisateur
- Le code s'exécute dans un espace de sécurité et peut faire des requêtes aux services qui nécessitent une authentification
- Une grande part de ses exécutions est planifiée plutôt que d’être invoquée explicitement par quelqu’un (agents environnants!!)
Merci à @caspar_br pour son aide sur ce blog
Agents internes de LangChain
Pour donner un cadre à cette discussion, voici un bref aperçu des trois principaux agents que nous avons dans LangChain :
GTM Agent : un agent proactif en permanence qui aide dans les activités GTM. Il surveille et répond aux e-mails, aux nouveaux leads qualifiés, envoie des rapports quotidiens, peut répondre aux questions relatives aux comptes, peut exécuter des actions sortantes
OpenSWE : notre agent d’ingénierie peut travailler sur les PRs et les rédiger, mais il effectue également les revues de code pour tous les PRs
Content Studio : notre agent de marketing peut rédiger des éléments (blogs, images, PowerPoint, vidéos) dans notre style et en tenant compte de notre positionnement
Tous ces agents sont construits de la même manière. Nous pensons que c’est une méthode générale pour fabriquer des harnais d’entreprise.
Problème : Expérience utilisateur
Tous nos agents travaillent là où les gens travaillent déjà, c’est-à-dire sur Slack. Chacun d’eux dispose de ses propres applications Slack, et peut être contacté par DM ou marqué dans un canal. Un avantage de travailler avec ces agents dans les canaux est que d’autres peuvent voir comment les gens les utilisent.
Une chose agréable que nous avons ajoutée est le concept de « séparation » d’une conversation dans Slack. Souvent, une excellente discussion se déroule et vous voudriez intégrer votre agent pour obtenir son avis ou lui demander de faire quelque chose. Mais s’il y participait dans cette discussion, cela polluerait la conversation humaine et distrairait. Ainsi, nous avons ajouté une manière simple pour que les agents puissent « séparer » leur propre thread dans le canal.
Il y a certaines expériences utilisateur qui ne devraient pas être effectuées sur Slack. Par exemple, lors de la révision des e-mails que l’agent GTM me demande d’envoyer, il est acceptable de le faire individuellement sur Slack, mais si il y a un grand backlog, il n’est pas agréable de suivre ces messages via Slack. Pour de telles expériences, nous avons finalement développé une interface personnalisée.
Problème : Identité
Le problème le plus compliqué et le plus difficile que nous avons abordé était l’identité : en particulier, lorsque ces agents agissent, pour qui agissent-ils ?
Il y a deux méthodes principales pour gérer cela dans l’industrie :
- On-behalf-of : l’agent agit au nom de l’utilisateur qui appelle l’agent
- Identifiants fixés : il existe un ensemble d’identifiants fixe que l’agent utilise indépendamment de la personne qui l’appelle (par ex. un compte de service).
C’est ainsi que nous avons géré la situation pour chaque agent (documents : Ajouter l’identité aux agents Deep Gérés, Gérer les connexions) :
OpenSWE:
- Lorsque vous en envoyez le message, il agit en votre nom (par exemple, il ouvrira les PRs avec votre handle GitHub).
- Lorsqu’il fonctionne en arrière-plan (par exemple, en tant qu’agent de revue de code), il agit avec sa propre identité (application GitHub)
Agent GTM :
- Il dispose de certains outils (par exemple, l’accès à Salesforce) où il utilise une identité fixe, donc tous les utilisateurs ne doivent pas se connecter
- Il dispose de certains outils (par ex. e-mail) qui agissent au nom de l’utilisateur qui appelle l’agent. Ces outils sont DISPONIBLES SEULEMENT dans les DM. Dans les canaux partagés, ils ne sont pas disponibles
Content Studio :
- Il dispose de certains outils (par ex. Notion) où il agit au nom de l’utilisateur qui appelle l’agent.
- Il dispose de certains outils (par exemple Twitter) où il utilise un ensemble fixe de identifiants, dans ce cas pour le compte Twitter de notre entreprise. Cependant, seuls les utilisateurs inscrits dans une liste blanche peuvent exécuter certaines opérations. Par exemple, tous ne peuvent pas poster sur Twitter (ils ne peuvent que lire ou rédiger).
Problème : Mémoire
Tous les agents disposent de deux niveaux de mémoire :
- Mémoire globale : mémoire qui s'applique à tous les utilisateurs
- Mémoire utilisateur : mémoire qui s’applique uniquement au utilisateur spécifique
Les agents décident quels faits ils veulent mémoriser pour quel niveau de mémoire.
C’est probablement la zone la moins explorée jusqu’à présent – nous avons beaucoup de travail à faire ici !
Problème : Exécution du code
Tous nos trois agents peuvent écrire et exécuter du code, et ont souvent besoin de cela pour accomplir des tâches. Ils suivent tous le même modèle : fonctionner en dehors du sandboks, mais se connecter à celui-ci et exécuter du code à l’intérieur. Ils disposent tous d’images de base légèrement différentes, avec des dépendances distinctes. OpenSWE (l’agent le plus lié à la programmation) est intelligent quant à l’image de base qu’il démarre (différent selon le canal ou l’utilisateur). Tous ils profitent du proxy secret sur LangSmith Sandboxes (voir également Ajouter un sandboks aux Managed Deep Agents) afin que l’agent puisse se connecter aux services de manière sûre et sécurisée depuis le sandboks lui-même.
Problème : Exécutions planifiées
Un grand pourcentage des opérations sont planifiées ou déclenchées en arrière-plan par des événements, plutôt que par un utilisateur direct.
Certaines de ces options sont définies par le développeur de l’agent. Par exemple : OpenSWE écoute les PR et, lorsqu’un nouveau PR est créé, il le examine.
D’autres sont configurés par l’utilisateur en demandant à l’agent de le faire. Par exemple : j’ai demandé à l’agent GTM de m’envoyer un rapport quotidien, et il a créé son propre cron pour le faire.
Tout est basé sur les Agents Profonds Gérés
Tous ces agents sont basés sur Managed Deep Agents, qui repose sur l’infrastructure ouverte Deep Agents. Elle fournit une infrastructure permettant de résoudre tous ces problèmes (canaux, crons, sandboxes, mémoire, identité), tout en offrant suffisamment de flexibilité pour personnaliser le comportement de l’agent selon les besoins. Essayez-le dès aujourd’hui avec le quickstart !