子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

过去一年，几乎所有做 Agent 的团队都会遇到一个共同的问题：

为什么 Agent 越用越笨？

刚开始的时候，效果很好：

会搜索

会写代码

会调用 Tool

会规划任务

但随着任务越来越复杂，系统运行时间越来越长，很快就会出现：

忘记用户之前说过什么

重复执行任务

上下文越来越长

推理成本越来越高

回答开始前后矛盾

于是很多团队的第一反应是：

扩大 Context Window

从：

32K

升级到：

128K

256K

1M Context

看起来问题解决了，但实际运行后发现，Token 成本暴涨：

Attention Cost ↑

KV Cache ↑

Latency ↑

历史垃圾越来越多，真正有价值的信息：

<5%

其余：

95%

都是无关历史

模型开始遗忘，大量信息混在一起：

最近的信息

长期知识

任务状态

用户偏好

互相干扰，于是行业慢慢发现：

Memory ≠ Context。

真正的 Agent，不是拥有无限 Context。而是拥有：

像人一样的分层记忆系统。

这也是为什么越来越多的 Agent Runtime，都开始构建：

Short Memory

Long Memory

Semantic Memory

State Memory

从：

上下文管理

演化成：

Memory Architecture

而这背后，本质上是一套存储系统。

一、人类的大脑，本身就是分层记忆

想象一下，当别人问：

你昨天午饭吃什么？

你可以马上回答，但是问：

三年前住在哪里？

需要回忆一下，再问：

自行车为什么会动？

你不需要回忆具体经历，而是直接调用知识。

实际上，人脑一直在使用：

工作记忆

短期记忆

长期记忆

语义记忆

而 Agent 也是一样，如果把所有内容全部塞进 Prompt：

System Prompt
+
历史记录
+
Tool Result
+
Memory
+
当前任务

最终：

100K Token

200K Token

1M Token

系统一定会失控，所以：

Agent 必须像数据库一样进行分层存储。

而不是：

把所有东西都塞进 Context。

二、为什么大 Context 不是答案

很多人认为：

Context Window 越大

Agent 越聪明

其实正好相反，Attention 计算复杂度：

O(n²)

Context 越长：

Latency ↑

KV Cache ↑

Cost ↑

例如：

当前任务

生成登录模块代码

真正需要的信息可能只有：

当前文件

接口定义

设计规范

不到：

2K Token

但实际发送给模型的是：

历史聊天

用户偏好

项目文档

旧任务结果

几十次 Tool 输出

达到：

100K Token

其中：

95%
都是噪音

所以问题来了：

为什么一定要每次都重新发送所有信息？

答案就是：

Memory Layer

需要的时候再取，而不是全部复制。

三、Short Memory：工作记忆

Short Memory 类似于人的：

工作记忆

负责：

当前任务状态

最近几轮对话

最近 Tool 输出

中间推理结果

生命周期：

Session 级别

例如，用户说：

帮我开发一个 Todo App

Agent 当前记住：

current_task = {
    "frontend": "完成",
    "backend": "开发中",
    "test": "未开始"
}

存储：

Redis

InMemory

Session Store

读取速度快

ms级

生命周期短

任务结束即销毁，类似：

CPU Cache

作用：

提供当前上下文。

而不是长期知识。

四、Long Memory：长期记忆

长期记忆保存：

用户偏好

历史项目

行为习惯

过去经验

例如，用户曾经说：

喜欢 Swift

使用 MVVM

数据库使用 PostgreSQL

下一次开发项目时，Agent 不需要重新询问。直接检索：

user_profile = {
    "language":"Swift",
    "architecture":"MVVM"
}

存储介质：

PostgreSQL

MongoDB

MySQL

生命周期：

月级

年级

类似于：

硬盘

特点：容量大、不频繁访问、持久化。

本质上：

Long Memory 是 Agent 的人格。

五、Semantic Memory：真正的知识库

很多信息不是经历，而是知识。例如：

Redis 是什么？

Transformer 原理？

Swift Concurrency 怎么用？

