上下文工程：AI上下文越大为何越笨？

从提示词工程到上下文工程

如果说过去我们讨论 AI 应用时最热的词是「提示词工程」（Prompt Engineering），那么 Anthropic 在其官方文章《Effective Context Engineering for AI Agents》中提出了一个更进阶的概念——上下文工程（Context Engineering）。

提示词工程在 2022 年 ChatGPT 走红后迅速成为一门显学。它的核心是通过精心设计输入文本来引导大语言模型输出符合预期的结果，衍生出诸如零样本（Zero-shot）、少样本（Few-shot）、思维链（Chain-of-Thought）等一系列技巧。早期开发者甚至将其戏称为「玄学」，因为微小的措辞变化就可能带来输出质量的天壤之别。然而随着 AI 应用从「一问一答」的聊天机器人演进到能够自主规划、调用工具、多步执行的智能体（Agent），单纯优化一句提示词已远远不够——模型在整个任务链条中需要消化的信息量呈指数级增长，这正是上下文工程接棒登场的历史背景。

两者的差别可以用一句话概括：提示词工程关心的是「怎么把那一句指令写好」，而上下文工程关心的则是一个更宏大的问题——在模型每一步推理时，到底哪些信息应该被放进它的上下文窗口里。

这里的「上下文」范畴远比一句提示词要广。系统提示词、可调用的工具、外部数据、历史消息、检索回来的内容……全都算在内。换句话说，我们要从「写好一句话」升级到「策展整个上下文的状态」。这是一个从点到面的跃迁，也是构建可靠 AI 智能体（Agent）的核心功夫。

为何上下文是一种有限资源

我们最近听到最多的宣传就是「窗口又变大了，能塞一百万 token 了」。但 Anthropic 提醒我们注意一个反直觉的事实：能塞和该塞是两回事。

这里有一个关键概念叫做「上下文腐烂」（Context Rot）：窗口里的 token 越多，模型从里面准确捞出某一条特定信息的能力反而越差。

这并不是模型在「偷懒」，而是由架构本身决定的。今天的大模型都基于 Transformer，每个 token 都要和其他所有 token 建立关系。n 个 token 意味着 n² 量级的关系对。因此模型有一个天然的「注意力预算」，它非常像人类的工作记忆——你每多塞一个 token，就消耗掉一点注意力。

这里的 n² 约束源自 Transformer 架构的核心——自注意力机制（Self-Attention），这一架构由 Google 在 2017 年论文《Attention is All You Need》中提出，如今几乎所有主流大模型（GPT、Claude、Gemini 等）都建立在其之上。自注意力的工作方式是让序列中每一个 token 都去「关注」其他所有 token，计算彼此之间的相关性权重。这也正是它强大之处：能够捕捉长距离依赖关系。但代价是计算与内存开销随序列长度呈平方级（O(n²)）增长——处理 1000 个 token 需要约 100 万次关系运算，而 10000 个 token 则骤增到 1 亿次。这一数学本质决定了：即便工程上能把窗口做到百万级别，模型分配给每个 token 的「注意力密度」也会被稀释，这正是「上下文腐烂」现象的技术根源。

所以全文的总纲其实只有一句话：把上下文当成一种珍贵而有限的资源来花。抓住这个前提，后面的所有原则都能顺理成章地推导出来。

好的上下文长什么样：三条核心原则

既然上下文是稀缺资源，那么什么样的上下文才算「好」？Anthropic 给出了三条实操原则。

系统提示词要找到「正确的海拔」

第一条是关于系统提示词的定位问题。不要把又复杂又脆弱的逻辑硬编码成一本厚厚的说明书，让模型逐条对照执行；但也不要走向另一个极端，只给一堆空泛的口号。

目标是找到那个恰到好处的「海拔高度」——用最小的一组高信号 token，最大程度地引出你想要的行为。理想状态是：字数少，但每一个字都顶用。

工具设计要少而清晰

第二条关于工具设计，Anthropic 给出了一个非常实用的判断标准：如果连人类工程师都说不清某种情况下该调用哪一个工具，那你就别指望 AI 能替你做对。

