OpenAI bietet Codex CLI Ein neuer Befehl namens /goal。
Man setzt ihm ein Ziel, und es läuft weiter, verliert über mehrere Runden nicht den Kontext und hört nicht auf, bis es sein Ziel erreicht hat.
Diese Funktion wurde mit der Codex CLI Version 0.128.0 veröffentlicht und ist noch experimentell und muss manuell aktiviert werden, wie Felipe Coury vom Codex-Team beschreibt:
“Halten Sie das Ziel über mehrere Runden hinweg aktiv. Wenn du es nicht erreichst, hörst du nicht auf.
nicht aufgeben, bis man sein Ziel erreicht hat
Und meiner Meinung nach verbirgt sich hinter dieser Funktion tatsächlich ein Trend:Im Zeitalter der KI wird der Prozess immer unwichtiger; was zählt, ist das Ziel.
01
Ralph Loop
verstehen. /goalSie müssen zuerst über Ralph Loop sprechen.
Der Name stammt von Ralph Wiggum, dem "ahnungslosen, hartnäckigen, optimistischen" Jungen aus Die Simpsons. Der Entwickler Geoffrey Huntley hat eine Agentenschleife nach ihm benannt: Setzen Sie ein Ziel für den Agenten, lassen Sie ihn sich selbst wiederholen, und wenn er scheitert, beginnen Sie von vorne, bis das Ziel erreicht ist.
VentureBeat schrieb sogar einen Artikel mit dem Titel "How Ralph Wiggum went from the Simpsons to the hottest name in AI".
In der ursprünglichen Implementierung der Gemeinschaft war der Ansatz von Ralph Loop etwas "gewalttätiger": Am Ende jeder Runde beginnt der Agent ein neues Kontextfenster von Grund auf und verlässt sich dabei auf Git-Protokolle und Fortschrittsdateien, um sein Gedächtnis am Leben zu erhalten.
Das ist so, als würde man bei jedem Schichtwechsel eine schriftliche Übergabe machen.
Und Codex's /goal hat dagegen einen anderen Weg eingeschlagen.
Es ist einEndlosschleife innerhalb eines Prozessesbleibt das Ziel über mehrere Runden in der gleichen Sitzung aktiv, ohne dass ein neuer Kontext von vorne begonnen werden muss.
Mit anderen Worten: Die Ralph-Schleife der Gemeinde ist wie ein Staffellauf, bei dem an jedem Staffelstab ein Neuankömmling steht.
Stafette vs. Marathon
Und Codex's /goalEr ist eher wie ein Marathonläufer, der vom Start bis zum Ziel läuft und eine Pause einlegen kann, wenn er müde wird, sich aber nicht verändert.
02
Wie zu verwenden
Die Verwendung ist einfach.
Vergewissern Sie sich, dass die Codex CLI-Version über 0.128.0 liegt, und geben Sie in der Konfigurationsdatei ~/.codex/config.toml Einen Absatz hinzufügen:
●●●
[features]
goals =true
└
Nach dem Öffnen geben Sie ihn in die Codex-CLI ein:
●●●
/goal 重构所有的数据库查询，添加连接池
└
Codex beginnt mit der Arbeit rund um dieses Ziel, schreibt Code, führt Tests durch, prüft die Ergebnisse, und wenn das Ziel nach einer Runde nicht erreicht ist, beginnt automatisch die nächste Runde.
Entgegennahme von Anweisungen.
Darüber hinaus gibt es mehrere Hilfsbefehle:
• /goal pauseUnterbrechen Sie das aktuelle Ziel.
• /goal resumeWiederaufnahme der ausgesetzten Ziele
• /goal clearFreigabeziele
Wenn Sie Strg+C drücken, um den Vorgang zu unterbrechen, wird das Ziel automatisch angehalten und beim nächsten Mal, wenn Sie den Thread wieder aufnehmen, automatisch fortgesetzt.
Ein praktischer Tipp: Wenn Ihre Zielbeschreibung zu lang ist, ist es möglicherweise falsch, sie direkt in den Befehl zu schreiben. Es ist möglich, die detaillierten Anweisungen in einem .md Datei, und verwenden Sie dann die /goal follow instructions.md durchzuführen.
Dies ist eine Technik, die ich schon vor langer Zeit immer wieder empfohlen habe, und die Aufnahme in eine Datei hat den zusätzlichen Vorteil, dass sie nicht durch den Kontext komprimiert wird und Details verliert.
Diese Version enthält auch eine /side können Sie vorübergehend eine Verzweigungssitzung öffnen, um Fragen zu stellen, ohne das Hauptziel zu unterbrechen. Wenn Sie fertig sind, drücken Sie Esc, um zum Hauptprogramm zurückzukehren, und die Verzweigungssitzung wird verworfen. Diese beiden Befehle funktionieren sehr gut zusammen.
Aber ...... sollte dies sein, um den Verdacht des Plagiats zu vermeiden. Claude Code, oder nennen Sie es einfach /btw, siehe: Claude Code fügt /btw-Funktion hinzu
03
Es wird nicht aufhören, aber es ist nicht dumm.
Die größte Sorge bei einem Agenten, der automatisch Schleifen durchläuft, ist: Wird er sich über bedeutungslose Dinge hinwegsetzen?
Die Umsetzung des Kodex umfasst eine Reihe von Schutzmechanismen.
Unterdrückung von Anrufen durch Null-Tools.Wenn der Agent während einer Fortsetzungsrunde keine Tools aufruft (keinen Code schreibt, keine Befehle ausführt, keine Dateien liest), stellt das System fest, dass es "feststeckt" und hält die Schleife automatisch an, bis neue Eingaben erfolgen.
Haushaltskontrolle.Jedes Ziel kann eingestellt werden token Budget und Zeitbegrenzung. Wenn der Verbrauch das Budget übersteigt, gibt das System eine Aufforderung an das Modell aus, keine neue Aufgabe zu starten, den Fortschritt zusammenzufassen und dem Benutzer einen klaren nächsten Schritt zu geben.
Roboterhund an drei Leinen
Ausfüllen von Prüfungsprotokollen.Zu Beginn eines jeden Durchlaufs injiziert das System eine versteckte Entwickleranweisung in das Modell und fordert es auf, eine Reihe von "Abschlussprüfungen" durchzuführen:
1. die Aufgliederung der Ziele in spezifische Leistungen
2. eine Checkliste zu erstellen, um jede Anforderung den tatsächlichen Nachweisen zuzuordnen
3. die Prüfung von realen Dokumenten, Outputs und Testergebnissen
4. man kann nicht davon ausgehen, dass ein Ziel erreicht wurde, nur weil "der Test bestanden wurde".
Das heißt, das System verhindert ein häufiges Problem bei Modellen auf der Ebene der Mechanismen:Verwechslung von "Ich habe etwas produziert" mit "Ich habe ein Ziel erreicht".。
Nur weil ein Test bestanden wurde, heißt das nicht, dass die Funktion vollständig ist, und nur weil der Code geschrieben wurde, heißt das nicht, dass die Anforderungen erfüllt sind. Diese "Proxy-Evidence-Akzeptanz" ist eine der heimtückischsten Fehlerarten in der Agentenschleife.
04
Quellcode-Analyse
Der Codex ist quelloffen, daher ist es einfach zu sehen, wie er implementiert ist. Ich habe den Code aktualisiert und die KI hat ihn für mich umgedreht.
Die Kernlogik der Funktion ist in codex-rs/core/src/goals.rs Im Fall von Rust sind es etwa 1.570 Zeilen Rust-Code.
Das gesamte System besteht aus drei Ebenen:
Persistente Schicht: Der Status des Ziels ist in der SQLite-Datenbank vorhanden und geht nicht verloren, wenn der Prozess neu gestartet oder der Thread wieder aufgenommen wird. Ziele haben vier Zustände: Aktiv, Pausiert, Budgetbegrenzt und Abgeschlossen.
Werkzeug-Ebene: Das System stellt dem Modell drei Werkzeuge zur Verfügung:get_goal(aktuelles Ziel lesen),create_goal(Schaffung von Zielen),update_goal(Zielstatus aktualisieren).
dreistufige Architektur
Das ist eine wichtige Designentscheidung:Das Modell kann ein Ziel nur als "abgeschlossen" markieren, es kann nicht unterbrochen oder fortgesetzt werden. Das Anhalten und Fortsetzen kann nur der Benutzer selbst vornehmen.
Die Logik im Quellcode lautet:
●●●
if args.status != ThreadGoalStatus::Complete {
return Err(FunctionCallError::RespondToModel(
"update_goal can only mark the existing goal complete"
));
}
└
Warum ist sie so konzipiert?
Damit soll verhindert werden, dass das Modell von sich aus "faul" wird und sich selbst eine Pause gönnt, wenn es das Gefühl hat, dass es fast fertig ist (ist das nicht eine Erfahrung?). .
Nachdem Sie sich ein Ziel gesetzt haben, wird das Modell es entweder erreichen oder Sie werden es aufgeben.
Es gibt keinen dritten Weg.
Die Schichten werden weiter ausgeführt: Dies ist der zentrale Teil. Am Ende jeder Runde führt das System eine Kette von Prüfungen durch:
1. ob die Zielfunktion aktiviert ist oder nicht
2. die Verfügbarkeit von derzeit aktiven Zielen
3. ob andere Runden durchgeführt werden
4. ausstehende Nachrichtenwarteschlangen
5. ob die Fortsetzung des Laufs verhindert wurde (keine Werkzeugaufrufe in der vorherigen Runde)
6. ob Sie sich gerade im Planmodus befinden (Ziele werden im Planmodus ignoriert)
Nachdem alle bestanden haben, sendet das System eine Entwicklermeldung, die eine Beschreibung des Ziels, die Verwendung des Budgets und die Protokolle für den Abschluss der Prüfung enthält. Dann beginnt eine neue Runde.
Es gibt noch ein kleines Detail:Bei der Token-Berechnung werden nur nicht zwischengespeicherte Eingabe-Token und Ausgabe-Token gezählt. Cache-Treffer werden nicht auf das Budget angerechnet. Das heißt, das Budget erfasst die "zusätzliche Arbeitslast", und es fallen keine Kosten für das erneute Einlesen von bestehendem Kontext an.
Der Entwickler dieser Funktion ist Eric Traut, der Autor von Pyright, dem Python Type Checker, den Felipe Coury als "einen der GOATs, mit denen man jeden Tag arbeiten kann" bezeichnet.
05
experimentelle Funktion
Ja, natürlich./goal Schließlich handelt es sich noch um eine experimentelle Funktion, die derzeit noch einige Einschränkungen aufweist.
Derzeit ist sie nur in der CLI verfügbar, die Codex-Desktop-App hat sie noch nicht.
Auch, wenn die API-Quote ausläuft./goal können in einer unangenehmen Schleife stecken bleiben BUG: Sie senden immer wieder Anfragen, erhalten immer wieder Fehler, wenn die Quote erschöpft ist, und versuchen es immer wieder ...... Einige Leute nennen dies die "Ralph-Schleife der Fehler".
Im Planungsmodus wird das Zielsystem automatisch ignoriert. Das heißt, Sie können nicht gleichzeitig planen und Ziele setzen; die beiden Modi schließen sich gegenseitig aus.
Das ist verständlich, das Ziel ist es, gute Ziele zu setzen, ein bisschen seltsam ......
Die derzeitige Beurteilung der Zielerfüllung leidet jedoch immer noch unter dem Problem des "vorzeitigen Abschlusses". Manchmal betrachtet das Modell ein Ziel als abgeschlossen, nur weil es ein Artefakt produziert, obwohl es nur die Oberflächenarbeit abgeschlossen hat.
06
Das Wichtigste: das Ziel.
/goal Der Umfang des Codes ist gering, und das Konzept ist nicht komplex. Aber es repräsentiert eine Richtung, die meiner Meinung nach wahrscheinlich sinnvoller ist als die meisten "großen Updates".
Denn es sind nicht die Grenzen der KI-Fähigkeiten, die sie verändert, es sind dieKollaborative Schnittstelle zwischen Menschen und KI。
Von "du sagst das eine und ich mache das andere" bis hin zu "du gibst das Ziel vor und ich bin für den gesamten Prozess verantwortlich".
Aus dem "Dialog" ist ein "Auftrag" geworden.
Der Wandel in der Denkweise vom Ende zum Anfang, der dahinter steht, ist mehr wert, darüber nachzudenken als die Funktion selbst.
Ich bin auch grundsätzlich weniger in den Prozess des Schreibens von praktischem Code in meiner eigenen Programmierung involviert. Ich verbringe mehr Zeit und Energie mit folgenden Fragen: Was genau will ich erreichen? Wie überprüfe ich, dass dieses Ziel auch tatsächlich erreicht wird?
Wie setzt man sich die richtigen Ziele, wie findet man heraus, was man genau tun will, um das Ziel zu erreichen?Dies ist die eigentlich prüfende und wichtige Beurteilung und Arbeit.
In der Vergangenheit waren wir an eine "prozessorientierte" Arbeitsweise gewöhnt: erst die Planung der Schritte, dann die schrittweise Ausführung, wobei die Mitarbeiter jeden Schritt überwachen.
Aber AI Agent stellt diese Logik auf den Kopf:Sie brauchen nur den Endpunkt zu definieren; der Pfad ist der des Agenten selbst.
Der Unterschied zwischen dieser und der traditionellen Programmierung ist wie der Unterschied zwischen einer Navigations-App und einer handgezeichneten Karte. In der Ära der handgezeichneten Karten musste man seine eigene Route planen und sich jede Kreuzung merken. Bei der Navigation muss man nur das Ziel eingeben. Welchen Weg man nimmt, wie man den Verkehr umgeht, wo man rechts abbiegt, das ist Sache der Navigation.
Prozessorientierung vs. Zielorientiertheit
Und Karpathy äußerte in seinem jüngsten AI Ascent-Vortrag eine ähnliche Einschätzung. Er fasste den Trend als Software 3.0 zusammen (siehe früheren Beitrag:Die Ära der Software 3.0 hat begonnen）：
“Während herkömmliche Software das automatisiert, was Sie spezifizieren können, automatisiert KI das, was Sie verifizieren können.
Der rote Faden in der Entwicklung der drei Generationen von Software-Paradigmen ist der Wandel in der Art und Weise, wie Menschen sich engagieren.
Vom Wie (der Maschine sagen, was sie tun soll) über das Zeigen (der Maschine zeigen, was sie tun soll) bis zum Was (der Maschine sagen, was man will).
Autor → Trainer → Kommandant
/goal was so etwas wie die letzte Fußnote zu diesem Thema ist.
Sie definieren das Ziel, also den überprüfbaren Endzustand. Der Agent findet den Weg selbst. Sie validieren das Ergebnis, er kümmert sich um den Prozess.
Wenn der Agent anfängt, seinen eigenen Fortschritt zu verwalten und die gesetzten Ziele tatsächlich erreichen kann, gibt es nur noch eine Sache, die der Mensch gut machen kann:
Finden Sie heraus, was Sie wirklich wollen.
◇ ◆ ◇
- Codex CLI Open Source Repository: https://github.com/openai/codex
- Originalbeitrag von Felipe Coury: https://x.com/fcoury/status/2049917871799636201
- Ralph Loop Community Realisierung: https://github.com/Th0rgal/open-ralph-wiggum
