状态与记忆管理
有效的记忆管理决定了智能体究竟像一个持久、智能的系统，还是一个无状态的聊天机器人。核心挑战在于：哪些内容留在成本高昂的上下文窗口中，哪些内容卸载到外部存储。
概述
智能体记忆分为三个功能层级：
| 层级 | 用途 | 存储方式 | 类比 |
|---|---|---|---|
| 短期记忆（工作记忆） | 当前任务上下文与对话流程 | 内存 / checkpointer | RAM |
| 情景记忆 | 可检索的历史事件与结果日志 | 向量数据库 / 结构化日志 | 日记 |
| 长期记忆（语义记忆） | 持久化的事实、偏好与已学规则 | 知识图谱 / SQL | 硬盘 |
最佳实践
| 核心挑战 | 描述 | 经验教训与已考虑的替代方案 | 采用的解决方案 |
|---|---|---|---|
| 上下文窗口溢出 | 长会话超出模型 Token 限制，导致截断或报错 | 曾尝试扩大上下文窗口，但成本呈二次方增长 | 实现滑动窗口或递归摘要，压缩历史记录 |
| 跨会话状态丢失 | 智能体在不同会话间忘记用户偏好和历史决策 | 曾存储完整对话历史，但检索变得缓慢且噪声增多 | 提取并持久化关键事实（实体抽取）至结构化存储，按需检索 |
| 记忆更新冲突 | 多个智能体并发写入共享记忆，导致数据不一致 | 曾使用单一共享向量数据库，并发写入造成脏读 | 实现乐观锁，或采用基于时序知识图谱（Zep/Graphiti）的事件溯源记忆 |
| 记忆检索相关性 | 拉取过多无关上下文，导致响应质量下降 | 曾仅用嵌入相似度检索 top-K，拉入了不相关事实 | 将语义搜索与元数据过滤（时效性、实体类型、会话 ID）结合使用 |
| 记忆隐私与隔离 | 用户 A 的记忆泄漏到用户 B 的上下文 | 曾跨用户共享嵌入空间，导致命名空间冲突 | 在所有记忆存储中强制执行严格的租户/用户命名空间隔离，并审计访问模式 |
| 隐式记忆与显式记忆 | 智能体遗漏用户未明确陈述的重要事实 | 曾依赖用户主动说"记住这个"，但大多数用户不会这样做 | 运行后台抽取 LLM 监控对话，自动保存关键事实 |
| 记忆过期 | 随着用户情境变化，存储的事实逐渐过时 | 曾无限期保留所有事实，导致智能体基于陈旧偏好行动 | 为易变事实附加 TTL；使用时序图追踪事实随时间的演变。对于托管平台，可使用定时 dreaming（Anthropic）在会话间自动清除矛盾事实 |
| 重工具任务的工作记忆 | 复杂的多步工具链丢失中间状态 | 曾将所有状态通过上下文窗口传递，触及 Token 上限 | 使用暂存区 / AgentFS 存储中间工具输出，在上下文中通过指针引用 |
| 无需重新训练的自我改进 | 智能体在不进行模型微调的情况下，跨会话重复犯同样的错误 | 曾在系统提示词中手动更新规则，工程师疲于应对 | 使用定时记忆整合（dreaming）从情景日志中提取重复模式，自动晋升为程序性记忆 |
| 智能体输出质量的自评估 | 不经人工审查难以判断智能体是否成功完成任务 | 曾抽样检查，遗漏了部分回归问题 | 添加独立的评分智能体（Outcomes 模式），在单独的上下文窗口中依据纯文本评分标准对输出打分，循环直至评分通过或达到最大迭代次数 |
| 定时/自动化循环在运行间失去连续性 | 周期性自动化任务（cron、/loop、/goal）对上一次运行的尝试或已解决事项毫无记忆 |
每天早晨从头重新执行同一个分类提示词，重复工作并重新浮现已解决的问题 | 将循环状态外部化到 Markdown 文件或任务看板（如通过 MCP 接入 Linear），记录已完成和待处理的事项——智能体在运行间会遗忘，但代码库/任务追踪器不会；参见循环工程 |
记忆解决方案参考
| 方案 | 提供商 | 核心技术 | 核心优势 |
|---|---|---|---|
| Mem0 | 独立 | 向量 + 图 | 自动跨会话提取并精炼用户事实 |
| Zep | 独立 | 时序知识图谱 | 追踪事实随时间的演变 |
| AgentFS | Turso | SQLite 支持的虚拟文件系统 | 以单一可移植 .db 文件实现类文件系统的持久化 |
| Letta (MemGPT) | 独立 | 虚拟上下文 | 自主管理 RAM/磁盘，实现上下文自主换页 |
| LangMem | LangChain | 托管 SaaS | 与 LangGraph 节点深度集成 |
| Claude Managed Agents Memory + Dreaming | Anthropic | 文件系统 + 定时整合 | 原生自我改进记忆，支持 dreaming（会话间整合）与 outcomes（自评分）；Harvey 报告任务完成率提升 6 倍 |
| Bedrock Memory | AWS | 托管 AWS | 面向 Bedrock 智能体的企业级扩展与合规支持 |
长期记忆（LTM）策略选择
| 策略 | 最适合场景 | 存储方式 |
|---|---|---|
| Vector RAG | 对大型知识库进行模糊/语义搜索 | Pinecone、Chroma、pgvector |
| 知识图谱 | 关系推理、多跳问题 | Neo4j、FalkorDB |
| 实体抽取 | 个性化、固定属性（过敏信息、偏好设置） | Postgres、Redis |
| 增量摘要 | 无需存储每条消息的长期叙事 | Markdown / 文本文件 |
| 反思 / 整合 | 自我纠错、从历史失败中学习 | AgentFS / 专用数据库 |
无状态智能体设计与水平扩展
LLM 本身是无状态的，因此将记忆持久化到外部存储对生产环境智能体而言不可妥协。其回报在于：任意智能体实例均可处理任意请求，从而实现无服务器水平扩展。
Google Cloud 模式：将智能体逻辑设计为携带外部状态的无状态容器化服务，可部署于 Cloud Run（自动扩缩）或 Vertex AI Agent Engine。
关键架构选择： - Vertex AI Agent Engine：提供内置的持久化会话与记忆服务。托管便利，但灵活性较低。 - Cloud Run + 外部数据库：灵活性更高，可直接集成 AlloyDB 或 Cloud SQL，但需自行管理持久化层。
处理长时任务：对于复杂任务，采用异步/事件驱动模式。服务将任务发布到 Pub/Sub，触发 Cloud Run 工作节点异步处理。智能体在后台任务运行期间保持响应。
有状态工具的可靠性：当工具调用失败（网络问题、瞬时错误）时，智能体必须安全地重试。这要求： - 幂等工具：工具设计上需保证以相同输入调用两次不会产生重复副作用（如重复扣款、重复发送消息）。对于涉及金融交易或外部写入的工具至关重要。 - 指数退避：以递增的延迟自动重试，给下游服务留出恢复时间。
多智能体共享状态（AWS 模式）
在多智能体系统中，智能体通过共享状态而非直接耦合来协同工作。AWS 推荐三层共享状态架构：
| 层级 | 存储 | 特性 | 适用场景 |
|---|---|---|---|
| 任务状态 | Amazon DynamoDB | 个位数毫秒级读取、智能体故障后仍可存续、完整审计链 | 持久化工作流执行状态——每一步均有记录 |
| 会话上下文 | Amazon ElastiCache | 亚毫秒访问、TTL 管理 | 对话轮次 + 最近访问的有效载荷 |
| 领域知识 | Amazon Bedrock Knowledge Bases | 向量检索、治理管控、跨所有智能体共享 | 避免智能体实例间的知识重复 |
| 中间结果 | Amazon S3 | 成本效益高、持久 | 在 DynamoDB 任务状态中通过指针引用，绝不在有效载荷中直接传递 |
交接有效载荷原则：只包含下一个智能体所需的内容。冗长的有效载荷会膨胀上下文窗口，降低推理质量。将大型中间产物存入 S3，传递引用而非内容本身。
记忆治理：血缘、留存、PII 与删除权
记忆存储会不断累积受监管义务约束的敏感数据。治理必须在设计阶段内建，而不能事后补救。
数据血缘
每次记忆写入都应生成一条审计记录，包含：session_id、agent_id、user_id、timestamp、source_ip。所有记忆记录都应附带 {tenant_id, data_classification, retention_class} 标签。
| 存储 | 血缘机制 |
|---|---|
| 所有记忆写入 | AWS CloudTrail API 记录 |
| 工作流状态变更 | Amazon DynamoDB Streams（审计回放） |
| S3 知识库记录 | Amazon S3 对象元数据（文档来源） |
分层留存策略
| 层级 | 存储 | 建议 TTL | 说明 |
|---|---|---|---|
| 会话 | Redis / ElastiCache | 默认 24 小时 | 超过 24 小时的会话通常已过时；激进 TTL 可释放 DRAM |
| 工作流 | DynamoDB | 90 天 | Step Functions 执行日志保留 90 天 |
| 长期 | MongoDB Atlas | 每租户可通过 expireAfterSeconds 配置 |
字段：timestamp |
| 知识库源文档 | Amazon S3 | 1 年后转入 Glacier，7 年后删除 | S3 Lifecycle 规则 |
PII 检测与处理
在任何数据写入长期存储前，应在巩固 Lambda 中应用 Amazon Bedrock Guardrails PII 过滤器。可配置为“检测并掩码”或“检测并阻止”模式。覆盖的 PII 类型包括姓名、SSN、电子邮件、信用卡号和 IP 地址。对 MongoDB Atlas 中含 PII 的字段使用由 KMS 管理密钥的字段级加密。知识库同步作业摄取文档前，使用 Amazon Macie 扫描 S3 源存储桶。
删除权（GDPR/CCPA）
在每层记忆存储上为 user_id 建立索引，可实现定向清除，避免全表扫描：
| 存储 | 删除方式 |
|---|---|
| MongoDB Atlas | 通过 user_id 索引执行 deleteMany({user_id: X}) |
| DynamoDB | 在 user_id 上建立 GSI——无需全表扫描即可清除工作流日志 |
| Redis Cloud | SCAN pattern 'session:*:{user_id}:*' + DEL——由删除请求触发异步 Lambda 任务 |
| Amazon Bedrock Knowledge Bases | 删除 S3 对象，再通过同步作业重新索引，以排除已删除文档 |
多智能体状态一致性的事件溯源方案（Confluent 模式）
这是共享可变状态存储的替代方案：通过不可变日志与事件溯源维护多个智能体间的状态一致性，如 Confluent 在 A Guide to Event-Driven Design for Agents and Multi-Agent Systems（2025）中所述。该模型将每次智能体交互视为在持久化事件日志（而非数据库记录）上的"输入 → 处理 → 输出"：
- 每个事件均以不可变的追加条目记录——零数据丢失，且保留状态演变的完整审计链。
- 基于回放的恢复：智能体故障后，通过从最后保存的偏移量回放事件来恢复状态，而非从快照重建。
- 并行消费互不干扰：多个智能体可独立消费同一事件流，各自追踪自身偏移量，在无锁争用的情况下实现水平扩展。
这与上文 AWS 三层共享状态模型形成互补：任务状态和中间结果可由事件日志派生（或以事件日志为底层支撑），替代或补充 DynamoDB 等行存储——尤其适用于主要访问模式为"按时序查询发生了什么"而非"查询当前值"的场景。