Uncaged — 能力虚拟化¶

一句话

有限的槽位 + 无限的能力 → 动态调度。操作系统换页、Agent 工具上下文、Cloudflare Worker 配额——本质是同一个问题。

问题的发现¶

2026-04-02，主人在讨论 Uncaged（基于 Cloudflare Workers 的 Serverless 平台）架构时，从操作系统的 LRU 内存换页机制出发，发现了一个跨领域的统一模式：

CF Workers 免费版只允许 100 个 Worker，付费版也只有 500 个；AI Agent 的 Context Window 也只能装有限数量的工具描述。两者的瓶颈结构完全一致。

Cloudflare Workers 平台配额¶

数据来源：Cloudflare Workers Limits（2026-04 查证）

特性	Workers Free	Workers Paid ($5/月)
Worker 数量	100	500
CPU Time / 请求	10 ms	5 min（默认 30s，可调）
请求量	100,000/天	无限制
Subrequests / 请求	50	10,000
内存	128 MB	128 MB
Worker 包大小	3 MB	10 MB
Cron Triggers	5	250

Workers for Platforms

如果需要突破 500 Worker 上限，CF 提供了 Workers for Platforms 产品，专为多租户场景设计，支持无限数量的用户 Worker、自定义限额、可观测性和标签管理。这是 Uncaged 长期演进的候选方案。

统一模型¶

┌─────────────┐
│  能力池      │  无限：KV 里的代码 / 所有可用工具
│  (磁盘/冷存) │
└──────┬──────┘
       │ 按需加载 (page in)
       ▼
┌─────────────┐
│  活跃槽位    │  有限：100~500 Worker / Context Window
│  (内存/热区) │
└──────┬──────┘
       │ LRU 淘汰 (page out)
       ▼
┌─────────────┐
│  回收        │  释放槽位给更需要的能力
└─────────────┘

对照表¶

维度	AI Agent 工具上下文	Uncaged Workers
槽位限制	Context Window (token 数)	100~500 Worker 配额
能力池	所有可用工具 / 技能	KV 里所有 Worker 源码
瓶颈表现	Token 太多 → 模型注意力下降	配额用完 → 无法部署新服务
调度策略	按语义相关性加载工具	按访问频率 LRU 换页
索引机制	工具描述 / 语义匹配	路由表 / 访问计数器

OpenClaw Skills：已有的两级页表¶

OpenClaw 的 Skills 机制天然实现了这个模式：

L1 页表（常驻）：每个 Skill 的 <description> 标签，轻量，始终在 Context 里
L2 页面（按需加载）：SKILL.md 完整内容，只在匹配到时才 read 进来

Agent 收到请求
  → 扫描所有 Skill 描述（L1，常驻）
  → 匹配到最相关的 Skill
  → read SKILL.md（L2，按需加载）
  → 执行

这就是两级页表——用极小的索引成本覆盖大量能力，只在需要时付出完整加载的代价。

Uncaged 分层架构¶

将同样的思路应用到 Uncaged，Worker 分为两层：内核态和用户态。

内核态 — 系统 Worker（常驻部署）¶

类比操作系统的内核进程，这些 Worker 是平台本身运行的基础设施，始终在线：

系统 Worker	职责	类比
forge-router	路由分发、LRU 调度器	内核调度器
worker-crud	Worker 的创建/部署/删除 API	进程管理 (fork/exec/kill)
auth-gateway	鉴权、密钥验证、访问控制	安全子系统
health-check	状态页、心跳检测	watchdog
kv-manager	KV 代码仓库管理	文件系统

这些对应 Agent 架构中的 Skill 注册表——不是具体能力，而是让能力能被发现和调度的基础设施。

用户态 — 业务 Worker（LRU 换页）¶

实际的业务功能 Worker，通过 LRU 策略动态管理：

全部源码存在 KV（相当于磁盘）
收到请求时，如果目标 Worker 未部署：
1. 从 KV 读取源码
2. 通过 CF API 部署 Worker
3. 配额满时，淘汰最久未访问的 Worker（LRU page out）
冷启动延迟 1-3 秒（CF API 部署时间）

请求 → forge-router（内核态）
  → 查路由表
  → 已部署？→ 直接转发（命中）
  → 未部署？→ worker-crud 从 KV 拉代码 → 部署 → 转发（换入）
  → 配额满？→ LRU 淘汰最冷用户 Worker → 再部署（换页）

配额分配策略¶

以付费版 500 Worker 为例：

层级	分配	用途
内核态	~10 个	系统基础设施，永不换出
用户态热区	~490 个	业务 Worker，LRU 管理
KV 冷存	无限	全部 Worker 源码备份

关键约束¶

约束	影响	应对
CF 禁止 `unsafe-eval`	不能在 forge 内部 `eval()` KV 代码	必须通过 CF API 部署为独立 Worker
Worker 数量上限	Free 100 / Paid 500	LRU 换页；长期考虑 Workers for Platforms
CF API Rate Limit	1000 req/min	批量操作需节流；预热策略减少突发换页
冷启动延迟	CF API 部署 1-3 秒	内核态 Worker 覆盖关键路径；业务 Worker 预热
免费版 CPU Time	10ms / 请求	路由转发 < 1ms 足够；复杂逻辑用付费版（默认 30s，可调至 5min）

设计哲学¶

Uncaged = 能力虚拟化平台。

就像操作系统让每个进程以为自己拥有全部内存，Uncaged 让每个 Agent 以为自己拥有无限的 Worker。实际的物理限制通过智能调度变得透明。

这个思路不仅适用于 CF Workers，也是 AI Agent 工具管理的通用范式：

核心原则

不要试图把所有能力同时装进有限的槽位。用轻量索引覆盖全局，按需加载具体能力，LRU 回收不活跃的资源。