Harnais d'agent vs Framework d'agent : quelles sont les réelles différences ?

Conçu pour la vitesse : latence d'environ 10 ms, même en cas de charge
Une méthode incroyablement rapide pour créer, suivre et déployer vos modèles !
- Gère plus de 350 RPS sur un seul processeur virtuel, aucun réglage n'est nécessaire
- Prêt pour la production avec un support complet pour les entreprises
Qu'est-ce qu'un framework d'agent ?
Un framework d'agent vous fournit les briques nécessaires pour assembler un agent. Il apporte une structure et des abstractions ; vous fournissez la logique qui les relie.
Un framework classique vous offre :
- Un moyen de définir des étapes. Des nœuds dans un graphe, des rôles dans une équipe, des fonctions dans une chaîne.
- Un moyen de les connecter. Des arêtes, des conditions, des transferts, des séquences.
- Un modèle d'état. Généralement un schéma typé que vous déclarez et qui est transmis à chaque étape.
- Des liaisons de modèles. Des adaptateurs pour que le même code fonctionne avec différents fournisseurs.
- L'exécution. Un moteur qui parcourt votre structure jusqu'à son terme.
LangGraph en est l'exemple le plus clair. Vous déclarez des nœuds, des arêtes et un schéma d'état partagé, et il s'exécute jusqu'à ce qu'un nœud renvoie END. CrewAI adopte une forme différente avec la même idée : déclarer des agents avec des rôles et des tâches, et les laisser s'exécuter de manière séquentielle ou hiérarchique. Microsoft Agent Framework, qui a fusionné AutoGen et Semantic Kernel lors de sa version 1.0 en avril 2026, fait de même pour .NET et Python.
Un framework est idéal lorsque :
- Votre flux de travail a une forme imposée et s'en écarter pose un problème de justesse
- Vous avez besoin de branchements conditionnels, de déploiements en parallèle ou de boucles vers des étapes précédentes
- Différentes étapes nécessitent des modèles, des prompts ou des ensembles d'outils différents
- Vous voulez que le chemin d'exécution soit lisible dans le code, et non déduit d'un prompt
- Une intervention humaine est requise pour valider une étape précise du flux
Qu'est-ce qu'un agent harness ?
Un agent harness est la couche d'exécution entourant un LLM qui le transforme en un agent fiable et durable. Il ne s'agit pas de primitives pour construire une boucle, mais de la boucle elle-même, déjà prête à l'emploi.
Un modèle seul peut raisonner, mais il ne peut pas agir. Donnez-lui une tâche, vous obtiendrez un plan et rien de plus. Il ne peut ni ouvrir un fichier, ni appeler une API, ni exécuter le code qu'il vient d'écrire, ni se souvenir de ses décisions passées. Le harness comble ce fossé et le maintient tout au long de l'exécution.
Un harness classique gère :
- La boucle d'exécution. Planifier, appeler un outil, lire le résultat, décider de la suite, et recommencer.
- La gestion du contexte. Compactage, chargement différé des outils, déchargement des réponses trop volumineuses, afin qu'une exécution longue ne dépasse ni la fenêtre de contexte ni le budget.
- Le sandboxing. Exécution isolée pour le code, les fichiers et les commandes shell.
- Les approbations. Mise en pause avant les appels d'outils destructeurs en attendant une validation humaine.
- L'état de session. Persistance lors des reconnexions, des redémarrages et des conversations multi-tours.
TrueForge, Claude Agent SDK, opencode, Pi et OpenHands sont tous des harnesses. Vous fournissez les outils et les instructions ; vous n'avez pas à construire la boucle.
Un harness est optimal lorsque :
- Le chemin se découvre plutôt qu'il ne se conçoit, et la prochaine étape dépend de ce que la précédente a révélé.
- Vous avez besoin d'un agent opérationnel cette semaine, pas d'une architecture de workflow.
- Les exécutions sont suffisamment longues pour que la gestion du contexte devienne le point de rupture.
- L'agent exécute du code ou accède à un système de fichiers et nécessite une isolation.
- Vous préférez optimiser des prompts et des outils plutôt que de maintenir une machine à états.
Différences fondamentales
Les deux permettent d'obtenir un agent fonctionnel. Ce qui les différencie, c'est ce dont vous êtes responsable.
Deux questions pour les distinguer
Les pages produits ne vous aideront pas à trancher, utilisez plutôt celles-ci.
Est-ce vous qui écrivez la boucle ?
Si vous déclarez des liens, des conditions ou une séquence d'étapes, il s'agit d'un framework. Si vous fournissez des outils et des instructions avant de lancer l'exécution, il s'agit d'un environnement d'exécution (harness).
Gère-t-il le contexte pour vous ?
Les frameworks vous fournissent généralement le schéma d'état et vous laissent décider de ce qui entre dans la fenêtre de contexte. Les environnements d'exécution doivent le gérer eux-mêmes, car ils contrôlent la boucle et une exécution prolongée finirait par saturer la fenêtre et bloquer le processus. Si la documentation ne mentionne ni compactage, ni déchargement, ni chargement différé des outils, vous avez probablement affaire à un framework.
Pourquoi ces termes sont souvent confondus
Trois raisons, dont la première est la plus importante.
Certains produits sont réellement les deux à la fois. deepagents est l'environnement d'exécution de LangChain construit sur LangGraph, qui est un framework. Il propose une boucle complète avec planification, système de fichiers virtuel, sous-agents et mémoire, se comportant ainsi comme un environnement d'exécution. En coulisses, il s'agit d'un graphe. Microsoft Agent Framework fait quelque chose de similaire, en fournissant à la fois les primitives d'orchestration et une couche d'exécution structurée par-dessus.
Le marketing suit le volume de recherche. « Framework » est le terme consacré depuis des années et génère plus de trafic. « Harness » n'a commencé à apparaître qu'en 2026. De nombreux « harnesses » se qualifient encore de « frameworks » car c'est le mot que les acheteurs tapent dans les moteurs de recherche.
La frontière se déplace à mesure que les produits arrivent à maturité. Les frameworks ajoutent des configurations par défaut et commencent à ressembler à des harnesses. Les harnesses exposent des hooks et commencent à ressembler à des frameworks. Le fait que Microsoft intègre une couche « Agent Harness » au sein d'un « Agent Framework » illustre parfaitement ce phénomène, et ce n'est qu'un début.
Cela ne rend pas la distinction inutile pour autant. Cela signifie simplement qu'il faut vérifier le comportement plutôt que l'étiquette.
Ils ne sont pas mutuellement exclusifs
L'erreur qui piège les équipes est de considérer cela comme un choix binaire. La plupart des systèmes en production utilisent les deux, à des niveaux différents.
Un harness gère la boucle de l'agent et tout ce qui doit se produire à chaque itération. Un framework gère l'orchestration entre les agents, ou le flux de travail déterministe au sein duquel un agent piloté par un harness est intégré. Diffuser une tâche vers cinq agents, attendre qu'ils aient tous terminé, exécuter une étape de validation, puis passer à la suite. C'est le rôle d'un framework, et chaque nœud peut être un harness.
L'erreur consiste à utiliser un framework pour reconstruire une boucle qui existe déjà. Créer un graphe pour un agent dont le chemin est réellement ouvert revient à écrire une version moins performante de ce qu'un harness vous offre gratuitement, tout en en payant le prix en maintenance indéfiniment. L'erreur inverse est tout aussi réelle : forcer un harness à suivre un flux de travail de conformité rigide en décrivant la séquence dans un prompt et en espérant que cela fonctionne.
TrueForge : Le meilleur Agent Harness pour les équipes en production

