通过基于 LLM 的多代理协同的统一调试方法：验证修复

仅当代理留下在其自己的对话中幸存的证据时，通过基于 LLM 的多代理协同的统一调试方法才有用。定位器听起来很确定，修复代理可以发出补丁，审核人员可以批准它，而原始故障从未重现或决定性的边界情况从未被测试过。因此，合理的默认设置是：让专业代理提出并质疑修复，但只有在相互关联的修复证据收据证明故障复现、证据谱系、测试覆盖范围、测试预期结果判定依据的质量和审查后才推广并采用修复补丁。 该操作规则遵循 FixAgent 论文 的架构，不会将研究结果与生产保证混淆。该论文将故障定位、补丁生成和错误后分析跨专业代理分开。它还区分了通过可用测试的“合理”补丁和通过手动验证建立的“正确”补丁。这种区别就是健康边界。 FixAgent 结果证明了什么——以及没有证明什么 FixAgent公布的设计比“请几个模型调试”更具体。其方法 使用定位器、修复器和重访器，以及用于附加测试的输入制作代理。代理解释他们的推理，跟踪重要变量，并将前期结果传递给下游。如果生成的补丁失败，可以再次对修复阶段进行采样并提供测试反馈。 该论文报告了 QuixBugs、Codeflaws 和 ConDefects 的强劲结果。这些是论文数据集、模型、提示和验证程序下的研究结果。他们没有确定任意代码仓库中的修复补丁可以安全地合并。主要来源的两个细节改变了运营决策： 1. 论文将合理的补丁定义为通过人工编写的测试的补丁，而正确性则需要单独的手动验证。 2.其限制部分表示额外的测试输入代理无法自行计算预期输出。没有可靠的测试预期结果判定依据的生成输入不能构成一项完整且可信的测试验证。 发布的 Rudra 实现 使边界能够被独立检查和验证。其多轮运行程序将零观察到的故障案例视为成功修复，并将该标志返回给启动器。这适用于实验的测试循环。操作员仍然需要询问哪些套件运行了，它们采用的测试预期结果判定依据是否值得信赖，结果是否属于这个具体的修复补丁，以及审阅者是否接受了实际的差异。 我们的教训并不是代理审查毫无用处。专家的分歧可能会暴露出糟糕的本地化或证据薄弱的修复补丁。教训是，一个代理生成的文本不能成为下一个代理所使用的唯一证据材料。 将每个调试阶段与修复证据收据链接起来 最低限度的修复证据收据可以是无内容的。它不需要提示、源代码、测试输出或模型推理。它需要稳定的身份和判决，让人类或确定性的自动验证门禁重建边界： 边界 最小收据字段 它捕获失败 --- --- --- 故障复现 运行 ID、命令哈希、观察到的原始故障 针对从未成功复现的错误所生成的修复补丁 本地化 运行 ID、源版本、证据材料的记录时间戳 从另一个版本重用的定位器结果 补丁 修复补丁的内容哈希、父版本、更改行计数 内容为空、已经过时或与当前问题无关的修复 验证 所需的套件 ID、观察到的套件 ID、失败计数 当所需的套件从未运行时“所有测试都通过” 测试预期结果判定依据 已验证、未知或有争议 生成的案例没有值得信赖的预期结果 审查 批准、拒绝或有明确责任人的等待状态 把模型共识误认为合并授权 结果 完成索赔和目的地收据 已完成的运行，其补丁未经验证或交付 运行 ID 尤其重要。来自 run-old 的本地化答案不得默默地证明来自 run-42 的补丁是合理的。修复补丁的内容哈希同样重要：一个差异的显示绿色通过状态的测试验证记录不能附加到以后的重新采样。这是普通的沿袭，但代理工作流程经常会丢失它，因为对话上下文使附近的消息看起来相关。 以下是随附夹具所使用的形状： 这些字符串是标识符，而不是存储的内容。在真实的系统中，应该根据规范的输入和工件计算哈希值，并且测试记录应包括工具版本、配置修订、开始时间、完成时间和退出来源。秘密、提示、文件内容和原始工具参数应保留在健康收据之外。 在信任绿色之前重播九个不方便的状态 该文章工件包含九个合成案例和一个按优先顺序排列的 Node.js 分类器。从文章报告目录运行它： 观察到的结果是： 这些案例故意造成不便： - UNREPRODUCED 在可信补丁可以隐藏丢失的基线之前停止工作流程。 - LOCALIZATION DRIFT 捕获来自不同运行的定位器收据。 - NO EFFECTIVE PATCH 拒绝丢失哈希或零行更改。 - TEST GAP 报告所需的集成套件从未运行过，即使观察到的测试套件显示绿色通过状态也是如此。 - ORACLE UNCERTAIN 当生成的输入没有经过验证的预期输出时保留不确定性。 - REVIEW REJECTED 阻止技术上的处于绿色通过状态的修复补丁成为已批准的补丁。 - WAITING 仅当收据指定所有者和截止日期时才表示合法依赖关系。 - 当任何观察到的测试仍然失败时， FALSE COMPLETE 优于关于任务已经完成的声明。 - VERIFIED REPAIR 要求所有先前的边界都一致。 顺序很重要。关于任务已经完成的声明不能推翻失败的测试。零故障计数器不能覆盖丢失的套件。如果没有可信的测试预期结果判定依据，生成的边界情况就无法确定正确性。当审查等待有所有者和截止日期时，不应将其归类为拖延。 该实验还说明了为什么单个单一的健康运行状况评分是一个糟糕的调试工件。 suite-gap 和 verified-repair 案例均报告零失败测试，​​但它们的操作状态有所不同，因为从未运行过所需的集成套件。缺失的证据材料比显示绿色通过状态的计数器更重要。 将门添加到真实的编码代理工作流程中 从一个小的修复补丁的推广边界开始，而不是重建代理框架： 1. 冻结输入修订版。 在本地化之前记录存储库提交或工作区快照。 2. 重现失败。 存储命令/配置哈希和结构化结果。如果故障复现过程不稳定，请将其标记为不确定，并且不要将最终的显示绿色通过状态的执行运行视为修复的证据。 3. 链接每次交接。 要求本地化人员、修复代理和审阅人员收据引用相同的运行和父版本。 4. 绑定重采样。 FixAgent 论文的反馈循环很有用，但重试会消耗预算并且可能会更改补丁。为每个新补丁提供自己的哈希值、上限尝试，并在差异更改时使先前产生的测试验证证据材料失效。 5. 在执行之前声明所需的套件。 否则，代理可以在看到结果后重新定义“所有测试”。 6. 将测试执行与测试预期结果判定依据的权威性分开。 生成的输入可以提高覆盖范围，但人员、规范、参考实现或独立的确定性规则必须提供预期结果。 7. 保持合并或部署权限由人控制。 批准的收据可以准备决策；它不应扩大代理人的许可范围。 8. 验证目标。 如果任务是打开拉取请求、更新问题或生成发布工件，请独立验证该目标。本地生成修复补丁只代表发生了一种执行活动，但不一定代表已经产生用户请求的最终结果。 对于批准暂停，请使用显式记录： 不要仅仅因为该记录有效时代理保持安静而寻呼。当截止日期到期、所有者失踪或恢复运行没有产生新证据时升级。等待并不等于陷入卡住状态；没有结果增量的重复活动并不能证明工作取得了有用进展。 Sidewisp 的边界 可支持的论点很狭窄：当专家输出与能够由确定性检查验证的修复证据材料相结合时，多代理调试在操作上变得值得信赖，而当证据谱系、测试覆盖范围、测试预期结果判定依据的质量、审查或结果证据缺失时，绿色就会被保留。九案例夹具证伪了“没有观察到故障就意味着修复已经得到验证”这一错误捷径，因为两个零故障案例得出了不同的结论。 这是一种操作模式，而不是声称 Sidewisp 当前运行 FixAgent 或监视编码代理修复。 Sidewisp 目前处于私密预览阶段。 它是一个AI-agent健康平台，但生产监控引擎、运行时适配器和恢复执行器目前尚未得到普遍交付。预期的健康层在这里是相关的，因为它区分有用的进展、合法的等待、错误的完成和不确定的证据，同时将合并权限留给人类。 首先在重复调试工作流程中使用收据。如果它在不阅读文字记录的情况下无法区分丢失的套件和已验证的修复，那么证据契约仍然太弱。