AI Agent 的记忆系统：从必要性到工程实践

引言

在与 AI Agent 的长时间交互中，你是否遇到过这样的困扰：明明上次已经告诉它你的偏好，但这次它又重新询问？或者在处理复杂任务时，AI 突然"失忆"，忘记了之前讨论的关键决策？

这些问题的根源在于：AI Agent 缺乏持久化的记忆能力。而记忆系统的引入，正是为了让 AI 从"健忘的助手"进化为"懂你的伙伴"。

一、为什么要引入记忆？

1.1 上下文的天然局限

大语言模型（LLM）虽然强大，但它们面临一个根本性约束：上下文窗口是有限的。即使最新的模型支持 100 万甚至 200 万 token 的上下文，在实际应用中仍然存在三个关键问题：

成本问题：每次对话都携带完整历史记录，计算成本呈线性增长
效率问题：上下文越长，推理速度越慢，用户体验下降
噪音问题：大量无关信息会干扰模型的判断，降低输出质量

1.2 用户体验的刚需

从用户角度看，记忆系统解决了几个核心痛点：

个性化体验：记住用户的偏好、习惯和特殊要求
连续性任务：在多轮对话或跨会话中保持任务的连贯性
效率提升：避免重复性的信息输入和说明
信任建立：AI 能记住你说过的话，增强人机信任感

1.3 复杂任务的必然要求

在代码开发、项目管理等复杂场景中，记忆系统更是不可或缺：

记住项目的架构决策和设计模式
跟踪已修复的 bug 和错误模式
保存用户的编码规范和风格偏好
维护任务的依赖关系和优先级

二、记忆是如何实现的？

2.1 记忆系统的基本架构

在 Agent 记忆系统（Agent Memory System） 的设计中，核心目标是：

让 Agent 在长期交互与任务执行中，既能"记住重要的事"，又不会被无关信息拖慢或污染推理。

从工程和认知两个维度来看，Agent 的记忆通常可以分为以下几大类型，并且在成熟系统中往往是组合使用的。

维度一：按「时间尺度」划分（最常见、最核心）

记忆类型	作用	典型内容	实现方式	特点	重要性
短期记忆 (Short-Term Memory / Working Memory)	支撑当前一步或几步的推理类似人类的"工作记忆"	• 最近 N 轮对话 • 当前任务上下文 • 中间推理结果（scratchpad / chain-of-thought 的压缩版）	• Prompt 中直接拼接 • Sliding Window • Recent Messages Buffer	• 生命周期短 • 每次请求都会加载 • 成本高（占 token）	几乎所有 Agent 都有
中期记忆 (Episodic Memory / Session Memory)	记住"发生过的事件" 跨多轮任务仍然可用，但不是永久	• 完成过哪些任务 • 用户最近的偏好变化 • 上一次失败 / 成功的策略	• 结构化日志（JSON / DB） • 向量化存储 + 相似度检索 • 会话级缓存（Session Store）	• 可检索 • 不每次都加载 • 触发式注入上下文	决定 Agent 是否"有连续感"
长期记忆 (Long-Term Memory / Persistent Memory)	形成"长期认知" 影响未来决策和行为风格	• 用户稳定偏好 • 固定事实（User Profile） • Agent 自身能力边界、经验总结	• Key-Value Memory • 文本 + Embedding • 显式 Memory Store（如 Claude / Cursor Memory）	• 持久化 • 写入受控 • 读取高度选择性	最难设计，也最容易"记坏"

维度二：按「内容性质」划分（比时间更重要）

记忆类型	存储内容	典型例子	实现方式	特点	评价
事实性记忆 (Semantic / Factual Memory)	不随时间变化的事实 "是什么"	• 用户使用 Java / Python • 项目技术栈 • 业务规则	结构化存储	• 低频写，高频读 • 适合结构化存储	最安全、性价比最高的记忆类型
经验记忆 (Procedural / Skill Memory)	"怎么做" 成功或失败的策略	• 解决某类 Bug 的步骤 • 某种 Prompt 模板效果很好 • 排班问题用 CP-SAT 比 MILP 更稳	• Rule / Template • Skill 文件 • Tool 调用策略	• 可复用 • 高价值	Claude Skills 就是典型代表
情景记忆 (Episodic Memory)	一次完整事件含上下文、过程、结果	• "在 2024-12 的一次排班优化中，因为约束冲突导致模型不可行"	向量化存储	• 高维、非结构化 • 用于"类比推理"	用于经验学习和问题诊断
偏好与风格记忆 (Preference / Personality Memory)	用户偏好表达风格输出习惯	• 喜欢表格而不是长文 • 代码优先于解释 • 中文 + 专业术语	Key-Value 或配置文件	• 影响交互体验 • 需要动态更新	决定 Agent 的"个性化"程度

