• 主动验证：通过实际执行干预来检验假设，避免了纯理论分析的盲目性。只有经过干预验证的假设，才能被认为是可信的故障定位【7†source】。
• 多步干预：DoVer并不局限于在单一步骤上进行干预。它将长交互日志分解为多个独立的“试验”（trial），在每个试验中分别尝试干预，从而全面评估不同干预点对故障的影响【7†source】。这种多步干预策略能够捕捉到那些需要多轮调整才能修复的复杂故障。
• 以结果为导向：DoVer不再将“归因准确度”作为调试成功的唯一指标，而是将“系统是否成功”或“任务进度是否提升”作为衡量调试效果的核心标准【7†source】。这种以任务成功率为导向的评价方式，确保调试活动真正朝着解决问题的方向推进，而不仅仅是停留在理论分析层面。

DoVer核心组件

• 日志分析器（Log Analyzer）：负责接收原始的执行日志，并对其进行分析和预处理。这一步可能包括对长日志进行分段、提取关键信息、识别潜在故障点等，为后续的假设生成提供基础。
• 假设生成器（Hypothesis Generator）：基于预处理后的日志，利用LLM生成若干可能的故障假设。每个假设通常指出一个疑似出错的智能体和步骤，以及相应的理由说明。假设生成器不需要产生绝对正确的假设，因为后续会通过干预来验证其正确性【7†source】。
• 干预设计器（Intervention Designer）：针对每个故障假设，设计具体的干预措施。干预可以是修改某个智能体接收到的消息内容，或者调整任务计划的顺序和内容等。设计器需要确保干预是“可行且最小化”的，即能够实际执行且对系统改动最小，以避免引入新的混乱。
• 干预执行器（Intervention Executor）：在原始执行日志的指定步骤插入干预，并从该点开始重新运行多智能体系统。执行器通常需要具备“检查点与回放”（checkpoint & replay）的能力，以便从日志的任意位置恢复执行【7†source】。通过对比干预后执行的输出与原始失败输出的差异，执行器可以判断干预是否有效。
• 结果评估器（Result Evaluator）：评估干预执行的结果，判断故障是否被解决或是否取得了进展。评估器可能使用多种指标，包括任务是否最终成功、在干预后的执行中是否达到了某些里程碑子目标等。根据评估结果，可以将假设标记为“已验证”、“部分验证”或“已反驳”等状态。
• 控制器（Controller）：协调整个调试流程的控制器。它根据评估结果决定下一步行动：如果某个假设被验证为错误原因，可以尝试进一步深入调试或记录结果；如果假设被证伪，则放弃该假设并尝试下一个；如果干预未取得明确进展，可能需要调整干预策略或引入人工参与。控制器确保调试过程按照“假设-干预-验证”的循环高效迭代。

• 日志分段与故障假设生成：面对长而复杂的交互日志，DoVer首先将其划分为若干独立的“试验”（trial）。每个试验通常由一次新的计划或规划阶段触发，并在任务完成或再次规划时结束【7†source】。这种分段策略有助于缩短上下文长度，将一个长日志拆解为多个可独立分析的子任务【7†source】。对于每个试验，DoVer利用LLM生成故障假设，指出哪个智能体在哪个步骤可能出错，并提供理由。这一步骤的输出是一系列候选的故障诊断结果。
• 针对性的干预设计：在获得故障假设后，DoVer需要将其转化为可执行的干预措施。DoVer主要采用“编排者级干预”（Orchestrator-level Interventions）的策略【7†source】。这意味着干预作用于任务的主控智能体或计划层，而不是直接修改底层子智能体的内部能力。具体做法包括：
  • 修改发给子智能体的指令：通过调整主控智能体（Orchestrator）发送给其他智能体的消息内容，来纠正错误的意图、补充缺失的上下文或修正错误的参数，从而间接引导子智能体修正其行为【7†source】。例如，如果Orchestrator给WebSurfer智能体的指令存在错误，DoVer会修改该指令，使其更加清晰准确，从而避免后续智能体的误操作。
  • 更新任务计划：直接修改Orchestrator制定的执行计划，包括重新排序、分解或替换计划中的步骤，以避开已识别的故障点【7†source】。这种干预方式从整体上调整任务的执行策略，而不是纠结于单个智能体的具体行为。例如，如果原计划中某一步骤导致失败，DoVer可以调整计划，将其后移或用替代方案替换，以绕过问题。
  通过在消息传递层进行干预，DoVer确保了干预的通用性和简洁性。这种方式不需要深入每个智能体内部进行修改，降低了调试的复杂度，同时避免了引入新的潜在错误。
