上下文工程：区分优秀与普通AI代理的隐形技能
想象一下，你聘请了一位才华横溢的咨询师。他拥有两个博士学位，会说七种语言，并能解决你甚至不知道存在的问题。你把他安排到一个会议室，然后告诉他：“我需要你重新设计项目的认证系统。” 咨询师看着你，点了点头，问道：“哪个项目？” 你没有提供代码访问权限，也没有解释其架构。他不知道你在使用JWT令牌还是会话cookie，也不了解你使用的编程语言或微服务数量，更不知道为什么你上一次迁移会失败。 这个咨询师，就像你的LLM（大型语言模型）。而你刚刚犯了90%的AI代理使用者都犯的错误：关注大脑本身，而不是关注大脑所看到的信息。 Prompt工程已经过时——上下文工程长盛不衰 过去几个月，我在每个论坛、每条推特讨论线程、每场团队会议中都看到同样的对话：“GPT-5还是Claude Opus？”“哪个模型对代码更好？”“哪个模型推理能力更强？” 我的回答，每次推算下来，都是一样的：这不重要。当然，不是完全不重要。但一个顶尖模型与另一个顶尖模型之间的差异，与提供优秀上下文和垃圾上下文之间的差异相比，简直微不足道。 一个表现平庸的模型但配备完美上下文，永远优于一个顶尖模型却给它垃圾上下文。总是如此，没有例外。 这就有了一个名词：上下文工程。而且，它与Prompt工程完全不同。 Prompt工程是编写一个好的提示。它是选择正确的词语、结构请求、加入示例。这很重要，但只是一个部分。 上下文工程则是设计模型看到的所有信息：哪些输入信息、顺序如何、空间有限时需要舍弃什么、压缩什么、哪些是必须保留的。这是为LLM做信息架构。 简单来说：Prompt工程是提出一个好的问题。而上下文工程则是在考试开始前决定学生桌上有什么书籍。 四阶段记忆：你看不到的生命周期 OpenAI最近发布了两个Cookbook文章，详细解构了具有长期记忆的代理如何进行上下文管理。这不是RAG，也不是矢量数据库，而是一种基于状态的系统，像一本具有严格规则的田野笔记本。 其模式是“本地优先”和“基于状态”的：一个结构化的状态对象与代理一起更新，贯穿每个阶段。 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拒绝PII和推测"] -.-> B C1["异步任务\n合并会话→全局\nLLM辅助去重\n过滤临时记忆"] -.-> C D1["修剪会话: 最近N次\n注入修剪记忆入\nsystem prompt"] -.-> 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：注入——考试桌上的资料 当会话启动时，代理会创建其初始上下文。这不是随机的，而是一个具体结构： YAML前置数据，包含用户状态（如偏好、配置）。 全局记忆列表：最多6个，按最近使用排序。为什么是6个？因为超过6个会相互竞争，导致信息模糊。少即是多。 <memory_policy>块，带有明确的优先规则。 优先规则至关重要：当前输入 > 会话记忆 > 全局记忆 > 同范围内的最新信息。如果用户说“我现在用Vim”，而你的全局记忆却显示“使用VS Code”，则以用户最新输入为准。虽然看起来显而易见，但没有明确规则的情况下，模型有时会选择其“记住”的内容而非用户给出的新信息。 ...