APEX

Das Repository trennt den APEX-Verteidiger, die Normalisierung von Benchmark-Daten, vertrauenswürdige Capability-Manifeste und Integrationen von Vergleichsmethoden, sodass jede Ebene unabhängig inspiziert werden kann.

Installation

python -m venv .venv
source .venv/bin/activate
pip install -e '.[test]'
export PYTHONPATH="$PWD/src:$PWD"

Modellgestützte Komponenten lesen OPENAI_API_KEY und die optionale OPENAI_BASE_URL aus der Umgebung. Kopieren Sie .env.example nur als Referenz; der Code liest keine lokalen Anmeldedatendateien.

Repository-Übersicht

Pfad	Zuständigkeit
src/apex/defender/	APEX-Task-Verträge, typisierte Bindings, Receipts, Proof-Checks, PLANT, WRAP und Continuation-Handling
src/apex/core/	Gemeinsames Protokoll, Ergebnistypen, Aggregation und anbieterneutrale Modellgrenze
benchmark/adapter/	Schreibgeschützte Konvertierung von Benchmark-Releases in eine einheitliche BenchmarkCase-Schnittstelle
benchmark/registry/	Vertrauenswürdige Fähigkeitsregistrierung und benchmarkspezifische Manifeste
baseline/<name>/	Eine Implementierung oder Laufzeitintegration pro Vergleichsmethode
tests/	Repository-Invarianten und schnelle Unit-Checks

Siehe STRUCTURE.md für den Komponentenfluss und die Erweiterungspunkte.

Laden von Benchmark-Fällen

Kompakte, eingefrorene Fallbeschreibungen für alle sechs Benchmarks sind unter benchmark/data/ enthalten. Vollständige Upstream-Repositories und Laufzeit-Sandboxes werden nicht mitgeliefert. Die Übergabe von None wählt die paketierten Daten aus; ein explizites data_root kann diese weiterhin überschreiben.

from benchmark.adapter import adapter_for

adapter = adapter_for("scr", None)
attack_cases = list(adapter.cases("attack"))

Der Adapter verwaltet Fallbezeichner, Split-Labels, Suite-Labels, die Eignung und die Nutzlast, die der Benchmark-Laufzeitumgebung präsentiert wird. Er verändert keine Benchmark- Inhalte und registriert keine Tool-Autorität.

Vertrauenswürdige Manifeste laden

from benchmark.registry import module_for

registry = module_for("mcptox")
environment_plan = registry.load("12306-mcp")

Capability-Manifeste werden getrennt von Dataset-Adaptern geführt, da Benchmark-Text nicht vertrauenswürdige Episode-Eingaben sind, während ein Manifest die operatorseitig kontrollierte Ausführungsgrenze beschreibt, die vor der Episode verfügbar ist.

Jede benchmark/registry/data/<benchmark>/manifest.json ist ein finales Registry-Artefakt, das apex-benchmark-registry-v2 verwendet. Ein Bundle speichert deduplizierte capability_units, wiederverwendbare Umgebungen und explizite Case-Bindings. Somit dupliziert ein Benchmark mit Hunderten von Cases ein identisches Tool-Manifest nicht hunderte Male. Jede Unit behält das exakte Input/Output-Schema, effect, observation, effect_return, die Receipt-Rolle und typisierte Annotationen bei. Jede Umgebung zeichnet separat Quellen, Skills und agent_visible_surface auf.

Die exakten auditierten Quell-Eingaben aus der Experiment-Implementierung werden unter benchmark/registry/source/ aufbewahrt. Der Build-Schritt normalisiert und dedupliziert diese bestehenden Registrierungen; er leitet keine neuen Capability-Semantiken aus Benchmark-Prompts ab. Alle finalen Artefakte neu generieren mit:

pip install -e '.[registry]'
python scripts/build_registry_manifests.py
python scripts/audit_registry_coverage.py

Um gepackte Fallbeschreibungen aus lokalen Upstream-Checkouts zu aktualisieren, führen Sie aus:

python scripts/import_benchmark_data.py \
  --research-root <research-checkout> \
  --scr-root <SCR_Bench-checkout>

Der SCR-Importer verifiziert den gepinnten Commit, bevor er seinen kompakten Fall-/Skill-Expositionsindex ableitet.

APEX-Ausführungsablauf

1. TaskContractor kompiliert die vertrauenswürdige Benutzeranfrage in einen Task-Vertrag.
2. Die Benchmark-Registry liefert die saubere Fähigkeitsoberfläche.
3. Die Engine löst typisierte Werte auf und zeichnet Beobachtungen als Belege auf.
4. PLANT prüft die Provenienz auf Aufgabenebene und die Commitment-Struktur.
5. WRAP prüft den vollständigen vorgeschlagenen Effekt gegen den Vertrag und die Belege.
6. Die Engine gibt Informationen zur Fortsetzung zurück: erlauben, verweigern, reparieren oder neu planen.

Die deterministischen Prüfungen bleiben unabhängig vom Zielmodell. Modellgestützte Rollen reichen typisierte Kandidaten ein, die dieselbe Validierungsgrenze passieren müssen.

Baselines

baseline/registry.py definiert die 13 Vergleichsmethoden. Jede Methode hat einen eigenen Ordner, der nach der Methode benannt ist, sowie einen implementation.py-Einstiegspunkt. Abhängigkeiten mit eigener Laufzeitumgebung werden verzögert importiert, sodass der APEX-Kern und die Datenadapter getestet werden können, ohne alle Benchmark-Umgebungen zu installieren.

Verifikation

python -m compileall -q src benchmark baseline tests
pytest

Vor der Veröffentlichung führe außerdem die Anonymitätsprüfungen in ANONYMITY.md aus. Es sollten keine Zugangsdaten, Ergebnisdateien, maschinenspezifischen Pfade, Git-Remotes oder Autorenmetadaten zur Einreichung hinzugefügt werden.