Codestin Search App

본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.

8년 전 Workers를 처음 출시했을 때는 개발자에게 직접 보내는 플랫폼이었습니다. 지난 몇 년 동안 저희는 플랫폼이 Workers를 직접 기반으로 구축할 수 있을 뿐만 아니라 고객이 여러 다중 테넌트 애플리케이션을 통해 자사 코드를 저희에게 제공할 수도 있도록 생태계를 확장하고 규모를 조정했습니다. 이제 우리는 Workers: 애플리케이션에서 사용자가 자신이 원하는 것을 설명하고, AI가 구현 내용을 작성하는 것을 목격하고 있습니다. 다중 테넌트 SaaS에서는 모든 고객의 비즈니스 로직이 런타임에 플랫폼에서 이전에는 본 적 없는 형태가 됩니다. 자체 툴을 작성하고 실행하는 에이전트. 모든 저장소가 자체 파이프라인을 정의하는 CI/CD 제품.

지난달 Dynamic Workers 오픈 베타를 출시했을 때, 이러한 플랫폼은 컴퓨팅 측면을 위한 깔끔한 기본 요소를 제공했습니다. 런타임에 Workers 런타임에 코드를 전달하면, 동일한 머신에서 단 몇 밀리초 만에 격리되고 샌드박스가 적용된 Worker를 얻을 수 있습니다. Durable Object Facets 는 동일한 아이디어를 스토리지 로 확장했습니다. 동적으로 로드된 각 앱은 자체 SQLite 데이터베이스를 가질 수 있고, 필요에 따라 스핀업할 수 있으며, 플랫폼은 슈퍼바이저로서 그 앞에 위치합니다. 아티팩트는 소스 제어용으로도 마찬가지입니다. 스토리지 및 소스 제어를 위한 동적 배포가 있습니다. 다음은 무엇일까요?

현재 우리는 Dynamic Workflows를 통해 지속형 실행과 동적 배포를 연결하고 있습니다.

지속 실행과 동적 실행 간의 격차

Cloudflare Workflows 는 당사의 지속형 실행 엔진입니다. run(event, step) 함수를 프로그램으로 전환하여 모든 단계가 실패 시에도 작동하도록 하고, 몇 시간이나 며칠 동안 절전 모드로 전환하고, 외부 이벤트를 기다릴 수 있으며, 분리물을 재활용할 때 중단된 위치에서 정확히 다시 시작합니다. 온보딩 흐름, 비디오 트랜스코딩 파이프라인, 다단계 청구, 장기 실행 에이전트 루프,Workflows V2 기준 최대 50,000개의 동시 인스턴스 및 300개의 계정당 초당 새로운 인스턴스 수, 에이전트 중심의 시대에 맞게 재설계

하지만 Workflows에는 항상 워크플로 코드가 배포의 일부라는 한 가지 가정이 구축되어 있었습니다. wrangler.jsonc 에 "엔진이 WORKFLOWS를 호출하면 MyWorkflow라는 클래스를 실행합니다." 라는 블록이 있습니다. 하나의 바인딩, 하나의 클래스. 배포당.

모든 코드를 소유하고 있다면 문제가 없을 것입니다. 기존 애플리케이션을 실행하고 있다면 문제가 없습니다.

고객이 자신의 워크플로우를 배포하도록 허용하려는 순간 작동이 멈춥니다.

AI가 모든 테넌트에 대해 TypeScript를 작성하는 앱 플랫폼을 구축 중이라고 가정해 보겠습니다. 각 리포지토리마다 자체 파이프라인이 있는 CI/CD 제품을 실행하고 있다고 가정해 보겠습니다. 각 에이전트가 자체 지속형 요금제를 작성하는 에이전트 SDK를 사용하고 있다고 가정해 보겠습니다. 이러한 모든 경우에서 모든 테넌트, 모든 에이전트, 모든 요청에 따라 워크플로가 다릅니다. 바인딩할 단일 클래스가 없습니다.

이는 Dynamic Workers가 컴퓨팅을 위해 해결하고 Durable Object Facets가 스토리지를 위해 해결했던 문제와 같은 형태입니다. 단지 지속해서 실행할 수 있도록 아직 해결하지 못했을 뿐입니다.

동적 Workflows

