Agent记忆机制全解：从Context、Session到State与Memory的工程实践

很多同学在开发 Agent 类应用时都会遇到一个尴尬情况Demo 阶段效果惊艳一进入真实场景就“失忆”。用户问“我刚才说的那个订单到哪了”Agent 一脸茫然换个会话再聊连用户名字都记不住。这个问题在电商客服助手里尤其致命——用户期待的是一个了解自己、能记住偏好和订单状态的“专属客服”而不是一个每次都要重新认识的机器人。本文围绕Agent 记忆机制展开从Context、Memory、Session、State四个核心概念讲起逐步拆解短期对话状态、长期用户画像与订单记忆、上下文窗口超限处理最后用一个电商客服助手实战案例把整套方案落地成一个清晰的 Python 项目。适合正在做 AI Agent、智能客服、RAG 应用的开发者也适合刚接触 Agent 开发、想建立记忆体系认知的新手。1. 先理解一个问题Agent 为什么需要记忆1.1 没有记忆的 Agent 长什么样先看一个没有记忆机制的对话用户你好我昨天在你们平台买了一个蓝牙耳机订单号是 20240508001。 Agent您好请问有什么可以帮您 用户我想查一下这个订单发货了没有。 Agent请问您能提供一下订单号吗 用户刚才不是说了吗20240508001 Agent好的请稍等……抱歉我没有查到该订单在你当前会话中的关联信息。这段对话几乎是所有 ChatBot 早期版本的共同痛点。原因是大模型本身是无状态的。模型每次收到请求看到的只是一堆文本它不记得上一次请求你说了什么更不记得昨天用户买了什么。1.2 电商客服助手的典型诉求电商客服场景对记忆的要求非常具体能记住当前会话中用户提到的订单号、商品名、问题。能跨会话记住用户身份、收货偏好、会员等级、历史客诉。当对话历史太长、Context 超限时不丢失关键信息。能区分“当前会话的临时状态”和“需要长期保存的用户记忆”。这些诉求对应到技术上就是Session、State、Memory、Context四个概念的分工问题。1.3 一句话总结记忆的价值Agent 记忆不是把所有聊天记录堆在一起而是把信息按生命周期分级管理临时信息放会话里长期信息存记忆库最终在请求前组装成模型需要的 Context。理解了这条主线后面的设计都会变得很清晰。2. 四个核心概念Context、Memory、Session、State很多资料把这四个词混着讲导致初学者很懵。我们先给每个词一个定位。2.1 Context模型当前“看得见”的信息Context 是本次请求中真正传给大模型的全部内容包括 System Prompt、聊天历史、检索到的知识、用户画像、工具返回结果等。Context 的特点是有长度限制不能无限塞内容。有成本每多一个 Token 就多一次 API 费用。有优先级System Prompt、最新消息、关键记忆通常排前面。一个典型的 Context 结构如下[ {role: system, content: 你是电商客服助手请根据用户信息和订单信息回答问题。}, {role: system, content: 用户偏好喜欢性价比商品常用收货地址为上海市浦东新区。}, {role: user, content: 我上次买的耳机什么时候发货订单号是20240508001}, {role: assistant, content: 好的我来查一下……您的订单已发货预计明天送达。} ]2.2 Session一次完整交互的会话容器Session 表示一次服务过程的边界。用户从打开聊天窗口到关闭中间的多轮问答属于同一个 Session。Session 通常包含唯一 ID。关联用户 ID。创建时间、更新时间。当前会话的完整消息历史。Session 不负责长期保存。用户下次再来应该创建一个新 Session然后从 Memory 中恢复长期信息。2.3 Memory跨会话长期保存的信息Memory 是独立于 Session 的长期存储层用于保存值得记住的信息。电商客服场景里常见的记忆包括用户姓名、手机号、会员等级。用户偏好、常见问题、语言习惯。历史订单、退款记录、沟通备注。Memory 的存储介质可以是数据库、JSON 文件、向量数据库甚至 Redis。它解决的核心问题是Session 结束时关键信息不丢。2.4 StateAgent 运行时的可变状态State 是 Agent 在处理请求过程中维护的一份临时运行时数据比 Session 更偏向“当前正在发生什么”。例如客服助手在判断用户意图的过程中会临时记录state { intent: 查订单, order_id: 20240508001, need_confirm: True, pending_action: query_logistics }State 的作用是让 Agent 在多次函数调用、工具调用中保持对“当前任务进度”的感知避免每一步都重新解析。2.5 四者关系速查表概念生命周期作用范围典型存储对应问题Context单次请求当前请求内存列表模型看到了什么Session一次会话多轮对话Redis/本地变量对话边界怎么划Memory用户生命周期跨会话数据库/向量库关键信息怎么留State单次任务过程Agent 内部内存对象任务进度怎么记用一句话记忆Session 划边界State 记进度Memory 做沉淀Context 是最终投喂给模型的“工作台”。3. 短期记忆如何用 Session 组织多轮对话3.1 设计一个 Session 数据结构在 Python 中最简单的 Session 可以是一个带消息列表的数据类# agent/session.py from dataclasses import dataclass, field from typing import List, Dict import time dataclass class Session: session_id: str user_id: str created_at: float time.time() updated_at: float time.time() history: List[Dict[str, str]] field(default_factorylist) def add_message(self, role: str, content: str): self.history.append({role: role, content: content}) self.updated_at time.time() def get_history(self, max_messages: int 10): if max_messages 0: return [] return self.history[-max_messages:]这里把消息直接保存成 OpenAI Chat Completions 风格的结构目的是后面组装 Context 时不需要再做格式转换。3.2 把 Session 历史组装成 Context在真实调用大模型前我们需要把 System Prompt、长期记忆、会话历史合并成一个消息列表# agent/context_builder.py from typing import List, Dict, Any, Optional SYSTEM_PROMPT 你是一名电商平台客服助手。 请根据用户的个人信息、历史订单和当前对话记录友好、简洁地回答用户问题。 如果信息不足请明确告知用户不要编造订单或物流信息。 def build_context( session, user_profile: Optional[Dict[str, Any]] None, memory_messages: Optional[List[Dict[str, str]]] None, max_history: int 6, ) - List[Dict[str, str]]: messages [{role: system, content: SYSTEM_PROMPT}] # 注入长期记忆 if user_profile: profile_text 用户档案 .join( f{k}:{v} for k, v in user_profile.items() ) messages.append({role: system, content: profile_text}) if memory_messages: memory_text 历史关键信息\n \n.join( m[content] for m in memory_messages ) messages.append({role: system, content: memory_text}) # 注入最近几轮会话历史 messages.extend(session.get_history(max_messagesmax_history)) return messages这里有一个重要原则长期记忆用 system 消息注入对话历史按原始顺序追加。这么做的原因是模型对 system 消息的优先级理解通常更高重要信息不容易被长对话淹没。3.3 会话窗口截断如果 Session 历史太长最直接的做法是只保留最近 N 轮# 保留最近 4 轮用户/助手消息 recent session.get_history(max_messages4)缺点也很明显中间的关键信息会被直接丢掉。比如用户第三轮说了订单号但截断后第七轮才问到订单进度订单号已经不在 Context 里了。所以在电商客服场景中我们通常先把订单号、商品名等结构化信息提取出来放到 State 或 Memory 中而不是完全依赖原始聊天记录。4. 长期记忆把对话沉淀成知识4.1 什么信息值得长期保存不是所有聊天内容都值得存。电商客服场景建议保存以下三类类型示例保存方式用户基础信息姓名、手机号、地址用户档案表偏好信息喜欢顺丰、退款要快用户档案表或标签表业务事件反馈过商品破损、申请过退货事件流水表保存时要顺手做“结构化提取”例如用户说“麻烦发到上海浦东”不要原样存这句话而应提取为收货地址更新。结构化的信息更容易被程序读取也能减少 Context 占用。4.2 用 SQLite 实现一个轻量记忆存储这里用 SQLite 做示例方便本地运行。生产环境可以换成 MySQL 或 PostgreSQL。# agent/memory_store.py import sqlite3 import json import time from typing import Dict, Any, List, Optional class MemoryStore: def __init__(self, db_path: str ecommerce_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 user_profile ( user_id TEXT PRIMARY KEY, profile_json TEXT, updated_at REAL ) ) conn.execute( CREATE TABLE IF NOT EXISTS event_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT, event_type TEXT, content_json TEXT, created_at REAL ) ) conn.execute( CREATE INDEX IF NOT EXISTS idx_event_user_time ON event_memory(user_id, created_at) ) def save_profile(self, user_id: str, profile: Dict[str, Any]): with sqlite3.connect(self.db_path) as conn: conn.execute( INSERT OR REPLACE INTO user_profile (user_id, profile_json, updated_at) VALUES (?, ?, ?), (user_id, json.dumps(profile, ensure_asciiFalse), time.time()), ) def load_profile(self, user_id: str) - Optional[Dict[str, Any]]: with sqlite3.connect(self.db_path) as conn: row conn.execute( SELECT profile_json FROM user_profile WHERE user_id ?, (user_id,), ).fetchone() return json.loads(row[0]) if row else None def append_event(self, user_id: str, event_type: str, content: Dict[str, Any]): with sqlite3.connect(self.db_path) as conn: conn.execute( INSERT INTO event_memory (user_id, event_type, content_json, created_at) VALUES (?, ?, ?, ?), (user_id, event_type, json.dumps(content, ensure_asciiFalse), time.time()), ) def search_events(self, user_id: str, limit: int 5) - List[Dict[str, Any]]: with sqlite3.connect(self.db_path) as conn: rows conn.execute( SELECT event_type, content_json, created_at FROM event_memory WHERE user_id ? ORDER BY created_at DESC LIMIT ? , (user_id, limit), ).fetchall() return [ { event_type: r[0], content: json.loads(r[1]), created_at: r[2], } for r in rows ]代码重点看三处save_profile使用INSERT OR REPLACE确保同一用户只保留一份最新档案。event_memory是事件流水保存用户和平台之间的关键历史动作支持后续召回。search_events按时间倒序取最近事件用于组装 Context 时优先展示最新记忆。4.3 写一条“订单查询事件”的持久化在客服助手识别到用户要查订单后可以这样做# 伪代码在服务层调用 store.append_event( user_iduser_123, event_typeorder_query, content{ order_id: 20240508001, asked_at: 2024-05-08 14:30:00, }, )下次用户再来即使不提供订单号我们也能从记忆里召回旧订单减少用户重复描述。4.4 从记忆到 Context召回策略长期记忆不是越多越好。在实际组装 Context 时建议做三步按用户维度过滤只取当前用户的档案和事件。按时间倒序取前 510 条事件保留最新动态。将档案和事件拼接到 system 消息中。如果事件数量很多可以使用关键词匹配甚至接入向量检索做语义召回。完整代码见第 6 章的build_context。5. Context 超限模型窗口不够了怎么办5.1 超限现象开发 Agent 时最常见的报错之一是This models maximum context length is 8192 tokens. However, your messages resulted in 10450 tokens.翻译一下你的 Context 已经超过模型最大上下文窗口请求会被拒绝或截断。即使没报错超长 Context 也会带来两个问题API 费用升高。模型对中间信息的注意力下降容易忽略关键内容。5.2 先做 Token 估算在调用模型前我们应该先估算 Context 长度# agent/context_builder.py def estimate_tokens(text: str) - int: # 中文场景下粗略估算1 个汉字约 1~2 token # 这里取一个简化算法生产环境建议使用 tiktoken 等真实分词器 return len(text) // 1 def estimate_messages_tokens(messages: List[Dict[str, str]]) - int: return sum(estimate_tokens(m.get(content, )) for m in messages)生产环境建议用官方 Tokenizer如 OpenAI 的tiktoken准确统计这里用简化逻辑演示设计思路。5.3 方案一截断历史消息最简单的方法是只保留最近 N 条消息def truncate_to_limit(messages, token_limit6000): # 保留第一条 system 消息 if not messages: return messages system_msg messages[0] rest messages[1:] kept [system_msg] total estimate_tokens(system_msg.get(content, )) # 从最新的消息开始往前保留 for msg in reversed(rest): msg_tokens estimate_tokens(msg.get(content, )) if total msg_tokens token_limit: break kept.insert(1, msg) total msg_tokens return kept这种方案实现快但可能丢掉“旧消息里的关键信息”。适合对话较短、关键信息会即时写入 Memory 的场景。5.4 方案二摘要压缩核心思路把旧历史先交给模型生成一段摘要然后用摘要替换原始消息。def summarize_messages(messages, token_limit6000): system_msg messages[0] rest messages[1:] total estimate_messages_tokens(messages) if total token_limit: return messages # 留出最近 2 轮完整消息更早的消息用于生成摘要 recent_messages rest[-2:] old_messages rest[:-2] # 调用 LLM 生成摘要 summary generate_summary(old_messages) new_messages [ system_msg, {role: system, content: f以下是更早的对话摘要{summary}}, ] recent_messages return new_messagesgenerate_summary建议用一条专门的 prompt 实现def generate_summary(messages): # 这里只是示例结构真正实现时替换成你的 LLM 调用 text \n.join(m[content] for m in messages) # 伪代码调用 LLM # response llm.chat([{role: user, content: f请压缩信息{text}}]) # return response return f[摘要] {text[:100]}...摘要压缩能最大程度保留关键信息同时显著降低 Token 占用。需要注意摘要本身的准确性如果摘要丢失了订单号后面仍然回答不了问题。5.5 方案三检索增强在前台会话开始前不把全部历史塞进 Prompt而是先从记忆库中检索当前问题最相关的内容def retrieve_relevant_events(user_id, query, store, top_k3): events store.search_events(user_id, limit50) # 这里可以接入向量检索用 query 的 embedding 与事件内容计算相似度 # 简化场景直接返回最近 top_k 条 return events[:top_k]RAG 方案在长期记忆场景几乎是必备的尤其当用户历史事件达到几百上千条时只靠“最近 N 条”不够准确。5.6 方案对比方案优点缺点适用场景截断历史实现简单、速度快可能丢失关键信息对话轮次少关键信息已结构化摘要压缩保留信息密度高增加一次 LLM 调用可能失真单会话长对话检索增强可扩展到海量记忆需要搭建索引复杂度高跨会话长期记忆实际生产系统通常组合使用短期对话做截断或摘要长期信息做检索召回。6. 实战手把手做出电商客服助手下面我们做一个轻量但完整的电商客服助手包含 Session、State、Memory、Context 的超限处理。6.1 项目结构ecommerce-agent/ ├── agent/ │ ├── __init__.py │ ├── session.py │ ├── state.py │ ├── memory_store.py │ ├── context_builder.py │ └── assistant.py ├── main.py └── requirements.txt6.2 环境准备Python 3.10。不需要安装额外第三方库即可演示记忆流程。真正接入大模型时再安装openai或你使用的模型 SDK。requirements.txt内容如下按你实际使用的模型服务调整# openai1.06.3 定义 State# agent/state.py from dataclasses import dataclass, field from typing import Any, Dict, Optional dataclass class AgentState: user_id: str intent: Optional[str] None order_id: Optional[str] None pending_action: Optional[str] None extra: Dict[str, Any] field(default_factorydict) def update(self, **kwargs): for key, value in kwargs.items(): if hasattr(self, key): setattr(self, key, value) else: self.extra[key] valueState 不直接存大段文本而是存结构化的任务进度。比如用户说“查订单”我们就把intentorder_querypending_actionquery_logistics写入 State后续步骤不再需要重新解析全文。6.4 定义 Session 与 MemoryStoreSession 复用第 3 节的类MemoryStore 复用第 4 节的类。这里直接导入使用。6.5 组装 Context# agent/context_builder.py from typing import Dict, List, Any, Optional SYSTEM_PROMPT 你是一名电商平台客服助手。 回答时优先参考用户档案、历史订单信息和最近对话内容。 如果缺少必要信息请明确向用户提问不要编造订单数据。 def estimate_tokens(text: str) - int: return len(text) def estimate_messages_tokens(messages: List[Dict[str, str]]) - int: return sum(estimate_tokens(m.get(content, )) for m in messages) def build_context( session, user_profile: Optional[Dict[str, Any]], memory_events: Optional[List[Dict[str, Any]]], max_history: int 6, ) - List[Dict[str, str]]: messages [{role: system, content: SYSTEM_PROMPT}] if user_profile: profile_text 用户档案 .join( f{k}:{v} for k, v in user_profile.items() ) messages.append({role: system, content: profile_text}) if memory_events: lines [] for event in memory_events: content event.get(content, {}) lines.append(f- {event.get(event_type)}: {content}) memory_text 历史关键信息\n \n.join(lines) messages.append({role: system, content: memory_text}) messages.extend(session.get_history(max_messagesmax_history)) return messages def truncate_to_limit(messages, token_limit6000): if not messages: return messages system_msg messages[0] rest messages[1:] kept [system_msg] total estimate_tokens(system_msg.get(content, )) for msg in reversed(rest): msg_tokens estimate_tokens(msg.get(content, )) if total msg_tokens token_limit: break kept.insert(1, msg) total msg_tokens return kept6.6 编写 Assistant 主流程# agent/assistant.py from .session import Session from .state import AgentState from .memory_store import MemoryStore from .context_builder import build_context, truncate_to_limit class EcommerceAssistant: def __init__(self, store: MemoryStore): self.store store def _detect_intent(self, user_message: str) - str: # 简易规则意图识别生产环境建议换成真实的 NLU 模型 if 订单 in user_message or 发货 in user_message or 物流 in user_message: return order_query if 退 in user_message or 换 in user_message: return after_sale if 地址 in user_message or 收货 in user_message: return address_update return general def handle_message(self, session: Session, user_message: str) - str: # 1. 加载长期记忆 profile self.store.load_profile(session.user_id) or {} state AgentState(user_idsession.user_id) # 2. 追加用户消息 session.add_message(user, user_message) # 3. 意图识别并更新 State intent self._detect_intent(user_message) state.update(intentintent) if intent order_query: # 简单提取订单号正式项目可用正则或 LLM 抽取 if 2024 in user_message: state.update(order_id20240508001, pending_actionquery_logistics) # 4. 召回历史事件 events self.store.search_events(session.user_id, limit5) # 5. 组装 Context 并做超限保护 messages build_context( sessionsession, user_profileprofile, memory_eventsevents, max_history6, ) messages truncate_to_limit(messages, token_limit6000) # 6. 调用模型生成回复 reply self._call_llm(messages) # 7. 追加助手消息 session.add_message(assistant, reply) # 8. 持久化本次事件与可能产生的档案更新 self.store.append_event( session.user_id, event_typeintent, content{order_id: state.order_id, message: user_message}, ) if intent address_update: profile[address] 用户最近提到的新地址需进一步确认 self.store.save_profile(session.user_id, profile) return reply def _call_llm(self, messages) - str: 这里只演示消息如何传给模型。 接入 OpenAI 时 from openai import OpenAI client OpenAI() resp client.chat.completions.create( model你的模型名, messagesmessages, temperature0.3, ) return resp.choices[0].message.content # 本地测试模式返回模拟回复方便验证记忆链路。 last_user_msg for m in messages: if m[role] user: last_user_msg m[content] return f[模拟回复] 已收到{last_user_msg}。我将根据记忆继续处理。6.7 主程序运行验证# main.py from agent.memory_store import MemoryStore from agent.session import Session from agent.assistant import EcommerceAssistant def main(): store MemoryStore(ecommerce_memory.db) assistant EcommerceAssistant(store) # 第一次会话 session1 Session(session_idsession_001, user_iduser_123) print(用户你好我昨天买了一个蓝牙耳机订单号20240508001发货了吗) reply1 assistant.handle_message(session1, 你好我昨天买了一个蓝牙耳机订单号20240508001发货了吗) print(助手 reply1) print(用户麻烦以后都发顺丰。) reply2 assistant.handle_message(session1, 麻烦以后都发顺丰。) print(助手 reply2) # 第二次会话模拟用户隔几天再来 session2 Session(session_idsession_002, user_iduser_123) print(用户我之前那个耳机如果退货怎么处理) reply3 assistant.handle_message(session2, 我之前那个耳机如果退货怎么处理) print(助手 reply3) # 查看记忆结果 profile store.load_profile(user_123) print(\n用户档案, profile) events store.search_events(user_123, limit10) print(事件记忆) for ev in events: print( -, ev[event_type], ev[content]) if __name__ __main__: main()预期输出效果用户你好我昨天买了一个蓝牙耳机订单号20240508001发货了吗 助手[模拟回复] 已收到你好我昨天买了一个蓝牙耳机订单号20240508001发货了吗我将根据记忆继续处理。 用户麻烦以后都发顺丰。 助手[模拟回复] 已收到麻烦以后都发顺丰。我将根据记忆继续处理。 用户我之前那个耳机如果退货怎么处理 助手[模拟回复] 已收到我之前那个耳机如果退货怎么处理我将根据记忆继续处理。 用户档案 {} 事件记忆 - after_sale {order_id: None, message: 我之前那个耳机如果退货怎么处理} - address_update {order_id: None, message: 麻烦以后都发顺丰。} - order_query {order_id: 20240508001, message: 你好我昨天买了一个蓝牙耳机订单号20240508001发货了吗}注意这段演示用的_call_llm是模拟回复。接入真实大模型后第二个 Session 里模型就能通过记忆事件了解用户之前查询过订单20240508001实现真正的跨会话记忆。6.8 代码还可以怎么优化用正则或 LLM 抽取用户意图替换掉简单的关键词识别。把 State 持久化到 Redis支持多实例部署。将build_context中的记忆召回改成向量检索。对每个用户的 Token 消耗做统计防止费用失控。7. 常见问题与排查思路7.1 高频问题表问题现象常见原因解决思路报错context length exceeded历史消息太多超过模型窗口截断、摘要压缩或 RAG 检索召回多轮对话中模型“忘了”之前信息关键信息没有写入 State/Memory用结构化抽取把订单号等写入 State换会话后用户信息丢失长期记忆没有持久化使用数据库保存用户档案和事件流水回复时把其他用户的信息带出来记忆检索没有按用户隔离所有查询必须带user_id过滤条件历史消息太多导致 API 费用高每轮都塞入全部历史限制 max_history并使用摘要压缩同一用户并发请求互相覆盖档案直接整体覆盖 profile 字段做字段级更新或版本控制7.2 排查清单当 Agent 出现记忆相关问题时按下面顺序排查确认模型实际收到的 Context 内容打印messages看 System、历史、记忆是否正常。确认 Session 边界是否正确换会话时是否新建了 Session旧 Session 是否被误用。确认长期记忆是否写入成功查询数据库检查user_profile和event_memory。确认是否超限打印estimate_messages_tokens(messages)对比模型窗口。确认是否有数据安全问题检查检索 SQL 是否漏了user_id条件。在开发环境建议给build_context加一个 debug 模式把最终 messages 输出到日志文件排查效率会高很多。8. 最佳实践与工程建议8.1 记忆分级管理从工程上把记忆分成三层层级内容生命周期存储临时记忆当前任务步骤、临时提取结果单次请求内存 State会话记忆当前会话历史一次会话Redis/内存长期记忆用户偏好、订单、事件用户生命周期数据库/向量库不要让临时信息长期存在数据库也不要让长期记忆塞进每次请求的无限制历史中。什么信息放哪层取决于它的复用价值。8.2 信息结构化优于原文堆叠保存用户记忆时尽量保存结构化字段而不是原始聊天文本。这样后续检索、更新、管理都方便。例如“麻烦以后发顺丰”应转换为{ shipping_preference: SF_EXPRESS, source: 2024-05-08对话, confirmed: false }这样即使模型换了一个版本记忆仍然可复用。8.3 始终做好 Token 预算把 Token 预算当成系统的一项配置来管system prompt 预算。记忆召回预算。历史会话预算。模型输出预算。一旦总预算超过模型窗口就执行截断或摘要策略。建议在请求前计算总 Token并记录到日志中方便成本分析。8.4 数据安全与隐私电商客服涉及用户手机号、地址、订单信息必须做好数据库加密和访问控制。敏感字段脱敏后再写入模型 Context。用户可选择删除记忆对应实现clear_profile、clear_events接口。多租户场景下所有记忆必须按租户隔离。8.5 让记忆“可解释、可干预”不要让记忆成为黑盒在管理后台能看到每个用户保存了哪些记忆。允许人工删除或修正错误记忆。给关键记忆字段增加来源时间和置信度。这样即使 Agent 判断失误也有办法快速止损。9. 总结与后续学习路线本文围绕 Agent 记忆机制从 Context、Memory、Session、State 四个概念出发解释了它们的分工与协作方式并用一个完整的电商客服助手示例演示了如何实现短期会话历史、长期用户记忆、State 状态跟踪以及 Context 超限处理。现在你应该已经掌握为什么 LLM 本身无状态Agent 的记忆需要开发者主动管理。Session、State、Memory、Context 四者的边界和关系。如何用 SQLite 保存用户档案和事件记忆。如何在请求前组装 Context并通过截断、摘要、检索控制长度。一个可扩展的电商客服助手代码骨架。下一步可以继续深入学习LangGraph 或同类 Agent 框架它会原生提供 State 管理和节点流转能力能少写很多胶水代码。向量检索与 RAG在记忆量变大时用向量召回替代“最近 N 条”策略。记忆评估体系定义“是否记住用户偏好”“是否找回历史订单”等指标定期评估记忆链路质量。多 Agent 场景记忆隔离多个 Agent 共享记忆时的权限与隔离方案。记忆系统是 Agent 从“玩具”走向“生产力”的关键一环。不要急着堆功能先把数据分层、流程边界和 Token 成本控制做好再逐步扩展接入真实模型。动手把上面的代码跑起来改成你自己的业务场景你会对 Agent 的记忆机制理解得更扎实。