你的AI智能体根本不需要向量数据库,除非满足这三种情况

源自190位全网作者

04-16 11:43

精选参考来源

1
姚顺雨在腾讯首个研究:在“上下文”这事上,在座的各位都不及格
2
memsearch:OpenClaw同源的记忆系统Zilliz 最近开源了 memsearch,从 OpenClaw 的记忆系统里提取出来的,核心思路很干净:Markdown 文件就是记忆的唯一真相。设计理念:Markdown is the source of truthAgent 的记忆就是本地文件,按天存,人能读、能改、Git 可以管理版本。索引坏了?删掉重建,原始记忆一行不丢。这是对"数据库黑盒"方案的直接反叛。三步记忆范式- Recall:用混合检索(向量语义 + BM25 关键词)从历史记忆里找相关上下文- Think:把检索结果注入 LLM,做有记忆支撑的推理- Remember:把这次对话写回 Markdown,自动重新索引几个工程细节值得关注- SHA-256 内容哈希去重:内容没变就不重复 embed,大幅降低 API 成本- 文件监听自动索引: 开启后,文件一保存立刻更新向量库,删文件时对应 chunk 也同步清除- 多 embedding 引擎:支持 Gemini、Voyage AI、Ollama(本地)、sentence-transformers(离线),换引擎只改配置,历史记忆不影响和 Mem0 / Zep 的本质区别Mem0、Zep 把记忆存在数据库里,人看不到、改不了、换供应商就麻烦。memsearch 的记忆就是普通文本文件: 看改动, 查历史,跨机器 同步,零供应商锁定。主要短板:暂不支持时序关系图谱和多 Agent 共享记忆,适合单 Agent 长期记忆场景,不适合复杂多 Agent 协作系统。🔑 三个关键点① Markdown 文件即记忆,人类可读可编辑,彻底解决 AI 记忆的"黑盒"问题② 混合检索(向量 + BM25)比单纯语义检索精度更高,"Redis 缓存"能精确匹配到相关决策③ SHA-256 去重 + 文件监听自动索引,工程上几乎是零维护成本GitHub:github.com/zilliztech/memsearch#how i ai##程序员#
全部
来源
内容由AI生成

精选参考来源

1. 姚顺雨在腾讯首个研究:在“上下文”这事上,在座的各位都不及格

2. memsearch:OpenClaw同源的记忆系统Zilliz 最近开源了 memsearch,从 OpenClaw 的记忆系统里提取出来的,核心思路很干净:Markdown 文件就是记忆的唯一真相。设计理念:Markdown is the source of truthAgent 的记忆就是本地文件,按天存,人能读、能改、Git 可以管理版本。索引坏了?删掉重建,原始记忆一行不丢。这是对"数据库黑盒"方案的直接反叛。三步记忆范式- Recall:用混合检索(向量语义 + BM25 关键词)从历史记忆里找相关上下文- Think:把检索结果注入 LLM,做有记忆支撑的推理- Remember:把这次对话写回 Markdown,自动重新索引几个工程细节值得关注- SHA-256 内容哈希去重:内容没变就不重复 embed,大幅降低 API 成本- 文件监听自动索引: 开启后,文件一保存立刻更新向量库,删文件时对应 chunk 也同步清除- 多 embedding 引擎:支持 Gemini、Voyage AI、Ollama(本地)、sentence-transformers(离线),换引擎只改配置,历史记忆不影响和 Mem0 / Zep 的本质区别Mem0、Zep 把记忆存在数据库里,人看不到、改不了、换供应商就麻烦。memsearch 的记忆就是普通文本文件: 看改动, 查历史,跨机器 同步,零供应商锁定。主要短板:暂不支持时序关系图谱和多 Agent 共享记忆,适合单 Agent 长期记忆场景,不适合复杂多 Agent 协作系统。🔑 三个关键点① Markdown 文件即记忆,人类可读可编辑,彻底解决 AI 记忆的"黑盒"问题② 混合检索(向量 + BM25)比单纯语义检索精度更高,"Redis 缓存"能精确匹配到相关决策③ SHA-256 去重 + 文件监听自动索引,工程上几乎是零维护成本GitHub:github.com/zilliztech/memsearch#how i ai##程序员#

3. Agent 真正的护城河,正在从工具转向记忆资产

4. LangSmith 如何构建 Agent Builder 的记忆系统

5. 养虾省91%词元!这家AI记忆公司用1亿个多模态文件验证了!

6. Claude Code自动记忆来了!配合老金三层记忆系统全开源!加强Plus!

7. OpenViking:一个非常实用的开源项目,专为AI Agent设计的上下文数据库,通过创新的“文件系统范式”统一管理Agent所需的记忆、资源和技能,彻底解决了传统向量数据库碎片化、检索效果差、上下文不可见的问题。主要亮点包括:- 文件系统管理范式,实现统一结构化管理,轻松浏览和操作上下文,像管理本地文件一样简单- L0/L1/L2三层上下文分级加载,按需调用,大幅降低Token消耗- 目录递归检索策略,结合目录位置和语义搜索,实现更精准、更全局的上下文获取- 可视化检索轨迹,完整呈现检索过程,方便调试和优化- 会话自动管理,自动提取长期记忆,Agent能“用得越久越聪明”支持Python包安装,也有Rust CLI工具;支持多家主流模型提供商,包含Volcengine、OpenAI、Anthropic、本地vLLM等等;同时提供详尽配置示例,轻松上手。新手快速开始示例脚本也非常简洁,几行代码即可增加资源、浏览文件结构、等待语义处理、抽取摘要、执行语义搜索,非常适合开发者验证和应用。同时官方推荐在云服务器(推荐Volcengine ECS + veLinux)环境中部署,保证稳定性和性能。如果你正打造智能Agent或者想优化上下文管理,强烈建议一试OpenViking,这个项目将让上下文管理和检索变得前所未有的清晰、高效、智能。GitHub地址:github.com/volcengine/OpenViking 官网:www.openviking.ai 文档:www.openviking.ai/docs

8. 从架构到代码:深入理解 OpenClaw 的双源记忆系统网页链接"使用完 OpenClaw 之后我最大的疑问是:一个 Agent 同时活跃在 Telegram、Slack、企微甚至本地 CLI 里,它是怎么“记住我是谁”的?这些记忆又是如何做到统一的?难道我一晚上花掉几十刀的 token 全都是因为他的上下文工程做的太烂?更关键的是——它到底“记住”的是什么?是对话?是总结?还是被结构化后的知识?"文章重点讨论了 OpenClaw 的记忆机制:----Agent 如何在多平台同时识别用户身份,并统一管理记忆。----记忆的内容可能包括对话、总结或结构化知识。----系统通过向量化和余弦相似度搜索,使压缩后的信息仍可检索。#How I AI#

