AI Memory / Context / State 管理手册

定位: 面向 AI PM / AI BA / AI Architect 的生产级记忆、上下文与状态管理手册。 目标: 训练从 demo 走向生产系统时, 如何设计“AI 能记住什么、何时使用、谁能控制、如何删除、如何审计、如何评估”。 核心观点: AI memory 不是把聊天历史塞进 prompt。生产级 memory 是受 consent、权限、数据治理、业务状态、合规留痕、删除机制和 eval 约束的系统能力。

---

0. 如何连接已有三份文档

本手册不是替代已有 AI 文档, 而是补上“上下文如何变成可治理的长期能力”这一层。

一句话关系:

Context Engineering 决定一次调用看什么。
Memory / State Management 决定什么能被留下、下次如何再用、何时必须忘记。
AI Platform PM 决定这些能力如何被多个业务团队安全复用。
Long-Term Knowledge Graph 决定学习者如何把这些设计转成作品集证据。

---

1. Source Anchors

这些来源作为学习锚点, 不构成法律、合规、采购或监管建议。

补充锚点:

---

2. 从 Demo 到生产: 为什么 Memory 是分水岭

Demo 阶段常见做法:

• 把最近几轮对话拼进 prompt。
• 把用户说过的偏好保存到一张表。
• 把文档切块进向量库。
• 让 agent 自己总结“重要记忆”。
• 看到效果不错就称为“个性化”。

生产阶段的问题完全不同:

• 用户是否明确同意系统记住这件事?
• 记住的是事实、偏好、推断、业务状态, 还是模型幻觉?
• 记忆是否过期?
• 当前用户是否仍有权限读取这段记忆?
• 客户换渠道、换身份、换产品线后, 记忆还能合并吗?
• 记忆被用于投资建议、信贷建议、客户权益判断时, 风险如何控制?
• 用户要求删除后, 向量库、缓存、备份、审计、下游副本如何处理?
• 监管要求留痕和用户删除权冲突时, 哪个字段可删除, 哪个字段必须保留, 保留多久?
• 个性化是否导致不公平、诱导销售、过度画像或错误拒绝服务?

生产级结论:

模型不拥有记忆。
应用层和平台层拥有记忆的写入、读取、更新、删除、审计和评估。
业务系统拥有权威状态。
合规和用户控制决定记忆边界。

---

3. 基本概念: Context、Memory、State、Audit

3.1 易混点

---

4. Memory Taxonomy

4.1 总览

4.2 Session Context

Session context 是当前对话或当前操作窗口内的上下文。它解决“不要每轮都让用户重复刚说过的话”。

设计原则:

• 会话上下文默认短期有效。
• 明确区分“当前任务摘要”和“可长期记住的事实”。
• 当用户切换客户、案件、产品或渠道时, 触发 context reset 或 scope reset。

4.3 Working Memory

Working memory 是 AI 或工作流为了完成当前任务保留的临时中间状态。

适用场景:

• AML 调查 copilot 暂存“候选风险假设”。
• 理赔助手暂存“缺失材料清单”。
• 金融零售 BA 助手暂存“访谈纪要到需求映射草稿”。

4.4 Episodic Memory

Episodic memory 记录过去发生过的具体事件或交互, 类似“某时某地发生了什么”。

关键边界:

Episodic memory: 2026-06-01 用户问过房贷提前还款手续费。
Semantic memory: 当前房贷提前还款政策是什么。
Business state: 这个用户的贷款合同当前是否允许提前还款。

4.5 Semantic Memory

Semantic memory 保存相对稳定的知识、规则、概念、流程和领域事实。

架构上常见组合:

• 文档库负责原文和版本。
• 向量库负责语义检索。
• 知识图谱负责实体、关系、规则和来源。
• Policy layer 决定哪些知识能进入当前用户的上下文。

4.6 User Preference

User preference 是用户明确表达或系统经授权学习到的偏好。

偏好强度建议:

4.7 Business Object State

Business object state 是客户、账户、订单、交易、案件、合同等业务对象的当前权威状态。

原则:

• State store 是权威, memory store 不是权威。
• AI 可以解释 state, 不能私自创造 state。
• 写入状态必须经过工具权限、幂等、校验、审计和必要的人审。

