一个研究 Agent 最容易展示的能力，是它会自己搜索。
最难做好的能力，却是它知道什么时候不再搜索。
如果系统停得太早，它可能只看了一份摘要，就把一个未经核实的说法写进报告。如果停得太晚，它会换着关键词反复查同一件事，消耗更多 Token 和工具调用，却没有增加新的证据。
很多 Demo 只有一个 max_steps。循环跑到第八步，无论信息是否充分都结束。这个设置能防止程序永远运行，却没有回答研究任务真正的问题：当前证据是否足以支持结论？
所以面试官追问“Agent 怎么停止”时，不能只回答“设置最大轮数”。完整问题是：
Deep Research 怎样判断已经查够？怎样区分信息充分、搜索无进展、预算耗尽和工具故障？如何避免没查够就回答，也避免陷入重复搜索？
先区分四种“结束”
第一种是正常完成。
系统已经覆盖任务契约里的关键对象和维度，主要结论有来源，关键冲突得到解释，剩余缺口不会推翻当前建议。这时结束是研究判断，不是预算被用完。
第二种是无进展退出。
Agent 已经换过合理查询或来源，但连续几步没有获得新信息。继续搜索只会重复。系统应停止当前路径，保留已经确认的内容，并说明哪部分仍然缺证据。
第三种是风险中止。
任务要求访问未授权资料、执行危险代码、提交外部操作或越过权限边界。此时即使研究尚未完成，也必须停止或转人工。
第四种是预算兜底。
达到最大步骤、最长时间或允许成本。预算上限保证系统不会无限运行，但它不等于研究完成。输出必须标明“因预算结束，以下问题尚未验证”，不能把超时包装成完整结论。
完成、无进展、风险中止和预算耗尽，对用户与评估系统有完全不同的含义。
正常完成的核心，是“证据充分”
证据充分不是来源越多越好。
十篇互相转载的文章，可能只有一个原始出处。三十条搜索结果，也可能都没有回答用户真正关心的部署限制。
判断充分度时，可以逐项检查任务契约。
对象覆盖：所有必须比较的候选是否都处理过，是否有候选因为硬约束被合理排除。
维度覆盖：影响结论的关键维度是否都有证据，不能只查到性能就跳过成本和合规。
来源质量：关键事实是否尽量回到原始或权威来源，二手转述是否标明边界。
冲突处理：多个来源不一致时，是否核对时间、版本、测试条件和统计口径。
不确定性：确实没有公开资料的部分，是否明确写成未知，而不是由模型补齐。
完成判断应该围绕“这份证据能否支撑当前结论”，而不是“搜索结果有多少”。
用研究状态代替“模型觉得够了”
如果只在 Prompt 里问模型“你认为信息够了吗”，判断很难复现。
更稳的方式是维护结构化研究状态。每个关键问题记录：当前结论、来源、来源类型、时间、是否存在冲突、仍需什么证据、当前状态。
状态可以是已确认、部分确认、待验证、公开不可得和不再相关。完成判断由这些状态聚合，而不是让模型凭一段长上下文自由宣布结束。
例如三个候选、四个关键维度，共十二个研究单元。并不要求十二格都填满。如果某候选已经不满足硬约束，后续低优先级维度可以标记不再相关；如果某项数据没有公开资料，可以标记公开不可得，并说明搜索范围。
这样做的价值是可解释。系统可以告诉用户：“部署方式和许可证已确认，性能资料口径不一致，当前只给出定性判断。”
“没有新信息”怎么判断？
无进展检测是停止系统最重要的一层。
第一种信号是查询重复。Agent 可能把同一句搜索词换一下语序，实际意图没有变化。可以对标准化查询、目标实体和目标维度做相似度或规则比较。
第二种信号是来源重复。多个 URL 可能转载同一个原文，或只是参数不同的同一页面。需要根据规范化 URL、正文指纹和引用关系去重。
第三种信号是状态没有变化。工具调用成功不代表有进展。如果新页面没有新增事实、没有关闭缺口、没有改变假设，就只是动作成功，研究未前进。
第四种信号是结果质量持续下降。搜索范围越放越宽，返回内容与任务越来越远。此时继续扩展关键词可能只增加噪声。
第五种信号是同一工具反复失败。网络超时适合有限重试，但参数错误、权限拒绝和页面永久不存在，不应该原样重试。
工具返回成功不是进展，研究状态发生有价值的变化才是。
检测到重复后，不要马上结束整个任务
重复通常说明当前路径走不通，不一定说明整个研究无法继续。
系统可以按顺序做几件事。
先换查询表达。把宽泛关键词改成具体实体、版本、时间或目标维度。
再换来源类型。普通搜索没有结果时，尝试官方文档、论文元数据或监管公告；但前提是这些工具在允许范围内。
然后检查问题本身。也许用户要求的数据没有公开口径，系统应把任务从“寻找精确数字”调整为“解释为什么不可比，并提供现有证据”。
最后才关闭这个子任务。关闭时记录已经尝试的路径和失败原因，避免后续重规划又创建同一任务。
这套过程对应“换策略”，不是简单增加重试次数。
最大步数为什么只能是兜底？
最大步数解决的是系统安全，不是研究质量。
它可以防止模型陷入死循环，限制异常任务占用资源，也方便对长任务做容量规划。但固定步数无法适应不同问题。
一个事实核查可能两步就完成。一个多对象比较可能需要更多动作。若统一跑满十步，前者被迫制造无效搜索；若统一限制五步，后者可能在关键证据缺失时被截断。
更合理的做法是同时保留软停止和硬停止。
软停止根据证据覆盖、冲突、信息增益和任务状态判断，可以提前完成。
硬停止根据步骤、时间、成本和安全边界判断，保证系统最终会退出。
硬停止发生时，结束状态必须是预算耗尽，而不是正常完成。评估系统也要把两者分开统计。
提前停止也可能是错误的
Agent 看到一个看似完整的答案时，很容易过早结束。
常见原因之一是首个来源写得很自信。页面结构完整、数字很多，模型误以为证据充分，却没有检查来源日期和统计条件。
原因之二是计划漏了关键维度。系统完成了自己列出的所有任务，但初始计划本身没有覆盖合规或迁移成本。
原因之三是工具只返回摘要。搜索摘要提到了结论，Agent 没有打开正文核对，就认为任务完成。
原因之四是训练数据偏向短轨迹。模型学会尽快给最终答案，因为短轨迹更常出现，或截断样本受到错误惩罚。
因此，停止判断需要反向检查：有没有关键结论只有单一弱来源？有没有要求多源验证却只查一处？有没有未打开正文就引用摘要？有没有重要维度从未创建任务？
一个可执行的停止决策顺序
每轮工具返回后，可以按以下顺序检查。
先检查安全和权限。发现越权、危险操作或不允许的数据范围，立即中止。
再检查工具结果是否有效。区分成功、有内容、与当前问题相关和产生新证据四个层次。
然后更新研究状态。把新事实、冲突、缺口和来源写入当前报告，不把整页内容无限追加。
接着检查正常完成条件。关键任务是否闭合，主要结论是否被支持，剩余缺口是否会改变结论。
若未完成，检查是否无进展。查询和来源是否重复，状态是否连续几轮不变，当前路径是否已经穷尽。
若仍有合理路径，生成下一步行动。若没有，就以“信息不足”结束该分支或整个任务。
最后检查硬预算。达到边界时保存状态，并返回部分结果和缺口。
这个顺序很重要。如果先检查步数再更新状态，最后一次有价值的证据可能丢失；如果先让模型自由生成下一步，再检查重复，系统已经多花了一次调用。
停止原因必须进入 Trace
一条研究 Trace 至少要记录任务 ID、当前步骤、调用工具、标准化查询、结果摘要、是否新增证据、关闭了哪个缺口、下一步决定和停止原因。
停止原因可以使用稳定枚举，例如：正常完成、无新证据、重复路径、工具不可用、权限中止、用户取消、时间预算和步骤预算。
这些枚举要支撑后续统计，不能只作为少写日志的快捷方式。
如果大量任务因步骤预算结束，可能是预算太紧，也可能是问题拆解太碎。如果大量任务因重复路径退出，可能是查询重写或状态管理有问题。如果任务总是正常完成，但用户仍反馈报告缺项，完成条件或初始计划可能漏了关键维度。
没有结构化停止原因，团队只能看到“任务结束”，无法知道系统到底是在完成研究还是被迫放弃。
四类 bad case 怎样定位？
Bad case 一：同一个词搜了五遍
先看标准化查询是否相同，再看模型是否读到了“已经搜索过”的状态。如果历史信息只存在于很长的对话中，模型可能忽略它。需要独立维护已执行动作集合，并把重复错误明确返回给模型。
Bad case 二：搜一次就给最终结论
检查任务契约是否要求比较和多源证据，训练数据是否大量是短轨迹，完成判定是否只看“已经得到一个答案”。修复应补充缺证据的反例和完整性检查，而不只是要求“多搜几次”。
Bad case 三：工具一直超时，Agent 一直重试
检查错误分类。暂时网络抖动可以退避重试，权限错误和参数错误必须先修参数或换路径。超过当前工具的失败预算后，应降级或明确无法获取。
Bad case 四：到上限后生成一份看似完整的报告
这是状态表达错误。预算耗尽只能输出部分结论、证据和未完成项。若前端把所有结束状态都显示为“研究完成”，用户会被误导。
怎么建立停止条件评测集？
第一组是可以快速完成的问题。用于检查系统能否在证据充分后提前结束，而不是机械跑满预算。
第二组是必须继续查的问题。初始搜索故意只提供局部信息，看系统是否会识别缺口并采取下一步。
第三组是公开资料不足的问题。正确行为是尝试合理路径后说明无法确认，而不是不断扩大搜索或编造结论。
第四组是来源冲突问题。系统需要核对时间、版本和口径，不能看到第二个不同答案就随便选一个结束。
第五组是循环诱导问题。提供重复页面、相似摘要或持续空结果，检查重复检测和无进展退出。
第六组是权限和风险问题。正确行为是中止或转人工，而不是以完成任务为目标绕过限制。
不同结束类型需要不同样本，不能用“最后有答案”作为统一验收。
停止系统要看哪些指标？
正常完成率只能说明有多少任务被标记完成，不能单独代表质量。
过早停止率用于观察关键证据尚未覆盖就结束的任务。
无效动作率可以定义为没有新增事实、没有关闭缺口、也没有改变有效假设的动作占比。
重复查询率和重复来源率用于定位循环。
预算耗尽率反映任务与资源边界是否匹配。
部分完成可用率则检查信息不足时，系统是否仍然提供了可核查的已有结果和明确缺口。
这些指标需要按问题类型和难度拆开看。开放研究任务的平均步数本来就可能高于事实核查，不能用一个全站均值要求所有任务一致。
用户取消和系统中断也要可恢复
长任务不一定由 Agent 自己结束。用户可能取消，进程可能重启，工具服务可能长时间不可用。
如果系统只在内存里保存消息列表，任务一断，已经核验的证据和未完成项就全部丢失。重新执行不仅浪费资源，还可能得到另一条无法对照的轨迹。
因此每完成一个关键子任务，应该持久化受控研究状态、来源 ID、已执行动作、剩余预算和当前结束原因。恢复时先校验任务版本和可用工具，再从下一个未完成节点继续，不能简单把最后一条消息重新发给模型。
用户取消时也分两步。先阻止新的工具调用，再等待或终止当前安全可中断的动作，最后把状态标记为用户取消。已经获取的资料是否向用户提供，取决于产品约定和内容是否完成核验，但不能把它标为正常完成。
系统中断恢复后要防止重复副作用。Search 和 Visit 通常是只读操作，重复代价主要是成本；如果未来接入写操作，则必须使用幂等键和人工确认，不能把研究循环的自动重试直接套到有副作用工具上。
部分完成报告应该包含什么？
任务被预算、工具故障或用户取消打断时，少写几段并非最大风险；真正危险的是把不完整结果包装成完整答案。
一份可用的部分完成报告至少应回答五件事：为什么停止，已经核验了哪些主张，每条主张由哪些来源支持，哪些关键问题仍未解决，以及后续从哪里恢复。对已经看过但尚未完成交叉核验的材料，要标成候选证据，不能混进确定结论。
这里还要保留尝试过的路径。例如系统连续访问某个来源都失败，恢复时就不该无条件重复同一动作；如果某个子问题因为资料口径冲突没有收敛，报告应把冲突条件写出来，而不是只留下一个被截断的结论。
产品展示也要明确区分“已完成”“部分完成”和“执行失败”。部分完成可以提供价值，但它的价值来自边界清楚、证据可查和任务可继续，不是靠语气把缺口遮住。
停止行为也会被训练数据塑造
如果训练轨迹大多在很短步骤内给出最终答案，模型可能倾向过早结束。
如果失败轨迹只因没有最终标签就被统一判低分，模型可能学会在接近长度上限时草率收尾。
如果训练数据几乎全是 Search 和 Visit，模型也可能觉得“继续调用工具”总比“基于证据结束”安全。
所以停止机制不能只靠运行时规则。数据中要同时存在证据充分后正确结束、信息不足时明确收口、工具失败后换策略、无需搜索直接回答和继续研究才正确的样本。奖励也要同时检查最终答案、格式和过程，避免只奖励短或长。
运行时规则负责硬边界和可解释状态，训练负责让模型在边界内形成更合理的行动倾向。二者不能互相替代。
面试官继续追问，怎么接？
追问一：如何量化“信息充分”？
不建议只给一个模型置信度。可以从任务单元覆盖、关键结论来源、来源独立性、冲突处理和剩余缺口影响五个方面做结构化判断，并保留人工评测校准。
追问二：重复检测用字符串相等够吗？
不够。需要结合标准化查询、目标实体、目标维度、URL 规范化和正文指纹。语义相同的查询可能文字不同，多个 URL 也可能转载同一来源。
追问三：达到最大步数时应该怎样返回？
保存当前状态，返回已确认结论、对应来源、待验证项和结束原因。不能生成一份假装完整的报告，也不能只返回“任务失败”。
追问四：怎样避免为了早停而牺牲质量？
把完成条件绑定任务契约和证据，不奖励单纯的短轨迹。评测集同时包含需要早停和必须继续的样本，防止系统只学会一个方向。
追问五：模型和规则谁来决定停止？
证据是否支持结论可以由模型按 Rubric 辅助判断；步骤、时间、权限、重复动作和状态完整性适合程序约束。二者组合比完全自由或完全硬编码更稳。
怎样回答“Agent 为什么此刻该停”
我会把 Deep Research 的结束分成正常完成、无进展退出、风险中止和预算兜底，不能用一个 done 状态混在一起。正常完成要回到任务契约，检查关键对象和维度是否覆盖、主要结论是否有来源、重要冲突是否处理，以及剩余缺口会不会改变结论。
每轮工具返回后，我会先校验安全和结果有效性，再更新已确认结论、待验证假设和信息缺口。工具调用成功不等于研究有进展，只有新增证据、关闭缺口或合理改变假设才算前进。如果查询、来源和研究状态连续重复，就换查询或来源类型；仍无进展则明确输出信息不足。最大步骤、时间和成本只是防止任务失控的硬兜底，触发时必须标记预算耗尽，不能冒充正常完成。
验证时我会准备可快速完成、必须继续查、公开资料不足、来源冲突、循环诱导和权限风险六类样本，分别观察过早停止、无效动作、重复查询和预算耗尽。搜索次数没有统一的好坏标准，每一步都为结论增加可核查价值才是目标。
停止机制必须留下什么证据
选择一次正常完成和一次无进展退出，对照研究状态与 stop reason，证明系统不是碰到步数上限才被迫结束。
- 你的系统是否只有
max_steps，还是存在证据完成和无进展判断？ - 是否区分正常完成、预算结束、工具失败和用户取消？
- 能否拿出一条 Trace 说明为什么停止？
- 重复检测比较的是文字、意图、来源还是研究状态？
- 如果没有停止评测集，不要宣称 Agent“知道什么时候收手”。
一个成熟的研究 Agent 应该能够说明：为什么这一刻继续查已经没有价值，或者为什么现在还不能下结论。 永远声称还有下一步，只说明停止条件没有建立起来。