1. 上下文工程到底在解决什么问题很多人第一次听到“上下文工程”这个词会下意识觉得它只是“提示词工程”换了个马甲。我一开始也这么想直到自己动手搭过几个 AI Agent 之后才发现这两件事根本不在一个层面上。提示词工程关心的是“这句话怎么说”上下文工程关心的是“模型在做出这一步决策之前它的脑子里应该装着哪些信息”。前者是措辞问题后者是信息架构问题。举个我踩过的真实场景。早期我做一个自动处理工单的 Agent提示词写得非常漂亮角色设定、语气要求、输出格式全都交代得清清楚楚。单轮测试的时候效果很好但一旦让它连续处理五六个工单它就开始胡言乱语要么把上一个工单的客户信息带到下一个工单里要么忘记了自己刚才已经查过数据库。当时我以为是模型能力不够换了更大的模型问题依旧。后来才想明白不是模型不行是我从来没有管理过它的上下文窗口。每一轮对话我都把全部历史一股脑塞进去窗口被无关信息塞满真正关键的当前任务信息反而被淹没了。这就是上下文工程要解决的核心矛盾。大语言模型的上下文窗口是有限的而 Agent 在运行过程中产生的信息是无限的——工具调用的返回结果、中间推理步骤、历史对话、外部检索到的文档、系统状态……这些东西如果不加管理地全部堆进去模型的有效注意力会被严重稀释。上下文工程本质上就是一套“在有限窗口内把最该让模型看到的信息以最合适的形式在最合适的时机喂给它”的系统方法。它和提示词工程的关系我习惯这样类比提示词工程像是给一个员工写清楚岗位说明书上下文工程则是决定这个员工每天上班时办公桌上应该摆哪些文件、哪些该收进抽屉、哪些该直接扔掉。岗位说明书写得再好如果桌上堆满了三年前的废纸他也干不好活。对于正在搭建 AI Agent 的开发者来说上下文工程能力直接决定了 Agent 能不能从“玩具 Demo”变成“能扛住真实业务”的产品。我见过太多项目Demo 阶段惊艳一上生产就崩根因几乎都出在上下文管理上。接下来的内容我会把上下文工程的几个核心机制拆开讲透包括它为什么这样设计、实际怎么落地、以及我在实操中踩过的那些坑。2. 上下文窗口的物理约束与信息密度博弈2.1 窗口不是越大越好这是个反直觉的结论现在主流模型的上下文窗口动辄 128K、200K 甚至更大很多人的第一反应是“那我把所有东西都塞进去不就行了”。我实测下来的结论是窗口大不等于效果好甚至在某些场景下塞得越满效果越差。原因有两个层面。第一层是注意力稀释。模型在处理长上下文时并不是对每个 token 都给予同等关注。当上下文里充斥着大量与当前决策无关的内容时真正关键的那几条信息所分配到的注意力权重会被摊薄。这就像在一个嘈杂的会议室里开会说话的人再多你也听不清重点。第二层是“中间遗忘”现象。有不少研究和我的实际测试都指向同一个规律模型对上下文开头和结尾部分的信息召回率明显高于中间部分。如果你把最关键的任务指令放在一个超长上下文的中间位置模型很可能“看不见”它。这个现象在需要精确检索信息的 Agent 场景里特别致命。所以我的第一条实操原则是永远不要因为窗口大就放弃信息筛选。窗口大小是上限不是目标。你应该追求的是在满足任务需求的前提下用尽可能少、尽可能精准的上下文。2.2 一个可量化的上下文预算分配方法光说“要精简”太虚我给一个自己常用的上下文预算分配思路。假设你用的是 128K 窗口的模型不要真的按 128K 去规划留出安全余量按 100K 来算。然后把这 100K 切成几块上下文分区建议占比内容说明是否可压缩系统指令区5%-10%角色设定、行为约束、输出格式低当前任务区15%-20%用户当前请求、任务目标低工具定义区10%-15%可用工具的 schema 描述中历史记忆区20%-30%对话历史、已完成步骤摘要高检索知识区20%-30%RAG 召回的外部文档高推理暂存区10%-15%中间推理、草稿高这张表的关键不在具体数字而在于它强迫你在设计阶段就想清楚哪些信息是“必须原样保留”的哪些是“可以摘要压缩”的哪些是“用完即弃”的。我见过很多 Agent 把所有信息都当成必须原样保留结果就是窗口迅速被撑爆。提示系统指令区和当前任务区通常不可压缩因为一旦这里的信息失真Agent 的行为会直接跑偏。而历史记忆区和检索知识区是最值得下功夫做压缩的地方也是上下文工程收益最高的地方。2.3 为什么工具定义也要纳入上下文管理这一点很多人会忽略。当你给 Agent 挂载了十几个工具时每个工具的 schema 描述加起来可能就占掉好几千 token。如果这些工具在当前任务里根本用不上它们就是在白白消耗上下文预算。我的做法是动态工具注入根据当前任务类型只把相关的工具定义放进上下文。比如用户问的是数据查询类问题那就只注入数据库查询相关的工具把文件操作、邮件发送之类的工具先收起来。这个策略在工具数量超过 8 个之后效果提升非常明显。实现上也不复杂给每个工具打上标签在构造上下文时按标签过滤即可。3. ReAct 循环里的上下文是怎么一步步失控的3.1 拆解一个典型 ReAct 循环的上下文增长ReActReasoning Acting是现在绝大多数 Agent 的基础运行范式模型先推理再决定调用哪个工具拿到工具结果后继续推理如此循环直到任务完成。这个范式本身很优雅但它在上下文管理上有个天然的隐患——每一轮循环都会往上下文里追加内容而且只增不减。我来还原一个真实的增长过程。假设一个 Agent 要完成“查一下上个月销售额最高的三个产品并给对应的负责人发提醒”这个任务第 1 轮系统指令 用户请求 工具定义约 3000 token第 2 轮模型推理“我需要先查销售数据” 工具调用参数 数据库返回的原始数据假设返回了 50 行记录约 4000 token第 3 轮模型推理“我需要排序取前三” 又一次工具调用 返回结果约 2000 token第 4 轮模型推理“我需要查负责人信息” 工具调用 返回约 2500 token第 5 轮模型推理“我需要发送提醒” 工具调用 返回约 1500 token到任务结束时上下文里累积了大约 13000 token。单看一次任务好像还好但如果这个 Agent 要连续处理几十个这样的任务或者任务本身更复杂、工具返回的数据量更大上下文会迅速膨胀到几万甚至十几万 token。更糟糕的是第 2 轮返回的那 50 行原始数据在后面几轮里其实已经完全没用了但它一直占着位置。3.2 三种主流的上下文压缩策略对比针对这个问题业界目前主要有三种处理思路我分别说说它们的适用场景和坑。第一种是滑动窗口。只保留最近 N 轮对话超出的直接丢弃。实现最简单但问题也很明显如果关键信息出现在被丢弃的早期轮次里Agent 就会“失忆”。我早期就吃过这个亏Agent 把用户最开始说的约束条件给忘了后面全做错。第二种是摘要压缩。把历史对话用模型总结成一段简短的摘要用摘要替代原始对话。这个策略比滑动窗口聪明但摘要本身是有损的而且摘要过程本身也要消耗一次模型调用。我的经验是摘要适合压缩“已经完成的步骤”不适合压缩“当前正在进行的推理链”因为推理链一旦被摘要细节丢失会导致后续推理断裂。第三种是结构化状态管理。这是我目前最推荐的方式。核心思路是不把上下文当成一个线性的文本流而是维护一个结构化的状态对象里面明确区分“任务目标”“已完成步骤”“当前待办”“关键事实”等字段。每一轮循环结束后把新产生的信息更新到对应字段里而不是无脑追加。构造下一次模型输入时再从这个结构化状态里按需渲染出上下文。三种策略的对比策略实现复杂度信息保真度适用场景主要风险滑动窗口低低短任务、无状态依赖关键信息丢失摘要压缩中中长对话、步骤独立摘要失真、额外开销结构化状态高高复杂任务、多步骤设计成本高3.3 我在结构化状态管理上的具体做法说点能直接抄的。我维护的状态对象大概长这样伪代码示意agent_state { task_goal: 查上个月销售额前三的产品并通知负责人, constraints: [只统计已完成的订单, 排除退货], completed_steps: [ {step: 查询销售数据, result_summary: 共50条记录已排序}, {step: 取前三, result: [产品A, 产品B, 产品C]} ], current_focus: 查询三个产品对应的负责人, key_facts: { top_products: [产品A, 产品B, 产品C], time_range: 上个月 }, pending_actions: [发送提醒] }每一轮循环结束后我不是把工具返回的原始数据直接追加到对话历史里而是先提取出关键信息更新到key_facts和completed_steps原始数据该丢就丢。构造模型输入时我把这个状态对象序列化成一段结构清晰的文本而不是把几十轮原始对话全塞进去。这样做的效果非常明显。同样那个任务用结构化状态管理之后整个任务执行过程中的上下文峰值从 13000 token 降到了 4000 token 左右而且因为关键信息被显式保留Agent 的“失忆”问题基本消失了。注意结构化状态管理的关键在于“提取”这一步。你需要让模型在每轮结束时输出一个结构化的状态更新而不是让它自由发挥。我通常会在系统指令里明确要求模型以 JSON 格式返回状态变更这样解析起来稳定得多。4. 记忆系统让 Agent 跨会话记住该记的东西4.1 短期记忆和长期记忆的边界在哪前面讲的主要是单次任务内的上下文管理属于短期记忆范畴。但真实的 Agent 往往需要跨会话工作比如一个客服 Agent 今天接待了用户明天用户又来了它应该记得上次的沟通内容。这就涉及长期记忆。短期记忆和长期记忆的边界我的划分标准是短期记忆服务于当前任务的推理链长期记忆服务于跨任务的个性化与连续性。短期记忆追求的是“当前这一步决策需要什么”长期记忆追求的是“这个用户/这个场景有什么是需要一直记住的”。这个边界很重要因为两者的存储介质和检索方式完全不同。短期记忆放在上下文窗口里长期记忆放在外部存储向量数据库、关系数据库、键值存储等里需要时再检索回上下文。4.2 长期记忆的写入时机比检索方式更关键很多人做长期记忆把精力全花在“怎么检索得准”上却忽略了“什么时候该写入”。我的经验是写入时机的设计才是长期记忆效果的分水岭。如果每轮对话都往长期记忆里写很快你就会得到一个充满噪音的记忆库检索出来的东西全是无关紧要的碎片。如果只在任务结束时写又可能漏掉过程中的关键信息。我目前的做法是事件驱动写入只在特定类型的事件发生时触发记忆写入。这些事件包括用户明确表达了偏好或约束“我不喜欢电话沟通”任务产生了明确的结果“订单已退款成功”出现了需要后续跟进的事项“用户说下周再联系”用户纠正了 Agent 的错误“不对我说的是另一个订单”这四类事件覆盖了绝大多数值得长期记住的信息。其他的日常对话内容让它随上下文窗口自然淘汰就好。4.3 记忆检索时的一个常见陷阱检索长期记忆时最容易犯的错误是“检索回来就直接塞进上下文”。我踩过这个坑检索回来五条记忆其中三条是相关的两条是噪音结果那两条噪音干扰了模型的判断。正确的做法是检索后二次筛选。检索回来的记忆先经过一轮相关性判断只把真正相关的放进上下文。这个判断可以用一个轻量模型来做也可以用规则过滤。我通常会用规则先粗筛比如时间范围、记忆类型再用模型精筛。多这一道工序效果提升很明显。另外检索回来的记忆最好带上时间戳和来源标注让模型知道这条信息的时效性和可信度。比如“用户三个月前说过偏好邮件沟通”和“用户昨天说过偏好电话沟通”模型看到时间戳就知道该以哪个为准。5. 多 Agent 协作时的上下文隔离与传递5.1 为什么多 Agent 场景下上下文更容易乱当你从单 Agent 扩展到多 Agent 协作时上下文管理会复杂一个数量级。因为每个 Agent 都有自己的上下文窗口而它们之间又需要传递信息。如果传递设计得不好要么信息传丢了要么信息重复传递导致上下文膨胀。我见过一个典型的多 Agent 架构一个调度 Agent 负责拆解任务然后分发给几个执行 Agent。结果调度 Agent 把完整的任务背景塞给了每个执行 Agent而执行 Agent 又把执行结果完整地回传给调度 Agent调度 Agent 的上下文迅速被撑爆。5.2 上下文传递的“最小必要”原则我的解决方案是最小必要传递。Agent 之间传递信息时只传对方完成任务所必需的最小信息集而不是把整个上下文复制过去。具体来说调度 Agent 给执行 Agent 传递的应该是一个“任务包”包含任务目标、输入数据、输出格式要求、约束条件。执行 Agent 回传给调度 Agent 的应该是一个“结果包”包含执行状态、关键结果、异常信息。中间的过程细节各自留在各自的上下文里不互相污染。这个原则听起来简单但实操中很容易违反。因为开发者总担心“万一对方需要更多信息呢”于是倾向于多传。我的建议是宁可少传需要时再补传。多一次交互的成本远低于上下文被撑爆的成本。5.3 共享状态与私有状态的划分多 Agent 协作时我习惯把状态分成两层共享状态和私有状态。共享状态是所有 Agent 都能读写的比如任务的整体进度、全局的关键事实。私有状态是每个 Agent 自己的推理过程、中间草稿其他 Agent 不需要也不应该看到。实现上共享状态可以放在一个中心化的存储里每个 Agent 按需读取和更新。私有状态就留在各自的上下文窗口里。这样既保证了协作所需的信息同步又避免了上下文的无谓膨胀。提示共享状态的更新要有版本控制或冲突检测机制。多个 Agent 同时更新同一个字段时如果没有冲突处理很容易出现状态不一致。我一般会给共享状态加一个简单的版本号更新时检查版本冲突了就重试或人工介入。6. 上下文工程实操中的几个硬核技巧6.1 用“信息锚点”对抗中间遗忘前面提到模型对上下文中间部分的信息召回率低。我的应对方法是设置“信息锚点”把最关键的信息在上下文里重复出现一次放在开头一次放在结尾中间部分放细节。比如任务的核心约束条件我会在系统指令里写一遍在用户请求后面再强调一遍。这样无论模型从哪个位置开始关注都能捕捉到关键约束。这个技巧看起来有点笨但实测下来对减少“跑偏”非常有效。6.2 工具返回结果的预处理工具返回的原始数据往往包含大量冗余。比如一个数据库查询返回了 50 行记录每行有 20 个字段但 Agent 实际只需要其中 3 个字段。如果直接把原始数据塞进上下文就是巨大的浪费。我的做法是在工具层做预处理工具返回结果时先经过一个格式化函数只提取 Agent 需要的字段并且做必要的聚合和摘要。这一步在工具实现里完成而不是让模型去处理。这样既节省了上下文又减少了模型出错的可能。6.3 上下文长度的实时监控上线之后一定要对上下文长度做实时监控。我一般会记录每次模型调用时的输入 token 数设置告警阈值。当某个任务的平均上下文长度持续上升时说明上下文管理可能出了问题需要及时排查。这个监控还能帮你发现异常任务。有些任务因为逻辑设计问题会陷入无限循环上下文不断增长。有了监控你能在它烧掉大量 token 之前就发现并干预。6.4 不同模型对上下文的敏感度差异最后说一个容易被忽略的点不同模型对上下文的敏感度是不一样的。有的模型在长上下文下表现稳定有的模型稍微长一点就开始丢信息。切换模型时一定要重新测试上下文策略不能想当然地沿用。我的经验是在选型阶段就用真实的长上下文场景做压测看看模型在上下文达到 50%、80%、100% 时的表现衰减情况。这个数据比任何 benchmark 都更能反映实际可用性。7. 我踩过的三个真实坑与修复过程7.1 坑一把工具调用历史全部保留导致死循环有一次我做一个数据同步 Agent它需要反复调用接口检查同步状态。我一开始把每次调用的完整历史都保留在上下文里结果 Agent 在第 8 次调用后开始重复之前的推理陷入了死循环。排查过程我先看了上下文长度发现已经涨到了 4 万多 token。然后我把上下文打印出来逐段分析发现前面 7 次的调用记录几乎一模一样模型被这些重复信息“带偏”了以为还在处理之前的状态。修复方案对工具调用历史做去重和摘要。相同类型的调用只保留最近一次的结果历史调用压缩成一行摘要。改完之后同样的任务上下文长度降到了 8000 以内死循环问题消失。7.2 坑二摘要压缩把关键数字压没了另一个项目里我用摘要压缩来管理长对话。结果有一次 Agent 在处理退款金额时出了错把 1999 元算成了 199 元。排查后发现摘要模型在压缩历史时把“订单金额 1999 元”这个关键数字给省略了只保留了“用户申请退款”这个概括。修复方案摘要压缩时对数字、日期、ID 这类关键实体做特殊保护要求摘要模型必须原样保留。我在摘要指令里明确列出了需要保留的实体类型并且加了校验步骤检查摘要里是否包含这些实体。这个改动之后类似的数字丢失问题再没出现过。7.3 坑三多 Agent 传递时上下文格式不兼容多 Agent 协作时我遇到过调度 Agent 和执行 Agent 对同一个字段的理解不一致的问题。调度 Agent 传过去的“优先级”是数字 1-5执行 Agent 却按“高/中/低”来解析导致任务排序全乱。修复方案定义统一的上下文传递 schema所有 Agent 之间的信息传递都必须符合这个 schema。schema 里明确每个字段的类型、取值范围、含义。这个 schema 用 JSON Schema 来定义传递时做校验不符合的直接报错。虽然增加了一点开发成本但彻底解决了格式不一致的问题。8. 上下文工程的未来演进方向从我这段时间的观察和实践来看上下文工程正在从“手工调优”走向“系统化、自动化”。早期我们靠经验去判断该保留什么、丢弃什么现在越来越多的框架开始提供上下文管理的抽象层把压缩、检索、状态管理这些能力封装成可配置的组件。另一个明显的趋势是上下文工程和模型能力的协同进化。模型本身在长上下文处理上的能力在提升这会改变上下文工程的策略重心——从“拼命压缩”转向“更智能地组织和检索”。但无论模型怎么进化信息筛选和组织的逻辑始终存在因为窗口再大也是有限的而信息永远是无限的。对于正在做 AI Agent 的开发者我的建议是不要把上下文工程当成一个后期优化的项而要在架构设计阶段就把它当成一等公民来对待。我见过太多项目功能逻辑写得很好但因为上下文管理没设计好最后不得不推倒重来。提前想清楚你的 Agent 在每个阶段需要什么信息、这些信息从哪来、用完怎么处理能帮你省下大量的返工时间。最后分享一个我自己的习惯每次设计一个新的 Agent我都会先画一张“上下文流转图”标清楚信息从哪进入上下文、在上下文里怎么流转、从哪退出。这张图不用很正式但画完之后很多上下文管理的问题在设计阶段就能暴露出来。这个习惯帮我避开了不少坑也推荐给你试试。