Context Engineering 实战：LLM 应用的上下文管理完全指南

如果你正在构建 LLM 应用，那么 Context Engineering（上下文工程）是你必须掌握的核心技能。2026 年，Andrej Karpathy 在多个公开演讲中反复强调：Prompt Engineering 已经过时，Context Engineering 才是未来。这不是文字游戏——当你的 AI Agent 需要在 128K token 的上下文窗口中同时处理用户对话历史、RAG 检索结果、工具调用返回值和系统指令时，如何高效管理这些上下文，直接决定了应用的质量和成本。根据 Anthropic 2026 年 Q1 的内部数据，超过 60% 的 LLM 应用质量问题源于上下文管理不当，而非模型能力不足。

本文将从生产实战角度，系统讲解 Context Engineering 的核心技术——上下文窗口管理、Token 预算分配、Prompt 压缩、结构化输出和动态上下文组装，并提供完整的 TypeScript 实现。

🧠 一、Context Engineering 核心理念与架构

1.1 从 Prompt Engineering 到 Context Engineering

很多人把 Context Engineering 等同于"写更好的 Prompt"，这是严重的误解。Prompt Engineering 关注的是如何措辞单条指令，而 Context Engineering 关注的是如何组装和管理发给 LLM 的全部信息。

一个典型的 LLM 应用上下文由以下部分组成：

⚡ 关键结论：Context Engineering 的本质是一个资源分配问题——在有限的上下文窗口中，如何为每个组件分配最优的 Token 预算，使得 LLM 的输出质量最大化、成本最小化。

1.2 上下文窗口的工程挑战

当前主流模型的上下文窗口大小对比：

看起来上下文窗口够大了？错。三个核心问题：

1. 成本爆炸：一次包含 100K token 输入的 GPT-4o 调用成本 $0.25，如果每轮对话都塞满上下文，1000 次对话就是 $250
2. 性能退化：研究表明，当上下文超过窗口的 60% 时，LLM 对中间位置信息的召回率显著下降（“Lost in the Middle” 问题）
3. 延迟增加：100K token 的输入比 10K token 的输入慢 3-5 倍

1.3 Context Engineering 架构模式

一个生产级的 Context Engineering 系统应该包含以下组件：

用户输入 → 查询分析器 → 上下文组装器 → Token 预算管理器 → LLM 调用
                ↑              ↑              ↑
           对话历史管理器  RAG 检索器    Prompt 压缩器
                ↑              ↑              ↑
           摘要/滑动窗口  重排序/过滤   摘要/蒸馏

🔧 二、核心技术实现

2.1 Token 预算管理器

Token 预算管理是 Context Engineering 的基石。我们需要为每个上下文组件分配 Token 预算，并确保总预算不超过模型的上下文窗口。

// token-budget-manager.ts — Token 预算分配与管理
interface TokenBudget {
  systemPrompt: number    // 系统指令预算
  chatHistory: number     // 对话历史预算
  retrievalResults: number // RAG 检索结果预算
  toolDescriptions: number // 工具描述预算
  toolResults: number     // 工具返回值预算
  userQuery: number       // 用户输入预算（通常不限制）
  reserve: number         // 预留空间（给输出）
}

interface BudgetAllocation {
  component: keyof TokenBudget
  allocated: number
  used: number
  compressed: boolean
}

class ContextBudgetManager {
  private totalWindow: number
  private budget: TokenBudget
  private allocations: BudgetAllocation[] = []

  constructor(model: 'gpt-4o' | 'claude-sonnet' | 'gemini-flash', strategy: 'balanced' | 'rag-priority' | 'history-priority' = 'balanced') {
    // 根据模型设置总窗口大小
    const windows = { 'gpt-4o': 128000, 'claude-sonnet': 200000, 'gemini-flash': 1000000 }
    this.totalWindow = windows[model]
    this.budget = this.allocateBudget(strategy)
  }

