Code as Agent Harness — un survey de 102 pages qui considère le code comme le socle d’exécution des agents

Projet commun UIUC × Meta × Stanford. Il s’agit d’un survey publié sur arXiv en mai, et l’angle est assez intéressant.

Thèse principale

"Le code n’est plus simplement le résultat généré par un LLM. C’est l’operational substrate sur lequel un agent raisonne, agit, stocke son état et vérifie les retours."

Autrement dit, le code n’est pas juste un fichier .py, mais le monde même dans lequel l’agent vit. Cette idée est appelée code as agent harness.

Une architecture en 3 couches

L’article analyse les systèmes d’agents en les divisant en 3 couches :

① Harness Interface — la manière dont le code relie l’agent à son environnement

• Externaliser le raisonnement sous forme de code, comme avec Program-of-Thoughts, puis l’exécuter/le vérifier
• En contrôle GUI/robotique, le programme généré fonctionne comme une politique
• Les codebases, traces et simulateurs représentent l’environnement lui-même

② Harness Mechanisms — le système de contrôle qui soutient l’exécution sur le long terme

• Planning : au-delà de la simple decomposition, on évolue vers une planification persistante basée sur le système de fichiers, avec des fichiers comme PLAN.md. Meta-Harness traite même la conception du harness comme un espace de recherche
• Memory : analyse découpée en working/semantic/experiential/long-term/multi-agent + context compaction. L’idée clé : la mémoire n’est pas une simple vector DB, mais une couche unifiée de gestion d’état
• PEV Loop : le cycle Plan → Execute → Verify est redéfini comme un cybernetic governor. L’exécution suit un modèle d’autorisations en 3 niveaux : read-only → sandbox-edit → full-access(HITL)
• AHE : une méta-couche qui mesure et optimise le harness lui-même

③ Scaling the Harness — la manière dont des multi-agents collaborent sur le code comme médium partagé

• Point marquant : "la complexité topologique est une taxe imposée par l’immaturité des représentations d’état partagé" — les systèmes qui conçoivent bien leur état fonctionnent même avec une structure simple, tandis que ceux qui dépendent d’un état implicite compensent ce manque par une topologie plus complexe

Points particulièrement marquants

• Context Compaction + State Offloading : ne mettez pas tout dans la context window ; gardez seulement, dans l’active context, les résumés nécessaires à la décision, et déléguez les données complètes via un protocole de type MCP — c’est un vrai conseil pratique
• La vérification comme capteur déterministe : des retours déterministes comme les linters, type checkers, tests ou fuzzers constituent des signaux de contrôle plus fiables que la critique par LLM
• La cause des échecs n’est pas le modèle mais le harness : "la plupart des échecs d’agents viennent d’un contexte de dépôt insuffisant, d’interfaces d’outils fragiles, de validateurs faibles, de coûts en tokens excessifs et de mauvaises politiques de retry"

Open Problems

Parmi les 7 problèmes ouverts laissés par l’article :

• Évaluer au-delà du succès final : considérer aussi les traces intermédiaires, les tentatives de récupération et les vérifications de sécurité comme des métriques de premier rang
• Améliorer le harness sans régression : comment apprendre des échecs sans casser le comportement existant
• État partagé transactionnel entre multi-agents : résolution des conflits quand plusieurs agents modifient le code en même temps

Références

• Article : https://arxiv.org/abs/2605.18747
• Site de résumé clair : https://code-as-harness.github.io/code-as-harness-webpage/
• Collection d’articles liés : https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers