LLM Wiki

Context-Engineering

17分钟阅读

Context Engineering（上下文工程）

一句话定义

Context Engineering是精心挑选、组织和压缩信息的工程实践，目标是在有限的上下文窗口内，让大模型获得回答问题所需的最优知识，是Prompt Engineering在AI时代的进化形态。

摘要

Context Engineering由大淘宝技术团队在AI Friendly架构实践中明确提出，作为对Prompt Engineering的升级。其核心观点是：Prompt Engineering始终是一门经验学科，当前各种提示词技巧本质上是在弥补大模型能力的不足；而当模型能力增强后，过多的提示词反而会成为累赘。Context Engineering关注的是如何从更宏观的角度管理上下文——包括RAG检索、记忆管理、知识图谱、动态剪枝等，让模型在有限窗口内获得最优信息。

详情

起源与背景

Context Engineering的概念在2025-2026年间随着Agent系统的成熟而逐渐清晰。早期的Prompt Engineering聚焦于如何写好单个提示词，但随着Agent系统变得复杂（多轮对话、多工具调用、多知识源），单靠提示词技巧已无法满足需求。上下文工程应运而生，它从系统工程的角度管理模型的输入信息。

核心机制 / 工作原理

与Prompt Engineering的区别

Prompt Engineering：
- 关注单个提示词的质量
- 经验驱动，依赖模板和技巧
- 本质上弥补模型能力不足
- 模型变强后可能成为累赘

Context Engineering：
- 关注整体上下文的组织
- 工程驱动，系统化设计
- 本质上优化信息输入
- 模型变强后价值更高

上下文的组成

一个完整的上下文通常包含以下部分：

  1. 系统提示：角色定义、行为约束
  2. 知识检索：RAG召回的相关文档
  3. 记忆：短期（当前对话）和长期（历史摘要）
  4. 工具描述：可用工具的定义和说明
  5. 用户输入：当前查询

关键技术

历史案例库：通过向量检索相似历史案例为模型提供参考。在秒杀AI审核中，历史审核案例库通过图片、标题等维度的相似性检索，带来约8%的准确率提升。

混合审核决策：多模型投票+置信度机制，通过引入水位有差异的多模型进行多次判断，结论一致且置信度较高时带来10%以上的准确率提升。

Advance RAG：知识图谱与结构化（如GraphRAG）、动态上下文剪枝（Context Pruning）等高级RAG技术。

长短记忆管理：短期记忆保持当前对话上下文，长期记忆存储历史交互摘要。

关键技术模式

1. RAG检索优化

基础的RAG（Retrieval-Augmented Generation）通过向量检索将相关文档注入上下文。但在实际应用中，单纯的top-K检索往往不够精准，需要结合重排序（Rerank）、混合检索（关键词+向量）、元数据过滤等技术来提升召回质量。

2. 知识图谱增强

知识图谱可以建立实体之间的关系网络，在需要多跳推理的场景（如答疑场景）效果显著。当用户问”X商品的Y活动为什么审核不通过”时，知识图谱可以帮助系统理解X、Y、审核规则之间的关联关系，而不仅仅是依赖文本相似度检索。代表性技术产品为GraphRAG。

3. 动态上下文剪枝（Context Pruning）

当上下文窗口有限而召回内容较多时，需要动态裁剪掉冗余信息。剪枝策略包括：按相关性得分裁剪、按信息熵裁剪（保留信息量最大的片段）、以及基于大模型反馈的自适应剪枝。

4. 长短记忆管理

  • 短期记忆（Working Memory）：保持当前对话轮次的上下文，通常在10-50轮之间
  • 长期记忆（Long-term Memory）：通过摘要、向量化存储历史交互，在需要时检索召回
  • 记忆压缩：当对话过长时，通过摘要压缩历史上下文，保留关键信息

5. 上下文窗口优化

  • 信息分层：将上下文分为”必需层”和”补充层”，优先保证必需层
  • 动态加载：根据当前任务动态加载相关上下文
  • Token预算管理：为不同上下文来源分配Token预算配额