TrueForge est le harness sous licence MIT que nous avons publié en open source en août 2026, et c'est le même runtime qui propulse notre propre agent AskTFY. Nous l'avons conçu parce que nous voulions l'ergonomie d'un agent managé sans confier les décisions du modèle à un fournisseur, et aucune solution open source ne couvrait l'ensemble de nos besoins.
Il est composé de trois éléments distincts. Un serveur central exécute la boucle : streaming, portes de validation pour les actions sensibles, délégation aux sous-agents, compactage et sessions persistantes après reconnexion. Une API HTTP avec un SDK TypeScript (@truefoundry/trueforge-sdk) permet à votre code d'accéder à toutes les fonctionnalités de l'interface. Enfin, une interface de chat avec son propre SDK (@truefoundry/trueforge-ui) est disponible pour être utilisée telle quelle, personnalisée ou intégrée. Ce troisième élément est ce qui le distingue de la plupart des solutions de cette liste, qui se limitent au terminal.
Le choix de conception qui impacte le plus votre facture : TrueForge traite le bac à sable (sandbox) comme un outil. Il ne le lance que lorsque l'agent a réellement besoin d'exécuter du code, au lieu d'envelopper toute la session dans un conteneur. Un seul serveur gère plusieurs agents simultanément, et les itérations qui ne nécessitent pas de code restent peu coûteuses.
Ce qu'il ajoute par-dessus la boucle, c'est la gestion du contexte, car c'est ce qui détermine si les exécutions longues restent abordables. Le chargement différé des outils signifie que les schémas d'outils MCP se chargent à la demande plutôt que d'encombrer la fenêtre dès le départ. Le mode Code permet à l'agent d'enchaîner plusieurs appels d'outils au sein d'un même script sandbox, de sorte que seul le résumé généré entre dans le contexte. Les réponses d'outils trop volumineuses sont écrites dans un fichier sandbox et remplacées par un chemin d'accès et un aperçu. Le compactage se déclenche à 80 % de la longueur du contexte du modèle et remplace l'historique ancien par un résumé structuré. Les sous-agents s'exécutent avec leur propre contexte propre et ne renvoient que le résultat.
Sur l'Enterprise-Bench de DevRev, qui consiste en 14 tâches inter-systèmes sur trois serveurs MCP avec une nouvelle session à chaque fois et un juge LLM à l'aveugle, TrueForge sur Opus 4.8 a résolu les mêmes tâches que les agents gérés par Claude pour 8,5 $ par exécution contre 11,8 $, avec 3,8 millions de jetons contre 10 millions. Le passage à GLM-5.2 a ramené ce coût à 2,9 $ par exécution. Par rapport aux deepagents sur le même modèle, il a utilisé moins d'un quart des jetons.

