DeepSeek Harness évolue d'une application d'agent classique vers un environnement d'exécution composable où les modèles, outils, compétences, sessions, bacs à sable, stockage, boucles, planification et interface sont fournis par des extensions. Le projet reste en préversion développeur, mais la branche 0.1.7 alpha rend cette architecture plus concrète : les dépendances d'extensions sont résolues à l'exécution, le Plugin Manager sait décharger des extensions et le mode Creator s'appuie désormais sur lui pour installer des extensions persistantes.
Cette évolution compte parce que le harness devient progressivement un environnement d'exécution complet, pas seulement une couche autour du modèle. Elle offre davantage de liberté, mais fait aussi de la compatibilité, de la provenance et du cycle de vie des extensions une partie du plan de contrôle.
« Tout est une extension » devient un principe opérationnel
DeepSeek présente Harness comme un environnement fondé sur Cordis. Les grandes capacités de l'agent résident dans des extensions. Le mode Standard fournit l'outillage complet. Le mode Code permet au modèle d'enchaîner plusieurs opérations via un SDK. Le mode Minimal réduit volontairement l'environnement pour les benchmarks. Le mode Creator sert à inspecter l'exécution et à construire de nouvelles compositions.
Dans la série 0.1.7 alpha, les dépendances utilisent désormais une résolution à l'exécution et le Plugin Manager prend en charge le déchargement. Le mode Creator abandonne les anciens outils de définition dynamique et installe des extensions persistantes via le Plugin Manager. La CLI peut aussi lancer directement un profil nommé.
Harness devient ainsi plus proche d'une plateforme configurable que d'un agent empaqueté une fois pour toutes.
La composition dynamique change aussi les modes de panne
Dans un paquet statique, le contrat de démarrage est relativement simple : les dépendances chargent ou l'application échoue. Un environnement composable possède davantage d'états. Une extension peut être installée mais inactive, chargée plus tard ou retirée alors qu'un autre service en dépend.
L'analyse d'Aipolix est que les équipes qui développent sur DeepSeek Harness doivent traiter le graphe des extensions comme un état de production. Elles devraient enregistrer les extensions et versions actives pour chaque exécution, tester les changements de dépendances avant déploiement et rendre visibles les événements de chargement et de déchargement. Sinon, deux sessions avec le même modèle et la même instruction peuvent se comporter différemment uniquement parce que la composition du harness a changé.
Cette exigence complète la traçabilité mise en avant par DeepSeek. Le projet enregistre dans un journal append-only ce que le modèle voit, les appels d'outils, la planification des sous-agents et les injections de contexte. Cette trace est vraiment reproductible seulement si la configuration du runtime l'est aussi.
Les changements de sessions rappellent que la plateforme reste mouvante
La même famille de versions modifie les formats de session, le comportement des sous-agents et certaines API d'extensions. Le projet documente les migrations de formats, tandis que les chaînes de sous-agents continuables reçoivent des limites par défaut sur le nombre d'enfants actifs et la profondeur de délégation.
Ces changements sont normaux pour une préversion développeur, mais ils montrent que la surface d'extension n'est pas stabilisée. Lorsque sessions persistées, profils, presets et API évoluent à des rythmes différents, l'exploitation devient plus délicate.
Les équipes devraient donc épingler leurs versions et tester toute mise à niveau avec de vraies sessions et leurs extensions privées. Une version alpha convient à l'exploration d'architecture, pas à l'hypothèse de compatibilité automatique.
Séparer le modèle du harness est l'idée la plus utile
L'architecture distingue explicitement les capacités du modèle de l'infrastructure qui lui permet d'agir. Outils, sandbox, état de session, planification et orchestration ne sont pas enfermés dans une implémentation spécifique à un modèle.
Cette séparation peut faciliter la comparaison de plusieurs modèles sous le même environnement ou le remplacement d'un composant d'infrastructure. Elle crée aussi un emplacement plus clair pour appliquer les politiques de permission, de stockage, de réseau et d'accès aux outils.
En contrepartie, le harness devient une partie plus importante de la base de confiance. Une extension qui modifie les outils ou la planification peut changer matériellement l'autorité de l'agent. La provenance des extensions et leurs permissions deviennent donc aussi importantes que le choix du modèle.
0.1.7 reste une préversion
GitHub marque les versions 0.1.7 comme pre-release. L'alpha la plus récente corrige notamment la découverte des modèles et la reconnexion Web, tandis que l'alpha précédente introduit les changements de runtime et de plugins les plus structurants.
Il faut prendre ce statut au sérieux. Harness est intéressant pour évaluer un runtime composable, construire des extensions expérimentales et étudier les traces de session, mais il ne prouve pas que les API ou les migrations sont figées.
Ce que les développeurs devraient tester
Une évaluation pratique peut partir d'un petit profil épinglé avec un modèle, des outils et un stockage connus. Il faut ensuite comparer les traces avant et après un changement contrôlé d'extension, puis tester chargement, déchargement, reprise après redémarrage, migration des sessions et limites de permission.
DeepSeek Harness 0.1.7 mérite l'attention parce qu'il rend le harness lui-même plus programmable. Cette souplesse accélère l'expérimentation, mais elle exige la même discipline de versionnement, d'observabilité et de gestion des changements que les dépendances d'une application classique.