Diese Seite ist eine Übersetzung der englischen Dokumentation. Befehle, Bezeichner und Beispiele bleiben unverändert. Runtime 7.24.4 · SDK 2.6.7. Englische Fassung

Harness-Steuerung und geprüfte Auswertung

Status: Aktiv

Umfang: aktueller Stand

Zuletzt geprüft: 2026-09-14

Verantwortlich: AX-Code-Laufzeit

Zur modellspezifischen Anstrengung, zu Denkschaltern und zur Wiedergabe von Schlussfolgerungen siehe aktuelle Steuerung der Modellschlussfolgerung.

Optionale Kontext- und Tool-Steuerung

Aktivieren Sie jedes Experiment unabhängig in Ihrer AX-Code-Konfiguration:

{
  "experimental": {
    "context_recovery": true,
    "mcp_tool_discovery": true,
    "tail_reminders": true,
    "read_only_recipes": true
  }
}

Alle vier Optionen sind standardmäßig aus. Messen Sie Aufgabenerfolg und vergangene Zeit mit Ihrem Modell, bevor Sie sie gemeinsam übernehmen. sie behalten vorhandene Toolberechtigungen und Isolationseinstellungen. Siehe Leistungsdiagnosen.

context_recovery stellt context_recover bereit und fügt erfolgreichen Kompaktierungszusammenfassungen Quellverweise hinzu. Das Tool akzeptiert ein Schlüsselwort, eine Nachrichten-ID, eine optionale Teil-ID und eine Ergebnisgrenze. Es liest nur die aktuelle Sitzung, einschließlich der Historie vor der Kompaktierung, und schließt zurückgesetztes Material, verborgene Schlussfolgerungen sowie ignorierten oder synthetischen Text aus. Es liefert ursprüngliche Nachrichten- und Teil-IDs sowie begrenzte Auszüge. Die Suche prüft höchstens 100 Teile je Seite und die ersten 16.000 Zeichen jedes Teils. before setzt in älteren Teilen fort. Ein fehlender Treffer beweist nicht, dass die gesamte Historie diesen Text nicht enthält. Forks verwenden ihre kopierte Historie und neue IDs. Zuweisungen von Zugangsdaten werden in Auszügen geschwärzt.

mcp_tool_discovery hält eingebaute Tools verfügbar und führt tool_search für verbundene MCP-Tools ein. Eine Suche liefert bis zu fünf passende Schemata und macht diese Tools bei der nächsten Modellanfrage verfügbar. sie führt sie nicht aus. Auswahlen gelten für die Sitzung, sind auf 32 Tools begrenzt und werden bei jeder Anfrage mit der aktuellen Zulassung geschnitten. Große Schemata können im Suchergebnis fehlen und bei der nächsten Anfrage geladen werden. Wenn tool_search abgelehnt wird, bleibt der gewöhnliche zugelassene MCP-Katalog verfügbar. Ein kollidierendes vorhandenes Tool namens tool_search erzeugt einen Fehler.

tail_reminders verschiebt nur die von AX Code erzeugten dynamischen Rundenerinnerungen an das Ende der Anbieteranfrage. Gespeicherte Benutzernachrichten, Schlussfolgerungen des Assistenten, Toolhistorie und statische Anweisungen bleiben unverändert. Das kann Modellverhalten und Cache-Nutzung ändern. Es belegt für sich genommen keine Geschwindigkeitsverbesserung.

read_only_recipes stellt read_recipe bereit. Es führt bis zu acht abhängige Aufrufe von read, glob oder grep über den normalen Tool-Dispatcher aus. Jedes Kind hat eigene Berechtigungsprüfungen, Hooks, Abbruch und Sitzungsnachweise. Ein Rezept kann keinen Code auswerten, keine Shell-Befehle ausführen, keine Dateien schreiben, keine MCP-Tools aufrufen und kein weiteres Rezept verschachteln.

{
  "steps": [
    { "id": "files", "tool": "glob", "parameters": { "pattern": "src/**/*.ts" } },
    {
      "id": "source",
      "tool": "read",
      "parameters": { "filePath": { "$ref": { "step": "files", "path": ["paths", 0] } } }
    }
  ],
  "select": [{ "step": "source", "path": ["text"] }]
}

Kanonische Glob-Ergebnisse enthalten paths und truncated. Grep-Ergebnisse enthalten matches mit path, line und text. Leseergebnisse enthalten kind, gerendertes text und truncated. Wählen Sie ein früheres Ergebnis über seinen Schritt und den Pfad einer eigenen Eigenschaft. Array-Auswahlen unterstützen einen literalen Filter contains und limit. Prüfen Sie den zurückgegebenen Status und die Kürzung. Das Rezept hat eine Abbruchfrist von 60 Sekunden, ein Argumentbudget von 32 KB, ein Zwischenbudget von 192 KB und eine begrenzte Endausgabe. Der Abbruch wartet, bis das eigene Tool zur Ruhe kommt. Neue Repository-Anweisungen oder Medien pausieren die Ausführung und behalten die normale Kindausgabe, damit das Modell sie sieht, bevor es fortfährt. Erfolgreiche Auswahlen ersetzen Zwischenausgaben nur in der Modellanfrage. Die ursprünglichen Kinddatensätze bleiben in der Historie. Unterbrochene Eltern behalten die Kindausgabe.

