Einen benannten Cloudflare-Support-Agent erstellen

Einführung

Ein KI-Agent wird häufig als Modell beschrieben, das schlussfolgern oder Tools verwenden kann. Bevor ein Modell hinzukommt, benötigt eine Anwendung jedoch eine zuverlässige Antwort auf eine einfachere Frage: Welche laufende Sitzung soll diese Anfrage erhalten? Eine Support-Anwendung muss jede Interaktion für planning an dieselbe logische Sitzung senden und billing gleichzeitig getrennt halten.

Das Agents SDK von Cloudflare stellt dafür die übergeordnete Klasse Agent bereit. Jeder benannte Agent basiert auf einer SQLite-Instanz eines Durable Object. Das SDK verwaltet gespeicherten Zustand und Anfrage-Routing, während Durable Objects darunter die stabile Identität und den Speicher bereitstellen. Sie sehen beide Ebenen, statt das SDK als Magie zu behandeln.

Sie erstellen eine kleine, bewusst nicht auf einem LLM basierende Support-Anwendung:

SupportAgent legt fest, was eine Support-Sitzung speichert und tut.
Das Binding SupportAgent repräsentiert den Klassen-Namespace.
/agents/support-agent/planning wählt die Instanz mit dem Namen planning aus.
initialState, this.state und setState() ermöglichen es dem SDK, den kleinen Zustand dieser Instanz dauerhaft zu speichern.

Sie schreiben zwei Notizen in eine benannte Sitzung, weisen nach, dass eine andere Sitzung isoliert bleibt, stoppen und starten die vollständige lokale Laufzeit neu, stellen denselben Code auf Cloudflare bereit, prüfen das tatsächliche Binding und den Namespace im Dashboard und entfernen anschließend alle nur für diesen Versuch erstellten Ressourcen.

Bevor Sie diesen Kurs beginnen, absolvieren Sie LabEx mit Ihrem Cloudflare-Konto verbinden. Dort lernen Sie das LabEx-VM-Terminal, die Geräteautorisierung mit Wrangler, die Kontobestätigung und die Konfiguration der Konto-ID kennen. Sie sollten bereits mit einem kleinen TypeScript-Worker und dem Identitätsmodell von Durable Objects aus O01–O06 vertraut sein. Kenntnisse über das Agents SDK, React oder Modelle werden nicht vorausgesetzt.

Die offizielle Dokumentation stellt SQLite-basierte Durable Objects derzeit im Workers-Free-Tarif bereit. In diesem Lab erstellen Sie einen entfernbaren Klassen-Namespace, einige kleine Agent-Instanzen und führen nur begrenzte Anfragen aus. Es wird kein Modell aufgerufen, und Workers Paid ist nicht erforderlich. Das Setup installiert Node.js 22.22.0, Agents SDK 0.23.0 und Wrangler 4.134.0 als lokale Projektabhängigkeit unter /home/labex/project/named-support-agent. Es meldet Sie nicht an, erstellt keinen Cloud-Zustand, stellt keinen Code bereit und schließt die Implementierung durch Sie nicht ab.

Die VM autorisieren und den Agent konfigurieren

In diesem Schritt autorisieren Sie Wrangler, bestätigen das vorgesehene Lernkonto und beschreiben eine Agent-Klasse, ohne sie bereits bereitzustellen. Diese neue VM hat ein eigenes Dateisystem. Eine Anmeldung im Cloudflare-Dashboard autorisiert daher nicht automatisch das Terminal der VM.

Wechseln Sie in das vorbereitete Projekt und prüfen Sie die festgelegten Versionen:

cd /home/labex/project/named-support-agent
node --version
npx wrangler --version
npm list agents --depth=0

Erwartet werden Node.js v22.22.0, Wrangler 4.134.0 und agents@0.23.0. Die festen Versionen sind wichtig, weil sich das Agents SDK schneller ändert als grundlegende Worker-APIs.

Starten Sie den Geräteautorisierungsablauf:

npx wrangler login --device --browser=false

Wrangler gibt eine Browser-URL und einen kurzen Gerätecode aus. Öffnen Sie die URL, geben Sie den Code ein, bestätigen Sie, dass das ausgewählte Konto Ihr dafür vorgesehenes Lernkonto ist, und prüfen Sie vor der Autorisierung die angeforderten Berechtigungen. Geben Sie niemals ein Cloudflare-Passwort oder API-Token im Terminal ein.

