Context Engineering
Brief
上下文工程是指在推理阶段，对提供给大语言模型的信息进行系统化的设计与优化，从而稳定地产生期望输出。它的核心是对各种情境要素进行结构化、选择和排序——例如提示词、检索到的数据、记忆、指令以及环境信号等——以便让模型的内部层次在一种最优状态下运行。
与只关注提示词措辞的提示工程不同，上下文工程关心的是“情境”的完整配置：相关知识、指令和历史上下文是如何被组织和投递的，以便实现最有效的结果。
目前，工程师会使用一系列离散的技术，这些技术大致可以分为三个方向：
- 情境搭建（Context setup）
主要关注“上下文的初始配置与精简”，包括：- 使用极简的系统提示词
- 使用规范化（canonical）的少样本示例
- 使用高效利用 token 的工具来支持果断行动
- 情境管理（Context management for long-horizon tasks）
面向长周期任务，解决有限上下文窗口的问题，包括：- 上下文摘要，将较长历史压缩成关键信息
- 结构化笔记，用外部持久化记忆记录关键过程与结论
- 子代理架构，将复杂任务拆解为子任务，并在子任务层面进行隔离与摘要
- 动态信息检索（Dynamic information retrieval）
依赖“即时（Just-in-Time, JIT）上下文检索”：- 只有在确实需要时，智能体才自主加载外部数据
- 通过这种按需拉取的方式，最大化信息利用效率与推理精度
Details
目录
- 什么是上下文工程
- 上下文工程 vs 提示工程
- 上下文工程的三大方向（架构颗粒度）
3.1 情境搭建（Context Setup）
3.2 情境管理：长周期任务（Context Management）
3.3 动态信息检索（Dynamic Information Retrieval） - 实践要点与落地建议
——————————
- 什么是上下文工程（Context Engineering）
1.1 概念
上下文工程是在推理阶段，对“喂给大模型的所有信息”进行整体设计和优化的一套方法论与工程实践。
它关心的是整个“上下文配置”如何影响模型内部状态，从而影响输出质量和稳定性。
1.2 对象范围
上下文工程覆盖但不限于：
- 系统提示词与角色设定
- 用户指令与任务描述
- 少样本示例与模板
- 从外部系统检索到的数据
- 会话历史与外部记忆（notes、知识库等）
- 环境信号（如工具调用结果、系统状态等）
这些都被视作“情境元素”，需要被合理组织和调度。
- 上下文工程 vs 提示工程
2.1 提示工程关注点
提示工程主要聚焦在一句或若干句“prompt”的写法：
- 如何更清晰地描述任务
- 如何减少歧义
- 如何通过措辞影响模型行为
2.2 上下文工程关注点
上下文工程则关注：
- 用哪些信息：信息源选择、过滤、裁剪
- 以什么结构组织：分块、层级、标签、模板化
- 以什么顺序喂给模型：先指令、后知识，或先总结、后追问等
- 在整个任务生命周期内，如何滚动维护与更新上下文
可以理解为：
提示工程是“怎么说这句话”，
上下文工程是“说什么、按什么结构说、在什么时机说，以及说给谁（哪个子代理）听”。
- 上下文工程的三大方向
3.1 情境搭建（Context Setup）
3.1.1 目标
在模型开始处理任务之前，搭建一个“干净、明确、轻量”的初始上下文，让后续推理在良好约束下进行。
3.1.2 关键实践
- 极简系统提示词
- 避免在系统提示里堆积过多要求
- 只保留核心角色设定和关键约束
- 其他细节通过工具、模板或后续指令承载
- 规范化少样本示例（Canonical Few-shot）
- 为高频任务设计标准示例集
- 示例结构统一：输入格式、思考过程、输出格式
- 通过“几个高质量样例”塑造模型行为，而不是大量杂乱样例
- token 高效的工具与结构
- 将复杂逻辑下沉到工具（代码、API），让模型通过自然语言调用
- 用紧凑的数据表示（ID、引用、索引）替代冗长文本
- 用模板化结构（JSON、表格样式文本）减少解释成本
3.2 情境管理：长周期任务（Context Management for Long-horizon Tasks）
3.2.1 问题背景
在长周期、多轮对话或复杂流程中：
- 模型的上下文窗口有限
- 历史信息会不断被新内容挤出
- 重要决策、约定和中间结论容易丢失
3.2.2 关键实践
- 上下文摘要
- 周期性地对对话/步骤做总结，保留：
- 关键决策
- 重要中间结论
- 未解决的问题与假设
- 用摘要替换长对话原文，以压缩 token
- 结构化笔记 / 外部记忆
- 将重要信息写入外部结构：
- 任务目标与约束
- 当前状态与进度
- 已完成与待办列表
- 以“笔记”形式重新注入上下文，而不是反复传入全部历史对话
- 子代理架构（Sub-agent Architectures）
- 将复杂任务拆解为多类子任务：分析、规划、执行、评审等
- 每个子代理只保留与自己子任务强相关的局部上下文
- 对子代理输出进行摘要，再汇总给主代理
- 通过“隔离 + 摘要”控制整体上下文体积与噪音
3.2.3 效果
- 减少无关历史对当前推理的干扰
- 在有限上下文内维持对长期任务的一致理解
- 提升长流程、多阶段系统的稳定性和可追溯性
3.3 动态信息检索（Dynamic Information Retrieval）
3.3.1 核心思想：JIT（Just-in-Time）
动态信息检索强调“按需加载”：
- 不在一开始就把所有可能相关的信息塞给模型
- 由智能体在推理过程中判断何时需要外部知识
- 只在“当下这一步”真的需要时，才发起检索或工具调用
3.3.2 关键实践
- JIT 检索策略
- 让代理先进行初步思考，识别信息缺口
- 在识别缺口后，触发检索：知识库、数据库、API、搜索等
- 将检索结果以结构化方式注入后续上下文
- 精准匹配与裁剪
- 使用向量检索 / 结构化查询，尽量只返回“最相关的少量片段”
- 对检索结果做二次过滤与摘要，降低噪音和 token 消耗
- 与工具生态结合
- 把外部系统封装成“可调用工具”，由代理按需调用
- 工具返回数据尽量结构化（JSON 等），便于后处理与复用
3.3.3 目标效果
- 在保持结果质量的前提下，最小化上下文体积
- 避免信息过载导致模型“跑偏”或陷入无关细节
- 实现更高的时效性和更好的领域适配（通过实时数据源）
- 实践要点与落地建议
4.1 设计层面
- 把“上下文”当成系统的一等公民来建模，而不是零散的 prompt 文本
- 明确区分：
- 固定长期配置：角色、全局约束
- 任务级配置：目标、输入、成功标准
- 步骤级配置：当前子任务相关信息
- 为这三层分别设计结构与更新策略
4.2 工程实现层面
- 引入“上下文编排层”：
- 负责收集、过滤、排序各种信息源
- 输出给模型的是一个结构化、可解释的最终上下文
- 内置常用能力模块：
- 摘要模块（对历史、对子代理输出）
- 检索模块（向量、全文、结构化）
- 记忆模块（长期笔记、会话级存储）
4.3 评估与优化
- 不只评估“单轮回答质量”，还要评估：
- 长任务中的一致性
- 信息利用率（用到的 vs 提供的）
- token 成本和延迟
- 用实验对比不同情境策略：
- 不同摘要粒度
- 不同检索阈值
- 不同子代理拆分方式
通过将以上三大方向（情境搭建、情境管理、动态检索）纳入统一架构设计，可以从“单次 prompt 调优”升级为“上下文系统工程”，在复杂场景下显著提高大模型应用的可靠性、效率与可维护性。