你有没有这样的经历:给 AI 投喂了海量信息,期待它给出惊艳的答案,结果它却开始胡言乱语?或者你精心设计了一个 AI Agent,在简单任务上表现完美,一旦任务复杂起来就开始"失忆"?

说实话,我刚开始做 AI Agent 的时候也是这样。我花了大量时间优化提示词,调整措辞,结果发现——提示词工程已经不够用了。

今天,我要和你聊聊一个正在改变 AI 应用开发的新概念:上下文工程(Context Engineering)。这不是又一个炒作的新名词,而是 AI 应用开发正在经历的一场静悄悄的革命。

这篇文章会很长,但我保证——看完这一篇,你就能彻底搞懂什么是上下文工程,以及如何用它构建真正可靠的 AI Agent。

---

第一部分:基础概念篇

1.从便签到剧本:一场思维方式的转变

让我先问你一个问题:当你让 ChatGPT 帮你写一封邮件时,你在做什么?

你在进行提示词工程(Prompt Engineering)。你精心措辞,调整语气,期待一次性得到满意的结果。

但如果你要构建一个客服 AI Agent,它需要:

• 查询用户的订单历史
• 检索产品知识库
• 记住之前的对话内容
• 调用退款接口
• 在必要时升级给人工客服

这时候,单纯写好一个提示词还够吗?显然不够。你需要的是上下文工程。

提示词工程就像给 AI 贴一张便签,告诉它"帮我做这件事"。

而上下文工程则像是为 AI 编写一部详细的剧本,不仅包含台词(提示词),还有舞台布景(系统状态)、道具(工具)、剧情回顾(对话历史)、参考资料(检索信息)等等。

2.上下文工程到底是什么?

用最简单的话说:

上下文工程是构建动态系统的艺术,它在正确的时间,以正确的格式,为大语言模型提供正确的信息,从而让 LLM 能够可靠地完成复杂任务。

注意这里的关键词:

• 动态系统:不是一次性的,而是持续演化的
• 正确的时间:不是一股脑全塞进去,而是按需提供
• 正确的格式:结构化、易于理解
• 正确的信息:高质量、高相关性

3.为什么提示词工程不够用了?

想象你在和朋友聊天。简单的寒暄,几句话就够了。但如果你们要一起策划一场婚礼,你需要:

• • 记住之前讨论的预算
• • 查看场地的可用日期
• • 参考其他婚礼的案例
• • 协调多个供应商
• • 追踪任务清单

人类的大脑会自然地管理这些信息。但 AI 呢?它只有一个"上下文窗口"——就像一块有限的白板,你能写上去的东西是有限的。

这就引出了上下文工程的核心挑战:如何在有限的空间里,放入最有价值的信息?

4.上下文工程的七大组成部分

一个完整的上下文工程系统包含七个核心组件,就像乐高积木一样,它们组合在一起构成了 AI Agent 的"认知环境":

1. 系统提示词(System Prompt)

• 定义 AI 的角色和行为准则
• 就像给员工的岗位说明书
• 例:你是一个专业的客服代表,始终保持礼貌和耐心

2. 用户提示词(User Prompt)

• 用户当前的具体请求
• 就像客户提出的问题
• 例:我的订单什么时候能到?

3. 短期记忆(对话历史)

• 当前会话中的上下文
• 就像你记得刚才说了什么
• 例:用户刚才提到订单号是 #12345

4. 长期记忆(持久化知识)

• 跨会话的知识积累
• 就像你的个人档案
• 例:这个用户是 VIP 客户,偏好快速响应

5. 检索信息(RAG)

• 从外部知识库动态获取的信息
• 就像查阅百科全书
• 例:产品 X 的退货政策是 30 天内无理由退款

6. 可用工具(Tools)

• AI 可以调用的函数和 API
• 就像你的工具箱
• 例:查询订单状态、发起退款、发送邮件

7. 结构化输出(Output Schema)

• 定义 AI 输出的格式
• 就像填写标准表格
• 例:返回 JSON 格式的订单信息

5.一个直观的对比