6. 个人工作流中的上下文质量

在个人使用 AI 的场景中，上下文工程不一定表现为复杂系统，最小形态是”给材料、给边界、给标准”：把会议记录、用户反馈、代码仓库、竞品页面、历史文档、数据表、错误日志等真实材料交给模型，再明确目标、约束、反例和验收标准。信息越具体，AI 越像帮手；信息越少，AI 越像在猜。

7. 状态外置与按需加载

生产级 Agent 的上下文治理不是只做摘要压缩。淘宝主播 Agent 用 Reducer 维护结构化 State，模型只产生 Action，每轮通过 system-hint 读最新状态，避免完整工具 JSON 堆进历史；淘宝企业购 Skill 流水线用索引、references 和子 Skill 按需加载单接口上下文；Token 经济学进一步说明，Memory、Rules、Skills、MCP 的加载策略本身就是上下文成本控制的一部分。

腾讯技术工程的 SpecWorker 实践把这个原则推进到阶段级：P1 读需求和验收条件，P2 读设计契约，P3 的 reviewer 优先读 git diff 与关键片段，P4 的 debugger 按 trace-id 拉日志和数据证据，P6 再把 delta spec 增量沉回知识库。这里最关键的经验是 SubAgent 不是免费的上下文隔离：每个 SubAgent 读全文件都会独立计费，所以上下文注入必须和阶段、角色、证据链绑定。

业界实践

Anthropic在其官方文档中系统性地介绍了Effective Context Engineering for AI Agents，将上下文工程视为提升Agent表现的关键手段，强调”精心挑选、组织、压缩上下文信息”的重要性，与本文中Context Engineering的定义高度一致。

Anthropic 框架：核心原则与四大要素（claude-mem 文档复述）

claude-mem 文档系统复述了 Anthropic《Effective context engineering for AI agents》（2025-09）的框架，可作为本实体的方法论骨架。其核心原则是：寻找能最大化目标达成概率的、尽可能小的高信号 token 集合（optimize signal-to-noise ratio）。病灶是「上下文腐烂（context rot）」——每个 token 都与其他所有 token 建立 n² 关系，上下文越长模型准确率越低，须把上下文当作边际收益递减的有限资源。四大可调要素：

1. 系统提示找「正确海拔」（Goldilocks Zone）：太死板（硬编码 if-else，脆弱难维护）❌；太空泛（高层指引无具体信号，假设共享上下文）❌；刚刚好（足够具体以引导行为、足够灵活以提供强启发，用最小信息集完整勾勒预期行为）✅。最佳实践：简单直接的语言；用 <background_information>、<instructions>、## Tool guidance 等 XML 标签或 Markdown 分节组织；从最小提示起步、按失败模式增补；注意「极简 ≠ 短」（该给的信息要一次给足）。

2. 工具极简而清晰：自包含（单一明确职责）、容错、意图无歧义、token 高效、参数命名无歧义（用 user_id 而非 user）。关键准则——如果一个人类工程师都无法明确指出某情境该用哪个工具，AI Agent 不可能做得更好。要避免：臃肿的工具集、职责重叠的工具、模糊的工具选择决策点。

3. 示例「多样而非穷举」：精选一组多样、典型的范例（“一图胜千言”）✅；不要堆砌边界情况清单、试图穷举每条规则 ❌。

三种上下文检索策略

策略做法何时用
Just-In-Time（推荐给 Agent）只维护轻量标识符（文件路径、查询、链接），运行时动态加载需动态探索；天然支持渐进式披露，避免上下文污染
预检索（传统 RAG）推理前用 embedding 召回上下文交互期间不变的静态内容
混合策略部分数据预取 + 必要时自主探索多数场景；如 Claude Code 预加载 CLAUDE.md，再用 glob/grep 做 JIT 检索

JIT 的代价是比预取慢、且需要良好的工具指引以免走进死胡同；经验法则是「做能跑通的最简单的事（do the simplest thing that works）」。

