惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

小众软件
小众软件
博客园 - Franky
罗磊的独立博客
G
Google Developers Blog
The GitHub Blog
The GitHub Blog
P
Proofpoint News Feed
Recent Announcements
Recent Announcements
V
V2EX
F
Fortinet All Blogs
阮一峰的网络日志
阮一峰的网络日志
Blog — PlanetScale
Blog — PlanetScale
月光博客
月光博客
U
Unit 42
GbyAI
GbyAI
A
About on SuperTechFans
WordPress大学
WordPress大学
Engineering at Meta
Engineering at Meta
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
Martin Fowler
Martin Fowler
D
DataBreaches.Net
The Cloudflare Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
MongoDB | Blog
MongoDB | Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
每天学一点AI知识:Claude code中有关memory(记忆)能力的设计
宇智波冰 · 2026-04-07 · via 人人都是产品经理

Claude的memory能力设计揭示了AI产品如何突破上下文限制的终极解法。从Session Memory的实时会话压缩,到extractMemories的长期知识沉淀,再到teamMemorySync的团队协作同步,这套三层记忆体系正在重新定义人机交互的深度。本文将深入解析每个模块的工程实现与产品逻辑,看顶尖AI如何用结构化记忆打破LLM的遗忘诅咒。

前几天发生了大家都知道的Claude code事件,我们也有机会学习世界顶尖的AI产品的设计。

我选择了LLM短板并且对用户使用影响较大的memory(记忆)能力,进行了学习,收获颇多,也分享给各位。

其中有关记忆的有3个能力,分别是:Session Memory(会话记忆)、teamMemorySync(团队记忆同步)、extractMemories(自动提取长期记忆)。

1、Session Memory(会话记忆)

  • 自动维护一份当前会话的 Markdown 总结/笔记文件(用于续航和后续压缩接续)
  • 按阈值触发更新:达到初始化 token 门槛、且在上次抽取后上下文增长到位(并结合 tool 调用情况判断是否在“自然断点”更新)
  • 更新方式是后台 fork 子 agent去抽取并写回这份会话笔记
  • 安全限制:子 agent 只被允许编辑这一份会话笔记文件路径(避免误改其它文件)
  • 额外支持手动触发:例如命令行 /summary 可以强制抽取

这样的好处是用户与智能体对话超出上下文限制后,下次对话可以通过读取这个markdown文件里的摘要继续进行对话,提升体验,也节省token消耗。

Markdown 会话笔记中内容:

保留「当前在干什么、关键文件/命令、踩过的坑」等高密度信息;

与 自动压缩(auto-compact)能力 配合:笔记里尤其强调 「Current State」要在压缩后仍能接续上下文。

prompt.ts提示词要求写入至会话笔记文件中内容:

# 会话标题 (5-10个词的简短标题,信息密集,不废话)

# 当前状态 现在正在做什么?还没完成的任务。下一步马上要做的事。

# 任务说明 用户让做什么?有哪些设计要求、背景信息。

# 文件与功能 重要文件有哪些?简单说它们是干嘛的、为什么重要。

# 工作流程 通常要运行哪些命令?按什么顺序?命令结果怎么看懂。

# 错误与修正 遇到了什么错误?怎么修好的?用户纠正过什么?哪些方法失败了、不要再试。

# 系统文档 重要的系统组件有哪些?它们怎么配合工作。

# 经验总结 什么有效?什么无效?要避免什么?不重复其他部分内容。

# 关键结果 如果用户要了明确结果(答案、表格、文档),在这里完整写出来。

# 工作记录 一步一步做了什么?每一步极简总结。

文件中函数的作用有:

1)给 AI 一套严格的记笔记规则

不许改标题结构、不许删模板说明、只准在每个标题下面填内容。要写详细:文件、命令、错误、步骤都要记等。

2)自动加载笔记模板

优先使用用户自定义笔记格式,否则使用默认固定格式。

3)检查笔记会不会太长

每一部分不能太长,整体笔记也不能太长,超了就提醒 AI精简。

4)自动替换变量

把 {{笔记路径}} {{当前笔记内容}} 自动换成真实信息,让 AI 直接看懂。

5)判断笔记是不是空的

如果 AI 还没记任何东西,就用老办法处理。

6)笔记太长就自动截断

防止笔记占太多空间,导致 AI 变笨。

2、extractMemories(自动提取长期记忆)。

就像一个“后台整理员”:每次对话快结束时,它会从你这轮聊天里挑出值得长期记住的要点,并且只允许它把结果写进记忆目录(保证不会乱改项目其它文件)。

详细内容:

1)在每次对话“收尾”(一轮完整 query loop 结束)时,从本轮对话内容里抽取可长期保存的信息抽取写入“auto-memory 目录”,形成一种可复用的记忆体系(通常是多文件 + 索引文件)

2)触发策略包括:

  • 跳过重复:如果主 agent 已经直接写了记忆文件,就不会再 fork 抽取
  • 节流:每隔 N 个合格轮次才抽取一次(避免频繁消耗 token)
  • 支持“trailing run”:如果抽取过程中又来了新上下文,会再补做一次尾巴抽取

3)安全限制:子 agent 的工具权限被严格限制

  • 只允许写入 memory 目录内部
  • 其它工具会被 deny,保证写入边界

4)强调不要把敏感信息写进共享团队记忆(这是模板/策略层面的约束)

这样的好处是用户在与智能体对话的过程中,智能体会越来越了解用户,因为它可以从对话中抽“值得长期保存”的要点,逐渐积累维护长期记忆,逐渐提升用户体验。

prompt.ts提示词文件中有

给子 agent 提供两套“写记忆规则”的提示词拼装函数。

  1. 每条记忆写到单独的文件(用 frontmatter 格式)
  2. 用 MEMORY.md 做索引(指向这些文件),MEMORY.md 不是记忆正文
  3. 强调:不要重复、可以更新/删除过期信息

3、teamMemorySync(团队记忆同步)

“全组共享记忆”机制,针对 某个 Git 仓库(一个项目),在本地有一块专门的“团队记忆文件夹”;你(或 Claude)把一些 对整个团队都有用的说明/文档 写进这个文件夹里的文件;这个服务会 自动同步这些文件到云端,你的同事只要在同一个仓库里用 Claude,也能看到/使用这些记忆。

详细内容:

1)把“本地团队 memory 目录里的文件”与服务器上的团队记忆条目做同步

2)同步语义(非常关键):

  • Pull:以服务器为准覆盖本地(server wins)
  • Push:只上传“本地内容和服务器不一致”的增量 delta(依赖每条的 hash/校验和)

3)触发方式:

  • 监听本地团队 memory 目录变化,2 秒 debounce 后自动 push
  • 启动时会先 pull,避免新仓库出现“等不到第一轮写入”的死等待

4)安全策略(另一块很关键):

  • 上传前做密钥扫描:发现疑似 secret 的文件会被跳过、不上传(并且日志只记录规则类型,不泄露 secret 值)
  • 写入时也有 guard:防止模型把敏感内容写入 team memory 共享区域

这样的好处是用户在同一代码仓库中与其它用户合作时,通过共享信息提高合作效率,并且整个过程AI会自动完成,其他同事可以通过team memory文件直接查看共享内容。

本文由@宇智波冰 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unspalsh, 基于CC0协议。