让我用一个例子让你感受两者的区别:

提示词工程场景:

用户:"明天方便碰个头吗?"AI:"好的,明天我有空。你想约几点?"

简单,但缺乏智能。

上下文工程场景:

用户:"明天方便碰个头吗?"上下文包含:- 日历信息:明天全天会议已满- 历史邮件:这是重要合作伙伴- 联系人信息:对方通常偏好上午会议- 可用工具:发送日历邀请AI:"嗨 Jim!明天我这边排满了,从早到晚都是会议。周四上午怎么样?我已经发了个邀请,看看是否合适?"

看到区别了吗?后者不仅回答了问题,还主动解决了问题。

---

第二部分:核心原理篇

1.上下文腐蚀:AI 的"注意力危机"

现在我们要聊一个反直觉的现象:更多的上下文,不一定带来更好的结果。

这听起来很奇怪,对吧?就像你给学生更多的参考书,他们应该考得更好才对。但现实是:当信息过载时,人会分心;AI 也一样。

Anthropic 的研究团队发现了一个现象,叫做"上下文腐蚀"(Context Rot):

随着上下文窗口中 token 数量的增加,模型准确回忆信息的能力会下降。

为什么会这样?

想象你用一个手电筒照亮房间。房间越大,光线越分散,你看清细节的能力就越弱。AI 的"注意力机制"也是如此。

技术上讲,Transformer 架构让每个 token 都要"关注"其他所有 token,形成 n² 的关系网络。当 n 变大时:

• • 注意力被稀释
• • 计算负担增加
• • 远距离依赖关系变弱

更重要的是,LLM 在训练时见到的大多是短文本,对长文本的处理经验不足。就像你习惯了短跑,突然让你跑马拉松,肯定力不从心。

这意味着什么?

上下文不是越多越好,而是要精挑细选。每一个 token 都是宝贵的"注意力预算",我们要把它花在刀刃上。

这就是上下文工程的核心原则:

找到最小的、高信号的 token 集合,最大化期望结果的可能性。

2.上下文窗口:AI 的"工作记忆"

如果把 LLM 比作 CPU,那么上下文窗口就是 RAM(内存)。

人类的工作记忆大约能记住 7±2 个信息块。AI 的上下文窗口虽然能容纳更多 token(现在有些模型能到 100 万 token),但本质上也是有限的。

而且,就像人的工作记忆一样,塞得越满,效率越低。

这引出了上下文工程的第一个核心挑战:如何在有限的空间里,动态管理不断增长的信息?

3.上下文工程的价值

为什么我们要花这么大力气做上下文工程?因为它能带来实实在在的价值:

1. 降低 AI 失败率

说实话,大多数 Agent 失败不是模型的问题,而是上下文不全。

我之前做过一个代码生成 Agent,刚开始它经常生成不符合项目规范的代码。后来我把项目的代码规范、常用模式都加入上下文,失败率立刻下降了 70%。

2. 保证一致性

有了完整的上下文,AI 能遵循你的项目模式和规范,输出的内容更加一致。

3. 支持复杂特性

当上下文足够丰富时,AI 能处理多步骤实现,完成更复杂的任务。

4. 自我修正

通过在上下文中保留错误信息,AI 能从失败中学习,自动修正错误。

这听起来反直觉,但确实有效。我们后面会详细讲。

---

第三部分:方法论篇

1.上下文管理的四大策略

面对上下文腐蚀的问题,业界提出了系统性的解决方案。LangChain 总结了四类上下文管理的基本方法:

策略一:写入(Offload)上下文

核心思想:不要把所有东西都塞进上下文窗口。

与其将工具返回的全部原始信息都直接喂给 LLM,不如将其"卸载"到外部存储(如文件系统、数据库),然后只将一个轻量级的"指针"返回给模型。

实际应用:

比如你的 Agent 需要处理一个 100 页的 PDF 文档。你不需要把整个文档都放进上下文,而是:

1. 将文档保存到文件系统
2. 给 Agent 提供文件路径和简要摘要
3. 提供工具让 Agent 按需读取特定章节

