En effet, Manus est très intelligent, ils ont divisé les outils en 3 niveaux : Niveau 1 : Appel de fonction (Function Calling) C'est le niveau le plus basique, qui ne conserve qu'un petit groupe de fonctions fixes et atomiques, comme : lire et écrire des fichiers, exécuter des commandes Shell, rechercher des fichiers, etc. Dans les invites système de LLM, il n'y a que la définition des outils de ce niveau, relativement peu, moins de 15, le format d'entrée et le format de sortie sont très clairs, il est donc difficile de se tromper, mais il y a deux outils très spéciaux ici, l'un est Shell, l'autre est File. Niveau 2 : Outils de bac à sable (Sandbox Utilities) Chaque session Manus s'exécute dans un bac à sable de machine virtuelle complet. C'est ce qui a été mentionné dans le tweet original, la machine virtuelle est préinstallée avec de nombreux outils en ligne de commande, comme des convertisseurs de format, des outils de reconnaissance vocale, voire un client en ligne de commande mcp. Ensuite, ces outils sont appelés via Shell défini au niveau 1, c'est-à-dire des outils en ligne de commande, appelés en ligne de commande. Mais comment le modèle d'outils sait-il tout cela ? Manus dira directement à LLM dans les invites système qu'il y a de nombreux outils en ligne de commande préinstallés dans un dossier spécifique. Pour les outils les plus couramment utilisés, leurs noms sont directement listés. Pour ceux qui sont moins utilisés, LLM peut directement lister tous les outils en ligne de commande via la commande mentionnée dans le tweet original, en utilisant le paramètre --help pour voir l'utilisation de n'importe quel outil, car tous ces outils sont développés par eux, avec un format uniforme. Niveau 3 : Paquets et API (Packages and APIs) Ce niveau consiste en fait à ce que LLM écrive du code Python en temps réel, permettant d'implémenter des fonctionnalités plus complexes. Par exemple, si un utilisateur souhaite interroger des données d'une API, il peut directement écrire une fonction en Python pour récupérer les données de l'API et les analyser dans le format requis. En fait, dans Codex, l'utilisation de code Python comme outil est déjà très répandue. Étant donné que les calculs complexes sont réalisés par le code, le résultat de la connaissance retourné au Principal Agent est le résultat du calcul, donc cela n'occupe pas le contexte du Principal Agent. Ainsi, le bénéfice de cette conception en 3 niveaux est que, du point de vue du modèle, les outils qu'il doit appeler sont fixés à une dizaine au niveau 1, tandis qu'avec l'aide de la ligne de commande et du code, il peut dériver d'innombrables combinaisons d'outils. Un autre point est que, comme je l'ai mentionné dans un tweet précédent, Manus adopte également massivement le modèle "agent comme outil (agent as tool)". Traiter les sous-agents comme des outils, par exemple, un sous-agent responsable de la recherche, mais ce sous-agent est perçu comme un outil par le Principal Agent. Cela peut également réduire efficacement le contexte.