Je vois cette sortie comme offrant deux choses : un agent de codage prêt à l'emploi et un framework méta-Harness sous-jacent, un peu comme Pi se rapporte à OpenClaw.
Cela peut aussi expliquer une partie de la controverse autour du projet. Les gens ne parlent pas toujours de la même chose. Beaucoup de critiques évaluent le premier, alors que je m'intéresse davantage à la conception du second.
DeepSeek Harness rend l'agent de codage lui-même enfichable. Les entreprises et les développeurs peuvent remplacer des composants individuels et assembler un Harness adapté à leurs besoins. Il fournit également un mode de création pour l'auto-extension à l'exécution et l'amélioration itérative.
À un niveau élevé, le modèle ressemble à ceci :
- Le Kernel fournit les mécanismes d'exécution et d'extension.
- Les Plugins fournissent des capacités atomiques remplaçables et composables.
- Les entreprises sélectionnent des Plugins dans la communauté ou construisent les leurs, puis empaquettent le Kernel et les Plugins dans un Harness interne adapté à leurs besoins.
Pour comprendre pourquoi cela compte, il faut d'abord clarifier ce que nous entendons par Harness.
Qu'est-ce qu'un Harness ?
Il y a quelques jours, quelqu'un d'InfoQ m'a posé une question :
De la gestion du contexte et de la planification des tâches aux appels d'outils MCP et à l'orchestration multi-agents, les capacités des Harness deviennent de plus en plus similaires. Où reste-t-il une marge pour une innovation significative ?
Il n'existe toujours pas de définition universellement acceptée d'un Harness.
Mon point de vue est qu'un modèle fournit les capacités fondamentales de raisonnement et de cognition d'un Agent. Le Harness détermine comment ces capacités sont organisées, invoquées et appliquées à des tâches réelles. Ensemble, le modèle et le Harness définissent les capacités pratiques et les performances de l'Agent.
Je divise les Harness en deux couches.
Un Harness au sens étroit est le framework d'exécution qui aide un agent de codage à accomplir une tâche. Il comprend la gestion du contexte, la mémoire, les appels d'outils, la planification, les tests, la validation et l'orchestration multi-agents. Il détermine si l'Agent peut accomplir une tâche de manière fiable.
Un Harness au sens large est le système en boucle fermée qui permet à un Agent de recevoir validation, rétroaction et correction au sein d'un environnement métier réel. Il connecte l'Agent aux systèmes et processus d'une organisation, l'aidant à continuer de faire ce qui est juste au fil du temps.
La première moitié du problème du Harness concerne la manière dont un Agent accomplit une tâche. Les capacités dans ce domaine convergent effectivement.
Mais des listes de fonctionnalités similaires ne produisent pas des résultats identiques. Les différences de vitesse, de précision, de stabilité, de coût et de récupération après échec sont souvent cachées sous la surface.
La seconde moitié concerne la manière dont un Agent entre dans de vrais systèmes d'ingénierie et métier, reçoit de la rétroaction et continue de progresser vers un objectif.
C'est là que la différenciation viendra de plus en plus : validation spécifique au scénario, attribution de la rétroaction et exécution en boucle fermée.
Les plateformes de développement, les journaux de production, les systèmes de traçage, les plateformes d'automatisation internes, les connaissances propriétaires et les règles organisationnelles doivent tous être connectés. Un Agent doit voir de la rétroaction réelle, déterminer si le résultat est correct, localiser la source de l'échec et continuer à apporter des corrections.
Cette couche dépend fortement de l'environnement spécifique. Un agent de codage généraliste ne peut pas la résoudre directement.
Le même agent de codage peut sembler presque magique dans une équipe et complètement inutile dans une autre. La différence réside souvent dans le Harness que l'équipe a construit autour de lui.
C'est pourquoi tant de projets empaquettent des Plugins. À la base, ces Plugins rassemblent des Skills, des intégrations MCP, de la documentation et des connecteurs auparavant dispersés en unités installables, composables et distribuables.
Vu sous cet angle, la direction de DeepSeek Harness devient beaucoup plus claire.
Regardons à nouveau DeepSeek Harness
Le message central de DeepSeek Harness est « Tout est un Plugin ».
Plus important encore, il rend l'agent de codage lui-même enfichable. Les modèles, les outils, les Skills, les sessions, les sandboxes, le stockage, les boucles, l'ordonnancement et l'interface utilisateur sont tous assemblés à partir de Plugins qui peuvent être remplacés et recombinés.
Cela signifie qu'une entreprise peut utiliser des Plugins communautaires, développer ses propres Plugins spécifiques à un scénario, ou remplacer les composants Harness par défaut inclus avec DeepSeek Harness.
En principe, cela augmente la flexibilité du développement secondaire tout en réduisant le besoin de Forker l'ensemble du projet, ce qui facilite la poursuite du suivi du développement amont.
La conception me rappelle ce que nous avons fait avec Egg il y a des années.
Egg fournissait un Kernel d'exécution, un système de Plugins et un mécanisme d'extension pour construire des frameworks de niveau supérieur.
Le même modèle peut être utilisé pour comprendre DeepSeek Harness :
- Le Kernel fournit les mécanismes d'exécution et d'extension.
- Les Plugins fournissent des capacités atomiques remplaçables et composables.
- Les entreprises combinent le Kernel avec des Plugins communautaires ou développés en interne pour construire leur propre Harness.
L'idée est de maintenir un Kernel stable et de laisser l'écosystème explorer le reste.
Si cette direction réussit, nous pourrions finir avec plus d'un oh-my-dsh. Nous pourrions voir d'innombrables variantes construites pour différents scénarios.
Comment cela pourrait affecter les agents de codage existants
Certaines personnes dans la communauté ont plaisanté en disant que des équipes comme MiniMax, Kimi et ZCode doivent sourire.
Je n'en suis pas si sûr.
DeepSeek Harness pourrait ne pas créer de pression produit immédiate sur les agents de codage existants. Son impact au niveau de l'écosystème, en revanche, pourrait devenir bien plus significatif.
La vision AGI de Liang Wenfeng et les modèles open source de DeepSeek fournissent déjà deux puissants points de ralliement. DeepSeek Harness ajoute désormais une proposition architecturale intéressante.
Si l'architecture tient le coup face à l'examen du monde réel, elle pourrait attirer des développeurs open source du monde entier. Dans ce cas, les équipes d'agents de codage existantes pourraient ne pas avoir le dernier mot.
Pi, qui a historiquement joué un rôle important sous OpenClaw, reste largement discuté. OpenCode continue également d'attirer une communauté de développeurs fidèle. Mais ces projets ont des Harness sans leurs propres modèles de fondation.
DeepSeek possède à la fois le LLM et le Harness. Cette combinaison crée un potentiel écosystémique substantiel.
La communauté discute récemment de la façon dont le même modèle peut se comporter très différemment sous différents Harness.
Et si DeepSeek Harness finissait par faire partie de l'infrastructure partagée pour comparer les modèles ?
S'il devenait une base de Harness privilégiée dans la communauté open source, et que les développeurs construisaient progressivement un riche écosystème de Plugins autour de lui, DSH pourrait devenir un standard de facto. D'autres agents de codage pourraient alors évoluer vers la compatibilité avec ses interfaces et conventions.
Ces possibilités restent spéculatives. Elles reposent sur les idées et l'architecture visibles aujourd'hui, et non sur des résultats écosystémiques prouvés.
Le concept est convaincant, et le potentiel est réel. Ce qui se passera ensuite dépendra de la capacité de l'architecture à conserver le soutien de la communauté après que les développeurs auront examiné le code au microscope.