Yandex a comparé MCP et CLI+Skill pour les agents AI : 400 requêtes et une panne inattendue

L'équipe des Services Urbains de Yandex a mené un benchmark comparant deux façons de connecter un agent IA aux APIs internes — et a découvert que le choix architectural affecte directement l'efficacité de la dépense en tokens.

Le Problème : Les Tokens Ne Sont Pas Infinis

Une fenêtre de contexte limitée — tout le monde le sait. Mais peu comptent combien de tokens sont dépensés non pas sur la tâche elle-même, mais sur le « wrapper » : descriptions d'outils, listes de paramètres, résultats intermédiaires des appels. Dans les scénarios complexes, ces coûts généraux peuvent occuper une part significative du contexte disponible — et l'agent commence alors à faire des erreurs non pas parce que le modèle est mauvais, mais simplement parce qu'il ne reste plus d'espace utile.

Daniil Mikhailov de l'équipe des produits partenaires de Yandex a posé la question directement : comment faire plus tout en dépensant moins de tokens quand on travaille avec des APIs internes réelles ?

MCP vs CLI + Skill

L'équipe a comparé deux façons d'intégrer un agent avec des outils. MCP (Model Context Protocol) — un protocole structuré : l'agent reçoit une description de chaque outil dans un format explicite, les appels passent par une couche standardisée. L'avantage — universalité et schéma prévisible. L'inconvénient — chaque description d'outil occupe l'espace du contexte en totalité.

CLI + Skill — une approche alternative : l'agent accède à la ligne de commande, et la connaissance des outils est intégrée dans une « skill » compacte — une instruction de prompt pré-écrite. La description est plus compacte, mais nécessite une maintenance manuelle.

Pour tester l'hypothèse tirée de recherches externes, ils ont monté un benchmark :

• 14 scénarios réels de travail avec les outils internes de Yandex
• 2 modèles de langage
• Plus de 400 requêtes
• Mesures de précision et de dépense en tokens dans chaque scénario

Le Moment Où Tout S'est Cassé

La découverte la plus précieuse n'est pas venue à la fin, mais au milieu de l'expérience : ce qui fonctionnait de manière stable a soudainement cessé de fonctionner. Selon Mikhailov, cette défaillance s'est avérée plus intéressante que les chiffres finaux — il a fallu comprendre pourquoi.

« À un moment donné, tout ce qui fonctionnait s'est cassé — et c'est ce qui s'est avéré être la partie la plus intéressante.

J'ai dû comprendre pourquoi. »

De telles anomalies dans les benchmarks révèlent souvent des dépendances cachées : comment le modèle interprète le format du schéma, comment les outils se comportent sous des appels répétés, à quel point la sortie est stable avec différentes formulations de tâches. Sans un tel « moment de stress », les résultats auraient pu s'avérer naïvement optimistes.

Résultat : Un Arbre de Décision

Sur la base de la série d'expériences, l'équipe a compilé un arbre de décision pratique : quand MCP est plus rentable, et quand — CLI + Skill. Ce n'est pas une recommandation abstraite, mais une conclusion à partir de données réelles — plus de 400 requêtes dans une infrastructure réelle.

Ce Que Cela Signifie

Choisir une façon de connecter un agent à une API n'est pas un caprice technique. Cela affecte le nombre de tokens gaspillés, la durée de vie du contexte et la stabilité du comportement de l'agent dans des scénarios non standards. Pour les équipes qui construisent des agents de produit au-dessus de systèmes internes, cette recherche fournit un outil concret pour choisir l'architecture — non pas pour des raisons de marketing, mais en fonction de mesures réelles.