上下文工程定义解析（详解 2026 年 AI Agent 关键工程能力）

截至 2026 年,上下文工程已成为 AI Agent 落地链路中权重靠前的工程技能——它解决的不是”怎么写提示词”,而是”模型在每个决策瞬间能看到什么”。Anthropic 在 2025 年的工程文章中将其定义为”在大模型推理时策展与维护最优 token 集合的策略集合”,LangChain 则把落地手段收敛为写入、选择、压缩、隔离四类。下面把这门学科拆开讲透,包括它和提示词工程的边界、四类核心策略,以及一个可运行的最小化实现。

一、为什么 2026 年必须谈上下文工程

Agent 已经从单轮问答走向多步执行,一次任务可能跨越几十轮工具调用、检索、记忆读写。模型并不推理你的”意图”,它只推理它实际看到的 token。在这个前提下,”措辞再好,上下文配错”就会翻车;反之”措辞一般,上下文精准”反而稳。Salesforce 在 2026 年发布的《AI Agent 八大趋势》报告里把上下文工程与”确定性护栏”并列为两大核心趋势,DataHub 的 2026 上下文管理调研显示 82% 的 IT 与数据负责人认为”仅靠提示词工程已不足”,95% 认同上下文工程是 Agent 规模化的必要条件。

这背后是一条朴素的算账逻辑:上下文窗口的每一 token 都有延迟和注意力稀释的双重成本,Databricks 的研究指出主流大模型在超过约 32k token 后效果会显著衰减。一个 200k 窗口并不意味着可以”装满再用”,而是要做主动预算。

二、提示词工程与上下文工程的边界

很多团队把”再改改 prompt”当作万能解法,实际上是混淆了关注点。提示词工程只优化那条由人写好的静态指令;上下文工程管理的是 Agent 整轮运行中动态变化的全部 token,包括系统提示、工具定义、检索结果、历史消息、临时草稿区。

维度	提示词工程	上下文工程
范围	一次写好的指令	Agent 整轮的全部可见 token
责任方	人工	人 + 工具 + 检索 + 记忆系统
时间维度	静态,一次性设定	动态,每一步都变化
主要失效模式	措辞模糊	窗口膨胀、上下文陈旧
主杠杆	改写措辞	选择、压缩、卸载、子代理拆分
关系	子集	超集,提示词工程是其内嵌工具

提示词工程并未消亡,只是被降级为上下文工程这一更大工程方法中的一个子能力。系统提示仍然重要,只是它通常只占 Agent 实际看到 token 的 5%–10%。

三、四类核心策略:LangChain 的收敛框架

LangChain 把上下文工程的落地手段收敛为四类策略,几乎覆盖了目前所有生产级 Agent 的做法。

3.1 写入(Write Context)

把信息持久化到上下文窗口之外,需要时再取回。常见载体有外部文件、向量数据库、知识图谱、长期记忆库。Salesforce 的 Agentforce 在重构运行时,把用户偏好、合规规则、跨会话决策记录写入结构化存储,Agent 重启后能直接复用,不必每次重读一遍历史。

3.2 选择(Select Context)

按当下任务只取最相关的片段注入窗口。代表技术是 RAG(检索增强生成),更进一步的 Agentic RAG 让模型自己决定何时检索、检索什么、重不重排。2024 年的 RAG 综述（Gao 等）也指出,不少 LLM 应用的实际错误来源于上下文不完整、不相关或结构混乱,而非模型能力本身不够。

3.3 压缩(Compress Context)

把超出窗口的旧对话、旧工具输出做摘要或裁剪。Anthropic 在文章中强调”长上下文里被压缩丢掉的部分,可能是真正决定下一步推理的关键信号”,所以压缩不是简单截断,通常要保留决策点、错误信息、最终结论这类高密度 token。

3.4 隔离(Isolate Context)

把多任务拆给多个子 Agent,各自只看到自己那一小段上下文。Manus、Zep、Google 的多 Agent 实践里都用了类似模式:主 Agent 只持有调度上下文,子 Agent 各自管理自己的工具与记忆,通过结构化消息回传结果。这样能有效防止单窗口被无关信息污染。

策略	解决什么	典型实现	适用场景
写入	上下文会丢失	长期记忆库、知识图谱	用户偏好、跨会话规则
选择	上下文会过载	RAG、Agentic RAG、GraphRAG	大知识库 + 窄问题
压缩	上下文会膨胀	摘要、关键 token 抽取	长链路 Agent
隔离	上下文会污染	多 Agent 分工、沙箱	可拆解的多步任务