Eine laufende Erzeugung korrigieren

GET /session/{sessionID}/steering liefert die UUID der aktiven Erzeugung und jüngste Belege. Fügen Sie den vorhandenen Abfrageparameter directory hinzu, wenn Sie ein Projekt über den HTTP-Server auswählen.

Senden Sie POST /session/{sessionID}/steering mit:

{
  "expectedGeneration": "00000000-0000-4000-8000-000000000001",
  "clientID": "correction_1",
  "text": "Preserve the existing public function signature."
}

Verwenden Sie die UUID aus GET, nicht die Beispiel-UUID. accepted bedeutet, dass die Korrektur aussteht. applied bedeutet, dass sie an einer Schleifengrenze als Benutzernachricht geschrieben wurde und ihre Nachrichten-ID enthält. Es garantiert nicht den Abschluss beim Anbieter. rejected bedeutet, dass sie nicht angewendet wurde. Lebenszyklus-Hooks können die Zulassung ablehnen. Eine angenommene Korrektur verlängert eine Erzeugung, die kurz vor dem Abschluss stand, um eine weitere Iteration, sodass eine an der Ziellinie gesendete Korrektur angewendet statt abgelehnt wird. Abbruch und Fehler lehnen ausstehende Korrekturen weiterhin ab, und eine alte Erzeugung kann ihrem Nachfolger keinen Text zuführen. Identische Wiederholungen liefern denselben behaltenen Beleg. Abweichender Inhalt unter einer vorhandenen Client-ID liefert HTTP 409. Die TUI-Geste ctrl+s zum sofortigen Senden verwendet diesen Endpunkt.

Parallele Toolaufrufe in einem Schritt

Wenn das Modell mehrere Toolaufrufe in einer Assistentennachricht ausgibt, führt die Laufzeit sie gleichzeitig über ein sitzungsbezogenes Lese- und Schreibgatter aus. Nur-Lese-Tools teilen sich die Spur und überlappen sich. Dateibearbeitungen, bash, bash_input, Notebook-Bearbeitungen, ops_apply, MCP-Tools und jedes batch, das ein nicht nebenläufigkeitssicheres Kind enthält, nehmen die exklusive Spur und laufen allein in Ankunftsreihenfolge. Ein Aufruf, der während des Wartens abgebrochen wird, läuft nie. Batch behält eine eigene Reihenfolgesperre für die Aufrufe, die es versendet, und Kindersitzungen haben ein eigenes Gatter.

Belege sind prozesslokal, mit höchstens 256 je Sitzung und 32 ausstehenden Anfragen. Abschließende Belege und Einträge inaktiver Sitzungen können verdrängt werden. Holen Sie nach einem Neustart die neue Erzeugung und gleichen Sie gespeicherte Nachrichten ab. Diese API verspricht keine dauerhafte Belegsuche über Neustarts hinweg. Das erzeugte SDK stellt session.steering und session.steer bereit.

Eine gespeicherte Folge in die laufende Runde lenken

POST /task-queue/{taskID}/steer lässt den Text einer eingereihten Folge an der nächsten Schrittgrenze in die laufende Erzeugung der Sitzung ein — derselbe Lieferpunkt wie POST /session/{sessionID}/steering — und bricht die Warteschlangenzeile in derselben Anfrage ab. Dabei werden steeredInto (die Erzeugungs-UUID) und steeredAt zur Prüfung auf der Zeilennutzlast aufgezeichnet. Nur-Text-Folgen bis 16.000 Zeichen lassen sich lenken. Der gelenkte Text übernimmt Agent, Modell und Tools der laufenden Runde. Anhänge, Arten, die keine Folge sind, abgeschlossene Zeilen und übergroßer Text werden mit HTTP 400 abgelehnt, und eine Zeile, die während der Anfrage in einen anderen Status wechselt, liefert HTTP 409.

Die Antwort trägt das jüngste Warteschlangenelement und einen nullbaren Beleg. Wenn keine Erzeugung aktiv ist, bleibt die Zeile unberührt, und die Antwort meldet generation_not_active mit einem Null-Beleg. Aufrufer können dann auf POST /task-queue/{taskID}/send-now zurückfallen, das die Zeile nur an den Anfang der Warteschlange verschiebt und weiterhin auf das Ende der Runde wartet. Eine gelenkte Zeile lässt sich nicht rückgängig machen, bleibt aber als cancelled in der Historie /queue mit ihren Prüffeldern sichtbar.