9. 向量数据库到底是怎么工作的?一、基础:向量嵌入(Vector Embeddings)首先,你的数据(无论是文本、图像还是音频)都会被转换成向量嵌入——也就是一组数字数组,用来表示内容的语义含义。可以把它想象成高维空间中的坐标点:含义相似的内容会聚集在一起,形成语义上的“簇”。二、挑战:规模(Scale)真正的难点在这里。如果你有上百万个向量,想找到与某个向量最相似的对象,逐个比较是不现实的——那会耗费巨大的时间。这就是**向量索引(Vector Indexing)**登场的地方。三、向量索引向量索引的作用是组织和优化这些嵌入,让相似向量可以被高效检索。本质上,它在搜索速度、准确率和资源占用三者之间寻找平衡。最常用的一种算法是 HNSW(Hierarchical Navigable Small World)。它会建立一个图结构,把相似的向量节点连接起来。当你查询时,系统就能在图中快速“跳跃”,找到与你的查询向量相似的那些节点。四、搜索过程当你在向量数据库中发出查询时,系统会经历以下步骤:1. 将查询内容转换为向量嵌入;2. 使用距离度量(如余弦相似度)来判断各向量之间的“接近程度”;3. 借助索引结构,快速定位最相似的向量;4. 返回最相关的结果,而不必遍历所有向量。五、权衡取舍不同的索引策略会有不同的取舍:有的更注重速度,但牺牲部分精确度(称为“近似最近邻”搜索);有的追求完全准确,但耗时更长。六、总结令人着迷的是,这种“把语义表示为数字、再去寻找相似数字”的简单思想,支撑了如今的语义搜索、RAG 检索增强生成系统、推荐引擎等各种智能应用。#人工智能##程序员#

10. 构建真正有效智能体,90%靠的是“记忆”,而非模型本身、框架或MCP。关键在于智能体对以下内容的理解和记忆:- 自身能力范围 - 目标与需求 - 过去失败经验 这段“上下文”决定了智能体是像六岁小孩般无知,还是像严谨工程师般高效。核心是“领域记忆”——既包含专业化知识,也包含任务专属的长期记忆。这不是简单的会话记忆,而是对未来至关重要的关键洞察的持续保存。可以称之为“工作流记忆”,它虽设置不复杂,但设计精妙且价值巨大。即便内部已有智能体架构,实现持久记忆也不难,且无需依赖外部API(当然也有选择)。让智能体把最终回答摘要存入持久存储,下次运行时回顾过去决策,大大提升了连续性与理性表现。失败尝试的历史比成功经验更宝贵,避免重复踩坑,节省时间和计算资源。通过保存失败日志,课减少70%的重复错误,证明记忆架构是生产级智能体的核心,而非模型升级的噱头。将记忆细分为“动态工作流记忆”(从失败中学习)和“静态目标记忆”(明确要求与验收标准),结合使用能让智能体拥有既稳固又灵活的执行力。记忆提供连续性,但“控制”才是智能体真正的主动性源泉。只有当系统能自主调节自身动态,才能实现真正的“代理行为”,而非被动反应。记忆塑造认知,控制塑造行为,两者合力才能造就真正有自主决策能力的智能体。产品角度看,模型是天花板,记忆系统是地板。没有强大且专注的长期记忆,再好的模型也难以落地应用。当大家热衷于追求更聪明的模型时,真正提升智能体智商的,是持续不断的记忆和上下文管理。只有打好记忆基础,智能体才能从随机猜测进化为可靠执行者,实现真正的智能与成长。x.com/Hesamation/status/1999255592242737658

11. 免费电子书《The Context Engineering Guide》Context Engineering(上下文工程)远非简单往提示词里堆数据,而是设计智能系统,在恰当时间、用合适格式,动态提供精准信息。关键不在于单纯扩大模型上下文窗口,而是如何高效利用有限的“活跃上下文”。真正的挑战是“编排”——让系统内部各模块(提示设计、检索增强、代理协作、记忆管理等)无缝协作,抵御人类和模型本身的错误。只有这样,AI系统才能突破模型固有限制,变得稳健且实用。这就是为什么Context Engineering将成为AI应用开发的核心复杂性。你需要让系统智能决定:- 什么信息放入活跃上下文- 何时总结压缩节省空间- 什么内容外部存储并按需调取- 如何精准路由查询到合适工具- 代理之间如何协同完成专业任务Victoria团队发布了完整电子书,详解如何构建这样的高效系统:从代理(Agents)、记忆系统(Memory Systems)、查询增强(Query Augmentation)、检索策略(Retrieval)到工具调用与提示循环(Tools & Prompting)。书中包含实战案例和架构图,直击从模型到生产级应用的瓶颈。业内反馈一致认为,单纯扩大上下文窗口是“懒办法”,真正难点在于设计类似人类记忆的动态、分层记忆系统。Context Engineering是连接理论与落地的桥梁,是AI技术走向成熟的必由之路。这不仅是技术细节,更是AI系统设计的艺术和哲学。掌握它,才能构建出既聪明又稳健的智能应用。电子书下载(含架构详解与实操指南):weaviate.io/ebooks/the-context-engineering-guide——思考:信息的力量不在于量多,而在于何时何地以何种方式被激活。未来AI的竞争,不是单纯模型大小,而是对“上下文生命线”的精妙编排。设计智能系统,就是设计未来人与机器共舞的节奏。

12. 《I Reverse Engineered ChatGPT's Memory System, and Here's What I Found!》 我逆向拆解了ChatGPT的记忆系统,发现它远比想象中简单高效。它没有用复杂的向量数据库,也没有传统的基于检索增强生成(RAG)机制,而是采用了四层结构: 1. 会话元数据(Session Metadata):每次对话开始时注入,包含设备类型、浏览器信息、地理位置、订阅等级、使用习惯等。这些信息实时适配你的环境,但不会永久保存。 2. 用户记忆(User Memory):长期存储明确的用户事实,如姓名、职业目标、兴趣爱好等。这些信息由用户明确添加或模型自动识别确认,并在所有后续对话中持续注入。 3. 最近对话摘要(Recent Conversations Summary):用轻量级的摘要记录近期用户的消息片段,约15条,帮助模型跨会话保持兴趣的连续性,而非检索完整历史,极大降低了延迟和计算成本。 4. 当前会话消息(Current Session Messages):滑动窗口式地保留当前对话的全部消息历史,确保对话的连贯性。基于token限制,旧消息会逐步被丢弃,但用户记忆和对话摘要始终保留。 这样分层协同,ChatGPT既能做到对用户“知根知底”,又避免了传统RAG系统中高昂的检索成本和复杂度。它牺牲了详细的历史上下文,换来了快速响应和高效个性化。 这背后的关键启示是:记忆不必是大而全的储存,而是动态的、分层的管理。会话元数据快速适应环境,显式记忆捕捉核心事实,摘要维系兴趣轨迹,当前消息保障即时理解。它们共同构建了一个“似乎真正了解你”的智能体。 对用户而言,ChatGPT可以随着使用越发贴合你的偏好和需求,无需复杂的知识库维护。对开发者,这是一堂务实的工程课:有时简单且精准的设计,胜过复杂难控的系统。 ChatGPT的记忆系统以平衡个性化、性能和token效率为目标,践行了“少即是多”的设计哲学。它记住重要的,而非全部,快速而灵活地陪伴你的每一次交流。 manthanguptaa.in/posts/chatgpt_memory/

13. GPT-5.4据传下周上线!200万上下文窗口+持久化状态,告别频繁遗忘

14. Agent Skills使用指南:让AI智能体拥有“即插即用”的超能力

