大语言模型智能体状态压缩实战：从上下文膨胀到成本优化

1. 从“上下文膨胀”到“成本焦虑”：为什么我们需要压缩智能体状态

最近在折腾几个基于大语言模型的智能体项目，从简单的客服机器人到复杂的多步骤工作流编排，一个绕不开的痛点越来越明显：上下文（Context）消耗的Token数量失控了。尤其是在使用“状态在上下文中”（State-in-Context）这种设计模式时，问题尤为突出。简单来说，为了让智能体记住对话历史、任务状态、用户偏好甚至它自己的“思考过程”，开发者通常会把所有这些信息都塞进每次与大模型交互的提示词（Prompt）里。这就像你每次跟一个记忆力只有七秒的鱼说话，都得先花十分钟把它的生平、你们聊过的所有事、以及它此刻应该做什么复述一遍。

结果就是，一个看似简单的交互，可能轻易消耗掉几千甚至上万个Token。当你的应用日活上来，或者智能体需要处理长周期、多轮次的任务时，API调用成本会像坐了火箭一样飙升。更糟的是，过长的上下文不仅烧钱，还可能影响模型性能。主流模型都有上下文窗口限制，当你的状态信息挤占了太多空间，留给模型“思考”和生成高质量回复的空间就少了。这让我想起了早期网页开发，大家一股脑往HTML里塞样式和脚本，导致页面臃肿不堪，加载缓慢。现在的“状态在上下文中”智能体，正面临着类似的“上下文膨胀”问题。

因此，“压缩”（Minification）成了一个必须认真对待的工程优化方向。这不仅仅是抠成本，更是为了提升智能体的可靠性、响应速度和整体用户体验。我们需要像前端工程师优化网页加载性能一样，来优化我们智能体的“思考负载”。

2. 理解“状态在上下文中”智能体的核心结构与消耗源

要有效压缩，首先得知道“肥肉”长在哪里。一个典型的State-in-Context Agent，其状态管理通常遵循一个循环：感知（用户输入/环境反馈）→ 更新内部状态 → 基于状态决定行动 → 执行行动 → 将新状态写入下一次交互的上下文。这个“内部状态”就是我们需要管理的大头。

2.1 状态信息的典型构成

我们可以把一个智能体的上下文状态拆解成几个主要部分，每一部分都是潜在的Token消耗大户：

1. 对话历史（Conversation History）：最直观的部分。包括用户的所有提问和智能体的所有回复。在多轮对话中，这部分会线性增长。
2. 任务状态与元数据（Task State & Metadata）：智能体正在执行的任务的进度、目标、已完成的步骤、待办事项列表、参数等。例如，一个旅行规划智能体的状态可能包含{destination: “东京”， dates: “2023-10-01 to 2023-10-07”， budget: 5000， completed_steps: [“确定目的地”， “查询航班”]， current_step: “筛选酒店”}。
3. 智能体自身指令与角色设定（System Prompt / Persona）：定义智能体是谁、应该遵循什么规则、具备什么能力的长篇描述。这部分虽然相对静态，但为了效果，开发者往往会写得非常详细，轻易就能占去几百个Token。
4. 工具/函数调用历史与结果（Tool Call History & Results）：如果智能体可以调用外部API（如搜索、计算、数据库查询），那么每次调用的函数名、参数以及返回的结果（可能是大段的JSON或文本）都会被记录在上下文中，以供后续决策参考。这部分数据量可能非常大，特别是当返回结果是网页摘要、长文档片段或复杂数据结构时。
5. 内部推理链或思维过程（Chain-of-Thought / Reasoning Traces）：为了让模型输出更可靠，我们常鼓励它“一步一步思考”，并将这些中间思考步骤也输出出来。这些“思维痕迹”对于调试和理解模型行为非常有用，但同样会占据大量上下文空间。

2.2 Token消耗的动态模型

