1. 从“信息过载”到“精准聚焦”：为什么你的Agent需要上下文预算

最近在折腾各种AI Agent项目，从Hermes Agent到DeepSeek Agent，再到自己动手搭一些简单的任务自动化脚本，我发现一个特别普遍又容易被忽视的问题：Agent的表现，很多时候不是输在模型能力上，而是栽在了“信息处理”上。你给它一堆文档、聊天记录、代码片段，指望它自己理出头绪，结果它要么抓不住重点，要么在无关的细节里打转，甚至直接“失忆”，把前面刚说过的关键信息给忘了。这感觉就像让一个助手同时处理十个会议纪要，最后他可能连会议主题都记混了。

问题的核心，就是我们今天要聊的“上下文预算”。这听起来像个财务术语，但在Agent开发里，它关乎生死。简单说，上下文预算就是你的Agent在单次思考或对话中，能够有效处理和参考的信息总量上限。这个上限不是由你决定的，而是由底层大语言模型的“上下文窗口”大小决定的。比如，一个模型支持8K上下文，那你的预算就是大约8000个token（可以粗略理解为4000个汉字）。

但关键不在于这个数字有多大，而在于你怎么花这笔“预算”。不加节制地把所有历史对话、系统指令、知识库文档都塞进去，必然导致预算超支。超支的后果不是简单的“装不下”，而是模型性能的急剧下降：关键信息被边缘化或遗忘（所谓的“中间层衰减”），回答变得冗长且偏离主题，处理速度变慢，成本还飙升。因此，“上下文预算管理”的本质，是教会你的Agent在有限的“注意力”和“记忆力”范围内，学会“看什么”以及“记住什么”，从而实现精准、高效且稳定的任务执行。

无论是做客服机器人、代码助手，还是复杂的多步工作流自动化，理解并实施上下文预算策略，都是从“玩具Demo”走向“可用产品”的关键一步。接下来，我们就拆开看看，这笔预算到底该怎么规划、怎么花、怎么省。

2. 拆解上下文预算的构成：你的Token都花在哪了？

在开始制定预算策略前，我们得先搞清楚Agent的一次典型调用中，上下文（即输入的Prompt）到底由哪些部分构成，每一部分都在消耗我们宝贵的Token。通常，一个功能完整的Agent Prompt模板会包含以下几个核心模块，我们可以把它们想象成一份报告的各个章节。

2.1 系统指令与角色设定：固定开销

这部分是Agent的“人设”和“基本原则”，通常放在Prompt的最开头。它定义了Agent的身份、核心职责、行为规范和回复格式。

• 内容示例 ：“你是一个专业的IT技术支持助手。你的职责是清晰、准确地回答用户关于网络、硬件和软件的问题。回答需分点说明，优先提供解决方案步骤。如果问题超出范围，应礼貌说明并引导至正确渠道。不要编造信息。”
• 消耗特点 ：相对固定，一次设定，多次使用。虽然它占用了预算，但这是必要的“固定成本”，确保了Agent行为的一致性。在长对话中，为了避免重复消耗，有时会采用“缩略指令”或依赖模型的“系统提示”功能（如果API支持），但明确写出仍是可靠的做法。

2.2 对话历史：最大的可变成本

这是上下文预算中最容易失控的部分。包括用户与Agent之间的多轮问答。每一轮对话（User: ... Assistant: ...）都在累积Token。

• 消耗特点 ：随着对话轮数增加而线性（甚至指数，如果包含长回复）增长。是导致预算超支的“头号元凶”。
• 管理关键 ：不是存得越多越好。十轮前的闲聊对解决当前的一个具体技术问题可能毫无帮助，反而会稀释关键信息的浓度。因此，对话历史管理策略是预算管理的核心，我们会在第三节详细讨论。

2.3 检索到的知识或工具输出：精准投资

