- 面试问题：Prompt Engineering 和 Context Engineering 有什么区别？
- 面试问题：Agent Memory 和普通聊天历史有什么区别？
- 面试问题：为什么长上下文模型不能完全替代记忆系统？
2. AI Agent 的 Memory 通常分为哪些类型？
- 面试问题：短期记忆、工作记忆、长期记忆、情景记忆如何区分？
- 面试问题：个人记忆、任务记忆、工具记忆分别解决什么问题？
- 面试问题：Memory 和 RAG 的本质区别是什么？
- 面试问题：Memory 与 RAG 如何组合使用？
- 面试问题：滑动窗口、摘要压缩、语义压缩如何对比？
- 面试问题：选择性保留和内容裁剪适合哪些场景？
- 面试问题：Context Engine 的 assemble / compact / retrieve 如何协同？
- 面试问题：编码 Agent 的上下文工程有哪些特殊难点？
- 面试问题：向量数据库、关系数据库、图数据库、事件日志如何分工？
- 面试问题：跨 Agent 记忆复用如何设计？
- 面试问题：记忆污染和隐私泄露有哪些风险？
- 面试问题：企业级 Memory 系统需要哪些工程能力？
标准大模型本质上是无状态的。每次请求只能看到当前输入窗口中的内容，无法天然记住长期偏好、历史任务、工具经验、项目规则和多轮进展。AI Agent 之所以需要记忆与上下文工程，是因为它要完成的任务往往具备连续性：
- 多轮对话需要知道前文。
- 长任务需要记住当前进度。
- 个人助手需要记住用户偏好。
- 编码 Agent 需要记住项目规则和已修改文件。
- 工具型 Agent 需要知道哪些工具过去有效。
- 多 Agent 系统需要避免重复探索和重复犯错。
记忆系统解决“哪些信息应该长期保留、如何检索、如何更新、如何遗忘”的问题；上下文工程解决“当前这一轮模型到底应该看到什么”的问题。二者合起来，决定 Agent 能否从一次性问答走向长期可靠工作。
可以用一个公式理解：
模型能力很重要，但如果上下文拼错、记忆污染或关键信息丢失，强模型也会做出错误决策。
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注点 | 如何写好指令 | 如何组织模型每轮看到的信息 |
| 核心对象 | system prompt、user prompt、few-shot 示例 | 消息历史、工具结果、记忆、RAG、文件、状态 |
| 目标 | 提升单次输出质量 | 支撑长期、多轮、多工具任务 |
| 难点 | 指令清晰、格式约束、角色设定 | token 预算、信息选择、压缩、检索、权限、来源可信度 |
| 典型场景 | 文案生成、结构化输出、角色扮演 | 编码 Agent、研究 Agent、个人助手、企业 Agent |
Prompt Engineering 更像“写好问题和规则”；Context Engineering 更像“管理模型的工作台”。后者需要决定：
- 哪些历史对话进入上下文。
- 哪些工具结果保留，哪些压缩。
- 哪些长期记忆相关。
- 哪些 RAG 文档可信。
- 哪些项目文件必须读取。
- 哪些信息优先级更高。
- 接近 token 上限时如何 compact。
面试中可以说：Prompt Engineering 是静态指令优化，Context Engineering 是动态信息调度。
普通聊天历史通常只是按时间顺序保存消息；Agent Memory 是经过筛选、结构化、检索和治理的长期信息资产。
| 维度 | 聊天历史 | Agent Memory |
|---|---|---|
| 存储方式 | 原始消息列表 | 结构化记录、向量、图、事件、摘要 |
| 写入策略 | 默认保存全部 | 选择性写入 |
| 检索方式 | 最近 N 轮或全文搜索 | 语义检索、时间检索、任务检索、规则检索 |
| 更新机制 | 很少更新 | 可增删改、合并、衰减、遗忘 |
| 风险控制 | 弱 | 隐私、权限、来源、过期、污染治理 |
| 作用 | 维持对话连续 | 支撑个性化、任务状态、经验复用、工具优化 |
例如“用户喜欢科幻电影”如果只存在聊天历史里，过几周后很难被准确找回；如果被提取为个人记忆，就可以在推荐电影、礼物或活动时被检索和使用。
长上下文模型能缓解短期信息容量问题，但不能替代记忆系统，原因有六个：
-
成本问题
每次都塞入大量历史会显著增加 token 成本和延迟。
-
注意力稀释
上下文很长时，模型不一定能稳定关注真正关键的信息。
-
缺少结构化
原始历史里混杂闲聊、工具输出、错误尝试和过期信息，不适合直接作为决策依据。
-
缺少更新和遗忘
长上下文只能“带上历史”，不能自动解决记忆冲突、过期、撤回和隐私删除。
-
缺少跨会话能力
用户下次新会话不一定会带上完整历史，仍需外部持久化。
-
缺少权限隔离
企业和多用户场景需要按用户、租户、项目、Agent 隔离记忆，不能简单拼接所有历史。
更合理的做法是：长上下文用于当前任务的高价值材料，Memory 系统负责长期存储、检索、压缩、更新和治理。
Agent Memory 可以从时间、功能和来源三个角度划分。
按时间划分：
- 短期记忆：当前对话窗口内的信息。
- 工作记忆：当前任务状态、计划、待办、工具结果摘要。
- 中期记忆：会话摘要、阶段性任务总结、近期项目上下文。
- 长期记忆：跨会话保留的用户偏好、稳定事实、经验和知识。
按功能划分：
- 个人记忆：用户画像、偏好、习惯、约束。
- 任务记忆：任务轨迹、成功策略、失败经验、SOP。
- 工具记忆：工具成功率、参数偏好、失败原因、成本和延迟。
- 项目记忆：仓库规则、团队规范、构建命令、架构约束。
- 安全记忆：用户撤回、禁止记录、敏感信息策略、权限边界。
按数据结构划分：
- 原始事件日志。
- 对话摘要。
- Key-Value 记忆。
- 向量记忆。
- 图记忆。
- 表格化用户画像。
- 文件或项目级记忆文档。
不同类型的记忆不应混在一个大向量库里粗暴检索。高质量 Memory 系统通常会分层、分域、分权限管理。
| 类型 | 保存内容 | 生命周期 | 典型实现 |
|---|---|---|---|
| 短期记忆 | 最近对话、最近工具结果 | 当前会话或当前窗口 | message list、sliding window |
| 工作记忆 | 当前目标、计划、进度、变量、中间结果 | 当前任务 | task state、scratchpad、todo |
| 长期记忆 | 稳定偏好、事实、经验、关系 | 跨会话 | DB、vector store、profile store |
| 情景记忆 | 某次具体事件或任务轨迹 | 可长期保存但按事件检索 | event log、timeline、episodic memory |
例子：
- “用户刚刚说预算 5000 元”是短期记忆。
- “当前旅行规划任务已完成机票，还没订酒店”是工作记忆。
- “用户偏好靠窗座位”是长期记忆。
- “2026-05-02 用户要求规划日本七日游，最终选择东京和京都”是情景记忆。
面试中要注意：工作记忆不等于长期记忆。工作记忆服务于当前任务，任务结束后可以压缩成摘要或情景记忆，其中少量稳定信息才进入长期记忆。
| 记忆类型 | 核心问题 | 示例 |
|---|---|---|
| 个人记忆 | Agent 如何更懂用户 | 偏好正式语气、喜欢科幻、对坚果过敏 |
| 任务记忆 | Agent 如何从任务经验中复用策略 | 某类 bug 修复先跑单测，再改 mock |
| 工具记忆 | Agent 如何更好地选择和使用工具 | 某搜索工具对中文文档命中率低，某 API 经常超时 |
个人记忆提升个性化；任务记忆提升复用和自我改进；工具记忆提升工具选择效率和稳定性。
一个成熟系统会把它们分开存储：
- 个人记忆按 user_id 隔离。
- 任务记忆按 task_type、domain、project、agent_role 分类。
- 工具记忆按 tool_id、参数模式、调用环境记录。
不要把工具失败记录写进用户个人画像，也不要把用户隐私写进全局任务记忆库。
| 维度 | Memory | RAG |
|---|---|---|
| 核心目的 | 保持连续性、个性化、状态和经验 | 检索外部知识，增强事实性 |
| 数据来源 | 对话、行为、任务轨迹、偏好、工具使用 | 文档、网页、知识库、数据库、手册 |
| 更新频率 | 高频、增量、交互驱动 | 低到中频，常为批量更新 |
| 检索方式 | Context / State-driven | Query-driven |
| 数据形态 | 事件、画像、摘要、向量、图、状态 | 文档块、向量索引、倒排索引、知识条目 |
| 风险 | 记忆污染、隐私泄露、跨用户串线 | 文档过期、检索不准、来源不可信 |
Memory 解决“这个 Agent 记得什么”；RAG 解决“这个问题需要查什么知识”。
例子：
- 用户说“我不吃香菜”，应进入个人 Memory。
- 企业产品手册、API 文档、报销制度，应进入 RAG 知识库。
- 某次任务失败原因“上次部署失败是因为 staging 环境缺少 env”，可进入任务 Memory。
一个完整 Agent 往往同时使用 Memory 和 RAG：
-
先理解用户和任务状态
从 Memory 中取用户偏好、当前任务进度、历史约束。
-
再检索外部知识
用 RAG 查企业文档、技术资料、产品政策、实时信息。
-
合并上下文
将用户目标、相关记忆、检索证据、工具结果和当前状态按优先级拼装。
-
生成答案或行动
模型基于合并上下文推理。
-
写回记忆
任务结束后提取新的偏好、经验或状态更新。
典型场景：
- 个人旅行助手：Memory 记住预算和偏好，RAG 查航班酒店政策。
- 企业客服：Memory 记住客户历史问题，RAG 查产品知识库。
- 编码 Agent：Memory 记住项目规范，RAG/代码检索查当前实现。
关键是来源标注。模型要知道哪些信息来自长期记忆，哪些来自文档检索，哪些来自当前用户指令，避免把不可信内容当成高优先级规则。
Agent Memory 不是简单的“保存一句话”，而是一个生命周期：
-
Ingest
接收用户消息、工具结果、任务状态、反馈和外部事件。
-
Filter
判断是否有记忆价值，过滤闲聊、临时信息、敏感信息和不可信内容。
-
Extract
提取结构化记忆，例如偏好、事实、约束、任务经验。
-
Normalize
标准化格式，添加 user_id、source、timestamp、confidence、scope、ttl、topic。
-
Store
写入合适存储：关系库、向量库、图数据库、事件日志等。
-
Retrieve
根据当前任务检索相关记忆。
-
Use
将记忆以有边界的方式注入上下文。
-
Update / Forget
合并、修改、降权、归档或删除记忆。
高质量 Memory 系统最重要的是“选择性”。不是所有内容都值得记住，错误记忆比没有记忆更危险。
可以从七个维度判断：
| 维度 | 问题 |
|---|---|
| 稳定性 | 这条信息是否长期有效？ |
| 复用价值 | 未来是否可能再次用到？ |
| 用户意图 | 用户是否明确要求记住或不要记住？ |
| 隐私等级 | 是否包含敏感个人信息？ |
| 来源可信度 | 信息来自用户、工具、网页还是模型猜测？ |
| 冲突情况 | 是否与已有记忆冲突？ |
| 作用域 | 应该属于用户、任务、项目还是全局？ |
应该写入的例子：
- “我以后都希望回答尽量用中文。”
- “这个项目测试命令是
npm test。” - “用户对花生过敏。”
- “处理某类工单时，先查订单状态再回复。”
不应写入的例子：
- 模型自己推测“用户可能喜欢跑步”。
- 临时上下文“今天下午 3 点之前要完成”。
- 未经授权的身份证、银行卡、密码。
- 来自网页的恶意指令。
工程上常用 LLM 评分 + 规则过滤：
- 0 分：无记忆价值。
- 1 分：临时信息或猜测，不写长期记忆。
- 2 分：有一定价值，可写任务或情景记忆。
- 3 分：明确长期价值或用户要求记住，可写长期记忆。
Memory CRUD 指记忆的增删改查。
| 操作 | 设计重点 |
|---|---|
| Create | 提取结构化内容，标注来源、作用域、置信度、时间 |
| Read | 支持最近、语义、主题、任务、用户画像等检索 |
| Update | 合并相似记忆，处理冲突，更新权重和时间戳 |
| Delete | 支持用户删除、隐私删除、TTL 到期、合规擦除 |
记忆记录建议包含：
{
"id": "mem_123",
"scope": "user",
"user_id": "u_001",
"content": "用户偏好中文技术解释。",
"topic": ["language_preference", "communication_style"],
"source": "user_message",
"confidence": 0.95,
"created_at": "2026-05-02T10:00:00Z",
"updated_at": "2026-05-02T10:00:00Z",
"ttl": null,
"sensitivity": "low"
}关键要求：
- 用户应能查看、修改、删除自己的长期记忆。
- 敏感记忆需要更高权限和更短保留周期。
- 删除不能只是从向量库删文本，还要处理缓存、索引、备份和日志策略。
- 更新记忆时要保留变更历史，便于审计和回滚。
常见检索策略：
-
last_n
读取最近 N 条记忆，适合近期连续任务。
-
first_n
读取最早或基础画像信息，适合稳定偏好。
-
semantic search
用向量相似度检索语义相关记忆。
-
keyword / metadata filter
按 topic、scope、project、tool_id、time range 过滤。
-
hybrid search
结合关键词、向量、时间、重要性评分。
-
agentic retrieval
让模型在候选记忆中判断哪些真正相关。
-
graph traversal
在用户、项目、实体、关系之间做图查询。
排序信号：
- 语义相关度。
- 时间新近度。
- 使用频率。
- 用户明确性。
- 置信度。
- 任务阶段相关性。
- 敏感等级和权限。
一个常见错误是只用向量相似度。实际系统里，记忆检索通常需要 metadata filter + hybrid score + rerank，否则容易检出语义相近但作用域错误的记忆。
记忆系统必须支持遗忘，否则会逐渐堆积错误和过期信息。
常见问题：
- 用户偏好变化：以前喜欢英文，现在要求中文。
- 任务状态变化：昨天的待办今天已完成。
- 事实过期：旧 API 已废弃。
- 错误写入：模型把猜测当事实。
- 隐私撤回：用户要求删除某些记忆。
处理策略：
-
时间衰减
旧记忆权重随时间下降，除非被反复使用或用户明确确认。
-
冲突检测
新记忆与旧记忆语义冲突时，不直接并存，而是触发合并或确认。
-
版本化
保留历史版本，但当前上下文只注入最新有效版本。
-
TTL
临时偏好、任务状态、短期约束设置过期时间。
-
用户可控删除
用户可以查看和删除个人记忆。
-
来源和置信度
用户明确陈述优先级高于模型推测；工具结果优先级高于网页评论。
-
合规删除
对隐私法规要求删除的数据，要处理索引、缓存和衍生摘要。
面试中可以说：Memory 系统不是只做“记住”，更重要的是“记对、用对、该忘就忘”。
上下文窗口溢出是 Agent 的高频工程问题。典型来源包括：
- 长时间对话。
- 多步骤 ReAct。
- 大量工具返回。
- 浏览器 DOM / AXTree。
- 代码仓库文件。
- 日志和测试输出。
- 多 Agent 汇报。
解决思路不是单一“换长上下文模型”，而是组合治理：
- 滑动窗口。
- 摘要压缩。
- 语义压缩。
- 选择性保留。
- 内容裁剪。
- 外部记忆。
- 分层上下文。
- 子 Agent 汇总。
- 长上下文模型。
- 混合模型策略。
目标是保证模型看到的不是“最多信息”，而是“对当前决策最有用的信息”。
| 方法 | 核心思想 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|---|
| 滑动窗口 | 只保留最近 N 轮 | 简单、稳定、低成本 | 丢失早期关键信息 | 短对话、客服 |
| 摘要压缩 | 用 LLM 把旧历史压缩成摘要 | 压缩比高，保留任务脉络 | 可能丢细节，需额外成本 | 长任务、咨询、编码 |
| 语义压缩 | 按语义重要性保留信息 | 能去冗余，信息密度高 | 实现复杂，可能破坏时序 | 文档分析、研究 Agent |
好的摘要应包含：
- 用户目标。
- 关键约束。
- 已完成步骤。
- 当前计划。
- 重要决策。
- 修改过的文件或工具结果。
- 失败尝试。
- 未解决问题。
- 下一步。
坏摘要只写“用户让我们继续完成任务”，这几乎无法恢复状态。
选择性保留是按重要性决定哪些消息进入上下文；内容裁剪是对单条内容删除无关部分。
适合选择性保留的场景：
- 多工具调用中只保留成功结果和关键错误。
- 研究任务中只保留高置信证据。
- 长对话中保留用户明确约束和最终决策。
- 多 Agent 协作中只保留子 Agent 结论，而不是完整对话。
适合内容裁剪的场景：
- 测试日志只保留失败堆栈附近内容。
- 浏览器 DOM 只保留可见区域和相关节点。
- 代码文件只保留相关函数和导入。
- 搜索结果只保留标题、摘要、URL 和关键片段。
工程建议：
- 工具返回结果先结构化再入上下文。
- 日志、网页、代码优先裁剪再摘要。
- 高风险任务保留原始引用位置，方便复查。
- 裁剪规则要可观测，避免重要信息被静默丢弃。
Context Engine 可以理解为 Agent 的上下文调度器。
三个关键动作：
-
retrieve
从 Memory、RAG、文件、工具历史、项目规则中找相关信息。
-
assemble
按优先级拼装当前 turn 的上下文：系统指令、用户目标、任务状态、相关记忆、检索证据、工具结果、当前文件。
-
compact
当 token 接近预算时，把低层级历史压缩为结构化摘要，同时保留恢复任务所需的关键信息。
优先级建议：
| 优先级 | 内容 |
|---|---|
| 最高 | system / developer 指令、安全策略、用户当前明确要求 |
| 高 | 当前任务目标、约束、待办、失败错误、相关文件 |
| 中 | 长期记忆、RAG 证据、历史摘要 |
| 低 | 过期工具输出、重复日志、闲聊、低置信记忆 |
Context Engine 还要处理来源可信度。网页、工具输出和用户上传文档不能覆盖系统指令；长期记忆也不能覆盖用户当前明确变更。
本节只把编码 Agent 作为上下文工程的典型案例，说明“相关性、新鲜度、可验证性”为什么重要；编码 Agent 的工具、权限、IDE/CLI、远程会话和 AgentOS 工程实现，见 02_编码Agent与AgentOS工程高频考点.md。
编码 Agent 的上下文工程更难，因为代码任务需要精确、可验证、跨文件一致。
难点：
- 大仓库文件太多，不能全塞上下文。
- 相关代码分散在多个模块。
- 类型定义、测试、配置、文档都可能关键。
- 用户可能有未提交改动，不能覆盖。
- 命令输出和测试日志很长。
- 代码修改后上下文会过期。
- LSP、搜索、文件读取、Git diff 需要协同。
策略：
- 先用
rg/ 文件索引定位，再读关键片段。 - 每次写入前检查当前 diff。
- 保留修改文件清单和关键行位置。
- 测试失败只保留错误附近日志。
- 对仓库规则使用
AGENTS.md/ 项目记忆文件。 - 对长任务定期 compact，保留目标、改动、验证结果和下一步。
- 子 Agent 只返回摘要，不把探索历史全部倒回主上下文。
面试中可以说：编码 Agent 的上下文工程核心是“相关性 + 新鲜度 + 可验证性”。读错旧文件或漏读测试，比上下文少一点更危险。
长期记忆系统通常不是单一数据库能解决的，而是多存储协同。
常见架构：
核心原则：
- 原始事件日志用于审计和重放。
- 关系数据库存结构化记忆和权限字段。
- 向量数据库做语义检索。
- 图数据库表达实体关系。
- 对象存储保存长文档、摘要和附件。
- 缓存层提升低延迟读取。
不要把所有记忆只存在向量库里。向量库适合语义相似搜索，但不擅长权限、版本、删除、审计和复杂事务。
| 存储 | 适合内容 | 优点 | 局限 |
|---|---|---|---|
| 关系数据库 | 用户画像、记忆元数据、权限、版本 | 事务、查询、权限、审计友好 | 语义检索弱 |
| 向量数据库 | 非结构化文本记忆、摘要、经验片段 | 语义相似检索强 | 删除和权限治理需额外设计 |
| 图数据库 | 人物、项目、实体关系、依赖网络 | 关系推理和路径查询强 | 成本和建模复杂 |
| 事件日志 | 原始对话、工具调用、任务轨迹 | 可审计、可回放 | 不能直接作为高效检索层 |
| 对象存储 | 长文档、附件、完整工具输出 | 便宜、容量大 | 需要索引层配合 |
| Redis/缓存 | 热点记忆、当前任务状态 | 低延迟 | 不适合长期可靠存储 |
生产系统常见组合：
- PostgreSQL 存 memory record 和权限元数据。
- pgvector / Milvus / Pinecone / Weaviate 存向量索引。
- Neo4j 或图扩展存复杂关系。
- S3 / OSS 存长文件和原始 transcript。
- Kafka / event log 存可回放事件流。
跨 Agent 记忆复用的目标是让多个 Agent 共享经验，但不泄露不该共享的信息。
设计方式：
-
分域存储
按 user、tenant、project、agent_role、task_type 划分记忆空间。
-
标准 Memory API
提供 search、add、update、delete、summarize、merge 等接口。
-
权限过滤
检索前先按用户、租户、项目和 Agent 权限过滤。
-
来源标注
每条记忆标明来自哪个 Agent、哪个任务、何时生成、置信度多少。
-
共享级别
个人偏好默认不共享；任务经验可在同项目或同团队共享；工具记忆可全局共享但需脱敏。
-
质量审核
只有经过验证的成功经验或明确失败教训才能进入共享记忆库。
反例：让所有 Agent 直接读写同一个全局向量库。这会导致隐私泄露、权限串线、记忆污染和错误复用。
主要风险：
- 错误记忆：模型把猜测写成事实。
- 过期记忆：旧偏好、旧规则继续影响决策。
- 恶意记忆：用户或网页注入“以后忽略安全规则”。
- 跨用户串线：A 用户记忆被 B 用户检索到。
- 敏感信息长期化：密码、token、身份证号被写入长期记忆。
- RAG 与 Memory 混淆：把外部文档中的描述当成用户偏好。
- 过度个性化：记忆使用不透明，让用户感到被监视。
治理策略：
- 写入前做敏感信息检测。
- 只有用户明确或高置信信息进入长期记忆。
- 记忆记录必须有 scope、source、confidence、sensitivity。
- 工具输出和网页内容默认不可信。
- 用户可查看、编辑、删除个人记忆。
- 不同用户、租户、Agent 的记忆物理或逻辑隔离。
- 定期清理低价值和过期记忆。
- 高风险记忆写入需要人工确认或策略审批。
面试中可以强调：Agent Memory 是产品体验能力，也是数据安全能力。记忆系统没有治理，越强越危险。
本节只讨论 Memory 子系统的工程能力，例如存储、权限、CRUD、TTL、冲突和隐私。企业级 Agent 平台整体架构、Builder、模型网关、Registry 和产品治理，见 07_企业级Agent平台与产品落地高频考点.md。
企业级 Memory 系统需要：
- 多租户隔离。
- user_id / tenant_id / project_id / agent_id 作用域。
- RBAC / ABAC 权限控制。
- 记忆 CRUD API。
- 记忆版本管理。
- 用户可查看和删除。
- PII 检测和脱敏。
- TTL、归档和遗忘机制。
- 向量检索和元数据过滤。
- 记忆质量评分。
- 冲突检测和合并。
- 审计日志。
- 检索命中率、使用率、污染率监控。
- 数据备份和合规删除。
- 与 RAG、Session Store、Tool Trace 解耦。
关键指标：
- 记忆写入准确率。
- 记忆检索命中率。
- 错误记忆率。
- 隐私违规率。
- 平均检索延迟。
- 上下文压缩比。
- 用户编辑/删除请求处理时延。
- 记忆对任务成功率的提升。
本章只从上下文工程角度解释 Skill 如何按需加载、降低 prompt 噪声并和 Memory / RAG / Tool 协同；自进化 Agent 中 Skill 如何被 Curator 评分、合并、归档、回滚和持续维护，见 09_自进化Agent与多平台运行时高频考点.md。
Skills 是一种按需加载的能力包，通常包含任务说明、流程、模板、参考资料和可选脚本。它属于上下文工程，因为它解决的是“不要把所有专业知识永久塞进系统提示词，而是在需要时加载相关能力”。
Skill 常见结构：
my-skill/
├── SKILL.md
├── scripts/
└── references/
它的价值：
- 减少系统 prompt 膨胀。
- 让 Agent 渐进式发现能力。
- 把专业流程模块化。
- 在多个 Agent 之间复用方法论。
- 将领域文档、模板、脚本和示例打包。
- 降低上下文噪声。
Skills 与 Memory 的关系：
- Memory 是 Agent 从历史中学到的内容。
- Skill 是开发者或团队预先整理的可复用能力包。
- 二者都可以按需注入上下文，但来源和治理方式不同。
| 概念 | 本质 | 例子 |
|---|---|---|
| Tool | 可执行动作 | 查数据库、发邮件、运行测试 |
| Skill | 可复用方法论和资源包 | 代码审查流程、论文阅读指南 |
| Memory | 历史经验和个性化状态 | 用户偏好、任务失败教训 |
| RAG | 外部知识检索 | 产品文档、API 手册、法规库 |
一句话区分：
- Tool 让 Agent 能做事。
- Skill 告诉 Agent 怎么做某类事。
- Memory 让 Agent 记得过去发生过什么。
- RAG 让 Agent 查到外部知识。
它们经常组合使用。例如代码审查 Agent：
- Tool：读取文件、运行测试。
- Skill：代码审查 checklist。
- Memory：该项目过去常见 bug。
- RAG：框架官方文档。
这里从上下文工程视角解释项目记忆文件的作用，重点是如何被加载、作用域如何管理、如何避免过期污染；在真实编码 Agent 中如何配合 rg、LSP、Git diff、测试日志和仓库权限，见 02_编码Agent与AgentOS工程高频考点.md。
项目记忆文件包括 AGENTS.md、特定生态的项目说明文件、团队约定文档等。它们为编码 Agent 提供仓库级上下文。
常见内容：
- 项目简介。
- 目录结构。
- 构建命令。
- 测试命令。
- 代码风格。
- 模块边界。
- 禁止操作。
- 安全要求。
- 常见坑。
- 提交流程。
价值：
- 减少每次重新探索项目。
- 避免运行错误命令。
- 帮助 Agent 遵守团队规范。
- 降低覆盖用户改动的风险。
- 让子 Agent 拿到一致规则。
注意：
- 项目记忆文件不是绝对真理，可能过期。
- Agent 执行前仍应通过 README、package、CI、实际测试结果验证。
- 多层目录下的项目记忆要有作用域规则，避免子目录规则被根目录规则覆盖。
可以按八层设计：
-
事件采集层
采集用户消息、任务、日程、工具调用、反馈和显式记忆指令。
-
记忆提取层
用规则和 LLM 提取偏好、事实、约束、关系、任务状态。
-
安全过滤层
做 PII 检测、敏感内容过滤、用户同意检查和作用域判断。
-
存储层
结构化画像放关系库，语义片段放向量库，关系放图数据库，原始事件放日志。
-
检索层
结合时间、语义、主题、用户当前任务和权限进行混合检索。
-
上下文组装层
只把当前任务需要的少量记忆注入模型，并标注来源和置信度。
-
更新与遗忘层
支持记忆合并、冲突处理、TTL、用户删除、隐私擦除。
-
可观测与控制层
用户可查看“我记住了什么”，系统监控写入准确率、检索命中率和隐私风险。
面试中的高分回答是：个人助理记忆系统不能只做向量检索，它必须同时解决用户控制权、隐私边界、记忆质量、上下文预算和长期演化。
- Memory 解决连续性、个性化、状态和经验，Context Engineering 决定模型每轮看到什么。
- Prompt Engineering 是静态指令优化，Context Engineering 是动态信息调度。
- 长上下文模型不能替代 Memory，因为成本、注意力、结构化、遗忘和权限问题仍然存在。
- 短期记忆看最近对话，工作记忆管当前任务，长期记忆跨会话保存稳定信息。
- Memory 和 RAG 互补：Memory 记住用户和任务，RAG 检索外部知识。
- 记忆生命周期包括 ingest、filter、extract、normalize、store、retrieve、use、update/forget。
- 不是所有信息都该记住，错误记忆比没有记忆更危险。
- 记忆检索不能只靠向量相似度，还要结合 metadata、时间、权限和任务状态。
- 上下文溢出要组合滑动窗口、摘要、语义压缩、选择性保留、内容裁剪和外部记忆。
- Context Engine 负责 retrieve、assemble、compact，是 Agent 的上下文调度器。
- 长期记忆存储常用关系库 + 向量库 + 图数据库 + 事件日志组合。
- 跨 Agent 记忆复用必须做作用域、权限、来源和质量控制。
- 记忆污染、隐私泄露、跨用户串线是 Memory 系统的核心安全风险。
- Skills 是按需加载的能力包，属于渐进式上下文工程。
- Tool 能做事，Skill 教怎么做，Memory 记住过去，RAG 查外部知识。
- Park et al., Generative Agents: Interactive Simulacra of Human Behavior, 2023.
- Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023.
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
- LangChain, Memory Documentation.
- LangChain, LangGraph Persistence.
- LlamaIndex, Agents and Memory Documentation.
- Mem0, Memory for AI Agents.
- Letta, Agent Memory and Context Management.
- Anthropic, Agent Skills Overview.