结合工作中的工程实践我的判断是Agent 记忆的第一版不该从“选哪个框架”开始而要先回答什么必须实时查询什么只在当前任务有效什么才值得跨会话保存。这篇文章会给出两套可以直接套用的默认架构Coding Agent 文件优先以仓库和持续集成CI结果为准面向用户的 Agent 以业务系统为准只保存用户明确授权、可修改、可删除的长期偏好。Agent 记忆的两套默认架构先问一个问题你要的是记忆还是上下文向量检索本身没有问题。问题是很多团队还没分清哪些信息该长期保存、哪些必须实时查询就先把全部对话接进了向量库。先把 Agent 运行时需要的信息分成四层Agent 运行时信息的四层优先级图里的 L0 是不能违反的规则L1 是每次都要重新查询的当前事实L2 只保存这次任务的进度L3 才是下次会话还可能用到的信息。我现在只用一个标准判断要不要保留 L3下次任务是否真的会因为这条信息而改变行为。所以这里的“两套”不是对所有 Agent 的分类。一次性 FAQ 可能只需要检索流程型 Agent 往往只要可靠的 L2保存当前表单和工具结果设置 TTL自动过期时间任务完成后清理。先问自己三个问题再决定是否需要长期记忆Agent 是否需要长期记忆的决策树回答完这三个问题很多 Agent 会发现自己只需要实时查询和当前任务状态根本用不上长期记忆。为什么 Coding Agent 和 To C Agent 不能共用一套方案两者的错误成本完全不一样。Coding Agent 的主要风险是拿旧上下文覆盖新代码。仓库每天变分支每天变CI 结果每天变。你让它“记住”太多它反而更容易相信过期经验。To C Agent 的主要风险是把用户隐私、业务真相和临时对话混在一起。用户上次说“我想买儿童座椅”可以成为偏好候选但“订单 123 还没到”不能永久保存成事实因为物流状态明天就变。Coding Agent 以仓库为真相To C Agent 以业务系统为真相长期记忆只能补充上下文不能覆盖当前事实。Coding Agent第一版先用文件不要急着上记忆平台Coding Agent 最值得学习的项目其实是 Claude Code。Claude Code 把CLAUDE.md、auto memory自动记忆和 Hook在工具执行前后触发的脚本分开。规则由人维护放在CLAUDE.md、AGENTS.md或目录规则里。反复出现的经验由 Claude 自动记录或由 Agent 提候选后写入可审阅的 learnings经验文件。高风险动作不靠记忆提醒而是交给PreToolUseHook工具执行前的拦截脚本、权限、审批和沙箱直接阻断。3.1 规则要像代码一样管理如果用 Claude Code 从零搭一个 Coding Agent优先沿用它原生识别的文件再补充跨工具的任务与经验目录。如果项目已经有AGENTS.md不要再把同一套规则复制到CLAUDE.md。Claude Code 直接读取CLAUDE.md可以在里面通过AGENTS.md导入共享规则不需要 Claude 专属内容时也可以把CLAUDE.md软链接到AGENTS.md。.claude/rules/用来放 Claude Code 的路径作用域规则.claude/settings.json才是配置权限和 Hooks 的地方。这里的.agent/task/和.agent/learnings/是本文为了跨工具管理任务状态与团队经验采用的目录约定。Claude Code 不会因为目录叫.agent/就自动加载它们。要让 Agent 使用这些内容需要在工作流或入口规则里明确要求它读写。目录结构如下.├── AGENTS.md # 可选多个 Coding Agent 共享的规则只维护这一份├── CLAUDE.md # Claude Code 入口可通过 AGENTS.md 导入共享规则├── .claude/│ ├── rules/│ │ └── payment.md # Claude Code 原生的路径作用域规则│ └── settings.json # permissions、Hooks 等强制控制└── .agent/ ├── task/ │ └── current.md # 当前任务状态完成后清理 └── learnings/ └── payment.md # 经验证、可编辑的项目经验维护边界不用复杂化规则、.claude/rules/和.claude/settings.json由人维护并进入版本控制当前任务状态可以由 Agent 更新任务结束后清理或归档learnings 由 Agent 提候选人确认后长期保留。只要一条经验会影响 Agent 行为它就应该能审阅、能回滚。规则文件不要写散文只写模型能执行的约束。例如.claude/rules/payment.md---paths: - services/payment/**---## services/payment 修改规则- 修改 PaymentService 后必须运行 ./mvnw -pl services/payment test- 不能直接改 payment.proto兼容性变更先更新 api-contract.md- 集成测试依赖 mock-bank本地命令是 make mock-bank- 任何涉及退款状态机的改动必须检查 RefundStateTest规则文件里我只留会改变动作的内容模型反复犯的高代价错误、新同学也不能漏掉的工程约束以及会改变工具或验证路径的信息。“这个模块重构过三次”通常没用“集成测试不能用单测替代”值得写。3.2 每次任务都先读现在再读过去每次开始任务Agent 都要重新看现场先加载规则和 Hook再读git status、git diff、相关代码、构建脚本和测试结果最后才轮到 task state 与 learnings。如果 learnings 还写着 npm但仓库已经出现pnpm-lock.yaml问题就不是检索不准而是读错了顺序。所以执行顺序要直接写进规则执行任何代码任务时先区分两件事1. 强制约束 组织规则、项目规则、目录规则、Hook、权限限制优先级最高。 如果规则禁止某个动作不允许因为仓库现状或历史经验而绕过。2. 事实判断 当前仓库文件、git diff、构建脚本、测试结果优先级最高 当前任务状态和用户本轮要求次之 learnings 只能作为线索不能覆盖当前事实。如果 learnings 与当前仓库文件、构建脚本、测试结果冲突以当前仓库和工具返回值为准并把冲突记录为待清理记忆。3.3 什么东西可以进入 Coding Agent 的长期记忆Coding Agent 的 L3 应该设置很高门槛。能进 learnings 的信息一般要满足两个条件之一同类纠正出现过两次以上开发者明确说“记住这个”。而且每条都要带作用域、来源和最后验证时间---scope: services/payment/**source: PR-1842verified_at: 2026-07-12owner: payment-team---运行集成测试前必须启动 mock-bank单测通过不代表支付合约通过。作用域和验证时间是为了防止把经验用错地方支付模块的经验不能跑到搜索模块Java 服务的习惯也不能套到前端目录。下面这些东西不要保存源码快照变化太快每次实时读仓库。CI 当前状态下一次就会变运行时查询 CI。排查问题时没有验证的中间猜测只留在当前任务状态。密钥、账号、内部地址回到密钥系统或配置中心不能进记忆。“用户喜欢怎么写代码”这类宽泛偏好容易覆盖项目规范只能作为低优先级的用户偏好。3.4 Coding Agent 什么时候才需要升级文件方案不够用时我会看系统缺哪种能力再补对应组件而不是直接换成“记忆平台”找不到架构决策记录ADR、Issue 和故障背景就加带来源的文档检索源码仍然实时读。多个 Agent 要接力同一需求就加共享任务状态和事件日志不要共享一个大而全的“团队记忆”。规则太长时拆成路径规则和按需 Skill反复出现的已验证经验再进入可审阅 learnings。跨会话任务需要的是 checkpoint可恢复的任务进度不是用户画像。两者放进同一个库迟早会互相污染。To C Agent可以记用户但不要让记忆接管业务To C Agent 需要跨会话连续性却也最容易把记忆做坏。把所有聊天历史按相似度召回会把用户偏好、业务事实、临时抱怨和过期状态混在一起。一个售后 Agent 如果从历史对话里召回“用户说包裹没收到”然后直接回答“你的包裹仍未送达”这就是事故。它必须查物流系统。所以处理顺序要固定安全和产品规则由策略系统发布订单、账户等当前状态实时查询session当前会话状态只保存这次任务的进度用户记忆只保留可修改、可删除的跨会话偏好。4.1 看 mem0 的add()写什么记到谁名下我沿着 mem0 的Memory.add()看了一遍。当前 V3 的默认流程可以概括成三步从对话中抽取事实、跳过重复内容、写入新记录。它不会自动判断“新事实是否应该覆盖旧事实”修改和删除需要单独处理。这意味着 mem0 可以帮你抽取和保存记忆但新旧事实冲突时听谁的仍然要由业务规则决定。写入前还要确定这条记忆属于某个用户、某个 Agent还是某次任务。拿旅行 Agent 举例这次东京行程计划只属于当前任务“喜欢安静酒店”才可能作为用户长期偏好。公司差旅政策仍从策略系统读取实时航班价格和酒店库存则直接查供应商接口。把这些数据混进同一个召回范围命中率再高也没用。4.2 明确指令直接进入写入流程自动推断先做候选写入门槛取决于来源。用户明确说“以后用中文回答”“记住我不吃花生”可以直接进入受控写入流程。模型从闲聊推断“用户可能偏好高端酒店”只能先进入候选区。当前工单进度属于 session不能直接写入用户记忆。模型自动推断的信息适合在对话结束后异步生成候选再经过规则过滤、冲突检查和必要的用户确认。候选记录至少要包含这些字段{ subject: user_42, kind: communication_preference, value: 优先中文回答尽量简洁, source: conversation/c_991/message_14, confidence: 0.92, scope: all_agents, expires_at: null, status: candidate}写入前我只核对几件硬事下次会话是否还会用到用户是否授权和旧记录冲突时怎么办多久过期、谁能删。任何一项说不清就继续留在候选区。To C 记忆最怕的不是漏记而是错记。漏记只是体验普通错记可能造成冒犯、越界甚至业务损失。4.3 每次只读和意图相关的少量记忆读取也不是越多越好。先判断这次需要的是用户偏好、Agent 规则还是当前任务信息再过滤已经过期、模型不太确定或者已经被新记录替换的内容只把少量相关结果交给模型。订单、账户和库存仍然实时查询。Mem0 主体选择与作用域隔离4.4 有些内容不是按需检索而是每次都要看到Mem0 处理的是“需要时查出哪些事实”Letta 处理的是另一件事哪些内容要一直留在上下文窗口里。Letta 把这类常驻内容叫作 Block它不是每次检索后临时塞进去的结果。Letta Memory Blocks 的运行机制Block 可以受控更新也能保留历史版本。但它的代价很直接常驻内容越多留给当前任务的上下文就越少。在 To C 场景里我会把规则和品牌口径设成只读块只把少量、每次都需要的用户偏好放进可更新块。会话状态不放这里——上下文窗口不是数据库常驻内容多一行留给当前任务的空间就少一行。4.5 To C Agent 什么时候升级到图Graphiti 写入的不只是一句话还会记录这件事的来源和发生时间。新信息与旧关系冲突时它可以让旧关系失效同时保留这段变化历史。时序图记忆的实现架构读取时它不只看文字是否相似也会利用实体之间的关系。至于要不要使用时序图我的标准很窄关系本身会变而且产品真的要回答“当时是什么、依据来自哪里”。销售 Agent 要追踪联系人、公司、商机和合同之间的变化可能用得上医疗或保险需要保留历史版本也有理由使用时序图。只是保存“用户喜欢中文回答”一张带版本和过期时间的事实表就够了。我不会把 Graphiti 放进默认第一版。大多数 To C Agent 做好 session、用户事实表、授权和删除已经能解决主要问题。等关系查询和历史时点真的出现再升级不迟。mem0、Letta、Graphiti最终到底怎么选这几个项目解决的不是同一层问题应该按系统缺少的能力来选。mem0、Letta、Graphiti 的选型矩阵多数团队的第一版都应该自己保管业务数据明确哪些信息允许写入记忆再按缺口补组件只做偏好抽取与检索用事实表或 mem0需要 Agent 自己维护核心状态再评估 Letta没有复杂关系和历史时点查询就不要上 Graphiti。选定之后第一版怎么落地前面讲的是取舍。真正开工时我会把第一版收敛成下面两张图。6.1 Coding Agent不建记忆库先用仓库文件Coding Agent 的第一版不需要专门的记忆数据库。规则、任务状态和经过审阅的经验都放在文件里仓库、测试和 CI 每次重新读取。Coding Agent 第一版的目录与运行流程.agent/task/current.md只记录当前任务完成后清理或归档.agent/learnings/只接收经过确认的经验。源码快照和 CI 状态不写进去避免 Agent 同时看到新旧两个版本。6.2 To C Agent业务数据、session 和用户记忆分开存我的默认值是用户记忆以 MySQL 或 PostgreSQL 事实表作为主存储session 放在带 TTL 的 Redis 或临时表里订单、账户和库存继续查业务系统。向量索引只负责模糊查找不是最终依据。To C Agent 第一版的存储与读写流程用户删除记忆时先删事实表再同步删除向量索引和缓存。这样即使后面接入 mem0主数据、当前任务和检索索引也不会混成一个库。6.3 上线后怎么知道记忆真的有用架构选型完后最容易漏的是验证。“存了多少条、召回多少次”甚至可能说明污染更严重。我会先固定一组高风险样例每次调整抽取或检索都重跑。具体可以参考下图Agent 记忆的生产验证流水线线上还要留完整的记忆处理记录memory trace至少能还原候选记忆、写入决定、召回与过滤结果、最终交给模型的内容以及业务 API 的返回值。出了错以后团队才能分清是写错、找错还是旧记忆压过了当前事实。写第一行记忆代码前我更建议先写一份“记忆合同”。它不讨论模型有多聪明只写清信息从哪来、谁能改、怎么过期、怎样删除和怎么回退。上线前必须写清的 Agent 记忆合同先守住当前事实的来源再看系统真正缺的是事实抽取、常驻上下文还是关系与时间查询。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
结合工作中的工程实践我的判断是Agent 记忆的第一版不该从“选哪个框架”开始而要先回答什么必须实时查询什么只在当前任务有效什么才值得跨会话保存。这篇文章会给出两套可以直接套用的默认架构Coding Agent 文件优先以仓库和持续集成CI结果为准面向用户的 Agent 以业务系统为准只保存用户明确授权、可修改、可删除的长期偏好。Agent 记忆的两套默认架构先问一个问题你要的是记忆还是上下文向量检索本身没有问题。问题是很多团队还没分清哪些信息该长期保存、哪些必须实时查询就先把全部对话接进了向量库。先把 Agent 运行时需要的信息分成四层Agent 运行时信息的四层优先级图里的 L0 是不能违反的规则L1 是每次都要重新查询的当前事实L2 只保存这次任务的进度L3 才是下次会话还可能用到的信息。我现在只用一个标准判断要不要保留 L3下次任务是否真的会因为这条信息而改变行为。所以这里的“两套”不是对所有 Agent 的分类。一次性 FAQ 可能只需要检索流程型 Agent 往往只要可靠的 L2保存当前表单和工具结果设置 TTL自动过期时间任务完成后清理。先问自己三个问题再决定是否需要长期记忆Agent 是否需要长期记忆的决策树回答完这三个问题很多 Agent 会发现自己只需要实时查询和当前任务状态根本用不上长期记忆。为什么 Coding Agent 和 To C Agent 不能共用一套方案两者的错误成本完全不一样。Coding Agent 的主要风险是拿旧上下文覆盖新代码。仓库每天变分支每天变CI 结果每天变。你让它“记住”太多它反而更容易相信过期经验。To C Agent 的主要风险是把用户隐私、业务真相和临时对话混在一起。用户上次说“我想买儿童座椅”可以成为偏好候选但“订单 123 还没到”不能永久保存成事实因为物流状态明天就变。Coding Agent 以仓库为真相To C Agent 以业务系统为真相长期记忆只能补充上下文不能覆盖当前事实。Coding Agent第一版先用文件不要急着上记忆平台Coding Agent 最值得学习的项目其实是 Claude Code。Claude Code 把CLAUDE.md、auto memory自动记忆和 Hook在工具执行前后触发的脚本分开。规则由人维护放在CLAUDE.md、AGENTS.md或目录规则里。反复出现的经验由 Claude 自动记录或由 Agent 提候选后写入可审阅的 learnings经验文件。高风险动作不靠记忆提醒而是交给PreToolUseHook工具执行前的拦截脚本、权限、审批和沙箱直接阻断。3.1 规则要像代码一样管理如果用 Claude Code 从零搭一个 Coding Agent优先沿用它原生识别的文件再补充跨工具的任务与经验目录。如果项目已经有AGENTS.md不要再把同一套规则复制到CLAUDE.md。Claude Code 直接读取CLAUDE.md可以在里面通过AGENTS.md导入共享规则不需要 Claude 专属内容时也可以把CLAUDE.md软链接到AGENTS.md。.claude/rules/用来放 Claude Code 的路径作用域规则.claude/settings.json才是配置权限和 Hooks 的地方。这里的.agent/task/和.agent/learnings/是本文为了跨工具管理任务状态与团队经验采用的目录约定。Claude Code 不会因为目录叫.agent/就自动加载它们。要让 Agent 使用这些内容需要在工作流或入口规则里明确要求它读写。目录结构如下.├── AGENTS.md # 可选多个 Coding Agent 共享的规则只维护这一份├── CLAUDE.md # Claude Code 入口可通过 AGENTS.md 导入共享规则├── .claude/│ ├── rules/│ │ └── payment.md # Claude Code 原生的路径作用域规则│ └── settings.json # permissions、Hooks 等强制控制└── .agent/ ├── task/ │ └── current.md # 当前任务状态完成后清理 └── learnings/ └── payment.md # 经验证、可编辑的项目经验维护边界不用复杂化规则、.claude/rules/和.claude/settings.json由人维护并进入版本控制当前任务状态可以由 Agent 更新任务结束后清理或归档learnings 由 Agent 提候选人确认后长期保留。只要一条经验会影响 Agent 行为它就应该能审阅、能回滚。规则文件不要写散文只写模型能执行的约束。例如.claude/rules/payment.md---paths: - services/payment/**---## services/payment 修改规则- 修改 PaymentService 后必须运行 ./mvnw -pl services/payment test- 不能直接改 payment.proto兼容性变更先更新 api-contract.md- 集成测试依赖 mock-bank本地命令是 make mock-bank- 任何涉及退款状态机的改动必须检查 RefundStateTest规则文件里我只留会改变动作的内容模型反复犯的高代价错误、新同学也不能漏掉的工程约束以及会改变工具或验证路径的信息。“这个模块重构过三次”通常没用“集成测试不能用单测替代”值得写。3.2 每次任务都先读现在再读过去每次开始任务Agent 都要重新看现场先加载规则和 Hook再读git status、git diff、相关代码、构建脚本和测试结果最后才轮到 task state 与 learnings。如果 learnings 还写着 npm但仓库已经出现pnpm-lock.yaml问题就不是检索不准而是读错了顺序。所以执行顺序要直接写进规则执行任何代码任务时先区分两件事1. 强制约束 组织规则、项目规则、目录规则、Hook、权限限制优先级最高。 如果规则禁止某个动作不允许因为仓库现状或历史经验而绕过。2. 事实判断 当前仓库文件、git diff、构建脚本、测试结果优先级最高 当前任务状态和用户本轮要求次之 learnings 只能作为线索不能覆盖当前事实。如果 learnings 与当前仓库文件、构建脚本、测试结果冲突以当前仓库和工具返回值为准并把冲突记录为待清理记忆。3.3 什么东西可以进入 Coding Agent 的长期记忆Coding Agent 的 L3 应该设置很高门槛。能进 learnings 的信息一般要满足两个条件之一同类纠正出现过两次以上开发者明确说“记住这个”。而且每条都要带作用域、来源和最后验证时间---scope: services/payment/**source: PR-1842verified_at: 2026-07-12owner: payment-team---运行集成测试前必须启动 mock-bank单测通过不代表支付合约通过。作用域和验证时间是为了防止把经验用错地方支付模块的经验不能跑到搜索模块Java 服务的习惯也不能套到前端目录。下面这些东西不要保存源码快照变化太快每次实时读仓库。CI 当前状态下一次就会变运行时查询 CI。排查问题时没有验证的中间猜测只留在当前任务状态。密钥、账号、内部地址回到密钥系统或配置中心不能进记忆。“用户喜欢怎么写代码”这类宽泛偏好容易覆盖项目规范只能作为低优先级的用户偏好。3.4 Coding Agent 什么时候才需要升级文件方案不够用时我会看系统缺哪种能力再补对应组件而不是直接换成“记忆平台”找不到架构决策记录ADR、Issue 和故障背景就加带来源的文档检索源码仍然实时读。多个 Agent 要接力同一需求就加共享任务状态和事件日志不要共享一个大而全的“团队记忆”。规则太长时拆成路径规则和按需 Skill反复出现的已验证经验再进入可审阅 learnings。跨会话任务需要的是 checkpoint可恢复的任务进度不是用户画像。两者放进同一个库迟早会互相污染。To C Agent可以记用户但不要让记忆接管业务To C Agent 需要跨会话连续性却也最容易把记忆做坏。把所有聊天历史按相似度召回会把用户偏好、业务事实、临时抱怨和过期状态混在一起。一个售后 Agent 如果从历史对话里召回“用户说包裹没收到”然后直接回答“你的包裹仍未送达”这就是事故。它必须查物流系统。所以处理顺序要固定安全和产品规则由策略系统发布订单、账户等当前状态实时查询session当前会话状态只保存这次任务的进度用户记忆只保留可修改、可删除的跨会话偏好。4.1 看 mem0 的add()写什么记到谁名下我沿着 mem0 的Memory.add()看了一遍。当前 V3 的默认流程可以概括成三步从对话中抽取事实、跳过重复内容、写入新记录。它不会自动判断“新事实是否应该覆盖旧事实”修改和删除需要单独处理。这意味着 mem0 可以帮你抽取和保存记忆但新旧事实冲突时听谁的仍然要由业务规则决定。写入前还要确定这条记忆属于某个用户、某个 Agent还是某次任务。拿旅行 Agent 举例这次东京行程计划只属于当前任务“喜欢安静酒店”才可能作为用户长期偏好。公司差旅政策仍从策略系统读取实时航班价格和酒店库存则直接查供应商接口。把这些数据混进同一个召回范围命中率再高也没用。4.2 明确指令直接进入写入流程自动推断先做候选写入门槛取决于来源。用户明确说“以后用中文回答”“记住我不吃花生”可以直接进入受控写入流程。模型从闲聊推断“用户可能偏好高端酒店”只能先进入候选区。当前工单进度属于 session不能直接写入用户记忆。模型自动推断的信息适合在对话结束后异步生成候选再经过规则过滤、冲突检查和必要的用户确认。候选记录至少要包含这些字段{ subject: user_42, kind: communication_preference, value: 优先中文回答尽量简洁, source: conversation/c_991/message_14, confidence: 0.92, scope: all_agents, expires_at: null, status: candidate}写入前我只核对几件硬事下次会话是否还会用到用户是否授权和旧记录冲突时怎么办多久过期、谁能删。任何一项说不清就继续留在候选区。To C 记忆最怕的不是漏记而是错记。漏记只是体验普通错记可能造成冒犯、越界甚至业务损失。4.3 每次只读和意图相关的少量记忆读取也不是越多越好。先判断这次需要的是用户偏好、Agent 规则还是当前任务信息再过滤已经过期、模型不太确定或者已经被新记录替换的内容只把少量相关结果交给模型。订单、账户和库存仍然实时查询。Mem0 主体选择与作用域隔离4.4 有些内容不是按需检索而是每次都要看到Mem0 处理的是“需要时查出哪些事实”Letta 处理的是另一件事哪些内容要一直留在上下文窗口里。Letta 把这类常驻内容叫作 Block它不是每次检索后临时塞进去的结果。Letta Memory Blocks 的运行机制Block 可以受控更新也能保留历史版本。但它的代价很直接常驻内容越多留给当前任务的上下文就越少。在 To C 场景里我会把规则和品牌口径设成只读块只把少量、每次都需要的用户偏好放进可更新块。会话状态不放这里——上下文窗口不是数据库常驻内容多一行留给当前任务的空间就少一行。4.5 To C Agent 什么时候升级到图Graphiti 写入的不只是一句话还会记录这件事的来源和发生时间。新信息与旧关系冲突时它可以让旧关系失效同时保留这段变化历史。时序图记忆的实现架构读取时它不只看文字是否相似也会利用实体之间的关系。至于要不要使用时序图我的标准很窄关系本身会变而且产品真的要回答“当时是什么、依据来自哪里”。销售 Agent 要追踪联系人、公司、商机和合同之间的变化可能用得上医疗或保险需要保留历史版本也有理由使用时序图。只是保存“用户喜欢中文回答”一张带版本和过期时间的事实表就够了。我不会把 Graphiti 放进默认第一版。大多数 To C Agent 做好 session、用户事实表、授权和删除已经能解决主要问题。等关系查询和历史时点真的出现再升级不迟。mem0、Letta、Graphiti最终到底怎么选这几个项目解决的不是同一层问题应该按系统缺少的能力来选。mem0、Letta、Graphiti 的选型矩阵多数团队的第一版都应该自己保管业务数据明确哪些信息允许写入记忆再按缺口补组件只做偏好抽取与检索用事实表或 mem0需要 Agent 自己维护核心状态再评估 Letta没有复杂关系和历史时点查询就不要上 Graphiti。选定之后第一版怎么落地前面讲的是取舍。真正开工时我会把第一版收敛成下面两张图。6.1 Coding Agent不建记忆库先用仓库文件Coding Agent 的第一版不需要专门的记忆数据库。规则、任务状态和经过审阅的经验都放在文件里仓库、测试和 CI 每次重新读取。Coding Agent 第一版的目录与运行流程.agent/task/current.md只记录当前任务完成后清理或归档.agent/learnings/只接收经过确认的经验。源码快照和 CI 状态不写进去避免 Agent 同时看到新旧两个版本。6.2 To C Agent业务数据、session 和用户记忆分开存我的默认值是用户记忆以 MySQL 或 PostgreSQL 事实表作为主存储session 放在带 TTL 的 Redis 或临时表里订单、账户和库存继续查业务系统。向量索引只负责模糊查找不是最终依据。To C Agent 第一版的存储与读写流程用户删除记忆时先删事实表再同步删除向量索引和缓存。这样即使后面接入 mem0主数据、当前任务和检索索引也不会混成一个库。6.3 上线后怎么知道记忆真的有用架构选型完后最容易漏的是验证。“存了多少条、召回多少次”甚至可能说明污染更严重。我会先固定一组高风险样例每次调整抽取或检索都重跑。具体可以参考下图Agent 记忆的生产验证流水线线上还要留完整的记忆处理记录memory trace至少能还原候选记忆、写入决定、召回与过滤结果、最终交给模型的内容以及业务 API 的返回值。出了错以后团队才能分清是写错、找错还是旧记忆压过了当前事实。写第一行记忆代码前我更建议先写一份“记忆合同”。它不讨论模型有多聪明只写清信息从哪来、谁能改、怎么过期、怎样删除和怎么回退。上线前必须写清的 Agent 记忆合同先守住当前事实的来源再看系统真正缺的是事实抽取、常驻上下文还是关系与时间查询。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
)