核心组件:

• Scratchpad(草稿本):用于会话内的临时信息持久化
• Memory(记忆):用于跨会话的知识积累

我第一次用这个方法的时候,简直茅塞顿开。原来我的 Agent 每次都要处理几万个 token 的搜索结果,导致响应速度特别慢。改用写入策略后,只保留搜索结果的链接和摘要,速度提升了 5 倍。

策略二:选择(Retrieve)上下文

核心思想:不是所有信息都相关,只检索需要的。

这就是我们熟悉的 RAG(检索增强生成)。通过检索和过滤相关信息,来控制进入上下文的内容的数量和质量。

实际应用:

假设你在构建一个法律咨询 Agent:

1. 用户提问:“租房合同可以提前解除吗?”
2. 通过向量检索,从法律知识库中找到最相关的 3-5 条法规
3. 只将这些相关法规放入上下文
4. 而不是把整个法律数据库都塞进去

核心组件:

• 向量数据库:用于语义检索
• 重排序(Reranking):用 LLM 对检索结果进行相关性排序
• 元数据过滤:通过文件名、时间戳等元数据快速筛选

进阶技巧:即时检索(Just-in-Time Retrieval)

与其在推理前预先检索所有可能相关的数据,不如让 Agent 在运行时动态获取信息。

Claude Code 就是这么做的:它维护轻量级标识符(文件路径、查询语句、网页链接等),在需要时才动态加载数据。

这就像人类的认知方式——我们不会记住整本百科全书,而是建立索引系统,需要时再查阅。

策略三:压缩(Compress)上下文

核心思想:裁剪上下文内容,只保留完成任务所需的 tokens。

当对话进行到一定长度,上下文窗口快要满了,怎么办?压缩它!

实际应用:

方法 1:总结压缩

将长对话历史总结成简短的摘要:

原始对话(5000 tokens):用户:我想买一台笔记本电脑...AI:您的预算是多少...[中间 50 轮对话]压缩后(500 tokens):用户需求:预算 8000 元,主要用于视频剪辑,偏好轻薄本,已排除 MacBook(超预算)

方法 2:清除工具调用结果

一旦工具调用完成,原始结果就可以清除了,只保留关键信息。

比如:

• 原始:查询数据库返回 1000 行数据(10000 tokens)
• 保留:查询成功,找到 1000 条记录,已保存到 results.csv

方法 3:滑动窗口

只保留最近的 N 轮对话,丢弃更早的历史。

注意事项:

压缩要小心!过度压缩可能丢失关键信息。我的建议是:

1. 先最大化召回(确保不丢重要信息)
2. 再提高精确度(去除冗余内容)
3. 在复杂的 Agent 轨迹上仔细测试

策略四:隔离(Isolate)上下文

核心思想:如果一个任务的上下文压力太大,就拆分它。

这非常类似"分而治之"的思想。将任务分配给不同的 sub-agents 来完成各个子任务,每个 agent 的上下文都是独立的,更加清晰和聚焦。

实际应用:

假设你要构建一个研究 Agent,需要:

1. 搜索相关论文
2. 阅读和总结每篇论文
3. 综合所有论文得出结论

你可以这样设计:

• 主 Agent:负责整体规划和协调
• 搜索 Sub-Agent:专门负责搜索论文
• 阅读 Sub-Agent:专门负责阅读和总结单篇论文
• 综合 Sub-Agent:负责综合分析

每个 Sub-Agent 只需要关注自己的任务,上下文窗口保持清晰。主 Agent 只接收 Sub-Agent 返回的精炼摘要(通常 1000-2000 tokens),而不是完整的工作过程(可能数万 tokens)。

好处:

• 防止"上下文污染"
• 支持并行处理
• 错误隔离(一个 Agent 出错不影响其他)
• 更容易调试和维护

Anthropic 的多 Agent 研究系统就是这么做的,在复杂研究任务上比单 Agent 系统表现好得多。

---

第四部分:实践案例篇

案例一:Claude Code 的工程实践

