Oggi presentiamo Project Think: la nuova generazione di Agents SDK. Project Think è un set di nuove primitive per la creazione di agenti a lunga esecuzione (esecuzione duratura, subagenti, esecuzione di codice in modalità sandbox, sessioni persistenti) e una classe di base prescrittiva che li collega tutti insieme. Utilizza le primitive per creare esattamente ciò di cui hai bisogno o utilizza la classe di base per iniziare rapidamente.
All'inizio di quest'anno è successo qualcosa che ha cambiato il modo in cui pensiamo all'IA. Strumenti come Pi, OpenClaw, Claude Code e Codex si sono rivelati un'idea semplice ma potente: dare a un LLM la capacità di leggere file, scrivere codice, eseguirlo e ricordare cosa ha imparato, e ottenere qualcosa che assomiglia meno a uno strumento di sviluppo e più a un assistente generico.
Questi agenti di codifica non si limitano più a scrivere codice. Le persone li utilizzano per gestire calendari, analizzare set di dati, negoziare acquisti, pagare le tasse e automatizzare interi flussi di lavoro aziendali. Il modello è sempre lo stesso: l'agente legge il contesto, ragiona su questo, scrive il codice per agire, osserva il risultato e itera. Il codice è il mezzo d'azione universale.
Il nostro team utilizza questi agenti di codifica ogni giorno. E abbiamo continuato a imbatterci negli stessi muri:
Funzionano solo sul tuo laptop o su un costoso VPS: non c'è condivisione, collaborazione o trasferimento tra dispositivi.
Sono costosi quando sono inattivi: un costo mensile fisso indipendentemente dal fatto che l'agente venga utilizzato o meno. Somma tutto questo all'interno di un team o di un'azienda e il costo lievita in breve tempo.
Richiedono gestione e configurazione manuale: installazione di dipendenze, gestione degli aggiornamenti, configurazione di identità e segreti.
E c'è un problema strutturale più profondo. Le applicazioni tradizionali servono molti utenti da un'unica istanza. Come accennato nel nostro post Ti diamo il benvenuto alla Agents Week, gli agenti sono one-to-one. Ogni agente è un'istanza unica, che serve un utente ed esegue un'attività. Un ristorante ha un menù e una cucina ottimizzata per sfornare piatti in base alle richieste. Un agente è più simile a uno chef personale: ingredienti diversi, tecniche diverse, strumenti diversi ogni volta.
Questo cambia radicalmente la complessità in termini di scalabilità. Se cento milioni di knowledge worker utilizzassero ciascuno un assistente agentico anche con una simultaneità modesta, sarebbe necessaria una capacità per decine di milioni di sessioni simultanee. Agli attuali costi per container, questo è insostenibile. Abbiamo bisogno di una base diversa.
Stiamo realizzando proprio questo.
Project Think fornisce una serie di nuove primitive per Agents SDK:
Esecuzione duratura con le fibre: ripristino dagli arresti anomali, checkpoint, keepalive automatico
Subagenti: agenti secondari isolati con il proprio SQLite e RPC tipizzato
Sessioni persistenti: messaggi strutturati ad albero, forking, compattazione, ricerca full-text
Esecuzione di codice in modalità sandbox: Dynamic Worker, codemode, risoluzione npm di runtime
La scala di esecuzione: workspace, isolato, npm, browser, sandbox
Estensioni autoprodotte: agenti che scrivono i propri strumenti in fase di runtime
Ognuno di questi è utilizzabile direttamente con la classe di base Agent. Crea esattamente ciò di cui hai bisogno con le primitive oppure utilizza la classe di base Think per iniziare rapidamente. Diamo un'occhiata a cosa fa ciascuno.
Agenti a lunga esecuzione
Gli agenti, così come esistono oggi, sono temporanei. Vengono eseguiti per una sessione, legati a un singolo processo o dispositivo, e poi scompaiono. Un agente di codifica che si interrompe quando il tuo laptop va in stand-by è uno strumento. Un agente persistente, in grado di riattivarsi su richiesta, continuare a operare dopo le interruzioni e mantenere lo stato senza dipendere dal runtime locale, inizia ad assomigliare a un'infrastruttura. E cambia completamente il modello di scalabilità per gli agenti.
Agents SDK si basa su Durable Objects per fornire a ogni agente un'identità, uno stato persistente e la possibilità di riattivarsi alla ricezione di un messaggio. Questo è il modello dell'attore: ogni agente è un'entità indirizzabile con il proprio database SQLite. Non consuma alcuna risorsa di elaborazione quando è in modalità di ibernazione. Quando accade qualcosa (una richiesta HTTP, un messaggio WebSocket, un allarme programmato, un'e-mail in entrata) la piattaforma riattiva l'agente, ne carica lo stato e gli passa l'evento. L'agente svolge il suo lavoro, quindi torna ad essere inattivo.
| VM/container | Durable Objects |
|---|
Costo di inattività | Costo di elaborazione completo, sempre | Zero (in modalità di ibernazione) |
Scalabilità | Provisioning e gestione della capacità | Automatico, per agente |
Stato | Database esterno richiesto | SQLite integrato |
Recupero | Lo realizzi tu (gestori di processo, controlli di integrità) | La piattaforma si riavvia, lo stato sopravvive |
Identità/routing | Lo realizzi tu (bilanciatori del carico, sessioni permanenti) | Integrato (nome → agente) |
10.000 agenti, ciascuno attivo l'1% delle volte | 10.000 istanze sempre attive | Circa 100 attivi in qualsiasi momento |
Questo cambia il modello economico della gestione degli agenti su larga scala. Invece di "un agente costoso per utente avanzato", puoi creare "un agente per cliente" o "un agente per attività" o "un agente per thread di e-mail". Il costo marginale della generazione di un nuovo agente è effettivamente zero.
Sopravvivere agli arresti anomali: esecuzione duratura con fibre
Una chiamata LLM richiede 30 secondi. Un loop di agente multi-turno può durare molto più a lungo. In qualsiasi momento durante quella finestra, l'ambiente di esecuzione può svanire: una distribuzione, il riavvio di una piattaforma, il raggiungimento dei limiti delle risorse. La connessione upstream al provider del modello viene interrotta in modo permanente, lo stato in-memory viene perso e i client connessi vedono il flusso interrotto senza alcuna spiegazione.
runFiber() risolve questo problema. Una fibra è una chiamata di funzione duratura: registrata in SQLite prima dell'inizio dell'esecuzione, controllabile in qualsiasi momento tramite stash() e recuperabile al riavvio tramite onFiberRecovered.
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);
}
}
}
L'SDK mantiene l'agente attivo automaticamente durante l'esecuzione della fibra, senza necessità di una configurazione speciale. Per il lavoro misurato in minuti, keepAlive()/keepAliveWhile() impedisce l'eliminazione durante il lavoro attivo. Per le operazioni più lunghe (pipeline CI, revisioni di design, generazione di video), l'agente avvia il lavoro, mantiene l'ID del processo, va in modalità di ibernazione e si riattiva al callback.
Delega del lavoro: subagenti tramite Facets
Un singolo agente non dovrebbe fare tutto da solo. I subagenti sono Durable Objects secondari collocati insieme a quello principale tramite Facets, ciascuno con il proprio SQLite isolato e il proprio contesto di esecuzione:
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);
}
}
I subagenti sono isolati a livello di archiviazione. Ognuno ha il proprio database SQLite e non c'è condivisione implicita di dati tra di loro. Ciò viene imposto dal runtime in cui la latenza RPC del subagente è una chiamata di funzione. TypeScript rileva un uso improprio in fase di compilazione.
Conversazioni che persistono: l'API Session
Gli agenti che vengono eseguiti per giorni o settimane hanno bisogno di più del tipico elenco semplice di messaggi. L'API Session sperimentale lo modella esplicitamente. Disponibili sulla classe di base Agent, le conversazioni vengono archiviate come strutture ad albero, in cui ogni messaggio ha un parent_id. Questo consente il fork (esplora un'alternativa senza perdere il percorso originale), la compattazione non distruttiva (riepiloga i messaggi meno recenti anziché eliminarli) e la ricerca full-text nella cronologia delle conversazioni tramite 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 è utilizzabile direttamente con Agent ed è il livello di archiviazione su cui si basa la classe di base Think.
Il richiamo degli strumenti convenzionale ha una forma complicata. Il modello richiama uno strumento, recupera il risultato attraverso la finestra di contesto, richiama un altro strumento, lo recupera e così via. Man mano che la superficie del sistema cresce, ciò diventa sia costoso che maldestro. Cento file significano cento viaggi di andata e ritorno attraverso il modello.
Ma i modelli sono più bravi a scrivere codice per utilizzare un sistema che a gestire il richiamo degli strumenti. Questa è l'intuizione alla base di @cloudflare/codemode: invece di richiamare gli strumenti in modo sequenziale, l'LLM scrive un singolo programma che gestisce l'intera attività.
// 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;
Invece di 100 viaggi di andata e ritorno al modello, esegui semplicemente un singolo programma. Questo consente di utilizzare un minor numero di token, avere un'esecuzione più rapida e fruire di risultati migliori. Il server Cloudflare API MCP lo dimostra su larga scala. Esponiamo solo due strumenti (search() e execute()), che consumano circa 1.000 token, rispetto a circa 1,17 milioni di token per l'equivalente non ottimizzato di uno strumento per endpoint. Si tratta di una riduzione del 99,9%.
La primitiva mancante: sandbox sicure
Una volta accettato che i modelli debbano scrivere codice per conto degli utenti, la domanda diventa: dove viene eseguito tale codice? Non alla fine, non dopo che un team di prodotto lo ha trasformato in un elemento della roadmap. In questo momento, per questo utente, con questo sistema, con autorizzazioni ben definite.
I Dynamic Worker sono quella sandbox. Un nuovo isolato V8 è stato creato in fase di runtime, in millisecondi, con pochi megabyte di memoria. È circa 100 volte più veloce e fino a 100 volte più efficiente in termini di memoria rispetto a un container. Puoi avviarne uno nuovo per ogni singola richiesta, eseguire un frammento di codice ed eliminarlo.
La scelta progettuale critica è il modello di capacità. Invece di iniziare con una macchina generica e provare a vincolarla, i Dynamic Worker iniziano con quasi nessuna autorità ambientale (globalOutbound: null, nessun accesso alla rete) e lo sviluppatore concede le funzionalità in modo esplicito, risorsa per risorsa, tramite binding. Passiamo dal chiederci "come possiamo impedire a questa cosa di fare troppo?" a "cosa vogliamo esattamente che questa cosa sia in grado di fare?"
Questa è la domanda giusta per l'infrastruttura per agenti.
Questo modello di capacità porta naturalmente a uno spettro di ambienti di elaborazione, una scala di esecuzione che l'agente percorre a seconda delle esigenze:
Il livello 0 è Workspace, un file system virtuale duraturo supportato da SQLite e R2. Lettura, scrittura, modifica, ricerca, grep, diff. Basato su @cloudflare/shell.
Il livello 1 è un Dynamic Worker: JavaScript generato da LLM in esecuzione in un isolato in sandbox senza accesso alla rete. Basato su @cloudflare/codemode.
Il livello 2 aggiunge npm. @cloudflare/worker-bundler recupera i pacchetti dal registro di sistema, li raggruppa con esbuild e carica il risultato nel Dynamic Worker. L'agente scrive import { z } from "zod" e funziona e basta.
Il livello 3 è un browser headless tramite Cloudflare Browser Run. Naviga, fai clic, estrai, acquisisci schermate. Utile quando il servizio non supporta ancora gli agenti tramite MCP o API.
Il livello 4 è una Cloudflare Sandbox configurata con i tuoi toolchain, repository e dipendenze: git clone, npm test, cargo build, sincronizzata bidirezionalmente con il Workspace.
Il principio chiave di progettazione: l'agente deve essere utile solo al livello 0, in cui ogni livello è additivo. L'utente può aggiungere funzionalità man mano che procede.
Elementi costitutivi, non un framework
Tutte queste primitive sono disponibili come pacchetti autonomi. Dynamic Worker, @cloudflare/codemode, @cloudflare/worker-bundler e @cloudflare/shell (un file system duraturo con strumenti) sono tutti utilizzabili direttamente con la classe di base Agent. Puoi combinarli per fornire a qualsiasi agente uno spazio di lavoro, l'esecuzione del codice e la risoluzione dei pacchetti di runtime senza adottare un framework prescrittivo.
Ecco lo stack completo per la creazione di agenti su Cloudflare:
Capacità | Cosa fa | Basata su |
|---|
Isolamento per agente | Ogni agente è il suo mondo | Durable Objects (DO) |
Zero costi quando inattiva | 0 costi fino alla riattivazione dell'agente | Ibernazione DO |
Stato persistente | Archiviazione transazionale sottoponibile a query | SQLite DO |
File system duraturo | File che sopravvivono ai riavvii | Workspace (SQLite + R2) |
Esecuzione di codice in sandbox | Esegui il codice generato da LLM in modo sicuro | Dynamic Worker + @cloudflare/codemode |
Dipendenze di runtime | import * from react funziona e basta
| @cloudflare/worker-bundler
|
Automazione web | Sfoglia, naviga, compila moduli | Browser Run |
Accesso completo al sistema operativo | git, compilatori, test runner | Sandbox |
Esecuzione programmata | Proattivo, non solo reattivo | Allarmi + fibre DO |
Streaming in tempo reale | Token per token per qualsiasi client | WebSocket |
Strumenti esterni | Connettiti a qualsiasi server di strumenti | MCP |
Coordinamento degli agenti | RPC tipizzato tra agenti | Subagenti (Facets) |
Accesso ai modelli | Connettiti a un LLM per alimentare l'agente | AI Gateway + Workers AI (o Bring Your Own Model) |
Ognuno di questi è un elemento costitutivo. Insieme, formano qualcosa di nuovo: una piattaforma in cui chiunque può creare, distribuire ed eseguire agenti IA capaci come quelli in esecuzione sul tuo computer locale oggi, ma serverless, duraturi e sicuri fin dalla realizzazione.
Ora che hai visto le primitive, ecco cosa succede quando le colleghi tutte insieme.
Think è un framework prescrittivo che gestisce l'intero ciclo di vita delle chat: loop agentico, persistenza dei messaggi, streaming, esecuzione degli strumenti, ripresa dello streaming ed estensioni. Ti concentri su ciò che rende unico il tuo agente.
La sottoclasse minimal si presenta così:
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"
);
}
}
Questo è effettivamente tutto ciò di cui hai bisogno per avere un agente di chat funzionante con streaming, persistenza, interruzione/annullamento, gestione degli errori, flussi ripristinabili e un file system del workspace integrato. Distribuisci con npx wrangler deploy.
Think prende le decisioni per te. Quando hai bisogno di maggiore controllo, puoi sovrascrivere quelle che ti interessano:
Override | Scopo |
getModel()
| Restituisce il LanguageModel da utilizzare |
getSystemPrompt()
| Prompt di sistema |
getTools()
| ToolSet compatibile con AI SDK per il loop agentico
|
maxSteps
| Numero massimo di round di richiami degli strumenti per turno |
configureSession()
| Blocchi di contesto, compattazione, ricerca, competenze |
Alla base di tutto, Think esegue l'intero loop di agenti ad ogni turno: assembla il contesto (istruzioni di base + descrizioni degli strumenti + competenze + memoria + cronologia delle conversazioni), richiama streamText, esegue i richiami degli strumenti (con troncamento dell'output per prevenire l'esplosione del contesto), aggiunge risultati ed esegue loop fino al completamento del modello o al raggiungimento del limite di passaggi. Tutti i messaggi vengono resi persistenti dopo ogni turno.
Think ti offre hook in ogni fase del turno di chat, senza che tu debba possedere l'intera pipeline:
beforeTurn()
→ streamText()
→ beforeToolCall()
→ afterToolCall()
→ onStepFinish()
→ onChatResponse()
Passa a un modello a basso costo per i turni di follow-up, limita gli strumenti che può utilizzare e passa nel contesto lato client ad ogni turno. Registra anche ogni richiamo degli strumenti all'analisi e attiva automaticamente un altro turno di follow-up al completamento del modello, il tutto senza sostituire onChatMessage.
Memoria persistente e lunghe conversazioni
Think si basa sull'API Session come livello di archiviazione, offrendoti messaggi strutturati ad albero con ramificazione integrata.
Inoltre, aggiunge memoria persistente tramite blocchi di contesto. Si tratta di sezioni strutturate del prompt di sistema che il modello può leggere e aggiornare nel tempo e persistono durante l'ibernazione.Il modello vede "MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]" e può ricordare tutto in modo proattivo.
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();
}
Le sessioni sono flessibili. Puoi eseguire più conversazioni per agente ed effettuarne il fork per provare una direzione diversa senza perdere l'originale.
Man mano che il contesto cresce, Think gestisce i limiti con una compattazione non distruttiva. I messaggi meno recenti vengono riepilogati anziché rimossi, mentre la cronologia completa rimane archiviata in SQLite.
Anche la ricerca è integrata. Utilizzando FTS5, puoi eseguire query nella cronologia delle conversazioni all'interno di una sessione o in tutte le sessioni. L'agente è anche in grado di cercare nel proprio passato utilizzando lo strumento search_context.
La scala di esecuzione completa, integrata
Think integra l'intera scala di esecuzione in un unico valore di ritorno getTools():
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()
};
}
}
Think porta l'esecuzione del codice un ulteriore passo avanti. Un agente può scrivere le proprie estensioni: programmi TypeScript che vengono eseguiti in Dynamic Worker, dichiarando le autorizzazioni per l'accesso alla rete e le operazioni del workspace.
{
"name": "github",
"description": "GitHub integration: PRs, issues, repos",
"tools": ["create_pr", "list_issues", "review_pr"],
"permissions": {
"network": ["api.github.com"],
"workspace": "read-write"
}
}
ExtensionManager di Think raggruppa l'estensione (facoltativamente con dipendenze npm tramite @cloudflare/worker-bundler), la carica in un Dynamic Worker e registra i nuovi strumenti. L'estensione persiste nell'archiviazione del DO e sopravvive all'ibernazione. La prossima volta che l'utente chiede informazioni sulle richieste pull, l'agente ha uno strumento github_create_pr che non esisteva 30 secondi prima.
Questo è il tipo di ciclo di automiglioramento che rende gli agenti davvero più utili nel tempo. Non attraverso la messa a punto o RLHF, ma tramite il codice. L'agente è in grado di scrivere nuove funzionalità per se stesso, il tutto in TypeScript in sandbox, verificabile e revocabile.
Think funziona anche come subagente, richiamato tramite chat() su RPC da un elemento principale, con eventi in streaming tramite callback:
const researcher = await this.subAgent(ResearchSession, "research");
const result = await researcher.chat(`Research this: ${task}`, streamRelay);
Ogni istanza secondaria ottiene la propria struttura ad albero di conversazioni, memoria, strumenti e modello. L'elemento principale non ha bisogno di conoscere i dettagli.
Project Think è sperimentale. L'interfaccia API è stabile ma continuerà ad evolversi nei prossimi giorni e nelle prossime settimane. Lo stiamo già utilizzando internamente per creare la nostra infrastruttura di agenti in background e lo stiamo condividendo in anticipo in modo che tu possa costruire insieme a noi.
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 usa lo stesso protocollo WebSocket di @cloudflare/ai-chat, quindi i componenti dell'interfaccia utente esistenti funzionano immediatamente. Se hai creato su AIChatAgent, il tuo codice client non cambia.
Vediamo tre ondate di agenti IA:
La prima ondata è stata quella dei chatbot. Erano stateless, reattivi e fragili. Ogni conversazione iniziava da zero senza memoria, senza strumenti e senza capacità di agire. Tutto questo li ha resi utili per rispondere alle domande, ma li ha limitati a rispondere solo alle domande.
La seconda ondata è stata quella degli agenti di codifica. Si tratta di strumenti stateful, che utilizzano strumenti e molto più capaci come Pi, Claude Code, OpenClaw e Codex. Questi agenti possono leggere codebase, scrivere codice, eseguirlo e iterare. Hanno dimostrato che un LLM con gli strumenti giusti è una macchina per uso generale, ma funziona sul tuo laptop, per un utente, senza garanzie di durata.
Ora passiamo alla terza ondata: gli agenti come infrastruttura. Duraturi, distribuiti, strutturalmente sicuri e serverless. Si tratta di agenti che vengono eseguiti su Internet, sopravvivono ai guasti, non costano nulla quando sono inattivi e applicano la sicurezza attraverso l'architettura piuttosto che il comportamento. Agenti che qualsiasi sviluppatore può creare e distribuire per un numero qualsiasi di utenti.
Questa è la direzione su cui puntiamo.
Agents SDK è già alla base di migliaia di agenti di produzione. Con Project Think e le primitive che introduce, stiamo aggiungendo i pezzi mancanti per rendere questi agenti notevolmente più capaci: workspace persistenti, esecuzione di codice in modalità sandbox, attività a lunga esecuzione durature, sicurezza strutturale, coordinamento tra subagenti ed estensioni autogenerate.
È disponibile oggi in anteprima. Stiamo costruendo insieme a te e ci piacerebbe davvero vedere cosa creerai tu (e il tuo agente di codifica) con questo.
Think fa parte di Cloudflare Agents SDK, disponibile come @cloudflare/think. Le funzionalità descritte in questo post sono in anteprima. Le API possono cambiare man mano che incorporiamo il feedback. Consulta la documentazione e l'esempio per iniziare.