网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

如果你学过计算机组成原理，一定知道一个经典事实：

CPU 为什么快？

很多人第一反应是：

主频更高

其实真正的原因不是，而是：

Cache

现代 CPU 真正依赖的是：

L1 Cache
      ↓
L2 Cache
      ↓
L3 Cache
      ↓
Memory

同样数据库为什么快？因为：

Buffer Pool

Linux 为什么快？因为：

Page Cache

浏览器为什么快？因为：

HTTP Cache

几乎所有大型系统都会有一个共同特点：

不会每次都重新读取全部数据。

而今天越来越多 AI Native 应用，却仍然在做一件非常低效的事情：

每一次请求
↓

重新构建全部 Context

这就是为什么很多 Agent：

• 响应越来越慢
• Token 消耗越来越高
• 推理成本越来越大
• 用户体验越来越差

问题并不在模型，真正的问题在于：

Context
没有缓存。

因此，一个新的 Runtime 能力开始出现：

Context Cache

它很可能会成为未来 HarmonyOS PC 最重要的系统能力之一。

一、为什么每次推理都在"冷启动"？

来看一个开发场景，开发者正在 HarmonyOS PC 上开发 AMS 系统。

Workspace 当前包含：

• DevEco Studio
• Git 仓库
• 接口文档
• 数据库设计
• 企业微信
• 浏览器
• AI 助手

用户连续输入：

帮我分析当前审批流。

继续生成接口。

补充单元测试。

优化刚才那段代码。

对于开发者来说，这些请求都属于：

同一个任务

但是很多 AI 系统实际上却在执行：

读取 Workspace

↓

重新扫描工程

↓

重新分析文件

↓

重新组织 Prompt

↓

重新推理

也就是说每一次请求，都是一次：

Cold Start

这显然是一种巨大的浪费。

二、真正应该缓存的不是 Prompt，而是 Context

很多团队开始优化：

Prompt Cache

例如，缓存：

System Prompt

或者：

Few-shot 示例

这当然可以提升效率，但真正昂贵的其实不是 Prompt。

而是：

Context Construction

例如，当前：

Workspace

↓

Project

↓

Current File

↓

Current Selection

↓

Task

↓

Goal

这些数据，每次重新构建都会产生：

• 文件读取
• Workspace 分析
• AST 分析
• Memory 检索
• 向量召回

真正耗时的正是这些步骤。因此未来真正需要缓存的是：

Runtime Context

而不是：

Prompt Text

三、什么是 Context Cache？

可以把它理解成：

AI Runtime 的二级缓存。

例如：

interface ContextCache {

    workspaceId: string

    activeGoal: Goal

    currentTask: Task

    activeFiles: string[]

    selectedCode: string

    summary: string

    timestamp: number

}

这些数据并不是最终 Prompt。而是：

Runtime Snapshot

每一次推理之前 Planner 首先读取：

Context Cache

而不是：

重新扫描整个 Workspace

这样 Context 构建时间，可以降低一个数量级。

四、为什么 Context Cache 比 Memory 更实时？

很多开发者容易把：

Memory

和：

Context Cache

混为一谈。实际上两者完全不同。

Memory 记录：

历史

例如：

昨天开发了什么？

之前讨论过什么？

而 Context Cache 记录：

现在

例如：

当前 Workspace

当前代码

当前 Task

当前 Goal

当前 Tool

也就是说 Memory 属于：

Long-term Memory

Context Cache 属于：

Working Memory

这更像人脑中的：

工作记忆（Working Memory）

而不是：

长期记忆（Long-term Memory）

五、Context Cache 如何更新？

这也是整个 Runtime 最重要的问题。

传统软件通常采用：

用户点击

↓

更新 State

但是 AI Native Runtime，Context 的来源更多。例如：

Workspace

↓

Window

↓

Task

↓

Goal

↓

Tool

↓

Memory

↓

Device

因此 Context Cache 必须成为：

Event Driven

例如：

文件切换

↓

更新 Cache

或者：

Task 完成

↓

更新 Cache

又或者：

Workspace 切换

↓

重新生成 Snapshot

整个更新流程：

Runtime Event

↓

Context Builder

↓

Context Cache

↓

Planner

真正实现：

增量更新（Incremental Update）

而不是：

全量重建（Full Rebuild）

六、Context Cache 为什么会影响 Agent 效果？

很多人认为模型决定 AI 的能力。实际上 Planner 每次做决策之前，首先读取的是：

Context

例如，当前 Cache：

Workspace：

AMS

↓

Current File：

ApprovalService.ets

↓

Current Goal：

审批流开发

↓

Current Task：

生成测试

Planner 几乎可以立即决定：

调用测试生成 Tool

如果没有 Cache，Planner 需要重新：

• 分析 Workspace
• 检索文件
• 查找 Goal
• 推断当前 Task

不仅速度更慢，还更容易：

理解错误。

因此 Context Cache 实际上决定了：

Planner 的推理质量。

七、HarmonyOS PC 为什么特别适合 Context Cache？

浏览器里的 AI 只能看到：

当前网页

HarmonyOS PC 不一样，Runtime 可以持续维护：

Workspace

↓

Window

↓

Project

↓

Task

↓

Goal

↓

Device

例如：

interface RuntimeSnapshot {

    workspace: Workspace

    activeProject: string

    activeWindow: string

    activeTask: Task

    currentGoal: Goal

}

整个 Snapshot，持续更新。Planner 始终读取：

最新 Context

而不是：

重新构建 Context

因此 HarmonyOS PC 更容易实现：

Workspace Native Context Cache

八、未来 Context Cache 很可能成为 Runtime 的基础设施

过去 CPU 有：

Cache

数据库有：

Buffer Pool

Linux 有：

Page Cache

未来 AI Native Runtime 也会拥有：

Context Cache

它维护的不再是：

数据块（Data Block）

而是：

运行状态（Runtime Snapshot）

未来整个 Runtime 执行链路，很可能演进为：

Workspace Runtime
        ↓
Runtime Event
        ↓
Context Builder
        ↓
Context Cache
        ↓
Goal Planner
        ↓
Agent Scheduler
        ↓
Tool Runtime
        ↓
Execution

这里 Context Cache 已经不只是性能优化，而是：

整个 Runtime 的基础设施。

总结

过去几十年，Cache 加速的是：

数据访问。

未来十年，Context Cache 加速的将是：

AI 理解世界。

过去：

CPU Cache
缓存的是数据。

未来：

Context Cache
缓存的是运行时认知。

过去：

程序每次读取 Memory。

未来：

Agent 每次读取 Context Cache。

因此，对于 AI Native 操作系统来说，真正重要的不只是更大的模型、更长的上下文窗口，而是如何让 Runtime 持续维护一份低延迟、可增量更新、始终反映当前工作状态的 Context Cache。

它连接着 Workspace、Goal、Task、Planner 与 Agent Scheduler，决定了 AI 是否能够持续理解用户、持续执行任务。

也许，未来衡量一个 AI Native 操作系统先进与否，不再只是看模型参数，而是看它是否拥有一套真正意义上的 Context Cache。它将像 CPU Cache 一样，成为整个 Runtime 中不可或缺的基础能力。