Le harnais est-il la même chose que le modèle ?

Non. Le modèle transforme du texte en davantage de texte et n'a aucun souvenir d'hier, aucun accès aux fichiers et aucune capacité d'exécuter quoi que ce soit. Le harnais est le programme autour de lui qui décide de ce que le modèle voit, exécute les outils demandés, réinjecte les résultats et arrête la boucle quand le travail est fait.

Un harnais d'agent n'est-il qu'un habillage autour d'un appel d'API ?

Un appel isolé n'est pas un harnais. La caractéristique déterminante est la boucle : le harnais appelle le modèle, exécute l'outil demandé, ajoute le résultat à la conversation et rappelle, jusqu'à ce qu'une condition d'arrêt soit remplie. Tout ce qui est difficile dans un harnais — gestion du contexte, permissions, persistance des sessions, reprise sur erreur — existe à cause de cette boucle.

En quoi un harnais diffère-t-il d'un framework d'agent ?

Un framework est une bibliothèque avec laquelle vous bâtissez une application ; un harnais est un programme exécutable que vous utilisez. Les frameworks vous donnent les pièces et vous laissent les décisions, tandis qu'un harnais a déjà pris ces décisions et les a livrées comme valeurs par défaut. La ligne s'estompe quand un harnais est exceptionnellement configurable, ce qu'est précisément DeepSeek Harness.

Un harnais d'agent remplace-t-il MCP ?

Non, ils répondent à des questions différentes. MCP est un protocole qui décrit comment un outil ou une source de données s'expose à un agent, tandis qu'un harnais est le programme qui fait tourner la boucle et décide si un outil est appelé, tout simplement. Un harnais peut agir comme client MCP, ce qui les rend complémentaires plutôt que concurrents.

Qu'est-ce qui rend DeepSeek Harness inhabituel parmi les harnais ?

Sa conception où tout est un plugin. Modèles, outils, skills, sessions, bacs à sable, systèmes de fichiers, la boucle, l'orchestration et l'interface sont tous des plugins chargés dans un runtime Cordis partagé et assemblés via un fichier cordis.yml : les parties que la plupart des outils traitent comme des internes figés sont ici des paquets remplaçables.

Qu'est-ce qu'un harnais d'agent ?

Un harnais d'agent est la couche runtime enroulée autour d'un modèle de langage qui transforme un générateur de texte en quelque chose capable de travailler. Il fait tourner la boucle, tend des outils au modèle, décide de ce qui entre dans le contexte, garde les sessions dans un endroit durable et impose ce que l'agent a le droit de toucher. Le modèle fournit le jugement ; le harnais fournit tout le reste.

Ce que fait réellement le harnais

Dépouillez un agent et il reste cinq responsabilités, dont aucune ne peut être assumée par le modèle seul.

La boucle. Un appel au modèle revient une fois puis s'arrête. Un agent, lui, continue : appeler le modèle, exécuter l'outil demandé, ajouter le résultat, rappeler — jusqu'à ce que la tâche soit finie ou qu'une limite soit atteinte. Ce cycle est le cœur du travail du harnais, et l'essentiel de ce qui distingue un harnais d'un autre — comment il réessaie, quand il abandonne, s'il peut paralléliser des étapes — est une décision sur la boucle.

Les outils. Lire un fichier, exécuter une commande, chercher sur le web. Le harnais annonce ce qui est disponible, valide les arguments produits par le modèle, exécute l'appel et remet le résultat dans une forme lisible par le modèle.

Le contexte. Tout modèle a une fenêtre finie, et une vraie tâche la fait déborder. Décider ce qui reste, ce qui est résumé et ce qui est récupéré à la demande relève du harnais, et c'est ce que les utilisateurs ressentent le plus directement quand un agent oublie ce qu'il faisait.

Les sessions. Un travail qui s'étale sur des heures ou survit à un redémarrage doit vivre quelque part : transcriptions, état intermédiaire, possibilité de reprendre. Sans persistance, vous avez une fenêtre de chat, pas un agent.

Les permissions. Un agent capable d'exécuter des commandes shell est une surface de sécurité. Demandes d'approbation, listes d'autorisation, bacs à sable et frontières du système de fichiers vivent tous dans le harnais, parce qu'on ne peut pas confier au modèle le soin de se surveiller lui-même — il n'a jamais été conçu pour cela.

Ce qu'un harnais n'est pas

Ce n'est pas le modèle. Changer de modèle change la qualité du raisonnement de l'agent ; cela ne change pas si les sessions reprennent ou si une commande exige une approbation. Ce sont des propriétés du harnais — c'est pourquoi un même modèle peut sembler compétent dans un outil et désespérant dans un autre.

Ce n'est pas non plus une extension d'IDE, même si les deux se confondent facilement puisqu'on rencontre souvent le harnais à travers un éditeur. Une extension d'éditeur est une surface : elle recueille votre demande et affiche la sortie. Le harnais est ce qui possède la boucle, l'exécution des outils et l'état. Un harnais bien construit peut piloter plusieurs surfaces — une CLI, une interface web, un éditeur — sur la même session, ce qui est un bon test pour savoir si vous avez affaire à un harnais ou à une façade.

Comment DeepSeek Harness l'implémente

DeepSeek Harness — dsh — a été publié par DeepSeek AI le 13 août 2026 sous licence MIT, et adopte sur tout ce qui précède une position exceptionnellement littérale : tout est un plugin. Modèles, outils, skills, sessions, bacs à sable, systèmes de fichiers, la boucle elle-même, l'orchestration et l'interface utilisateur sont tous des plugins chargés dans un runtime partagé.

