上下文工程：AI 智能体时代的新基建

林洪勇创建于 2025年10月2日562

上下文工程：AI 智能体时代的新基建

“构建 AI 应用的重心，已经从提示词工程转向上下文工程。”
—— Anthropic，《AI 智能体的高效上下文设计》

就在 Anthropic 推出 Claude Sonnet 4.5 的第二天，其工程团队发布了一篇极具前瞻性的博客：《AI 智能体的高效上下文设计》。这篇博文不仅呼应了 Andrej Karpathy 的观点，也正式宣告了 “上下文工程”（Context Engineering） 正成为构建工业级大模型应用的核心方法论。

本文将带你深入解读这篇博客的核心思想，系统梳理上下文工程与提示词工程的区别、为何它如此重要，以及如何在实践中构建高效的上下文结构。

一、从“提示词工程”到“上下文工程”：一场范式迁移

1.1 什么是“上下文”？

在大语言模型（LLM）中，上下文指的是模型在采样生成时所能看到的所有 token，包括：

系统提示（System Prompt）
用户输入与对话历史
工具调用记录
外部数据检索结果
模型输出及反馈

换句话说：上下文 = LLM 当前状态下能“看到”的全部信息。

1.2 提示词工程 vs 上下文工程

维度	提示词工程（Prompt Engineering）	上下文工程（Context Engineering）
核心目标	编写最优提示以获得理想输出	在整个推理过程中管理最优信息集合
关注点	单次请求的指令设计	多轮交互中的状态持续优化
时间范围	静态、一次性	动态、持续演进
范围	仅限于 prompt 文本	包括历史、工具、记忆、协议等

Anthropic 明确指出：

上下文工程是提示词工程的自然演进。

早期 AI 应用多为单次任务（如文本分类、问答），此时“写好一个提示”足以解决问题。但随着我们迈向能执行复杂任务、长时间运行的 AI 智能体（AI Agents），仅仅优化提示已远远不够。

真正的挑战在于：如何在有限的上下文窗口内，始终保留最关键的信息？

这正是“上下文工程”要解决的问题。

二、为什么上下文如此重要？——注意力预算的稀缺性

尽管现代 LLM 支持长达 200K 的上下文长度，但我们发现：模型对远距离信息的记忆和利用能力会随上下文增长而下降。

这种现象被称为 “上下文衰减”（Contextual Fading）。

2.1 上下文衰减的三大根源

注意力机制的平方复杂度（n² 限制）
Transformer 架构要求每个 token 关注所有其他 token，导致随着上下文增长，注意力权重被稀释。
训练数据偏差
模型更多地见过中短文本，对“超长依赖”的处理经验较少，缺乏专项训练。
位置编码的局限性
即使通过插值技术扩展上下文，也会导致模型对位置的理解模糊化，影响推理链完整性。

这意味着：

上下文是一种边际收益递减的有限资源。

我们可以将其类比为人类的“工作记忆”——容量有限，每增加一条信息都会消耗一部分“注意力预算”。

因此，上下文工程的本质是：

在注意力预算内，精确筛选最具信号价值的信息，最大化期望行为出现的可能性。

三、高效上下文的四项设计原则

为了在智能体系统中实现高效的上下文管理，Anthropic 提出了四个关键维度的设计建议：

1. 系统提示：清晰而不僵化

系统提示应处于“过度控制”与“过度模糊”之间的“黄金区间”：

❌ 太死板：硬编码 if-else 规则 → 易崩溃、难维护
❌ 太抽象：缺少具体行为指引 → 输出不可控
✅ 刚刚好：提供明确指令 + 启发式行为指导

实践建议：

使用结构化格式（XML / Markdown）组织提示内容，例如：

markdown 复制代码

<background>
...
</background>

<instructions>
...
</instructions>

## Tools
...

## Output Format
...

始终追求 “最小但完整的信息集” ——不是越短越好，而是在确保行为可控的前提下尽量精简。
从最小提示开始测试，逐步根据失败案例补充规则和示例。

2. 工具设计：高效交互的信息桥梁

工具（Tools）是智能体与环境互动的接口。好的工具设计应当：

自包含、鲁棒性强
参数命名清晰、语义明确
功能正交、避免重叠

常见失败模式：

工具太多 → 决策混乱
工具职责不清 → 模型难以选择

最佳实践：

构建 最小可行工具集（Minimal Viable Toolset），聚焦核心能力
让每个工具返回“高 token 效率”的结果（如摘要而非原始日志）

例如：grep 返回匹配行，而不是整个文件。