15. 【AI记忆系统突破99%准确率:用Agent完全替代向量数据库】快速阅读: Supermemory团队用多智能体协作系统在长期记忆基准测试LongMemEval上达到99%准确率,核心突破是用3个并行搜索Agent替代传统向量检索,让AI通过“理解”而非“数学相似度”来回忆信息。这套方案不需要向量数据库,甚至可以嵌入机器人。---向量数据库可能不是AI记忆的最优解。Supermemory在LongMemEval基准测试(11.5万token对话历史)上达到99%准确率,用的方法反而更简单:完全抛弃向量检索,改用多个Agent协作。传统RAG的问题出在检索环节。语义相似度匹配根本分不清“旧事实”和“新更正”,当检索结果里混杂太多噪音,大模型就会迷失。他们的解法是ASMR(Agentic Search and Memory Retrieval):信息摄取阶段,3个并行Observer Agent同时读取对话记录,按照个人信息、偏好、事件、时间数据等六个维度提取知识点,直接存储结构化内容而非生成embedding。检索阶段才是关键。面对提问时不查询数据库,而是派出3个专门的搜索Agent——一个找直接事实,一个挖隐含语境,一个重建时间线。这些Agent是在“主动阅读和推理”,不是在做向量余弦计算。回答阶段用了两种策略测试。第一种是8个高度专业化的prompt变体并行运行(精确计数专家、时间专家、上下文深挖专家等),只要任何一条推理路径答对就算成功,准确率98.6%。第二种是12个Agent独立作答后,由一个聚合器LLM综合投票裁决,准确率97.2%。有观点认为这套系统证明了“认知理解”比“数学相似性”更适合处理记忆任务。数学只能捕捉表层模式,而Agent可以处理时间序列中的矛盾、更新和细微差别。更有意思的是,这个架构完全在内存中运行,不依赖外部向量数据库,理论上可以部署到任何设备,包括机器人。他们11天后会开源全部代码。当数十亿个高度个性化的AI Agent开始学习和记住我们的一切时,记忆系统的天花板在哪里?也许不在算力,而在我们愿意给Agent多少“主动思考”的权限。ref: x.com/DhravyaShah/status/2035517012647272689#AI创造营##人工智能#

16. 在开发AI解决方案时,传统向量数据库或记忆API常面临延迟高、成本昂贵等问题。OpenMemory是一款开源、自托管的AI记忆引擎,通过独特的分层记忆分解架构,实现了长期、语义、情境记忆的高效存储与检索。它不仅支持多种嵌入模型,还能为AI助手、代理和协同工具提供持续、透明的记忆服务。 主要特点包括:- 结构化记忆:利用分层设计,实现多领域记忆存储,无数据冗余 - 高效检索:多向融合检索机制提供更低延迟的记忆回溯 - 开放自托:源代码公开,自行部署,100%数据归属用户 - 跨平台支持:兼容OpenAI、Gemini、Ollama等多种嵌入方案 GitHub:github.com/CaviraOSS/OpenMemory通过OpenMemory,开发者能为AI系统赋予更丰富、灵活的记忆能力,实现更智能、高效的交互体验。

17. AI智能体之所以强大,核心在于它们的“记忆系统”。没有记忆,智能体只能盲目行动,无法学习和适应。记忆让它们能够跨时推理、优化决策,真正实现智能。短期记忆(工作记忆)负责暂时存储任务相关信息,帮助智能体追踪当前用户问题、对话上下文和任务中间步骤,从而做出连贯且有针对性的回应。长期记忆则保存跨任务的知识与经验,积累事实和规律,使智能体随着时间变得更高效、更准确。情景记忆像人类的经历记录,存储状态、行为、结果和奖励,助力强化学习中识别哪些行为带来成功或失败。语义记忆包含结构化的世界知识——概念、规则、语言和领域信息,支持智能体推理和理解新信息。检索机制根据上下文、关键词或相似度精准调用所需记忆,避免信息混乱和过时。记忆还支持多步规划,智能体能记住子目标、进展和障碍,提升长远策略,而非仅解决眼前问题。多任务环境中,智能体为每个任务维护独立记忆,防止任务混淆,提升切换效率,并跟踪用户偏好。强化学习中的经验回放机制,通过反复利用历史经验,稳定训练过程,避免重复错误。记忆系统是动态演进的,智能体通过反馈、奖励和新交互不断更新,持续优化表现。记忆不仅是AI智能体的“知识库”,更是其“成长引擎”。理解短期、长期、情景和语义记忆的区别与协作,是构建高效智能体的关键。未来,记忆与检索机制的进步,将推动AI从“会思考”向“会记忆、会学习、会进化”迈进。原文:x.com/e_opore/status/1994331859661000712

18. 如何评价DeepSeek发布梁文锋署名论文,提出「条件记忆」及Engram记忆检索架构?有哪些亮点?

19. 为什么鸿蒙座舱5可以把交代的事办得干净利落?看完MoLA智能化架构后我懂了

20. LLM 的记忆问题「很快」就不再是问题了?

21. 一夜之间,AI终获「永久记忆」!最难考试99%刷爆SOTA,全网直呼疯狂

22. 论文 Fundamentals of Building Autonomous LLM Agents,系统性地梳理 “如何构建一个真正具备自主性的 LLM 智能体”,也就是从「语言模型」走向「智能体」(而不仅仅是增强的聊天机器人/工具调用系统)。论文提出希望解答以下几个研究问题(RQs): (1)设计空间(Design space):核心子系统(感知/推理/记忆/执行)有哪些可选方案?如何系统化组织? (2)子系统整合(Integration):在现实软件环境(比如 GUI、web 任务)中,这些子系统如何闭环协作? (3)推理效能(Reasoning efficacy):不同推理策略(如 Chain-of-Thought、Tree-of-Thought、并行规划等)对任务成功率、效率、成本有什么影响? (4)记忆影响(Memory impact):短期/长期记忆机制(例如 RAG、上下文管理)怎样提升模型在长时程任务或大上下文任务中的表现? (5)失败模式与缓解(Failures & mitigation):代理在哪些方面容易失败(如幻觉、GUI误定位、重复循环、工具误用)?有哪些缓解技术? (6)评估与泛化(Evaluation & generalization):有哪些基准/指标适用于评估此类代理?代理能在多任务、多界面条件下泛化吗?★ 核心架构论文将一个具备自主能力的 LLM 智能体拆解为以下四大模块:1. 感知(Perception)系统2. 推理/规划(Reasoning/Planning)系统3. 记忆(Memory)系统4. 执行(Execution)系 统★ 感知系统感知系统是智能体“看/听/感知环境”的部分。论文提及四种主要方式:文本感知、多模态感知、结构化数据/信息树感知、工具辅助感知。- 文本感知(Text-Based):环境以纯文本形式输入,LLM 直接处理。这种方式代价最低,但只适用于文本驱动的场景。- 多模态感知(Multimodal):环境包含图像/视频+文字,使用视觉‐语言模型(VLM)或多模态 LLM(MM-LLM)将视觉输入编码为与文本兼容的向量。- 结构化数据/信息树(Information Tree / Structured Data):例如 GUI 的 Accessibility Tree、HTML DOM 树,将界面元素结构化地输入模型。- 工具辅助感知(Tool-based):智能体调用外部 API/工具获取环境信息(如网页检索、数据库查询、传感器数据等)然后将结果反馈给 LLM。论文还指出感知系统的关键挑战:例如图像识别中模型可能“幻觉”对象、上下文窗口受限、高计算/延迟成本、数据收集困难等。★ 推理系统推理系统是智能体“思考/规划/决策”那部分。论文讨论了多种方法:- 任务分解(Task decomposition):把大任务拆成子任务。包括“先分解再规划”(Decomposition first)和“交错分解”(Interleaved decomposition)两类。- 多方案生成与选择(Multi-plan generation & selection):代理生成多个可能方案(如通过 Tree-of-Thought, Graph-of-Thought, LLM-MCTS 等)然后选择最优一个。- 反思(Reflection):智能体在执行后或执行途中反思自己的决策/行动,识别错误并改进。甚至“预反思”(anticipatory reflection)在执行前预测失败。- 多智能体系统(Multi-agent systems):将推理分为多个“专家”模块(Planning Expert、Memory Expert、Error Handling Expert 等),各司其职、协同完成。★ 记忆系统记忆系统使智能体不仅“即时反应”,还能“记住过去、用过去指导未来”。论文区分短期记忆与长期记忆。- 长期记忆(Long-term memory):如将经验固化、使用 Retrieval-Augmented Generation(RAG)从外部知识库检索、将结构化数据(如 SQL 数据库)用于查询。- 短期记忆(Short-term memory):通常是 LLM 的上下文窗口中的“当前任务状态”。- 应存储的数据类型:成功经验、失败经验、动作轨迹、环境反馈等。将“失败”经验也显式记录有助于避免重复错误。- 记忆系统的挑战包括:上下文窗口限制、检索噪声、长期记忆如何更新与维护、如何避免“记忆漂移”等。★ 执行系统执行系统是智能体“将内部决策落实为环境动作”的部分。论文谈到执行系统要支持工具调用、API/代码生成、物理操作、GUI 控制等。具体维度包括:- 工具与 API 集成(Tool and API Integration)- 多模态行动空间(Multimodal Action Spaces)——例如 GUI 控制、视觉界面操作、机器人控制、代码执行等。- 整合挑战(Integration Challenges)——例如如何让决策结果真正映射到动作、如何反馈结果、如何监控执行失败/成功。论文:arxiv.org/abs/2510.09244#ai创造营##程序员#

