原作者：演讲者 Lamis（Anthropic），帖子由 Hux（@huxlab）发布 · 原文链接：https://x.com/huxlab/status/2110223784791937384

Anthropic Lamis：上下文工程与 Agent 记忆系统

这篇是根据演讲英文转写（约 31 分钟，含问答）整理的。我看不了视频画面，幻灯片上的内容可能没覆盖到，所有内容都以转写为准。时间戳指视频里的位置。

0. 先澄清：「改写 loop」是发帖人的概括

发帖人把这场演讲概括为：Anthropic 内部已经不太写 prompt，而是写能自我提示的循环。

核对转写后：Lamis 没说过「不写 prompt、写循环」，也没说过「自我提示的循环」。 这是发帖人自己的说法。她实际讲的是：

主题是 context engineering，这是把模型智能变成可用产品的主要手段（01:14）。
转写里 "loop" 只出现两次：一次说 agent 在后台跑「self-learning, continual learning loop」（14:51），另一次在总结里说「if you really want to close the loop，就加一个 out-of-band 的流程，比如 dreaming，用来整理记忆」（26:09）。
她反复说的原则是「do the simple thing that works」（03:25、24:59）。

所以更准确的概括是：从静态的上下文文件，演进到 agent 自主管理的记忆，再加上异步的 dreaming 整理，形成一个持续学习的闭环。

1. 为什么要做上下文工程

模型越来越聪明，但不知道你的组织、代码库和偏好，这部分上下文和模型智能基本无关（02:28）。
常见的问题：agent 不熟悉代码库，不了解用户偏好，同一个任务第二次做也不会更好，没有持续学习（02:56）。
在上下文上的投入会放大模型的智能，模型升级以后这份投入依然有效。

2. 演进路线（大约一年内）

flowchart LR
  A[CLAUDE.md<br/>会话开始时注入] --> B[Memory tool<br/>agent 在会话内自主读写]
  B --> C[Skills<br/>渐进披露]
  C --> D[文件系统式记忆<br/>markdown + bash/grep]
  D --> E[生产护栏<br/>版本/并发/权限/可移植]
  E --> F[Dreaming<br/>out-of-band 异步整理]

2.1 CLAUDE.md

随 Claude Code 推出。一个 markdown 文件，写几条关于代码库、组织、用户偏好的指令，在会话开始时注入上下文。她的评价是效果好得出奇（unreasonably effective）（03:35）。
问题是上下文膨胀：文件越写越长，很难长期维护（04:08）。
保留下来的经验：简单、人能读、人和 agent 都能写的 markdown 文件非常有效。

2.2 Memory tool（记忆工具）

让 agent 自主决定什么时候读、写、更新记忆，而且是 in-band 的，也就是在会话进行中完成（04:41）。
结论是自主管理效果很好。后来他们对工具的具体形式也越来越不做规定。

2.3 Skills 与渐进披露

适合有固定流程的工作，即你对端到端怎么做已经有明确想法的那类（05:51）。
agent 平时只看文件顶部 frontmatter 里的几句话，决定加载后才读正文，所以正文可以写得很细，也不会占满上下文。
她的比喻是书架：只扫书名，用到时才取下来。有人跟你说法语，你去拿法语词典，而不是把七年法语课一直装在脑子里。
局限：哪些东西值得做成 skill，仍然要靠人（加 agent）来判断，主观成分比较大（06:57）。

2.4 文件系统式记忆（她称之为目前的最佳实践）

把记忆系统直接建成文件系统，里面放 markdown（07:19）。
agent 本来就很会用 bash、grep 这类通用工具，不必再设计专用的读写记忆工具。
搜索本身就是一种渐进披露。给记忆做好索引，方便 agent 检索。
三条经验（08:01）：格式用 markdown；读的时候允许记忆变大，同时提供快速索引和搜索；写的时候交给 agent 自主决定。

3. 上生产会遇到的问题和四道护栏

会出问题的场景（08:30 起）：多个 agent 同时写同一个记忆文件；某个 agent 把错误写进全组织共享的上下文，所有 agent 都跟着读到；人和 agent 一起编辑记忆，很难追踪谁改了什么；记忆过期、写错，或者被人通过 prompt injection 恶意写入。

