Context Engineering

Brief

上下文工程是指在推理阶段，对提供给大语言模型的信息进行系统化的设计与优化，从而稳定地产生期望输出。它的核心是对各种情境要素进行结构化、选择和排序——例如提示词、检索到的数据、记忆、指令以及环境信号等—— 以便让模型的内部层次在一种最优状态下运行。

与只关注提示词措辞的提示工程不同，上下文工程关心的是“情境”的完整配置：相关知识、指令和历史上下文是如何被组织和投递的，以便实现最有效的结果。

目前，工程师会使用一系列离散的技术，这些技术大致可以分为三个方向：

1. 情境搭建（Context setup）
   主要关注“上下文的初始配置与精简”，包括：
   • 使用极简的系统提示词
   • 使用规范化（canonical）的少样本示例
   • 使用高效利用 token 的工具来支持果断行动
2. 情境管理（Context management for long-horizon tasks）
   面向长周期任务，解决有限上下文窗口的问题，包括：
   • 上下文摘要，将较长历史压缩成关键信息
   • 结构化笔记，用外部持久化记忆记录关键过程与结论
   • 子代理架构，将复杂任务拆解为子任务，并在子任务层面进行隔离与摘要
3. 动态信息检索（Dynamic information retrieval）
   依赖“即时（Just-in-Time, JIT）上下文检索”：
   • 只有在确实需要时，智能体才自主加载外部数据
   • 通过这种按需拉取的方式，最大化信息利用效率与推理精度

Details

目录

1. 什么是上下文工程
2. 上下文工程 vs 提示工程
3. 上下文工程的三大方向（架构颗粒度）
   3.1 情境搭建（Context Setup）
   3.2 情境管理：长周期任务（Context Management）
   3.3 动态信息检索（Dynamic Information Retrieval）
4. 实践要点与落地建议

——————————

1. 什么是上下文工程（Context Engineering）

1.1 概念
上下文工程是在推理阶段，对“喂给大模型的所有信息”进行整体设计和优化的一套方法论与工程实践。
它关心的是整个“上下文配置”如何影响模型内部状态，从而影响输出质量和稳定性。

1.2 对象范围
上下文工程覆盖但不限于：

• 系统提示词与角色设定
• 用户指令与任务描述
• 少样本示例与模板
• 从外部系统检索到的数据
• 会话历史与外部记忆（notes、知识库等）
• 环境信号（如工具调用结果、系统状态等）

这些都被视作“情境元素”，需要被合理组织和调度。

2. 上下文工程 vs 提示工程

2.1 提示工程关注点
提示工程主要聚焦在一句或若干句“prompt”的写法：

• 如何更清晰地描述任务
• 如何减少歧义
• 如何通过措辞影响模型行为

2.2 上下文工程关注点
上下文工程则关注：

• 用哪些信息：信息源选择、过滤、裁剪
• 以什么结构组织：分块、层级、标签、模板化
• 以什么顺序喂给模型：先指令、后知识，或先总结、后追问等
• 在整个任务生命周期内，如何滚动维护与更新上下文

可以理解为：
提示工程是“怎么说这句话”，
上下文工程是“说什么、按什么结构说、在什么时机说，以及说给谁（哪个子代理）听”。

3. 上下文工程的三大方向

3.1 情境搭建（Context Setup）

3.1.1 目标
在模型开始处理任务之前，搭建一个“干净、明确、轻量”的初始上下文，让后续推理在良好约束下进行。

3.1.2 关键实践

1. 极简系统提示词

• 避免在系统提示里堆积过多要求
• 只保留核心角色设定和关键约束
• 其他细节通过工具、模板或后续指令承载

2. 规范化少样本示例（Canonical Few-shot）

• 为高频任务设计标准示例集
• 示例结构统一：输入格式、思考过程、输出格式
• 通过“几个高质量样例”塑造模型行为，而不是大量杂乱样例

3. token 高效的工具与结构

• 将复杂逻辑下沉到工具（代码、API），让模型通过自然语言调用
• 用紧凑的数据表示（ID、引用、索引）替代冗长文本
• 用模板化结构（JSON、表格样式文本）减少解释成本

3.2 情境管理：长周期任务（Context Management for Long-horizon Tasks）

3.2.1 问题背景
在长周期、多轮对话或复杂流程中：

• 模型的上下文窗口有限
• 历史信息会不断被新内容挤出
• 重要决策、约定和中间结论容易丢失

3.2.2 关键实践

1. 上下文摘要

• 周期性地对对话/步骤做总结，保留：
  • 关键决策
  • 重要中间结论
  • 未解决的问题与假设
• 用摘要替换长对话原文，以压缩 token

2. 结构化笔记 / 外部记忆

• 将重要信息写入外部结构：
  • 任务目标与约束
  • 当前状态与进度
  • 已完成与待办列表
