上下文工程：大模型应用上下文管理的架构艺术

当我们谈论大语言模型的能力时，往往聚焦于参数规模、训练数据和推理速度。然而在真实的工程实践中，决定一个 AI 应用成败的，却是另一个更隐蔽却更关键的因素——如何高效、精准、经济地管理上下文。这就是"上下文工程"（Context Engineering）的核心命题。

从简单的 RAG 检索到多轮对话记忆，从工具调用的上下文注入到超长文档的窗口管理，上下文的编排艺术正在成为区分优秀 AI 应用与普通聊天机器人的分水岭。本文将深入剖析上下文工程的核心原则、架构模式和实践策略，为你构建生产级 LLM 应用提供系统性的方法论。

一、为什么上下文工程如此重要

大语言模型的本质是一个条件概率生成器：给定一段上下文，生成下一个 token。这意味着模型的输出质量直接取决于输入上下文的质量。与微调相比，上下文工程具有以下独特优势：

• 即时性：不需要重新训练，注入上下文即可获得新能力
• 灵活性：同一模型可通过不同上下文扮演不同角色
• 经济性：避免高昂的微调成本，经济实惠的迭代方式
• 可解释性：显式控制模型"看到什么"，比黑盒微调更易调试

然而，上下文窗口并非越大越好。研究表明，在超长上下文中，模型对中间段落的注意力显著下降——这就是著名的"Lost in the Middle"现象。因此，上下文的质量远比数量重要。

二、上下文的五个层次

一个完整的 LLM 应用上下文，通常包含以下五个层次，从底层到顶层依次构建：

2.1 系统层上下文（System Context）

系统提示词（System Prompt）定义了模型的身份、能力边界和行为准则。一个精心设计的系统提示词应包含：

# 角色定义
你是一名资深的云原生架构师，专注于 Kubernetes 和微服务领域。

# 行为准则
- 回答需简洁、结构化，避免冗长的前言
- 涉及代码示例时优先使用生产级写法
- 主动指出潜在的生产风险和反模式
- 对不确定的信息明确标注"待验证"

# 输出格式
采用"问题诊断 → 根因分析 → 解决方案 → 预防措施"四段式结构。

2.2 检索增强上下文（Retrieval-Augmented Context）

RAG（Retrieval-Augmented Generation）是当前上下文工程最核心的技术手段。但它远非"检索+拼接"那么简单：

• 分块策略：固定大小分块简单易行但容易切割语义；语义分块和递归分块效果更好但计算成本更高
• 嵌入模型选择：OpenAI text-embedding-3-large、Cohere embed-v3、BGE-M3 各有适用场景，中文场景需特别验证
• 重排序机制：初次检索结果往往含噪声，Cross-Encoder 重排序可显著提升精确率
• 查询改写：将用户原始问题扩展为多个子查询或假设性答案（HyDE），提升召回率

2.3 工具上下文（Tool Context）

当 LLM 需要调用外部工具（函数调用）时，工具定义本身就是一种上下文。良好的工具上下文设计遵循"少即是多"原则：

{
  "name": "search_documents",
  "description": "在用户知识库中搜索相关文档。当用户询问公司内部流程、技术规范或产品信息时使用此工具。",
  "parameters": {
    "query": {
      "type": "string",
      "description": "搜索查询（建议使用关键词组合而非自然语句）"
    },
    "max_results": {
      "type": "number",
      "description": "返回结果数量，默认5条，最多20条"
    }
  }
}

工具描述的 clarity 直接影响模型的调用决策质量——模糊的描述会导致误调用，而过长的描述则浪费宝贵的 token 预算。

2.4 会话层上下文（Session Context）

多轮对话需要维护会话状态。核心挑战在于：如何在有限的窗口内保留最有价值的对话历史？常见策略包括：

• 滑动窗口：保留最近 N 轮对话，简单粗暴但可能丢失早期关键信息
• 摘要压缩：定期用 LLM 将历史对话压缩为结构化摘要
• 重要性采样：根据信息密度计算每条消息的"信息价值"，优先保留高价值内容
• 分层记忆：短期记忆（当前轮次）、中期记忆（本轮会话摘要）、长期记忆（跨会话持久化）

