4.2 KiB
4.2 KiB
Uncaged — 能力虚拟化
!!! abstract "一句话" 有限的槽位 + 无限的能力 → 动态调度。操作系统换页、Agent 工具上下文、Cloudflare Worker 配额——本质是同一个问题。
问题的发现
2026-04-02,主人在讨论 Uncaged(基于 Cloudflare Workers 的 Serverless 平台)架构时,从操作系统的 LRU 内存换页机制出发,发现了一个跨领域的统一模式:
CF Workers 免费版只允许 500 个 Worker;AI Agent 的 Context Window 也只能装有限数量的工具描述。两者的瓶颈结构完全一致。
统一模型
┌─────────────┐
│ 能力池 │ 无限:KV 里的代码 / 所有可用工具
│ (磁盘/冷存) │
└──────┬──────┘
│ 按需加载 (page in)
▼
┌─────────────┐
│ 活跃槽位 │ 有限:500 Worker / Context Window
│ (内存/热区) │
└──────┬──────┘
│ LRU 淘汰 (page out)
▼
┌─────────────┐
│ 回收 │ 释放槽位给更需要的能力
└─────────────┘
对照表
| 维度 | AI Agent 工具上下文 | Uncaged Workers |
|---|---|---|
| 槽位限制 | Context Window (token 数) | 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:
L1 — 热 Worker(独立部署)
- 核心高频服务,始终在线
- 独立 CF Worker,性能最优
- 数量:~50 个关键服务
L2 — 冷代码(KV 存储 + 按需部署)
- 全部 Worker 源码存在 KV(相当于磁盘)
- 收到请求时,如果目标 Worker 未部署:
- 从 KV 读取源码
- 通过 CF API 部署 Worker
- 淘汰最久未访问的 Worker(LRU)
- 冷启动延迟 1-3 秒(CF API 部署时间)
路由表 — Forge Router(常驻)
- 轻量映射:
路径 → Worker 名 → 部署状态 - 记录每个 Worker 的最后访问时间
- LRU 淘汰决策的依据
请求 → Forge Router
→ 查路由表
→ 已部署?→ 直接转发(L1 命中)
→ 未部署?→ KV 读源码 → CF API 部署 → 转发(L2 换入)
→ 配额满?→ LRU 淘汰最冷 Worker → 再部署(换页)
关键约束
| 约束 | 影响 | 应对 |
|---|---|---|
CF 禁止 unsafe-eval |
不能在 forge 内部 eval() KV 代码 |
必须通过 CF API 部署为独立 Worker |
| CF API Rate Limit | 1000 req/min | 批量操作需节流;预热策略减少突发换页 |
| 冷启动延迟 | 1-3 秒 | L1 热 Worker 覆盖高频请求;低频可接受 |
| 免费版 CPU Time | 10ms/请求 | 简单路由足够;复杂逻辑考虑付费版(50ms) |
设计哲学
Uncaged = 能力虚拟化平台。
就像操作系统让每个进程以为自己拥有全部内存,Uncaged 让每个 Agent 以为自己拥有无限的 Worker。实际的物理限制通过智能调度变得透明。
这个思路不仅适用于 CF Workers,也是 AI Agent 工具管理的通用范式:
!!! tip "核心原则" 不要试图把所有能力同时装进有限的槽位。用轻量索引覆盖全局,按需加载具体能力,LRU 回收不活跃的资源。
来源:2026-04-02 主人与小墨的架构讨论