• 干预执行与回放：设计好干预后，DoVer需要在实际系统中执行它，以观察效果。这要求系统能够从日志的任意位置恢复执行并进行干预。DoVer通常通过“检查点与回放”机制来实现这一点【7†source】。具体而言，在原始日志中，DoVer记录下每个步骤的系统状态和消息，作为检查点。当执行干预时，它将日志回滚到疑似故障步骤的前一刻，然后应用干预（例如修改一条消息或调整计划），接着让系统从该点继续执行【7†source】。这样，干预后的执行结果与原始执行结果可以进行对比，以判断干预是否有效。这种在原日志基础上进行的“反事实执行”（Counterfactual Execution）是DoVer验证假设的关键手段。
• 结果度量与反馈：在干预执行完毕后，DoVer需要对结果进行评估，以确定调试是否成功。评估分为两个层面：
  • 任务成功与否：最直接的度量是干预后的系统是否最终完成了任务。如果干预后的执行达到了任务的成功状态，则可以认为相应的故障假设得到验证，调试成功。DoVer通过定义明确的任务完成标准（如输出满足要求、达到目标状态等）来判断任务成功【7†source】。
  • 任务进展度量：并非所有干预都能直接让任务从失败变为成功。有时干预只能部分改善情况，使任务取得一定进展。DoVer引入了“里程碑”（milestone）的概念来衡量这种进展【7†source】。具体而言，它通过LLM分析任务的理想执行路径，提取出一系列关键子目标作为里程碑。然后比较干预前后执行中完成的里程碑数量，计算“进展率”【7†source】。如果干预后的执行相比原执行取得了更多里程碑（例如从完成0个里程碑提高到完成2个），则认为假设得到了部分验证，即使任务未最终成功，也表明调试朝着正确方向前进。这种细致的进展度量使DoVer能够捕捉到那些“部分修复”的案例，从而更全面地评估调试效果。
• 假设验证与迭代调试：基于上述结果度量，DoVer会对每个故障假设进行验证或反驳的判定。如果至少两次独立运行的干预中有一次成功，DoVer将该假设标记为“已验证”；如果两次运行都失败但进展显著提升，则标记为“部分验证”；如果进展未达到阈值，则标记为“已反驳”；其余情况标记为“不确定”（Inconclusive）【7†source】。通过这种分类，DoVer能够明确知道哪些假设确实是错误的根源，哪些不是。对于未验证的假设，DoVer可以继续尝试其他干预或引入人工分析，从而进入下一轮调试迭代。这种迭代循环保证了调试过程的持续改进，直到找到真正的故障原因并加以解决。

