Skip to main content
Verwende @phaseo/agent-sdk, wenn deine Anwendung mehr als eine einmalige Textgenerierung benötigt:
  • mehrstufige Tool-Schleifen
  • lokale Runtime-Tools
  • fortsetzbare Runs anhand des vom SDK zurückgegebenen Zustands
  • explizite Pausen für menschliche Freigaben
  • typisierte Endausgaben
  • Gateway-gestützte Modell-Turns über das vorhandene TypeScript-SDK
Das Paket ist ein installierbares SDK und keine gehostete Agent-Plattform. Anwendung, Bereitstellungsmodell und gewünschte Persistenzstrategie für den zurückgegebenen Run-Zustand liegen bei dir.

Zustandsmodell

Das Agent-SDK speichert Runs nicht in einem von Phaseo gehosteten Dienst.
  • run() gibt den vollständigen Zustand zurück, der zum späteren Fortsetzen benötigt wird. Wenn deine Anwendung Runs über Anfragen oder Prozessneustarts hinweg fortsetzen soll, speichere den zurückgegebenen Zustand in deinem eigenen Anwendungsspeicher.
  • continueRun() übernimmt den vorherigen Run-Zustand direkt.
Phaseo speichert außerhalb deiner Anwendung nichts.

Installation

Umfang des SDK

  • createAgent()
  • defineTool()
  • createGatewayAgentClient()
  • continueRun() zum Fortsetzen anhand eines zuvor zurückgegebenen Run-Zustands
  • stream() und continueStream() für schrittweise, erneut abspielbare Ergebnisse
  • Helfer für Stoppbedingungen wie stepCountIs(), maxCost() und hasToolCall()

Erster Agent

Grundmodell

Die Runtime-Schleife führt vier Schritte aus:
  1. sendet den aktuellen Nachrichtenstatus an den Modell-Client
  2. führt zurückgegebene lokale Tool-Aufrufe aus
  3. fügt die Tool-Ergebnisse dem nächsten Turn hinzu
  4. gibt nach jedem abgeschlossenen Schritt den aktualisierten Run-Zustand zurück
So erhält deine Anwendung eine fortsetzbare Schleife, ohne dass du eine gehostete Orchestrierungsplattform verwenden musst.

Zentrale Bausteine

createAgent()

Mit createAgent() legst du Folgendes fest:
  • eine stabile id
  • Anweisungen
  • ein Modell oder Preset
  • eine kurze Tool-Liste
  • optionale Ausgabeverarbeitung
  • optionale Regeln für menschliche Prüfung
  • optionale Steuerungen für Wiederholungen und Tool-Ausführung
Halte den ersten Agenten eng umrissen. Ein Workflow und ein oder zwei Tools reichen meist aus.

defineTool()

Definiere lokale Runtime-Tools mit:
  • id
  • description
  • optionale JSON-parameters
  • optionales timeoutMs
  • Runtime-Validatoren inputSchema und outputSchema
  • execute(), execute: false oder Callbacks mit menschlicher Beteiligung
  • requireApproval, onError, nextTurnParams und Fortschrittsereignisse
Läuft ein Timeout ab, bricht die Runtime context.signal ab, markiert den Run als failed und wirft den Timeout-Fehler erneut. Schemas können Funktionen oder beliebige Objekte mit parse() oder safeParse() sein. Ungültige Modellargumente und Tool-Ergebnisse schlagen fehl, bevor sie die Tool-Grenze überschreiten.

Freigabe, HITL und manuelle Tools

Schütze jeden Aufruf eines Tools mit Nebenwirkungen:
Der Run pausiert mit run.pause.pendingToolCalls. Setze ihn anhand der genauen Call-ID fort, damit parallele Aufrufe nicht verwechselt werden:
Setze execute: false für Aufgaben, die deine Anwendung ausführt, und übergib das Ergebnis über toolOutputs. Gib bei einem interaktiven Tool null aus onToolCalled zurück; nach dem Fortsetzen kann onResponseReceived die menschliche Antwort validieren oder umwandeln.

Tools mit Fortschrittsausgabe

Ein asynchroner Generator kann vorläufige Ergebnisse veröffentlichen und ein endgültiges Ergebnis zurückgeben:
Der Fortschritt erscheint als tool.preliminary_result-Ereignisse und in preliminaryResults des Schritts.

Gestreamte Ergebnisse

stream() startet dieselbe Zustandsmaschine mit einem Streaming-Modell-Client. Die Ergebnisse lassen sich erneut abspielen, sodass UI, Telemetrie und Persistenzcode gleichzeitig lesen können:
Nutze getReasoningStream(), getItemsStream(), getToolStream() oder getFullStream() für spezifischere Streams. cancel() bricht den Run ab.

Typisierte Run-Elemente darstellen

getItemsStream() liefert AgentItem<TOutput>, eine diskriminierte Union, die sich sicher mit switch auswerten lässt:
Derselbe geordnete Elementvertrag steht nach run() oder stream() in completed.items bereit. Die Anbieterausgabe wird in Nachrichten-, Reasoning-, Tool-Aufruf-, Tool-Ergebnis-, Fehler- und Endausgabe-Elemente normalisiert. Anbieterspezifische Felder bleiben über rawProviderItem in den normalisierten Elementen verfügbar.

Stoppbedingungen und dynamische Turns

