DeepSeek Harness met l’agent open source sous contrainte

DeepSeek Harness, le framework d’agent open source de DeepSeek AI, mise sur une architecture « tout est plugin » pour piloter des agents, des outils et leur contexte d’exécution. Le projet est encore en préversion développeur, avec des changements possibles et des compatibilités susceptibles de casser. Son intérêt tient surtout à une idée simple mais exigeante : rendre chaque action rejouable à partir d’un journal d’événements, afin de pouvoir déboguer, compacter l’historique et reprendre une session sans bricolage.

Un agent sans noyau privilégié, et c’est là que tout commence

Le point de départ du projet, c’est l’absence de « noyau » propriétaire. Dans DeepSeek Harness, le modèle, la boucle d’agent, les outils, les événements de session et même certaines étapes de maintenance sont traités comme des plugins remplaçables. L’ossature repose sur Cordis, une bibliothèque vendue avec le dépôt, et sur un workspace pnpm qui aligne 219 paquets répartis en 49 groupes fonctionnels, avec un ESM intégral et Node ^22.19 ou >=24.

Ce choix change la façon de penser l’agent. Au lieu d’empiler des couches fixes, DeepSeek Harness sépare les rôles : une définition de service, un fournisseur, puis un consommateur. La boucle principale peut ainsi rester interchangeable, tandis que les extensions s’accrochent à côté. Le revers existe aussi : la discipline est stricte, et les erreurs de forme peuvent faire tomber l’intégration au lieu de se cacher derrière une compatibilité de façade. C’est moins confortable, mais beaucoup plus sain quand on veut rejouer un système entier.

Le journal de session comme source unique de vérité

La logique centrale du dépôt tient dans un principe : le log append-only est la seule réalité durable. Les messages visibles par le modèle sont dérivés du journal, pas stockés à part. Les relectures, les reprises, la télémétrie et la persistance repartent tous de cette même trace. En pratique, cela permet de reconstruire les messages à partir des événements, puis de vérifier que ce que le modèle voit correspond exactement à ce qui a été journalisé.

Cette rigueur s’accompagne d’un système d’invariants à l’exécution. Un événement inconnu peut être refusé, sauf s’il est marqué comme ignoré. Les formats de session et les schémas de la base SQLite disposent aussi de gardes serrées. Le message implicite est clair : le projet préfère refuser une entrée douteuse plutôt que de prétendre qu’elle passera plus tard. La base est rustique, presque têtue. Et elle ne s’excuse pas.

Compaction, contexte et le piège du « ça rentrera bien »

La gestion du contexte est l’autre grosse pièce du puzzle. DeepSeek Harness introduit une compaction explicite : quand le journal devient trop lourd, le système résume une portion de l’historique puis remplace la zone visée par un seul message utilisateur synthétique, au lieu d’empiler des résumés successifs. La compaction conserve les événements d’origine dans les métadonnées, pour que la reprise puisse expliquer ce qui a été effacé et à quelle étape cela s’est produit.

Le mécanisme est encadré de plusieurs verrous. Un résumé doit être plus court que la portion masquée, les plages sélectionnées doivent rester stables, et une tentative interrompue laisse une trace exploitable dans le journal. DeepSeek Harness sépare aussi le comptage des jetons, la stratégie de compression et la décision de compacter. Ce découplage compte, car il évite qu’une règle de coût brouille la logique métier de l’agent. Dans un long échange, c’est souvent là que l’on gagne du temps, ou que l’on en perd beaucoup.

Des outils pensés pour ne pas mentir au modèle

Les outils suivent la même logique. Chaque outil possède une définition, une sortie schéma-validée, une fonction d’exécution et, si besoin, une présentation UI purement fonctionnelle. L’exécution est entourée de couches de validation, de politiques d’autorisation, de timeouts et de gestion des annulations. Le système distingue clairement ce qui doit être visible du modèle, ce qui reste log-only et ce qui ne sert qu’à l’interface. Cette séparation évite une vieille tentation des systèmes agentiques : faire croire au modèle qu’un résultat est disponible alors qu’il a simplement disparu dans un coin du runtime.

Le dépôt couvre aussi des cas plus spécialisés, comme les outils shell, les fils de travail persistants, les connecteurs de recherche de fichiers, les sous-agents, le stockage temporaire ou encore les plugins Cordis dynamiques. Plusieurs packages sont générés à partir des schémas réels du contexte d’exécution, ce qui limite la dérive entre documentation et code. Le prix à payer, c’est une architecture dense et très normée. Le bénéfice, lui, est évident pour qui a déjà perdu une soirée à comprendre pourquoi un outil « marchait » en apparence mais n’avait jamais vraiment été injecté.

Ce que ce design dit du marché des agents

Au fond, DeepSeek Harness raconte quelque chose d’assez net sur l’état du marché des agents : les gains ne viennent plus seulement du modèle, mais de l’outillage autour. Journalisation stricte, compaction, séparation des capacités, politiques d’exécution et reprise fiable deviennent des arguments de produit à part entière. La promesse n’est pas glamour, mais elle est solide : si l’agent doit agir plusieurs heures, il faut qu’il sache aussi se souvenir sans se raconter d’histoires.

Les sources disponibles décrivent encore un projet jeune, avec une documentation riche mais parfois redondante, et des zones signalées comme susceptibles d’évoluer [à vérifier]. Reste une direction très lisible : DeepSeek AI pousse un socle où l’on peut remplacer presque chaque brique, rejouer chaque action et mesurer ce qui a vraiment changé. Pour les équipes qui construisent des agents en production, c’est moins une démonstration de style qu’une réponse à une question très concrète : comment éviter qu’un système intelligent devienne juste un système bavard ?