In der TUI lenkt die Tastenbindung input_submit_steer (Standard ctrl+s) den getippten Entwurf, wenn einer vorhanden ist. Bei leerem Eingabefeld über einer beschäftigten Sitzung befördert sie stattdessen das lenkbare Präfix der gespeicherten Warteschlange in FIFO-Reihenfolge und stoppt bei der ersten nicht lenkbaren Zeile, sodass spätere Folgen ihr nie vorausspringen. Der Abschnitt Folgen in der Seitenleiste und der Dialog /queue bieten dieselbe Aktion zum sofortigen Lenken je Zeile, und ein Hinweis bei eingereihten Folgen zeigt die gebundene Taste. Das erzeugte SDK stellt taskQueue.steer bereit.

Einen Skill aus geprüfter Arbeit vorschlagen

Skill-Kandidaten sind ausdrückliche Datensätze im vorhandenen lokalen Speicher von AX Code. sie gelangen erst in die Skill-Entdeckung, wenn Sie sie befördern, und lösen nie einen automatischen Modellaufruf oder eine Umschreibung von Anweisungen aus.

Erzeugen Sie eine Vorschlagsdatei in JSON mit name, description, applicability, procedure und evidence, das sessionID, messageID und partID enthält. Nachweise müssen ein ursprüngliches erfolgreiches Ergebnis verify_project mit ausgeführten Umschlägen für Tests oder Typprüfung gegen die aktuelle saubere Git-Revision benennen. Ein Erfolgssatz oder ein beliebiger Shell-Exit genügt nicht. Die Validierung muss eine erfolgreiche Prüfung einer anderen Sitzung bei derselben Revision zitieren.

ax-code skill candidate propose --proposal proposal.json
ax-code skill candidate show verified-procedure
ax-code skill candidate validate verified-procedure --proposal independent-evidence.json
ax-code skill candidate promote verified-procedure
ax-code skill candidate retire verified-procedure

Halten Sie die Eingabe-JSON außerhalb des Worktrees oder in einem ignorierten lokalen Verzeichnis, damit die Prüfung der sauberen Revision sinnvoll bleibt. Die Beförderung erzeugt .ax-code/skill/{name}/SKILL.md, ohne einen vorhandenen Skill zu überschreiben. Quellnachweise werden vor der Beförderung erneut geprüft. Symbolisch verlinkte Verzeichnisse werden abgelehnt. Die Außerbetriebnahme entfernt nur die eigene unveränderte Datei des Kandidaten. Manuelle Bearbeitungen verursachen einen Konflikt. Starten Sie eine vorhandene Laufzeitinstanz neu, um ihre zwischengespeicherte Skill-Entdeckung zu aktualisieren. Bestandene Prüfungen belegen Nachweise für genau diese Prüfungen. Prüfen Sie die Anwendbarkeit des Verfahrens vor der Beförderung.

Ein zugeordnetes Experiment erfassen

Verwenden Sie aus einer Quellarbeitskopie:

pnpm --dir packages/ax-code exec tsx script/harness-eval.ts run /path/to/manifest.json > /path/to/runs.ndjson
pnpm --dir packages/ax-code exec tsx script/harness-eval.ts compare /path/to/runs.ndjson baseline candidate

Das vertrauenswürdige Betreibermanifest enthält ein ausdrückliches provider/model, runtimeRevision, optionales CLI-Argv command, repetitions, timeoutMs, genau zwei benannte arms und tasks. Jeder Arm hat optionale features (die experimentellen Flags oben) und toolProfile. Jede Aufgabe liefert id, prompt, eingebettetes files (path/content) und ein oracle. Das Orakel ist vertrauenswürdiges JavaScript, das Node ausführt, nachdem der Coding-Prozess endet. process.argv[1] benennt das temporäre Fixture. Sein Code bleibt außerhalb des Arbeitsbereichs des Agenten und stammt nie aus der Modellantwort.

Jeder Versuch erhält ein frisches Git-Fixture. Das Orakel muss auf dem anfänglichen Fixture mit Exitcode 1 fehlschlagen. Der Runner verwendet einen festen Aufruf der Headless-CLI, wechselt die Armreihenfolge zwischen Wiederholungen, wendet eine Zeitüberschreitung an und führt das Orakel nach einem abgeschlossenen Versuch erneut aus. elapsedMs umfasst den Coding-Prozess und die Prüfung nach dem Lauf. verificationMs kennzeichnet Letzteres getrennt. Die Fixture-Einrichtung und die anfängliche fehlschlagende Prüfung sind ausgeschlossen. Der Strom zeichnet jeden abgeschlossenen, fehlgeschlagenen, zeitüberschrittenen oder abgebrochenen Versuch auf, sobald er endet. Rohe Prompts, Ausgabe von Subprozessen und Zugangsdaten werden in Auswertungsdatensätzen nicht ausgegeben. Eine unterbrochene Kohorte bleibt unvollständig und kann keinen zugeordneten Vergleich erzeugen.