  private allocateBudget(strategy: string): TokenBudget {
    const usable = Math.floor(this.totalWindow * 0.85) // 预留 15% 给输出
    const ratios: Record<string, Omit<TokenBudget, 'userQuery' | 'reserve'>> = {
      balanced: {
        systemPrompt: 0.08,
        chatHistory: 0.30,
        retrievalResults: 0.35,
        toolDescriptions: 0.07,
        toolResults: 0.20,
      },
      'rag-priority': {
        systemPrompt: 0.05,
        chatHistory: 0.15,
        retrievalResults: 0.55,
        toolDescriptions: 0.05,
        toolResults: 0.20,
      },
      'history-priority': {
        systemPrompt: 0.08,
        chatHistory: 0.50,
        retrievalResults: 0.20,
        toolDescriptions: 0.07,
        toolResults: 0.15,
      },
    }
    const r = ratios[strategy]
    return {
      systemPrompt: Math.floor(usable * r.systemPrompt),
      chatHistory: Math.floor(usable * r.chatHistory),
      retrievalResults: Math.floor(usable * r.retrievalResults),
      toolDescriptions: Math.floor(usable * r.toolDescriptions),
      toolResults: Math.floor(usable * r.toolResults),
      userQuery: 0,       // 动态分配
      reserve: Math.floor(this.totalWindow * 0.15),
    }
  }

  // 检查某个组件是否超出预算
  checkBudget(component: keyof TokenBudget, actualTokens: number): { withinBudget: boolean; overBy: number } {
    const allocated = this.budget[component]
    return {
      withinBudget: actualTokens <= allocated,
      overBy: Math.max(0, actualTokens - allocated),
    }
  }

  // 获取剩余可用 Token 数
  getRemainingBudget(): number {
    const totalAllocated = Object.values(this.budget).reduce((sum, v) => sum + v, 0)
    return this.totalWindow - totalAllocated
  }

  getBudget(): TokenBudget {
    return { ...this.budget }
  }
}

// 使用示例
const manager = new ContextBudgetManager('gpt-4o', 'rag-priority')
const budget = manager.getBudget()
console.log(`RAG 检索结果预算: ${budget.retrievalResults} tokens`)  // 约 47,600 tokens
console.log(`对话历史预算: ${budget.chatHistory} tokens`)            // 约 13,600 tokens

💡 提示：strategy 参数决定了 Token 分配的侧重方向。对于知识密集型应用（如文档问答），用 rag-priority；对于多轮对话型应用（如客服机器人），用 history-priority。

2.2 对话历史压缩：滑动窗口 + 摘要

对话历史是 Token 消耗的大头。一个 10 轮对话可能轻松超过 20K tokens。我们需要两种策略的组合：**滑动窗口（Sliding Window）**保留最近的对话，**摘要压缩（Summary Compression）**压缩早期的对话。

// chat-history-manager.ts — 对话历史管理与压缩
import OpenAI from 'openai'

const openai = new OpenAI()

interface ChatMessage {
  role: 'system' | 'user' | 'assistant' | 'tool'
  content: string
  tokenCount: number
  timestamp: number
}

interface CompressedHistory {
  summary: string           // 早期对话的摘要
  recentMessages: ChatMessage[] // 最近的对话（保留原文）
  totalTokens: number
}

class ChatHistoryManager {
  private messages: ChatMessage[] = []
  private summary: string = ''
  private maxRecentMessages: number
  private summaryThreshold: number // 超过多少条消息时触发摘要

  constructor(maxRecentMessages = 10, summaryThreshold = 20) {
    this.maxRecentMessages = maxRecentMessages
    this.summaryThreshold = summaryThreshold
  }

  addMessage(msg: ChatMessage): void {
    this.messages.push(msg)
    // 消息数量超过阈值时，压缩早期对话
    if (this.messages.length > this.summaryThreshold) {
      this.compressHistory()
    }
  }

