Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Diese Seite ist der ausführliche API-Referenzentwurf für das öffentliche OpenClaw App SDK. Sie ist absichtlich vom Plugin SDK getrennt.
@openclaw/sdk ist das externe App-/Client-Paket für die Kommunikation mit dem Gateway. openclaw/plugin-sdk/* ist der In-Process-Vertrag für die Plugin-Erstellung. Importieren Sie keine Plugin SDK-Unterpfade aus Apps, die nur Agents ausführen müssen.
Das öffentliche App SDK sollte in zwei Schichten aufgebaut sein:
  1. Ein generierter Gateway-Client auf niedriger Ebene.
  2. Ein ergonomischer High-Level-Wrapper mit OpenClaw-, Agent-, Session-, Run-, Task-, Artifact-, Approval- und Environment-Objekten.

Namespace-Design

Die Low-Level-Namespaces sollten sich eng an den Gateway-Ressourcen orientieren:
oc.agents.list();
oc.agents.get("main");
oc.agents.create(...);
oc.agents.update(...);

oc.sessions.list();
oc.sessions.create(...);
oc.sessions.resolve(...);
oc.sessions.send(...);
oc.sessions.messages(...);
oc.sessions.fork(...);
oc.sessions.compact(...);
oc.sessions.abort(...);

oc.runs.create(...);
oc.runs.get(runId);
oc.runs.events(runId, { after });
oc.runs.wait(runId);
oc.runs.cancel(runId);

oc.tasks.list(); // future API: current SDK throws unsupported
oc.tasks.get(taskId); // future API: current SDK throws unsupported
oc.tasks.cancel(taskId); // future API: current SDK throws unsupported
oc.tasks.events(taskId, { after }); // future API

oc.models.list();
oc.models.status(); // Gateway models.authStatus

oc.tools.list();
oc.tools.invoke(...); // future API: current SDK throws unsupported

oc.artifacts.list({ runId }); // future API: current SDK throws unsupported
oc.artifacts.get(artifactId); // future API: current SDK throws unsupported
oc.artifacts.download(artifactId); // future API: current SDK throws unsupported

oc.approvals.list();
oc.approvals.respond(approvalId, ...);

oc.environments.list(); // future API: current SDK throws unsupported
oc.environments.create(...); // future API: current SDK throws unsupported
oc.environments.status(environmentId); // future API: current SDK throws unsupported
oc.environments.delete(environmentId); // future API: current SDK throws unsupported
High-Level-Wrapper sollten Objekte zurückgeben, die häufige Abläufe angenehm machen:
const run = await agent.run(inputOrParams);
await run.cancel();
await run.wait();

for await (const event of run.events()) {
  // normalized event stream
}

const artifacts = await run.artifacts.list();
const session = await run.session();

Event-Vertrag

Das öffentliche SDK sollte versionierte, erneut abspielbare, normalisierte Events bereitstellen.
type OpenClawEvent = {
  version: 1;
  id: string;
  ts: number;
  type: OpenClawEventType;
  runId?: string;
  sessionId?: string;
  sessionKey?: string;
  taskId?: string;
  agentId?: string;
  data: unknown;
  raw?: unknown;
};
id ist ein Replay-Cursor. Konsumenten sollten sich mit events({ after: id }) erneut verbinden und verpasste Events erhalten können, wenn die Aufbewahrung dies zulässt. Empfohlene normalisierte Event-Familien:
EventBedeutung
run.createdRun akzeptiert.
run.queuedRun wartet auf eine Session-Spur, Runtime oder Umgebung.
run.startedRuntime hat die Ausführung gestartet.
run.completedRun wurde erfolgreich abgeschlossen.
run.failedRun endete mit einem Fehler.
run.cancelledRun wurde abgebrochen.
run.timed_outRun hat sein Timeout überschritten.
assistant.deltaAssistant-Textdelta.
assistant.messageVollständige Assistant-Nachricht oder Ersetzung.
thinking.deltaReasoning- oder Plandelta, wenn die Richtlinie die Offenlegung erlaubt.
tool.call.startedTool-Aufruf hat begonnen.
tool.call.deltaTool-Aufruf hat Fortschritt oder Teilausgabe gestreamt.
tool.call.completedTool-Aufruf wurde erfolgreich zurückgegeben.
tool.call.failedTool-Aufruf ist fehlgeschlagen.
approval.requestedEin Run oder Tool benötigt Genehmigung.
approval.resolvedGenehmigung wurde erteilt, verweigert, ist abgelaufen oder wurde abgebrochen.
question.requestedRuntime fragt den Benutzer oder die Host-App nach Eingaben.
question.answeredHost-App hat eine Antwort bereitgestellt.
artifact.createdNeues Artifact verfügbar.
artifact.updatedVorhandenes Artifact wurde geändert.
session.createdSession erstellt.
session.updatedSession-Metadaten wurden geändert.
session.compactedSession-Compaction ist erfolgt.
task.updatedZustand der Hintergrundaufgabe wurde geändert.
git.branchRuntime hat Branch-Zustand beobachtet oder geändert.
git.diffRuntime hat ein Diff erzeugt oder geändert.
git.prRuntime hat einen Pull Request geöffnet, aktualisiert oder verknüpft.
Runtime-native Payloads sollten über raw verfügbar sein, aber Apps sollten raw für normale UI nicht parsen müssen.

Ergebnisvertrag

Run.wait() sollte einen stabilen Ergebnisumschlag zurückgeben:
type RunResult = {
  runId: string;
  status: "accepted" | "completed" | "failed" | "cancelled" | "timed_out";
  sessionId?: string;
  sessionKey?: string;
  taskId?: string;
  startedAt?: string | number;
  endedAt?: string | number;
  output?: {
    text?: string;
    messages?: SDKMessage[];
  };
  usage?: {
    inputTokens?: number;
    outputTokens?: number;
    totalTokens?: number;
    costUsd?: number;
  };
  artifacts?: ArtifactSummary[];
  error?: SDKError;
};
Das Ergebnis sollte schlicht und stabil sein. Zeitstempelwerte behalten die Gateway-Form bei, sodass aktuelle lifecycle-gestützte Runs normalerweise Epoch-Millisekundenwerte melden, während Adapter weiterhin ISO-Strings bereitstellen können. Umfangreiche UI, Tool-Traces und runtime-native Details gehören in Events und Artifacts. accepted ist ein nicht terminales Warteergebnis: Es bedeutet, dass die Gateway-Wartefrist abgelaufen ist, bevor der Run ein Lifecycle-Ende oder einen Fehler erzeugt hat. Es darf nicht als timed_out behandelt werden; timed_out ist für einen Run reserviert, der sein eigenes Runtime-Timeout überschritten hat.

Genehmigungen und Fragen

Genehmigungen müssen First-Class sein, weil Coding Agents ständig Sicherheitsgrenzen überschreiten.
run.onApproval(async (request) => {
  if (request.kind === "tool" && request.toolName === "exec") {
    return request.approveOnce({ reason: "CI command allowed by policy" });
  }

  return request.askUser();
});
Genehmigungs-Events sollten Folgendes enthalten:
  • Genehmigungs-ID
  • Run-ID und Session-ID
  • Art der Anfrage
  • Zusammenfassung der angeforderten Aktion
  • Tool-Name oder Umgebungsaktion
  • Risikostufe
  • verfügbare Entscheidungen
  • Ablaufzeitpunkt
  • ob die Entscheidung wiederverwendet werden kann
Fragen sind von Genehmigungen getrennt. Eine Frage fordert Informationen vom Benutzer oder von der Host-App an. Eine Genehmigung fragt nach der Erlaubnis, eine Aktion auszuführen.

ToolSpace-Modell

Apps müssen die Tool-Oberfläche verstehen können, ohne Plugin-Interna zu importieren.
const tools = await run.toolSpace();

for (const tool of tools.list()) {
  console.log(tool.name, tool.source, tool.requiresApproval);
}
Das SDK sollte Folgendes bereitstellen:
  • normalisierte Tool-Metadaten
  • Quelle: OpenClaw, MCP, Plugin, Kanal, Runtime oder App
  • Schema-Zusammenfassung
  • Genehmigungsrichtlinie
  • Runtime-Kompatibilität
  • ob ein Tool ausgeblendet, readonly, schreibfähig oder hostfähig ist
Tool-Aufrufe über das SDK sollten explizit und eingegrenzt sein. Die meisten Apps sollten Agents ausführen und nicht beliebige Tools direkt aufrufen.

Artifact-Modell

Artifacts sollten mehr als Dateien abdecken.
type ArtifactSummary = {
  id: string;
  runId?: string;
  sessionId?: string;
  type:
    | "file"
    | "patch"
    | "diff"
    | "log"
    | "media"
    | "screenshot"
    | "trajectory"
    | "pull_request"
    | "workspace";
  title?: string;
  mimeType?: string;
  sizeBytes?: number;
  createdAt: string;
  expiresAt?: string;
};
Häufige Beispiele:
  • Dateiänderungen und generierte Dateien
  • Patch-Bundles
  • VCS-Diffs
  • Screenshots und Medienausgaben
  • Logs und Trace-Bundles
  • Pull-Request-Links
  • Runtime-Trajektorien
  • Snapshots verwalteter Umgebungs-Workspaces
Artifact-Zugriff sollte Schwärzung, Aufbewahrung und Download-URLs unterstützen, ohne anzunehmen, dass jedes Artifact eine normale lokale Datei ist.

Sicherheitsmodell

Das App SDK muss explizit mit Berechtigungen umgehen. Empfohlene Token-Scopes:
ScopeErlaubt
agent.readAgents auflisten und prüfen.
agent.runRuns starten.
session.readSession-Metadaten und Nachrichten lesen.
session.writeSessions erstellen, an sie senden, forken, compacten und abbrechen.
task.readZustand von Hintergrundaufgaben lesen.
task.writeBenachrichtigungsrichtlinie für Aufgaben abbrechen oder ändern.
approval.respondAnfragen genehmigen oder verweigern.
tools.invokeOffengelegte Tools direkt aufrufen.
artifacts.readArtifacts auflisten und herunterladen.
environment.writeVerwaltete Umgebungen erstellen oder zerstören.
adminAdministrative Vorgänge.
Standards:
  • keine Secret-Weiterleitung standardmäßig
  • keine uneingeschränkte Durchleitung von Umgebungsvariablen
  • Secret-Referenzen statt Secret-Werten
  • explizite Sandbox- und Netzwerkrichtlinie
  • explizite Aufbewahrung von Remote-Umgebungen
  • Genehmigungen für Host-Ausführung, sofern die Richtlinie nichts anderes belegt
  • rohe Runtime-Events werden geschwärzt, bevor sie das Gateway verlassen, es sei denn, der Aufrufer hat einen stärkeren Diagnose-Scope

Provider für verwaltete Umgebungen

Verwaltete Agents sollten als Umgebungs-Provider implementiert werden.
type EnvironmentProvider = {
  id: string;
  capabilities: {
    checkout?: boolean;
    sandbox?: boolean;
    networkPolicy?: boolean;
    secrets?: boolean;
    artifacts?: boolean;
    logs?: boolean;
    pullRequests?: boolean;
    longRunning?: boolean;
  };
};
Die erste Implementierung muss kein gehostetes SaaS sein. Sie kann auf bestehende Node-Hosts, kurzlebige Workspaces, CI-artige Runner oder Testbox-artige Umgebungen abzielen. Der wichtige Vertrag lautet:
  1. Workspace vorbereiten
  2. sichere Umgebung und Secrets binden
  3. Run starten
  4. Events streamen
  5. Artifacts sammeln
  6. nach Richtlinie bereinigen oder aufbewahren
Sobald dies stabil ist, kann ein gehosteter Cloud-Dienst denselben Provider-Vertrag implementieren.

Paketstruktur

Empfohlene Pakete:
PaketZweck
@openclaw/sdkÖffentliches High-Level-SDK und generierter Low-Level-Gateway-Client.
@openclaw/sdk-reactOptionale React-Hooks für Dashboards und App-Entwickler.
@openclaw/sdk-testingTesthilfen und Fake-Gateway-Server für App-Integrationen.
Das Repo enthält bereits openclaw/plugin-sdk/* für Plugins. Halten Sie diesen Namespace getrennt, um Plugin-Autoren nicht mit App-Entwicklern zu verwechseln.

Strategie für den generierten Client

Der Low-Level-Client sollte aus versionierten Gateway-Protokollschemata generiert und anschließend durch handgeschriebene, ergonomische Klassen umhüllt werden. Schichtung:
  1. Gateway-Schema als Quelle der Wahrheit.
  2. Generierter Low-Level-TypeScript-Client.
  3. Laufzeitvalidatoren für externe Eingaben und Event-Payloads.
  4. High-Level-Wrapper für OpenClaw, Agent, Session, Run, Task und Artifact.
  5. Cookbook-Beispiele und Integrationstests.
Vorteile:
  • Protokolldrift wird sichtbar
  • Tests können generierte Methoden mit Gateway-Exporten vergleichen
  • Das App-SDK bleibt unabhängig von Interna des Plugin-SDK
  • Low-Level-Consumer behalten vollständigen Protokollzugriff
  • High-Level-Consumer erhalten die kleine Produkt-API

Verwandte Dokumentation