L'équipe LangChain sur MCP : une nouvelle direction pour la mise à l'échelle des outils d'agents d'IA ?

Récemment, le protocole de contexte de modèle (MCP) a suscité beaucoup d'intérêt dans le domaine de l'IA. Cette technologie vise à résoudre un problème central :Comment permettre aux utilisateurs d'étendre les capacités de l'outil à l'agent sous-jacent sans le contrôler ? Harrison Chase, PDG de LangChain, a parlé de l'utilité pratique du MCP lors d'un entretien avec LangGraph Nuno Campos, responsable de l'organisation de l'entreprise, aborde le sujet en profondeur.

La valeur fondamentale de MCP : étendre les outils pour les agents incontrôlables

Pour Harrison Chase, la valeur de MCP réside dans sa capacité à fournir aux utilisateurs un moyen d'ajouter des outils à des agents sur lesquels ils n'ont pas de contrôle direct. Il cite Claude Bureau, curseur et Planche à voile À titre d'exemple, il a été souligné que, lorsqu'ils utilisent ces produits, les utilisateurs ne peuvent pas modifier directement la logique de l'agent sous-jacent et que les outils à la disposition de l'agent sont limités à un petit nombre d'outils intégrés.

Toutefois, les utilisateurs peuvent souhaiter ajouter des outils supplémentaires à ces agents pour répondre à des besoins plus personnalisés. Par exemple, vous pouvez ajouter des outils supplémentaires à l'éditeur de code Curseur Intégrer un outil spécifique d'analyse de code ou ajouter un outil personnalisé d'accès à la base de connaissances à Claude Desktop. Afin d'atteindre cet objectif, un protocole commun est nécessaire pour permettre à l'agent de reconnaître et d'invoquer ces outils externes, et MCP a été créé pour résoudre ce problème.

Harrison a également noté que le MCP est également important pour les non-développeurs qui créent des agents. À mesure que la construction d'agents devient plus populaire, de plus en plus d'experts du domaine veulent être impliqués dans le processus de création d'agents. Ces experts n'ont peut-être pas de compétences approfondies en programmation, mais ils ont une connaissance approfondie du domaine et des besoins spécifiques en matière d'outils, et MCP abaisse les barrières à la construction d'agents en leur permettant de configurer les outils dont ils ont besoin sans avoir à modifier la logique de base de l'agent.

Harrison a reconnu la valeur potentielle du MCP en comblant une lacune importante dans l'écosystème des outils d'agent existants. Dans le monde en évolution rapide de la technologie des agents, il existe une demande croissante de fonctionnalités personnalisées pour les agents. Si le MCP peut effectivement réduire la complexité de l'intégration des outils, il accélérera sans aucun doute la popularité de la technologie des agents et donnera lieu à des scénarios d'application plus innovants. Pour les non-développeurs en particulier, une manière plus conviviale d'étendre les outils libérera grandement leur créativité et favorisera la démocratisation des applications d'IA.

Défis pragmatiques : personnalisation des agents et intégration des outils

Nuno Campos a remis en question l'utilité de MCP. Il affirme que la conception d'un agent doit être étroitement intégrée aux outils utilisés. Le simple fait d'ajouter des outils à un agent sans ajuster les indices du système de l'agent ou même l'architecture n'est souvent pas suffisant pour obtenir les résultats souhaités.

Nuno admet que MCP peut fonctionner si les utilisateurs souhaitent simplement remplacer les outils de recherche Web intégrés dans des applications telles que Windsurf. Mais ce n'est pas le cas d'utilisation le plus intéressant pour MCP, affirme-t-il. Le cas d'utilisation le plus convaincant serait que les utilisateurs injectent un "outil magique" qui donnerait aux développeurs d'applications comme Cursor de nouvelles capacités qu'ils n'avaient même pas envisagées. Dans la pratique, cependant, il est très peu probable que cela se produise.

Nuno a souligné que dans la plupart des environnements de production, pour s'assurer qu'un agent est en mesure d'utiliser efficacement les outils, il est nécessaire d'ajuster les messages du système de l'agent, et même l'architecture globale, pour correspondre à l'ensemble des outils disponibles.