• 以“笔记”形式重新注入上下文，而不是反复传入全部历史对话

3. 子代理架构（Sub-agent Architectures）

• 将复杂任务拆解为多类子任务：分析、规划、执行、评审等
• 每个子代理只保留与自己子任务强相关的局部上下文
• 对子代理输出进行摘要，再汇总给主代理
• 通过“隔离 + 摘要”控制整体上下文体积与噪音

3.2.3 效果

• 减少无关历史对当前推理的干扰
• 在有限上下文内维持对长期任务的一致理解
• 提升长流程、多阶段系统的稳定性和可追溯性

3.3 动态信息检索（Dynamic Information Retrieval）

3.3.1 核心思想：JIT（Just-in-Time）
动态信息检索强调“按需加载”：

• 不在一开始就把所有可能相关的信息塞给模型
• 由智能体在推理过程中判断何时需要外部知识
• 只在“当下这一步”真的需要时，才发起检索或工具调用

3.3.2 关键实践

1. JIT 检索策略

• 让代理先进行初步思考，识别信息缺口
• 在识别缺口后，触发检索：知识库、数据库、API、搜索等
• 将检索结果以结构化方式注入后续上下文

2. 精准匹配与裁剪

• 使用向量检索 / 结构化查询，尽量只返回“最相关的少量片段”
• 对检索结果做二次过滤与摘要，降低噪音和 token 消耗

3. 与工具生态结合

• 把外部系统封装成“可调用工具”，由代理按需调用
• 工具返回数据尽量结构化（JSON 等），便于后处理与复用

3.3.3 目标效果

• 在保持结果质量的前提下，最小化上下文体积
• 避免信息过载导致模型“跑偏”或陷入无关细节
• 实现更高的时效性和更好的领域适配（通过实时数据源）

4. 实践要点与落地建议

4.1 设计层面

• 把“上下文”当成系统的一等公民来建模，而不是零散的 prompt 文本
• 明确区分：
  • 固定长期配置：角色、全局约束
  • 任务级配置：目标、输入、成功标准
  • 步骤级配置：当前子任务相关信息
• 为这三层分别设计结构与更新策略

4.2 工程实现层面

• 引入“上下文编排层”：
  • 负责收集、过滤、排序各种信息源
  • 输出给模型的是一个结构化、可解释的最终上下文
• 内置常用能力模块：
  • 摘要模块（对历史、对子代理输出）
  • 检索模块（向量、全文、结构化）
  • 记忆模块（长期笔记、会话级存储）

4.3 评估与优化

• 不只评估“单轮回答质量”，还要评估：
  • 长任务中的一致性
  • 信息利用率（用到的 vs 提供的）
  • token 成本和延迟
• 用实验对比不同情境策略：
  • 不同摘要粒度
  • 不同检索阈值
  • 不同子代理拆分方式

通过将以上三大方向（情境搭建、情境管理、动态检索）纳入统一架构设计，可以从“单次 prompt 调优”升级为“上下文系统工程”，在复杂场景下显著提高大模型应用的可靠性、效率与可维护性。

提示工程 vs 上下文工程：学科分野与层级关系

到 2025 年，产学研界已形成共识：提示工程关注措辞与单次交互优化，是一门交互设计学科；上下文工程则关注信息环境整体设计——检索哪些文档、如何管理对话历史、如何编排工具输出、如何编码机构知识——本质上是一门系统架构学科。 Andrej Karpathy 在 2025 年指出，工业级 LLM 应用中的难题不再是“如何措辞请求”，而是“如何在正确的时间组装正确的信息”。企业正在构建专门的上下文层（Context Layers）， 使 Agent 查询受治理的上下文层而非依赖单个 Prompt 字符串。两门学科的关系越来越被理解为层级性的：提示工程已成为上下文工程的一个子集。

见：Atlan、Elastic、Firecrawl、KeyValue Systems

上下文腐烂：长上下文退化的实证与机制

Chroma Research 在 2025 年对 18 个前沿模型（包括 GPT-4.1、Claude 4 Sonnet、Gemini 2.5 Pro）的评测显示，所有模型均随输入长度增长而单调退化， 最陡峭的下降通常发生在 100K–500K token 区间。Wang 等人（2026）将这一现象定义为“智能退化（Intelligence Degradation）”——超过临界阈值后综合任务性能下降超过 30%。 arXiv:2510.05381 的实验更具冲击力：即使在完美检索和最小干扰的情况下，向上下文插入 25,000 个空白 token 就足以导致模型得出错误答案，证明上下文长度本身就会损害推理，与检索质量无关。导致退化的机制包括： Liu 等人记录的“Lost in the Middle”现象（RoPE 长期衰减所致）、注意力稀释（100K token 需计算 100 亿对关系）、以及临界阈值崩塌（性能在狭窄范围内灾难性下降）。

见：Chroma Research、arXiv:2601.15300、arXiv:2510.05381、arXiv:2410.15288

