让 Agent 持续研究半小时：从普通研究到可靠交付的设计

本文结论

超长研究沿用普通研究的判断与工具循环，但要额外处理材料累积、目标保持、跨中断执行和报告收敛。
模型负责研究策略和语义判断；运行时负责权限、执行事实、资源与持久效果，用同一条循环连接两者。
给探索设置边界并提前保护收尾资源，让有限材料有机会变成用户可取得的回答。
原始要求、可回读证据、工作摘要与近期交互分别组织，摘要不能改写用户限制或执行事实。
后台执行、检查点与报告版本共同保护已有工作；中断按实际支持的路径结算或接续，答案质量还需单独评测。

适用

已有模型与工具调用能力，准备支持持续数十分钟研究，并设计异常处理与交付路径的开发者。

不适用

完整框架安装教程，或把更长运行时间、更多调用直接当作答案质量保证。

预计阅读 32 分钟。

用户问"这只基金的管理费是多少"，Agent 找到正式说明，核对份额类别和生效日期，通常就能回答。

换成下面这项任务，工作方式会发生变化：

比较 A、B、C 三只基金的费用、跟踪表现和行业暴露。以最近一期可取得的正式披露为依据，解释差异和资料限制，给我一份便于继续讨论的报告，不执行交易。

Agent 需要多次检索、阅读、计算和交叉核对。中途发现某份披露日期不同，还要补读原文，修订先前判断。用户可能离开页面，材料可能超出上下文，某个来源也可能暂时不可用。

要支持这样的研究，设计需要回答两个问题：怎样让多轮工作始终围绕原任务推进？当材料、资源或执行出现问题时，怎样保住已有工作，并把它整理成回答？

下面用这项三基金比较任务，自上而下拆解设计。基金和任务是教学简化；机制依据截至 2026 年 11 月 12 日核实的 ETF Agent 私有工程实现与记录，局部实验来自不同任务，公开教学仓库未必包含全部能力。"半小时"描述任务尺度，可以提前完成。

一、超长研究与普通研究，区别在哪里？

两者都可以使用同一个基本循环：模型选择下一步，工具返回观察，模型据此继续判断。超长研究增加的设计压力，来自这些动作长期累积，以及任务跨过了更多可能中断的位置。

设计维度	普通研究中的常见情况	超长研究需要额外处理什么
问题推进	少数材料就能回答，依赖关系较短	多个子问题相互影响，要根据新证据调整研究方向
上下文	原问题与主要材料通常能一起保留	旧材料和过程历史不断增长，要控制驻留并支持精确回读
资源	一套固定额度往往够用	探索、摘要、委派和成稿竞争同一份资源，必须保护收尾机会
生命周期	用户在线等待便能拿到结果	可能跨页面断线、停放和进程中断，需要保留任务与执行事实
输出	核实后形成一次相对完整的回答	暂定判断会被后续证据修订，报告需要维护连贯的当前版本
验证	容易观察完整输入到输出	要检查长链条中的真实消费、资源消耗、恢复与最终论证

这不是严格按分钟分类。一个十分钟任务也可能需要恢复；一个材料固定、依赖简单的长计算，也未必需要工作摘要。判断依据是任务是否出现了这些条件。

因此，延长超时只解决其中一部分。要让研究可交付，还需要同时保护三件事：下一轮知道该做什么，已经完成的工作不丢失，以及结束时仍有条件整理回答。系统能提高这些环节的可控性，研究结论是否正确则需要另行审阅。

开始改造时，先用同一项三基金任务跑一遍现有 Agent，保留原问题、实际请求与可取得的报告。重点看三个位置：后续请求是否还带着完整比较要求，材料增加后是否开始重复读取，结束时是否真的保存了可阅读的正文。这份基线决定先补哪一环。下面的实施步骤都接在现有研究链上；具体机制在对应专题展开。

二、先确定交付物，再搭建整体架构

从用户最终要取得的报告倒推，三基金比较至少包含四部分：

比较范围。 明确产品、份额类别、数据期间和披露日期。
对照结果。 按可比口径整理费用、跟踪表现与行业暴露。
差异解释。 说明差异来自产品本身、计算条件，还是披露时点。
结论与缺口。 回答哪些判断成立，哪些因缺少资料暂时无法判断。