长程任务三技术

  1. 压缩（Compaction）：接近窗口上限时把对话摘要后重新初始化。先最大化召回（抓全相关信息）、再提升精度（剔除冗余）；优先清理旧的工具调用与结果（low-hanging fruit）；保留架构决策、bug、实现细节。适合需大量来回的任务。
  2. 结构化笔记（Agentic Memory）：Agent 把笔记持久化到上下文窗口外（to-do、NOTES.md、游戏状态、进度日志），之后再取回。开销极小却能维持跨工具调用的关键上下文，支撑多小时连贯策略（文档举 Pokémon 训练 1,234 步追踪为例）。适合有明确里程碑的迭代开发。
  3. 子 Agent 架构：专职子 Agent 在干净上下文里做聚焦任务——主 Agent 协调高层计划，子 Agent 深入探索（数万 token）后只回传 1,000–2,000 token 的浓缩摘要，细节上下文隔离。适合复杂研究与分析。

决策速查：静态内容→预检索/混合；需动态探索→JIT；长来回→压缩；迭代开发→结构化笔记；复杂研究→子 Agent；模型快速进步→做最简单能跑通的事。其中 Progressive-Disclosure 是 JIT 策略的信息架构实现，claude-mem 则把 JIT + 结构化笔记落到 Claude Code 的记忆层。

应用场景

  • 多轮对话系统
  • 复杂 Agent 的上下文管理
  • 多知识源融合场景
  • Token 窗口受限的优化场景

Agent 上下文压缩策略（第二代方案）

上下文压缩是 Context Engineering 的核心子领域。2026 年主流 Agent 产品走向「分层 + 渐进」，但哲学各异：

按成本递增排列：Claude Code 五段流水线（Budget Reduction → Snip → Microcompact → Context Collapse → Auto-Compact），前四步纯本地零 API 调用；Codex CLI 近期用户消息优先保护；OpenCode 可逆隐藏 + 回放最后一条指令；Cline 自动 + 手动双模式；Cursor 压缩 + 可回溯历史；Amp 不压缩换线程；MemGPT/Letta 操作系统级内存调度。

实践共识：分层渐进不一刀切、成本严格递增、增量摘要优于全量摘要、用真实 token 别估算（text.length/3 在中英混合场景误差 30-50%）、用户消息有特权、保护近端、单调边界绝不滑窗（滑窗式 stub 替换会导致每步缓存前缀失效）。

旁路代理式压缩：Headroom 代表另一类实现，把压缩层放在 Agent 与模型 API 之间，而不是只内嵌在某个 Agent 产品里。它通过 SDK、HTTP proxy、CLI wrap 或 MCP 形态接入，对工具输出、日志、RAG 文档和长会话历史做可逆压缩，并用 /stats、Prometheus、预算和审计导出把上下文成本变成可观测对象。

四级水位线方案（MUR AI 落地）：Tier 0 不做（<60%）→ Tier 1 Snip 截短老工具输出（60-80%，零 LLM）→ Tier 2 Prune 替换占位符（80-95%，零 LLM）→ Tier 3 增量摘要兜底（≥95%，调 LLM）。

云端特化设计：存储分离（完整日志落盘，对话只留截断版）、工具差异化（四个梯度）、跨轮缓存 ReplacementCache（按 part ID 存 Redis，跨实例复用压缩决策）。

限制与边界

  • 压缩系统最大的事故不是压不够，而是压错东西
  • 保护区内的消息、用户纯文本、PROTECTED_TOOLS 输出是红线
  • 跨会话记忆是另一个产品方向，不在单会话压缩范围内

局限与注意事项

  • 上下文工程需要结合具体业务场景做定制化链路
  • 每个AI应用所需的上下文工程能力不一而足
  • 过度优化可能导致信息丢失，需要平衡压缩与完整性
  • 评测成本高，需要建立可持续的评测链路

参考来源

关系图谱

反向链接