Einen Agenten durchgängig steuern | Developer Docs

Diese Anleitung führt Sie anhand eines einzigen, generischen Beispiels durch die vollständige Control-Plane-Schleife: ein Claims-Triage-Agent, der eingehende Schadensmeldungen liest und Rückerstattungen auslösen kann. Am Ende haben Sie den Agenten registriert, eine Policy geschrieben, die jede Rückerstattung über einem Schwellenwert pausiert, eine Ausführung gestartet, die dieses Gate auslöst, sie als Mensch freigegeben, den Lauf erneut abgespielt und einen manipulationssicheren Nachweis für eine Prüferin oder einen Prüfer exportiert.

Das durchgängige Prinzip ist gesteuerte Autonomie: Der Agent empfiehlt eine Aktion, aber die Policy behält die Hoheit darüber, ob sie ausgeführt wird. Der Agent bleibt bei risikoarmen Aufgaben schnell und pausiert für einen Menschen genau dort, wo die Tragweite es rechtfertigt. Die KLA Control Plane ist eine Govern-in-Place-Schicht: Sie instrumentieren Ihren bestehenden Agenten, anstatt ihn auf eine neue Plattform zu migrieren, sodass diese Schleife Code umschließt, den Sie bereits haben.

Alles Folgende verwendet den Live-API-Host https://api.kla.digital mit zwei Headern: einem Bearer-Token und Ihrer Tenant-ID. Exportieren Sie diese einmalig:

export KLA_TOKEN="<paste access_token>"
export KLA_TENANT="acme-claims"

sequenceDiagram
  participant Dev as Entwickler
  participant Agent as Claims-Agent
  participant KLA as KLA Control Plane
  participant Desk as Decision Desk
  participant Room as Evidence Room
  Dev->>KLA: 1. Agent registrieren
  Agent->>KLA: 3. Ausführung starten (Rückerstattung 1.250 $)
  KLA->>KLA: 2. Policy auswerten
  KLA->>Desk: require_approval -> Escalation
  Desk->>KLA: 4. Prüfer gibt frei
  KLA->>Agent: Ausführung fortsetzen
  Dev->>KLA: 5. Im Lineage Explorer erneut abspielen
  KLA->>Room: 6. Sealed Evidence Bundle exportieren

Schritt 1: Den Agenten registrieren

Das Registrieren eines Agenten meldet ihn bei der Control Plane an und gibt ihm eine stabile Identität, auf die sich jeder spätere Schritt bezieht. Das Manifest benennt den Agenten, listet die Tools auf, die er aufrufen darf, und weist einen Owner zu. Das Tool process_refund ist dasjenige, das wir steuern werden.

curl -X POST https://api.kla.digital/v1/agents \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "claims-triage",
    "description": "Triages inbound claims and issues refunds",
    "owner": "claims-ops",
    "tools": ["lookup_claim", "process_refund"]
  }'

Die Antwort liefert eine agentId (zum Beispiel agt_9f81a7) zurück. Der Agent erscheint nun im Agent Registry, dem Inventar jedes gesteuerten Agenten, seines Owners und seines aktuellen Release-Zustands.

Schritt 2: Eine Policy verfassen, die eine Freigabe erfordert

Policy ist deklarativ und wird von der KLA Policy Engine auf Anwendungsebene ausgewertet. Wir schreiben zwei Regeln für execute_refund: Kleine Rückerstattungen laufen durch, und Rückerstattungen über dem Schwellenwert pausieren für einen Menschen. KLA löst Policy in vier Ergebnisse in Vorrangreihenfolge auf: allow, warn, require_approval, block. Hier löst die Regel für hohe Beträge zu require_approval (eine Pause für eine Prüferin oder einen Prüfer) auf statt zu block (ein harter Stopp).

# claims-triage policy (illustrative): refunds over $100 pause for review
- rule: low-value-refund
  when:
    tool: execute_refund
    amount: "<= 100.00"
  then:
    decision: allow
    reasonCode: REFUND_WITHIN_THRESHOLD

- rule: high-value-refund
  when:
    tool: execute_refund
    amount: "> 100.00"
  then:
    decision: require_approval
    reasonCode: REFUND_OVER_THRESHOLD
    route: Decision Desk

Verfassen Sie dies im Policy Builder, führen Sie eine Simulation durch, um zu bestätigen, dass eine Testanfrage über $1,250 zu require_approval auflöst, und veröffentlichen Sie sie dann. Beim Veröffentlichen wird sie zu einem signierten Policy Pack kompiliert, sodass die Live-Auswertung schnell und manipulationssicher ist.

💡 Tip