这份骨架为研究提供方向。例如，A 使用季报、B 使用旧年报时，应该先核对 B 的正式披露，而不是直接相减。报告需要什么，决定下一步值得补什么；具体工具顺序仍由模型随证据调整。

在系统侧，可以用以下职责组成完整路径：

职责	负责什么	与下一环节怎样交接
任务入口	保存原始要求、用户补充和初次授权	向研究提供准确的任务与适用限制
主模型	拆解问题、选择方法、解释证据、组织报告	提出下一步操作或交付建议
研究运行时与工具执行	编排调用，执行权限和资源边界，记录真实结果	把取得的内容、失败或未知状态反馈给模型
持久记录与恢复	保存执行位置、结果定位、消耗和已发生效果	读回成果，按原恢复约定处理接续，避免重复执行
报告发布	保存并提供用户可取得的正文版本	让用户读取当前报告及已有成果

这些是职责划分，可以存在于同一个进程，复用已有入口与存储。它们不要求五个独立服务，也不需要另加一套统一规划器。

图 1 · 整体路径先跑通一个循环：观察回到模型，回答进入原发布路径。

模型拥有研究判断，运行时拥有执行事实。 模型可以判断还缺哪份证据；程序可以知道工具有没有执行、返回了什么、额度还剩多少。程序不应靠关键词判断"研究已充分"，模型的"我已算完"也不能替代计算回执。

用户原话独立保留。"不执行交易"不能在摘要中丢失，"最近一期正式披露"也不能被转述成"实时持仓"。这让后续判断始终有准确的任务依据。

实施时，先找到三个已有接缝

不用先拆服务。先在现有工程里找到下面三个位置，并沿同一个任务身份接通：

模型请求装配处。 从原会话和任务记录读取用户原文、补充与当前工作状态，每一轮重新组装；不要只在第一次请求时传入任务要求。
工具调用结算处。 保存调用身份、参数、实际结果、来源定位及成功、失败或未知状态，再把可用观察送回下一轮。模型提出调用与工具真正完成分开记录。
正文保存与读取处。 模型生成正文后，交给原发布模块保存；页面和历史读取同一份已提交版本，不只显示流式输出的临时文本。

第一次接线先验证一条短路径：读取 A 的费率，形成费用小节，刷新页面后仍能读到。随后再扩大到三只基金。首轮输入如何组织、怎样检查最终发出的请求，可以直接看《上下文治理·行动篇》的任务保留与首轮工作视图。

三、研究循环怎样持续推进，又怎样发现该收尾？

最小循环可以按五步实现：

准备输入： 原始要求、适用补充、当前工作摘要、材料定位、近期交互与实际剩余资源。
模型选择： 读什么、算什么、核对什么，或者提出交付当前结果。
执行并记录： 在既有权限和预算内调用工具，保存真实内容、结果身份及状态。
反馈观察： 新材料或失败原因进入下一次请求，模型据此修订研究问题。
继续或结束： 模型判断下一步价值和回答范围；运行时处理取消、资源、执行终态与发布事实。

对示例而言，一段研究路径可能是：取得三只基金的基本材料，发现 B 的行业披露日期不符，补读季报，统一期间后再比较。若 B 的原文仍无法取得，模型可以寻找其他获准来源，或把这一项保留为缺口。

这里每一轮都应该增加材料、消除分歧、完成计算，或把问题收敛到可回答范围。模型根据观察决定是否继续；系统把已用资源、失败原因和真实可用材料提供清楚。不要把"已搜索十次"当作充分，也不要因为"还有二十分钟"就要求继续搜索。

把下一步写成可修订的研究问题

实现时，在已有工作状态里保留模型当前关心的问题。ETF Agent 已有 researchNeeds 和 set_research_needs，可以表达下面这样的便笺；这是教学内容示例，不是工具参数格式：

text 复制代码

费用：A、C 已核对，B 还需确认份额类别。
跟踪表现：缺少同期间基准，暂不作三者排名。
行业暴露：B 的页面使用旧披露，下一步读取正式季报。
交付：先整理已确认费用，再综合可比部分与缺口。

