article / aiznoyer
Context Engineering
Context Engineering 上下文工程
从提示词工程到上下文工程的范式转移
在人工智能应用发展的早期阶段，提升大语言模型（LLM）表现的核心手段集中于“提示词工程”（Prompt Engineering）。提示词工程主要关注如何通过精确的自然语言指令、角色设定（Role-playing）、少样本学习（Few-shot learning）以及思维链（Chain-of-Thought）技术来引导模型输出特定格式或风格的回答 。然而，随着大模型应用从单一的对话问答走向复杂的多步推理和自主智能体（AI Agents）系统，提示词工程的局限性开始暴漏无遗。当模型需要处理跨越数十个对话轮次、整合外部API数据并遵循严格的企业合规逻辑时，单纯依赖静态指令已无法避免模型出现幻觉、指令遗忘或工具调用混乱。
这种技术瓶颈促成了行业向“上下文工程”（Context Engineering）的重大范式转移。上下文工程并非要取代提示词工程，而是将其降维为自身系统架构中的一个子集。提示词工程解决的是“如何对模型说话”的语言学问题，而上下文工程解决的则是“在说话时，模型需要并且只能知道什么”的系统级数据架构问题 。当智能体在循环中运行时，它会不断生成庞大的数据宇宙（包括工具调用结果、检索到的文档、历史对话和中间推理步骤）。如果不加节制地将这些信息全部塞入上下文窗口，模型将面临严重的挑战。研究表明，大模型在处理长文本时存在“中间迷失”（Lost in the Middle）的U型性能曲线问题，即模型能较好地回忆起开头和结尾的信息，但会忽略埋藏在中间的细节 。
为了清晰界定上下文工程的理论边界，有必要将其与传统的提示词工程以及检索增强生成（RAG）进行多维度的对比分析。
| 对比维度 | 提示词工程 (Prompt Engineering) | 检索增强生成 (RAG) | 上下文工程 (Context Engineering) |
|---|---|---|---|
| 核心目标 | 优化单一交互的语言学精确度与输出格式，消除自然语言指令中的歧义 | 通过连接外部结构化或非结构化知识库，解决模型知识盲区与事实性幻觉问题 | 构建完整的动态信息环境，精细化管理计算资源，确保智能体在多步执行中的连贯性与可靠性 |
| 作用范围 | 单轮次、静态、局部（指令层面），将被动接受的上下文视为既定前提 | 局部数据检索、向量映射、单点知识片段注入 | 全局系统架构、跨会话状态管理、生命周期干预、动态工具编排与剪裁 |
| 核心机制 | 角色设定、思维链（CoT）、输出格式约束（如JSON/XML声明） | 文本切分（Chunking）、语义嵌入（Embedding）、相似度排序（Re-ranking） | 上下文物理隔离、记忆有损压缩、中间件拦截控制流、模型上下文协议（MCP）映射 |
| 典型故障模式 | 歧义指令导致误解，或过度约束导致模型丧失灵活性 | 召回质量低导致答案错误，或检索粒度不当导致噪音引入 | 噪音过载导致上下文坍塌、冗余工具重叠导致决策树混乱、状态丢失导致陷入死循环 |
| 系统级隐喻 | 编写单个离散函数的逻辑代码与入参声明 | 数据库的索引构建与特定条件下的查询（Query）操作 | 设计整个软件的内存分配、垃圾回收机制（GC）、多线程状态同步与系统安全架构 |
在现代智能体开发中，RAG仅仅是上下文工程众多信息输入管道中的一条 。上下文工程需要统筹考虑RAG召回的片段如何与对话历史、工具描述以及用户系统状态进行优先级排序和融合。如果缺乏上下文工程的全局视角，盲目扩大上下文窗口不仅会导致成本和首字延迟呈二次方级数增长，还会引发“上下文腐化”，即随着上下文标记数的增加，模型准确回忆特定信息的能力显著下降 。
LangChain 上下文工程
在工业级智能体系统的构建中，LangChain 及其底层运行时 LangGraph 提供了目前业界最为完善的上下文工程抽象模型。一个典型的智能体运行循环（Agent Loop）本质上是一个状态机，包含两个主要步骤的交替运行：首先是模型调用（Model Call）阶段，系统将系统指令、历史消息和可用工具的模式（Schema）传递给 LLM，模型进行推理后返回最终响应或发出执行工具的请求；其次是工具执行（Tool Execution）阶段，系统接管控制权，执行模型请求的特定工具逻辑，并将执行结果作为观察（Observation）返回给状态机。这个循环将持续迭代，直到大模型决定任务已完成并输出最终结果。
为了使这个循环具备工业级的稳定性，系统设计者必须在循环的每一个执行节点，以及节点之间的状态流转过程中，实施精准的上下文控制。LangChain 将这种控制域划分为三种核心上下文类型：模型上下文（Model Context）、工具上下文（Tool Context）以及生命周期上下文（Life-cycle Context）。
**模型上下文决定了单次模型调用时究竟“看”到什么信息。**这包括系统提示词的动态拼接、经过剪裁和过滤的对话消息历史、当前节点激活的特定工具子集、动态选择的基础模型（如针对简单任务调用轻量级模型，针对复杂推理调用前沿模型），以及强制约束的结构化响应格式。这种上下文被定义为“瞬态”（Transient），因为对其进行的修改仅仅改变了当前这一轮次发给模型的请求负载，而不会永久改变系统保存在底层的全局状态 。例如，在某次调用前临时隐藏某个涉及高权限的转账工具，这一操作在当前轮次生效，但底层注册的工具列表并未丢失。
**工具上下文涉及工具在执行过程中能够访问和产生的信息边界。**工具不仅是执行外部动作（如调用 API、修改文件）的执行器，更是读取环境深层状态并向系统写入新知识的桥梁。工具上下文的修改通常是“持久化”（Persistent）的，工具的执行结果会被永久追加到消息历史中，或者工具内部的逻辑会直接更新系统的长期记忆数据库。
生命周期上下文关注的是在模型调用和工具调用之间发生的跨领域关注点（Cross-cutting concerns）。通过生命周期钩子，系统可以在不侵入核心业务逻辑和提示词模板的前提下，持久化地执行对话历史摘要、应用数据防泄漏（DLP）护栏拦截、或者进行合规性审计日志的记录。
为了物理支撑上述三种上下文的高效流转，LangChain 抽象出了三个维度的基础数据源，它们在生命周期和可变性维度上存在严格的隔离界限，构成了上下文工程的底层数据底座。
| 数据源类型 | 架构别名与系统隐喻 | 生命周期与可变性界限 | 核心作用与典型企业级应用场景 |
|---|---|---|---|
| Runtime Context (运行时上下文) | 静态配置 / 依赖注入 | 单次运行级 (不可变 Static) | 传递系统级的基础设施依赖，如数据库连接池对象、当前请求的用户 ID、外部 API 密钥、环境变量及租户级别的功能开关。其核心价值在于避免了全局变量的污染，使得工具和中间件在执行时能够保持无状态（Stateless）和高可测试性。 |
| State (状态) | 短期记忆 / 本地工作台 | 会话/线程级 (动态可变 Dynamic) | 存储当前对话生命周期内的完整执行轨迹、消息列表、临时上传的文件元数据、当前步骤的认知授权状态以及中间推理结果。LangGraph 通过 Checkpointer 将状态持久化，支持线程的随时挂起与恢复，但一旦逻辑上的会话被重置，该短期记忆即失去当前焦点。 |
| Store (存储) | 长期记忆 / 全局档案库 | 跨会话级 (持久可变 Dynamic) | 持久化存储用户的偏好设置、从历史交互中提取并压缩的核心洞察、组织架构知识以及业务策略。供智能体在未来全新的会话中进行跨线程检索和复用，通常由键值对存储或向量数据库（如 MongoDB, PostgreSQL）提供底层支持。 |
高级的上下文工程实践则是：在系统初始化阶段，将用户的鉴权令牌（Auth Token）和所在司法管辖区（Jurisdiction）放入 Runtime Context；在模型推理前的拦截阶段，通过中间件从 Store 中读取该用户以往的偏好报表格式并注入到 State 的特定字段中；最后在模型决定执行 SQL 查询工具时，工具内部逻辑直接从 Runtime Context 读取令牌，并根据鉴权系统动态拼接最终的执行代码，而无需大模型感知底层的鉴权复杂性 。这种关注点分离的架构不仅保证了数据的绝对隔离与安全性，还极大提升了系统的模块化与可维护性。
LangChain 中间件：上下文控制的神经中枢
在复杂的智能体流转网络中，如果将上下文工程中的各种修剪、注入、路由逻辑直接耦合在代理的核心执行节点代码中，系统很快就会陷入难以调试的代码泥潭。为了应对生产环境中的复杂干预需求，LangChain 在其 1.0 Alpha 版本中引入了革命性的中间件（Middleware）架构 。中间件是使上下文工程在工程实践中得以优雅落地的神经中枢，它借鉴了成熟 Web 服务器（如 Express.js 或 Django）的洋葱模型与拦截器模式，允许开发者在代理生命周期的任意细微阶段挂载非侵入式逻辑，从而实现对上下文的精准“外科手术式”干预 。
LangChain 的中间件架构暴露了多个核心的生命周期钩子（Hooks），按照其执行的机制可以分为节点式钩子（Node-style hooks）和包裹式钩子（Wrap-style hooks）。每个钩子在上下文控制矩阵中承担着不可替代的职能。
节点式拦截钩子：全局状态与控制流的守门人
节点式钩子主要包括 before_model 和 after_model，它们在特定的执行点按顺序触发，并拥有对智能体底层 State 的直接突变（Mutation）权限。
before_model 钩子在每次向大模型发起调用之前触发。它的核心价值在于对持久化上下文进行前置的全局干预。在处理超长文本或多轮对话场景下，对话历史记录的无限制增长是导致模型 OOM（Out of Memory）或推理性能崩溃的首要原因。系统架构师通常会在此处部署高级的总结策略（Summarization）：当检测到 State 中的消息总标记数接近当前模型上下文窗口的 80% 阈值时，before_model 中间件会主动挂起主流程，触发一个轻量级模型（如 GPT-4o-mini）对早期的对话历史进行结构化摘要，随后持久化地用这条摘要消息替换掉 State 中的冗长列表 。这并不是简单的数据截断，而是通过“有损压缩”机制永久性地重塑了智能体的短期记忆，确保最新的关键指令不被淹没。此外，该钩子常被用于前置的访问控制拦截，若中间件检测到用户当前的意图违反了企业合规策略，它可以直接返回更新后的状态，并使用路由指令跳转（Jump）至结束节点，从而阻断后续昂贵的模型推理过程。
after_model 钩子则运行在模型输出生成之后、工具实际执行之前，构成了系统的后置安全防线。这是部署安全护栏（Guardrails）和引入人在回路（Human-in-the-loop）机制的最佳节点。例如，如果模型经过推理，决定调用一个涉及高敏感操作（如“删除云端生产环境数据库”或“向外部供应商发送带机密附件的邮件”）的工具，after_model 中间件会立刻拦截该工具调用请求，将智能体状态挂起（Pause），并向外部系统发送审批通知。只有当人类管理员或自动化策略系统返回明确的批准指令后，智能体才会被重新唤醒并进入工具执行节点 。
瞬态干预钩子：精细化请求的动态重塑
相较于直接修改底层 State 的持久化操作，modify_model_request 钩子提供了一种更为克制且极具针对性的瞬态干预机制。它在模型即将被触发的最后一刻执行，专门用于动态修改当前请求的有效负载（Payload），而绝对不会对 State 造成任何持久化污染 。
以一个全能型企业 IT 支持智能体为例，它可能在底层注册了高达上百个潜在的运维工具。如果将所有工具的描述 Schema 一次性塞入提示词，庞大的 Token 消耗将急剧增加延迟，且相似度极高的工具描述会导致模型患上“选择困难症”进而产生幻觉 。通过 modify_model_request，系统可以根据 State 中记录的当前对话阶段、用户输入意图的分类结果，或者从 Runtime Context 中提取的用户部门信息，动态过滤并仅仅下发当前轮次最相关的 3 到 5 个工具描述。同时，系统也可以利用此钩子实现动态模型路由（Model Routing）。例如，当检测到上下文包含大量复杂的 Python 代码生成需求时，动态将请求重定向至代码能力极强的模型版本（如 Claude 3.5 Sonnet）；而在处理常规的闲聊澄清环节时，则动态切换至成本更低、速度更快的模型，从而在保证质量的同时实现全局推理成本的最优化 。
包裹式钩子：可观测性与韧性工程的基石
wrap_model_call 和 wrap_tool_call 属于包裹式钩子（Wrap-style hooks），它们的设计理念类似于面向切面编程（AOP）中的环绕通知（Around Advice）。这两个钩子能够同时拦截目标函数执行前和执行后的状态，是实现企业级系统韧性（Resilience）和深度可观测性（Observability）的基石。
当外部 API 不稳定或模型服务遭遇限流（Rate Limiting）时，wrap_model_call 和 wrap_tool_call 可以优雅地捕获异常，并实施带有指数退避（Exponential Backoff）的自动重试逻辑。更为关键的是，在通过这些钩子拦截到模型响应后，开发者可以返回一个携带 Command 指令的 ExtendedModelResponse 对象，将运行时计算的元数据（如当前调用的确切 Token 消耗量、网络延迟毫秒数、工具执行时间等）以非侵入式的方式注入到智能体的 State 中，以便后续节点用于成本计费或性能监控分析 。这种基于中间件的拦截矩阵，使得上下文工程从零散的“打补丁”式的代码片段，升华为一套高度内聚、可复用且易于测试的工业级流水线。
长期记忆管理（Memory Management）
在掌握了基础的上下文组装与中间件控制流之后，工程团队面临的最大挑战往往是如何处理动辄需要跨越数小时甚至数周的长周期任务（Long-horizon tasks）。现代智能体系统绝不能仅仅依赖模型不断膨胀的上下文窗口能力。因为即使模型在理论上支持高达数百万 Token 的输入，海量无结构的原始数据堆砌依然会导致严重的“注意力稀释”与“上下文坍塌”（Context Collapse），表现为模型在海量噪音中遗失关键业务逻辑，最终导致行为失控 。因此，高阶上下文工程必须实施极具策略性的记忆管理模式，将信息从“被动堆积”转变为“主动提纯”。
结构化笔记与代理式记忆（Agentic Memory）
第一种关键模式是“结构化笔记”（Structured Note-taking），在业界也常被称为代理式记忆。与系统强制执行的截断式文本摘要不同，这是一种赋予智能体自主性，让其主动在当前上下文窗口之外维护外部持久化状态的策略。
当智能体被要求执行复杂的代码库重构或跨越数小时的游戏探索（如控制智能体游玩宝可梦）时，单纯的窗口滚动会导致其迅速丧失对全局目标的把控 。通过上下文工程，系统为智能体提供了一个专用的文件写入工具，并指令其维护一个类似于 NOTES.md 或 STATE.json 的独立状态账本。在这个文件中，智能体被要求以高密度的结构化格式持续记录当前的核心目标、已完成的里程碑、遇到的死胡同（避免重复试错）、以及未完成的子任务依赖树。每当当前的上下文窗口因填充了过多冗余的工具调用日志而面临崩溃，系统触发环境重置（Environment Reset）时，智能体在新的干净窗口中只需首先调用读取工具拉取这份结构化笔记，即可在几秒钟内瞬间恢复完整的工作记忆与任务上下文 。这种模式完美模仿了人类高级工程师的交接班记录习惯，用极小的 Token 开销彻底规避了细粒度技术决策在长程对话中的消散。
多维记忆流抽象
在更广阔的企业级应用中，用户的个性化偏好、历史纠错记录以及组织内部的业务惯例不能随着单个智能体生命周期的结束而灰飞烟灭。这要求上下文工程从短期的 State 管理跨越到基于 Store 的全局长期记忆融合。
LangChain 推出的 LangMem 架构为这种复杂需求提供了标准化的解决方案，它将记忆系统解耦为三种并行的记忆流：
- 语义记忆（Semantic Memory）：用于提取和存储交互中呈现的客观事实关系（如“用户的核心项目是项目 A”、“公司的默认数据库是 PostgreSQL”），通常映射到图数据库或知识图谱中。
- 情景记忆（Episodic Memory）：用于保留特定历史会话的连贯时间切片，帮助智能体回溯“上周二我们关于服务器宕机的讨论进行到了哪一步”。
- 程序记忆（Procedural Memory）：这是最具价值的层面，专门用于系统后台异步提取并固化用户的工作流偏好、纠错指令或特定的代码编写风格（如“用户偏好使用 TypeScript 强类型声明”），并在未来的会话中作为隐式规则自动注入系统提示词 。
为了保证记忆的动态更新而不发生坍塌，斯坦福与学术界联合提出的 ACE（Agentic Context Engineering）框架引入了更为模块化的演进机制。ACE 框架将上下文视为一本“不断进化的战术手册”，其内部运作包含三个专门的子代理角色：生成器（Generator）负责执行任务并产出轨迹；反思器（Reflector）负责批判这些轨迹，从成功或失败的反馈中提取具体的经验教训；策展人（Curator）则负责将这些洞察合成为结构化的、条目化的“增量更新”（Delta Updates）。通过这种基于局部增量编辑而非全局重写的机制，ACE 框架有效防止了信息迭代过程中的细节磨损（Brevity bias） 。在底层基础设施层面，这些高阶记忆策略通常与融合了向量搜索与文档存储能力的数据库（如集成 Vector Search 的 MongoDB Atlas 或支持 pgvector 的 PostgreSQL）紧密结合，构成强大的记忆检索中枢 。
上下文物理隔离（Context Isolation）
当单个智能体面对跨域的复杂企业任务时，即便是最顶尖的大模型，其推理能力也会在海量异构信息的冲击下出现退化。将数百页的 API 文档、所有可能的执行工具库以及冗长的业务规则全部集中在单一节点（Single-agent node）的提示词中，被业界公认为是一种极其脆弱的“巨型提示词反模式”（Monolithic Mega-Prompt Anti-pattern）。
在多智能体架构中，协调者-工作者（Orchestrator-Worker / Supervisor）模式是最为主流且经过验证的企业级设计模式 。在该模式下，主节点（Orchestrator Agent）扮演项目经理的角色，它自身不携带任何具体的执行工具（如代码解释器或数据库连接器），而是仅仅维持一个高度凝练的“全局上下文”（Global Context），其中包含了用户的终极目标、总体约束条件以及任务的分解蓝图。
当遇到需要深度下钻的具体子任务时，主节点会采用“将智能体作为工具”（Agent-as-a-Tool）的范式，动态孵化或调用一个专业的工作者智能体（如专门负责编写 SQL 的子智能体，或专门负责审查安全漏洞的子智能体）。在任务交接的瞬间，上下文工程的精髓得以体现：主节点并不会将数百轮的对话历史和所有背景资料一股脑地倾泻给子智能体，而是通过上下文过滤器，提炼并仅向子智能体下发严格限定的“局部上下文”（Local Context），即它完成当前原子任务所需的最小信息集。
工作者智能体在其独立的上下文沙盒（Context Sandbox）中，由于没有全局无关信息的干扰，能够以极高的准确率进行高频的试错、工具调用和逻辑推理。当子任务完成后，工作者同样不会返回冗长的执行日志，而是仅仅将脱水后的、提纯的关键结果（通常严格限制在 1000 到 2000 个 Token 以内）作为最终输出返回给协调者主节点 。这种严格的上下文进出双向管控机制，不仅大幅削减了 API 调用的 Token 计费成本，更从系统架构的根源上阻断了长下文导致的逻辑幻觉与认知过载现象，使得整个 AI 系统的表现变得确定且可追溯。