我是南国无炊烟正在学习 Agent 开发。这篇文章记录我对 Context Engineering 的理解与反思也希望给同样在学习 Agent 的读者一点参考。摘要开发一款 Agent 需要很多部件但 Context Engineering 是至关重要的一环。大模型本身更像负责推理与生成的“大脑”它缺少个性化的长期记忆、外部知识接入和行动能力。Agent 要做的是让大模型变成一个更完整的系统。而上下文工程解决的就是在每一步让模型看到合适的信息。它不只是历史对话也不只是 Prompt而是包括系统提示词、历史信息、知识与数据、工具相关信息等在内的整体设计。本文尝试回答三个问题为什么 Agent 需要上下文工程上下文到底包含哪些内容有哪些常见的上下文处理方法目录为什么 Agent 需要上下文工程上下文到底包含什么上下文工程要解决的核心问题常见方法上下文工程 vs 提示词工程一个具体例子旅行规划 Agent实践 Checklist总结1. 为什么 Agent 需要上下文工程1.1 大模型是“大脑”但不是完整 Agent大模型对输入内容的理解能力固然重要但如果没有高质量的输入内容就无法精准完成用户需求。如果没有上下文大模型只能根据本轮对话内容回答它不记得刚才说了什么它无法调用外部资源它无法形成长期记忆它也无法知道自己执行任务到了哪一步。可以把大模型看作负责推理与生成的“大脑”。它本身缺少可靠的长期个性化记忆、外部知识接入和行动能力。Agent 负责让大模型变成一个更完整的系统而上下文工程就是把这个系统所需要的信息在合适的时候喂给模型。1.2 没有上下文会发生什么在一次任务会话中我们通常会先提出根本需求然后根据 AI 的结果不断改善和迭代。但随着对话轮次增多上下文窗口是有限的。如果不处理历史对话只是一直把前面的会话和文件全部带上那么时间较久远的对话可能被挤出上下文窗口Agent 会逐渐忘记最初的目标输出结果可能偏离用户真实需求。更麻烦的是即便每次都能携带全部对话记录和文件也不一定是好事。内容太多模型可能抓不住主次导致逻辑混乱最终输出和预期大相径庭。1.3 一个常见误区很多人会简单认为上下文就是历史对话或者用户给 Agent 提供的 Prompt。其实不是。上下文的范围要宽得多至少包括系统提示词历史信息知识与数据工具相关信息。这也是为什么说上下文工程包括提示词工程但提示词工程不等于上下文工程。2. 上下文到底包含什么类型具体内容作用常见处理方式系统提示词System Prompt、输出格式要求、特定 Agent 和任务描述定义角色、边界和输出规范模板化、版本管理、按任务注入历史信息用户对话、文件资料、反馈记录保持对话连续性和需求一致性滑动窗口、摘要、压缩知识与数据RAG 知识库、持久化记忆、网络爬虫数据、Scratchpad提供外部知识和中间状态按需检索、提炼、结构化存储工具相关信息工具描述、参数 schema、调用结果支持 Agent 筛选和调用工具工具筛选、结果压缩、结构化记录2.1 系统提示词这里的系统提示词不仅包括 System Prompt还包括对输出格式的要求对特定 Agent 和特定任务的描述一些安全边界和行为约束。这些通常在 Agent 开发阶段就写在代码里了。2.2 历史信息历史信息很好理解就是用户提供的对话 Prompt以及其他文件资料。它让 Agent 知道用户之前说过什么任务是如何一步步演变的哪些要求已经被确认哪些已经被否定。2.3 知识与数据很多 Agent 在执行专业任务时需要调用 RAG 知识库或者一些持久化记忆、网络爬虫爬取的数据。此外还有一个容易被忽略的部分Scratchpad也就是草稿区。Scratchpad 一般针对多轮 Agent 迭代才存在。每一轮 Agent 循环中Agent 会把调用工具的记录、思考过程、输出结果等信息记录在上面用来指导下一次行动。2.4 工具相关信息大部分 Agent 执行任务时都要调用工具。模型需要读取工具描述才能判断该不该调用、调用哪个工具、参数怎么填。因此工具描述、工具参数、工具调用结果也都是上下文工程需要管理的内容。3. 上下文工程要解决的核心问题总的来说上下文工程是为了解决下面几个重要问题遗忘上下文窗口有限超出范围的内容不会被模型直接看到。让大模型准确完成任务减少噪声这里的“准确”有个性化含义。比如你问大模型“今天晚上推荐吃什么”它并不知道你是哪里人、口味如何只能给机械化回答。有了上下文它才能知道用户偏好甚至调用工具查看外部菜单。提取长期记忆比如形成新的用户偏好。如果任务结束后就把本次会话全部丢弃就无法形成记忆。多轮会话的状态管理Agent 往往会把任务拆成很多步骤。从上下文中提取任务状态非常重要方便 Agent 知道自己执行到哪里了以及之前完成的状态。节省成本携带大量上下文意味着消耗大量 Token。Token 消耗会直接影响成本、延迟和可处理的上下文长度。4. 常见方法最简单的方法是滑动窗口但实际开发中我们还需要一些更有效的策略。对于外部数据、知识库和记忆等信息需要按需筛选、提炼然后加载。下面重点看对话历史和上下文的处理方式。4.1 滑动窗口滑动窗口是最直观的方法只保留最近若干轮对话。它实现简单但问题也明显早期关键信息可能被丢掉用户最初的目标可能被遗忘任务状态可能断裂。所以滑动窗口通常需要和其他方法配合使用。4.2 压缩与摘要压缩与摘要很好理解。可以设置两个阈值例如最近 N 条消息完整保留第 N 到 M 条消息压缩和摘要保留大部分信息超过 M 条消息极简压缩只留下最关键的信息。压缩通常由大模型处理。这虽然需要额外的 Token但在大量上下文中通常还是能降低总 Token 消耗和延迟。不过要注意压缩本身也有成本而且可能丢失细节甚至引入模型幻觉。因此关键信息最好不要只靠自然语言摘要而应该结构化存储。一般情况下压缩摘要和滑动窗口会配合使用。这样既可以保留关键信息又能减少上下文窗口的负担。压缩也可以不按时间远近进行。比如每次对话都让大模型评估重要性然后决定是否压缩。但这样做会耗费额外 Token需要权衡。4.3 筛选决定“哪些该留下”筛选可以看作摘要的补充而不是简单替代。简单压缩摘要有一个严重问题Agent 在上下文增加的过程中很可能会忘记最初想做什么。如果最开始的目的被压缩成一句非常简短的话关键信息就可能丢失。因此对于一些目的性、关键性的信息重要性会很高。在摘要和遗忘过程中就要特殊处理。一些需要长期记忆的地方还需要提炼后录入数据库。筛选可以按这些维度进行相关性重要性时效性任务状态用户偏好。4.4 长期记忆与结构化存储记忆的内容可能需要完整记录也可能需要摘要记录还可能结构化存储方便查找。长期记忆可以包括用户偏好喜欢什么、讨厌什么任务状态做到哪一步、下一步是什么决策记录为什么选 A 不选 B实体信息人名、项目名、时间、地点。这些内容适合结构化存储而不是全部塞进上下文。4.5 状态管理Agent 完成任务时往往会拆解成多个步骤。上下文工程需要帮助 Agent 知道当前任务是什么已经完成了哪些步骤下一步应该做什么哪些工具已经调用过哪些结果已经确认。这部分可以放在 Scratchpad、任务状态表或结构化记忆中。4.6 工具描述与工具结果工具描述太多会占用大量上下文工具调用结果太长也会污染上下文。常见处理方式只加载当前任务相关的工具对工具结果进行截取、摘要或结构化把关键结果写入 Scratchpad避免把完整原始数据反复塞进上下文。4.7 分层处理总之分层处理是非常高效的关键约束完整保留一般历史摘要压缩长期记忆结构化存储工具结果按需提炼任务状态单独维护。5. 上下文工程 vs 提示词工程提示词工程主要关注“怎么问”即指令、示例、输出格式。上下文工程关注的是“模型每一步能看到什么”包括提示词历史对话长期记忆RAG 知识工具结果任务状态。所以提示词工程是上下文工程的一部分但上下文工程范围更大。6. 一个具体例子旅行规划 Agent假设用户第一轮说我想去云南玩 5 天预算 5000 左右不喜欢早起。如果多轮对话后预算和目的地被摘要丢掉Agent 就可能推荐高价方案或者安排很多早起行程。上下文工程要做的是提取关键约束预算 5000、目的地云南、5 天、不喜欢早起结构化存储预算、目的地、日期、偏好每轮重新注入关键约束用工具查机票、天气、酒店用 Scratchpad 记录已查航班、待定酒店、用户确认信息在上下文变长时优先保留这些关键约束。这样Agent 才不容易在长对话中“忘记初心”。7. 实践 Checklist开发 Agent 时可以用下面这份清单检查上下文工程System Prompt 是否清晰输出格式和任务边界是否明确历史对话是否压缩关键约束是否结构化保存长期记忆是否提取用户偏好是否记录任务状态是否维护工具描述是否准确、精简工具结果是否压缩或结构化Scratchpad 是否记录关键中间状态Token 成本是否可控长对话中最初目标是否仍能被模型看到8. 总结大模型是 Agent 的“大脑”但只有大脑还不够。Agent 要真正完成任务还需要记忆、知识、工具和状态管理。上下文工程的核心是在有限的上下文窗口里放入最合适的信息不让模型遗忘关键目标不让模型被噪声干扰能提取长期记忆能管理多轮任务状态能控制 Token 成本。提示词工程解决“怎么问”上下文工程解决“模型每一步看到什么”。后者范围更大也更能决定一个 Agent 的上限。写在最后以上是我学习 Agent 开发过程中对 Context Engineering 的记录与反思。文中很多地方还在不断理解和完善欢迎交流指正。