Der Vergleich lehnt Duplikate sowie fehlende oder nicht passende Paare aus Aufgabe, Modell, Kohorte und Wiederholung ab. Fehlgeschlagene und ungeprüfte Versuche bleiben in den Nennern der Erfolgsquote. Mediane der Latenz und gepaarte Verhältnisse sind ausdrücklich an geprüften Erfolg gebunden. P95 verlangt 20 erfolgreiche Beobachtungen in einer Zelle aus Aufgabe, Modell, Kohorte und Arm. Aggregate gemischter Zellen lassen es weg. Die Kohorte hasht das Manifest, aber Laufzeitrevision sowie äußere Bedingungen von Anbieter, Konfiguration und Cache verlangen weiterhin die Kontrolle des Betreibers. Ein kleiner Probelauf kann keine allgemeine Geschwindigkeitsüberlegenheit belegen und rechtfertigt keine Änderung der Standards.

Auswahl der Fähigkeiten und Wiederherstellungsdiagnosen

Autonome Anfragen können ein Kontextpaket für lange Agenten enthalten, wenn das Modell mindestens 64.000 Token Kontext, Unterstützung für Schlussfolgerungen und Unterstützung für Tools hat. Bei Modellen ohne Registereintrag müssen alle drei Punkte in den aufgelösten Modellmetadaten erklärt sein. Das Zusatzpaket hat eine Obergrenze der Zeichenschätzung von 2.048 Token. Es ist nicht das Gesprächsfenster. Ausdrückliche negative Erklärungen und registrierte Einschränkungen verhindern die Zulassung. Diese Optimierung des Prompttexts belegt keine Kompatibilität von Cache oder bewahrtem Denken und ändert nicht die automatischen Fristen und das Tempo von Super-Long. Diese behalten ihre vorhandenen Regeln für Qualifikation und Überschreibung.

Zwei aufeinanderfolgende strukturierte Toolfehler nach der jüngsten Benutzernachricht (gezählt vor synthetischen Enderinnerungen) verlangen beim nächsten Modellaufruf eine tiefere Schlussfolgerung, wenn eine nutzbare Variante der Anstrengung existiert. Ein erfolgreiches Toolergebnis setzt die Zählung zurück. Ausdrückliche Anstrengung des Benutzers und konfigurierte Optionen der Schlussfolgerung behalten Vorrang. Das ändert die Auswahl der Anstrengung, nicht die Wiederholungsgrenzen oder die Toolberechtigungen.

Lokale Wiedergabeereignisse von llm.request enthalten capabilityResolution: Protokoll, Kontextfenster, ob ein Kontextpaket oder der Modus Super-Long gewählt wurde, aufeinanderfolgende Toolfehler sowie die Auswahl der Schlussfolgerung oder einen Grund, warum sie nicht angewendet wurde. boundary: "policy-selection" beschreibt die Entscheidung von AX Code. Plugins und Anbieter-SDKs können die endgültige Anfrage weiterhin ändern. Ausdrückliche Aufwandswerte von GPT-6 bleiben erhalten. Die API verlangt low oder höher statt none oder minimal. Das Ereignis behält Anfrage-Hashes statt Körper von Prompt oder Zugangsdaten. Eine fehlende Variante der Anstrengung bedeutet nicht, dass das anbieterseitige Standarddenken deaktiviert ist.

Die gepaarte Harness-Erfassung liest die JSON-Ereignisse step_finish und tool_use der CLI für Token von Eingabe, Ausgabe, Schlussfolgerung und Cache-Lesen, für abgeschlossene Toolaufrufe und für Toolfehler. Doppelte Teil-IDs zählen einmal. metricsStatus ist observed, partial oder unavailable. Gekürzte oder fehlerhafte Ströme und unterbrochene Versuche halten Summen zurück. Vergleiche melden für jede Metrik die Zahl beobachteter und fehlender Läufe sowie den Median, einschließlich fehlgeschlagener Versuche, soweit Beobachtungen existieren. Fehlende Werte bleiben fehlend. Diese Zähler beschreiben ausgegebene Laufzeitereignisse, nicht die Abrechnung des Anbieters, die Nutzung von Kindersitzungen oder native interne CLI-Tools. Ein vollständig beobachteter Strom ohne abschließende Toolereignisse meldet null Toolaufrufe. Die Prüfung durch das Orakel bleibt die Quelle des Aufgabenerfolgs. Nutzung allein belegt keine erfolgreiche Wiederherstellung und keine bessere Qualität.