Project Think: Die nächste Generation von KI-Agenten auf Cloudflare entwickeln

Heute stellen wir Project Think vor: die nächste Generation des Agenten-SDK. Project Think besteht aus einer Reihe neuer Grundbausteine für die Erstellung lang laufender Agenten (dauerhafte Ausführung, Unteragenten, Codeausführung in Sandboxen, persistente Sitzungen) und einer vorgabebasierten Basisklasse, die diese miteinander verbindet. Sie können mithilfe dieser Grundbausteine genau das erstellen, was Sie brauchen, oder mit der Basisklasse schnell loslegen.

Anfang dieses Jahres ist etwas passiert, das unsere Sicht auf KI verändert hat. Werkzeuge wie Pi, OpenClaw, Claude Code und Codex haben sich als einfach, aber wirkungsvoll erwiesen: Gibt man einem LLM die Möglichkeit, Dateien zu lesen, Programmcode zu verfassen, ihn auszuführen und sich das Gelernte zu merken, dann entsteht daraus etwas, das größere Ähnlichkeit mit einem universellen Assistenten als mit einem Entwicklertool hat.

Solche Programmieragenten beschränken sich nicht auf das Schreiben von Quellcode. Man kann damit Kalender verwalten, Datensätze analysieren, Käufe abwickeln, die Steuererklärung einreichen und komplette Geschäftsabläufe automatisieren. Das Muster ist immer das gleiche: Der Agent erfasst den Kontext, denkt darüber nach, schreibt Programmcode für die erforderlichen Maßnahmen, begutachtet das Ergebnis und nimmt Iterationen vor. Quellcode bildet die Grundlage für alle Vorgänge.

Unser Team verwendet diese Coding-Agenten tagtäglich. Dabei stoßen wir immer wieder auf dieselben Probleme:

• Sie laufen nur auf einem bestimmten Laptop oder einem teuren VPS: Es gibt weder einen Austausch noch eine Zusammenarbeit oder eine Übergabe zwischen Geräten.

• Ihre Nichtnutzung ist kostspielig: Unabhängig davon, ob der Agent gerade im Einsatz ist, fällt eine feste monatliche Gebühr an. Rechnet man das auf ein ganzes Team oder ein Unternehmen hoch, kommt schnell eine beträchtliche Summe zusammen.

• Sie müssen verwaltet und manuell eingerichtet werden: Man muss sich um die Installation von Abhängigkeiten, Updates und die Konfiguration von Identität und Geheimnissen kümmern.

Es besteht aber noch ein tieferliegendes strukturelles Problem. Herkömmliche Anwendungen versorgen viele Nutzer über eine einzige Instanz. Doch wie in unserem Beitrag „Willkommen bei der Agents Week“ erläutert, funktionieren Agenten nach dem „Eins-zu-eins“-Prinzip. Jeder Agent ist eine gesonderte Instanz und führt für einen einzigen Nutzer eine einzige Aufgabe aus. Ein Restaurant hat eine Küche, die darauf ausgelegt ist, die Gerichte auf der Speisekarte in großen Mengen zuzubereiten. Ein Agent ist aber eher mit einem persönlichen Koch vergleichbar, der jedes Mal andere Zutaten, andere Techniken und andere Utensilien verwendet.

Somit muss man beim Skalieren ganz anders rechnen. Würden 100 Millionen Wissensarbeiter jeweils einen agentenbasierten Assistenten verwenden, wären dafür selbst bei moderater Parallelität Kapazitäten für zig Millionen gleichzeitige Sitzungen erforderlich. Das ist bei den derzeit pro Container anfallenden Kosten nicht tragfähig. Deshalb wird ein anderes Fundament benötigt.

Und genau das haben wir entwickelt.

Project Think liefert eine Reihe neuer Grundbausteine für das Agenten-SDK:

• Langlebige Ausführung mit Fiber: Wiederherstellung nach Absturz, Checkpointing, automatisches Keep-alive

