掌握上下文工程：让你的 AI Agent 既“看得全”又“看得准”，新手程序员必备

本文深入探讨了 AI Agent 的上下文工程阐述了 Agent 在每次决策时如何向大模型传递信息。通过 KV Cache、提示词工程、Skills、Agent 状态栏和上下文压缩等技术优化 Agent 在长任务中的表现平衡信息完整性、准确性和效率。文章强调上下文质量对 Agent 能力的关键影响并提供了实用的工程原则和设计方法帮助程序员构建更高效的 AI Agent 系统。什么是上下文工程 上下文就是模型在当前这一次决策时能够看到的全部信息。它不仅包括用户刚刚说的话还包括预先写好的行为规则(系统指令)外部功能说明(工具描述)之前聊了什么(对话历史)…因此上下文工程可以定义为上下文工程就是系统性地设计、组织、更新和压缩这些信息让模型在每一个决策点都能拿到“足够且正确”的信息。1.1 为什么上下文是决定 Agent 能力上限的关键 可以把一个大模型想象成一个刚刚加入公司的天才新员工。他的编程能力很强、逻辑能力很好、知识面也非常广。但是你没有告诉他公司代码库是怎么组织的哪些模块负责什么Git 分支规范是什么哪些 API 可以调用哪些操作需要审批项目历史上做过什么架构决策。然后你直接对他说“帮我修一下这个 Bug。”即使这个员工再聪明也很难把事情做好。AI Agent 面临的就是完全相同的问题。所以模型能力决定 Agent 的基础智力而上下文质量决定这些智力能发挥出来多少。一个中等能力的模型如果拥有完整、清晰、结构化的上下文很多时候反而可能比一个更强的模型在信息不足的情况下表现得更好。这也是为什么上下文工程不是简单地“往 Prompt 里多塞一些信息”而是在构建一套高效的信息供给系统。Agent 每次给大模型看了什么要真正理解上下文工程首先必须要明确大模型 API 本身通常是无状态的。 也就是说大模型并不会天然“记得”上一轮发生了什么。每一次调用模型时Agent 框架都需要重新把模型需要的信息发送过去。以 OpenAI 的 Chat Completions API 为例大模型 API 中最核心的是一个 messages 列表其中通常包含四种角色System系统消息User用户消息Assistant模型之前的回复Tool工具执行结果。2.1 System系统消息由开发者提供。主要负责定义Agent 是谁应该遵守什么规则什么事情可以做什么事情不能做遇到不同情况时应该按照什么流程处理。模型将其视为最高优先级的指令。整个对话过程中通常只有一条,放在消息列表的最前面。2.2 User用户消息也就是用户给 Agent 的输入。例如帮我查一下今天北京的天气。或者帮我分析这个代码仓库为什么编译失败。2.3 Assistant模型之前的回复就是模型之前的回复, 包括文本回复和工具调用请求。这样模型下一轮才能知道“我刚才已经做过什么了。”2.4 Tool工具执行结果模型只是提出工具调用请求真正执行工具的是 Agent 框架。例如模型决定调用天气工具 city BeijingAgent 框架执行后得到北京晴23℃这个结果会再次加入上下文然后重新交给模型判断下一步做什么。除此之外还有一个非常重要的部分工具定义Tool Definitions 作为请求的独立字段(而非消息),告诉模型有哪些工具可以使用、每个工具接受什么参数。例如它告诉模型有哪些工具每个工具能干什么参数是什么参数应该怎么填写。在第一章中我们还给了上下文的另一个定义上下文 静态前缀 动态轨迹因此Agent 每次调用模型时, 上下文的完整构成如下图所示上半部分(System Prompt Tool Definitions)在整个对话过程中保持不变,下半部分(对话历史)随着交互的进行不断增长。现在就有个新的问题模型处理很长的上下文是非常昂贵的。随着下半部分不断增长假设当前上下文已经有几万个 Token如果每生成一个新的 Token都把前面的几万个 Token 从头计算一遍Agent 的速度会越来越慢成本也会越来越高。那么该如何进行优化于是就需要采用KV Cache 优化、上下文压缩等技术。KV Cache 友好的上下文设计KV Cache 可以简单理解成模型把已经读过的内容产生的中间计算结果保存下来下次继续往后读时只需要计算新增 token 的部分。因此如果连续两次请求的前面部分完全一致System PromptTool Definitions, 那么前面的计算就可以直接复用。这一部分涉及到Transformer的基础. 用一个具体例子来说明。假设模型正在处理“北京的天气怎么样”这句话,当读到“怎么样”时, 模型需要决定:前面哪些词对理解“怎么样”最重要?计算过程分三步:首先,“怎么样”生成自己的 Query 向量(一串数字,代表“我在找什么”);然后, Query 与每个词的 Key 做点积(可以理解为“匹配度打分”——两组数字逐位相乘再加起来,结果越大说明越匹配),得到注意力权重;最后, 用这些权重对所有词的 Value 加权求和——打分高的词贡献多,打分低的词贡献少.大致理解为: 每生成一个新词,它的 Query 都要与前面所有词的 Key 做匹配,再用所有词的 Value 加权求和。如果每次都从头计算所有 K 和 V,计算量会随上下文长度不断增长。KV Cache 就是把已算过的 K 和 V 缓存起来,让新词直接复用假设开发者为了告诉 Agent 当前时间把下面这句话放进 System PromptCurrent time: 10:30:01. 下一秒Current time: 10:30:02. 看起来只改了一个数字。但对于缓存而言前面的 Token 已经不一样了。从发生变化的位置开始后面的缓存就无法继续复用。因此一个看起来非常不起眼的动态时间戳都可能让 Agent 的延迟和推理成本明显增加。所以第二章给出了三个非常重要的工程原则原则一System Prompt 和核心工具定义尽量保持稳定, 确定之后不要频繁修改。甚至工具定义的排列顺序也最好保持稳定。原则二动态信息尽量往上下文末尾追加. 例如当前时间当前工作目录用户当前状态工具已经调用几次当前任务进度。不要反复修改前面的 System Prompt而应该追加到轨迹后面。原则三尽量使用模型的标准 API 消息格式, 不要自行拼接消息.因此可以总结为一句话静态信息放前面并保持稳定动态信息不断往后追加。这既有利于模型理解也有利于 KV Cache。提示工程System Prompt 应该怎么写上下文结构设计好了下一个问题就是里面到底应该写什么这里就进入了大家比较熟悉的提示工程Prompt Engineering。在 Agent 系统里提示工程最核心的对象就是 System Prompt, 定义了 Agent 的身份、行为规则、约束条件和工作流程。系统提示词的设计有一个实用的检验标准: 如果一个聪明的新员工读完你的系统提示词还不知道该怎么做, Agent 也一样不知道。下面从几个维度讨论如何优化系统提示词:4.1 系统提示词的语气和风格语气和风格的设计是提示工程中最容易被忽视,却又深刻影响用户体验的部分。例如, 可以要求“You MUST answer concisely with fewer than 4 lines”(你必须简洁地回答,不超过 4 行)等。这种设计避免了 Agent 陷入冗长的自我辩护, 但过度使用会导致效果被稀释,应保留给真正关键的约束4.2 系统提示词的结构化格式现代大语言模型对结构化输入展现出显著的敏感性, 这源于训练数据中包含大量的结构化内容。XML 和 Markdown配合使用, 可以形成一种双层结构: XML负责机器可解析的精确语义, Markdown负责人机共读的组织逻辑。比如一个系统提示词同时用了两者:# 工具使用规范 ## 文件操作 file_operation - 读取文件前必须先检查路径是否存在 - 写入文件前必须先备份 /file_operation ## 网络请求 network_request - 超时时间设置为 30 秒 - 失败后最多重试 3 次 /network_request两者配合, 人读着清晰, 模型理解也准确。4.3 系统提示词的设计流程不要只堆规则要设计流程.假设给 Agent 写了 100 条规则不能做 A遇到 B 要做 C如果 D 则不能 E出现 F 应该 G…规则越来越多以后模型会遇到一个问题多条规则同时适用时我到底应该先遵守哪一条所以相比“规则堆砌”更加可靠的方法是流程驱动。例如文件处理 标准操作流程(SOP) Step 1检查文件是否存在 ↓ Step 2判断文件类型 ↓ Step 3执行预处理 ↓ Step 4执行核心操作 ↓ Step 5检查结果是否正确这样模型在执行过程中始终知道我现在在哪一步当前目标是什么下一步是什么出现异常应该在哪个阶段处理。好的 Prompt 不只是告诉模型“不能做什么”更应该告诉模型“应该怎样完成任务”。4.4 系统提示词的业务规则在生产级 Agent 中一个非常重要的问题是不要让模型替产品经理制定业务规则。例如“根据具体情况选择合适的退款方式。” 这句话对人看起来似乎很合理。但对 Agent 来说却包含大量自由裁量空间什么叫“具体情况”什么叫“合适”不同模型甚至同一个模型不同运行次数都可能给出不同判断。因此应该把业务规则细化成情况 A → 使用方案 1情况 B → 使用方案 2情况 C → 禁止执行情况 D → 必须人工确认大模型真正擅长的是在复杂规则下进行理解和决策。而不是自己创造业务规则。4.5 规则不好描述时可以直接给例子当期望的输出难以用规则精确描述时,可以直接给出两三个高质量的输入-输出示例。例如你希望 Agent 写出某一种非常特殊的文案风格。与其写自然一点, 少一点 AI 味, 句子不要太机械, 语言更有人情味可能不如直接给它输入 A → 理想输出 A输入 B → 理想输出 B输入 C → 理想输出 C让模型从几个高质量例子中自己学习模式。但示例也不是越多越好。两三个覆盖典型情况和边界情况的高质量示例通常比十几个重复案例更加有效。4.6 工具描述也是 Prompt 的一部分除了系统提示词, API 请求中另一个重要的静态组成部分是工具定义(tools 字段) 。工具定义的质量直接决定了Agent使用工具的准确性.工具定义写得好不好会直接影响 Agent会不会选错工具参数会不会填错会不会在不该调用的时候调用是否理解多个工具之间的关系。因此一个好的工具描述而应该告诉模型什么时候使用什么时候不要使用参数分别表示什么有没有典型示例是否应该和其他工具配合使用。Agent Skills随着 Agent 覆盖的业务场景越来越多,系统提示词会不断膨胀.如果全部塞进 System PromptPrompt 会越来越长。这会产生两个问题浪费 Token绝大多数知识跟当前任务没有关系稀释注意力无关信息越来越多真正重要的信息反而不容易被关注。所以出现了一种新的上下文组织方式Agent Skills.Skills 的核心思想可以总结成四个字按需加载。它采用的是一种Progressive Disclosure渐进式披露的设计思想。Skills 通常可以分成三层:第一层元数据, 每个 Skill 必须包含一个 SKILL.md 文件,开头是 YAML frontmatter(即文件顶部用 --分隔的元数据块,类似书籍的版权页),包含 name 和 description 两个字段。只告诉 AgentSkill 名称;Skill 用途;什么时候应该使用;什么时候不应该使用.这一层非常短可以长期存在于上下文中。第二层核心流程. 当 Agent 判断某个任务需要特定的 Skill 时,运行时才加载完整的 SKILL.md。第三层细则. 通过文件引用深入到更详细的子文档。 如果任务进一步需要“使用 HTML 模板制作 PPT。” 再继续读取对应的子文档、模板或脚本。 于是目录 ↓ 需要时加载 Skill ↓ 需要更深入时加载子文档这就是渐进式披露。不是让 Agent 一开始知道所有细节而是保证它知道“去哪里找到需要的知识”。这也是上下文工程非常重要的思想转变从“把知识全部塞给模型”转变为“让模型能够按需获取知识”。Agent 状态栏如何让 Agent 随时看到任务进度、环境变化和工具调用计数等运行时状态?提示工程给的是静态指令,而 Agent 在执行过程中还需要动态感知自身状态与任务进展。Agent 框架把这些动态信息整理成结构化摘要并注入上下文,这种机制称为 Agent 状态栏(Agent Status Bar).也就是说Agent状态栏就是让 Agent 知道自己“做到哪了”。这个概念最好的类比是手机顶部的状态栏。手机不会要求用户自己从过去几个小时的操作记录里推算“现在还剩多少电”而是直接告诉你Battery36% Wi-FiConnected Time10:30。Agent状态栏也一样。Agent 状态栏的本质就是把隐藏在长轨迹中的“隐式状态”提前整理成模型可以直接读取的“显式知识”。上下文压缩策略Agent 每调用一次工具Assistant MessageTool Result。 轨迹就会继续增长。一次工具调用可能就返回几万甚至几十万个字符。于是出现一个必然的问题上下文会越来越大。所以需要Context Compression上下文压缩。上下文压缩的设计原则: 与其期望模型从冗长的上下文中自动学习,不如主动地、显式地进行知识提炼。虽然需要额外的计算投入(用专门的 LLM 调用来做总结),但产生的是经过压缩的高密度知识表示。上下文感知压缩——将当前的查询意图和已积累的信息纳入压缩的决策过程。通过在压 缩提示中指定“Given the search query: {query}”和“Current context: {context}”,引导模型生成有针对性的摘要。需要注意的是System Prompt 和 Tool Definitions 永远不动这是KV Cache 要求。压缩的对象是对话历史中的 tool results以及Assistant Message。隔离优于压缩上下文工程还有一个非常重要的思想隔离优于压缩。假设主 Agent 要完成“在整个代码库里找到处理支付回调的函数。”如果主 Agent 自己搜索搜索目录 ↓ 读取文件 A ↓ 读取文件 B ↓ 读取文件 C ↓ 读取文件 D ......可能几十万个 Token 的代码都会进入主 Agent 的上下文。因此可以派一个子 Agent去搜索。子 Agent 自己经历几十次搜索几十个文件大量代码。最后只给主 Agent 返回。这样大量中间噪声根本不会进入主 Agent 的上下文。所以压缩是在垃圾进来以后再清理而隔离是从一开始就不让垃圾进入主上下文。当然它也有代价子 Agent 看不到主 Agent 的所有上下文。因此主 Agent 给子 Agent 的任务描述必须目标明确提供必要背景明确需要返回什么结果。总结经过这一章我们可以把上下文工程总结成下面这套结构因此可以总结出几个核心原则上下文不是越多越好而是越相关、越清晰、信息密度越高越好。System Prompt 和核心 Tool Definitions 尽量保持稳定。时间、状态等动态信息尽量追加到上下文末尾。Prompt 应该流程化、结构化而不是无限堆叠规则。大量领域知识不要全部常驻通过 Skills 按需加载。**把工具调用次数、TODO、环境状态等隐式信息如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取