Context Engineering：AI 智能体的新型基础设施建设

如果你使用过大语言模型，一定遇到过这个问题：给 AI 发送了大量背景信息后，换一个对话窗口，它就像失忆了一样，什么都不记得。这不是模型的 bug，而是整个 AI 应用范式正在经历的一次深刻变革的缩影。

这场变革有一个正在兴起名字：Context Engineering——上下文工程。

从"有多少显存，就有多少智能"说起

2023 年，业界流传一句话："有多少显存，就有多少智能。"彼时，LLM 的上下文窗口是4K、8K，后来卷到 128K、200K。开发者们兴奋地往上下文里塞更多文档、更多对话历史、更多代码，以为窗口越大，AI 就越聪明。

但很快人们发现这不是线性关系。当你往200K 上下文中塞入一份10 万字的技术文档时，AI 的表现并非"更好地理解了文档"，而是开始出现中间遗忘——重要信息在序列的中间位置，模型对其的感知能力显著下降。这被研究者称为"中间丢失问题"（Lost in the Middle）。

更重要的是，经济账算不过来。以 GPT-4 Turbo128K 上下文为例，每一次完整的上下文传递，其成本远高于只传递相关片段。当你构建一个日均服务 10 万次请求的 AI 应用时，上下文膨胀带来的成本是致命的。

于是，行业开始分化出两条路：更大窗口与更聪明地上下文。Anthropic 在 2024 年初给出了答案——不是继续扩大窗口，而是重新设计信息传递的方式。

Claude 的"上下文提示"：把答案嵌在问题里

Anthropic 在2024 年 3 月发表了一篇技术博客，标题简单直接："Prompting Guidelines"。其中最核心的一条建议后来被广泛引用：

把答案嵌在用户的问题里，而不是依赖模型自己的记忆。

这不是在说模型的记忆不可靠。这是在说，上下文本身就是一种编程范式。

具体怎么操作？Anthropic 建议开发者在提示中显式包含：用户可能不知道但模型需要知道的关键背景、与当前任务直接相关的历史信息摘要、以及预期的回答格式和质量标准。

这三件事，本质上是在构建一个上下文协议（Context Protocol）——一种在每次请求时双方共同遵循的信息契约。

Memory：AI Agent 的第三根支柱

如果你关注 AI Agent 的发展，会发现行业的共识架构正在形成三根支柱：工具调用（Tool Use）、推理（Reasoning） 和 记忆（Memory）。

工具调用让 Agent 能操控外部世界。推理让 Agent 能规划行动步骤。而记忆——让 Agent 能跨对话、跨任务保留关键信息——长期处于被忽视的状态。

为什么？因为记忆的实现远比看起来困难。

一个朴素的想法是：给 Agent 接一个向量数据库，把所有对话都存进去，检索时拿出来。实践中这个方案问题很多：对话片段零碎、检索命中率不稳定、长期记忆和短期记忆没有区分、没有优先级机制。

行业正在探索更成熟的方案：

第一层：会话记忆（Session Memory）。在一次对话窗口内，模型持续保有对之前交流内容的感知。这是基础层，但窗口有限。

第二层：个性化记忆（Persona/Preference Memory）。记录用户的工作习惯、偏好设置、专业领域，在后续对话中自动适配。这一层的数据结构相对稳定，适合用结构化方式存储。

第三层：项目记忆（Project Memory）。当 Agent 参与一个长期项目时，它需要对这个项目的技术栈、架构决策、已知 bug、团队规范有完整记忆。这是最难的一层，因为项目信息不仅量大，而且会不断演进。