• LLM在日志分析和假设生成中的应用：DoVer充分利用了LLM在理解和推理方面的强大能力。在日志分析阶段，DoVer使用LLM来识别日志中的“规划步骤”，从而实现自动化的试验分段【7†source】。LLM能够根据上下文判断哪些步骤是新的计划开始，哪些是任务的结束，从而将长日志合理地切分为多个试验。这种基于LLM的分段方法比人工更高效，也比简单的规则更准确，因为它可以理解复杂任务中隐含的规划意图。在假设生成阶段，DoVer同样依赖LLM来分析每个试验的执行过程，找出可能的故障点。LLM能够综合考虑多轮对话、工具调用结果等因素，给出一个“疑似出错智能体 + 步骤索引 + 理由说明”的假设【7†source】。虽然LLM生成的假设可能不完全精确，但DoVer通过后续的干预验证来弥补这一点，即使初期假设不准确，也能通过实验反馈进行修正。
• 干预设计的通用策略：DoVer在干预设计上采用了通用且可扩展的策略。正如前文所述，DoVer主要关注编排者层的干预【7†source】。这种设计选择有几方面考虑：一是通用性，因为大多数多智能体系统都有一个主控智能体或计划层，修改其消息或计划即可对整个系统产生影响；二是安全性，避免直接修改底层智能体可能带来的副作用；三是简洁性，只需少量改动即可尝试多种假设。在实现上，DoVer需要构建一套“干预规则”或模板，用于根据假设生成具体的干预内容。例如，对于“Orchestrator在某步骤指令错误”的假设，干预规则可能是将Orchestrator在该步骤发送的消息替换为修正后的文本；对于“计划中某步骤不必要”的假设，干预规则可能是将计划中该步骤删除或替换为其他操作。DoVer通过LLM结合规则，为每个假设生成若干备选干预方案。为了提高效率，DoVer可能优先尝试那些“最小改动”的干预，因为改动越少，引入额外问题的概率越低。一旦某个干预成功，DoVer会记录下该有效的干预模式，供后续类似故障参考。
• 检查点与回放机制：实现DoVer的关键挑战之一是如何在日志中插入干预并重新执行。这要求底层智能体框架提供检查点和回放的支持。DoVer通过在执行过程中保存关键状态快照来实现检查点功能【7†source】。例如，每当一个智能体完成一个动作或发送一条消息时，系统记录下当时的环境状态、智能体内部状态和该消息内容。这些快照构成了可回放的日志。当需要进行干预时，DoVer将日志回滚到目标步骤之前的最后一个检查点，然后在该步骤应用干预（例如修改即将发送的消息内容），接着从该点继续执行。由于已经记录了之前步骤的所有状态，系统可以精确地复现干预前的上下文，从而保证干预实验的“一致性”和“可重复性”。这种检查点-回放机制是DoVer验证假设的基础，它使得在真实系统中进行受控实验成为可能。需要注意的是，并非所有框架都天然支持回放，因此DoVer在一些框架上进行了增强。例如，在AutoGen2框架上，DoVer通过为其添加检查点和回放接口，使其支持干预式调试【7†source】。这表明DoVer具有较强的框架适应性，可以通过对现有框架进行“最小侵入式”改造来实现功能【1†source】。
• 结果度量的自动化：DoVer引入了任务进展的度量，这需要系统能够自动判断执行是否达到了某个子目标。为此，DoVer利用LLM充当“评判员”来分析执行日志【7†source】。在实验前，DoVer会先基于人工标注或理想解决方案，提取出任务的“里程碑列表”。这些里程碑可以是任务完成过程中的关键步骤或子目标（例如“成功登录系统”、“提取到所需数据”等）。在干预执行后，DoVer使用LLM阅读干预后的执行日志，检查其中是否完成了里程碑列表中的各项。LLM能够理解任务的语义，判断某个操作是否对应某个里程碑。例如，如果里程碑是“找到目标网页”，LLM可以判断日志中是否有步骤表示找到了该网页。通过将干预后的执行日志与里程碑列表逐一比对，DoVer可以计算出完成了多少里程碑，从而量化进展【7†source】。这种基于LLM的自动度量方法避免了繁琐的人工标注，同时能够处理开放性的任务。当然，它也存在一定偏差，因为LLM作为评判员可能偶尔误判。但总体而言，这种方法大大提高了结果度量的效率和可扩展性。
• 多假设并行与迭代调试：DoVer通常需要对多个假设进行验证。为了提高调试效率，DoVer可以并行地对多个假设进行干预实验。例如，对于同一故障日志，DoVer可以同时生成多个假设，并在不同的运行实例上分别应用相应的干预，观察结果。这种并行策略可以利用多核或分布式计算资源，在较短时间内获取多个假设的验证结果。一旦某个假设被验证为错误原因，DoVer可以立即停止对其他假设的实验，从而节省时间。如果所有假设都未得到验证，DoVer会启动下一轮迭代。在下一轮中，DoVer可能基于前一轮的结果调整策略，例如引入人工专家对复杂日志进行分析，或者让LLM基于失败案例重新生成新的假设。通过这种“假设-干预-验证-新假设”的循环，DoVer能够不断逼近真正的故障根源，直到找到解决方案。整个迭代过程在DoVer框架中自动进行，无需人工过多介入，大大降低了调试的复杂度。

方法对比

• 与传统日志归因的比较： 传统的日志归因方法通常由人工或简单的脚本完成，其效率和准确度都较为有限。在效率方面，人工调试往往需要反复阅读冗长的日志，尝试不同的假设，这非常耗时且容易遗漏关键信息。而DoVer通过自动化分析日志和并行实验，大大加快了定位错误的进程。一项对现有日志归因方法的复现研究显示，即使是经过提示工程优化的GPT-4o模型，在精确步骤级归因上的准确率也仅有24%【7†source】。这表明仅凭LLM分析日志，很多情况下难以找到确切的错误步骤。而DoVer通过干预验证，不再依赖单一归因的准确率，而是通过实验结果来定位错误。因此，DoVer在错误检测的准确度上远超传统方法，在复杂任务中的优势尤为明显。
• 与Self-Refine方法的比较： Self-Refine是一种让LLM自我生成反馈并改进输出的方法，常用于提高LLM的答案质量。然而，在多智能体系统调试中，Self-Refine存在明显不足。实验结果表明，Self-Refine在DoVer的实验中未能恢复任何失败案例【7†source】。这意味着，仅靠LLM自我反思和改写输出，无法解决多智能体系统中深层次的执行错误。原因在于，Self-Refine通常只能针对最终输出进行改进，而多智能体系统的错误往往发生在交互过程的中间步骤，需要修改系统的行为而非仅修改最终输出。DoVer通过干预直接作用于执行过程，弥补了Self-Refine在这方面的缺陷。因此，在实际效果上，DoVer能够修复Self-Refine无法修复的错误，显示出更强的错误检测和修复能力。
• 与CRITIC方法的比较： CRITIC是一种让智能体互相批评和改进的方法，类似于多智能体系统内部的自我纠错机制。然而，DoVer的实验同样发现CRITIC在调试中没有成功恢复任何失败案例【7†source】。这表明，让智能体互相批评也难以触及到那些需要改变执行策略或系统设计才能解决的错误。CRITIC更多适用于表面答案或计划的改进，而对于需要“改变执行流程”的错误束手无策。DoVer通过外部干预，可以强制改变系统的执行路径，这是内部批评机制无法实现的。因此，在处理多智能体系统调试这类问题时，DoVer表现出CRITIC所不具备的深度调试能力。

