上下文工程终极指南：从提示工程到Claude Code，看懂这篇就够了！

引言

随着 AI Agent 的快速发展，一个新的名词「上下文工程」进入大家的视野，很多人会好奇它与「提示词工程」有什么区别，是又在造新的概念吗？我们今天就来聊聊，究竟什么是「上下文工程」，以及它是如何工作的。

本文将围绕三个核心主题展开：

1.概念定义：介绍上下文工程的基本概念和核心组成部分。

2.业界工程实践：深入分析业界知名产品在上下文工程方面的具体实践。

3.未来展望：探讨上下文工程后续可能的演进方向。

今天我们将探讨的问题：

• 为什么需要上下文工程？
• 为什么 Claude Code 效果这么好？
• Manus 在优化 Agent 上做了哪些尝试？
• 为什么 Spec Driven + Context Engineering 会代替 Vibe Coding + Prompt Engineering？

概念定义

什么是上下文工程

上下文工程是指构建动态系统，以合适的格式为大语言模型（LLM）提供正确的信息和工具，从而让LLM能够合理地完成任务。

上下文不仅指你发送给 LLM 的单一提示词（prompt），更应该被视为模型在生成响应前所看到的一切信息。上下文工程就是如何将合适的信息填充到有限的上下文里的艺术和科学。

其核心特点包括：

• 动态构建系统
• 提供正确信息和工具
• 合适的格式化
• 让LLM合理完成任务

图片来源于网络

上下文工程的组成部分

一个完整的上下文工程系统包含以下七个核心组成部分：

1.指令/系统提示词：定义模型整体行为的初始指令，可以（也应该）包含示例、规则等。

2.用户提示词：用户提出的即时任务或问题。

3.当前状态或对话历史（短期记忆）：用户和模型此前的对话内容，展现当前交流的背景。

4.长期记忆：跨多次对话积累的持久性知识库，比如用户喜好、历史项目摘要、记住的特定事实。

5.检索的信息（RAG）：外部的、最新的信息，包括从文档、数据库或 API 获取的相关内容，用于回答特定问题。

6.可用工具：模型可以调用的所有函数或内置工具定义（如检查库存、发送邮件等）。

7.结构化输出：明确定义模型输出的格式，例如 JSON 格式的对象。

提示工程 vs 上下文工程

Context Engineering 代表着从传统 Prompt Engineering 到新范式的转变。

对比维度	Prompt Engineering	Context Engineering
关注点	词句技巧和表达方式	提供全面上下文
作用范围	只限于任务描述的表达	包含文档、示例、规则、模式和验证
类比	就像贴一张便签	就像写一部详细剧本

为什么需要上下文工程

简单演示对比

让我们通过一个简单的演示来理解上下文工程的价值：

上下文贫乏的情况：

用户：“Hey, just checking if you’re around for a quick sync tomorrow. 嘿，想问一问明天方不方便，我们快速碰个头？”

AI：“Thank you for your message. Tomorrow works for me. May I ask what time you had in mind? 感谢来信！明天我有空。你想约在几点？”

上下文丰富的"神奇"产品：

上下文：你的日历信息（显示你日程已满）、你与此人的过往邮件（用于确定合适的非正式语气）、你的联系人列表（用于识别 ta 为关键的合作伙伴）、send_invite 或 send_email 工具。

AI：“Hey Jim! Tomorrow’s packed on my end, back-to-back all day. Thursday AM free if that works for you? Sent an invite, lmk if it works. 嗨 Jim！明天我这边日程全排满了，从早到晚连轴转。周四上午有空，你看行不？邀请已发，确认下是否合适~”

上下文工程的价值

上下文工程能够带来以下重要价值：

1.降低 AI 失败率：大多数 Agent 失败不是模型问题，而是上下文不全。

2.保证一致性：AI 能遵循你的项目模式和规范。

3.支持复杂特性：有了完整上下文，AI 能处理多步骤实现。

4.自我修正：验证循环让 AI 能自动修正错误。

业界工程实践概览

在上下文工程领域，有三个产品代表了不同的实践方向：

1.LangChain：代表 Agent 框架和工具集合，早期的 Agent 框架，提供了各种Agent开发的基础设施，提出了一套上下文管理的方法论。

2.Claude Code：代表 Code Agent 能力上限，编码 Agent 的能力标杆，在长短记忆、分层多 Agent 协作等方面有独到实践。

