Zum Inhalt springen

Version veröffentlichen und zurücksetzen

Jede Änderung an einem Feature wird als neue Version einer Agent-Contract-Definition festgehalten. Eine Version durchläuft den Lebenszyklus Entwurf (draft) → aktiv (active) → abgelöst (superseded). Erst wenn eine Version veröffentlicht ist, lädt das SDK sie und führt das Feature damit aus. Diese Seite beschreibt den Weg vom Entwurf zur aktiven Version, das Vergleichen zweier Versionen und das Zurücksetzen auf eine frühere Version. Den Aufbau einer Version erklärt Der Agent Contract.

Veröffentlichen (eine Version aktiv schalten) dürfen developer, domain_expert, platform_engineer und admin. Zurücksetzen (Rollback) dürfen developer, platform_engineer und admin. compliance_officer und viewer haben nur Lesezugriff. Sobald ein Feature im Lebenszyklus stillgelegt (sunset) ist, kann es niemand mehr bearbeiten oder zurücksetzen. Die Oberfläche blendet Aktionen aus, die die eigene Rolle nicht ausführen darf; durchgesetzt wird das im Backend. Die vollständige Aufstellung steht unter Rollen und Rechte.

Geöffnet wird der Editor über die Feature-Karte und die Tab Versions (Versionen) beziehungsweise den Editor-Bereich des Features. Ein Entwurf wird erst veröffentlichbar, wenn zwei Prüfungen bestanden sind.

Production-Readiness-Leiste. Am unteren Rand des Editors zeigt die Leiste Production-Readiness mehrere Reife-Kriterien als Fortschrittsanzeige, daneben den Stand N / N grün. Jedes Kriterium erscheint als farbiger Chip:

KriteriumBedeutung
Schema enforcedEin nicht-leeres, gültiges Output-Schema (das stabile Interface) ist hinterlegt.
Tools isoliertTool-Isolation (vorgemerkt).
IdempotencyIdempotenz-Prüfung (vorgemerkt).
Auth verifiziertDie Zugriffsregeln sind aktiv.
Audit aktivDie Protokollierung läuft.
Evals bestandenEine Eval-Baseline (Schwellwerte für die Qualitätsprüfung) ist gesetzt.

Ist ein Kriterium rot, blockiert es die Veröffentlichung. Die Leiste nennt dann unten die Ursache, etwa Publish blockiert durch: Schema enforced. Zu einem roten Kriterium führt der Knopf Was tun? zu konkreten Schritten.

Linter. Beim Speichern und beim Veröffentlichen prüft ein Linter den Inhalt auf Regelverstöße. Findings mit der Stufe Block erscheinen als Banner und sperren die Veröffentlichung (Publish blockiert); Findings der Stufe Warn sind nur Hinweise. Erst wenn die Readiness-Kriterien grün sind und kein Block-Finding mehr vorliegt, wird der Knopf Publish aktiv.

Sind alle Prüfungen grün, ist der Ablauf:

  1. Klicke auf Publish.
  2. Im Dialog Contract publizieren? erscheint zur Kontrolle die Zusammenfassung Version … · Risk-Tier … · Provider … (Risk Tier = Risikoklasse 1/2/3).
  3. Bestätige mit Publizieren oder breche mit Abbrechen ab.

Nach dem Veröffentlichen erscheint der Dialog Contract publiziert — {Version}. Er enthält ein fertiges SDK-Code-Snippet zum Aufrufen des Contracts; über Zur SDK-Doku geht es zur SDK-Einrichtung. Mit Schließen wird der Dialog geschlossen.

Die neue Versionsnummer vergibt die Plattform automatisch je nach Schema-Änderung: Patch (Prompt-Änderung, Provider-Wechsel ohne Schema-Effekt, Eval-Baseline-Update), Minor (optionales Feld oder neuer Enum-Wert, abwärtskompatibel) oder Major (Pflichtfeld entfernt, Typ geändert, Enum-Wert entfernt). Ein Hinweis im Editor zeigt vorab die vorgeschlagene Nummer und die Begründung.

Bricht eine Output-Schema-Änderung die Kompatibilität, verlangt die Plattform eine ausdrückliche Bestätigung. Der Dialog Breaking-Schema-Änderung — Major-Bump bestätigen? listet die einzelnen Schema-Änderungen auf und verlangt, zur Bestätigung den Feature-Namen einzutippen. Erst danach lässt sich Major-Bump bestätigen auslösen; Abbrechen bricht ab.

In der Tab Versions listet eine Tabelle alle Versionen mit den Spalten Version, Lifecycle, Erstellt, Autor, Änderungen und Aktionen. Der Knopf Diff in einer Zeile vergleicht die Version mit ihrer Vorgänger-Version; über die beiden Auswahlfelder im Diff-Bereich lassen sich auch zwei beliebige veröffentlichte Versionen wählen.

Der Vergleich zeigt die Unterschiede gegliedert nach den Bestandteilen Header, Prompt, Modell-Pin, Tool-Pins, RAG-Index und Eval-Baseline. Gibt es keine Unterschiede, erscheint Keine Änderungen zwischen den Versionen.

Mit einem Rollback wird der aktive Zeiger atomar auf eine frühere, bereits veröffentlichte Version umgelegt — entweder vollständig oder gar nicht, niemals halb. Der Knopf Rollback steht nur bei Versionen mit dem Zustand abgelöst (superseded) und nur für die berechtigten Rollen.

  1. Klicke in der Versions-Tabelle in der gewünschten Zeile auf Rollback.
  2. Der Dialog Bundle zurückrollen auf v…? zeigt die Ziel-Version und weist darauf hin, dass alle Bestandteile (Prompt, Modell-Pin, Tool-Pins, RAG-Index, Eval-Baseline) gemeinsam zurückgesetzt werden.
  3. Optional eine Begründung eintragen (wird im Audit-Trail festgehalten).
  4. Bei einem Tier-3-Feature zusätzlich die Versions-Nummer zur Bestätigung eintippen.
  5. Bestätige mit Rollback ausführen oder breche mit Abbrechen ab.

Ändert die Ziel-Version die Risikoklasse, warnt der Dialog vorab. Jeder Rollback ist im Audit dokumentiert.

Eine veröffentlichte Version ist schreibgeschützt. Im Editor erscheint der Hinweis Version X ist aktiv. Der Editor ist gesperrt. Für Änderungen den Knopf Neuen Draft anlegen verwenden: Er erstellt aus dem aktiven Inhalt einen neuen Entwurf, der wieder bearbeitet werden kann. Die neue Versionsnummer wird erst beim nächsten Veröffentlichen vergeben, abhängig vom Schema-Diff.