@cloudflare/dynamic-workflows 는 소규모 라이브러리입니다. 약 300줄의 TypeScript. 이를 통해 Worker Loader 하나는 모든 create() 호출을 다른 테넌트의 코드로 라우팅하고, 중요하게는 Workflows 엔진이 워크플로가 실제로 실행될 때 몇 초 또는 몇 초 또는 몇 시간이나 며칠 후에

전체 패턴은 다음과 같습니다. Worker Loader:

import {
  createDynamicWorkflowEntrypoint,
  DynamicWorkflowBinding,
  wrapWorkflowBinding,
} from '@cloudflare/dynamic-workflows';

// The library looks this class up on cloudflare:workers exports.
export { DynamicWorkflowBinding };

function loadTenant(env, tenantId) {
  return env.LOADER.get(tenantId, async () => ({
    compatibilityDate: '2026-01-01',
    mainModule: 'index.js',
    modules: { 'index.js': await fetchTenantCode(tenantId) },
    // The tenant sees this as a normal Workflow binding.
    env: { WORKFLOWS: wrapWorkflowBinding({ tenantId }) },
  }));
}

// Register this as class_name in wrangler.jsonc.
export const DynamicWorkflow = createDynamicWorkflowEntrypoint<Env>(
  async ({ env, metadata }) => {
    const stub = loadTenant(env, metadata.tenantId);
    return stub.getEntrypoint('TenantWorkflow');
  }
);

export default {
  fetch(request, env) {
    const tenantId = request.headers.get('x-tenant-id');
    return loadTenant(env, tenantId).getEntrypoint().fetch(request);
  },
};

다음을 wrangler.jsonc에 추가하세요.

"workflows": [
		{
			"name": "dynamic-workflow",
			"binding": "WORKFLOW",
			"class_name": "DynamicWorkflow"
		}
	]

테넌트는 일반 관용 Workflows 코드를 작성합니다. 자신이 파견되고 있는지도 알지 못합니다.

import { WorkflowEntrypoint } from 'cloudflare:workers';

export class TenantWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    return step.do('greet', async () => `Hello, ${event.payload.name}!`);
  }
}

export default {
  async fetch(request, env) {
    const instance = await env.WORKFLOWS.create({ params: await request.json() });
    return Response.json({ id: await instance.id });
  },
};

다 됐습니다. 테넌트는 완벽하게 정상적인 Workflow 바인딩처럼 보이는 것에 대해 env.WORKFLOWS.create(...) 를 호출합니다. Workflow IDs, .status(), .pause(), retries, hibernation, durable steps, step.sleep('24 hours'), step.waitForEvent() — 모든 것이 지금까지와 같은 방식으로 작동합니다.

이 라이브러리가 처리하는 한 가지 일은 Workflows 엔진이 마침내 활성화되어 run(event, step)을 호출할 때 올바른 테넌트의 코드 내부에 있는지 확인하는 것입니다.

작동 방식

세 개의 계층이 있습니다. 상단에는 Workflows 엔진(플랫폼), 중간에는 Worker Loader, 하단에는 테넌트 코드(Dynamic Worker)가 있습니다.

요청이 Worker Loader에 도달하면, 즉석에서 올바른 동적 코드로 실행을 라우팅합니다. 나머지 실행은 왼쪽에서 오른쪽 방향으로 이 세 계층 사이의 핸드오프입니다. 요청이 들어와 엔진으로 바운스되고, 지속되다가 나중에 다시 바운스됩니다.

흐름 살펴보기:

① → ② 테넌트의 코드를 입력합니다. Worker Loader는 HTTP 요청을 받고, 어떤 테넌트를 위한 것인지 파악하고, Worker Loader를 통해 해당 테넌트의 코드를 로드하고, 요청을 default.fetch로 전달합니다. 테넌트가 전달하는 환경 에는 WORKFLOWS: 랩워크플로 바인딩({ tenantId })이 포함되어 있습니다. 테넌트에 관한 한, 이는 실제 Workflow 바인딩처럼 보이고 작동합니다.