3.Manus：重新展现 Agent 能力，让 Agent 回到大众视野，带动 MCP 发展，在工具使用、缓存设计等方面有独到实践。

长上下文的Context-Rot问题

随着上下文长度的增加，模型的注意力机制可能会出现"腐蚀"现象，导致对关键信息的关注度下降。

图片来源于网络

问题表现

• 产生幻觉后，会被持续带偏。
• 模糊性导致信息冲突，模型的行为会变得不可预测。
• 关键信息被稀释，随着上下文的增长，模型的注意力会被分散。
• 大量重复文本导致的"行动瘫痪"。

影响因素

• 上下文长度超过训练时的常见长度。
• 模型能力的限制。
• 信息密度不均匀分布。
• 自然语言的模糊性。

解决方案

为了解决长上下文带来的问题，业界提出了系统性的上下文工程方法论：

• Offload：通过引用减少上下文长度。
• Retrieve：RAG 技术动态检索相关信息。
• Reduce：压缩裁剪冗余信息。
• Isolate：分而治之，通过SubAgent处理子任务。

因此系统性的上下文工程方法论显得尤为重要。

LangChain的上下文管理方法论

LangChain 提出了四类上下文管理的基本方法：

图片来源于网络

写入（Offload）上下文

图片来源于网络

将信息保存在上下文窗口之外，以帮助 Agent 完成任务。不要将工具返回的全部原始信息都直接喂给 LLM。相反，应将其"卸载"到外部存储（如文件系统、数据库或一个专门的代理状态对象中），然后只将一个轻量级的"指针"返回给模型。

核心组件包括：

• File System - 文件系统
• Memories - 长期记忆系统(zep, mem0)
• DataBase - 数据库存储

应用场景：

• 长期记忆构建-claude
• 任务计划保存-manus
• 用户偏好记录
• 知识库管理

选择（Retrieve）上下文

简单来说就是我们所熟悉的 RAG，通过检索和过滤相关信息，来控制进入 Context 的内容的数量和质量。

核心组件：

• 更高级的检索（agentic search）- 从向量检索出发，逐渐往更复杂的搜索体系演化。例如混合召回，结合图谱的 GraphRAG，rerank 等等。
• 返璞归真的文本检索 - 仅仅使用 llms.txt + grep/find 之类的工具，通过 agent 的多轮工具调用来获取相关信息。这也是 Claude Code 的实现方式。

应用场景：

• 代码索引：DeepWiki
• todolist 召回
• 过多工具的召回 langgraph-bigtool（Manus 不推荐，可能导致缓存失效）
• 知识库

压缩（Compress）上下文

通过各种手段来裁剪上下文的内容，只保留完成任务所需的 tokens。

图片来源于网络

核心组件：

• 摘要生成 - 提取核心信息。
• Rerank - 移除不太相关的信息，RAG 场景中常用。
• 语义总结、压缩 - 保持含义精简表达。如果总结得不好，一样会出现关键信息丢失，甚至引入幻觉等问题。

应用场景：

• 网络搜索
• RAG
• 大量工具使用
• 多轮聊天

隔离（Isolate）上下文

非常类似 Workflow 时代的"分而治之"思想，如果一个任务的 context 压力太过巨大，我们就拆分一下，分配给不同的 sub agents 来完成各个子任务。这样每个 agent 的 context 内容都是独立的，会更加清晰和聚焦。

图片来源于网络

核心组件：

• 环境隔离 - 环境/沙盒隔离，让部分内容在 LLM 环境外运行，如代码执行场景，非常类似"卸载"。
• 多 Agent 分离 - 不同角色独立上下文，容易产生冲突的工作尤其要注意。"只读"类的工作最合适。

应用场景：

• 智能体中涉及代码执行或数据分析。
• 智能体工具调用。
• 复杂的多智能体系统如 Manus。

Claude Code的工程实践

Claude Code 作为编码 Agent 的标杆，在上下文工程方面有很多独到的实践：

• 三层记忆架构：实现从实时访问到持久化存储的完整覆盖。
• 实时 Steering 机制：流式输出提供持续交互反馈。
• 分层多 Agent 协作：主 Agent 协调 + SubAgent 执行的分层架构。
• 动态上下文注入：自动识别和注入相关文件内容。

三层记忆架构

在长对话中，上下文管理面临 Token 限制导致信息丢失、传统压缩方法破坏上下文连续性、无法支持复杂多轮协作任务等挑战。

Claude Code 的解决方案是构建三层记忆系统：

