Dans SHARP Agent Protocol v2 : un prompt de 22 kilo-octets qui manage des agents comme une équipe d'ingénierie
SHARP Agent Protocol v2 est un jeu d'instructions de 488 lignes qui transforme un seul modèle de langage en équipe d'ingénierie managée : exactement une tâche par sous-agent frais, des tests adversariaux écrits avant tout code, une vérification indépendante, et des fichiers mémoire durables qui survivent à la perte de contexte. Ce qu'il fait, comment l'utiliser, et où ses affirmations dépassent les preuves.
La section des prompts de ce site s'est enrichie aujourd'hui d'une nouvelle entrée : le LLM Sharp Reasoning Prompt, officiellement intitulé SHARP Agent Protocol v2 - Multi-Agent Execution, Adversarial Verification and Memory Context Boost. Avec 488 lignes et environ 22 kilo-octets, ce n'est pas un prompt qu'on colle pour obtenir un meilleur e-mail. C'est un manuel d'exploitation qui tente de transformer un seul modèle de langage en une équipe d'ingénierie managée : un manager qui planifie, des sous-agents frais qui font chacun exactement une tâche, un testeur adversarial qui écrit des cas d'échec avant que le code n'existe, et un ensemble de fichiers mémoire durables qui survivent à la conversation. J'ai lu l'intégralité du texte attentivement. Cette entrée est ma carte de ce qu'il fait, des idées qui valent la peine d'être empruntées, et des endroits où ses promesses dépassent ce qu'un prompt peut réellement garantir.
La version courte
SHARP est un protocole de style prompt système en trois parties. La partie I définit une boucle d'exécution adaptative - triage, plan, ideate, test-spec, work, verify, manage - dans laquelle un agent manager délègue exactement une tâche par sous-agent frais, puis vérifie le résultat indépendamment au regard de critères d'acceptation explicites. La partie II est une discipline de mémoire : des fichiers durables aux noms par défaut comme AGENTS.md, TASKS.md, DECISIONS.md, HANDOFF.md et VERIFICATION.md, une hiérarchie de récupération, des points de contrôle, et une procédure de récupération obligatoire après perte de contexte. La partie III relie le tout en une seule boucle avec un format de rapport final strict (Done, Verified, Not verified, Risks, Resume state). Ses affirmations centrales - les plans ne sont pas l'exécution, l'implémentation n'est pas une preuve, l'historique de conversation n'est pas une mémoire - sont une culture d'ingénierie solide compressée en instructions. Les coûts sont réels : une dépense de tokens importante en cérémonial, des hypothèses sur des fonctionnalités de plateforme absentes de bien des configurations, et aucune évaluation publiée, donc les bénéfices sont argumentés, pas mesurés. Le texte intégral est publié verbatim dans la section des prompts, lien ci-dessous.
Ce qu'est réellement ce prompt
SHARP se présente comme un seul bloc d'instructions destiné à être installé comme prompt système ou jeu d'instructions permanent pour un agent de code ou d'ingénierie. Il s'ouvre sur une déclaration de mission - opérer comme un agent d'ingénierie discipliné et auto-correcteur - et une liste de sept principes fondamentaux qui se lisent comme un document de culture de revue de code : les plans ne sont pas l'exécution ; l'implémentation n'est pas une preuve de correction ; l'historique de conversation n'est pas une mémoire durable ; les résumés ne sont pas la vérité de référence ; les sous-agents sont des contributeurs, pas des autorités ; une tâche n'est pas terminée tant que ses critères d'acceptation obligatoires ne sont pas vérifiés ; et ne jamais revendiquer des capacités, des actions, des résultats de tests ou un succès qu'on ne peut pas étayer. Le corps compte dix-neuf sections numérotées organisées en trois parties, conclues par une règle d'application finale : ne jamais fabriquer de progrès. Le texte ne nomme aucun auteur et ne porte aucune provenance au-delà du v2 de son titre, ce qui suggère au moins une itération. Je ne prétends rien sur son origine ; ce qui suit est une analyse du texte lui-même, publié verbatim sur ce site.
Partie I : une boucle d'ingénierie, pas un chat
La première partie définit sept phases. TRIAGE dimensionne la tâche et choisit l'un des trois niveaux de rigueur - trivial, standard ou complexe - avec un avertissement explicite : le triage détermine la quantité de travail, pas la permission d'ignorer les contrôles obligatoires. PLAN fait rédiger par le manager une stratégie courte, trois à six tâches concrètes étiquetées par difficulté, des critères d'acceptation pour chacune, et les preuves qui établiront le succès. IDEATE envoie le problème à un sous-agent frais qui n'a pas vu le travail en cours, exige au moins trois approches véritablement distinctes avec leurs modes d'échec, et interdit le code d'implémentation à ce stade. TEST-SPEC est la phase inhabituelle : avant le début de l'implémentation, un sous-agent adversarial frais écrit des tests conçus pour découvrir comment la solution proposée pourrait échouer - entrées limites, courses critiques, risques d'injection, régressions - et ces tests sont conservés pour la phase de vérification. WORK confie exactement une tâche à chaque sous-agent d'implémentation frais avec un brief discipliné, interdit la dérive du périmètre, et exige un passage d'auto-attaque nommant au moins trois modes d'échec plausibles. VERIFY remet le manager aux commandes : il doit réellement exécuter l'implémentation et les tests adversariaux, et les règles de preuve sont directes - ne jamais affirmer qu'un test a réussi s'il n'a pas réellement tourné et réussi, ne jamais masquer des contrôles ignorés, et un critère obligatoire échoué annule toute affirmation antérieure d'achèvement. MANAGE boucle la boucle avec une classification feu tricolore (vert, jaune, rouge) et une procédure de récupération qui revient en arrière, fait courir des alternatives en parallèle, ou change d'approche plutôt que de rafistoler indéfiniment.
Partie II : la mémoire comme composant de premier ordre
La deuxième partie traite l'épuisement de la fenêtre de contexte, les redémarrages de session et la compaction comme des conditions d'exploitation attendues, non des cas limites. Sa règle centrale : la connaissance critique doit être récupérable depuis un état durable, pas depuis l'historique de conversation. Elle prescrit cinq fichiers par défaut - AGENTS.md pour les instructions persistantes du projet, TASKS.md pour l'état d'exécution, DECISIONS.md pour l'historique des décisions avec les alternatives rejetées, HANDOFF.md comme point de reprise, et VERIFICATION.md comme journal de preuves des contrôles réellement exécutés - tout en soulignant que les noms sont des défauts et que les enregistrements existants du projet doivent être réutilisés. Autour de ces fichiers, elle construit une hiérarchie de récupération (les instructions courantes et la documentation du dépôt priment sur la mémoire, la mémoire prime sur les résumés de conversations), des règles de mise à jour des enregistrements aux étapes significatives, une gestion du budget de contexte qui sauvegarde des points de contrôle de récupération avant une compaction probable, et une hypothèse stricte : chaque sous-agent frais démarre sans mémoire implicite, donc les briefs de transmission doivent être complets. Deux sections se distinguent. CONTEXT RECOVERY est une procédure obligatoire en neuf étapes après toute interruption : relire les enregistrements, inspecter l'état réel du dépôt, vérifier que les changements précédemment revendiqués existent vraiment, et reprendre depuis la dépendance non résolue la plus ancienne - sans jamais faire confiance à un résumé qui contredit l'état observé. Et le RESUMABILITY TEST demande, pour tout travail substantiel inachevé, si un agent frais pourrait continuer à partir des seuls enregistrements durables ; si les enregistrements ne peuvent pas dire ce que veut l'utilisateur, ce qui est vérifié et ce qui vient ensuite, ils doivent être améliorés avant la fin de la session.
Partie III : une boucle, un format de rapport
La dernière partie compresse le tout en un pipeline unique - de triage à plan à ideate à test-spec à work à verify à manage à la mise à jour mémoire puis à la tâche suivante - avec la récupération mémoire en continu. La section de clôture définit un format de réponse finale que je verrais volontiers adopté partout : rapporter ce qui est fait, ce qui a été vérifié avec les résultats observés, ce qui n'a pas été vérifié, les risques, et l'état de reprise pour le travail inachevé. Elle interdit aussi d'affirmer que la mémoire a été sauvegardée si l'écriture n'a pas réellement réussi, et d'affirmer qu'une tâche peut reprendre si les enregistrements n'existent pas. La dernière ligne est toute la philosophie en une phrase : l'implémentation réelle et la vérification exécutée établissent la vérité.
Ce qu'il fait bien
Le protocole se lit comme une liste de modes d'échec observés des agents avec une contre-mesure attachée à chacun. Le succès halluciné reçoit les règles de preuve. La dérive du périmètre reçoit la règle d'exactement une tâche. La perte de contexte reçoit les fichiers mémoire et la procédure de récupération. Les sous-agents sycophantes reçoivent la ligne selon laquelle le code et les affirmations d'un sous-agent ne sont pas fiables tant qu'ils ne sont pas vérifiés. La conception à contexte frais par tâche reflète le comportement des frameworks d'orchestration sérieux, et écrire des tests adversariaux avant l'implémentation, c'est de la pensée red team appliquée au moment le moins coûteux possible. J'apprécie aussi les contraintes d'honnêteté que la plupart des prompts oublient : révéler quand une capacité requise est indisponible, ne jamais simuler la conformité, et ne jamais déclasser une tâche pour esquiver des contrôles requis. Que vous adoptiez ou non le protocole entier, l'habitude VERIFICATION.md - un journal courant des commandes exécutées et des résultats observés - vaut la peine d'être volée à elle seule.
Comment l'utiliser
Collez le texte intégral comme prompt système ou instructions permanentes d'une plateforme d'agents qui prend réellement en charge les sous-agents et les fichiers persistants ; c'est le public que suppose le protocole. Sur une configuration plus légère, la section triage vous autorise une version allégée : les tâches triviales obtiennent une exécution directe avec des contrôles proportionnés, et le cérémonial multi-agents complet ne se déclenche que sur le travail complexe. Adaptez les noms des fichiers mémoire à ce que votre projet utilise déjà plutôt que de créer des documents parallèles - le texte l'autorise explicitement. Attendez-vous à une forte hausse de la consommation de tokens sur les tâches difficiles, car l'idéation, l'écriture de tests adversariaux et la vérification indépendante sont toutes des appels de modèle supplémentaires par construction. Et gardez le format de rapport final même si vous ne gardez rien d'autre ; il met au jour la différence entre fait, vérifié et supposé.
Limites honnêtes
Plusieurs, et le prompt lui-même insisterait probablement pour que je les énumère. D'abord, il n'existe aucune évaluation publiée : rien dans le texte ni ailleurs ne démontre que les agents suivant SHARP produisent mesurablement moins de défauts que des jeux d'instructions plus simples, donc chaque bénéfice ici est argumenté à partir de la structure, pas de la preuve. Ensuite, le protocole suppose des fonctionnalités de plateforme - sous-agents frais instanciables, fichiers durables, récupération, télémétrie d'usage du contexte - dont beaucoup de déploiements sont tout simplement dépourvus, et un modèle sur une plateforme moindre peut simuler le cérémonial au lieu de l'omettre honnêtement. Troisièmement, 22 kilo-octets d'instructions sont eux-mêmes une taxe de contexte qui concurrence le budget même que les sections mémoire tentent de protéger. Quatrièmement, un prompt contraint le comportement ; il ne peut pas le garantir. Un modèle peut toujours écrire "tous les tests passent" pour des tests qui n'ont jamais tourné - le protocole peut interdire le mensonge, mais il ne peut pas l'empêcher, c'est pourquoi l'habitude de vérification côté manager compte plus que n'importe quelle règle isolée. Enfin, le cérémonial a un coût sur les petites tâches même avec le triage, et les équipes qui font déjà tourner une CI et des revues de code disciplinées trouveront des parties redondantes avec des outils qui appliquent les mêmes règles mécaniquement plutôt qu'en les demandant poliment.
Où lire le texte intégral
Le protocole complet est publié verbatim - les 488 lignes - dans la section des prompts de ce site sous le nom LLM Sharp Reasoning Prompt, avec la page environnante en six langues. Si vous menez des flux de travail de code multi-agents, il vaut vingt minutes de lecture même si vous n'en gardez que trois idées : une tâche par sous-agent frais, des tests adversariaux avant le code, et un journal de vérification qui consigne ce qui a réellement tourné.