  private compressHistory(): void {
    // 保留最近 N 条消息，将其余消息压缩为摘要
    const toCompress = this.messages.slice(0, -this.maxRecentMessages)
    const toKeep = this.messages.slice(-this.maxRecentMessages)

    // 将需要压缩的消息转为文本
    const conversationText = toCompress
      .map(m => `${m.role}: ${m.content}`)
      .join('\n')

    // 用 LLM 生成摘要（使用便宜的模型）
    this.generateSummary(conversationText).then(summary => {
      this.summary = summary
      this.messages = toKeep
    })
  }

  private async generateSummary(text: string): Promise<string> {
    const response = await openai.chat.completions.create({
      model: 'gpt-4o-mini', // 用便宜模型做摘要
      temperature: 0,
      messages: [
        {
          role: 'system',
          content: `将以下对话压缩为简洁的摘要，保留关键信息、用户偏好、决策结论和待办事项。摘要不超过 500 字。`
        },
        { role: 'user', content: text }
      ],
    })
    return response.choices[0].message.content || ''
  }

  // 获取压缩后的对话历史（用于发送给 LLM）
  getCompressedHistory(): CompressedHistory {
    const recentMessages = this.messages.slice(-this.maxRecentMessages)
    const recentTokens = recentMessages.reduce((sum, m) => sum + m.tokenCount, 0)
    const summaryTokens = Math.ceil(this.summary.length / 3) // 粗略估算中文 token 数

    return {
      summary: this.summary,
      recentMessages,
      totalTokens: summaryTokens + recentTokens,
    }
  }

  // 构建发给 LLM 的消息数组
  buildMessages(systemPrompt: string): Array<{ role: string; content: string }> {
    const compressed = this.getCompressedHistory()
    const messages: Array<{ role: string; content: string }> = []

    // 1. 系统指令
    messages.push({ role: 'system', content: systemPrompt })

    // 2. 历史摘要（如果有）
    if (compressed.summary) {
      messages.push({
        role: 'system',
        content: `[以下是对早期对话的摘要]\n${compressed.summary}`
      })
    }

    // 3. 最近的对话
    for (const msg of compressed.recentMessages) {
      messages.push({ role: msg.role, content: msg.content })
    }

    return messages
  }
}

// 使用示例
const historyManager = new ChatHistoryManager(10, 20)
// 模拟添加对话...
historyManager.addMessage({ role: 'user', content: '帮我写一个排序算法', tokenCount: 15, timestamp: Date.now() })
historyManager.addMessage({ role: 'assistant', content: '好的，这是一个快速排序实现...', tokenCount: 200, timestamp: Date.now() })

const messages = historyManager.buildMessages('你是一个编程助手')
console.log(`发送给 LLM 的消息数: ${messages.length}`)

⚠️ **警告：**摘要压缩是有损的——早期对话中的细节会丢失。如果用户说"我之前提到的那个蓝色按钮"，而这个信息已经被压缩进摘要中，LLM 可能无法准确定位。对于关键业务场景，建议保留完整的对话历史到数据库，仅在构建上下文时做压缩。

2.3 RAG 检索结果的智能裁剪

RAG 检索返回的文档往往超出 Token 预算。我们需要一个智能裁剪器，根据相关性分数和上下文冗余度来决定保留哪些内容。

// retrieval-trimmer.ts — RAG 检索结果智能裁剪
interface RetrievalChunk {
  content: string
  source: string
  score: number        // 相关性分数 (0-1)
  tokenCount: number
}

class RetrievalTrimmer {
  private tokenBudget: number
  private minScore: number       // 最低相关性阈值
  private redundancyThreshold: number // 冗余度阈值

  constructor(tokenBudget: number, minScore = 0.3, redundancyThreshold = 0.85) {
    this.tokenBudget = tokenBudget
    this.minScore = minScore
    this.redundancyThreshold = redundancyThreshold
  }

