Agents Week 2026

Cloudflare
智能体五层架构

从 Workspace 到 Sandbox — 逐级授权的智能体运行时策略

技术研究报告 · 五层执行能力梯子 (Tier 0–4)

核心理念

默认不给电脑，只给最小可用能力

01

最小可用

智能体在 Tier 0 (文件工作区) 就应该能完成大量工作

02

按需升级

更高层不是替代低层，而是在任务需要时叠加

03

三维控制

成本、安全、性能同时优化，而非只选其一

五层执行能力梯子

// 持久化工作区

Tier 0: Workspace

可持久化的虚拟文件系统 (DO SQLite)
工具集: read / write / edit / list / find / grep / delete
不执行代码，不直接联网
整个五层中的最小公共状态平面
与 Artifacts 互补: 会话级 vs 版本化协作

// 运行时代码执行

Tier 1: Dynamic Worker

V8 Isolate 沙箱，启动几毫秒，内存几 MB
Capability-based Security: 按需授权，非默认给权
globalOutbound 可设为 null，完全断网
Durable Object Facets: 受监管的持久化子实例
比典型容器快 ~100 倍

// 生态扩展

Tier 2: npm 依赖层

worker-bundler + esbuild 运行时打包 npm 包
仍运行在 Tier 1 沙箱内，不换执行器
让模型写出的程序能接入现成 JS 生态
风险: 供应链治理 / bundle 冷路径延迟 / 版本漂移

// 浏览器能力层

Tier 3: Browser Run

CDP (Chrome DevTools Protocol) 驱动 headless browser
当目标服务没有 MCP 或 API 时的兜底方案
Live View + Human in the Loop (MFA/CAPTCHA)
默认每次新会话，无 cookie/登录状态继承

// 完整计算机环境

Tier 4: Sandbox

Workers + DO + Containers，每个 sandbox 独立 VM
真实终端、进程管理、后台服务、Preview URL
与 Workspace 双向同步
安全: 文件/进程/网络/资源配额四维隔离
成本最高，但能力最完整

数据与请求流向

用户请求

→

Agent Turn

→

组装上下文

→

模型推理

→

需要哪层?

→

Tier 0-4

→

结果回写

智能体主循环先做规划，再做分层升级，而不是默认在最重环境里执行所有动作。

横向配套能力

AI Gateway / Workers AI

统一推理层、模型目录、自动 failover

Agent Memory

FTS5 + 向量检索 + HyDE，长期交互记忆

AI Search

混合检索 + RRF 融合，agent 原生搜索

Access / Mesh

Managed OAuth + 私网接入，agent 一等身份

MCP Portal

工具发现、DLP、审计、最小暴露

Workflows

50K 并发实例，耐久调度控制面

工程与产品评估

优势

平均成本压在低层，极端能力放在高层
安全设计前移到能力授予模型
执行/推理/检索/记忆/身份/安全统一平台
已验证: 3683 活跃用户, 241 亿 tokens routed

挑战

升层策略: 什么条件允许进入 Tier 3-4?
Tier 2 供应链治理需企业侧补充
多状态面: Workspace/Memory/Search/Artifacts/Sandbox
状态分类与治理边界需前置设计

核心结论

能用文件就别上代码，能用受限代码就别上生态依赖，能用 API 就别开浏览器，能不开完整电脑就不要给完整电脑

最适合: 长生命周期、多用户、多租户、需要强隔离的在线智能体平台
核心价值: 把"能力升级"做成产品化的决策路径
关键前提: 明确升层策略、状态分类和治理边界

Cloudflare智能体五层架构