Kehren Sie zum Terminal zurück, sobald der Browser den Erfolg meldet, und warten Sie, bis Wrangler den Vorgang beendet. Fordern Sie strukturierte Identitätsinformationen an:

npx wrangler whoami --json

Bestätigen Sie loggedIn: true. Lassen Sie anschließend nur die Kontonamen anzeigen und wählen Sie die ID von LabEx Learning privat aus:

WHOAMI="$(npx wrangler whoami --json)"
printf '%s\n' "$WHOAMI" | jq '{loggedIn, authType, accounts: [.accounts[] | {name}]}'
ACCOUNT_ID="$(printf '%s\n' "$WHOAMI" | jq -r '.accounts[] | select(.name == "LabEx Learning") | .id')"
test -n "$ACCOUNT_ID"

Wenn Ihr eigenes Lernkonto einen anderen Anzeigenamen hat, ersetzen Sie LabEx Learning erst, nachdem Sie den korrekten Namen bestätigt haben. Die Konto-ID ist keine geheime Information. Dieser Befehl vermeidet jedoch, sie unnötig auszugeben.

Erstellen Sie einen eindeutigen Namen für den entfernbaren Worker:

RUN="labex-c11-s01-$(openssl rand -hex 6)"
printf '%s\n' "$RUN"

Erstellen Sie wrangler.jsonc:

cat > wrangler.jsonc <<JSON
{
  "\$schema": "./node_modules/wrangler/config-schema.json",
  "name": "$RUN",
  "account_id": "$ACCOUNT_ID",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-18",
  "compatibility_flags": ["nodejs_compat"],
  "workers_dev": true,
  "preview_urls": false,
  "observability": {
    "enabled": true,
    "head_sampling_rate": 1
  },
  "durable_objects": {
    "bindings": [
      { "name": "SupportAgent", "class_name": "SupportAgent" }
    ]
  },
  "migrations": [
    { "tag": "v1", "new_sqlite_classes": ["SupportAgent"] }
  ]
}
JSON

Das Binding SupportAgent ist der Zugriff des Workers auf den Klassen-Namespace. Die Migration v1 weist Cloudflare an, diese Klasse mit SQLite-Speicher zu erstellen. Agents verwenden die Infrastruktur von Durable Objects; das SDK entfernt diese Ressourcenebene nicht. nodejs_compat wird derzeit vom SDK benötigt. Keine dieser Deklarationen erstellt Cloud-Ressourcen, solange Sie noch keine Bereitstellung durchführen.

Den benannten Support-Agent implementieren

In diesem Schritt implementieren Sie den Zustand und das HTTP-Verhalten, das alle benannten Support-Sitzungen gemeinsam verwenden. Eine Agent-Klasse beschreibt das wiederverwendbare Verhalten, während eine Agent-Instanz eine einzelne benannte Sitzung wie planning ist. Cloudflare kann viele Instanzen derselben Klasse ausführen, und jede Instanz besitzt einen unabhängigen Zustand.

Erstellen Sie src/index.ts:

cat > src/index.ts <<'TS'
import { Agent, routeAgentRequest } from "agents";

export interface SupportState {
  status: "new" | "active";
  noteCount: number;
  lastNote: string | null;
}

interface Env {
  SupportAgent: DurableObjectNamespace<SupportAgent>;
}

function json(value: unknown, init: ResponseInit = {}): Response {
  const headers = new Headers(init.headers);
  headers.set("content-type", "application/json; charset=utf-8");
  return new Response(JSON.stringify(value, null, 2), { ...init, headers });
}

export class SupportAgent extends Agent<Env, SupportState> {
  initialState: SupportState = {
    status: "new",
    noteCount: 0,
    lastNote: null
  };

  async onRequest(request: Request): Promise<Response> {
    if (request.method === "GET") {
      console.log(JSON.stringify({ event: "support_agent_read", instance: this.name, noteCount: this.state.noteCount }));
      return json({ instance: this.name, ...this.state });
    }

    if (request.method === "POST") {
      const body = await request.json<{ note?: unknown }>().catch(() => null);
      const note = typeof body?.note === "string" ? body.note.trim() : "";
      if (note.length < 1 || note.length > 120) {
        return json({ error: "note must contain 1-120 characters" }, { status: 400 });
      }

      this.setState({
        status: "active",
        noteCount: this.state.noteCount + 1,
        lastNote: note
      });
      console.log(JSON.stringify({ event: "support_agent_updated", instance: this.name, noteCount: this.state.noteCount }));
      return json({ instance: this.name, ...this.state });
    }

    return json({ error: "method not allowed" }, { status: 405 });
  }
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    if (url.pathname === "/health") {
      return json({ status: "ok" });
    }

