- OpenAI a présenté la Responses API, des outils intégrés, l’Agents SDK et des outils d’observabilité afin de faciliter le développement d’agents prêts pour la production
- La Responses API combine la simplicité de la Chat Completions API avec les capacités d’utilisation d’outils de l’Assistants API, afin de gérer en un seul flux la recherche web, la recherche de fichiers et l’utilisation d’un ordinateur
- Pour les nouvelles intégrations, il est recommandé d’utiliser la Responses API ; l’Assistants API entrera en phase de retrait après l’obtention de la parité fonctionnelle, avec un arrêt visé mi-2026
- Les outils intégrés prennent en charge les informations web récentes, la recherche dans de grands volumes de documents et l’automatisation de tâches informatiques via souris et clavier, mais la supervision humaine est particulièrement recommandée pour computer use, surtout dans les environnements hors navigateur
- Les développeurs peuvent combiner API, outils, SDK, fonctions de suivi et d’évaluation sur une même plateforme pour créer, déployer et optimiser des agents
De nouveaux composants pour développer des agents
- OpenAI considère les agents comme des systèmes qui accomplissent des tâches de manière autonome pour le compte des utilisateurs
- Au cours de l’année écoulée, l’introduction du raisonnement avancé, des interactions multimodales et de nouvelles techniques de sécurité a posé les bases nécessaires au traitement de tâches complexes en plusieurs étapes
- Les clients ont rencontré des difficultés pour transformer ces capacités en agents prêts pour la production
- Il faut de nombreuses itérations de prompts
- Il faut créer soi-même une logique d’orchestration personnalisée
- La visibilité et le support intégré sont insuffisants
- Les composants publiés cette fois-ci sont les suivants
- Responses API : combine la simplicité de la Chat Completions API avec les capacités d’utilisation d’outils de l’Assistants API
- Outils intégrés : web search, file search, computer use
- Agents SDK : orchestre les workflows à agent unique et multi-agents
- Outils d’observabilité : suivent et inspectent l’exécution des workflows d’agents
Responses API
- La Responses API est la nouvelle brique API de base pour créer des agents à l’aide des outils intégrés d’OpenAI
- Elle combine la simplicité de Chat Completions avec les capacités d’utilisation d’outils de l’Assistants API
- Un seul appel à la Responses API peut utiliser plusieurs outils et plusieurs tours de modèle pour traiter des tâches plus complexes
- Les premiers outils pris en charge sont les suivants
- Recherche web
- Recherche de fichiers
- Utilisation d’un ordinateur
- Des améliorations d’utilisabilité sont également incluses
- Conception unifiée basée sur des items
- Polymorphisme plus simple
- Événements de streaming intuitifs
- Helpers SDK comme
response.output_text
- Elle est conçue pour les développeurs qui veulent combiner les modèles OpenAI et les outils intégrés dans leurs applications sans intégrer séparément plusieurs API ou fournisseurs externes
- Si les données sont stockées chez OpenAI, les fonctionnalités de suivi et d’évaluation facilitent l’évaluation des performances des agents
- OpenAI n’utilise pas par défaut les données professionnelles pour l’entraînement des modèles, y compris lorsque les données sont stockées chez OpenAI
- Elle est disponible pour tous les développeurs dès aujourd’hui, sans frais distincts ; les tokens et les outils sont facturés aux tarifs standard de la page des prix
- La documentation de démarrage est disponible dans le guide de démarrage rapide de la Responses API
Relation avec les API existantes
- La Chat Completions API, l’API la plus largement adoptée d’OpenAI, continuera d’être prise en charge
- Les développeurs qui n’ont pas besoin d’outils intégrés peuvent continuer à l’utiliser
- Les nouveaux modèles pour les fonctionnalités qui ne reposent pas sur des outils intégrés ni sur plusieurs appels de modèle continueront également à être publiés sur Chat Completions
- La Responses API est un sur-ensemble de Chat Completions et offre les mêmes performances ; elle est donc recommandée pour les nouvelles intégrations
- Les retours de la bêta de l’Assistants API ont été intégrés à la Responses API, qui devient plus flexible, plus rapide et plus facile à utiliser
- La parité fonctionnelle complète entre l’Assistants API et la Responses API est en cours, notamment pour les objets de type Assistant, les objets de type Thread et l’outil Code Interpreter
- Une fois la parité fonctionnelle atteinte, le retrait de l’Assistants API sera officiellement annoncé
- La date cible d’arrêt est mi-2026
- Lors de l’annonce du retrait, un guide de migration sera fourni afin de permettre la conservation des données et la migration des applications
- Jusqu’à l’annonce officielle du retrait, de nouveaux modèles continueront aussi d’être proposés dans l’Assistants API
- OpenAI positionne la Responses API comme la direction future pour créer des agents avec OpenAI
Outils intégrés de la Responses API
-
Recherche web
- Les développeurs peuvent obtenir depuis le web des réponses rapides et à jour avec des citations de sources claires
- Dans la Responses API, la recherche web est proposée comme outil avec
gpt-4oetgpt-4o-mini, et peut être utilisée avec d’autres outils ou appels de fonctions - Les cas d’usage observés lors des premiers tests concernent des applications nécessitant des informations web récentes, comme des assistants d’achat, des agents de recherche ou des agents de réservation de voyages
- Hebbia utilise l’outil de recherche web pour aider les gestionnaires d’actifs, les sociétés de capital-investissement et de crédit, ainsi que les professionnels du droit, à extraire rapidement des insights exploitables depuis de grands ensembles de données publiques et privées
- La recherche web de l’API repose sur les mêmes modèles que ceux utilisés pour ChatGPT search
- Sur SimpleQA, GPT‑4o search preview a atteint 90 % d’exactitude, et GPT‑4o mini search preview 88 %
- Les réponses de recherche web de l’API incluent des liens vers les sources, comme des articles de presse et des billets de blog
- Les sites web et éditeurs peuvent choisir d’apparaître dans la recherche web de l’API
- L’outil de recherche web est disponible en aperçu pour tous les développeurs dans la Responses API
- Dans la Chat Completions API, il est possible d’accéder directement aux modèles de recherche via
gpt-4o-search-previewetgpt-4o-mini-search-preview - Les tarifs commencent à 30 dollars pour 1 000 requêtes avec GPT‑4o search et à 25 dollars pour 1 000 requêtes avec 4o-mini search
-
Recherche de fichiers
- L’outil file search amélioré permet de rechercher facilement des informations pertinentes dans de grands volumes de documents
- Il prend en charge plusieurs formats de fichiers, l’optimisation des requêtes, le filtrage par métadonnées et le reclassement personnalisé
- Dans la Responses API, il peut être intégré en quelques lignes de code
- Les cas d’usage sont les suivants
- Un agent de support client accède à une FAQ
- Un assistant juridique consulte rapidement des affaires passées pour des professionnels qualifiés
- Un agent de codage consulte de la documentation technique
- Navan utilise file search dans son agent de voyage basé sur l’IA pour fournir rapidement des réponses exactes à partir de documents de base de connaissances, comme les politiques de voyage d’entreprise
- L’optimisation intégrée des requêtes et le reclassement permettent de construire un pipeline RAG sans réglage ni configuration supplémentaire
- Des vector stores dédiés par groupe d’utilisateurs permettent de fournir des réponses adaptées aux paramètres de compte et aux rôles des utilisateurs
- file search est disponible pour tous les développeurs dans la Responses API
- Le tarif d’utilisation est de 2,50 dollars pour 1 000 requêtes ; le stockage de fichiers coûte 0,10 dollar par Go et par jour, le premier Go étant gratuit
- Il reste également disponible dans l’Assistants API
- Un nouvel endpoint de recherche a été ajouté aux objets Vector Store API afin d’interroger directement les données à utiliser dans d’autres applications et API
-
Utilisation d’un ordinateur
- L’outil computer use permet de créer dans la Responses API des agents capables d’effectuer des tâches sur ordinateur
- Cet outil est propulsé par le modèle Computer-Using Agent(CUA) qui a rendu possible Operator
- Le modèle en aperçu de recherche a obtenu les résultats suivants aux benchmarks
- OSWorld : 38,1 % sur l’ensemble des tâches d’utilisation d’un ordinateur
- WebArena : 58,1 %
- WebVoyager : 87 % sur les interactions web
- L’outil intégré computer use capture les actions de souris et de clavier générées par le modèle
- Les développeurs peuvent convertir ces actions en commandes exécutables dans leur propre environnement afin d’automatiser des tâches d’utilisation d’un ordinateur
- Les cas d’usage incluent l’automatisation de workflows basés sur un navigateur, comme l’assurance qualité d’applications web ou la saisie de données entre systèmes legacy
- Unify utilise l’outil computer use dans un système de croissance du chiffre d’affaires où les agents effectuent l’identification des intentions, la recherche sur les comptes et la prise de contact avec les acheteurs
- Les agents peuvent aussi exploiter des informations qui n’étaient pas accessibles via API
- Par exemple, une société de gestion immobilière peut vérifier via des cartes en ligne si une entreprise a agrandi son parc immobilier
- Luminai intègre l’outil computer use pour automatiser des workflows opérationnels complexes dans de grandes entreprises disposant de systèmes legacy sans API ni données standardisées
- Dans un pilote mené avec une grande organisation de services communautaires, le traitement des demandes et les procédures d’inscription des utilisateurs ont été automatisés en quelques jours
- La RPA traditionnelle aurait eu du mal à accomplir la même tâche même après plusieurs mois d’essais
- Avant de lancer CUA dans Operator, des tests de sécurité approfondis et du red teaming ont été menés sur trois domaines : les usages abusifs, les erreurs du modèle et les risques de frontière
- Des évaluations de sécurité et du red teaming supplémentaires ont également été réalisés pour traiter les risques liés à l’extension, via CUA dans l’API, des fonctionnalités d’Operator aux systèmes d’exploitation locaux
- Des mesures d’atténuation destinées aux développeurs ont aussi été ajoutées
- Contrôles de sécurité contre l’injection de prompt
- Prompts de confirmation pour les actions sensibles
- Outils aidant à isoler les environnements
- Détection améliorée des violations potentielles de politique
- Même si les mesures d’atténuation réduisent les risques, le modèle peut commettre des erreurs involontaires, en particulier dans les environnements hors navigateur
- La performance de 38,1 % sur OSWorld indique que la fiabilité n’est pas encore élevée pour l’automatisation des tâches de système d’exploitation ; dans ce cas, la supervision humaine est recommandée
- Les détails des travaux de sécurité spécifiques à l’API sont disponibles dans la system card mise à jour
Agents SDK et orchestration de workflows
- Les agents ont besoin non seulement d’une logique centrale et d’un accès aux outils, mais aussi d’une orchestration de workflows
- Le nouvel Agents SDK open source simplifie l’orchestration des workflows multi-agents
- Il améliore le SDK expérimental Swarm publié l’an dernier
- Ses principales fonctionnalités sont les suivantes
- Agents : des LLM faciles à configurer, dotés d’instructions claires et d’outils intégrés
- Handoffs : transfert intelligent du contrôle entre agents
- Guardrails : contrôles de sécurité configurables pour valider les entrées et les sorties
- Tracing & Observability : visualisation des traces d’exécution des agents afin de faciliter le débogage et l’optimisation des performances
- Les cas d’usage réels applicables incluent l’automatisation du support client, la recherche multi-étapes, la génération de contenu, la revue de code et la prospection commerciale
- Coinbase utilise l’Agents SDK pour prototyper et déployer rapidement AgentKit, qui permet aux agents IA d’interagir avec des portefeuilles de cryptomonnaies et des activités on-chain
- En quelques heures, des actions personnalisées du Developer Platform SDK ont été intégrées à un agent pleinement opérationnel
- L’architecture simplifiée d’AgentKit facilite l’ajout de nouvelles actions d’agent
- Box a créé en quelques jours un agent utilisant la recherche web et l’Agents SDK, permettant de rechercher, interroger et extraire des insights à partir de données non structurées internes à Box et de sources publiques sur Internet
- Les clients entreprise peuvent rechercher non seulement des informations récentes, mais aussi leurs données internes propriétaires en respectant les autorisations internes et les politiques de sécurité
- Par exemple, une entreprise de services financiers peut créer un agent personnalisé qui combine des analyses de marché internes stockées dans Box avec des actualités et données économiques en temps réel du web
- L’Agents SDK fonctionne avec la Responses API et la Chat Completions API
- Il peut aussi être utilisé avec des modèles d’autres fournisseurs lorsqu’ils proposent un endpoint API de style Chat Completions
- Il peut être intégré immédiatement aux codebases Python, et la prise en charge de Node.js arrivera prochainement
- Dans la conception de l’Agents SDK, OpenAI s’est inspiré des travaux de Pydantic, Griffe et MkDocs
- OpenAI prévoit de continuer à développer l’Agents SDK comme framework open source afin que la communauté puisse étendre cette approche
Orientation pour l’extension de la plateforme d’agents
- OpenAI estime que les agents deviendront bientôt un élément central de la main-d’œuvre et augmenteront fortement la productivité dans tous les secteurs
- À mesure que la demande des entreprises pour exploiter l’IA sur des tâches complexes augmente, OpenAI se concentre sur la fourniture de composants permettant aux développeurs et aux entreprises de créer des systèmes autonomes ayant un impact concret
- Cette publication constitue les premiers composants destinés à faciliter la création, le déploiement et le passage à l’échelle d’agents IA fiables et performants
- À mesure que les capacités des modèles évolueront vers des comportements plus agentiques, OpenAI continuera d’investir dans des intégrations plus profondes sur l’ensemble de ses API et dans de nouveaux outils aidant à déployer, évaluer et optimiser des agents en production
- L’objectif est d’offrir une expérience de plateforme fluide pour créer des agents capables d’aider à réaliser une grande variété de tâches dans n’importe quel secteur
1 commentaires
Avis de Hacker News
Je ne sais pas trop en quoi ces changements d’API vont aider les développeurs qui essaient d’intégrer OpenAI dans de vrais produits.
Les machines à états gérées par les fournisseurs pour gérer les conversations, les messages, la transmission des prompts, etc., ont fini, dans mon cas, par être insuffisantes, trop présomptueuses ou gênantes.
Au final, j’utilise la Chat Completions API avec uniquement les sorties structurées activées, et même là-dedans je fais largement de l’utilisation d’outils, des conversations récursives, du RAG, etc.
Je ne vois pas l’intérêt de confier la gestion de l’état de mon « agent » à un tiers ; garder ce genre de chose en local donne beaucoup plus d’autonomie.
L’essentiel, c’est simplement qu’on met une chaîne littérale dans une boîte noire et qu’on reçoit une nouvelle chaîne, si possible dans le format demandé, comme du JSON.
Si l’on se concentre à chaque fois sur l’assemblage de la bonne chaîne, le reste disparaît, et cela revient à produire une chaîne très structurée à partir de l’état métier d’une base de données.
C’est en pratique la même chose que faire du rendu serveur de pages web en PHP ; la vraie différence n’est que le mode de livraison.
Je n’ai pas encore trouvé de framework d’agents qui ajoute ce dont j’ai besoin par-dessus de simples appels de génération structurée.
La plupart des requêtes LLM devraient être « prompt en entrée, sortie structurée », ce qui correspond aussi à la philosophie Unix consistant à bien faire une seule chose.
Les frameworks d’agents arrivent trop tôt : ce ne sont que des couches qui abstraient un ensemble de patterns de conception encore peu courants.
Il faut créer une abstraction seulement lorsqu’il est clair que tout le monde réinvente la roue ; avec les agents, il n’y a pas de roue à inventer, tout se résume à de simples appels à un modèle de langage.
Je dis souvent que « le modèle de langage devrait être la partie la moins intéressante du code ».
La majeure partie du temps devrait être consacrée à construire le vrai logiciel et les outils ; le LLM devrait n’être qu’un petit composant du logiciel.
À mon goût, les frameworks d’agents donnent une place beaucoup trop importante au modèle de langage dans la codebase.
Même l’abstraction de function calling d’OpenAI hallucine des paramètres et des schémas, et JSON Schema lui-même est tellement verbeux que dès qu’on dépasse un tout petit peu cinq appels de fonctions très simples, tout s’effondre complètement.
Cela ressemble à une couche ajoutée par-dessus une abstraction en boîte noire déjà cassée, et ce n’est pas très utile pour de vraies applications.
Ça peut aider à créer rapidement de petites applis de preuve de concept.
Il faut être naïf pour bâtir une entreprise sur ce genre d’API.
Les LLM vont devenir une commodité, et OpenAI n’a pas d’autre choix que de lutter contre ce destin si elle veut justifier sa valorisation et l’ampleur des investissements dont elle a continuellement besoin.
Si vous avez construit sur l’Assistant API, prenez le signal : ne vous contentez pas de tout réécrire avec la Responses API, prenez possession de votre produit.
Les LLM d’aujourd’hui sont mieux traités comme une boîte noire encapsulée.
C’est à cause de ce passage : « Lorsque vous utilisez Chat Completions, le modèle récupère toujours des informations sur le web avant de répondre. Pour que des modèles comme gpt-4o et gpt-4o-mini n’appellent web_search_preview comme outil que lorsque c’est nécessaire, passez à la Responses API ».
Porter vers la nouvelle Responses API n’est pas simple, et nous avons déjà l’historique, le RAG et ce dont nous avons besoin pour les assistants.
J’ai développé plusieurs agents avec seulement le function calling et les sorties structurées, et ils tournent en production depuis plus d’un an.
Avant, on n’appelait même pas ça des agents.
Cette nouveauté semble viser les gens qui utilisent déjà des frameworks d’agents avec l’API OpenAI.
Il y a un bon thread Twitter dans lequel le concepteur de la nouvelle API explique le contexte de plusieurs décisions de conception : https://twitter.com/athyuttamre/status/1899541471532867821
Il existe aussi un lien alternatif pour ceux qui ne sont pas connectés à Twitter : https://nitter.net/athyuttamre/status/1899541471532867821
Ces tentatives d’agents IA me semblent passer à côté du sujet dès le départ.
Parce qu’elles essaient de remplacer des humains dans les systèmes existants, au lieu d’inventer une nouvelle manière de faire.
L’économie, la vie, tout tourne au fond autour des interactions entre personnes, donc c’est fondamentalement myope.
L’approche actuelle des agents IA ressemble à une variation de la blague : « une IA transforme une phrase en un long e-mail plausible, puis l’IA du destinataire résume ce long e-mail en une phrase ».
Je comprends l’utilité d’automatiser des tâches dans les systèmes existants, mais la vraie opportunité consiste à supprimer la plupart de ces systèmes.
Les humains ne sont pas si mauvais que ça.
Je me demande vraiment si créer avec l’IA des interfaces destinées aux humains, pour ensuite faire manipuler ces interfaces par l’IA, est la voie à suivre.
Combien de paniers tressés avec des branches cassées à la main utilises-tu ?
L’histoire montre que ce qui peut être automatisé finit par l’être, et que ce qui peut être produit moins cher ou plus vite finit aussi par l’être.
Par exemple, dans l’écosystème SaaS B2B, comme expérience utilisateur assistée permettant aux utilisateurs avancés d’une organisation de macro-automatiser la configuration client et les tâches de gestion de projet.
Lorsque l’abstraction, le contexte et l’ensemble d’utilisateurs sont bien délimités, l’utilisation d’outils peut être assez stable.
Ce qui manque de manière flagrante : Model Context Protocol
https://www.anthropic.com/news/model-context-protocol
Les agents auront toujours besoin d’une forme de protocole de communication, et l’univers des frameworks agentiques est une mer de logos, donc sans standard ouvert ça devient compliqué
Je suis actuellement chez Comet, j’ai aussi travaillé directement sur une implémentation de MCP et contribué à l’Agent SDK sous forme d’intégration native et d’améliorations de la suite de tests
https://github.com/comet-ml/opik-mcp
https://github.com/openai/openai-agents-python/pull/91
La récente intégration, nous l’avons sortie dès le premier jour
https://www.comet.com/docs/opik/tracing/integrations/openai_...
Je pense que le point central de la direction que prend OpenAI est d’apporter de la simplicité aux développeurs via des composants faciles à utiliser
Je ne parlerai pas de stratégie ni de prix, mais du point de vue d’un développeur, au premier abord, l’approche simple et modulaire du SDK, sans fioritures, est rafraîchissante
Ce n’est pas généraliste, c’est destiné à utiliser les appels d’outils mcp.run avec les modèles d’OpenAI
Cela dit, ne pas prendre en charge MCP directement est à peu près l’un des gestes les plus hostiles aux développeurs, et venant d’OpenAI, ce n’est pas surprenant
Ce serait vraiment bien que ce soit ajouté
À la question « L’Agents SDK prend-il en charge les connexions MCP ? Peut-on facilement fournir des outils à un agent donné via une connexion client-serveur MCP ? », la réponse est : « Comme vous pouvez définir les outils que vous voulez, vous pouvez implémenter des outils MCP avec le function calling »
En résumé, il faut faire soi-même un peu de plomberie
Issue liée : https://github.com/openai/openai-agents-python/issues/23
Ici swyx
J’ai pu voir en avance l’ensemble de la nouvelle API avec l’équipe API/DX et leur poser les questions fréquentes
https://latent.space/p/openai-agents-platform
Le point intéressant, c’est que les réponses sont désormais stockées gratuitement par défaut : peut-on donc détourner la Responses API pour l’utiliser comme une base de données ?
Il y a aussi des questions qui devraient plaire aux gens de HN
Les hyperparamètres de la recherche web, c’est-à-dire comment régler la profondeur et la largeur de la recherche quand on construit un Deep Research maison
Maintenant qu’OAI fournit nativement le RAG et le reranking dans la Responses API, quand faut-il encore construire son propre RAG ?
Personnellement, je pense que quelqu’un devrait benchmarker les performances RAG de la Files API. L’impression de la communauté ne semble pas avoir beaucoup évolué depuis le premier lancement de l’Assistants API
Les différences entre l’Agents SDK et OAI Swarm sont en gros les types, le tracing et le LLM remplaçable
Je me demande aussi si les fine-tunings
search-previewetcomputer-use-previewseront fusionnés dans GPT50 - https://ai.pydantic.dev/
L’une des principales raisons de construire soi-même ce genre d’outil de recherche IA est de pouvoir contrôler complètement la profondeur et la largeur, et aussi personnaliser les loaders selon les données ou sites que l’on veut
La recherche web actuelle n’est pas transparente sur les sites pour lesquels elle dispose du texte intégral et ceux pour lesquels elle n’utilise que des extraits
Avoir à la fois l’utilisation de l’ordinateur et la recherche web est clairement puissant. C’est, en substance, quelque chose comme le Deep Research d’OpenAI
Les prix n’ont pas été dévoilés lors de la présentation
Probablement parce qu’ils savaient que ce serait très cher
Recherche Web [0] : GPT‑4o search et 4o-mini search coûtent respectivement 30 $ et 25 $ pour 1 000 requêtes
Recherche de fichiers [1] : 2,50 $ pour 1 000 requêtes, stockage des fichiers à 0,10 $/Go/jour, le premier Go étant gratuit
Outil d’utilisation de l’ordinateur (modèle computer-use-preview) [2] : 3 $ par million de tokens en entrée, 12 $ par million de tokens en sortie
[0] https://platform.openai.com/docs/pricing#web-search
[1] https://platform.openai.com/docs/pricing#built-in-tools
[2] https://platform.openai.com/docs/pricing#latest-models
Je ne vois pas bien en quoi cette API est meilleure que https://www.anthropic.com/news/model-context-protocol
La motivation semble avoir été « comment gagner plus d’argent » plutôt que « comment être plus utile aux utilisateurs »
J’aime bien, mouvement audacieux
Quand les gens lents de Google finiront enfin par rattraper leur retard, il sera peut-être trop tard pour Google
J’ai aussi écrit un script qui recherche sur le Web et fonctionne plutôt bien. Il utilise vercel ai sdk [1]
[0] - https://brave.com/search/api/
[1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...
J’ai créé moi-même une version bien plus simple et plus puissante que la Responses API, et elle fonctionne avec tous les fournisseurs de LLM
https://github.com/Anilturaga/aiide
C’est agréable à voir, et ça a vraiment l’air bien
Il y a une phrase disant : « Nous prévoyons d’annoncer officiellement l’abandon de l’Assistant API, avec une date de fin visée à la mi-2026 »
La nouvelle Responses API est un pas dans la bonne direction, avec même une fonction intégrée de « handoff »
Cela dit, elle semble encore un peu limitée pour les cas d’usage agentiques, et il manque des garde-fous et une logique de machine à états officiels
Ils ont dit que l’objectif était de « fournir une expérience de plateforme fluide permettant aux développeurs de créer des agents » ; il sera intéressant de voir comment ils évolueront vers cette plateforme
Je pense qu’on verra un contrôle de flux basé sur des graphes dans les prochains mois
Il existe déjà d’innombrables solutions open source, mais la plupart sont insuffisantes ou ajoutent de l’opacité et de la complexité inutiles
On pouvait déjà créer des flux agentiques avec une combinaison d’appels d’outils et de réponses JSON, mais il manque encore les composants de plus haut niveau que personne n’a vraiment résolus
Les progrès de Computer Use mentionnés ici sont impressionnants, au point que je me demande si c’est déjà assez mature pour être utilisé dans des tests d’utilisabilité
En général, si une UI est difficile à parcourir pour une IA, est-ce qu’on peut considérer qu’elle a aussi de bonnes chances d’être relativement difficile pour un humain, et que c’est donc le signe qu’il faut la simplifier ou l’améliorer d’une manière ou d’une autre ?
La manière dont un LLM interagit avec une UI est très différente de la façon dont un humain utilise une UI
Le SDK Agents lié renvoie une 404
Pour référence, MindRoot propose quelque chose de similaire à Responses et à une partie de File Search via une task API : https://github.com/runvnc/mindroot/blob/main/api.md
Cela peut être combiné avec l’outil query_kb du plugin mr_kb, et comme cela permet des recherches dans plusieurs bases de connaissances, cela pourrait en fait être meilleur que File Search
Si quelqu’un veut aider mon programme, créer un plugin ou envoyer une PR, qu’il n’hésite pas à me contacter via GitHub, e-mail ou Discord/Telegram (runvnc)
C’est peut-être parce que je suis connecté