23. 如何从零构建一个 LLM 记忆层系统towardsdatascience.com/how-to-build-your-own-custom-llm-memory-layer-from-scratch/这篇文章介绍了如何从零构建一个受 Mem0 架构启发的 LLM 记忆层系统,通过 DSPy 框架 实现四阶段流水线:提取(将对话转为原子化事实)、嵌入(使用 text-embedding-3-small 存入 QDrant 向量数据库)、检索(ReAct Agent 自主决定何时查询历史记忆)和 维护(Agent 动态执行增删改查操作以处理矛盾或过时的信息),最终解决 LLM 无状态性问题,实现跨会话的个性化用户记忆管理。#HOW I AI#

24. Weaviate的免费电子书:《上下文工程(Context Engineering)》你是否也遇到过这样的问题?用强大的大语言模型(LLM)做应用时,模型能写能总结能推理,但面对你的专属数据却无能为力,甚至自信地“胡编乱造”。问题不在模型智能,而是它被“孤立”了——没有访问你的私有文档,没有实时信息,没有记忆。这正是“上下文工程”(Context Engineering)的核心挑战:设计系统,让模型在合适的时间获得正确的信息,连接外部知识库和工具,赋予它记忆,帮它在真实世界中可靠工作。这本电子书详细讲述了如何打造这样的系统:1. 智能代理(Agents):它们不再盲目执行固定流程,而是动态判断、选择工具、调整策略,甚至修正错误,像个有头脑的“指挥官”。2. 上下文窗口的限制与管理:模型的工作记忆有限,不能简单扩容。要懂得剔除无关信息、压缩摘要、防止信息冲突和错误积累,才能保持“思路清晰”。3. 查询增强(Query Augmentation):通过重写、扩展、拆解查询,提升检索准确度,让模型更懂你的问题。4. 文档切片(Chunking)策略:如何拆解文档成既精确又完整的小块,是检索表现好坏的关键。预切片和后切片各有利弊,复杂文档更需要层级和语义切片。5. 记忆管理:短期记忆为即时推理服务,长期记忆保存事实和经验。高效的记忆管理防止信息污染,支持多层次记忆结构,提升连贯性和智能度。6. 工具集成(Tools):模型借助外部API和功能调用,才真正能够“动手”解决问题。精确的工具描述和合理的调用逻辑,是提升系统可靠性的秘诀。7. 编排挑战(Orchestration):让代理知道何时用什么工具、如何构造参数、如何根据结果调整策略,形成“思考-行动-观察”的闭环。8. 未来趋势:Anthropic提出的“模型上下文协议”(Model Context Protocol,MCP)将实现AI应用与工具的标准化连接,告别碎片化集成,迈向模块化、组合式AI系统。总结来说,打造智能AI应用的关键不再是更大更复杂的模型,而是更精妙的上下文系统设计。上下文工程让我们从“给模型写提示词”升级为“构建模型的世界”。掌握代理、查询增强、检索、记忆和工具的协同,才能让AI真正“活”起来。🔗 weaviate.io/ebooks/the-context-engineering-guide这就是我们,构建未来AI的工程师,正在重新定义智能的边界。你准备好了吗?

25. 《Making Sense of Memory in AI Agents》 AI智能体的“记忆”其实是指它们跨多轮对话,记住并调用重要信息的能力。这让智能体能从反馈中学习,适应用户喜好,提升体验和效果。但目前驱动这些智能体的语言模型(LLM)本身是无状态的,每次交互都是“重头开始”,没有内置记忆功能。要实现记忆,必须借助外部存储或上下文管理,帮它们回顾之前的对话内容。“记忆”既是信息的存储位置(如数据库、Markdown文件),也是一种信息管理机制。研究中区分了“智能体记忆”(agent memory)和“自主记忆”(agentic memory)——前者是赋予智能体访问记忆的能力,后者是智能体主动写入和管理记忆的系统。智能体记忆大致分为短期和长期两类: - 短期记忆存在于模型的上下文窗口里,保存当前对话内容; - 长期记忆储存在外部系统,如向量数据库,保存更稳定、广泛的信息。模仿人类记忆结构,有四种记忆类型:工作记忆(当前对话)、语义记忆(事实)、情景记忆(经历)、程序记忆(指令)。另一种设计思路则划分为消息缓存、核心记忆、回顾记忆和档案记忆,分别对应不同存储和管理策略。智能体记忆管理的关键,是如何在上下文窗口和外部存储间高效传递信息,着重解决以下难题: - 如何避免上下文过长导致响应变慢和成本飙升; - 如何判断哪些信息需要被记住、更新或者删除,防止记忆膨胀和信息质量下降。这里涉及“显式记忆”(智能体主动识别和保存重要信息)与“隐式记忆”(系统自动定时更新或批处理记忆)的区分。实现时,当前对话通常用列表形式保存,指令用文本文件,其他信息则根据检索需求存数据库。技术挑战主要集中在延迟控制和“忘记机制”的设计:如何精准判断哪些信息该被遗忘,防止系统负担过重,保持记忆的相关性和有效性。目前,围绕智能体记忆管理的开发框架快速涌现,如mem0、Letta、Cognee、zep,以及LangChain、LlamaIndex等通用智能体开发工具,都在积极推动技术成熟。总结来看,AI智能体记忆设计是连接短期对话和长期知识存储的桥梁。它不仅关乎记忆的保存,更涉及记忆的更新和遗忘,是打造更智能、更贴心AI的核心难题和发展方向。原文:leoniemonigatti.com/blog/memory-in-ai-agents.html

