多轮审计收敛:复杂 AI 工程任务的覆盖状态判断与递归控制

摘要

大模型及其 Agent 已经能够处理部分真实的软件工程任务,但一次执行成功仍不足以证明具体结果已经达到可交付、可依赖的程度。前置研究提出 SCR(Search Space–Coverage Capability–Delivery Reliability Relationship,即“搜索空间—覆盖能力—交付可靠性关系”),指出交付可靠性取决于完整 AI 开发系统的覆盖能力与任务搜索空间的匹配程度。然而,这一匹配关系不能被直接观察,工程系统需要从执行与验证过程中获得判断依据。 本文首先分析执行、独立审计与修复之间的关系。执行形成候选结果后,独立审计可以围绕具体对象寻找遗漏、冲突和验证缺口,在比原始生成任务更受约束的问题范围内工作;问题修复后,下一轮审计面对更新后的工程对象。因此,执行、审计与修复并非对同一问题的简单重复,而是让有限覆盖能力分阶段作用于不同问题,使完整系统有可能处理部分超出单次执行稳定覆盖范围的任务。 在此基础上,本文提出多轮审计收敛(Multi-Round Audit Convergence,MRAC)。每轮审计产生当前工程对象上的问题发现;连续的审计、修复和再审计进一步形成关于新增问题数量、严重度和类型变化的轨迹。MRAC 对这一多轮问题轨迹进行二阶观测:新的重要问题总体减少并逐步稳定时,轨迹表现为收敛;持续修复后仍不断出现新的重要问题时,轨迹表现为不收敛。多轮的意义不在于简单增加审计次数,而在于形成这一二阶观测对象。 MRAC 直接得到的是问题轨迹。结合 SCR,在任务边界、审计协议和验证条件具有可比性,且后续审计仍对剩余重要问题保持有效发现能力时,收敛可以作为“当前覆盖能力足以稳定处理该任务”的正面过程证据,但不能证明结果绝对正确,也不能排除共同盲区;持续不收敛则更直接地说明当前系统尚未表现出稳定处理该任务的能力。因此,两类证据并不对称:不收敛是较强的负面证据,收敛则依赖审计持续有效这一附加条件。 截至本文数据截点,当前项目的 MRAC 观察记录覆盖 35 个任务或拆分后的子任务,其中 33 个已经达到项目采用的收敛条件、完成验证并合入主线,2 个仍在进行中。另有 3 个父任务在原边界下持续不收敛后触发拆分,共形成 10 个子任务;这些子任务均达到收敛条件并完成验证,3 个父任务随后关闭。当前记录中尚未出现拆分后因子任务持续无法收敛而不能完成闭环的案例。上述小样本不能证明任意工程任务均可通过递归拆分达到收敛,也不能单独证明真实交付可靠性同步提高,但表明“不收敛—拆分—重新收敛”的过程已经在多个真实工程任务中重复出现。 本文据此将 MRAC 定位为 SCR 基础关系之上的一种搜索空间覆盖判断与任务调整机制。不同层级命题的证据要求与外推范围留待后续 MRAC L1–L5 研究讨论。