Le point de vue de Nuno est plus pragmatique sur le plan technique. Il souligne que l'intégration des outils n'est pas simplement "plug and play" et que les performances d'un agent dépendent largement de la manière dont il fonctionne avec l'outil. En fait, cela met en évidence un défi commun dans le développement de la technologie actuelle des agents d'IA : comment trouver un équilibre entre une grande flexibilité dans la mise à l'échelle des outils et l'optimisation des performances de l'agent. L'inquiétude de Nuno n'est pas vaine, car de nombreux développeurs ont constaté l'importance d'une ingénierie rapide lorsqu'ils travaillent avec de grands modèles de langage, et l'impact profond que l'architecture du système peut avoir sur le résultat final.

Compromis entre la fiabilité et les attentes des utilisateurs

M. Harrison reconnaît qu'un agent basé sur l'outil d'intégration MCP peut ne pas être en mesure d'atteindre la fiabilité de 99%. Toutefois, il estime que même si la fiabilité de l'agent est légèrement inférieure, il peut encore être utile. Il souligne que si les descriptions et les instructions relatives aux outils sont importantes, les points suivants ne doivent pas être négligés :

1. MCP contient des définitions d'outils, et de bons serveurs MCP peuvent fournir de meilleures descriptions d'outils que celles que les utilisateurs peuvent écrire eux-mêmes.
2. Le MCP permet d'inclure des invites que l'utilisateur peut utiliser pour indiquer à l'agent comment utiliser l'outil.
3. Au fur et à mesure que les capacités du modèle sous-jacent s'améliorent, les performances prêtes à l'emploi de l'outil invoquant l'agent s'améliorent de plus en plus.

Selon M. Harrison, s'il n'est pas possible de construire un produit aussi complet que Cursor avec les seules intégrations MCP et les agents d'appel des outils génériques, les MCP peuvent toujours être utiles dans certains scénarios, tels que la construction d'agents internes ou personnels.

En réponse à la question de Nuno, Harrison s'est montré plus optimiste. Il reconnaît que le MCP n'est peut-être pas parfait dans tous les cas de figure, mais il insiste sur le principe pragmatique du "juste assez, c'est assez". Dans les premiers stades du développement technologique, la recherche de la perfection limite souvent l'innovation. Le point de vue de M. Harrison est également conforme à la nature itérative de la technologie, où une version utilisable est publiée rapidement, puis améliorée dans la pratique. En outre, sa confiance dans la capacité du modèle à s'améliorer reflète également un consensus général dans le domaine de l'IA : l'amélioration continue de la capacité du modèle continuera à repousser les limites des applications de l'agent.

Synchronisation des capacités des modèles avec les attentes des utilisateurs

Nuno a rétorqué que les tests d'invocation d'outils de LangGraph montrent que même avec un agent dont l'architecture et les invites sont adaptées à un ensemble d'outils spécifique, le modèle actuel n'a qu'un taux de réussite d'environ 50% lorsqu'il invoque le bon outil. Un agent personnel qui ne fonctionne pas correctement la moitié du temps est d'une utilité douteuse.

Nuno reconnaît que les capacités du modèle continueront de croître, mais aussi les attentes des utilisateurs. Il cite Jeff Bezos : "Les clients sont toujours insatisfaits du statu quo et leurs attentes sont sans fin". Si les développeurs maîtrisent l'ensemble de la pile technologique, y compris l'interface utilisateur, les indices, l'architecture et les outils, ils pourront peut-être répondre aux attentes croissantes des utilisateurs. Dans le cas contraire, les perspectives sont sombres.

Nuno est allé plus loin avec les données, soulignant les limites du modèle actuel en termes d'appels d'outils. Le taux de réussite du 50% est certainement un chiffre inquiétant, en particulier dans les environnements de production où l'efficacité et la fiabilité sont recherchées. Dans le même temps, Nuno a également placé la barre plus haut en termes d'attentes des utilisateurs. Les avancées technologiques doivent non seulement améliorer les capacités, mais aussi répondre aux attentes croissantes des utilisateurs. En fait, cela place la barre plus haut pour MCP et toutes les technologies d'agents d'intelligence artificielle : non seulement ils doivent fonctionner, mais ils doivent bien fonctionner et continuer à répondre aux besoins croissants des utilisateurs.

L'effet longue traîne et l'analogie avec Zapier

M. Harrison reste persuadé que les capacités du modèle vont s'améliorer. Il estime que, quel que soit le taux de réussite actuel des agents, il ne pourra que s'améliorer à l'avenir. Il insiste sur le fait que la valeur d'un MCP ne doit pas être évaluée en le comparant à un agent bien rodé. La véritable valeur d'un MCP réside dans sa capacité à permettre un grand nombre de connexions et d'intégrations à long terme.

