오늘, 저희는 차세대 Agents SDK인 Project Think를 소개합니다. Project Think는 장기 실행 에이전트(내구성 실행, 하위 에이전트, 샌드박스 코드 실행, 영구 세션)를 구축하기 위한 새로운 기본 클래스와 이들을 모두 연결하는 독단적인 기본 클래스의 세트입니다. 기본 클래스를 사용하여 필요한 것을 정확히 구축하거나 기본 클래스를 사용하여 빠르게 시작하세요.
올해 초 AI에 대한 우리의 생각을 변화시킨 사건이 발생했습니다. Pi, OpenClaw, Claude Code, Codex 같은 도구는 단순하지만 강력한 아이디어를 입증했습니다 범용 비서에 가깝습니다.
이러한 코딩 에이전트는 더 이상 코드만 작성하는 것이 아닙니다. 사람들은 캘린더를 관리하고, 데이터 세트를 분석하며, 구매 협상, 세금 신고, 전체 비즈니스 워크플로우를 자동화하는 데 API를 사용하고 있습니다. 패턴은 항상 동일합니다. 에이전트가 컨텍스트를 읽고, 추론하며, 조치를 취하기 위해 코드를 작성하고, 결과를 관찰하고, 반복합니다. 강령은 보편적인 행동 매개체입니다.
우리 팀은 매일 이러한 코딩 에이전트를 사용하고 있습니다. 그리고 우리는 계속해서 같은 벽에 부딪혔습니다.
사용자의 노트북이나 고가의 VPS에서만 실행됩니다. 공유도, 협업도, 장치 간의 핸드오프도 없습니다.
유휴 상태일 때는 비용이 많이 듭니다: 에이전트가 작동하든 안 하든 고정된 월별 비용이 발생합니다. 이를 팀이나 회사로 확장하면 빠르게 확장됩니다.
종속성 설치, 업데이트 관리, ID 및 비밀 구성 등관리와 수동 설정이 필요합니다.
여기에는 더 깊은 구조적 문제가 있습니다. 기존의 애플리케이션은 하나의 인스턴스에서 많은 사용자에게 서비스를 제공합니다. Agents Week에 오신 것을 환영합니다 게시물에서 언급했듯이, 상담원은 일대일입니다. 각 에이전트는 한 가지 사용자에게 서비스를 제공하며 하나의 작업을 실행하는 고유한 인스턴스입니다. 레스토랑은 메뉴와 주방을 갖추고 있어 요리를 대량으로 제공할 수 있습니다. 에이전트는 개인 요리사와 같습니다. 매번 다른 재료, 다른 기술, 다른 도구를 사용해야 합니다.
이로 인해 확장성에 대한 수학의 개념이 근본적으로 바뀝니다. 지식 근로자가 수억 명이라고 해도 각각 에이전트 어시스턴트를 적절한 속도로 사용한다면, 수천만 개의 동시 세션을 처리할 수 있는 용량이 필요합니다. 현재의 컨테이너당 비용으로 보면 이는 지속 가능하지 않습니다. 우리는 다른 기반이 필요합니다.
이것이 바로 우리가 해 온 작업입니다.
Project Think는 Agents SDK를 위한 새로운 기본 요소 세트를 제공합니다.
파이버를 사용한 내구성 있는 실행: 충돌 복구, 검사점, 자동 Keepalive
하위 에이전트: 자체 SQLite 및 유형 RPC를 사용하는 격리된 하위 에이전트
영구 세션: 트리 구조 메시지, 분기, 압축, 전체 텍스트 검색
샌드박스를 적용한 코드 실행: Dynamic Workers, 코드 모드, 런타임 npm 확인
실행 래더: 작업 공간, 격리, npm, 브라우저, 샌드박스
자체 작성 확장: 런타임에 자체 도구를 작성하는 에이전트
이들 각각은 Agent 기본 클래스와 함께 직접 사용할 수 있습니다. 기본 요소를 이용해 필요한 것을 정확히 구축하거나, Think 기본 클래스를 사용하여 빠르게 시작할 수 있습니다. 각각 어떤 역할을 하는지 살펴보겠습니다.
오늘날의 에이전트는 임시적입니다. 쿼리는 단일 프로세스나 장치에 연결된 세션 동안 실행된 다음 사라집니다. 노트북이 절전 모드가 되면 사라지는 코딩 에이전트가 바로 도구입니다. 요청에 따라 활성화되고, 중단 후에도 작업을 계속 진행하며, 로컬 런타임에 의존하지 않고 상태를 이월할 수 있는 지속되는 에이전트로, 인프라처럼 보이기 시작합니다. 그리고 이로 인해 에이전트의 확장 모델은 완전히 바뀝니다.
Agents SDK는 Durable Objects 를 기반으로 구축되어 모든 에이전트에 ID, 영구 상태, 메시지를 받고 활성화할 수 있는 기능을 제공합니다. 이는 행위자 모델입니다. 각 에이전트는 자체 SQLite 데이터베이스를 가진 주소 지정 가능한 엔터티입니다. 최대 절전 모드에서도 컴퓨팅을 전혀 소비하지 않습니다. 문제가 발생하면(HTTP 요청, WebSocket 메시지, 예약된 경보, 인바운드 이메일) 플랫폼에서는 에이전트를 깨우고 상태를 로드한 다음 해당 이벤트를 전달합니다. 에이전트가 작업을 수행한 다음 다시 절전 모드로 전환됩니다.
| VM / 컨테이너 | Durable Objects |
|---|
유휴 비용 | 항상 전체 컴퓨팅 비용 | Zero(최대 절전 모드) |
확장 | 용량 프로비저닝 및 관리 | 에이전트별 자동 |
상태 | 외부 데이터베이스 필요 | 기본 제공 SQLite |
복구 | 직접 구축(프로세스 관리자, 상태 검사) | 플랫폼이 재시작되면 상태가 유지됩니다 |
ID / 라우팅 | 사용자가 이를 구축(로드 밸런서, 고정 세션) | 기본 제공(이름 → 에이전트) |
10,000명의 에이전트, 각각 1%의 시간 동안 활성화 | 10,000개의 상시 가동 인스턴스 | 언제든지 최대 100개 활성화 |
이에 따라 대규모 에이전트 실행의 경제성이 바뀌었습니다. "고급의 파워 유저당 에이전트 한 명" 대신 "고객당 하나의 에이전트", "작업당 하나의 에이전트", "이메일 스레드당 하나의 에이전트"를 구축할 수 있습니다. 새로운 에이전트를 생성하는 데 드는 한계 비용은 사실상 0입니다.
LLM 호출에는 30초가 걸립니다. 여러 차례 에이전트 루프가 훨씬 더 길어질 수 있습니다. 해당 기간 중 언제든지 배포, 플랫폼 재시작, 리소스 제한 도달 등 실행 환경이 사라질 수 있습니다. 모델 공급자에 대한 업스트림 연결이 영구적으로 끊어지고, 인메모리 상태가 손실되며, 연결된 클라이언트에서는 설명 없이 스트림이 중지됩니다.
runFiber() 를 사용하면 이 문제가 해결됩니다. 파이버는 지속형 함수 호출입니다. 실행이 시작되기 전에 SQLite에 등록되며, stash()를 통해 언제든지 체크포인트할 수 있고, 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);
}
}
}
SDK는 특별한 구성이 필요 없이 광섬유 실행 중에 에이전트를 자동으로 활성 상태로 유지합니다. 분 단위로 측정된 작업의 경우, KeepAlive() / KeepAliveWhile() 은 활성 작업 중에 만료되는 것을 방지합니다. 더 긴 작업(CI 파이프라인, 디자인 검토, 비디오 생성)의 경우 에이전트는 작업을 시작하고, 작업 ID를 유지하며, 최대 절전 모드로 전환하고, 콜백에 다시 활성화합니다.
작업 위임: Facets를 통한 하위 에이전트
단일 에이전트가 모든 작업을 스스로 처리해서는 안 됩니다. 하위 에이전트 는 Facets를 통해 상위 요소와 함께 배치된 하위 Durable Object이며, 각각 격리된 SQLite 및 실행 컨텍스트를 가지고 있습니다.
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);
}
}
하위 에이전트는 스토리지 수준에서 격리됩니다. 각각 자체 SQLite 데이터베이스를 가지며 둘 사이에 데이터가 암시적으로 공유되지는 않습니다. 이는 하위 에이전트 RPC 대기 시간이 함수 호출인 런타임에 의해 적용됩니다. TypeScript는 컴파일 타임에 오용을 포착합니다.
며칠 또는 몇 주 동안 작동하는 에이전트는 단순한 메시지 목록보다 많은 것이 필요합니다. 실험적인 세션 API 는 이를 명시적으로 모델링합니다. Agent 기본 클래스에서 제공되는 대화는 트리로 저장되며 각 메시지에는 parent_id가 있습니다. 이를 통해 대화 기록 전반에 걸쳐 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");
}
}
세션은 Agent에서 직접 사용할 수 있으며, Think 기본 클래스가 기반으로 하는 스토리지 계층입니다.
기존의 도구 호출은 형태가 불편합니다. 모델은 도구를 호출하고, 컨텍스트 창을 통해 결과를 다시 가져오고, 다른 도구를 호출하고, 다시 가져오는 등의 작업을 반복합니다. 도구 표면이 커질수록 비용이 많이 들고 복잡해집니다. 파일이 100개라는 것은 모델이 100번 왕복한다는 의미입니다.
그러나 모델은 도구 호출 게임을 하는 것보다 시스템을 사용하기 위한 코드를 작성하는 데 더 능숙합니다. 이것이 @cloudflare/codemode 이면의 통찰력입니다. LLM은 순차적인 도구 호출 대신 전체 작업을 처리하는 단일 프로그램을 작성합니다.
// 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;
모델을 100번 왕복하는 대신 단일 프로그램을 실행하면 됩니다. 따라서 토큰을 더 적게 사용하고, 더 빠르게 실행하며, 더 나은 결과를 얻을 수 있습니다. Cloudflare API MCP 서버 가 대규모로 이를 보여줍니다. 저희가 공개한 것은 두 가지 도구 (search() 및 execute())만 사용하는데, 이는 최대 1,000개의 토큰을 사용하는데, 엔드포인트당 단순한 도구에 해당하는 경우에는 약 117만 개의 토큰을 사용합니다. 이는 99.9% 감소한 수치입니다.
모델이 사용자를 대신하여 코드를 작성해야 한다는 사실을 받아들일 수 있다면, 질문은 다음과 같습니다. 해당 코드는 어디에서 실행되는가? 결국에는, 제품팀에서 로드맵 항목으로 전환한 후에도 마찬가지입니다. 지금 바로 이 사용자에 대해 이 시스템에 대해 엄격하게 정의된 권한으로 공격할 것입니다.
Dynamic Workers 는 바로 그 샌드박스입니다. 새로운 V8 격리는 몇 메가바이트의 메모리로 런타임 시 밀리초 단위로 스핀업합니다. 이는 컨테이너보다 약 100배 빠르고 최대 100배 더 메모리 효율적입니다. 모든 단일 요청에 대해 새 요청을 시작하고, 코드 스니펫을 실행하며, 폐기할 수 있습니다.
중요한 설계 선택은 역량 모델입니다. Dynamic Workers는 범용 기기로 시작하여 이를 제한하는 대신, 거의 주변 권한 없이(globalOutbound: null, 네트워크 액세스 없음) 시작하며 개발자가 바인딩을 통해 리소스별로 명시적으로 기능을 부여합니다. 우리는 "이 장치가 너무 많은 일을 하지 않게 하려면 어떻게 해야 할까요?"라는 질문을 던집니다. "이 장치가 정확히 무엇을 할 수 있기를 원하는가?"로 질문하는 것입니다.
에이전트 인프라에 관한 적절한 질문입니다.
이 기능 모델은 자연스럽게 다양한 컴퓨팅 환경, 즉 필요에 따라 에이전트가 에스컬레이션하는 실행 래더 로 이어집니다.
0계층은 SQLite와 R2로 지원되는 지속형 가상 파일 시스템인 Workspace입니다. 읽기, 쓰기, 편집, 검색, grep, diff. 제공: @cloudflare/shell.
1계층 은 네트워크에 액세스하지 않고 샌드박스를 적용한 격리에서 실행되는 Dynamic Worker: LLM으로 생성된 JavaScript입니다. 제공: @cloudflare/codemode.
2계층 에서는 npm이 추가됩니다. @cloudflare/worker-bundler 는 레지스트리에서 패키지를 가져와 esbuild로 번들하고 그 결과를 동적 작업자에 로드합니다. 에이전트가 { z } "zod"에서 가져오기를 작성하면 바로 작동합니다.
3계층 은 Cloudflare Browser Run을 통한 헤드리스 브라우저입니다. 탐색, 클릭, 추출, 스크린샷. 이 서비스는 서비스가 MCP 또는 API를 통해 아직 에이전트를 지원하지 않을 때 유용합니다.
4계층은 사용자의 툴체인, 저장소 및 종속성( git clone, npm test, cargo build)으로 구성된 Cloudflare 샌드박스 이며 Workspace와 양방향으로 동기화됩니다.
키 설계 원칙: 에이전트는 각 계층이 추가되며 계층 0에서만 유용해야 합니다. 사용자는 필요에 따라 기능을 추가할 수 있습니다.
이러한 모든 기본 요소는 독립형 패키지로 제공됩니다. Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, and @cloudflare/shell (도구가 있는 지속형 파일 시스템)은 모두 Agent 기본 클래스와 함께 직접 사용할 수 있습니다. 독단적인 프레임워크를 채택하지 않고도 이들을 결합하여 모든 에이전트에 작업 영역, 코드 실행, 런타임 패키지 확인 기능을 제공할 수 있습니다.
다음은 Cloudflare에서 에이전트를 구축하기 위한 전체 스택입니다.
이들 각각이 빌딩 블록입니다. 이들은 함께 새로운 것을 형성합니다. 즉, 현재 로컬 머신에서 실행되는 것과 같은 AI 에이전트를 누구나 구축, 배포, 실행할 수 있지만, 서버리스이며, 내구성이 뛰어나고, 본질적으로 안전한 플랫폼입니다.
이제 기본 요소를 보았으므로, 모두 함께 연결하면 다음과 같은 일이 발생합니다.
Think 는 에이전트형 루프, 메시지 지속성, 스트리밍, 도구 실행, 스트림 재개, 확장 등 전체 채팅 수명 주기를 처리하는 독단적인 도구 모음입니다. 에이전트를 독특하게 만드는 요소에 집중합니다.
최소 서브클래스는 다음과 같습니다.
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"
);
}
}
스트리밍, 지속성, 중단/ 취소, 오류 처리, 재개 가능한 스트림, 기본 제공 작업 공간 파일 시스템 등을 갖춘 채팅 에이전트가 작동하기 위해 필요한 전부입니다. npx wrangler deploy를 사용하여 배포하세요.
Think가 대신 결정을 내립니다. 더 많은 제어가 필요한 경우 관심 있는 항목을 재정의할 수 있습니다.
재정의 | 목적 |
getModel()
| 사용할 LanguageModel 을 반환합니다. |
getSystemPrompt()
| 시스템 프롬프트 |
getTools()
| 에이전트 루프를 위한 AI SDK 호환 툴세트 |
maxSteps
| 차례당 최대 도구 호출 라운드 |
구성세션()
| 컨텍스트 차단, 압축, 검색, 기술 |
Think는 내부적으로 매 턴마다 완전한 에이전트 루프를 실행합니다. 컨텍스트(기본 지침 + 도구 설명 + 기술 + 메모리 + 대화 기록)를 구성하고, streamText를 호출하고, 도구 호출을 실행하고(컨텍스트 폭발을 방지하기 위해 출력 일부를 잘라냄), 결과를 추가하고, 모델이 완료되거나 단계 제한에 도달할 때까지 루프를 반복합니다. 모든 메시지는 각 턴 후에 지속됩니다.
Think는 사용자가 전체 파이프라인을 소유할 필요 없이 대화의 모든 단계에서 후크를 제공합니다.
beforeTurn()
→ streamText()
→ beforeToolCall()
→ afterToolCall()
→ onStepFinish()
→ onChatResponse()
후속 조치를 위해 더 저렴한 비용 모델로 전환하고, 사용할 수 있는 도구를 제한하며, 매 차례마다 클라이언트 측 컨텍스트를 전달합니다. 또한 모든 도구 호출을 analytics에 기록하고 모델 완료 후 onChatMessage를 대체할 필요 없이 한 번의 후속 조치를 자동으로 트리거할 수 있습니다.
Think는 스토리지 계층인 Session API 를 기반으로 구축되어 분기가 내장된 트리 구조의 메시지를 제공합니다.
게다가 컨텍스트 블록을 통해 영구 메모리를 추가합니다. 이는 모델이 시간이 지남에 따라 읽고 업데이트할 수 있는 시스템 프롬프트의 구조화된 섹션이며, 최대 절전 모드에서도 지속됩니다.이 모델은 "메모리(중요한 사실, set_context를 사용하여 업데이트) [42%, 462/1100 토큰]"을 인식하고 능동적으로 사물을 기억할 수 있습니다.
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();
}
세션은 유연합니다. 에이전트당 여러 대화를 실행하고 원본을 잃지 않고 분기하여 다른 방향을 시도할 수 있습니다.
Think는 컨텍스트가 커짐에 따라 비파괴적인 압축으로 제한을 처리합니다. 오래된 메시지는 제거되지 않고 요약되지만, 전체 기록은 SQLite에 계속 저장된 상태로 유지됩니다.
검색 기능도 기본 탑재되어 있습니다. FTS5를 사용하여 세션 내 또는 모든 세션의 대화 기록을 쿼리할 수 있습니다. 또한, 에이전트는 search_context 도구를 사용하여 자신의 과거를 검색할 수도 있습니다.
Think는 전체 실행 래더를 단일 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는 코드 실행을 한 단계 더 발전시킵니다. 에이전트는 자체 확장을 작성할 수 있습니다. TypeScript 프로그램은 동적 작업자에서 실행되어 네트워크 액세스 및 작업 영역 작업에 대한 권한을 선언합니다.
{
"name": "github",
"description": "GitHub integration: PRs, issues, repos",
"tools": ["create_pr", "list_issues", "review_pr"],
"permissions": {
"network": ["api.github.com"],
"workspace": "read-write"
}
}
Think의 ExtensionManager 는 확장 기능을 번들로 제공하고( @cloudflare/worker-bundler를 통해 npm deps 사용 시 선택 가능), Dynamic Worker에 로드하고, 새 도구를 등록합니다. 확장자는 DO 스토리지에 유지되며 최대 절전 모드에서도 생존합니다. 다음에 사용자가 풀 요청에 대해 질문하면 에이전트에는 30초 전에는 존재하지 않았던 github_create_pr 도구가 있습니다.
이는 일종의 자체 개선 루프로, 시간이 지남에 따라 에이전트를 진정으로 더 유용하게 만듭니다. 미세 조정이나 RLLF를 통해서가 아니라 코드를 통해서입니다. 에이전트는 샌드박스를 적용하고 감사 및 취소할 수 있는 TypeScript를 사용하여 새로운 기능을 자체적으로 작성할 수 있습니다.
Think는 콜백을 통해 이벤트를 스트리밍하면서 부모로부터 RPC를 통해 chat() 을 통해 호출되는 하위 에이전트로도 작동합니다.
const researcher = await this.subAgent(ResearchSession, "research");
const result = await researcher.chat(`Research this: ${task}`, streamRelay);
자녀가 각자 고유한 대화 트리, 메모리, 도구, 모델을 갖게 됩니다. 부모는 세부 사항을 알 필요가 없습니다.
Project Think는 실험적입니다. API 노출 영역은 안정적이지만, 앞으로도 계속 진화할 것입니다. 현재 내부적으로 이를 사용하여 자체 백그라운드 에이전트 인프라를 구축하고 있으며, 귀사와 함께 구축할 수 있도록 조기에 공유하고 있습니다.
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는 @cloudflare/ai-chat과 동일한 WebSocket 프로토콜을 사용하므로 기존 UI 구성 요소가 바로 작동합니다. AIChatAgent를 기반으로 구축한 경우 클라이언트 코드는 변경되지 않습니다.
AI 에이전트에는 세 가지 흐름이 있습니다.
첫 번째 물결은 챗봇이었습니다. 상태 비저장 방식은 반응에 민감하고 취약했습니다. 모든 대화는 기억도, 도구도, 조치를 취할 능력도 없이 처음부터 시작되었습니다. 따라서 질문에 답하는 데 유용했지만, 질문에만 답하도록 제한되었습니다.
두 번째 물결은 코딩 에이전트였습니다. 이러한 도구는 Pi, Claude Code, OpenClaw, Codex 등 상태 저장형 도구 사용 도구입니다. 이 에이전트는 코드베이스를 읽고, 코드를 작성하며, 실행하고, 반복할 수 있습니다. 이를 통해 올바른 도구를 갖춘 LLM이 범용 머신이지만, 노트북에서 1명의 사용자만 실행할 수 있고, 내구성이 보장되지는 않는다는 것이 증명되었습니다.
이제 우리는 인프라로서의 에이전트인 제3의 물결로 진입하고 있습니다. 내구성이 뛰어나고 분산되며 구조적으로 안전하고 서버리스입니다. 이러한 에이전트는 인터넷에서 실행되고, 장애를 극복하며, 유휴 상태일 때는 비용이 들지 않으며, 행동이 아닌 아키텍처를 통해 보안을 강화합니다. 모든 개발자가 원하는 수의 사용자를 위해 구축하고 배포할 수 있는 에이전트.
이것이 우리가 기대하는 방향입니다.
Agents SDK는 이미 수천 개의 프로덕션 에이전트를 지원하고 있습니다. Project Think와 그에 따라 도입되는 기본 기능을 통해 에이전트의 역량을 강화하기 위해 영구 작업 영역, 샌드박스 코드 실행, 지속형 장기 실행 작업, 구조적 보안, 하위 에이전트 조정, 자체 작성 기능 등 부족한 부분을 추가하고 있습니다. 확장자에게 제공합니다.
이 기능은 오늘 미리 보기로 제공됩니다. Cloudflare는 귀사와 함께 구축하고 있으며 귀사(그리고 귀사의 코딩 에이전트)를 활용해 무엇을 만들어낼지 꼭 확인하고 싶습니다.
Think는 Cloudflare Agents SDK의 일부로, @cloudflare/think로 제공됩니다. 이 게시물에서 설명하는 기능은 현재 미리 보기 상태입니다. APIs는 피드백을 반영하여 변경될 수 있습니다. 문서 와 예제 를 확인하여 시작하세요.