Agent 上下文怎么管：五个组件与优先级排序

如果你做过 Agent，多半遇到过这种翻车：让它「查一下公司今年的差旅政策并总结」，它给出一份结构漂亮、条目齐全的答案。你差点转发出去，才发现政策里没有的内容它也写了。换更强的模型一样翻。根源不在模型，而在前一步——整个过程中，Agent 从来没有真正读到过那份文件。文件在磁盘上，但没进上下文。

这篇就拆开「上下文」这只眼睛：每一次调用大模型时到底传了什么、哪一块拆了会报废、长任务怎么管预算。适合刚上手 Agent 开发、想搞清楚幻觉从哪来、以及准备做上下文压缩的读者。

一、每次调用，上下文里到底装了什么

从 API 视角看，Agent 每次调用 LLM，传进去的上下文由五部分组成。先记住一个生活化的比喻：系统提示词是新员工的岗位说明书，工具定义是手部说明书，剩下三块是任务源源、模型一侧的输出、以及环境的真实反馈。

• 系统提示词：由开发者编写，定义角色、权限边界、行为准则、工作流程，此外还常拼入用户记忆和当前环境状态。它不是静态文本，有一部分每轮都要重新组装。
• 工具定义：包含名称、功能、参数格式，构成行动能力的基础。没有它，模型只能输出纯文本。
• 用户消息：当前请求，加上 RAG 检索到的外部知识、私有领域知识、训练截止后的新信息。检索增强本质上是把检索结果伪装成用户的一部分送进去。
• 模型回复：含 reasoning（内部思考）、content（给用户的文本）、tool_calls（调用请求）三类。注意三者不一定同时出现：要动手时通常是 reasoning 加 tool_calls，给最终答案时是 reasoning 加 content。
• 工具执行结果：搜索结果、API 返回、文件内容、命令输出、页面状态。这是模型下一步决策唯一直接的现实依据。

二、静态前缀与轨迹：两种性质完全不同的管理工作

五块东西容易记乱，换一种切分方式立刻清楚：上下文 = 静态前缀 + 轨迹。静态前缀是系统提示词加工具定义，每次请求原样重放，长度基本不变；轨迹是用户消息、模型回复、工具执行结果，随交互不断向窗口末尾追加，只增不减。

这个视角直接把「上下文工程」劈成两件事：管静态前缀是信息设计问题——写什么、不写什么、按什么顺序排；管轨迹是预算管理问题——哪些该留、哪些能压、哪些能重建。短任务里只增不减是优点，长任务里跑几十步窗口就被撑爆，这时压缩、摘要、丢弃低价值步骤就成了必选项，而压缩的依据正是下一节的组件分级。

还有两个工程细节值得注意：一是新式框架开始支持把完整工具 schema 按需动态加载到窗口末尾，而不是开局全塞进去——工具一多，开局全塞会让上下文迅速膨胀，而多数任务只用到其中一两个。二是用户记忆与环境状态放进系统提示词，意味着这部分每轮都要重新拼装，别把它当静态文本处理。

三、做一次消融实验：哪个组件拆了会报废

原书给了一个很干净的做法：每次只从完整上下文里移除一个组件，与完整基线对照，看 Agent 退化多少。注意系统提示词不参与消融——没有它，Agent 连自己是谁都不知道，测出来的只是模型底线，没有解释力。另外，这组消融得出的是定性判断，不是分数。结果如下：

四者的相对次序是：工具定义 ≈ 工具执行结果 > 历史消息 > 思考过程。前两个拆了就报废，历史消息拆了会转圈，reasoning 能重建就能扔。其中最值得记住的是 reasoning 的定位：它是一份可重建的记录，而不是不可替代的信息源。这也解释了为什么很多上下文压缩方案优先砍思考过程。

这里有个坑必须点破：很多人以为在提示词里写一句「不得自行估计、必须依据工具返回结果」就能消除幻觉。提示词是软约束，只能降低编造概率，模型仍有概率偏离。要真正兜住只有两条路：工具层面的验证，以及对结果合理性的校验。

四、这套结论什么时候会失效

上述次序很好用，但边界必须说清楚，否则容易当成普适常数照抄。

• 不是每个任务都要凑满五块。纯问答任务里工具定义和工具结果都是空的，只有系统提示词、用户消息加一次回复。五组件是完整形态的分析框架，不是必填表格。
• 「reasoning 可压缩」有前提：它真的能被重建。若某条推理依赖未被记录、也无法从环境反推的判断依据，删掉就是净损失。重建成本低的可以压，成本高的必须留，不能一刀切。
• 重要性依赖具体任务，必须实测。信息检索为主的任务里历史消息价值可能远高于工具定义；多轮工具调用的编码任务反过来。别照抄结论，去跑自己的消融。
• 长任务的上下文预算是硬约束。轨迹只增不减，跑几十步窗口被撑爆后，压缩、摘要、丢弃低价值步骤成为必选项，前面的分级判断正好充当取舍依据。消融实验在长任务里的价值比短任务大得多。
• 上下文里有 ≠ 模型会用。塞十条规则模型可能一条不守，塞三页文档可能一行不读。难点不只是放什么，还有放进去之后模型看不看得进去。

小结

最后带走路四条判断。第一，上下文决定 Agent 能看到什么，而 Agent 只能基于它看到的信息决策——文件在磁盘上不等于它看到了。第二，工具定义缺失时，模型会用参数记忆冒充观察，提示词约束压不住幻觉，必须靠工具验证。第三，reasoning 是可重建的记录、不是不可替代的信息源，压缩时优先考虑它。第四，也是最贵的一条：「给出了回答」不等于「完成了任务」。上下文残缺时 Agent 往往不报错，而是给一个看起来合理但没有依据的答案。很多 Agent 评测之所以好看，测的只是有没有给出回答，而不是任务有没有完成——这两个指标之间隔着的，正是上下文里缺的那几块。

本文基于 rss-juejin《上下文：Agent 的眼睛里到底装着什么》深度重写，事实与观点归原作者所有。建议阅读原文。原作者：米小虾。发布于 2026-10-15。