这些内容不应该放在：

Long Memory

而应该进入：

Semantic Memory

通常采用：

Embedding

Vector DB

Knowledge Graph

例如，用户问：

LoRA 原理是什么？

系统：

Question
      ↓
Embedding
      ↓
Vector Search
      ↓
TopK Recall
      ↓
LLM

类似：

RAG

存储：

Milvus

Qdrant

FAISS

PGVector

本质上：

Semantic Memory 是 Agent 的知识大脑。

六、State Memory：真正容易被忽略的部分

很多 Agent 失败，不是因为知识不够。而是：

状态丢失

例如，一个 Coding Agent 正在执行：

生成代码
↓
测试
↓
部署

运行到一半 Agent 重启。如果没有状态保存：整个流程重新开始。

于是需要：

State Memory

记录：

{
 "task_id":123,
 "step":"testing",
 "retry_count":1
}

存储：

Redis

Etcd

ZooKeeper

作用：

Checkpoint

Resume

Recovery

类似：

Kubernetes etcd

本质上：

State Memory 保存的是系统状态，而不是知识。

七、为什么记忆必须分层

很多团队早期都是：

一个 VectorDB 解决所有问题

Session 信息混入知识库

导致：

召回污染

例如，用户昨天说：

今天心情不好

结果搜索：

Redis 原理

竟然召回：

今天心情不好

完全无关。

长期偏好被覆盖

用户：

喜欢 Swift

一次临时项目：

使用 Python

结果人格发生漂移。

状态信息丢失

任务恢复失败，于是系统开始演化：

                 Memory Center
                       │
      ┌────────────────┼───────────────┐
      │                │               │
 Short Memory     Long Memory     Semantic Memory
      │                │               │
 Session          User Profile       Vector DB
      │                │               │
      └────────────┬───┘               │
                   │                   │
               State Memory             │
                   │                   │
                Redis                 RAG

越来越像：

数据库分层架构

而不是：

Prompt Engineering

八、Memory Bus：未来的统一记忆中心

随着 Multi-Agent 出现，一个新的问题来了：多个 Agent 如何共享记忆？

例如：

Research Agent

Coding Agent

Review Agent

如果各自维护 Memory，很快会出现：

信息不同步

重复推理

上下文冲突

于是出现：

Memory Bus

统一管理：

Session Memory

User Memory

State Memory

Vector Memory

所有 Agent：

Read

Write

Subscribe

越来越像：

Redis Cluster

Kafka

Database

Memory 不再属于某个 Agent，而属于整个系统。

九、Agent Runtime 正在从 Context Engine 变成 Memory OS

过去，大家关注：

Prompt

Tool

Model

未来真正需要管理的是：

Memory Lifecycle

Memory Compression

Memory Index

Memory Routing

Memory Sync

整个 Runtime 会逐渐变成：

                 Memory OS
                       ↓
      ┌────────────────────────┐
      │ Session Memory         │
      ├────────────────────────┤
      │ Long Memory            │
      ├────────────────────────┤
      │ Semantic Memory        │
      ├────────────────────────┤
      │ State Memory           │
      ├────────────────────────┤
      │ Memory Router          │
      ├────────────────────────┤
      │ Memory Compression     │
      └────────────────────────┘

越来越像：

Redis
+
数据库
+
操作系统

而不是：

Chat History

总结

如果用一句话理解 Agent Memory：

记忆不是一个无限大的 Prompt，而是一套分层存储系统。

其核心架构可以概括为：

Short Memory
+
Long Memory
+
Semantic Memory
+
State Memory
+
Memory Bus

过去：

Chat History
↓

Long Context

未来正在走向：

Memory Layer
↓

Memory Center
↓

Memory Runtime
↓

Memory Operating System

最终，Agent 的竞争力，很可能不再取决于：

Context Window 有多大

而取决于：

谁能够构建出一个稳定、高效、可持续成长的记忆系统。

因为真正的智能，从来不是记住所有东西。而是：

知道什么该记住，什么该遗忘，以及什么时候应该回忆。