③ Worker Loader까지. 테넌트가 env.WORKFLOWS.create({ params })를 호출하면, 실제로 Worker Loader에 대한 원격 프로시저 호출(RPC)을 만드는 것입니다. 래핑된 바인딩은 WorkerEntrypoint 하위 클래스(DynamicWorkflowBinding)이며, 런타임이 로드 시 테넌트의 메타데이터로 특정화합니다. 그래서 Worker Loader에서 export { DynamicWorkflowBinding } 해야 합니다. 런타임은 cloudflare:workers 내보내기에서 클래스를 찾아 테넌트별 스텁을 빌드합니다. 동적 Worker 경계를 넘는 바인딩은 RPC 스텁이어야 합니다.{ create, get } 일반 개체는 구조화 복제할 수 없으며 원시 Workflow 바인딩도 직렬화할 수 없습니다.

Worker Loader 내에서 래핑된 바인딩은 다음과 같이 페이로드를 투명하게 다시 씁니다.

tenant calls:  create({ params: { name: 'Alice' } })
                            │
                            ▼
engine sees:   create({ params: {
                  __workerLoaderMetadata: { tenantId: 't-42' },
                  params: { name: 'Alice' }
               }})

④ 엔진까지. 그런 다음 Worker Loader는 봉투를 매개변수로 하여 실제 WORKFLOWS 바인딩에서.create() 를 호출합니다. 여기에서 Workflows 엔진이 대신합니다. 이 메서드는 이제 envelope을 포함하는 event.payload 를 유지하고 실행을 예약합니다. 나중에 엔진이 워크플로우를 재개할 때마다(24시간 절전 모드, 충돌, 배포 후 여부) 메타데이터는 페이로드를 따라 이동하면서 실행 라우팅을 기다립니다.

한 가지 시사점은 메타데이터를 인증이 아닌 라우팅 힌트로 처리하는 것입니다. 테넌트는 instance.status()를 통해 이를 다시 읽을 수 있습니다. 거기에 비밀을 입력하지 마세요.

5 → 6 다시 엔진이 꺼집니다. 엔진이 단계를 실행할 준비가 되면 사용자가 wrangler.jsonc에 등록한 클래스에서 createDynamicWorkflowEntrypoint에서 제공했던 클래스에서.run(event, step)을 호출합니다. 이 클래스는 봉투의 래핑을 풀고, loadRunner 콜백 사용자가 작성한 콜백에 메타데이터를 전달하고, 콜백이 반환하는 러너에게 래핑되지 않은 이벤트를 전달합니다.

흥미로운 모든 일이 콜백에서 발생하며 전적으로 사용자의 책임입니다. R2에서 테넌트의 최신 소스를 가져옵니다. 요금제 등급을 확인하고 지역을 선택하세요. 테넌트별 로깅을 위해 Tail Worker를 연결합니다. @cloudflare/worker-bundler를 사용하여 TypeScript를 즉시 번들로 제공합니다. 일반적인 경우에는 다음을 Worker Loader로 넘기면 됩니다.

const stub = env.LOADER.get(tenantId, () => loadTenantCode(tenantId));
return stub.getEntrypoint('TenantWorkflow');

Worker Loader는 ID별로 캐시하므로, 여러 시간에 걸쳐 여러 단계를 실행하는 워크플로우는 단계 간에 동일한 동적 Worker를 재사용합니다. 격리가 결국 해제되면 다음 step.do() 에서 코드를 다시 가져와 계속 이동합니다. 테넌트의 워크플로에서는 아무 일이 발생했는지 알지 못합니다. Dynamic Worker는 몇 메가바이트의 메모리를 사용하여 한 자릿수 밀리초 단위로 부팅되므로 디스패치 오버헤드는 본질적으로 무료입니다. 각각 고유한 워크플로 코드를 가진 백만 개의 테넌트를 보유하고, 필요한 단계 경계에서 느리게 가동하고, 유휴 상태에서는 비용이 전혀 발생하지 않습니다.

이스케이프 해치

Run() 주변에 로깅을 추가하거나, 테넌트별 관찰 가능성을 연결하거나, 사용자 지정 상태를 스레드하기 위해 WorkflowEntrypoint를 직접 서브클래스로 만들고 싶은 경우,라이브러리에서는 createDynamicWorkflowEntrypoint가 구축된 하위 수준의 scriptWorkflow 프리미티브를 노출합니다.

import { dispatchWorkflow } from '@cloudflare/dynamic-workflows';

export class MyDynamicWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    return dispatchWorkflow(
      { env: this.env, ctx: this.ctx },
      event,
      step,
      ({ metadata, env }) => loadRunnerForTenant(env, metadata),
    );
  }
}