• Unteragenten: isolierte untergeordnete Agenten mit ihrer eigenen SQLite-Bibliothek und typisiertem RPC

• Persistente Sitzungen: Nachrichten mit Baumstruktur, Abspaltung, Komprimierung, Volltextsuche

• Codeausführung in Sandboxen: dynamische Worker, Codemodus, Laufzeit-npm-Auflösung

• Ausführungskette: Arbeitsbereich, isolierte Instanz, npm, Browser, Sandbox

• Selbstverfasste Erweiterungen: Agenten, die ihre eigenen Tools während der Laufzeit schreiben

Jede dieser Komponenten kann direkt mit der Basisklasse „Agent“ verwendet werden. Anhand der Grundbausteine können Sie genau das erschaffen, was Sie brauchen. Alternativ ermöglicht Ihnen die Basisklasse „Think“ einen schnellen Einstieg. Als Nächstes schauen wir uns an, wofür diese Elemente genutzt werden können.

Heutige Agenten sind kurzlebig. Sie laufen eine Sitzung lang, sind an einen einzelnen Prozess oder ein Gerät gebunden, und verschwinden danach wieder. Bei einem Programmieragenten, dessen Existenz endet, wenn Ihr Laptop in den Ruhezustand wechselt, handelt es sich um ein Werkzeug. Ein langlebiger Agent, der bei Bedarf aus dem Ruhezustand geholt werden kann, die Arbeit nach Unterbrechungen fortsetzt und den Zustand aufrechterhält, ohne von der lokalen Laufzeitumgebung abhängig zu sein, hat größere Ähnlichkeit mit einer Infrastruktur. Außerdem verändert sich dadurch das Skalierungsmodell für Agenten vollständig.

Das Agenten-SDK baut auf Durable Objects auf. Damit verfügt jeder Agenten über eine Identität, einen dauerhaften Zustand und die Möglichkeit, bei einer Nachricht aus dem Ruhezustand „aufzuwachen“. Man spricht hier vom Akteurmodell: Jeder Agent ist eine adressierbare Einheit mit einer eigenen SQLite-Datenbank. Im Ruhezustand verbraucht er keine Rechenleistung. Bei einem Ereignis (einer HTTP-Anfrage, einer WebSocket-Nachricht, einem geplanten Alarm, einer eingehenden E-Mail) wird der Agent von der Plattform aus dem Ruhezustand geholt. Sie lädt dann seinen Zustand und übergibt ihm das Ereignis. Der Agent erledigt seine Arbeit und wechselt anschließend wieder in den Ruhezustand.

	VM / Container	Durable Objects
Leerlaufkosten	Immer volle Rechenleistungskosten	Null (Ruhezustand)
Skalierung	Bereitstellung und Verwaltung von Kapazität	Automatisch, pro Agent
Zustand	Externe Datenbank erforderlich	Integrierte SQLite-Datenbank
Wiederherstellung	Von Ihnen entwickelt (Prozessmanager, Integritätsprüfungen)	Plattform-Neustart, Zustand bleibt bestehen
Identität / Routing	Sie entwickeln die Lösung (Lastverteilung, Sticky Sessions)	Integriert (Name → Agent)
10.000 Agenten, jeweils 1 % der Zeit aktiv	10.000 dauerhaft aktive Instanzen	ca. 100 jederzeit aktiv

Dadurch verändern sich die wirtschaftlichen Rahmenbedingungen für den Betrieb von Agenten in großem Maßstab. Man kann nun anstelle eines teuren Agenten pro Power-User einen Agenten pro Kunde, einen Agenten pro Aufgabe oder einen Agenten pro E-Mail-Thread erstellen. Die Grenzkosten für die Erschaffung eines neuen Agenten liegen praktisch bei Null.

