Awesome Context Engineering：AI 时代的上下文工程知识百科

当 AI 开始"健忘"：一个真实的痛点场景

你在调试一个复杂的 AI 智能体，它已经能完成代码审查、数据分析和报告生成。然而某天你突然发现：当你让它处理一个包含 50 份文档的长任务时，它的输出质量断崖式下跌——曾经准确的分析开始出现逻辑混乱，重要细节被完全忽略，甚至连任务目标都开始混淆。

这不是模型变笨了，而是 上下文窗口被污染了。

这就是 Context Engineering（上下文工程）要解决的核心问题：在大模型处理超长文本、多轮对话、多智能体协作时，如何科学地管理"喂给"模型的信息，让它始终保持清醒、高效、准确。

Context Engineering 是什么？

Context Engineering 是对大语言模型信息负载进行系统性优化的学科。在 AI 智能体轨迹的每一步中，用恰当的信息填充 context 窗口——不多，不少，刚刚好。

它包含五个核心维度：

• Context 检索与生成：选择和创建最相关的信息
• Context 处理：组织和构建 context 以实现最佳消费
• Context 管理：处理 context 窗口、内存和跨交互状态
• Context 压缩：在保留关键信息的同时减少 token 使用
• Context 隔离：在不同 context 空间中分离关注点

为什么这个问题在 2025 年变得如此紧迫？

随着 Claude 3.5、GPT-4o、Gemini 1.5 等模型将 context 窗口扩展到 100K 甚至 1M tokens，开发者们普遍产生了一种幻觉：上下文够长了，随便用。

然而现实很残酷。Chroma Research 的研究（Context Rot）明确指出：增加输入 token 数量会显著降低模型性能。模型对远处信息的记忆力远不如近期信息，在超长 context 中，关键细节被"稀释"的概率大幅上升。

Manus 团队在构建生产级 AI 智能体时，总结出一条血泪教训：围绕 KV-Cache 进行性能优化设计，同时采用"掩码而非移除"（Mask, don't remove）的工具管理策略——因为彻底移除工具会破坏模型对工具生态的认知，而掩码只是暂时忽略。

四大核心策略：LangChain 的 Context 工程方法论

LangChain 官方博客系统总结了 Context 工程的四大关键策略：

1. 写入 Context（Write Context）：将信息保存在 context 窗口之外。通过外部存储（向量数据库、键值存储、文件系统）来扩展模型记忆，而非堆砌在 prompt 中。

2. 选择 Context（Select Context）：将最相关的信息拉入 context。不是把整个知识库都塞进去，而是通过 RAG、语义检索等手段精准"召回"所需片段。

3. 压缩 Context（Compress Context）：仅保留必要的 token。通过摘要、实体提取、关键信息蒸馏等技术，在有限空间内最大化信息密度。

4. 隔离 Context（Isolate Context）：在不同空间分割 context。在多智能体系统中，不同智能体有各自独立的 context 空间，避免信息相互干扰。

Context 失效的四种模式

dbreunig 的深度研究将长 context 失效归纳为四种典型模式：

• Context 污染（Poisoning）：无关信息污染了 context 空间，干扰模型对核心任务的判断
• Context 分散（Distraction）：信息过于碎片化，模型注意力被分散，难以聚焦
• Context 混乱（Confusion）：相似但不同的信息在 context 中重叠，模型产生混淆
• Context 冲突（Clash）：新信息与旧信息相互矛盾，模型决策依据不一致

针对这些问题，解决方案包括：RAG 精排、工具配置优化、Context 隔离、上下文剪枝、摘要压缩、信息卸载等技术手段。

Claude 的工程实践：来自 Anthropic 官方的建议

Anthropic 工程师在官方博客中分享了大量实战经验：

• 为 AI 智能体编写高效工具：工具设计要简单、明确、一致，避免过于复杂的参数结构
• 通过 MCP 实现高效代码执行：Model Context Protocol 让智能体与外部工具的交互更规范、更高效
• Context 编辑与 Memory 工具：在多轮对话中管理模型对历史信息的读写，避免记忆混乱
• 多智能体研究系统的构建：如何在多个 AI 智能体之间分配 context 资源

Claude Code 的最佳实践指南更是直接面向开发者，提供了大量可直接复用的 prompt 模板和工具设计模式。

谁在推动这个领域？

• Manus：首个通用 AI 智能体项目，在生产环境中积累了丰富的 Context 工程经验
• Anthropic：Claude 系列模型的开发商，输出了大量权威的 Context 工程实践指南
• LangChain：最流行的 LLM 应用开发框架，提供了系统的 Context 管理方法论
• Humanlayer：专注于为 AI 智能体设计人机协作工具的团队

上手门槛与使用建议

维度	说明
知识门槛	需了解 LLM 基本原理，有 AI 应用开发经验更佳
技术门槛	无需编程，直接阅读 Markdown 文档即可学习
适用人群	AI 开发者、NLP 研究者、智能体设计者
语言支持	英文原版 + 中文翻译（README_CN.md）

局限与争议

作为一个知识合集类项目，Awesome Context Engineering 的局限性也比较明显：

1. 不提供可运行代码：所有内容均为 Markdown 文档，无法直接部署或运行
2. 内容时效性挑战：AI 领域发展迅速，部分资源可能面临链接失效的问题
3. 偏向理论框架：虽然有实践案例，但缺乏系统性的工具库或框架实现
4. 收录标准不透明：作为 Awesome List，资源筛选标准完全依赖维护者主观判断

此外，关于"长 context 是否真的有效"在学术界仍有争议。部分研究者认为，扩展 context 窗口只是表面解法，真正的瓶颈在于模型架构本身对长程依赖的建模能力。

行业意义与未来趋势

Context Engineering 的兴起折射出 AI 应用开发的一个根本性转变：从"调 Prompt"到"建系统"的跃迁。

早期 AI 应用开发者的核心技能是写好 prompt。如今，随着应用复杂度提升，Context 管理已经成为与模型选择同等重要的系统性工程能力。从 RAG 到 MCP，从向量数据库到外部记忆系统，所有这些技术本质上都在回答同一个问题：如何让 AI 在无限的语义空间中，始终拿到正确的信息。

这个知识库的价值在于：它将散落在论文、博客、代码库中的 Context 工程实践系统化地组织起来，为 AI 开发者提供了一张完整的知识地图。在 AI 应用开发从"调参艺术"走向"系统工程"的大趋势下，这类知识基础设施的价值只会越来越大。

---

项目基本信息

属性	值
GitHub	yzfly/awesome-context-engineering
Stars	127
License	CC0-1.0（完全开源，无版权限制）
语言	无代码（Markdown 知识合集）
维护者	yzfly
主题标签	context-engineering, prompt-engineering, claude, manus, AI-agents