4.8 Workflow State

Workflow state 描述流程实例当前处于哪个阶段、可执行哪些动作、异常路径是什么。

推荐表达:

AI 可以建议下一步。
Workflow engine 决定下一步是否允许执行。
Human / policy 决定高风险步骤是否批准。
Audit store 记录建议、批准、执行和结果。

4.9 Audit Memory

Audit memory 是为追溯和问责保留的记录。它不是默认个性化材料。

审计记录建议包含:

• 谁发起: actor、role、tenant、channel。
• 做什么: task type、risk tier、business object id。
• 用什么: model version、prompt/config version、policy version、source ids。
• 调什么工具: tool name、input hash、output hash、approval id。
• 结果如何: final action、human decision、error category、feedback id。

4.10 Feedback Memory

Feedback memory 记录用户、审核员、运营、eval 对 AI 输出的评价和修正。

反馈分类建议:

---

5. 生产级 Memory Object Schema

任何长期 memory 都应该是可治理对象, 不是一段裸文本。

写入门禁:

1. 这条 memory 是否有明确业务价值?
2. 来源是否可追溯?
3. 是否包含 PII、敏感推断或受监管信息?
4. 用户是否同意或是否有合法业务依据?
5. 是否设置 scope、retention、deletion path?
6. 是否有过期或重新确认机制?
7. 是否能被 eval 覆盖?

---

6. PM / BA / Architect 分工

6.1 PM: 定义记忆价值、用户控制和产品边界

PM 负责回答“为什么要记住”和“用户如何控制”。

PM 需要避免的陷阱:

• 把“更懂用户”当成天然好事。
• 只追求留存和转化, 忽略客户权益和合规边界。
• 默认所有用户都希望被记住。
• 没有给用户“本次不要使用这条记忆”的控制。
• 用过期偏好持续影响关键决策。

6.2 BA: 写 consent、retention、exception requirements

BA 负责把 memory 行为变成可验收需求、流程和异常路径。

BA 需求示例:

REQ-MEM-001: 系统必须在保存用户长期偏好前展示记忆内容、用途、保留期和撤回方式。

REQ-MEM-002: 当用户撤回个性化 consent 后, 系统必须停止在未来模型上下文中使用该用户的 preference memory。

REQ-MEM-003: 当业务对象状态来自核心系统且与 episodic memory 冲突时, 系统必须以核心系统状态为准, 并在回答中提示“历史记录可能已过期”。

REQ-MEM-004: 对包含 restricted PII 的 memory, 系统必须禁止跨租户、跨客户、跨未授权渠道检索。

REQ-MEM-005: 当用户请求删除可删除记忆时, 系统必须删除 primary store、vector index、cache 和非监管必留副本, 并生成删除证明。

REQ-MEM-006: 当删除请求涉及监管留痕字段时, 系统必须区分可删除内容、可脱敏内容、必须保留的审计元数据和 legal hold 情形。

REQ-MEM-007: 当 AI 使用 memory 生成客户权益、费用、授信、投资或投诉处理建议时, 系统必须记录 memory ids、policy version 和人工审批结果。

BA 异常路径:

6.3 Architect: 设计 state store、memory store、vector/KG、policy layer、deletion

Architect 负责回答“如何安全可靠地实现”。

核心架构原则:

• State and memory separation: 业务状态和 AI 记忆分开建模。
• Policy before retrieval: 不是检索后再过滤, 而是检索前就带上权限和 scope。
• Memory as data product: 每类 memory 有 owner、SLA、质量指标和生命周期。
• Deletion by design: 删除不是后台脚本, 是产品和平台能力。
• Audit without overexposure: 留痕要足够复盘, 但避免长期保存完整敏感内容。

6.4 RACI

---

7. 金融零售风险地图

金融零售场景的 memory 风险高, 因为系统常涉及身份、资产、信用、权益、投诉、营销和监管义务。

7.1 PII 与敏感数据

7.2 客户权益

7.3 投资与信贷建议

7.4 历史偏好误用

7.5 跨渠道身份合并

7.6 Right to Deletion

