# 01、现场：上周的错误，今天还在自信执行

假设一个客服Agent上周把某类退款请求判成“需人工复核”。

这个判断当时就错了，但工具日志和对话被原样写进长期记忆。

今天新会话开始，注入层把这条笔记带了进来，Agent照着执行。

更麻烦的是，它还会引用这条笔记作为“历史经验”，语气很确定。

团队最初的解法是扩大记忆容量：聊天、工具调用、工单摘要全存。

结果是记忆越滚越大，检索命中率下降，错误和过期规则被反复带入。

这不是容量问题，而是记忆缺少证据校验、版本和撤销机制。

![部署边界图](https://developer.qcloudimg.com/http-save/yehe-9261324/fadfa1bc2151aa2a38921cdb3ef7296d.png)

---

# 02、拆题：记忆不是聊天记录仓库

先把四个容易混淆的概念分开，这是后面所有取舍的前提。

上下文是单次会话窗口内的信息，会话结束即失效。

摘要是对已有内容的压缩，压缩本身不产生新判断，也不纠错。

模型权重更新是训练行为，改变的是参数，成本高且不可逐条撤销。

Agent记忆则是跨会话保留、可检索、可修改的外部状态。

Anthropic在《The components of agent memory》中把长期记忆拆成四层。

第一层是可搜索的会话转录，保留原始对话与工具调用，是证据源。

第二层是Agent写入的记忆笔记，是它对事实和规则的提炼。

第三层是Wiki等记忆表征，把零散笔记组织成可导航的结构。

第四层是每次会话预先注入的少量上下文，直接占用上下文预算。

四层的关系是：转录是证据，笔记是推断，Wiki是索引，注入是投影。

把四层混成一个大向量库，就等于让推断和证据平权，错误无法追溯。

---

# 03、原理：Dreaming是事后的证据复核

Dreaming是空闲时段的后台过程：回看转录与记忆，纠错、整理笔记。

它还会构建或修剪Wiki，并筛选下一轮可注入的少量上下文。

关键边界有三条：它不修改模型权重，不是自我训练。

它也不是单轮上下文压缩，压缩只处理当前会话，Dreaming跨会话。

它更像值班结束后的复盘会：拿着原始记录，逐条核对笔记是否成立。

为什么事后回看有效？因为有些判断在当时缺少信息。

比如工单后来被升级、规则后来被运营确认、工具返回后来被证伪。

这些事后信息只在转录里，Dreaming回看时才能把笔记改正或撤销。

Anthropic展示过通过回看原始转录纠正错误记忆的案例。

流程上，Dreaming先取一批候选笔记，再回到转录找支撑证据。

证据不足的标记为待验证，证据冲突的进入冲突队列。

重复知识合并，过期规则打上失效时间，Wiki补齐链接与归属。

最后只把高置信、小体积的摘要放进注入层，其余留给按需检索。

![跨角色泳道图](https://developer.qcloudimg.com/http-save/yehe-9261324/676645a436b883233458cf0a52290513.png)

---

# 04、取舍：Wiki加搜索不是万能公式

Anthropic公布过一组内部实验，需要严格标注适用范围。

语料约35万份内部文档、约4.2亿Token，用128轮Dreaming逐步构建Wiki。

25个问题的评测中，Wiki单独使用的评分覆盖从13%升至48%。

Wiki加搜索从54%升至61%，搜索单独为53%。

该测试中每题约节省2万Token。

这些数字只适用于该语料与评测设置，不能外推为所有企业知识库的收益。

样本只有25个问题，语料是特定内部文档，轮次也是特定配置。

从机制上看，Wiki的价值在跨文档、需要多跳关联的任务。

如果任务只是单文档检索，原文片段往往比结构化表征更直接。

此时建Wiki的维护成本和Dreaming后台计算，未必能换回收益。

另一个取舍是注入层大小：注入越多，单次上下文预算越紧张。

Anthropic也提醒，错误笔记会在每次会话中被放大。

所以注入层应只放高频、已验证、体积小的规则，其余按需检索。

---

# 05、架构：把记忆做成可撤销的假设

企业落地的核心判断：记忆是经过证据校验、可更新可撤销的未来工作假设。

第一块是追加式Session Log，只追加不修改，作为唯一证据源。

第二块是事件标记与短期笔记，记录候选规则，但默认不注入。

第三块是版本化记忆卡，字段包括来源、时间、适用范围、置信度、责任人。

第四块是异步Dreaming任务，定期回看日志，验证、合并、纠错、修剪。

第五块是冲突与过期检测，同一规则多版本时进入冲突队列。

第六块是门禁：人工审核或自动测试通过后，记忆卡才可注入。

第七块是Wiki索引与小型注入摘要，控制体积，其余走运行时检索。

记忆卡的状态机建议为：候选、已验证、已过期、已撤销。

撤销不删除证据，只把状态置为撤销并保留审计轨迹。

这样任何一次注入都能回答：依据哪条转录、谁批准、何时失效。

![工具调用时序图](https://developer.qcloudimg.com/http-save/yehe-9261324/a70db262e6c572d3491e5500fa358b89.png)

---

# 06、实战：最小可运行的治理闭环

下面用Java片段示意记忆卡的校验与状态流转，仅表达结构，不是完整实现。

```java
record MemoryCard(String id, String claim, String sourceRef,
                  Instant validFrom, Instant validTo,
                  String scope, double confidence, String owner) {
    boolean injectable(Instant now) {
        return confidence >= 0.8
            && now.isAfter(validFrom)
            && (validTo == null || now.isBefore(validTo));
    }
}
```

Dreaming任务的最小流程是：拉取候选卡、回查转录、给出结论。

结论只有三种：确认、修正、撤销，每种都写回审计字段。

自动测试门禁可以用历史问题集回归，检查注入后是否引入矛盾。

运行时先查注入摘要，未命中再检索Wiki与转录，避免注入层膨胀。

---

# 07、复盘：风险与验收指标

风险一是敏感信息，转录里可能有个人信息，需脱敏后再进记忆层。

风险二是记忆投毒，恶意内容写入笔记后会被反复注入，需来源校验。

风险三是过期规则，业务规则变化后旧卡仍在注入，需有效期与巡检。

风险四是错误传播，一条错卡影响多个会话，需快速撤销通道。

风险五是Token预算，注入层过大挤压推理空间，需设体积上限。

风险六是后台计算成本，Dreaming轮次与语料规模要按收益调节。

验收指标建议：未来任务成功率、记忆命中准确率、过期记忆命中率。

再加矛盾率、引用可追溯率、注入Token占比与Dreaming单轮成本。

这些指标要按业务线分开看，避免用平均值掩盖局部退化。

---

# 08、洞见：记忆的竞争力在治理而非容量

腾讯云开发者社区李伟山的文章概括了一个务实原则。

记忆应优先保存经过验证、未来可能复用、且无法直接从环境读取的规则。

而不是囤积海量聊天。这与四层模型的取舍一致。

从生态看，记忆层正在从“向量库插件”变成“带审计的数据资产”。

谁能回答记忆从哪来、谁改过、何时失效，谁才敢让Agent自主执行。

Dreaming这类后台过程的价值，不是让模型变聪明，而是让记忆变干净。

---

# 09、小结：先建证据链，再谈自动做梦

Agent忘记规则，往往不是记性差，而是没把证据和推断分开。

四层结构给出分工：转录留证据，笔记写推断，Wiki做索引，注入要克制。

Dreaming是事后的复核机制，不是权重训练，也不是上下文压缩。

Wiki加搜索的收益有明确实验边界，单文档场景未必值得。

企业落地先做追加日志、版本化记忆卡和撤销通道，再逐步自动化。

延伸阅读可查Anthropic工程博客《The components of agent memory》。

也可查腾讯云开发者社区李伟山对Claude Agent记忆系统与Dreaming的拆解。

对照阅读时注意区分官方实验结论与企业架构建议的边界。

Anthropic在《The components of agent memory》中把长期记忆拆成四层。

80:Agent 开始“做梦”，别把错误也存成经验！

企业Agent跨会话遗忘已验证规则，团队把全部聊天与工具日志塞进长期记忆，导致错误和过期信息反复放大。本文区分转录、记忆笔记、Wiki表征与注入上下文四层结构，

架构师

人工智能

架构设计

后端

建立基于证据校验的Agent记忆治理体系，区分转录、笔记、Wiki与注入四层结构，通过Dreaming后台机制回查日志并纠错，采用版本化记忆卡与撤销通道，防止错误规则反复注入。优先存储已验证、高复用且不可从环境直接读取的规则，以治理能力而非存储容量构建记忆系统竞争力。

代码解释

Agent

Java

腾讯云双十一大促

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

80:Agent 开始“做梦”，别把错误也存成经验！-腾讯云开发者社区-腾讯云

80:Agent 开始“做梦”，别把错误也存成经验！

80:Agent 开始“做梦”，别把错误也存成经验！

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