2.5 上下文优先级（Context Priority & Budget）

当所有层的上下文总和超出窗口限制时，需要进行优先级裁剪。推荐的分配策略是：系统提示词占 15-20%、检索结果占 40-50%、工具定义占 10%、对话历史占 20-30%。

三、上下文工程的四种架构模式

在真实生产环境中，上下文工程通常演化为以下四种架构模式：

3.1 线性注入模式（Linear Injection）

最基础的架构：系统提示 → 检索结果 → 用户问题，依次拼接后送入模型。适用于单轮问答、文档阅读等简单场景。

优点是简单可控，缺点是随着交互加深，线性拼接很快会超出窗口限制，且每次请求的 token 消耗线性增长。

3.2 动态路由模式（Dynamic Routing）

根据用户意图动态决定注入哪些上下文。例如：用户询问技术问题时注入代码库检索结果，询问数据分析时注入 schema 信息，闲聊时则仅保留系统提示。

实现上通常需要一个"意图分类器"（可以是轻量模型或规则引擎），在完整上下文组装之前先做一次快速路由决策。这种模式显著降低了平均 token 消耗，但对分类器的准确率有较高要求。

3.3 分层缓存模式（Hierarchical Caching）

将上下文分为热、温、冷三层：热上下文（如系统提示、核心安全规则）常驻内存且只发送一次；温上下文（如用户画像、频繁访问的文档）按需加载到上下文窗口；冷上下文（如历史对话归档）需要时从存储中检索。

这种模式特别适合企业级应用：通过缓存系统提示和工具定义，每次 API 调用的 token 成本可降低 30-60%（配合 Prompt Caching 功能）。

3.4 自适应进化模式（Adaptive Evolution）

最高级的架构：上下文本身会随着交互进行自我优化。具体包括：

• 上下文反馈循环：根据模型输出质量，动态调整检索的 top-k 数量
• 记忆巩固：高频出现的信息自动提升为长期记忆，减少重复检索
• 失败回退：当模型在给定上下文下输出质量下降时，自动触发补充检索
• 个性化适配：根据用户的知识背景和偏好，调整上下文的深度和风格

四、十大上下文反模式与规避策略

在实际工程中，上下文工程存在大量容易踩到的"坑"：

五、生产级上下文管道的实现要点

将上下文工程落地为生产系统，需要关注以下核心工程问题：

5.1 Token 预算系统

实现一个 token 计数器（或使用 tiktoken 库精确计算），在所有上下文进入窗口前进行预算分配。推荐为每个上下文层设置硬上限和软上限：达到软上限时触发压缩，达到硬上限时强制执行截断。

5.2 可观测性

上下文工程最大的挑战在于"黑盒感"——你不知道模型到底"看到"了什么。建议构建以下监控能力：

• 每次请求的上下文组成分析（系统/检索/工具/历史各占比）
• 检索结果的相关性人工标注和自动化评估
• 模型输出与输入上下文的归因分析（哪些上下文实际影响了输出）
• 上下文变更与输出质量的 A/B 测试实验框架

5.3 安全护栏

对外开放的 AI 应用必须防范上下文注入攻击（Context Injection）。攻击者可能在网页内容中嵌入隐藏指令，当这些内容被 RAG 系统检索并成为上下文的一部分时，就可能被模型执行。防御策略包括：严格的角色隔离、输入输出的双层检测、以及清晰的指令/数据边界标记。

六、未来展望

上下文工程正在从"手工艺"走向"工业化"。随着 Anthropic 的 Prompt Caching、Gemini 的 200 万 token 超长窗口、以及各类上下文压缩技术的成熟，上下文工程的边界正在快速扩展。但核心原则始终未变：

上下文的本质不是"给模型更多信息"，而是"给模型在特定时刻最需要的信息"。

未来的 AI 应用架构师，本质上将是"上下文架构师"——谁能在正确的时间以正确的粒度向模型注入正确的信息，谁就能将 LLM 的潜力发挥到极致。上下文工程，正是通往这一目标的必经之路。