Ce runtime, c'est Cordis, un méta-framework dont le métier est de charger et de câbler des plugins ; @deepseek-ai/cordis est une peer dependency de chaque paquet du harnais. La composition se fait dans une configuration de loader cordis.yml qui liste les plugins à démarrer et leurs options, et une option --profile choisit entre des lots adaptés à différentes situations — les profils fournis incluent headless.

La conséquence, c'est que dans dsh il n'existe pas de ligne significative entre l'application et ses extensions. Remplacer le bac à sable est structurellement le même geste qu'ajouter un outil. Voilà pourquoi un annuaire de plugins compte davantage ici que pour la plupart des outils d'agent : la capacité réside dans les paquets, pas dans le cœur. Nous indexons actuellement 7900 dépôts portant des topics dsh, dont 3942 présentent un vrai branchement de plugin — vous pouvez les parcourir ou les traverser par catégorie. Une réserve à répéter : dsh est une préversion développeur et son README avertit que des changements cassant la compatibilité arrivent ; le format de loader décrit ici est un instantané, pas un contrat.

Harnais et frameworks d'agent

Un framework d'agent est une bibliothèque avec laquelle vous bâtissez une application. Il vous tend des primitives de boucle, des abstractions d'outils et des aides à la mémoire, et vous laisse les décisions produit — c'est vous qui écrivez le programme, et ce que vous livrez vous appartient.

Un harnais a déjà pris ces décisions. Vous l'installez et il tourne : il y a une boucle par défaut, un jeu d'outils par défaut, un modèle de permissions par défaut, un moyen de reprendre la session d'hier. Le compromis est celui, habituel, entre une bibliothèque et un produit — moins de contrôle, bien moins à construire.

dsh occupe une position intéressante sur cette ligne. C'est un harnais que vous pouvez lancer tout de suite, mais comme chacune de ses parties est un plugin au-dessus d'un framework généraliste, un utilisateur suffisamment déterminé peut remplacer les parties que la plupart des harnais traitent comme figées. La distinction tient toujours — vous pouvez utiliser dsh sans écrire une ligne de code — mais la frontière est plus molle que d'habitude.

Harnais et MCP

MCP, le Model Context Protocol, est souvent cité dans la même phrase que les harnais, mais les deux résolvent des problèmes différents. MCP est un protocole : il normalise la façon dont un outil ou une source de données se décrit et répond aux appels, afin qu'un serveur écrit une fois soit utilisable par tout client qui le parle. Il répond à « comment l'agent atteint-il cette chose ».

Un harnais répond à « qui fait tourner la boucle, et quand cet outil est-il appelé, si tant est qu'il le soit ». Il gère le contexte, les permissions et les sessions, autant de sujets sur lesquels MCP n'a pas d'avis. Un harnais peut être un client MCP, auquel cas les serveurs MCP deviennent une source d'outils parmi d'autres. Pour la version concrète dans l'écosystème dsh, la catégorie MCP et outils de l'annuaire rassemble les plugins qui se tiennent à cette frontière.

Questions fréquentes

Le harnais est-il la même chose que le modèle ?: Non. Le modèle transforme du texte en davantage de texte et n'a aucun souvenir d'hier, aucun accès aux fichiers et aucune capacité d'exécuter quoi que ce soit. Le harnais est le programme autour de lui qui décide de ce que le modèle voit, exécute les outils demandés, réinjecte les résultats et arrête la boucle quand le travail est fait.
Un harnais d'agent n'est-il qu'un habillage autour d'un appel d'API ?: Un appel isolé n'est pas un harnais. La caractéristique déterminante est la boucle : le harnais appelle le modèle, exécute l'outil demandé, ajoute le résultat à la conversation et rappelle, jusqu'à ce qu'une condition d'arrêt soit remplie. Tout ce qui est difficile dans un harnais — gestion du contexte, permissions, persistance des sessions, reprise sur erreur — existe à cause de cette boucle.
En quoi un harnais diffère-t-il d'un framework d'agent ?: Un framework est une bibliothèque avec laquelle vous bâtissez une application ; un harnais est un programme exécutable que vous utilisez. Les frameworks vous donnent les pièces et vous laissent les décisions, tandis qu'un harnais a déjà pris ces décisions et les a livrées comme valeurs par défaut. La ligne s'estompe quand un harnais est exceptionnellement configurable, ce qu'est précisément DeepSeek Harness.
Un harnais d'agent remplace-t-il MCP ?: Non, ils répondent à des questions différentes. MCP est un protocole qui décrit comment un outil ou une source de données s'expose à un agent, tandis qu'un harnais est le programme qui fait tourner la boucle et décide si un outil est appelé, tout simplement. Un harnais peut agir comme client MCP, ce qui les rend complémentaires plutôt que concurrents.
Qu'est-ce qui rend DeepSeek Harness inhabituel parmi les harnais ?: Sa conception où tout est un plugin. Modèles, outils, skills, sessions, bacs à sable, systèmes de fichiers, la boucle, l'orchestration et l'interface sont tous des plugins chargés dans un runtime Cordis partagé et assemblés via un fichier cordis.yml : les parties que la plupart des outils traitent comme des internes figés sont ici des paquets remplaçables.

Pour continuer

Pour voir les idées ci-dessus sous forme de logiciel qui tourne, installez dsh — une commande npx vous donne une interface web sur http://127.0.0.1:3080. Pour voir comment un harnais où tout est un plugin se compare à un produit propriétaire établi, lisez notre comparaison précoce de dsh et Claude Code.