Ein LLM-Aufruf dauert 30 Sekunden. Eine mehrstufige Agentenschleife kann deutlich mehr Zeit in Anspruch nehmen. Zu jedem Zeitpunkt innerhalb dieses Zeitfensters kann die Ausführungsumgebung verschwinden: durch eine Bereitstellung, einen Neustart der Plattform oder das Erreichen von Ressourcengrenzen. Die vorgelagerte Verbindung zum Modellanbieter wird dauerhaft unterbrochen, der Speicherzustand geht verloren und die verbundenen Clients verzeichnen einen Abbruch des Streams ohne Erklärung.

runFiber() löst dieses Problem. Ein Fiber ist ein dauerhafter Funktionsaufruf: Er wird vor Beginn der Ausführung in SQLite registriert, kann jederzeit über stash() überprüft werden und ist bei einem Neustart über onFiberRecovered wiederherstellbar.

import { Agent } from "agents";

export class ResearchAgent extends Agent {
  async startResearch(topic: string) {
    void this.runFiber("research", async (ctx) => {
      const findings = [];

      for (let i = 0; i < 10; i++) {
        const result = await this.callLLM(`Research step ${i}: ${topic}`);
        findings.push(result);

        // Checkpoint: if evicted, we resume from here
        ctx.stash({ findings, step: i, topic });

        this.broadcast({ type: "progress", step: i });
      }

      return { findings };
    });
  }

  async onFiberRecovered(ctx) {
    if (ctx.name === "research" && ctx.snapshot) {
      const { topic } = ctx.snapshot;
      await this.startResearch(topic);
    }
  }
}

Das SDK hält den Agenten während der Fiber-Ausführung automatisch aktiv, eine spezielle Konfiguration ist nicht erforderlich. Bei Aufgaben, die nur wenige Minuten dauern, verhindern keepAlive() / keepAliveWhile(), dass der Agent während der aktiven Ausführung beendet wird. Bei längeren Vorgängen (CI-Pipelines, Designprüfungen, Videogenerierung) startet der Agent die Aufgabe, dann speichert er die Job-ID, wechselt in den Ruhezustand und wird bei einem Callback wieder aktiviert.

Ein einzelner Agent sollte nicht die ganze Arbeit allein erledigen. Unteragenten sind untergeordnete Durable Objects, die über Facets gemeinsam mit dem übergeordneten Object untergebracht sind, wobei jedes Object über seine eigene isolierte SQLite-Datenbank und seinen eigenen Ausführungskontext verfügt:

import { Agent } from "agents";

export class ResearchAgent extends Agent {
  async search(query: string) { /* ... */ }
}

export class ReviewAgent extends Agent {
  async analyze(query: string) { /* ... */ }
}

export class Orchestrator extends Agent {
  async handleTask(task: string) {
    const researcher = await this.subAgent(ResearchAgent, "research");
    const reviewer = await this.subAgent(ReviewAgent, "review");

    const [research, review] = await Promise.all([
      researcher.search(task),
      reviewer.analyze(task)
    ]);

    return this.synthesize(research, review);
  }
}

Unteragenten sind auf Speicherebene isoliert. Jeder erhält seine eigene SQLite-Datenbank, und es findet kein impliziter Datenaustausch zwischen Unteragenten statt. Dies wird durch die Laufzeitumgebung sichergestellt, in der die RPC-Latenz der Unteragenten einem Funktionsaufruf entspricht. TypeScript erkennt Fehlverwendungen zum Zeitpunkt der Kompilierung.

Agenten, die tage- oder wochenlang laufen, benötigen mehr als die typische einfache Liste von Nachrichten. Die experimentelle Session-API bildet dies explizit ab. In der Basisklasse „Agent“ werden Konversationen als Baumstrukturen gespeichert, wobei jede Nachricht mit einer „parent_id“ versehen ist. Das ermöglicht Verzweigungen (das Ausloten einer Alternative ohne Verlust des ursprünglichen Pfads), nicht-destruktive Komprimierung (das Zusammenfassen älterer Nachrichten anstatt ihrer Löschung) sowie die Volltextsuche im gesamten Konversationsverlauf mittels FTS5.

import { Agent } from "agents";
import { Session, SessionManager } from "agents/experimental/memory/session";