7.7 监管留痕与删除冲突

---

8. Architecture Patterns

8.1 Stateless Copilot

适用:

• 高风险、低个性化、强合规场景。
• 早期 MVP。
• 用户不希望系统长期记住。

结构:

User request -> Context composer -> Policy -> Model -> Response
                         |
                 Current documents / tools

优势:

• 隐私风险较低。
• 删除简单。
• 容易做权限和审计。

局限:

• 用户每次要重复背景。
• 难支持长期任务。
• 个性化弱。

金融零售例子:

• 内部政策问答助手。
• 客服话术草稿助手。
• BA 需求摘要助手。

8.2 Session Memory

适用:

• 多轮对话。
• 单次任务内连续操作。
• 不需要跨会话记忆。

结构:

Session cache -> Context summarizer -> Context composer -> Model

设计要点:

• session timeout。
• task boundary reset。
• 敏感字段脱敏。
• 用户切换客户或案件时清空。

例子:

• 客服在一次通话中让 AI 帮忙整理问题、查政策、生成回复。

8.3 Case Memory

适用:

• AML、KYC、理赔、投诉、运营工单。
• 多人、多天、多阶段处理同一 case。

结构:

Case events + case notes + documents
        -> Case memory service
        -> Retrieval with case_id and role permission
        -> AI case copilot

设计要点:

• case_id 是强边界。
• 区分原始证据、人工结论、AI 草稿。
• case closure 后切换保留策略。
• 高风险结论需要人审。

例子:

• AML investigator copilot 记住调查进度、已排除假设、仍需补充的证据。

8.4 Customer Memory

适用:

• 长期服务关系。
• 用户明确希望系统记住偏好。
• 客户服务、财富服务、零售会员。

结构:

Customer profile / consent / preference / episodic events
        -> Customer memory service
        -> Policy + entitlement filter
        -> Personalized response

设计要点:

• 默认显式 consent。
• 用户可查看、编辑、删除。
• 高风险决策不能只依赖 customer memory。
• 与 CRM、核心系统、适当性系统建立边界。

例子:

• 记住客户偏好“每月第一周发送英文 PDF 账单摘要”, 但不把一次基金浏览记录当成投资偏好。

8.5 Enterprise Semantic Memory

适用:

• 企业知识、政策、流程、产品规则。
• 多业务团队复用。
• RAG / knowledge assistant。

结构:

Source systems -> Ingestion -> Metadata / ACL -> Vector index + KG
        -> Retrieval policy -> Context composer -> Model

设计要点:

• owner、version、effective date。
• 权限继承和文档级 ACL。
• freshness eval。
• prompt injection 防护。
• 引用和证据返回。

例子:

• 客服政策助手读取最新费用政策、投诉流程、地区差异规则。

8.6 Workflow State Machine

适用:

• 需要 AI 参与但不能自由行动的业务流程。
• KYC remediation、支付异常、贷款材料补充、订单售后。

结构:

Workflow engine
  -> current state
  -> allowed transitions
  -> tool gateway
  -> human approval gate
  -> audit event

设计要点:

• AI 只建议动作。
• 状态机决定动作是否合法。
• 工具层执行动作。
• 高风险步骤需要人审。

例子:

• 支付异常 agent 可建议“发起对账查询”, 但不能绕过审批直接退款。

8.7 Event-Sourced Audit Trail

适用:

• 高监管、高问责、高风险系统。
• 需要复盘“AI 为什么这么回答/做了什么”。

结构:

Command / query / memory read / tool call / policy decision / human approval
        -> Append-only event store
        -> Audit views / incident views / compliance reports

设计要点:

• 事件不可变。
• 敏感 payload 用 hash、redaction 或加密引用。
• 可重建决策路径。
• 与删除策略分层处理。

例子:

• 财富合规助手记录每次使用的政策版本、客户适当性状态、拒答原因和人工审批。

---

9. Reference Architecture

