1. 为什么上下文工程成了 AI Agent 的分水岭1.1 从提示词工程到上下文工程的认知跃迁过去两年大家聊得最多的是提示词工程Prompt Engineering琢磨怎么把一句话写得更精准、更结构化让大语言模型输出想要的结果。但真正把 AI Agent 跑起来的人很快会发现提示词只是冰山一角。一个能自主思考、调用工具、多轮迭代的智能体它每一轮决策所依赖的“信息环境”远比一句精心雕琢的提示词复杂得多。这个信息环境就是上下文Context。上下文工程Context Engineering要解决的问题是在 Agent 运行的每一个决策节点如何动态地组装、筛选、压缩、排序所有可用的信息让大语言模型在有限的上下文窗口内拿到最相关、最完整、最不冗余的输入。这跟传统提示词工程的区别就像“写一封得体的邮件”和“运营一个实时信息调度中心”的区别。前者是静态文本后者是动态系统。我最初做 Agent 的时候也踩过这个坑。当时觉得提示词写得够细了工具描述也够清楚了但 Agent 跑多轮之后就开始“失忆”——前面调用的工具结果被后面的对话挤掉了或者被无关的历史信息干扰导致重复调用同一个工具、参数传错、甚至完全跑偏。后来才意识到问题不在模型能力而在上下文管理。上下文窗口就那么大你往里塞什么、按什么顺序塞、什么时候清理直接决定了 Agent 的智商上限。1.2 上下文窗口的物理约束与信息密度的矛盾当前主流大语言模型的上下文窗口从 8K 到 200K token 不等看起来很大但放到 Agent 场景里消耗极快。一次工具调用的返回结果可能就几千 token多轮 ReAct 循环下来历史记录迅速膨胀。更麻烦的是上下文窗口越大模型对中间位置信息的注意力越容易衰减——这就是业内常说的“迷失在中间”Lost in the Middle现象。所以上下文工程的核心矛盾是Agent 需要的信息量在增长但有效注意力容量是有限的。你不能简单地把所有东西都塞进去必须做取舍。这个取舍不是拍脑袋而是要有策略地做优先级排序、摘要压缩、分段加载。我通常把上下文分成几个层次来管理系统指令层角色定义、行为约束、任务状态层当前目标、已完成步骤、待办事项、工具交互层工具描述、调用结果、对话历史层用户输入、Agent 输出。每一层的更新频率、保留策略、压缩方式都不一样。1.3 上下文工程直接影响 Agent 的三大核心能力第一是推理连贯性。Agent 在多轮 ReAct 循环中需要记住之前做了什么、为什么这么做、结果是什么。如果上下文丢失了关键中间状态推理链就断了Agent 会做出自相矛盾的决策。第二是工具调用准确性。工具的描述、参数格式、调用约束都放在上下文里。如果上下文被无关信息挤占工具描述被截断或模糊化Agent 调错工具、传错参数的概率会大幅上升。第三是成本与延迟控制。上下文越长推理成本越高、响应越慢。一个不做上下文优化的 Agent跑十几轮之后每轮消耗的 token 可能是初始轮的好几倍。上下文工程不只是“让 Agent 更聪明”也是“让 Agent 跑得起”。2. 上下文工程的核心架构拆解2.1 上下文的分层模型与生命周期管理我在实际项目中总结出一套四层上下文模型每一层有不同的生命周期和更新策略层级内容更新频率保留策略典型 token 占比系统指令层角色定义、行为约束、输出格式极低始终保留5%-10%任务状态层当前目标、步骤进度、关键决策记录每轮更新滚动摘要10%-15%工具交互层工具描述、最近调用结果按需更新滑动窗口30%-50%对话历史层用户输入、Agent 输出每轮追加摘要截断20%-40%这个分层不是拍脑袋定的而是根据信息的重要性和时效性来划分。系统指令层几乎不变放在上下文最前面利用模型对开头位置的高注意力。任务状态层是 Agent 的“工作记忆”需要每轮更新但要做摘要压缩不能无限增长。工具交互层是消耗大户尤其是返回结果很长的工具比如网页抓取、数据库查询必须做截断或摘要。对话历史层用滑动窗口加摘要的方式控制总量。注意不同模型对上下文位置的注意力分布不同。有些模型对开头和结尾注意力强中间弱有些模型经过专门训练中间位置的注意力有所改善。上线前一定要用实际模型做位置敏感性测试别照搬别人的分层比例。2.2 ReAct 模式下的上下文流转机制ReActReasoning Acting是目前最主流的 Agent 运行模式它的核心循环是“思考→行动→观察→再思考”。在这个循环里上下文的流转有几个关键节点思考阶段模型基于当前上下文生成推理文本和下一步行动决策。这时候上下文里需要包含任务目标、已完成的步骤摘要、可用工具列表、最近几次工具调用结果。行动阶段模型输出工具调用请求工具名参数。这部分输出会追加到上下文里作为后续观察的“前情提要”。观察阶段工具执行结果被注入上下文。这是上下文膨胀最快的环节必须做处理。我的做法是短结果小于 500 token直接保留原文中等结果500-2000 token做关键信息提取长结果超过 2000 token做摘要加分段索引只把摘要和索引放进上下文需要细节时再按索引回查。再思考阶段模型基于更新后的上下文继续推理。这时候要检查上下文是否超限如果接近窗口上限触发压缩流程——把较早的对话历史做摘要把已完成的子任务从任务状态层移除只保留结论。2.3 上下文压缩的四种实战策略上下文压缩不是简单截断截断会丢信息导致 Agent 行为异常。我常用的四种策略按激进程度从低到高排列策略一滑动窗口。只保留最近 N 轮对话更早的直接丢弃。优点是实现简单、零额外成本缺点是会丢失早期关键信息。适合任务步骤独立、不需要长期记忆的场景。策略二摘要压缩。用大语言模型对早期对话做摘要把摘要替换原文。优点是信息保留度高缺点是需要额外调用模型增加延迟和成本。适合任务链较长、需要记住早期决策的场景。策略三关键信息抽取。不保留对话原文只抽取结构化关键信息如“用户要求X”“已完成Y”“当前状态Z”。优点是 token 效率极高缺点是抽取过程可能遗漏细节。适合信息密度要求高的场景。策略四外部记忆检索。把完整历史存到外部存储向量数据库或键值存储上下文里只放索引需要时按需检索。优点是上下文窗口几乎不占缺点是检索准确性依赖索引质量且增加一次检索调用。适合超长任务、多会话场景。实际项目中我通常是组合使用近期对话用滑动窗口中期历史用摘要压缩远期历史用外部记忆检索。这样在 token 消耗和信息保留之间取得平衡。3. 上下文工程的实操落地要点3.1 系统指令层的编写规范与避坑系统指令层是 Agent 的“宪法”写得好不好直接影响后续所有环节。我踩过的坑包括指令太长导致工具描述被挤到中间位置、指令太模糊导致 Agent 行为不稳定、指令里放了太多示例导致 token 浪费。我的编写规范是角色定义控制在 50 字以内说清楚 Agent 是什么、能做什么、不能做什么。比如“你是一个电商客服 Agent负责回答订单查询和退换货问题不处理支付和物流投诉”。行为约束用列表而非段落列表更清晰模型遵循度更高。每条约束不超过 20 字。输出格式用 schema 定义如果需要结构化输出直接给 JSON schema 或 TypeScript 类型定义比自然语言描述更准确。工具描述放在系统指令之后、对话历史之前这个位置注意力较强且不会被对话历史挤走。实操心得系统指令层不要放具体示例。示例放在工具描述里或单独的 few-shot 区域。系统指令层越精简后续上下文管理的灵活度越高。3.2 工具交互层的 token 控制技巧工具交互层是上下文膨胀的重灾区。我做过统计一个中等复杂度的 Agent 任务工具返回结果占上下文总量的 60% 以上。控制这部分 token效果最立竿见影。技巧一工具返回结果预处理。不要让工具直接返回原始数据在工具层做一次过滤。比如网页抓取工具不要返回整个 HTML先用解析器提取正文再截断到 2000 字以内。数据库查询工具不要返回所有字段只返回 Agent 需要的字段。技巧二结果摘要与索引分离。长结果做摘要放进上下文完整结果存到外部存储上下文里附一个引用 ID。Agent 需要细节时通过引用 ID 回查。这样上下文里只占摘要的 token细节按需加载。技巧三工具描述动态加载。如果 Agent 有几十个工具不要一次性全部加载。按任务类型分组只加载当前任务相关的工具组。比如客服 Agent 在处理订单查询时只加载订单相关工具不加载退换货工具。技巧四调用结果去重。同一个工具用相同参数重复调用时直接复用上次结果不重复注入上下文。这个逻辑要在 Agent 框架层实现不能依赖模型自己判断。3.3 任务状态层的滚动摘要实现任务状态层是 Agent 的“工作记忆”需要每轮更新。我的实现方式是维护一个结构化状态对象包含当前目标、已完成步骤列表、待办步骤列表、关键决策记录、当前阻塞点。每轮循环结束后用一段简短的提示词让模型更新这个状态对象。提示词大概是“基于最新一轮的思考和行动结果更新任务状态。已完成步骤只保留结论待办步骤按优先级排序关键决策记录只保留影响后续步骤的决策。”这个更新过程本身也消耗 token但相比让完整对话历史无限增长滚动摘要的 token 效率高得多。实测下来一个 20 轮的任务不做滚动摘要上下文会膨胀到 50K token 以上做了滚动摘要能控制在 15K token 以内。3.4 对话历史层的滑动窗口参数调优滑动窗口的大小不是拍脑袋定的要根据任务类型和模型窗口来算。我的经验公式是窗口大小 (模型窗口 - 系统指令层 - 工具交互层预留 - 任务状态层预留) / 平均每轮 token 消耗比如模型窗口 32K系统指令层占 2K工具交互层预留 8K任务状态层预留 3K平均每轮对话消耗 500 token那么窗口大小 (32000 - 2000 - 8000 - 3000) / 500 38 轮。但实际不会留这么多因为工具返回结果波动很大我通常会再打个七折留 25 轮左右的安全边际。注意滑动窗口的截断点要选在完整轮次之间不能把一轮对话截成两半。否则模型看到半截工具调用结果会产生混乱。4. 常见问题与排查技巧实录4.1 Agent 反复调用同一工具怎么排查这是上下文工程最典型的问题。Agent 调了一个工具拿到结果下一轮又调同一个工具参数都一样。原因通常有三个原因一工具结果没有正确注入上下文。检查工具执行框架确认结果确实被追加到了上下文里。有时候框架有 bug结果被丢弃了模型看不到自然重复调用。原因二工具结果被后续信息挤出了有效注意力范围。如果工具结果在上下文中间位置模型可能没注意到。解决办法是把最近一次工具结果放在上下文末尾附近或者用特殊标记如[最新工具结果]突出显示。原因三任务状态层没有更新。模型不知道这个工具已经调过了。检查滚动摘要逻辑确认已完成步骤被正确记录。排查顺序先看上下文日志确认工具结果在不在再看位置确认在不在注意力强的区域最后看任务状态确认有没有记录。4.2 上下文超限导致 Agent 行为异常怎么处理上下文超限的表现包括Agent 突然忘记任务目标、输出格式错乱、工具调用参数缺失、推理链断裂。处理流程确认是否真的超限打印每轮上下文的 token 数看是否接近或超过模型窗口。定位膨胀来源按四层模型分别统计 token 占比找出哪一层失控。紧急压缩如果是工具交互层膨胀启用结果摘要如果是对话历史层膨胀启用滑动窗口截断。长期优化调整各层预留比例优化工具返回结果预处理逻辑。我遇到过一次线上事故Agent 在处理长文档摘要任务时把整篇文档塞进了上下文导致后续所有轮次都超限。后来改成文档分段加载每段摘要后再合并问题解决。4.3 上下文压缩后信息丢失怎么补救压缩必然丢信息关键是怎么丢得聪明。我的补救策略是关键决策不压缩任务状态层里的关键决策记录永远保留原文不参与摘要。工具结果保留引用压缩时保留工具结果的引用 ID 和摘要完整结果存外部存储。用户输入不压缩用户原始输入永远保留因为这是任务的源头压缩容易失真。压缩日志可追溯每次压缩记录哪些内容被压缩了、压缩成什么方便排查问题。4.4 常见问题速查表问题现象可能原因排查方法解决措施反复调用同一工具结果未注入/位置不佳/状态未更新查上下文日志调整注入位置更新任务状态行为突然异常上下文超限统计各层 token启用压缩调整预留比例工具参数传错工具描述被挤占检查工具描述位置工具描述前置精简对话历史推理链断裂中间步骤丢失检查滑动窗口截断点调整窗口大小保留关键步骤响应变慢上下文过长统计 token 趋势启用摘要压缩外部记忆检索输出格式错乱系统指令被稀释检查系统指令位置系统指令前置精简内容5. 上下文工程的进阶优化方向5.1 基于向量检索的动态上下文组装当 Agent 需要处理的知识量超过上下文窗口时静态组装就不够了。我的做法是引入向量检索把所有可能用到的知识工具文档、历史案例、领域知识做 embedding 存到向量数据库每轮根据当前任务状态做检索只把最相关的 top-k 片段注入上下文。这个方案的关键是检索质量。检索不准注入的就是噪音反而干扰模型。我的调优经验是查询语句要用任务状态层的当前目标加最近一轮的思考文本拼接而成不要只用用户原始输入。因为用户输入往往很简短检索信号不足。5.2 多 Agent 场景下的上下文隔离与共享多 Agent 协作时上下文管理更复杂。每个 Agent 有自己的上下文但又要共享部分信息。我的做法是分三层私有上下文每个 Agent 独立维护、共享状态所有 Agent 可读写如任务进度、消息队列Agent 间通信按需拉取。共享状态要加锁或版本控制避免多个 Agent 同时写入导致冲突。消息队列要设过期时间避免旧消息干扰新任务。5.3 上下文工程的评估指标与持续优化上下文工程做得好不好不能靠感觉要有指标。我常用的指标包括上下文利用率有效信息 token / 总上下文 token越高越好。压缩比压缩后 token / 压缩前 token反映压缩效率。任务完成率Agent 成功完成任务的比例最终指标。平均轮次完成任务的平均循环次数越少越好。单任务 token 成本完成任务消耗的总 token越低越好。这些指标要持续监控每次调整上下文策略后对比变化。我一般会做 A/B 测试一组用旧策略一组用新策略跑同一批任务对比指标。5.4 面向未来的上下文工程趋势从目前的技术演进来看上下文工程有几个方向值得关注。一是模型原生支持的结构化上下文比如某些模型开始支持在上下文里标记信息优先级模型会根据优先级分配注意力。二是自动上下文优化用一个小模型专门做上下文组装和压缩主模型只负责推理。三是上下文缓存与复用相似任务的上下文可以部分复用减少重复组装成本。这些方向目前还在早期但思路很明确上下文工程会从手工调优走向自动化、系统化。对于现在做 Agent 的团队来说先把基础的分层模型、压缩策略、监控指标搭起来后续升级就有基础。我个人在实际操作中的体会是上下文工程没有一劳永逸的方案它是一个持续调优的过程。任务类型变了、模型换了、工具增减了上下文策略都要跟着调。但只要你把分层模型和监控指标建起来每次调整都有据可依不会瞎调。最后再分享一个小技巧每次上线新策略前先用历史任务日志做离线回放测试确认指标不退化再上线上。这个习惯帮我避免了好几次线上事故。