export class MyAgent extends Agent {
  sessions = SessionManager.create(this);

  async onStart() {
    const session = this.sessions.create("main");
    const history = session.getHistory();
    const forked = this.sessions.fork(session.id, messageId, "alternative-approach");
  }
}

Session kann direkt mit dem Agenten verwendet werden und es ist die Speicherebene, auf der die Basisklasse „Think“ aufbaut.

Die herkömmliche Aufrufweise von Tools ist umständlich. Das Modell ruft ein Tool auf, holt das Ergebnis durch das Kontextfenster zurück, ruft ein weiteres Tool auf, holt auch dieses zurück und so weiter. Mit wachsender Tool-Oberfläche wird dieses Verfahren sowohl teuer als auch unhandlich. Hundert Dateien bedeuten hundert Runden durch das Modell.

Doch Modelle sind besser darin, Quellcode für die Nutzung eines Systems zu schreiben, als Tools aufzurufen. Auf dieser Erkenntnis beruht @cloudflare/codemode. Anstelle von sequenziellen Tool-Aufrufen schreibt das LLM ein einziges Programm, das die gesamte Aufgabe erledigt.

// The LLM writes this. It runs in a sandboxed Dynamic Worker.
const files = await tools.find({ pattern: "**/*.ts" });
const results = [];
for (const file of files) {
  const content = await tools.read({ path: file });
  if (content.includes("TODO")) {
    results.push({ file, todos: content.match(/\/\/ TODO:.*/g) });
  }
}
return results;

Anstelle von 100 Runden von Modellaufrufen und Antworten wird nur ein einziges Programm ausgeführt. Die Folge sind ein geringerer Tokenverbrauch, eine schnellere Ausführung und bessere Ergebnisse. Der API-MCP-Server von Cloudflare demonstriert dies in großem Maßstab. Wir stellen nur zwei Tools (search() und execute()) bereit, die etwa 1.000 Token verbrauchen, im Vergleich zu rund 1,17 Millionen Token bei einem gleichwertigen einfachen Tool pro Endpunkt. Das stellt eine Reduzierung um 99,9 % dar.

Wenn man akzeptiert, dass Modelle im Namen der Nutzer Quellcode schreiben, stellt sich die Frage: Wo werden diese Programme ausgeführt? Und zwar nicht irgendwann und auch nicht, nachdem ein Produktteam daraus einen Roadmap-Eintrag erstellt hat. Sondern genau jetzt, für diesen Nutzer, für dieses System, mit genau definierten Berechtigungen.

Dynamische Workers bilden die dafür nötige Sandbox. Eine neue isolierte V8-Instanz wird zur Laufzeit in Millisekunden mit ein paar Megabyte Arbeitsspeicher erstellt. Das macht diese Lösung etwa hundertmal schneller und bis zu hundertmal speichereffizienter als einen Container. Für jede einzelne Anfrage kann eine neue isolierte Instanz gestartet, ein Codesnippet ausgeführt und die Instanz dann wieder ausgemustert werden.

Entscheidend ist die Wahl des richtigen Funktionsmodells. Anstatt mit einem Allzweckgerät anzufangen und zu versuchen, dieses zu beschränken, beginnen Dynamic Workers fast ohne Umgebungsautorisierung (globalOutbound: null, kein Netzwerkzugriff) und der Entwickler gibt Funktionen explizit – Ressource für Ressource – durch Bindungen frei. Die Überlegung lautet also nicht mehr „Wie lässt sich verhindern, dass dieses Tool zu viel tut?“, sondern „Was genau soll dieses Tool tun können?“.

Das ist die richtige Frage, wenn es um Agenteninfrastruktur geht.

Dieses Funktionsmodell führt natürlich zu einem ganzen Spektrum von Rechenumgebungen, einer Ausführungskette, die der Agent bei Bedarf durchläuft:

Stufe 0 ist der Arbeitsbereich, ein dauerhaftes virtuelles Dateisystem, das von SQLite und R2 unterstützt wird. Lesen, Schreiben, Bearbeiten, Suchen, Filtern und Vergleichen werden von @cloudflare/shell unterstützt.

Stufe 1 ist ein Dynamic Worker: ein LLM-generiertes JavaScript-Programm, das in einer isolierten Sandbox ohne Netzwerkzugang ausgeführt und von @cloudflare/codemode unterstützt wird.

Stufe 2 fügt npm hinzu. @cloudflare/worker-bundler ruft Pakete aus der Registrierungsdatenbank ab, bündelt sie mit esbuild und lädt das Ergebnis in den Dynamic Worker. Der Agent schreibt import { z } from „zod“ und es funktioniert einfach.

Stufe 3 ist ein Headless-Browser über Cloudflare Browser Run. Navigieren, Klicken, Extrahieren, Screenshot machen. Diese Option ist hilfreich, wenn ein Dienst Agenten noch nicht per MCP oder API unterstützt.

Stufe 4 ist eine Cloudflare-Sandbox, die mit Ihren Toolchains, Repositorys und Abhängigkeiten konfiguriert ist: git clone, npm test, cargo build. Es erfolgt eine bidirektionale Synchronisierung mit dem Arbeitsbereich.

Das oberste Prinzip bei der Gestaltung: Der Agent sollte bereits auf Stufe 0 nützlich sein und mit jeder Stufe an Nützlichkeit hinzugewinnen. Funktionen können also nach und nach hinzugefügt werden.

Alle diese Bausteine sind als eigenständige Pakete verfügbar. Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler und @cloudflare/shell (ein dauerhaftes Dateisystem mit Tools) sind alle direkt mit der Basisklasse „Agent“ verwendbar. Sie können kombiniert werden, um jedem Agenten einen Arbeitsbereich, Codeausführung und die Auflösung von Laufzeitpaketen zur Verfügung zu stellen, ohne sich auf ein bestimmtes Framework festlegen zu müssen.

Hier der vollständige Stack zur Erstellung von Agenten auf Cloudflare:

Funktion	Vorteil	Unterstützt von
Isolierung pro Agent	Jeder Agent ist eigenständig	Durable Objects (DO)
Keine Kosten im Leerlauf	0 $, bis der Agent aus dem Ruhezustand aufwacht	DO-Ruhezustand
Dauerhafter Zustand	Abfragefähiger, transaktionaler Speicher	DO-SQLite
Permanentes Dateisystem	Dateien sind nach einem Neustart noch vorhanden	Arbeitsbereich (SQLite + R2)
Codeausführung in der Sandbox	Sicheres Ausführen von LLM-generiertem Quellcode	Dynamische Workers + @cloudflare/codemode
Laufzeitabhängigkeiten	import * from react funktioniert einfach	@cloudflare/worker-bundler
Web-Automatisierung	Durchsuchen, navigieren und Formulare ausfüllen	Browser Run
Vollzugriff auf das Betriebssystem	git, Compiler, Test-Runner	Sandboxen
Zeitgesteuerte Ausführung	Nicht nur reaktiv, sondern proaktiv	DO-Warnmeldungen + Fibers
Streaming in Echtzeit	Token für Token an jeden Client	WebSockets
Externe Werkzeuge	Verbindungen zu einem beliebigen Tool-Server	MCP
Agentenkoordination	Typisierter RPC zwischen Agenten	Unteragenten (Facets)
Modellzugriff	Verbindung zu einem LLM für den Betrieb des Agenten	AI Gateway + Workers AI (oder Bring Your Own Model)

Jede dieser Komponenten ist ein Baustein. Zusammen ergeben sie etwas Neues: eine Plattform, auf der jeder KI-Agenten entwickeln, bereitstellen und ausführen kann, die genauso leistungsfähig sind wie die, die heute auf Ihrem lokalen Rechner laufen – jedoch serverlos, langlebig und von Grund auf sicher.