flowchart TB
  U[User / Employee / Channel] --> I[Identity and Consent Service]
  I --> R[Request Risk Classifier]
  R --> S[State Reader]
  R --> MR[Memory Retrieval Planner]

  S --> ST[(Business State Store)]
  S --> WF[(Workflow Engine)]

  MR --> P[Policy Layer]
  P --> MS[(Memory Store)]
  P --> VX[(Vector Index)]
  P --> KG[(Knowledge Graph)]

  ST --> CC[Context Composer]
  WF --> CC
  MS --> CC
  VX --> CC
  KG --> CC
  P --> CC

  CC --> MG[Model Gateway]
  MG --> V[Response Validator]
  V --> TW[Tool Gateway]
  TW --> WF
  TW --> ST
  V --> OUT[Response / Draft / Action Recommendation]

  CC --> AU[(Audit Event Store)]
  MG --> AU
  TW --> AU
  V --> FB[(Feedback Store)]
  FB --> EV[Memory Eval Harness]
  EV --> P

  I --> DS[Deletion and Retention Service]
  DS --> MS
  DS --> VX
  DS --> KG
  DS --> FB
  DS --> AU

9.1 关键边界

9.2 Context Composer 的输入顺序

推荐顺序:

1. 当前 task 和 risk tier。
2. 用户角色、权限、consent 状态。
3. 当前业务对象 state。
4. 当前 workflow state 和 allowed actions。
5. 经授权的 semantic evidence。
6. 经授权且未过期的 memory 摘要。
7. policy constraints 和 refusal/escalation rule。
8. output schema。
9. uncertainty and conflict instruction。

避免:

• 把 memory 放在 policy 前面。
• 把用户历史偏好放在当前业务状态前面。
• 把审计日志原文直接放入 prompt。
• 把跨租户检索结果再靠模型“自行判断是否相关”。

---

10. 关键设计决策

10.1 记什么

建议优先记:

• 用户明确设置的偏好。
• 当前 case 的处理进度和人工确认结论。
• 企业知识的权威版本和来源。
• 业务流程状态和允许动作。
• 对产品改进有价值的脱敏反馈。

建议谨慎记:

• 从单次对话推断出的兴趣。
• 负面事件、投诉、逾期、疾病、家庭变化。
• 客户情绪标签。
• 可能影响价格、授信、权益、投资建议的历史行为。

建议不记:

• 不必要的完整 PII。
• 模型内部推理链。
• 未验证的敏感推断。
• 用户临时说出的隐私信息且无业务必要。
• prompt injection 中要求“永久记住”的恶意指令。

10.2 谁能写 memory

10.3 如何解决冲突

冲突优先级:

Law / regulation / enterprise policy
> current business state from source of truth
> explicit user setting
> approved case note or human decision
> enterprise semantic memory with current version
> episodic memory
> inferred preference
> model-generated summary

冲突处理话术:

我看到历史记录显示你之前选择过短信通知, 但当前账户设置显示通知方式已改为 App push。为了避免误导, 本次以当前账户设置为准。

10.4 如何删除

删除不是单表操作, 而是数据生命周期流程。

删除设计要点:

• 向量索引必须能从 memory_id 反查并删除。
• 缓存必须短 TTL 或支持主动 purge。
• 备份可以通过到期清除, 但需要明确恢复后再删除机制。
• legal hold 不是继续个性化使用的理由。
• 删除后需要 suppression list, 防止系统从旧事件重新生成同一记忆。

10.5 MCP 与 Memory 边界

MCP 可以让模型访问 tools、resources、prompts 等外部能力, 但 MCP 暴露的内容不应自动变成长期 memory。

设计原则:

• Resource 是可读取上下文, 不是默认可保存记忆。
• Tool result 是一次观察, 不是永久事实。
• Prompt template 是行为配置, 不是业务政策本身。
• Tool write action 必须受权限、幂等、审批和审计约束。
• 从 MCP server 返回的内容需要经过同样的 classification、policy 和 retention 处理。

---

11. Evaluation: Memory 评估体系

Memory eval 不是只问“回答是否更自然”, 而是测试记忆是否有用、准确、合规、可控、可删除。

11.1 指标总览

11.2 Memory Eval Set

11.3 Release Gate

上线前建议门槛:

11.4 线上监控

---

12. 30 天 Lab: 从 Memory Inventory 到面试故事

目标: 30 天内完成一套可放入作品集的“金融零售 AI Memory / Context / State 设计包”。