    const agentResponse = await routeAgentRequest(request, env, {
      onBeforeRequest(incoming, { name }) {
        if (!/^[a-z][a-z0-9-]{1,31}$/.test(name)) {
          return json({ error: "invalid support session name" }, { status: 400 });
        }
        return incoming;
      }
    });
    return agentResponse ?? json({ error: "not found" }, { status: 404 });
  }
} satisfies ExportedHandler<Env>;
TS

Lesen Sie die wichtigen Teile von innen nach außen:

initialState ist der Wert, den eine neu angelegte benannte Instanz erhält.
this.state liest den aktuellen, vom SDK verwalteten Zustand dieser Instanz.
setState() prüft den Ersatz-Zustand synchron und speichert ihn im SQLite-Speicher der Instanz. In späteren Labs wird dieser Zustand zusätzlich mit verbundenen Clients synchronisiert.
this.name ist der stabile Instanzname, den das Routing auswählt. Es handelt sich nicht um einen Klassennamen oder eine zufällige Prozess-ID.
routeAgentRequest() ordnet /agents/<binding>/<name> dem korrekten Agent zu. Das Binding SupportAgent wird in der URL zu support-agent.
onBeforeRequest weist ungültig formatierte Namen zurück, bevor eine Durable-Object-Instanz ausgewählt wird. So werden unerwünschte dauerhafte Identitäten vermieden.

Das Protokoll enthält nur einen künstlichen Instanznamen und den Zähler. Der Text der Notiz wird absichtlich nicht protokolliert, damit die spätere Dashboard-Übung keine Support-Inhalte speichert.

Typen generieren und vor dem Start bauen

In diesem Schritt generieren Sie konfigurationsabhängige Typen und bauen den Worker, ohne ihn bereitzustellen. Die generierten Worker-Typen verbinden die Konfiguration mit TypeScript. Dadurch wird beispielsweise ein falsch geschriebenes Binding oder ein falscher Klassenname erkannt, bevor ein lokaler Prozess oder eine Cloud-Bereitstellung Zeit verbraucht.

Generieren Sie Typen aus wrangler.jsonc:

npx wrangler types

Wrangler schreibt worker-configuration.d.ts. Prüfen Sie, ob die konfigurierte Agent-Bindung enthalten ist, ohne andere generierte Inhalte auszugeben:

grep -n "SupportAgent" worker-configuration.d.ts | head

Führen Sie den TypeScript-Compiler aus:

npm run check

Wenn nach der Kopfzeile des Scripts keine Ausgabe erscheint, wurden keine Compilerfehler gefunden. Lassen Sie Wrangler nun das Bereitstellungspaket erstellen, ohne Cloudflare zu kontaktieren oder eine Ressource anzulegen:

npx wrangler deploy --dry-run --outdir .labex/dry-run

Erwartet werden eine erfolgreiche Zusammenfassung der Upload-Größe und das Binding des Durable Objects SupportAgent. Ein dry run prüft das lokale Bundling und die Konfiguration. Er beweist weder die Autorisierung noch den entfernten Speicher oder das Verhalten am Edge.

Lokale Identität und Persistenz nach einem Neustart nachweisen

In diesem Schritt weisen Sie drei verschiedene Eigenschaften nach: Die wiederholte Verwendung eines Namens erreicht denselben Zustand, ein anderer Name bleibt isoliert, und gespeicherter Zustand bleibt nach einem vollständigen Neustart des Entwicklungsprozesses erhalten.

Starten Sie die lokale Workers-Laufzeit im Hintergrund:

npm run dev > .labex/dev.log 2>&1 &
echo $! > .labex/dev.pid
for attempt in $(seq 1 30); do
  if curl --silent --fail http://127.0.0.1:8787/health; then
    break
  fi
  sleep 1
done

Erwartet wird {"status":"ok"}. Lesen Sie den neuen Agent planning:

curl --silent http://127.0.0.1:8787/agents/support-agent/planning | jq

Er beginnt mit status: "new", noteCount: 0 und lastNote: null. Fügen Sie zwei künstliche Notizen hinzu:

curl --silent --request POST --header 'content-type: application/json' \
  --data '{"note":"Customer cannot open the invoice"}' \
  http://127.0.0.1:8787/agents/support-agent/planning | jq