取得 B 的新季报后，让模型修订相关问题，并把新便笺与真实读取结果接入后继请求。用户再补充"请解释跟踪误差"时，保留这句原文，模型据此更新工作问题；不要用替换计划的方式删除原比较要求。

验证也落在后继请求：检查它是否同时包含原任务、最新补充、B 的新材料与尚未解决的问题。下一步选择是否合理再单独审阅，不靠便笺里一个"完成"状态判定。便笺与回执怎样分工，见《上下文治理·行动篇》的工作问题更新。

新要求到来时，怎样交接正在执行的请求？

假设模型已经发出一轮请求，用户此时补充"只比较同一披露期"。这句话首先按原文保存，绑定目标研究及纠偏版本。正在传输的请求不会凭空获得新内容；新要求应当进入下一次获准发送的模型请求。

实现时分开处理三种情况：未派发的旧提议在原安全边界停止执行；已经完成的调用保留真实结果；已发出但结果不明的调用继续保留未知状态与消耗。原调用模块允许时，可以尝试打断正在执行的旧请求，但这种请求级中断不能被解释为用户停止了整项研究。

这也是纠偏接线里最值得单独测的分支：让旧请求因新要求而中断，确认后继仍能在原研究阶段重新准入、继续读取资料。显式停止与真实期限仍按原控制处理；重新准入不清零预算，不盲目重做未知请求。只有完整纠偏实际进入后继请求，才能记录交接；最终是否按同一披露期比较，还要检查报告。定向输入、独立短问和研究调整的关系，见后台研究交互专题。

图 2 · 纠偏交接发生在请求边界，不把旧请求中断误写成整项研究停止。

子代理用于独立问题，主模型保留综合职责

先用一个主循环跑通完整任务。只有研究方向可以独立推进时，再把费用核对、跟踪表现或披露差异调查交给子代理。

委派要给出具体问题、适用范围和返回要求。例如："核对 B 最近一期行业披露，返回日期、来源、分布与无法确认的内容。"结果返回后，主模型仍要读取、比较并整合。

需要观察完整交接：子任务完成，结果保存，结果进入主模型输入，最终报告正确采用。这几件事不能互相替代。并行调查可以扩展取证广度，也会增加请求和整合成本；关联紧密的小任务，单模型通常更直接。

实际接入时，先只委派 B 的披露核对，要求返回日期、份额、行业分类、原文定位和未确认项。检查主模型收到的内容中是否保留这些条件，再看报告有没有误用旧日期。具体任务分工与成果交接见《Subagent 全景》的贯穿案例；先跑通这一次交接，再增加并行分支。

四、用明确预算和收尾预留保护交付机会

超长研究首先需要足够的执行空间，同时也要限制消耗，并保留成稿机会。

至少区分三类时间：单次模型或工具操作的期限、整项研究实际执行的时间、从开始至今的墙钟时间。并发活动按真实重叠区间计量；等待和停放另有含义，不能拿当前进程存活时间代替研究已用时间。

ETF Agent 当前新 Run 的默认实际执行上限为 60 分钟，Deep 档位目标为 90 分钟，墙钟安全上限为 120 分钟。旧 Run 保留原准入策略，其他额度和期限仍可能更早限制执行。这些值说明系统提供的空间，不要求每次研究都使用，也不是适合所有产品的默认值。

图 3 · 探索与收尾共用原预算，开始研究时就给整理报告留下空间。

请求额度同样要覆盖主模型、摘要和子代理。探索不能耗尽原有交付预留，主模型需要独立的收尾机会。接近边界时，把真实剩余资源反馈给它，由它决定放弃哪些低价值探索，围绕已有依据形成回答。

例如，费用已核清，行业暴露可以在注明时点的条件下比较，B 的部分历史数据仍缺失。此时应当把可回答部分整理出来，明确跟踪表现的覆盖区间。有限结果仍然可以服务原任务。

若支持运行中升档，由原预算模块记录一次变更，请求准入、循环、计时器和提醒采用同一有效版本。已用、预留和未知消耗继续保留，确认丢失后读回原记录，不能再次放大额度。固定任务先用统一固定预算即可，有实际升档需求再增加这部分机制。