그 외의 모든 요소(ID, 일시 중지/재개, sendEvent, 재시도)는 그대로 실제 Workflows 엔진으로 전달됩니다.

Dynamic Workers는

다시 세부적인 내용을 다룰 차례입니다. 이 라이브러리에서 흥미로운 줄은 모두 아웃바운드 측의 주위에 있는 주위의 래퍼(round) 또는 인바운드의 경우에 WorkflowEntrypoint의 주위에 있는 래퍼입니다. 테넌트의 코드를 스핀업하고, 샌드박싱하고, 경계를 넘어 RPC를 라우팅하고, 격리를 캐싱하고, 단계 사이를 최대 절전 모드로 전환하는 실제 작업은 모두 그 아래에 있는 Dynamic Workers에서 수행됩니다.

이것이 실제 사례이며 Workflows보다 훨씬 큽니다

Dynamic Workers는 모든 것을 삼켜버리는 기본 요소입니다. Durable Object Facets 는 Durable Objects에 적용된 것과 동일한 패턴입니다. 동적 Workflows는 WorkflowEntrypoint에 동일한 패턴을 적용한 것입니다. 각 바인딩은 여러분이 항상 사용했던 정적 바인딩과 이제 고객에게 건네줄 수 있는 동적 버전 사이에서 봉투를 풀고 풀고 같은 소량의 풀 역할을 합니다.

또한, Workflows에 그치지 않습니다. 현재 Workers가 노출하고 있는 모든 바인딩은 역동적인 대기열로 향하고 있습니다. 각 제작자가 자체 핸들러, 캐시, 데이터베이스, 개체 스토어, AI 바인딩, MCP 서버를 배송하며 모든 테넌트가 자체 도구를 가져오는 대기열입니다. 현재 여러분이 Worker에 무엇을 바인딩하든, 곧 테넌트별로, 에이전트별로, 요청별로 동적으로 바인딩되며 유휴 비용이 없습니다.

이런 플랫폼을 운영하는 것은 솔직히 말해서 말도 안 됩니다. 예전에는 다중 테넌트 제품을 출시한다는 것은 모든 고객에게 자체 컨테이너, 자체 데이터베이스, 자체 디스크, 자체 스케줄러를 제공하고 이를 오케스트레이션 글루, 서비스 메시, 까다로운 청구 수학으로 결합하는 것을 의미했습니다. 이러한 애플리케이션 중 상당수는 최소한 수천 명의 고객을 지원해야 합니다. 수백만 달러에 달합니다. Dynamic Workers와 그 위에 구성되는 모든 것에서 유휴 테넌트는 비용이 거의 들지 않으며 활성 테넌트는 격리 수준 멀티 테넌트를 통해 동일한 하드웨어를 공유합니다. 수준이 몇 배나 됩니다. 수천 명의 유료 고객으로 이어진 플랫폼은 이제 수천만 명의 고객에게 합리적으로 서비스를 제공할 수 있습니다.

Cloudflare의 이점

엔지니어처럼 계획하는 에이전트 플랫폼

코딩 에이전트 — OpenCode, Claude Code, Codex, Pi —는 지난 한 해 동안 LLM이 순차적인 도구 호출보다 코드 작성 에 훨씬 더 능숙하다는 것을 입증해 왔습니다. Cloudflare 에이전트 SDK 와 Project Think 는 이러한 인사이트를 지속형 실행으로 확장합니다. 파이버 및 하위 에이전트와 같은 기본 요소를 통해 에이전트의 장기 실행 계획은 충돌, 최대 절전 모드, 재배포 후에도 사용자가 인지하지 못하는 사이에 계속 실행될 수 있습니다.

동적 Workflows는 계획을 최고 수준의 Cloudflare Workflow 로 만들어주는 요소입니다. 이는 에이전트가 말 그대로 작성하고 플랫폼이 말 그대로 실행하며, 완전한 내구성 메커니즘이 뒷받침됩니다. 모델이 1분 전에 작성한 run(event, step) 함수를 살펴보면, 모든 step.do(...) 는 독립적으로 재시도할 수 있고, 모든 step.sleep('24 hours') 는 무료로 최대 절전 모드로 전환하며, 모든 step.waitForEvent(...) 는 사람이 다음 작업을 승인할 때까지 무기한 기다립니다. 에이전트가 워크플로를 작성합니다. 플랫폼에서 실행됩니다. 계획이 어떻게 보이는지 미리 알 필요가 없습니다.