curl --silent --request POST --header 'content-type: application/json' \
  --data '{"note":"Asked customer to retry"}' \
  http://127.0.0.1:8787/agents/support-agent/planning | jq

Die zweite Antwort meldet instance: "planning", status: "active", noteCount: 2 und die zweite Notiz. Beide Anfragen verwendeten denselben Namen in der URL und erreichten daher denselben logischen Agent.

Lesen Sie eine andere Instanz:

curl --silent http://127.0.0.1:8787/agents/support-agent/support | jq

support besitzt weiterhin seinen eigenen Anfangszustand mit dem Zähler 0. Die beiden Namen verwenden dasselbe Klassenverhalten, teilen aber keine gespeicherten Werte.

Weisen Sie einen ungültig formatierten Namen zurück:

curl --silent --write-out '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8787/agents/support-agent/INVALID

Erwartet werden invalid support session name und HTTP 400.

Stoppen Sie genau den gestarteten Prozess und starten Sie anschließend einen neuen Prozess mit demselben lokalen Persistenzverzeichnis:

kill "$(cat .labex/dev.pid)"
wait "$(cat .labex/dev.pid)" 2>/dev/null || true
npm run dev > .labex/dev-restart.log 2>&1 &
echo $! > .labex/dev.pid
for attempt in $(seq 1 30); do
  if curl --silent --fail http://127.0.0.1:8787/health; then
    break
  fi
  sleep 1
done
curl --silent http://127.0.0.1:8787/agents/support-agent/planning | jq
curl --silent http://127.0.0.1:8787/agents/support-agent/support | jq

Nach einem vollständigen Neustart von Wrangler bleibt planning bei 2, während support bei 0 bleibt. Das ist ein stärkerer Beleg als zweimaliges Lesen innerhalb desselben JavaScript-Prozesses: Die Daten wurden aus dem lokalen Persistenzverzeichnis des Durable Object wiederhergestellt.

Bereitstellen und Cloud-Agent-Instanzen testen

In diesem Schritt stellen Sie die unveränderte Anwendung bereit und testen echte, von der Cloud verwaltete Agent-Instanzen. Lokale Ergebnisse können nicht beweisen, dass das ausgewählte Cloudflare-Konto die Ressource besitzt oder dass die Edge-Laufzeit dieselbe benannte Identität bereitstellt.

Stoppen Sie den lokalen Prozess und stellen Sie die Anwendung bereit:

kill "$(cat .labex/dev.pid)"
wait "$(cat .labex/dev.pid)" 2>/dev/null || true
npx wrangler deploy

Wrangler wendet die Migration v1 an, erstellt den SQLite-basierten Klassen-Namespace SupportAgent und gibt eine öffentliche workers.dev-URL aus. Speichern Sie genau diese URL, indem Sie das Beispiel ersetzen:

WORKER_URL="https://YOUR_WORKER_URL"

Warten Sie auf die zustandslose Health-Route:

for attempt in $(seq 1 30); do
  if curl --silent --fail "$WORKER_URL/health"; then
    break
  fi
  sleep 2
done

Testen Sie nun die von der Cloud verwalteten Instanzen mit künstlichen Daten:

curl --silent --request POST --header 'content-type: application/json' \
  --data '{"note":"Cloud planning note one"}' \
  "$WORKER_URL/agents/support-agent/planning" | jq
curl --silent --request POST --header 'content-type: application/json' \
  --data '{"note":"Cloud planning note two"}' \
  "$WORKER_URL/agents/support-agent/planning" | jq
curl --silent --request POST --header 'content-type: application/json' \
  --data '{"note":"Independent support note"}' \
  "$WORKER_URL/agents/support-agent/support" | jq

Lesen Sie beide Instanzen:

curl --silent "$WORKER_URL/agents/support-agent/planning" | jq
curl --silent "$WORKER_URL/agents/support-agent/support" | jq

Der Cloud-Agent planning hat den Zähler 2, der unabhängige Agent support den Zähler 1. Lokaler und Cloud-Speicher sind absichtlich getrennt, aber beide Umgebungen implementieren denselben Vertrag zwischen Namen und Instanz.

Der Verifizierer erstellt außerdem zwei für den Durchlauf eindeutige Agent-Namen und wiederholt die Prüfung des Anfangszustands, der Persistenz bei gleichem Namen, der Isolation bei verschiedenen Namen und der Zurückweisung ungültiger Namen. Eine lokale Datei oder Befehlshistorie wird niemals als Beleg für Remote-Verhalten gewertet.