工具集合的模糊与臃肿，往往是智能体出错的重灾区。与其堆砌大量功能重叠、边界不清的工具，不如精简到每个工具职责明确、彼此正交。

示例只给典型，别堆边角案例

第三条关于 few-shot 示例。给模型的示例应该聚焦几个典型场景就够了，不要为了「覆盖全面」而堆砌各种边角案例。因为示例本质上就是那张「一图胜千言」的图——用最少的样本传达最清晰的行为模式。

上下文该怎么喂进去：预检索 vs 及时检索

这是整篇文章中最有价值的一段：数据究竟应该以什么方式进入模型的上下文？这里有两种思路。

第一种是传统思路，叫做「预检索」（pre-retrieval）：在任务开跑之前，就用各种手段把所有可能用得上的资料一股脑捞出来，全部塞进上下文。

第二种是新思路，叫做「及时检索」（just-in-time retrieval）：平时只给模型留下「线索」——比如文件路径、一个链接——等它真正需要用到时，再用工具把数据动态拉进来。

这里的「预检索」与「及时检索」之争，实际上是检索增强生成（RAG, Retrieval-Augmented Generation）技术演进的缩影。传统 RAG 属于典型的预检索思路：将文档切块、向量化后存入向量数据库，用户提问时先检索相关片段再一并送入模型。这套方案在知识问答场景表现优异，但面对复杂的智能体任务时暴露出局限——一次性检索往往塞入大量不相关内容，既浪费注意力预算又引入噪声。及时检索则借鉴了智能体（Agentic）范式，把检索本身变成模型可以主动调用的工具，让模型根据推理进展决定「此刻需要什么」，类似 Anthropic 自家 Claude 的工具调用（Tool Use）与模型上下文协议（MCP, Model Context Protocol）所倡导的动态、按需获取数据的思路。

为什么后者更高级？Anthropic 打了一个非常戳中要害的比方：这就是人类的认知方式。我们不会去背整座图书馆，而是依靠文件系统、书签这些外部索引，需要的时候再去翻查。你只要记得「书在哪个架子上」就够了。

当然，这也不是绝对的。最有效的方案往往是混合策略：关键数据预先拿好保存，剩下的让智能体自己去探索。而落到最朴素的一条原则上，就是——

做那个能跑通的最简单的事，别一上来就堆花活。

长任务场景：三招对抗上下文溢出

最硬核的场景是长任务智能体——它可能连续运行几个小时、执行上千个步骤，上下文迟早会撑爆窗口。针对这种情况，Anthropic 给出了三招。

第一招是压缩（Compaction）：当窗口快满时，就把前面的内容总结一下，用一份摘要重开一个干净的窗口。保留决策和关键信息，扔掉冗余细节。

第二招是结构化笔记（Structured Note-taking）：让模型把笔记写在窗口之外持久存储，过一阵再按需取回。这相当于给模型配了一个「外挂记事本」。

第三招是子智能体（Sub-agents）架构：主智能体负责拿计划、做协调，配一批子智能体在各自干净的窗口里干活，每个子智能体只回传一份一两千 token 的浓缩摘要，杂乱的细节都被隔离在外面。

怎么选也很简单：长对话优先用压缩；有明确里程碑的任务用笔记；能够并行探索的复杂研究任务，则上多智能体架构。

与「框架工程」咬合的关键一层

读完这篇文章，最大的体会是它和「框架工程」是紧密咬合的。围绕模型搭建的每一个组件，其实都编码了一个关于「模型做不到什么」的假设，而上下文工程正是其中专门管理注意力的那一层。

这一层有一个特别之处：它不会随着模型变强而彻底消解。因为 n² 那个约束是架构层面的，窗口可以越做越大，但「多则乱」的规律不会消失。

所以结论是：无论模型如何进化，真正的功夫永远在于那一句话——在每一步都深思熟虑地去策展，到底让哪些信息进入模型那有限的注意力之中。

本文内容基于 Anthropic 官方文章《Effective Context Engineering for AI Agents》整理，尽量忠于原文观点。

核心要点