当Agent需要调用检索增强生成（RAG）从知识库查资料，或者调用某个工具（如计算器、搜索引擎、API）并获取结果时，这些外部信息会被插入到上下文中。

• 内容示例 ：“[根据知识库检索] 关于‘SSL证书过期’的解决方案：1. 检查证书有效期... 2. 联系证书颁发机构续订... 3. 在服务器上更新证书文件...”
• 消耗特点 ：这是“投资性”支出。我们消耗Token引入这些信息，是为了让Agent基于更准确的依据来回答。关键在于 精准和简洁 。检索系统应该返回最相关、最精简的片段，而不是整篇文档。工具的输出也应该被格式化或摘要，只保留核心结果。

2.4 当前用户查询与任务描述：目标本身

即用户最新提出的问题或指令。这是整个上下文的“靶心”，所有其他信息都应该服务于它。

• 消耗特点 ：通常较短，是必须保留的核心部分。预算管理要确保这个“靶心”始终在模型的注意力范围内，不被其他冗杂信息淹没。

2.5 思维链或中间步骤：可控的推理开销

对于一些复杂任务，你可能要求Agent展示其思考过程（Chain-of-Thought），或者将多步工具调用的中间结果也保留在上下文中，以供后续步骤参考。

• 消耗特点 ：这是一把双刃剑。它有助于提升任务完成的可靠性和可解释性，但会显著增加Token消耗。需要权衡是否必要，以及是否可以对中间过程进行压缩。

一个简单的预算分配意识 ：假设你的模型上下文窗口是8K Token，你可以做一个粗略的规划：系统指令（500 Token）+ 当前查询（200 Token）+ 必要知识/工具结果（1000 Token）+ 思维链（500 Token）= 2200 Token。那么，你留给对话历史的预算就剩下5800 Token。这5800 Token，是用来保留完整的50轮简短对话，还是精挑细选最近5轮的关键对话？不同的策略将直接导致Agent表现的天壤之别。建立这种“预算构成”意识，是进行有效管理的第一步。

3. 核心策略：如何为Agent制定聪明的“观看”清单

知道了预算花在哪，接下来就是如何精明地花钱。我们的目标不是盲目地塞满上下文，而是精心策划一份“观看”清单，让Agent只看到对完成当前任务最关键的信息。这里有几个核心策略，从易到难，你可以根据Agent的复杂度进行组合使用。

3.1 策略一：对话历史摘要与滑动窗口

这是最基础也最有效的策略。其核心思想是：用一份简短的摘要来替代冗长的原始对话历史。

• 滑动窗口 ：最简单的方法。只保留最近N轮对话（比如最近3-5轮）。这基于“最近的信息最相关”的假设，对于短平快的对话非常有效。实现起来很简单，在代码中维护一个固定长度的队列即可。
• 增量摘要 ：更高级的方法。在每一轮或每几轮对话后，动态地生成一个对话摘要。当上下文快满时，不再放入原始对话，而是放入这份不断更新的摘要。例如：
  • 原始历史 （消耗大）：
    • User: 我的网站无法访问了。
    • Assistant: 请检查服务器状态和域名解析。
    • User: 服务器ping得通，域名也正常。
    • Assistant: 那检查一下Web服务（如Nginx）是否在运行。
    • User: Nginx服务是活跃的。
  • 增量摘要 （消耗小）：
    • “[对话摘要] 用户报告网站无法访问。已排除服务器连通性和域名解析问题，确认Web服务（Nginx）正在运行。当前待排查方向：端口监听、防火墙规则、应用本身。”
• 如何实现摘要 ：你可以让Agent自己生成摘要（在Assistant回复后，添加一个生成摘要的隐藏指令），也可以用一个小一点的、专用于摘要的模型来处理。关键是要把摘要做得客观、包含关键事实和待办事项，而不是观点。