维度三：按「使用方式」划分（工程视角）

记忆类型	定义	特征	示例	优势	风险
显式记忆 (Explicit Memory)	明确写入明确读取有规则、有生命周期	• 结构化 • 可追溯 • 用户可见	`{"type": "user_preference", "key": "response_style", "value": "engineering-oriented"}`	✔ 可控 ✔ 可调试 ✔ 可删除	需要显式管理接口
隐式记忆 (Implicit Memory)	融入模型权重或 Prompt 模板用户不可见难以删除	• 不可见 • 难以修改 • 系统级	• System Prompt 中的行为约束 • 微调模型的偏置	不需要额外存储和检索	⚠️ 风险高 ⚠️ 不适合个性化长期记忆

一个成熟 Agent 的"记忆组合架构"

┌───────────┐
│ System    │  ← 角色、规则（几乎不变）
└────┬──────┘
     │
┌────▼──────┐
│ Short-Term│  ← 最近对话 / 当前任务
└────┬──────┘
     │
┌────▼─────────────┐
│ Memory Retriever │  ← 向量 / 规则
└────┬─────────────┘
     │
┌────▼──────┐
│ Long-Term │  ← 事实 / 偏好 / 经验
└───────────┘

关键设计原则（非常重要）

1️⃣ 不是记得越多越好

2️⃣ 写记忆要比读记忆更谨慎

3️⃣ 事实、偏好、经验必须分层存储

4️⃣ 记忆必须可解释、可回滚、可过期

5️⃣ Agent 失败，80% 是记忆污染

一句话总结

Agent 的记忆不是"聊天记录"，而是"可被检索、可被治理的认知资产"。

三、引入记忆会带来什么问题？

3.1 上下文容量的权衡

虽然记忆系统旨在缓解上下文限制，但它本身也会占用上下文空间：

记忆注入开销：每次对话需要注入相关记忆，占用 token
边际效益递减：注入的记忆越多，噪音也越大
检索精度困境：检索不准确会引入无关记忆，反而降低性能

3.2 记忆的一致性和准确性

记忆冲突：不同时间的记忆可能互相矛盾
记忆失真：模型可能错误理解或记录信息
记忆过时：用户偏好改变，旧记忆成为干扰

3.3 隐私和安全问题

敏感信息泄露：记忆可能包含用户不希望保留的敏感信息
记忆污染攻击：恶意用户可能故意植入误导性记忆
跨会话泄漏：不当的记忆管理可能导致信息跨用户泄漏

3.4 系统复杂度的增加

存储成本：大规模记忆需要持久化存储和索引
维护成本：记忆的更新、删除、去重需要额外逻辑
调试困难：记忆系统引入新的不确定性，问题排查更复杂

四、Cursor 记忆工具的设计启示

当我们为 Agent 引入记忆系统之后，一个随之而来的核心问题便是：如何更加合理地使用与维护这些记忆？创建记忆本身并不困难，真正具有挑战性的，是记忆的更新与删除机制。

一般而言，我们最直观的做法是通过规则来解决这些问题。例如，设定时间窗口或最近对话轮数来筛选可用记忆；在生成新的对话内容后写入记忆，并定期清理过时、低价值的旧记忆。我在实际开发 Agent 时，也基本沿用了这一套思路。这种方式当然谈不上错误，但也很难称得上有什么新意。

直到我看到 Cursor 在系统提示词中对记忆维护的设计方式——它将“是否保留、如何更新记忆”的决策权，再次交还给了大模型本身。第一次看到这种设计时，我产生了一种很微妙的感受：一方面觉得“事情本就应该如此”，另一方面又不得不佩服 Cursor 工程师在设计上的大胆与想象力。

以下是Cursor系统提示词中对于 memory 部分的描述：

