记忆

想象一下，你聘请了一位才华横溢的顾问。他拥有两个博士学位，会说七种语言，并且能够解决你甚至都不知道存在的问题。你让他坐到会议室里，然后对他说：“我需要你重构项目的认证流程。” 顾问看着你，点点头，问：“哪个项目？” 你没有给他代码访问权限，也没有给他解释系统架构。他不知道你用的是 JWT 令牌还是会话 cookie，不知道你使用什么编程语言，也不知道你有多少微服务，更不知道为什么上次的迁移尝试以失败告终。 这个顾问，就好比你的 LLM（大型语言模型）。而你刚刚犯了一个 90% 使用 AI 代理的人都会犯的错误：你专注于“大脑”，却忽略了“大脑所看到的内容”。 Prompt engineering 已死。Context engineering 长存。 最近几个月，我在每个论坛、每个 Twitter 话题、每次团队会议中都看到同一个讨论：“用 GPT-5 还是 Claude Opus？哪个模型更适合编程？哪个模型的推理能力更强？” 每次我计算这些问题时，答案基本都是一样的：无所谓。好吧，也不能说完全无所谓。但是，对比选择最好的模型和提供一个完美的上下文，后者的重要性高得多。 一个中等水平的模型配上完美的上下文，能够轻松打败一个顶级模型却只有糟糕上下文的组合。没有例外。这永远成立。 这就是**上下文工程（Context Engineering）**的意义所在。而且，请注意，这与 prompt engineering 并不是同样的概念。 Prompt engineering 是编写一个好的提示：选择正确的词语、组织请求的结构、添加示例等。这很重要，但只是其中的一部分。 做 context engineering 则是在设计模型所看到的一切内容：包括哪些信息要输入、顺序如何、有什么被舍弃、如何压缩，以及哪些必须被优先保留。这是为 LLM 设计的信息架构。 简单来说：prompt engineering 是提出一个好的问题，而 context engineering 是决定学生在考试前可以参考哪些书。 记忆的四个阶段：隐藏的生命周期 OpenAI 最近发布了两篇 Cookbook 文章，深入分析了拥有长期记忆的 AI 代理如何管理上下文。这不是 RAG（检索增强生成），也不是矢量数据库管理。它是一个基于状态的系统，就像一本有严格规则的现场笔记本。 这个模式使用的是 local-first 和 state-based 的方法：一个结构化的状态对象随着代理的运行更新，分为几个主要阶段。 flowchart TD A["1. 注入\n（会话创建时）"] --> B["2. 精炼\n（会话中）"] B --> C["3. 整理\n（会话后）"] C --> D["4. 修剪\n（保存时）"] D -->|"新会话开始"| A A1["将状态渲染为 YAML\n+ 全局记忆（最多 6 条）\n+ 优先级规则"] -.-> A B1["save_memory_note()\n校验记忆持久性\n要求有可操作性\n拒绝保存个人信息和假设"] -.-> B C1["异步任务\n合并会话数据 → 全局记忆\n使用 LLM 进行去重\n过滤临时信息"] -.-> C D1["修剪会话历史至 N 条\n重新注入修剪笔记\n到系统提示中"] -.-> D style A fill:#2d3748,stroke:#4a9eed,color:#fff style B fill:#2d3748,stroke:#ed9a4a,color:#fff style C fill:#2d3748,stroke:#9a4eed,color:#fff style D fill:#2d3748,stroke:#4aed5c,color:#fff 阶段 1: 注入（Injection）—— 考试桌上的教科书 在会话开始时，AI 代理会准备好其初始上下文。这不是随意拼凑的，而是一个明确的结构： ...