Il est sous licence MIT, maintenu par nos soins et développé en open source. Ses points forts résident dans ces trois surfaces, le sandboxing à la demande, et un chemin documenté allant de npx jusqu'à Helm avec Postgres, Redis, des réplicas et OIDC, ainsi que des chiffres de référence publiés que vous pouvez vérifier. Sa faiblesse évidente est son ancienneté. C'est le projet le plus récent ici, donc l'écosystème d'extensions tierces est limité par rapport à ce que propose opencode.
Essayez-le en 60 secondes : npx @truefoundry/trueforge ou ajoutez une étoile sur GitHub.
FAQ
Q : Qu'est-ce qu'un agent harness ?
R : Un agent harness est la couche d'exécution entourant un LLM qui le transforme en un agent fiable et durable. Il gère la boucle d'exécution, la gestion du contexte, le sandboxing, les approbations et l'état de la session, car un modèle seul peut raisonner mais ne peut ni agir, ni exécuter, ni se souvenir d'une interaction à l'autre.
Q : Quelle est la différence entre un « agent harness » et un framework d'agent ?
R : Un framework vous fournit des primitives pour construire un agent et attend de vous que vous conceviez le flux de contrôle. Un « harness » est un environnement d'exécution prêt à l'emploi avec une boucle déjà intégrée ; il vous suffit donc de fournir les outils et les instructions. Les frameworks servent à construire des agents, les « harnesses » servent à les exécuter.
Q : LangGraph est-il un « agent harness » ou un framework ?
R : LangGraph est un framework. Vous déclarez des nœuds, des arêtes et un schéma d'état, et il exécute votre graphe. deepagents, qui est construit sur LangGraph, est un « harness » car il propose une boucle complète que vous n'avez pas à écrire. Un produit peut contenir ces deux couches.
Q : Ai-je besoin des deux ?
R : Souvent, mais à des niveaux différents. Utilisez un « harness » pour la boucle de l'agent et un framework pour l'orchestration entre les agents ou pour un flux de travail déterministe dans lequel l'agent est intégré. Ce qu'il ne faut pas faire, c'est utiliser un framework pour construire manuellement une boucle qu'un « harness » vous fournirait gratuitement.
Q : Puis-je exécuter un « agent harness » dans mon propre VPC ou sur site ?
R : Oui, avec une solution open source. TrueForge s'exécute à partir d'une seule commande npx en local, ou via Docker Compose et Helm pour des déploiements en équipe avec Postgres, Redis, des réplicas et une connexion OIDC. La version gérée de TrueFoundry peut également être auto-hébergée, sur site, en environnement isolé (air-gapped) ou hybride, afin qu'aucune donnée ne quitte votre domaine.
Q : Comment gouverner les modèles et les serveurs MCP à travers de nombreux agents ?
R : Via une couche de passerelle. L' AI Gateway de TrueFoundry place plus de 1 000 LLM derrière une API compatible OpenAI avec une latence ajoutée d'environ 3 à 4 ms et 350+ RPS sur un seul vCPU, incluant RBAC, budgets, garde-fous et rotation des identifiants, ainsi qu'une passerelle MCP pour le contrôle d'accès au niveau des outils et des traces OpenTelemetry vers Grafana, Datadog ou Prometheus.
Lectures associées
- Les meilleurs harnais d'agents en 2026 : comparatif des 5 meilleures options: le domaine, une fois que vous avez décidé d'utiliser un harnais
- Présentation de TrueForge : le harnais d'agents open source que nous utilisons en production: architecture et choix de conception
- TrueForge vs les agents gérés par Claude : jusqu'à 75 % moins cher: l'impact de la couche de harnais sur les coûts
- Pourquoi les harnais d'agents devraient être open source: les arguments contre la location de cette couche
- Comment AskTFY, l'outil de TrueFoundry, fonctionne sur TrueForge: un agent en production construit sur un harnais
Conclusion
En résumé : un framework sert à construire un agent, un harnais d'agent sert à le faire fonctionner. Si vous devez écrire la boucle vous-même, vous avez choisi un framework. Si la boucle est déjà intégrée, vous avez choisi un harnais. De nombreuses équipes ont besoin des deux, à des niveaux différents, et l'erreur coûteuse consiste à utiliser l'un pour reconstruire ce que l'autre propose déjà.
Si vous voulez la boucle sans avoir à l'écrire, TrueForge est disponible sur GitHub et npx @truefoundry/trueforge ne prend qu'une minute. Si vous voulez voir comment ce même harnais fonctionne avec une gouvernance, des budgets, un contrôle d'accès (RBAC) et des traces unifiées, découvrez le Harnais d'agents TrueFoundry.
TrueFoundry AI Gateway offre une latence d'environ 3 à 4 ms, gère plus de 350 RPS sur 1 processeur virtuel, évolue horizontalement facilement et est prête pour la production, tandis que LiteLM souffre d'une latence élevée, peine à dépasser un RPS modéré, ne dispose pas d'une mise à l'échelle intégrée et convient parfaitement aux charges de travail légères ou aux prototypes.













.webp)



.png)
.png)
.png)
.png)
.png)






.png)