• 案例1：GAIA任务中的多故障点发现。 在GAIA数据集的一个任务中，一个多智能体系统尝试通过网络搜索和操作来回答问题，但多次尝试均告失败。DoVer首先将日志划分为4个试验，每个试验都代表一次独立的尝试策略【7†source】。通过假设生成，DoVer怀疑第2个试验中的第53步是错误所在：Orchestrator在这一步给WebSurfer发送了一个无效指令（让WebSurfer点击一个不存在的按钮），而WebSurfer随后错误地点击了另一个无关元素【7†source】。针对这一假设，DoVer在第53步进行了干预：将Orchestrator的指令修改为指向正确的按钮。重新执行后，WebSurfer正确地点击了目标按钮，并在后续步骤中成功完成任务的一部分，达到了关键的里程碑。然而，任务仍未完全成功。DoVer继续分析第4个试验，发现另一个假设：如果在第1步就修改Orchestrator的计划，将原本计划的直接滚动改为通过日历导航来查找目标网页，可以绕过之前的错误。DoVer对第4步进行了干预：调整了Orchestrator的计划。结果这次干预完全成功了，系统最终找到了所需信息并完成了任务。这个案例展示了DoVer如何在一个任务中发现两个独立的故障点，并通过两次不同位置的干预修复了它们。最终，该任务从失败转为成功，验证了DoVer的多点故障检测和修复能力。
• 案例2：AssistantBench任务中的部分验证。 在AssistantBench数据集的一个任务中，系统尝试通过一系列工具调用来生成报告，但最终报告内容有误。DoVer生成了一个假设：如果在某一步骤中给负责报告生成的智能体提供额外的上下文信息，可以修正错误。干预设计是在该步骤插入一条额外的消息，告知该智能体一些之前遗漏的信息。重新执行后，任务的最终报告虽然仍不完全正确，但相比原执行，报告中的关键信息从0个提高到2个（共需要4个），取得了显著进展。DoVer将该假设标记为“部分验证”。开发人员据此进一步调整了给该智能体的上下文提供方式，最终在下一轮调试中完全修复了错误。这个案例说明了DoVer的进展度量和部分验证机制的实际意义：即使没有一次性成功，DoVer也提供了明确的改进方向，大大加速了后续人工修复的过程。
• 案例3：不确定案例带来的系统改进。 在GSMPlus数学问题求解任务中，有一个任务需要MathChat系统与外部计算工具交互来求解复杂方程。多次尝试都失败后，DoVer生成了一个假设：如果MathChat在调用计算工具前先对表达式进行简化，可能避免错误。然而，在干预执行时，MathChat本身并不支持表达式简化这一步骤，导致干预未能被正确实施，最终任务依然失败。DoVer将该假设标记为“不确定”。通过分析多个类似的“不确定”案例，开发团队发现MathChat缺少一些基本的数学变换能力。于是，他们在后续版本的系统中添加了表达式预处理模块，支持常见简化操作。这一改进使得之前许多不确定的任务变得可以解决。这个案例展示了DoVer如何将看似无果的调试尝试转化为系统层面的改进线索，体现了DoVer在错误检测之外的“发现盲点”价值。

未来展望

