真实面经题目 · 原创解析
Agent 使用滑动窗口摘要时,旧摘要应逐步合并还是分段保留,如何控制信息遗失、冲突和可追溯性?
这题考滑动窗口摘要的状态维护策略:合并摘要更省上下文,分段摘要更可追溯,工程上通常需要分层结构而不是二选一。
真实面经题目 · 原创解析
这题考滑动窗口摘要的状态维护策略:合并摘要更省上下文,分段摘要更可追溯,工程上通常需要分层结构而不是二选一。
滑动窗口摘要不建议简单回答“全部合并”或“全部分段”。我会按任务长度、可追溯要求和状态变化来选。合并成一份滚动摘要的优点是上下文最省,模型每次只读一个当前状态,适合短到中等任务、约束稳定、历史冲突少的场景;缺点是多次摘要会产生信息衰减,旧细节容易被改写,发生冲突时难以知道某个结论来自哪一轮。分段保留摘要的优点是可追溯性好,可以按阶段回看需求澄清、工具执行、错误恢复和用户确认,也方便定位冲突;缺点是摘要段越多越占 token,模型可能读到重复或过期信息。实际工程里更推荐分层策略:保留一份 current state 作为合并后的最新任务状态,同时保留若干带时间和来源范围的阶段摘要;再把原始消息、工具结果和文件产物放在 trace 或外部存储里,需要时检索回查。更新时不要让新摘要覆盖所有旧摘要,而是做结构化合并:目标、硬约束、已确认事实、待办、决策、风险和证据引用分别更新,冲突字段显式标记。这样既能控制 token,又能避免长期摘要漂移。落地时还要给摘要设置版本、覆盖范围、过期标记和召回规则,避免旧阶段内容反复污染当前状态。评估时要看长任务完成率、硬约束保留率、冲突恢复能力、引用可追溯性和压缩后成本延迟。
合并摘要解决的是上下文成本和当前状态聚焦,分段摘要解决的是历史可追溯和阶段边界。面向 Agent 长任务时,问题不只是省 token,还包括能否记住硬约束、识别过期信息、回查决策来源和处理用户反悔。因此不能把它简化成一种固定选择。
如果任务目标清楚、历史冲突少、主要需要一个最新状态,那么滚动合并摘要很高效。每轮把新窗口内容合入 current state,保留当前目标、约束、进度、待办和关键事实。它的风险是摘要多次迭代后发生语义漂移,早期细节被概括掉,模型难以判断某个结论是否仍然有效。
如果任务包含多个阶段、工具调用、人工确认、失败恢复或重要决策,分段摘要更稳。每段摘要记录覆盖的消息范围、阶段标题、关键输入输出、决策和证据引用。后续只把相关阶段召回,而不是让模型读取所有历史。代价是段数增多后需要排序、去重和过期标记,否则会让上下文重新变得嘈杂。
更实用的方案是双层或三层结构:第一层是短小的 current state,供每次推理默认读取;第二层是最近若干阶段摘要,保留决策来源和上下文边界;第三层是原始 trace、工具结果和文件产物,按需检索回查。这样大多数轮次只读当前状态,出现争议或需要细节时再召回对应阶段。
摘要合并最好按字段更新:目标、硬约束、偏好、事实、计划、已完成事项、待办、风险、阻塞和证据引用分别维护。新信息如果推翻旧信息,不要直接覆盖成一句话,而要标记旧状态已过期、记录新来源和确认时间。这样可以减少摘要漂移,也能帮助模型理解为什么计划发生变化。
滑动窗口摘要的好坏不能只看压缩比例。要用长任务回放测试硬约束是否保留、关键事实是否被改写、冲突能否定位来源、模型是否重复已完成工作、是否能从阶段摘要恢复任务,以及 token、延迟和调用成本是否可接受。
任务较短、目标稳定、风险低、很少需要回查来源时可以只保留合并摘要。即便如此,也最好保留原始 trace,避免摘要出错后无法恢复。
优先按语义阶段切,例如需求澄清、方案确认、工具执行、异常恢复和最终产出。按固定轮次切实现简单,但容易把同一决策拆散,降低可读性。
可以通过用户新确认、工具结果变更、计划状态更新、任务阶段推进和显式冲突字段判断。过期摘要不一定删除,但要降权或标记,避免被当成当前事实。
会,尤其是摘要模型把不确定信息写成确定事实时。要保留证据引用、置信度和来源范围,对关键事实尽量保存原文片段或工具结果引用。
默认只放 current state 和最近或最相关的阶段摘要,其余放外部存储。根据当前子任务检索召回,并对召回摘要做去重和过期过滤。