...
<memories>
你可能会得到一份记忆清单。这些记忆是从过去与agent的对话中产生的。它们可能是正确的，也可能是不正确的，所以如果认为相关，请遵循它们，但是当你注意到用户根据记忆更正了你所做的事情，或者遇到一些与现有记忆相矛盾或增加的信息时，你必须立即使用update_memory工具更新/删除记忆。绝对不能使用update_memory工具创建 与 实现计划、代理完成的迁移或其他特定于任务的信息 相关的记忆。
如果用户曾经反驳过你的记忆，那么最好删除那个记忆，而不是更新它。
你可以根据工具描述中的标准 创建、更新或删除 记忆
<memory_citation>
在生成内容、回复用户查询或执行命令时，你必须始终通过引用的方式使用记忆，引用格式为：[[memory:MEMORY_ID]]。你应将记忆引用自然地融入回复内容中，而非仅作为注释。

例如：“我会使用 -la 标志 [[memory:MEMORY_ID]] 运行该命令，以显示详细的文件信息。”

当你因某条记忆而拒绝用户的明确请求时，必须在对话中提及，如果该记忆有误，用户会纠正你，而你会更新自己的记忆。
</memory_citation>
</memories>
...

# Tools
## functions

namespace functions {
...

// 在供AI使用时参考的知识库中创建、更新或删除一条记忆。
// 如果用户对现有记忆进行了补充完善，你必须使用此工具并将 action 设置为“update（更新）”。
// 如果用户(的对话)与现有记忆相矛盾，重点是要将此工具与“删除”操作一起使用，而不是“更新”或“创建”。.
// 要更新或删除已有记忆，必须提供existing_knowledge_id参数。
// 如果用户要求记住一些东西，保存一些东西，或者创建一个记忆，你必须使用这个工具的动作“创建”。
// 除非用户明确要求记住或保存某些内容，否则不要使用“创建”操作调用此工具。
// 如果用户(的对话)与你的记忆相矛盾，那么最好删除这段记忆，而不是更新这段记忆。
type update_memory = (_: {
// 记忆的标题。这可以用来查找和检索以后的记忆。这应该是一个简短的标题，抓住记忆的本质。对于“创建”和“更新”操作这个参数是必需的。
title?: string,
// 要存储的具体记忆内容。其长度不应超过一个段落。如果该记忆是对先前记忆的更新或与之相矛盾，则不要提及或引用先前的记忆。在执行“create（创建）”和“update（更新）”操作时，此项为必填内容。
knowledge_to_store?: string,
// 对知识库执行的操作。若未提供此项，为保证向后兼容性，默认操作设为“create（创建）”。
action?: "create" | "update" | "delete",
// 若操作是“update（更新）”或“delete（删除）”，则此项为必填项。是要更新（而非创建新记忆）的现有记忆的ID。
existing_knowledge_id?: string,
}) => any;

...
}

通过分析 Cursor 的记忆工具实现，我们可以提炼出几个关键的设计智慧：

4.1 记忆的"不确定性"哲学

Cursor 开篇即声明："这些记忆可能是正确的，也可能是不正确的"。

这个设计体现了深刻的认知：

承认 AI 理解的局限性，避免过度自信
鼓励用户反馈，建立动态修正机制
记忆应该是辅助判断的参考，而非绝对真理

工程启示：记忆系统应该是"柔性"的，而非"刚性"的规则引擎。

4.2 引用式使用（Citation）

Cursor 要求 AI 在使用记忆时必须明确引用：[[memory:MEMORY_ID]]

这个设计的价值：

可追溯性：用户知道 AI 的决策基于哪条记忆
可纠错性：用户发现问题时可以精确定位需要修正的记忆
透明度：增强人机交互的透明度和信任

类比：就像学术论文的引用机制，让知识的来源清晰可查。

4.3 避免"任务型"记忆

Cursor 明确禁止创建"与实现计划、迁移等特定任务相关的记忆"。

为什么？

❌ 错误示例：
记忆："用户正在将数据库从 MySQL 迁移到 PostgreSQL"
（这是任务状态，会过时）

✅ 正确示例：
记忆："用户偏好使用 PostgreSQL 作为主数据库"
（这是长期偏好，不易过时）

任务型信息应该由待办事项（TODO）系统管理，记忆系统专注于持久性的知识和偏好。

工程启示：明确区分"记忆"与"状态"，避免系统功能混淆。

4.4 冲突处理的"删除优先"原则

Cursor 特别强调："如果用户曾经反驳过你的记忆，那么最好删除那个记忆，而不是更新它。"

这是一个反直觉但极其明智的设计：