实施顺序：先接资源账，再验证收尾

先核对当前配置与计量：每次模型调用、摘要和 Child 消耗记在哪里，时间由谁累计，交付预留由谁保护。保留原有额度，在下一次请求准入与模型输入中读取同一份有效资源状态，避免另加一个外层小额度提前打断任务。

然后接入原有收尾路径：探索机会耗尽时，停止新增探索，仍允许资源模块认可的收尾调用；把已有材料、当前正文和缺口交给主模型。若最终模型调用也失败，读取已经提交的成果，并保留真实失败，不把未生成的回答标成已交付。

在可控工程测试里构造"探索额度已用完，收尾仍有余额"的状态，观察是否停止搜索、进入原收尾入口并保存实际生成的正文。真实测评仍使用获准的正常配置，不靠临时降低额度制造成功。升档入口、共享预算账和下一轮请求的接线，见Deep 专题的实现章节。

排查时不要只看一个"剩余请求数"。同一次研究至少要分别回答：真实模型请求还有多少可用容量，当前阶段还有多少研究或收尾机会，以及期限和输入容量是否允许下一次调用。这些是原资源记录的不同视图，不是三套独立预算。

例如，两个发布回合可以不再占用其自身已确认的专用收尾单位，但实际发出的模型请求仍计入总消耗；另一次未知请求也不能跟着退款。结算应绑定原请求身份，以原模块的确切回执为据，而不能只看到 send_answer_part 就批量释放相邻占用。历史实现曾验证过这类区别，它不保证所有真实任务都能在剩余机会内完成。

因此再补两项可控检查：总额度非零、当前阶段机会却不足时，提示是否说明真实原因；收尾仍有次数、硬期限却已到时，是否停止新调用并提供已提交成果。内层计数器通过，不代表外层期限和提供方容量也允许执行。相关阶段与边界见预算与约束治理专题。

图 4 · 总余额、当前阶段与外部硬边界一起决定下一次调用能否发生。

五、管理材料与过程，让长研究保持任务方向

时间越长，工具正文、计算结果和分析历史越多。准备下一次模型输入时，可以按用途理解四类内容：

内容	怎样处理	示例
原始要求与用户补充	独立保留原文，按适用顺序提供	比较维度、不执行交易
原始证据与计算结果	保存真实身份、版本和定位，按需回读	季报原文、行业分布及计算输入
工作摘要	概括已做工作、暂定判断、冲突和下一步	"B 的旧页面日期不符，已补读季报，待统一分类"
近期完整交互	保留当前调用与对应返回	最近一次读取及后续分析

这是一种输入组织方式，不需要为它另造四套存储。

材料外置，保留可以工作的桌面

网页全文、长表格和 PDF 可以存放在模型上下文之外，留下原入口可读的定位。当前判断需要的段落或字段直接进入输入；暂时不用的旧正文退出工作集，争议出现时再精确回读。

比较行业暴露时，三份披露的日期、行业分类和权重适合一起保留。核对某个数字时，再读取对应版本和页码。结果要说明实际取得的范围，不能把"有文件引用"当作"已读全文"。小结果也应有可靠定位，避免大量小结果累积后无法退出上下文。

接线从结果生产端开始：读取完成后，由宿主保存获准视图并签发 resultRef；回到模型的内容带上实际选区与覆盖。下一轮请求装配时，才将适合退出的旧正文换成原引用。需要核查时，模型通过已有 read_tool_result 读取该版本的字段、记录或文本范围。

先拿 B 的一张行业表验证：首次取得正文，后续退出工作集，再按原引用回读，核对日期、指定记录和覆盖是否相同。还要检查最终发给模型的请求，确认回读正文没有在后续适配中再次丢失。获取、存储、目录与选区读取的具体示例，见《工具查到的数据，为什么不一定要给大模型看？》。

工作集也不能压得太小。ETF Agent 曾在 96KiB 目标下出现反复回读；调整到 192KiB 后，一项合成教学任务由真实模型用六次请求完成八份文档整理，并触发旧正文引用化。这只支持该样本，不能推导通用最佳容量。观察重点应是下一轮是否有足够材料，以及回读增加了多少操作。