Simulieren Sie immer vor dem Veröffentlichen. Eine Simulation spielt repräsentative Anfragen gegen den Entwurf ab, sodass Sie bestätigen, dass jede einzelne zu dem erwarteten Ergebnis auflöst, ohne Auswirkungen auf laufende Agenten.

Schritt 3: Eine gesteuerte Ausführung starten, die das Gate auslöst

Lassen Sie den Agenten nun gegen eine Schadensmeldung laufen, die eine hohe Rückerstattung erfordert. Ihr instrumentierter Agent reicht einen Decision Request ein (die Aktion samt ihres geschäftlichen Kontexts), bevor er process_refund aufruft. Da der Betrag den Schwellenwert überschreitet, gibt die Policy require_approval zurück und eröffnet eine Escalation, anstatt die Rückerstattung durchzulassen.

curl -X POST https://api.kla.digital/v1/decisions.evaluate \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "claims-triage",
    "action": "execute_refund",
    "attributes": { "amount": 1250.00, "claim_id": "clm_9921" }
  }'

{
  "outcome": "require_approval",
  "reasonCodes": ["REFUND_OVER_THRESHOLD"],
  "remediation": "Refunds above $100 require a reviewer. Routed to the Decision Desk.",
  "escalationId": "esc_01HZ8K"
}

Die Ausführung ist pausiert, nicht fehlgeschlagen. Behandeln Sie require_approval als asynchrone Wartephase und zeigen Sie dem Endnutzer den ausstehenden Zustand an.

Schritt 4: Am Decision Desk freigeben

Die Escalation wartet nun im Decision Desk, wo eine autorisierte Prüferin oder ein autorisierter Prüfer die Aktion, ihren Betrag, die Reason Codes und die Remediation-Hinweise sieht. Eine Freigabe setzt die ursprüngliche Ausführung genau dort fort, wo sie pausiert wurde; eine Ablehnung stoppt sie. Eine prüfende Person kann in der UI oder über die API handeln.

curl -X POST https://api.kla.digital/v1/escalations/esc_01HZ8K/approve \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{ "note": "Verified claim documentation; refund authorized." }'

Die Rückerstattung wird nun ausgeführt. Der Mensch behielt die Hoheit über die folgenschwere Aktion, während der Agent alles Übrige autonom erledigte.

Schritt 5: Den Lauf im Lineage Explorer erneut abspielen

Jeder gesteuerte Lauf wird zu einem Lineage Record: der geordnete Baum von Schritten vom auslösenden Prompt über jeden Tool-Aufruf bis zur finalen Ausgabe. Öffnen Sie ihn im Lineage Explorer, um genau abzuspielen, was passiert ist: das Policy-Ergebnis inline, die GenAI-Attribute (genai.tool.name, genai.tool.parameters, genai.cost.usd, genai.token.usage) und die Freigabe. Beim Verifizieren eines Records wird sein Merkle proof bis zur verankerten Ledger-Wurzel nachvollzogen.

curl https://api.kla.digital/v1/lineage/lr_8f21/verify \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT"

Eine Übereinstimmung bestätigt, dass der Record Byte für Byte dem entspricht, was zum Ausführungszeitpunkt versiegelt wurde. Die Verifizierung ist unabhängig von der Anwendung, die ihn erzeugt hat, und genau das macht den Record zu einem Nachweis und nicht zu einem bloßen Log.

Schritt 6: Ein Sealed Evidence Bundle exportieren

Leiten Sie schließlich den Record (oder ein gefiltertes Zeitfenster) an den Evidence Room weiter und schnüren Sie ihn zu einem Sealed Evidence Bundle: signierte Records, vollständige Lineage, der angewandte Policy-Zustand und die Verifizierungsprotokolle.

curl -X POST https://api.kla.digital/v1/evidence/bundles \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{ "lineageRecords": ["lr_8f21"], "format": "pdf" }'

ℹ️ Note

Ein Sealed Evidence Bundle ist ein portabler Nachweis. Übergeben Sie es einer Prüferin oder einem Prüfer oder hängen Sie es an einen **Control Pack** an (ein Compliance-Export, der Ihre gesteuerten Aktionen bestimmten Framework-Controls zuordnet), und die prüfende Person kann die Integrität verifizieren, ganz ohne Zugriff auf Ihre Systeme.

Sie haben nun die vollständige Schleife durchlaufen: registrieren, steuern, absichern, freigeben, erneut abspielen, nachweisen. Dieselben sechs Schritte gelten für jede folgenschwere Agentenaktion, ob ein zur Prüfung versendetes Dokument, ein aktualisierter Datensatz oder ein aufgerufenes externes API, überall dort, wo der Agent schnell sein soll und die Policy die Hoheit behalten soll.