Les harness d'agents sont souvent présentés comme un moyen d'aider les agents à prendre en charge des travaux plus longs et plus complexes. Le harness d'agent de Glean y parvient de plusieurs façons, principalement grâce à une gestion du contexte qui permet aux agents de raisonner efficacement à travers les outils, les données et les workflows. Le harness prend également en charge l'apprentissage par traces, aidant les systèmes d'agents à s'améliorer eux-mêmes à partir de sessions passées. Le routage permet à des modèles spécialisés de prendre en charge les tâches qu'ils sont les mieux à même de traiter, afin que les agents obtiennent des résultats de haute qualité à moindre coût.
Mais la conception d'un harness ne consiste pas seulement à rendre les agents plus capables. Elle est aussi essentielle à l'efficacité en tokens. Dans cet article, nous expliquons comment nous avons fait évoluer notre harness pour orchestrer les outils pour chaque requête à l'aide de code, et pourquoi cette approche s'est révélée plus efficace, même pour des requêtes simples. Par rapport à notre approche précédente, elle a réduit l'utilisation de tokens de 24 %. Nous examinerons également les principales décisions de conception prises en cours de route qui ont rendu ces résultats possibles.
Les harness d'agents sont à leur meilleur avec un appel d'outils 100 % programmatique
La caractéristique définissante du harness d'agent de Glean est l'appel d'outils 100 % programmatique. Au lieu d'émettre directement des appels d'outils standard, le modèle écrit du code dans le sandbox de l'agent, en appelant les capacités de Glean via le runtime Python et le SDK d'outils. Le code est un meilleur primitif d'exécution que les appels d'outils standard, car l'orchestration, le filtrage, les boucles et les branches peuvent tous se dérouler au sein d'une seule exécution de script, au lieu d'être dispersés sur plusieurs allers-retours LLM.
Dans une boucle standard d'appel d'outils, chaque entrée et sortie d'outil est sérialisée puis désérialisée dans la fenêtre de contexte. Le modèle appelle un outil, le résultat arrive dans le contexte, le modèle le lit et appelle l'outil suivant. Pour un workflow touchant des dizaines de documents dans plusieurs systèmes, ce schéma ajoute du gaspillage de tokens, de la latence et une surcharge de raisonnement qui n'ont rien à voir avec la logique réelle de la tâche.
Notre première tentative d'appel d'outils programmatique était une approche hybride. L'appel d'outils standard gérait les opérations simples, en une seule étape, tandis que l'appel d'outils programmatique gérait les travaux multi-outils. Mais le fait d'obliger le modèle à décider à chaque tour quel mode utiliser introduisait sa propre surcharge, ce qui réduisait les gains d'efficacité que nous cherchions à obtenir. Il s'avère que les modèles sont tout aussi capables d'écrire un court script pour un seul appel d'outil que d'effectuer un appel d'outil standard. ;
Nous avons donc supprimé complètement l'appel d'outils standard. Le shell est désormais le seul outil exposé directement au modèle, ce qui lui permet d'écrire et d'exécuter des scripts dans le sandbox pour tout ce qu'il doit appeler. Toutes les autres capacités, y compris la recherche, les outils d'écriture et les skills, sont exposées via le SDK d'outils de Glean. ;
La troncature des outils relie le contexte au système de fichiers du sandbox
Un harness de code comme celui-ci a besoin d'un système de fichiers sandbox pour stocker les sorties d'outils, les étapes intermédiaires, les données et le raisonnement. Ces sorties restent sur disque entre les tours au lieu d'inonder le contexte du modèle, qui est réservé au raisonnement à fort signal, aux décisions et aux résultats d'outils tronqués. Conserver dans la fenêtre de contexte uniquement les parties les plus informatives d'un workflow aide le harness à éviter la dégradation du contexte et à rester fiable dans des travaux longs nécessitant un raisonnement complexe sur de grandes quantités de données.
Chaque harness doit décider quelle part de la sortie d'un outil le modèle voit réellement. Si tout reste dans le contexte, les performances se dégradent à mesure que le contexte s'accumule et que le modèle perd en attention. Si tout est résumé, le modèle peut perdre des informations clés dont il a besoin. La sur-synthèse a aussi un coût caché : puisque le modèle ne connaît pas à l'avance la structure de la sortie d'un outil donné, il peut consommer des tokens simplement pour comprendre comment lire les données depuis le système de fichiers.
Dans le harness de code de Glean, chaque appel d'outil renvoie un aperçu tronqué, écrit la sortie complète dans un fichier et indique au modèle exactement quelle quantité de contenu se trouve sur le disque. Le modèle lit directement le fichier lorsqu'il a besoin de plus de détails, et évite ce coût lorsqu'il n'en a pas besoin. Cela fonctionne parce qu'une fois que le modèle voit la structure d'un résultat et quelques lignes ou entrées représentatives, il peut inférer le reste sans avoir besoin de la charge utile complète dans le contexte. Le modèle a seulement besoin de savoir où se trouve la sortie utile et comment y accéder.
La recherche et la divulgation progressive maintiennent un contexte léger
Le harness de code peut exécuter des workflows complexes avec des outils à grande échelle, mais précharger des centaines de skills et d'outils d'entreprise dans la fenêtre de contexte dilue l'attention, diminue la fiabilité et augmente le coût. Nous avons donc construit le harness sur une combinaison de recherche et de divulgation progressive.
Le harness démarre avec un ensemble minimal d'outils de base dans les instructions système. Cela n'inclut que deux outils de recherche : l'un pour le contexte d'entreprise et l'autre pour les outils et les skills. Ces outils de base permettent à l'agent de trouver toutes les autres ressources dont il a besoin. Lorsque l'agent trouve un outil ou un skill via la recherche, il ne voit pas immédiatement le contenu complet. Il ne voit qu'un nom et une description légers, puis lit le schéma complet ou l'ensemble complet de références uniquement lorsque la tâche l'exige réellement grâce à la divulgation progressive.
La recherche et la divulgation progressive sont toutes deux nécessaires parce qu'elles résolvent des problèmes différents. La divulgation progressive permet à un agent d'utiliser efficacement une ressource complexe en ne lisant que les parties d'un skill ou d'un schéma pertinentes pour la tâche en cours, au lieu d'être distrait par le reste. Mais la divulgation progressive n'aide qu'une fois que l'agent sait quelle ressource utiliser. La recherche oriente l'agent vers le bon outil ou le bon skill, de sorte que lorsqu'il approfondit, il peut être sûr d'examiner le bon élément.
La réarchitecture du harness autour d'un ensemble central d'outils de recherche a introduit ses propres défis. Chaque recherche fait apparaître de nouveaux outils et skills que le modèle doit prendre en compte, ce qui signifie que l'ensemble d'instructions sur lequel le modèle raisonne peut s'étoffer à chaque tour. Si ce contexte était inséré dans les tours précédents, il invaliderait le cache de préfixe, c'est-à-dire la portion initiale d'une conversation dont les LLMs peuvent réutiliser les états d'attention au lieu de les recalculer. Pour éviter cela, Glean ajoute les résultats de recherche à la fin de la conversation. Cela permet au modèle d'agir sur les outils et skills nouvellement découverts sans invalider le cache de préfixe, rendant les réponses plus rapides et plus rentables.
Pourquoi les harness de code conviennent aux travaux d'entreprise de longue durée
Le passage à un harness de code reflète une évolution plus large dans l'IA d'entreprise. Le travail signifie de plus en plus orchestration et automatisation à travers des dizaines de systèmes SaaS, et pas seulement une conversation textuelle. Les workflows intersystèmes exigent une logique précise et une gestion d'état, et le code répond plus directement à ces exigences que les appels d'outils basés sur le langage naturel.
Les harness de code deviennent aussi l'option agnostique au modèle la plus efficace pour l'exécution agentique. Les modèles de pointe de tous les laboratoires leaders excellent déjà dans le codage agentique, et les modèles open source rattrapent rapidement leur retard. Comme une large gamme de modèles peut piloter le harness de Glean, les améliorations de la capacité de codage des LLMs se traduisent directement par une meilleure exécution des agents, sans nécessiter de refonte. Les créateurs d'agents peuvent remplacer librement les modèles au fil de l'évolution de leurs besoins et exigences.
Un harness de code ne permet pas seulement aux agents d'appeler plus d'outils. Il leur permet d'utiliser les outils, le contexte et les skills avec une efficacité et une fiabilité bien supérieures, même à l'échelle des 1000+ outils nécessaires pour automatiser toute une entreprise. Associé à un ensemble central d'outils de recherche de haute précision, le harness de code de Glean devient la base d'agents de travail puissants qui exécutent des workflows d'entreprise avancés avec 24 % de tokens en moins.
