Aujourd'hui, à l'aube,
DeepSeek
V4 Pro, la version officielle, a été publiée, déclenchant un vif engouement. Maintenant, une demi-journée plus tard,
DeepSeek
Harness (version de prévisualisation pour les développeurs) est aussi disponible !
Bien sûr, cela n'est pas une surprise, car ce projet a été annoncé depuis longtemps, par exemple
DeepSeek
Harness L'équipe de Cui Tianyi a continué à poster des teasers sur les réseaux sociaux et à recruter des talents pour son équipe.
Nous avons également obtenu l'accès à la version bêta de
DeepSeek
Harness début août, profitant à l'avance de ce framework d'agent intelligent qui est destiné à apporter un nouveau changement à la communauté de l'IA.
Adresse du dépôt open source : https://github.com/deepseek-ai/deepseek-harness
Par exemple, ici, nous avons laissé le
DeepSeek
Harness configuré avec le modèle officiel
DeepSeek
-V4-Flash créer pour nous un jeu de tir de zombies à la première personne. Sans aucune intervention de notre part, nous avons obtenu en une trentaine de minutes un produit fini, certes imparfait mais déjà tout à fait jouable.
Étant donné que l'approche d'Andrej Karpathy pour générer des mondes 3D avec l'IA est très en vogue ces derniers jours, nous avons également fait relever à
DeepSeek
Harness(V4-Flash) le défi du benchmark « Huaqiang achète des pastèques » : recréer la scène classique « Huaqiang achète des pastèques » en animation 3D à partir d'une description textuelle (également le résultat d'une seule instruction) :
Dans l'ensemble, bien que loin d'être parfaite, l'animation reprend globalement l'histoire et les relations entre les personnages sont reconnaissables. En comparaison, l'animation que nous avons produite avec le même prompt, mais en utilisant Codex configuré avec GPT-5.6 sol-xhigh, était bien inférieure :
Il faut savoir que la taille des paramètres de
DeepSeek
-V4-Flash est bien inférieure à celle de GPT-5.6 sol. On peut imaginer que
DeepSeek
Harness doit y être pour beaucoup.
Aujourd'hui, avec la sortie de la version officielle de
DeepSeek
V4 Pro, nous avons également intégré ce modèle dans
DeepSeek
Harness et avons relancé le processus :
L'effet est en effet un peu meilleur.
Ensuite, en examinant la structure du projet, c'est impressionnant : le dépôt contient déjà plus de 230 membres du workspace, le code étant réparti dans les répertoires packages/, apps/, examples/, python/, native/, vendor/, website/, etc. Système de fichiers, terminal, sous-processus, PTY, serveur de langage, accès web, compétences, sous-agents, workflows, mode planification, persistance de session, paramètres, informations d'identification, télémétrie, presque chaque capacité possède son propre package.
Si on compare un projet d'agent ordinaire à un ordinateur déjà assemblé, alors
DeepSeek
Harness ressemble plus à une plaque de prototypage de taille impressionnante : le modèle, les outils, l'interface, le stockage, les politiques de sécurité et la gestion du contexte peuvent tous être branchés et débranchés.
Il fournit un plan d'assemblage par défaut, mais il est clair que ce que
DeepSeek
veut vraiment créer n'est pas un « assistant de programmation DeepSeek » de forme fixe, mais plutôt une méthode d'assemblage d'agents intelligents.
Qu'est-ce que DeepSeek Harness ?
Clarifions d'abord une question qui prête à confusion :
DeepSeek
Harness n'est pas un nouveau modèle
DeepSeek
, ni un simple client API. C'est un SDK et un framework d'application pour construire, exécuter et étendre des agents intelligents, qui peut par défaut se connecter aux modèles DeepSeek (mais peut aussi facilement se connecter à d'autres modèles), permettant au modèle de lire des projets, modifier des fichiers, exécuter des commandes, gérer des tâches, attribuer des sous-tâches, et d'interagir avec l'utilisateur via une interface Web, un terminal plein écran, une ligne de commande sans interface (Headless) ou des protocoles d'automatisation.
L'interface Web de
DeepSeek
Harness fournit une entrée pratique pour configurer directement d'autres services de modèle, sans que l'utilisateur ait à modifier manuellement les fichiers de configuration.
La communauté de l'IA n'est désormais plus étrangère au terme Harness. Son sens originel est harnais, faisceau, dispositif de retenue, etc. En l'abstrayant, son rôle est de connecter une force à une structure opérationnelle, tout en empêchant cette force de s'emballer. Concrètement dans le domaine de l'IA, Harness est responsable de connecter le modèle au système de fichiers, au shell, à l'éditeur de code, aux pages web et à d'autres agents, tout en enregistrant ce qu'il fait, en limitant ce qu'il peut faire, et en décidant, en cas d'erreur, s'il faut réessayer, annuler, compresser le contexte ou renvoyer le problème à l'utilisateur.
Cela explique peut-être aussi pourquoi la quantité de code et le nombre de packages de ce projet sont si importants, car les tâches et les choix d'outils impliqués sont nombreux, y compris l'appel d'outils pouvant être exécuté en parallèle, la possibilité d'arrêter réellement un sous-processus, la contamination du contexte par les résultats des outils, où doivent être insérées les nouveaux messages envoyés par l'utilisateur pendant l'exécution du modèle, comment reconstruire l'entrée du modèle lors de la reprise d'une session, quels outils possède un sous-agent, si l'écriture de fichiers peut dépasser l'espace de travail, et si le contenu vu lors de la relecture de l'interface est cohérent avec l'exécution en temps réel.
DeepSeek
Harness tente de transformer tous ces problèmes en capacités système formelles.
Tout est un plugin
La proposition de conception la plus frappante de
DeepSeek
Harness est « Tout est un plugin », la boucle de l'agent elle-même étant également considérée comme un plugin.
Le projet est construit sur le micro-noyau Cordis, un Harness en cours d'exécution est essentiellement un Contexte Cordis. Différents packages enregistrent des services, des événements et des capacités auprès du Contexte, qui sont finalement combinés par un fichier de configuration pour former un agent intelligent exécutable.
packages/core/ est le cœur de tout le système, contenant Session, System Prompt, Tools, Agent et Agent Loop. Ils résolvent les problèmes les plus fondamentaux : qu'est-ce qu'une session, comment est assemblé l'invite système, comment les outils sont enregistrés et appelés, comment l'agent est créé, et comment un tour de conversation passe de l'entrée de l'utilisateur à la requête du modèle, à l'exécution des outils et à la réponse finale.
Au-delà du noyau, il y a de nombreux packages de capacités :
- packages/llm/ est responsable des adaptateurs de modèle et de la sortie en streaming ;
- packages/shell/, packages/subprocess/ et packages/terminal/ sont responsables des commandes ponctuelles, de l'arborescence des processus et du terminal persistant ;
- packages/fs/ est responsable de la lecture/écriture, de l'édition, de la recherche et des restrictions de stratégie des fichiers ;
- packages/lsp/ se connecte au serveur de langage, permettant à l'agent non seulement de rechercher du texte, mais aussi d'obtenir une navigation sémantique du code ;
- packages/web/ est responsable de la recherche et du scraping web ;
- packages/skill/ gère les compétences réutilisables ;
- packages/subagent/ et packages/workflow/ étendent l'agent unique en un système multi-agents pouvant déléguer et orchestrer.
En regardant plus loin, la planification, les objectifs, les tâches à faire, les tâches en arrière-plan, la compression du contexte, l'interrogation des sessions, le titre de session, les informations d'identification, les paramètres utilisateur, les mécanismes d'approbation et la télémétrie sont également divisés en capacités indépendantes. La partie la plus intéressante de cette structure est qu'elle reflète une conscience presque obstinée des frontières : qui possède l'interface, qui est responsable de l'implémentation, qui expose la capacité au modèle, en essayant autant que possible de ne pas les mélanger.
La documentation du projet divise les capacités typiques en trois couches : interface, implémentation et consommateur.
Prenons Bash comme exemple : l'interface définit ce qu'est « exécuter une commande », l'implémentation locale est responsable de la création réelle du processus, et le package d'outils destiné au modèle est responsable de transformer cette capacité en schéma et résultats compréhensibles par le modèle. À l'avenir, si le shell local doit être remplacé par un conteneur distant, un bac à sable cloud ou une plateforme d'exécution d'entreprise, théoriquement, seule la couche d'implémentation doit être remplacée, sans avoir à réécrire les outils du modèle et la boucle de l'agent.
C'est une pensée typique de framework. Cela rendra le dépôt important au début, mais cela montre aussi que l'objectif de
DeepSeek
Harness n'est pas de créer un produit fini que seules les équipes officielles peuvent maintenir, mais de permettre aux différents déploiements de changer de modèle, de stockage, de stratégie de sécurité, d'ajouter des outils, voire de remplacer la boucle de l'agent intelligent.
Ici, nous voyons également l'engagement de
DeepSeek
en faveur d'un véritable open source !
cordis.yml
Un fichier de configuration assemble différents agents
L'architecture par plugins se concrétise finalement pour les développeurs via cordis.yml. Le fichier de configuration liste les noms des plugins, les ID stables et les paramètres, décidant quelles capacités exactes possède l'agent actuel.
Le même code peut être assemblé en des produits de forme complètement différente. Ajoutez l'adaptateur LLM DeepSeek, le système de fichiers, Bash et TUI, et vous obtenez un agent de programmation dans le terminal ; remplacez l'interface d'interaction par le plugin Web, et vous obtenez une application de navigateur ; utilisez l'entrée Headless, il accepte une tâche, complète les tours de modèle et d'outils, imprime la réponse et se termine ; remplacez-la par une façade ACP ou JSON-RPC, et il peut devenir un service automatisé que d'autres programmes peuvent piloter.
La configuration prend également en charge les couches de recouvrement. TUI et Web UI peuvent partager une configuration de base, superposée avec leurs propres plugins d'interface et paramètres ; la configuration personnelle se situe quant à elle dans la dernière couche. Ainsi, le déploiement n'a pas besoin de copier l'arborescence de configuration entière, il suffit de remplacer les plugins spécifiés. Cependant, il y a un détail à noter ici : le correctif de configuration remplace l'ensemble du config du plugin cible, il ne s'agit pas d'une fusion en profondeur. Si vous n'écrivez qu'un nouveau champ, les clés API, les adresses de base ou autres paramètres existants peuvent également disparaître. C'est explicite, mais pas forcément intuitif pour un premier utilisateur.
Le projet permet également de lire les variables d'environnement et les expressions d'exécution via !!js dans le YAML, par exemple en récupérant la clé secrète depuis DEEPSEEK_API_KEY. La configuration ne fait référence qu'au nom des informations d'identification, la clé est résolue lors de l'appel réel. L'interface Web écrira la clé dans $DSH_HOME/.credentials.yaml, tandis que les variables d'environnement et .env peuvent servir de sources de secours pour l'automatisation ou le développement local ; les clés ne doivent pas être écrites directement dans cordis.yml ni entrer dans les logs de session.
Agent Loop
Pas une boucle, mais un ensemble de règles de circulation
Le code central de nombreux projets d'agent précoces peut être simplifié en quelques lignes : envoyer le message au modèle, si le modèle renvoie un appel d'outil, exécuter l'outil, puis renvoyer le résultat au modèle, jusqu'à ce que le modèle produise du texte.
DeepSeek
Harness Bien sûr, il fait aussi cela, mais il divise ce processus en un cycle de vie strict.
Une entrée utilisateur ouvrira un Tour (Turn), un Tour peut contenir plusieurs Étapes (Step) ; une Étape correspond à une requête de modèle et à son exécution d'outils ultérieure. Avant la requête, le système assemble l'invite système stable, l'environnement d'exécution actuel, le schéma des outils et les messages de la session ; après la requête, les segments (chunk) en streaming du modèle, le message complet, les appels d'outils, les résultats des outils et la raison de la fin entreront tous dans le flux d'événements.
Le jeu de tir de zombies mentionné ci-dessus a exécuté 3 tours, 127 étapes.
L'outil n'est pas non plus « appelle dès qu'il obtient le nom de la fonction ». Il passera par une stratégie préalable, une garde de sécurité irréversible, l'exécution réelle, un traitement postérieur, une organisation du contenu et une notification des résultats. Autorisation ou refus, dépassement de délai, nouvelle tentative, statistiques de métriques, ajout de contexte, peuvent tous être connectés à différents points de la ligne de production. Un outil peut déclarer que les appels sous un certain type de paramètre sont sûrs en concurrence, le planificateur exécutera alors les tâches de lecture seule consécutives en parallèle ; une fois qu'il rencontre un appel modifiant l'état ou dont la sécurité ne peut être déterminée, il le traite comme une barrière, attendant que les tâches précédentes se terminent avant de l'exécuter de manière exclusive.
Cette conception peut sembler un peu comme installer un système de contrôle aérien sur un chemin de campagne, mais lorsque l'agent commence à rechercher dix fichiers en même temps, exécuter des tests, accepter des instructions supplémentaires de l'utilisateur, et doit en plus permettre l'annulation à tout moment, ces règles passeront rapidement de la « conception excessive » aux « choses que l'on souhaiterait avoir plus tôt dans le rapport d'enquête sur un incident ».
Il traite également sérieusement la destination des messages reçus pendant l'exécution. Le nouveau contenu envoyé par l'utilisateur pendant le travail de l'agent peut être la tâche suivante, ou une instruction de redirection pour le travail en cours. Le système distingue les messages en attente, l'injection de contexte et le pilotage (Steering), et confirme via un accusé de réception si une instruction de pilotage est réellement entrée dans une requête de modèle spécifique. En d'autres termes, il ne se contente pas de savoir si « le message a été reçu », mais aussi « à quelle étape exacte le modèle l'a vu ».
Session Log
La véritable source d'autorité de tout le système
Une autre conception notable de
DeepSeek
Harness est le Journal de Session (Session Log).
Le projet stipule que tout contenu vu par le modèle doit pouvoir être reconstruit à partir du journal. Les messages utilisateur, le contexte de l'environnement d'exécution, les informations de requête du modèle, la sortie en streaming, les appels et résultats d'outils, les événements de compression, les changements de permission, les raisons d'annulation, tous entreront sous forme d'événements dans le flux de session en ajout. L'interface, la persistance, la reprise, le Fork, la télémétrie et la relecture ne devraient pas maintenir chacun un état « à peu près correct », mais dériver de la même source d'événements.
Ce principe résout un problème très épineux dans les systèmes d'agents : lorsqu'une tâche échoue, pouvons-nous vraiment savoir ce que le modèle a vu à ce moment-là ?
Si le système ne sauvegarde que le texte de conversation final, de nombreux facteurs clés seront perdus. Peut-être que juste avant la requête du modèle, l'état de l'espace de travail venait d'être injecté, peut-être que les résultats des outils ont été tronqués, peut-être que le système a automatiquement changé le routage du modèle, peut-être que l'utilisateur a changé de direction en plein milieu de la sortie en streaming.
DeepSeek
Harness sauvegardera, aux limites des requêtes, des enregistrements suffisants pour reconstruire les messages, les segments de streaming originaux seront également conservés, afin que l'interface et la relecture restent cohérentes.
La persistance de session elle-même reste un plugin. Le projet fournit des backends comme JSONL et SQLite, la capacité de requête peut accéder en priorité à la session en direct, mais peut également rechercher dans l'historique via la recherche en texte intégral de SQLite. Resume continuera le travail avec la session d'origine, Fork dérivera une nouvelle session à partir d'une limite historique déterminée. Pour les développeurs, cela fournit une base unifiée pour le débogage, l'évaluation, l'audit et l'automatisation.
D'un agent à un groupe d'agents
DeepSeek
Harness intègre déjà diverses capacités de sous-agents et de workflows.
L'agent principal peut déléguer des tâches à des sous-agents, un sous-agent peut être une instance nouvellement créée, un Fork à partir d'une limite terminée d'une session existante, ou une connexion à un processus externe via ACP.
Le jeu de tir de zombies mentionné ci-dessus a créé 5 sous-agents exécutés en parallèle.
La conception de la portée (scope) est importante ici. Chaque agent possède sa propre couche de contexte, pouvant voir des outils, des invites et des commandes spécifiques. Un sous-agent peut être limité à ne faire que de la recherche et de l'analyse, un autre peut être autorisé à modifier des fichiers. Les capacités enregistrées dans la portée d'un agent sont automatiquement nettoyées avec le cycle de vie de l'agent, évitant de dépendre de conventions de nommage globales pour maintenir l'isolation.
Le workflow va encore plus loin : il permet de piloter l'orchestration multi-agents avec un script, reliant plusieurs sous-tâches, sorties structurées et exécution continue. Le projet fournit simultanément des objectifs, plans, tâches à faire et tâches en arrière-plan. Ce ne sont pas seulement quatre petits composants d'interface avec des noms similaires, ce sont en réalité des états de collaboration à différents cycles de vie. Le mode plan enregistre la phase de collaboration actuelle, les objectifs peuvent persister sur la même session, les tâches à faire fournissent une liste de tâches légère pour le modèle, les tâches en arrière-plan sont quant à elles responsables de la gestion du travail réel encore en cours.
Cela montre que Harness ne souhaite pas seulement couvrir la « programmation question-réponse ». Il espère supporter les tâches longues, les investigations parallèles, l'exécution automatisée et la coordination avec les systèmes externes. Quant à savoir si le modèle peut maîtriser de manière stable autant de mécanismes, c'est un autre test ; au moins le framework a d'abord créé le volant, le tableau de bord et les freins.
Web, TUI, Headless et SDK
Pour les utilisateurs ordinaires, le projet recommande l'interface Web, écoutant par défaut sur http://127.0.0.1:3080. Elle offre la conversation, la barre latérale des sessions, la sélection des permissions, le mode planification, les cartes d'outils et l'interaction avec l'espace de travail.
L'interface Web fournit également quatre modes prédéfinis pour l'agent. Ce ne sont pas quatre ensembles d'agents indépendants, ni seulement des changements de style d'invite, mais plutôt, basés sur le même hôte Harness, ils assemblent pour la session actuelle différents outils, invites et capacités d'exécution :
Mode Standard : L'agent de programmation général le plus complet, fournissant l'édition de fichiers, Shell, recherche de fichiers et web, Compétences, planification, objectifs, sous-agents et workflows, adapté à la grande majorité des tâches de développement quotidiennes ;
Mode PTC : Conserve toutes les capacités du mode standard, tout en présentant les outils au modèle via le SDK Code Mode. Le modèle peut écrire un programme TypeScript, combinant plusieurs opérations en un seul run_code, réduisant les allers-retours répétés entre le modèle et les outils, plus adapté aux tâches complexes avec des chaînes d'appels longues ;
Mode Minimaliste : Ne fournit que deux outils : Bash persistant et str_replace_editor. Un ensemble d'outils plus réduit diminue la charge de choix et de contexte, adapté aux tâches de programmation avec un chemin clair, où l'on souhaite que l'agent passe directement à l'action ;
Mode Création : Ajoute au mode standard la vérification du runtime Cordis, l'expérimentation temporaire de plugins et le guide de création de presets d'agents. L'agent peut non seulement utiliser les outils existants, mais aussi explorer et recombiner son propre runtime, créant ainsi de nouveaux presets personnalisés. Puisqu'il peut exécuter du code de plugin écrit par le modèle, c'est un mode de haute confiance pour les utilisateurs avancés.
Cet ensemble de presets est peut-être l'expression la plus intuitive du produit pour « tout est un plugin » : le routage du modèle sous-jacent, la persistance de session, le bac à sable et l'approbation sont toujours fournis par l'hôte partagé, le preset ne décide que quelles capacités exactes sont chargées dans un Contexte d'Agent spécifique. La même interface Web peut ainsi passer d'un agent minimaliste à deux outils, au mode standard capable d'orchestrer des sous-agents, et même devenir un mode création capable de se modifier lui-même.
Par exemple, ici, en mode création, nous avons laissé le
DeepSeek
Harness connecté à
DeepSeek
V4 Pro créer un « mode trois colonnes » que l'interface Web officielle ne possède pas :
En dehors de l'interface Web, le TUI s'adresse aux développeurs qui préfèrent rester dans le terminal.
Le mode Headless convient aux scripts et à l'intégration continue (CI) : il accepte une tâche, attend que l'agent s'arrête complètement, sort la dernière réponse valide et se termine. Si le programme nécessite des événements structurés et un contrôle continu, il doit utiliser ACP ou JSON-RPC / le SDK Python.
En matière d'automatisation, le projet fournit un service ACP et une entrée JSON-RPC. Le SDK Python pilote le runtime JSON-RPC fourni, permettant aux applications Python de démarrer des sessions, d'envoyer des tâches, de recevoir des notifications, sans avoir à intégrer directement le noyau Node. Le dépôt contient également des exemples comme Code Mode, Cordis autoréférentiel, service de mémoire MCP, etc.
Il est important de noter que ces entrées ne sont pas quatre agents évoluant chacun de leur côté. Ils partagent le modèle de capacité central, la sémantique d'événements de session et la plupart des plugins de base, mais il ne s'agit pas simplement de remplacer une couche d'interface, mais plutôt d'assembler via différents bundles des formes de produits comme Web, tâches ponctuelles et services automatisés. C'est le résultat le plus intuitif de « tout est un plugin ».
L'agent peut s'inspecter et même se modifier
DeepSeek
Harness fournit également un ensemble d'outils Cordis autoréférentiels (self-referential). Ils n'entrent pas dans les modes standard, PTC ou minimaliste, mais sont fournis via le « mode création » dans l'interface Web comme point d'entrée avancé explicite. Après avoir choisi ce preset, l'agent peut inspecter l'arborescence des plugins du runtime actuel, et monter ou démonter dynamiquement des plugins temporaires.
Cela ressemble un peu à demander à une voiture de changer son propre moteur sur l'autoroute, c'est pourquoi le projet ne l'active pas par défaut. Il convient aux scénarios de recherche ou d'automatisation avancée : le modèle peut écrire temporairement un écouteur d'événements, enregistrer un nouvel outil, fournir un service, puis le démonter une fois la tâche terminée.
Un agent auto-modifiable peut facilement devenir une simple démonstration de concept, mais Harness l'a au moins placé dans le cycle de vie existant des plugins. Les plugins dynamiques s'exécutent toujours sous le mécanisme de Contexte et d'Effet de Cordis, les éléments d'enregistrement ont un chemin de nettoyage clair.
C'est encore loin d'être sans risque, mais cela montre l'endroit où cette architecture veut vraiment arriver : l'agent intelligent n'utilise pas seulement les capacités, il peut aussi recombiner son propre runtime dans une frontière contrôlée.
La conception derrière Cordis peut être consultée dans l'article publié simultanément par l'équipe officielle, « A Programming Paradigm for Spatiotemporal Composability » :
Adresse de l'article : https://github.com/cordiverse/paper
Stratégie de sécurité
Une fois qu'un agent de programmation obtient les permissions du système de fichiers et du Shell, il peut modifier du code, installer des dépendances, démarrer des processus, voire toucher à l'environnement de l'hôte en dehors de l'espace de travail.
DeepSeek
Harness considère clairement cela comme un problème d'infrastructure fondamentale, et non comme une simple fenêtre de confirmation ajoutée à l'interface.
Le projet adopte par défaut le mode workspace-write, limitant l'exécution des commandes et la modification des fichiers à l'espace de travail actuel et aux répertoires temporaires autorisés, et combiné avec la stratégie d'approbation ask pour traiter les opérations nécessitant une extension des permissions. Le mode plus permissif danger-full-access existe également, mais doit être explicitement choisi par le déploiement ; il ne sera pas emballé comme une option de compatibilité apparemment inoffensive.
Les appels d'outils doivent également passer par une stratégie préalable, une garde de sécurité monotone (monotonic safety guard), un wrapper d'exécution et un traitement postérieur. Une opération refusée par la garde ne peut pas être réautorisée par un plugin ultérieur ; une commande nécessitant une extension de permission doit expliquer la raison et être réessayée via le mécanisme d'approbation. Le système de fichiers, Bash et les sous-processus partagent la même stratégie de bac à sable, évitant une frontière fracturée où « les commandes sont limitées, mais les outils de fichiers peuvent contourner ».
Plus remarquable encore,
DeepSeek
Harness adopte le principe de « défaillance en position fermée » (fail-closed). Si le système ne peut pas confirmer que le mécanisme d'isolation est réellement efficace, il refuse l'exécution, au lieu de se dégrader silencieusement en une exécution sans protection. Le changement de permission, la demande d'approbation, les paramètres des outils, les résultats d'exécution et les raisons d'annulation entreront également dans le Journal de Session, fournissant une base pour l'audit ultérieur et la reproduction des problèmes.
Cette conception n'élimine pas tous les risques de l'exécution d'opérations locales par un agent intelligent, mais elle reflète une attitude d'ingénierie rare : la sécurité est une contrainte systémique qui traverse les mécanismes de configuration, d'exécution, d'approbation, de journalisation et de reprise. Le modèle peut proposer une action, mais ce qui décide réellement si l'action peut avoir lieu, c'est toujours Harness.
Ce que DeepSeek veut faire n'est pas seulement « un autre Codex »
Si l'on ne regarde que l'interface Web ou le TUI, il est facile de comprendre
DeepSeek
Harness comme une version DeepSeek de Codex, Claude Code ou d'autres assistants de programmation. Mais en regardant la structure du dépôt, son objectif est clairement plus fondamental.
L'application par défaut est bien sûr importante, elle permet aux développeurs d'obtenir directement un outil capable de lire/écrire des projets, d'exécuter des commandes, de planifier des tâches et d'appeler des sous-agents. Mais ce qui occupe vraiment le centre du projet, ce sont les interfaces de capacité remplaçables, le cycle de vie piloté par les événements, le journal de session faisant autorité et la composition déclarative. En d'autres termes, l'agent fini ressemble davantage au premier client de ce SDK.
Cela complète également l'écosystème de modèles de
DeepSeek
avec une pièce du puzzle qui n'était pas très visible auparavant. Le modèle détermine l'intelligence supérieure, Harness détermine comment cette intelligence entre dans l'environnement réel, comment utiliser les outils, comment conserver l'état, et comment travailler dans les limites des permissions. Pour les développeurs d'entreprise, ce dernier point est souvent plus important que d'avoir quelques boutons de plus dans la fenêtre de chat, car il détermine si le système peut être audité, étendu, remplacé et maintenu à long terme.
DeepSeek
Harness est encore loin d'être à l'étape « installation terminée, tout est fluide », mais il a déjà montré un ensemble de jugements techniques assez complets : l'agent ne devrait pas être une boucle de plus en plus lourde, mais plutôt un ensemble de capacités qui peuvent être combinées, observées et remplacées ; une session ne devrait pas être seulement un historique de chat, mais plutôt des faits d'exécution ; un outil ne devrait pas être seulement une fonction, mais devrait simultanément posséder des stratégies, une journalisation et un protocole de présentation.
Par conséquent, le plus digne d'attention concernant
DeepSeek
Harness n'est pas de savoir s'il peut aujourd'hui remplacer l'assistant de programmation que vous utilisez, mais à quel point il a rendu public la réponse de DeepSeek à l'ingénierie des agents.
Cet article provient du compte officiel WeChat « Machine Heart » (ID : almosthuman2014), auteur : Machine Heart qui suit DSH.