• 短期记忆（当前对话）
• 中期记忆（智能压缩）
• 长期记忆（CLAUDE.md 项目知识库）

实现从实时访问到持久化存储的完整覆盖。

关键要点：

• 92% 阈值自动触发智能压缩
• 8 段式结构化保存核心信息
• 跨会话恢复项目背景和用户偏好

实时 Steering 机制

传统 Agent 无法中断，用户必须等待完整执行结束才能调整方向，导致资源浪费和用户体验差，无法应对动态变化的需求。

Claude Code 的解决方案是采用异步消息队列 + 主循环的双引擎设计，支持实时中断和恢复，用户可以随时调整任务方向，系统自动保存状态并无缝切换。

关键要点：

• 异步消息队列支持实时中断。
• 主循环自适应流程控制。
• 流式输出提供持续交互反馈。

分层多 Agent 协作

复杂任务需要并发处理多个子任务，单 Agent 模式容易出现上下文污染、资源竞争和故障传播，影响整体执行效率和稳定性。

Claude Code 的解决方案是采用主 Agent 负责任务协调，SubAgent 执行专项任务，实现隔离执行环境，调度器控制最多 10 个工具并发，确保任务隔离和资源优化。

关键要点：

• 主 Agent 协调 + SubAgent 执行的分层架构。
• 独立执行环境避免上下文污染。
• 智能调度器实现 10 工具并发控制。

动态上下文注入

用户在对话中提及文件或概念时，系统无法自动关联相关信息，导致模型缺乏必要的上下文背景，影响响应质量和准确性。

Claude Code 的解决方案是智能检测用户意图中的文件引用，自动读取相关内容并注入上下文，基于依赖关系推荐相关文件，提供语法高亮和格式化显示，最大20文件8K Token限制。

关键要点：

• 自动识别和注入相关文件内容。
• 智能推荐基于依赖关系分析。
• 容量控制和格式优化提升体验。

Manus的优化实践

Manus 在上下文工程方面有诸多独特的优化实践：

• KV 缓存优化：围绕 KV 缓存设计，大幅降低成本和延迟。
• 工具遮蔽：遮蔽而非移除工具，保持上下文稳定性。
• 文件系统记忆：使用文件系统作为终极上下文。
• 注意力操控：通过复述操控注意力，保持目标一致。
• 错误保留：保留错误内容，让模型从失败中学习。
• 多样性增强：避免少样本示例陷阱，增加结构化变化。

围绕 KV 缓存进行设计

随着每一步的推进，上下文不断增长，而输出保持相对简短。这使得 Agent 相比聊天机器人的预填充和解码比例高度倾斜。在 Manus 中，平均输入与输出的 token 比例约为 100:1。

具有相同前缀的上下文可以利用 KV 缓存，大大减少首个 token 生成的时间和推理成本。使用 Claude Sonnet 时，输入 token 缓存 0.3 美元/百万 token，未缓存 3 美元/百万 token，十倍成本差异！

关键要点：

• 保持前缀稳定，时间戳会使 KV 缓存失效。
• 使上下文只追加，确保你的 JSON 序列化是确定性的，键顺序不稳定会破坏缓存。
• 在需要时明确标记缓存断点，不支持自动增量前缀缓存模型或推理框架需要在上下文中手动插入缓存断点。

遮蔽，而非移除工具

工具数量爆炸式增长，模型更可能选择错误的行动或采取低效的路径，但是要避免在迭代过程中动态添加或移除工具：

• 动态更改会导致 KV 缓存失效。
• 模型会对不再定义的工具感到困惑。

Manus 的解决方案是使用上下文感知的状态机来管理工具可用性，在解码过程中掩蔽 token 的 logits，基于当前上下文阻止或强制选择某些工具。

关键要点：

• 在实践中，大多数模型提供商和推理框架都支持某种形式的响应预填充（response prefill），这允许你在不修改工具定义的情况下约束动作空间。

使用文件系统作为上下文

当前上下文窗口限制带来三个常见的痛点：

• 观察结果可能非常庞大，容易超出上下文限制。
• 超过一定的上下文长度后，模型性能往往会下降。
• 即使使用 KV 缓存，长输入成本依然高昂。

为了解决这个问题，Manus 将文件系统视为终极上下文：大小不受限制，天然持久化，并且 Agent 可以直接操作。模型学会按需写入和读取文件——不仅将文件系统用作存储，还用作结构化的外部记忆。

关键要点：