工作摘要压缩过程，原记录保留事实

对已经结算的完整历史区间生成摘要，保留研究做到哪里、判断有什么条件、下一步还缺什么。调用与结果保持完整；多次摘要覆盖不同原始区间，避免递归总结旧摘要。原始要求、执行回执和材料不交给摘要改写。

用真实摘要组成下一次完整请求，检查是否获得实际缩减、能否装入提供方硬容量。有用的部分改善可以采用，软目标不应变成一次必须达成的门槛。摘要沿用已配置请求与已知提供方容量，计入原消耗；失败时保留原上下文，避免为了摘要成功无限重试。

具体落地时，先完成旧正文引用化，再在完整请求仍有容量压力时接入压缩。ETF Agent 保留最近两轮完整交互，只选择已持久保存、调用与结果已结算的连续旧组；摘要只接收可摘要的工作轨迹，原用户要求和执行回执继续由各自记录提供。采用后保存源区间、摘要及后继投影，下一轮从已提交记录组装，避免再次生成同一段摘要。

检查三个结果：旧调用与结果没有被拆开，后继实际请求确实带上摘要，争议数字仍能回到原材料核对。完整选区算法与采用顺序见上下文压缩专题的实际算法，无需在本文再实现第二套压缩器。

图 5 · 摘要接到后续输入，原始要求、材料和执行事实仍可独立核对。

验证要看到实际消费端。10 月 25 日一次真实研究的两段摘要，分别进入后续 19 次和 11 次主模型请求，新进程也读回同一检查点。其中一段仍有期间含义误述，原始参数则保持不变。摘要已采用与摘要解释正确，需要分别检查；原记录让后续核查仍能找到依据。

Anthropic 的上下文工程文章也讨论了压缩、外部笔记与子代理等手段。选择时看瓶颈：材料体积大，先做定位和回读；过程历史长，再考虑摘要；短任务和足够大的窗口，保留近期原文通常更简单。

六、中断后保住已有工作，避免从头再来

已获准后台执行的研究，生命周期独立于页面连接。断线只解除订阅，用户明确停止才进入取消路径；重新打开页面，读取原任务进度和已保存报告。

持久记录要能回答"进程在这里消失，接下来从哪里继续"。复用原有记录，找到原始要求与补充、执行位置、已完成调用及结果、材料定位、工作摘要、资源消耗和正文版本。

恢复先读取这些事实。已保存结果不为重建上下文再次执行，已有正文直接提供给用户。未确认完成的动作沿原执行模块处理，不能换个身份把它当作没发生。同一 Run 继承已记录授权，换进程也不清零消耗。

显式后继研究则是新执行，需要独立准入，并带上获准继承的原问题、限制、来源和待办。父子关联本身不会让模型知道原任务；应检查这些内容是否真正进入后继输入。普通新提问独立处理。

恢复能力按实际路径承诺。截至本次取材，崩溃后某些 Child／Peer 唤醒路径的未闭合活动区间结算与恢复验证仍在补齐，不能承诺任意位置无损续传。先提供已保存成果，再验证承诺的恢复路径。

把保存位置和中断出口分别接清楚

保存动作接在原运行时的生命周期边界：先记录模型提议，由原动作模块保存真实结果回执，再由检查点记录下一阶段与必要引用。先前的"准备读取"不能覆盖已经提交的"读取完成"。具体保存顺序见检查点专题的正常运行路径。

随后分别实现、验证三种出口：

页面断线。 原后台执行继续；重新打开页面只订阅进度、读取正文，不为恢复显示再调用模型。
普通进程中断。 由原恢复职责结算并保留成果。ETF Agent 默认不因此重建整张旧 Root／Child 执行图；用户明确继续时，进入独立准入的新 Run，携带获准复用的原问题、材料与缺口。
已有合法控制唤醒。 按原等待关系、检查点和执行身份接续它允许的动作，不能只因找到旧 Run 就启动执行。

对应地做刷新页面、停止自有测试执行器、触发原等待回复三种检查；分别观察有没有额外模型请求、已保存报告能否读回、已结算工具是否重复派发。具体出口选择见《断线不是崩溃》的连接分类，不能拿其中一种成功替代另外两种。