模型腐烂：训练快照与世界演进的脱节

LLM 训练成本极高（不是周末练手项目），完成即冻结，模型成为 6/8/12/18 个月前世界与 Web 的快照。对快速演进的开源项目，这意味着模型的认知与现实严重脱节——会编造 keys、捏造模式、虚构不存在的 API。「 我们没做错什么，但这是我们的问题」——PostHog 的 Danilo Campos 用这句话概括了厂商责任：模型不是上游训练的事，是下游集成方的工程问题。模型腐烂区别于上文「上下文腐烂」（context rot 是窗口内信息退化， model rot 是训练截止后世界继续演化）。应对策略不是等 Anthropic 重训模型，而是把第一手最新文档主动注入上下文（见下文「Fresh Markdown 注入」）。

见：The PostHog Wizard: Lessons in AI onboarding

渐进式上下文披露：设计模式与实现架构

Thoughtworks 在 2026 年 4 月技术雷达中将渐进式上下文披露纳入新兴技术，认为它能通过确保 Agent“在正确时刻获得正确引导”来防止上下文腐烂。这种模式比传统 RAG 更广泛——它不仅关注“检索什么”，更关注“何时加载” 、“如何触发”以及“如何限定作用范围”。Anthropic 推广的 SKILL.md 规范将技能信息组织为 L1（始终保留的轻量级元数据/目录）、L2（按需加载的程序性指令）、L3（保持休眠的深度参考资料）， 从而允许任意大的参考资料而不导致基线上下文膨胀。实现渐进式披露需要三个组件：条件检测（显式工作流步骤或任务类别推断）、获取机制（文件读取、向量查询或子 Agent 检索）、以及范围限定（确保加载内容仅与当前任务阶段绑定，不会无限累积）。 Anthropic 的 Agent Skills 框架在生产部署中实现了 70–90% 的 token 削减。

见：Thoughtworks Technology Radar、MindStudio、arXiv:2603.11808、Context-Bench

Fresh Markdown 注入：大上下文时代的反 RAG 实践

PostHog Wizard 在生产实践中提出反共识观点：「凭借现有的 context 窗口大小，没什么能比直接塞一堆 Markdown 文件、填补漏洞更有效」。具体做法是文档源头永远是 posthog.com 实时渲染的最新版本（ 不是向量库快照），Agent 通过工具从「Fresh Hot Markdown 菜单」按当前任务类型挑选载入，直接 slide right into context，不经过分块、嵌入与 ANN 检索。这与上文「渐进式上下文披露」形成互补： 渐进式披露解决「全量加载会把窗口撑爆」的问题，Fresh Markdown 解决「向量化是为窗口太小而妥协」的问题。当 token 充裕、文档量可控时，最直接的检索就是「全量带入」——RAG 在很多简单文档检索场景里不再必要， 简化检索栈反而更可靠。

见：The PostHog Wizard: Lessons in AI onboarding

Prompt 缓存：机制、成本结构与部署陷阱

Anthropic 为 Claude 推出的 Prompt 缓存通过前缀匹配（Prefix Matching）存储 KV 缓存：只有 Prompt 开头部分可被缓存，且必须逐字符完全相同。缓存条目存活时间约 5 分钟。 缓存读取成本约为标准输入 token 费率的 10%，缓存创建（写入）成本比标准输入高约 25%，但只需支付一次即可在后续命中中摊销。Anthropic 宣称，对于命中缓存的长 Prompt， 可实现高达 90% 的成本降低和 85% 的延迟降低。对于企业级 Agent，最有价值的缓存放置位置是：系统提示词末尾（静态且重复）、注入的工作区文件末尾（如 MEMORY.md、AGENTS.md）、以及对话历史中的可配置断点。 关键陷阱包括：向系统提示词注入动态内容（时间戳、会话 ID）会在每次调用时使缓存失效；在各轮之间积极修剪或总结对话历史会改变前缀并破坏缓存命中。

见：AWS Bedrock 博客、InfoWorld、MindStudio

文章建议：上下文工程落地七条原则

作者主张的七条落地原则如下：

1. 在优化 Prompt 之前先投资上下文基础设施——上下文工程的回报更高、更持久。
2. 采用渐进式上下文披露模式，将 Agent 知识组织为带有按需加载的轻量级索引。
3. 为静态前缀实现 Prompt 缓存，审计会使缓存失效的动态内容。
4. 使用语义工具选择和动态 MCP 管理，避免将所有可用工具倾倒进上下文窗口。
5. 为机构化推理构建或集成知识/上下文图，向量相似性搜索在受监管或高风险领域是不够的。
6. 为长周期的有状态执行而设计，使用持久状态存储、检查点和主动压缩，而非被动截断。
7. 衡量和监控上下文质量（token 预算、缓存命中率、检索相关性、上下文长度），而不仅仅是输出质量。