Nachdem Sie nun einen Überblick über die Grundbausteine haben, schauen wir uns an, was passiert, wenn diese miteinander vernetzt werden.

Think ist ein vorgabebasierter Rahmen, der den gesamten Lebenszyklus eines Chats abdeckt: Agentenschleife, Persistenz von Nachrichten, Streaming, Ausführung von Tools, Wiederaufnahme des Streams und Erweiterungen. Sie können sich auf das konzentrieren, was Ihren Agenten einzigartig macht.

Die minimale Unterklasse sieht wie folgt aus:

import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";

export class MyAgent extends Think<Env> {
  getModel() {
    return createWorkersAI({ binding: this.env.AI })(
      "@cf/moonshotai/kimi-k2.5"
    );
  }
}

Das ist praktisch alles, was Sie für einen funktionierenden Chat-Agenten mit Streaming, Persistenz, Abbruch, Fehlerbehandlung, wiederaufnehmbaren Streams und einem integrierten Arbeitsbereich-Dateisystem benötigen. Die Bereitstellung erfolgt mit npx wrangler deploy.

Think trifft Entscheidungen für Sie. Doch wenn Sie mehr Kontrolle brauchen, können Sie in den Fällen, die Ihnen wichtig sind, das Ruder übernehmen.

Überschreiben	Zweck
getModel()	Gibt das zu verwendende Sprachmodell zurück
getSystemPrompt()	System-Prompt
getTools()	KI-SDK kompatibles ToolSet für die Agentenschleife
maxSteps	Maximale Zahl von Tool-Aufrufen pro Durchlauf
configureSession()	Kontextblöcke, Komprimierung, Suche, Fähigkeiten

Im Hintergrund durchläuft Think bei jedem Durchgang den gesamten Agentenzyklus: Die Lösung stellt den Kontext zusammen (Basisbefehle + Tool-Beschreibungen + Fähigkeiten + Speicher + Unterhaltungsverlauf), ruft streamText auf, führt Tool-Aufrufe aus (mit Kürzung der Ausgaben, um eine Überschreitung der Kontextgrenze zu verhindern), hängt die Ergebnisse an und wiederholt diesen Vorgang, bis das Modell fertig ist oder das Limit der Schritte erreicht ist. Alle Nachrichten werden nach jedem Durchgang gespeichert.

Think bietet Ihnen in jeder Phase des Chat-Ablaufs Hooks, ohne dass Sie die gesamte Pipeline selbst verwalten müssen:

beforeTurn()
  → streamText()
    → beforeToolCall()
    → afterToolCall()
  → onStepFinish()
→ onChatResponse()

Sie können für nachfolgende Durchgänge zu einem günstigeren Modell wechseln, die verfügbaren Tools einschränken und bei jedem Durchgang den clientseitigen Kontext übergeben. Außerdem können Sie jeden Tool-Aufruf in der Analyse protokollieren und automatisch einen weiteren Folge-Durchlauf auslösen, sobald das Modell den vorherigen abgeschlossen hat – und das alles, ohne onChatMessage zu ersetzen.

Think baut auf der Session-API als Speicherschicht auf und bietet Ihnen Nachrichten in einer Baumstruktur mit integrierter Verzweigung.

Darüber hinaus wird durch Kontextblöcke ein Permanentspeicher hinzugefügt. Es handelt sich um strukturierte Abschnitte des System-Prompts, die das Modell lesen und im Lauf der Zeit aktualisieren kann. Außerdem bleiben diese über den Ruhezustand hinaus bestehen. Das Modell sieht „MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]“ und kann sich proaktiv an Dinge erinnern.

configureSession(session: Session) {
  return session
    .withContext("soul", {
      provider: { get: async () => "You are a helpful coding assistant." }
    })
    .withContext("memory", {
      description: "Important facts learned during conversation.",
      maxTokens: 2000
    })
    .withCachedPrompt();
}

Die Sitzungen sind flexibel. Pro Agent lassen sich mehrere Unterhaltungen ausführen und aufteilen, um eine andere Richtung auszuprobieren, ohne dass das Original verloren geht. 

