Generative Agents：Memory、Reflection、Planning
Generative Agents 的原理是把长期行为拆成 memory stream、retrieval、reflection 和 planning。Agent 持续记录观察和交互，按相关性、时间性和重要性召回记忆，再把零散事件反思成高层抽象，最后把抽象转成未来计划。它研究的是 AI 如何在一段时间内保持行为连续性，而不是一次性回答是否聪明。
Generative Agents / Memory / Reflection / Planning 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Generative Agents | https://arxiv.org/abs/2304.03442 | 理解 memory stream、reflection、planning 和 believable agent behavior |
| NIST GenAI Profile | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 把 memory risk 放入 govern / map / measure / manage |
| MCP specification | https://modelcontextprotocol.io/specification/2025-03-26 | 理解工具、资源、上下文连接和协议边界 |
核心导读
Generative Agents 的原理是把长期行为拆成 memory stream、retrieval、reflection 和 planning。Agent 持续记录观察和交互，按相关性、时间性和重要性召回记忆，再把零散事件反思成高层抽象，最后把抽象转成未来计划。它研究的是 AI 如何在一段时间内保持行为连续性，而不是一次性回答是否聪明。
这套机制的价值在于解释“长期上下文”不是把历史对话无限塞进 prompt。记忆需要被写入、分类、检索、压缩、过期和纠正；反思可以帮助形成案件假设、客户偏好或任务状态；计划可以把下一步行动组织成可执行流程。对企业 AI 来说，memory 是一个受控子系统，而不是一个向量库附加功能。
治理边界决定它能否上线。模型生成的 reflection 是推断，不是事实；AI memory 不能替代 CRM、case system、核心银行、审批系统或监管记录。金融零售系统必须为记忆设置来源、权限、用途限制、保留期、删除机制、证据锚点、复核状态和失效条件，否则长期记忆会从体验能力变成隐私、偏见和审计负债。
1. 论文真正研究的问题
Generative Agents 研究的是一个看似简单、实际很深的问题：如果一个 AI 角色要在一段时间内持续行动，它如何保持行为连续性？
普通聊天模型只有当前 prompt 和有限上下文。它可以在一次对话里表现得聪明，但跨事件、跨时间、跨目标时会出现三类断裂：
| 断裂 | 表现 | 企业系统中的对应问题 |
|---|---|---|
| 记忆断裂 | 忘记先前事件、偏好、承诺和约束 | 客服助手忘记客户刚提交的证据；调查助手忘记前一次结论 |
| 推理断裂 | 只对局部消息反应，无法形成稳定判断 | AML case 每次只看一条交易，不能形成 typology hypothesis |
| 行动断裂 | 没有未来计划，下一步动作不连续 | Agent 不能把“收集证据、复核、提交、通知”串成流程 |
这篇论文的贡献，是提出一种可组合架构：把观察到的事件写入记忆流，按相关性、时间性和重要性检索，再通过反思形成高层抽象，最后把抽象转成计划。
它不是企业 agent 的完整架构。它没有解决权限、隐私、数据保留、监管证据、人工复核、模型风险和生产可观测性。但它解释了长期 agent 行为的底层构造。
2. Memory Stream：记忆不是一段长 prompt
Memory stream 是论文的基础结构。每个 agent 会持续把观察、交互和内部结论写成离散 memory record。
一个 record 至少包含：
| 字段 | 含义 |
|---|---|
| 内容 | 观察到的事件或生成的内部记忆 |
| 时间 | 什么时候发生 |
| 重要性 | 这条记忆是否值得未来影响行为 |
| 嵌入表示 | 用于语义检索 |
| 来源 | 来自环境、对话、反思还是计划 |
这比“把历史对话全部塞进上下文”更重要。长期系统不可能无限扩展上下文，也不应该让所有历史信息都进入每次推理。记忆必须可选择、可过滤、可解释。
企业 AI 中的 memory stream 应该进一步拆成几类：
| 记忆类型 | 例子 | 主要风险 |
|---|---|---|
| Episodic memory | 某次客户交互、某次 case review、某次审批记录 | 过期、误读、上下文缺失 |
| Semantic memory | 政策规则、产品知识、流程定义 | 版本失效、来源不明 |
| Preference memory | 客户沟通偏好、员工工作偏好 | 隐私、用途越界 |
| Decision memory | 曾经做过的判断和理由 | 把旧判断当成事实 |
| Operational memory | 工单状态、任务计划、待办项 | 状态不一致、重复执行 |
一个成熟系统不会只有一个“memory database”。它会按风险和用途分层，给不同记忆设置不同的写入权限、读取权限、保留期、删除机制和审计策略。
3. Retrieval：记忆选择决定行为质量
论文的检索机制不是简单相似度搜索，而是综合三类信号：
| 信号 | 作用 |
|---|---|
| Recency | 最近发生的事情更可能影响当前行为 |
| Relevance | 与当前情境语义相关的记忆更有价值 |
| Importance | 高影响事件应该比日常噪音更容易被召回 |
这个设计解释了为什么长期 agent 不只是“向量库 + top-k”。如果只按相似度检索，系统会召回语义相近但已经过期、低价值或不该进入当前任务的内容。如果只按时间检索，系统会被最近噪音淹没。如果只按重要性检索，系统会忽略当前细节。
金融零售系统尤其需要把 retrieval 做成策略层，而不是单个算法：
| 策略问题 | 示例 |
|---|---|
| 当前任务允许读取哪些记忆？ | 投诉处理可读客户投诉历史，但不能读无关营销偏好 |
| 哪些记忆必须带来源和时间？ | KYC、AML、信贷政策相关记忆必须显示证据锚点 |
| 哪些记忆不能被自动写入？ | 受保护属性、健康状况、推断出的敏感偏好 |
| 哪些记忆只能作为线索，不能作为事实？ | 模型上次总结、客户情绪推断、未复核的调查假设 |
检索质量会直接影响 agent 的人格一致性、业务判断和风险边界。错误记忆比没有记忆更危险，因为用户和员工会误以为系统“知道上下文”。
4. Reflection：从事件到抽象，但抽象不能脱离证据
Reflection 是 Generative Agents 最有启发的部分。系统不是只保存原始事件，而是定期从记忆中总结高层结论，例如关系变化、目标倾向、长期偏好和未来意图。
它解决了一个真实问题：如果每次决策都只读取零散事件，agent 很难形成稳定的“理解”。反思把多个低层事件压缩成可复用抽象。
但企业系统必须非常谨慎。Reflection 生成的是模型推断，不等于事实。
| 反思结果 | 可接受用法 | 不可接受用法 |
|---|---|---|
| “客户多次询问提前还款费用” | 优先展示相关 FAQ 和费用解释 | 断定客户准备违约或流失 |
| “调查员认为该 case 可能涉及 layering” | 作为 typology hypothesis 进入复核 | 自动生成 SAR 结论 |
| “员工常选择手工复核高额交易” | 优化工作台默认排序 | 评估员工绩效 |
| “供应商多次延迟响应接口问题” | 触发供应商管理提醒 | 自动降级供应商评级 |
关键不是要不要 reflection，而是 reflection 是否有证据锚点、置信度、有效期、可撤销机制和人工复核边界。
一个好的 reflection record 应包含：
| 字段 | 目的 |
|---|---|
| Claim | 反思形成的抽象判断 |
| Evidence IDs | 支撑它的原始记忆 |
| Confidence | 模型或规则给出的置信度 |
| Scope | 适用于哪个任务、客户、流程或产品 |
| Expiry | 什么时候必须重新评估 |
| Review status | 是否经过人工确认 |
没有这些字段，reflection 很容易变成“AI 自己编出来的组织记忆”。
5. Planning：计划是状态机，不是漂亮的待办列表
论文中的 planning 让 agent 根据记忆和目标生成行动计划，从而表现出跨时间的连贯行为。
在企业里，planning 的难点不在“生成步骤”，而在把步骤变成可执行、可恢复、可审计的状态机。
一个工作计划至少要区分：
| 层次 | 示例 |
|---|---|
| Goal | 完成 KYC remediation 并让客户通过复核 |
| Milestone | 收集缺失文件、验证 UBO、完成风险评级、通知客户 |
| Action | 发送补件请求、读取证件、调用 sanctions screening、创建审批任务 |
| Guardrail | 高风险客户必须人工复核；客户沟通必须使用批准模板 |
| State | pending / waiting_customer / under_review / escalated / closed |
| Recovery | 工具失败、客户未响应、证据冲突、审批超时 |
如果 planning 只是一次性 prompt 输出，系统无法处理真实业务中的中断、重试、例外和审批。
Generative Agents 给出的启发是：计划要由记忆驱动，而不是孤立生成。但企业架构还必须把计划交给 workflow engine、case management、event log 或 durable execution runtime 管理。
6. 为什么这套机制有效
这篇论文的机制有效，是因为它把“智能行为”拆成了三个可操作能力：
- 持续记录：agent 不依赖一次上下文，而是把观察转成可检索资产。
- 选择性召回：agent 不读取全部历史，而是按当前任务选择相关记忆。
- 抽象与计划：agent 不只是反应，而是形成高层理解和未来行动。
这和人类知识工作有相似结构。一个资深调查员不会记住每个字段，但会记住关键事件、形成案件假设，并规划下一步证据收集。一个成熟客服不会逐字背历史对话，但会抓住客户偏好、产品状态和承诺事项。
企业 AI 的机会，是把这种工作方式产品化。风险是把不稳定的模型推断误认为可靠组织记忆。
7. 和普通 RAG、CRM 记录、工作流系统的区别
Generative Agents 经常被误读为“长期记忆 = RAG”。实际差异更大。
| 能力 | 普通 RAG | CRM / Case 系统 | Generative-Agent-style Memory |
|---|---|---|---|
| 核心对象 | 文档片段 | 业务记录和状态 | 观察、交互、反思、计划 |
| 主要用途 | 回答事实问题 | 管理客户/案件生命周期 | 支持连续行为和情境理解 |
| 更新方式 | 文档索引更新 | 人工或系统写入 | 事件驱动和模型生成 |
| 风险焦点 | 引用错误、召回不足 | 数据质量、权限、流程一致性 | 虚假记忆、推断越权、状态漂移 |
企业系统通常需要三者组合：
- RAG 提供政策、制度、产品和知识来源。
- CRM / case system 提供事实状态和正式记录。
- Agent memory 提供任务上下文、工作假设、计划和人机交互连续性。
架构上必须明确哪一类是 source of record。AI memory 不能替代核心业务系统，也不能把模型生成的反思写成监管事实。
8. 架构落地：把 memory 做成受控子系统
一个可上线的 memory subsystem 可以按下面的边界设计：
Event / Observation
-> Memory Ingestion Policy
-> Memory Classifier
-> Memory Store
- episodic
- semantic
- preference
- decision
- operational state
-> Retrieval Policy
-> Context Builder
-> Model / Agent Runtime
-> Reflection Pipeline
-> Plan / Workflow Runtime
-> Evidence and Audit Log
关键设计不是数据库选型，而是控制面：
| 控制点 | 要回答的问题 |
|---|---|
| Ingestion policy | 什么可以写入记忆，什么必须丢弃或脱敏？ |
| Classification | 这条记忆属于事实、偏好、推断、计划还是状态？ |
| Access control | 当前 user、agent、tool、workflow 是否有权读取？ |
| Retention | 这条记忆保存多久，何时自动过期？ |
| Deletion | 客户撤回同意或记录错误时如何删除和传播？ |
| Evidence | 未来复盘时能否还原这条记忆如何影响输出？ |
| Evaluation | 记忆是否提升质量，还是制造偏差和幻觉？ |
如果这些控制缺失，长期记忆会迅速从“个性化能力”变成合规和安全负债。
9. 金融零售案例：AML Investigation Memory
AML 调查是长期记忆最有价值也最危险的场景之一。
低成熟度做法是把历史 alert、交易摘要和调查员 notes 全部塞进 prompt。短期看似增强上下文，长期会产生三个问题：
- 过期假设持续影响新 case。
- 未复核的 AI 总结被当成事实。
- 不同客户、账户、案件之间的证据边界变模糊。
更合理的设计是把记忆拆成四层：
| 层 | 内容 | 使用方式 |
|---|---|---|
| Case episodic memory | 本案 alert、交易、调查动作、沟通记录 | 作为事实上下文，必须可追溯 |
| Typology hypothesis memory | layering、structuring、mule activity 等假设 | 作为调查线索，必须标记未确认/已确认 |
| Investigator workflow memory | 已检查哪些证据、哪些仍缺失 | 驱动下一步任务 |
| Policy semantic memory | SAR threshold、case closure policy、监管要求 | 通过 RAG 引用当前版本 |
这时 reflection 的作用不是“自动判断可疑”，而是帮助形成和维护调查假设。例如：多次小额入账后快速转出、交易对手集中在高风险地区、账户行为与客户画像不符。每个假设都必须链接到交易证据和人工复核状态。
计划层则负责把调查转成可执行路径：
- 补齐客户画像和账户历史。
- 检索相关 typology 和过去相似 case。
- 生成证据缺口。
- 请求人工确认关键假设。
- 在满足阈值后辅助生成 narrative draft。
- 记录最终决定和理由。
系统价值不是“让 agent 像调查员一样思考”，而是降低上下文切换、减少遗漏、提升假设管理和证据复盘能力。
10. 金融零售案例：客户服务 Preference Memory
客服场景中，长期记忆很容易被包装成“个性化体验”。真正的难点是区分有价值偏好和敏感推断。
可接受的记忆：
- 客户偏好电子账单。
- 客户希望使用简体中文沟通。
- 客户上次投诉的是信用卡年费解释不清。
- 客户已经提交过某份文件，不应重复索要。
高风险或不应自动记忆的内容：
- 模型推断客户有财务困难。
- 从语气推断客户脆弱性。
- 根据投诉内容推断健康、家庭、宗教或受保护属性。
- 把一次争议中的情绪表达作为长期性格标签。
因此客服 memory 的架构要把“便利性”和“用途限制”绑定在一起。偏好记忆只应用于改善交互体验，不能进入营销、信用、风险定价或员工绩效判断，除非有明确同意、合法用途和治理边界。
11. 评价长期记忆是否真的有用
长期记忆不能只靠用户觉得“更懂我”来评价。至少要同时看质量、风险和可运营性。
| 评价维度 | 关键问题 |
|---|---|
| Task quality | 记忆是否减少重复提问、提升下一步建议质量？ |
| Grounding | 输出中使用的记忆是否能追溯到事实来源？ |
| Memory precision | 召回的记忆是否确实与当前任务相关？ |
| Memory harm | 是否引入过期、敏感、错误或未经确认的推断？ |
| Correction | 用户或员工纠正后，错误记忆是否停止影响输出？ |
| Deletion | 删除请求是否能从检索、缓存、摘要和反思中生效？ |
| Drift | 长期积累后，系统是否越来越偏向早期错误假设？ |
如果一个 memory feature 只提升少量便利性，却显著增加隐私、解释和审计负担，应优先降级为短期会话状态或显式用户偏好，而不是长期隐式记忆。
12. 常见误读
| 误读 | 更准确的理解 |
|---|---|
| 长期记忆就是把历史对话存起来 | 记忆需要分类、过滤、权限、保留期和证据链 |
| Reflection 能让 agent 更聪明 | Reflection 只是压缩和抽象，可能制造虚假结论 |
| Agent 自己规划就能自动执行流程 | 计划必须落到状态机、审批、工具权限和恢复机制 |
| 记忆越多体验越好 | 错误或越权记忆会降低信任并制造合规风险 |
| 向量库能解决长期上下文 | 向量检索只是召回层，不能替代 policy 和 source-of-record |
13. 学习验证
读完这篇后，不应该只会复述 memory / reflection / planning，而应该能形成一个可评审的 memory design。
建议做一个 1 页设计稿：
| 模块 | 你需要写清楚的内容 |
|---|---|
| Memory scope | 哪些业务对象需要记忆，哪些禁止记忆 |
| Memory taxonomy | episodic / semantic / preference / decision / operational 如何区分 |
| Write policy | 谁能写入，模型生成内容是否需要复核 |
| Retrieval policy | 当前任务如何选择记忆，如何处理过期和敏感信息 |
| Reflection policy | 哪些反思允许生成，如何链接证据和有效期 |
| Plan execution | 计划如何交给 workflow/case runtime，而不是停留在文本 |
| Eval | 如何证明记忆提升质量，并且没有制造隐私和审计风险 |
真正掌握这篇论文的标志，是能解释为什么“记住用户”这个简单需求背后，其实是 data governance、workflow state、retrieval policy、human oversight 和 audit evidence 的组合问题。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。