Agents & Registry

Das Modul Agents ist der Lebenszyklus-Mittelpunkt für jeden KI-Agenten, den Sie mit der KLA Control Plane steuern, also der Schicht für Laufzeitsicherheit, Audit und Governance, mit der Sie Ihre bestehenden Agenten instrumentieren, statt sie auf eine neue Plattform zu migrieren. Es kombiniert eine Agent Registry (das Inventar jedes Agenten, seines Eigentümers und seiner Versionen) mit einer gesteuerten Auslieferungspipeline: Eine Änderung entwerfen, validieren, ein unveränderliches Release veröffentlichen, ausrollen und bei Bedarf zurückrollen. Agents deckt den gesamten Bogen ab, von "dieser Agent existiert" bis "genau diese Version läuft in der Produktion".

Wer es nutzt

• Entwickler und Integratoren registrieren Agenten, definieren deren Manifeste, führen Simulations aus und liefern Releases über denselben Ablauf aus, den sie für Code verwenden.
• Plattformbetreiber verwalten Rollouts über Umgebungen hinweg, steuern Promotions und lösen einen Rollback aus, sobald sich das Verhalten verschlechtert.
• Compliance- und Risikoverantwortliche verlassen sich auf die Agent Registry als verbindliche Antwort auf die Frage "Welche Agenten existieren, wem gehören sie, was dürfen sie tun und was hat sich geändert?". Jedes Release ist versioniert und zuordenbar.

Zentrale Funktionen

• Agent Registry. Durchsuchen und filtern Sie jeden registrierten Agenten nach Modell, verantwortlichem Team, Release-Status oder Manifest-Hash. Jeder Eintrag enthält die Eigentümerschaft, das aktive Release und die vollständige Versionshistorie.
• Releases. Ein Release ist eine unveränderliche, versionierte Momentaufnahme der Konfiguration eines Agenten: Modell, Systemanweisungen, Parameter und Tool-Bindungen. Releases ändern sich nach der Veröffentlichung nie; jede Änderung erzeugt stets ein neues Release mit einem neuen Hash. Genau das macht die Frage "Was lief an jenem Datum?" zu einer präzisen, beweisbaren Frage.
• Rollouts und Rollback. Ein Rollout befördert ein Release in eine Zielumgebung. Ein Rollback versetzt die Umgebung sofort auf ein zuvor veröffentlichtes Release zurück. Beide sind erstklassige, auditierte Aktionen, ohne Hot-Editing der Live-Konfiguration.
• Simulations. Führen Sie vor der Veröffentlichung eine Simulation in einer Sandbox aus: Spielen Sie repräsentative Prompts gegen das Kandidaten-Release ab und prüfen Sie Ausgaben, Tool-Aufrufe, Kosten und die Policy-Entscheidungen, die jede Aktion auslösen würde, und das alles ohne jede Auswirkung auf die Produktion.
• Durchsetzung von Tool-Bindungen. Jeder Agent deklariert die Tools, die er aufrufen darf. Zur Laufzeit erzwingt KLA diese Bindungen gegen den Tool Catalog (das gesteuerte Inventar genehmigter Tools und ihrer Berechtigungen). Versucht ein Agent ein Tool aufzurufen, das in seinem aktiven Release nicht gebunden ist, wird die Aktion blockiert: standardmäßig Ausführung nach dem Least-Privilege-Prinzip.

Agent-Manifest

Agenten werden deklarativ als JSON-Manifeste definiert. Ein neues Manifest erzeugt bei der Veröffentlichung ein neues Release mit einem neuen Hash.

{
  "id": "agt_9f81a7",
  "name": "support-classifier",
  "model": "gpt-4o",
  "temperature": 0.0,
  "tools": ["escalate_ticket", "read_knowledge_base"],
  "env": "production"
}

Das tools-Array ist die Bindungsmenge. Zur Laufzeit prüft KLA jeden Tool-Aufruf gegen den Tool Catalog und diese deklarierte Menge; ein Aufruf eines nicht deklarierten Tools wird abgelehnt, bevor er ausgeführt wird.

Release-Lebenszyklus

flowchart LR
  A["Änderung entwerfen"] --> B{"Validieren"}
  B -->|schlägt fehl| A
  B -->|erfolgreich| C["Release veröffentlichen"]
  C --> D["Rollout in Umgebung"]
  D --> E{"Gesund?"}
  E -->|ja| F["Aktives Release"]
  E -->|nein| G["Rollback"]
  G --> F

Wie es zusammenhängt

Agents steht im Zentrum der vier Säulen Govern, Operate, Assure, Prove:

• Policy Builder verfasst die Policies, die gegen jede Agentenaktion ausgewertet werden. Führen Sie diese Policies vor der Veröffentlichung in einer Simulation gegen ein Kandidaten-Release aus.
• Decision Desk erhält eine Escalation, sobald eine gesteuerte Aktion eine require_approval-Entscheidung zurückgibt, und pausiert die Ausführung, bis ein Prüfer entscheidet.
• Lineage Explorer erfasst jede Aktion als Lineage Record, der jeweils mit dem exakten Release-Hash gestempelt ist, der ihn erzeugt hat, sodass eine Spur immer auf eine bekannte, unveränderliche Konfiguration zurückführt.
• Evidence Room versiegelt diese Lineage in ein Sealed Evidence Bundle und liefert Prüfern den kryptografischen Nachweis darüber, welches Release lief, was es tun durfte und was es tatsächlich getan hat.