超越提示词：Anthropic 在智能体记忆、梦境与图工作流中的方法

重要的机制是渐进式披露。

Claude 会看到一个简短的描述，帮助它决定某个技能是否相关。完整的技能正文和支持文件仅在需要该流程时才被加载。

Mukta 将此比作一个书架。

一个人不需要在开始对话之前记住每一本书。他们只需要知道哪本书可能包含相关信息，并在合适的时机将其取出。

技能有助于解决“不断增长的上下文文件”问题：

• 稳定、高层级的事实可以保留在 CLAUDE.md 中。
• 详细的流程可以移入技能中。
• 支持材料可以在需要之前保留在活动上下文之外。

Anthropic 官方的技能文档建议，在团队反复将相同的指令、检查清单或多步骤流程粘贴到对话中时，或当 CLAUDE.md 的某个部分已发展为流程而非简明事实时，创建技能。

技能仍需人工管理

技能是可复用的，但仍需有人来决定：

• 哪些工作流值得创建技能
• 流程应如何构建
• 应包含哪些文件
• 技能何时过时
• 谁有权限编辑它

代理可以帮助编写和维护技能，但该系统仍然部分依赖人工管理。

这引出了第四种方法。

第四代：将文件系统视为记忆

Mukta 将基于文件系统的记忆描述为 Anthropic 目前在许多代理记忆系统中偏好的模式。

其理由非常务实。

代理已经擅长：

• 列出文件
• 搜索文件名
• 运行 grep
• 阅读 Markdown
• 浏览目录
• 编辑文本
• 比较版本

与其发明一种高度专门化的记忆接口，团队可以将记忆组织为文件，并为代理提供普通的文件系统工具。

一种可能的布局如下：

memory/
├── organization/
│   ├── principles.md
│   ├── terminology.md
│   └── security-policy.md
├── teams/
│   ├── engineering/
│   │   ├── architecture.md
│   │   └── release-process.md
│   └── support/
│       ├── escalation-rules.md
│       └── response-style.md
├── projects/
│   └── billing-redesign/
│       ├── decisions.md
│       ├── known-issues.md
│       └── current-status.md
└── agents/
└── agent-104/
└── scratchpad.md

这种布局支持不同层级的记忆：

• 组织级规则
• 团队知识
• 项目上下文
• 用户偏好
• 特定代理的工作笔记

它也体现了渐进式披露。

代理可以搜索目录，仅加载与当前任务相关的文件。

文件是接口，不一定是物理存储

文件系统风格的接口并不要求每个企业记忆都以未管理的文件形式存在于笔记本电脑上。

底层实现仍然可以使用：

• 数据库
• 版本化对象存储

访问控制服务

• 搜索索引
• 审计日志
• 事务性 API

关键点在于，智能体获得的是一个简单、可导航的抽象。

在问答环节中，一位听众问这是否等同于重新发明数据库。

Mukta 认可这一架构回归了熟悉的软件工程原则。一旦团队了解了哪些行为应当是确定性的，他们就可以将这些行为移入控制框架中，而不是让模型每次都即兴发挥。

生产级记忆的四条护栏

一个装满 Markdown 文件的文件夹对单个用户可能有效。

但当数千个智能体都能更新共享的组织记忆时，这就变得危险了。

Mukta 强调了四条生产原则：

1. 版本控制
2. 并发控制
3. 权限管理
4. 可移植性

1. 为每次记忆变更建立版本

每次记忆更新都应有历史记录。

有用的元数据包括：

• 先前版本
• 新版本
• 时间戳
• 人类或智能体作者
• 来源会话
• 支持的对话记录
• 变更原因
• 审批状态

没有来源溯源的记忆条目难以获得信任。

假设一个智能体添加了：

- 周五的生产部署无需审批。

如果没有来源、审核者和修订历史，另一个智能体可能会将该陈述视为权威。

版本控制支持：

• 审查
• 回滚
• 审计
• 比较
• 根因分析

版本化的记忆系统应能轻松回答：

哪次交互导致这条规则出现？

1. 防止并发智能体相互覆盖

两个智能体可能在 10:00 读取了同一条记忆。

智能体 A 在 10:02 写入了一项更新。