建议主题:

Customer Service + KYC Remediation Copilot
场景: 金融机构客服和运营人员使用 AI 协助处理客户 KYC 补件、权益解释、投诉跟进和政策问答。

30 天完成后的作品集证据:

• 一张 memory taxonomy 图。
• 一张 state boundary diagram。
• 一份 retention & deletion matrix。
• 一份 context composer 示例。
• 一份 memory eval set。
• 一份 incident drill。
• 一份面试故事。

---

13. Templates

13.1 Memory Inventory

使用规则:

• 每一行都必须能回答“为什么记、谁能看、保留多久、如何删除”。
• 没有 owner 的 memory 不进入生产。
• 没有 deletion path 的 memory 不进入长期存储。

13.2 State Boundary Diagram

flowchart LR
  User[User / Customer] --> Channel[Channel UI]
  Channel --> AI[AI Copilot]
  AI --> Context[Context Composer]
  Context --> Memory[(Memory Store)]
  Context --> Semantic[(Semantic KB / Vector / KG)]
  Context --> State[(Business State Store)]
  State --> Core[Core Banking / CRM / OMS]
  AI --> Workflow[Workflow Engine]
  Workflow --> Tool[Tool Gateway]
  Tool --> Core
  AI --> Audit[(Audit Event Store)]
  Memory --> Deletion[Deletion Service]
  Semantic --> Deletion
  Audit --> Retention[Retention / Legal Hold Policy]

边界标注:

13.3 Retention & Deletion Matrix

13.4 Memory Eval Set

13.5 Memory Incident Triage

Severity 建议:

---

14. 面试表达

14.1 30 秒版本

AI memory 不能理解成“让模型记住聊天历史”。生产系统里我会把 context、memory、business state 和 audit 分开: context 是当前调用可见内容, memory 是可持久化且受 consent 和 retention 管理的信息, state 必须来自业务系统, audit 用于追溯而不是默认个性化。金融零售场景尤其要控制 PII、投资/信贷建议、跨渠道身份合并和删除权。我会用 memory inventory、policy layer、deletion workflow 和 memory eval 来保证它有用、不过期、不越权、可删除。

14.2 2 分钟版本

我会先做 taxonomy: session context、working memory、episodic memory、semantic memory、user preference、business object state、workflow state、audit memory、feedback memory。每类信息的价值、来源、权限、保留期和删除方式不同。

架构上, 我不会让模型直接拥有记忆。业务状态从 core system 或 workflow engine 读取; 长期记忆进入 memory store; 企业知识进入 vector/KG; 所有写入、检索、上下文注入和删除都经过 policy layer。Context composer 只把当前任务必要、授权、未过期的内容放进 prompt。高风险动作通过 tool gateway、人工审批和 audit trail。

PM 负责定义记忆价值和用户控制, 例如用户是否能查看、编辑、关闭和删除记忆。BA 负责把 consent、retention、异常路径、删除冲突写成可验收需求。Architect 负责 state store、memory store、vector/KG、policy、deletion 和 eval。

评估上, 我会覆盖 usefulness、staleness、privacy leak、preference conflict、policy conflict、deletion test、cross-tenant leakage 和 bad personalization。尤其在金融零售中, 历史偏好不能替代适当性或授信规则, 审计留痕也不能被滥用于个性化。

14.3 CTO 深挖

Q: 你怎么设计 memory 架构, 避免变成不可控的数据泥潭?

A: 我会做四层分离。第一层是权威 state store, 只承载业务对象和流程状态; 第二层是 memory store, 以结构化 memory object 保存用户偏好、case memory、feedback 等; 第三层是 semantic memory, 用文档库、向量索引和知识图谱管理企业知识; 第四层是 audit event store, 用 append-only 事件记录上下文选择、工具调用、policy decision 和人审。所有读取经过 policy layer, 所有注入由 context composer 做必要性、权限、freshness 和 risk tier 过滤。向量索引只存可反查的 embedding_ref, 删除从 memory_id 编排到 index、cache 和下游副本。

Q: 为什么不用一个向量库解决所有 memory?

