La télécommande universelle pour l'IA — Alex Hancock, Block

AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Alex Hancock : Bonjour à tous. Je m'appelle Alex Hancock. Aujourd'hui, je vais vous parler d'une
00:00:17télécommande universelle pour l'IA. Et avant de commencer, je tiens juste à dire que l'intervenant
00:00:21précédent a affirmé que les mainteneurs de clients MCP n'avaient pas implémenté la prise en charge
00:00:26des tâches parce qu'ils étaient intelligents. Je suis mainteneur d'un client MCP et je peux vous
00:00:33dire que c'est simplement parce que je suis paresseux. Je ne l'ai pas fait. Bon,
00:00:37présentons-nous brièvement avant de commencer. Je suis ingénieur logiciel chez Block, la société
00:00:43mère de Cash App, Square et Tidal. Nous avons pas mal de projets en cours actuellement.
00:00:47Je travaille là-bas depuis longtemps. J'ai travaillé sur des produits Square et des fonctionnalités
00:00:51de Cash App. Mais ces dernières années, je me suis consacré à l'IA open source. Plus précisément,
00:00:56je travaille sur ce projet de framework open source appelé Goose, qui a débuté en interne chez Block.
00:01:02Oui, je vois des fans de Goose dans la salle. Ensuite, nous l'avons passé en open source et nous
00:01:07l'avons donné à la Linux Foundation. La propriété intellectuelle y réside donc désormais. Mais beaucoup
00:01:14d'entre nous chez Block continuent d'y contribuer. Je suis également mainteneur de MCP, le Model
00:01:20Context Protocol. Je travaille sur le SDK Rust de ce projet. Plus récemment, j'ai aussi commencé
00:01:27à travailler sur l'ACP (Agent Client Protocol), qui est le sujet du jour. Je pense que nous avons
00:01:35un problème avec les frameworks que j'aimerais vous exposer aujourd'hui, vous présenter comme un
00:01:40problème, avant de vous recommander une solution. Ces derniers temps, j'ai remarqué que nous
00:01:46avons d'excellents frameworks, n'est-ce pas ? Il y a ceux des laboratoires, ceux de différentes
00:01:52entreprises, et beaucoup basés sur des standards ouverts. Mais j'ai constaté que leur interface
00:01:57est souvent personnalisée ou sur mesure. Dans le pire des cas, vous pouvez avoir des frameworks
00:02:03qui ne possèdent littéralement qu'une seule application cliente pour les contrôler, n'est-ce pas ?
00:02:11Cela pose plusieurs problèmes. Pour faire une analogie avec le web, ce serait comme si vous
00:02:16deviez utiliser un seul navigateur ou un seul protocole donné pour vous connecter à chaque site web.
00:02:22Cela ne fonctionnerait tout simplement pas. Nous n'aurions pas un web ouvert si c'était la réalité
00:02:28des navigateurs. Je pense donc que nous pouvons faire mieux. Et le propre des standards, c'est
00:02:35qu'ils créent des écosystèmes et des marchés. Je dirais que dans le domaine de l'IA agentique,
00:02:41nous disposons d'un bon standard pour permettre à l'agent d'agir, d'appeler des outils, d'exécuter des
00:02:47actions dans d'autres systèmes, de lire des ressources et des données. Nous avons tous bénéficié en
00:02:53tant que communauté d'avoir MCP, n'est-ce pas ? Et la force principale de MCP ne réside pas dans le
00:02:58protocole en soi, mais dans le fait que tout le monde l'utilise. C'est pourquoi nous avons des
00:03:05milliers ou des dizaines de milliers de serveurs dans le monde, et que tous les agents peuvent s'y
00:03:13connecter pour agir dans ces systèmes tiers. Je dirais que nous n'avons pas encore de bonne solution
00:03:20ou de standard permettant aux logiciels clients de donner des instructions aux agents, de leur assigner
00:03:26des tâches, de leur dire sur quoi travailler et de recevoir des mises à jour. Je vais donc vous
00:03:32proposer aujourd'hui une option qui me semble pertinente, sur laquelle notre équipe travaille et
00:03:39que nous considérons comme une excellente solution dans l'espace des standards ouverts : l'ACP.
00:03:45Agent Client Protocol est le nom de ce projet. Il vient des éditeurs de logiciels. Si vous
00:03:49avez utilisé l'éditeur Zed ou l'un des produits de JetBrains, les équipes de Zed et de JetBrains
00:03:54ont fait équipe pour proposer un standard permettant aux clients de contrôler des frameworks.
00:04:00C'est tout à fait logique si l'on se place de leur point de vue, n'est-ce pas ? Ce qu'ils
00:04:06en voyant les choses de leur point de vue, n'est-ce pas ?
00:04:10éditeur, que ce soit Zed, IntelliJ ou autre, et pouvoir contrôler n'importe quel framework avec
00:04:17cette même implémentation, en envoyant des tâches, en récupérant des résultats, en voyant quels
00:04:22fichiers sont modifiés, etc. C'est parfaitement logique quand on y pense. Mais nous avons compris
00:04:30cela dans l'équipe Goose, et nous pensons que l'utilité va bien au-delà des simples éditeurs. Il
00:04:37est relativement neutre et ne comporte pas beaucoup de fonctionnalités spécifiques aux éditeurs.
00:04:45Nous pensons donc qu'il peut être adopté par un plus large éventail de logiciels clients. Pour
00:04:51entrer un peu plus dans les détails de la conception d'ACP et de ses possibilités, il vous permet
00:04:59d'établir des connexions entre des clients et des frameworks d'agents dotés d'un ensemble de
00:05:04capacités associées à la connexion. Vous pouvez ensuite créer des sessions. Au sein de ces sessions,
00:05:10vous pouvez envoyer des messages utilisateur, c'est-à-dire ce que l'utilisateur tape dans
00:05:16l'application ou ce que le logiciel client souhaite transmettre. L'agent peut alors y répondre par du
00:05:24texte, des images, de l'audio, ou par des mises à jour sur ce qui se passe. Par exemple, si
00:05:29un outil est appelé, il peut envoyer une notification d'appel d'outil pour expliquer quel outil a
00:05:37été utilisé et quelles étaient les métadonnées. Il peut aussi envoyer des demandes d'autorisation
00:05:41afin que le logiciel client puisse demander à l'utilisateur si oui ou non il doit exécuter cet
00:05:46appel d'outil. Sa conception est assez simple : il utilise des messages JSON-RPC. Et ce que nous
00:05:52aimons le plus, c'est qu'il est également extensible. Vous n'êtes donc pas limité au protocole de
00:05:58base. Vous pouvez ajouter des méthodes personnalisées. La convention consiste à utiliser un tiret
00:06:03bas suivi de vos propres méthodes. Ce qui me plaît là-dedans, c'est que si suffisamment de projets
00:06:12de frameworks ou de clients l'adoptent, nous pourrons voir ce que nous faisons tous en commun,
00:06:18n'est-ce pas ? Par exemple, si l'équipe Codex ou l'équipe Goose implémente des méthodes personnalisées,
00:06:25ou n'importe quelle équipe cliente, nous pourrons observer ce qui émerge dans l'écosystème et ce qui
00:06:31mérite d'être standardisé et intégré au protocole lui-même, de sorte qu'il soit façonné par les
00:06:36usages et par la communauté. Je vais faire une démonstration d'une version utilisant les entrées/sorties
00:06:42standard. Je vais donc ouvrir Zed et j'ai ici un projet très simple où je vais demander de me
00:06:50parler de ce projet. Il s'agit d'un fichier HTML unique. Vous voyez que j'ai pu saisir ma requête
00:06:55dans Zed, et l'agent utilisé ici est Goose, via son interface ACP. Vous pouvez voir qu'il renvoie
00:07:01du texte, des informations sur les appels d'outils concernant ce qu'il a lu et fait. Il a découvert
00:07:06qu'il s'agissait d'un unique fichier HTML et l'a expliqué. Je vais en faire une autre, je vais en
00:07:13faire une autre. Celle-ci provient d'une entreprise appelée Poolside AI. Je vais demander de me
00:07:21parler de ce projet dans ce même environnement. Il s'agit d'un client en terminal qui obtient
00:07:25exactement la même expérience avec le même agent, une seule implémentation côté framework, et vous
00:07:31transport HTTP, il y a une version HTTP et il y a une mise à niveau WebSocket. Et donc maintenant les messages sont les mêmes,
00:07:37fait la même chose : il m'a affiché des résultats textuels, un appel d'outil, puis il a diffusé un
00:07:42résumé en streaming. C'est une démo basique montrant deux clients qui communiquent avec le même agent
00:07:49via des E/S standard en local. Mais le local ne suffit évidemment pas, n'est-ce pas ? Pour que cela
00:07:54se développe, il faut aussi prendre en charge le mode distant. Des agents vont tourner dans le
00:07:59cloud. Lorsque nous avons abordé ce projet, nous avons constaté qu'il ne disposait pas encore du
00:08:04support distant. Nous avons donc spécifié un transport HTTP (il existe une version HTTP et une mise à
00:08:13niveau WebSocket). Désormais, les messages sont les mêmes, la sémantique du protocole est la
00:08:18même, mais il y a un nouveau transport qui vient d'arriver et qui permet le mode distant. Pour nous,
00:08:24dans l'équipe Goose, la pile agentique comprend quatre composants essentiels, n'est-ce pas ? Le
00:08:29client, qui est l'application utilisée par l'utilisateur ou une application sans interface exécutée
00:08:34quelque part sur la machine ; le framework, qui est le programme implémentant la boucle d'appel
00:08:39des outils ; les outils eux-mêmes, souvent via MCP ; et enfin le modèle, n'est-ce pas ? En
00:08:46proposant un transport distant pour l'Agent Client Protocol, sachant que MCP possède déjà un transport
00:08:53distant pour les appels d'outils et que les modèles disposent d'endpoints distants (comme des API de
00:09:01réponse) depuis longtemps, vous avez désormais la flexibilité de déplacer ces quatre composants.
00:09:03Ils peuvent tous se trouver sur la même machine, ou le framework peut tourner sur une machine
00:09:09différente de celle du client. Le modèle peut être le seul élément distant, ou les outils peuvent
00:09:15l'être également. S'accorder sur des standards et s'assurer qu'ils gèrent bien les transports
00:09:21est ce qui nous permettra de déplacer tous les éléments de cette pile agentique. Je peux également
00:09:25en faire une rapide démonstration. Voici un client, juste pour montrer à quel point il est
00:09:29simple de créer des clients pour cela. Je l'ai codé à l'instinct hier soir, et je vais dire :
00:09:34“Écris un poème.” Il se connecte donc de nouveau au même processus sur ma machine. Dans ce cas,
00:09:41je l'exécute sur le réseau, mais c'est local. Il se connecte et envoie des instructions à Goose
00:09:49sur les tâches à exécuter à distance. Cela pourrait être dans un conteneur, dans le cloud, mais
00:09:54les messages et la bibliothèque utilisés restent les mêmes. Vous pouvez donc basculer entre le
00:10:00mode local et distant très, très facilement. Si vous souhaitez vous intégrer à cet écosystème,
00:10:06commencez à expérimenter le support, que ce soit en créant vos propres clients ou en ajoutant
00:10:12des fonctionnalités aux frameworks. Ceci vous redirigera vers le site de l'Agent Client Protocol
00:10:17pour savoir comment démarrer. Il existe déjà un certain nombre de clients et de serveurs d'agents.
00:10:22Cela va des éditeurs aux applications de bureau, en passant par les applications mobiles et les
00:10:26outils en terminal. Il y a une véritable prolifération. Et je pense que les cas d'usage sont
00:10:33potentiellement immenses, n'est-ce pas ? Si nous parvenons à obtenir de l'interopérabilité,
00:10:37car les gens pourront créer des clients personnels exactement comme ils le souhaitent pour orchestrer leurs agents, ou des clients conçus pour certains domaines professionnels, pour une entreprise spécifique ou un ensemble d'entreprises. Vous pourriez personnaliser un client en marque blanche pour qu'il fonctionne avec tous les frameworks. Je pense aussi qu'en créant cette nouvelle catégorie, nous verrons la qualité des clients augmenter, n'est-ce pas ? Car chaque fois qu'un écosystème ou un marché se développe et offre de nombreuses options, les utilisateurs peuvent voter avec leurs pieds si les clients ne répondent pas à leurs besoins. Les gens commenceront donc à rivaliser sur la qualité de l'expérience utilisateur, et globalement, cela devrait améliorer l'expérience d'utilisation de l'IA. C'est tout pour moi aujourd'hui. Merci beaucoup. Si vous souhaitez discuter avec moi, retrouvez-moi après ou envoyez-moi un e-mail. Je serais ravi de vous faire participer à ce travail. Merci.

