Astronomischer Agent Debuggen und Nachbesprechung
Lokalisiere das Symptom auf den frühesten fehlgeschlagenen Vertrag, repariere die notwendige Schicht und beweise dann separat korrekte Ausführung, funktionierenden Mechanismus und tatsächlichen Nutzen. Die drei Schlussfolgerungen werden unabhängig erfasst.
Dieses Skill wurde aus lesbaren historischen Materialien des Projekts „AstroAgent“ destilliert. Fallbeispiele sind diagnostische Hinweise und bedeuten nicht, dass die aktuelle Implementierung zwangsläufig die gleichen Fehler aufweist. Historische Budgets, Knoten, Daten, Kartennamen und Bestehensgrenzen können nicht als Standardkonstanten für neue Aufgaben übernommen werden.
Identität feststellen
Bestätige, ob das Ziel Fehlerbehebung, Diagnose, äquivalente Beschleunigung, Strategieverbesserung oder die Auslieferung einer Reparatur ist. Lokalisiere den tatsächlichen Pfad und die aktuelle Version, überprüfe CURRENT, eingefrorene Listen, Quittungen und endgültige Pakete; die Identität basiert auf dem Hash von Quellcode, Eingaben, Konfiguration und Ergebnissen.
Erfasse die Version des offiziellen Protokolls/Bewertungssystems, online sichtbare Felder, initialize-Einschränkungen, Ausführungsmodus, CPU-Kalibrierung und unabhängige Wanduhrzeit-Begrenzungen. Nur wenn ein allgemeiner Website-Fehler oder eine gleichnamige lokale Karte vorliegt, ist die Cloud-Ursache noch nicht gefunden.
Unterscheide zwischen vollständig gültig, Budget abgelaufen, technischer Fehler, Benutzerunterbrechung, Diagnose abgeschlossen aber wissenschaftliches Gate nicht bestanden. Einige saisonale Punktzahlen gehen nicht in das vollständige Saison-Ranking ein; fehlende Werte bleiben null.
Referenzen nach Symptom lesen
- Ungültige Aktion, Start/ABI/manifest/ZIP, Datenzählung, Backup-Bereinigung: Lies protocol-and-data.md.
- Viele Zuweisungen aber niedrige Punktzahl, Nullpunktzahl, fehlende Reparaturmeldung, REQ/Anfrage fehlt, Wiedergabe-Divergenz: Lies state-and-physics.md.
- Timeout, Modell ohne Nutzen, Diagnose beschleunigt aber ganze Saison unverändert, Holdout/Abnahme fehlgeschlagen: Lies budget-and-experiments.md.
- Historische Gegenbeispiele und Reparaturbelege suchen: Lies casebook.md; Originaldatei-Identität prüfen: Lies evidence.md und corpus-index.tsv.
Früheste Abweichung finden
Vergleiche entlang des tatsächlichen Datenflusses: Eingabe/Einschränkungen → Verbrauchte Nachrichten → Zustand/Cache → Kandidaten-Eintritt → Vollständige Punktzahl/Zuweisung → Endgültige Aktion → Offizielle Ausführung → Feedback-Abrechnung.
Finde die erste Abweichung ab dem minimalen Fehlerzustand oder der unveränderlichen Trajektorie bei gleicher Eingabe. Speichere Erwartung, Ist-Wert, Einheit, Nenner, Stichprobenauswahl und Quelle. Markiere Quellcode-Reproduktion, Log-Verknüpfung, Mechanismus-Hypothese und Nutzenbelege separat.
Korrigiere zuerst Protokoll-, Identitäts- und Wiedergabeverunreinigungen, bevor wissenschaftliche Unterschiede erklärt werden. Eine originalgetreue Wiedergabe reproduziert die ursprüngliche Verbrauchsreihenfolge; das Ändern des historischen Verhaltens ist ein neuer Kandidat und darf nicht in die ursprüngliche Trajektorie gemischt werden. Wenn Initialisierung oder wichtige Nachrichten fehlen, stoppe an der erkennbaren Grenze und erfinde keine verborgenen Zustände.
Minimal falsifizierbaren Kontrollversuch entwerfen
Eine Hypothese benötigt einen Test, der sie widerlegen kann. Synthetische Fixtures testen Grenzen, öffentliche Zustands-Schatten testen Eintritts- und Auswahlmechanismen, vollständig gepaarte Saisons testen die Gesamtleistung, unabhängige Holdouts testen eingeschränkte Verallgemeinerung; jede Schicht unterstützt nur ihre eigenen Schlussfolgerungen.
Liste die relevanten beibehaltenen Elemente auf: Physik/Bewertung, öffentliche Informationen, RNG, Nachrichtenreihenfolge, Hauptbuch, native ABI, Kandidaten-/Tie-Reihenfolge und Abrechnung. Äquivalente Beschleunigung, die Aktionen oder Kandidatenmengen ändert, wird als Strategieänderung neu klassifiziert.
Strategiekandidaten werden zuerst daraufhin verfolgt, ob sie in die tatsächliche Kandidatenkette gelangen, präzise berechnet werden, die Abschlussschutzbedingungen erfüllen und die Ausführungswahl ändern; falls das vorgesehene Mechanismus-Gate nicht bestanden wird, wird die Hypothese geschlossen. Protokollreparaturen werden mit echten Grenzfällen als Gegenbeispiel abgenommen; es wird nicht verlangt, dass normale Karten ihre Aktionen ändern.
Eingeschränkte Validierung durchführen
Bewertung und entfernte Modelle verwenden die aktuelle Autorisierung und das begrenzte Budget, nicht die verbleibenden Mittel abgeschlossener Forschungen. Wähle basierend auf der Änderung sinnvolle Grenzen, Differenzen und normale Kontrollen.
Wenn das Projekt einen Logger verwendet, bestätige vor dem Start den geplanten Erfolg, lese die Identität zurück, überprüfe Quell-/Eingabe-Hash und Ausgabeisolation; behandle Fehler zuerst, falls die Protokollierung fehlschlägt. Ausnahmen werden dennoch im finally-Block abgerechnet (tatsächliche Kosten und Anfrageanzahl). Technische Reparaturen behalten die fehlgeschlagene übergeordnete Version mit einer Unterversion; nachträgliche Protokollierung wird mit „retrospective“ gekennzeichnet.
Vergleiche den endgültigen Quellcode mit gleicher Quelle, gleicher Eingabe und gleicher Abrechnung AUS/EIN. Nach Quellcodeänderungen verweise nur auf Belege, die noch mit diesem Quellcode übereinstimmen. Berichte die vorgeschriebenen Gates einzeln: Vollständiger Endzustand, Budget, REQ, Anfrage, Wissenschaft/Gesamtpunktzahl und angeforderte API-Rollen. Wenn ein erforderliches Gate fehlschlägt, ist die Abnahme nicht erfolgt.
Nach einem Fehlschlag wechsle zur neuen Ursachenhypothese mit neuen Belegen; Seed wechseln, Quellcode auswählen, Bestehensgrenze ändern oder Scan erweitern ist keine Reparatur der ursprünglichen Abnahme. Für Auswahl oder Diagnose verwendete Holdout-Sets werden zu Entwicklungsdaten; nachfolgende Verallgemeinerung verwendet neue Holdouts.
Ausgabe und Abschlusskriterien
Ausgabe nach Problemumfang in folgendem Format:
Symptom und erste Fehlerstelle:
Beweisstufe und Quellenidentität:
Ursache bestätigt / zu bestätigen:
Minimale Änderung und beibehaltene Elemente:
Ergebnis: Protokoll / Zustand / Mechanismus / Ganze Saison / Holdout / Bereitstellung
Fehlgeschlagene, nicht ausgeführte Elemente und Unsicherheiten:
Nächster Test zur Unterscheidung der Hypothesen:
Das hochgeladene Paket wird aus dem endgültig eingefrorenen Quellcode erstellt, in einem neuen Verzeichnis mit dem offiziellen manifest parser build/run gestartet, JSONL, Ressourcen und source/ZIP-Hash verifiziert. Mock, lokale native, echte API, Linux, Website werden separat gemeldet; sie ersetzen sich nicht gegenseitig.
Neue Erfahrungen müssen mit Anwendungsbedingungen, minimaler Reproduktion und Belegen versehen werden; es werden nur Regeln behalten, die tatsächlich Entscheidungen ändern.