Einen Agenten erstellen
Erstellt einen Agenten aus einer Definition. Das Schrittlimit der Definition gilt für jeden Run- oder Continue-Aufruf.Felder der Definition
Rust baut die Definition mit Methoden statt Feldern:AgentDefinition::new(id, model), dann .instructions(text), .tool(tool) (einmal pro Tool), .max_steps(limit), .model_retries(count, backoff) und .human_review(callback). AgentDefinition in Java ist ein Record mit Konstruktoren für 10, 13 und 19 Argumente.
In TypeScript können
model, instructions und die Sampling-Werte fest oder dynamisch sein.
Ein Tool definieren
Unter Tools ist jedes Tool-Feld aufgeführt.
Mit dem Phaseo Gateway verbinden
Unter Ausgaben und Wiederholungen sind die Client-Optionen in jeder Sprache aufgeführt.
Läufe lokal aufzeichnen
Siehe DevTools.
Stoppbedingungen
Go und Java geben eine
StopCondition zurück; C# gibt eine Func<StopState, (bool Stop, string Reason)> zurück; PHP gibt ein callable zurück; Ruby gibt ein Lambda zurück. Rust hat keine Stoppbedingungen, nur das Schrittlimit. Siehe Stoppbedingungen.
Ausführen und fortsetzen
Run und Continue geben ein Laufergebnis zurück: ein
Promise<AgentRunResult> in TypeScript, (RunResult, error) in Go, Task<RunResult> in C#, Result<RunResult, AgentError> in Rust und sonst direkt das Laufergebnis. Stream-Methoden geben sofort ein Stream-Ergebnis zurück.
Laufoptionen
PHP und Ruby nehmen diese als benannte bzw. Keyword-Argumente;RunOptions in Java ist ein positionaler Record in der Reihenfolge input, client, context, model, preset, maxSteps, modelRetry, toolExecution, onEvent, devtools, danach optional state.
run() in Python akzeptiert außerdem stop_when, ignoriert es aber; setze Stoppbedingungen in der Definition. stream() in PHP und stream in Ruby nehmen nur input, client, context und state. Rust erstellt Standardwerte mit RunOptions::new(input).
Fortsetzungsoptionen
Fortsetzungsoptionen nehmen die obigen Laufüberschreibungen und zusätzlich:
Die Reihenfolge von
ContinueOptions in Java ist run, client, context, model, preset, maxSteps, humanInput, modelRetry, toolExecution, onEvent, devtools, dann approvals, rejections, toolOutputs, dann runId, state. Neben dieser Form mit 16 Argumenten gibt es Konstruktoren, die nur die ersten 11 oder die ersten 14 Argumente nehmen; der Rest wird mit leeren Listen oder null belegt. Rust erstellt Standardwerte mit ContinueOptions::new(result).
Stream-Ergebnis
Consumer spielen von Anfang an ab, sodass mehrere denselben Lauf lesen können. Ihr Verhalten unterscheidet sich:
Laufergebnis
Der Typ ist
AgentRunResult in TypeScript und Python und sonst RunResult. TypeScript ergänzt stepResults (normalisierte Schrittergebnisse) und items (geordnete Nachrichten, Reasoning, Tool-Aktivität, Fehler und endgültige Ausgabe; siehe Items). In Rust ist output ein serde_json::Value, und RunResult, RunRecord, RunStep, Message, ToolCall, HumanPause, PendingToolCall, ToolDecision, ToolOutput und UsageSummary werden mit Serde serialisiert.
Laufeintrag
RunRecord in Rust speichert außerdem das effektive Modell und das Schrittlimit. TypeScript ergänzt errorDetails mit Details zu Gateway-Fehlern.
Die Laufstatus sind queued, running, waiting_for_tools, waiting_for_human, completed, stopped und failed. TypeScript ergänzt cancelled.
Schritteintrag
Der Typ ist überall
RunStep, außer in TypeScript und Python (AgentStepRecord).
Nutzungsübersicht
inputTokens, outputTokens, cachedTokens, totalTokens, cost (TypeScript, Java); input_tokens, output_tokens, cached_tokens, total_tokens, cost (Schlüssel in Python, PHP und Ruby, Rust); InputTokens, OutputTokens, CachedTokens, TotalTokens, Cost (Go, C#). Der Typ ist AgentUsageSummary in TypeScript und Python und UsageSummary in Go, C#, Java und Rust. PHP und Ruby verwenden ein Array bzw. einen Hash. Einschränkungen zu cost stehen unter Beobachtbarkeit.
Pausen und Entscheidungen
Die Feldnamen folgen dem Stil der jeweiligen Sprache:
toolCallId (TypeScript, PHP, Java), tool_call_id (Python, Ruby, Rust), ToolCallID (Go) und ToolCallId (C#). ToolDecision in Rust dient nur der Freigabe. Siehe Status und Freigabe.
An Tools übergebener Laufzeitkontext
Status-Accessor
Modell-Clients
Implementiere einen Modell-Client, um Modell-Turns über einen anderen Transport zu senden oder den Gateway-Client zu umhüllen.
In Rust enthält
ModelRequest die Agenten-ID, das effektive Modell, die Anweisungen, die aktuellen Nachrichten, die Tool-Spezifikationen (ToolSpec: id, description, JSON-Schema parameters) und den Anwendungskontext. ModelResponse enthält message, usage, request_id, provider, model und finish_reason. Message hat role, content, tool_calls, tool_call_id, name und is_error, mit den Konstruktoren Message::user(content) und Message::assistant(content); ToolCall hat id, name und JSON-input.
Events und Fehler
TypeScript exportiert außerdem
agentErrorIsRetryable(), agentRetryAfterMs() und agentErrorIsContextOverflow() zum Einordnen von Fehlern, repairToolHistory(messages), um Tool-Aufrufe ohne Ergebnis zu beantworten und Ergebnisse ohne zugehörigen Aufruf zu entfernen, sowie truncateToolOutput(text, limit), um Anfang und Ende langer Texte mit einem Hinweis auf das Gekürzte zu behalten. Siehe Lifecycle-Hooks und Events und Fehler.