智能体 B 不知道这一变更，在 10:03 写入了自己的版本，并意外删除了智能体 A 的更新。

Mukta 描述了一种基于哈希的并发模式：

智能体读取记忆并记录哈希 A
↓
智能体起草更新
↓
智能体再次读取记忆并记录哈希 B
↓
如果哈希 A == 哈希 B：
提交更新
否则：
重新加载、重新基于并重试

这就是乐观并发控制。

模型可以决定提出什么变更，但控制框架应以确定性的方式防止过期的写入替换较新的版本。

1. 区分读写权限

并非每个智能体都应被允许编辑每条记忆。

一个合理的权限模型可能如下：

一个智能体不应能将一个不确定的观察转化为组织范围的规则。

权限边界同样需要应用于 Dreaming。整合任务只能接收其身份被授权访问的对话记录和记忆。

1. 使记忆可移植

记忆可能成为

一个组织最有价值的AI资产之一。

它包含：

• 决策
• 修正
• 工作流程
• 偏好
• 失败模式
• 工具知识
• 领域特定指令

Mukta认为，团队应避免将该资产设计为仅能在单一产品内部运行。

一个可移植的记忆系统应具备：

• 清晰的API
• 可导出的格式
• 文档化的模式
• 稳定的标识符
• 标准的访问控制
• 与工具无关的来源追溯

可移植性使得同一份精心整理的情境能够支持：

• Claude Code
• Claude托管代理
• 内部工具
• 其他代理系统
• 人工文档工作流

为什么会话内记忆不够用

即使设计良好的记忆工具也存在两个结构性限制。

限制一：代理容易分心

代理必须同时完成任务并整理记忆。

写入记忆会消耗原本可用于当前目标的资源。

代理可能会：

• 保存过多内容
• 保存过少内容
• 存储未经验证的结论
• 在时间压力下跳过记忆工作
• 只关注局部细节而非更宏观的模式

限制二：代理只能看到一个会话

一个代理可能会注意到某个命令失败了一次。

它无法看到同样的命令在其他300个会话中也都失败了。

一个支持代理可能会看到某位客户对某项政策感到困惑。

它无法看到同样的困惑在整个区域范围内反复出现。

一个覆盖全系统的学习机制需要一个具备更广可见性的流程。

这个流程正是Anthropic所称的**“梦”**（Dreaming）。

梦：一个用于整理记忆的带外流程

梦是一个异步流程，它在正常工作完成之后对代理历史进行回顾。

Anthropic当前的API发布说明中，将Claude托管代理的“梦”功能描述为一项研究预览。

一次“梦”会读取：

• 现有的记忆存储
• 过往的会话记录

随后它会创建一个重新组织后的输出记忆存储，在其中可以：

• 合并重复条目
• 替换过期信息
• 浮现缺失的洞察
• 重新组织内容
• 提出改进后的记忆

这不是模型重新训练。

底层模型的权重没有变化。

改进来源于改变持久化情境，使未来的会话可以检索到这些内容。

学校类比

Mukta用一所学校来解释普通记忆与“梦”之间的区别。

想象一下：

• 学生完成作业。
• 教师批改每一份作业。
• 一位教务主任审视全校的整体结果。

一位教师可以帮助一个学生纠正一个错误。

教务主任则可以注意到，每一位地理课学生都在同一个知识点上出错，因为课程大纲中根本没有包含这个内容。

系统层面的修正不是逐一批改每份试卷。

而是更新课程大纲。

agent 术语：

• 学生作业 = 单独会话
• 教师反馈 = 会话内记忆更新
• 学校课程 = 共享记忆存储
• 校长评审 = 梦境处理（Dreaming）
• 课程更新 = 拟议的记忆变更

这使得系统能够从单个代理无法察觉的模式中学习。

梦境处理的机械原理

简化的梦境处理管道如下所示：

流程图 TD
A[现有记忆存储] --> D[梦境编排器]
B[会话记录] --> D
C[工具调用和元数据] --> D
D --> E1[评审代理 1]
D --> E2[评审代理 2]
D --> E3[评审代理 3]
E1 --> F[模式聚合器]
E2 --> F
E3 --> F
F --> G[拟议的记忆变更]
G --> H{人工审批}
H -->|接受| I[更新后的记忆存储]
H -->|拒绝| J[保留现有记忆]