26. Leonie Monigatti深入剖析了AI代理中的记忆演进,从最初的RAG(检索增强生成)到Agentic RAG,再到具备读写能力的Agent Memory,厘清了这一系列技术的核心逻辑与突破。RAG诞生于2020年,其核心是将离线存储的外部知识检索进LLM上下文,解决模型记忆有限带来的问题。但其“单次检索”与“只读”限制导致复杂场景下仍有误导风险。Agentic RAG引入了“工具调用”机制,允许智能体主动判断是否需要检索、选择检索工具,并评估检索结果相关性,显著提升了灵活性和准确性,但仍无法动态学习和更新信息。Agent Memory则迈出关键一步:支持智能体不仅读取,还能写入和管理外部记忆,实现基于历史交互的持续学习和个性化体验。它将记忆从“静态”转变为“动态”,但也带来了记忆管理和遗忘机制的新挑战。这三者共同体现了信息“存储-检索-编辑-删除”的完整闭环,也反映了AI系统从单点知识调用向复杂记忆体系演进的趋势。未来,如何设计高效的多源、多类型记忆管理策略,将是提升AI智能和人机交互体验的关键。详细内容及代码示例请见原文:leoniemonigatti.com/blog/from-rag-to-agent-memory.html

27. Manus 的上下文工程

28. Clawdbot 实现突破,AI的致命缺陷不再是无解难题。 #大咖观察 #红衣聊AI #医疗 #科研

29. 看大家都在搞openclaw的自主进化学习,目前测试来看,大部分的智能体都可以实现,让他自己给自己生成记忆体长文和临时会话记录,临时的就是当前会话干完活就销毁,支持多个智能体协同记忆,除了openclaw,opencode,claude,codex都可以实现,每一次都会提炼,一些刁钻的问题,本次解决之后,下次直接本地检索,不会消耗token,速度和效率都会提升,准确度也提高了。

30. 在构建面向大语言模型(LLM)的长期记忆系统时,如何实现高效、可扩展的知识图谱存储与语义检索?Memento MCP 提供了一套完整解决方案。这是一个基于 Neo4j 的知识图谱记忆系统,支持实体与关系的版本管理、时间感知和置信度衰减,结合向量嵌入实现高质量的语义搜索。它兼容支持 Model Context Protocol 的 LLM 客户端,如 Claude Desktop、Cursor 等,能够为对话模型提供持久、上下文丰富的本体记忆。主要功能包括:- 实体和关系的完全版本历史追踪,支持任意时间点的图谱状态查询;- 结合向量搜索和关键词检索的混合语义搜索,提升查询准确度和覆盖率;- 关系强度与置信度动态衰减,保证记忆信息的时效性与可靠性;- 丰富的元数据支持,包括来源、标签和时间戳,方便分类与过滤;- 多平台兼容,支持通过 Neo4j Desktop 或 Docker 快速部署;- 提供命令行工具简化数据库管理与调试。适合需要构建智能助理、对话系统或知识管理应用的开发者使用。详细文档和源码请访问:GitHub:github.com/gannonh/memento-mcp可通过简单配置,即刻为你的 LLM 应用注入强大且灵活的知识图谱记忆能力。

31. 删掉 OpenClaw!Hermes Agent 才是真王炸,一键本地部署 +模型接入全教程(避坑指南) | 零度解说

32. 一位网友逆向破解了 ChatGPT 记忆系统,给我干破防了

33. 开发者在使用 Claude Code 编写代码时,想要自动保存每次操作的上下文和工具使用情况,方便后续继续工作。Claude-Mem 是一款为 Claude Code 打造的持久化记忆压缩插件,能抓取工具执行的观察数据,通过 AI 进行语义压缩,并将相关上下文注入到未来的编码会话中。它支持跨会话保持上下文连贯,内置智能搜索功能,能用自然语言查询历史操作,极大提升项目管理和代码回溯的效率。插件提供 Web UI 实时查看记忆流,并可配置隐私标签过滤敏感信息。更有实验性的“无限模式”,通过压缩和分层存储实现更长的会话记忆,适合复杂项目的持续开发。主要功能:- 自动捕获并压缩会话数据,实现跨会话记忆延续- 语义搜索工具,快速定位历史决策和代码修改- Web 界面实时展示记忆流和搜索结果- 灵活配置隐私控制和上下文注入策略- 支持实验性无限扩展会话长度的“Endless Mode”- 基于 SQLite 和向量数据库结合实现高效存储和检索适用于需要在多次编码会话中保持项目上下文连续的开发者,尤其是使用 Claude Code 进行 AI 辅助编程的用户。项目地址:github.com/thedotmack/claude-mem安装简单,启动后自动生效,无需手动操作。想让 AI 更懂你的代码历史,这个开源插件值得一试。

34. 未来人类社会或将出现百亿甚至千亿智能体,智能体经济是未来方向 #大咖观察 #2026AI看崇礼 #红衣聊AI #智能体

35. 「Github一周热点97期」开源AI手机、AI画架构图、AI编程的指导、看板工具、GO语言的游戏引擎和具身智能资料库

36. 突破一亿Token极限:EverMind提出MSA架构,实现大模型高效端到端长时记忆

37. 刚刚,Claude实现「永久记忆」!官方还没上线,大神已玩疯

38. 在线聊天记录和上下文管理总是难题,消息太多模型上下文窗口很快就撑满了。一个超棒的开源插件 Lossless Claw(基于 LCM:Lossless Context Management),为 OpenClaw 提供了一套无损上下文管理方案。它用有向无环图(DAG)替代传统滑动窗口,完美保存所有消息,通过智能摘要浓缩旧消息,又能即时复原细节,感觉像和一个“永不忘记”的智能助手聊天。主要功能:- 所有对话消息持久存储到 SQLite 数据库,确保数据不丢失;- 采用 LLM 自动生成多层摘要形成聚合 DAG 结构,压缩旧内容但保持可展开细节;- 每次对话上下文由最新消息+层级摘要组成,极大扩展了上下文容量;- 配套 lcm_grep、lcm_describe、lcm_expand 等搜索和回溯工具,快速定位旧消息和内容;- 支持自动分层压缩、会话持久化,减少手动操作;- 多种可自定义参数调节压缩触发阈值、摘要深度、最新消息保护数量等。安装只需在 OpenClaw中执行插件安装命令,一键启用,适合想突破上下文限制的AI项目和研究者。GitHub:github.com/martian-engineering/lossless-claw#AI技术# #开源插件# #上下文管理##AI创造营##人工智能#

39. AI应该像个会成长的伙伴,而不是只会复述的机器。 #大咖观察 #红衣聊AI #智能体

40. 大模型更像人的大脑,智能体是大模型的手和脚。 #大咖观察 #红衣聊AI #智能体 #大模型

41. 「Github一周热点103期」超轻量的clawdbot、编程智能体的记忆工具、聊天记录分析工具、视觉agent框架和键盘、鼠标统计工具

