Notes techniques Naly : Codex CLI, JSON structuré et agents IA compatibles cron

Résumé

Naly utilise Codex CLI comme plan de contrôle pour le travail IA planifié : chaque entrée cron exécute un script validé qui lance une tâche d’assistant bornée avec recherche web et un contrat de sortie strict, puis écrit des artefacts JSON validés pour la publication en aval, la rejouabilité et les nouvelles tentatives. Cela rend le travail du modèle plus proche d’un pipeline opérationnel—même commande, schéma explicite, artefacts explicites—plutôt qu’un flux interactif mutable. Au 25 juin 2026, cette distinction constitue l’avantage de fiabilité pour une infrastructure de contenu critique pour la croissance.

Sa place dans Naly

Naly dispose déjà de priorités GST actives autour des workflows de découverte, de rétention et de distribution. Ce modèle correspond directement à cette couche d’exécution :

Les tâches cron déclenchent un seul tsx script par cas d’utilisation afin que chaque exécution reste dans le code versionné, et non dans des snippets shell ad hoc.
Codex CLI effectue le raisonnement et la récupération, tandis que Naly gère le contrôle d’orchestration : planification, tentatives, verrouillage et artefacts durables.
La sortie structurée alimente les systèmes aval construits sur Next.js, React, Drizzle ORM et Neon sans supposition de schéma en aval.
Les journaux externes et les métadonnées d’exécution sont écrits sous NALY_LOG_ROOT, ce qui rend les post-mortems reproductibles indépendamment de la mise en mémoire tampon de la sortie du processus.

L’hypothèse centrale est la suivante : en production, la qualité d’un LLM n’est que la moitié du système ; les limites déterministes autour de ce LLM constituent l’autre moitié.

Mécanisme technique

1) Point d’entrée du worker orienté contrat

Chaque tâche démarre à partir de trois entrées immuables :

Un modèle de prompt codifié et une intention de tâche.
Un schéma de réponse qui doit être validé.
Une enveloppe d’exécution (run_id, source_query, attempt, env), persistée avant l’appel API.

Naly invoque Codex CLI en mode batch depuis cron, pas en mode interactif. Codex est documenté comme un agent de codage local et distribué comme CLI autonome avec une distribution open source et des versions actives, et peut être exécuté dans un environnement scripté Codex CLI, OpenAI Codex repository.

2) Pourquoi la sortie structurée est non négociable

Les guides OpenAI sur les sorties structurées décrivent l’extraction de schéma assistée par parseur et le comportement de mode strict requis pour les pipelines machine. Chez Naly, la sortie du modèle est traitée comme un artefact intermédiaire, pas comme la vérité finale, donc le contrat JSON est là où la fiabilité est appliquée :

champs obligatoires (titre, liste de preuves, confiance, citations, raison d’échec)
champs optionnels avec valeurs par défaut
confiance numérique et énumérations bornées
échecs explicites du parseur exposés comme erreurs d’exécution, pas comme texte auto-corrigé silencieusement.

3) Cycle cron-vers-agent avec contrôle de concurrence

Cron exécute les lignes planifiées selon les 5 champs de timing standards et lance une commande quand les champs correspondent crontab. Pour la sécurité en production, Naly ajoute :

garde de verrou (une seule exécution active par tâche)
clé d’exécution idempotente
politique de nouvelles tentatives bornée avec jitter
capture de journaux externes pour chaque phase
mise à jour d’état post-exécution dans des tables gérées par Drizzle/Neon.

flock est conçu précisément pour ce modèle de garde-fou : acquérir un verrou, exécuter une section critique, quitter proprement quand il est déjà verrouillé flock. Parce que l’état du verrou suit les descripteurs de fichier, les fenêtres cron qui se chevauchent sont explicitement refusées au lieu de corrompre l’état.

4) Pourquoi MCP compte dans ce modèle

Le Model Context Protocol formalise les contrats hôte/client/serveur des outils via JSON-RPC, la négociation de capacités et des appels d’outils structurés MCP. Chez Naly, les frontières de type MCP réduisent l’accouplement implicite : la recherche web peut être représentée comme une interface d’outil contrôlée avec des capacités explicites plutôt qu’un comportement libre au niveau du shell.

Ce que dit la littérature

