Eine Fähigkeit zur Überprüfung und Reparatur des gesamten Codebestands, die die Arbeit über eine kostenabgestufte Agentenleiter verteilt – und sich weigert, sich vor dem exakten endgültigen SHA als fertig zu melden.
Ich habe die letzte Zeit damit verbracht, eine Codex-Fähigkeit zu entwickeln, die ein gesamtes Repository überprüft und die gefundenen Probleme behebt. Das Überprüfen war der einfache Teil. Der schwierige Teil war, sie davon abzuhalten, mir zu sagen, sie sei fertig, obwohl sie es nicht war.
Drei Dinge haben geprägt, wie es am Ende aussah.
Aufzählen ist keine Beurteilung. Zahle nicht denselben Preis für beides.
Das Auflisten verfolgter Dateien, das Erstellen eines Abdeckungsmanifests, das Ausführen eines Befehls und das Zurückgeben der Ausgabe – das ist Schreibtischarbeit. Bei einer Auditierung des gesamten Repositorys macht sie den Großteil der Tokens und fast keinen Anteil des Denkens aus, und sie an das Top-Modell zu leiten, ist für mich der schnellste Weg, richtig Geld für die Erzeugung einer Dateiliste auszugeben.
Also teilt die Fähigkeit die Arbeit in eine Leiter auf:
- ENUMERATE –
cheap. Alles auflisten, was existiert. Dateien, Module, Testabdeckung, der Diff gegen main, das Manifest dessen, was wir anfassen werden. Keine Meinungen. Keine Beurteilung. - REVIEW –
mid. Das Manifest durchgehen. Die Funde gruppieren. Für jedes Cluster den minimalen Patch und eine kurze Begründung entwerfen, die den Fehlermodus benennt, den er verhindert. - JUDGE –
nur Top-Tier. Jeden vorgeschlagenen Patch erneut gegen den Code lesen, den er betrifft. Genehmigen, ablehnen oder zur erneuten Aufzählung zurückschicken. Hier ist falsch zu liegen teuer, also verdient hier das teure Modell seinen Preis: Autorisierungspfade, Nebenläufigkeit und Abbruch, Transaktions- und Migrationssicherheit, Verträge, die Dateien übergreifen.
Die gestrichelte Schleife im Diagramm ist nicht dekorativ. Eine Ablehnung durch den Judge beendet den Lauf nicht – sie schickt die Arbeit mit engerem Umfang zurück zum Enumerator. repeat until the pass comes back clean ist der eigentliche Vertrag.
Codex-Sub-Agenten teilen sich ein Dateisystem.
Das war der Teil, der mich überrascht hat. Keine isolierten Kopien. Kein Merge-Schritt. Eine Schreibung durch einen Agenten ist für jeden anderen Agenten sofort sichtbar – einschließlich des nächsten, der gerade erzeugt wird.
Das verändert, wie man den Workflow entwerfen muss. Es bringt nichts, drei Reviewer jeweils das Repository klonen und ihren eigenen Diff erzeugen zu lassen; wer zuletzt schreibt, gewinnt, und die Arbeit der anderen löst sich einfach auf. Stattdessen behandelt die Fähigkeit den Working Tree als eine einzige gemeinsame Tafel: Enumerate schreibt das Manifest, Review liest es und hängt pro Cluster eine Patch-Datei an, Judge liest die Patches, wendet die genehmigten an und führt den Build erneut aus. Der Verifikationsschritt schließt die Schleife.
Die andere Konsequenz: Die Fähigkeit kann ihren eigenen Fortschrittsmarkierungen nicht vertrauen. „Ich habe 14 Patches angewendet" bedeutet nichts, wenn der nächste Agent sie überschreibt. Also stützt sich die Fähigkeit nicht auf Zähler oder „completed"-Markierungen, sondern koppelt den Abschluss an das Einzige, das tatsächlich bestehen bleibt: den exakten endgültigen SHA des Working Tree. Wenn der Judge freigibt, zeichnet der Lauf diesen SHA auf, und die nächste Aufrufung prüft den Tree dagegen, bevor sie fortgesetzt wird. Wenn der SHA nicht mit dem übereinstimmt, was der letzte saubere Durchlauf hinterlassen hat, beginnt der Lauf erneut ab der Aufzählung – nicht weil die Arbeit falsch war, sondern weil sich das Substrat darunter bewegt hat.
Die Statusabzeichen sind keine Stimmungen. Sie sind der SHA.
- READY FOR MERGE – der aufgezeichnete SHA stimmt mit dem aktuellen Tree-SHA überein, der Build besteht, und der Judge hat jeden Patch genehmigt.
- INCOMPLETE – es wurde Arbeit angewendet, aber entweder ist der Tree seit dem letzten sauberen Durchlauf abgewichen oder der Judge hat eines oder mehrere Cluster abgelehnt und zur erneuten Aufzählung zurückgeschickt.
- BLOCKED – die Schleife ist gelaufen und fehlgeschlagen; ein Cluster, das der Judge immer wieder ablehnt, oder ein Build, der nicht grün wird. Ein Mensch schaut es sich an.
Der ganze Punkt der Leiter war, das günstige Tier günstig zu halten, das teure Tier für die Stellen zu reservieren, an denen es seinen Preis verdient, und das Urteil von etwas abhängig zu machen, worüber das Dateisystem nicht lügen kann.