Claude Code 是编码 Agent 的标杆,它在上下文工程方面有很多独到的实践。让我们看看它是怎么做的。

三层记忆架构

在长对话中,上下文管理面临的挑战:

• Token 限制导致信息丢失
• 传统压缩方法破坏上下文连续性
• 无法支持复杂多轮协作任务

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

第一层:工作记忆(Working Memory)

• 当前上下文窗口中的内容
• 最近的对话历史
• 当前正在处理的文件
• 就像人的短期记忆,容量小但访问快

第二层:会话记忆(Session Memory)

• 当前会话中的关键信息
• 通过总结压缩保存
• 包含:架构决策、未解决的 bug、实现细节
• 就像你做笔记,记录重要内容

第三层:长期记忆(Long-term Memory)

• 跨会话的持久化知识
• 用户偏好、项目规范、常用模式
• 存储在外部数据库
• 就像你的个人知识库

实现细节:

当上下文窗口快满时,Claude Code 会:

1. 将消息历史传给模型进行总结压缩
2. 保留最关键的信息:架构决策、未解决问题、实现细节
3. 丢弃冗余的工具输出和消息
4. 保留最近访问的 5 个文件
5. 用压缩后的上下文继续工作

用户感受不到任何中断,但 Agent 保持了连贯性。

混合检索策略

Claude Code 采用了前置基础内容 + 运行时工具检索的混合策略:

前置内容:

• CLAUDE.md 文件(项目说明)
• 项目结构概览
• 代码规范

运行时检索:

• 使用 glob 查找相关文件
• 使用 grep 搜索特定代码
• 使用 head/tail 查看文件片段
• 按需读取完整文件

这避免了过时数据的问题,并且模仿了人类程序员的工作方式——先了解项目整体,再深入具体细节。

保留错误信息

这是一个反直觉的设计:Claude Code 会保留失败的工具调用和错误信息。

为什么?因为看到错误会更新模型的"内部信念",减少重复错误。

举个例子:

第一次尝试:Agent: 运行 npm install结果: 错误 - Node.js 版本不兼容第二次尝试(有错误历史):Agent: 看到之前的错误,先检查 Node.js 版本结果: 发现需要升级,执行 nvm use 16成功!

如果抹去失败记录,Agent 可能会重复犯同样的错误。

案例二:Manus 的创新实践

Manus 是另一个优秀的 AI Agent 产品,它在上下文工程方面也有独到之处。

文件系统作为"终极上下文"

Manus 将文件系统视为 Agent 的"大脑":

• 所有数据都写入文件
• Agent 通过文件路径导航
• 使用简单工具(grep、glob)检索
• 无界且可扩展

好处:

• 避免上下文过载
• 降低成本(KV 缓存节省)
• 支持渐进式探索

我试了很多个 Agent 框架,Manus 的这个设计真的很聪明。它把复杂的上下文管理问题,转化成了简单的文件操作问题。

缓存设计

Manus 使用了智能缓存策略:

• 系统提示词缓存(不常变化)
• 工具定义缓存
• 最近文件内容缓存

这大大降低了推理成本,同时保持了响应速度。

案例三:实战技巧总结

基于 Claude Code 和 Manus 的实践,我总结了一些实战技巧:

技巧 1:设计高质量的系统提示词

避免两个极端:

1. 过度具体:把所有逻辑都硬编码进提示词

• 问题:脆弱、难维护

2. 过度模糊:只给高层次指导

• 问题:AI 不知道具体怎么做

找到平衡点:

• 足够具体,能指导行为
• 足够灵活,能应对变化
• 提供强启发式,而非硬规则

结构化组织:

使用 XML 标签或 Markdown 标题分隔不同部分:

<background_information>你是一个专业的代码审查 Agent...</background_information><instructions>1. 检查代码风格2. 识别潜在 bug3. 提出改进建议</instructions><tool_guidance>- 使用 read_file 读取代码- 使用 run_tests 执行测试</tool_guidance><output_format>返回 JSON 格式,包含:- issues: 问题列表- suggestions: 改进建议</output_format>

技巧 2:设计 Token 高效的工具