注意 ：摘要会损失细节。如果后续问题突然涉及到很早之前对话里的一个具体数字（比如“你之前提到的那个IP地址是多少？”），摘要可能无法涵盖。因此，摘要策略通常需要配合一个“长期记忆”存储（如向量数据库）来弥补，当需要细节时再去检索。

3.2 策略二：基于查询的主动检索与过滤

这个策略将Agent从被动“观看”转变为主动“查阅”。它不依赖（或不全依赖）线性排列的对话历史，而是将所有可能有用的信息（历史对话、知识库条目、用户资料等）存储在一个可检索的数据库（通常是向量数据库）中。

• 工作流程 ：
  1. 接收到用户当前查询。
  2. 用该查询作为“检索键”，去向量数据库中搜索最相关的信息片段（通常是Top K个，比如3-5条）。
  3. 只将这些检索到的、高相关度的片段插入到本次调用的上下文中。
• 优势 ：
  • 精准 ：上下文里全是与当前问题强相关的内容，无关历史被自然过滤。
  • 突破窗口限制 ：理论上，你可以存储海量的历史信息，但每次只取用一点点，完全不受原始上下文窗口大小的限制。
  • 记忆持久 ：解决了传统对话模型“记不住”太久远信息的问题。
• 挑战 ：
  • 检索质量 ：高度依赖于嵌入模型的质量和检索算法的准确性。如果检索不到或检索错了，Agent就会“失明”。
  • 丢失时序与逻辑流 ：纯粹的检索可能会打乱对话的先后顺序和逻辑连贯性。比如，用户说“不对，我指的是上一个方案”，这种指代关系在检索片段中可能无法体现。因此，通常需要将“最近几轮对话（滑动窗口）”和“检索到的相关记忆”结合使用。

3.3 策略三：结构化上下文与智能路由

对于处理复杂、多步骤任务的Agent（比如一个能写代码、运行测试、调试错误的编程助手），我们可以将上下文结构化和模块化。

• 思路 ：不再使用一个“大一统”的、越来越长的Prompt。而是为不同的任务阶段或功能模块，设计不同的、精炼的“子Prompt”或“技能”。
• 示例 ：一个编程Agent的上下文管理。
  • 需求分析阶段 ：上下文主要是“系统指令（分析师角色）” + “用户原始需求描述”。此时不需要代码片段或错误日志。
  • 代码编写阶段 ：切换到“系统指令（程序员角色）” + “需求摘要” + “相关API文档片段（通过检索获得）” + “当前文件的部分代码（作为参考）”。
  • 调试报错阶段 ：切换到“系统指令（调试员角色）” + “错误信息” + “相关代码块” + “可能原因的常见解决方案（通过检索获得）”。
• 如何实现 ：这通常需要一个“控制器”或“路由Agent”来根据当前状态，动态组装最合适的上下文，并调用相应的功能模块。这就像给Agent配了一个项目经理，项目经理手里有各种专家的联系方式（子Prompt），根据项目阶段（任务状态）决定请哪位专家（使用哪个上下文）来干活。
• 好处 ：每个阶段的上下文都非常聚焦和纯净，预算用在刀刃上，避免了不同阶段信息的相互干扰。

3.4 策略四：Token级别的压缩与优化

这是一些更底层的技巧，旨在不损失语义的前提下，物理上减少Token数量。

• 指令优化 ：检查你的系统指令，是否过于冗长？能否用更简洁的语言表达同样的约束？例如，“你必须确保你的回答是准确和真实的，不要捏造任何信息”可以优化为“回答需准确，禁止虚构”。
• 精简输出格式 ：要求Agent的回复格式尽量简洁。避免不必要的礼貌用语、重复性解释。但这需要权衡用户体验。
• 使用更高效的Tokenizer ：不同的模型使用不同的分词器（Tokenizer）。同一个中文句子，用不同的分词器，产生的Token数量可能不同。虽然模型本身不能换，但在项目选型时，可以将“上下文窗口效率”作为一个考量因素。

