Naly-Engineering-Notizen: Codex CLI, strukturiertes JSON und cron-sichere KI-Worker

Zusammenfassung

Naly nutzt Codex CLI als Kontroll-Ebene für terminierte KI-Arbeiten: Jeder Cron-Eintrag startet ein versioniertes Skript, das eine begrenzte Assistenzaufgabe mit Websuche und einem strengen Ausgabekontrakt ausführt und validierte JSON-Artefakte für nachgelagerte Veröffentlichung, Reproduktion und Wiederholungsversuche schreibt. Dadurch verhält sich Modellarbeit wie eine operative Pipeline—gleicher Befehl, explizites Schema, explizite Artefakte—statt eines mutablen interaktiven Workflows. Stand 2026-06-25 ist diese Unterscheidung der Zuverlässigkeitsvorteil für wachstumsrelevante Inhaltsinfrastruktur.

Einsatz im Naly-System

Naly hat bereits aktive GST-Prioritäten rund um Discovery-, Retention- und Distributions-Workflows. Dieses Muster passt direkt in diese Ausführungsebene:

Cron-Jobs führen ein einziges tsx Skript pro Anwendungsfall aus, damit jeder Lauf innerhalb versionierten Codes bleibt, nicht in ad-hoc Shell-Snippets.
Codex CLI übernimmt die Reasoning- und Sucharbeit, während Naly die Orchestrierung steuert: Zeitplan, Wiederholungen, Sperren und dauerhafte Artefakte.
Strukturierte Ausgabe speist nachgelagerte Systeme auf Basis von Next.js, React, Drizzle ORM und Neon, ohne dass ein nachgelagertes Schema geraten werden muss.
Externe Logs und Lauf-Metadaten werden abgelegt unter NALY_LOG_ROOT, wodurch Post-Mortems reproduzierbar sind und unabhängig vom Prozessausgabepuffer funktionieren.

Die These lautet: Für den Produktionseinsatz ist LLM-Qualität nur die halbe Lösung; deterministische Grenzen um dieses LLM sind die andere Hälfte.

Technischer Mechanismus

1) Vertrag-zentrierter Worker-Einstiegspunkt

Jede Aufgabe startet mit drei unveränderlichen Eingaben:

Eine kodifizierte Prompt-Vorlage und ein Aufgaben-Intent.
Ein Antwortschema, das validiert werden muss.
Eine Laufumgebung (run_id, source_query, attempt, env), die vor dem API-Aufruf persistiert wird.

Naly ruft Codex CLI aus Cron im Batch-Modus auf, nicht im interaktiven Modus. Codex ist als lokaler Coding-Agent dokumentiert und wird als eigenständige CLI mit Open-Source-Vertrieb und aktiven Releases ausgeliefert und kann in einer skriptbasierten Umgebung ausgeführt werden Codex CLI, OpenAI Codex repo.

2) Warum strukturierte Ausgabe unverzichtbar ist

OpenAI-Guías für strukturierte Ausgaben beschreiben Parser-gestützte Schema-Extraktion und das strikte Verhalten im Strict-Modus, das für Maschinen-Pipelines nötig ist. In Naly wird die Modellausgabe als Zwischenartefakt verstanden, nicht als Endwahrheit, daher wird die JSON-Konvention dort durchgesetzt, wo Zuverlässigkeit erzwungen wird:

Pflichtfelder (headline, evidence list, confidence, citations, failure reason)
optionale Felder mit Standardwerten
numerische Confidence und gebundene Enums
Explizite Parserfehler werden als Lauffehler ausgeworfen, nicht stillschweigend automatisch korrigiert.

3) Cron-to-Agent-Lebenszyklus mit Nebenläufigkeitskontrolle

Cron führt geplante Zeilen nach den Standard-Feldern mit 5 Feldern aus und startet einen Befehl, wenn die Felder übereinstimmen crontab. Für Produktionssicherheit ergänzt Naly:

Lock-Guard (ein aktiver Lauf pro Aufgabe)
idempotenter Laufschlüssel
begrenzt konfiguriertes Retry-Policy mit Jitter
externe Log-Erfassung für jede Phase
Post-Run-Statusupdate in Datenbanktabellen, die von Drizzle/Neon verwaltet werden.

flock ist genau für dieses Guardrail-Muster ausgelegt: Sperre holen, kritischen Abschnitt ausführen, sauber beenden, wenn bereits gesperrt flock. Da der Lock-Status Dateideskriptoren folgt, werden sich überschneidende Cron-Fenster explizit blockiert statt den Zustand zu beschädigen.

4) Warum MCP in diesem Muster wichtig ist

Das Model Context Protocol formalisiert Host/Client/Server-Tool-Verträge mit JSON-RPC, Capability-Aushandlung und strukturierten Tool-Calls MCP. In Naly reduzieren MCP-ähnliche Grenzen implizite Kopplungen: Websuche kann als kontrolliertes Tool-Interface mit expliziten Fähigkeiten statt als freiformige shell-basierte Logik abgebildet werden.

Was die Literatur sagt