• 只要保留 URL，网页内容就可以从上下文中移除；如果沙盒中仍然保留文档路径，则可以省略文档内容。这使得 Manus 能够缩短上下文长度，而不会永久丢失信息。

通过复述操控注意力

Manus 中的一个典型任务平均需要大约 50 次工具调用。这是一个很长的循环——由于 Manus 依赖 LLM 进行决策，它很容易偏离主题或忘记早期目标，尤其是在长上下文或复杂任务中。

Manus 的解决方案是通过不断重写待办事项列表，将目标复述到上下文的末尾。这将全局计划推入模型的近期注意力范围内，避免了"丢失在中间"的问题。

关键要点：

• 避免"丢失在中间"问题
• 保持目标一致性
• 提升长任务执行能力
• 无需架构变更

保留错误的内容

在多步骤任务中，失败不是例外；它是循环的一部分。然而，一个常见的冲动是隐藏这些错误，这是有代价的：擦除失败会移除证据。没有证据，模型就无法适应。

Manus 的解决方案是将错误的尝试保留在上下文中。当模型看到一个失败的行动——以及由此产生的观察结果或堆栈跟踪——它会隐式地更新其内部信念。这会改变其先验，降低重复相同错误的可能性。

关键要点：

• 模型从错误中学习
• 降低重复错误概率
• 提供负面样本训练
• 增强适应能力

不要被少样本示例所困

Few-Shot 是提高 LLM 输出的常用技术。但在 Agent 系统中，它可能会以微妙的方式适得其反。LLM 倾向于模仿上下文中的行为模式，容易导致偏离、过度泛化，或产生幻觉。

解决方法是增加多样性。Manus 在行动和观察中引入少量的结构化变化——不同的序列化模板、替代性措辞、顺序或格式上的微小噪音。

关键要点：

• 不同的序列化模板
• 替代性措辞表达
• 顺序上的微小变化
• 格式上的受控噪音

Spec-Driven Development：从提示词到规范驱动

Vibe Coding 的局限性

传统的 Vibe Coding 模式（Prompt → Code）存在明显局限性：

1.指望用户写出高质量的提示词是不现实的。

2.快速迭代生成的代码缺乏充分的文档、单元测试或架构约束，易引入技术债务。

3.开发者可能不完全理解生成的代码，当需要调试、修改或扩展功能时面临巨大困难，难以维护和扩展。

Spec-Driven的理念

解决方案是采用 Spec-Driven Development：

• Vibe Coding 是：Prompt → Code
• Spec-Driven Development 是：Prompt → Requirements → Design → Tasks → Code

关键优势：

• 优先定义需求文档、系统设计和任务清单，确保逻辑清晰，与业务目标对齐。
• 标准化利于针对性训练和调优大模型返回。
• 标准化利于构建完善的上下文，包含数据、实体、交互等。
• 对于大项目的维护和多人协作更有帮助。

Kiro 的实现方式

在具体实现上，Kiro 项目采用了规范驱动的开发方式：

requirement.md

定义了软件使用的 Story，这些 Story 定义遵循一种叫做 EARS (Easy Approach to Requirements Syntax) 的格式： WHEN [condition/event] THE SYSTEM SHALL [expected behavior] 由 LLM 根据需求生成。可以二次确认和修改。

design.md

详细列举设计的各种技术细节：

• 架构设计与模块拆分
• 接口与流程
• 数据库表结构
• 前端实现

tasks.md

• 把开发过程分解成任务。
• 每一个任务都被定义成一个 TODO List。
• 可以点击一个按钮启动一个 Task 的开发过程。
• 实时更新、回溯状态。

未来展望：从上下文工程到环境工程

LLM 现在就像在一间封闭的屋子中，我们通过发短信和它交流，未来它需要更完善的五感。

上下文工程仍是中间态，环境工程是终极目标。

阶段	主要内容	特点与局限性
提示词工程	设计单条高质量 Prompt，指导模型输出	静态、一次性、依赖人类编写，缺乏动态适应性
上下文工程	动态收集、组织和注入多模态、多维度上下文信息	关注"模型输入"，提升智能体表现，但仍以模型为中心
环境工程	构建一个持续演化、可感知、可交互的智能环境	关注"模型所处的世界"，AI不仅感知环境，还能主动塑造环境

为什么环境工程是终极目标？

1.环境不仅包含上下文，还包括动态变化的世界状态、规则、交互历史、反馈机制等。

2.AI Agent 不再只是"被动"接受上下文，而是"主动"感知、探索、影响环境。

