---
title: 范围
description: v1 包含什么、从早期执行层计划中删去了什么，以及原因。
sidebar:
  order: 8
---
Runic 并非一直都是缓存。早期计划（仓库中归档在 `_deprecated/` 下，以及用于保留历史背景的 `ALPHA.md`/`ROADMAP.md`）描述的是一个执行运行时：拦截工具调用、执行权限控制、对文件系统/网络访问进行沙箱隔离，以及按严格预算计量。本页说明为何该计划被删减，而非继续扩展。

## v1 的范围

- 缓存某项决策的结果，并以完全匹配的规范化签名为键——`{ intent, params }`，绝不使用原始任务文本，也绝不使用推理轨迹。
- 记录已花费的 token（由代理报告）与缓存命中时节省的 token。
- 单会话范围。跨会话/跨代理共享属于后续阶段，前提是先证明单会话复用在实践中确实重要。

## 明确不在范围内

- **任何形式的执行。** Runic 从不调用能力、部署任何内容或运行代码。旧的 `packages/runtime` 已废弃。
- **权限或沙箱隔离。** 如果没有任何内容执行，就没有需要检查的东西。旧的 `packages/permissions` 和 `packages/sandbox` 已废弃。
- **语义或模糊任务匹配。** 这被刻意限定得很窄——仅完全匹配。这是一项旨在持续保持约束的设计限制，而不是一个 v1 的临时捷径；日后若要放宽，必须重新审视缓存命中是否*确实*代表同一项决策。

## 为什么这是一次转向，而非新增功能

旧执行层计划的大部分内容——权限执行、沙箱隔离、能力执行——最终都与 MCP 已为工具调用标准化的内容重复。在其之上构建并行的权限/执行系统，本身并不是一个站得住脚的切入点；它是与既有标准竞争的冗余基础设施。

缓存与账本的想法在删减后得以保留，因为它回答了 MCP 没有回答的问题：*这个完全相同的决策是否已经被解决过，它的成本是多少？* 这比“Runic 管理你的代理执行”是一个更窄、更诚实的主张——而且这是该仓库实际交付的内容，有真实的基准测试数据支撑，而不是一张架构图。

## 如果你在寻找执行层计划

它作为历史资料保存在仓库根目录的 `ALPHA.md` 和 `ROADMAP.md` 中，代码本身则归档于 `_deprecated/` 下。两者均不再维护，也都不反映 Runic 如今发布的内容——请阅读 [介绍](/) 了解当前情况。