3. 少样本示例：用“图”代替千言万语

示例是强大的行为塑造工具，但常见误区是：

“把所有边缘情况都写进去，试图穷举规则。”

这不仅浪费上下文，还可能干扰模型判断。

正确做法：

精心策划一组多样化、代表性强的规范示例
展示典型输入输出对，体现目标行为模式
避免堆砌异常案例

记住：示例即“行为蓝图”，质量远胜数量。

4. 上下文检索：运行时按需加载

越来越多的应用采用 “即时检索”（Just-in-Time Retrieval） 策略，而非一次性加载所有数据。

即时检索的工作方式：

保留轻量级标识符（文件路径、URL、查询句柄）
运行时通过工具动态调用，按需加载相关内容

例如，Claude Code 并不一次性载入整个代码库，而是使用 glob, head, tail, grep 等命令逐步探索文件系统。

优势：

节省上下文空间
支持渐进式理解（Progressive Disclosure）
模拟人类认知：不靠记忆，靠索引+按需查找

元数据的价值不可忽视：

文件名（test_utils.py vs core_logic.py）暗示用途
目录结构反映模块职责
时间戳帮助判断信息时效性

这些信号共同构成了智能体的“情境感知”能力。

四、应对长周期任务的三大技术策略

当任务跨度超过上下文窗口时（如大型代码迁移、综合研究报告），传统方法将遭遇瓶颈。Anthropic 提出了三种主流解决方案：

1. 压缩（Compression）

原理：对历史对话进行摘要，保留关键信息，开启新的上下文窗口。

典型流程：

模型读取完整上下文
输出结构化摘要（如：关键决策、未解决问题、待办事项）
丢弃冗余内容（如工具调用结果）
新会话基于摘要继续执行

技巧：

先最大化召回 → 确保不遗漏关键信息
再逐步优化精度 → 去除冗余
可安全清理：深层的工具调用输出

📌 Anthropic 已在 Claude 开发者平台推出“自动压缩”功能。

2. 结构化笔记（Structured Notes）——智能体的记忆系统

又称“外部记忆”或“智能体记忆”，指将关键信息持久化存储在上下文之外，并在需要时重新载入。

典型应用场景：

维护 NOTES.md 或 TODO.md 文件
记录项目进展、依赖关系、实验结果
跨会话保持状态

经典案例：Claude 玩宝可梦

在数千步游戏中持续记录：
- 经验值增长
- 已探索区域地图
- 战斗策略演变
即使重置上下文，也能通过读取笔记恢复进度

🧠 这种“长期连贯性”使原本不可能的长期规划任务成为现实。

📌 Anthropic 已推出公开测试版的 Memory Tool，支持基于文件的持久化记忆管理。

3. 子智能体架构（Multi-Agent Architecture）

核心思想：拆解任务，由多个专业化子智能体并行处理，主智能体负责协调与整合。

架构层级：

主智能体：制定战略、分配任务、汇总结果
子智能体：专注执行具体子任务（如文档分析、代码生成）

数据流特点：

子智能体可在本地使用数万 token 进行深度探索
最终只向主智能体返回 1,000–2,000 token 的精炼摘要

优势：

实现关注点分离
防止上下文污染
提升复杂任务的可扩展性与可靠性

类似人类团队协作：专家深入调研，经理听取汇报后做决策。

📌 参考文章：《我们如何构建多智能体研究系统》

五、如何选择合适的上下文策略？

任务类型	推荐策略	原因
高频交互对话	压缩 + 摘要	保持对话连贯性
迭代式开发项目	结构化笔记	记录里程碑、跟踪进度
复杂研究分析	子智能体架构	并行探索、降低认知负荷
动态环境操作	即时检索	避免预加载过期数据

最佳实践：采用混合策略
如 Claude Code：

预载 CLAUDE.md（关键配置）

按需调用 grep/ls/cat 动态探索

自动压缩历史 + 维护 NOTES.md

六、结语：上下文即战略资源

上下文工程代表了我们使用 LLM 的根本转变：

❌ 从前：寻找“完美的提示”
✅ 现在：持续策划“最优的信息流”

无论你是：

设计压缩机制
构建高效工具
实现即时检索
还是搭建多智能体系统

核心原则不变：

找到最小但信号最强的 token 集合，
最大化你期望结果出现的概率。

随着模型能力不断增强，未来的趋势是：

更少的人工干预
更多的智能体自主探索
更强大的上下文自我管理能力

但无论如何演进，将上下文视为稀缺资源，将是构建可靠、高效 AI 智能体的永恒准则。