Das Manifest
Was jeder Build darüber festhält, was genau in die generierte App eingeflossen ist.
On this page
Das Manifest
Jeder build schreibt .build/manifest.json - BX Agents' eigenen Datensatz darüber, was genau in die generierte App eingeflossen ist. bxAgents inspect gibt es hübsch aus, ohne neu zu bauen; bxAgents package kopiert eine geschwärzte Version davon neben die .bxa (siehe Deployment & Secrets).
Schema
{
"manifestVersion": "1.0.0",
"generator": { "name": "bx-agents", "version": "dev" },
"agent": {
"name": "my-agent",
"description": "",
"model": "openai/gpt-5",
"environment": "development"
},
"files": [
{ "category": "tools", "name": "Greeter", "path": "tools/Greeter.bx", "hash": "..." }
]
}
| Feld | Bedeutung |
|---|---|
manifestVersion | Semver-Stempel für das Manifest-Schema selbst (aktuell 1.0.0) - package verweigert die Ausführung, falls dieser Wert nicht gesetzt oder fehlerhaft ist. |
generator.name / generator.version | Immer "bx-agents" / die BX-Agents-Modulversion, die diesen Build erzeugt hat. |
agent | Nur sichere, strukturelle Felder (name, description, model, environment) - nie Secrets. Secrets werden überhaupt nie in das Manifest eingelesen; sie werden von bx-ai selbst, live, zur Laufzeit aufgelöst. |
files | Ein Eintrag pro entdecktem Konventionsordner-Element, sortiert nach Kategorie und dann Pfad für deterministische Reihenfolge - unabhängig von der Auflistungsreihenfolge des Dateisystems. |
Inhalts-Hashes
Der hash jedes files[]-Eintrags ist ein SHA-256 seines Inhalts:
- Eine Datei: der Hash ihres Inhalts, wobei Zeilenenden zuerst normalisiert werden (CRLF- und LF-Checkouts desselben Inhalts hashen identisch).
- Ein Verzeichnis (ein Skill-Ordner, ein Subagenten-Ordner, ein Modul-Ordner): der Hash aus dem eigenen
relativePath:contentHashjeder enthaltenen Datei, rekursiv, für Determinismus sortiert - das Umbenennen oder Bearbeiten einer einzelnen enthaltenen Datei ändert also den Hash des gesamten Ordners.
Das ist es, was den erneuten Build eines unveränderten Projekts ein identisches Manifest erzeugen lässt: gleiche Kategorien, gleiche Reihenfolge, gleiche Hashes, jedes Mal - und genau deshalb ändert das Ändern einer einzelnen Tool-Datei stets nur den Hash dieses einen Eintrags, sonst nichts.
Kompatibilitätsrichtlinie
manifestVersion existiert, damit eine zukünftige Breaking Change an diesem Schema von allem erkannt werden kann, das manifest.json liest (ein Deploy-Ziel, eine zukünftige inspect-Version, externes Tooling) - ein Tool, das auf eine unbekannte Hauptversion trifft, sollte sich weigern, die Form zu erraten, und klar fehlschlagen, statt Felder stillschweigend falsch zu interpretieren.