Anthropic 正在通过 CLAUDE.md、Skills、梦境机制和智能体图，将记忆从提示词技巧升级为可组织、可复用的工作流。
重要的机制是渐进式披露。
Claude 会看到一个简短的描述，帮助它决定某个技能是否相关。完整的技能正文和支持文件仅在需要该流程时才被加载。
Mukta 将此比作一个书架。
一个人不需要在开始对话之前记住每一本书。他们只需要知道哪本书可能包含相关信息，并在合适的时机将其取出。
技能有助于解决“不断增长的上下文文件”问题：
CLAUDE.md 中。Anthropic 官方的技能文档建议，在团队反复将相同的指令、检查清单或多步骤流程粘贴到对话中时，或当 CLAUDE.md 的某个部分已发展为流程而非简明事实时，创建技能。
技能是可复用的，但仍需有人来决定：
代理可以帮助编写和维护技能，但该系统仍然部分依赖人工管理。
这引出了第四种方法。
Mukta 将基于文件系统的记忆描述为 Anthropic 目前在许多代理记忆系统中偏好的模式。
其理由非常务实。
代理已经擅长：
grep与其发明一种高度专门化的记忆接口，团队可以将记忆组织为文件，并为代理提供普通的文件系统工具。
一种可能的布局如下：
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
这种布局支持不同层级的记忆：
它也体现了渐进式披露。
代理可以搜索目录，仅加载与当前任务相关的文件。
文件系统风格的接口并不要求每个企业记忆都以未管理的文件形式存在于笔记本电脑上。
底层实现仍然可以使用：
访问控制服务
关键点在于，智能体获得的是一个简单、可导航的抽象。
在问答环节中，一位听众问这是否等同于重新发明数据库。
Mukta 认可这一架构回归了熟悉的软件工程原则。一旦团队了解了哪些行为应当是确定性的，他们就可以将这些行为移入控制框架中，而不是让模型每次都即兴发挥。
一个装满 Markdown 文件的文件夹对单个用户可能有效。
但当数千个智能体都能更新共享的组织记忆时，这就变得危险了。
Mukta 强调了四条生产原则：
每次记忆更新都应有历史记录。
有用的元数据包括：
没有来源溯源的记忆条目难以获得信任。
假设一个智能体添加了：
- 周五的生产部署无需审批。
如果没有来源、审核者和修订历史，另一个智能体可能会将该陈述视为权威。
版本控制支持：
版本化的记忆系统应能轻松回答：
哪次交互导致这条规则出现？
两个智能体可能在 10:00 读取了同一条记忆。
智能体 A 在 10:02 写入了一项更新。
智能体 B 不知道这一变更，在 10:03 写入了自己的版本，并意外删除了智能体 A 的更新。
Mukta 描述了一种基于哈希的并发模式：
智能体读取记忆并记录哈希 A
↓
智能体起草更新
↓
智能体再次读取记忆并记录哈希 B
↓
如果哈希 A == 哈希 B：
提交更新
否则：
重新加载、重新基于并重试
这就是乐观并发控制。
模型可以决定提出什么变更，但控制框架应以确定性的方式防止过期的写入替换较新的版本。
并非每个智能体都应被允许编辑每条记忆。
一个合理的权限模型可能如下：
| 记忆范围 | 典型访问方式 |
|---|---|
| 组织原则 | 大多数智能体只读；仅通过审核流程写入 |
| 安全策略 | 相关智能体只读；受限制的人工控制写入 |
| 团队流程 | 团队只读；指定维护者写入 |
| 项目决策 | 项目智能体只读；提议的编辑需经批准 |
| 智能体草稿区 | 单个智能体读写 |
| 用户偏好 | 用户范围智能体访问 |
| 敏感客户上下文 | 严格的基于角色的访问 |
一个智能体不应能将一个不确定的观察转化为组织范围的规则。
权限边界同样需要应用于 Dreaming。整合任务只能接收其身份被授权访问的对话记录和记忆。
记忆可能成为
一个组织最有价值的AI资产之一。
它包含：
Mukta认为，团队应避免将该资产设计为仅能在单一产品内部运行。
一个可移植的记忆系统应具备：
可移植性使得同一份精心整理的情境能够支持：
即使设计良好的记忆工具也存在两个结构性限制。
代理必须同时完成任务并整理记忆。
写入记忆会消耗原本可用于当前目标的资源。
代理可能会：
一个代理可能会注意到某个命令失败了一次。
它无法看到同样的命令在其他300个会话中也都失败了。
一个支持代理可能会看到某位客户对某项政策感到困惑。
它无法看到同样的困惑在整个区域范围内反复出现。
一个覆盖全系统的学习机制需要一个具备更广可见性的流程。
这个流程正是Anthropic所称的**“梦”**（Dreaming）。
梦是一个异步流程，它在正常工作完成之后对代理历史进行回顾。
Anthropic当前的API发布说明中，将Claude托管代理的“梦”功能描述为一项研究预览。
一次“梦”会读取：
随后它会创建一个重新组织后的输出记忆存储，在其中可以：
这不是模型重新训练。
底层模型的权重没有变化。
改进来源于改变持久化情境，使未来的会话可以检索到这些内容。
Mukta用一所学校来解释普通记忆与“梦”之间的区别。
想象一下：
一位教师可以帮助一个学生纠正一个错误。
教务主任则可以注意到，每一位地理课学生都在同一个知识点上出错，因为课程大纲中根本没有包含这个内容。
系统层面的修正不是逐一批改每份试卷。
而是更新课程大纲。
agent 术语：
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
这使得系统能够从单个代理无法察觉的模式中学习。
简化的梦境处理管道如下所示：
流程图 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 的设计可以包含相关会话记录的示例以及显示模式发生频率的统计数据。
这些证据有助于人类判断拟议的记忆变更是否合理。
梦境处理过程具有广泛的访问权限，可能影响整个代理集群的未来行为。
这使得自动且未经审查的更新具有风险。
更安全的工作流程是：
例如：
## 拟议记忆更新
**目标：** `teams/engineering/test-process.md`
**观察到的问题：**
代理在 63 个相关会话中的 18 个会话里使用了单元测试命令来执行集成测试。
**证据：**
会话 `s-102`、`s-111`、`s-118`、`s-124`、……
**拟议新增内容：**
- 对所有需要数据库容器的测试使用 `npm run test:integration`。
- 对 `tests/integration/` 下的文件不要使用 `npm test`。
**置信度：** 高
**人工决策：** 待定
这既保留了对人工监督，又允许代理集群完成大部分分析工作。
梦境处理需要额外的模型调用。
乍一听，这似乎是不必要的开销。
Mukta 认为，更清洁的记忆存储可以降低总成本，因为未来的代理更有可能在首次尝试时正确完成任务。
第一次尝试。
一个有用的经济性对比是：
做梦的成本
对比
反复失败、重试、返工和超长上下文的成本
潜在节省可以来自：
Anthropic 尚未发布一个通用基准，能够说明每个组织能节省多少。具体价值取决于：
当大量代理执行相关工作并反复遇到相同模式时，"做梦"最有可能产生回报。
一个团队不需要等待完整的平台集成就能测试这个概念。
手动版本可以每周运行一次。
只收集审查者有权查看的对话记录。
按以下方式组织：
包括：
CLAUDE.md提示词可以这样写：
审查这些授权会话记录和当前记忆文件。
识别反复出现的失败、用户重复修正、过时指令、
缺失流程和重复条目。
对于每项拟议修改：
1. 指明目标文件。
2. 给出支持的会话 ID。
3. 说明该模式出现的频率。
4. 起草最小有效的修改。
5. 不要直接编辑文件。
拒绝以下修改：
使用版本控制，并在提交或审计记录中包含来源证据。
跟踪相同失败是否在后续会话中减少。
如果没有衡量，"做梦"就会变成一项文档生成工作，而不是一个学习系统。
记忆回答的是：
代理应该从之前的工作中记住什么？
图结构工程回答的是一个不同的问题：
当前任务的哪些部分实际上相互依赖？
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分钟：
图并不会让任何单个智能体变得更快。
它改变的是调度方式。
移除伪边后，一种常见的形态会出现：
这通常被称为菱形。
一个研究示例可能如下所示：
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 图工作流的核心：先明确真实依赖，再并行处理独立任务，最后由核查者验证并综合结果。这样，记忆、工具和工作流就不再是孤立的提示词技巧，而会成为可持续演进的系统。
从一句话开始，几分钟内拿到完整网站。