SDK 및 프레임워크에서 사용자가 로직을

고객이 run(event, step) 함수를 작성하는 프레임워크(워크플로우 빌더 UI, 시각적 자동화 도구, 테넌트별 확장 시스템, 비개발자를 위한 로우코드 도구)를 출시하는 경우, Dynamic Workflows는 이제 손상 없이 작동하게 하는 기본 요소입니다. wrapWorkflowBinding({ tenantId }) 을 한 번 호출하고, 그 결과를 코드에 WORKFLOWS로 전달하면, 생성하는 모든 워크플로우 인스턴스에 자동으로 태그가 지정되고 다시 라우팅되어 샌드박스에서 실행됩니다. 프레임워크는 Worker Loader를 소유합니다. 사용자가 워크플로를 소유합니다. 어느 쪽도 다른 쪽을 신경 쓸 필요가 없습니다.

기본 속도의 CI/CD

다음은 우리를 가장 흥미롭게 만든 사용 사례입니다.

현존하는 모든 CI/CD 플랫폼은 기본적으로 각 Repo 구성 파일의 디스패처입니다. "이러한 단계를 이 순서대로, 이러한 비밀과 함께 실행하고, 이 디렉터리를 캐시하고, 이 아티팩트를 업로드합니다." 각 저장소에는 자체 파이프라인이 있습니다. 각 분기에는 고유한 변형이 있을 수 있습니다. 각 풀 요청은 해당 파이프라인의 인스턴스를 생성하며, 실행을 완료하고, 컴퓨터 충돌에서 생존하며, 비정상적인 단계를 다시 시도하고, 로그를 스트리밍하고, 승인을 위해 일시 중지하고, 결과를 유지해야 합니다.

그것이 바로 정확히 지속 가능한 워크플로우의 형태입니다. CI가 지금까지 이런 방식으로 구축되지 않았던 이유는 리포지터리마다 워크플로우 자체가 다르고 런타임에 파견되며 프로비저닝 비용은 없는 클라우드 기본 요소가 없었기 때문입니다. 이제 할 수 있습니다.

다음은 고객이 자신의 저장소와 함께 제공하는 코드(예: .cloudflare/ci.ts)일 때 CI 파이프라인의 모습입니다. 워크플로우 자체는 실제입니다. 아래의 runInSandbox() / summarise() / GitHub 바인딩 도우미는 플랫폼에서 제공하는 연결 고리이며, 디스패처에 한 번 배포할 만한 종류의 것입니다.

import { WorkflowEntrypoint } from 'cloudflare:workers';

export class CIPipeline extends WorkflowEntrypoint {
  async run(event, step) {
    const { repo, sha, branch, pr } = event.payload;

    // Fork an isolated copy of the repo at this commit. Seconds, not minutes.
    const workspace = await step.do('checkout', () =>
      this.env.ARTIFACTS.fork(repo, { sha })
    );

    await step.do('install', () => runInSandbox(workspace, ['pnpm', 'install']));

    // Each parallel step is independently retryable.
    const [lint, test, build] = await Promise.all([
      step.do('lint',  () => runInSandbox(workspace, ['pnpm', 'lint'])),
      step.do('test',  () => runInSandbox(workspace, ['pnpm', 'test'])),
      step.do('build', () => runInSandbox(workspace, ['pnpm', 'build'])),
    ]);

    if (pr) {
      await step.do('comment', () =>
        this.env.GITHUB.commentOnPR(repo, pr, summarise({ lint, test, build }))
      );
    }

    // Workflow hibernates until approval arrives. No VM held open.
    if (branch === 'main') {
      await step.waitForEvent('approval', { type: 'deploy-approval', timeout: '24 hours' });
      await step.do('deploy', () => runInSandbox(workspace, ['pnpm', 'deploy']));
    }
  }
}

플랫폼이 디스패처를 소유합니다. 웹훅을 수집하고, 어느 레포에서 왔는지 파악하고, 해당 레포의 CIPipeline 클래스를 Dynamic Worker로 로드한 다음, 실행을 Dynamic Workflows에 전달합니다. 플랫폼에서는 파이프라인에 무엇이 있는지 알 수 없습니다. 그럴 필요가 없습니다. 이 시스템은 우연히 고객의 리포지토리에 있는 지속형 기능을 실행하고 있습니다.