同时控制历史处理成本

持续运行也要求服务自身不被历史拖慢。除了模型与工具耗时，还要观察事件循环延迟、历史处理耗时和取消响应。

ETF Agent 一次租约故障中，事件循环阻塞约 30.4 秒，租约查询本身约 1ms。瓶颈是为同一候选重复构造证明；限定在同一次同步推导内复用后，46 轮、111 条回执的固定快照处理从 27,887ms 降到 358ms，关系哈希一致。这是局部纯函数对照，不是整项研究加速比例。

因此先查重复扫描、序列化与证明重建。单纯延长租约会推迟识别失效执行者，永久缓存又可能复用过期事实；必要计算仍重时再考虑工作线程。Node.js 的事件循环说明解释了同步阻塞为何影响其他任务调度。

七、把进度、报告和异常收尾设计成一条交付路径

研究过程中，用户需要知道正在推进什么；研究结束后，需要一份连贯的回答。两类内容分别组织。

进度可以是："费率已核对，正在统一行业披露时点，B 的跟踪数据仍缺一段。"报告则按前面的骨架，呈现比较范围、对照结果、解释和缺口。独立成熟的小节可以先交付，依赖多路材料的综合结论由模型在比较必要依据后组织。无需增加"证据充分"布尔门，也不要求耗满某个时间比例。

后续发现 B 的费率属于另一类份额时，更新费用章节，并检查依赖它的综合判断。通过已有发布路径保存当前版本，旧版本保留历史，让用户直接读到连贯报告，不必自行拼接几段勘误。

修订也需要容量。ETF Agent 的 Deep 默认更正空间曾从每块 2 次、整次 8 次扩大到每块 6 次、整次 24 次；显式配置仍优先，已用和预留不重置。这提供修订机会，不能保证改判正确，已有配对实验也未得到一致改善。

实施时，给模型看当前正文，再按身份更新

先复用两条现有路径：send_research_update 发送工作进展，send_answer_part 提交正式答案部分。费用小节保存成功后，下一轮由发布模块提供当前块的身份、版本、正文和遗漏说明，让模型知道用户已经读到了什么。

发现 B 的份额错误时，让模型针对原块使用已有 replaces 修订，提交纠正后的完整小节；发布模块保存新版本，再由页面读取。不要根据 Markdown 标题猜替换目标，也不要靠聊天历史推测当前正文。

可以用两份教学披露验证：先提供旧费率，保存费用小节；随后提供适用份额的更正材料，检查新版本是否替换原块、相关结论是否同步修订、刷新后是否只读到当前版本。模型怎样取得当前正文，以及怎样定位修订对象，分别见渐进式回答专题的当前文章视图与按身份修订。

把可选观测从正文提交的等待链中移开

还要检查发布周围的日志、诊断和可选证据采集。它们如果持锁等待，或被放进必须成功的提交链，即使模型已经写出正文，也可能拖住发布和结束流程。

ETF Agent 在冻结基线中复现过一条跨事务锁等待环。对应修复只处理可选采集持锁等待的那一条边：遇到该处锁冲突，回滚本次采集、释放事务锁，并留下有限的失败记录；独立正文提交、结束和后续读取继续走原路径。这个取舍允许丢失一份可选观测，不把它写成采集成功，也不通过全局重试或另一套队列掩盖问题。

实践中可以在自有隔离测试环境占住该采集需要的锁，检查采集失败是否可见、正文能否保存和读回、后续独立采集能否成功。正文自身的必要存储失败仍然是交付失败，不能被当作可选观测跳过。若正文事务已提交、运行日志尚未更新，则按原提交身份读回，不把日志缺失当作重新发布的依据。准备、预览、提交和运行终态的区别，见Publication 专题。

图 6 · 局部回滚保护的是独立交付；正文自身的必要存储仍必须成功。

出问题时，系统具体保护什么？