42. 文档平台 Mintlify 发了一篇工程博客,讲了一件挺有意思的事:他们给自家 AI 文档助手造了一套假的文件系统,叫 ChromaFs,让 AI 以为自己在用 grep、cat、ls 这些命令浏览文件,实际上每个命令都被拦截、翻译成了数据库查询。效果很直接:会话启动时间从原来沙箱方案的 46 秒降到 100 毫秒,每次对话的边际计算成本几乎为零。Mintlify 之前的方案是标准的 RAG 流程:把文档切块、向量化、存进 Chroma 数据库,用户提问时检索最相关的片段喂给大模型。问题是,如果答案分散在好几个页面里,或者用户要的是某段精确的代码语法,向量检索经常找不对。他们想让 AI 像开发者翻代码一样翻文档,而不是靠语义相似度碰运气。核心思路是:AI 不需要真的操作系统,只需要一个足够逼真的幻觉。ChromaFs 基于 Vercel Labs 的开源项目 just-bash(一个用 TypeScript 重写的 bash 子集)构建。just-bash 提供了可插拔的文件系统接口,负责解析命令和管道逻辑,ChromaFs 则把所有底层文件操作翻译成 Chroma 数据库查询。每个文档页面变成一个"文件",每个章节变成一个"目录",AI 就可以用 grep 搜精确字符串、用 cat 读整页内容、用 find 遍历结构。之前用真沙箱的方案(给每个用户起一个微型虚拟机),按 Mintlify 月均 85 万次对话的量算,一年光计算成本就要 7 万美元以上。ChromaFs 复用了已有的数据库基础设施,这笔钱省了。grep 是最难虚拟化的命令。如果真让它逐文件扫描,走网络 IO 会很慢。ChromaFs 的做法是先把 grep 的参数解析出来,用 Chroma 的元数据查询做粗筛,找出可能命中的文件批量预取到缓存里,再让 just-bash 在内存中做精确匹配。权限控制也很优雅:初始化时根据用户身份裁剪文件树,没权限的路径直接从树里删掉,AI 连路径都看不到,不存在越权风险。所有写操作一律返回"只读文件系统"错误,AI 能随便看但改不了任何东西,整个系统无状态,不用担心清理和数据污染。这篇文章在 Hacker News 上引发了一个有意思的讨论。好几位开发者指出,大家不知不觉中把 RAG(检索增强生成)等同于了向量搜索,但 RAG 里的 R 是 Retrieval(检索),本来可以是任何方式:全文搜索、SQL 查询、甚至翻电话簿。把 RAG 绑死在向量数据库上,是早期技术路径的惯性。有人解释了这种惯性的由来:RAG 概念流行的时候,大模型还不太会用工具,多轮搜索和纠错能力也差,向量检索是当时最省事的方案。现在模型的工具调用和推理能力上来了,让 AI 自己决定用什么方式找信息,反而比预设一条检索管道更灵活。也有人提出了务实的质疑:Mintlify 的场景是结构化的技术文档,天然适合文件系统隐喻,但如果是组织内部那种乱七八糟、没有层级结构的知识库,这套方案未必好使。这个方向和 Claude Code 的做法有相通之处:与其把所有信息预检索好喂给模型,不如给模型一套探索工具,让它自己决定看什么、怎么找。对于正在搭建 AI 文档助手或内部知识库的开发者来说,Mintlify 的这套方案提供了一个向量检索之外的选项,尤其适合文档结构清晰、对精确匹配要求高的场景。

43. 未来的人和智能体应该是相互融合协作的关系。 #大咖观察 #红衣聊AI #智能体 #人机协作

44. 「Github一周热点107期」OpenAI收购的AI安全工具、AI代理事务所、OpenClaw技能库、claude code插件和上下文数据库

45. 「Github一周热点110期」Github历史增长最快的项目?

46. 「Github一周热点98期」AI文档检索框架、微软最新TTS、Claude Code 记忆插件、自动化备份、 jellyfin和linux桌面环境

47. 「Github一周热点95期」META 3D 模型、智能体记忆引擎、向量数据库、 Web 3D 引擎、AirPods 跨平台、数据库管理工具

48. 「Github一周热点96期」Flux2绘图模型、腾讯的视频生成模型、AI记忆、开源Launchpad、笔记和知识库,Nginx可视化工具

49. 大模型的上下文工程,都说很重要,但相关的研究那么少,对Agent开发有什么影响,有大佬能解释一下吗?

50. 在线构建智能体记忆库的必备利器!🚀Honcho 是一款开源的记忆库与托管服务,专为构建有状态的智能体(stateful agents)设计。它支持任何模型和架构,能持续学习并维护用户、智能体、群组、观点等实体的动态状态,让你的智能助手记忆力爆棚,更加可信和个性化。主要亮点:- 统一的“伙伴”模型,支持多参与者多会话交互- 多种记忆存储原语:工作空间、会话、消息、集合与文档- 强大的异步推理系统,自动生成用户画像与会话摘要- 自然语言查询聊天接口,快速获取用户偏好与历史信息- 支持多种大模型(OpenAI、Anthropic、Google Gemini 等)- 丰富的SDK支持 Python 和 TypeScript,开发体验极佳- 灵活配置,支持本地部署、Docker 和云端部署(Fly.io)GitHub: github.com/plastic-labs/honchoHoncho让你的智能体拥有“记忆”,让人机交互更自然、更高效,也帮助你打造持久的竞争壁垒。#开源项目# #人工智能# #智能体开发# #长期记忆# #Honcho# #Python神器#

51. 智能体上下文工程:为什么文件系统成了AI记忆的最佳载体?

52. 不知道大家想过这个问题没有,大家都感觉现在大模型的记忆存储受限,200万的上下文记忆其实也不够用。但我想说,其实即使大模型能够记住海量的上下文,也未必有用,它依然需要上下文的管理。也就是说,在AI时代,一个人非常重要的能力就是如何去管理上下文,去领导Agent。为什么这么讲呢?大家可以想想,如果记忆不受限,大模型可以无限存储,你和它聊的内容越多,它大脑里塞的东西就越满。在执行任务的过程中,它不知道到底应该怎么去执行,因为塞的东西太多了,哪个是核心的?是不是太多了?如果记忆太多,就容易导致错乱和模糊,因为你塞得太满,它不知道怎么执行,很多东西在里面很乱。所以,上下文管理是必须的。第二,即使大模型的记忆非常多,人和人之间沟通,一句话的理解都可能不同,何况大模型和人之间的沟通呢?这里面肯定也会存在交流的摩擦。所以,人需要及时干预和介入到大模型的工作流程当中,去管理上下文、管理整个流程,这是非常必要的。所以大家不要期待说,大模型的上下文越来越长就越好,不一定,有利有弊。即使大模型不会丢掉记忆,记忆永存,它依然不会精准地按照人类的要求去执行。我之前看过一个调查或研究,就是说大模型里,你上下文塞得越多越满,它的执行就会越混乱、越模糊,就是因为东西太多了,它不知道怎么执行了。所以,管理上下文这个事情,依然需要有人去管理、去做。#科技先锋官##How I AI#

53. 大模型的上下文工程,都说很重要,但相关的研究那么少,对Agent开发有什么影响,有大佬能解释一下吗?

54. 网页链接langchain发了篇官博,探讨了智能体如何利用文件系统进行上下文工程,以提升其性能和可靠性。智能体失败的主要原因并非模型能力不足,而是缺乏正确的上下文信息。上下文工程的目标是精准地将必要信息填入模型的上下文窗口,避免信息缺失、冗余或不相关。常见的上下文工程挑战包括: 信息过多(检索内容远超所需):如网络搜索返回大量无用内容,浪费token并增加成本。 信息过少或超出上下文窗口:复杂任务需大量信息,单次无法加载全部。 难以定位小众信息:所需信息埋藏在大量文件中,语义搜索效果有限。 缺乏持续学习能力:无法从交互中积累新知识。文件系统是解决这些问题的关键工具,其优势体现在: 作为“草稿板”:将大体积工具输出(如网页内容)存入文件系统,按需通过grep等工具提取关键信息,减少上下文占用。 动态管理上下文:存储长期计划、子任务结果或复杂指令,按需调用,避免系统提示过载。 精准搜索:利用ls、glob、grep等命令在结构化目录中快速定位特定文件、行甚至字符,尤其适合代码或技术文档。 持续学习与自我更新:智能体可通过用户反馈更新自身“技能文件”,将新知识写入文件系统,实现长期记忆与能力进化。#科技先锋官#