핵심 요약

L'adoption de l'Agent Client Protocol permet aux clients logiciels et aux frameworks d'intelligence artificielle de communiquer via un standard unifié, gérant à la fois les modes locaux et distants.

하이라이트

  • L'Agent Client Protocol standardise la communication entre les logiciels clients et les frameworks d'agents d'intelligence artificielle.

  • Le framework open source Goose, développé initialement chez Block, est désormais confié à la Linux Foundation.

  • Le protocole ACP prend en charge les flux de transport HTTP et WebSocket pour permettre le mode distant des agents.

  • Les messages JSON-RPC constituent la base de conception simple et extensible du protocole ACP.

  • L'interopérabilité offerte par l'ACP permet d'associer un client unique à de multiples frameworks d'agents.

타임라인

Présentation des projets et du problème d'interopérabilité

  • Le projet open source Goose migre vers la Linux Foundation.
  • Le protocole Model Context Protocol gère efficacement les appels d'outils mais manque d'un équivalent pour les instructions des clients.
  • L'absence de standardisation pour le contrôle des frameworks d'agents isole les applications clientes.

L'intervenant présente son rôle d'ingénieur chez Block et de mainteneur sur plusieurs projets d'intelligence artificielle open source. Il expose les limites actuelles des frameworks qui possèdent des interfaces sur mesure ou une seule application cliente dédiée, comparant cette situation dysfonctionnelle à l'obligation d'utiliser un navigateur web unique pour chaque site.