  // 核心裁剪算法
  trim(chunks: RetrievalChunk[]): RetrievalChunk[] {
    // 第一步：过滤低相关性文档
    let filtered = chunks.filter(c => c.score >= this.minScore)

    // 第二步：按相关性分数降序排列
    filtered.sort((a, b) => b.score - a.score)

    // 第三步：贪心选择，在预算内尽可能保留高相关性文档
    const selected: RetrievalChunk[] = []
    let usedTokens = 0

    for (const chunk of filtered) {
      if (usedTokens + chunk.tokenCount <= this.tokenBudget) {
        // 第四步：检查与已选文档的冗余度
        if (!this.isRedundant(chunk, selected)) {
          selected.push(chunk)
          usedTokens += chunk.tokenCount
        }
      }
      // 如果当前文档放不下，尝试截断
      else if (selected.length === 0) {
        const remaining = this.tokenBudget - usedTokens
        if (remaining > 100) { // 至少保留 100 tokens 才有意义
          selected.push({
            ...chunk,
            content: this.truncateContent(chunk.content, remaining),
            tokenCount: remaining,
          })
          break
        }
      }
    }

    return selected
  }

  // 简化的冗余度检测（基于字符重叠率）
  private isRedundant(chunk: RetrievalChunk, selected: RetrievalChunk[]): boolean {
    if (selected.length === 0) return false

    for (const existing of selected) {
      const overlap = this.calculateOverlap(chunk.content, existing.content)
      if (overlap > this.redundancyThreshold) {
        return true
      }
    }
    return false
  }

  private calculateOverlap(text1: string, text2: string): number {
    const words1 = new Set(text1.split(/\s+/))
    const words2 = new Set(text2.split(/\s+/))
    let overlap = 0
    for (const word of words1) {
      if (words2.has(word)) overlap++
    }
    return overlap / Math.max(words1.size, words2.size)
  }

  private truncateContent(content: string, maxTokens: number): string {
    // 粗略截断：按字符数估算（中文约 1 字 = 1.5 tokens）
    const maxChars = Math.floor(maxTokens * 0.7)
    if (content.length <= maxChars) return content
    return content.slice(0, maxChars) + '...[已截断]'
  }
}

// 使用示例
const trimmer = new RetrievalTrimmer(5000) // 5000 token 预算
const chunks: RetrievalChunk[] = [
  { content: 'React 19 引入了 Server Components...', source: 'docs/react.md', score: 0.95, tokenCount: 2000 },
  { content: 'React 19 的 Server Components 特性...', source: 'blog/react19.md', score: 0.88, tokenCount: 1800 }, // 与第一条高度冗余
  { content: 'Vue 3.5 的响应式系统改进...', source: 'docs/vue.md', score: 0.72, tokenCount: 1500 },
  { content: 'Svelte 5 的 Runes 响应式机制...', source: 'docs/svelte.md', score: 0.65, tokenCount: 2200 },
  { content: 'Angular 18 的 Signals 特性...', source: 'docs/angular.md', score: 0.45, tokenCount: 1800 },
]

const result = trimmer.trim(chunks)
console.log(`保留了 ${result.length} 个文档片段`) // 3 个（排除了冗余的第二条和低分的最后一条）
console.log(`总 Token: ${result.reduce((s, c) => s + c.tokenCount, 0)}`)

💡 **提示：**冗余度检测对于 RAG 场景至关重要。当你的知识库中有多篇关于同一主题的文档时，检索引擎可能返回多条高度相似的内容。保留它们不仅浪费 Token，还会让 LLM 过度偏向某个观点。

2.4 结构化输出：让 LLM 返回可靠 JSON

Context Engineering 不仅是管理输入上下文，还包括约束输出格式。当你需要 LLM 返回结构化数据时，JSON Schema 约束是必须的。

// structured-output.ts — 使用 JSON Schema 约束 LLM 输出
import OpenAI from 'openai'
import { z } from 'zod'
import { zodResponseFormat } from 'openai/helpers/zod'