55. 【向量数据库被颠覆?一个无需嵌入的RAG新思路】 最近开源社区出现了一个有意思的项目PageIndex,它提出了一种完全不同的RAG实现路径:用文档树结构替代传统的向量嵌入,在FinanceBench基准测试上达到了98.7%的准确率。 这个方案的核心理念是让大模型直接在文档结构上进行推理,而不是通过关键词匹配来检索。不需要嵌入,不需要分块,完全开源。 听起来很激进,但仔细想想,这其实回归了一个朴素的问题:人类阅读文档时,依赖的是什么?是语义相似度,还是章节、标题、表格这些结构化线索? 对于金融报告、法律合同、合规文档这类天然具有清晰层级结构的内容,让模型沿着文档树进行推理,确实比把文档切成碎片再用向量匹配更符合直觉。结构优先的检索方式,也让引用溯源变得更加可靠。 但社区的实测反馈也很真实。有人指出它目前只能处理单个文档,跨文档比较和相似性匹配这类场景还是需要向量数据库。也有人反映速度偏慢,对于简单查询来说,逐层遍历节点的开销不小。还有人质疑:面对大规模非结构化数据,这种方案能否扩展? 一位开发者的评论很中肯:向量数据库能用廉价的数学运算实现毫秒级检索,而PageIndex依赖的是昂贵且缓慢的大模型推理,在需要扫描海量文档的场景下,可行性存疑。 所以这不是一个“谁取代谁”的故事。更准确的理解是:RAG的工具箱里多了一件趁手的武器。结构化文档用文档树,非结构化内容用向量嵌入,复杂场景可能需要混合方案。 技术选型从来不是非此即彼。真正的答案永远是:在你自己的数据上跑一遍基准测试。 GitHub:github.com/VectifyAI/PageIndex x.com/dr_cintas/status/2019045152350756869

56. 【AI Agent的终局不是无限上下文,而是60年前的操作系统】快速导读:大家都在卷百万上下文窗口,但一篇新论文和一线实践者的共识是:真正的解法是把AI的上下文当成一个文件系统来管。这不仅是理论,更是正在发生的事实。---几乎所有人都默认,AI Agent的瓶颈是上下文窗口不够大。从几千个token卷到上百万,仿佛只要窗口无限,AI就能包揽一切。但一篇名为《Everything is Context》的论文提出了一个反直觉的观点:解决上下文问题的最佳方式,是退回到60年前,像操作系统一样,把一切都视为文件系统。记忆、工具、外部源、人类笔记,都作为文件出现在一个共享空间里,只在需要时加载必要的部分。这不只是个学术脑洞。评论区里的一线开发者证实,他们早已在实践中这么做了。他们发现,真正的难题不是建立文件结构,而是决定“不加载什么”。上下文工程的核心,是战略性地遗忘,而不是暴力地堆砌。当AI的每一次信息调用都有时间戳和来源记录,调试Agent的过程就从“重跑一遍碰运气”,变成了像git-blame一样精确回溯。有人一针见血地评论:我们正在以惊人的速度,重跑一遍计算机科学60年的历史,最后发现,操作系统第一次就做对了。最好的想法不会消亡——它们只是在等待房间里的人跟上。---简评:长上下文的暴力美学走到了尽头,架构的优雅开始回归。从“大力出奇迹”到“万物皆文件”,不是技术倒退,而是认知升级。AI的未来,藏在计算机科学的过去里。---ref: x.com/rohanpaul_ai/status/2028184543040270769#AI创造营##人工智能#

57. AI记忆革命爆发!Clawdbot如何像大脑般记住一切

58. 《Making Sense of Memory in AI Agents》AI代理记忆的最大难题,不是教它们“记住”,而是教它们“忘记”。核心挑战是:大语言模型(LLM)天生无状态,每次对话都是全新开始,既不记得五分钟前说了什么,也不记得上周的内容。那么,如何让代理“记住”呢?记忆类型分两大类:• 短期记忆:LLM上下文窗口里的当前对话信息• 长期记忆:外部存储的历史对话、用户偏好、学习事实等不同框架对记忆分类也不尽相同:CoALA(类人认知架构):- 工作记忆(当前对话)- 语义记忆(用户事实)- 情景记忆(过去经历)- 程序记忆(指令和行为)Letta(架构导向):- 消息缓冲(最近消息)- 核心记忆(主动管理的上下文块)- 回忆记忆(对话历史)- 档案记忆(显式存储的知识)最难的部分是忘记。如何自动判断哪些信息过时了?哪些依然相关?这正是大多数实现的难点。Leonie的文章不仅讲清了各种记忆类型,还分享了实践中如何管理记忆(生成、存储、检索、更新、删除),并介绍了mem0、Letta、zep等新兴记忆框架。社区专家提到:- 让代理自己判断哪些记忆该删,比用复杂的衰减机制更靠谱。- 记忆管理不能只是简单的“先进先出”,需要智能逻辑。- 忘记不仅是存储问题,更是时间、情境和价值判断问题。- 合规需求(如“被遗忘权”)让删除机制变得更复杂。总结:AI代理记忆设计的核心,是如何在短期上下文与长期外存之间高效流转信息,同时智能决策何时更新、合并或删除信息。忘记难题不仅关乎技术,更关乎对时间和情境的理解以及用户隐私的尊重。文章:leoniemonigatti.com/blog/memory-in-ai-agents.html

59. 为什么在生产环境部署多智能体系统(Multi-Agent)容易出现成本失控,有哪些常见的踩坑场景?

60. AI 智能体记忆系统现状深度调研(二)

61. AI 智能体记忆系统现状深度调研(三)

62. 0x07 企业级AI智能体第一性原理

63. 智能体的记忆系统

64. AI 智能体记忆系统现状深度调研(八)

65. AI 智能体记忆系统现状深度调研(五)

66. AI系列-大模型中向量数据如何存储呢?用向量数据库吗?

67. 谷歌提出: 持久在线记忆智能体如何设计

68. 如何搭建开发AI智能体?

69. AI智能体技术方案

70. AI智能体开发技术方案

71. 通俗讲解大模型短期记忆 vs 长期记忆

72. 想用好AI Agent?你得先搞懂“短期记忆”和“长期记忆”的区别

73. AI设计模式

74. AI Agent 记忆系统设计

75. Agent如何联动短期记忆和长期记忆?

76. AI 智能体记忆系统现状深度调研(九)

77. 小红书大模型二面

78. LangChain之长时记忆Long-term Memory

79. 什么是 LlamaIndex,它为何出现?它主要解决了什么问题?

80. 打败5000万美元向量数据库的Markdown文件

81. 传统RAG尴尬了,三巨头OpenClaw、Manus、Claude都选了MD

82. 智能体架构-向量数据库分析

83. 颠覆 RAG!本地 Markdown 知识库,AI 自动维护不遗忘,基于Karpathy 4月的LLM Knowledge Base 推文

84. Supermemory CEO

85. 从“存储匹配”到“函数映射”

86. 纯向量数据库,真的凉了?