Stoppbedingungen werden als Array kombiniert. Die erste zutreffende Bedingung speichert den Grund und gibt einen Run mit Status stopped zurück:
Tools können mit context.setContext() den Anwendungskontext festlegen und den unmittelbar folgenden Turn mit nextTurnParams überschreiben.

createGatewayAgentClient()

Nutze den Gateway-Adapter, wenn Modell-Turns über Phaseo Gateway ausgeführt werden sollen. Er kann Gateway-eigene Steuerungen wie die folgenden übertragen:
  • responseFormat
  • plugins
  • gatewayTools
  • toolChoice
  • webSearchOptions
  • providerOptions
  • promptCacheKey
  • includeMeta
So bleiben Routing, Suche, strukturierte Ausgaben und Plugin-Standards nahe am Modell-Client, statt bei jedem Run rohe Anfrage-Payloads neu aufzubauen.

Anwendungseigene Persistenz

Wenn deine Anwendung Runs fortsetzen muss, speichere das zurückgegebene AgentRunResult direkt oder stelle einen state-Zugriff mit asynchronen Methoden load(runId) und save(result) bereit. Ein fortgesetzter Run kann dann runId verwenden, ohne den serialisierten Datensatz durch jede Ebene zu tragen. Das SDK enthält absichtlich weder Persistenzadapter noch ein gehostetes State-Backend. Das bedeutet, du kannst:
  • einmalige Runs vollständig im Prozess halten
  • pausierte oder unvollständige Runs in eigenen Anwendungsdatensätzen serialisieren
  • den gespeicherten Run-Zustand erneut laden und später an continueRun() übergeben

Menschliche Prüfung und Fortsetzung

Nutze humanReview, wenn ein Run einen Checkpoint speichern und auf eine Freigabe warten soll:
Setze den Run mit einer expliziten menschlichen Eingabe fort:

Typisierte Ausgaben

Nutze parseOutput, wenn deine Anwendung einen typisierten Endwert benötigt:
Für ein strengeres Modellverhalten kannst du dies mit strukturierten Ausgaben im Gateway-Adapter kombinieren:

Runtime-Steuerungen

Modell-Wiederholungen

Nutze modelRetry, wenn vorübergehende Modellfehler erneut versucht werden sollen, bevor der Run als failed gespeichert wird:
maxRetries zählt zusätzliche Versuche nach der ersten Modellanfrage. Der gespeicherte Schritt-Datensatz enthält die endgültige Anzahl der Versuche in modelAttempts.

Gleichzeitige lokale Tools

Wenn ein Modell-Turn mehrere unabhängige Tools sicher aufrufen kann, setze toolExecution.toolConcurrency:
Die Runtime erhält weiterhin die Reihenfolge der Tool-Ergebnisnachrichten.

Preset-gesteuertes Routing

Nutze preset, wenn Routing-, Prompt- oder Parameter-Standards im Dashboard verwaltet statt im App-Code fest codiert werden sollen:

Event-Hooks

Nutze onEvent, wenn deine Anwendung Lifecycle-Hooks für Logs, Telemetrie oder interne Workflows benötigt. Zu den aktuellen Ereignissen gehören:
  • run.started
  • run.resumed
  • step.started
  • step.completed
  • step.failed
  • step.cancelled
  • model.requested
  • model.completed
  • model.failed
  • tool.started
  • tool.completed
  • tool.failed
  • checkpoint.saved
  • run.waiting_for_human
  • run.cancelled
  • run.completed
  • run.failed
Wenn ein Schritt erfolgreich ist, sendet die Runtime step.completed, nachdem der Schritt mit Checkpoint gespeichert wurde.

Fehlerbehandlung

Gateway-Fehler werden als AgentGatewayError erneut ausgelöst:
Stammt der Fehler vom Gateway, speichern fehlgeschlagene Runs und Schritte ebenfalls errorDetails.

Enthaltene Beispiele

Das Paket enthält derzeit folgende Beispiele:
  • examples/research-brief-agent.ts
  • examples/support-triage-agent.ts
  • examples/coding-review-agent.ts
  • examples/parallel-tool-agent.ts

Aktueller Umfang

Das SDK konzentriert sich bewusst auf grundlegende Bausteine für die Anwendungsentwicklung:
  • lokale oder anwendungseigene Checkpoint-Persistenz
  • Gateway-gestützte Modell-Turns
  • lokale Tools
  • fortsetzbare Agent-Schleifen
  • normalisierter Token-Verbrauch, Kosten, Warnungen, Endgründe und Tool-Ergebnisse pro Schritt
Es ist weder eine gehostete Orchestrierungsplattform noch enthält es ein vorgegebenes Remote-Persistenz-Backend.

Verwandte Anleitungen

  • Eine robuste Agent-Schleife in TypeScript erstellen(../../cookbook/agent-sdk-durable-loop.mdx)
  • Mit agentengestützter Websuche recherchieren(../../cookbook/agent-sdk-research-brief.mdx)
  • Supportanfragen mit Preset-gesteuerten Agents priorisieren(../../cookbook/agent-sdk-support-triage.mdx)
  • Code mit lokalen Runtime-Tools prüfen(../../cookbook/agent-sdk-coding-review.mdx)
  • Lokale Tools parallel ausführen(../../cookbook/agent-sdk-parallel-tools.mdx)
Zuletzt geändert am 2. Oktober 2026