压缩上下文时如何判断信息的重要性?
未标记
考查重点:后续动作依赖与信息优先级。优先保留会改变下一步动作的目标、硬约束、事实和未完成状态;可回查材料留引用,冗余过程压缩
本题目录
参考答案
核心回答
压缩时的重要性,应按信息丢失会不会改变当前任务的判断或下一步动作来评估,再结合有效时间、依赖关系和能否回查决定保留形式,不能只按“用户消息比助手消息重要”或“越近越重要”排序。
优先保留四类信息:当前有效目标和硬性条件;影响决策的已确认事实及原始证据;已完成、待执行、待确认等任务状态;尚未解决的问题、关键更正和后续步骤的依赖。金额、日期、对象 ID、否定词和适用条件,往往需要保留精确值。
重复解释、无关闲聊和已被消化的大段日志可以先精简。对仍可能有用的细节,可以保留摘要与可回查引用,而不是全部塞在窗口里。压缩后要检查关键事实是否完整、状态是否正确,并用跨窗口追问和任务继续执行验证;压缩率只能说明变短了,不能说明信息保留得好。
展开说明
1. 从任务影响判断,不从消息类别直接定级
判断一条信息时,可以依次问:
- 它是否约束当前交付物、操作范围或成功标准?丢失后会不会做错对象、违反条件?
- 下一步是否依赖它?例如前一步返回的记录 ID、未解决错误、已排除的方案和等待确认的事项。
- 它是否仍然有效?有没有被后续消息更正、被新版本替代,或只适用于已结束的任务?
- 它是否容易重新获得?一份可按版本读取的长文,与用户只说过一次的关键数字,保留策略可以不同。
消息角色影响指令层次,但不能直接替代信息价值判断。早期用户的一句限制可能一直有效,最近助手的一段重复解释则可以精简;工具结果中的失败原因,也可能是避免下一步再次走错的关键证据。
时间新并不自动意味着正确。用户把“周五交付”改为“周三交付”时,应保留更正后的有效条件及必要的更正记录,不能把两个时间都列成当前要求,也不能永远固定第一次抽取的条件。
2. 对关键字段保真,对叙述过程压缩
可把当前任务的目标、有效约束、关键事实、进度和待办维护成结构化状态,再用摘要保留原因、决策及证据位置。结构化字段也要记录必要的来源、范围和更新关系,并在后续模型调用中实际提供,存进数据库本身不会让模型记住。
以一个假设的售后对话为例,用户说“订单 A17 实付 500 元,先核对退款条件,暂时不要提交退款”。后续上下文至少需要保住订单对象、500 元、核对条件这个目标,以及“不要提交”的当前限制;商品描述的重复解释可以压缩。如果只总结成“用户想退款”,下一步就可能选错动作。
关键值可以保存为字段,同时保留对应原消息 ID;“尚未提交”和“已提交成功”要明确区分。若金额含税、日期含时区、范围带例外,这些条件也属于事实的一部分,不能只留下一个数字。对于不确定信息,要保留不确定状态,摘要不能把推测改写成确认。
3. 原文、摘要和引用怎样配合
适合的组合通常是:当前有效条件与任务状态、较早内容的摘要、最近必要的完整交互。长工具结果先按任务裁剪,保留结论、关键字段、必要反证和原始位置;例如排障日志可以保留错误码、请求时间、traceId、相关堆栈及文件位置,不必持续携带全部成功日志。
摘要可以按“当前目标—约束—已确认事实—关键决策—已完成与待处理—证据位置”组织。更新时记录覆盖到哪条消息和摘要版本,避免漏掉新增消息、重复摘要或旧摘要覆盖新状态。先成功保存新摘要及其覆盖范围,再清理对应历史;并发生成时可串行提交,或检查版本后更新。
对尚未结束的工具交互要格外小心:调用仍待执行时不能压成“已经完成”;保留在消息历史中的工具调用与结果,要满足目标接口的配对要求。已经完成的旧交互可以按规则整体转为摘要,不需要为了形式给每条旧用户消息补一个空助手回复。
原文回查还需要真正可用的存储和定位方式,例如会话消息 ID、文档版本与段落或结果文件路径。摘要中写“详见原文”,但系统找不到对应原文,就没有提供恢复能力。清理和保留范围也应遵循数据的权限与保留策略。
4. 怎样检查压缩没有破坏任务
先从业务中提取必须保真的字段和状态,检查压缩前后数值、单位、否定条件、对象、最新更正和未完成事项是否一致。模型可以辅助发现语义遗漏,但关键字段适合再做程序化比对。
随后用代表性的长对话回放,尤其测试早期条件、金额追问、目标修改、工具失败和跨窗口继续执行。观察关键事实召回、约束违反、下一步动作是否正确,以及是否重复执行已经完成的操作,同时记录 Token、延迟和压缩成本。若指标变差,就调整保留规则或摘要内容;不能只根据摘要模型自评“保留完整”判断效果。
常见追问
开放式对话不知道后面会问什么,怎么决定必须保留?
无法提前精确预测所有未来问题。可以保留少量已确认且可能持续有用的信息、当前对话主题与未解决事项,把其余内容保存在可检索的原始历史中。读取时结合新问题按需召回,并保留来源和有效时间;压缩摘要与写入长期记忆是不同操作,不需要把每句闲聊都变成长期用户画像。
能不能让模型给每条消息打重要性分数?
可以作为候选筛选,但评分应结合当前目标、状态和后续依赖,并由明确规则保护关键字段。最好以完整的语义片段或工具交互为单位,避免拆掉条件与结论的关系;再用实际回放验证评分是否有用,不能只按分数机械删除。
什么时候触发压缩?用户可以切换模型怎么办?
按当前模型及接口的实际输入限制,计算消息、工具定义、附件等开销,并为输出和预期工具反馈预留空间。可在接近预算时触发,结合任务阶段选择较完整的压缩边界;切换模型后重新计算预算和 Token 估算,不能让所有模型共用一个固定消息条数或阈值。
对应教程
- 记忆与对话历史:阅读历史读写与注入,以及长历史需要截断、摘要和重要信息提取的说明;本文补充具体保留依据及压缩后的行为验证。
- LangGraph 高级特性:阅读线程内状态与跨线程存储的分工,理解任务状态可以单独保存,再按当前步骤取用,而不是全部依赖历史消息。
参考资料
- 国内:JavaGuide:上下文工程:参考原文、摘要、引用在预算中的取舍,以及排障场景应保留的标识和原始证据,解释“可回查”需要哪些信息。
- 国内:zero2Agent:记忆与上下文工程:参考否定条件、数字约束和状态外置,说明压缩后应如何检查关键条件;条件仍需随任务修改和失效。
- 国内:WeThinkIn:Agent 记忆与上下文工程:参考增量摘要的内容、覆盖水位、版本更新和关键数字回查,解释压缩为何还要保持任务连续性。
- 国外:Anthropic:Effective context engineering for AI agents:借鉴长任务压缩与结构化笔记中先覆盖关键内容、再删除冗余的做法,说明正文中如何避免丢失后续行动依赖。
- 国外:LangChain:Short-term memory:依据裁剪、删除与摘要的区别及工具消息配对要求,说明正文中压缩后的输入为何仍须满足协议结构并可继续执行。
相关面经
6 篇拼多多
Agent上下文压缩的时候怎么压缩的,哪些是可以被放弃的
百度
Java 开发工程师(智能客服)百度
AI 应用开发工程师压缩时怎么排序重要性?(这题被问的顺序误导了按照上一题答得分类说的,实际上应该可以按照语意等来说)
硅心科技
智能软件工程师对短期记忆和长期记忆的哪些内容会做优先裁剪?
快手
AI 应用 / Agent 开发刚才也提到了token策略,那你说说这里压缩上下文的策略,压缩的具体是那部分message?
展开剩余 1 篇面经
公司未注明
Agent 实习岗短期记忆如何选择

