企业官网建设流程全解析

在单机工具里能闭着眼跑通的记忆逻辑，一放到真实Agent产品里就散架——这是我从年初到现在观察到的普遍现象。

很多团队做Agent，第一版对话体验还行，跑几轮业务逻辑之后就开始“失忆”：用户十分钟前说过的偏好，下个任务就忘了；两个子Agent协作，信息传到一半就断层；跨天会话更是完全归零。问题基本都出在记忆层。最近我们的Agent记忆项目登上了相关榜单，这个项目不是什么炫酷的模型创新，就是把“记忆”这件事从架构层面彻底想清楚了。这篇就完整拆一下我们踩过的坑、定下的架构，以及最终跑通的东西。

先说清楚：这个项目解决的核心问题是“长上下文之外、多会话之间、多Agent之间怎么可靠地记住该记的事”。关键词就是Agent记忆、双网络记忆模型、记忆评分与时间衰减，全部围绕记忆这个方向展开。

1. 为什么“Agent有记忆”这件事这么难

记忆问题听着简单，不就是把对话历史存下来、下次再带进上下文吗？真做起来完全不是这么回事，几个层面的困难叠在一起，让Agent记忆成了业界的普遍难点。

1.1 上下文窗口再大，也装不下“全部历史”

现在大模型的上下文窗口动辄几十万token，看起来够用了。但实际使用中你会发现：把一堆历史对话全部塞进上下文，模型确实不会直接报错，可关键信息会被淹没在海量文本里，召回精度反而下降。我们团队有位同事做了个测试，往上下文里塞了六万字的背景资料之后，简单的是否判断题都能做错。

更现实的问题是成本。上下文越长，单次推理的token开销和延迟就越高。一个跑生产业务的Agent，每轮请求都带上一整周的历史记录，这个费用和响应速度都不可能落地。所以“记什么、不记什么”必须有一个主动筛选的机制，而不是一股脑全存。

1.2 Agent的任务形态决定了记忆必须是结构化的

大模型单轮的“对话记忆”其实很浅，就是上下文里的话。但Agent是一个持续执行任务的系统，需要跨步骤、跨会话地记住：用户的偏好、业务约束、任务进度、外部工具的状态，这些东西形态各异，有的是短句，有的是结构化参数，有的是一段长文档的摘要。

如果只用一个“历史消息列表”来承载所有记忆，效果会非常差。我们早期版本就是这么干的，结果用户改了一次偏好，老偏好和新偏好同时出现在记忆里，Agent当场“精神分裂”，一会儿按旧规则执行，一会儿按新规则执行。

1.3 记忆必须有“更新”和“遗忘”机制，而不只是“存储”

这是最容易忽略的一点。人的记忆是有遗忘曲线的，长期不用的信息逐渐模糊，频繁使用的信息保持清晰。Agent记忆也一样：一次性的临时状态（比如“当前正在执行的任务ID”）和长期稳定的用户画像（比如“用户是内容创作者”），生命周期完全不同，不可能用同一个存储策略。

很多文章喜欢提“记忆=score+时间半衰期”，这句话我们实测下来是对的。核心就是每条记忆不仅要记录内容，还要记录重要性分值和最后访问时间，定期重算出一个“当前价值分”，价值分低的慢慢沉底，价值分高的在召回时优先出现。

2. 双网络记忆模型：长期层和短期层各自干各自的活

项目核心架构就是我们常说的“双网络记忆模型”。这个名字听起来挺唬人，拆开看其实很朴素：把Agent的记忆分成两个网络层，一个负责长期稳定信息，一个负责短期任务状态，各管各的，互不干扰。

2.1 长期记忆层：存那些“跨会话不变”的事

长期记忆层存的是用户的长期偏好、业务规则、知识库摘要、历史项目结论这类很少变动的信息。这一层的核心诉求是：存得稳、查得准、更新慢。

我们用向量数据库承担长期记忆的物理存储，每条记忆生成embedding向量，写入时顺便打上类型标签和重要性分数。召回的时候直接做向量相似度检索，取Top-K条插入当前上下文。这个方案的好处是完全不需要模型参与检索，几十毫秒就能完成，不烧token。

