导航|地址|刷新
Project Think: creare la nuova generazio…






Salta al contenuto
















Tutte le categorie

AI

Sviluppatori

Radar

Novità sul prodotto

Sicurezza

Informativa e note legali

Zero Trust

Velocità e affidabilità

La vita con Cloudflare

Partner



Questo post è disponibile in

English

Deutsch

Español

Español (Latinoamérica)

Français

日本語

한국어

繁體中文

简体中文

Cambia lingua del sito

English

Deutsch

Español

Español (Latinoamérica)

Français

Italiano

日本語

한국어

繁體中文

简体中文

Português

Русский

Bahasa Indonesia

ภาษาไทย

Tiếng Việt

Polski

العربية

עברית

Svenska

Nederlands

Türkçe

AccediContatta il reparto Vendite










Blog

AgentiAgents WeekArchiviazione+5Mostra altri 5 tag


8 tagMostra 8 tag






Tag selezionati

AgentiAgents WeekArchiviazioneCloudflare WorkersDurable ObjectsIAPiattaforma per sviluppatoriSviluppatori

Tutti i tag

Tag corrispondenti

Nessun tag trovato

1.1.1.1

Agenti

Agents Week

API

Archiviazione

Automazione

Browser Run

Cloudflare Access

Cloudflare Gateway

Cloudflare One

Cloudflare Workers

Code Orange

Container

Disservizio

DNS

Documentazione per gli sviluppatori

DoH (IT)

Durable Objects

Firewall (IT)

Gatebot (IT)

Gestione dei bot

Gestione del rischio

GitHub

HTTP2 (IT)

IA

Impatto

Informativa e note legali

Ingegneria

IPSec

La crittografia

La vita con Cloudflare

LLM

MCP

Novità sul prodotto

Open source

Operazioni sulle minacce

Ottimizzazione

Partner

PCI Certified (IT)

Piattaforma per sviluppatori

Post mortem

Post-quantistico

Predisposizione agli agenti

Privacy

Progetto Galileo

Radar

Rapid Reset (IT)

Regolamento Internet

Rendering del browser

Sandbox

SASE

SDK

Serverless

Servizi consumer

Sicurezza

Sicurezza informatica

Sviluppatori

Team

Threat Intelligence

Trasparenza

Velocità e affidabilità

Workers AI

Zero Trust




Cloudflare WorkersDurable ObjectsIAPiattaforma per sviluppatoriSviluppatori





AgentiAgents WeekArchiviazioneCloudflare WorkersDurable ObjectsIAPiattaforma per sviluppatoriSviluppatori






15 aprile 2026
Project Think: creare la nuova generazione di agenti IA su Cloudflare




Sunil Pai e Kate Reznykova



Lettura di 15 min
COPIA URL



Questo post è disponibile anche in English,Deutsch,Español,Español (Latinoamérica),Français,日本語,한국어,繁體中文 e 简体中文.








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.

Ecco Project Think

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.

Dai richiami degli strumenti all'esecuzione del codice

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.

La scala di esecuzione

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.


…(内容过长已截断)

------
导航页 打开网址