上下文工程（Context Engineering）

随着 LLM 理解推理能力增强，复杂的 prompt 技巧变得不再必要，简单意图输入即可被很好理解。配合 prompt enhancement 工具，prompting engineering 变得更容易。同时，AI 智能体技术快速发展，交互对象从 LLM 升级到智能体。有效管理和优化上下文信息成为构建高效智能体的关键技能。上下文工程（Context Engineering）变得更重要，正重新定义我们与 AI 的交互方式。

本文主要参考 Context Engineering，How Long Contexts Fail 感兴趣的同学可直接阅读原文。

智能体能力分级（L0-L5）

在讲上下文工程前，先了解智能体能力分级。当前 AI 智能体按能力和复杂度分为六个等级，每个等级在上下文处理能力上有显著差异：

等级	名称	核心特征	上下文需求	代表产品
L0	无 AI	纯工具 + 感知 + 行动	基础指令集	传统软件、脚本工具
L1	基础智能体	基于规则的 AI	静态规则库	早期聊天机器人、专家系统
L2	任务级智能体	IL/RL + 推理决策	动态上下文管理，任务相关信息检索和基本对话历史记忆	ChatGPT、GitHub Copilot
L3	认知智能体	LLM + 记忆反思，能够从经验中学习和改进，支持复杂的多步推理	长期记忆 + 上下文压缩，智能的上下文压缩和摘要	Claude、GPT-4、Cursor
L4	自主学习智能体	自主学习泛化	元学习上下文，自适应上下文策略，知识主动获取和整合	o1-preview、Claude Sonnet
L5	协作智能体	个性化 + 多智能体协作	分布式上下文管理，多智能体间的上下文同步	多智能体系统（Anthropic multi-agent research system）

我们目前主要构建或使用的智能体至少是 L2 级别，智能体复杂度增长正是上下文工程变得重要的根本原因。

智能体架构如下：

什么是上下文工程？

一句话说明：Context Engineering 通过系统性构建、管理和优化 AI 模型的输入上下文，提升模型在复杂任务中的理解与输出能力。

核心是在智能体轨迹的每个步骤中，用恰到好处的信息填充上下文窗口 的艺术和科学。正如操作系统管理 CPU 的 RAM 一样，上下文工程在 AI 系统中扮演类似角色。

LLM 的能力来源于两个方面：

• in-weights memory：训练集学到的能力，训练完成就定型，基本难以修改。决定 LLM 的 "智力" 水平和泛领域知识能力
• in-context memory：从对话、知识库、参考资料等学到的，提供新的正确知识，LLM 就能对特定领域获得 "新知"

因此上下文工程关注的是 in-context memory。

上下文包含的内容

上下文功能包含的内容已远超用户的 Prompt，涵盖 LLM 在做出响应前能看到的所有信息生态系统：

• Instructions/System Prompt：系统级指令和角色设定

• History：对话历史（短期记忆）

• Long-Term Memory：持久化的用户偏好和事实（长期记忆），比如 Cursor 的 memory、rules，或 Claude Code 的 CLAUDE.md

• Retrieved Information：动态检索的外部数据（例如来自 RAG，仓库代码）

• Available Tools：可用的工具（API、函数）及其定义，比如 MCP 功能或智能体自身的工具（write、read tools）

• Structured Output ：期望的输出格式（例如，JSON Schema）

可见，用户通过问答提供的 Prompt 只占很小部分，可归类到 Instructions 中。

How Long Contexts Fail

今年，随着 LLM 在推理和工具调用（MCP、Function Call 等）方面能力飞速提升。智能体交替进行 LLM 调用和工具调用，通常用于长期运行任务。智能体通过工具反馈决定下一步行动，即 ReACT（Reasoning and Acting）框架架构，通过 "思考-行动-观察" 循环，为上下文工程提供结构化管理模式。

然而，长期运行任务和大量 Tool Calls，意味着智能体经常使用大量 token。毕竟 LLM 不带记忆，不记得之前发生什么。为让它具备多轮对话能力，会将历史会话信息、Tool Calls 信息全部带上。

这会导致许多问题：

• 超出上下文窗口的大小，造成"失忆"
• 增加成本/延迟，或降低智能体性能，越多 token 意味着越长处理时间

长上下文导致问题的几种具体表现：

Context Poisoning（上下文中毒）

当错误信息或幻觉内容进入上下文并被持续传播时发生。

典型表现：

• 智能体基于错误信息制定不可能或无关的目标
• 错误假设在后续推理中被当作事实使用
• 一旦中毒信息进入上下文，很难被自动纠正