更新的问题：

原记忆："用户喜欢使用 Vue 框架"
用户反驳："我现在更喜欢 React"
如果更新为："用户喜欢使用 Vue 框架，但现在更喜欢 React"
→ 产生模糊性，AI 可能困惑

删除的优势：

避免记忆内部矛盾
让 AI 基于当前上下文重新判断
用户可以选择创建新的明确记忆

哲学思考：有时候"遗忘"比"记住"更重要。

4.4 工具化的记忆管理

在《ClaudeCode为什么这么强大？通过解析其系统提示词一探究竟》一文中，我们指出应该按照结构化语言组织提示词，Cursor系统提示词告诉我们：这种“结构化”的形式除了文档还可以使用伪代码。

Cursor 将记忆操作封装为标准化的工具接口：

type update_memory = {
    title?: string,                    // 记忆标题
    knowledge_to_store?: string,       // 记忆内容
    action?: "create" | "update" | "delete",  // 操作类型
    existing_knowledge_id?: string,    // 已有记忆 ID
}

设计优势：

可控性：明确的操作语义，避免隐式记忆生成
可审计：所有记忆变更都通过工具调用，可以记录和审计

五、Claude Code 的记忆压缩策略：精准摘要的艺术

在上一节中，我们分享了 Cursor 在记忆维护机制上所带来的不同视角。本节将转向另一个重量级工具 —— Claude Code。相比之下，Claude Code 面对的是更极端的场景：当上下文窗口用尽时，如何将过去的对话压缩为精准的摘要，既节省 token 又不影响任务的连续性？

5.1 结构化分析框架

Claude Code 的压缩 prompt 首先要求进行结构化的分析：

你的任务是对到目前为止的对话进行详细总结，要密切关注用户的明确请求以及你之前采取的行动。
该总结应全面涵盖技术细节、代码模式和架构决策，这些内容对于在不丢失上下文的情况下继续开展开发工作至关重要。

在提供最终总结之前，将你的分析包裹在 <analysis> 标签中，以组织你的思路并确保你已涵盖所有必要的要点。在你的分析过程中：

1. 按时间顺序分析对话的每条消息和每个部分。对于每个部分，请仔细识别：
    - 用户的明确请求和意图
    - 你处理用户请求的方法
    - 关键决策、技术概念和代码模式
    - 具体细节，例如：
        - 文件名
        - 完整的代码片段
        - 函数签名
        - 文件编辑
    - 你遇到的错误以及你如何修复它们
    - 特别关注你收到的具体用户反馈，尤其是用户要求你以不同方式做某事的情况。
2. 仔细检查技术准确性和完整性，彻底处理每个必需的元素。

你的总结应该包括以下几个部分：

1. 主要请求和意图：详细捕获所有用户明确的请求和意图
2. 关键技术概念：列出讨论的所有重要技术概念、技术和框架。
3. 文件和代码部分：列举检查、修改或创建的具体文件和代码部分。特别关注最近的消息，如果合适的话，应当包含完整的代码片段，同时总结为什么这个文件读取或编辑很重要。
4. 错误和修复：列出你遇到的所有错误，以及你如何修复它们。特别关注你收到的具体用户反馈，尤其是用户要求你以不同方式做某事的情况。
5. 解决问题: 记录已解决的问题和正在进行的故障排除工作。
6. 用户的所有消息：列出所有非工具结果的用户消息。这些对于理解用户的反馈和变化的意图至关重要。
7. 待处理任务：概述你被明确要求处理的任何待处理任务。
8. 当前工作：详细描述在此总结请求之前正在处理的确切内容，特别关注用户和assistant的最新消息。在合适的情况下包含文件名和代码片段。
9. 可选的下一步：列出与你最近正在进行的工作相关的下一步操作。重要提示：确保这一步与用户的明确请求以及你在此总结请求之前正在处理的任务直接一致。如果你的上一个任务已经完成，那么只有在明确符合用户请求的情况下才列出下一步。在未与用户确认之前，不要开始处理无关的请求。
   如果有下一步操作，请包含最近对话中的直接引用，准确显示你正在处理什么任务以及你停在哪里。这应该是逐字引用，以确保任务解释不会偏离。

你的输出应该是结构化的，以下是一个结构化输出的示例：

<example>
<analysis>
[你的思考过程，确保所有要点都被全面准确地涵盖]
</analysis>

