Context Window Management for Long-Running Agents: Strategies and Tradeoffs
TL;DR · AI 摘要
Context Window Management for Long-Running Agents: Strategies and Tradeoffs - MachineLearningMastery.com Context Window...
核心要点
- 主题聚焦：Context Window Management for Long-Running Agent
- 来源：Machine Learning Mastery，建议结合原文判断细节。
- AI 分析暂不可用，本条为保底评分与摘要。
长期运行代理的上下文窗口管理：策略与权衡 - MachineLearningMastery.com
长期运行代理的上下文窗口管理：策略与权衡
作者：
Iván Palomares Carrascosa
发布于：
2026年6月30日
分类：
人工智能
0
分享
文章
在本文中，你将学习到五种实用策略，用于管理长期运行AI代理应用中的上下文窗口，同时了解每种方法带来的关键权衡。
我们将涵盖的主题包括：
- 为什么在设计用于持续自主运行的基于代理的AI系统中，上下文窗口会成为关键瓶颈。
- 五种不同的上下文管理策略：滑动窗口、递归摘要、结构化状态管理、通过RAG实现的临时上下文，以及动态上下文路由。
- 每种策略固有的权衡，从记忆丢失和信息压缩到检索盲区和维护复杂性。
引言
长期运行代理是指能够随时间推移持续自主执行的代理。在这些基于代理的应用中——通过与用户或其他系统的交互，信息迅速累积——上下文窗口是关键瓶颈。可以说，代理和大型语言模型（LLMs）是现代AI系统中同一枚硬币的两面。因此，从将LLMs视为"提示-响应引擎"转变为"(具备代理能力的)LLMs作为长期后台进程"，使上下文窗口成为AI工程中的主要瓶颈。
鉴于上述所有原因，长期管理上下文窗口需要特定的策略，如滑动窗口、分级内存和动态摘要。本文介绍了五种不同的操作策略，并附带它们不可避免的权衡。
1. 滑动窗口
设想一个AI代理，它只能记住过去十分钟的工作内容。滑动窗口方法通过管理内存限制来实现这一目标：当历史记录过长时，会删除最旧的消息，为最新消息腾出空间，仅将核心指令"锁定"在上下文顶部。
以下是一个滑动窗口实现的示例（代码本身不旨在单独执行，仅用于说明目的）：
def manage_sliding_window(system_prompt, message_history, max_turns=10): """保留永久系统指令，并在历史记录过长时删除最旧的对话轮次。 """ if len(message_history) > max_turns: # 修剪历史记录，仅保留最新的 'X' 条消息 message_history = message_history[-max_turns:] # 始终在开头添加系统提示，使代理记住其身份 return [system_prompt] + message_history
1
2
3
4
5
6
7
8
9
10
def
manage_sliding_window
(
system_prompt
,
message_history
max_turns
=
)
:
""
"保留永久系统指令，并在历史记录过长时删除最旧的对话轮次。
"
if
len
修剪历史记录，仅保留最新的 'X' 条消息
[
-
]
始终在开头添加系统提示，使代理记住其身份
return
+
由于无需额外AI处理，这种策略极其廉价且快速，但有一个注意事项："数字遗忘症"。换句话说，如果代理遇到一小时前已经处理过的问题，它将完全忘记如何处理，这可能导致其陷入无限循环。
2. 递归摘要
- 结构化状态管理
在此策略中，运行中的聊天记录会被完全舍弃。取而代之的是，代理维护一个可管理的JSON对象，用于跟踪目标、事实和错误——充当一种结构化的“草稿纸”。在每一步操作中，原始对话都会被丢弃，AI代理仅接收核心指令、更新后的JSON对象和当前的新输入。这无疑是一种非常节省token的策略。然而，它高度依赖开发者定义的跟踪标准。如果关键但未预料到的变量超出预定义的模式范围，代理将不可避免地忽略它们。
以下是该策略实现的简化示例：
def run_scratchpad_turn(system_prompt, scratchpad_state, new_input): """完全清除对话历史。代理仅使用核心指令、当前状态和新任务进行导航。 """ # 将固定状态与新输入合并为单个提示 prompt = f"{system_prompt}\nMEMORIZED STATE: {scratchpad_state}\nNEW INPUT: {new_input}" # AI处理提示，返回下一步操作和更新后的状态 ai_output = call_llm(prompt, response_format="json") return ai_output["chosen_action"], ai_output["updated_scratchpad"]
11
run_scratchpad_turn
scratchpad_state
new_input
"完全清除对话历史。代理仅使用核心指令、当前状态和新任务进行导航。
将固定状态与新输入合并为单个提示
prompt
f
"{system_prompt}\nMEMORIZED STATE: {scratchpad_state}\nNEW INPUT: {new_input}"
AI处理提示，返回下一步操作和更新后的状态
ai_output
call_llm
response_format
"json"
"chosen_action"
"updated_scratchpad"
4. 通过RAG实现的临时上下文
基于RAG的策略将累积的上下文全部卸载到外部数据库（在RAG系统中为向量数据库，如此处所述）。这为强制代理在活跃内存中保留历史记录提供了替代方案，使得通过相关性搜索可以将最相关的过去事件检索到当前提示中。理论上这可以让代理无限运行而不会出现上下文过载问题。然而存在一个缺点：检索盲区，特别是当代理需要重新连接两个看似无关的过去事件时。依赖检索器及其底层搜索策略可能会导致遗漏本应连接重要“思维碎片”的相关上下文。
5. 动态上下文路由
这种策略旨在平衡能力和成本。它让两种不同的AI模型协同工作。主代理执行高频、重复性任务，依赖于一个更快、更便宜的模型，该模型处理较小的上下文窗口。与此同时，当发生异常事件——例如任务连续三次失败时——完整的原始历史记录会被转发给一个具有大上下文窗口的强大模型，该模型分析全局情况，并将更清晰的指令集反馈给较便宜的模型。这是一种相当节省成本的策略，但可靠识别较便宜模型何时陷入困境所需的代码可能极其难以维护和微调。
总结
本文概述了五种策略——以及它们不可避免的权衡——以优化长期运行的基于代理的AI应用中的上下文窗口管理。但请注意：最终，构建成功的自主代理应用并不是追求无限记忆的幻觉，而是要构建更智能的架构和底层逻辑，以确定需要记住的内容，以及代理可以承担遗忘的内容。
更多相关内容
- 位置编码中的插值与YaRN的使用…
- 数据管理的重要性及为何需要关注…
- 革新MLOps：增强的BigQuery ML UI…
- AI代理的有效上下文工程：…
- 为长期运行代理构建上下文修剪流水线
- 如何开发和评估朴素分类器…