一文梳理上下文工程（上）：如果Agent没做好，大概率是信息没给对！
核心要点
- 上下文工程（Context Engineering）本质是信息管理，通过优化信息的组织和呈现方式，可以显著提升大语言模型（LLM）的表现【AI大模型教程】
- 上下文窗口（Context Window）是模型的“工作记忆”，容量有限，是我们与 LLM 交互的主要方式
- 设计智能体（Agent）的关键在于规划信息流：需要什么信息，信息从哪儿来、怎么存、需要的时候怎么精准获取
P.S. 尝试从模型视角来编写提示和工具文档（共情一下同是“打工”的 Agent），你会发现一切变得特别好理解
内容大纲
- 什么是上下文工程（及其类型）
- 为什么上下文工程很重要（长上下文引发的问题）
- 如何优化上下文工程（四大策略和六项技术）
什么是上下文工程
在工作中，我们可能常抱怨“需求不清晰”，比如老板提出了一个抽象想法，或者是同事写的文档又臭又长，让人无从下手。同理，你需要输入完整、清晰且结构化的相关准确信息，大模型才能把活干好。
Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task. @LangChain
翻译版：上下文工程指构建动态系统，以合适的格式提供必要信息与工具，使 LLM 能够合理完成任务。
人话版：由于上下文窗口容量是有限的（就像你也记不住很多东西一样），上下文工程的核心任务，就是决定在 LLM 运行的每一步中，哪些信息需要被加载到上下文窗口中。
LLM 所需的信息可分为三类：
- 指令（Instructions）：
- 系统提示和用户请求
- 记忆（跨多个会话保留的用户偏好或历史交互信息）
- 少量示例（提供输入输出样例以引导模型行为）
- 工具描述（解释可用工具的功能和参数）
- 知识（Knowledge）：通过 RAG 等技术检索到的事实、文档和代码等
- 工具（Tools）：包括调用记录、工具反馈（如API返回结果或错误信息）等
浅浅总结一下，
优秀的上下文 =
给模型的提示词/指令
-
检索得到的文档/数据
-
过程中产生的数据（历史状态/工具调用记录/执行结果等）
-
跨对话记忆（相关历史消息或事件）
-
输出规范（需要什么格式的数据）
Q：和提示词工程（Prompt Engineering）的区别？
A：顾名思义，提示词工程专注于通过编写有效提示词来优化 LLM 的输出效果。上下文工程则是为 Agent 提供完整且结构化上下文的一系列策略，比如检索（在调用大模型前动态获取并插入相关信息），记忆管理（如生成对话摘要、记录用户偏好等）。
为什么上下文工程很重要
上下文工程对 Agent 非常关键，原因如下：
- 任务的复杂性与长期性： Agent 通常需要执行多步骤、长时间运行的任务，导致多轮交互中信息持续累积
- 工具的使用：Agent 可以调用工具与外部环境交互（如联网搜索），并需要保存工具返回的结果，信息进一步变多
Agent 需要正确信息来执行任务，而执行过程又会产生新信息，所有这些信息都会存在上下文窗口中。信息过多（即长上下文）可能导致以下问题：超出上下文窗口容量、增加成本与延迟，降低输出质量。
另外，Agent 需要记住的信息越多，出错的概率也会越大（是的谁不会犯错呢），所以如何管理上下文就变得很重要。
Q：什么是 Agent？和 LLM 的区别？
Agent 通过交替调用 LLM 和工具，根据工具的反馈（Observation）来决定下一步操作，循环迭代直到完成任务，通常用于处理长时间运行的复杂任务。Agent 是能调用工具的 LLM。
长上下文的问题（Context Rot）
在《How Long Contexts Fail》一文中，Drew Breunig 指出了长上下文可能导致的问题：
-
上下文污染（Context Poisoning）：幻觉或错误信息进入上下文后被反复引用，导致模型输出错误内容
-
上下文干扰（Context Distraction）：上下文过多时，模型过度关注某些信息而忽略当前任务
-
上下文混淆（Context Confusion）：不相关的上下文内容影响输出质量，因为模型倾向于使用所有可用信息
-
上下文冲突（Context Clash）：累积的上下文中存在相互矛盾的信息，从而削弱模型的推理能力
我们可以用一个小剧场来理解以上问题：
假设你是一个项目经理，正负责写一份复杂的行业研究报告。你的办公桌（上下文窗口）就是工作区，桌子的容量固定且有限（临时工作记忆），且你只能从桌上的文件查找需要的信息。
每完成一个分析步骤，你的助手们（工具调用）都会将完整未压缩的反馈报告（调用结果）堆放在你的桌上。由于空间有限，报告迅速堆满，导致无法放新文件，任务陷入停滞——内存限制。
桌上堆满冗长且不重要的原始数据，你的注意力被大量细节分散，难以从中提取关键信息并聚焦下一步要完成的任务，导致效率低下——上下文干扰。
除了必要的报告外，桌上还有数百份功能相似的工具说明书，这些不相关的文件让你难以选择正确的工具或行动——上下文混淆。
其中两位助手提交了关于同一主题但结论矛盾的报告，导致你在确定最终结论时感到困惑——上下文冲突。
项目初期，你在核心项目计划书（上下文历史）中误写了一个错误数据。由于这份计划书一直放在你的桌上，并被反复参考，这个错误的前提“污染”了后续所有分析，导致项目偏离正轨——上下文污染。
下一篇会继续分享如何优化上下文工程，欢迎留言讨论！