Harrison compare MCP à Zapier, qui relie des applications telles que la messagerie, Google Sheets et Slack, et permet aux utilisateurs de créer d'innombrables flux de travail sans avoir à développer un agent sophistiqué pour chacun d'entre eux. Avec MCP, les utilisateurs peuvent créer leur propre version de Zapier, ce qui permet une variété d'intégrations personnalisées. intégrations personnalisées.

Harrison a habilement déplacé le positionnement du MCP d'une "plateforme d'outils d'agents polyvalents à haute performance" à un "connecteur pour les scénarios à longue traîne". L'analogie de Zapier est pertinente, soulignant que l'application potentielle du MCP n'est pas de remplacer les solutions d'agent existantes, mais plutôt de tirer parti de sa valeur dans un éventail plus large d'exigences plus personnalisées et de longue durée. Ce changement de mentalité réduit en fait les exigences en matière de maturité de la technologie MCP et facilite la recherche d'applications à court terme. La théorie de la longue traîne a été vérifiée à maintes reprises dans le domaine de l'internet, et si le MCP peut capter la demande de la longue traîne, il est également susceptible de réussir.

Différences par rapport à l'outil LangChain

Nuno souligne que LangChain dispose déjà d'une bibliothèque de 500 outils, mais qu'ils ne sont pas utilisés très souvent dans les environnements de production. Ces outils sont tous mis en œuvre selon le même protocole, compatible avec n'importe quel modèle, et sont librement interchangeables. Il s'est interrogé sur l'avantage de MCP. Est-ce simplement que MCP prend une "forme unique" qui oblige l'utilisateur à faire tourner un grand nombre de serveurs sur un terminal local et n'est compatible qu'avec des applications de bureau ? Selon lui, ce n'est pas un avantage. Il pense que Zapier pourrait être la limite supérieure du potentiel de MCP.

La différence entre l'outil LangChain et l'outil MCP, selon Harrison, est que l'outil LangChain est principalement destiné aux développeurs d'agents, alors que le MCP est principalement destiné aux personnes suivantesincapableLes utilisateurs qui développent des agents. L'objectif de MCP est de permettre aux utilisateurs d'ajouter des outils aux agents sur lesquels ils n'ont aucun contrôle. En outre, MCP permet également aux non-développeurs d'ajouter des outils aux agents qu'ils utilisent, alors que les outils LangChain sont davantage destinés aux développeurs. Les non-développeurs sont bien plus nombreux que les développeurs, et c'est là le marché potentiel de MCP.

M. Harrison reconnaît également les lacunes du programme MCP dans sa forme actuelle. Mais il est convaincu que MCP continuera à s'améliorer. Il imagine un avenir où les applications MCP pourront être installées en un seul clic, ne nécessiteront pas l'exécution d'un serveur sur le terminal local et seront accessibles par le biais d'applications web. C'est vers cela que MCP se dirige.

Nuno s'est interrogé sur la nécessité de MCP du point de vue de l'écosystème d'outils de LangChain. Sa question est simple : si LangChain fournit déjà un grand nombre d'outils qui sont sous-utilisés, comment MCP peut-il résoudre ce problème ? M. Harrison a répondu en différenciant la base d'utilisateurs, en faisant valoir que MCP s'adresse à un ensemble d'utilisateurs différents de ceux qui utilisent les outils de LangChain. Cette différenciation permet de cibler plus précisément le marché de MCP et d'éviter la concurrence directe avec l'écosystème d'outils existant. Le groupe des "non-développeurs" est en effet très important, et si MCP peut servir efficacement ce groupe d'utilisateurs, le potentiel du marché est encore considérable.

L'avenir des MCP : analogies avec les GPT et les plugins personnalisés

Nuno résume l'argument de Harrison selon lequel MCP doit se rapprocher des Custom GPT d'OpenAI pour justifier l'engouement actuel. Cependant, les Custom GPT ne sont pas aussi populaires qu'ils pourraient l'être. Il pose la question rhétorique suivante : que manque-t-il aux Custom GPTs que MCP possède ?

Harrison considère que MCP ressemble davantage aux plugins qu'OpenAI avait l'habitude de mettre en place, mais qui ont finalement échoué. Il admet que son expérience des plugins est floue, mais il réfléchit :