• 更高效的调试策略与算法优化： 虽然DoVer已经显著提升了调试效率，但在处理超大规模系统或极其复杂的任务时，仍可能面临挑战。未来的工作可以探索更高效的调试策略，以进一步缩短调试时间。例如，引入“智能搜索”算法，在庞大的假设空间中更聪明地选择优先验证的假设，从而减少不必要的实验。这可以借鉴强化学习或规划算法，让DoVer根据之前的干预结果，动态调整假设验证的顺序，优先验证那些更可能正确的假设。此外，随着多智能体系统规模的扩大，日志长度和交互复杂度也会增加，DoVer需要优化日志分段和假设生成算法，以应对更长上下文的处理。可能的改进包括：采用更先进的上下文压缩技术，使LLM能够处理超长日志；或者开发基于“增量分析”的算法，只在日志的关键片段上进行分析，从而提高效率。
• 增强的错误诊断与自动修复能力： 目前DoVer主要关注“发现并验证错误原因”，在修复方面通常采用简单的干预（如修改消息或计划）。未来的DoVer可以朝着“自动修复”的方向发展，即不仅指出错误，还能尝试生成并应用修复方案。这包括让DoVer能够修改代码逻辑、调整系统配置或添加新的工具/知识。例如，DoVer可以结合LLM的代码生成能力，自动生成修复错误所需的代码片段，并通过干预将其插入到系统中执行。如果修复成功，系统将自动采纳该修复。这种“自我修复”能力将极大提高系统的鲁棒性，使其在遇到错误时能够自主恢复。此外，DoVer还可以在验证假设的同时，学习哪些干预模式对某类错误有效，从而建立“错误-干预”知识库。当遇到类似错误时，DoVer可以直接应用已知的修复模式，实现更快的故障修复。
• 对不确定结果的处理与人类协作： 正如前文提到的，DoVer在某些情况下会将假设判定为“不确定”。未来可以引入机制来更好地处理这些不确定情况，例如让DoVer在不确定时主动寻求人工介入。通过构建“人机协同调试”的界面，当DoVer无法自行判断时，可以将相关日志和假设呈现给开发者，请求人工判断。开发者可以提供高层次的指导，比如指出某一步骤确实可疑，或者提供额外的领域知识。DoVer再根据这些反馈继续尝试验证。这种协作模式将人类的经验与DoVer的自动化能力相结合，有望解决那些单纯依赖算法难以攻克的复杂故障。同时，DoVer也可以从这些人工介入的案例中学习，不断改进自己的决策模型，在未来减少对人工的依赖。
• 框架通用性与迁移学习： 目前DoVer已经在Magnetic-One和AutoGen2等框架上成功应用【7†source】。未来，DoVer的框架通用性可以进一步提高，使其能够“即插即用”地适配更多不同的多智能体框架和平台。为此，需要定义一套标准的接口和协议，让DoVer能够方便地与各种智能体框架进行交互。例如，制定标准的日志格式、检查点接口和干预执行接口等。一旦标准建立，新框架的开发者只需按照标准提供相应接口，DoVer就可以无缝集成到该框架中，为其提供自动调试能力。此外，DoVer还可以探索“迁移学习”的方法，将从一个框架或任务上学到的调试经验，迁移到另一个框架或任务上。这意味着，DoVer在不同场景下积累的调试知识（例如哪些类型的错误常见、哪些干预策略有效）可以被共享和复用，从而在新环境中更快地发挥作用。
• 与形式化方法和符号推理的结合： 为了进一步提高调试的准确性和可靠性，DoVer可以尝试与形式化验证和符号推理等技术结合。形式化方法能够提供严格的正确性保证，但往往受限于状态空间爆炸等问题。而DoVer的干预实验为形式化验证提供了“实际执行路径”的信息，有助于缩小需要验证的状态范围。例如，DoVer可以通过干预找到一个接近正确的执行路径，然后让形式化验证器验证这条路径是否完全正确，以及如何微调即可满足要求。反过来，形式化方法可以为DoVer提供“理论指导”，例如在生成假设时，形式化分析可以指出某些步骤在逻辑上必然有问题，从而引导DoVer优先验证这些假设。这种“经验+理论”的融合，有望提升DoVer在复杂、关键系统（如金融交易系统、自动驾驶系统）中的应用信心。
• 多智能体系统的持续学习与自适应： DoVer的最终愿景之一是实现多智能体系统的“自适应调试”和“持续进化”。这意味着系统在运行过程中，能够利用DoVer不断发现和修复自身的问题，从而越用越聪明。例如，一个部署在云端的大型多智能体系统，可以持续收集运行日志，DoVer在后台对这些日志进行离线分析和调试。当发现某些错误反复出现时，DoVer可以自动尝试修改系统的策略或参数，并通过A/B测试验证修改的有效性。如果有效，系统将自动更新自身的模型或配置，从而实现“自我进化”。这种机制将使多智能体系统具备类似“免疫系统”的能力，在遇到新错误时能够快速适应和恢复，大幅提高系统的长期稳定性。