const openai = new OpenAI()

// 定义输出 Schema
const CodeReviewSchema = z.object({
  overallScore: z.number().min(1).max(10).describe('代码质量总分 1-10'),
  issues: z.array(z.object({
    severity: z.enum(['critical', 'warning', 'info']),
    line: z.number(),
    message: z.string(),
    suggestion: z.string(),
  })),
  summary: z.string().describe('一句话总结代码质量'),
  refactored: z.boolean().describe('是否需要重构'),
})

type CodeReview = z.infer<typeof CodeReviewSchema>

async function reviewCode(code: string, language: string): Promise<CodeReview> {
  const response = await openai.beta.chat.completions.parse({
    model: 'gpt-4o',
    temperature: 0,
    response_format: zodResponseFormat(CodeReviewSchema, 'code_review'),
    messages: [
      {
        role: 'system',
        content: `你是一个资深代码审查专家。审查用户提交的 ${language} 代码，返回结构化的审查结果。`
      },
      { role: 'user', content: `\`\`\`${language}\n${code}\n\`\`\`` }
    ],
  })

  return response.choices[0].message.parsed!
}

// 使用示例
const review = await reviewCode(`
function fetchData(url) {
  const response = fetch(url)
  return response.json()
}
`, 'javascript')

console.log(`代码质量评分: ${review.overallScore}/10`)
console.log(`发现问题数: ${review.issues.length}`)
console.log(`需要重构: ${review.refactored ? '是' : '否'}`)
// 输出: 代码质量评分: 4/10
// 输出: 发现问题数: 2
// 输出: 需要重构: 是

⚠️ **警告：**不要手动拼接 JSON Schema 字符串到 Prompt 中让 LLM “按格式返回”。这种方式在输入较长时极不稳定——LLM 容易遗漏字段或生成无效 JSON。必须使用 API 的 response_format 参数或 Function Calling 来强制约束输出格式。

🚀 三、生产级 Context Assembly Pipeline

3.1 动态上下文组装器

将前面的所有组件组合成一个完整的上下文组装管道：

// context-assembler.ts — 生产级上下文组装管道
interface ContextAssemblyInput {
  userQuery: string
  systemPrompt: string
  tools?: Array<{ name: string; description: string; parameters: object }>
  retrievalResults?: RetrievalChunk[]
  chatHistory?: ChatMessage[]
  budgetStrategy?: 'balanced' | 'rag-priority' | 'history-priority'
}

interface AssembledContext {
  messages: Array<{ role: string; content: string }>
  tokenCount: number
  budgetUsage: Record<string, { allocated: number; used: number }>
  compressionApplied: string[]
}

class ContextAssembler {
  private budgetManager: ContextBudgetManager
  private historyManager: ChatHistoryManager
  private trimmer: RetrievalTrimmer

  constructor(model: 'gpt-4o' | 'claude-sonnet' | 'gemini-flash' = 'gpt-4o') {
    this.budgetManager = new ContextBudgetManager(model, 'balanced')
    this.historyManager = new ChatHistoryManager(10, 20)
    this.trimmer = new RetrievalTrimmer(0) // 预算在 assemble 时动态设置
  }