这里有第一个值得注意的设计：长期记忆不直接存原始对话，而是存“提炼后的结论”。比如用户说“以后周报别在周五晚上发”，我们不是把这句话原封不动存进去，而是用小模型抽取成结构化条目：“周报发送时间约束：非周五晚上”。这一步非常关键，能过滤掉大量口语化的噪声，让下游召回更干净。

2.2 短期记忆层：管住正在进行的任务状态

短期记忆层对应人脑的工作记忆，存的是当前会话内的任务状态、中间变量、待办事项。你让Agent先查资料再写报告再发邮件，这三个步骤之间流转的数据，都在短期记忆里。

短期记忆的存储不需要向量库，我们用的是Redis加一个轻量级状态表。每条记录带session_id和task_id，任务完成后自动清理。这一层的要求是读写快、过期明确，不跟长期记忆混在一起。

双网络最大的好处是隔离了“检索噪声”。如果我们把所有数据都放在一个库里，召回时很容易把“上一个任务的临时状态”误当成“用户的长期偏好”带进上下文，导致Agent执行逻辑跑偏。网络分开之后，长期层只检索长期条目，短期层只按任务ID精确取数，谁也不会污染谁。

2.3 长期和短期的联动：工作记忆写入长期记忆的时机

双网络不是完全独立的，需要一条联动通道：短期记忆里的信息，在什么条件下升迁到长期记忆里？

我们定的规则是：同一条信息在短期记忆里出现超过两次（比如用户连续两次强调同一偏好），自动触发“提炼+写入长期层”的流程；或者用户在会话里明确说“记住以后都这样”，也会直接触发长期写入。触发后，系统会调用一个轻量的抽取模型，把原始语句转成标准化的记忆条目，再生成向量入库。

这条联动通道是整个记忆系统最出彩的地方。它让Agent不需要把所有内容都永久保存，只在信息足够重要时才沉淀到长期层，既控制了存储量，又保证了关键信息的连续性。

3. 记忆的评分、衰减与召回：让系统自己判断该记住什么

记忆系统能不能用，一大半取决于“召回时能不能把最该让模型看到的东西找出来”。前面说了太多存储，这块重点讲召回前的排序逻辑，也就是热度计算和召回机制。

3.1 记忆热度的计算公式：score与时间半衰期

我们在项目里实践下来的一套热度公式，核心就是热搜词里那个“记忆=score+时间半衰期”：

当前热度 = 原始分值 * 衰减系数 ^ (当前时间戳 - 最后访问时间戳) / 半衰期

看起来很简单，细节在于参数怎么定。

原始分值（score）由两部分构成：写入时根据记忆类型给的基准分，加上每次被成功召回后加的“命中加分”。基准分我们是这样定的：

半衰期则是按类型区分的：用户偏好类半衰期30天，任务结论类7天，临时日志类1天。这套参数不是拍脑袋定的，是跑了四轮线上A/B测试调出来的。核心规律是：半衰期太短，隔两周的用户偏好就召不回；太长，过时信息在库里堆积，召回的条目质量会快速下降。

3.2 召回时的“热度+相似度”双排序

很多新手做检索式记忆，只按向量相似度取Top-K。实际跑下来问题很大：相似度高的条目不一定重要，可能只是匹配到了用户随口说的一句话。我们在召回时采用两阶段排序。

第一阶段：向量检索，候选集取Top-50。 第二阶段：把50条候选按“当前热度×0.6 + 相似度×0.4”组合打分，重新取Top-5真正塞进上下文。

这个双排序机制，让“重要但表述不太一样的老记忆”也能排到前面。举个例子，用户曾经说过“我一般不用腾讯系的产品”，后来再聊到工具选型时，向量相似度可能匹配不到这句原话（因为检索词是“协同办公软件”），但因为这条记忆热度极高，重排序之后照样能被带上。这就是热度排序存在的价值。

3.3 召回内容的格式控制与上下文预算