Context Distraction（上下文分散）

当累积的上下文变得过于庞大，模型更多关注历史信息而非生成新解决方案时发生。

性能衰减：

• LLM 阈值：约 32k tokens 后开始显著性能下降
• 小 LLM 阈值：更低，通常在 8k-16k tokens

Context Confusion（上下文混乱）

当上下文中包含过多无关内容影响模型响应质量时发生。

• 模型在多工具环境下性能显著下降，比如有非常多的 MCP tools 生效
• 核心问题是 "如果你把某些内容放入上下文，模型就必须关注它"，即使是无关工具的存在也会干扰决策过程

混乱产生：

# 上下文混乱示例
context_example:
  task: "帮我写一个排序函数"

  # 相关信息（有用）
  relevant_context:
    - 编程语言：Python
    - 数据类型：整数数组
    - 性能要求：O(n log n)

  # 无关信息（产生混乱）
  irrelevant_context:
    - 数据库连接配置
    - 前端样式规范
    - 邮件发送接口
    - 用户认证逻辑

  # 结果：模型试图关注所有信息，导致输出质量下降

Context Clash（上下文冲突）

当上下文中新信息与现有信息发生冲突时发生。

• 平均性能会严重下降
• 模型在早期轮次做出假设并过早尝试生成最终解决方案
• 新信息与先前假设冲突时，模型难以有效调整，比如你先告诉模型应该这样做，然后又告诉它不能这样做，它就乱

How to Fix Context

所谓 "Garbage in, garbage out"，让智能体更好工作关键在于：给智能体正确且恰到好处信息。工程上可从以下四个关键策略进行优化：

1. 持久化上下文（Write Context）

好记性不如烂笔头，更何况 LLM 没有记性，只能将信息保存在上下文窗口之外，供智能体执行任务时使用。为让模型拥有更长久记忆和对项目整体认知，我们需要在模型任务处理前、过程中、结束后在 Context 窗口外部记录一些存档点（ScratchPad）。让模型在后续操作中，能从外部读取游戏进度，而不每次都从 0 开始。

ScratchPad 可以几种不同方式实现。可以是一个简单写入文件工具调用，也可以是运行时状态对象中一个字段，在会话期间持续存在。比如 RAG、Memory、Rule 等。

RAG（检索增强生成）

常见的外部文档知识库，或者代码仓库都可以通过 RAG 的方式进行向量存储，便于后续的相关性查找。

• 将文档切片并转换为向量存储
• 基于语义相似度检索相关内容
• 动态注入到模型的上下文中

比如在 Cursor 中打开一个代码仓库后，后台会启动 Codebase Indexing 的工作流，将所有的代码建立索引：

Memory

长期、持久化的存储，记录关键事实、用户偏好或对话摘要，可在不同会话间调用。将一些特定场景的处理方式已 Memory 的方式存储下来，让模型下次再遇到该问题时，可以按照要求进行处理。

像是 Cursor, Claude Code 等等主流的 AI 编码工具都具有记忆的能力。

Cursor Rules

在 Cursor 中还存在一个特殊的 Memory, 叫做 Rules, 也是用来规范模型的行为。在 Cursor Rules 开发实践指南 中有提到具体的使用方式。而在 Claude Code 中不管是 Memory 还是类似于 Cursor 的 Rules 规范, 默认都只存在一个地方，就是 CLAUDE.md。

Scratchpads

供智能体在执行复杂任务时使用的临时、会话内记忆，用于记录中间步骤。这些信息不会记录到外部。主要用于在对话中，对模型进行规范。和 Memory 的区别主要在于一个长期，一个短期。

2. 检索上下文（Search Context）

根据当前任务，使用 RAG，Grep 等方式动态地从记忆、工具库或知识库中选择相关上下文。从大量可用信息中智能选择最相关的内容动态构建任务相关的上下文。

RAG 是代码智能体中最成熟的上下文选择技术，智能体还需要搭配 多层次检索策略 进行相关信息检索：

• AST 解析 + 语义分块：沿语义边界进行代码分割
• Grep/文件搜索：精确匹配
• 嵌入向量+知识图谱检索：关系推理
• 语义相似度检索：基于任务内容匹配最相关的记忆片段
• 重排序步骤：按相关性排序最终结果

Cursor 在检索代码时，就会同时利用 Index Codebase 的向量检索，再加上 AST（抽象语法树）分析和静态分析结果来筛选合适的代码片段。而 Claude Code 做为 CLI 工具，没有向量检索的能力，所以检索时会大量使用 Grep 工具，相对来说更耗 token。