  async assemble(input: ContextAssemblyInput): Promise<AssembledContext> {
    const budget = this.budgetManager.getBudget()
    const compressionApplied: string[] = []
    const budgetUsage: Record<string, { allocated: number; used: number }> = {}
    const messages: Array<{ role: string; content: string }> = []

    // 1. 系统指令（通常不需要压缩）
    messages.push({ role: 'system', content: input.systemPrompt })
    budgetUsage.systemPrompt = {
      allocated: budget.systemPrompt,
      used: Math.ceil(input.systemPrompt.length / 2),
    }

    // 2. 工具描述（如果有）
    if (input.tools?.length) {
      const toolDescriptions = input.tools
        .map(t => `${t.name}: ${t.description}`)
        .join('\n')
      if (toolDescriptions.length / 2 > budget.toolDescriptions) {
        compressionApplied.push('工具描述已截断')
      }
      messages.push({
        role: 'system',
        content: `[可用工具]\n${toolDescriptions}`
      })
    }

    // 3. 对话历史（应用压缩）
    if (input.chatHistory?.length) {
      for (const msg of input.chatHistory) {
        this.historyManager.addMessage(msg)
      }
      const compressed = this.historyManager.getCompressedHistory()
      if (compressed.summary) {
        compressionApplied.push(`对话历史已压缩: ${input.chatHistory.length} 条 → 摘要 + ${compressed.recentMessages.length} 条`)
      }
      // 将压缩后的历史插入到系统指令之后
      if (compressed.summary) {
        messages.splice(1, 0, {
          role: 'system',
          content: `[对话历史摘要]\n${compressed.summary}`
        })
      }
      for (const msg of compressed.recentMessages) {
        messages.push({ role: msg.role, content: msg.content })
      }
      budgetUsage.chatHistory = {
        allocated: budget.chatHistory,
        used: compressed.totalTokens,
      }
    }

    // 4. RAG 检索结果（应用裁剪）
    if (input.retrievalResults?.length) {
      const trimmer = new RetrievalTrimmer(budget.retrievalResults)
      const trimmed = trimmer.trim(input.retrievalResults)
      if (trimmed.length < input.retrievalResults.length) {
        compressionApplied.push(`RAG 结果已裁剪: ${input.retrievalResults.length} 条 → ${trimmed.length} 条`)
      }
      const ragContent = trimmed
        .map((c, i) => `[来源 ${i + 1}: ${c.source}] (相关度: ${(c.score * 100).toFixed(0)}%)\n${c.content}`)
        .join('\n\n')
      messages.push({ role: 'system', content: `[参考资料]\n${ragContent}` })
      budgetUsage.retrievalResults = {
        allocated: budget.retrievalResults,
        used: trimmed.reduce((s, c) => s + c.tokenCount, 0),
      }
    }

    // 5. 用户输入（最后添加）
    messages.push({ role: 'user', content: input.userQuery })

    // 计算总 Token
    const totalTokens = Object.values(budgetUsage).reduce((s, v) => s + v.used, 0)

    return { messages, tokenCount: totalTokens, budgetUsage, compressionApplied }
  }
}

// 使用示例
const assembler = new ContextAssembler('gpt-4o')
const context = await assembler.assemble({
  userQuery: '如何优化 React 应用的首屏加载速度？',
  systemPrompt: '你是一个前端性能优化专家。',
  tools: [
    { name: 'lighthouse', description: '运行 Lighthouse 性能审计', parameters: {} },
    { name: 'webpack-analyzer', description: '分析 Webpack 打包结果', parameters: {} },
  ],
  retrievalResults: [
    { content: 'React.lazy 和 Suspense 实现代码分割...', source: 'react-docs', score: 0.92, tokenCount: 1500 },
    { content: '图片懒加载最佳实践...', source: 'web-dev', score: 0.85, tokenCount: 800 },
  ],
  chatHistory: [
    { role: 'user', content: '我在用 Next.js 14', tokenCount: 10, timestamp: Date.now() },
    { role: 'assistant', content: '好的，Next.js 14 支持...', tokenCount: 150, timestamp: Date.now() },
  ],
})

console.log(`组装完成: ${context.messages.length} 条消息, ~${context.tokenCount} tokens`)
console.log(`压缩措施: ${context.compressionApplied.join(', ') || '无'}`)

3.2 成本对比：优化前 vs 优化后

以下是一个典型的 RAG 应用在实施 Context Engineering 前后的对比：

⚡ 关键结论：Context Engineering 不仅降低了成本，还提升了回答准确率。原因很简单：无关信息减少后，LLM 能更专注于关键内容，减少了"注意力分散"导致的错误。