87. Mem0轻量级记忆框架。轻量级记忆框架Mem0, 配置极简,生态完善,社区增长快速(44.6K)

88. 别再盲目套用缓冲记忆了!你的 LLM 应用该用哪种记忆模式?

89. memU 拆解

90. 小智Pro

91. LLM 长期记忆与跨 Session 记忆方案全景

92. 智能体记忆相关论文

93. AI智能体长期记忆系统

94. [论文速记] Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

95. 告别拼凑

96. 为什么上下文窗口再大也替代不了记忆——AI Agent的RAM与硬盘之争

97. 上下文窗口不是记忆

98. 人人都能懂的大模型 · 第14期

99. 大模型长记忆的三个误区

100. AI的记忆问题解决了!最强记忆基准99%的准确率

101. AI智能体记忆管理深度解析

102. 肖涵

103. DeepSeek 爆火后,我建议你把 90% 的向量数据库“降级”为对象存储

104. AWS S3 Vectors vs 向量数据库

105. 架构师视角的企业级向量数据库选型实践

106. 硅基大脑记忆觉醒!会遗忘、会反思、会成长的AI正在到来

107. EverOS智能体记忆自进化

108. 智能体如何解决大模型“没手没脚”的落地难题?

109. AI智能体时代的记忆革命:形式、功能与动态机制全景解析

110. 大模型时代的向量数据库-机器之心 - 哔哩哔哩

111. 大模型时代的向量数据库-实战课程-慕课网

112. 向量数据库

113. 数据库对比:向量库与传统数据库的差异分析

114. 为什么 AI 不能有无限记忆?到底什么是上下文窗口限制?

115. AI算法面试:向量存储与数据库

116. Zvec进程内向量数据库

117. AI开发者必看!10种向量数据库大起底

118. 养虾记·第110期|龙虾的记忆宫殿——向量数据库选型指南

119. 🚀【进阶篇】第 8 课:上下文管理——告别”七秒记忆”进阶版

120. 向量数据库基础入门

121. 什么是向量数据库 —— 零基础也能懂的核心概念

122. 智能体效率大揭秘:记忆、工具与规划的优化之道

123. 机器学习向量数据库完全指南

124. 高效智能体的「幕后推手」是谁?一篇综述带你从记忆×工具学习×规划看透

125. 向量数据库详解(三个难度级别)

126. Hindsight:能学习的AI 智能体记忆系统

127. 学长带你吃透 AI 时代 “外挂”:向量数据库与 RAG,一文就够!

128. LangChain检索增强生成(RAG)技术深度解析:从原理到实践

129. 年度必读!NUS、人大、复旦、北大联手,一文讲透AI Agent记忆的所有关键问题

130. 壮笔记丨综述:Agent记忆方案梳理

131. 【RAG技术入门】 2.RAG核心组件之向量数据库

132. 【OpenClaw 记忆机制】第1课:为什么需要记忆机制?上下文窗口的局限性

133. 易术观点 | 智能体记忆系统架构的演进与分类

134. 向量数据库简述

135. 实战案例day9 上下文管理之长短期记忆

136. Agent的短期缓存与长期沉淀记忆,决定AI的智商上限

137. 了解 MemWal:为 AI 智能体打造的长期记忆层

138. SQL Server 2025向量功能:救回濒临倒闭的副业,收入直接翻倍

139. 向量数据库已死?PostgreSQL 这个新功能,让闭源尬住了

140. 传统数据库与向量数据库:一个管“是什么”,一个管“像什么”

141. 大模型知识库开发中的向量数据库选型指南:从理论到实践

142. 图谱智能体记忆技术和应用综述:构建AI Agent的"大脑记忆系统"

143. 向量数据库白皮书内容总结和解读(可下载)

144. AgenticAI时代,向量数据库成必选项

145. LlamaIndex技术深度解析:从数据框架到高级RAG实践

146. AI智能体五层架构各有哪些核心技术支撑?

147. 第10章 RAG(检索增强生成)系统构建(LangChain实战)

148. 【人工智能专题】(六)「湘信AI」智能体分层记忆系统的技术研究与应用实践

149. AI 智能体记忆系统现状深度调研(六):LlamaIndex 的记忆系统/机制

150. 后端开发必看!大模型离不开的向量数据库,原理+实战一次性讲透

151. 告别选择困难:一文读懂向量数据库核心差异,做出明智的技术选型

152. 大模型检索增强生成(RAG)实战:从基础架构到

153. AI时代的技术基座-向量数据库

154. LLM 到底是怎么“记住东西”的?它的记忆分三层:参数、上下文、外部存储

155. 论文阅读——智能体记忆的解剖学:评估与系统局限的分类学与实证分析

156. 向量数据库:大模型时代的记忆大脑

157. 大规模智能体网络一篇综述梳理拓扑、记忆与动态更新三大核心维度

158. LlamaIndex框架核心知识点

159. 大模型应用:从问题到答案:LlamaIndex RAG系统工作流程详解.15

160. AI 智能体记忆系统现状深度调研(一):概述

161. AI中四种向量数据库

162. Agentic Memory:超越Mem0, 智能体记忆新范式——统一长任务的记忆管理

163. 每日GitHub精选:打造个人AI助手的「轻在线」向量数据库—LEANN

164. Redis 8.0向量库 vs 传统向量数据库:大模型知识库开发选型全指南

165. 怎么选向量数据库:Pgvector、Redis、Milvus、Qdrant

166. 大数据转型的“降维打击”:当分布式架构遇上向量数据库 (Milvus)

167. 每日GitHub精选:用 LlamaIndex 构建自己的智能知识大脑

168. AI 向量数据库选型指南:2026 年主流平台深度横评

169. AI智能体时代中的记忆机制:全面探讨其形式、功能与动态发展综述!

170. 从零理解 RAG:LlamaIndex 入门指南

171. AI算法原理0基础入门-第37回-长期记忆——让智能体记住你

172. LangChain(四)Memory 核心要点:4 种记忆策略对比与选型

173. 海马体与向量数据库的认知博弈——有限遗忘 vs 无限存储的困局

174. LangGraph - 04:短期记忆与长期记忆

175. 向量数据库选型指南1024维场景下,Milvus、pgvector、ES、MongoDB深度实测

176. 实战:从索引到embedding再到内存管理,如何降低80%向量数据库成本

177. 先进的检索增强生成:从理论到 LlamaIndex 实现

178. AI 智能体本地化部署

179. 如何让 AI 记住几万字的上下文?揭秘 LLM 记忆架构 🏗

180. 关于向量数据库我错的离谱

181. 从原理到实战:30分钟掌握下一代数据库——向量数据库

182. Agent Memory 才是 AI 应用的下一个瓶颈

183. 主流向量数据库原理、使用、混合检索与生产实践对比报告

184. AI 智能体本地化部署的流程

185. Agent Memory新范式!智能体记忆SOTA思路📌

186. 让AI学会过目不忘:Agent Memory相关论文分类梳理

187. 智能体记忆模式的全景分类解析

188. 中兴通讯取得智能体记忆法相关专利,智能体记忆架构助力对话信息处理及响应

189. 聊聊AI的记忆——短期记忆

190. Day10 学习日志:用 LangChain 搭一套可落地的**制度 RAG**(检索 + 生成)

0
扫一下,分享更方便,购买更轻松
0评论

当前文章无评论,是时候发表评论了
提示信息

取消
确认
评论举报

最新文章 热门文章