上一篇讲了预置 middleware 全景。这一篇聚焦其中最热门的一类——Context Engineering（上下文工程）。
为什么单独拎出来讲？因为 Agent 跑久了，上下文必然越来越长：对话历史累积、工具结果堆积、检索资料塞入……一旦超过模型的上下文窗口，要么报错，要么模型「记不住」前面的东西。怎么管好这个越来越长的上下文，是 2026 年 Agent 工程的核心议题。
问题：上下文会无限增长
Agent 和单次问答不同，它是多轮、长流程的。每一轮都会往 context 里加东西：
- 每轮对话加消息
- 每次调工具加工具结果
- 每次检索加检索到的文档
跑得越久，context 越长。而模型的上下文窗口是有限的（即使是长窗口模型，也有上限，且越长越贵越慢）。
不管理的话，结果就是：要么超窗口报错，要么模型在超长 context 里「找不到重点」（研究表明模型对超长 context 的中间部分注意力会下降，所谓 lost in the middle）。
Context Engineering：主动管理上下文
Context Engineering 就是主动管理 Agent 的上下文，让它「该有的有，不该有的去掉」。它的核心手段，都是通过 middleware 实现的（上一篇讲的钩子点，主要在 beforeModel）。
主要几种策略：
压缩（Compression）
对话太长时，把早期的消息摘要化——比如把前 20 轮对话总结成一段「之前讨论了 X、Y、Z」。保留信息要点，去掉冗余细节。
裁剪（Trimming）
按策略裁掉太老的消息。比如只保留最近 N 轮，更早的直接删。简单粗暴，但有效。
筛选（Selection）
不是所有消息都同等重要。智能筛选：保留关键的（比如含决策的、含工具结果的），去掉无关的（寒暄、重复）。
外置记忆（Offloading）
把不常用的信息挪到外部存储（长期记忆，第 37 篇），context 里只留指针或摘要，要用时再取回。
都通过 middleware 实现
这几种策略，在 LangChain 里都是 middleware 的活——在 beforeModel 钩子里，对将要传给模型的 messages 做处理：
beforeModel(state):
if 消息太多:
state.messages = 压缩(state.messages) # 或裁剪/筛选
每次模型要被调用前，这个 middleware 先把 context 整理到合适的大小，再传给模型。模型始终在一个「可控、聚焦」的 context 上工作。
一个关键判断：不是越长越好
很多人以为「上下文越多越好，模型知道得越多答得越准」。这是误区。
实际情况是：上下文过长，模型反而表现下降。原因有二：
- 注意力稀释：context 越长，模型对每一部分的注意力越分散，关键信息容易被淹没（lost in the middle）
- 成本和延迟：context 越长，token 越多，越贵越慢
所以 Context Engineering 不是「尽可能多塞」，而是**「精准投放」——让模型在每一步看到它这一步最需要的信息，不多不少**。
这个认知转变很重要：从「给模型所有信息」到「给模型此刻最相关的信息」。这也是为什么 Context Engineering 被称为 2026 年 Agent 工程的核心——它直接决定 Agent 的质量和成本。
收束：管理上下文就是管理 Agent 的注意力
这一篇讲了 Context Engineering：
- Agent 跑久了上下文必然增长，不管会超窗口或表现下降
- 几种策略：压缩、裁剪、筛选、外置记忆
- 都通过 beforeModel middleware 实现
- 关键认知：不是越长越好，是精准投放
- 它直接决定 Agent 质量和成本，是 2026 的核心议题
下一篇讲 Deep Agents——用 middleware 这套机制搭出来的、能处理长上下文多步任务的复杂 Agent，是 Context Engineering 的集大成应用。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