策略组合建议 ：对于大多数实用型Agent，我推荐 “滑动窗口（最近3-5轮）+ 向量检索长期记忆 + 清晰系统指令” 的组合拳。这保证了对话的短期连贯性、长期知识的可获取性以及行为的稳定性，是性价比很高的方案。当任务极度复杂时，再考虑引入结构化和智能路由。

4. 实战避坑：开发中常见的上下文管理陷阱与解决方案

理论说完了，我们来点实在的。下面是我在开发Hermes Agent、DeepSeek Agent以及一些自定义项目时，踩过的几个典型坑，以及对应的解决思路。

4.1 陷阱一：“全量历史”导致的性能悬崖

这是新手最容易掉进去的坑。为了让Agent“记住一切”，简单地把所有对话历史都append到prompt里。在对话初期，一切正常。但当对话轮数超过某个阈值（例如，历史消耗达到上下文窗口的70%-80%），你会突然发现Agent开始出现以下症状：

• 回答开始偏离主题，甚至回答一些很久以前的问题。
• 对当前问题中最关键的细节视而不见。
• 生成速度变慢，API调用成本激增。

根因 ：这不仅仅是“装不下”的问题，更是大语言模型注意力机制的特性。当上下文过长时，模型对序列中间部分信息的注意力权重会显著下降（即“中间层衰减”），导致这些信息在计算时被“边缘化”。你的关键信息如果埋在了长长的历史中间，就等于白给了。

解决方案 ：

• 立即实施滑动窗口 ：这是最快的止血方案。确定一个安全的窗口大小，比如5轮。在代码中维护一个 conversation_history 列表，每次新的交互后，检查列表长度，如果超过5轮，就从头部移除最老的记录。

  # 伪代码示例
  max_history_turns = 5
  conversation_history = [] # 存储格式：[{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]
  
  def add_interaction(user_input, assistant_output):
      conversation_history.append({"role": "user", "content": user_input})
      conversation_history.append({"role": "assistant", "content": assistant_output})
      # 保持历史不超过最大轮数（注意：一轮包含user和assistant两条记录）
      if len(conversation_history) > max_history_turns * 2:
          conversation_history = conversation_history[-(max_history_turns * 2):]
  

• 引入摘要生成 ：对于需要长期记忆的场景，在滑动窗口的基础上，增加一个摘要生成器。每完成一个重要任务阶段，就生成一个阶段摘要，存入长期存储（如向量库或普通数据库），并从当前对话历史中移除该阶段的原始记录。

4.2 陷阱二：检索结果“喧宾夺主”

当你兴奋地接入了RAG，把一堆知识库文档喂给Agent后，可能会发现另一个问题：Agent的回答变成了知识库片段的简单复读或拼接，失去了它原有的推理和创造能力，甚至忽略了用户查询中的细微差别。

根因 ：检索到的文档片段被不加处理地、大量地塞入上下文，其Token数量和质量（信息密度）可能远远超过了原始查询和简短的历史。模型会倾向于“复现”它看到的大量文本，而不是“思考”后回答。

解决方案 ：

• 控制检索数量（Top-K）和质量 ：不要盲目返回Top 5或Top 10。先从Top 3开始，并设置一个相关性分数阈值，低于阈值的结果即使排在前列也不采用。你可以通过观察，找到一个质量和数量的平衡点。
• 对检索结果进行预处理 ：在将检索到的文本块插入上下文前，先做一个简单的处理。例如：
  • 提取核心句 ：用一个小模型或简单规则，从长段落中提取出最核心的一两句话。
  • 格式化 ：明确标注这是“[知识库参考]”，并将其放在一个独立的、结构化的区块里，与对话历史区分开。这有助于模型理解信息的来源和性质。
  • 指令引导 ：在系统指令中明确告诉Agent：“当你参考提供的知识库信息时，请基于它们进行推理和整合，而不是直接复制。如果用户问题与知识库信息有冲突，以你的最佳判断为准，并可以指出不一致之处。”