Anthropic 额外强调了三件常被忽视的事:系统提示要”校准”而非堆砌、工具定义要”少而可组合”避免 MCP 过载、检索要”刚好及时”而非预加载所有可能用到的资料。

四、上下文工程落地的五个步骤

从认知到能跑通,建议按下面五步推进:

盘清现状:列出 Agent 当前每一步实际看到的 token 来源与体量,识别哪些在膨胀;
设定 token 预算:为系统提示、工具定义、检索结果、历史消息、草稿区分别设上限,总值不超过模型有效注意力区间(经验值 32k 上下);
四类策略组合:写入做长期记忆、选择做按需检索、压缩做长链路管理、隔离做任务拆分;
小模型先验:用 1B–3B 模型跑通 pipeline,确认 token 预算与压缩策略没把关键信号挤掉,再上 7B+;
建立评估闭环:用”答准率 + 工具调用成功率 + 单任务 token 消耗”三项核心指标持续观察,每两周复盘一次窗口结构。

五、一个可运行的最小化例子

下面给出一段 Python 伪代码,展示一个 Agent 循环如何按”选择 + 压缩 + 写入”三策略维护上下文。运行后能直观看到窗口大小被稳定控制在预算内,长对话也不会失忆。

class ContextEngine:
    def __init__(self, budget=8000):
        self.budget = budget
        self.system = "你是一名严谨的助手,先复述任务,再给结论。"
        self.long_term = []   # 写入:跨会话记忆
        self.history = []     # 选择+压缩:近 N 轮
        self.scratchpad = ""  # 隔离:草稿区

    def select(self, query, docs):
        # 选择:按关键词打分,只取最相关的 3 条
        scored = sorted(docs, key=lambda d: -sum(k in d for k in query.split()))
        return scored[:3]

    def compress(self):
        # 压缩:超过 6 轮就摘要前 4 轮
        if len(self.history) > 6:
            old = self.history[:4]
            digest = f"[摘要] 此前 {len(old)} 轮围绕:{old[0]['user'][:30]}"
            self.history = [{"digest": digest}] + self.history[4:]

    def remember(self, fact):
        # 写入:长期记忆去重
        if fact not in self.long_term:
            self.long_term.append(fact)

    def build_prompt(self, query, docs):
        self.compress()
        picked = self.select(query, docs)
        ctx = [
            {"role": "system", "content": self.system},
            {"role": "system", "content": "长期记忆:" + ";".join(self.long_term[-5:])},
            {"role": "system", "content": "参考资料:" + "\n".join(picked)},
            *self.history,
            {"role": "user", "content": query},
        ]
        return ctx

# 用法
engine = ContextEngine(budget=8000)
engine.remember("用户偏好中文回答")
prompt = engine.build_prompt("解释 RAG", docs=["RAG 是检索增强生成...", "RAG 包括三段式管线..."])
print(len(prompt), "条消息送入模型")

这段代码的价值在于把策略显式化为可被测试的接口:预算一旦写死,任何一次”窗口超限”都会成为可定位的工程问题,而不是”感觉 Agent 变笨了”这种玄学反馈。生产环境可在此基础上把”选择”换成向量检索、把”压缩”换成模型摘要,基本结构不变。

六、2026 年的两个新趋势

最后提两个正在显现的方向。第一个是 Context Engine as a Service(CEaaS),把上下文构建做成独立服务层,类比当年数据库从应用里抽离,行业普遍预期 2026 年起它会成为企业级 Agent 平台的基础设施。第二个是 Memory Graph,用图数据库替代传统 RAG,专门解决”金鱼问题”——Agent 忘记前几轮的教训;早期实测显示,带 Memory Graph 的多 Agent 群组相比传统 RAG 在一致性任务上效果提升明显。

到这里,上下文工程从概念、边界、策略到落地代码的链路就完整了。模型能力仍会持续变强,但”喂给模型什么”会越来越决定 Agent 能不能用。

常见问题(FAQ)

Q1：上下文工程会取代提示词工程吗?

不会。提示词工程被纳入上下文工程,成为其内嵌工具,系统提示仍需写好。

Q2：上下文窗口越大越好吗?

不是。研究显示主流模型在约 32k token 后效果衰减,200k 窗口仍需主动管理。

Q3：普通业务人员需要学上下文工程吗?

需要。AI 智能体进入日常工作后,什么数据让它看、什么文档要附,本身就是上下文工程。