上下文工程：2026 年 AI 工程的核心学科

2026 年 7 月，Anthropic 做了一件让开发者社区哗然的事：他们将 Claude Code 的系统提示词砍掉了超过 80%，跑完内部编码评测后，没有检测到任何可测量的性能损失。两个月后，OpenAI 工程师在 GPT-6 Astra 发布当天的第一句话不是介绍新模型，而是"回去清理你的 AGENTS.md 和 Skills，该删的删"。两大实验室在两个月内不约而同地指向同一个结论：提示词工程作为独立学科的时代正在终结，接管它的，是上下文工程。
这不是一次简单的术语翻新。提示词工程处理的是"怎么写好一条指令"，上下文工程设计的是模型在推理的每一步究竟看到什么——系统提示、工具定义、检索到的文档、对话历史、中间推理产物，全部纳入一个统一的信息架构。在单轮对话场景里，两者差别不大；但当 AI 系统演化为跨步骤、跨会话、长时程的 Agent，模型的注意力预算便取代模型能力本身，成为系统的第一瓶颈。

一、"RAG 已死"是一桩范畴错误

2026 年 1 月，一个病毒式论断在工程社区流传："RAG 已死了。"理由看起来无可辩驳：Gemini 提供 100 万 token 上下文窗口，Claude 达到 100 万，GPT-5.4 为 105 万——既然能一次性塞进整个知识库，为什么还要向量数据库和检索管线？
但这个论断混淆了三件不同的事。RAG 作为一种模式——检索相关信息、增强提示、生成回答——没有死，也没有濒死。向量数据库作为一个品类，虽然受到 pgvector 与 Elasticsearch 的挤压，但同样活着。真正在死去的，是朴素的单阶段检索：把查询嵌入、做余弦相似度搜索、把 Top-K 块塞进提示、发给大模型。
取代它的，正是上下文工程。它把 RAG 降格为自己诸多子问题之一：不是"如何尽可能多地检索相关文档"，而是"在模型有限的注意力下，什么信息应该在什么时刻以什么形式进入上下文窗口"。检索从主舞台退到幕后，成为按需供给的一个数据源。

二、上下文腐蚀：为什么更大的窗口反而让模型更差

理解上下文工程的必要性，需要先理解一个反直觉的现象：上下文窗口越大，模型的有效利用率反而越低。
Chroma 的研究团队对 18 个前沿模型做了系统测试，发现随着输入长度增长，模型的实际信息利用率出现渐进且不均匀的退化——而且这种退化在词法匹配型基准上不可见，只有深层的理解型任务才暴露出来。研究者们将这一现象命名为"上下文腐蚀"（Context Rot）。
其物理机制植根于 Transformer 架构本身：注意力依赖 token 两两之间的关系，复杂度是 $n^2$ 级的。上下文越长，每个 token 能分到的成对关系注意力就越稀薄。换一种说法：模型的注意力是有限的预算，每引入一个新 token，都在稀释这个预算。
这解释了 Anthropic 在数据分析场景下发现的一个刺眼数字：让模型访问数千个历史 SQL 文件，带来的准确率提升不足 1%；而没有领域 Skills 时准确率不超过 21%，加入 Skills 后整体超过 95%。信息量与信息价值是两回事。一个 20,000 token 的系统提示如果 90% 与当前任务无关，它不只是浪费成本——它会让模型在剩下 10% 相关内容上的表现也变差。
Anthropic 的 2026 年代理编码趋势报告给出了佐证：维护良好上下文文件的团队，错误率降低 40%，任务完成速度提升 55%。另一份研究报告则显示，代理任务成功率在加入结构化上下文文件后，从 30% 提升到 90%。

三、四个被验证的核心策略

Anthropic Applied AI 团队在 2026 年 6 月给出了上下文工程的系统化定义：在有限的注意力预算下，找到最小的高信号 token 集合来最大化期望行为。围绕这个定义，工程界形成了四个已被生产环境反复验证的机制。

1. 压缩：在抵达窗口边界前主动总结

当长会话逼近上下文窗口上限时，系统应主动将历史对话压缩为一份摘要，保留架构决策、未解决的 bug、关键实现细节，丢弃已被替代的探索性回合、已解决的报错、对结果无影响的中间推理。Claude Code 在 Claude 玩 Pokemon 的实验中，用同样的技术让 Agent 维护精确计数、探索地图与策略笔记，实现了跨上下文重置的状态保持。

