API- und Coding-Agent-Schritte in einer geprüften Pipeline ausführen
Benötigt: Gemini API + Claude Code + Codex + OpenAI API · Dieser Ablauf braucht alle genannten Tools. Die Auswahl zeigt passende Abläufe und ersetzt keine Voraussetzung.
Diese Seite behandelt andere Tools als deine Auswahl. Du kannst sie weiterhin lesen. Passende Anleitungen finden
Direkte Modellaufrufe mit CLI-Schritten verbinden, Anfragegrenzen prüfen und unklare Ergebnisse vor weiteren Aufrufen abgleichen.
Ein direkter Modellaufruf passt zu einem Schritt, der ausgewählte Belege in JSON überführt. Coding-Agenten bleiben dort sinnvoll, wo ihre Arbeitsweise der Aufgabe hilft. Das Referenzpaket kann beides in einem Lauf überwachen. Menschen entscheiden über Umfang, Entwurf und Abnahme.
Diese Ausführung ist optional. Der Standard nutzt weiterhin synthetische Antworten. CLI-Zugang und API-Schlüssel werden getrennt eingerichtet. Die Zugangsreferenz auf Englisch erklärt die Unterschiede. Eine IDE als Host belegt nicht, welches Konto den Zugang liefert.
Jedem Schritt eine konkrete Aufgabe geben
Das Rezept research führt einen Retry-Vertrag durch vier Modellschritte:
| Schritt | Empfänger | Zu prüfendes Ergebnis |
|---|---|---|
| Anforderungen extrahieren | Gemini API | Aussagen mit Quellzeilen und offenen Fragen |
| Plan vorschlagen | Claude Code | Änderung mit Bezug zu den ausgewählten Anforderungen |
| Konfiguration vorschlagen | Codex | JSON-Kandidat für die feste Prüffunktion |
| Belege bewerten | OpenAI API | Befunde und Einschränkungen nach der Prüfung |
Diese Rollenverteilung ist ein zu bewertendes Beispiel. Sie belegt keine allgemeine Rangfolge. Die Änderung der Testaufgabe beschränkt sich auf firstAttempt: 0 zu firstAttempt: 1. Die Prüffunktion wertet JSON-Daten aus; generierter Code wird nicht ausgeführt. Die API-Schritte haben keine Browser- oder Repository-Werkzeuge.
Das Ausführungsprofil prüfen
Kopiere profiles/research.example.json aus dem Download in eine private lokale Konfiguration. Bereite CLI-Pfade, Konto-Umgebung und das getrennte Arbeitsverzeichnis wie unter CLI-Ausführung beschrieben vor. Ein zusätzlicher API-Eintrag sieht so aus:
{
"model": "REPLACE_WITH_AVAILABLE_RESPONSES_MODEL",
"api_key_env": "PIPELINE_OPENAI_API_KEY",
"max_output_tokens": 4096,
"max_request_bytes": 65536
}
Das ist der Wert von apis["openai-api"]. Wähle ein verfügbares Modell mit Unterstützung für das dokumentierte Antwortformat. Stelle den Schlüssel über die vorbereitete Prozessumgebung oder einen Secret Manager bereit. Das Profil enthält den Variablennamen; erst beim Start des Schritts liest der Koordinator den Wert. Gespeicherte Chat- oder CLI-Anmeldedaten werden dafür nicht ausgelesen.
Das geprüfte Profil zeigt den abgeleiteten öffentlichen Endpunkt, die API-Familie, das angeforderte Modell und die Grenzen. Freie Endpunkte, zusätzliche Anfrageparameter und nicht im Rezept deklarierte API-Empfänger werden abgewiesen. Ein in apis fehlender API-Adapter wartet auf einen expliziten Ergebnisimport. Manuelle Schritte warten immer auf eine Person.
Das versiegelte Profil erkennt Änderungen an seiner aufgezeichneten Konfiguration. Es beweist nicht, zu welchem Konto ein Schlüssel gehört, fixiert keinen Anbieter-Alias und richtet keine Netzwerkgrenze ein. Prüfe das gegen den freigegebenen Konto- und Datenumfang.
Den gemischten Lauf starten
Im entpackten Paket:
node cli.mjs new ./research-run --recipe research --execution native --profile ./research.local.json
Prüfe das ausgegebene Umfangspaket. Halte deine Entscheidung mit dem angezeigten Digest und deinem Namen fest:
node cli.mjs decide ./research-run --gate scope --digest PRINTED_DIGEST --decision approve --by YOUR_NAME
node cli.mjs run ./research-run
Der Koordinator führt Recherche und Planung aus und hält beim Entwurf an. Prüfe Aussagen und Plan, bevor du diesen Gate mit dem neu angezeigten Digest freigibst. Ein weiterer run erstellt den Konfigurationsvorschlag, prüft ihn und fordert das Review an. Die Abnahme braucht eine weitere menschliche Entscheidung über diese Belege.
Die Anbieterformate sichtbar halten
OpenAI Responses verwendet text.format für das JSON-Schema, Anthropic Messages output_config.format. Der Gemini-Adapter dieses Pakets nutzt GenerateContent mit generationConfig.responseFormat.text. Google bezeichnet diese API-Familie als Legacy. Interactions braucht einen eigenen Anfrageaufbau und eine eigene Auswertung des Abschlusszustands.
Die Clients senden ein Schema mit Struktur und erlaubten Werten. Das vollständige Schema bleibt im Prompt und in der lokalen Validierung. Längen, Wertebereiche und Array-Größen werden nach dem Parsen geprüft; Anthropic dokumentiert Grenzen für diese Bedingungen im Anfrageformat. Ein erfolgreicher HTTP-Transport belegt noch kein gültiges Aufgabenergebnis.
Fehler vor einem weiteren Aufruf prüfen
Jeder Versuch protokolliert Status, Endpunkt, Modell, Anfrage- und Antwortbytes mit Hashes sowie verfügbare numerische Verbrauchszähler. Fehlertexte des Anbieters werden weder ausgegeben noch aufbewahrt. Bei Fehlern können Verbrauchsangaben fehlen. Laufzeit, Ausgabetokens, Byte-Grenzen und Versuchszähler setzen keine Ausgabenobergrenze für dein Konto durch.
| Beobachtetes Ergebnis | Verhalten des Koordinators |
|---|---|
| Vollständiges, gültiges Ergebnis | Weiter zum nächsten zulässigen Schritt oder Gate |
| HTTP 429, Ablehnung, ungültiges JSON oder falsche Belege | Schritt schlägt fehl; run allein wiederholt ihn nicht |
| Weiterleitung | Status aufzeichnen und der Weiterleitung nicht folgen |
| Zeitüberschreitung, abgebrochene/zu große Antwort, laufender Auftrag, HTTP 408 oder Serverfehler | Abgleich verlangen und weitere Aufrufe sperren |
Eine Verbindung kann beispielsweise abbrechen, nachdem der Anbieter die Anfrage angenommen hat. Dann steht im Protokoll remote_completion: "unknown". Prüfe Belege und Verbrauch auf Anbieterseite, bevor du einen neu freigegebenen Lauf startest. Das Paket kann das Ergebnis nicht automatisch wiederherstellen oder nachweisen.
cancel oder Strg-C bricht die lokale HTTP-Anfrage ab und stoppt überwachte CLI-Prozesse. Eine geschlossene Verbindung beweist nicht, dass die entfernte Berechnung beendet wurde. Protokolle und frühere Versuche bleiben zur Prüfung erhalten.
Was schiefgeht
Ein Entwickler hält sein Abonnement für API-Guthaben, wählt ein Modell ohne das benötigte Schemaformat oder kopiert einen Schlüssel in das Quellpaket. Ein anderer wertet passendes JSON als Beweis, dass die zitierte Anforderung gilt. Prüfe Konto, Anfrageformat und Quellenbelege jeweils eigenständig.
Eine ungültige Konfiguration kann vor jeder HTTP-Anfrage scheitern. Brauchen aufgezeichnete Werte eine Änderung, erstelle ein neu geprüftes Profil. Lösche keine früheren Protokolle, um das Versuchslimit zurückzusetzen.
So prüfst du das Ergebnis
node --test test.mjs executor.test.mjs api-executor.test.mjs
Die HTTP-Tests nutzen einen lokalen Server und einen synthetischen Schlüssel. Sie prüfen Anbieterformate, gemischte CLI/API-Übergaben, menschliche Pausen, unabhängige Reviews, Weiterleitungen, Fehler, Grenzen, Abbruch und Validierung. Sie verbrauchen keine Anbieterleistung und belegen keine Integration mit echten Zugangsdaten.
Nutze für einen Versuch mit deinem Konto dieselbe kleine Retry-Aufgabe. Bewahre Profil, gemeldetes Modell und Verbrauch, Transportergebnis sowie Quellen- und Prüfbelege auf. Kennzeichne diesen Versuch separat und vergleiche Ergebnis und Review-Aufwand des gesamten Ablaufs.
Quellen
- OpenAI: strukturierte Modellausgaben Tier 1 2026-09-08
- Anthropic: strukturierte Ausgaben Tier 1 2026-09-08
- Google: strukturierte Ausgabe mit GenerateContent Tier 1 2026-09-08
- Google: GenerateContent-API-Referenz Tier 1 2026-09-08
Stimmt etwas auf dieser Seite nicht?
Schreib, was du erwartet hast und was passiert ist. Das ist meist der kürzeste Weg zu einer Korrektur, und es landet im öffentlichen Issue-Tracker, damit die Änderung nachvollziehbar bleibt.