​memory技术被高估了，真正难的是“上下文组装”

真正拉开差距、考验功力的地方，是如何把各种信息组装成有效的prompt，给模型看的真正重要的、有价值的内容，这个是agentic runtime的核心。

而非memory。

memory技术 被高估了，真正难的是“提示词组装”

最近在搭建agentic runtime 时，

有一个感受越来越强烈：

memory技术被夸大了。

市面上很多文章和产品把“记忆模块”吹成万能钥匙，似乎有了它，智能体就能像人一样“过目不忘、举一反三”。

但实际动手做下来，你会发现，现有的三种记忆和召回方式混合使用，已经足够应对大部分场景。

真正拉开差距、考验功力的地方，是如何把各种信息巧妙组装成每次给模型看的提示内容。

先说记忆：

三种方式混着用就够了

当前主流的记忆存储和召回方案，基本可以归为三类：

语义相似检索：

适合处理大量非结构化的文档、聊天记录或知识。

它能找到“大概这个意思”的内容，

但缺点也很明显：经常召回一些看似相关、实际无关的片段，容易干扰模型判断。

更新旧信息也不方便，时间久了容易“记错”。

纯文本文件 + 关键词搜索

比如用Markdown文件存笔记，直接用搜索工具找

这是最简单、最透明的方式，glob+grep。

很多原型系统或代码相关任务用这个就跑得很稳。

优点是清晰、可调试、容易用版本控制管理；

缺点是对同义词或模糊描述的处理能力弱。

结构化存储 + 精准关键词搜索

用数据库存事实、偏好、事件记录，支持精确查询和过滤。

这类方式特别可靠，能精确找到“某个具体关键词”“某段时间的事件”或“用户上次提到的偏好”。

支持增删改，适合需要审计和更新的长期事实。

结合SQL一样的查询，能做多条件筛选，非常实用。

实际做法是把这三种混合起来：

短期对话用简单的临时记忆；

事件日志和笔记用文本文件 + 关键词搜；

重要事实、用户偏好用结构化数据库 + 精准搜索；

只有需要模糊语义补充时，才偶尔用向量检索作为备用。

很多短视频和推文吹的graph rag或多层记忆系统。我发现边际效果不大，反而增加了维护难度。

记忆更多是基础设施，做好“先精准搜、不行再语义补”的路由机制就够稳了。

真正有门槛的：上下文组装

如果说记忆是“仓库”，那每次让模型思考前，如何把仓库里的东西、当前任务、可用工具、历史关键点等信息，合理地拼成一段清晰、有效的输入内容，才是核心功夫。

为什么这部分难？

动态调整：智能体是多步循环工作的（规划→调用工具→观察结果→反思→下一步）。每一步需要的内容都不一样，不能用固定模板硬塞。

平衡问题：塞太多无关信息，模型会分心、浪费计算资源，甚至判断出错；塞太少，又会丢失重要连续性。

结构与自然语言的融合：从数据库拉出的结构化事实、从文件搜出的文本片段、工具列表、当前目标……需要巧妙交织。太生硬像代码，模型不喜欢；太随意又容易丢精度。

长时管理：对话越长，越需要定期压缩历史、突出重要点，避免内容膨胀。

做好提示词组装，相当于给智能体搭建了一个“大脑调度器”。

它需要考虑：

哪些记忆片段最相关？按重要性、时间远近、当前任务需求排序。

如何用简洁语言呈现？是否需要先总结压缩？

给模型的指令要清晰但不过度限制，让它有一定自主空间，同时加上自我检查的步骤。

整个过程要可观察、可调试，便于后续优化。

很多原型系统记忆做得不错，但因为组装方式粗糙，导致循环卡住、重复出错或偏题。反过来，记忆简单一些，但组装逻辑精巧的系统，往往表现更稳定、任务完成率更高。

纯干货：实用建议

先把记忆基础设施做简单可靠：三种方式混合 + 智能路由，别急着堆新技术。

重点投入上下文组装模块：开发一个专门负责“收集→筛选→排序→格式化→输出”的组件。可以用模板系统动态渲染，支持不同子任务用不同组装策略。

加入反思机制：让智能体在行动前后简单自查一下“当前信息够吗？有没有遗漏关键事实？

重视可观测性：每次组装后的完整输入都要记录下来，方便排查问题。

---

原文链接：https://mp.weixin.qq.com/s/C2gKSdwmBl9qDHOGH6cf9w

来源：XT