Les recherches récentes montrent que la fiabilité n’est pas équivalente à la capacité brute. L’article AI Agent Reliability signale des écarts importants entre la précision de tâche et la cohérence entre exécutions, et propose des dimensions de fiabilité explicites (consistance, robustesse, prévisibilité, sécurité) pour l’évaluation opérationnelle Towards a Science of AI Agent Reliability. Cela soutient la conception run-state-first de Naly : si une exécution réussit mais ne peut pas être répétée avec des artefacts clairs, elle n’est pas de qualité production.

Pour les sorties structurées, ToolPRM montre que le comportement de call d’outils structuré nécessite une supervision explicite et que les gains sont particulièrement forts lorsque l’on modélise le processus interne d’appel de fonctions plutôt que seulement les résultats finaux ToolPRM: Fine-Grained Inference Scaling of Structured Outputs for Function Calling. Cela est cohérent avec la boucle runner orientée schéma de Naly : la barrière de qualité se trouve aux frontières d’interface, pas seulement dans la fluidité du contenu.

Un troisième article sur cette même frontière, SLOT, montre une voie alternative pratique en ajoutant une couche de façonnage de sortie agnostique du modèle au-dessus des LLMs SLOT: Structuring the Output of Large Language Models. Il renforce le même principe : la fiabilité de la structure est un problème d’ingénierie même lorsque la qualité du modèle de base est élevée.

Compromis de conception

Schéma strict vs. portabilité du modèle: les schémas stricts réduisent l’ambiguïté en aval mais peuvent augmenter le churn de parsing lorsque les fournisseurs interprètent différemment les contraintes.
Simplicité de cron vs. élasticité de la file d’attente: cron est simple et visible, mais les charges par rafale ont besoin d’un backoff conscient du verrou ou d’une couche de file d’attente pour éviter les exécutions en chevauchement et les fenêtres manquées.
Recherche web intra-tâche vs. rejouabilité déterministe: la recherche web en temps réel améliore la fraîcheur mais introduit de la volatilité des sources ; c’est pourquoi Naly stocke le texte de requête, la liste des sources et les références brutes dans les artefacts d’exécution.
Journaux externes vs. journaux uniquement base de données: les journaux de système de fichiers résistent aux redémarrages de processus et sont peu coûteux pour l’ingestion ; les journaux en BD simplifient l’ergonomie des requêtes mais peuvent échouer en boucle ouverte si la partition n’est pas soignée.

Modes d’échec

Dérive de schéma: la sortie du fournisseur enfreint le schéma ; la mitigation est une validation stricte en échec rapide, un verrouillage de version de schéma et des exécutions de dead-letter.
Exécutions cron qui se chevauchent: doubles écritures ou actions externes dupliquées ; la mitigation est un verrou consultatif + une garde de sortie de processus.
Instabilité de la recherche: la réponse de l’outil amont change d’une tentative à l’autre ; la mitigation est la limitation des retries, un délai exponentiel et la persistance des références amont.
Surprises de timing: la variation de DST et des fuseaux horaires hôte peut affecter la sémantique de planification ; la mitigation est une politique de planification en UTC et des vérifications explicites de l’environnement.
Écritures partielles silencieuses: le parsing réussit mais l’écriture aval échoue ; la mitigation est un ordre de persistance transactionnel et des upserts idempotents.
Fuite de sécurité/contexte: tout chemin d’agent capable d’utiliser des outils peut dépasser son périmètre, donc des frontières de moindre privilège de type MCP et des hypothèses explicites de consentement/autorisation sont nécessaires, surtout quand les chemins d’exécution d’outils touchent des ressources réseau Notes de sécurité MCP.

Notes d’implémentation

Conservez une seule commande worker par tâche métier dans scripts/ et laissez cron appeler uniquement ce point d’entrée.
Stockez le hash du fichier de schéma dans les métadonnées d’exécution pour que les attentes du parseur soient auditables après une mise à niveau du modèle.
Définissez set -euo pipefailun comportement de type set dans les scripts wrappers et incluez toujours les IDs d’exécution dans les noms de journal.
Écrivez trois points de contrôle dans les journaux : started, codex_result_parsed, artifact_persisted.
Utilisez NALY_LOG_ROOT pour que les traces d’exécution ne polluent jamais l’état du dépôt et résistent aux contextes de redémarrage.
Persistez attempt, exit_code, retry_reason, et validation_errors pour permettre aux tableaux de bord GST et d’audit de séparer l’infra instable des régressions de modèle réelles.