1. 项目概述当LLM智能体学会“自我清理”最近在折腾长周期任务的LLM智能体时我遇到了一个几乎所有同行都会头疼的问题上下文爆炸。你给智能体设定一个目标比如“开发一个完整的Web应用”它开始规划、写代码、调试对话轮数轻松突破几十轮。这时LLM的上下文窗口就像一间从不打扫的房间堆满了过时的计划草稿、早已解决的错误日志、以及不再相关的中间文件。智能体的“记忆力”开始混乱响应速度变慢甚至做出基于陈旧信息的错误决策。这不仅仅是资源浪费更是长周期任务可靠性的致命瓶颈。“Self-GC: Self-Governing Context for Long-Horizon LLM Agents”这个项目直击的就是这个痛点。它的核心思想非常巧妙让智能体自己学会做“垃圾回收”。这不仅仅是简单的历史对话截断而是一套让智能体能够自主评估上下文信息价值主动压缩、提炼、归档或丢弃信息的自我治理机制。你可以把它想象成一位拥有极强归纳整理能力的项目助理在项目推进过程中不断将冗长的会议纪要提炼成行动项将已完成的待办事项归档只把当前最相关的资料放在手边。这个概念之所以重要是因为它触及了构建实用级自主智能体的核心。我们不再满足于智能体完成三五轮对话的简单任务而是希望它们能管理持续数天甚至数周的项目处理包含数百个步骤的复杂工作流。没有高效的上下文管理这一切都是空中楼阁。Self-GC试图赋予智能体一种“认知负荷管理”能力使其能够长期稳定运行这对于实现真正的LLM-powered Autonomous Agents至关重要。2. 核心设计思路从被动承载到主动治理传统的LLM智能体上下文管理大多处于一种被动承载的状态。常见的方法无外乎几种滑动窗口法只保留最近N条对话、关键信息提取法定期总结、或者干脆依赖外部向量数据库来存储历史。这些方法各有各的问题。滑动窗口会无情地丢失可能有长期价值的早期信息手动总结的时机和粒度难以把握外部存储则引入了检索延迟和精度损失形成了“侧信道”依赖。Self-GC的设计哲学是根本性的转变将上下文管理提升为智能体核心能力的一部分使其具备自我治理的“元认知”。它的思路不是从外部强行给智能体套一个管理策略而是让智能体在任务执行过程中自发地、动态地维护一个高质量、高密度的上下文工作集。2.1 核心组件拆解要实现自我治理Self-GC机制通常需要几个核心组件协同工作价值评估器这是Self-GC的“大脑”。它的任务是给上下文中的每一条信息可能是一段对话、一个工具调用结果、一个内部状态打分。打分标准不是固定的而是基于当前任务阶段、目标、以及历史效用动态调整。例如在代码调试阶段一条具体的错误信息和其解决方案价值极高但当这个模块测试通过后其价值就迅速衰减只需保留“XX模块已通过测试”的结论性事实即可。压缩与提炼引擎对于价值尚存但信息冗余的内容不是直接丢弃而是进行压缩。这不仅仅是文本摘要更是一种面向任务的提炼。比如将十轮关于API接口设计的讨论提炼成一份结构化的“API设计规范v1.0”文档并丢弃原始的散乱对话。这个引擎需要深度理解任务领域才能做出有效的提炼。归档与唤醒机制对于暂时不需要但未来可能至关重要的信息如项目早期设定的核心约束、客户原始需求Self-GC会将其进行结构化归档。归档不是简单的存储而是建立索引和关联。当智能体后续任务触发了相关关键词或目标时这套机制能够像记忆联想一样精准地唤醒相关的归档信息并将其重新纳入工作上下文。决策与执行模块这个模块基于价值评估器的输出决定对每段信息采取何种操作保留、压缩、归档还是丢弃。同时它还要决定执行这些操作的时机是在每轮对话后还是在达成某个子目标后这需要一套轻量而高效的触发策略。2.2 与“侧信道规划器”的协同在更复杂的架构中Self-GC往往会与一个“侧信道规划器”协同工作。这里的“侧信道”并非指安全漏洞而是指一个与主任务执行流并行的、专门负责宏观规划和上下文管理的思维链。你可以理解为智能体有了“双重思维”一个线程主信道专注执行当前具体动作如写一行代码、调用一个API另一个线程侧信道则每隔一段时间就跳出来以更高视角审视任务进展并指挥Self-GC进行上下文整理和下一步的路线规划。这种架构的优势很明显它实现了规划与执行的解耦避免了智能体在复杂思考时“钻牛角尖”。侧信道规划器负责制定和更新高层次计划而Self-GC则负责确保执行这个计划所需的上下文始终是干净、相关的。两者结合让智能体既能保持宏观方向感又能高效处理微观任务。3. 实现一个基础版Self-GC机制理论讲起来可能有些抽象我们直接来看一个相对基础但完整的实现方案。这里我们以构建一个“自动化数据分析报告智能体”为例它需要根据用户需求连接数据库执行一系列查询、分析和可视化最终生成报告。这个任务周期长、步骤多是Self-GC的典型应用场景。我们将基于流行的智能体开发框架如LangChain的AgentExecutor或AutoGen的GroupChat来构建但核心逻辑是框架无关的。3.1 第一步定义上下文信息结构与价值评估维度首先我们需要定义智能体上下文中流动的都是什么信息。通常包括用户消息用户的原始指令和后续反馈。智能体思考链式思考CoT的过程记录。工具调用与结果调用了哪个工具如execute_sqlgenerate_plot传入参数是什么返回结果是什么。内部状态当前任务阶段、已完成的子目标列表、遇到的错误历史等。接下来为每类信息设计价值评估维度。一个简单的多维度打分模型可以如下class ContextItem: def __init__(self, content, item_type, timestamp, metadataNone): self.content content # 信息内容 self.item_type item_type # 如 ‘user_input‘ ’agent_thought‘ ’tool_result‘ self.timestamp timestamp self.metadata metadata or {} # 可包含工具名、成功与否、关联的子目标等 def calculate_value(self, current_phase, completed_subgoals): 计算当前时刻该信息项的价值得分0-1 base_score 0.5 # 规则1类型权重 type_weights {user_original_goal: 1.0 user_feedback: 0.8 agent_plan: 0.7 tool_result_success: 0.6 tool_result_error: 0.9 agent_thought: 0.3} base_score * type_weights.get(self.item_type, 0.5) # 规则2时效性衰减越旧价值越低 age time.now() - self.timestamp recency_decay max(0, 1 - age.total_seconds() / 3600) # 1小时内线性衰减 base_score * recency_decay # 规则3任务相关性是否与当前阶段强相关 # 假设metadata中存储了关联的‘subgoal’ item_subgoal self.metadata.get(related_subgoal) if item_subgoal and item_subgoal current_phase: base_score * 1.5 # 当前阶段相关信息价值提升 elif item_subgoal and item_subgoal in completed_subgoals: base_score * 0.3 # 已完成阶段的信息价值大幅降低 # 规则4错误信息特殊处理近期错误需重点保留以供排查 if self.item_type tool_result_error and recency_decay 0.5: base_score min(1.0, base_score * 2) return min(1.0, max(0, base_score)) # 钳制在0-1这个评估模型虽然简单但融合了信息类型、时效性、任务阶段相关性等多个关键维度。在实际应用中你甚至可以引入一个小型神经网络来学习价值评估根据任务完成成功率来动态调整权重。3.2 第二步构建压缩与提炼策略对于价值评分处于中间区间比如0.3-0.7的信息我们启动压缩提炼。压缩的目标是保留信息熵减少token占用。对于工具调用序列的压缩示例假设智能体连续执行了5次SQL查询来探索数据分布原始的上下文记录了5次独立的工具调用和结果非常冗长。压缩引擎可以将其提炼为【数据探索阶段总结】 目标理解用户表users的核心字段分布。 执行操作 1. 查询了‘users‘表的行数总计1234567行。 2. 检查了‘registration_date‘的范围从2020-01-01至2024-05-20。 3. 分析了‘country‘字段的分布前五为US IN GB DE FR。 4. 确认了‘last_login‘字段的空值率约15%。 5. 验证了核心数值字段‘account_balance‘无异常负值。 结论数据集质量良好可用于后续的活跃用户分析。原始信息可能占用了上千个token压缩后仅用两百多个token就清晰概括了所有关键发现和结论并将原始细节归档。实现上可以调用LLM本身用一个独立的、提示词精心设计的调用来执行这种摘要性压缩。3.3 第三步设计Self-GC的触发与执行循环Self-GC不应该每轮都运行那样开销太大。一个合理的策略是将其嵌入智能体的主循环在关键节点触发。class SelfGCAgent: def __init__(self, context_window_size10000): self.context [] # 存储ContextItem对象的列表 self.working_memory [] # 高价值、当前相关的信息 self.archive {} # 归档信息按主题或子目标索引 self.context_window_size context_window_size def run_cycle(self, user_input): # 1. 接收新输入创建ContextItem并加入context new_item ContextItem(user_input, user_input, time.now()) self.context.append(new_item) self.working_memory.append(new_item) # 2. 智能体正常进行思考、规划、工具调用... # ... 这部分是原有的智能体逻辑期间产生的所有思考、工具结果都封装为ContextItem加入self.context # 3. 在关键节点如完成一个子目标、或context长度阈值触发GC if self._should_trigger_gc(): self._self_gc() # 4. 基于整理后的working_memory组织下一轮响应的上下文 return self._format_context_for_llm() def _should_trigger_gc(self): # 触发策略上下文token数超阈值或完成了一个明确子目标 estimated_tokens sum([estimate_tokens(item.content) for item in self.context]) return estimated_tokens self.context_window_size * 0.8 # 达到窗口80%时触发 def _self_gc(self): current_phase self._get_current_phase() # 获取当前任务阶段 completed_goals self._get_completed_subgoals() # 获取已完成的子目标 # 对context中所有item进行价值重估 for item in self.context: item.current_value item.calculate_value(current_phase, completed_goals) # 分类处理 new_working_memory [] for item in self.context: if item.current_value 0.7: # 高价值保留在工作记忆中 new_working_memory.append(item) elif 0.3 item.current_value 0.7: # 中等价值尝试压缩 compressed_item self._compress_item(item) if compressed_item: new_working_memory.append(compressed_item) # 原始item可考虑归档 self._archive_item(item, tagcurrent_phase) else: # 低价值丢弃或深度归档 self._archive_item(item, taglow_priority_archive) # 更新工作记忆 self.working_memory new_working_memory # 注意context列表本身可能仍保留所有item的引用或摘要用于长期追溯但提供给LLM的仅是working_memory print(f“[Self-GC Executed] Working memory condensed from {len(self.context)} items to {len(self.working_memory)} core items.”)这个循环确保了上下文池始终处于受控状态。工作记忆working_memory是经过GC筛选和压缩后的精华直接用于构成LLM的提示词。而完整的context和archive则作为历史记录供更复杂的查询或复盘使用。实操心得阈值设置的艺术_should_trigger_gc中的触发阈值如80%需要根据具体任务和模型窗口大小谨慎调整。设置过高如95%可能导致GC触发前模型就已因上下文过长而性能下降设置过低如50%则会导致过于频繁的GC打断任务连贯性。一个实用的技巧是结合“子目标完成”作为更强触发信号确保每个逻辑阶段结束后都进行一次整理让智能体“轻装上阵”进入下一阶段。4. 高级策略与性能优化基础版Self-GC解决了有无问题但要投入生产环境尤其是在复杂长周期任务中还需要考虑更多高级策略和优化点。4.1 分层上下文管理一个高效的上下文系统应该是分层的类似于计算机的存储体系L1缓存、L2缓存、内存、硬盘。L0 - 即时工作区即上述的working_memory容量最小如最近3-5轮高度相关的交互访问速度最快直接喂给LLM。这是智能体的“意识焦点”。L1 - 会话缓存保存当前任务会话中的所有context经过GC压缩但未丢弃。当智能体需要回顾稍早的细节比如“我之前是用哪个参数查询的”时可以快速从这里检索。L2 - 项目归档即archive按项目或顶级任务目标索引。存储被压缩后的历史、关键决策快照、最终成果物。用于项目复盘、知识沉淀或在新任务中加载先验经验。L3 - 外部知识库向量数据库或关系型数据库存储超越本次会话的通用知识、API文档、代码片段等。通过检索增强生成RAG方式按需接入。Self-GC主要管理L0和L1之间的数据流动以及决定哪些内容值得沉淀到L2。4.2 价值评估模型的迭代学习静态规则的价值评估器有其局限性。更先进的思路是让评估器能够从智能体自身的任务执行效果中学习。我们可以建立一个简单的反馈循环每当智能体成功完成一个子目标或最终任务就对导致这一成功路径上的上下文信息进行“正向强化”微调其价值评估权重。反之如果智能体因信息缺失或误导而犯错则对相关时期的信息进行“负向强化”。这相当于让Self-GC具备了根据历史效用进行自我优化的能力。实现上可以记录每个ContextItem的“被利用历史”。当某个信息项在后续步骤中被频繁引用并导向成功它的基础价值权重就应该提高。这种机制使得Self-GC越来越擅长为特定类型的任务保留最关键的信息。4.3 与规划器的深度集成如前所述Self-GC与规划器尤其是侧信道规划器的集成能产生“112”的效果。一个典型的工作流如下主信道执行智能体执行当前规划器指定的动作如运行查询A。侧信道监控与规划并行地侧信道规划器分析动作结果并更新长期计划。例如发现查询A的结果暗示了数据质量问题侧信道规划器可能决定插入一个“数据清洗”子目标。触发上下文重构侧信道规划器在更新计划后立即向Self-GC发送指令“当前阶段已从‘数据探索’切换到‘数据清洗’。请重新评估上下文价值提升与数据质量相关的错误和警告信息的优先级并压缩纯探索性的查询结果。”GC执行Self-GC根据新的任务阶段指令动态调整价值评估模型中的current_phase权重并立即执行一轮垃圾回收确保工作记忆与新的任务目标高度对齐。这种紧密集成使得上下文管理不再是周期性的后台任务而是成为了任务推进过程中的一个主动、定向的认知工具。5. 常见问题与实战调试技巧在实际部署Self-GC机制时我踩过不少坑也总结出一些调试技巧。5.1 问题一GC过于激进丢失关键信息这是最常见的问题。表现是智能体突然“失忆”忘记了用户早先提出的核心约束或者重复执行已经做过的步骤。排查与解决检查价值评估规则首先检查calculate_value函数中对于“用户原始目标”user_original_goal这类信息是否赋予了足够高且不易衰减的权重。通常这类信息的基础权重应接近1.0且时效性衰减系数应极低或为零。引入“信息锁”机制对于极其关键的信息项如项目核心KPI、不可违背的约束条件可以打上“锁定”标签。Self-GC在运行时会跳过对被锁定项的评估和压缩强制将其保留在工作记忆中。细化任务阶段如果“当前阶段”定义得太粗糙会导致GC误判。将“开发Web应用”细分为“需求确认”、“UI设计”、“后端API开发”、“前端集成”、“测试部署”等更细的阶段。这样在API开发阶段UI设计的讨论细节价值会自然降低但需求确认文档的价值依然很高因为它在所有阶段都相关。5.2 问题二GC开销过大影响响应速度如果GC过程涉及大量LLM调用进行文本压缩或者评估模型非常复杂会导致智能体响应明显变慢。排查与解决异步执行GC将_self_gc()过程改为异步任务。在主循环触发GC后智能体可以立即基于上一次的working_memory继续响应而GC在后台线程中运行。待GC完成后再原子性地替换掉旧的working_memory。这需要处理好状态一致性问题。简化压缩策略对于工具调用结果优先使用规则模板进行压缩而非每次都调用LLM。例如所有成功的SQL查询结果都可以用“查询[目的]成功返回[行数]行数据关键样本[前两行数据]”的模板来概括。仅对复杂的、非结构化的文本讨论才使用LLM摘要。抽样评估不必在每次GC时都对所有上下文项进行重估。可以对context列表进行采样或者只对上一次GC之后新增的项进行评估其余项沿用旧的价值分数结合一个全局的缓慢衰减因子。5.3 问题三压缩导致信息失真影响后续决策LLM进行的摘要压缩有时会遗漏关键细节或者引入误解导致智能体基于不准确的压缩信息做出错误判断。排查与解决保留可追溯性压缩不是删除。每当生成一个压缩项时都应在元数据中记录其来源的原始信息ID。当智能体在后续步骤中需要引用该压缩信息或者对其内容产生疑惑时可以提供一个“展开详情”的机制从归档中重新调取原始信息。关键数据结构化对于工具返回的结果尤其是数据查询类在存储时就将关键数值如行数、最大值、最小值、状态码提取为结构化的键值对与原始文本一同保存。压缩时优先保留这些结构化数据它们比文本摘要更可靠。压缩后验证对于非常重要的信息压缩可以设计一个简单的验证步骤。例如用另一个提示词让LLM检查压缩后的文本是否与原始文本在事实性上保持一致。虽然增加了开销但对于关键决策点来说是值得的。5.4 问题四在动态变化任务中阶段识别不准Self-GC严重依赖对当前任务阶段的准确判断。但在开放域任务中阶段的转换可能是模糊、动态甚至并发的。解决思路基于子目标完成状态不要硬编码阶段名称而是维护一个动态的“活跃子目标集合”和“已完成子目标集合”。价值评估基于信息与“活跃子目标”的相关性。当一个子目标的所有关键动作都标记完成它就从未活跃集合移入已完成集合。利用规划器输出与侧信道规划器深度集成直接使用规划器输出的“当前重点任务”或“下一步动作队列”作为价值评估的核心依据。规划器本身就是阶段的最佳定义者。聚类分析对上下文中的工具调用序列和对话主题进行简单的实时聚类分析。如果检测到智能体连续一段时间的行为模式发生了显著变化例如从频繁调用search_web变为频繁调用write_file则可以推断任务阶段可能已发生转换从而触发GC重新评估。6. 效果评估与未来展望实施Self-GC后如何衡量其效果不能只看上下文长度减少了更要看智能体最终的任务完成质量和效率。我常用的评估维度包括任务成功率在相同的长周期任务测试集上比较启用和禁用Self-GC时智能体完整达成目标的比例。成功的Self-GC应该能提升成功率。平均每轮响应时间由于输入给LLM的上下文更精简推理速度应有所提升。上下文Token使用效率计算“任务总产出如代码行数、报告质量分数”与“消耗的总上下文Token数”的比值。比值越高说明信息利用效率越高。抗干扰能力在任务中插入一些无关的干扰性对话或信息观察启用Self-GC的智能体是否比未启用的更能忽略干扰保持任务焦点。从我实践的几个项目来看一个设计良好的Self-GC机制能将长任务50轮的上下文长度稳定控制在模型窗口的50%以下同时任务成功率有10%-30%的提升因为智能体更少地“迷失”在历史细节中。未来我认为Self-GC会朝着更智能、更通用的方向发展。例如预测性GC不仅评估当前价值还能预测信息在未来潜在子目标中的价值提前进行保留或预加载。再比如跨会话GC将本次任务中学习到的上下文管理策略抽象成可迁移的“经验”应用到同一智能体的不同任务中实现持续学习。让LLM智能体学会自我治理上下文是将其从“单次对话的奇迹”转变为“长期运行的伙伴”的关键一步。这条路还很长但Self-GC已经为我们指出了一个清晰而实用的方向。 LLM智能体上下文管理：Self-GC机制实现长周期任务高效运行
1. 项目概述当LLM智能体学会“自我清理”最近在折腾长周期任务的LLM智能体时我遇到了一个几乎所有同行都会头疼的问题上下文爆炸。你给智能体设定一个目标比如“开发一个完整的Web应用”它开始规划、写代码、调试对话轮数轻松突破几十轮。这时LLM的上下文窗口就像一间从不打扫的房间堆满了过时的计划草稿、早已解决的错误日志、以及不再相关的中间文件。智能体的“记忆力”开始混乱响应速度变慢甚至做出基于陈旧信息的错误决策。这不仅仅是资源浪费更是长周期任务可靠性的致命瓶颈。“Self-GC: Self-Governing Context for Long-Horizon LLM Agents”这个项目直击的就是这个痛点。它的核心思想非常巧妙让智能体自己学会做“垃圾回收”。这不仅仅是简单的历史对话截断而是一套让智能体能够自主评估上下文信息价值主动压缩、提炼、归档或丢弃信息的自我治理机制。你可以把它想象成一位拥有极强归纳整理能力的项目助理在项目推进过程中不断将冗长的会议纪要提炼成行动项将已完成的待办事项归档只把当前最相关的资料放在手边。这个概念之所以重要是因为它触及了构建实用级自主智能体的核心。我们不再满足于智能体完成三五轮对话的简单任务而是希望它们能管理持续数天甚至数周的项目处理包含数百个步骤的复杂工作流。没有高效的上下文管理这一切都是空中楼阁。Self-GC试图赋予智能体一种“认知负荷管理”能力使其能够长期稳定运行这对于实现真正的LLM-powered Autonomous Agents至关重要。2. 核心设计思路从被动承载到主动治理传统的LLM智能体上下文管理大多处于一种被动承载的状态。常见的方法无外乎几种滑动窗口法只保留最近N条对话、关键信息提取法定期总结、或者干脆依赖外部向量数据库来存储历史。这些方法各有各的问题。滑动窗口会无情地丢失可能有长期价值的早期信息手动总结的时机和粒度难以把握外部存储则引入了检索延迟和精度损失形成了“侧信道”依赖。Self-GC的设计哲学是根本性的转变将上下文管理提升为智能体核心能力的一部分使其具备自我治理的“元认知”。它的思路不是从外部强行给智能体套一个管理策略而是让智能体在任务执行过程中自发地、动态地维护一个高质量、高密度的上下文工作集。2.1 核心组件拆解要实现自我治理Self-GC机制通常需要几个核心组件协同工作价值评估器这是Self-GC的“大脑”。它的任务是给上下文中的每一条信息可能是一段对话、一个工具调用结果、一个内部状态打分。打分标准不是固定的而是基于当前任务阶段、目标、以及历史效用动态调整。例如在代码调试阶段一条具体的错误信息和其解决方案价值极高但当这个模块测试通过后其价值就迅速衰减只需保留“XX模块已通过测试”的结论性事实即可。压缩与提炼引擎对于价值尚存但信息冗余的内容不是直接丢弃而是进行压缩。这不仅仅是文本摘要更是一种面向任务的提炼。比如将十轮关于API接口设计的讨论提炼成一份结构化的“API设计规范v1.0”文档并丢弃原始的散乱对话。这个引擎需要深度理解任务领域才能做出有效的提炼。归档与唤醒机制对于暂时不需要但未来可能至关重要的信息如项目早期设定的核心约束、客户原始需求Self-GC会将其进行结构化归档。归档不是简单的存储而是建立索引和关联。当智能体后续任务触发了相关关键词或目标时这套机制能够像记忆联想一样精准地唤醒相关的归档信息并将其重新纳入工作上下文。决策与执行模块这个模块基于价值评估器的输出决定对每段信息采取何种操作保留、压缩、归档还是丢弃。同时它还要决定执行这些操作的时机是在每轮对话后还是在达成某个子目标后这需要一套轻量而高效的触发策略。2.2 与“侧信道规划器”的协同在更复杂的架构中Self-GC往往会与一个“侧信道规划器”协同工作。这里的“侧信道”并非指安全漏洞而是指一个与主任务执行流并行的、专门负责宏观规划和上下文管理的思维链。你可以理解为智能体有了“双重思维”一个线程主信道专注执行当前具体动作如写一行代码、调用一个API另一个线程侧信道则每隔一段时间就跳出来以更高视角审视任务进展并指挥Self-GC进行上下文整理和下一步的路线规划。这种架构的优势很明显它实现了规划与执行的解耦避免了智能体在复杂思考时“钻牛角尖”。侧信道规划器负责制定和更新高层次计划而Self-GC则负责确保执行这个计划所需的上下文始终是干净、相关的。两者结合让智能体既能保持宏观方向感又能高效处理微观任务。3. 实现一个基础版Self-GC机制理论讲起来可能有些抽象我们直接来看一个相对基础但完整的实现方案。这里我们以构建一个“自动化数据分析报告智能体”为例它需要根据用户需求连接数据库执行一系列查询、分析和可视化最终生成报告。这个任务周期长、步骤多是Self-GC的典型应用场景。我们将基于流行的智能体开发框架如LangChain的AgentExecutor或AutoGen的GroupChat来构建但核心逻辑是框架无关的。3.1 第一步定义上下文信息结构与价值评估维度首先我们需要定义智能体上下文中流动的都是什么信息。通常包括用户消息用户的原始指令和后续反馈。智能体思考链式思考CoT的过程记录。工具调用与结果调用了哪个工具如execute_sqlgenerate_plot传入参数是什么返回结果是什么。内部状态当前任务阶段、已完成的子目标列表、遇到的错误历史等。接下来为每类信息设计价值评估维度。一个简单的多维度打分模型可以如下class ContextItem: def __init__(self, content, item_type, timestamp, metadataNone): self.content content # 信息内容 self.item_type item_type # 如 ‘user_input‘ ’agent_thought‘ ’tool_result‘ self.timestamp timestamp self.metadata metadata or {} # 可包含工具名、成功与否、关联的子目标等 def calculate_value(self, current_phase, completed_subgoals): 计算当前时刻该信息项的价值得分0-1 base_score 0.5 # 规则1类型权重 type_weights {user_original_goal: 1.0 user_feedback: 0.8 agent_plan: 0.7 tool_result_success: 0.6 tool_result_error: 0.9 agent_thought: 0.3} base_score * type_weights.get(self.item_type, 0.5) # 规则2时效性衰减越旧价值越低 age time.now() - self.timestamp recency_decay max(0, 1 - age.total_seconds() / 3600) # 1小时内线性衰减 base_score * recency_decay # 规则3任务相关性是否与当前阶段强相关 # 假设metadata中存储了关联的‘subgoal’ item_subgoal self.metadata.get(related_subgoal) if item_subgoal and item_subgoal current_phase: base_score * 1.5 # 当前阶段相关信息价值提升 elif item_subgoal and item_subgoal in completed_subgoals: base_score * 0.3 # 已完成阶段的信息价值大幅降低 # 规则4错误信息特殊处理近期错误需重点保留以供排查 if self.item_type tool_result_error and recency_decay 0.5: base_score min(1.0, base_score * 2) return min(1.0, max(0, base_score)) # 钳制在0-1这个评估模型虽然简单但融合了信息类型、时效性、任务阶段相关性等多个关键维度。在实际应用中你甚至可以引入一个小型神经网络来学习价值评估根据任务完成成功率来动态调整权重。3.2 第二步构建压缩与提炼策略对于价值评分处于中间区间比如0.3-0.7的信息我们启动压缩提炼。压缩的目标是保留信息熵减少token占用。对于工具调用序列的压缩示例假设智能体连续执行了5次SQL查询来探索数据分布原始的上下文记录了5次独立的工具调用和结果非常冗长。压缩引擎可以将其提炼为【数据探索阶段总结】 目标理解用户表users的核心字段分布。 执行操作 1. 查询了‘users‘表的行数总计1234567行。 2. 检查了‘registration_date‘的范围从2020-01-01至2024-05-20。 3. 分析了‘country‘字段的分布前五为US IN GB DE FR。 4. 确认了‘last_login‘字段的空值率约15%。 5. 验证了核心数值字段‘account_balance‘无异常负值。 结论数据集质量良好可用于后续的活跃用户分析。原始信息可能占用了上千个token压缩后仅用两百多个token就清晰概括了所有关键发现和结论并将原始细节归档。实现上可以调用LLM本身用一个独立的、提示词精心设计的调用来执行这种摘要性压缩。3.3 第三步设计Self-GC的触发与执行循环Self-GC不应该每轮都运行那样开销太大。一个合理的策略是将其嵌入智能体的主循环在关键节点触发。class SelfGCAgent: def __init__(self, context_window_size10000): self.context [] # 存储ContextItem对象的列表 self.working_memory [] # 高价值、当前相关的信息 self.archive {} # 归档信息按主题或子目标索引 self.context_window_size context_window_size def run_cycle(self, user_input): # 1. 接收新输入创建ContextItem并加入context new_item ContextItem(user_input, user_input, time.now()) self.context.append(new_item) self.working_memory.append(new_item) # 2. 智能体正常进行思考、规划、工具调用... # ... 这部分是原有的智能体逻辑期间产生的所有思考、工具结果都封装为ContextItem加入self.context # 3. 在关键节点如完成一个子目标、或context长度阈值触发GC if self._should_trigger_gc(): self._self_gc() # 4. 基于整理后的working_memory组织下一轮响应的上下文 return self._format_context_for_llm() def _should_trigger_gc(self): # 触发策略上下文token数超阈值或完成了一个明确子目标 estimated_tokens sum([estimate_tokens(item.content) for item in self.context]) return estimated_tokens self.context_window_size * 0.8 # 达到窗口80%时触发 def _self_gc(self): current_phase self._get_current_phase() # 获取当前任务阶段 completed_goals self._get_completed_subgoals() # 获取已完成的子目标 # 对context中所有item进行价值重估 for item in self.context: item.current_value item.calculate_value(current_phase, completed_goals) # 分类处理 new_working_memory [] for item in self.context: if item.current_value 0.7: # 高价值保留在工作记忆中 new_working_memory.append(item) elif 0.3 item.current_value 0.7: # 中等价值尝试压缩 compressed_item self._compress_item(item) if compressed_item: new_working_memory.append(compressed_item) # 原始item可考虑归档 self._archive_item(item, tagcurrent_phase) else: # 低价值丢弃或深度归档 self._archive_item(item, taglow_priority_archive) # 更新工作记忆 self.working_memory new_working_memory # 注意context列表本身可能仍保留所有item的引用或摘要用于长期追溯但提供给LLM的仅是working_memory print(f“[Self-GC Executed] Working memory condensed from {len(self.context)} items to {len(self.working_memory)} core items.”)这个循环确保了上下文池始终处于受控状态。工作记忆working_memory是经过GC筛选和压缩后的精华直接用于构成LLM的提示词。而完整的context和archive则作为历史记录供更复杂的查询或复盘使用。实操心得阈值设置的艺术_should_trigger_gc中的触发阈值如80%需要根据具体任务和模型窗口大小谨慎调整。设置过高如95%可能导致GC触发前模型就已因上下文过长而性能下降设置过低如50%则会导致过于频繁的GC打断任务连贯性。一个实用的技巧是结合“子目标完成”作为更强触发信号确保每个逻辑阶段结束后都进行一次整理让智能体“轻装上阵”进入下一阶段。4. 高级策略与性能优化基础版Self-GC解决了有无问题但要投入生产环境尤其是在复杂长周期任务中还需要考虑更多高级策略和优化点。4.1 分层上下文管理一个高效的上下文系统应该是分层的类似于计算机的存储体系L1缓存、L2缓存、内存、硬盘。L0 - 即时工作区即上述的working_memory容量最小如最近3-5轮高度相关的交互访问速度最快直接喂给LLM。这是智能体的“意识焦点”。L1 - 会话缓存保存当前任务会话中的所有context经过GC压缩但未丢弃。当智能体需要回顾稍早的细节比如“我之前是用哪个参数查询的”时可以快速从这里检索。L2 - 项目归档即archive按项目或顶级任务目标索引。存储被压缩后的历史、关键决策快照、最终成果物。用于项目复盘、知识沉淀或在新任务中加载先验经验。L3 - 外部知识库向量数据库或关系型数据库存储超越本次会话的通用知识、API文档、代码片段等。通过检索增强生成RAG方式按需接入。Self-GC主要管理L0和L1之间的数据流动以及决定哪些内容值得沉淀到L2。4.2 价值评估模型的迭代学习静态规则的价值评估器有其局限性。更先进的思路是让评估器能够从智能体自身的任务执行效果中学习。我们可以建立一个简单的反馈循环每当智能体成功完成一个子目标或最终任务就对导致这一成功路径上的上下文信息进行“正向强化”微调其价值评估权重。反之如果智能体因信息缺失或误导而犯错则对相关时期的信息进行“负向强化”。这相当于让Self-GC具备了根据历史效用进行自我优化的能力。实现上可以记录每个ContextItem的“被利用历史”。当某个信息项在后续步骤中被频繁引用并导向成功它的基础价值权重就应该提高。这种机制使得Self-GC越来越擅长为特定类型的任务保留最关键的信息。4.3 与规划器的深度集成如前所述Self-GC与规划器尤其是侧信道规划器的集成能产生“112”的效果。一个典型的工作流如下主信道执行智能体执行当前规划器指定的动作如运行查询A。侧信道监控与规划并行地侧信道规划器分析动作结果并更新长期计划。例如发现查询A的结果暗示了数据质量问题侧信道规划器可能决定插入一个“数据清洗”子目标。触发上下文重构侧信道规划器在更新计划后立即向Self-GC发送指令“当前阶段已从‘数据探索’切换到‘数据清洗’。请重新评估上下文价值提升与数据质量相关的错误和警告信息的优先级并压缩纯探索性的查询结果。”GC执行Self-GC根据新的任务阶段指令动态调整价值评估模型中的current_phase权重并立即执行一轮垃圾回收确保工作记忆与新的任务目标高度对齐。这种紧密集成使得上下文管理不再是周期性的后台任务而是成为了任务推进过程中的一个主动、定向的认知工具。5. 常见问题与实战调试技巧在实际部署Self-GC机制时我踩过不少坑也总结出一些调试技巧。5.1 问题一GC过于激进丢失关键信息这是最常见的问题。表现是智能体突然“失忆”忘记了用户早先提出的核心约束或者重复执行已经做过的步骤。排查与解决检查价值评估规则首先检查calculate_value函数中对于“用户原始目标”user_original_goal这类信息是否赋予了足够高且不易衰减的权重。通常这类信息的基础权重应接近1.0且时效性衰减系数应极低或为零。引入“信息锁”机制对于极其关键的信息项如项目核心KPI、不可违背的约束条件可以打上“锁定”标签。Self-GC在运行时会跳过对被锁定项的评估和压缩强制将其保留在工作记忆中。细化任务阶段如果“当前阶段”定义得太粗糙会导致GC误判。将“开发Web应用”细分为“需求确认”、“UI设计”、“后端API开发”、“前端集成”、“测试部署”等更细的阶段。这样在API开发阶段UI设计的讨论细节价值会自然降低但需求确认文档的价值依然很高因为它在所有阶段都相关。5.2 问题二GC开销过大影响响应速度如果GC过程涉及大量LLM调用进行文本压缩或者评估模型非常复杂会导致智能体响应明显变慢。排查与解决异步执行GC将_self_gc()过程改为异步任务。在主循环触发GC后智能体可以立即基于上一次的working_memory继续响应而GC在后台线程中运行。待GC完成后再原子性地替换掉旧的working_memory。这需要处理好状态一致性问题。简化压缩策略对于工具调用结果优先使用规则模板进行压缩而非每次都调用LLM。例如所有成功的SQL查询结果都可以用“查询[目的]成功返回[行数]行数据关键样本[前两行数据]”的模板来概括。仅对复杂的、非结构化的文本讨论才使用LLM摘要。抽样评估不必在每次GC时都对所有上下文项进行重估。可以对context列表进行采样或者只对上一次GC之后新增的项进行评估其余项沿用旧的价值分数结合一个全局的缓慢衰减因子。5.3 问题三压缩导致信息失真影响后续决策LLM进行的摘要压缩有时会遗漏关键细节或者引入误解导致智能体基于不准确的压缩信息做出错误判断。排查与解决保留可追溯性压缩不是删除。每当生成一个压缩项时都应在元数据中记录其来源的原始信息ID。当智能体在后续步骤中需要引用该压缩信息或者对其内容产生疑惑时可以提供一个“展开详情”的机制从归档中重新调取原始信息。关键数据结构化对于工具返回的结果尤其是数据查询类在存储时就将关键数值如行数、最大值、最小值、状态码提取为结构化的键值对与原始文本一同保存。压缩时优先保留这些结构化数据它们比文本摘要更可靠。压缩后验证对于非常重要的信息压缩可以设计一个简单的验证步骤。例如用另一个提示词让LLM检查压缩后的文本是否与原始文本在事实性上保持一致。虽然增加了开销但对于关键决策点来说是值得的。5.4 问题四在动态变化任务中阶段识别不准Self-GC严重依赖对当前任务阶段的准确判断。但在开放域任务中阶段的转换可能是模糊、动态甚至并发的。解决思路基于子目标完成状态不要硬编码阶段名称而是维护一个动态的“活跃子目标集合”和“已完成子目标集合”。价值评估基于信息与“活跃子目标”的相关性。当一个子目标的所有关键动作都标记完成它就从未活跃集合移入已完成集合。利用规划器输出与侧信道规划器深度集成直接使用规划器输出的“当前重点任务”或“下一步动作队列”作为价值评估的核心依据。规划器本身就是阶段的最佳定义者。聚类分析对上下文中的工具调用序列和对话主题进行简单的实时聚类分析。如果检测到智能体连续一段时间的行为模式发生了显著变化例如从频繁调用search_web变为频繁调用write_file则可以推断任务阶段可能已发生转换从而触发GC重新评估。6. 效果评估与未来展望实施Self-GC后如何衡量其效果不能只看上下文长度减少了更要看智能体最终的任务完成质量和效率。我常用的评估维度包括任务成功率在相同的长周期任务测试集上比较启用和禁用Self-GC时智能体完整达成目标的比例。成功的Self-GC应该能提升成功率。平均每轮响应时间由于输入给LLM的上下文更精简推理速度应有所提升。上下文Token使用效率计算“任务总产出如代码行数、报告质量分数”与“消耗的总上下文Token数”的比值。比值越高说明信息利用效率越高。抗干扰能力在任务中插入一些无关的干扰性对话或信息观察启用Self-GC的智能体是否比未启用的更能忽略干扰保持任务焦点。从我实践的几个项目来看一个设计良好的Self-GC机制能将长任务50轮的上下文长度稳定控制在模型窗口的50%以下同时任务成功率有10%-30%的提升因为智能体更少地“迷失”在历史细节中。未来我认为Self-GC会朝着更智能、更通用的方向发展。例如预测性GC不仅评估当前价值还能预测信息在未来潜在子目标中的价值提前进行保留或预加载。再比如跨会话GC将本次任务中学习到的上下文管理策略抽象成可迁移的“经验”应用到同一智能体的不同任务中实现持续学习。让LLM智能体学会自我治理上下文是将其从“单次对话的奇迹”转变为“长期运行的伙伴”的关键一步。这条路还很长但Self-GC已经为我们指出了一个清晰而实用的方向。