Anthropic团队拆解上下文工程：从Claude MD到文件系统记忆

在AI DevCon上，Anthropic技术团队成员Lamis系统回顾了上下文工程（Context Engineering）近一年的演进路径。这场演讲没有堆砌概念，而是沿着一条清晰的实践线索展开：从最初简单有效的Claude MD文件，到让Agent自主管理记忆，再到生产环境中的并发、版本与权限难题，最终指向一套正在成形的「文件系统即记忆」架构。

简单的起点：Claude MD为什么有效，又在哪里失效

Anthropic内部有一句被反复验证的话：「做简单但有效的事」。上下文工程的第一站正是Claude MD——一个在会话开始时注入模型上下文的Markdown文件，里面写着环境提示、组织规范、个人偏好等信息。据Lamis介绍，这个做法「惊人地有效」，因为它把对Agent真正重要的信息在会话开端就喂给了模型。

但问题随之而来。当这个文件变得非常重要时，它也开始膨胀：把大量内容一次性塞进上下文，会挤占模型处理实际任务的空间。团队因此回到画板前重新思考——有没有一种方式，既能保留MD文件「人类可读、可写、可编辑」的优势，又不必一次性全部加载？

答案是文件系统记忆：让Agent自主决定何时读、何时写、写什么。这一转变在Claude Code中已有体现，Agent在会话内判断哪些档案值得读取、哪些经验值得沉淀，自主性在这里表现得相当好。

上下文窗口（Context Window） 是理解Claude MD为何会「失效」的关键概念。它指模型单次推理时能同时处理的token总量上限，包括系统提示、对话历史、工具返回结果以及注入的记忆内容。Claude MD在会话开始时被整体注入，意味着它占据的是与任务本身共享的固定预算——文件越大，留给推理、代码阅读和工具输出的空间就越小。这也是为什么Anthropic强调「按需加载」：上下文窗口不是无限黑板，而是一块需要精打细算分配的工作台面。文件系统记忆之所以有效，正是因为它把「常驻内存」改为「按需换页」，让有限的窗口优先服务于当前任务。

技能机制与渐进式披露

上下文持续增长带来的第二个解法是「技能」（Skills）。Lamis用了一个生动的类比：就像书架上摆着一排词典，当有人用外语和我说话时，我可以先扫一眼书脊判断哪本词典相关，再取下来翻阅——不需要事先把整本词典背下来。

这就是渐进式披露（progressive disclosure）的核心：Agent先只看到技能的元信息，只有当任务确实需要时才加载完整内容。这样既保证了上下文的精简，又保留了深度能力。不过Lamis也指出一个现实约束：即便用Agent来撰写技能，人类仍然需要高度介入，判断「什么才算一个真正的技能」。

生产环境的四个硬问题

原型好用不等于生产可用。当多个Agent并发读写同一份记忆、会话跨越很长时间、记忆内容变得复杂时，一系列问题开始浮现。Lamis列出了几类典型风险：多个Agent同时写同一文件如何协调；某个Agent写入的全局上下文若出错，会污染所有正在读取它的Agent；人类与Agent协作时如何追踪变更；以及最危险的——记忆可能被恶意诱导写入错误内容。

团队为此引入了一组工程原则：

版本、哈希与并发控制

每次写入记忆前先取哈希，写入时再取一次哈希，若两次不一致则拒绝写入并要求重新读取、重新起草。这套乐观并发控制的思路，直接借自传统软件工程。

乐观并发控制（Optimistic Concurrency Control） 是一种假定冲突不常发生、只在写入时检测冲突的并发策略，与写入前就加锁的悲观锁形成对照。文中「写入前取哈希、写入时再取哈希、不一致则拒绝」正是其典型实现：读取时记录版本指纹，提交时比对，若期间被他人修改则让本次写入失败并要求重读重写。它适合Agent场景的原因是锁的开销和死锁风险被规避，且Agent可以廉价地重新读取和起草。代价是冲突频繁时重试成本上升，因此实践中常配合权限分层，减少对高频共享记忆的并发写入。

写入权限的分层

并非所有记忆都该由Agent随意改写。组织级的核心上下文应当受到更严格的约束，而Agent个人工作笔记则可以放开自主权。

可审计与可集成

记忆系统需要记录「哪次会话、哪段记录、哪个人」触发了这次变更，并以API优先的方式设计，方便跨系统集成。Lamis强调，如果在记忆的耐久性上投入足够多，收益会体现在跨会话、跨系统的连贯性上。

会话内记忆 vs 会话外「Dreaming」

Lamis把记忆工作分成两条互补的路径。第一条是会话内记忆：Agent在单次会话中读写记忆，帮助自己在下一次同类任务中表现更好。但这条路径有两个天然限制——Agent既要完成任务又要维护记忆，是一个很难的优化问题；而且单个Agent只能看到自己会话内的上下文，无法察觉跨会话的重复错误。

第二条路径是会话外的「Dreaming」：由一个独立的Agent批量审阅历史会话记录，识别模式性问题，并直接修改记忆库。Lamis用学校作类比——学生交作业，老师批改，还有督学跨班级审视整体教学质量。Dreaming扮演的正是「督学」角色：它能看到所有学生的共性问题，比如某个数学知识点全班都以同样方式出错，然后建议把正确解法补充进课程材料。

你可能没注意到，Dreaming审阅的不只是Agent与用户的对话，还包括工具调用记录和其他元数据，这让它能定位到更细粒度的失败原因。

批处理式反思（Batch Reflection） 是理解Dreaming定位的背景概念。与在线学习不同，Dreaming不在任务执行过程中更新记忆，而是离线地、周期性地回放历史会话，做模式归纳后再写回记忆库。这种分离带来两个好处：一是把「完成任务」与「维护记忆」两个目标解耦，避免单Agent在同一上下文里同时优化二者；二是获得跨会话的全局视野，能发现单个会话无法察觉的系统性偏差。其代价是反馈存在延迟，且批量修改需要版本与审计机制兜底，否则一次错误的归纳可能污染整库记忆。

落地路径与适用边界

对于想要落地的团队，Lamis给出了渐进路线：先用好Claude MD和技能这类简单手段；当Agent数量增多、运行周期变长、协作变复杂时，再引入版本、哈希、权限分层等生产级机制；最后考虑加入Dreaming这类会话外流程。

他还特别澄清了一个常见误解：这套方法并非只适用于编程任务。Lamis自己就用记忆系统来沉淀演示文稿的写作偏好和幻灯片风格，这些偏好会随着时间逐步演化。

在问答环节，有听众问这是否等于「从第一性原理重新发明数据库」。Lamis坦率承认，团队确实在回归软件工程中被验证过的做法——版本控制、并发控制、确定性执行——但前提是这些机制要能被自主Agent高效使用。换句话说，不是重新发明轮子，而是在「让Agent自主行动」和「把必要约束固化进框架」之间找到那条分界线。

写在最后

这场演讲的价值在于它呈现了一条真实的工程演进曲线：先让Agent自由地用Markdown写记忆，观察哪些原语真正有效，再把验证过的部分固化为确定性机制。上下文工程不是一个静态的技巧集合，而是一个随着模型能力提升、部署规模扩大而持续重构的领域。对于正在构建Agent应用的团队，这条从简单到复杂的路径，或许比任何单一技巧都更值得参考。