情况	对应处理	交付时保留什么
一个来源读不到	如实返回失败，模型选择其他获准来源或缩小判断范围	其他已取得依据和已成立结论
旧材料退出上下文	保留真实定位，必要时回读对应版本与范围	核对原文的能力，不把摘要冒充原文
摘要生成失败	不采用失败摘要，保留原历史，按原资源机制继续或收尾	原始要求、执行事实和已有正文
资源接近边界	限制进一步探索，使用原先保护的收尾机会	围绕原问题的有限回答与关键缺口
页面断线或进程中断	页面重新订阅；进程按实际支持的恢复路径继续	已保存结果与报告，不清零消耗或重做已结算效果
发现旧结论有误	修订对应章节和依赖判断，保存新版本	用户可取得的当前报告与历史版本
可选提醒或附件异常	限制在对应局部效果，交给原职责处理	独立合法正文和同批可用内容

运行终结由原有职责统一处理，局部异常不自动取得整份正文的处置权。真实权限、隔离与投资执行边界仍由各自模块执行；无法支持的判断如实留缺，已有合法内容继续提供。

这些手段让问题更容易被定位、影响更局部、已有工作更容易保留，也让任务在资源允许时有收尾机会。它们不能保证永不故障，更不能认证答案正确。实际生成、保存的内容应可取得；尚未发生的交付也不能用状态标签冒充成功。

八、落地顺序：先跑通回答，再扩大持续研究能力

如果已有模型和工具入口，可以分三步实施，每步先交出完整可观察的结果：

阶段	先实现什么	怎样检查
完整交付	固定预算、一个主循环、真实工具结果、报告保存与读取	从原问题追到最终回答，确认用户能取得正文
长任务支撑	结果定位与回读、按需摘要、收尾预留、历史成本观察	检查实际请求、摘要后继采用、资源将尽时的回答
中断与协作	后台订阅、用户补充、按既有约定结算或接续、必要的委派	检查断线读回、中断后保留成果、合法接续不重复动作、子结果进入主模型综合

先用可控材料检查关键分支：披露日期冲突、来源失败、摘要失败、资源将尽和进程中断。再用真实模型审阅研究行为：是否补核冲突、采用读到的证据、覆盖原问题，以及报告是否自洽。系统行为检查与答案质量评测分别进行。

第一轮实施可以直接围绕同一项任务安排四次检查：正常生成三基金比较报告；撤掉 B 的一份教学材料，检查局部缺口与其他结论；用可控状态触发上下文压力和探索额度耗尽，检查回读与收尾；在保存费用小节后断开页面，重新读取，再输入更正材料检查版本更新。

每次都保留实际输入、工具回执、最终正文和取得正文的位置。若系统没有生成新回答，明确是哪一步失败、已有哪份成果仍可取得。真实模型比较沿用同一原问题与资料条件，分别观察覆盖、来源使用、矛盾、可读性和消耗，不只比较运行分钟数。可照《上下文治理·行动篇》的端到端检查组织任务记录，再参考Deep 专题的配对实验理解结果取舍。

用版本修订检查研究判断，别只检查数字

四组人工合成任务、真实模型参与的 Normal／Deep 配对实验里，有一项收益差额案例：更正材料把差额从 −0.5 改为 −0.9 个百分点。模型能够更新数值，却仍可能声称费用无法解释主要差额，或从名义费率推断费用影响上限；材料实际只支持费用贡献未知。

所以修订测试应逐版核对三件事：新数据有没有进入，依赖旧数据的解释有没有重新评估，证据仍然未知的部分有没有继续保留未知。改对差额，不自动使归因正确。

释放更正材料的时机也会影响测试含义。若第一次发布只有"正在读取"，随即就提供新版，只能观察之后如何消费资料，不能证明模型修正过旧结论。要检验改判，可以先冻结旧版资料与预期问题，在旧版实质结论实际保存后再提供更正材料，由独立评阅逐版比较正文与来源。这个判断用于评测，不在生产运行里增加关键词门或强制复核步骤。完整样本与解释边界仍见Deep 的配对结果。

图 7 · 检验改判要看逐版实质结论；改对数值，仍须核对依赖解释。

对于开头的任务，最终要观察的是：同一口径能否建立，缺口能否被识别，原始限制能否保留，用户能否取得一份清楚的比较报告。沿着这条交付链增加机制，每一项设计就都有明确用途，而不是仅仅让 Agent 运行得更久。

阅读站点原文与完整图解 · GitHub 技术文集，欢迎 Star 支持。