Bei wachsendem Kontext bewältigt Think die Grenzen mit nicht-destruktiver Komprimierung: Ältere Nachrichten werden nicht gelöscht, sondern zusammengefasst, während der vollständige Verlauf in SQLite gespeichert wird. 

Auch eine Suchfunktion ist integriert. Mit FTS5 kann der Unterhaltungsverlauf innerhalb einer Sitzung oder für alle Sitzungen abgefragt werden. Der Agent ist auch in der Lage, seine eigene Vergangenheit mit dem search_context-Tool zu durchsuchen.

Think fasst die gesamte Ausführungskette in einem einzigen Rückgabewert von getTools() zusammen:

import { Think } from "@cloudflare/think";
import { createWorkspaceTools } from "@cloudflare/think/tools/workspace";
import { createExecuteTool } from "@cloudflare/think/tools/execute";
import { createBrowserTools } from "@cloudflare/think/tools/browser";
import { createSandboxTools } from "@cloudflare/think/tools/sandbox";
import { createExtensionTools } from "@cloudflare/think/tools/extensions";

export class MyAgent extends Think<Env> {
  extensionLoader = this.env.LOADER;

  getModel() {
    /* ... */
  }

  getTools() {
    return {
      execute: createExecuteTool({
        tools: createWorkspaceTools(this.workspace),
        loader: this.env.LOADER
      }),
      ...createBrowserTools(this.env.BROWSER),
      ...createSandboxTools(this.env.SANDBOX), // configured per-agent: toolchains, repos, snapshots
      ...createExtensionTools({ manager: this.extensionManager! }),
      ...this.extensionManager!.getTools()
    };
  }
}

Bei der Codeausführung geht Think einen Schritt weiter. Ein Agent kann eigene Erweiterungen schreiben: TypeScript-Programme, die in Dynamic Workers ausgeführt werden und Berechtigungen für den Netzwerkzugriff und Arbeitsbereichsvorgänge festlegen.

{
  "name": "github",
  "description": "GitHub integration: PRs, issues, repos",
  "tools": ["create_pr", "list_issues", "review_pr"],
  "permissions": {
    "network": ["api.github.com"],
    "workspace": "read-write"
  }
}

Der ExtensionManager von Think bündelt die Erweiterung (optional mit npm-Abhängigkeiten über @cloudflare/worker-bundler), lädt sie in einen Dynamic Worker und registriert die neuen Tools. Die Erweiterung verbleibt im DO-Speicher und überdauert den Ruhezustand. Wenn der Nutzer das nächste Mal nach Pull-Anfragen fragt, verfügt der Agent über ein Tool namens github_create_pr“, das vor 30 Sekunden noch nicht existierte.

Durch diese Art von Selbstverbesserungsschleife werden Agenten mit der Zeit immer nützlicher. Dies geschieht nicht durch Feinabstimmung oder RLHF, sondern durch Programmierung. Der Agent ist in der Lage, für sich selbst neue Fähigkeiten zu programmieren – und zwar vollständig in überprüfbarem und widerrufbarem TypeScript in einer Sandbox.

Think funktioniert auch als Unteragent, der über chat() per RPC von einem übergeordneten Prozess aufgerufen wird, wobei Ereignisse per Callback gestreamt werden:

const researcher = await this.subAgent(ResearchSession, "research");
const result = await researcher.chat(`Research this: ${task}`, streamRelay);

Jedes untergeordnete Element erhält einen eigenen Konversationsbaum, einen eigenen Speicher, eigene Werkzeuge und ein eigenes Modell. Der übergeordnete Prozess muss die Details nicht kennen.

Project Think ist experimenteller Natur. Die API-Oberfläche ist stabil, wird sich aber in den kommenden Tagen und Wochen weiterentwickeln. Wir nutzen die Lösung bereits intern, um unsere eigene Infrastruktur für Hintergrundagenten aufzubauen, und stellen sie schon jetzt zur Verfügung, damit Sie sie für Ihre Projekte verwenden können.

