学习笔记：上下文工程 (Context Engineering) —— AI Agent 背后的关键技术

同样一句话，为什么有人能用 AI 写出高质量结果，有人却老是「答非所问」？差别往往不在模型，而在你喂给它的上下文（Context）。这篇笔记整理自一堂上下文工程公开课，从 Prompt Engineering 到 Context Engineering 的演进讲起，拆解选择、压缩、Multi-Agent 三大实战招式，以及工具调用的落地机制。

课程来源：【生成式人工智慧與機器學習導論2025】第 2 講：上下文工程 (Context Engineering) — AI Agent 背後的關鍵技術
配套代码：Google Colab 范例代码

核心导览

从 Prompt Engineering 到 Context Engineering
一个完整的 Context 包含哪些要素？
为什么 AI Agent 时代尤其需要 Context Engineering？
Context Engineering 的三大核心招式：选择、压缩、Multi-Agent
动手实作：工具调用（Tool Use）与 Computer Use 机制

1. 从 Prompt Engineering 演进到 Context Engineering

在数学上，模型生成可以看作函数映射 $y = f(x)$ ：

修改模型参数 $f$ ：属于机器学习/微调（Training/Learning），成本高且许多闭源模型无法直接修改。
优化输入序列 $x$ ：即管理上下文，确保给模型足够且高质量的输入，直接决定了输出质量。

Prompt Engineering vs. Context Engineering

早期 Prompt Engineering：关注特定排版格式（如 JSON 结构、Markdown 分割）或是各种奇妙的“提示词咒语”（如 “Let’s think step by step”、“给你小费”、“事关世界和平” 等）。然而随着现代大模型原生能力提升，这些表层咒语的收益已越来越低。
现代 Context Engineering：核心不再是人工试探玄学语句，而是系统化、自动化地管理和组织模型的输入流。通过动态筛选、过滤和清理，在有限的上下文窗口中精准保留高价值信息。

2. 一个完整的 Context 应该包含什么？

现代大模型在复杂任务中实际接收的 Context 绝不仅是用户说的一句话，而是多维信息的组合体：

User Prompt（用户指令与约束）：任务要求、格式规则、背景前提与上下文细节（例如明确指出是在超商还是在曼谷，能避免歧义回答）。
In-Context Learning（上下文示例）：给出少量高质量示例（Few-shot）。如 Gemini 1.5 依靠输入整本教科书与双语句对（示例）即获得了小众语言 Kalamang 的翻译能力，底层未更新参数，全靠上下文推理。
System Prompt（系统提示词）：定义模型身份、规则底线（拒绝危险行为）、输出风格、知识截止日期与当前时间等。
对话历史（短期记忆）与外部长期记忆：多轮会话记录或从外部记忆库拉取的用户画像。
外部检索资料（RAG 搜索结果）：搜索引擎或知识库回传的事实依据。
工具调用信息（Tool Use & Observation）：工具声明、模型生成的调用指令以及工具执行后的返回结果。
深度思考过程（Reasoning / CoT）：如 o 系列或 DeepSeek-R 系列生成的思维链（脑内小剧场）。

3. 为什么 AI Agent 时代特别需要 Context Engineering？

3.1 AI Agent 的运行本质

AI Agent 并没有脱离自回归文字接龙的本质。它以环境交互循环为核心：

\text{Observation} \rightarrow \text{LLM Reasoning/Action} \rightarrow \text{Environment Feedback} \rightarrow \text{New Observation} \dots

3.2 运行长程任务的挑战

长上下文衰减与迷失（Lost in the Middle）：模型往往只对上下文的“头部（开头）”与“尾部（结尾）”注意度高，位于中间的信息极易被忽略。
Context Rot（上下文腐烂）与性能退化：实验表明，虽然模型标称支持数十万甚至数百万 Token，但随着无用历史信息堆积，模型执行简单任务（如精确复述或长文本推理）的准确率会急剧下滑。
信息碎片化负效应：以“挤牙膏式”逐步追加碎指令，往往比一次性给出清晰完整的前提要求得到更差的表现。
负面经验的反效果：在上下文中直接塞入大量“模型过去的错误回答”，有时反而像“不要想白熊”效应一样诱导模型继续犯错，而非学会纠正。

因此，Context Engineering 的第一准则就是：避免塞爆 Context，只放必要信息，及时清理无用冗余！

4. Context Engineering 的三大核心套路

招式一：选择（Selection）—— 严控输入准入

RAG 进阶筛选（Reranking & 句级精炼）：通过小模型对搜索结果重排，甚至只提取关键句，避免将整篇冗长网页直接塞入 Prompt。
工具检索（Tool RAG）：当系统拥有成百上千个 API 时，不能把所有工具定义都塞进 System Prompt，而是先检索出当前意图最相关的几个工具。
记忆精选（Memory Selection）：将海量琐碎历史存入外部磁盘向量数据库，根据时间新鲜度（Recency）、重要性打分（Importance）与相关度（Relevance）精准检索。

招式二：压缩（Compression）—— 提炼骨干状态

递归摘要（Recursive Summarization）：会话或 Agent 步数达到阈值后，调用专职轻量模型对过往历程生成紧凑摘要，丢弃无意义的过程数据（如点击广告弹窗、页面渲染过渡信息等）。
保留索引与外部挂载：在摘要中留下关键文件指针（如本地日志路径或文档 ID），需要详查时再由 Agent 自主调用工具打开。

招式三：Multi-Agent 协作 —— 上下文解耦与分工

单 Agent 的困境：一个人既当指挥、又写代码、还要排查环境和执行页面交互，庞大的多步上下文会瞬间填满窗口导致瘫痪。
多 Agent 架构的本质优势：除了专业分工外，更是极佳的上下文隔离手段。
- 主控 Leader Agent：仅维护全局规划与状态总览，不记录底层细碎执行细节。
- 执行 Sub-Agent：各自在干净独立的上下文中专心完成特定子任务（如订餐厅、订机票、代码测试），完成后仅向上层回传精炼结果。

5. 动手实作：工具调用与 Agent 落地

5.1 工具调用的真实执行流

语言模型本身永远只能输出文本，它没有直接运行代码或调用外部系统的魔法。完整的 Tool Use 流程为：

指令定义：在 Context 中用自然语言或 Schema 告知模型工具名称、参数格式及触发标签（如 <tool>...</tool>）。
模型生成调用意图：模型做文字接龙，自发输出调用文本（如 <tool>multiply(111, 22)</tool>）。
外部程序拦截与执行：后端代码截取该标签内容，利用解释器或 API 发起真实计算，得到执行结果。
上下文回填与再生成：把工具输出注入对话上下文，模型读取真实数据后再输出最终答复。

5.2 Computer Use（操作屏幕与键鼠）

将屏幕截屏转化为视觉/坐标 Token，结合键鼠控制 API（移动、点击、键盘输入），使模型能够以图形界面交互的形式自动化处理长流程任务（如网页订票、代码工程生成等）。

小结

Context Engineering 的第一准则是不塞爆：只放必要信息、及时清理冗余，对抗长上下文衰减与「迷失在中间」。
三大核心招式：选择（严控输入准入）、压缩（提炼骨干状态）、Multi-Agent（上下文解耦与分工）。
工具调用让模型长出手脚：模型只输出文本，由外部程序拦截执行，再把结果回填上下文继续生成。