Laufzeitbelege mit dem Dashboard verknüpfen

In diesem Schritt verknüpfen Sie das Verhalten im Terminal mit dem Binding, dem Namespace und den im Dashboard sichtbaren Logs. Namen, Zeitstempel und Gesamtzahlen in den Screenshots stammen aus dem getesteten Durchlauf. Verwenden Sie den eindeutigen Namen labex-c11-s01-... aus Ihrem eigenen Terminal.

Öffnen Sie im Cloudflare-Dashboard Workers & Pages und wählen Sie Ihren entfernbaren Worker aus. Die Übersicht identifiziert die bereitgestellte Anwendung und den aktuellen Datenverkehr.

Der bereitgestellte benannte Support-Agent-Worker in Workers and Pages

Öffnen Sie den Tab Bindings des Workers. Suchen Sie SupportAgent, das mit der Durable-Object-Klasse SupportAgent verbunden ist. Die erste Bezeichnung ist der Name, den Worker-Code und Routing verwenden. Der Klassenname identifiziert die aus src/index.ts exportierte Implementierung.

Das mit seiner Durable-Object-Klasse verbundene SupportAgent-Binding

Öffnen Sie über die Navigation der Developer Platform Durable Objects und wählen Sie den Namespace aus, der Ihrem exakten Worker gehört. Bestätigen Sie die Klasse SupportAgent und Storage: SQL. Der Namespace ist die Sammlung auf Klassenebene. planning, support und die Namen des Verifizierers sind einzelne Instanzen innerhalb dieser Sammlung. Das Beispielbild lässt seine laufspezifische Namespace-ID aus Datenschutzgründen weg.

Der SupportAgent-Namespace mit SQL-Speicher

Kehren Sie zum Worker zurück und öffnen Sie Observability → Logs. Suchen und erweitern Sie ein Anwendungsereignis support_agent_read oder support_agent_updated. Vergleichen Sie dessen künstliche Werte für instance und noteCount mit einer begrenzten Anfrage. Die Anwendung protokolliert absichtlich keinen Notiztext.

Ein strukturiertes Support-Agent-Ereignis mit Instanzname und Notizzähler

Dashboard-Metriken und Logs können verspätet eintreffen. Ein leeres aktuelles Diagramm ist daher nicht aussagekräftig. Die authentifizierte API, der Besitz des Namespace und die Live-Prüfungen der Laufzeit bleiben maßgeblich. Die Screenshots zeigen, an welcher Stelle dieselben Beziehungen visuell erscheinen; sie sind keine Abgaben der Lernenden.

Den Agent-Namespace und den Worker entfernen

In diesem Schritt entfernen Sie den exakten Agent-Namespace und den Worker dauerhaft, solange die VM noch autorisiert ist. Der Zustand des Agents gehört zum Klassen-Namespace des Durable Object. Nur das Worker-Skript zu löschen ist daher keine ausdrückliche Aufforderung, diesen gespeicherten Zustand zu löschen. Cloudflare-Migrationen sind nur erweiterbar: Behalten Sie v1 bei und fügen Sie anschließend eine Löschmigration v2 für genau diese Klasse hinzu.

Erstellen Sie einen kleinen Bereitstellungseinstiegspunkt ohne Agent-Export:

cat > src/cleanup.ts <<'TS'
export default {
  fetch() {
    return Response.json({ status: "cleanup" }, { status: 410 });
  }
};
TS

Lesen Sie den exakten Namen und das Konto aus der ursprünglichen Konfiguration und erstellen Sie anschließend wrangler.cleanup.jsonc:

RUN="$(node -e 'console.log(JSON.parse(require("fs").readFileSync("wrangler.jsonc", "utf8")).name)')"
ACCOUNT_ID="$(node -e 'console.log(JSON.parse(require("fs").readFileSync("wrangler.jsonc", "utf8")).account_id)')"
cat > wrangler.cleanup.jsonc <<JSON
{
  "\$schema": "./node_modules/wrangler/config-schema.json",
  "name": "$RUN",
  "account_id": "$ACCOUNT_ID",
  "main": "src/cleanup.ts",
  "compatibility_date": "2026-09-18",
  "compatibility_flags": ["nodejs_compat"],
  "workers_dev": true,
  "preview_urls": false,
  "migrations": [
    { "tag": "v1", "new_sqlite_classes": ["SupportAgent"] },
    { "tag": "v2", "deleted_classes": ["SupportAgent"] }
  ]
}
JSON