• 动态调整检索范围 ：根据当前对话的上下文来决定检索什么。例如，如果用户正在问一个非常具体的技术参数，就检索技术手册；如果用户在问操作流程，就检索教程文档。这需要更精细的检索路由设计。

4.3 陷阱三：系统指令与用户输入的角色混淆

这个坑比较隐蔽。有时你会发现Agent的行为变得怪异，比如用系统指令的口吻回答用户，或者把用户之前的一句话当成了新的系统指令。

根因 ：在拼接最终Prompt时，角色（Role）标记（如 system , user , assistant ）使用错误或丢失。特别是当你在运行时动态修改或添加系统指令时，容易出错。另外，如果用户输入中恰好包含了类似“你是一个...”的句子，也可能被模型误解。

解决方案 ：

• 严格遵循API的角色格式 ：无论是使用OpenAI格式、Claude格式还是本地模型的API，都必须严格按照其要求设置每条消息的 role 字段。这是模型区分指令、对话和自身回复的基础。
• 隔离系统指令 ：确保系统指令只出现在Prompt的开头，并且通常只有一条 system 消息。避免在对话中间再次插入 system 角色的内容。如果需要动态调整Agent行为，可以考虑在 user 消息中，以自然语言的形式给出新的指示（例如：“现在请切换角色，作为一个语法检查员来审核下面的文本。”），但这依赖于模型的理解能力，不如固定的系统指令稳定。
• 对用户输入进行简单的清洗 （谨慎使用）：对于高度可控的场景（如企业内部助手），可以设置一个过滤器，如果用户输入以某些特定关键词（如“我命令你”、“系统指令：”）开头，则进行拦截或特殊处理，但这会影响用户体验，需权衡。

4.4 陷阱四：在多轮复杂任务中“迷失目标”

Agent在处理一个需要多步交互的复杂任务时（比如帮用户规划一个旅行行程，需要多次确认偏好），可能会在第五轮对话时，完全忘记第一轮对话中用户设定的核心约束（比如“预算不超过5000元”）。

根因 ：纯粹的滑动窗口策略，在窗口之外的早期关键信息会被丢弃。而如果依赖检索，又可能因为早期信息的嵌入向量与当前查询的语义不够匹配，而检索失败。

解决方案 ：

• 关键信息提取与固化 ：在对话开始时或关键节点，主动提取并固化约束条件。例如，在旅行规划的例子中，当用户第一次说出预算时，Agent可以在内部生成一个“用户档案”或“任务约束清单”，内容如 {"budget": 5000, "destination": "Japan", "travel_time": "7 days"} 。这个清单可以：
  1. 作为一个简短的文本片段，在后续每一轮对话的Prompt中都固定出现（占用少量但稳定的Token）。
  2. 存储到数据库，每次需要时通过一个固定的键（如“用户约束”）检索出来，插入上下文。
• 定期总结与确认 ：在任务的关键阶段，Agent可以主动输出一个阶段性总结：“根据我们目前的讨论，您的需求是：预算5000元，日本7日游，偏好温泉和美食。接下来我将为您推荐具体行程。请问以上信息是否有误？”这既是对齐，也是将关键信息在上下文中以“助理回复”的形式再次强化，使其进入最近的对话历史窗口。

管理上下文预算，本质上是在教导Agent如何成为一个高效的思考者，而不是一个被信息洪流冲垮的收集者。它没有一成不变的银弹，需要你根据任务类型、模型能力和用户体验目标，灵活搭配上述策略。从最简单的滑动窗口开始，逐步引入摘要和检索，最终向着结构化、智能化的上下文路由演进，这是一个随着你对Agent能力要求提高而不断深化的过程。最关键的永远是那个问题： 为了回答当前这个问题，我的Agent最少需要“看”到什么？ 围绕这个问题去设计你的上下文，你的Agent就会越来越聪明。