对于有 Memories 的智能体来说，Memory 的选择也是一个巨大的挑战，不是所有的 Memories 都和当前对话相关联，需要从其中筛选出合适的 Memories。尤其 Memory 具有分层，比如 user memory、project memory，对于 Cursor 来说，Rules 也具备不同的关联方式。

3. 压缩上下文（Compress Context）

利用摘要或修剪技术来管理智能体在长时程任务中不断增长的上下文，防止上下文窗口溢出问题。保留执行任务所需的最少 tokens，优化上下文使用效率。

无论 LLM 的上下文窗口有多大，智能体的交互可能涉及数百轮对话，并且可以还会包含大量 Tool Calls 和 RAG 检索。迟早是要将上下文窗口占满的。为了让智能体不要失忆，并且保持性能，所以需要在合适的时候，手动或者自动进行上下文压缩，只保留关键的历史信息。

就像是工作中开了一个三四小时的长会，里面有很多细节的讨论，拉扯，发散。最后留下的关键结论和 todo list 可能就那几条，而后续的工作也是基于这些关键项进行，没有人会把会议录屏完整的播放一遍，在开始后续的工作。

而筛选关键信息，需精准捕捉特定事件或决策过程。就是压缩上下文的首要目的。

在 Claude Code 或者 Gemini CLI 中，当对话内容占用上下文窗口 92%或者更高容量时，系统会自动启动 "压缩模式"，对用户与智能体的完整交互轨迹进行摘要处理。也可以通过 compact 等命令手动让智能体进行压缩，在压缩时，还可以告知智能体你想保留哪些关键信息：

Claude Code 采用三层记忆架构，会从 背景上下文，关键决策，工具使用，用户意图，执行结果，错误处理，未解决问题，后续继续 等 8 个关键点进行压缩：

Claude Code 的整体架构和压缩流程可以查看 Claude Code 智能体系统完整技术解析 获得更完整的介绍。

4. 隔离上下文（Isolate Context）

主要应用到多智能体场景中，将一个复杂问题分解，并将子任务分配给专门的子智能体，多智能直接通过 A2A 协议进行通信。每个子智能体都拥有自己独立的、更聚焦的上下文窗口通过智能分离实现精准的任务执行环境。

关键点在于：

• 每个智能体维护独立的上下文空间
• 通过标准化协议进行信息交换
• 避免上下文污染和认知冲突

多智能体架构通常会有一个 Lead 智能体，也可以叫做 Orchestrator。用于调度和与其他子智能体通信，并且将合适的上下文传给到对应的子智能体：

比如一个用于编写代码和审查的多智能体架构，在和编程智能体信息体通信时，只需要传递任务信息，在和审查智能体通信时需要给代码信息即可。

需要注意的是，多智能体架构特别的烧 token。

除了真正参与到智能体开发的同学，平时我们可能会比较少有机会会直接接触。有兴趣的同学可以查看 Anthropic 搭建多智能体的文章：How we built our multi-agent research system。

最近 Claude Code 也推出 Sub Agents 功能，可以创建并使用专业化 AI 子智能体，用来处理特定类型任务，实现任务导向工作流程和优化上下文管理。通过提供任务专属配置（包括定制化系统提示、工具和独立上下文窗口），实现更高效问题解决。可直观感受到多智能体架构能力：

5. 输出格式控制（Output Format）

虽然说是 4 个关键点，但是输出格式控制也还是蛮重要的。和智能体的交互，本质就是输入和输出，智能体调用 Tool，也是通过结构化输出的方式获取信息。 因此通过结构化输出格式能确保能上下文的有效传递和使用。

我们可以灵活尝试不同的上下文输出结构。常见的输出方式有两个 JSON Schema 或者 XML Schema。通常来说，XML 会具有更高的信息密度，以最大化 LLM 理解的方式组织信息。这意味着同样的信息，只消耗更少的 token:

参考：Own your context window

可以看到，所谓 Context Engineering 其实就是在智能体的构建和使用链路中加上了工程性的优化。没错，所谓 Context Engineering，其实就是 Software Engineering!

主流 LLM 上下文容量对比

模型	上下文窗口	约等于
Gemini 2.5 Pro	1000K tokens	75 万字（8 个 React 代码库）
GPT-4.1	1000K tokens	75 万字
Claude 3.7 Sonnet	200K tokens	15 万字（中等长度小说）
Kimi K2	128K tokens	9.6 万字（长篇论文）
DeepSeek V3	64K tokens	4.8 万字（技术文档）

