Agents.json - la spécification OpenAI pour les LLM

 (github.com/wild-card-ai)
5 points par GN⁺ 2025-03-06 | 1 commentaires | Partager sur WhatsApp
  • Une spécification ouverte, fondée sur le standard OpenAPI, qui définit un contrat clair entre les LLM et les API
    • Elle organise les appels d’API en outils orientés objectifs afin que les LLM puissent les utiliser facilement
  • La seule documentation OpenAPI existante rendait difficile, pour les LLM, la sélection et l’appel des API appropriées
    • agents.json permet de garder le processus d’appel d’API déterministe, tout en laissant le résultat visé par le LLM être atteint de manière non déterministe

Pourquoi est-ce nécessaire ?

  • Pour utiliser un LLM, il faut souvent implémenter soi-même la manière de l’intégrer à des API
  • Beaucoup de développeurs renoncent au comportement non déterministe des agents et cherchent à obtenir le résultat voulu via des workflows codés en dur
  • Avec agents.json, le LLM peut fonctionner de manière non déterministe dans le processus menant au résultat souhaité, tandis que les appels d’API eux-mêmes restent exécutés de façon déterministe
  • Les API existantes sont conçues avant tout pour les développeurs, ce qui les rend difficiles à utiliser directement par un LLM
  • Exemple avec l’API Gmail :
    • il faut rechercher des e-mails, récupérer la liste des e-mails d’un thread, puis répondre à un e-mail spécifique
    • lorsque le LLM s’appuie tel quel sur la documentation OpenAPI, il échoue souvent à choisir les bons appels d’API
    • avec agents.json, les appels d’API peuvent être prédéfinis afin d’être exécutés dans le bon ordre

Composants de agents.json

  • Le fichier agents.json
    • il sert à définir des outils orientés résultats en reliant entre eux des appels d’API
    • il est utilisé avec le fichier OpenAPI existant
  • Le SDK agents.json
    • il permet au LLM de charger des outils à partir de agents.json et d’exécuter une série d’appels d’API

Différences avec OpenAPI classique

  • Avec OpenAPI seul, le LLM échoue souvent à sélectionner correctement les appels d’API
  • Avec agents.json, il est possible de mettre en modèle le processus d’appel d’API afin de fournir un flux optimal d’appels d’API pour obtenir le résultat souhaité

Pourquoi l’avoir publié en open source

  • Au départ, il s’agissait d’un fichier de configuration utilisé en interne, mais à mesure que ses fonctionnalités se sont étendues, la décision a été prise de le publier en open source
  • Dharmesh, CTO de HubSpot, a proposé l’idée d’une spécification de traduction d’API pour les LLM, ce qui a inspiré cette publication
  • À ce jour, 10 intégrations d’API validées ont été réalisées, et de nouvelles API sont ajoutées chaque jour
  • Une plateforme gratuite de recherche d’outils et de collections personnalisées est proposée pour permettre aux développeurs d’étendre facilement le système (https://wild-card.ai)

À lire aussi

1 commentaires

 
GN⁺ 2025-03-06
Avis sur Hacker News

  • agents.json suscite de l’intérêt, avec l’espoir que ce protocole réussisse

    • Il semble possible que MCP et agents.json coexistent
    • MCP couvre davantage de cas, et il pourrait être difficile d’en faire un protocole simplifié

  • Pour qu’agents.json soit adopté tôt, la documentation doit être plus facile à comprendre

    • Les exemples devraient être visibles immédiatement, et le schéma devrait être à portée de main
    • Le pitch devrait être concis, et les champs du schéma devraient aussi être clairs
    • Il pourrait être utile d’avoir un outil qui prend un schéma OpenAPI en entrée et génère une ébauche de agents.json avec un LLM

  • La compatibilité entre OpenAPI et agents.json est bonne, mais peut-être excessive

    • OpenAPI est populaire, mais n’a pas totalement dominé le marché
    • Si cela ajoute de la complexité à agents.json, on peut se demander si cela vaut la peine d’être pris en charge
    • Même sans compatibilité à 100 %, un support partiel via des convertisseurs personnalisés pourrait être possible

  • Beaucoup de personnes utilisent des IDE agentiques, et il serait utile qu’agents.json partage des extraits expliquant l’usage, la façon de trouver la documentation et de rechercher dans le registre

  • Question sur les différences entre agents.json et la spécification OpenAPI Arazzo

    • Doute sur le fait que ce soit mieux adapté à l’usage par les LLM
    • Les exemples montrent des concepts similaires

  • Avis selon lequel il est difficile de voir de vrais fichiers agents.json

    • Même après 10 minutes de recherche dans le registre, aucun exemple n’a été trouvé

  • Question sur la licence du package Python

    • Interrogation sur le fait de savoir s’il s’agit de l’AGPL

  • Bonne idée, mais les questions de licence pourraient compliquer l’adoption

    • Souhait que l’équipe explique comment adopter un package AGPL dans un produit

  • Cela pourrait être plus simple, et ce serait une bonne chose

    • Il y a peut-être un bug dans le titre de la propriété d’information de la spécification

  • Comparaison entre agents.json et llms.txt

    • llms.txt émerge aussi comme un standard aidant les LLM à comprendre les API
    • agents.json semble mieux gérer la compréhension structurée de différents endpoints

  • Question sur la raison pour laquelle les agents ne pourraient pas utiliser des API documentées avec une spécification OpenAPI

    • Dans des tests personnels, cela fonctionnait bien, mais quelque chose a probablement été manqué

  • Souhait que les fichiers agents.json et LLM.txt deviennent des standards simples comme robot.txt

    • CrewAI, Letta/MemGPT, OpenHands/OpenDevin et d’autres sont liés au sujet, mais rien ne dépasse vraiment les frontières
    • MCP est l’approche la plus flexible, et on espère qu’il pourra bien s’accorder avec agents.json
    • L’équipe Netlify réfléchit à quelque chose d’intéressant autour de l’Agent Experience (AX), et les équipes d’Anthropic et de wildcard devraient y prêter attention

  • Question sur les similarités et différences avec MCP

    • Cela a l’air sympa