A: 向量库解决相似度检索, 不能单独解决权威状态、权限、版本、consent、删除、审计和冲突优先级。比如客户贷款状态必须从核心系统读, 不能从历史聊天向量里推断。向量库可以是 memory retrieval 的一个组件, 但不是 memory governance 本身。

Q: 如何处理 latency 和成本?

A: 分层检索。低风险任务只用 session summary 和 semantic top-k; 高风险任务增加 state read、policy check 和 citation validation。常用企业知识可以缓存, 但个人 memory 和 state cache 要短 TTL 并支持 purge。context composer 需要 budget: 每类 context 有 token 上限和优先级, 冲突时保留 policy、state 和证据, 降低 episodic memory 权重。

14.4 DPO / Privacy 深挖

Q: 用户要求删除时, 你怎么证明真的删除了?

A: 我会把删除设计成服务而不是手工脚本。删除请求先验证身份和范围, 然后分类为 preference、episodic、case、feedback、audit 等。可删除内容先进入 suppression, 立即停止未来上下文使用; 随后删除 primary store、vector index、cache 和可控下游副本; 对备份按恢复后再删除机制处理; 对监管必留内容做字段级脱敏或 legal hold 标记。最后运行 deletion eval, 验证该 memory_id 不再能被检索或注入, 并生成 deletion receipt。

Q: 审计留痕和删除权冲突怎么办?

A: 我会做字段级和用途级分离。用户偏好和个性化内容通常可删除; 法定交易记录、投诉处理记录或合规审批元数据可能需要保留。保留不等于继续个性化使用。被 legal hold 的记录应限制访问、禁止进入普通 context composer, 并在保留期结束后执行删除或脱敏。

Q: 如何防止敏感推断?

A: 首先禁止把模型推断的健康、财务困境、政治倾向、风险承受能力等敏感属性自动写入长期 memory。其次 memory write gate 会检查 sensitivity、source、consent 和用途。第三, bad personalization eval 会测试系统是否利用历史投诉、困难陈述或单次浏览行为做营销、授信或投资建议。

14.5 PM 深挖

Q: 怎么判断一个 memory 功能值得做?

A: 我会看三个价值: 是否减少用户重复输入, 是否降低运营错误, 是否提升复杂任务连续性。然后看三个风险: 用户是否愿意被记住, 记忆是否会影响权益或建议, 删除和纠错成本是否可控。如果记忆只带来轻微便利但引入 PII、合规和信任风险, 我会选择 session memory 或显式偏好, 不做隐式长期记忆。

Q: 用户控制怎么设计?

A: 至少要有五个控制: 记住前确认、记忆中心查看、编辑、暂停使用、删除。回答中如果使用了重要 memory, 可以显示“本次使用了你的摘要格式偏好”或“基于当前案件状态”。高风险场景还要支持“本次不要使用历史偏好”, 以及把 memory 纠错变成反馈入口。

Q: Memory 成功指标是什么?

A: 不只看使用率。核心指标包括任务完成时间、重复输入次数、人审修改率、用户纠错率、opt-out rate、stale memory rate、deletion SLA、privacy incident count、bad personalization rate。PM 要把“更个性化”拆成“更有用且更可控”。

---

15. 作品集转化方式

可以把本手册转成一个 capstone:

Case Study: Production-grade Memory, Context and State Management for Financial Retail AI Copilot

作品集结构:

面试故事主线:

我不是把 memory 当成模型特性, 而是把它当成企业数据产品和平台能力。
PM 定义价值和控制, BA 定义需求和异常, Architect 定义存储、策略、删除和评估。
在金融零售场景, 这能避免过期偏好、越权读取、错误建议和删除失败。

---

16. 自检清单

---

17. 关键提醒

• Memory 的默认立场不是“尽量多记”, 而是“只记有价值、被授权、可控制、可删除的内容”。
• Business state 永远优先于历史 memory。
• Audit memory 不应默认用于个性化。
• Vector DB 是检索组件, 不是治理边界。
• 删除能力必须在架构第一天设计, 不能上线后补。
• 金融零售 AI 的差异化能力, 不在于会调用模型, 而在于能把 memory、state、policy、audit 和 eval 设计成可信系统。