2. 子代理架构：用隔离的上下文换深度

这是 2026 年公认的最强上下文工程模式。一个研究型子代理读取 80 个文件时，可能在自身上下文中消耗 120,000 token；而它的父代理只接收一份 400 token 的压缩摘要。协调代理的全局上下文可以稳定在约 40k token，而所有重度工作在子代理的隔离上下文中完成。
Anthropic 的多代理研究系统报告了一个关键发现：token 使用量本身解释了 80% 的性能差异，工具调用次数和模型选择是另两个次要变量。这印证了上下文工程的核心假设——管理 token 的分配方式，比选择更强的模型更重要。

3. Just-in-Time 检索：让 Agent 持有轻量标识符

与其把大文件、长 API 响应、完整搜索结果全部塞进上下文，不如让 Agent 只持有它们的标识符（文件路径、查询关键词、URL），运行时按需加载。Claude Code 用这种模式写入定向查询，用 head/tail 分析大文件而不将其完整载入上下文。Agent Skills 是该模式的优雅实现：每个 Skill 在上下文中只占约 100 token 的触发器，请求匹配其描述时才注入完整指令。

4. 预算与卸载：让大载荷落盘

对于超出阈值（通常是数万 token）的工具结果，将其写入外部存储，在上下文中只保留路径与预览。这使内容可恢复，而不挤占活动上下文。Pinterest 工程团队的实践从工具侧印证了同一逻辑：他们把领域特定工具拆分为多个 MCP 服务器，Agent 在处理 Presto 数据时只加载 Presto 相关工具，而不是把 Spark、Airflow 等所有工具全部堆在上下文里——这显著降低了噪声，提升了决策准确性。

四、代码落地：LangGraph 中的子代理与压缩

下面是一个可直接运行的多代理工作流骨架，展示上下文工程中最关键的三个机制：子代理隔离、结构化笔记、按需工具加载。

import operator
from typing import Annotated, TypedDict, Literal
from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
from langchain_openai import ChatOpenAI
from langchain_core.messages import BaseMessage, HumanMessage
class AgentState(TypedDict):
    messages: Annotated[list, operator.add]      # 消息通道
    scratchpad: dict                            # 结构化笔记：跨上下文重置存活
    working_memory: str                         # 压缩后的当前目标摘要
def coordinator(state: AgentState):
    """协调代理：持有全局目标，不执行具体工作"""
    llm = ChatOpenAI(model="gpt-5.4", temperature=0)
    response = llm.invoke([
        SystemMessage(content=(
            "你是协调者。分析当前任务，决定下一步：
             1) 需要深入调研 → 委托 research_subagent
             2) 需要工具调用 → 调用 tools
             3) 目标已达成 → 输出最终结论
             只输出决策，不输出执行过程。"),
        *state["messages"]
    ])
    return {"messages": [response]}
def research_subagent(state: AgentState):
    """子代理：在隔离的上下文中执行重度阅读，返回压缩摘要"""
    llm = ChatOpenAI(model="gpt-5.4", temperature=0)
    # 注意：子代理不继承完整历史，只接收当前子任务
    sub_task = state["scratchpad"].get("current_subtask", "")
    summary = llm.invoke([
        HumanMessage(content=(
            f"子任务：{sub_task}\n"
            "阅读所有相关文件，返回不超过 400 token 的摘要，"
            "包含：关键事实、未解决的疑点、建议的下一步。"))
    ])
    # 父上下文只收到摘要，而非原始阅读内容
    return {
        "messages": [HumanMessage(content=f"[研究摘要] {summary.content}")],
        "scratchpad": {**state["scratchpad"], 
                       "research_done": True}
    }
