Deep Research 做到十几轮之后，网页通常已经不少，真正稀缺的是一份可靠的当前状态。
用户究竟要什么，已经确认了哪些事实，哪些来源互相冲突，还缺什么证据，下一步为什么要继续搜，这些信息如果只散落在聊天记录里，Agent 每轮都要重新理解一遍。
IterResearch 用一份持续更新的演进报告承载当前研究状态。新观察到来后，有价值的信息被合并进报告，原始材料进入外部证据库，系统再根据更新后的状态决定下一步，避免整段网页永久挤在上下文里。
这个思路看起来像“做摘要”，但工程难点完全不同。普通摘要追求短和通顺，演进报告必须支持后续决策，还要保留来源、冲突、缺口和版本。一次更新写错，后面的搜索方向和最终报告都会一起偏。
所以面试官真正想问的是：
演进报告里应该存什么，怎样从新观察更新状态，怎样防止事实被删、来源错配和结论漂移，又怎样证明它比完整消息历史更适合长任务？
演进报告首先是一份“工作状态”
最终报告面向用户，重点是结论清楚、证据完整和表达易读。
演进报告首先面向下一轮 Agent。它要回答当前该做什么，以及为什么做。里面可以有尚未成熟的假设、待补证据、冲突状态和失败动作，这些内容不一定直接展示给用户，却决定后续研究能否继续。
普通对话摘要通常回答“之前聊了什么”。演进报告还要回答“当前哪些结论有效”“哪些已经失效”“下一步应关闭哪个缺口”。如果只把聊天压成几段通顺文字，模型仍然要从自然语言里猜当前状态。
更准确的理解是：演进报告是受控研究状态的一种实现，最终报告只是它在任务结束时的一种输出。
摘要主要帮助回忆，演进报告还要驱动行动、约束更新并保持证据关系。
一份可执行的演进报告应该存什么？
第一部分是任务契约。
它包括用户问题、交付形式、时间范围、比较对象、必须使用或禁止使用的来源，以及需要人工确认的高风险边界。任务契约属于受保护字段，后续压缩不能随意删除。
第二部分是已确认主张。
每条主张不只是一句话，还要带稳定 ID、支持来源、适用时间、对象版本和限定条件。若它只是从搜索摘要得到的线索，就不能直接标成已确认。
第三部分是冲突与不确定性。
两个来源口径不同，应同时保存差异原因和待核验项。演进报告不能为了变短，静默选一个看起来更顺的说法。
第四部分是信息缺口。
缺口要写成可执行问题。例如“缺资料”无法指导下一步，“尚未找到同一版本下的公开部署限制”才可以生成新的搜索或访问动作。
第五部分是动作状态。
保存已经搜索的查询、访问过的来源、失败原因和已关闭子任务，避免 Agent 不断重复。原始工具结果不必全部进报告，但要通过 ID 能够重新取回。
第六部分是计划和预算。
下一步动作应指向某个缺口，同时记录剩余工具、时间或来源预算。达到边界时系统才能区分正常完成、部分完成和预算兜底。
为什么不能只保留“结论”？
假设旧报告写着：“方案 A 支持某能力，来源 S3，适用于版本 V2。”
新页面提到方案 A 的新版本，但没有说明旧能力是否保留。如果更新器只追求最新、简短，可能把报告改成：“方案 A 当前支持该能力。”
看起来更顺，实际上丢了三个关键信息：原结论来自哪个来源，结论只确认到哪个版本，新页面是否真的支持“当前”这个判断。
后续 Agent 再也不知道该复核什么，最终报告却会把不确定内容写成事实。
因此演进报告的最小单位应该是主张加证据关系，而不是一段自由文本。文本可以重写，主张 ID、来源 ID、版本和冲突状态不能在无证据时悄悄变化。
每次更新都应该像一笔事务
一次稳妥的更新可以拆成六步。
第一步，保存原始观察。网页正文、工具参数、访问时间和返回状态先写入外部证据层，得到稳定 Evidence ID。
第二步，做相关性抽取。只提取与当前子问题有关的片段，标注它支持、反对还是补充哪条主张。
第三步，读取旧报告。更新器同时看到任务契约、当前主张、缺口和动作历史，而不是只看最新网页。
第四步，生成候选报告。新证据可以新增主张、修改状态、关闭缺口或提出新的待验证项。
第五步，运行校验。检查 Schema、受保护字段、来源 ID 是否存在、数字和时间是否有依据、删除的主张是否给出原因。
第六步，提交新版本。校验通过才替换当前状态；失败时保留旧版本，并把新观察标成尚未合并。
先保存证据，再更新候选状态，校验通过后提交，避免一次错误覆盖可靠历史。
主张需要有自己的生命周期
一条主张刚出现时，可以是候选线索。
找到原始来源并核对对象、时间和口径后，才进入已支持状态。
若另一个来源给出不同结果，它应进入冲突状态，而不是被新句子直接覆盖。
证据被证明过时或对象不一致时，可以标为失效。失效不是删除，系统还要知道它曾经影响过哪些计划和结论。
任务结束时，只有支持充分、边界清楚的主张进入确定结论。仍有缺口的内容可以放进限制说明，不能靠语气变成确定事实。
这个生命周期让 Agent 能够纠错。如果报告只保留最终句子，团队很难回答“错误从哪一轮开始”“为什么旧结论被替换”“哪些动作依赖了它”。
演进报告大小受控，不等于绝对恒定
训练材料会用常量工作空间帮助理解 IterResearch，但生产表达要更谨慎。
任务契约、系统要求、当前工具交互和报告本身都会占用上下文。随着对象和关键主张增加，报告也可能变长。工程目标是让主要状态在设定范围内可控，不再与原始网页总量一起线性增长，而不是承诺每一轮字符数完全一样。
报告过长时，优先做结构化去重和层级化。
重复主张合并，但保留多个独立来源；已经关闭的低风险子任务可以只保留结果与证据 ID；原始正文移到外部；非关键动作只保留统计和失败原因。
如果这些措施后仍接近窗口边界，再考虑动态摘要。不能一看到报告变长，就机械截断末尾或删除最早内容，因为任务约束和早期关键证据可能正好在那里。
外部证据库不是可选装饰
演进报告为了可控，必然不会保存所有原文。
如果被移出的内容没有外部落点，报告一旦摘要错了就无法恢复。来源链接后来失效，也无法确认当时看到了什么。
外部证据记录至少需要 URL、标题、访问时间、内容版本或快照策略、相关片段、来源类型和与主张的关系。涉及受限内容时，还要遵守授权、隐私和存储边界，不能无条件保存整页。
演进报告只携带必要的 Evidence ID 和短摘要。需要复核时按 ID 取回相关片段，而不是重新把所有历史塞回上下文。
这样做也便于最终引用。报告中的结论可以回到具体证据，不会出现“状态里有一句话，却不知道从哪来”的断链。
一个教学场景：比较三种技术路线
下面是教学设计，不代表真实客户项目或线上实测。
用户要求比较三种技术路线的部署方式、维护成本和适用边界，并且只接受公开可核验资料。
第一轮搜索得到候选来源。演进报告不直接写结论，只记录三个对象、交付维度和待访问页面。
第二轮访问方案 A 的官方文档，确认一种部署方式。报告新增 Claim A1，绑定来源 S1，同时关闭“部署形态”缺口。
第三轮访问一篇旧版本博客，它说 A 不支持某能力。报告发现时间冲突，把这条信息标为待核验，不覆盖 A1。
第四轮找到新版本发布说明，确认能力后来加入。报告将旧博客限制在历史版本，新增当前版本主张，同时记录版本演变。
第五轮方案 C 的资料仍不足。报告把它保留为缺口，下一步计划寻找原始文档。若预算耗尽，最终输出应说明 C 的证据不足，而不是照着 A、B 的结构补齐一句猜测。
这个过程展示了演进报告的价值：每条信息都进入正确状态，远比把五轮内容简单缩短更重要。
更新器最常见的六种错误
第一种是关键事实遗漏。新报告读起来更短，却删掉了用户硬约束或已经确认的限制。
第二种是无依据合并。两个来源谈的是不同版本，更新器把它们揉成一个更强的结论。
第三种是来源错配。主张保留下来，Source ID 却在重排时指向了另一段材料。
第四种是冲突被抹平。报告为了连贯，只留下多数来源的说法，少数但更原始的证据消失。
第五种是计划漂移。下一步动作没有对应信息缺口，只因为新网页出现一个吸引人的关键词就转向。
第六种是状态回退。工具或更新调用重试后，旧结果再次写入，把较新的可靠状态覆盖掉。
报告质量要分事实、证据、约束、计划和版本检查，不能只看语言是否通顺。
怎样避免并发和重试把状态写乱？
如果多个子任务并行返回，不能让它们都基于旧版本直接覆盖当前报告。
每次更新应携带报告版本号。提交时发现当前版本已变化，就重新读取最新状态并合并，或者把子结果交给统一综合节点处理。
工具重试也要有幂等标识。同一次 Visit 因网络超时返回两次，不应生成两条独立证据并被误判为多源支持。
对于高风险字段，可以使用更严格的合并规则。任务契约只能由明确的用户更新改变；已确认数字不能在没有新 Evidence ID 时修改；删除主张必须给出失效或合并理由。
这些控制不依赖模型“记得小心”，而是由状态层和程序校验保证。
怎样把演进报告拆成稳定 Schema？
一个实用做法，是把报告分成受保护区、可更新区和外部索引区。
受保护区保存用户任务、范围、禁止项和人工确认状态。除非收到明确的新用户输入，否则更新器只能读取，不能改写。
可更新区保存主张、冲突、缺口和计划。每条记录都有稳定 ID、状态和更新时间。模型可以提出新增或变更，但必须同时给出对应 Evidence ID 或状态理由。
外部索引区只保存原始证据、完整 Trace 和大段材料的位置，不把正文复制进报告。这样既控制长度，又能在核验时恢复。
Schema 还要明确空值的含义。“没有冲突”与“尚未检查冲突”不能都写成空数组；“子任务完成”与“预算耗尽后停止”也不能共用一个 finished。状态含义不清，后续统计和恢复都会误判。
字段也不宜无限扩张。每增加一个字段，都要回答它驱动哪个动作、由谁更新、怎样校验、任务结束后是否仍有价值。只为了显得完整而堆元数据，会让报告本身变成新的上下文负担。
怎样做可重放的故障定位？
发现最终报告写错后，不能只重新跑一次看是否恢复。
先找到错误主张的当前 ID，再沿版本记录定位它第一次出现、第一次被确认和最近一次被修改的时刻。然后检查当时使用的 Evidence ID、候选状态差异和校验结果。
若原始证据就错误，问题在检索或抽取；若证据正确但候选报告改了限定条件，问题在状态更新；若候选正确却提交后消失，问题在并发或版本覆盖；若演进报告正确而最终稿错误，问题在生成与引用阶段。
重放时固定任务契约、工具结果和旧报告，从出错版本前一步重新执行更新。这样可以验证修复针对真实根因，而不是因为重新搜索碰巧得到另一批资料。
故障样本应沉淀进回归集。至少保留触发输入、旧状态、候选状态、期望差异和禁止变化字段，让后续 Schema、Prompt 或模型升级都能重复验证。
演进报告应该怎样评测？
第一类是事实保留。
在长轨迹中埋入任务约束、关键事实、否定关系、时间和单位，检查多轮更新后是否仍然准确。
第二类是证据可追溯。
随机抽取主张，看 Source ID 和 Evidence ID 是否存在，原文是否真正支持当前表述。
第三类是纠错能力。
先给一个过时或错误来源，后续再提供更可靠证据，检查旧主张能否进入失效或冲突状态，相关计划是否一起更新。
第四类是状态效率。
观察报告长度、重复字段、外部证据取回次数和无效动作。长度更短但不断重复搜索，不算更好。
第五类是最终可用性。
从演进报告生成最终稿，检查覆盖、引用、限制和结构。演进报告自身通过 Schema，不代表最终研究质量一定合格。
还要与完整历史做对照。短任务里，维护报告可能增加额外开销；长任务里，才重点观察上下文增长、错误传播和关键事实保留。不能只拿最有利的一类样本证明方案。
最终报告生成前还要做一次状态审计
演进报告适合执行，不代表可以原样发布。
发布前先筛选能够进入确定结论的主张，逐条核对来源、版本和适用条件。冲突状态不得被最终生成器自动改成单一答案，未完成缺口也不能为了版式整齐被补齐。
接着检查任务契约中的交付项是否都有对应内容。缺失项应说明未完成原因，而不是从相邻主张推测。
最后冻结报告版本，再生成面向用户的结构和引用。生成期间若有新证据迟到，应作为新版本重新审计，不能在发布中的文本上静默插入。这样才能区分执行状态正确、最终表达正确和发布版本一致三个不同验收层。
失败时应该怎样降级？
候选报告格式不合法时，先做一次受限结构修复，不重新生成事实。
来源 ID 不存在、受保护字段丢失或关键数字改变时，拒绝提交，保留旧版本，并把新观察放入待合并队列。
更新服务暂时不可用时，系统可以继续保存原始证据，但应暂停依赖新状态的复杂规划。不能为了不中断，把整页 Observation 又永久追加回消息列表，否则系统会悄悄退化成最初的问题。
恢复后从最后一个可靠版本继续，按照证据时间和幂等 ID 合并待处理观察。最终 Trace 需要说明哪次更新失败、采用了什么降级、是否影响结论完整性。
面试官继续追问，怎么接？
追问一：演进报告和普通摘要最大的差别是什么？
普通摘要帮助回忆，演进报告还要驱动下一步。它必须保留任务约束、主张状态、来源、冲突、缺口、动作和预算，并支持版本化更新。
追问二：报告越短越好吗？
不是。目标是大小受控和信息可恢复。过度压缩会丢限定条件、否定关系和来源，反而增加重复搜索与错误结论。
追问三：为什么不直接让模型每轮重写全部报告？
可以由模型生成候选版本，但提交前需要 Schema、来源、关键约束和差异检查。自由重写没有事务边界，一次错误可能覆盖可靠状态。
追问四：演进报告能支持无限深度研究吗？
更谨慎的说法是显著控制主要工作状态的增长。工具交互、报告复杂度、外部存储和累计误差仍有边界，不能承诺真正无限或绝对恒定。
追问五：原始网页不在报告里，怎样防止证据丢失？
原始内容进入外部证据层，报告保存稳定 ID 和必要摘要。需要核验时按 ID 取回，来源映射在状态更新时不能被自由重写。
如何在一分钟内讲清演进报告
IterResearch 的演进报告是一份驱动后续行动的受控研究状态，不能按普通聊天摘要处理。它至少保存任务契约、已确认主张和来源、冲突、不确定性、信息缺口、已执行动作、剩余预算和下一步计划。原始网页存入外部证据库，报告通过稳定 ID 引用，避免长期堆在上下文里。
每次更新我会按事务处理：先保存新观察和证据片段，再基于旧报告生成候选状态，检查固定 Schema、受保护约束、来源 ID、数字时间和前后差异，通过后才提交新版本。校验失败保留旧状态，避免一次重写把可靠事实覆盖。报告大小追求受控，不承诺绝对恒定，也不把摘要说成无损。
验证时会用短、中、长任务测试关键事实和否定关系保留、证据可追溯、错误纠正、重复动作、报告长度和最终研究质量，并与完整历史方案对照。IterResearch 的价值在于把原始历史与当前状态分开，让长任务可更新、可恢复和可审计；“能跑无限轮”既不现实，也不应成为卖点。
演进状态能否经得住这四项核验
从任意一次状态更新入手，核对旧约束、新证据、变更理由和回退版本是否都能追溯。
- 演进报告是否有明确 Schema，而不是一段自由文本？
- 每条关键主张能否回到真实 Evidence ID 和来源片段？
- 更新前后是否保留任务约束、否定关系、时间和单位？
- 更新失败时能否拒绝提交、回退并从可靠版本恢复？