• L'écosystème MCP est déjà beaucoup plus vaste que l'écosystème Plugins.
• La capacité du modèle a été considérablement améliorée pour permettre une meilleure utilisation de ces outils.

Nuno est sceptique quant à la taille de l'écosystème MCP. Il n'a trouvé que 893 serveurs MCP dans un répertoire trouvé au hasard. Il pense que Harrison peut juger de la taille de l'écosystème simplement par le nombre de tweets sur la ligne de temps de Twitter qui mentionnent MCP.

Nuno estime que pour que le MCP ne soit plus une note de bas de page dans l'histoire du développement de l'IA, les améliorations suivantes doivent être apportées :

• Complexité réduitePourquoi le protocole de l'outil doit-il gérer à la fois les invites et l'achèvement du mécanisme d'apprentissage tout au long de la vie ?
• Simplifier la difficulté de réalisationPourquoi les protocoles des outils de service doivent-ils communiquer dans les deux sens ? Nuno pense que la réception des journaux du serveur n'est pas une raison suffisante.
• Aide au déploiement de serveursLes protocoles sans état sont essentiels et les meilleures pratiques pour la mise à l'échelle en ligne ne doivent pas être oubliées simplement parce que vous construisez une application LLM. Une fois que les déploiements de serveurs sont pris en charge, d'autres questions telles que l'authentification entrent en jeu.
• Compenser les pertes de qualitéLes outils : Insérer des outils aléatoires dans des agents qui n'en connaissent rien entraînera inévitablement une perte de qualité, et il faudra trouver des moyens de compenser.

Harrison a reconnu que la question de Nuno avait un certain mérite et a posé la question à la communauté Twitter, en lançant un sondage demandant si les gens pensaient que le MCP était un feu de paille ou la norme de l'avenir.

En résumé, le protocole de contexte de modèle (MCP) est une technologie émergente qui tente d'ouvrir de nouvelles voies dans l'extensibilité des outils d'agent. Bien que le MCP soit encore confronté à de nombreux défis, sa valeur potentielle et son orientation future méritent d'être observées.

points de vue

Modèle Contexte Protocole (MCP) a peu de chances de devenir la norme du futur. Personnellement, je suis pessimiste quant à l'avenir du MCP.

Le problème que le MCP tente de résoudre est logique, mais il n'est peut-être pas très efficace dans la pratique. L'idée de Harrison Chase selon laquelle le MCP aidera les utilisateurs à étendre les outils de l'agent part d'une bonne intention, mais les utilisateurs n'en auront peut-être pas besoin. Les utilisateurs peuvent préférer utiliser un produit bien développé plutôt que d'ajouter eux-mêmes des outils.

Nuno Campos n'a pas tort. Il a souligné que les outils et les agents doivent bien fonctionner ensemble pour être efficaces. Le protocole MCP n'en tient peut-être pas suffisamment compte, et le simple fait de connecter des outils peut ne pas suffire à utiliser efficacement les agents. Les grands modèles actuels ont encore des limites en termes d'invocation d'outils, et il est trop optimiste de s'attendre à ce que MCP construise une plate-forme d'outils efficace.

MCP est également compliqué à mettre en œuvre. L'exécution locale d'un serveur, limitée aux applications de bureau, n'offre pas une bonne expérience à l'utilisateur. Les applications d'IA ont tendance à être basées sur l'informatique en nuage et à être légères, et si MCP n'est pas amélioré, il sera difficile pour les utilisateurs de l'accepter.

L'échec des plugins et des GPT personnalisés d'OpenAI a montré qu'il n'est pas facile d'étendre la plateforme. MCP essaie de la surpasser, mais je crains qu'il n'y parvienne pas et qu'il soit oublié aussi rapidement que les plugins.

Par conséquent, le MCP pourrait n'être qu'un phénomène éphémère dans le développement de l'IA, et il est peu probable qu'il se généralise à l'avenir. Bien qu'il ait une valeur expérimentale, l'objectif de Harrison Chase est difficile à atteindre. En revanche, il pourrait être plus pratique et plus efficace d'améliorer la capacité du grand modèle lui-même ou de créer des applications d'agents plus verticales.

Dans l'ensemble, il est peu probable que MCP soit un succès, et il s'agit probablement d'un simple battage publicitaire. Je suis très sceptique quant à l'avenir du MCP. L'exploration du MCP est utile, mais son succès final est peu probable.