超级详细的上下文工程指南

超级详细的上下文工程指南 🫡 超级详细的上下文工程指南 Modified December 8, 2025 实际应用: • 将文档保存到文件系统 • 给 Agent 提供文件路径和简要摘要 • 提供工具让 Agent 按需读取特定章节 核心组件: • Scratchpad (草稿本) • Memory (记忆) 策略二: 选择 (Retrieve) 上下文 核心思想: 不是所有信息都相关, 只检索需要的。 这就是我们熟悉的 RAG (检索增强生成)。通过检索和过滤相关信息, 来控制进入上下文的内容的数量和质量。 实际应用: 假设你在构建一个法律咨询 Agent: 通过向量检索, 从法律知识库中找到最相关的 3 5 条法规, 只将这些相关法规放入上下文。 核心组件: • 向量数据库 • 重排序 (Reranking) • 元数据过滤 进阶技巧: 即时检索 (Just in Time Retrieval) 策略三: 压缩 (Compress) 上下文 核心思想: 裁剪上下文内容, 只保留完成任务所需的 tokens。 当对话进行到一定长度, 上下文窗口快要满了, 怎么办? 压缩它! 实际应用: • 方法 1: 总结压缩 (将长对话历史总结成摘要) • 方法 2: 清除工具调用结果 (只保留关键信息) • 方法 3: 滑动窗口 (只保留最近 N 轮对话) 注意事项: • 先最大化召回 (确保不丢重要信息) • 再提高精确度 (去除冗余内容) • 在复杂的 Agent 轨迹上仔细测试 策略四: 隔离 (Isolate) 上下文 核心思想: 如果一个任务的上下文压力太大, 就拆分它。 这非常类似"分而治之"的思想。将任务分配给不同的 sub agents 来完成各个子任务, 每个 agent 的上下文都是独立的。 实际应用: 构建一个研究 Agent, 可拆分为: 搜索 Sub Agent、阅读 Sub Agent 和综合 Sub Agent。 好处: • 防止"上下文污染" • 支持并行处理 • 错误隔离 • 更容易调试和维护 第四部分: 实践案例篇 案例一: Claude Code 的工程实践 Claude Code 是编码 Agent 的标杆, 它在上下文工程方面有很多独到的实践。 三层记忆架构 在长对话中, 上下文管理面临的挑战: • Token 限制导致信息丢失 • 传统压缩方法破坏上下文连续性 • 无法支持复杂多轮协作任务 Claude Code 的解决方案是构建三层记忆系统: • 第一层: 工作记忆 (Working Memory): 当前上下文窗口中的内容 (最近对话、当前文件)。 • 第二层: 会话记忆 (Session Memory): 当前会话中的关键信息, 通过总结压缩保存 (架构决策、未解决的 bug)。 • 第三层: 长期记忆 (Long term Memory): 跨会话的持久化知识 (用户偏好、项目规范)。 混合检索策略 Claude Code 采用了前置基础内容 + 运行时工具检索的混合策略: • 前置内容: (项目说明)、项目结构概览、代码规范。 • 运行时检索: 使用 查找文件、 搜索代码、 查看片段, 并按需读取完整文件。 保留错误信息 这是一个反直觉的设计: Claude Code 会保留失败的工具调用和错误信息。 为什么? 因为看到错误会更新模型的"内部信念", 减少重复错误。 案例二: Manus 的创新实践 Manus 是另一个优秀的 AI Agent 产品, 它在上下文工程方面也有独到之处。 文件系统作为"终极上下文" Manus 将文件系统视为 Agent 的"大脑": • 所有数据都写入文件 • Agent 通过文件路径导航 • 使用简单工具 (grep、glob) 检索 • 无界且可扩展 好处: • 避免上下文过载 • 降低成本 (KV 缓存节省) • 支持渐进式探索 缓存设计 Manus 使用了智能缓存策略, 大大降低了推理成本, 同时保持了响应速度: • 系统提示词缓存 (不常变化) • 工具定义缓存 • 最近文件内容缓存 第五部分: 未来展望篇 从上下文工程到环境工程 上下文工程还在快速演进。接下来可能的方向是: 环境工程 (Environment Engineering)。 现在的上下文工程, AI 是被动接收我们提供的信息。未来的环境工程, AI 会主动塑造它的工作环境。 就像人类会: • 整理桌面 • 建立文件夹结构 • 写备忘录 • 设置提醒 未来的 AI Agent 也会: • 自主组织知识库 • 创建自己的工具 • 维护自己的记忆系统 • 优化自己的工作流程 更智能的模型, 更少的工程 随着模型能力提升, 上下文工程的负担会减轻。 现在我们需要精心设计提示词、工具、检索策略。未来, 更智能的模型可能只需要简单的指导, 就能自己搞定这些。 但核心原则不会变: 上下文是稀缺资源, 需要精心管理。 多模态上下文 现在的上下文主要是文本。未来会包含: • 图像 • 音频 • 视频 • 3D 模型 • 交互式界面 我的建议: 如果你正在构建 AI Agent, 现在就开始实践上下文工程: • 从简单开始, 逐步优化 • 把上下文当作稀缺资源 • 测试、测试、再测试 • 从失败中学习 "记住: 先完成, 再完美。不要一开始就追求完美的上下文设计, 而是快速迭代, 持续改进。" 速度就是生命线, 在 AI 快速发展的时代, 快速实践、快速学习, 比等待完美方案更重要。 You don't have permission to access this synced block. Please log in and try again. Log In 知识库动态 实际应用: • 将文档保存到文件系统 • 给 Agent 提供文件路径和简要摘要 • 提供工具让 Agent 按需读取特定章节 核心组件: • Scratchpad (草稿本) • Memory (记忆) 策略二: 选择 (Retrieve) 上下文 核心思想: 不是所有信息都相关, 只检索需要的。 这就是我们熟悉的 RAG (检索增强生成)。通过检索和过滤相关信息, 来控制进入上下文的内容的数量和质量。 实际应用: 假设你在构建一个法律咨询 Agent: 通过向量检索, 从法律知识库中找到最相关的 3 5 条法规, 只将这些相关法规放入上下文。 核心组件: • 向量数据库 • 重排序 (Reranking) • 元数据过滤 进阶技巧: 即时检索 (Just in Time Retrieval) 策略三: 压缩 (Compress) 上下文 核心思想: 裁剪上下文内容, 只保留完成任务所需的 tokens。 当对话进行到一定长度, 上下文窗口快要满了, 怎么办? 压缩它! 实际应用: • 方法 1: 总结压缩 (将长对话历史总结成摘要) • 方法 2: 清除工具调用结果 (只保留关键信息) • 方法 3: 滑动窗口 (只保留最近 N 轮对话) 注意事项: • 先最大化召回 (确保不丢重要信息) • 再提高精确度 (去除冗余内容) • 在复杂的 Agent 轨迹上仔细测试 策略四: 隔离 (Isolate) 上下文 核心思想: 如果一个任务的上下文压力太大, 就拆分它。 这非常类似"分而治之"的思想。将任务分配给不同的 sub agents 来完成各个子任务, 每个 agent 的上下文都是独立的。 实际应用: 构建一个研究 Agent, 可拆分为: 搜索 Sub Agent、阅读 Sub Agent 和综合 Sub Agent。 好处: • 防止"上下文污染" • 支持并行处理 • 错误隔离 • 更容易调试和维护 第四部分: 实践案例篇 案例一: Claude Code 的工程实践 Claude Code 是编码 Agent 的标杆, 它在上下文工程方面有很多独到的实践。 三层记忆架构 在长对话中, 上下文管理面临的挑战: • Token 限制导致信息丢失 • 传统压缩方法破坏上下文连续性 • 无法支持复杂多轮协作任务 Claude Code 的解决方案是构建三层记忆系统: • 第一层: 工作记忆 (Working Memory): 当前上下文窗口中的内容 (最近对话、当前文件)。 • 第二层: 会话记忆 (Session Memory): 当前会话中的关键信息, 通过总结压缩保存 (架构决策、未解决的 bug)。 • 第三层: 长期记忆 (Long term Memory): 跨会话的持久化知识 (用户偏好、项目规范)。 混合检索策略 Claude Code 采用了前置基础内容 + 运行时工具检索的混合策略: • 前置内容: (项目说明)、项目结构概览、代码规范。 • 运行时检索: 使用 查找文件、 搜索代码、 查看片段, 并按需读取完整文件。 保留错误信息 这是一个反直觉的设计: Claude Code 会保留失败的工具调用和错误信息。 为什么? 因为看到错误会更新模型的"内部信念", 减少重复错误。 案例二: Manus 的创新实践 Manus 是另一个优秀的 AI Agent 产品, 它在上下文工程方面也有独到之处。 文件系统作为"终极上下文" Manus 将文件系统视为 Agent 的"大脑": • 所有数据都写入文件 • Agent 通过文件路径导航 • 使用简单工具 (grep、glob) 检索 • 无界且可扩展 好处: • 避免上下文过载 • 降低成本 (KV 缓存节省) • 支持渐进式探索 缓存设计 Manus 使用了智能缓存策略, 大大降低了推理成本, 同时保持了响应速度: • 系统提示词缓存 (不常变化) • 工具定义缓存 • 最近文件内容缓存 第五部分: 未来展望篇 从上下文工程到环境工程 上下文工程还在快速演进。接下来可能的方向是: 环境工程 (Environment Engineering)。 现在的上下文工程, AI 是被动接收我们提供的信息。未来的环境工程, AI 会主动塑造它的工作环境。 就像人类会: • 整理桌面 • 建立文件夹结构 • 写备忘录 • 设置提醒 未来的 AI Agent 也会: • 自主组织知识库 • 创建自己的工具 • 维护自己的记忆系统 • 优化自己的工作流程 更智能的模型, 更少的工程 随着模型能力提升, 上下文工程的负担会减轻。 现在我们需要精心设计提示词、工具、检索策略。未来, 更智能的模型可能只需要简单的指导, 就能自己搞定这些。 但核心原则不会变: 上下文是稀缺资源, 需要精心管理。 多模态上下文 现在的上下文主要是文本。未来会包含: • 图像 • 音频 • 视频 • 3D 模型 • 交互式界面 我的建议: 如果你正在构建 AI Agent, 现在就开始实践上下文工程: • 从简单开始, 逐步优化 • 把上下文当作稀缺资源 • 测试、测试、再测试 • 从失败中学习 "记住: 先完成, 再完美。不要一开始就追求完美的上下文设计, 而是快速迭代, 持续改进。" "记住: 先完成, 再完美。不要一开始就追求完美的上下文设计, 而是快速迭代, 持续改进。" 速度就是生命线, 在 AI 快速发展的时代, 快速实践、快速学习, 比等待完美方案更重要。 You don't have permission to access this synced block. Please log in and try again. Log In 知识库动态 从提示词工程到动态 AI 系统的构建艺术 从提示词工程到动态 AI 系统的构建艺术 第一部分: 基础概念篇 从便签到剧本: 一场思维方式的转变 让我先问你一个问题: 当你让 ChatGPT 帮你写一封邮件时, 你在做什么? 你在进行提示词工程 (Prompt Engineering)。你精心措辞, 调整语气, 期待一次性得到满意的结果。 但如果你要构建一个客服 AI Agent, 它需要: 1. 查询用户的订单历史 2. 检索产品知识库 3. 记住之前的对话内容 4. 调用退款接口 5. 在必要时升级给人工客服 这时候, 单纯写好一个提示词还够吗? 显然不够。你需要的是上下文工程。 上下文工程到底是什么? 用最简单的话说: "上下文工程是构建动态系统的艺术, 它在正确的时间, 以正确的格式, 为大语言模型提供正确的信息, 从而让 LLM 能够可靠地完成复杂任务。" "上下文工程是构建动态系统的艺术, 它在正确的时间, 以正确的格式, 为大语言模型提供正确的信息, 从而让 LLM 能够可靠地完成复杂任务。" 注意这里的关键词: • 动态系统: 不是一次性的, 而是持续演化的 • 正确的时间: 不是一股脑全塞进去, 而是按需提供 • 正确的格式: 结构化、易于理解 • 正确的信息: 高质量、高相关性 为什么提示词工程不够用了? 想象你在和朋友聊天。简单的寒暄, 几句话就够了。但如果你们要一起策划一场婚礼, 你需要: 1. 记住之前讨论的预算 2. 查看场地的可用日期 3. 参考其他婚礼的案例 4. 协调多个供应商 5. 追踪任务清单 人类的大脑会自然地管理这些信息。但 AI 呢? 它只有一个"上下文窗口"——就像一块有限的白板, 你能写上去的东西是有限的。 这就引出了上下文工程的核心挑战: 如何在有限的空间里, 放入最有价值的信息? 上下文工程的七大组成部分 一个完整的上下文工程系统包含七个核心组合, 在一起构成了 AI Agent 的"认知环境": 1. 系统提示词 (System Prompt): 定义 AI 的角色和行为准则。就像给员工的岗位说明书。 2. 用户提示词 (User Prompt): 用户当前的具体请求。就像客户提出的问题。 3. 短期记忆 (对话历史): 当前会话中的上下文。就像你记得刚才说了什么。 4. 长期记忆 (持久化知识): 跨会话的知识积累。就像你的个人档案。 5. 检索信息 (RAG): 从外部知识库动态获取的信息。就像查阅百科全书。 6. 可用工具 (Tools): AI 可以调用的函数和 API。就像你的工具箱。 7. 结构化输出 (Output Schema): 定义 AI 输出的格式。就像填写标准表格。 一个直观的对比 提示词工程场景: 🔗 用户: "明天方便碰个头吗?" AI: "好的, 明天我有空。你想约几点?" 用户: "明天方便碰个头吗?" AI: "好的, 明天我有空。你想约几点?" 简单, 但缺乏智能。 上下文工程场景: 🔗 用户: "明天方便碰个头吗?" 上下文包含: 日历信息: 明天全天会议已满 历史邮件: 这是重要合作伙伴 联系人信息: 对方通常偏好上午会议 可用工具: 发送日历邀请 AI: "嗨 Jim! 明天我这边排满了, 从早到晚都是会议。 周四上午怎么样? 我已经发了个邀请, 看看是否合适?" 用户: "明天方便碰个头吗?" 上下文包含: 日历信息: 明天全天会议已满 历史邮件: 这是重要合作伙伴 联系人信息: 对方通常偏好上午会议 可用工具: 发送日历邀请 AI: "嗨 Jim! 明天我这边排满了, 从早到晚都是会议。 周四上午怎么样? 我已经发了个邀请, 看看是否合适?" 看到区别了吗? 后者不仅回答了问题, 还主动解决了问题。 第二部分: 核心原理篇 上下文腐蚀: AI 的"注意力危机" 现在我们要聊一个反直觉的现象: 更多的上下文, 不一定带来更好的结果。 这听起来很奇怪, 对吧? 就像你给学生更多的参考书, 他们应该考得更好才对。但现实是: 当信息过载时, 人会分心; AI 也一样。 Anthropic 的研究团队发现了一个现象, 叫做"上下文腐蚀" (Context Rot): 随着上下文窗口中 token 数量的增加, 模型准确回忆信息的能力会下降。 Anthropic 的研究团队发现了一个现象, 叫做"上下文腐蚀" (Context Rot): 随着上下文窗口中 token 数量的增加, 模型准确回忆信息的能力会下降。 为什么会这样? 想象你用一个手电筒照亮房间。房间越大, 光线越分散, 你看清细节的能力就越弱。AI 的"注意力机制"也是如此。 技术上讲, Transformer 架构让每个 token 都要"关注"其他所有 token, 形成 n 2 的关系网络。当 n 变大时: 1. 注意力被稀释 2. 计算负担增加 3. 远距离依赖关系变弱 更重要的是, LLM 在训练时见到的大多是短文本, 对长文本的处理经验不足。就像你习惯了短跑, 突然让你跑马拉松, 肯定力不从心。 这意味着什么? 上下文不是越多越好, 而是要精挑细选。每一个 token 都是宝贵的"注意力预算", 我们要把它花在刀刃上。 这就是上下文工程的核心原则: 找到最小的、高信号的 token 集合, 最大化期望结果的可能性。 找到最小的、高信号的 token 集合, 最大化期望结果的可能性。 上下文窗口: AI 的"工作记忆" 如果把 LLM 比作 CPU, 那么上下文窗口就是 RAM (内存)。 人类的工作记忆大约能记住 7±2 个信息块。AI 的上下文窗口虽然能容纳更多 token (现在有些模型能到 100 万 token), 但本质上也是有限的。 而且, 就像人的工作记忆一样, 塞得越满, 效率越低。 这引出了上下文工程的第一个核心挑战: 如何在有限的空间里, 动态管理不断增长的信息? 上下文工程的价值 为什么我们要花这么大力气做上下文工程? 因为它能带来实实在在的价值: • 降低 AI 失败率: 说实话, 大多数 Agent 失败不是模型的问题, 而是上下文不全。 • 保证一致性: 有了完整的上下文, AI 能遵循你的项目模式和规范, 输出的内容更加一致。 • 支持复杂特性: 当上下文足够丰富时, AI 能处理多步骤实现, 完成更复杂的任务。 • 自我修正: 通过在上下文中保留错误信息, AI 能从失败中学习, 自动修正错误。 第三部分: 方法论篇 上下文管理的四大策略 面对上下文腐蚀的问题, 业界提出了系统性的解决方案。LangChain 总结了四类上下文管理的基本方法: 策略一: 写入 (Offload) 上下文 核心思想: 不要把所有东西都塞进上下文窗口。 与其将工具返回的全部原始信息都直接喂给 LLM, 不如将其"卸载"到外部存储 (如文件系统、数据库), 然后只将一个轻量级的"指针"返回给模型。