Aktuelle Forschung zeigt, dass Zuverlässigkeit nicht gleich Rohleistung ist. Das Paper AI Agent Reliability berichtet erhebliche Lücken zwischen Aufgabenpräzision und Konsistenz über Läufe hinweg und schlägt explizite Zuverlässigkeitsdimensionen (Konsistenz, Robustheit, Vorhersagbarkeit, Sicherheit) für die operative Bewertung vor Towards a Science of AI Agent Reliability. Das stützt Nass Run-State-first Design von Naly: Wenn ein Lauf erfolgreich ist, aber nicht mit klaren Artefakten wiederholbar ist, ist er nicht produktionsreif.

Für strukturierte Ausgaben argumentiert ToolPRM, dass strukturiertes Tool-Calling-Behavior explizite Aufsicht braucht und dass Verbesserungen besonders stark sind, wenn der interne Funktionsaufruf-Prozess modelliert wird statt nur die Endergebnisse. ToolPRM: Fine-Grained Inference Scaling of Structured Outputs for Function Calling. Das passt zu Naly’s schema-first Runner-Schleife: Die Qualitätskontrolle sitzt an Schnittstellen-Grenzen, nicht nur an der inhaltlichen Sprachgewandtheit.

Ein drittes Paper auf derselben Front, SLOT, zeigt einen praktikablen alternativen Weg, indem eine modellunabhängige Ausgabemanipulationsschicht oberhalb von LLMs ergänzt wird SLOT: Structuring the Output of Large Language Models. Es verstärkt das gleiche Prinzip: Strukturierte Zuverlässigkeit ist ein Engineering-Problem, auch wenn die Basismodellqualität hoch ist.

Entwurfs-Trade-offs

Strenges Schema versus Modell-Portabilität: Strenge Schemata reduzieren Mehrdeutigkeiten downstream, können aber gelegentlich zu Parse-Churn führen, wenn Anbieter Constraints unterschiedlich interpretieren.
Cron-Simplicity versus Queue-Elasticity: Cron ist einfach und nachvollziehbar, aber Spitzenlasten brauchen lock-bewussten Backoff oder eine Queue-Schicht, um Überschneidungen und verpasste Fenster zu vermeiden.
In-Task-Websuche versus deterministisches Replaying: Frische Websuche erhöht die Aktualität, bringt aber Quellenvolatilität mit sich; daher speichert Naly Abfragetext, Quellenliste und Rohreferenzen in Lauf-Artefakten.
Externe Logs versus nur DB-Logs: Dateien-Logs überstehen Prozess-Neustarts und sind günstig für das Einlesen; DB-Logs vereinfachen die Abfrage-Ergonomie, können aber offene Schleifen erzeugen, wenn sie nicht sauber partitioniert sind.

Ausfallmodi

Schema-Drift: Anbieterausgabe verletzt das Schema; Gegenmaßnahme ist strikte Validierung mit Fail-Fast, Schema-Version-Pinning und Dead-Letter-Läufen.
Überlappende Cron-Ausführungen: doppelte Schreibvorgänge oder doppelte externe Aktionen; Gegenmaßnahme ist Advisory-Lock plus Prozess-Beendigungs-Schutz.
Suchinstabilität: Upstream-Tool-Antworten ändern sich zwischen Versuchen; Gegenmaßnahme sind Retry-Caps, exponentielle Verzögerung und persistierte Upstream-Referenzen.
Zeitliche Überraschungen: DST und Timezone-Unterschiede des Hosts können die Planungssemantik verändern; Gegenmaßnahme ist UTC-Scheduling-Policy und explizite Environment-Checks.
Stille Teilschreibungen: Parsing gelingt, aber nachgelagerter Write scheitert; Gegenmaßnahme ist transaktionale Persistenzreihenfolge und idempotente Upserts.
Security-/Kontext-Leckage: jeder tool-fähige Agentenpfad kann über das Ziel hinausschießen, daher sind MCP-ähnliche Least-Privilege-Grenzen und explizite Zustimmung/Auth-Annahmen nötig, besonders wenn Toolausführungspfade Netzwerkressourcen berühren. MCP-Sicherheitshinweise.

Implementierungshinweise

Behalten Sie einen Worker-Befehl pro Business-Task in scripts/ und lassen Sie nur diesen Entry-Point von Cron aufrufen.
Speichern Sie den Hash der Schema-Datei in den Lauf-Metadaten, damit Parsererwartungen nach einem Modell-Upgrade prüfbar sind.
Setzen Sie set -euo pipefail-style Verhalten in Wrapper-Skripten und verwenden Sie stets Run-IDs in Log-Namen.
Schreiben Sie drei Checkpoints in Logs: started, codex_result_parsed, artifact_persisted.
Verwenden Sie NALY_LOG_ROOT damit Runtime-Spuren niemals den Repository-Zustand verschmutzen und Neustart-Kontexte überstehen.
Persistieren Sie attempt, exit_code, retry_reasonund validation_errors um GST- und Audit-Dashboards zu ermöglichen, instabile Infrastruktur von echten Modellregressionen zu trennen.