⚠️ 四、常见陷阱与避坑指南

4.1 五大常见错误

❌ 错误一：把所有历史消息都塞进上下文

很多开发者不做对话历史管理，每次都把完整的历史发给 LLM。20 轮对话后，输入 Token 轻松突破 50K，成本和延迟都不可接受。

✅ 正确做法：使用滑动窗口 + 摘要压缩，保留最近 5-10 轮对话 + 历史摘要。

❌ 错误二：RAG 检索结果不裁剪直接塞入

向量检索返回 Top-10 结果，每条 500 tokens，总计 5000 tokens。但其中可能有 3 条是冗余的，2 条是低相关性的。

✅ 正确做法：先过滤低分结果，再去重（冗余检测），最后按预算截断。

❌ 错误三：用自然语言约束输出格式

“请以 JSON 格式返回，包含 name、age、email 三个字段”——这种方式在上下文较长时极不稳定。

✅ 正确做法：使用 API 的 response_format 或 tools 参数强制约束输出 Schema。

❌ 错误四：忽视 System Prompt 的 Token 开销

一个 2000 字的 System Prompt 在 GPT-4o 上消耗约 1500 tokens，每次调用都计入成本。如果每天调用 10000 次，仅 System Prompt 就消耗 15M tokens = $37.5/天。

✅ 正确做法：精简 System Prompt，将不常用指令改为动态注入。使用 Prompt 缓存（如 OpenAI 的 Automatic Prompt Caching）降低成本。

❌ 错误五：不做 Token 计数就直接调用 API

“我的上下文应该没超吧？”——然后收到 context_length_exceeded 错误，或者更糟：静默截断导致输出质量下降。

✅ 正确做法：在发送请求前，使用 tiktoken 或模型厂商提供的 Token 计数 API 进行精确计算。

// token-counter.ts — 精确计算 Token 数
import { encoding_for_model } from 'tiktoken'

function countTokens(text: string, model: string = 'gpt-4o'): number {
  const enc = encoding_for_model(model as any)
  const tokens = enc.encode(text)
  enc.free()
  return tokens.length
}

// 在发送前检查
const messages = [{ role: 'user', content: '...' }]
const totalTokens = messages.reduce((sum, m) => sum + countTokens(m.content), 0)
if (totalTokens > 120000) {
  console.warn(`⚠️ Token 数 ${totalTokens} 接近窗口上限，建议压缩上下文`)
}

4.2 生产环境 Checklist

• ✅ 为每种模型配置 Token 预算分配策略
• ✅ 实现对话历史的滑动窗口 + 摘要压缩
• ✅ RAG 检索结果必须经过过滤、去重、截断
• ✅ 使用 API 的结构化输出功能，不依赖自然语言约束
• ✅ 在发送前进行 Token 计数校验
• ✅ 监控每次调用的 Token 消耗和成本
• ✅ 为 System Prompt 启用缓存机制
• ✅ 为不同场景配置不同的预算策略

💡 五、总结与工具推荐

Context Engineering 是 LLM 应用开发中最被低估的工程学科。大多数团队把精力花在"选哪个模型更好"上，却忽略了同样的模型，通过上下文优化可以获得 30-50% 的质量提升和 70%+ 的成本降低。

核心原则总结：

1. 预算优先：在组装上下文之前，先分配 Token 预算
2. 分层压缩：对话历史用摘要压缩，RAG 结果用相关性裁剪
3. 结构化输出：用 Schema 约束输出，不用自然语言
4. 动态组装：根据查询复杂度动态调整上下文策略
5. 监控成本：每次调用都要记录 Token 消耗，建立成本基线

相关工具推荐：

📌 **记住：**Context Engineering 不是一次性的工作，而是一个持续优化的过程。建立 Token 消耗监控，定期分析上下文组装的效果，根据实际数据调整预算策略——这才是生产级 LLM 应用的正确打开方式。