<summary>
1. 主要请求和意图:
   [详细描述]
2. 关键技术概念:
    - [概念 1]
    - [概念 2]
    - [...]
3. 文件和代码部分:
    - [文件名 1]
        - [总结为什么这个文件很重要]
        - [对该文件所做更改的总结（如果有）]
        - [重要代码段]
    - [文件名 2]
        - [重要代码段]
    - [...]
4. 错误和修复:
    - [错误1的详细描述]:
        - [如何修复这个错误]
        - [用户对错误的反馈（如果有）]
    - [...]
5. 解决问题:
   [描述已解决的问题和正在进行的故障排除]
6. 用户的所有消息:
    - [详细的用户消息]
    - [...]
7. 待处理任务:
    - [Task 1]
    - [Task 2]
    - [...]
8. 当前工作:
   [当前工作的精确描述]
9. 可选的下一步:
   [可选的下一步要采取的步骤]

</summary>
</example>

请根据到目前为止的对话提供你的总结，遵循这个结构，并确保你的回答准确和彻底。

在所包含的上下文中可能会提供额外的指示。如果是这样，请记住在创建上述总结时遵循以下说明。说明的例子包括：
<example>
## Compact Instructions
在总结对话时，重点关注 TypeScript 代码更改，同时记住你犯的错误以及你如何修复它们。
</example>

<example>
## Summary instructions
当你使用compact进行总结时 - 请专注于测试输出和代码更改。包括文件逐字读取。
</example>

5.2 九维度摘要模型

Claude Code 将对话压缩为 9 个维度（重点是前8个维度，通常称为8段式压缩）：

维度	目的	示例
1. 主要请求和意图	捕获用户的核心诉求	"用户要求实现用户认证系统"
2. 关键技术概念	保留技术决策上下文	"JWT、OAuth2.0、bcrypt 密码加密"
3. 文件和代码部分	精确定位修改位置	"`auth.py`: 实现了 `hash_password()` 函数"
4. 错误和修复	避免重复犯错	"ImportError: 缺少 pyjwt 依赖，已添加到 requirements.txt"
5. 解决问题	跟踪问题状态	"已解决：登录超时问题；进行中：邮件验证功能"
6. 用户的所有消息	保留用户的原始意图	"用户说：'密码必须支持特殊字符'"
7. 待处理任务	确保任务连续性	"待实现：邮件验证、密码重置功能"
8. 当前工作	精确恢复工作现场	"正在修改 `user_model.py` 的第 45-60 行，添加邮箱验证逻辑"
9. 可选的下一步	提供上下文感知的建议	"下一步：测试邮箱验证流程，然后实现密码重置"

5.3 保留用户原始消息的重要性

特别值得注意的是第 6 点：用户的所有消息。

为什么要单独保留用户的原始消息？

意图的准确性：AI 的理解可能有偏差，用户原话是最可靠的参考
细节的完整性：用户可能提到了 AI 认为不重要但实际关键的细节
纠错的可能性：当发现理解偏差时，可以回溯到原始需求

案例对比：

❌ 只保留 AI 的理解：
"用户要求优化数据库查询性能"

✅ 同时保留用户原话：
"用户说：'首页加载太慢了，能不能优化一下？我看日志里有很多数据库查询。'"

→ 原始消息提供了更丰富的上下文：
   - 问题表现：首页加载慢
   - 问题线索：日志中的查询
   - 用户语气：非技术用户

5.4 当前工作的精确描述

第 8 点：当前工作的设计体现了对"工作现场"的重视。

Claude Code 要求：

详细描述在总结请求之前正在处理的确切内容
在合适的情况下包含文件名和代码片段
特别关注用户和 assistant 的最新消息

实际效果：

当前工作：
正在修改 `solve/employee_timegrid_solve.py` 文件。
已经添加了 `EmployeeTimegridSolver` 类（第 50-120 行），
实现了以下方法：
  - `__init__()`: 初始化求解器
  - `create_model()`: 创建 CP-SAT 模型
  - `add_constraints()`: 添加约束条件

最后一步是在第 115 行添加目标函数优化逻辑，
用户特别强调要优化员工的工作时间均衡性。