이제 각 단계가 실제로 수행하는 작업을 나열하세요.

아티팩트 는 전 세계에 분산된 Cloudflare의 네트워크에서 구동되는 Git 네이티브 버전 파일 시스템을 모든 저장소에 제공합니다. ArtifactFS는 나무를 느리게 수화하므로 수 GB가 된 저장소도 한 자릿수 초 이내에 작동할 준비가 되어 있으며 fork()는 각 CI에 git 복제 세금 없이 자체 격리된 복사본을 실행할 수 있도록 합니다.
Dynamic Workers 는 리포지터리의 데이터와 동일한 시스템에서 밀리초 단위로 부팅되는 샌드박스를 사용한 격리에서 각 간단한 단계(린트, 포맷, 유형 검사, 번들)를 실행합니다. VM 프로비저닝도 없고, 이미지 풀도 없고, 콜드 스타트도 없습니다.
Dynamic Workflows 는 전체 실행을 하나로 통합합니다. 단계는 다시 시도할 수 있으며 지속 가능합니다. 실행은 승인을 기다리는 동안 무료로 최대 절전 모드로 전환됩니다. 배포, 만료, 충돌이 발생해도 상태 및 진행률은 살아남습니다.
샌드박스는 도커 빌드가 필요한 단계, Postgres를 실행해야 하는 통합 제품군, 8개의 코어가 필요한 Rust 컴파일이 필요한 어려운 단계를 처리합니다. R2에 대한 스냅샷은 심지어 몇 초 만에 웜 스타트하는 것을 의미합니다.

기존의 CI 실행 과정은 중형 JS Repo에 대해 진행되었습니다. → 해체합니다. 첫 번째 테스트가 실행되기 몇 분간 식을 진행하면 전체 VM의 비용을 지불하게 됩니다.

이 스택의 동일한 파이프라인은 다음과 같습니다: 리포지토리의 에지 포크(초) → 각 단계에 따라 밀리초 내에 새로운 격리 또는 스냅샷 복원 샌드박스가 부팅됨 → 실제 작업이 실행됨 → 최대 절전 모드로 전환됨. 어떤 것도 콜드 스타트가 필요하지 않습니다. 아무것도 미리 프로비저닝할 필요가 없습니다. 어떤 것도 따뜻하게 유지할 필요가 없습니다. 저장소는 움직이지 않습니다. 컴퓨팅이 핵심입니다.

CI가 이렇게 빨랐던 적이 없으며, 그렇지 않은 이유는 이러한 기본 요소가 한 곳에 함께 존재하지 않았기 때문입니다. 이제 실행 가능합니다.

체험하기

@cloudflare/dynamic-workflows 는 MIT 라이선스이며 오늘 npm에 출시되었습니다.

npm install @cloudflare/dynamic-workflows

Workers Paid 요금제의 오픈 베타 버전인 Dynamic Workers를 기반으로 실행됩니다. 이 저장소 에는 작동하는 예제가 포함되어 있습니다. 즉, 대화형 브라우저 플레이그라운드에서 TenantWorkflow 클래스를 작성하고, 실행을 누르면, 라이브 스트리밍 로그와 각 step.do() 가 실행될 때마다 불이 들어오는 단계별 체크리스트를 통해 단계가 실행되는 것을 확인할 수 있습니다. 커밋합니다. 복제하고, 배포하고, 동료에게 보여주세요.

여러분이 플랫폼, SDK, 프레임워크, CI/CD 제품이고, 고객에게 여러분의 자체 프로세스에서 코드를 실행하지 않고 자체 워크플로를 제공하고자 하는 경우, 이것이 바로 저희가 구축한 기본 기능입니다. 영구적인 계획을 작성하는 에이전트를 구축하는 경우, 이것이 바로 계획을 실제 Workflows로 만드는 기본 요소입니다. 여러분이 이 모든 것을 지켜보고 있으며 그 위에 구축하는 것이 재미있어 보이신다면, 여러분의 창작 활동을 지켜보고 싶습니다.

Cloudflare 개발자 Discord에서 저희를 찾으세요.

Cloudflare 블로그

Dynamic Workflows 소개: 테넌트를 따르는 Durable 실행