3.环境工程强调 AI 与环境的双向作用，支持持续学习、自适应、协作等更复杂的智能行为。

4.在环境工程中，AI 的输入输出不再局限于文本或结构化数据，而是包括真实世界的感知、动作和长期影响。

总结

通过对 Claude Code、Manus 和 Kiro 等产品的分析，我们可以看到上下文工程在现代 AI 系统中的关键作用。它不仅解决了传统提示词工程的局限性，还为构建更智能、更可靠的 AI Agent 提供了系统化的方法论。

从 LangChain 的四类上下文管理方法，到 Claude Code 的三层记忆架构和实时 Steering 机制，再到 Manus 的 KV 缓存优化和工具遮蔽技术，以及 Kiro 的规范驱动开发模式，业界正在不断探索和完善上下文工程的最佳实践。

未来，随着环境工程概念的成熟，我们将看到 AI 系统从被动接受上下文走向主动感知和塑造环境，实现更高级别的智能交互。

如何学习大模型 AI ？

我国在AI大模型领域面临人才短缺，数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着Al技术飞速发展，预计到2025年，这一缺口将急剧扩大至400万，严重制约我国Al产业的创新步伐。加强人才培养，优化教育体系，国际合作并进，是破解困局、推动AI发展的关键。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

2025最新大模型学习路线

明确的学习路线至关重要。它能指引新人起点、规划学习顺序、明确核心知识点。大模型领域涉及的知识点非常广泛，没有明确的学习路线可能会导致新人感到迷茫，不知道应该专注于哪些内容。

对于从来没有接触过AI大模型的同学，我帮大家准备了从零基础到精通学习成长路线图以及学习规划。可以说是最科学最系统的学习路线。

针对以上大模型的学习路线我们也整理了对应的学习视频教程，和配套的学习资料。

大模型经典PDF书籍

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路！

配套大模型项目实战

所有视频教程所涉及的实战项目和项目源码等

博主介绍＋AI项目案例集锦

MoPaaS专注于Al技术能力建设与应用场景开发，与智学优课联合孵化，培养适合未来发展需求的技术性人才和应用型领袖。

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】

为什么要学习大模型？

2025人工智能大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 ， 大模型作为其中的重要组成部分 ， 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力， 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 ，为各行各业带来了革命性的改变和机遇 。

适合人群

• 在校学生：包括专科、本科、硕士和博士研究生。学生应具备扎实的编程基础和一定的数学基础，有志于深入AGI大模型行业，希望开展相关的研究和开发工作。
• IT行业从业人员：包括在职或失业者，涵盖开发、测试、运维、产品经理等职务。拥有一定的IT从业经验，至少1年以上的编程工作经验，对大模型技术感兴趣或有业务需求，希望通过课程提升自身在IT领域的竞争力。
• IT管理及技术研究领域人员：包括技术经理、技术负责人、CTO、架构师、研究员等角色。这些人员需要跟随技术发展趋势，主导技术创新，推动大模型技术在企业业务中的应用与改造。
• 传统AI从业人员：包括算法工程师、机器视觉工程师、深度学习工程师等。这些AI技术人才原先从事机器视觉、自然语言处理、推荐系统等领域工作，现需要快速补充大模型技术能力，获得大模型训练微调的实操技能，以适应新的技术发展趋势。
  

课程精彩瞬间

大模型核心原理与Prompt：掌握大语言模型的核心知识，了解行业应用与趋势；熟练Python编程，提升提示工程技能，为Al应用开发打下坚实基础。

RAG应用开发工程：掌握RAG应用开发全流程，理解前沿技术，提升商业化分析与优化能力，通过实战项目加深理解与应用。

Agent应用架构进阶实践：掌握大模型Agent技术的核心原理与实践应用，能够独立完成Agent系统的设计与开发，提升多智能体协同与复杂任务处理的能力，为AI产品的创新与优化提供有力支持。

模型微调与私有化大模型：掌握大模型微调与私有化部署技能，提升模型优化与部署能力，为大模型项目落地打下坚实基础。

顶尖师资，深耕AI大模型前沿技术

实战专家亲授，让你少走弯路

一对一学习规划，职业生涯指导

• 真实商业项目实训
• 大厂绿色直通车

人才库优秀学员参与真实商业项目实训

以商业交付标准作为学习标准，具备真实大模型项目实践操作经验可写入简历，支持项目背调

大厂绿色直通车，冲击行业高薪岗位

文中涉及到的完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】