Token消耗不是静态的。它随着交互轮次呈非线性增长，因为新产生的状态会不断附加到历史状态之后。假设每轮交互平均产生S个Token的新状态，经过n轮对话后，仅状态部分消耗的Token就可能达到O(n * S)，如果再考虑完整的对话历史，消耗会更快。当总长度接近模型上下文窗口上限（如GPT-4的128K）时，就会触发模型的“长上下文遗忘”机制，最早的信息会被丢弃，可能导致智能体失忆，任务失败。

因此，压缩的目标很明确：在保证智能体功能完整性和决策质量的前提下，最大限度地减少每次API调用时，需要放入上下文中的状态信息的Token数量。

3. 压缩策略全景图：从基础清洗到高级抽象

压缩不是简单的删除，而是一种有损的信息提炼。下面我结合实践，梳理出一套从易到难、从通用到专用的压缩策略。

3.1 基础层：无损压缩与格式优化

这一层的目标是挤掉“水分”，不损失任何信息含义。

1. 去除冗余格式与空白符：这是最像前端代码Minification的一步。将JSON状态中的缩进、换行、多余空格全部去掉。将冗长的自然语言系统提示中的啰嗦表达进行精简。

   • 实操示例：
     • 优化前（System Prompt）: “你是一个乐于助人且专业的AI助手。你的目标是尽你所能，以准确、清晰、详尽的方式回应用户的查询和请求。请始终保持友好和礼貌的态度。”
     • 优化后: “专业且友好的AI助手，准确清晰地响应用户请求。”
   • 工具：对于JSON，可以使用编程语言自带的json.dumps(..., separators=(‘,’, ‘:’))（Python）来生成最紧凑格式。对于自然语言，则需要人工或通过另一个轻量级LLM进行重写提炼。