原则:

• 工具定义要清晰明确
• 避免功能重叠
• 返回信息要精炼

反例:

def search_database(query: str) -> str:    """搜索数据库"""    results = db.query(query)    return str(results)  # 返回 10000 tokens 的原始数据!

正例:

def search_database(query: str, limit: int = 10) -> dict:    """    搜索数据库并返回精炼结果        Args:        query: SQL 查询语句        limit: 返回结果数量上限        Returns:        {            "count": 总数,            "results": 前 N 条记录,            "file_path": 完整结果保存路径        }    """    results = db.query(query)        # 保存完整结果到文件    save_to_file(results, "results.json")        # 只返回摘要    return {        "count": len(results),        "results": results[:limit],        "file_path": "results.json"    }

技巧 3:提供高质量的示例

不要:

• 堆砌大量边缘案例
• 每个规则都给一个例子

要:

• 精选多样化的典型示例
• 每个示例都展示核心行为
• 例子要清晰、完整

记住:对 LLM 来说,示例就是"一图胜千言"的图。

技巧 4:动态调整上下文

根据任务复杂度动态调整策略:

简单任务:

• 直接检索
• 最小化上下文

中等任务:

• 混合策略(前置 + 即时检索)
• 适度压缩

复杂任务:

• 多 Agent 架构
• 结构化笔记
• 定期压缩

技巧 5:测试和迭代

测试清单:

• 在简单任务上是否工作?
• 在复杂任务上是否保持连贯?
• 上下文快满时是否优雅降级?
• 错误恢复是否有效?
• Token 使用是否高效?

迭代流程:

1. 从最简单的提示词开始
2. 在最好的模型上测试
3. 根据失败案例添加指导
4. 优化工具和上下文管理
5. 持续监控和改进

---

第五部分:未来展望篇

从上下文工程到环境工程

上下文工程还在快速演进。接下来可能的方向是:环境工程(Environment Engineering)。

什么意思?

现在的上下文工程,AI 是被动接收我们提供的信息。未来的环境工程,AI 会主动塑造它的工作环境。

就像人类会:

• 整理桌面
• 建立文件夹结构
• 写备忘录
• 设置提醒

未来的 AI Agent 也会:

• 自主组织知识库
• 创建自己的工具
• 维护自己的记忆系统
• 优化自己的工作流程

更智能的模型,更少的工程

随着模型能力提升,上下文工程的负担会减轻。

现在我们需要精心设计提示词、工具、检索策略。未来,更智能的模型可能只需要简单的指导,就能自己搞定这些。

但核心原则不会变:上下文是稀缺资源,需要精心管理。

多模态上下文

现在的上下文主要是文本。未来会包含:

• 图像
• 音频
• 视频
• 3D 模型
• 交互式界面

如何在多模态环境中管理上下文?这是新的挑战。

---

写到最后

从提示词工程到上下文工程,这不仅是技术的演进,更是思维方式的转变。

我们不再只是写一个完美的提示词,而是要构建一个完整的"认知环境",让 AI 能够像人类一样,在复杂任务中保持连贯、高效、可靠。

核心要点回顾:

1. 上下文工程是构建动态系统的艺术,在正确的时间提供正确的信息
2. 上下文腐蚀是真实存在的,更多不等于更好
3. 四大策略:写入、选择、压缩、隔离
4. 实践案例:Claude Code 和 Manus 的成功经验
5. 未来方向:从上下文工程到环境工程

我的建议:

如果你正在构建 AI Agent,现在就开始实践上下文工程:

1. 从简单开始,逐步优化
2. 把上下文当作稀缺资源
3. 测试、测试、再测试
4. 从失败中学习

记住:先完成,再完美。不要一开始就追求完美的上下文设计,而是快速迭代,持续改进。

速度就是生命线，在 AI 快速发展的时代,快速实践、快速学习,比等待完美方案更重要。

现在就去试试吧!把你学到的上下文工程技巧应用到你的项目中,你会发现 AI Agent 的能力会有质的飞跃。

---

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

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

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

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

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

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

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

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