本文将深入探讨为什么上下文工程是构建可靠AI产品的核心，并系统性地介绍其两大基础原则与四大实现策略。无论您是产品经理、工程师还是AI爱好者，理解这些概念都将帮助您构建出更强大、更可靠的AI智能体。现在，让我们首先来探究，为何对上下文的管理如此至关重要。
在过去几年里，我们见证了“提示词工程”（Prompt Engineering）从一个专业术语迅速演变为AI从业者的基本功。我们学会了如何通过精心设计的指令与大语言模型（LLM）高效对话。然而，当我们着手构建能够长时间运行、处理复杂任务的AI智能体（Agent）时，仅仅优化单次提示是远远不够的。一个更深层次、更系统化的挑战浮出水面——“上下文工程”（Context Engineering）。
为了直观地理解这个概念，我们可以借鉴著名AI学者Andrej Karpathy提出的一个精妙类比：
将大语言模型（LLM）视为一个全新的操作系统。在这个系统中，LLM本身是CPU，负责计算和推理；而模型的“上下文窗口”（Context Window）则扮演着RAM（工作内存）的角色。它决定了模型在执行任务的每一步中，能够看到哪些“恰到好处”的信息。
在构建需要长时间运行并保持连贯性的AI智能体时，可靠性是首要挑战。智能体在多轮对话、工具调用和任务分解的过程中，任何微小的偏差都可能被放大，最终导致任务失败。正如AI新锐公司Cognition所强调的，对于构建AI智能体的工程师而言，“上下文工程”实际上是他们的头等大事。
其核心原因在于，不受控的“长上下文”会带来几大大严峻挑战：
1）超出上下文窗口限制
这构成了最基本的物理瓶颈。每个模型都有其token数量上限（例如200K tokens）。当对话历史、工具调用反馈和中间思考过程不断累积，很容易就会超出这个限制，导致关键信息的丢失。
2）成本与延迟激增
API调用的成本与输入的token数量直接挂钩。上下文越长，单次调用的费用就越高，同时模型的响应时间也会显著增加。对于生产环境的应用而言，这直接影响了产品的经济效益和用户体验。
3）模型性能下降
更令人担忧的是，过长的上下文不仅是资源问题，更会直接损害模型的性能。正如研究者Drew Breunig所总结的，长上下文会导致四种具体的性能退化问题：
为了克服这些挑战，我们不能简单地将所有信息都塞入上下文窗口，而是需要一套系统性的方法论来主动管理它。这套方法论建立在两条基础原则之上。
在深入探讨具体的技术策略之前，我们必须首先理解构建智能体背后的底层哲学思想。
这就像Web开发的发展历程：在原始的HTML/CSS时代，开发者们各自摸索。直到2013年Facebook发布React框架，它不仅提供了一套工具，更带来了一种关于“响应式”和“模块化”的设计哲学。这种哲学思想深刻地影响了整个行业，并成为了现代Web应用开发的标准。
同样，在构建AI智能体时，遵循正确的原则比盲目堆砌技术更为重要。Cognition公司通过大量的试错，总结出了两条构建可靠智能体的核心原则：
仅仅向子任务传递一条简单的指令或原始任务目标是远远不够的。智能体需要了解任务的全貌以及其他部分已经完成的工作。
反面案例：克隆Flappy Bird游戏（详见最后引用链接）
假设一个主智能体将任务分解为：“子任务1-构建一个带有绿色管道和碰撞框的移动游戏背景”和“子任务2-构建一只可以上下移动的小鸟”。如果这两个子智能体之间缺乏对彼此工作进度的了解，很可能会出现灾难性的结果：
最终，主智能体得到的是两个风格迥异、无法整合的半成品。失败的根源在于，子智能体们没有共享一个完整的、持续更新的上下文。
智能体的每一步操作（action），无论是调用工具还是生成代码，都基于某些并未明确说明的假设或决策。
继续以Flappy Bird为例
即使两个子智能体都清楚最终目标是“克隆Flappy Bird”，但由于它们看不到对方的具体行动，各自做出的隐性决策很可能会发生冲突。例如，一个子智能体可能决定采用像素艺术风格，而另一个则可能选择了卡通渲染风格。这些未经协调的决策，最终会导致产品的不一致和低劣。
正是因为当前流行的多智能体（Multi-Agent）架构从根本上就难以遵循上述两条原则，所以它们的表现才往往很脆弱。在这些架构中，“决策权过于分散，上下文无法在智能体之间被彻底共享”，从而极易产生冲突的隐性决策。正如Cognition所观察到的，目前的多智能体协作系统可靠性并不高。
遵循这两大原则，我们才能在坚实的地基上，探索一系列具体的工程策略来管理我们宝贵的“工作内存”。
为了系统性地管理上下文，我们可以将主流的工程实践归纳为四大核心策略：写入（Write）、选择（Select）、压缩（Compress）和隔离（Isolate）。这些策略共同构成了一个强大的工具箱，为工程师提供了精细化管理“RAM”的手段。
如果把上下文窗口比作电脑的RAM（内存），那么当RAM即将占满时，最基本的操作就是将暂时不用的数据转存到“硬盘”上。“写入”策略正是AI智能体中与此概念等价的操作，它将信息移出活跃的上下文窗口，以备后续检索。
定义： 将信息从即时的上下文窗口中持久化保存到外部存储，以备后续任务或跨会话使用。
技术方法：
案例： 在Anthropic的多智能体研究员项目中，主智能体首先会将研究计划写入Memory，以防止因上下文窗口超限而被截断。我们熟知的ChatGPT、Cursor等产品，也都内置了类似的长期记忆机制，能够记住用户的偏好和历史对话中的关键信息。
电脑不会一次性将整个硬盘的数据都加载到RAM中，而是选择性地读取当前任务所需的文件。同样地，“选择”策略的核心在于智能地从外部存储中，将最相关的信息拉回智能体的“工作内存”中。
定义： 在需要时，精准地从外部存储（如暂存区或记忆库）中提取与当前步骤最相关的信息，并加载到上下文窗口中。
技术方法：
案例： 技术博主Simon Willison分享过一个生动的失败案例：他要求ChatGPT生成一张图片，但模型错误地从记忆中选择了他的地理位置信息，并将其强行注入到图片生成请求中。这说明了精准选择的挑战性，错误的“选择”甚至可能让用户觉得“上下文窗口不再属于自己了”。
在将文件加载到RAM之前，我们常常会先将其“压缩”（例如使用zip），以节省宝贵的内存空间。“压缩”策略在上下文工程中扮演着类似的角色，旨在减少token占用，同时保留核心信息。
定义： 在保留完成任务所需核心信息的前提下，通过总结或修剪的方式，尽可能地减少上下文的token数量。
技术方法：
案例： 著名的编程智能体Claude Code就应用了这一策略。当上下文窗口的使用率超过95%时，它会自动触发一个名为“auto-compact”的进程，总结整个交互轨迹，释放空间。此外，Cognition也提到，他们会使用一个经过微调的模型，在不同智能体之间进行信息交接时，对上下文进行总结，以降低通信成本。
现代操作系统允许我们同时运行多个应用程序，每个程序都在自己受保护的独立内存空间中运行，互不干扰。“隔离”策略采用了相同的思想，通过创建独立的、受保护的上下文“容器”，来降低认知负担并防止干扰。
定义： 通过创建独立的、受保护的上下文“容器”来降低认知负担并防止干扰。
技术方法：
案例： Anthropic的多智能体研究员项目再次证明了隔离策略的有效性。多个拥有隔离上下文的子智能体并行工作，各自深入研究问题的不同方面，其最终表现显著优于单个智能体处理整个复杂任务。
这四项策略为我们构建高级AI智能体提供了坚实的工程基础，指明了通往更可靠、更高效系统的路径。
通过本文的探讨，我们系统性地了解了上下文工程，它为所有AI产品领导者提供了一个强大的工具箱。这些策略直接对应着产品的核心价值：
理解和应用上下文工程，已不再仅仅是工程师的职责。
对于AI产品经理而言，这些概念直接关系到产品的核心体验：可靠性、成本效益和可扩展性。我们必须开始将这些工程思想融入产品设计和规划之中，思考如何通过巧妙的上下文管理，提升用户与AI协作的流畅度和成功率。
随着我们从简单的聊天机器人，迈向能够独立完成复杂任务的AI智能体时代，对上下文的精细化管理将成为区分优秀AI产品与平庸AI产品的关键战场。希望本文介绍的原则和策略能为您带来启发，助您在未来的工作中，打造出真正智能、可靠的新一代AI产品。
【参考来源】
本文由 @Tracy 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图由豆包AI生成
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。