Fonctionnement et conception de l'Agent Client Protocol

  • Zed et JetBrains conçoivent initialement l'Agent Client Protocol pour relier les éditeurs aux frameworks.
  • Le protocole gère les sessions, les messages utilisateurs, les réponses multimodales et les demandes d'autorisation d'outils.
  • L'utilisation de messages JSON-RPC et l'extensibilité permettent d'ajouter des méthodes personnalisées.

L'Agent Client Protocol dépasse le cadre des seuls éditeurs de code pour s'appliquer à une gamme plus large de logiciels clients. Les démonstrations pratiques illustrent l'utilisation du même agent Goose à travers différentes interfaces clientes connectées via les entrées/sorties standard locales.

Support distant et perspectives de l'écosystème agentique

  • Un transport HTTP et WebSocket permet d'exécuter les agents à distance dans le cloud.
  • La pile agentique se compose du client, du framework, des outils et du modèle.
  • La standardisation favorise l'émergence d'un marché concurrentiel axé sur la qualité de l'expérience utilisateur.

L'ajout d'un transport distant comble le manque initial du protocole pour faire fonctionner les composants sur des machines distinctes. Cette flexibilité structurelle ouvre la voie à des clients personnalisés par domaine professionnel et stimule la concurrence sur l'expérience utilisateur.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기