APEX

Code accompagnant une soumission d'article anonyme. Le dépôt sépare le défenseur APEX, la normalisation des données de benchmark, les manifestes de capacités de confiance et les intégrations des méthodes de comparaison afin que chaque couche puisse être inspectée indépendamment.

Installation

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

Les composants reposant sur des modèles lisent OPENAI_API_KEY et la variable optionnelle OPENAI_BASE_URL depuis l'environnement. Copiez .env.example uniquement à titre de référence ; le code ne lit pas les fichiers d'identifiants locaux.

Carte du dépôt

Chemin	Responsabilité
src/apex/defender/	Contrats de tâches APEX, liaisons typées, reçus, vérifications de preuve, PLANT, WRAP et gestion de la continuation
src/apex/core/	Protocole partagé, types de résultats, agrégation et frontière de modèle neutre vis-à-vis du fournisseur
benchmark/adapter/	Conversion en lecture seule des versions de benchmark vers une interface unique BenchmarkCase
benchmark/registry/	Enregistrement des capacités de confiance et manifestes spécifiques aux benchmarks
baseline/<name>/	Une implémentation ou intégration d'exécution par méthode de comparaison
tests/	Invariants du dépôt et vérifications unitaires rapides

Voir STRUCTURE.md pour le flux des composants et les points d'extension.

Chargement des cas de benchmark

Des descripteurs de cas figés et compacts pour les six benchmarks sont inclus sous benchmark/data/. Les dépôts amont complets et les sandboxes d'exécution ne sont pas vendus. Passer None sélectionne les données empaquetées ; un data_root explicite peut toujours les remplacer.

from benchmark.adapter import adapter_for

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

L'adaptateur possède les identifiants de cas, les étiquettes de découpage, les étiquettes de suite, l'éligibilité et la charge utile présentée à l'exécution du benchmark. Il ne modifie pas le contenu du benchmark et n'enregistre pas l'autorité des outils.

Chargement des manifestes de confiance

from benchmark.registry import module_for

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

Les manifestes de capacités sont conservés séparément des adaptateurs de jeux de données car le texte du benchmark est une entrée d'épisode non fiable, tandis qu'un manifeste décrit la frontière d'exécution détenue par l'opérateur et disponible avant l'épisode.

Chaque benchmark/registry/data/<benchmark>/manifest.json est un artefact de registre final utilisant apex-benchmark-registry-v2. Un bundle stocke des capability_units dédupliquées, des environnements réutilisables et des liaisons de cas explicites. Ainsi, un benchmark comportant des centaines de cas ne duplique pas un même manifeste d'outil des centaines de fois. Chaque unité conserve le schéma exact d'entrée/sortie, effect, observation, effect_return, le rôle de reçu et les annotations typées. Chaque environnement enregistre séparément les sources, les Skills et agent_visible_surface.

Les entrées sources exactes auditées issues de l'implémentation expérimentale sont conservées sous benchmark/registry/source/. L'étape de build normalise et déduplique ces enregistrements existants ; elle n'infère pas de nouvelles sémantiques de capacités à partir des invites de benchmark. Régénérez tous les artefacts finaux avec :

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

Pour actualiser les descripteurs de cas empaquetés à partir de checkouts amont locaux, exécutez :

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

L'importateur SCR vérifie le commit épinglé avant de dériver son index compact d'exposition des cas/Skills.

Flux d'exécution APEX

1. TaskContractor compile la requête utilisateur de confiance en un contrat de tâche.
2. Le registre de benchmark fournit la surface de capacités propre.
3. Le moteur résout les valeurs typées et enregistre les observations sous forme de reçus.
4. PLANT vérifie la provenance au niveau de la tâche et la structure d'engagement.
5. WRAP vérifie l'effet complet proposé par rapport au contrat et aux reçus.
6. Le moteur renvoie les informations de continuation allow, deny, repair ou replan.

Les vérifications déterministes restent indépendantes du modèle cible. Les rôles reposant sur des modèles soumettent des candidats typés qui doivent franchir la même frontière de validation.

Baselines

baseline/registry.py définit les 13 méthodes de comparaison. Chaque méthode dispose d'un dossier dédié portant le nom de la méthode et d'un point d'entrée implementation.py. Les dépendances ayant leur propre exécution sont importées paresseusement afin que le cœur d'APEX et les adaptateurs de données puissent être testés sans installer tous les environnements de benchmark.

Vérification

python -m compileall -q src benchmark baseline tests
pytest

Avant la publication, exécutez également les vérifications d'anonymat dans ANONYMITY.md. Aucun identifiant, fichier de résultats, chemin spécifique à une machine, dépôt distant Git ou métadonnée d'auteur ne doit être ajouté à la soumission.