npm install @cloudflare/think agents ai @cloudflare/shell zod workers-ai-provider

// src/server.ts
import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
import { routeAgentRequest } from "agents";

export class MyAgent extends Think<Env> {
  getModel() {
    return createWorkersAI({ binding: this.env.AI })(
      "@cf/moonshotai/kimi-k2.5"
    );
  }
}

export default {
  async fetch(request: Request, env: Env) {
    return (
      (await routeAgentRequest(request, env)) ||
      new Response("Not found", { status: 404 })
    );
  }
} satisfies ExportedHandler<Env>;

// src/client.tsx
import { useAgent } from "agents/react";
import { useAgentChat } from "@cloudflare/ai-chat/react";

function Chat() {
  const agent = useAgent({ agent: "MyAgent" });
  const { messages, sendMessage, status } = useAgentChat({ agent });
  // Render your chat UI
}

Think nutzt dasselbe WebSocket-Protokoll wie @cloudflare/ai-chat, sodass vorhandene Benutzeroberflächen-Komponenten sofort einsatzbereit sind. Wenn Sie auf AIChatAgent aufgesetzt haben, ändert sich Ihr Client-Quellcode nicht.

Wir unterscheiden bei KI-Agenten zwischen drei Wellen:

Bei der ersten Welle handelte es sich um Chatbots. Diese waren zustandslos, reaktiv und fehleranfällig. Man fing bei jeder neuen Unterhaltung wieder bei Null an – ohne Erinnerung, ohne Tools und ohne Handlungsspielraum. Dadurch waren diese Chatbots bei der Beantwortung von Fragen hilfreich, aber auch auf diese Funktion beschränkt.

Programmieragenten bildeten die zweite Welle. Dabei handelt es sich um zustandsbehaftete, weitaus leistungsfähigere Lösungen wie Pi, Claude Code, OpenClaw und Codex, die Tools nutzen. Diese Agenten können Codebasen lesen, Quellcode schreiben, ihn ausführen und iterieren. Sie haben bewiesen, dass ein LLM mit den richtigen Werkzeugen ein Allzweckprodukt ist. Doch sie laufen auf Ihrem Laptop, für einen einzelnen Nutzer und ohne Garantien hinsichtlich der Langlebigkeit.

Gerade entsteht die dritte Welle: Agenten als Infrastruktur. Diese sind langlebig, verteilt, strukturell sicher und serverlos. Es handelt sich um Agenten, die im Internet laufen, Ausfälle überstehen, im Leerlauf keine Kosten verursachen und Sicherheit eher durch ihre Architektur als durch ihr Verhalten gewährleisten. Jeder Entwickler kann sie für eine beliebige Anzahl von Nutzern erstellen und implementieren.

Auf diese Entwicklung setzen wir.

Das Agenten-SDK läuft bereits für Tausende von Agenten im Produktivbetrieb. Mit Project Think und den darin enthaltenen Grundbausteinen ergänzen wir die fehlenden Elemente, um diese Agenten deutlich leistungsfähiger zu machen: dauerhafte Arbeitsbereiche, Codeausführung in einer Sandbox, langlebige und lang laufende Aufgaben, strukturelle Sicherheit, Abstimmung zwischen Unteragenten und selbst erstellte Erweiterungen.

Die Lösung ist ab heute als Preview verfügbar. Wir wollen Ihnen diese zur Entwicklung bereitstellen und sind schon gespannt, was Sie (und Ihr Coding-Agent) damit erschaffen.

---

^{Think ist Teil des Agenten-SDK von Cloudflare und verfügbar als @cloudflare/think. Die in diesem Beitrag beschriebenen Funktionen befinden sich in der Preview-Phase. An den API werden möglicherweise aufgrund von Rückmeldungen noch Änderungen vorgenommen. Wenn Sie loslegen möchten, finden Sie hier die Dokumentation und ein Beispiel.}