模型上下文是有限的，所以每次召回多少记忆也要严格设预算。我们按token数做预算分配：长期记忆召回上限约800token，短期记忆精简到300token以内。召回内容统一拼装成一个固定的“记忆区块”，放在系统提示词之后、用户消息之前。

这个记忆区块的模板是这样的：

[记忆] - 用户偏好：不喜欢周五晚上处理周报，需要提前一天发送 - 业务约束：报价单必须经过二次审核后才能发给客户 - 任务状态：正在进行第三季度的竞品分析，已收集6份材料

格式统一之后，模型解析记忆块的准确率明显提高。早期版本我们直接塞JSON，模型有时候会把JSON字段当成业务指令执行，出了几次事故，换成结构化短句模板才消停。

4. 踩过的坑：检索漂移、写入风暴与记忆边界争议

记忆系统光看架构挺美好，真正落地时问题和方案一样多。这块把我认为最值得分享的几个坑原原本本写出来。

4.1 向量检索的“失焦”问题：怎么修都不如规则兜底

第一个深坑是向量检索的失焦。我们的长期记忆库跑了两周后，发现一个问题：用户问“那个文档的链接呢？”，向量检索召回的竟然是各种关于“文档格式”的记忆，而不是用户实际的文档地址。

查下来原因是embedding模型对“链接”这个词的语义理解不够精确，把“文档链接”和“文档说明”混为一谈了。我们试过换更强的embedding模型，改善了一些，但两个问题随之而来。

第一个是成本。商业embedding接口按百万token计费，换更强模型后单条记忆写入费用翻了三倍。 第二个是延迟。强模型的向量维度更大，检索耗时从50毫秒涨到180毫秒，感知明显。

最后我们的解法是“规则先过滤、向量再排序”——召回时先用关键词和记忆类型做一轮硬过滤，把候选集从几万条缩到几百条，再做向量检索。比如用户提到“链接”，规则层就过滤出类型为“文件引用”的记忆，向量层只管在这类记忆里找最相关的。实测下来，召回准确率从82.6%提升到了94.1%，成本和延迟反而降了。

4.2 写入风暴：短期记忆高频触发长期写入

运营反馈说“Agent变笨了”，排查之后发现是写入风暴。我们的短期记忆转长期记忆逻辑，触发条件之一是“同信息出现两次”，结果某条用户指令在会话中反复出现，系统疯狂提炼并写入，长期库一周内涨了四万多条垃圾记忆。

后来加了两个限制：

• 单会话内同一信息触发写入的次数上限为两次
• 长期库中已有相似度高于0.9的条目时，不再新增写入，而是给原条目的score加一分

第二点很重要。它让记忆库始终是“收敛”的。大量重复信息进来时会不断累加到同一条记忆上，而不是各自为政地长出无数个同等条目。这直接规避了库的爆炸式增长。

4.3 多会话之间记忆串台：用户A的偏好跑到用户B身上

这是最严重的一个坑。早期我们按全局库来做记忆检索，不同用户的数据没有隔离，结果用户A问一句话，系统把用户B的“我讨厌第三方推送”当成了背景信息，导致整个对话风格和决策全错了。

这事对我们触动极大。现在所有的记忆表都强制带user_id，检索时第一步就是按user_id做数据源隔离，规则层校验不过，后面的任何召回操作压根不会执行。这种问题说白了就是系统边界没设计清楚，越早定好隔离机制，后面越省心。

4.4 记忆内容的安全边界与业务合规

再说一个容易被忽视但很重要的点：记忆系统里存的是用户数据，涉及信息安全和合规边界。我们上线前专门拉了一轮评审，定下了三条红线：

• 敏感字段（密码、明文密钥、身份证号等）不做记忆写入，实时拦截
• 记忆删除接口必须支持按user_id全量清理，且双写删除日志
• 记忆的使用范围必须在产品说明中展示给用户，不能偷偷记录

这个也是值得所有做Agent记忆的团队提前考虑的问题，产品可以后补，但基础能力必须在早期就定清楚。

5. 多Agent协作场景下的记忆共享与隔离

项目后期我们开始做多Agent协作，记忆这块又面临一个更复杂的维度。