def compaction_node(state: AgentState):
    """压缩节点：当上下文压力增大时主动总结历史"""
    llm = ChatOpenAI(model="gpt-5.4", temperature=0)
    summary = llm.invoke([
        HumanMessage(content=(
            "把以下对话压缩为一份执行摘要，保留：
             - 当前目标与未完成的子任务
             - 关键架构决策及其理由
             - 必须继续持有的代码/文件引用
             丢弃：已完成的探索、被替代的方案、中间推理。\n\n"
             + "\n".join(m.content for m in state["messages"][-20:]))
    ])
    return {
        "messages": [HumanMessage(content=f"[历史压缩]\n{summary.content}")],
        "working_memory": summary.content
    }
def should_compact(state: AgentState) -> Literal["compact", "continue"]:
    token_count = sum(len(m.content) for m in state["messages"])
    return "compact" if token_count > 50_000 else "continue"
def route_next(state: AgentState) -> str:
    last = state["messages"][-1].content
    if "研究" in last: return "research"
    if "工具" in last: return "tools"
    return END
# 构建图
builder = StateGraph(AgentState)
builder.add_node("coordinator", coordinator)
builder.add_node("research", research_subagent)
builder.add_node("tools", ToolNode([...]))          # MCP 工具集
builder.add_node("compact", compaction_node)
builder.set_entry_point("coordinator")
builder.add_conditional_edges("coordinator", route_next,
                              {"research": "research", "tools": "tools", END: END})
builder.add_conditional_edges("tools", should_compact,
                              {"continue": "coordinator", "compact": "compact"})
builder.add_edge("compact", "coordinator")
builder.add_edge("research", "coordinator")
graph = builder.compile()

这段骨架刻意把四个上下文工程机制显式化。真实的生产系统中，压缩的触发条件、子代理的委托粒度、结构化笔记的字段设计，都是需要基于业务数据反复调优的核心参数。

五、框架的隐性税负：为什么脚手架本身值 7 个百分点

上下文工程的实践并不仅在应用层。框架本身对上下文的处理方式，已经成为决定性能的隐性变量。
Princeton HAL 排行榜上出现了一个值得注意的数据：同一个 Claude Opus 4 模型，在一个代理脚手架内 GAIA 基准得分为 64.9%，在另一个脚手架内只有 57.6%。7 个百分点的差距，完全来自框架对上下文的组织方式——工具定义的排序、历史消息的截断策略、节点间状态传递的粒度。
这解释了 2026 年框架生态的演化方向。LangGraph 用图式状态机提供显式可审计的控制流，成为受监管行业生产环境的首选；CrewAI 用基于角色的多代理编队换取 2–4 小时的原型搭建速度，但在简单工作流上消耗更多 token。类型安全成为新的分化轴：Mastra（TypeScript 优先）和 Pydantic AI（Python 侧）把结构化保证作为首要设计目标——当代理从原型走向生产，对数据流向的结构化保证，比最大灵活性更重要。
模型上下文协议（MCP）在 2025 年 12 月被 Anthropic 捐赠给 Linux 基金会下的 Agentic AI 基金会后，正在成为跨框架的工具集成标准。其工程意义直接服务于上下文工程：标准化在 MCP 上的工具集成可以在框架之间迁移而不需要重写，团队可以更换 LangGraph 为 Microsoft Agent Framework，而不需要重建集成层。

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

把两者对立起来并不准确。上下文工程不是取代提示词工程，而是吸收它。Anthropic 把它定义为"提示词工程的自然演进"：提示词工程是把单条指令写好，上下文工程是管理整个多回合运行中 token 的全集——系统提示、工具、检索到的数据、消息历史。
两者的适用边界可以用一个简单标准判断：单轮对话任务里，提示词技能仍然承担大部分权重；对于代理和生产系统，提示词只占整体工作量的一小部分。
术语本身有一个明确的诞生谱系：Shopify CEO Tobi Lütke 在 2025 年 6 月 18 日的帖子中首次提出"上下文工程"，一周后 Andrej Karpathy 的背书使其广为传播；Anthropic 在 2025 年 9 月的论文中建立了规范框架，包括"注意力预算"概念。从提出到成为行业共识，不到一年。

结语：管理注意力比堆砌算力更划算

回看 Anthropic 砍掉 80% 系统提示词这个标志性事件，它的真正启示不是"提示词不重要"，而是新模型已经具备在干净上下文中自主判断的能力。旧模型需要用死规则约束"永远不要写多行文档字符串"；新模型只需要一句"写出来的代码要像周围的代码，匹配它的注释密度、命名方式和惯用法"。规则清单变成了判断依据。
这背后是一个更基础的经济学事实：模型能力的增长速度，正在超过上下文窗口有效利用率的增长速度。继续把更大的上下文窗口当作万能解，相当于给一台精密仪器不断增加噪声输入。2026 年真正稀缺的工程能力，不是找到更多信息，而是让模型在每一步都恰好看到它需要看到的那部分信息。
上下文工程之所以成为核心学科，正是因为它直接对应了这个稀缺能力——在有限注意力预算下，持续构建最小的高信号 token 集合。从压缩、子代理隔离、按需加载到工具生态标准化，所有这些实践的共同目标只有一个：让每个 token 都挣得它的位置。