1. 项目概述为什么你的Agent总是“答非所问”最近在折腾AI Agent的朋友估计都遇到过这么个场景你精心设计了一个客服Agent希望它能根据用户的历史对话记录提供个性化的服务。你信心满满地给它喂了长达几十轮的对话历史结果它要么对最新的问题视而不见还在纠结十分钟前的一个细节要么干脆“失忆”把关键的订单信息给忘了。这感觉就像你请了个助手但他总在翻一本写满无关紧要笔记的旧本子反而忽略了眼前最紧急的任务。问题的核心往往不在于模型不够聪明而在于我们没告诉它“该看什么”。这就是“上下文预算”要解决的根本痛点。在AI Agent的开发中上下文Context指的是我们一次性输入给大语言模型LLM的所有信息包括系统指令、历史对话、知识库片段、工具调用结果等。而“上下文预算”形象地说就是给Agent的“工作记忆区”划出了一块明确的范围和优先级规则。它不是一个简单的长度限制而是一套动态的管理策略确保Agent在有限的注意力窗口内始终聚焦于与当前任务最相关、最重要的信息。对于开发者而言无论是构建一个简单的聊天机器人还是一个复杂的多步骤任务自动化Agent上下文管理都是决定其表现是否“智能”和“稳定”的关键。没有预算管理Agent就像在信息的海洋里盲目打捞效率低下且容易出错。理解了上下文预算你就能让Agent从“被动接收信息”转变为“主动管理注意力”从而显著提升其响应准确性、任务完成率和用户体验。接下来我们就深入拆解如何为你的Agent设计并实现一套高效的上下文预算方案。2. 上下文预算的核心原理与设计思路2.1 从“无限内存”的幻想到“有限注意力”的现实许多刚接触Agent开发的朋友容易陷入一个误区认为给模型输入的上下文越长越好恨不得把整个知识库和历史记录都塞进去。这源于我们对人类记忆的类比——我们似乎能记住很多事。但实际上当前的大语言模型如GPT-4、Claude-3、国内的各种大模型在处理长上下文时存在两个关键限制技术硬限制上下文窗口长度每个模型都有一个固定的最大令牌Token数限制比如4K、8K、16K、128K甚至更长。这是模型架构决定的物理上限超出部分模型无法处理。性能软限制中间信息衰减即使是在窗口长度内模型对输入内容不同位置的“注意力”强度也是不同的。大量研究表明模型对输入开头和结尾部分的信息记忆和理解更好而对中间部分尤其是非常长的上下文中间部分存在明显的“信息衰减”或“迷失”现象。你把关键信息埋在冗长历史的中间模型很可能“看”不到它。因此“上下文预算”的第一层含义就是承认并尊重模型的“有限注意力”特性。我们不能假设Agent拥有无限、均匀的记忆能力而必须主动地、有策略地为其筛选和呈现信息。2.2 预算的四大核心维度一个完整的上下文预算策略通常围绕以下四个维度进行设计这决定了Agent的“工作风格”容量预算Capacity Budget这是最基础的维度即本次调用最多能使用多少Tokens。它通常由模型的最大上下文窗口减去预留空间用于系统指令、本次用户查询、工具调用结果和模型回复来决定。例如如果你的模型支持16K上下文你可能会设定单轮交互的容量预算为12K为不可预见的扩展留出缓冲。优先级预算Priority Budget并非所有历史信息都同等重要。优先级预算定义了信息的价值排序。通常时间邻近性越近的对话越重要和任务相关性与当前用户意图直接相关的信息越重要是两个核心的优先级指标。例如在客服场景中用户刚刚提到的“订单号12345”的优先级远高于一小时前闲聊的“天气不错”。结构预算Structure Budget信息如何组织极大影响模型的提取效率。杂乱无章地将历史记录堆砌在一起远不如将其结构化。常见的结构包括按轮次组织用户: 说A。助手: 回复B。按主题/会话分段将长对话拆分成多个逻辑段落并添加小标题。关键信息摘要将过去多轮对话压缩成一段简洁的摘要。 结构预算决定了我们以何种“格式”向模型呈现历史帮助它快速定位。刷新预算Refresh Budget对于长程交互如持续数小时或天的对话我们需要决定何时以及如何更新Agent的“记忆”。是每N轮对话后强制做一次摘要还是当历史长度达到阈值X时触发压缩刷新预算定义了记忆更新的触发条件和策略防止陈旧信息过度堆积。2.3 设计思路从静态切割到动态管理初级的上下文管理可能就是简单的“截断”保留最新的N条对话。但这很粗暴可能会丢失重要的早期指令比如用户一开始说“请用英文回答我”。更高级的动态管理思路是构建一个上下文管理器Context Manager。它的工作流程像一个智能的编辑评估Evaluate当新的用户输入到来时管理器首先评估现有历史上下文的价值。哪些对话轮次与当前问题高度相关哪些已经过时或无关筛选Filter根据优先级预算过滤掉低相关性的历史信息。例如可以计算历史对话片段与当前查询的语义相似度保留得分最高的Top-K条。压缩Compress对于需要保留但过于冗长的信息进行压缩。例如将一段关于用户偏好“我喜欢蓝色讨厌下雨天是素食主义者”的多轮对话压缩成一条结构化的事实陈述“用户偏好颜色-蓝色天气-讨厌雨天饮食-素食。”组装Assemble将系统指令、压缩/筛选后的历史、当前查询、以及必要的工具调用结果如查询数据库得到的数据按照结构预算组装成最终的、符合容量预算的提示词Prompt送给LLM。这个动态过程确保了Agent的“工作记忆”始终是精简、相关和即时的。3. 核心细节解析与实操要点3.1 如何量化“相关性”——相似度计算与关键词提取优先级预算的核心是判断历史信息与当前任务的相关性。这里有两个实用的技术手段语义相似度计算这是最主流和有效的方法。你可以使用一个轻量级的嵌入模型Embedding Model例如开源的text-embedding-3-small或BGE系列模型将每一段历史对话和当前查询都转换为向量Vector。然后计算当前查询向量与每一段历史向量之间的余弦相似度。相似度越高代表相关性越强。实操示例假设历史中有10轮对话你将每轮对话或每两轮合并作为一个文本块计算其嵌入向量。当新查询到来时同样计算其向量然后与这10个历史向量逐一计算相似度保留相似度最高的3-5个历史块。注意点嵌入模型的选择很重要需要与你的主模型和任务领域匹配。对于中文场景BGE系列通常是更好的选择。关键词/实体提取与匹配对于某些垂直领域如客服、法律、医疗任务围绕明确的实体展开订单号、病例ID、法律条款编号。此时可以使用命名实体识别NER工具提取历史和当前查询中的关键实体直接进行匹配。包含相同或相关实体的历史片段优先级自然提高。实操示例在电商客服Agent中你识别到当前用户查询中包含实体“订单号: 78910”。那么在历史对话中所有提及“订单号: 78910”的对话轮次无论时间远近都应获得高优先级并被保留。3.2 压缩技术的选择从摘要到结构化表示当必须保留的信息超过容量预算时压缩就派上用场了。不要幻想用一个复杂的提示词让主模型自己总结这既昂贵又低效。正确的做法是使用更小、更快的专用总结模型专门为摘要任务微调的小模型如一些百亿参数级别的模型在速度和成本上远优于动用千亿参数的主模型。你可以部署一个这样的总结模型作为“上下文压缩器”。结构化提取而非泛泛总结对于任务型对话压缩的目标不是生成一段流畅的段落而是提取出对后续决策关键的结构化信息。原始历史用户我想订一张明天从北京飞上海的机票。 助手好的。请问您希望什么时间出发有什么偏好的航空公司吗 用户最好是上午东航或者国航都可以。 助手查到明天上午东航MU5101航班08:00起飞09:55到达价格1200元。您看可以吗 用户价格有点高有更便宜的吗 助手国航CA150107:55起飞09:45到达价格950元。 用户好的就这个吧。糟糕的摘要“用户想订明天北京到上海的机票讨论了时间和航空公司最后选择了国航的航班。” 丢失了关键的价格、航班号等细节良好的结构化提取{ “任务状态”: “已确认航班” “行程”: { “日期”: “明天” “出发地”: “北京” “目的地”: “上海” }, “选定航班”: { “航空公司”: “国航” “航班号”: “CA1501” “起飞时间”: “07:55” “到达时间”: “09:45” “价格”: 950 }, “用户偏好”: [“上午出发” “东航或国航”] }这种结构化的表示信息密度极高且易于被主模型解析和利用。3.3 系统指令的恒定性与动态性系统指令System Prompt是Agent的“宪法”定义了它的角色、能力和行为规范。在上下文预算中系统指令的处理有一个基本原则必须保证其始终存在且完整。恒定部分核心角色定义、基础安全规则、通用响应格式等应作为“保留区”永远不被压缩或截断。通常这部分会固定在Prompt的开头。动态部分有些指令可能与当前会话阶段相关。例如在游戏Agent中系统指令可能包含当前关卡的目标。当关卡切换时这部分指令需要更新。这要求你的上下文管理器能识别并替换指令中的特定段落而不是简单追加。注意永远不要为了给历史对话腾出空间而截断或压缩系统指令。一个行为失控的Agent比一个健忘的Agent危险得多。4. 实操过程与核心环节实现下面我将以一个“技术支持问答Agent”为例展示如何实现一个简单的、基于语义相似度的动态上下文管理器。我们假设使用OpenAI兼容的API如DeepSeek、GPT等和text-embedding-ada-002类似的嵌入模型。4.1 环境准备与工具选型首先明确我们的技术栈主LLM用于生成最终回答的模型如gpt-4或deepseek-chat。嵌入模型用于计算文本相似度轻量且高效如text-embedding-3-small或BGE-M3。这里我们假设有一个兼容OpenAI Embeddings API的端点。向量数据库可选但推荐用于高效存储和检索历史对话的嵌入向量。对于生产环境使用ChromaDB、Weaviate或Qdrant是标准做法。本例为简化使用内存中的列表模拟。开发语言Python。安装基础库pip install openai chromadb # 示例使用openai和chromadb4.2 构建上下文管理器类我们创建一个ContextManager类它负责管理对话历史。import openai from typing import List, Dict, Any import numpy as np from sklearn.metrics.pairwise import cosine_similarity import json class ContextManager: def __init__(self, embedding_model: str, llm_model: str, max_context_tokens: int 8000): 初始化上下文管理器。 :param embedding_model: 嵌入模型名称 :param llm_model: 主LLM模型名称 :param max_context_tokens: 最大上下文令牌数 self.embedding_model embedding_model self.llm_model llm_model self.max_context_tokens max_context_tokens self.system_prompt 你是一个专业的技术支持助手。请根据对话历史和当前问题提供准确、简洁、有帮助的回答。如果问题涉及具体错误请提供排查步骤。 # 存储历史每个元素是一个字典包含‘role‘, ‘content‘, ‘embedding‘ self.history: List[Dict[str, Any]] [] # 估计的令牌占用简化版实际应用应使用tiktoken等库精确计算 self.estimated_tokens_used self._estimate_tokens(self.system_prompt) def _get_embedding(self, text: str) - List[float]: 获取文本的嵌入向量模拟实际需调用API # 这里简化处理实际应调用OpenAI或本地嵌入模型API # response openai.embeddings.create(modelself.embedding_model, inputtext) # return response.data[0].embedding # 为示例返回一个随机向量实际不可用 return np.random.rand(768).tolist() # 假设维度为768 def _estimate_tokens(self, text: str) - int: 粗略估计文本的令牌数实际应用务必使用精确库如tiktoken for OpenAI # 简单按字符数除以4估算非常不精确仅用于演示。 return len(text) // 4 def add_interaction(self, role: str, content: str): 添加一轮交互到历史并计算其嵌入 entry { role: role, # ‘user‘ or ‘assistant‘ content: content, embedding: self._get_embedding(content) } self.history.append(entry) self.estimated_tokens_used self._estimate_tokens(f{role}: {content}) def _select_relevant_history(self, current_query: str, top_k: int 5) - List[Dict]: 基于语义相似度选择与当前查询最相关的历史片段 if not self.history: return [] query_embedding self._get_embedding(current_query) history_embeddings [entry[embedding] for entry in self.history] # 计算余弦相似度 similarities cosine_similarity([query_embedding], history_embeddings)[0] # 获取相似度最高的top_k个索引 top_indices np.argsort(similarities)[-top_k:][::-1] # 从高到低排序 selected_history [self.history[i] for i in top_indices] # 按时间顺序重新排序选中的历史以保持逻辑连贯性 selected_history.sort(keylambda x: self.history.index(x)) return selected_history def _compress_history_if_needed(self, selected_history: List[Dict]) - List[Dict]: 如果选中的历史预计令牌数超限则进行压缩 # 估算选中历史的令牌数 selected_tokens sum(self._estimate_tokens(f{h[‘role‘]}: {h[‘content‘]}) for h in selected_history) total_estimated self._estimate_tokens(self.system_prompt) selected_tokens self._estimate_tokens(user: [当前查询]) 500 # 预留回复空间 if total_estimated self.max_context_tokens: return selected_history # 无需压缩 # 简易压缩策略如果超限优先保留更近的历史假设selected_history已按时间排序 # 更复杂的策略可以调用摘要模型 print(f上下文预算({self.max_context_tokens})可能不足预计{total_estimated}。启用压缩策略。) # 从最旧的开始丢弃直到满足预算这是一个非常基础的策略 compressed_history selected_history.copy() while compressed_history and total_estimated self.max_context_tokens: removed compressed_history.pop(0) # 丢弃最旧的一条 total_estimated - self._estimate_tokens(f{removed[‘role‘]}: {removed[‘content‘]}) print(f 丢弃历史记录: {removed[‘content‘][:50]}...) return compressed_history def build_prompt(self, user_query: str) - List[Dict[str, str]]: 构建最终发送给LLM的消息列表 # 1. 选择相关历史 relevant_history self._select_relevant_history(user_query, top_k8) # 尝试多选一些 # 2. 检查并压缩 final_history self._compress_history_if_needed(relevant_history) # 3. 构建消息 messages [{role: system, content: self.system_prompt}] for entry in final_history: messages.append({role: entry[role], content: entry[content]}) messages.append({role: user, content: user_query}) return messages def generate_response(self, user_query: str) - str: 完整的处理流程构建Prompt调用LLM添加历史 messages self.build_prompt(user_query) # 模拟调用LLM # response openai.chat.completions.create(modelself.llm_model, messagesmessages) # assistant_reply response.choices[0].message.content assistant_reply f[模拟LLM回复基于历史长度{len(messages)-2}条和查询‘{user_query}‘] # 将本轮交互加入历史 self.add_interaction(user, user_query) self.add_interaction(assistant, assistant_reply) return assistant_reply # 使用示例 if __name__ __main__: manager ContextManager(embedding_modeltext-embedding-3-small, llm_modelgpt-4, max_context_tokens4000) # 模拟历史对话 manager.add_interaction(user, 我的网站无法访问了显示502错误。) manager.add_interaction(assistant, 502错误通常表示网关问题。请先检查您的后端服务如PHP-FPM或Node.js是否在运行。您可以尝试重启后端服务。) manager.add_interaction(user, 我重启了PHP-FPM但还是不行。) manager.add_interaction(assistant, 请检查Web服务器如Nginx的错误日志通常在/var/log/nginx/error.log。看看有没有相关错误信息。) # 新查询 new_query 日志里有很多‘connect() failed (111: Connection refused)‘的错误。 response manager.generate_response(new_query) print(最终Prompt消息结构最后两条是当前查询和预留的助手位置:) prompt_msgs manager.build_prompt(new_query) for msg in prompt_msgs: print(f {msg[‘role‘]}: {msg[‘content‘][:80]}...) print(f\nAgent回复: {response})4.3 关键环节解析历史存储与嵌入self.history列表不仅存储对话内容还预存了每段内容的嵌入向量。这避免了每次检索时重复计算是性能优化的关键。在生产环境中这部分应由向量数据库高效处理。相关性检索_select_relevant_history方法实现了基于余弦相似度的语义检索。我们取了与当前查询最相似的top_k条历史。这里top_k是一个可调参数值越大保留的相关信息可能越多但也更容易触发压缩。动态压缩_compress_history_if_needed方法实现了简单的“按时间丢弃”压缩策略。这是一个保底策略。更优的做法是当预测到会超限时主动调用一个摘要模型将selected_history中较旧或较低优先级的部分合并成一个摘要块替换掉原来的多条记录从而在更小的空间内保留更多信息。Prompt组装build_prompt方法严格按照ChatML等常见格式组装消息系统指令 - 筛选压缩后的历史 - 当前用户查询。这个顺序符合模型的标准处理流程。这个示例提供了一个基础框架。在实际复杂应用中你需要集成精确的令牌计数库如tiktoken。用真实的嵌入API和向量数据库替换模拟部分。实现更智能的压缩策略如摘要模型。考虑多模态上下文如图片、文档片段的管理。5. 常见问题与排查技巧实录在实际开发和调试上下文预算策略时你肯定会遇到各种问题。下面是我踩过的一些坑和总结的排查思路。5.1 问题Agent似乎“忘记了”很早但非常重要的指令场景用户在第一句话中说“请全程用英文回复”但在对话了十几轮后Agent突然开始用中文回答。根因分析你的优先级预算可能过度依赖“时间邻近性”或“语义相似度”。早期指令与后续的具体技术问题在语义上关联度很低因此在相关性检索中被过滤掉了。解决方案标记关键指令在系统指令或上下文管理逻辑中定义一些“必须永远保留”的关键信息类型。例如识别出包含“请用英文”、“我的名字是”、“我的订单号是”等模式的语句给它们打上高优先级标签使其免于被常规的过滤和压缩流程淘汰。设立“元指令”区在系统指令之后开辟一个独立的“会话元数据”区域。每当识别到用户设置了全局性偏好如语言、称呼、任务目标就将其提取并结构化放入这个区域。这个区域不计入常规历史压缩的容量或享有最高的保留优先级。5.2 问题上下文切换后Agent表现混乱场景用户先讨论了A项目然后又切换到B项目。Agent在回答B项目问题时偶尔会引用A项目的数据。根因分析你的上下文管理器可能只做了相关性筛选但没有做“主题分割”。当两个主题在词义上有重叠时比如都涉及“预算”、“设计”基于嵌入的检索可能会把不同主题的片段混在一起。解决方案主题/会话分割检测在添加历史时运行一个轻量级的主题分类或对话行为检测模型。当检测到用户意图发生显著转变如从“咨询价格”变为“报告故障”或检测到明显的开场白如“现在我们来聊聊另一个问题”就在历史中插入一个无形的“会话边界”标记。检索时尊重边界在进行相关性检索时优先在同一会话主题内检索。只有当同一主题内信息不足时才跨主题检索并对跨主题检索到的信息进行降权或附加来源说明如“[来自关于A项目的讨论]”让主模型知道这是不同上下文的信息。5.3 问题压缩导致信息失真Agent基于错误摘要做出判断场景你将一段复杂的用户需求包含多个例外条件和偏好压缩成一段摘要。结果摘要遗漏或曲解了一个关键例外条件导致Agent给出的方案完全错误。根因分析摘要模型能力不足或压缩提示词Prompt设计不当导致“幻觉”或信息丢失。解决方案结构化提取优先于概括性摘要如前文所述对于任务关键信息强制使用模板进行结构化提取如JSON Schema。让压缩模型扮演“信息提取员”而非“总结作家”的角色。例如提示词可以是“请从以下对话中提取关于用户订单的以下信息以JSON格式输出{‘product_name‘: str, ‘quantity‘: int, ‘special_requests‘: list[str]}。如果某项信息未提及则输出null。”保留原始片段引用在压缩时不仅生成摘要还记录该摘要源自哪几条原始对话的ID。当主模型在后续决策中需要引用细节时可以设计一个机制让它能“追溯”并临时调取原始对话片段进行复核。对压缩结果进行验证对于高风险领域如医疗、金融可以设计一个简单的验证步骤。例如用另一个小模型或一组规则检查压缩后的关键事实如数字、日期、否定词是否与原始文本一致。5.4 性能与成本优化技巧嵌入缓存对历史对话的嵌入计算是一次性的。计算后存入向量数据库或本地缓存后续检索直接使用避免重复调用嵌入模型产生不必要的成本和延迟。分层检索不要所有历史都做精细的语义检索。可以先根据时间如最近50条、关键词或实体进行粗筛得到一个较小的候选集再对这个候选集进行精确的语义相似度计算。这能大幅减少计算量。预算的动态调整不要给容量预算设死一个值。可以根据当前查询的复杂度和历史长度动态调整。例如简单问候语查询可以分配更小的预算保留更多历史复杂的问题解决查询则分配更大的预算允许带入更多上下文。非对称上下文窗口有些模型或API支持非对称上下文即输入可以很长但输出模型的回答较短。了解你所用模型的这一特性可以在输入侧分配更充裕的预算。调试上下文预算策略是一个迭代过程。最有效的方法是记录和复盘保存每次Agent调用时的完整Prompt输入和Completion输出。当出现回答不准确时回顾当时的Prompt看看是哪些历史信息被包含/排除了压缩是否导致了失真。通过大量案例分析你就能不断调整优先级规则、压缩策略和容量参数让你的Agent真正变得“耳聪目明”。
