APEX

Le dépôt sépare le défenseur APEX, la normalisation des données de référence, 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 adossés à un modèle lisent OPENAI_API_KEY et la variable facultative OPENAI_BASE_URL depuis l'environnement. Copiez .env.example uniquement à titre de référence ; le code ne lit pas de fichiers d'identifiants locaux.

Plan 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 des continuations
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 en une interface BenchmarkCase unique
benchmark/registry/	Enregistrement de 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 bacs à sable d'exécution ne sont pas intégrés au dépôt. 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 gère les identifiants de cas, les étiquettes de division, les étiquettes de suite, l'éligibilité et la charge utile présentée à l'environnement d'exécution du benchmark. Il ne modifie pas le contenu du benchmark ni n'enregistre l'autorité de l'outil.

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 de 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 manifeste d'outil identique des centaines de fois. Chaque unité conserve le schéma d'entrée/sortie exact, 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 auditées exactes issues de l'implémentation de l'expérience sont conservées sous benchmark/registry/source/. L'étape de build normalise et déduplique ces enregistrements existants ; elle ne déduit pas de nouvelles sémantiques de capacités à partir des prompts 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 des copies locales des dépôts amont, 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 benchmarks 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 adossés à un modèle soumettent des candidats typés qui doivent franchir la même frontière de validation.

Références de base

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 disposant de leur propre runtime 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 décrites 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.