评审过程可以检查的内容不仅限于用户和助手的消息。

有用的证据包括：

• 工具调用
• 工具失败
• 重试次数
• 执行元数据
• 人工纠正
• 评估得分
• 被接受和被拒绝的输出
• 技能使用情况
• 模型版本
• 延迟和成本

梦境代理随后寻找此类模式，例如：

• 同一条命令反复失败。
• 多个代理误解某个内部术语。
• 某条记忆条目已不再有效。
• 两个文件包含重复的规则。
• 团队反复纠正同一格式问题。
• 某个工具配置在多个项目中引发错误。
• 缺少某项策略，迫使代理进行猜测。

Mukta 提到，Anthropic 的设计可以包含相关会话记录的示例以及显示模式发生频率的统计数据。

这些证据有助于人类判断拟议的记忆变更是否合理。

梦境处理应提出建议，而非静默重写一切

梦境处理过程具有广泛的访问权限，可能影响整个代理集群的未来行为。

这使得自动且未经审查的更新具有风险。

更安全的工作流程是：

1. 分析经授权的会话记录。
2. 识别重复出现的模式。
3. 将模式关联到支持性会话。
4. 起草拟议的记忆变更。
5. 估算问题的普遍程度。
6. 请求人工或政策控制的评审者批准。
7. 提交带来源记录的已批准更新。
8. 衡量未来性能是否有所提升。

例如：

## 拟议记忆更新

**目标：** `teams/engineering/test-process.md`

**观察到的问题：**
代理在 63 个相关会话中的 18 个会话里使用了单元测试命令来执行集成测试。

**证据：**
会话 `s-102`、`s-111`、`s-118`、`s-124`、……

**拟议新增内容：**
- 对所有需要数据库容器的测试使用 `npm run test:integration`。
- 对 `tests/integration/` 下的文件不要使用 `npm test`。

**置信度：** 高

**人工决策：** 待定

这既保留了对人工监督，又允许代理集群完成大部分分析工作。

为什么梦境处理虽然使用更多 token 却能降低成本

梦境处理需要额外的模型调用。

乍一听，这似乎是不必要的开销。

Mukta 认为，更清洁的记忆存储可以降低总成本，因为未来的代理更有可能在首次尝试时正确完成任务。

第一次尝试。

一个有用的经济性对比是：

做梦的成本
对比
反复失败、重试、返工和超长上下文的成本

潜在节省可以来自：

• 更少的重试
• 更少的重复解释
• 更少的不相关上下文
• 更好的工具选择
• 更高的首次尝试准确率
• 更快地上手新代理
• 更少的人工重复修正

Anthropic 尚未发布一个通用基准，能够说明每个组织能节省多少。具体价值取决于：

• 任务重复程度
• 记忆质量
• 错误成本
• 会话数量
• 审查设计
• 模型和工具的定价

当大量代理执行相关工作并反复遇到相同模式时，"做梦"最有可能产生回报。

无托管代理的简单每周做梦流程

一个团队不需要等待完整的平台集成就能测试这个概念。

手动版本可以每周运行一次。

第 1 步：导出相关会话

只收集审查者有权查看的对话记录。

按以下方式组织：

• 项目
• 团队
• 工作流
• 权限范围
• 时间段

第 2 步：提供当前记忆

包括：

• CLAUDE.md
• 相关技能
• 项目记忆文件
• 团队说明
• 已知问题文档

第 3 步：要求提供有证据支撑的提案

提示词可以这样写：

审查这些授权会话记录和当前记忆文件。

识别反复出现的失败、用户重复修正、过时指令、
缺失流程和重复条目。

对于每项拟议修改：
1. 指明目标文件。
2. 给出支持的会话 ID。
3. 说明该模式出现的频率。
4. 起草最小有效的修改。
5. 不要直接编辑文件。

第 4 步：审查提案

拒绝以下修改：

• 基于单一含糊事件
• 缺乏证据支持
• 范围过广
• 涉及安全敏感
• 超出审查者权限范围
• 更适合以确定性代码实现

