1. 先把概念说清楚Agent场景里“模型的学习”到底指什么前两天我在梳理 Agent 技术栈的时候发现一个特别容易混淆的点很多人把“Agent 会学习”挂在嘴边但真去追问他“模型到底是怎么学习的”往往就说不清了。这不是基础不基础的问题是整个 Agent 领域的术语本身就容易绕晕人。所以这篇精读的开头我先把这块最容易产生误解的地基给铲平。先说我的结论Agent 场景中“模型的学习”绝大多数时候指的不是重新训练模型也不是给模型喂更多数据做微调而是指模型在推理过程中利用上下文信息进行“动态学习”的能力。也就是所谓的 In-Context Learning上下文学习。模型本身的权重没有变化但它在读取上下文的时候能够从你给它的示例、工具返回结果、历史对话中“现学现用”。这就像你临时拉了一个人进项目组不需要他重新上大学只需要给他看两三条过往项目文档他就能立刻上手干活——这就是 Agent 的“学习”。为了更严谨我把 Agent 项目中“模型的学习”拆成了三个层面第一个层面是权重学习Weight Learning。这是传统意义上的“训练”发生在模型真正投入使用之前比如预训练、指令微调、RLHF。这一层决定了模型的基础能力但它在 Agent 运行过程中不会发生。你不可能在 Agent 跑任务的时候实时去改模型权重成本太高也没有这个必要。第二个层面是实例对齐Example Alignment也就是把几个 few-shot 示例塞到 prompt 里。很多人认为这只是在“给模型看例子”但更准确的比喻是这是在给模型划定一个“答题风格”。比如说你给它看了三个客服对话案例它就会模仿案例里的语气、信息密度、追问方式。Prompt 里放例子本质上是在做“即时风格对齐”而不是在做“知识灌输”。第三个层面是上下文推理Context Reasoning这是 Agent 最核心的学习方式。模型把当前的任务描述、工具返回的报错信息、历史对话中已经尝试过的方案全部拼接在上下文里然后基于这些信息推导下一步动作。注意这些信息中有相当一部分是之前几轮才产生的换句话说模型是在“读过自己刚刚做过的事情之后”再来决定下一步怎么做——这是一种动态的、边做边学的机制。这三个层面搞清楚之后你就不难理解一个关键问题了为什么 Agent 项目里大家疯狂追求长上下文因为上下文就是 Agent 的“短期工作记忆”。窗口越长模型能“读到”的历史越多能做的推理就越连贯。1M 上下文之所以成为热门话题就是因为它在工程层面把工作记忆的容量拉到了一个新的量级。理解了这一点我们再往下看上下文怎么构成就顺理成章了。2. Agent 的“学习”机制核心是上下文工程2.1 从提示词工程到上下文工程到底发生了什么变化这两年圈子里有个明显的趋势——大家讨论的重心逐渐从“提示词工程Prompt Engineering”转移到了“上下文工程Context Engineering”。这两个词的区别一开始我以为是噱头真正跑过几个 Agent 项目之后才发现两者完全不在一个层级上。提示词工程的关注点是怎么用一段精心构造的文字让模型给出更好的回答。它的对象是单轮、短文本、模型内部的 pattern matching。你调的是措辞、结构、语气本质上是在“哄模型”。上下文工程的关注点是怎么构造、组织、管理模型读取到的所有信息让 Agent 在多轮工具调用中保持稳定和高效。它的对象是多轮、跨工具、动态变化的完整信息流。你调的是哪些信息该放进来、放在什么位置、什么时候该丢弃、什么时候该滚动出窗口。我举个具体例子。单轮提示词工程里你写“请扮演一位资深运维专家帮我分析这段日志”——这就是全部了。但在 Agent 场景里你需要同时管理系统指令、用户当前问题、上一次工具调用返回的报错堆栈、前三次尝试过的命令行历史、从知识库里检索到的运维文档片段、以及本轮模型的推理轨迹。这些信息加起来可能超过一万 token。这时候你面临的核心问题已经变了——不是怎么把问题问得更清楚而是怎么在一堆信息里让模型找到它真正需要的部分。这就是上下文工程的活儿。在我自己的 Agent 开发经验里提示词工程大概只占整个上下文设计的 20% 工作量剩下 80% 都在做信息架构什么东西该常驻什么东西该按需注入什么东西该压缩什么东西该直接扔掉。如果你还停留在“把 prompt 写漂亮一点”的思路来做 Agent大概率会被上下文爆炸、模型跑偏、工具调用失序这些问题折磨得焦头烂额。2.2 Agent 为什么离不开长上下文滑动窗口的启示长上下文不是炫技而是 Agent 工作方式的硬性需求。要理解这一点可以从一个和 Agent 关系密切的经典算法——滑动窗口滤波模型——说起。滑动窗口滤波模型的核心思想是只对最近一段时间窗口内的数据进行处理窗口外的旧数据逐步衰减或丢弃。这个算法在信号处理、时间序列预测、流式计算中广泛应用而在大模型场景里它几乎就是 Transformer 注意力机制的一种直观形态——模型在生成当前 token 时注意力权重只会集中在它可见的上下文范围之内超出范围的内容对当前生成结果“不可见”。Agent 的推理过程也类似每一轮工具调用之后都会产生新的信息工具返回值、错误日志、中间结果这些信息进入上下文后会构成后续推理的依据。模型相当于在一个“滑动的上下文窗口”上持续做决策——窗口够长就能覆盖更多的历史信息和工具调用链条窗口被截断它就只能基于不完整的信息继续干活结果就是逻辑断裂、重复尝试、甚至幻觉。这也是为什么 Claude 的 1M 上下文一出来我身边做 Agent 的朋友几乎都在讨论它。1M token 意味着什么大约相当于《三体》三部曲的总字数。放到 Agent 场景里就是模型可以一次性把几十轮工具调用的完整历史、几千行代码文件、多份参考文档全部装进窗口而不需要频繁压缩和截断。做长任务、跑复杂工作流的时候这个优势是致命的。但注意长上下文不是越多越好。我实测过上下文窗口拉长之后模型对早期信息的“注意力”会被稀释——就算是 1M 窗口模型也并不是对窗口内每个 token 都一视同仁。实际经验是超过一定长度之后模型对中部内容的记忆效果明显变差这就是所谓的“lost in the middle”现象。所以与其盲目追求超长窗口不如学会“在合适的位置放合适的信息”。这就是我们接下来要说的内容上下文的构成。2.3 上下文如何影响模型输出一个形象的类比为了把“上下文影响”这件事讲得更直观我常用一个类比上下文就是模型在推理时拿到的“剧本卡”。想象一个演员模型上台演戏。他不可能临时背诵整个剧本而是靠场务Agent 框架在每一幕开始前递给他一叠卡片。卡片上可能写着你的角色设定系统指令、你现在在哪个场景当前目标、上一位演员刚刚说了什么对话历史、道具组临时改了什么工具返回值。这个演员演得好不好不只看他演技多强更要看场务递的卡片够不够清晰、有没有相互矛盾、有没有漏掉关键剧情。这个类比能帮你解释很多 Agent 开发中的怪现象为什么同一个模型在一个框架里表现惊艳换一个框架就蠢得像人工智障大概率不是模型的问题而是上下文组织方式变了。为什么有时候模型会反复调用同一个工具、陷入死循环因为上一轮调用返回的结果没有被正确地放进上下文模型压根不知道自己已经试过一次了。所以上下文不是简单的“信息堆叠”它直接影响模型的行为轨迹——这比单轮 prompt 的影响面要大得多。3. 上下文的构成从内到外拆解每一层信息3.1 上下文的物理构成一段拼接起来的 Token 序列要理解上下文的构成先看物理层面。大模型接收的输入本质上是一段 token 序列而 Agent 框架做的“上下文组装”工作就是把各种来源的信息按某种顺序拼接到这段序列里。一个典型的 Agent 上下文长这样按出现顺序系统指令System Prompt工具定义Tool Schemas对话历史Conversation History外部检索结果/知识库片段RAG Context用户当前输入Current User Message最近一轮工具调用的返回值Tool Result这套结构绝大多数 Agent 框架都类似区别在于顺序、截断策略、以及各部分占用的 token 预算。而在实际使用中模型最先读到的是头部内容最后读到的是尾部内容。头部内容系统指令和工具定义决定了模型的全局行为尾部内容工具返回值、当前输入决定了模型的立即行动中间部分对话历史、检索结果负责提供背景信息支撑。这就是为什么这类信息排列顺序是有讲究的把不该被忽略的信息放在头部或尾部把次要信息放在中间是上下文工程的基本操作。3.2 上下文的分层视角人设层、状态层、知识层、即时层如果从“信息职能”来分类上下文还可以分成四层。我一般这样划分人设层——对应系统指令和固定的任务模板。这层信息描述 Agent 的角色、行为边界、输出格式、解决什么类型的问题。它的特点是几乎恒定不变每一轮对话都要带上但内容必须精简因为它会长期占用上下文空间。写系统指令时我习惯控制在 500 token 以内只交代“你是谁、你要做什么、你不做什么”。状态层——对应对话历史和工具调用历史。它记录 Agent 到目前为止“做过什么”“得到过什么结论”“当前处于哪一步”。这层是动态的每轮结束都会追加新的内容也是上下文膨胀的主要来源。状态层的管理策略就是“取舍”——保留对后续任务有影响的信息压缩或丢弃纯过渡性的内容。知识层——对应 RAG 检索到的文档、外部数据库查询结果、预先准备的参考材料。这层信息通常不是用户主动输入的而是 Agent 按需拉取的外部知识。知识层的关键在于“按需注入”——不要在对话一开始就把所有知识塞进上下文而是等 Agent 需要的时候再检索对应片段塞进去。这样可以大幅节省 token 预算。即时层——对应当前用户输入、最近一次工具返回的原始数据。这层直接决定了模型本轮做出什么决策。即时层的优先级最高——即使上下文前面写得不够好模型通常也会优先响应最后出现在窗口里的信息。理解了这个分层你在设计和排查 Agent 行为时就多了一个维度模型表现不对劲时先问一句——是状态层丢了关键信息还是知识层注入的内容和用户问题矛盾还是人设层写得含糊导致模型不知道自己的职责边界大多数 Agent 故障都能归到这四个层的某一段上。3.3 框架视角Agent 框架中的上下文变量是怎么设计的最近热度很高的几个 Agent 框架比如 Swarm、DeepAgent、Hermes Agent、Pi Agent它们的上下文设计逻辑各有侧重。我把它们看成三种典型范式范式一显式上下文变量传参典型代表Swarm。Swarm 框架里有一个很核心的概念叫“上下文变量Context Variables”它和普通的函数参数不一样是用来在整个 Agent 运行过程中跨步骤共享数据的。比如说第一步工具调用获取了用户信息后续步骤就不用重新读取而是从上下文变量里直接取值。这种设计的好处是状态透明排障容易——你随时可以打印出当前上下文变量列表看看哪个数据丢了或覆盖了。缺点是变量多了之后Agent 需要手工维护变量名和数据生命周期工程复杂度随之上升。范式二隐式全历史回放典型代表Claude Code 这类编程 Agent。框架不主动管理哪些信息重要、哪些不重要而是把全部对话历史、工具返回、文件读取记录一股脑放在上下文里。好处是信息完整、实现简单坏处是随着对话轮次增多token 消耗和“lost in the middle”问题会越来越严重。这类框架的共同解法是“压缩”——把早期对话摘要成几句话腾出空间给新内容。范式三混合编排式典型代表各类企业级 Agent 框架。框架允许开发者对上下文做精细化控制可以设定哪些系统内容常驻、哪些对话历史保留最近 N 轮、哪些外部知识按需检索注入。这种设计最灵活也最难配置因为你要理解业务场景中哪些信息是必要的哪些是噪音。我建议做 Agent 开发的人先把这三个范式都跑一遍。跑 Swarm 理解显式变量跑 Claude Code 理解长上下文场景下的压缩需求再上手一个混合式框架理解工程化调度。三套都跑完你对“上下文的构成”才算真正建立起了体感。3.4 上下文数据流从输入到输出是如何流转的上下文不是静态的它在一次 Agent 运行中会经历“组装—消费—更新—再组装”的循环。理解这个数据流对排查问题至关重要。我把它拆成五步第 1 步初始化。框架读取配置组装系统指令、工具定义、用户初始输入形成第一轮上下文。第 2 步模型推理。上下文作为输入模型生成输出。这个输出可能是最终回答文本也可能是一个工具调用请求。第 3 步工具执行。如果是工具调用请求框架解析出工具名称和参数执行对应函数比如调用 API、读文件、跑命令得到原始返回结果。第 4 步结果回填。框架把工具返回结果附加到上下文中形成新一轮的上下文——模型现在能“看得到”自己上次调用的结果了。第 5 步迭代循环。回到第 2 步模型基于更新后的上下文继续推理直到触发停止条件完成目标、达到最大轮数、模型主动结束。这个循环中最容易出问题的就是第 4 步——工具返回结果有没有被正确回填。很多时候 Agent 出现“明明调用了工具却像没调用过一样”的情况就是因为框架把工具结果截断了、格式化了错误、或者压根没拼进上下文。排查这类问题时直接把框架渲染出来的完整 prompt 打出来看看一目了然。4. 上下文管理实操预算分配、压缩策略与持久化4.1 上下文 Token 预算分配一段可以抄的配置经验上下文窗口不是越大越好而是要“花在该花的地方”。我自己的经验是把上下文窗口当成一个预算表来分配而不是等它满了再去截断。下面是一套我常用的预算分配逻辑以 128K约 131072 token窗口为例上下文部分预算占比说明系统指令1%~3%只写不可省略的角色、约束、输出规范工具定义5%~15%有多少个工具就要多少空间工具越多占用越大对话历史30%~50%保留最近 N 轮完整对话更早的做摘要压缩RAG 知识20%~30%按需注入每次检索只取命中片段不整篇灌入工具返回10%~20%关键返回值完整保留长日志做截断当前用户输入/输出5%~10%当前任务的最新信息你可能会注意到这份预算表的核心逻辑是“压缩中间、保全两端”。系统指令和当前输入是模型最敏感的区域必须完整保留对话历史和工具结果信息量大但优先级相对低是可以压缩和摘取的对象。到这里你可能会冒出一个问题这不是把问题弄复杂了吗我的回答是如果你做的是只有两三个工具的简单 Agent随便放都没问题。但当你开始做真正复杂的 Agent——比如一个带 20 个工具、需要跨 50 轮对话、每小时执行上百次调用的自动化工作流——不建立预算管理上下文一定会失控。我见过太多项目上线后模型表现突然下滑最后一查原因全是上下文里堆积了太多无用信息。4.2 上下文压缩与截断给 Ultra Long Context 场景的几种策略长上下文窗口带来一个实际工程问题窗口再大只要任务够长总有塞满的一天。所以上下文管理必不可少。这里分享三种我在项目中实际用过的策略按“从轻到重”排列。策略一滑动窗口截断Rolling Window。最朴素的方式只保留最近 N 轮对话超过的部分直接丢弃。适合工具调用频率不高、各轮之间关联度较低的场景。优点是零成本、实现简单、响应速度快缺点是信息损失大Agent 可能忘记早期的任务约束导致后续行为偏航。策略二摘要压缩Summarization。当对话历史超过阈值时用模型把早期对话压成一段摘要放进上下文顶部。摘要保留关键结论与决策理由但去掉对话过程细节。这个方案能保留远期的关键信息同时控制 token 增长但有两个坑一是摘要本身要花一次模型调用有额外成本二是摘要可能失真模型概括时漏掉影响后续判断的细节——缓解办法是用带结构的摘要模板强制要求摘要包含“已完成目标”“未完成事项”“当前障碍”三个字段。策略三外部记忆持久化External Memory。把对话历史和中间结果存到外部存储比如向量数据库每轮只把与当前任务最相关的记忆片段以 RAG 方式检索回来。这个方案几乎不受上下文窗口限制适合超长任务、跨会话续跑的场景。代价是要维护一套检索系统和记忆索引工程复杂度上了一个台阶。我实际做过的项目里大多数时候是混合策略RAG 只检索知识库不检索对话历史对话历史用摘要 滑动窗口组合管理工具返回结果按大小分两类小的完整保留大的压缩成结论。这套混合方案在长任务里跑了两个月模型稳定性明显优于单用任何一种策略。4.3 上下文持久化与跨会话恢复续跑的前提条件还有一个和上下文构成强相关的问题跨会话恢复。很多人用 ChatGPT 时都会遇到切账号之后上下文丢失、对话记录加载不出来的情况——这在 Agent 开发里同样是常见问题。核心原因是上下文没有做持久化session 一断所有历史状态全没了。做 Agent 上下文持久化时需要在数据库里存三类信息对话消息记录用户消息、助手消息、工具调用记录、上下文变量快照当前任务状态、已获取的数据、压缩摘要早期对话的提炼结果。恢复时先从库里读出摘要和变量再把最近的原始对话载入上下文组成一个“带记忆的新 session”。这里有个实操细节恢复时不要把全部历史都塞进上下文因为模型可以从摘要获得远期的背景信息而近期对话只需要保留最近几轮就够。否则你又回到了“上下文膨胀—性能衰减”的老路上。所以持久化恢复的核心理念是上下文里只放“模型做下一代决策真正需要的信息”其余的都放到外部存储里等着按需取用。5. 常见问题与排查技巧实录5.1 与长上下文相关的典型疑问先整理几个我经常被问到的、也是网上热度很高的问题。问1M 上下文是什么意思是不是必须开启才能用1M 上下文就是模型单次可处理约 100 万 token 的输入窗口。很多大模型产品把它作为高级功能或灰度功能默认可能只有几百 K。如果你的场景是短对话、单次分析没必要强行开启。但跑 Agent 长任务、处理大代码库、分析超长文档时1M 窗口能明显减少“对话中段遗忘”的问题值得开启。问上下文长度设置多少合适设置上下文长度不是“越大越好”。窗口设得过大显存/内存消耗随之上涨响应速度也会下降。我的经验是先按任务类型估算简单 QA 场景 4K~8K 足够需要多轮工具调用的 Agent 起步 32K~64K跑超长代码分析或文档处理再考虑 128K 以上。等你发现“截断历史导致模型遗忘关键信息”时再逐步往上加不要一上来就拉满。问为什么模型多轮对话之后表现越来越差绝大多数原因是早期重要信息被滚动截断了。排查思路是检查历史压缩策略里有没有保留“任务目标”和“关键结论”确认工具结果有没有被完整回填确认早期系统指令没有被后续对话淹没。我的常用补救办法是定期把“当前任务目标 已完成步骤清单”重写一遍放到上下文头部模型会重新聚焦。问自定义模型是否适合拿来做 Agent 底座如果模型本身不支持工具调用或指令遵循能力弱做 Agent 会非常吃力。你能在开源模型上跑 Agent但要做好心理准备——指令遵循、复杂多步推理、从错误中恢复这三项能力是 Agent 对模型的核心要求。我的排序建议是CLI Agent 用支持工具调用的前沿 API 模型最省心本地部署场景优先选在 Agent benchmark 上有公开成绩的模型而不是只看通用榜单分数。5.2 上下文工程里的排查三板斧排查 Agent 上下文问题时我一般按以下顺序操作——这条“三板斧”路径等于把黑盒变成白盒第一板斧打印完整 Prompt。把框架提交给模型前的最终上下文完整打印出来人工过一遍往往一眼就能看出问题工具返回被截断、对话历史顺序颠倒、系统指令被淹没在中间。这一步能解决 50% 以上的问题。第二板斧检查 Token 消耗分布。记录每一轮的 token 使用情况看哪一部分增长最快。如果 80% 的 token 都花在工具返回值上了说明工具返回的截断和压缩策略没有生效如果对话历史增长异常说明循环中没有正确实施历史压缩。第三板斧做最小回归测试。把复杂任务降维成一个简单测试用例只测某一个上下文环节是否正常。比如“只保留系统指令和一句输入调用一个工具看模型能否按预期推理”。逐环节加回复杂度就能定位问题出在哪一层。这三步听起来简单但恰恰是很多 Agent 项目里被跳过的步骤。我见过太多团队花一小时在模型选型上争论却不愿意花十分钟看一眼实际发给模型的 prompt 是什么样的。上下文工程的第一原则就是先看清事实再谈优化。5.3 关于模型选型与低资源部署的一点补充和上下文构成同样影响 Agent 效果的因素是模型本身的底座能力。如果你在本地部署 Agent低显存运行模型是现实需求。我的经验是低于 8GB 显存基本告别本地跑 7B 以上模型的 Agent 场景就算勉强跑起来推理速度也慢到无法支撑高频工具调用。可以考虑量化版本比如 4bit但要做好能力下降的心理准备。另一个思路是“小模型 大模型”混合调度本地小模型负责工具调用和简单任务复杂推理转发给云端大模型——这也是目前不少 Agent 框架推荐的架构。另外关于模型学习相关的热搜词汇——比如“深度学习”“强化学习”“transformer 模型”之类——如果你想在 Agent 领域深耕这些底子迟早要补。但我的建议是不要为了“学习”而学习而是带着 Agent 项目里的实际问题去补。比如你发现模型在长任务里遗忘严重就可以去读 transformer 的注意力机制和位置编码原理如果你做的是让 Agent 通过奖励信号优化行为策略再去认真看强化学习。问题驱动的学习路径效率远高于从教材第一页开始刷。写给同行的一段话做 Agent 项目这一年多最大的感受是这个领域看起来每天都有新框架、新模型、新概念但剥开外壳真正决定成败的还是那些最基础的东西——模型能力、上下文组织、状态管理、工具调用的正确性。“模型的学习”和“上下文的构成”这两个话题本质上是同一枚硬币的两面模型会“学”什么取决于你在上下文里“教”了什么。把上下文工程做扎实了你的 Agent 就赢在起跑线上了。希望这篇精读能帮你少踩几个坑。 
长河君 · 2026/9/29 23:12:23 · 阅读 1.2k Agent必读：模型“学习”真相与上下文工程实战指南
1. 先把概念说清楚Agent场景里“模型的学习”到底指什么前两天我在梳理 Agent 技术栈的时候发现一个特别容易混淆的点很多人把“Agent 会学习”挂在嘴边但真去追问他“模型到底是怎么学习的”往往就说不清了。这不是基础不基础的问题是整个 Agent 领域的术语本身就容易绕晕人。所以这篇精读的开头我先把这块最容易产生误解的地基给铲平。先说我的结论Agent 场景中“模型的学习”绝大多数时候指的不是重新训练模型也不是给模型喂更多数据做微调而是指模型在推理过程中利用上下文信息进行“动态学习”的能力。也就是所谓的 In-Context Learning上下文学习。模型本身的权重没有变化但它在读取上下文的时候能够从你给它的示例、工具返回结果、历史对话中“现学现用”。这就像你临时拉了一个人进项目组不需要他重新上大学只需要给他看两三条过往项目文档他就能立刻上手干活——这就是 Agent 的“学习”。为了更严谨我把 Agent 项目中“模型的学习”拆成了三个层面第一个层面是权重学习Weight Learning。这是传统意义上的“训练”发生在模型真正投入使用之前比如预训练、指令微调、RLHF。这一层决定了模型的基础能力但它在 Agent 运行过程中不会发生。你不可能在 Agent 跑任务的时候实时去改模型权重成本太高也没有这个必要。第二个层面是实例对齐Example Alignment也就是把几个 few-shot 示例塞到 prompt 里。很多人认为这只是在“给模型看例子”但更准确的比喻是这是在给模型划定一个“答题风格”。比如说你给它看了三个客服对话案例它就会模仿案例里的语气、信息密度、追问方式。Prompt 里放例子本质上是在做“即时风格对齐”而不是在做“知识灌输”。第三个层面是上下文推理Context Reasoning这是 Agent 最核心的学习方式。模型把当前的任务描述、工具返回的报错信息、历史对话中已经尝试过的方案全部拼接在上下文里然后基于这些信息推导下一步动作。注意这些信息中有相当一部分是之前几轮才产生的换句话说模型是在“读过自己刚刚做过的事情之后”再来决定下一步怎么做——这是一种动态的、边做边学的机制。这三个层面搞清楚之后你就不难理解一个关键问题了为什么 Agent 项目里大家疯狂追求长上下文因为上下文就是 Agent 的“短期工作记忆”。窗口越长模型能“读到”的历史越多能做的推理就越连贯。1M 上下文之所以成为热门话题就是因为它在工程层面把工作记忆的容量拉到了一个新的量级。理解了这一点我们再往下看上下文怎么构成就顺理成章了。2. Agent 的“学习”机制核心是上下文工程2.1 从提示词工程到上下文工程到底发生了什么变化这两年圈子里有个明显的趋势——大家讨论的重心逐渐从“提示词工程Prompt Engineering”转移到了“上下文工程Context Engineering”。这两个词的区别一开始我以为是噱头真正跑过几个 Agent 项目之后才发现两者完全不在一个层级上。提示词工程的关注点是怎么用一段精心构造的文字让模型给出更好的回答。它的对象是单轮、短文本、模型内部的 pattern matching。你调的是措辞、结构、语气本质上是在“哄模型”。上下文工程的关注点是怎么构造、组织、管理模型读取到的所有信息让 Agent 在多轮工具调用中保持稳定和高效。它的对象是多轮、跨工具、动态变化的完整信息流。你调的是哪些信息该放进来、放在什么位置、什么时候该丢弃、什么时候该滚动出窗口。我举个具体例子。单轮提示词工程里你写“请扮演一位资深运维专家帮我分析这段日志”——这就是全部了。但在 Agent 场景里你需要同时管理系统指令、用户当前问题、上一次工具调用返回的报错堆栈、前三次尝试过的命令行历史、从知识库里检索到的运维文档片段、以及本轮模型的推理轨迹。这些信息加起来可能超过一万 token。这时候你面临的核心问题已经变了——不是怎么把问题问得更清楚而是怎么在一堆信息里让模型找到它真正需要的部分。这就是上下文工程的活儿。在我自己的 Agent 开发经验里提示词工程大概只占整个上下文设计的 20% 工作量剩下 80% 都在做信息架构什么东西该常驻什么东西该按需注入什么东西该压缩什么东西该直接扔掉。如果你还停留在“把 prompt 写漂亮一点”的思路来做 Agent大概率会被上下文爆炸、模型跑偏、工具调用失序这些问题折磨得焦头烂额。2.2 Agent 为什么离不开长上下文滑动窗口的启示长上下文不是炫技而是 Agent 工作方式的硬性需求。要理解这一点可以从一个和 Agent 关系密切的经典算法——滑动窗口滤波模型——说起。滑动窗口滤波模型的核心思想是只对最近一段时间窗口内的数据进行处理窗口外的旧数据逐步衰减或丢弃。这个算法在信号处理、时间序列预测、流式计算中广泛应用而在大模型场景里它几乎就是 Transformer 注意力机制的一种直观形态——模型在生成当前 token 时注意力权重只会集中在它可见的上下文范围之内超出范围的内容对当前生成结果“不可见”。Agent 的推理过程也类似每一轮工具调用之后都会产生新的信息工具返回值、错误日志、中间结果这些信息进入上下文后会构成后续推理的依据。模型相当于在一个“滑动的上下文窗口”上持续做决策——窗口够长就能覆盖更多的历史信息和工具调用链条窗口被截断它就只能基于不完整的信息继续干活结果就是逻辑断裂、重复尝试、甚至幻觉。这也是为什么 Claude 的 1M 上下文一出来我身边做 Agent 的朋友几乎都在讨论它。1M token 意味着什么大约相当于《三体》三部曲的总字数。放到 Agent 场景里就是模型可以一次性把几十轮工具调用的完整历史、几千行代码文件、多份参考文档全部装进窗口而不需要频繁压缩和截断。做长任务、跑复杂工作流的时候这个优势是致命的。但注意长上下文不是越多越好。我实测过上下文窗口拉长之后模型对早期信息的“注意力”会被稀释——就算是 1M 窗口模型也并不是对窗口内每个 token 都一视同仁。实际经验是超过一定长度之后模型对中部内容的记忆效果明显变差这就是所谓的“lost in the middle”现象。所以与其盲目追求超长窗口不如学会“在合适的位置放合适的信息”。这就是我们接下来要说的内容上下文的构成。2.3 上下文如何影响模型输出一个形象的类比为了把“上下文影响”这件事讲得更直观我常用一个类比上下文就是模型在推理时拿到的“剧本卡”。想象一个演员模型上台演戏。他不可能临时背诵整个剧本而是靠场务Agent 框架在每一幕开始前递给他一叠卡片。卡片上可能写着你的角色设定系统指令、你现在在哪个场景当前目标、上一位演员刚刚说了什么对话历史、道具组临时改了什么工具返回值。这个演员演得好不好不只看他演技多强更要看场务递的卡片够不够清晰、有没有相互矛盾、有没有漏掉关键剧情。这个类比能帮你解释很多 Agent 开发中的怪现象为什么同一个模型在一个框架里表现惊艳换一个框架就蠢得像人工智障大概率不是模型的问题而是上下文组织方式变了。为什么有时候模型会反复调用同一个工具、陷入死循环因为上一轮调用返回的结果没有被正确地放进上下文模型压根不知道自己已经试过一次了。所以上下文不是简单的“信息堆叠”它直接影响模型的行为轨迹——这比单轮 prompt 的影响面要大得多。3. 上下文的构成从内到外拆解每一层信息3.1 上下文的物理构成一段拼接起来的 Token 序列要理解上下文的构成先看物理层面。大模型接收的输入本质上是一段 token 序列而 Agent 框架做的“上下文组装”工作就是把各种来源的信息按某种顺序拼接到这段序列里。一个典型的 Agent 上下文长这样按出现顺序系统指令System Prompt工具定义Tool Schemas对话历史Conversation History外部检索结果/知识库片段RAG Context用户当前输入Current User Message最近一轮工具调用的返回值Tool Result这套结构绝大多数 Agent 框架都类似区别在于顺序、截断策略、以及各部分占用的 token 预算。而在实际使用中模型最先读到的是头部内容最后读到的是尾部内容。头部内容系统指令和工具定义决定了模型的全局行为尾部内容工具返回值、当前输入决定了模型的立即行动中间部分对话历史、检索结果负责提供背景信息支撑。这就是为什么这类信息排列顺序是有讲究的把不该被忽略的信息放在头部或尾部把次要信息放在中间是上下文工程的基本操作。3.2 上下文的分层视角人设层、状态层、知识层、即时层如果从“信息职能”来分类上下文还可以分成四层。我一般这样划分人设层——对应系统指令和固定的任务模板。这层信息描述 Agent 的角色、行为边界、输出格式、解决什么类型的问题。它的特点是几乎恒定不变每一轮对话都要带上但内容必须精简因为它会长期占用上下文空间。写系统指令时我习惯控制在 500 token 以内只交代“你是谁、你要做什么、你不做什么”。状态层——对应对话历史和工具调用历史。它记录 Agent 到目前为止“做过什么”“得到过什么结论”“当前处于哪一步”。这层是动态的每轮结束都会追加新的内容也是上下文膨胀的主要来源。状态层的管理策略就是“取舍”——保留对后续任务有影响的信息压缩或丢弃纯过渡性的内容。知识层——对应 RAG 检索到的文档、外部数据库查询结果、预先准备的参考材料。这层信息通常不是用户主动输入的而是 Agent 按需拉取的外部知识。知识层的关键在于“按需注入”——不要在对话一开始就把所有知识塞进上下文而是等 Agent 需要的时候再检索对应片段塞进去。这样可以大幅节省 token 预算。即时层——对应当前用户输入、最近一次工具返回的原始数据。这层直接决定了模型本轮做出什么决策。即时层的优先级最高——即使上下文前面写得不够好模型通常也会优先响应最后出现在窗口里的信息。理解了这个分层你在设计和排查 Agent 行为时就多了一个维度模型表现不对劲时先问一句——是状态层丢了关键信息还是知识层注入的内容和用户问题矛盾还是人设层写得含糊导致模型不知道自己的职责边界大多数 Agent 故障都能归到这四个层的某一段上。3.3 框架视角Agent 框架中的上下文变量是怎么设计的最近热度很高的几个 Agent 框架比如 Swarm、DeepAgent、Hermes Agent、Pi Agent它们的上下文设计逻辑各有侧重。我把它们看成三种典型范式范式一显式上下文变量传参典型代表Swarm。Swarm 框架里有一个很核心的概念叫“上下文变量Context Variables”它和普通的函数参数不一样是用来在整个 Agent 运行过程中跨步骤共享数据的。比如说第一步工具调用获取了用户信息后续步骤就不用重新读取而是从上下文变量里直接取值。这种设计的好处是状态透明排障容易——你随时可以打印出当前上下文变量列表看看哪个数据丢了或覆盖了。缺点是变量多了之后Agent 需要手工维护变量名和数据生命周期工程复杂度随之上升。范式二隐式全历史回放典型代表Claude Code 这类编程 Agent。框架不主动管理哪些信息重要、哪些不重要而是把全部对话历史、工具返回、文件读取记录一股脑放在上下文里。好处是信息完整、实现简单坏处是随着对话轮次增多token 消耗和“lost in the middle”问题会越来越严重。这类框架的共同解法是“压缩”——把早期对话摘要成几句话腾出空间给新内容。范式三混合编排式典型代表各类企业级 Agent 框架。框架允许开发者对上下文做精细化控制可以设定哪些系统内容常驻、哪些对话历史保留最近 N 轮、哪些外部知识按需检索注入。这种设计最灵活也最难配置因为你要理解业务场景中哪些信息是必要的哪些是噪音。我建议做 Agent 开发的人先把这三个范式都跑一遍。跑 Swarm 理解显式变量跑 Claude Code 理解长上下文场景下的压缩需求再上手一个混合式框架理解工程化调度。三套都跑完你对“上下文的构成”才算真正建立起了体感。3.4 上下文数据流从输入到输出是如何流转的上下文不是静态的它在一次 Agent 运行中会经历“组装—消费—更新—再组装”的循环。理解这个数据流对排查问题至关重要。我把它拆成五步第 1 步初始化。框架读取配置组装系统指令、工具定义、用户初始输入形成第一轮上下文。第 2 步模型推理。上下文作为输入模型生成输出。这个输出可能是最终回答文本也可能是一个工具调用请求。第 3 步工具执行。如果是工具调用请求框架解析出工具名称和参数执行对应函数比如调用 API、读文件、跑命令得到原始返回结果。第 4 步结果回填。框架把工具返回结果附加到上下文中形成新一轮的上下文——模型现在能“看得到”自己上次调用的结果了。第 5 步迭代循环。回到第 2 步模型基于更新后的上下文继续推理直到触发停止条件完成目标、达到最大轮数、模型主动结束。这个循环中最容易出问题的就是第 4 步——工具返回结果有没有被正确回填。很多时候 Agent 出现“明明调用了工具却像没调用过一样”的情况就是因为框架把工具结果截断了、格式化了错误、或者压根没拼进上下文。排查这类问题时直接把框架渲染出来的完整 prompt 打出来看看一目了然。4. 上下文管理实操预算分配、压缩策略与持久化4.1 上下文 Token 预算分配一段可以抄的配置经验上下文窗口不是越大越好而是要“花在该花的地方”。我自己的经验是把上下文窗口当成一个预算表来分配而不是等它满了再去截断。下面是一套我常用的预算分配逻辑以 128K约 131072 token窗口为例上下文部分预算占比说明系统指令1%~3%只写不可省略的角色、约束、输出规范工具定义5%~15%有多少个工具就要多少空间工具越多占用越大对话历史30%~50%保留最近 N 轮完整对话更早的做摘要压缩RAG 知识20%~30%按需注入每次检索只取命中片段不整篇灌入工具返回10%~20%关键返回值完整保留长日志做截断当前用户输入/输出5%~10%当前任务的最新信息你可能会注意到这份预算表的核心逻辑是“压缩中间、保全两端”。系统指令和当前输入是模型最敏感的区域必须完整保留对话历史和工具结果信息量大但优先级相对低是可以压缩和摘取的对象。到这里你可能会冒出一个问题这不是把问题弄复杂了吗我的回答是如果你做的是只有两三个工具的简单 Agent随便放都没问题。但当你开始做真正复杂的 Agent——比如一个带 20 个工具、需要跨 50 轮对话、每小时执行上百次调用的自动化工作流——不建立预算管理上下文一定会失控。我见过太多项目上线后模型表现突然下滑最后一查原因全是上下文里堆积了太多无用信息。4.2 上下文压缩与截断给 Ultra Long Context 场景的几种策略长上下文窗口带来一个实际工程问题窗口再大只要任务够长总有塞满的一天。所以上下文管理必不可少。这里分享三种我在项目中实际用过的策略按“从轻到重”排列。策略一滑动窗口截断Rolling Window。最朴素的方式只保留最近 N 轮对话超过的部分直接丢弃。适合工具调用频率不高、各轮之间关联度较低的场景。优点是零成本、实现简单、响应速度快缺点是信息损失大Agent 可能忘记早期的任务约束导致后续行为偏航。策略二摘要压缩Summarization。当对话历史超过阈值时用模型把早期对话压成一段摘要放进上下文顶部。摘要保留关键结论与决策理由但去掉对话过程细节。这个方案能保留远期的关键信息同时控制 token 增长但有两个坑一是摘要本身要花一次模型调用有额外成本二是摘要可能失真模型概括时漏掉影响后续判断的细节——缓解办法是用带结构的摘要模板强制要求摘要包含“已完成目标”“未完成事项”“当前障碍”三个字段。策略三外部记忆持久化External Memory。把对话历史和中间结果存到外部存储比如向量数据库每轮只把与当前任务最相关的记忆片段以 RAG 方式检索回来。这个方案几乎不受上下文窗口限制适合超长任务、跨会话续跑的场景。代价是要维护一套检索系统和记忆索引工程复杂度上了一个台阶。我实际做过的项目里大多数时候是混合策略RAG 只检索知识库不检索对话历史对话历史用摘要 滑动窗口组合管理工具返回结果按大小分两类小的完整保留大的压缩成结论。这套混合方案在长任务里跑了两个月模型稳定性明显优于单用任何一种策略。4.3 上下文持久化与跨会话恢复续跑的前提条件还有一个和上下文构成强相关的问题跨会话恢复。很多人用 ChatGPT 时都会遇到切账号之后上下文丢失、对话记录加载不出来的情况——这在 Agent 开发里同样是常见问题。核心原因是上下文没有做持久化session 一断所有历史状态全没了。做 Agent 上下文持久化时需要在数据库里存三类信息对话消息记录用户消息、助手消息、工具调用记录、上下文变量快照当前任务状态、已获取的数据、压缩摘要早期对话的提炼结果。恢复时先从库里读出摘要和变量再把最近的原始对话载入上下文组成一个“带记忆的新 session”。这里有个实操细节恢复时不要把全部历史都塞进上下文因为模型可以从摘要获得远期的背景信息而近期对话只需要保留最近几轮就够。否则你又回到了“上下文膨胀—性能衰减”的老路上。所以持久化恢复的核心理念是上下文里只放“模型做下一代决策真正需要的信息”其余的都放到外部存储里等着按需取用。5. 常见问题与排查技巧实录5.1 与长上下文相关的典型疑问先整理几个我经常被问到的、也是网上热度很高的问题。问1M 上下文是什么意思是不是必须开启才能用1M 上下文就是模型单次可处理约 100 万 token 的输入窗口。很多大模型产品把它作为高级功能或灰度功能默认可能只有几百 K。如果你的场景是短对话、单次分析没必要强行开启。但跑 Agent 长任务、处理大代码库、分析超长文档时1M 窗口能明显减少“对话中段遗忘”的问题值得开启。问上下文长度设置多少合适设置上下文长度不是“越大越好”。窗口设得过大显存/内存消耗随之上涨响应速度也会下降。我的经验是先按任务类型估算简单 QA 场景 4K~8K 足够需要多轮工具调用的 Agent 起步 32K~64K跑超长代码分析或文档处理再考虑 128K 以上。等你发现“截断历史导致模型遗忘关键信息”时再逐步往上加不要一上来就拉满。问为什么模型多轮对话之后表现越来越差绝大多数原因是早期重要信息被滚动截断了。排查思路是检查历史压缩策略里有没有保留“任务目标”和“关键结论”确认工具结果有没有被完整回填确认早期系统指令没有被后续对话淹没。我的常用补救办法是定期把“当前任务目标 已完成步骤清单”重写一遍放到上下文头部模型会重新聚焦。问自定义模型是否适合拿来做 Agent 底座如果模型本身不支持工具调用或指令遵循能力弱做 Agent 会非常吃力。你能在开源模型上跑 Agent但要做好心理准备——指令遵循、复杂多步推理、从错误中恢复这三项能力是 Agent 对模型的核心要求。我的排序建议是CLI Agent 用支持工具调用的前沿 API 模型最省心本地部署场景优先选在 Agent benchmark 上有公开成绩的模型而不是只看通用榜单分数。5.2 上下文工程里的排查三板斧排查 Agent 上下文问题时我一般按以下顺序操作——这条“三板斧”路径等于把黑盒变成白盒第一板斧打印完整 Prompt。把框架提交给模型前的最终上下文完整打印出来人工过一遍往往一眼就能看出问题工具返回被截断、对话历史顺序颠倒、系统指令被淹没在中间。这一步能解决 50% 以上的问题。第二板斧检查 Token 消耗分布。记录每一轮的 token 使用情况看哪一部分增长最快。如果 80% 的 token 都花在工具返回值上了说明工具返回的截断和压缩策略没有生效如果对话历史增长异常说明循环中没有正确实施历史压缩。第三板斧做最小回归测试。把复杂任务降维成一个简单测试用例只测某一个上下文环节是否正常。比如“只保留系统指令和一句输入调用一个工具看模型能否按预期推理”。逐环节加回复杂度就能定位问题出在哪一层。这三步听起来简单但恰恰是很多 Agent 项目里被跳过的步骤。我见过太多团队花一小时在模型选型上争论却不愿意花十分钟看一眼实际发给模型的 prompt 是什么样的。上下文工程的第一原则就是先看清事实再谈优化。5.3 关于模型选型与低资源部署的一点补充和上下文构成同样影响 Agent 效果的因素是模型本身的底座能力。如果你在本地部署 Agent低显存运行模型是现实需求。我的经验是低于 8GB 显存基本告别本地跑 7B 以上模型的 Agent 场景就算勉强跑起来推理速度也慢到无法支撑高频工具调用。可以考虑量化版本比如 4bit但要做好能力下降的心理准备。另一个思路是“小模型 大模型”混合调度本地小模型负责工具调用和简单任务复杂推理转发给云端大模型——这也是目前不少 Agent 框架推荐的架构。另外关于模型学习相关的热搜词汇——比如“深度学习”“强化学习”“transformer 模型”之类——如果你想在 Agent 领域深耕这些底子迟早要补。但我的建议是不要为了“学习”而学习而是带着 Agent 项目里的实际问题去补。比如你发现模型在长任务里遗忘严重就可以去读 transformer 的注意力机制和位置编码原理如果你做的是让 Agent 通过奖励信号优化行为策略再去认真看强化学习。问题驱动的学习路径效率远高于从教材第一页开始刷。写给同行的一段话做 Agent 项目这一年多最大的感受是这个领域看起来每天都有新框架、新模型、新概念但剥开外壳真正决定成败的还是那些最基础的东西——模型能力、上下文组织、状态管理、工具调用的正确性。“模型的学习”和“上下文的构成”这两个话题本质上是同一枚硬币的两面模型会“学”什么取决于你在上下文里“教”了什么。把上下文工程做扎实了你的 Agent 就赢在起跑线上了。希望这篇精读能帮你少踩几个坑。