Sie lassen die Tastatursteuerung prüfen und bemerken dann, dass die nächste Version auch Touch-Eingaben unterstützen muss. Die Steuerung laufender Aufgaben in GPT-6 Astra ist für solche Änderungen gedacht. Eine unterstützte Integration kann Folgearbeit neu ausrichten, aber keine abgeschlossene Bearbeitung oder bereits gesendeten Werkzeugaufrufe verschwinden lassen.
Dieser Leitfaden beruht auf Dokumentation. Die Beispiele sind vorgeschlagene Anwendungsentwürfe, keine mit einem kostenpflichtigen API-Konto ausgeführten Demonstrationen.
Kurzüberblick
Das Wichtigste
- Eine neue Anforderung macht abgeschlossene Aktionen nicht rückgängig.
- Verfolgen Sie geplante, laufende und abgeschlossene Arbeit getrennt.
- Prüfen Sie Freigaben erneut, wenn sich Aktion oder Ziel ändern.
Was die Steuerung während der Ausführung verändert
Die offizielle Dokumentation zur Aufgabensteuerung beschreibt GPT-6 Astra über eine WebSocket-Verbindung zur Responses API. Sie unterscheidet ausdrücklich zwischen Neuausrichtung und Rücknahme: Bereits gelieferte Ausgaben werden nicht umgeschrieben und gestartete Werkzeuge nicht automatisch abgebrochen.
Die Oberfläche muss diesen Unterschied zeigen. „Anforderung ändern“ und „Vorgang stoppen“ benötigen verschiedene Bedeutungen. Ändert sich ein Ziel während eines externen Schreibvorgangs, darf die Anwendung nicht davon ausgehen, dass dieser nie stattgefunden hat.
Eine gute Statusmeldung zeigt offene und abgeschlossene Arbeit. „Die neue Anforderung gilt für die nächste Arbeit“ ist klarer als ein stiller Austausch der ursprünglichen Anfrage, bei dem Nutzer die zuletzt geltenden Anweisungen erraten müssen.
Die Ereignisfolge nachvollziehen
Streaming zeigt Ausgaben beim Eintreffen. Aufgabensteuerung ändert die Anweisungen für Folgearbeit. Ein Produkt kann das eine anbieten, ohne das andere zugänglich zu machen.
Im dokumentierten WebSocket-Ablauf beginnen Sie mit response.create und warten auf response.created. Senden Sie auf derselben Verbindung response.steer mit der Antwort-ID als previous_response_id und der neuen Anweisung als input. response.steer.accepted bestätigt die Aufnahme in die Warteschlange, nicht den Abschluss der geänderten Arbeit. Fehlende Werkzeugresultate oder Freigaben meldet response.steer.pending. Verfolgen Sie die Fortsetzung getrennt von der ursprünglichen Antwort.
Eine normale Nachricht nach dem Abschluss ist ebenfalls etwas anderes als eine Änderung während einer laufenden Antwort. Unterscheiden Sie diese Wege in Protokollen, damit sich die Aufgabe rekonstruieren lässt.
Der Leitfaden zu GPT-6 Astra nennt diese Steuerung als neue Arbeitsfunktion. Daraus folgt nicht, dass jedes Chatfenster oder jede Drittanwendung die nötigen Ereignisse verarbeitet. Prüfen Sie die Oberfläche, nicht nur den angezeigten Modellnamen.
Trennen Sie in der Anwendung „Änderung empfangen“ von „Neue Arbeit abgeschlossen“. Zeigen Sie die aktuelle Anforderung neben dem noch laufenden Vorgang. Das ist ein Gestaltungsvorschlag, keine Behauptung, die API liefere eine vollständige Aufgabenübersicht.
Nützliche Arbeit bei einer Änderung erhalten
Eine hilfreiche Aktualisierung sagt, was sich ändert, was bleibt und was als Nächstes nicht passieren darf.
Zum Beispiel: „Behalte das Desktop-Layout. Konzentriere die nächste Überarbeitung auf Touch-Steuerung. Veröffentliche oder ersetze den aktuellen Build nicht.“ Das erhält brauchbaren Kontext und begrenzt den nächsten Schritt.
„Mach es anders“ zwingt den Assistenten zu raten, ob ein neues Ziel, eine visuelle Änderung oder ein Stopp gemeint ist. Die Oberfläche kann das aktive Ziel anzeigen und konkrete Anforderungen bearbeiten lassen.
Widerspricht die Änderung abgeschlossener Arbeit, benennen Sie den Konflikt. Eine Korrektur bleibt eine neue Handlung mit eigenem Umfang und eigenen Folgen.
Prüft ein Assistent die Tastatur eines Prototyps und kommt eine mobile Anforderung hinzu, lautet die hilfreiche Anweisung: „Behalte das Spielziel, prüfe als Nächstes Touch-Eingaben und ändere das Tastaturverhalten nicht.“ „Alles neu machen“ ist weniger präzise.
Frühere Beobachtungen können weiterhin nützlich sein. Neue Tests sollten Berührungsflächen, versehentliche Mehrfacheingaben, Ausrichtungswechsel und konsistentes Feedback für dieselbe Aktion abdecken. Das sind Vorschläge, keine gemessenen Astra-Ergebnisse.
Probieren Sie zur Konkretisierung Arcade-Spiele aus und beobachten Sie Tippen, Gedrückthalten und schnell wiederholte Aktionen. Verwenden Sie die Beobachtungen für den nächsten Prüfauftrag, ohne daraus ein verwendetes Modell oder überhaupt einen Modelleinsatz abzuleiten.
| Teil der Änderung | Beispielanforderung |
|---|---|
| Erhalten | Desktop-Steuerung und Spielziel beibehalten. |
| Ändern | Als Nächstes Berührungsflächen und wiederholtes Tippen prüfen. |
| Begrenzen | Den aktuellen Build nicht bearbeiten, hochladen oder veröffentlichen. |
| Berichten | Weiterhin gültige frühere Erkenntnisse nennen. |
Ein Zustandsmodell für wechselnde Anforderungen
Halten Sie geplante, laufende und abgeschlossene Arbeit in den Aufzeichnungen auseinander.
Die Tabelle unterstützt die Anwendungsgestaltung und ersetzt keine API-Ereignisreferenz. Sie verhindert, jede Aufgabe wie einen beliebig editierbaren Absatz zu behandeln.
Ordnen Sie Werkzeugergebnisse ihrem ursprünglichen Vorgang zu. Ein spätes Ergebnis darf nicht wie ein Nachweis unter neuen Anforderungen wirken. Auch veraltete Ergebnisse können aufbewahrt werden müssen, obwohl sie für die nächste Entscheidung ungeeignet sind.
Beispiel: Eine Leseoperation startet unter A, danach trifft Anforderung B ein, dann das alte Ergebnis. Speichern Sie es unter A und prüfen Sie, ob es auch B beantwortet. Etikettieren Sie es nicht als neue Prüfung. Ein Ergebnis zur Tastatur belegt keine funktionierende Touch-Steuerung.
| Zustand | Beispiel | Reaktion auf neue Anforderungen |
|---|---|---|
| Geplant | Eine vorgeschlagene Bearbeitung hat noch nicht begonnen | An neuer Anforderung messen |
| Laufend | Ein Werkzeugaufruf wurde gesendet | Ergebnis verfolgen und weitere Brauchbarkeit prüfen |
| Abgeschlossen | Eine Datei wurde geändert oder eine Ausgabe geliefert | Wirkung berichten und bei Bedarf separat korrigieren |
Änderungen durch die Anwendung kontrollieren
Das Modell sollte nicht die einzige Sicherung zwischen einer unklaren Änderung und einem folgenreichen Vorgang sein. Die Anwendung kann Schreibvorschläge sammeln, wichtige Schritte freigeben lassen und prüfen, ob die Freigabe noch zur aktuellen Aufgabe passt.
Wurde das Hochladen eines Entwurfs freigegeben und dann das Zielprojekt geändert, darf die alte Freigabe nicht still übertragen werden. Prüfen Sie Ziel und Inhalt erneut.
Das gilt auch für externe Nachrichten, Käufe, Löschungen und Bereitstellungen. Die Neuausrichtung hilft beim Verständnis des geänderten Ziels; sie bietet kein Transaktionssystem und keine Rücknahmegarantie.
Bei Leseoperationen führt ein spätes Ergebnis meist zu unnötiger Arbeit oder Verwirrung. Bei Schreiboperationen kann sich ein realer Zustand ändern. Entwerfen und testen Sie beide Fälle getrennt.
Änderungen zu ungünstigen Zeitpunkten testen
Die folgenden Fälle sind ein vorgeschlagener Integrationstestplan. Sie wurden für diesen Artikel nicht ausgeführt.
Legen Sie jeweils sichtbaren Status, Zulässigkeit einer neuen Aktion und Abschlussprotokollierung fest. Bewerten Sie konsistentes Verhalten, nicht nur die Bestätigung der Nachricht durch das Modell.
- Die Änderung kommt vor dem Start eines Werkzeugs.
- Sie kommt während einer Leseoperation.
- Sie kommt während eines bereits laufenden Schreibvorgangs.
- Zwei Änderungen enthalten widersprüchliche Anforderungen.
- Die Verbindung bricht vor der sichtbaren Bestätigung ab.
- Ein spätes Werkzeugergebnis gehört zu einer älteren Aufgabenversion.
Den nächsten Schritt sichtbar machen
Eine verlässliche Steuerung zeigt das aktuelle Ziel, abgeschlossene Arbeit und die nächste Aktion, die auf Erlaubnis wartet. Nutzer sollten das nicht aus einem langen Verlauf ableiten müssen.
Der praktische Nutzen besteht in weniger vermeidbaren Neustarts, nicht in unbegrenzter Autonomie. Halten Sie Änderungen überprüfbar und protokollieren Sie den tatsächlichen Ablauf ehrlich.
Für einen neuen Interaktionsauftrag können Sie die Spielebibliothek erkunden und eine Steuerungsfunktion auswählen. Halten Sie den Umfang so klein, dass Änderungen präzise formulierbar bleiben: Was bleibt, was ändert sich, was wartet auf Freigabe?
Quellen und weiterführende Literatur
- Offizielle Dokumentation zur Aufgabensteuerung
WebSocket-Ereignisse und Grenzen, geprüft am 14. September 2026. Beispiele sind Entwürfe, keine ausgeführten Tests.
- Leitfaden zu GPT-6 Astra
Funktionskontext des Modells, kein Nachweis für Unterstützung in jeder Anwendung oder jedem Konto.
Nächster Schritt