代码片段：
```python
def add_objective(self) -> None:
    # 正在实现中...
    pass

这种精确描述确保了在新的上下文窗口中，AI 能够无缝地继续工作，不会出现"我们刚才做到哪了？"的困惑。

5.5 技术细节的取舍原则

Claude Code 强调"彻底处理每个必需的元素"，但什么是"必需"的？

保留的细节：

完整的文件路径：solve/employee_timegrid_solve.py
具体的函数签名：def create_model(self, employees: List[Employee]) -> CpModel
关键的代码片段：实现的核心逻辑
精确的错误信息：ImportError: No module named 'ortools'

可以省略的细节：

重复性的调试输出
中间状态的临时代码
已经完全解决且不会再出现的问题

取舍原则：如果这个细节的缺失会导致后续无法继续工作，就必须保留；如果只是过程性信息，可以概括或省略。

5.6 错误驱动的学习机制

第 4 点：错误和修复是一个被低估但极其重要的设计。

AI Agent 在工作中会犯错，关键是如何从错误中学习：

错误和修复：
1. ImportError: No module named 'ortools'
   - 原因：requirements.txt 中缺少依赖
   - 修复：添加 `ortools>=9.6.0`
   - 用户反馈：建议锁定版本避免兼容性问题

2. 求解器返回 INFEASIBLE
   - 原因：员工可用时间约束与需求时间窗口冲突
   - 修复：放宽了部分软约束，改为惩罚项
   - 用户反馈：满意，但要求输出冲突原因

3. 性能问题：求解器运行超过 5 分钟
   - 原因：变量数量过多（10000+）
   - 修复：引入分层求解，先优化关键班次
   - 用户反馈：运行时间降到 30 秒，符合预期

这种错误记录的价值：

避免重复犯错：同类问题有了解决模式
用户反馈的宝贵性：用户的修正意见是最重要的记忆
问题诊断的速度：遇到类似问题时有历史参考

5.7 下一步行动的上下文一致性

第 9 点：可选的下一步有一个重要的约束：

"重要提示：确保这一步与用户的明确请求以及你在此总结请求之前正在处理的任务直接一致。如果你的上一个任务已经完成，那么只有在明确符合用户请求的情况下才列出下一步。在未与用户确认之前，不要开始处理无关的请求。"

这个约束防止了 AI 的"功能蔓延"：

❌ 错误示例：
当前任务：实现用户登录功能（已完成）
下一步：实现用户注册、密码重置、邮箱验证、第三方登录...

（AI 自作主张扩展了任务范围）

✅ 正确示例：
当前任务：实现用户登录功能（已完成）
下一步：根据用户的原始要求"实现基本的用户认证"，登录功能已满足需求。等待用户确认或提出新的要求。

（保持对用户意图的忠实）

5.8 引用的真实性原则

Claude Code 强调：

"如果有下一步操作，请包含最近对话中的直接引用，准确显示你正在处理什么任务以及你停在哪里。这应该是逐字引用，以确保任务解释不会偏离。"

逐字引用的价值：

❌ AI 的释义：
"用户要求优化算法性能"

✅ 用户的原话：
"能不能让这个排班算法快一点？现在 100 个员工需要跑 10 分钟，太慢了。"

→ 原话包含的额外信息：
   - 具体场景：100 个员工
   - 性能基准：10 分钟
   - 用户期望：需要更快

逐字引用避免了 AI 在多次转述中逐渐偏离用户的原始意图。

六最终思考

AI Agent 的记忆系统，本质上是在解决连续性和个性化的问题。它让 AI 从一个无状态的函数调用，进化为一个有"经历"、有"学习能力"的智能体。

但我们必须认识到，记忆系统不是银弹：

它不能替代清晰的用户表达和良好的上下文设计
它会引入新的复杂度和潜在错误
它需要持续的维护和优化

真正优秀的记忆系统，应该像一个优秀的助手：

记住该记的：关键决策、用户偏好、错误教训
忘记该忘的：过时信息、临时状态、错误记忆
知道何时求助：不确定时主动向用户确认

从 Cursor 的"引用式记忆"到 Claude Code 的"结构化压缩"，我们看到了不同场景下的设计智慧。但更重要的是背后的设计哲学：

以用户为中心，以反馈为驱动，以透明为原则，以价值为导向。

在 AI Agent 日益成为我们工作伙伴的今天，记忆系统的优劣，将直接决定人机协作的效率和体验。希望本文的分析能为你设计或使用 AI Agent 提供有价值的参考。

posted @ 2026-01-10 12:07 DeepSky丶阅读(58) 评论(0) 收藏举报

刷新页面返回顶部