2. 键名缩写：在JSON状态中，将长的键名替换为短的缩写，并维护一个映射表在代码中。

   • 示例：{"user_preferences”: {“favorite_color”: “blue”， “newsletter_subscribed”: true}}可以压缩为{“up”: {“fc”: “blue”， “ns”: true}}。
   • 注意：这会给调试带来一些不便，需要确保映射表被妥善管理。

3. 数据序列化格式选择：虽然JSON易读性好，但并非最紧凑的格式。在某些对极致压缩有要求的场景，可以考虑MessagePack、CBOR或Protocol Buffers等二进制序列化格式。不过，这需要额外的编解码步骤，并且大多数LLM API直接接收文本，所以通常需要在发送前编码为Base64等文本格式，可能会抵消部分压缩收益，需权衡。

3.2 核心层：有损压缩与信息提炼

这一层开始涉及对信息内容的取舍和再加工，是压缩效果最显著的环节。

1. 对话历史摘要（Conversation Summarization）：这是应对长对话的杀手锏。不要保存完整的原始对话，而是定期（例如每5轮，或当Token数达到阈值时）用模型对之前的对话历史生成一个简洁的摘要。

   • 如何做：设计一个摘要提示词，要求模型提取关键决策、用户的核心意图和已确认的事实，忽略寒暄和无关细节。
   • 示例提示词：“请将以下对话历史总结为一个简洁的段落，只保留与用户核心请求（规划一次东京旅行）相关的关键信息，如已确定的预算、日期、兴趣点，以及已完成的步骤（如航班已查询）。忽略问候语和重复确认。”
   • 进阶技巧：可以采用“增量摘要”策略。只摘要最老的、超出窗口的部分，而保留最近几轮完整的、高相关性的对话。这样既能压缩，又能保证近期上下文的丰富性。

2. 工具调用结果的提炼：工具返回的原始数据（如整篇网页内容、庞大的API响应）是Token消耗的巨兽。我们不应该直接把原始结果丢进上下文。

   • 策略：在工具调用后，立即用一个“提炼”步骤，让另一个轻量且快速的模型（如GPT-5-mini这类小型模型非常适合此角色）从结果中提取出对当前任务最关键的信息。
   • 示例：智能体调用搜索API获取“东京三天游攻略”，返回了10个网页的摘要。提炼步骤可以要求GPT-5-mini：“基于用户想要规划文化之旅的需求，从以下搜索结果中提取出最重要的3-4个景点推荐、1-2条交通建议，并以极简的要点列出。” 这样，原本可能上千Token的搜索结果，被压缩成了不到100Token的精华要点。

3. 状态差异化更新：不要每次都将完整状态序列化到上下文。只记录自上次交互以来发生变化的状态（Delta）。

   • 机制：在代码中维护一个完整的状态对象。每次交互后，计算当前状态与上一次提交到上下文的状态之间的差异（diff），只将这个“差异”连同必要的指令（如“将以下变更合并到你的状态中”）发送给模型。
   • 挑战：这要求智能体具备合并差异的能力。你需要在系统提示中明确指导模型如何理解和应用这些差异更新。这增加了逻辑复杂性，但在状态结构稳定、变化局部的场景下效果极佳。

3.3 架构层：状态外部化与引用机制

这是更根本的解法，将状态移出模型的上下文，另寻他处存储。

1. 向量数据库存储与检索：将长篇的、静态的或历史的状态信息（如产品文档、历史对话摘要、用户档案详情）存入向量数据库。在需要时，根据当前对话的语义，从库中检索最相关的几个片段（Chunk），作为“上下文补充”插入提示词，而不是携带全部信息。

   • 流程：
     1. 智能体收到查询。
     2. 从向量库中检索出前K个最相关的历史片段。
     3. 将这些片段作为“参考材料”与当前查询一起构成提示，发送给LLM。
     4. LLM基于有限的、高相关的上下文生成回复。
   • 优势：突破了上下文窗口的长度限制，理论上可以关联海量历史信息。
   • 成本转移：Token消耗从LLM API转移到了向量数据库的存储和检索上，通常后者的成本更低，且更具可预测性。

2. 传统数据库/缓存存储：对于结构化的任务状态（如订单ID、进度百分比、选项列表），完全可以用外部数据库（如Redis、SQLite）来存储。智能体的上下文里只需要保存一个轻量的“状态指针”（如session_id或task_id），然后在需要时，由后端代码根据这个指针去查询完整状态，并可能进行提炼后再喂给LLM。

   • 示例：一个订餐智能体的状态中，不再保存用户完整的订单历史JSON，而是保存user_id: “123”。当模型需要了解用户口味时，后端代码从数据库查询用户最近的5个订单，提炼出“偏爱辣味、常点牛肉类”这样的标签，再插入上下文。

4. 实战：构建一个可配置的状态压缩管道

理论说再多，不如一行代码。下面我设计一个简单的、可插拔的压缩管道示例，你可以根据自己的需求进行组合和扩展。

假设我们有一个智能体，其状态对象agent_state结构如下：

agent_state = { “conversation_history”: […], # 列表，包含多轮 {“role”: “user”/“assistant”， “content”: “…”} “task”: { “name”: “travel_planning”， “goal”: “计划一次东京文化之旅”， “steps_completed”: [“set_budget”， “find_flights”], “current_step”: “book_hotel”， “parameters”: {“budget”: 5000， “dates”: “2023-10-01 to 07”， “interests”: [“museum”， “temple”]} }, “user_profile”: {“name”: “Alex”， “preference”: “quiet hotel near subway”}, “last_tool_results”: […] # 可能很大的工具调用结果列表 }

我们的压缩管道可以包含多个“压缩器”（Compressor），每个负责一种策略：

class StateCompressor: def __init__(self， compression_strategies=None): self.strategies = compression_strategies or [“format”， “summarize”， “refine_tools”] def compress(self， agent_state， max_history_turns=10): compressed_state = agent_state.copy() if “format” in self.strategies: # 策略1: 格式压缩 compressed_state = self._minify_json(compressed_state) compressed_state[“system_prompt”] = self._shorten_prompt(compressed_state.get(“system_prompt”， “”)) if “summarize” in self.strategies and len(compressed_state[“conversation_history”]) > max_history_turns: # 策略2: 对话摘要 (当历史轮次超过阈值) old_history = compressed_state[“conversation_history”][:-5] # 保留最近5轮完整对话 summary = self._call_summarizer(old_history) # 调用一个轻量LLM生成摘要 compressed_state[“conversation_history”] = [{“role”: “system”， “content”: f”对话历史摘要: {summary}”}] + compressed_state[“conversation_history”][-5:] if “refine_tools” in self.strategies and compressed_state[“last_tool_results”]: # 策略3: 提炼工具结果 refined_results = [] for result in compressed_state[“last_tool_results”]: if self._is_large_result(result): # 判断结果是否过大 refined = self._call_refiner(result， compressed_state[“task”][“goal”]) # 调用小型模型提炼 refined_results.append(refined) else: refined_results.append(result) compressed_state[“last_tool_results”] = refined_results # 策略4: 键名缩写 (示例) key_mapping = {“conversation_history”: “ch”， “task”: “t”， “user_profile”: “up”} compressed_state = self._replace_keys(compressed_state， key_mapping) return compressed_state def _call_summarizer(self， history): # 这里可以集成对 GPT-5-mini 或类似低成本模型的调用 # 模拟返回 prompt = f”请用一段话总结以下对话的核心内容:\n{history}” # 调用 LLM API (如 openai.ChatCompletion.create(model=“gpt-5-mini”， …)) # summary = response.choices[0].message.content return “用户计划东京文化之旅，预算5000，日期10月1-7日，已查询航班，正在筛选酒店。” def _call_refiner(self， raw_result， task_goal): # 调用小型模型提炼工具结果 prompt = f”基于当前任务‘{task_goal}’，从以下文本中提取最关键的信息，以要点列出:\n{raw_result}” # 调用 LLM API return “- 浅草寺: 著名古刹，可体验文化\n- 东京国立博物馆: 藏品丰富\n- 推荐乘坐地铁山手线，方便快捷” # 其他辅助方法 (_minify_json， _shorten_prompt， _is_large_result， _replace_keys) 略…

在实际调用LLM前，我们使用这个压缩器：

compressor = StateCompressor(compression_strategies=[“format”， “summarize”， “refine_tools”]) compressed_state = compressor.compress(current_agent_state) # 然后将 compressed_state 序列化为字符串，与系统提示等一起构成最终的API请求 final_prompt = construct_prompt(system_prompt， compressed_state， user_query) response = call_llm_api(final_prompt)

这个管道可以根据配置灵活开启或关闭某些压缩策略，方便进行效果对比和调试。

5. 压缩的代价：在成本、性能与可靠性间寻找平衡

压缩不是免费的午餐，每一种策略都可能引入新的问题，需要在实践中小心权衡。

1. 信息丢失与任务漂移：这是有损压缩最大的风险。过于激进的摘要或提炼，可能会丢失关键细节，导致智能体后续决策出错。例如，在旅行规划中，如果摘要漏掉了用户对“过敏原”的特殊要求，后续推荐的餐厅就可能出问题。

   • 缓解策略：实施“关键信息检查点”。定义一组绝对不能丢失的信息维度（如预算、日期、硬性约束），在压缩过程中，显式地检查并确保这些信息被保留。或者，采用“混合”模式，关键信息以结构化字段保留，非关键叙述性内容才进行摘要。

2. 计算开销与延迟：压缩本身需要计算资源。调用GPT-5-mini进行摘要和提炼，虽然比主模型便宜，但也增加了额外的API调用和网络延迟。向量数据库的检索也需要时间。

   • 缓解策略：异步与非实时压缩。对于对话摘要，不必每轮都做，可以设定一个时间或长度阈值。对于工具结果提炼，如果后续步骤并非立即需要全部细节，也可以稍后异步处理。衡量压缩节省的Token成本与额外计算开销之间的平衡点。

3. 系统复杂度提升：状态外部化（如使用向量库）引入了新的基础设施依赖和数据一致性问题。差异化更新要求状态合并逻辑健壮。整个系统从“纯提示工程”变成了一个更复杂的分布式系统，调试难度增加。

   • 缓解策略：逐步引入，充分测试。先从最简单的格式压缩和对话摘要开始，观察效果。引入新组件时，做好完备的日志记录，记录压缩前、后的状态快照，以便在出现问题时能够回溯。

4. 对模型“思维链”的影响：如果压缩掉了模型的内部推理步骤，虽然节省了Token，但我们也失去了洞察模型决策过程的机会，不利于调试和优化。

   • 缓解策略：区分环境。在开发、调试阶段，可以保留完整的思维链。在生产环境，可以尝试只保留最终结论，或者将详细的思维链记录到独立的日志系统中，而不是主上下文里。

6. 效果评估与监控：如何量化你的压缩收益

优化不能凭感觉，必须建立度量指标。以下是一些关键的评估维度：

1. 核心指标：平均每轮交互Token数：这是最直接的效益指标。在引入压缩策略前后，统计相同或类似任务流下，平均每次调用LLM API所消耗的提示词（Prompt）Token数。下降百分比就是你的直接成本节省。
2. 质量指标：任务完成率与用户满意度：压缩不能损害功能。需要A/B测试，对比压缩版和未压缩版智能体在核心任务（如客服问题解决率、旅行计划完整性）上的表现。可以通过人工评估或自动化关键节点检查来实现。
3. 性能指标：响应延迟：监控从用户请求到收到智能体回复的总时间。确保引入压缩管道（尤其是需要额外模型调用的策略）后，延迟仍在可接受范围内。
4. 辅助指标：上下文窗口利用率：观察你的提示词长度距离模型上下文窗口上限还有多少余量。健康的压缩应该使利用率保持在一个安全水位（例如，对于128K窗口，日常使用在80K以下），为复杂的任务高峰预留空间。

建立一个监控面板，持续跟踪这些指标。当业务逻辑或状态结构发生变化时，重新评估压缩策略的有效性。

7. 面向未来：更智能的压缩与模型进化

我们讨论的压缩，很大程度上是在弥补当前LLM作为“无状态”推理引擎的不足。未来的发展可能会从两个方向改变游戏规则：

1. 模型原生支持长上下文与状态管理：像GPT-4.1这类模型，可能在架构层面就优化了对长上下文的处理效率，或者通过更精细的注意力机制降低长文本的计算开销。更革命性的是，如果模型API能原生支持“会话状态”的托管，允许开发者通过一个session_id来关联历史，而无需在每次请求中传递，那么上下文Token的消耗将大大减少。我们需要密切关注主流API提供商在这方面的动向。

2. 智能体框架的内置优化：主流的智能体开发框架（如LangChain， LlamaIndex）将会把状态压缩作为一项核心基础设施来提供。它们可能会提供开箱即用的、可配置的压缩中间件，集成最优的摘要模型、向量检索方案，让开发者无需从零造轮子。

3. 压缩算法的自适应化：未来的压缩策略可能不再是静态配置的，而是自适应的。智能体可以根据当前任务的类型、阶段以及状态的信息密度，动态选择最合适的压缩策略组合。例如，在任务规划阶段保留详细推理，在执行阶段则高度压缩历史，聚焦于当前动作。

作为开发者，我们现在的压缩实践，一方面是为了立即降低成本、提升性能，另一方面也是在为未来更优雅的解决方案积累经验和定义需求。在现阶段，掌握状态压缩这项技能，意味着你能在同等预算下，部署更强大、更持久的智能体应用，这在竞争中无疑是一个重要的优势。从我自己的项目经验来看，一套合理的压缩组合拳，轻松能将长期运行任务的Token消耗降低30%-50%，这对于规模化应用而言，意义重大。