1. 从“上下文膨胀”到“成本焦虑”为什么我们需要压缩智能体状态最近在折腾几个基于大语言模型的智能体项目从简单的客服机器人到复杂的多步骤工作流编排一个绕不开的痛点越来越明显上下文Context消耗的Token数量失控了。尤其是在使用“状态在上下文中”State-in-Context这种设计模式时问题尤为突出。简单来说为了让智能体记住对话历史、任务状态、用户偏好甚至它自己的“思考过程”开发者通常会把所有这些信息都塞进每次与大模型交互的提示词Prompt里。这就像你每次跟一个记忆力只有七秒的鱼说话都得先花十分钟把它的生平、你们聊过的所有事、以及它此刻应该做什么复述一遍。结果就是一个看似简单的交互可能轻易消耗掉几千甚至上万个Token。当你的应用日活上来或者智能体需要处理长周期、多轮次的任务时API调用成本会像坐了火箭一样飙升。更糟的是过长的上下文不仅烧钱还可能影响模型性能。主流模型都有上下文窗口限制当你的状态信息挤占了太多空间留给模型“思考”和生成高质量回复的空间就少了。这让我想起了早期网页开发大家一股脑往HTML里塞样式和脚本导致页面臃肿不堪加载缓慢。现在的“状态在上下文中”智能体正面临着类似的“上下文膨胀”问题。因此“压缩”Minification成了一个必须认真对待的工程优化方向。这不仅仅是抠成本更是为了提升智能体的可靠性、响应速度和整体用户体验。我们需要像前端工程师优化网页加载性能一样来优化我们智能体的“思考负载”。2. 理解“状态在上下文中”智能体的核心结构与消耗源要有效压缩首先得知道“肥肉”长在哪里。一个典型的State-in-Context Agent其状态管理通常遵循一个循环感知用户输入/环境反馈→ 更新内部状态 → 基于状态决定行动 → 执行行动 → 将新状态写入下一次交互的上下文。这个“内部状态”就是我们需要管理的大头。2.1 状态信息的典型构成我们可以把一个智能体的上下文状态拆解成几个主要部分每一部分都是潜在的Token消耗大户对话历史Conversation History最直观的部分。包括用户的所有提问和智能体的所有回复。在多轮对话中这部分会线性增长。任务状态与元数据Task State Metadata智能体正在执行的任务的进度、目标、已完成的步骤、待办事项列表、参数等。例如一个旅行规划智能体的状态可能包含{destination: “东京” dates: “2023-10-01 to 2023-10-07” budget: 5000 completed_steps: [“确定目的地” “查询航班”] current_step: “筛选酒店”}。智能体自身指令与角色设定System Prompt / Persona定义智能体是谁、应该遵循什么规则、具备什么能力的长篇描述。这部分虽然相对静态但为了效果开发者往往会写得非常详细轻易就能占去几百个Token。工具/函数调用历史与结果Tool Call History Results如果智能体可以调用外部API如搜索、计算、数据库查询那么每次调用的函数名、参数以及返回的结果可能是大段的JSON或文本都会被记录在上下文中以供后续决策参考。这部分数据量可能非常大特别是当返回结果是网页摘要、长文档片段或复杂数据结构时。内部推理链或思维过程Chain-of-Thought / Reasoning Traces为了让模型输出更可靠我们常鼓励它“一步一步思考”并将这些中间思考步骤也输出出来。这些“思维痕迹”对于调试和理解模型行为非常有用但同样会占据大量上下文空间。2.2 Token消耗的动态模型Token消耗不是静态的。它随着交互轮次呈非线性增长因为新产生的状态会不断附加到历史状态之后。假设每轮交互平均产生S个Token的新状态经过n轮对话后仅状态部分消耗的Token就可能达到O(n * S)如果再考虑完整的对话历史消耗会更快。当总长度接近模型上下文窗口上限如GPT-4的128K时就会触发模型的“长上下文遗忘”机制最早的信息会被丢弃可能导致智能体失忆任务失败。因此压缩的目标很明确在保证智能体功能完整性和决策质量的前提下最大限度地减少每次API调用时需要放入上下文中的状态信息的Token数量。3. 压缩策略全景图从基础清洗到高级抽象压缩不是简单的删除而是一种有损的信息提炼。下面我结合实践梳理出一套从易到难、从通用到专用的压缩策略。3.1 基础层无损压缩与格式优化这一层的目标是挤掉“水分”不损失任何信息含义。去除冗余格式与空白符这是最像前端代码Minification的一步。将JSON状态中的缩进、换行、多余空格全部去掉。将冗长的自然语言系统提示中的啰嗦表达进行精简。实操示例优化前System Prompt: “你是一个乐于助人且专业的AI助手。你的目标是尽你所能以准确、清晰、详尽的方式回应用户的查询和请求。请始终保持友好和礼貌的态度。”优化后: “专业且友好的AI助手准确清晰地响应用户请求。”工具对于JSON可以使用编程语言自带的json.dumps(..., separators(‘,’, ‘:’))Python来生成最紧凑格式。对于自然语言则需要人工或通过另一个轻量级LLM进行重写提炼。键名缩写在JSON状态中将长的键名替换为短的缩写并维护一个映射表在代码中。示例{user_preferences”: {“favorite_color”: “blue” “newsletter_subscribed”: true}}可以压缩为{“up”: {“fc”: “blue” “ns”: true}}。注意这会给调试带来一些不便需要确保映射表被妥善管理。数据序列化格式选择虽然JSON易读性好但并非最紧凑的格式。在某些对极致压缩有要求的场景可以考虑MessagePack、CBOR或Protocol Buffers等二进制序列化格式。不过这需要额外的编解码步骤并且大多数LLM API直接接收文本所以通常需要在发送前编码为Base64等文本格式可能会抵消部分压缩收益需权衡。3.2 核心层有损压缩与信息提炼这一层开始涉及对信息内容的取舍和再加工是压缩效果最显著的环节。对话历史摘要Conversation Summarization这是应对长对话的杀手锏。不要保存完整的原始对话而是定期例如每5轮或当Token数达到阈值时用模型对之前的对话历史生成一个简洁的摘要。如何做设计一个摘要提示词要求模型提取关键决策、用户的核心意图和已确认的事实忽略寒暄和无关细节。示例提示词“请将以下对话历史总结为一个简洁的段落只保留与用户核心请求规划一次东京旅行相关的关键信息如已确定的预算、日期、兴趣点以及已完成的步骤如航班已查询。忽略问候语和重复确认。”进阶技巧可以采用“增量摘要”策略。只摘要最老的、超出窗口的部分而保留最近几轮完整的、高相关性的对话。这样既能压缩又能保证近期上下文的丰富性。工具调用结果的提炼工具返回的原始数据如整篇网页内容、庞大的API响应是Token消耗的巨兽。我们不应该直接把原始结果丢进上下文。策略在工具调用后立即用一个“提炼”步骤让另一个轻量且快速的模型如GPT-5-mini这类小型模型非常适合此角色从结果中提取出对当前任务最关键的信息。示例智能体调用搜索API获取“东京三天游攻略”返回了10个网页的摘要。提炼步骤可以要求GPT-5-mini“基于用户想要规划文化之旅的需求从以下搜索结果中提取出最重要的3-4个景点推荐、1-2条交通建议并以极简的要点列出。” 这样原本可能上千Token的搜索结果被压缩成了不到100Token的精华要点。状态差异化更新不要每次都将完整状态序列化到上下文。只记录自上次交互以来发生变化的状态Delta。机制在代码中维护一个完整的状态对象。每次交互后计算当前状态与上一次提交到上下文的状态之间的差异diff只将这个“差异”连同必要的指令如“将以下变更合并到你的状态中”发送给模型。挑战这要求智能体具备合并差异的能力。你需要在系统提示中明确指导模型如何理解和应用这些差异更新。这增加了逻辑复杂性但在状态结构稳定、变化局部的场景下效果极佳。3.3 架构层状态外部化与引用机制这是更根本的解法将状态移出模型的上下文另寻他处存储。向量数据库存储与检索将长篇的、静态的或历史的状态信息如产品文档、历史对话摘要、用户档案详情存入向量数据库。在需要时根据当前对话的语义从库中检索最相关的几个片段Chunk作为“上下文补充”插入提示词而不是携带全部信息。流程智能体收到查询。从向量库中检索出前K个最相关的历史片段。将这些片段作为“参考材料”与当前查询一起构成提示发送给LLM。LLM基于有限的、高相关的上下文生成回复。优势突破了上下文窗口的长度限制理论上可以关联海量历史信息。成本转移Token消耗从LLM API转移到了向量数据库的存储和检索上通常后者的成本更低且更具可预测性。传统数据库/缓存存储对于结构化的任务状态如订单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_strategiesNone): self.strategies compression_strategies or [“format” “summarize” “refine_tools”] def compress(self agent_state max_history_turns10): 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. 压缩的代价在成本、性能与可靠性间寻找平衡压缩不是免费的午餐每一种策略都可能引入新的问题需要在实践中小心权衡。信息丢失与任务漂移这是有损压缩最大的风险。过于激进的摘要或提炼可能会丢失关键细节导致智能体后续决策出错。例如在旅行规划中如果摘要漏掉了用户对“过敏原”的特殊要求后续推荐的餐厅就可能出问题。缓解策略实施“关键信息检查点”。定义一组绝对不能丢失的信息维度如预算、日期、硬性约束在压缩过程中显式地检查并确保这些信息被保留。或者采用“混合”模式关键信息以结构化字段保留非关键叙述性内容才进行摘要。计算开销与延迟压缩本身需要计算资源。调用GPT-5-mini进行摘要和提炼虽然比主模型便宜但也增加了额外的API调用和网络延迟。向量数据库的检索也需要时间。缓解策略异步与非实时压缩。对于对话摘要不必每轮都做可以设定一个时间或长度阈值。对于工具结果提炼如果后续步骤并非立即需要全部细节也可以稍后异步处理。衡量压缩节省的Token成本与额外计算开销之间的平衡点。系统复杂度提升状态外部化如使用向量库引入了新的基础设施依赖和数据一致性问题。差异化更新要求状态合并逻辑健壮。整个系统从“纯提示工程”变成了一个更复杂的分布式系统调试难度增加。缓解策略逐步引入充分测试。先从最简单的格式压缩和对话摘要开始观察效果。引入新组件时做好完备的日志记录记录压缩前、后的状态快照以便在出现问题时能够回溯。对模型“思维链”的影响如果压缩掉了模型的内部推理步骤虽然节省了Token但我们也失去了洞察模型决策过程的机会不利于调试和优化。缓解策略区分环境。在开发、调试阶段可以保留完整的思维链。在生产环境可以尝试只保留最终结论或者将详细的思维链记录到独立的日志系统中而不是主上下文里。6. 效果评估与监控如何量化你的压缩收益优化不能凭感觉必须建立度量指标。以下是一些关键的评估维度核心指标平均每轮交互Token数这是最直接的效益指标。在引入压缩策略前后统计相同或类似任务流下平均每次调用LLM API所消耗的提示词PromptToken数。下降百分比就是你的直接成本节省。质量指标任务完成率与用户满意度压缩不能损害功能。需要A/B测试对比压缩版和未压缩版智能体在核心任务如客服问题解决率、旅行计划完整性上的表现。可以通过人工评估或自动化关键节点检查来实现。性能指标响应延迟监控从用户请求到收到智能体回复的总时间。确保引入压缩管道尤其是需要额外模型调用的策略后延迟仍在可接受范围内。辅助指标上下文窗口利用率观察你的提示词长度距离模型上下文窗口上限还有多少余量。健康的压缩应该使利用率保持在一个安全水位例如对于128K窗口日常使用在80K以下为复杂的任务高峰预留空间。建立一个监控面板持续跟踪这些指标。当业务逻辑或状态结构发生变化时重新评估压缩策略的有效性。7. 面向未来更智能的压缩与模型进化我们讨论的压缩很大程度上是在弥补当前LLM作为“无状态”推理引擎的不足。未来的发展可能会从两个方向改变游戏规则模型原生支持长上下文与状态管理像GPT-4.1这类模型可能在架构层面就优化了对长上下文的处理效率或者通过更精细的注意力机制降低长文本的计算开销。更革命性的是如果模型API能原生支持“会话状态”的托管允许开发者通过一个session_id来关联历史而无需在每次请求中传递那么上下文Token的消耗将大大减少。我们需要密切关注主流API提供商在这方面的动向。智能体框架的内置优化主流的智能体开发框架如LangChain LlamaIndex将会把状态压缩作为一项核心基础设施来提供。它们可能会提供开箱即用的、可配置的压缩中间件集成最优的摘要模型、向量检索方案让开发者无需从零造轮子。压缩算法的自适应化未来的压缩策略可能不再是静态配置的而是自适应的。智能体可以根据当前任务的类型、阶段以及状态的信息密度动态选择最合适的压缩策略组合。例如在任务规划阶段保留详细推理在执行阶段则高度压缩历史聚焦于当前动作。作为开发者我们现在的压缩实践一方面是为了立即降低成本、提升性能另一方面也是在为未来更优雅的解决方案积累经验和定义需求。在现阶段掌握状态压缩这项技能意味着你能在同等预算下部署更强大、更持久的智能体应用这在竞争中无疑是一个重要的优势。从我自己的项目经验来看一套合理的压缩组合拳轻松能将长期运行任务的Token消耗降低30%-50%这对于规模化应用而言意义重大。
1. 从“上下文膨胀”到“成本焦虑”为什么我们需要压缩智能体状态最近在折腾几个基于大语言模型的智能体项目从简单的客服机器人到复杂的多步骤工作流编排一个绕不开的痛点越来越明显上下文Context消耗的Token数量失控了。尤其是在使用“状态在上下文中”State-in-Context这种设计模式时问题尤为突出。简单来说为了让智能体记住对话历史、任务状态、用户偏好甚至它自己的“思考过程”开发者通常会把所有这些信息都塞进每次与大模型交互的提示词Prompt里。这就像你每次跟一个记忆力只有七秒的鱼说话都得先花十分钟把它的生平、你们聊过的所有事、以及它此刻应该做什么复述一遍。结果就是一个看似简单的交互可能轻易消耗掉几千甚至上万个Token。当你的应用日活上来或者智能体需要处理长周期、多轮次的任务时API调用成本会像坐了火箭一样飙升。更糟的是过长的上下文不仅烧钱还可能影响模型性能。主流模型都有上下文窗口限制当你的状态信息挤占了太多空间留给模型“思考”和生成高质量回复的空间就少了。这让我想起了早期网页开发大家一股脑往HTML里塞样式和脚本导致页面臃肿不堪加载缓慢。现在的“状态在上下文中”智能体正面临着类似的“上下文膨胀”问题。因此“压缩”Minification成了一个必须认真对待的工程优化方向。这不仅仅是抠成本更是为了提升智能体的可靠性、响应速度和整体用户体验。我们需要像前端工程师优化网页加载性能一样来优化我们智能体的“思考负载”。2. 理解“状态在上下文中”智能体的核心结构与消耗源要有效压缩首先得知道“肥肉”长在哪里。一个典型的State-in-Context Agent其状态管理通常遵循一个循环感知用户输入/环境反馈→ 更新内部状态 → 基于状态决定行动 → 执行行动 → 将新状态写入下一次交互的上下文。这个“内部状态”就是我们需要管理的大头。2.1 状态信息的典型构成我们可以把一个智能体的上下文状态拆解成几个主要部分每一部分都是潜在的Token消耗大户对话历史Conversation History最直观的部分。包括用户的所有提问和智能体的所有回复。在多轮对话中这部分会线性增长。任务状态与元数据Task State Metadata智能体正在执行的任务的进度、目标、已完成的步骤、待办事项列表、参数等。例如一个旅行规划智能体的状态可能包含{destination: “东京” dates: “2023-10-01 to 2023-10-07” budget: 5000 completed_steps: [“确定目的地” “查询航班”] current_step: “筛选酒店”}。智能体自身指令与角色设定System Prompt / Persona定义智能体是谁、应该遵循什么规则、具备什么能力的长篇描述。这部分虽然相对静态但为了效果开发者往往会写得非常详细轻易就能占去几百个Token。工具/函数调用历史与结果Tool Call History Results如果智能体可以调用外部API如搜索、计算、数据库查询那么每次调用的函数名、参数以及返回的结果可能是大段的JSON或文本都会被记录在上下文中以供后续决策参考。这部分数据量可能非常大特别是当返回结果是网页摘要、长文档片段或复杂数据结构时。内部推理链或思维过程Chain-of-Thought / Reasoning Traces为了让模型输出更可靠我们常鼓励它“一步一步思考”并将这些中间思考步骤也输出出来。这些“思维痕迹”对于调试和理解模型行为非常有用但同样会占据大量上下文空间。2.2 Token消耗的动态模型Token消耗不是静态的。它随着交互轮次呈非线性增长因为新产生的状态会不断附加到历史状态之后。假设每轮交互平均产生S个Token的新状态经过n轮对话后仅状态部分消耗的Token就可能达到O(n * S)如果再考虑完整的对话历史消耗会更快。当总长度接近模型上下文窗口上限如GPT-4的128K时就会触发模型的“长上下文遗忘”机制最早的信息会被丢弃可能导致智能体失忆任务失败。因此压缩的目标很明确在保证智能体功能完整性和决策质量的前提下最大限度地减少每次API调用时需要放入上下文中的状态信息的Token数量。3. 压缩策略全景图从基础清洗到高级抽象压缩不是简单的删除而是一种有损的信息提炼。下面我结合实践梳理出一套从易到难、从通用到专用的压缩策略。3.1 基础层无损压缩与格式优化这一层的目标是挤掉“水分”不损失任何信息含义。去除冗余格式与空白符这是最像前端代码Minification的一步。将JSON状态中的缩进、换行、多余空格全部去掉。将冗长的自然语言系统提示中的啰嗦表达进行精简。实操示例优化前System Prompt: “你是一个乐于助人且专业的AI助手。你的目标是尽你所能以准确、清晰、详尽的方式回应用户的查询和请求。请始终保持友好和礼貌的态度。”优化后: “专业且友好的AI助手准确清晰地响应用户请求。”工具对于JSON可以使用编程语言自带的json.dumps(..., separators(‘,’, ‘:’))Python来生成最紧凑格式。对于自然语言则需要人工或通过另一个轻量级LLM进行重写提炼。键名缩写在JSON状态中将长的键名替换为短的缩写并维护一个映射表在代码中。示例{user_preferences”: {“favorite_color”: “blue” “newsletter_subscribed”: true}}可以压缩为{“up”: {“fc”: “blue” “ns”: true}}。注意这会给调试带来一些不便需要确保映射表被妥善管理。数据序列化格式选择虽然JSON易读性好但并非最紧凑的格式。在某些对极致压缩有要求的场景可以考虑MessagePack、CBOR或Protocol Buffers等二进制序列化格式。不过这需要额外的编解码步骤并且大多数LLM API直接接收文本所以通常需要在发送前编码为Base64等文本格式可能会抵消部分压缩收益需权衡。3.2 核心层有损压缩与信息提炼这一层开始涉及对信息内容的取舍和再加工是压缩效果最显著的环节。对话历史摘要Conversation Summarization这是应对长对话的杀手锏。不要保存完整的原始对话而是定期例如每5轮或当Token数达到阈值时用模型对之前的对话历史生成一个简洁的摘要。如何做设计一个摘要提示词要求模型提取关键决策、用户的核心意图和已确认的事实忽略寒暄和无关细节。示例提示词“请将以下对话历史总结为一个简洁的段落只保留与用户核心请求规划一次东京旅行相关的关键信息如已确定的预算、日期、兴趣点以及已完成的步骤如航班已查询。忽略问候语和重复确认。”进阶技巧可以采用“增量摘要”策略。只摘要最老的、超出窗口的部分而保留最近几轮完整的、高相关性的对话。这样既能压缩又能保证近期上下文的丰富性。工具调用结果的提炼工具返回的原始数据如整篇网页内容、庞大的API响应是Token消耗的巨兽。我们不应该直接把原始结果丢进上下文。策略在工具调用后立即用一个“提炼”步骤让另一个轻量且快速的模型如GPT-5-mini这类小型模型非常适合此角色从结果中提取出对当前任务最关键的信息。示例智能体调用搜索API获取“东京三天游攻略”返回了10个网页的摘要。提炼步骤可以要求GPT-5-mini“基于用户想要规划文化之旅的需求从以下搜索结果中提取出最重要的3-4个景点推荐、1-2条交通建议并以极简的要点列出。” 这样原本可能上千Token的搜索结果被压缩成了不到100Token的精华要点。状态差异化更新不要每次都将完整状态序列化到上下文。只记录自上次交互以来发生变化的状态Delta。机制在代码中维护一个完整的状态对象。每次交互后计算当前状态与上一次提交到上下文的状态之间的差异diff只将这个“差异”连同必要的指令如“将以下变更合并到你的状态中”发送给模型。挑战这要求智能体具备合并差异的能力。你需要在系统提示中明确指导模型如何理解和应用这些差异更新。这增加了逻辑复杂性但在状态结构稳定、变化局部的场景下效果极佳。3.3 架构层状态外部化与引用机制这是更根本的解法将状态移出模型的上下文另寻他处存储。向量数据库存储与检索将长篇的、静态的或历史的状态信息如产品文档、历史对话摘要、用户档案详情存入向量数据库。在需要时根据当前对话的语义从库中检索最相关的几个片段Chunk作为“上下文补充”插入提示词而不是携带全部信息。流程智能体收到查询。从向量库中检索出前K个最相关的历史片段。将这些片段作为“参考材料”与当前查询一起构成提示发送给LLM。LLM基于有限的、高相关的上下文生成回复。优势突破了上下文窗口的长度限制理论上可以关联海量历史信息。成本转移Token消耗从LLM API转移到了向量数据库的存储和检索上通常后者的成本更低且更具可预测性。传统数据库/缓存存储对于结构化的任务状态如订单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_strategiesNone): self.strategies compression_strategies or [“format” “summarize” “refine_tools”] def compress(self agent_state max_history_turns10): 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. 压缩的代价在成本、性能与可靠性间寻找平衡压缩不是免费的午餐每一种策略都可能引入新的问题需要在实践中小心权衡。信息丢失与任务漂移这是有损压缩最大的风险。过于激进的摘要或提炼可能会丢失关键细节导致智能体后续决策出错。例如在旅行规划中如果摘要漏掉了用户对“过敏原”的特殊要求后续推荐的餐厅就可能出问题。缓解策略实施“关键信息检查点”。定义一组绝对不能丢失的信息维度如预算、日期、硬性约束在压缩过程中显式地检查并确保这些信息被保留。或者采用“混合”模式关键信息以结构化字段保留非关键叙述性内容才进行摘要。计算开销与延迟压缩本身需要计算资源。调用GPT-5-mini进行摘要和提炼虽然比主模型便宜但也增加了额外的API调用和网络延迟。向量数据库的检索也需要时间。缓解策略异步与非实时压缩。对于对话摘要不必每轮都做可以设定一个时间或长度阈值。对于工具结果提炼如果后续步骤并非立即需要全部细节也可以稍后异步处理。衡量压缩节省的Token成本与额外计算开销之间的平衡点。系统复杂度提升状态外部化如使用向量库引入了新的基础设施依赖和数据一致性问题。差异化更新要求状态合并逻辑健壮。整个系统从“纯提示工程”变成了一个更复杂的分布式系统调试难度增加。缓解策略逐步引入充分测试。先从最简单的格式压缩和对话摘要开始观察效果。引入新组件时做好完备的日志记录记录压缩前、后的状态快照以便在出现问题时能够回溯。对模型“思维链”的影响如果压缩掉了模型的内部推理步骤虽然节省了Token但我们也失去了洞察模型决策过程的机会不利于调试和优化。缓解策略区分环境。在开发、调试阶段可以保留完整的思维链。在生产环境可以尝试只保留最终结论或者将详细的思维链记录到独立的日志系统中而不是主上下文里。6. 效果评估与监控如何量化你的压缩收益优化不能凭感觉必须建立度量指标。以下是一些关键的评估维度核心指标平均每轮交互Token数这是最直接的效益指标。在引入压缩策略前后统计相同或类似任务流下平均每次调用LLM API所消耗的提示词PromptToken数。下降百分比就是你的直接成本节省。质量指标任务完成率与用户满意度压缩不能损害功能。需要A/B测试对比压缩版和未压缩版智能体在核心任务如客服问题解决率、旅行计划完整性上的表现。可以通过人工评估或自动化关键节点检查来实现。性能指标响应延迟监控从用户请求到收到智能体回复的总时间。确保引入压缩管道尤其是需要额外模型调用的策略后延迟仍在可接受范围内。辅助指标上下文窗口利用率观察你的提示词长度距离模型上下文窗口上限还有多少余量。健康的压缩应该使利用率保持在一个安全水位例如对于128K窗口日常使用在80K以下为复杂的任务高峰预留空间。建立一个监控面板持续跟踪这些指标。当业务逻辑或状态结构发生变化时重新评估压缩策略的有效性。7. 面向未来更智能的压缩与模型进化我们讨论的压缩很大程度上是在弥补当前LLM作为“无状态”推理引擎的不足。未来的发展可能会从两个方向改变游戏规则模型原生支持长上下文与状态管理像GPT-4.1这类模型可能在架构层面就优化了对长上下文的处理效率或者通过更精细的注意力机制降低长文本的计算开销。更革命性的是如果模型API能原生支持“会话状态”的托管允许开发者通过一个session_id来关联历史而无需在每次请求中传递那么上下文Token的消耗将大大减少。我们需要密切关注主流API提供商在这方面的动向。智能体框架的内置优化主流的智能体开发框架如LangChain LlamaIndex将会把状态压缩作为一项核心基础设施来提供。它们可能会提供开箱即用的、可配置的压缩中间件集成最优的摘要模型、向量检索方案让开发者无需从零造轮子。压缩算法的自适应化未来的压缩策略可能不再是静态配置的而是自适应的。智能体可以根据当前任务的类型、阶段以及状态的信息密度动态选择最合适的压缩策略组合。例如在任务规划阶段保留详细推理在执行阶段则高度压缩历史聚焦于当前动作。作为开发者我们现在的压缩实践一方面是为了立即降低成本、提升性能另一方面也是在为未来更优雅的解决方案积累经验和定义需求。在现阶段掌握状态压缩这项技能意味着你能在同等预算下部署更强大、更持久的智能体应用这在竞争中无疑是一个重要的优势。从我自己的项目经验来看一套合理的压缩组合拳轻松能将长期运行任务的Token消耗降低30%-50%这对于规模化应用而言意义重大。