Das Beibehalten von v1 ist wichtig: Die Migrationshistorie ist eine Abfolge und keine Beschreibung, die neu geschrieben werden sollte. v2 entfernt den Klassen-Namespace und alle darin enthaltenen, für diesen Versuch erstellten benannten Instanzen dauerhaft.

Stellen Sie die Löschmigration bereit:

npx wrangler deploy --config wrangler.cleanup.jsonc

Lesen Sie die Ausgabe der Migration und bestätigen Sie, dass nur SupportAgent Ihres eindeutigen Workers gelöscht wird. Löschen Sie anschließend den verbleibenden zustandslosen Cleanup-Worker:

npx wrangler delete --config wrangler.cleanup.jsonc --force

Bestätigen Sie bei einer Nachfrage die exakte Anwendung labex-c11-s01-.... Prüfen Sie unter Workers & Pages, dass der exakte Worker nicht mehr vorhanden ist. Dieses Testkonto enthält keine anderen Anwendungen. Beim erfolgreichen Durchlauf wird daher die gesamte Liste leer. Ein Konto mit anderen Projekten sollte diese nicht betroffenen Einträge behalten.

Workers and Pages ohne Projekte, nachdem der entfernbare Worker gelöscht wurde

Öffnen Sie Durable Objects und prüfen Sie, dass auch der Namespace des gelöschten Workers nicht mehr vorhanden ist. Im akzeptierten Testkonto gibt es keine anderen Namespaces, daher meldet die Liste keine Durable Objects. Löschen Sie nicht den Namespace eines anderen Projekts, nur um dieses Beispiel nachzustellen.

Durable Objects ohne Namespaces, nachdem die SupportAgent-Klasse entfernt wurde

Historische Logs können vorübergehend erhalten bleiben und sind keine aktiven Ressourcen.

Führen Sie die authentifizierte Prüfung auf Abwesenheit vor der Abmeldung aus:

python3 .labex/verify.py deleted

Nur PASS: deleted beweist, dass das ausgewählte Konto keine der beiden zugehörigen Ressourcen mehr enthält. Ein 404-Fehler aufgrund verlorener Autorisierung oder ein Netzwerkfehler gilt nicht als Beleg für die Löschung.

Die Autorisierung dieser VM widerrufen

In diesem Schritt entfernen Sie die in dieser entfernbaren VM gespeicherte OAuth-Autorisierung. Die Bereinigung von Cloud-Ressourcen und lokalen Zugangsdaten löst unterschiedliche Probleme. Worker und Namespace wurden bereits entfernt.

Melden Sie sich ab:

npx wrangler logout

Fordern Sie den strukturierten Status von Wrangler an:

npx wrangler whoami --json

Das Ergebnis muss ausdrücklich "loggedIn": false enthalten. Dieser strukturierte Wert ist aussagekräftiger als eine benutzerfreundliche Meldung, da die getestete Wrangler-Version in mehreren Authentifizierungszuständen normale Ausgaben erzeugen kann. Ein Netzwerkfehler ist nicht eindeutig. Wiederholen Sie den Befehl, statt ihn als Abmeldung zu interpretieren.

Sie haben beide Arten von Zustand entfernt, die dieses Lab erstellt hat: den entfernten Support-Agent-Namespace und Worker sowie die lokale Autorisierung der VM.

Zusammenfassung

Sie haben den ersten Cloudflare-Agent des Kurses erstellt, ohne die Grundlage hinter KI-Begriffen zu verbergen. Sie haben gelernt, dass eine Agent-Klasse das Verhalten definiert, ihr Binding einen SQLite-basierten Durable-Object-Namespace bereitstellt, ein stabiler Name in der URL eine logische Instanz auswählt und das Agents SDK Aktualisierungen von initialState über this.state und setState() dauerhaft speichert.

Sie haben lokal die Persistenz desselben Namens, die Isolation verschiedener Namen und die Beständigkeit nach einem Prozessneustart nachgewiesen, denselben Vertrag in Ihrem Cloudflare-Lernkonto wiederholt, Laufzeitbelege mit Binding, Namespace und datenschutzbegrenzten Logs im Dashboard verknüpft und sowohl die Cloud-Ressourcen als auch die VM-Autorisierung entfernt. Im nächsten Lab verbinden Sie Browser-Clients mit diesem Zustand und führen eine kontrollierte Echtzeitsynchronisierung ein.

Einen benannten Support-Agent erstellen