Harness de code IA : architecture, sécurité et cas Pi
Le modèle propose le prochain mouvement. Le harness le rend exécutable, borné, observable et récupérable. Ce n’est ni le modèle ni une simple fenêtre de dialogue : c’est le plan de contrôle qui relie modèle, dépôt, terminal, permissions et vérifications.
Responsabilités minimales
Boucler jusqu’à ce que le modèle dise « terminé » donne une orchestration, pas encore un harness fiable.
Frontière des preuves
Les responsabilités d’architecture sont une synthèse. Le comportement de Pi est vérifié dans sa documentation et son code source ; la comparaison avec DeepSeek Harness reste attribuée à la vidéo liée dans le texte. Ces sources établissent une conception ou une fonction documentée, pas la supériorité ni la fiabilité d’un harness.
Cette note privilégie le code en terminal et couvre moins les IDE, les agents navigateur, le travail non anglophone, la gouvernance et l’automatisation hors code. Preuves et biais fournit la méthode de lecture ; l’évaluation datée des agents de code contient la sélection actuelle des produits.
Système de contrôle interne
Trois notes rendent ce plan concret :
- Boucles d’agent distingue session courte, contexte neuf, implémentation–vérification et évaluateur–optimiseur ; toute boucle exige un succès externe et des budgets fermes.
- Ingénierie du contexte traite la fenêtre du modèle comme un jeu de travail changeant, tandis que plans, preuves et checkpoints restent durables hors transcript.
- Contrats d’outils explicite effets, reprises, approbations et succès partiels au lieu de les déduire d’un nom de fonction.
Ces couches comptent davantage avec un petit modèle local : raccourcir les tours, réduire les outils et les sorties, puis laisser des contrôles déterministes décider s’il faut continuer.
Pi : un harness minimal programmable
Pi se présente comme un harness minimal de code en terminal. Son noyau conserve les appels de modèles, la boucle d’agent, l’exécution des outils, les sessions arborescentes et l’interface terminal, puis confie les comportements propres à chaque workflow à des ressources composables. Par défaut, le modèle ne reçoit que read, write, edit et bash. grep, find et ls sont aussi intégrés, mais doivent être sélectionnés explicitement ou activés par la configuration.
Outre le TUI interactif, Pi offre la sortie ponctuelle -p, un flux d’événements JSON, un RPC sur stdin/stdout et un SDK pour intégrer l’agent à une application Node.js. Les fournisseurs de modèles peuvent être remplacés. Les sessions sont des arbres JSONL : /tree, /fork, /clone et /compact couvrent l’exploration dans un même fichier, les sessions séparées et la compression du contexte.
Les détails Pi ci-dessous ont été vérifiés le 2026-08-28 dans la documentation de Pi 0.84.3 installée localement. Ce sont des faits produit versionnés, pas une promesse de compatibilité permanente.
Rôle de chaque couche de personnalisation
Les ressources globales résident généralement sous ~/.pi/agent/, celles du projet sous .pi/ ou .agents/skills/. Un prompt développe du texte. Un skill applique la divulgation progressive : seuls son nom et sa description entrent par défaut dans le contexte. Une extension modifie directement le harness. Préférer un skill lorsqu’il manque une méthode, un prompt lorsqu’il manque une entrée réutilisable, et une extension seulement lorsqu’un nouvel outil, hook d’événement ou élément d’UI est réellement nécessaire.
Le déroulement vérifié des requêtes, du Steering, du Follow-up, de la compaction et des sessions de Pi est regroupé dans Boucles d’agent bornées. Une branche de session modifie la conversation vue par le modèle sans restaurer les fichiers sur disque ; les commandes ci-dessous restent ici comme référence pratique.
Extensions : la couche de plugins de Pi
Une extension est un module TypeScript chargé directement par Pi. Elle peut :
- enregistrer des outils appelables par le modèle et des commandes slash utilisateur ;
- intercepter tours du modèle, appels et résultats d’outils, changements de modèle et cycle de vie des sessions ;
- bloquer ou réécrire les appels dangereux et ajouter chemins protégés ou UI d’approbation ;
- personnaliser compaction, état de session, composants du terminal et rendu ;
- enregistrer des providers, ou implémenter MCP, sous-agents, plan mode et intégration sandbox.
Le dernier point est essentiel : des exemples ou packages tiers peuvent fournir ces fonctions, mais elles ne font pas partie des valeurs par défaut du noyau. Un petit noyau autorise plusieurs conceptions, tout en rendant l’installateur responsable de leurs politiques, de leur maintenance et de leur récupération après erreur.
Les extensions découvertes automatiquement vont dans ~/.pi/agent/extensions/ ou .pi/extensions/ d’un projet approuvé ; après modification, exécuter /reload. Pour un essai temporaire sans installation, utiliser pi -e ./extension.ts. Un package Pi peut distribuer ensemble extensions, skills, prompts et thèmes :
pi install npm:@scope/package@1.2.3 # fixer une version
pi install ./local-package -l # portée projet
pi list
pi config # activer ou désactiver chaque ressource
pi update --extensions
Une extension exécute du code arbitraire avec les droits de l’utilisateur courant, et un skill peut demander au modèle d’exécuter des scripts inclus. Un package est donc une unité de distribution, pas une frontière de sécurité. Lire le code source et les dépendances avant installation, fixer les versions lorsque c’est utile et n’activer que les ressources nécessaires.
Usage quotidien
Un projet ordinaire n’a pas besoin d’un vaste plan de contrôle dès le premier jour :
Un petit projet peut n’utiliser que les fichiers nécessaires :
AGENTS.mdpour les règles et les commandes d’acceptation ;.pi/prompts/review.mdpour un court prompt répété, si besoin ;.agents/skills/release/SKILL.mdpour une procédure réutilisable facultative ;.pi/extensions/policy.tsuniquement lorsqu’une politique du host exige du code.
Modes de lancement courants :
cd my-project
pi --name "parser repair" # session interactive
pi -c # continuer la dernière session
pi --no-session -p "Summarize this repository" # tâche ponctuelle éphémère
# Pour une revue, n’exposer que les outils en lecture seule
pi --no-session --tools read,grep,find,ls -p "Review the change"
# Ignorer la découverte et ne charger que la ressource testée
pi --no-extensions -e ./.pi/extensions/policy.ts
pi --no-skills --skill ./.agents/skills/release/SKILL.md
Premières commandes interactives à retenir :
Socle de sécurité
La confiance accordée au projet décide si Pi charge les réglages .pi, les ressources et les extensions exécutables du projet. Ce n’est pas une sandbox réseau ou système de fichiers. Les modes non interactifs n’affichent pas la demande intégrée de confiance du projet ; l’automatisation doit donc prendre une décision --approve explicite plutôt que de faire confiance par défaut à tout dépôt.
Point de départ conservateur :
- inspecter l’état Git,
AGENTS.mdet le périmètre d’écriture avant d’approuver les ressources du projet ; - utiliser
--tools read,grep,find,lspour une revue, puis élargir les outils seulement si l’écriture devient nécessaire ; - placer dépôts inconnus ou commandes dangereuses dans un conteneur ou une VM, en laissant identifiants, socket Docker et dossiers sans rapport à l’extérieur ;
- construire un jeu minimal et reproductible avec
--no-extensions,--no-skillset les options apparentées ; - auditer et fixer les packages tiers, en considérant toute extension comme du code disposant de tous les droits utilisateur ;
- juger la réussite avec tests, lint, diff et état final des processus, pas avec l’affirmation du modèle qu’il a terminé.
C’est l’échange central entre Pi et les harnesses plus « produits » : son noyau est plus petit et plus malléable, mais politique de sécurité et qualité du workflow n’apparaissent pas automatiquement.
Pi et DeepSeek Harness : qui prend en charge la complexité ?
La vidéo de présentation de Pi et la vidéo sur DeepSeek Harness montrent des systèmes qui se ressemblent au premier abord. Tous deux peuvent changer de modèle, connecter des outils et ajouter des plugins. La distinction la plus utile ne concerne pas le nombre de fonctions, mais le moment où la complexité apparaît et la personne qui doit la gérer.
Pi part d’un petit noyau. Si l’utilisateur veut un mode plan, des sous-agents, MCP ou une interface spécialisée, il assemble cette capacité lorsqu’elle devient utile. Le système par défaut reste ainsi lisible, mais la compatibilité, les permissions et la maintenance incombent à l’utilisateur.
La vidéo sur DeepSeek Harness part au contraire de la formule « Everything is a plugin ». Modèles, outils, interfaces et workflows partagent une même surface de composition. Cette approche facilite la réutilisation des processus récurrents dans une équipe, tout en transférant la gestion des dépendances, des versions et du diagnostic à la plateforme de plugins.
Aucune approche ne supprime la complexité. Pi la retarde et la confie à la personne qui construit le workflow ; la conception montrée dans la vidéo sur DeepSeek Harness en concentre davantage dans la plateforme. Pour mon workflow actuel, Pi doit rester petit et compréhensible. Seules les capacités récurrentes et déjà stables méritent de devenir des composants communs. Un atelier de plugins devient utile lorsque ces composants sont trop nombreux pour être maintenus séparément.
Les comparaisons de produits appartiennent à Frontier
Cette page emploie Pi et la vidéo sur DeepSeek Harness comme cas de conception. La matrice datée des produits, les conseils de sélection et le protocole de rejeu se trouvent dans Choisir un agent de programmation IA, afin de mettre les faits produit à jour sans modifier le modèle durable du harness.
Ordre de conception
- Définir le résultat et un contrôle externe de réussite.
- Exposer le plus petit ensemble d’outils utile.
- Séparer lectures, écritures et actions irréversibles.
- Conserver artefacts et preuves hors de la conversation.
- Fixer des limites de temps, tokens, reprises et concurrence.
- Tracer tours et appels d’outils tout en protégeant les données sensibles.
- Rejouer des tâches représentatives avant de changer de modèle, de harness ou d’effort de raisonnement.
Le harness et le workflow possèdent les critères de qualité ; le modèle reste remplaçable. Un meilleur modèle peut réduire les reprises, mais ne supprime ni preuves, ni permissions, ni contrôles de bout en bout. Les modèles et tarifs changeants appartiennent au Radar des modèles et API ; les résultats publics et pièges propres aux outils vont dans l’Évaluation des agents de code.