5.1 Agent之间需要“共享工作区”而不是“共享全部记忆”

几个子Agent协作完成一个复杂任务时，如果共享全部记忆，最先出的问题就是信息量过载。A Agent在检索记忆时会把B Agent的中间状态也捞出来，因为相似度高，结果两个Agent互相看到对方没整理完的结果，产生脏数据。

我们的方案是给多Agent场景单独加一层“共享工作区”，相当于任务级的黑板。每个任务有一个task_id，所有参与该任务的Agent共享这个工作区的读写权限，但各自的长期记忆库仍然隔离。工作区里写的是“我正在做什么、已经完成了什么、下一步是什么”。子Agent拿这个工作区作为协作上下文，完全够用，又不会触及各自隐私化的长期记忆。

5.2 主Agent的“决策记忆”与执行Agent的“操作记忆”分离

协作场景中，主Agent做规划和决策，执行Agent做具体操作。我们发现两者的记忆需求完全不同。主Agent需要的是“用户目标的高层记忆”，比如用户想要一份竞品分析报告、市场策略建议、执行排期参考；执行Agent需要的是“操作过程的具体参数”，比如表格要分几列、报告格式是PDF还是PPT、邮件要发给谁。

如果混在同一个记忆库里，主Agent规划时会看到一堆无关的操作参数，执行Agent执行时会看到一堆不必要的高层目标。所以我们在记忆条目的type字段上做了更细的划分，并在检索时按Agent角色过滤可见的记忆类型。

5.3 记忆共享的权限控制：角色白名单

多Agent协作必然涉及权限控制。我们的设计是：每种记忆类型都维护一个允许读取的Agent角色白名单。比如“用户财务信息”只能由财务类Agent读取，“外部沟通口径”只能由对外Agent读取，“项目进度”则对项目内所有Agent开放。

这套权限设计让多个Agent在保持独立的同时可以高效协作。至少在我们的项目里，它让并行任务处理效率提升了大约35%，信息误用率降到了1%以下。

6. 把记忆系统接进真实业务的关键动作

前面讲了很多架构和原理，最后落回实操层面。如果你正在做一个原本“无记忆”的Agent，想把这套方案接进去，最关键的几个动作是什么？

6.1 第一步永远是梳理记忆类型清单

不要上来就建库、配索引。先花一个下午，跟业务方坐在一起梳理：你的Agent在真实业务里会遇到哪些需要记住的信息？把它们一条一条列出来，然后归到长期记忆、短期记忆、共享工作区这三类里。这一步决定后续所有设计的边界，做的越细，后面返工越少。

6.2 建立记忆回放与分析机制

记忆写得好不好、召回的准不准，凭感觉是没有用的。我们上线初期就接了一套回放机制：每个会话结束后，抽取“Agent实际用到的记忆”和“理论上最应该用到的记忆”两个集合，交给评估模型打分。

回放分析的耗时不高，一个会话大概几毫秒，跑在后台即可。但它带来的价值非常大。所有召回精度、时序错误、乱序进入上下文的问题，都能通过这套机制快速暴露。

6.3 留好记忆擦除的“后悔药”

再强调一次开始提到的安全话题。就算你的记忆系统做得再完善，也要先想清楚怎么擦除：用户想清空记忆怎么办？记忆写错了怎么办？业务下线了怎么办？

我们在这个项目里做了两层擦除：操作层（主动删除的单条记忆）和合规层（批量清空某个用户或某个项目的全部数据）。擦除是异步的，先标记失效再物理清理，这样即便误删也能在短时间内恢复。此外擦除全程留痕，便于跨团队协查定位问题。

这套“先想好怎么删，再谈怎么存”的思路，在真实的业务环境里非常受用。

从我们这次登顶项目的实际经验来看，Agent记忆不是一个可有可无的辅助功能，而是决定Agent能不能真正稳定产出结果的地基。能记住、会遗忘、懂得在合适的时候把合适的信息带进推理，这三个能力结合在一起，Agent才像一个真的在工作的人，而不是一个每轮对话都重新开始的“金鱼”模型。