一个中文字符不是对应一个 token，可以查看 DeepSeek Tokenizer 和 Token Counter 可视化查看模型 token 拆解方式：

最佳实践与建议

即使我们不进行智能体开发，了解上下文工程也能帮助我们更好使用智能体，并知道为什么有时候智能体会犯蠢。

疑惑解答

为什么 Cursor Rules 有时不生效？

原因一：规则冲突

# ❌ 冲突的规则
rules:
  - "使用 TypeScript 严格模式"
  - "允许 any 类型以提高开发速度"

# ✅ 一致的规则
rules:
  - "使用 TypeScript 严格模式，避免 any 类型"
  - "使用具体类型替代 any，如 unknown 或联合类型"

原因二：上下文压缩时丢失

Cursor 在进行上下文压缩时对 User Rules、Project Rules、Memory 等信息会按照优先级和相关性进行压缩，就会导致一些 Rules 丢失。

为什么智能体有时理解错误我的意图？

原因一：上下文污染

当对话中包含错误信息或不一致的描述时，会影响智能体的判断：

# ❌ 容易导致误解

用户："帮我实现一个用户管理功能"
用户："不对，我想要的是商品管理"
用户："等等，还是用户管理吧，但是要加上权限控制"

# ✅ 清晰的描述

用户："帮我实现一个用户管理功能，包含以下需求：

1. 用户的增删改查
2. 角色权限控制
3. 登录状态管理"

原因二：缺少上下文信息

智能体缺少项目背景或技术栈信息时容易产生偏差：

# ❌ 缺少背景

"帮我优化这个组件的性能"

# ✅ 提供背景

"这是一个 React + TypeScript 项目的用户列表组件，
当前渲染 1000+ 用户时很卡顿，帮我优化性能"

为什么智能体生成的代码风格不一致？

原因：缺少代码风格规范

解决方案是在 CLAUDE.md 或 Rules 中明确代码规范：

## 代码规范

- 使用 TypeScript 严格模式
- 组件使用函数式写法 + Hooks
- 状态管理使用 Zustand
- 样式使用 Tailwind CSS
- 文件命名使用 kebab-case

最佳实践建议

1. 及时开始新对话

当我们进行多轮对话和纠正后，发现智能体老是走偏，可能此时上下文窗口接近饱和，或包含太多无关信息。可主动开启新对话，用干净环境重新开始。

2. 不要关联过多的 MCP 工具

在 MCP 发展火热时，我们可能会尝鲜关联很多工具。模型在多工具环境下性能显著下降，无关工具存在会干扰决策过程。因此只激活几个真正会用到的 MCP 工具可有效降低噪声。

3. 好记性不如烂笔头

在开发项目之前，可以让 Cursor 和 Claude Code 等工具对代码库进行全面扫描，生成项目架构、领域模型等信息。将这些信息写入 Rules 或 CLAUDE.md 中，让智能体对代码库有大体认知。以后做需求开发时，智能体就不需要全面扫描代码库，可直接根据这些 Rules、CLAUDE.md 文件快速了解，缩小收缩范围。也可利用 memory-bank MCP 工具生成更详细工程信息。

在进行超大需求开发时，可以让模型分析需求，拆解任务。将每一步要做什么等信息写入 todolist 文件中。完成任务规划后，按照 todolist 进行分步处理，每一步完成后及时更新进度。后续哪怕开启新对话，也可进行进度追踪和继续任务。也可使用 claude-task-master 这样工具简化这一流程。

Cursor， Claude Code 在单次对话中已经采用了 todos 的方式来拆解任务和管理进度。

4. 给出尽量准确的输入

如果我们明确知道功能要修改范围，可使用 @ 方式直接告诉智能体。这样既准确，又省去它自己查找过程的 token 开销。

5. one more thing

除此之外，在 Cursor 等文档中也提到了如何处理 Large Codebases，Cursor 的工程师也在 Twitter 上发表了 12 条 best practice

总结

上下文工程作为 AI 智能体时代的关键技术，正重塑我们与 AI 系统的交互方式。通过掌握写入、选择、压缩、隔离这四种核心模式，结合 ReACT 框架和 MCP 协议的实践经验，我们能够构建更智能、高效的 AI 系统。

核心要点：

1. 上下文质量决定输出质量 - "Garbage in, garbage out"
2. 工程化管理是关键 - 系统性构建和优化上下文
3. 实践中不断调优 - 根据具体场景选择合适策略
4. 团队协作需要规范 - 统一的配置和知识共享

随着 AI 技术持续发展，上下文工程将成为每个开发者必备的核心技能。