第 5 步：提交已批准的修改

使用版本控制，并在提交或审计记录中包含来源证据。

第 6 步：衡量结果

跟踪相同失败是否在后续会话中减少。

如果没有衡量，"做梦"就会变成一项文档生成工作，而不是一个学习系统。

从随时间积累的记忆到任务内的结构

记忆回答的是：

代理应该从之前的工作中记住什么？

图结构工程回答的是一个不同的问题：

当前任务的哪些部分实际上相互依赖？

BAAI 源文章将记忆话题与人工智能开发社区中流传的一份图结构工程指南联系在一起。

该指南的核心论点是，许多"工作流"本质上已经是图——只是设计得很差。

以列表形式编写的工作流往往会被人为地变成串行流程：

研究
↓
总结
↓
对比
↓
事实核查
↓
写作

其中一些步骤可能确实依赖前序输出。

另一些则可能是无谓地在等待。

节点、边与真实数据流

在工作流图中：

• 节点代表一项任务。
• 边代表真实的依赖关系。
• 数据沿着边流动。

例如：

研究节点产出研究成果。

写作节点消费这些研究成果并产出一份草稿。

验证节点消费草稿并产出经过核查的结果。

这些箭头是合理的，因为每个下游节点都需要上游节点的输出。

伪边测试

社区图指南为每条箭头提出了一个简单的测试：

下一个任务是否真的需要前一个任务的输出？

如果答案是否定的，那么这条依赖关系就是伪依赖。

考虑以下工作流：

研究竞争对手A
↓
研究竞争对手B
↓
研究竞争对手C
↓
撰写对比报告

研究竞争对手B通常不需要研究竞争对手A的输出。

研究竞争对手C通常不需要研究竞争对手B的输出。

这些任务可以并行执行：

flowchart TD
A[定义对比标准] --> B1[研究竞争对手A]
A --> B2[研究竞争对手B]
A --> B3[研究竞争对手C]
B1 --> C[撰写对比报告]
B2 --> C
B3 --> C

移除伪边可以减少等待时间。

如果三个研究任务分别耗时10、12和15分钟：

• 顺序执行大约需要37分钟。
• 并行执行大约等待15分钟，加上编排开销。

图并不会让任何单个智能体变得更快。

它改变的是调度方式。

菱形模式

移除伪边后，一种常见的形态会出现：

1. 一个任务拆分成若干独立分支。
2. 这些分支并行运行。
3. 结果汇聚。
4. 最终节点对结果进行综合。

这通常被称为菱形。

一个研究示例可能如下所示：

flowchart TD
A[研究问题] --> B1[市场数据]
A --> B2[客户证据]
A --> B3[竞争对手分析]
B1 --> C[核查者]
B2 --> C
B3 --> C
C --> D[最终综合]

总耗时主要由最慢的分支决定，而不是所有分支耗时之和。

并行工作需要核查者

并行引入了一个新的

风险。

一个工作线程可能会产生薄弱、过时或不受支持的输出。

如果系统在没有验证的情况下合并所有内容，一个坏的分支就可能污染最终答案。

因此，图指南在综合之前放置了一个检查器。

一个检查器可以询问：

• 这个主张是否有支持？
• 来源是否是最新的？
• 输出是否符合所要求的格式？
• 工作线程是否完成了分配的任务？
• 代码是否通过测试？
• 结果是否与其他分支冲突？
• 是否存在敏感数据？
• 这个输出是否可以安全地继续进行？

一个有用的检查器应该有明确的验收标准。

例如：

flowchart TD
A[研究问题] --> B1[市场数据]
A --> B2[客户证据]
A --> B3[竞争对手分析]
B1 --> C[核查者]
B2 --> C
B3 --> C
C --> D[最终综合]

一个可复用的核查清单可以包括：来源与时效性、输出格式、任务完成度、测试结果、分支冲突、敏感数据和后续操作安全性。

这也是 Anthropic 图工作流的核心：先明确真实依赖，再并行处理独立任务，最后由核查者验证并综合结果。这样，记忆、工具和工作流就不再是孤立的提示词技巧，而会成为可持续演进的系统。