APEX

Codice che accompagna una sottomissione anonima a una conferenza. Il repository separa il difensore APEX, la normalizzazione dei dati di benchmark, i manifest delle capacità fidate e le integrazioni dei metodi di confronto, in modo che ogni livello possa essere ispezionato in modo indipendente.

Installazione

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

I componenti basati su modelli leggono OPENAI_API_KEY e l'opzionale OPENAI_BASE_URL dall'ambiente. Copia .env.example solo come riferimento; il codice non legge file di credenziali locali.

Mappa del repository

Percorso	Responsabilità
src/apex/defender/	Contratti dei task APEX, binding tipizzati, ricevute, controlli di prova, PLANT, WRAP e gestione della continuazione
src/apex/core/	Protocollo condiviso, tipi di risultato, aggregazione e confine del modello neutrale rispetto al provider
benchmark/adapter/	Conversione in sola lettura delle release di benchmark in un'unica interfaccia BenchmarkCase
benchmark/registry/	Registrazione delle capacità fidate e manifest specifici del benchmark
baseline/<name>/	Un'implementazione o integrazione runtime per ogni metodo di confronto
tests/	Invarianti del repository e controlli unitari rapidi

Vedi STRUCTURE.md per il flusso dei componenti e i punti di estensione.

Caricamento dei casi di benchmark

Descrittori di caso compatti e congelati per tutti e sei i benchmark sono inclusi in benchmark/data/. I repository upstream completi e le sandbox di runtime non sono inclusi nel vendor. Passare None seleziona i dati pacchettizzati; un data_root esplicito può comunque sovrascriverli.

from benchmark.adapter import adapter_for

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

L'adapter possiede gli identificatori dei casi, le etichette di split, le etichette di suite, l'eleggibilità e il payload presentato al runtime del benchmark. Non altera il contenuto del benchmark né registra l'autorità degli strumenti.

Caricamento dei manifest fidati

from benchmark.registry import module_for

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

I manifest delle capacità sono tenuti separati dagli adapter dei dataset perché il testo del benchmark è input non fidato dell'episodio, mentre un manifest descrive il confine di esecuzione di proprietà dell'operatore disponibile prima dell'episodio.

Ogni benchmark/registry/data/<benchmark>/manifest.json è un artefatto di registro finale che utilizza apex-benchmark-registry-v2. Un bundle memorizza capability_units deduplicati, ambienti riutilizzabili e binding espliciti dei casi. Così un benchmark con centinaia di casi non duplica un identico manifest di Tool centinaia di volte. Ogni unità conserva lo schema esatto di input/output, effect, observation, effect_return, il ruolo della ricevuta e le annotazioni tipizzate. Ogni ambiente registra separatamente le fonti, le Skills e agent_visible_surface.

Gli input sorgente esatti e verificati dall'implementazione dell'esperimento sono conservati in benchmark/registry/source/. La fase di build normalizza e deduplica quelle registrazioni esistenti; non inferisce nuove semantiche di capacità dai prompt del benchmark. Rigenera tutti gli artefatti finali con:

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

Per aggiornare i descrittori di caso pacchettizzati dai checkout upstream locali, esegui:

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

L'importer SCR verifica il commit fissato prima di derivare il suo indice compatto di esposizione di casi/Skill.

Flusso di esecuzione di APEX

1. TaskContractor compila la richiesta utente fidata in un contratto di task.
2. Il registro del benchmark fornisce la superficie di capacità pulita.
3. Il motore risolve i valori tipizzati e registra le osservazioni come ricevute.
4. PLANT verifica la provenienza a livello di task e la struttura di commitment.
5. WRAP verifica l'effetto completo proposto rispetto al contratto e alle ricevute.
6. Il motore restituisce informazioni di continuazione allow, deny, repair o replan.

I controlli deterministici rimangono indipendenti dal modello target. I ruoli basati su modelli inviano candidati tipizzati che devono superare lo stesso confine di validazione.

Baseline

baseline/registry.py definisce i 13 metodi di confronto. Ogni metodo ha una cartella dedicata con il nome del metodo e un punto di ingresso implementation.py. Le dipendenze con un proprio runtime vengono importate in modo lazy, così il core di APEX e gli adapter dei dati possono essere testati senza installare tutti gli ambienti di benchmark.

Verifica

python -m compileall -q src benchmark baseline tests
pytest

Prima del rilascio, esegui anche i controlli di anonimato in ANONYMITY.md. Nessuna credenziale, file di risultato, percorso specifico della macchina, remote Git o metadato dell'autore deve essere aggiunto alla sottomissione.