护栏	转写里的说法
Versioning 版本	保存每个版本，可以回滚；记下这次更新依据的上下文（哪个会话、哪份 transcript），以及是谁改的（哪个 agent 或哪个人）
Concurrency 并发	用哈希做乐观锁：读的时候取哈希，起草修改，写入前再取一次哈希，两次不一致就拒绝写入，重新拉取、重新起草、再提交
Permissioning 权限	记忆分层，从组织级的核心原则到 agent 自己的 scratch pad，中间还有团队、部门等层级。组织级通常只读，scratch pad 可写
Portability 可移植	精心整理的记忆是长期资产，要能跨产品、跨系统访问，所以需要干净的 API

她提到的效果（13:50 前后）：准确率提高，第二次做同一个任务会更好；token 更少、更容易一次做对，速度和成本都改善；开发者能腾出精力去做产品。

sequenceDiagram
  participant A as Agent
  participant M as Memory Store
  A->>M: 读取记忆 + hash1
  A->>A: 起草修改
  A->>M: 写前取 hash2
  alt hash1 == hash2
    A->>M: 提交（记版本、来源 transcript、作者）
  else 不一致
    A->>M: 重新拉取，重新起草，重试
  end

4. Dreaming：out-of-band 的异步记忆整理

in-band 记忆的局限（15:00 起）：

注意力和资源要分给两件事：agent 既要完成任务，又要为以后的自己整理记忆，很难权衡，还会增加延迟。
视野有限：agent 只能看到当前会话，看不出跨会话的模式（所以同一个错误会反复犯），也不知道其他 agent 遇到了什么失败。
另外，记忆会过期，需要有一个环节定期检查。

学校的比喻：学生交作业，老师批改，校长看全局。有专人负责帮别人学习，又有人能看到整体并调整课程，这样的分工有效。

流程（20:00 起）：

flowchart TB
  MS[(现有 Memory Store<br/>markdown 目录)] --> O
  T[一段时间内的会话 transcripts<br/>含工具调用和元数据] --> O[Orchestrator]
  O --> S1[Sub-agent 分析一批 transcripts]
  O --> S2[Sub-agent ...]
  O --> S3[Sub-agent ...]
  S1 & S2 & S3 --> O2[Orchestrator 汇总<br/>判断模式是否普遍到需要改记忆]
  O2 --> P[逐条提出修改建议<br/>附示例 transcript 和出现频率]
  P --> H{人工审核<br/>接受 / 拒绝}
  H --> MS

可以告诉做 dreaming 的 agent，在你的场景里哪些东西重要、哪些不重要。
她举的例子：地理学生都答错同一题，说明课程里缺了这个知识点，于是补进记忆；数学题统一用了弧度而不是角度，对应到 agent 是工具配置出错，要重点看工具调用；全员都在滥用破折号（em dash），就发一条组织级的规范。
两条流程并行：in-band 记忆见效快，下一个会话就更好，但资源有限、视野窄；dreaming 视野广，有专门分配的 token 预算。看起来更贵，但 agent 更容易一次做对，总成本反而可能下降（24:27）。

5. 总结与问答要点

最基本的做法：CLAUDE.md、skills，加上让 agent 自主管理记忆。等到 agent 数量多、运行时间长、长期维护同一个代码库或领域复杂时，再加上安全、可验证、可审计的护栏（24:59）。
不限于写代码。她自己做演示文稿时也用记忆，记住写作和幻灯片风格。
问答 1：企业级方案她指向 Claude Managed Agents 的 memory 和 dreaming API，版本、哈希这些功能都在里面（27:52）。
问答 2：dreaming 怎么配合权限？做 dreaming 时你自己决定附上哪些 transcripts，可以只选和目标 memory store 权限一致的会话（29:08）。
问答 3：「这是不是又在重新发明数据库？」她的回答是要划好边界，哪些交给 agent 自主决定，哪些固化成 harness 里确定性的程序逻辑。已经验证有效的部分（哈希、版本）就回归传统软件工程的做法，不用重新造轮子（30:12）。

Anthropic Lamis：上下文工程与 Agent 记忆系统（AI DevCon 演讲笔记）