摘要很多团队做AI Agent陷入了“效果差就换更大模型”的误区却忽略了一个核心事实模型能力是天花板上下文质量才是决定Agent实际表现的地板。同一个模型上下文组织得好与坏任务完成率可以差出一个量级。本文基于一线工程实践系统拆解上下文工程的7个核心层级从底层最容易被忽略的KV Cache性能约束到静态提示工程、Skills动态能力加载、Agent状态栏、上下文压缩再到子Agent隔离架构。每个模块讲清原理、真实踩坑、生产级最佳实践帮你用现有模型把Agent能力拉满同时控制延迟与推理成本。关键词AI Agent上下文工程KV Cache提示工程Agent状态栏上下文压缩子Agent隔离目录0 前言别再只靠换模型提升Agent效果1 底层约束KV Cache——90%的人都踩过的性能暗坑2 静态底座提示工程首先是产品设计问题3 动态扩展Agent Skills按需加载的能力模块4 状态感知Agent状态栏把隐式状态变成显式知识5 密度提升上下文压缩解决的不只是长度问题6 架构优化子Agent隔离用隔离代替压缩7 落地路线从入门到高阶的7步优化清单8 结语上下文工程的核心哲学0 前言别再只靠换模型提升Agent效果做Coding Agent的同学大概率有过这种体验同样是修复一个bug给Agent完整的目录结构、代码规范、分支策略它能输出符合项目规范的代码只丢一句“帮我修bug”它写出来的东西往往语法正确但完全不符合项目架构甚至直接往主分支瞎提交。这就是上下文的价值。模型就像一个能力很强的新员工你不给它业务规则、流程规范、环境信息它再聪明也发挥不出来。很多团队做Agent效果不好第一反应是换更大的模型却忽略了上下文的组织质量。上下文工程不是“往提示词里塞更多信息”而是系统性地设计模型每次决策时能看到什么、信息怎么组织、哪些静态哪些动态、膨胀了怎么处理。这篇文章我们从底层约束到顶层架构逐层拆解上下文工程的完整方法论每一层都配真实踩坑和生产级实践。1 底层约束KV Cache——90%的人都踩过的性能暗坑1.1 一个真实事故某团队的客服Agent上线后一直很稳定某天工程师为了让Agent知道当前时间在系统提示词里加了一行Current time: {{now}}每次请求动态替换时间戳。结果第二天直接告警首token延迟从0.5秒涨到3-5秒月度推理账单几乎翻了一倍。代码看起来完全没错问题就出在KV Cache上——那一行动态时间戳让所有请求的前缀缓存全部失效模型每次都要从头计算所有token的键值对。1.2 KV Cache到底是什么简单说模型生成每个token时都需要回看前文所有token的中间计算结果。如果每轮都从头算开销会随上下文长度爆炸式增长。KV Cache就是把前文的中间计算结果缓存下来下一轮只算新增token的部分。前提是前缀必须字节级完全一致哪怕多一个空格、改一个标点缓存都会全部失效。类比前面切菜、调酱汁的步骤每次都一样就可以提前备好直接用如果前面换了食材后面所有步骤都得重来。系统提示词、工具定义就是“前面的步骤”定了就别改时间、状态这类动态内容应该追加到末尾不能改前面的前缀。1.3 三条必须刻进脑子里的铁律系统提示词和工具定义一旦确定就不要改。任何改动都会导致缓存全失效延迟成倍增加成本直接翻倍。动态信息永远追加到末尾。时间戳、用户状态、进度信息全部作为新消息追加到对话末尾绝对不要修改已有的system消息。用标准API消息格式不要自己拼字符串。每个模型都有官方训练时的聊天模板自己拼USER:... ASSISTANT:...等于发明一套模型没见过的格式模型表现会打折。1.4 KV Cache vs Prompt Cache别搞混很多人把这两个概念混为一谈其实完全不在一个层面KV Cache推理引擎层面的缓存存在于vLLM、SGLang的内存里是单次会话内的加速会话结束就清空。Prompt CacheAPI服务商的跨请求缓存在KV Cache之上实现允许相同前缀在不同用户、不同请求之间复用。OpenAI、Anthropic的提示词缓存都属于这一类。【实战避坑】不要为了“个性化”给每个用户改系统提示词不要动态往system里塞few-shot示例。这些做法都会让缓存彻底失效推理成本涨几倍都找不到原因。2 静态底座提示工程首先是产品设计问题很多人觉得提示工程就是“把指令写清楚”其实远不止如此。对Agent来说系统提示词工具定义是整个上下文的静态前缀是Agent行为的规则底座。2.1 案例电商退货审核Agent假设要做一个自动审核退货的Agent目标是正常订单快速批恶意订单防薅羊毛。如果只写一句“对合理的退货请求予以批准”Agent的批准率会忽高忽低超过7天的VIP订单批不批拆封的数码产品退不退生鲜食品退不退全靠模型自由发挥。正确的做法是把规则写死、边界划清NEVER auto_approve returns for fresh food or activated digital products. Use human_review instead. VIP orders: extend the return window to 30 days.这个案例背后有一个核心认知提示工程首先是产品设计问题其次才是技术问题。成熟的Agent团队里提示词是产品经理基于业务规则、用户反馈来设计迭代的工程师负责把规则准确落地而不是自己拍脑袋定业务逻辑。2.2 四个提示工程最佳实践关键约束用大写强调。NEVER、MUST比“请不要”“建议”的约束力强很多但别滥用只留给真正的红线规则。XML Markdown双层结构化。XML标签自带语义比如working_directory模型能快速识别Markdown用来组织层级兼顾可读性。两者配合效果远好于纯文本堆砌。用SOP流程代替规则堆砌。就像新员工培训给流程图比给一百条零散规则有用给Agent写标准操作流程一步一步告诉它先做什么、再做什么、异常怎么处理模型的稳定性会大幅提升。few-shot示例宁少勿滥。两三个覆盖边界场景的高质量示例远好于十个大同小异的例子。而且示例一旦放进系统提示词就要保持固定不要动态检索替换否则缓存会失效。2.3 不能不提的安全风险提示注入提示工程设计得再完善只要攻击者能往上下文里注入恶意指令所有规则都可能被绕过。尤其是Agent有工具调用能力被注入后可能执行删文件、泄露数据等危险操作比普通聊天机器人风险高得多。上下文层面的基础防御手段所有外部内容用external_content标签包裹帮模型区分“指令”和“数据”过滤外部内容里的“忽略之前所有指令”这类常见注入模式永远不要把上下文层防御当成唯一防线执行层的权限控制、沙盒隔离、高危操作人工审核必须配齐3 动态扩展Agent Skills按需加载的能力模块3.1 为什么不能把所有规则都塞进系统提示词随着Agent覆盖的场景越来越多客服退款规则、代码规范、文档格式要求……全塞进系统提示词会出两个问题浪费token大部分内容和当前任务完全无关白白占用上下文和成本注意力稀释无关信息太多模型会漏掉真正关键的规则于是就有了Skills机制不是把所有手册一次性塞给Agent而是先给一份能力目录需要哪个领域的知识再加载对应的完整内容。这就是渐进式披露的设计思想。3.2 Skills的三层架构层级内容位置特点第一层元数据技能名称、适用场景、不适用场景常驻上下文前缀只有几百token用于路由判断第二层核心流程完整的操作规范、SOP按需加载追加到对话末尾任务需要时才加载第三层细则技术细节、子文档按需深入读取只有需要细节时才展开类比就像你不会把公司所有部门的手册都堆在新员工桌上而是先给总目录需要哪个部门的规则再去取。3.3 三种实现方式的权衡Skills内容放在上下文的什么位置直接决定了缓存效率和指令遵循效果实现方式做法优点缺点注入system消息加载时改写系统提示词指令遵循最强每次加载都破坏前缀缓存成本暴涨作为tool result追加完整内容作为工具返回结果放在对话中完全不影响前缀缓存模型对中间位置的指令遵循度会打折扣路由执行分离生产推荐元数据常驻前缀用于判断完整内容按需追加兼顾缓存效率和指令遵循实现复杂度最高目前Claude Code等成熟产品都采用第三种方案这是在性能和效果之间找到的最优平衡。【实战提醒】Skill的描述里一定要写清楚“Don’t use when”什么场景别用只写适用场景不写反例路由准确率会明显下降经常在不相关的任务上误触发。4 状态感知Agent状态栏把隐式状态变成显式知识4.1 为什么模型总“数不清”一个非常经典的问题你告诉Agent“同一个商家最多打3次电话”结果它经常打第4次、第5次陷入循环。是模型笨吗不是。本质原因是注意力机制擅长检索不擅长提炼。上下文里有原始的通话记录但“已经打了几次”这个结论模型每次都要从头扫一遍上下文去数效率极低还容易数错。就像你书桌上堆了一堆单据你不整理出一个总数每次都得从头翻一遍数。状态栏解决的就是这个问题框架提前把状态算好以非常低的token成本直接把结论摆在模型面前不用它自己去数。4.2 状态栏的量化效果在专门的基准测试ContextDistill-Bench上状态栏的效果非常显著对小模型计数、规则归纳、状态跟踪类任务准确率能提升40-54个百分点2B的小模型甚至能追平不带状态栏的前沿大模型对大模型准确率提升不明显但思考token、延迟、成本能降一个数量级最本质的变化不带状态栏思考量随上下文变长而增长带上状态栏思考量基本恒定4.3 三条工程经验踩过坑才懂状态栏用代码维护绝对不要用LLM去总结。一个20行的正则函数就能统计出准确的调用次数让大模型去读历史统计等于把“扫上下文”的难题原封不动搬了个家反而更不准。状态栏覆盖的维度要提前想全。状态栏是有损投影只覆盖了你预设的维度。如果后面业务问了状态栏没统计的问题就会出问题。准备压缩原始上下文之前先确认状态栏能覆盖所有后续会用到的信息。把状态栏的准确率当成生产指标来盯。模型几乎会无条件相信状态栏里的内容你写“打了3次”它就当真的是3次。状态栏写错了最终结果一定错。状态信息越来自真实的外部观测价值越高。4.4 放对位置很重要状态栏在API层面是作为user角色的消息插到上下文末尾的绝对不能去改开头的system消息。原因还是KV Cache改system会让整个前缀缓存失效追加到末尾前面的缓存完全不受影响。而且放在末尾紧邻生成位置模型的注意力权重最高效果最好。5 密度提升上下文压缩解决的不只是长度问题很多人对压缩的理解停留在“上下文满了装不下压一压”其实压缩更深层的价值是提升信息密度解决上下文腐化。5.1 上下文腐化装得下但找不到长上下文有一个非常隐蔽的问题明明窗口还没满但模型突然找不到关键信息了或者反复纠结已经解决的问题。这就是Lost in the Middle等研究证实的现象信息越在上下文中间模型检索到的概率越低。上下文越长中间的信息越容易被淹没。就像你的书桌越堆越乱虽然还有空位但你想找的东西已经找不到了。这时候换更大的桌子更大的上下文窗口没用定期整理才有用。5.2 六种压缩策略对比策略做法评价无压缩完整保留所有原始结果窗口溢出直接失败不推荐个体摘要每个结果单独压缩信息碎片化整体逻辑差组合摘要所有结果合并生成综合摘要信息密度高但超长输入需截断上下文感知压缩结合查询意图和已有信息做压缩效果最佳保留关键信息比例最高带引用的感知压缩压缩同时保留溯源链接可验证但token开销高自适应窗口化接近阈值才触发压缩保留初期完整性适合短任务生产环境首推上下文感知压缩同样压缩到1.3%的体积它能精准保留人名、职位变动等核心决策信息不会把关键内容压丢。5.3 生产级分层压缩机制成熟的Agent系统不会只用一种压缩方式而是像垃圾分类一样分层处理优先用成本最低的手段工具结果预算控制大体积输出存磁盘模型只看摘要噪声直接删除低价值、只看过一眼的内容直接移除不做摘要API层微压缩调用服务端接口移除指定的历史工具结果归档式摘要逐轮做结构化摘要像git log一样保留每轮脉络全量压缩LLM驱动的完整压缩作为最后手段配熔断器避免反复失败死循环5.4 压缩保留优先级生产必配压缩最容易丢的不是细节是早期的架构决策、约束的原因、失败的路径。一定要显式定义保留优先级✅ 必须完整保留架构决策与关键约束、文件修改记录、验证结果、待办与回滚笔记⚠️ 可保留结论工具输出只保留pass/fail结果删除详情❌ 必须原样保留UUID、hash、文件名、IP、端口号等标识符错一位后续工具调用就会失效6 架构优化子Agent隔离用隔离代替压缩压缩是信息已经进了上下文之后做减法还有一种更彻底的思路让大体积的中间信息根本不进入主上下文这就是子Agent隔离。6.1 一个直观的对比任务在代码库里找处理支付回调的函数主Agent亲自搜十几个文件、数万token的原始代码全部进入主上下文找到目标后这些代码就成了永久占着窗口的噪声后面还要压缩清理委派给子Agent子Agent在自己的上下文里读文件、搜关键词、分析候选函数最后只把“函数位置调用点”几百token的结论回传给主Agent。中间过程的数万token随子Agent一起被丢弃。主上下文始终干干净净没有噪声KV缓存也完全不受影响。6.2 隔离 vs 压缩 完整对比维度压缩隔离时机事后补救信息已经进入上下文事前预防信息根本不进入有损性有损LLM蒸馏会丢信息无损原始信息在子Agent里完整保留额外成本需要额外LLM调用做压缩需要子Agent的推理成本缓存影响替换点之后缓存失效主上下文缓存完全不受影响适用场景信息已进入必须精简可预判会产生大量中间内容的任务一句话总结能用隔离解决的就不要等到需要压缩的时候。现在主流的深度研究Agent、代码库分析Agent基本都是这个架构主Agent负责规划和汇总子Agent负责具体的检索、阅读、分析只把结论传回来。7 落地路线从入门到高阶的7步优化清单很多人看完一堆技术点不知道从哪下手这里给一个可直接执行的落地优先级入门级先做这两步见效最快固定静态前缀把系统提示词、工具定义彻底固定下来所有动态内容全部追加到对话末尾先把KV Cache的性能红利吃满SOP化提示词把零散规则改成流程化指令结构化组织先把Agent的稳定性提上来进阶级加上基础状态栏先做工具调用计数、任务进度、当前时间这三个最基础的状态解决循环、忘事的问题能力模块化把不同领域的规则拆成Skills按需加载不要全堆在系统提示词里加上下文压缩配置分层压缩机制和保留优先级控制上下文长度和推理成本高阶级复杂任务子Agent化大体积检索、深度分析类任务拆成子Agent隔离执行主Agent只做规划和汇总建立监控指标把缓存命中率、上下文膨胀速度、状态栏准确率当成核心生产指标来监控8 结语上下文工程的核心哲学整篇文章看下来你会发现所有技术都在围绕同一个核心原则静态的归静态动态的归动态主动提炼结构化信息而不是让模型被动在海量内容里检索。模型在变强上下文窗口在变大但这个原则不会变。未来模型能力会越来越强但上下文工程永远有价值——它本质上是用工程手段在当前模型能力边界下把信息利用效率最大化。与其一味追更大的模型、更长的窗口不如先把上下文组织好。很多时候不是模型不够强是你给它看的信息太乱了。你们做Agent的时候遇到过最头疼的上下文问题是什么是无限循环、任务跑偏还是推理成本太高欢迎评论区交流。#AI Agent #上下文工程 #KV Cache #提示工程 #Agent开发 #大模型工程化