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

Lokaler Nachweiscache

Status: Speicher standardmäßig aktiv; RocksDB optional

Umfang: aktueller Stand

Zuletzt geprüft: 2026-09-13

Verantwortlich: AX-Code-Laufzeit

AX Code verwendet standardmäßig einen begrenzten Nachweiscache im Speicher, mit optionaler RocksDB-Persistenz neben dem vorhandenen SQLite-Speicher. SQLite behält die vollständige Sitzungshistorie und die Prüfdatensätze. Der Cache enthält wegwerfbaren gerenderten Text und syntaktische Symbole. Er ändert keine Berechtigungen und zählt nicht als frische Prüfung.

Der Standardspeichermodus öffnet keine RocksDB-Datenbank. Um in einer Quellinstallation Persistenz zu wählen, bauen Sie die native Unterstützung und wählen Sie RocksDB ausdrücklich:

pnpm build:native fs
AX_CODE_EVIDENCE_CACHE=rocksdb pnpm run dev

AX_CODE_EVIDENCE_CACHE=memory wählt ausdrücklich die standardmäßige begrenzte Wiederverwendung im Prozess ohne dauerhaften Speicher. Im RocksDB-Modus fällt fehlende native Unterstützung, eine von einer anderen Laufzeit gehaltene Datenbanksperre oder ein Cachefehler mit einer Diagnose auf den Speicher zurück. Standardbuilds des Dateisystem-Zusatzmoduls enthalten RocksDB für die ausdrückliche Wahl. Release-Builds prüfen, dass das gepackte Zusatzmodul seinen Cache schreiben und erneut öffnen kann. Native Operationen laufen außerhalb der JavaScript-Ereignisschleife.

Textlesevorgänge bis 1 MiB prüfen die aktuellen Quellbytes und verwenden den gerenderten Bereich wieder, wenn Inhalt, Pfad, Bereich und Format übereinstimmen. Größere Dateien, externe Lesevorgänge, Verzeichnisse und Anhänge gelangen nicht in den Lesecache. Repository-Anweisungen und Stempel von Dateilesungen bleiben live. Syntaktische Extraktion kann Symbole für identischen Quelltext und dieselbe Sprache wiederverwenden. Diese Symbole belegen keine semantischen Verweise oder Aufrufer.

In beiden Cache-Modi verwenden wiederholte vollständige Textleseergebnisse, die in der aktuellen Modellanfrage bereits sichtbar sind, einen kurzen Verweis auf das erste Ergebnis. Die ursprünglichen vollständigen Toolausgaben bleiben in der Sitzungshistorie. Die Kompaktierung baut die Sichtbarkeit neu auf. Ein späteres Lesen wird vollständig gerendert, wenn seine frühere Kopie fehlt. Wiederholte byteidentische seitenweise Lese-, Grep- und Glob-Ansichten können ebenfalls auf die erste vollständig zurückgegebene Ansicht verweisen. Jeder Verweis behält seine ursprüngliche Kürzungsfußzeile und die Fortsetzungsanleitung. Weggelassener Quellinhalt bleibt nicht verfügbar. Ergebnisse mit Anweisungen, Medien, Fehlern, zeilenweiser Kürzung und unerkannte Teilergebnisse bleiben wortgetreu. Das ändert die Modelleingabe, nicht die kanonische Historie oder die Toolausführung, und belegt keine Verringerung der Anbieterabrechnung.

Cache-Treffer sparen Rendern oder Parsen und ersparen keine prüfenden Quelllesevorgänge und keine vom Modell angeforderten Toolaufrufe. Um abhängige Entdeckung in weniger Modellrunden zu bündeln, aktivieren Sie ausdrücklich die vorhandene Option experimental.read_only_recipes und verwenden Sie read_recipe mit begrenzten Auswahlen. Verwenden Sie code_intelligence mit operation: "buildContext" für eine begrenzte strukturelle Übersicht. Keine der beiden Optionen wird vom Cache automatisch aktiviert.

Wenn er gewählt ist, liegt der dauerhafte Cache im gewöhnlichen Cache-Verzeichnis von AX Code unter evidence-v1, mit einer eigenen Datenbank je Projektinstanzverzeichnis. Die RocksDB-Zulassung ist auf 1024 Einträge und 32 MiB logischer Werte begrenzt. Der physische Plattenverbrauch umfasst außerdem Kodierung, Protokolle und Kompaktierungsaufwand. Beide Modi begrenzen die Wiederverwendung im Speicher auf 128 Einträge und 4 MiB serialisierter Werte je Projektinstanz und Prozess. Das ist keine Grenze für den gesamten Prozess-RAM. Speichereinträge werden beim Freigeben der Instanz gelöscht und überstehen das Prozessende nicht. Einträge verfallen nach 24 Stunden und werden beim Nachschlagen geprüft. Eine Kapazitätsverdrängung kann die wegwerfbaren nativen Einträge als Stapel löschen. Vorhandene SQLite-Daten werden weder migriert noch nachgefüllt.

Um sowohl die Speicherwiederverwendung als auch die Deduplizierung der Modelleingabe abzuschalten, setzen Sie AX_CODE_EVIDENCE_CACHE=off und starten Sie AX Code neu. Ein ungesetzter oder leerer Wert verwendet den Speicher. Ein nicht erkannter nicht leerer Wert deaktiviert den Cache. Starten Sie vorhandene Laufzeiten neu, um den neuen Standard anzuwenden, und entfernen Sie jede ausdrückliche Überschreibung rocksdb, um den Speicher zu verwenden. Vorhandene dauerhafte Cache-Dateien bleiben erhalten. Ein SQLite-Rollback ist nicht nötig. Stoppen Sie Laufzeiten, bevor Sie evidence-v1 von Hand entfernen. Entfernen Sie RocksDB-Sperrdateien nicht, während eine Laufzeit den Cache verwendet.

Für die lokale native Qualifikation nach dem Bau der Funktion:

cd packages/ax-code
AX_TEST_EVIDENCE_NATIVE=1 AX_TEST_FILES=test/evidence/cache-native.test.ts,test/evidence/cache-eval.test.ts pnpm exec vitest run --retry 0

Die Auswertung mit festem Fixture meldet angeforderte Lesevorgänge, Rendering-Treffer, weggelassene Ausgabebytes und vergangene Zeit getrennt. Die Auswertung ist kein Benchmark mit live Modell und keine Aussage über die Tokenabrechnung des Anbieters.

Wenn Sie ein Problem melden, geben Sie die AX-Code-Version, Betriebssystem und Architektur, die Ausgabe von ax-code doctor, ob off oder memory das Verhalten ändert, und wenn möglich eine reproduzierbare Aufgabe an. Doctor meldet den angeforderten Modus und die native Fähigkeit. Es kann nicht feststellen, ob ein anderer laufender Prozess den Projektcache besitzt. Der Rückfall bei Projektsperre oder E/A erscheint im Laufzeitprotokoll. Es wird kein Feedback und kein zwischengespeicherter Quellinhalt automatisch hochgeladen. Vorhandene veröffentlichte Binärdateien erhalten diese Vorgaben erst, nachdem eine aktualisierte Veröffentlichung installiert wurde.