1. 背景LLM Agent 为什么总在“记忆”上栽跟头先聊一个所有做过 LLM Agent 开发的开发者都会遇到的问题。当你用大模型做一个稍复杂的 Agent 时很快就发现它“记不住事”。对话稍微长一点前面提到的用户偏好、中间产生的结论、已经处理完的任务状态统统变得模糊。更让人头疼的是为了让 Agent“记住”这些信息你不得不在每次请求里把历史记录、检索结果、上下文摘要全部拼进 Prompt然后看着 Token 消耗像流水一样上涨响应时间也跟着变慢。这是当前 LLM Agent 落地时最核心的矛盾之一上下文窗口是有限的不可能无限塞历史。Token 是要花钱的塞得越多成本越高。信息不够Agent 又无法做出连续、一致的决策。为了解决这个问题业界出现了很多方案RAG检索增强生成、记忆摘要、向量数据库、长期记忆存储……但绝大多数方案仍然有一个共同的隐含前提——记忆内容最终要“注入”到上下文窗口里被模型以 Token 的形式读取。于是就有了本文要讨论的主题Zero-MemZero-Token Memory Operations即“零 Token 记忆操作”。所谓零 Token 记忆操作核心理念是让 Agent 的记忆读写操作不消耗上下文 Token。记忆不再通过 Prompt 注入而是通过工具调用、外部存储、结构化接口等方式完成模型只在需要的时候以最精炼的方式获取真正有用的信息。这篇文章会围绕以下几个问题展开Agent 记忆问题的本质是什么Zero-Mem 的零 Token 记忆操作到底是什么思路它与 RAG、上下文注入式记忆有什么区别如何自己实现一个零 Token 记忆管理器落地过程中有哪些坑和最佳实践适合的读者包括正在开发 LLM Agent 的工程师、对大模型应用架构感兴趣的同学、以及被 Token 成本和上下文长度困扰的开发者。读完你可以获得一套完整的设计思路和可扩展的代码骨架。2. 先理解 Agent 的记忆困境2.1 三种记忆的划分在讨论 Zero-Mem 之前我们需要先建立一套统一的记忆分类。目前社区里比较常见的是把 Agent 记忆分成三层记忆类型层级典型实现特点短期记忆Short-term对话上下文把历史消息塞进 Prompt直接、但消耗 Token工作记忆Working Memory当前任务状态结构化状态对象、待办列表面向当前任务需要更新长期记忆Long-term跨会话存储数据库、向量库、知识图谱持久化需要检索大多数 Agent 框架默认只实现了短期记忆把 messages 列表不断累积最终全部拼进请求。这种方式在简单 Demo 里没问题但一旦对话轮次变多、任务变复杂就会出现三个非常现实的问题。2.2 三个现实问题第一上下文窗口挤压。即使是最新的长上下文模型窗口也不是无限大的。当历史消息占用 80% 窗口时模型真正可以用来推理的空间所剩无几输出质量会明显下降。而且部分模型在超长上下文下还有“迷失在中间”的问题历史信息虽然都在但模型不一定能正确利用。第二Token 成本线性增长。每次请求都要重新发送全部历史Token 消耗随对话轮数线性增长。对于一个需要长期运行、多轮任务迭代的 Agent 来说这是非常高的成本。有人开玩笑说Agent 不是在干活是在烧 Token。第三记忆检索与更新的粒度太粗。把整段历史塞进去其实是一种非常粗糙的“记忆”方式。真正有用的信息可能只是其中一两句比如“用户偏好 Python 而不是 Java”“订单号是 A12345”“上一步已经完成了数据清洗”。把这些信息从长文本中精确提取出来比无脑塞上下文要难得多但价值也大得多。2.3 记忆的本质是什么从工程角度看Agent 的记忆本质上是一组状态数据用户的偏好、任务进度、实体信息、决策历史、错误记录等。既然是状态数据就应该用状态管理的方式来处理——存储、读取、更新、删除、查询而不是用“拼接文本”的方式来处理。Zero-Mem 的核心主张就在这里把记忆从 Prompt 文本中剥离出来变成一套可操作的数据接口。3. Zero-Mem 的设计思想零 Token 记忆操作3.1 什么叫“零 Token 记忆操作”“零 Token”并不是说 Agent 什么都不记得而是说记忆的读写本身不占据上下文 Token。我们对比两种模式传统模式用户提问 → 拼装历史消息全部转为 Token → 拼装检索到的知识片段全部转为 Token → 拼装当前问题 → 调用 LLM → 返回结果Zero-Mem 思路下的模式用户提问 → Agent 判断需要哪些记忆 → 通过工具接口读取记忆如 get_user_preference → 只把关键结论拼成极短的结构化信息或直接让工具返回处理结果 → 调用 LLM → 返回结果看到区别了吗传统模式是“先全部加载再让模型筛选”Zero-Mem 是“先精准取用再让模型处理”。记忆操作变成了 Agent 主动发起的工具调用Tool Call / Function Call而不是被动拼进上下文的文本。3.2 零 Token 不等于零信息这里需要澄清一个容易误解的概念。零 Token 记忆操作的意思是记忆系统的存取过程不消耗 Token。比如把一条新的记忆写入数据库不需要经过 LLM不消耗 Token。从数据库中读取一条记忆不需要经过 LLM不消耗 Token。更新、删除、检索记忆都不需要经过 LLM不消耗 Token。那模型怎么知道该读哪条记忆呢答案是模型只需要生成一次工具调用指令比如memory_read(keyuser_preference_python)。这个工具调用指令本身确实消耗少量 Token但它只包含一个函数名和几个参数比把整段历史拼进去少几个数量级。这就是“零 Token 记忆操作”的真正含义记忆的存储、读取、管理行为本身不消耗 Token模型只需要为“决定调用哪个记忆操作”付出极少的 Token 成本。3.3 与传统方案的核心区别维度RAG 注入式记忆摘要式Zero-Mem 记忆操作记忆保存方式向量库 原文周期性摘要结构化存储KV、SQL、文档读取时机每次请求都检索定期压缩Agent 按需主动调用Token 消耗检索结果完整注入摘要文本注入仅工具调用参数消耗信息精度依赖相似度排序依赖摘要质量依赖键设计和查询条件适合场景知识问答长对话压缩多步骤任务、状态管理当然这并不是说 Zero-Mem 要完全替代 RAG 和上下文注入。在实际系统中三者往往是配合使用的。Zero-Mem 更擅长的是任务状态、用户偏好、实体信息、决策历史这类结构化记忆RAG 更擅长的是知识文档、语料库这类非结构化内容。4. 零 Token 记忆操作的系统设计4.1 架构分层要落地零 Token 记忆操作我们需要把系统拆成几个清晰的层次┌─────────────────────────────────────────┐ │ Agent 层LLM 工具调用 / 决策逻辑 │ ├─────────────────────────────────────────┤ │ 记忆接口层Read / Write / Update / ... │ ├─────────────────────────────────────────┤ │ 记忆管理核心键管理、过期策略、冲突处理 │ ├─────────────────────────────────────────┤ │ 存储层内存 / SQLite / Redis / 文件 │ └─────────────────────────────────────────┘各层职责如下Agent 层负责理解用户意图决定是否调用记忆接口。LLM 只看到“有哪些记忆工具可用”看不到记忆正文。记忆接口层定义统一的记忆操作 API暴露给 Agent 作为工具。包括读取、写入、更新、删除、列出、搜索等。记忆管理核心负责处理键的命名规范、数据有效期、类型校验、并发冲突等逻辑。存储层真正保存记忆数据的地方。简单场景用 SQLite分布式场景用 Redis需要语义检索再加向量库。4.2 记忆操作的类型设计一个完整的记忆系统至少应该支持以下操作操作方法名说明是否消耗 Token写入memory_write(key, value)保存一条记忆否读取memory_read(key)按键读取记忆否更新memory_update(key, value)更新已有记忆否删除memory_delete(key)删除记忆否列出memory_list(prefix)按前缀列出记忆键否搜索memory_search(query)按关键词检索记忆否或用向量检索这里需要注意一个细节记忆操作的读取结果也不是直接拼 Prompt 的。更推荐的做法是让工具的返回值直接参与程序逻辑比如判断条件、拼装结构化上下文而不是把一大段记忆文本丢回给模型。4.3 为什么工具调用方式能省 Token以 OpenAI 风格的 Function Calling 为例模型在判断是否需要读取记忆时只会生成类似这样的结构{ name: memory_read, arguments: {\key\: \order_status\} }这段结构化输出可能只需要 10~20 个 Token。而如果采用传统方式把整个订单状态历史、之前的操作记录全部拼进 Prompt可能需要几千甚至上万 Token。更重要的是记忆的写入路径完全不需要模型参与。在 Agent 执行某个工具并获得结果后程序可以直接调用memory_write记录关键信息。比如工具返回订单创建成功程序自动写入order_status created。用户明确说自己喜欢简洁回答程序自动写入user_preference concise。一轮任务完成程序更新task_progress stage2_done。这些写入操作消耗的 Token 为 0。这就是零 Token 记忆操作的核心价值。5. 实战实现一个零 Token 记忆管理器接下来我们动手写一个最小可用的零 Token 记忆管理器。为了方便演示我会使用 Python 3存储层选择 SQLite封装成一个可被 LLM Agent 调用的工具类。5.1 环境准备示例环境如下操作系统Windows / macOS / Linux 均可Python3.9 及以上依赖标准库sqlite3、json无需安装第三方包如果你有更复杂的存储需求可以把 SQLite 替换成 Redis、MySQL 或向量数据库接口保持不变。项目结构zero_mem_demo/ ├── memory_store.py # 存储层SQLite 封装 ├── memory_manager.py # 记忆管理核心操作接口 ├── agent_tools.py # 工具封装暴露给 LLM Agent └── demo.py # 演示模拟 Agent 调用记忆操作5.2 存储层实现先写存储层负责最底层的数据库操作。# 文件路径zero_mem_demo/memory_store.py import json import sqlite3 from datetime import datetime from typing import Any, List, Optional class MemoryStore: 基于 SQLite 的记忆存储层。 def __init__(self, db_path: str agent_memory.db): self.db_path db_path self._init_db() def _init_db(self): 初始化数据表。 with sqlite3.connect(self.db_path) as conn: conn.execute( CREATE TABLE IF NOT EXISTS memories ( key TEXT PRIMARY KEY, value TEXT NOT NULL, updated_at TEXT NOT NULL ) ) conn.commit() def set(self, key: str, value: Any) - None: 写入或更新一条记忆。 serialized json.dumps(value, ensure_asciiFalse) now datetime.now().isoformat() with sqlite3.connect(self.db_path) as conn: conn.execute( INSERT INTO memories (key, value, updated_at) VALUES (?, ?, ?) ON CONFLICT(key) DO UPDATE SET value excluded.value, updated_at excluded.updated_at , (key, serialized, now), ) conn.commit() def get(self, key: str) - Optional[Any]: 按键读取一条记忆。 with sqlite3.connect(self.db_path) as conn: row conn.execute( SELECT value FROM memories WHERE key ?, (key,) ).fetchone() if row is None: return None return json.loads(row[0]) def delete(self, key: str) - bool: 删除一条记忆返回是否存在。 with sqlite3.connect(self.db_path) as conn: cursor conn.execute( DELETE FROM memories WHERE key ?, (key,) ) conn.commit() return cursor.rowcount 0 def list_keys(self, prefix: str ) - List[str]: 按前缀列出所有记忆键。 with sqlite3.connect(self.db_path) as conn: rows conn.execute( SELECT key FROM memories WHERE key LIKE ? ORDER BY updated_at DESC, (prefix %,), ).fetchall() return [row[0] for row in rows] def search(self, keyword: str) - List[dict]: 基于关键词的简单检索。 with sqlite3.connect(self.db_path) as conn: rows conn.execute( SELECT key, value, updated_at FROM memories WHERE value LIKE ? OR key LIKE ? ORDER BY updated_at DESC , (f%{keyword}%, f%{keyword}%), ).fetchall() return [ { key: row[0], value: json.loads(row[1]), updated_at: row[2], } for row in rows ]这个存储层有四个特点使用sqlite3标准库零第三方依赖。value字段用 JSON 序列化支持存入任意结构化数据。写入使用ON CONFLICT DO UPDATE天然支持 upsert 语义。提供search方法支持最简单的关键词检索。5.3 记忆管理核心存储层之上是记忆管理核心。它的职责是定义键命名规范、封装记忆操作语义并为 Agent 提供更友好的接口。# 文件路径zero_mem_demo/memory_manager.py from typing import Any, Dict, List, Optional from memory_store import MemoryStore class MemoryManager: 记忆管理核心对外提供语义化记忆操作。 # 键前缀分类定义便于管理和隔离 PREFIX_USER user PREFIX_TASK task PREFIX_DECISION decision PREFIX_FACT fact def __init__(self, store: Optional[MemoryStore] None): self.store store or MemoryStore() staticmethod def _build_key(category: str, name: str) - str: 构建层级化记忆键category:name。 return f{category}:{name} def write_memory(self, category: str, name: str, value: Any) - dict: 写入记忆。category 决定记忆分类name 是具体标识。 key self._build_key(category, name) self.store.set(key, value) return {status: ok, key: key} def read_memory(self, category: str, name: str) - dict: 读取记忆。 key self._build_key(category, name) value self.store.get(key) if value is None: return {status: not_found, key: key, value: None} return {status: ok, key: key, value: value} def update_memory(self, category: str, name: str, value: Any) - dict: 更新记忆。与写入共用 upsert 逻辑但语义上更明确。 return self.write_memory(category, name, value) def delete_memory(self, category: str, name: str) - dict: 删除记忆。 key self._build_key(category, name) deleted self.store.delete(key) return {status: ok if deleted else not_found, key: key} def list_by_category(self, category: str) - List[str]: 列出某个分类下的所有记忆键。 return self.store.list_keys(prefixcategory :) def search_memory(self, keyword: str) - List[Dict[str, Any]]: 按关键词检索记忆。 return self.store.search(keyword)_build_key方法非常关键。它把键设计成category:name的二级结构例如user:language表示用户语言偏好task:12345:status表示某任务的状态decision:order_validate表示之前做过的某个决策这种命名规范让记忆天然具有可分类、可枚举、可隔离的能力。5.4 封装成 Agent 工具接下来是最重要的一步把记忆操作封装成 LLM Agent 可调用的工具。这一步的目的就是 Agent 与记忆系统之间的“协议层”。在 OpenAI Function Calling 风格的框架中工具通常用 JSON Schema 描述。我们需要为每个记忆操作定义一个工具描述同时把执行函数包装成统一的调用格式。# 文件路径zero_mem_demo/agent_tools.py import json from typing import Callable, Dict, List from memory_manager import MemoryManager class AgentMemoryTools: 将记忆操作封装为 Agent 工具。 def __init__(self, manager: MemoryManager): self.manager manager def _wrap(self, func: Callable, *args, **kwargs) - str: 统一包装返回值为 JSON 字符串方便直接作为工具结果返回。 result func(*args, **kwargs) return json.dumps(result, ensure_asciiFalse) def get_tool_schemas(self) - List[Dict]: 返回工具定义列表可直接用于 Function Calling 的 tools 参数。 return [ { type: function, function: { name: memory_write, description: 写入或更新一条记忆。category 表示分类user/task/decision/factname 是标识value 是需要记住的信息。, parameters: { type: object, properties: { category: { type: string, enum: [user, task, decision, fact], description: 记忆分类, }, name: {type: string, description: 记忆标识}, value: {type: object, description: 记忆内容任意 JSON 结构}, }, required: [category, name, value], }, }, }, { type: function, function: { name: memory_read, description: 读取一条记忆。返回记忆的内容。, parameters: { type: object, properties: { category: {type: string, description: 记忆分类}, name: {type: string, description: 记忆标识}, }, required: [category, name], }, }, }, { type: function, function: { name: memory_search, description: 按关键词搜索记忆返回所有匹配的记忆。, parameters: { type: object, properties: { keyword: {type: string, description: 搜索关键词}, }, required: [keyword], }, }, }, ] def execute_tool(self, tool_name: str, arguments: dict) - str: 执行工具调用。arguments 是解析后的字典。 if tool_name memory_write: return self._wrap( self.manager.write_memory, arguments[category], arguments[name], arguments[value], ) if tool_name memory_read: return self._wrap( self.manager.read_memory, arguments[category], arguments[name], ) if tool_name memory_search: return self._wrap(self.manager.search_memory, arguments[keyword]) raise ValueError(fUnknown tool: {tool_name})这个封装层有几个设计要点每个工具的description必须写清楚用途方便模型正确选择。parameters使用 JSON Schema 描述模型可以据此生成合理参数。所有返回值统一JSON序列化保证工具调用链路的稳定性。category使用枚举值避免模型随意构造分类。5.5 模拟 Agent 运行与验证最后写一个演示脚本模拟 Agent 的完整记忆操作流程。# 文件路径zero_mem_demo/demo.py from agent_tools import AgentMemoryTools from memory_manager import MemoryManager # 1. 初始化记忆系统和工具层 manager MemoryManager() tools AgentMemoryTools(manager) print( 模拟 Agent 运行流程 \n) # 2. 模拟用户告诉 Agent 自己喜欢简洁回答 # 传统方案把这一信息注入 Prompt每次请求都消耗 Token # Zero-Mem程序直接调用写入消耗 0 Token result tools.execute_tool(memory_write, { category: user, name: preference, value: {style: concise, language: python}, }) print(写入用户偏好, result) # 3. 模拟Agent 在处理订单任务时需要查询之前的任务状态 # 传统方案把整段历史对话塞进上下文 # Zero-Mem调用一次 memory_read工具调用本身只消耗少量 Token result tools.execute_tool(memory_read, { category: task, name: order_20250101:status, }) print(读取任务状态, result) # 4. 模拟写入任务状态 tools.execute_tool(memory_write, { category: task, name: order_20250101:status, value: {stage: data_cleaned, next_step: model_training}, }) print(更新任务状态done) # 5. 模拟模型不确定该读哪条记忆时使用搜索 result tools.execute_tool(memory_search, {keyword: 数据清洗}) print(搜索记忆结果, result) # 6. 查看当前所有记忆分类 print(\n 当前记忆分类清单 ) for category in [user, task, decision, fact]: keys manager.list_by_category(category) print(f{category}: {keys})运行结果预期如下实际输出会因时间字段略有不同 模拟 Agent 运行流程 写入用户偏好 {status: ok, key: user:preference} 读取任务状态 {status: not_found, key: task:order_20250101:status, value: null} 更新任务状态 done 搜索记忆结果 [] 当前记忆分类 ...5.6 结合 LLM 的完整调用思路上面的示例还没有真正调用 LLM。在真实项目中流程是这样的用户发起对话。Agent 系统拿到用户输入连同工具定义memory_read、memory_write、memory_search等一起发给 LLM。LLM 判断需要读取记忆返回工具调用请求而不是直接回答。系统执行工具拿到记忆结果。系统把工具结果通常很短的结构化数据返回给 LLM或者直接在程序逻辑中使用。LLM 生成最终回答。这个流程里记忆本体从来没有出现在对话上下文中只有工具调用的指令和简短结果经过了模型。当 Agent 执行多轮任务时记忆的读写都在外部完成上下文始终保持精简。这里有一个工程选择需要说明工具结果是否注入回 LLM 上下文取决于你的场景。如果记忆结果只是程序逻辑需要可以不回传如果模型确实需要基于记忆内容做判断就把它以极短的摘要形式回传。无论哪种方式都比把整段历史塞进上下文要节省得多。6. 常见问题与排查思路在实际开发中大家会遇到一些高频问题这里整理成表格供快速查阅。问题现象常见原因解决思路模型生成了不存在的记忆键工具 description 不清晰或没有给出分类约束使用枚举值限制 category在 description 中给出示例键名模型总是忘记调用记忆工具工具列表太长模型注意力分散或工具描述不够明确精简工具数量把记忆工具放在靠前位置优先采用强相关的场景触发记忆写入重复键无法区分键命名没有考虑任务维度引入任务 ID 到键中如task:{task_id}:status记忆数据过时没有定义更新时机在关键节点主动更新记忆设置 TTL 过期策略并发写入导致冲突多个 Agent 实例同时操作同一个键使用 Redis 分布式锁或采用版本号乐观锁先按任务 ID 分片隔离检索效果差简单 LIKE 搜索无法匹配语义升级为 SQLite FTS5 全文检索或接入向量数据库工具返回的结果太大一次读取了大量记忆数据设计分页读取记忆写入时控制单条大小必要时设置摘要机制Agent 重启后记忆丢失使用内存存储改用持久化存储SQLite / Redis / 云数据库下面展开几个更值得重视的问题。关于键冲突。在真实业务中同一个 Agent 可能服务多个用户、多个任务。键如果只写user:preference不同用户之间就会互相覆盖。解决办法是在键中加入用户 ID 或会话 ID例如user:{user_id}:preference。这个思路同样适用于任务级记忆task:{task_id}:status。关于“该读哪些记忆”的判断。LLM 生成的工具调用并不总是准确的。可能模型读了不必要的记忆也可能漏掉了关键记忆。缓解方法包括在系统 Prompt 中说明记忆分类和典型使用场景。在工具 description 中写清“什么时候用”。对高确定性逻辑如程序状态流转不使用 LLM 判断而是由程序直接读写。关于安全边界。记忆系统里可能存有用户隐私、业务敏感数据。必须在工具层做好权限控制。建议至少做到按用户隔离存储、工具调用前校验权限、敏感字段加密存储、日志脱敏输出。7. 最佳实践与工程建议7.1 记忆键设计规范键是记忆系统的门面。一套清晰的键规范能减少大量索引和维护成本。推荐采用三段式{命名空间}:{用户/会话ID}:{业务标识}例如usr:u10086:pref_langtask:t20250101:statusagent:agent01:last_decision三段式的优点是可以按前缀做范围查询、做用户级隔离、加 TTL 批量清理。7.2 记忆写入的自动化不要让模型每次都要显式决定“要不要写记忆”。更可靠的做法是在 Agent 执行链路的固定节点自动写入。例如工具执行成功后由程序自动记录结果摘要。状态机转换时自动更新task:xxx:status。用户明确表达偏好时由拦截逻辑自动写入。这种“半自动化写入”的好处是减少模型失误也让记忆数据更稳定、更可预期。7.3 记忆读取的降级策略如果记忆读取失败比如键不存在Agent 不能崩溃。应该有一套降级策略尝试默认值。调用 LLM 进行模糊判断。向用户询问澄清。例如读取user:pref_lang失败时Agent 可以使用默认语言继续而不是阻塞流程。7.4 可观测性与审计记忆系统需要日志。建议至少记录以下内容写入时间、键、写入来源哪个任务/哪个工具。读取时间、键、读取者。删除操作的完整审计日志。日志不仅用于排查问题也用于分析 Token 节省效果。你可以对比“零 Token 记忆操作方案”和“全注入方案”的 Token 消耗数据量化收益。7.5 渐进式演进路径如果你的项目已经用了传统记忆方案不要一次性推翻重来。建议按以下阶段演进第一阶段旁路记录。在现有 Agent 链路旁边先跑一套记忆存储记录关键状态但不强制 Agent 使用。第二阶段工具暴露。把记忆读写封装成工具让模型在部分场景下使用和现有历史拼接并存。第三阶段精简上下文。当模型开始稳定使用记忆工具后逐步缩减注入的上下文量将短期记忆从“全部拼接”改成“关键信息 工具查询”。第四阶段全面改造。将工作记忆、长期记忆、任务状态全部迁入零 Token 记忆体系上下文只保留当前轮次必需的少量信息。这种渐进策略可以降低重构风险也让每一步的效果都能被量化验证。7.6 量化 Token 收益在团队推广这套方案时一份量化的收益报告比任何概念都有说服力。你可以统计改造前后平均每轮对话的输入 Token 数。多轮长任务比如 20 轮以上的总 Token 消耗。响应时间的差异输入 Token 减少通常会带来首 Token 时延下降。任务完成率是否因记忆更精确而提升。8. 总结与下一步学习方向本文围绕 Zero-MemZero-Token Memory Operations这个核心概念梳理了 LLM Agent 记忆问题的本质并给出了一个可运行的零 Token 记忆管理器实现。关键收获可以总结为三点记忆不是拿来“拼 Prompt”的文本而是需要管理的状态数据。记忆操作可以通过工具调用完成让存储、读取、更新不占用上下文 Token只让模型为“决策”付出极少的 Token 成本。键设计、自动化写入、降级策略和可观测性是落地时最重要的工程细节。下一步你可以从这几个方向继续深入将示例代码接入你正在使用的 Agent 框架LangChain、LlamaIndex、Spring AI 或自研框架。把 SQLite 存储层替换为 Redis 或向量数据库增加语义检索能力。实现基于 TTL 的自动过期机制避免记忆无限膨胀。设计更完善的权限隔离支持多用户多租户场景。尝试用这套机制重构你项目中最耗 Token 的那条 Agent 链路然后对比前后数据。最后提醒一句零 Token 记忆操作并不是银弹。它适合状态型、任务型记忆但知识型问答仍然需要 RAG 或上下文注入来配合。把合适的方案用在合适的场景才是一个稳定、高效的 Agent 系统该有的样子。如果本文对你有帮助可以收藏备用后续实践中有任何问题也欢迎在评论区交流。