页面加载中…
长程研究有一个很现实的矛盾。
Agent 需要记住已经发现的事实、失败路径和用户约束，但模型一次能读取的上下文有限。把所有历史一直带着，后面的每一步都要重复处理旧内容；直接删除旧消息，又可能把关键证据一起丢掉。
ReSum 原论文的做法，是定期调用外部摘要工具把交互历史压成紧凑状态，再让 Agent 从摘要继续执行。论文同时区分无需额外训练的 ReSum 与 ReSum-GRPO：后者把长轨迹分段，并用 advantage broadcasting 将最终奖励传播到各段，以适配摘要条件下的推理。
这些论文结果只适用于其模型、摘要器、任务和评测设置。落到具体系统时，压缩仍会带来信息损失；何时触发、哪些信息不能丢、原始证据放在哪里，以及怎样发现摘要已把研究带偏，都要单独验证。
面试官问 ReSum 时，通常不满足于“上下文快满了就总结一下”。他更想听到：
摘要触发条件怎样设置，摘要 Schema 保存什么，如何防止多轮压缩造成事实漂移，怎样评测摘要质量，失败时又如何恢复到原始证据？
ReSum 解决的是上下文压力，不是所有记忆问题
ReSum 适合已经出现长历史压力的任务。
如果任务只有两三步，摘要会增加一次模型调用和新的丢失风险，直接保留历史更简单。
如果系统根本没有保存来源，摘要也不能凭空重建证据关系。
如果 Agent 一直重复搜索，单纯摘要只会把重复历史压短，下一轮仍可能继续重复。
如果当前状态本身混乱，摘要可能把互相冲突的旧结论写成一句更流畅的错误结论。
因此先限制工具输出、去重和外置原文，是所有方案都需要的基线。随后可以分别比较完整历史、IterResearch 式工作空间重建、ReSum 式周期摘要或其它受控状态设计；论文没有规定 ReSum 必须排在 IterResearch 后面。
截断只解决长度，ReSum 还要保护状态并保留回到原始证据的路径。
什么时候应该触发摘要？
最直接的信号是上下文预算。
系统可以估算系统要求、用户问题、当前研究状态、最近工具交互和预留输出分别占多少。当可用空间接近安全边界时触发，而不是等模型请求已经超过限制才处理。
但不能只看一个固定 Token 数。
不同模型窗口不同，不同任务需要的最终输出空间也不同。一个需要生成长报告的任务，应更早预留输出；一个正在处理关键冲突的步骤，当前原文虽然长，却可能不适合立刻摘要。
第二个信号是历史结构。
已经关闭的子任务、重复网页和早期失败日志适合优先压缩。最近正在核验的证据、用户刚修改的约束和未解决冲突应该保留更多细节。
第三个信号是任务阶段。
完成一个相对独立的研究单元后摘要，比在一条证据链中间强行切断更安全。摘要边界最好与子任务边界对齐。
所以触发器应同时考虑预算、内容重要性和任务阶段，而不是“每 N 轮总结一次”。
摘要里必须保留哪些信息？
第一，用户任务和硬约束。
时间范围、对象边界、交付格式、禁止使用的来源和需要人工确认的事项，不能因为出现得早就被压掉。
第二，关键主张与来源。
摘要里可以缩短表述，但不能只留下结论。至少要保留 Claim ID、Source ID、对象、时间和限定条件，必要时还要记录支持与反对关系。
第三，冲突和不确定性。
两个来源尚未对齐，摘要应保留冲突原因和下一步核验方式。把“来源 A 与 B 口径不同”写成“综合来看 A 更合理”，就是摘要替系统做了未经证据支持的裁决。
第四，信息缺口和下一步。
Agent 必须知道哪些问题尚未完成。摘要只写已经发现的内容，会让后续误以为研究结束。
第五，已执行动作和失败路径。
不必保存每次调用全文，但要知道哪些查询已经尝试、哪些页面不可用、哪个策略失败，防止摘要后重新走一遍。
第六，预算和停止状态。
剩余步骤、工具限制、当前任务状态和最近一次失败原因，决定下一步是否还能执行。
这些字段适合结构化保存。自由文本用于解释，固定字段用于校验。
原始证据为什么必须留在摘要之外？
摘要越短，越不可能保留所有原文。
如果原始工具返回只存在于即将被替换的消息里，摘要一旦漏掉一个否定词、单位或版本，系统就没有恢复依据。
外部证据层应保存可授权保存的原始内容、相关片段、访问时间、工具参数和稳定 ID。摘要只携带必要主张和 ID，需要复核时按 ID 取回。
例如摘要写着“来源 S8 表明方案 A 在条件 C 下支持能力 X”。后续要生成最终引用时，系统可以重新读取 S8 的证据片段，确认“条件 C”没有在多轮压缩中变形。
原始证据外置还让摘要可以更积极地去掉临时文本，因为重要信息仍可恢复。没有外部证据库时，所谓摘要压缩往往只是不可逆删除。
一次安全的 ReSum 流程
第一步，计算当前上下文组成和安全余量。
第二步，选择摘要范围。保留最近必要交互，优先压缩已经关闭的旧研究单元，不跨越正在核验的关键证据链。
第三步，提取受保护内容，包括任务契约、关键主张、来源、冲突、缺口、失败动作和预算。
第四步，生成候选摘要。摘要应按照固定结构输出，不让模型自行发明栏目。
第五步，运行一致性检查。核对关键 ID、数字、单位、时间、否定关系和完成状态，比较新旧差异。
第六步，执行状态探针。用少量明确问题检查摘要能否回答当前任务目标、最重要证据、未完成事项和禁止重复的动作。
第七步，提交摘要版本，同时保留旧上下文索引和恢复点。校验不通过则不替换。
摘要是一次有校验和回滚的状态变更，不是一条随手追加的总结指令。
为什么多次摘要最容易漂移？
第一次摘要可能把“某能力只在特定版本下提供”压成“某版本提供该能力”。
第二次摘要再压缩这句话，可能只剩“支持该能力”。
第三次生成最终报告时，限定条件已经完全消失。
这种错误往往没有一次明显的幻觉，而由多轮压缩中的微小信息损失逐步累积。
另一个常见问题是来源关系漂移。原本一个来源支持事实，另一个来源只提供背景。摘要为了简洁把两个都列在结论后，后续系统会误以为它们是独立交叉验证。
还有计划漂移。旧摘要中的待核验项在新摘要里被省略，Agent 便提前结束。
因此摘要版本之间要做差异检查。新增结论必须有新证据，删除缺口必须说明已解决或不再属于范围，数字与来源变化必须可解释。
压缩率高，不代表摘要质量高
一份摘要从很长历史压到几百字，看起来效率惊人，但可能已经无法继续研究。
摘要质量至少要分五个维度。
事实保留：关键主张、数字、时间、单位和否定关系是否准确。
证据保留：主张能否回到正确来源，冲突是否仍然存在。
任务保留：用户目标、硬约束和交付边界是否完整。
行动保留：已执行、失败和下一步是否足以避免重复并继续任务。
结构效率：是否真正去掉冗余，而不是用更抽象的话重复同一内容。
压缩率只能描述长度变化，不能替代这些质量指标。
摘要既要节省上下文，也要保住继续研究和最终核验所需的信息。
没有标准摘要，怎样评测？
长任务通常不存在唯一正确摘要。不能只拿模型输出与一份人工摘要做字面相似度。
第一种方法是关键事实探针。
在原始历史中标记必须保留的任务约束、主张、来源、冲突和缺口，摘要后逐项检查。
第二种方法是状态恢复。
只给执行器摘要和外部证据索引，让它回答“当前任务是什么”“哪些子问题已完成”“下一步为什么做”“哪些路径不要重复”。
第三种方法是下游对照。
同一批长任务分别使用完整历史、机械截断和 ReSum，比较后续动作、重复率、关键证据使用和最终报告。摘要质量最终要落在任务结果上。
第四种方法是反事实样本。
故意放入相似数字、相反结论、版本更新、否定词和同源转载，检查摘要是否把边界抹平。
第五种方法是人工抽检。
对高风险结论检查摘要前后是否等价，尤其关注模型评分器容易忽略的来源和限定条件。
一个教学场景：摘要把旧限制写成当前事实
下面是教学情境，不代表真实产品数据。
任务要研究某技术在不同版本中的能力变化。
早期来源 S1 表明旧版本不支持能力 X。中途来源 S2 是新版本发布说明，确认后来增加了 X。Agent 已经把两者整理成“旧版本不支持，新版本支持”。
上下文接近预算后触发摘要。
错误摘要写成：“该技术是否支持 X 存在来源冲突。”它保留了两种说法，却丢了版本条件，把可以解释的演变变成未解决冲突。
另一种错误摘要写成：“该技术支持 X。”它保留了当前结论，却丢了历史版本边界。用户如果问升级前后的差异，系统无法回答。
合格摘要应保留版本演变、两个来源 ID、当前适用结论和是否还需要核验。这个例子说明，摘要工作的核心是选择正确的信息结构，不能只把句子缩短。
最近窗口和摘要怎样组合？
摘要不必替代全部历史。
一种常见做法是保留一份较稳定的研究摘要，加上最近几轮未压缩交互。摘要负责长期状态，最近窗口保留当前证据细节和工具错误。
这样能避免每个新 Observation 都立刻被二次改写。当前子任务完成后，再把必要内容合并进摘要。
但最近窗口也要设边界。Visit 返回整页正文，即使只保留两轮，也可能占用大量空间。工具层仍需做相关性抽取，并把原文外置。
摘要、最近窗口和外部证据库是三个不同层级：摘要保存稳定状态，窗口保存当前工作材料，证据库保存可恢复原文。把三者混成一个消息列表，ReSum 很快又会退化。
摘要粒度应该怎样选择？
按单条消息摘要，容易失去一组动作共同解决的研究目标。
按整个任务一次性摘要，又会让候选文本过长，模型难以判断哪些子问题已经关闭。
更稳妥的粒度是研究单元。例如“核对方案 A 的当前部署方式”形成一个单元，里面包含查询、页面、证据和结论。单元完成后，可以把过程压成主张、来源、限制和失败记录；单元仍在进行时，保留最近窗口和关键原文。
粒度还要与恢复边界一致。摘要后若需要重放，系统应能从一个单元开始，而不是只能从整项研究开头重来。
跨单元共享的用户约束和术语放在全局受保护区，不随任何局部摘要重复改写。这样既减少重复，也避免不同单元产生互相矛盾的任务理解。
摘要错误传播怎样定位？
最终结论错误时，先确定错误事实在原始证据、首次摘要还是后续摘要中出现。
若原文正确、第一次摘要就丢了否定词，属于抽取和压缩错误。若第一次摘要正确，第二次将版本条件删除，属于多轮摘要漂移。若摘要始终正确，最终报告却扩大了结论，问题在生成阶段。
定位需要保存摘要版本、覆盖的消息范围、输入 Evidence ID、受保护字段和前后差异。只保留最新摘要，会让团队无法判断错误是如何累积的。
可以把关键主张建立摘要谱系：当前句子来自哪个旧状态，经过哪些改写，哪些限定条件被合并或删除。它不需要保存模型隐式推理，只记录可审计的信息变化。
修复后用相同原始历史重放，并比较下一步动作是否恢复。只看新摘要文字更像参考答案，不足以证明 Agent 已经不会走错方向。
摘要失败时怎样恢复？
若候选摘要丢失受保护字段、引用不存在或关键数字改变，直接拒绝提交。
如果只是格式错误，可以在不改事实的前提下做结构修复。不能用“重新总结一次”掩盖证据问题，因为第二次可能生成另一套错误。
已经提交后才发现漂移，应回到上一个可靠摘要版本，重新加载受影响的原始证据，重放这段更新。后续基于错误摘要产生的主张和动作也要标记待复核。
如果摘要服务不可用，系统可以暂时保留最近窗口并暂停新的长链路，或者返回部分完成状态。不能无限追加历史直到请求失败，也不能在无状态下继续生成确定结论。
所有恢复过程要进入 Trace：触发原因、摘要范围、旧版本、新版本、校验结果、恢复动作和受影响主张。团队才能区分是检索错、摘要错还是最终生成错。
摘要数据应该怎样构造？
训练或评测样本不能只有“长文本到短文本”。
需要包含任务契约、来源 ID、数字单位、否定关系、冲突、失败工具和未完成项，让模型学习哪些内容不可随意删除。
还要有错误摘要作为负样本：把不同版本合并、把候选线索写成事实、丢掉来源、提前关闭缺口、删除失败路径、改变用户边界。
样本要覆盖不同任务阶段。研究单元结束后的摘要与证据核验中途的摘要难度不同，不能只用结构完整的最终报告反推训练数据。
评估也不能只由另一个模型看“是否简洁”。应加入程序校验、关键字段对比和人工抽检，把语言质量与状态正确性分开。
怎样把摘要质量接入发布门槛？
离线评测通过后，上线仍需要运行门槛。
每次摘要先做硬校验：任务契约是否保留，关键来源 ID 是否存在，数字与单位是否改变，未完成项是否无依据减少。任一硬项失败，就拒绝替换旧状态。
软指标可以观察摘要长度、重复字段、后续重复动作和证据取回次数。软指标异常不一定马上中止，但应触发采样审查或降级到更保守的上下文策略。
对高风险任务，可以在最终发布前从原始证据重新核对关键主张，不完全依赖多轮摘要结果。不同任务风险不同，不能让所有请求都承担同样的人工或模型核验成本。
摘要器、Schema 或模型升级时，要回放固定长轨迹集，并分任务长度、冲突数量和摘要次数报告结果。只有平均分提高，边界样本持续变差，不能直接发布。
用户中途修改任务，摘要应该怎样更新？
用户增加对象、缩短时间范围或改变交付形式时，任务契约已经发生版本变化，应按新任务边界处理，不能当作普通新证据合并。
系统应先保存旧契约和旧摘要，标出哪些已完成主张仍然有效，哪些因为范围变化需要重新核验。新要求进入受保护区后，再生成对应缺口和计划。
不能让摘要器把新旧要求“综合”成一个看似折中的任务。例如用户明确排除某类来源，旧摘要中的相关结论就要降级或移出最终结果，而不是继续沿用。
任务变化也要进入 Trace，并让最终报告说明依据的是哪一版用户要求。这样恢复和重放时，系统不会拿旧范围覆盖新范围。
面试官继续追问，怎么接？
追问一：ReSum 和 IterResearch 有什么关系？
它们是不同的长程上下文范式。IterResearch 用问题、演进报告和最近交互重建当前工作空间；ReSum 定期调用外部摘要工具压缩交互历史。二者可以作为平行基线，也可在明确协议下组合，但没有固定前后顺序，都要验证证据恢复、信息损失和额外成本。
追问二：为什么不固定每五轮摘要一次？
轮数不能代表内容压力。一次长网页可能比五次短工具调用更占空间，关键证据链中途也不适合切断。应结合预算、任务阶段和内容重要性触发。
追问三：摘要能做到无损吗？
不能这样承诺。摘要本质是有损压缩。工程上通过受保护字段、外部证据、差异检查和回滚，把关键损失控制在可接受范围。
追问四：怎样证明摘要没有把 Agent 带偏？
用状态探针和下游对照。检查任务、主张、来源、缺口和动作是否可恢复，再比较摘要前后的下一步选择与最终报告。
追问五：有了更长上下文，还需要 ReSum 吗？
更长窗口能延后溢出，但不能消除重复输入、信息污染和状态漂移。是否使用 ReSum 仍取决于真实任务长度、成本和质量对照。
如何说明 ReSum 的收益与信息损失
ReSum 是论文提出的周期上下文摘要范式：外部摘要工具压缩交互历史，Agent 从紧凑状态继续；ReSum-GRPO 另行用分段轨迹和 advantage broadcasting 训练策略适应摘要上下文。我不会把论文设置直接当成本项目收益，触发条件仍按上下文预算、任务阶段和内容重要性验证。
摘要必须结构化保存任务契约、关键主张和来源、冲突、信息缺口、已执行与失败动作、预算和下一步。原始网页放到外部证据库，摘要只带稳定 ID。生成候选摘要后，检查受保护字段、数字单位、否定关系、来源 ID 和前后差异，再用探针问题验证当前任务和未完成项能否恢复，通过后才提交版本。失败则保留旧摘要或回到原始证据重放。
验收时不能只看压缩率。我会比较完整历史、机械截断和 ReSum 在事实保留、证据追溯、重复动作、后续决策、上下文用量和最终报告上的表现，并加入版本冲突和否定关系等边界样本。ReSum 的价值是用可控的信息损失换取长任务继续执行，不是让上下文永远不增长。
摘要系统能否回答这四个问题
挑一次摘要更新，检查触发理由、受保护字段、证据恢复和漂移回滚，才能说明压缩过程是受控的。
- 摘要由什么信号触发，是否只用了固定轮数？
- 哪些字段受保护，能否检查来源、数字、单位和否定关系？
- 原始证据是否通过稳定 ID 可恢复，而不是摘要后永久丢失？
- 摘要漂移时是否有版本、回滚和受影响主张复核机制？