AGI 理论 / v1.1

多轮审计收敛：面向工程 AGI 的外部验证机制与递归任务闭环

提出多轮审计收敛（MRAC）作为二阶验证信号，并以不收敛触发任务拆分，构建面向工程 AGI 的递归任务闭环。

2026-08-05 2026-08-05
工程 AGI多轮审计收敛MRAC

作者：刘明
日期：2026 年 8 月 5 日

本文同时提供英文翻译版本；如中英文表述存在理解差异，以中文原始版本为准。

摘要

当前大模型已经能够完成大量软件工程任务，但仍难以在长期复杂项目中稳定判断自己的结果是否可信。一次执行成功或一次审计未发现问题，都不足以区分“结果已经可靠”与“当前审计暂时未覆盖到错误”。本文提出多轮审计收敛（Multi-Round Audit Convergence，MRAC）：对同一工程对象持续执行审计、修复和再审计，并观察新增有效问题的数量、严重程度与结构性是否总体下降，最终在预定审计覆盖条件下连续多轮保持稳定。

本文将 MRAC 解释为一种二阶验证信号。它不直接证明工程结果绝对正确，而是为判断当前任务、Spec 或 PR 是否已经进入给定模型、工具、上下文和审计协议能够稳定覆盖的有效搜索空间提供证据。当审计结果持续不收敛时，系统不应在原任务边界内无限追加局部修补，而应停止当前任务并返回任务拆分阶段，缩小搜索空间后重新开始。由此可以形成“任务拆分—Spec 审计—执行—PR 审计—合入”的递归任务闭环。

本文基于两个内部软件工程案例给出初步观察：一个 Spec 在多轮审计中持续出现新的 P1、P2 问题，最终停止原任务并进一步拆分；另一个任务的 Spec 与 PR 分别在连续多轮无新增实质问题后进入下一阶段。本文进一步提出一个工程假说：如果复杂软件项目能够被递归拆分为 AI 可稳定覆盖的子问题，并且任务依赖、状态、模块边界、审计与回退机制能够被系统治理，那么 MRAC 可能成为工程 AGI 外部工程化路线中的关键验证机制。该假说目前尚未经过完整项目、多模型和对照实验验证。

关键词： 多轮审计收敛；工程 AGI；自主软件工程；搜索空间治理；任务拆分；Spec；代码审查；Agent Harness

1. 引言

1.1 工程 AGI 的工程化定义

本文采用一个强调长期复杂项目交付的工程化定义：

工程 AGI，是指 AI 能够无人化完成原本需要普通人类团队长期协作的复杂项目。

本文所说的“无人化”，主要指项目推进不再依赖人类持续进行任务拆分、过程追踪、错误定位和局部修复；它不排斥人类提供初始工程目标、产品意图、权限授权，以及当前系统尚不能独立完成的高代价取舍。

本文首先聚焦软件工程。原因不是软件工程能够代表全部人类复杂工作，而是代码、Spec、PR、测试、日志和版本历史提供了相对完整的工程对象、证据链和回退条件，使外部验证机制更容易被定义和检验。

通往工程 AGI 至少存在两类并不互斥的路线：

  1. 模型内部能力路线：继续扩大模型的知识、推理、有效注意力和自我纠错能力，直到模型能够直接完成长期复杂项目，并可靠发现自己的错误；
  2. 模型外部工程化路线：在模型外建立任务拆分、状态管理、审计、回退和交付机制，使仍会犯错的 AI 也能够持续推进复杂工程。

本文不把多轮审计收敛视为外部工程系统的全部，而提出以下研究假说：

MRAC 可能是使外部工程化路线形成可运行闭环的关键验证机制之一。

1.2 AI 无人化工程的核心困难

当前大模型可以理解代码、设计方案、实现功能、补充测试，并修复已经明确的问题。在局部任务上，它们已经能够承担相当比例的实际工程工作。

长期无人化工程面对的关键困难并不只是“AI 是否会做”，而是：

AI 无法稳定判断自己什么时候犯了错，也无法可靠区分“结果已经正确”与“当前尚未发现错误”。

具体而言，AI 可能：

  • 遗漏未被显式写入上下文的需求约束；
  • 在局部合理的情况下误判系统边界；
  • 选择短期可运行但会积累结构债的方案；
  • 在测试覆盖不足时把局部通过误判为完整交付；
  • 修复一个问题后引入新的失败路径；
  • 因审计视角或上下文相似而反复共享同一盲区。

因此，工程 AGI 所需要的并不只是一个错误率更低的执行器，还需要一个外部机制持续回答：

  1. 当前工程对象是否仍存在未被发现的重要问题？
  2. 当前任务是否已经处于 AI 与审计机制能够稳定处理的范围？
  3. 当当前范围不可稳定处理时，系统是否应该停止原任务，并返回任务拆分阶段进一步缩小搜索空间？

1.3 本文的三层主张

为避免把初步案例、机制解释和远期推论混为一体，本文将主张分为三个层级。

第一层：已观察到的工程现象

在本文记录的内部项目中，一部分 Spec 或 PR 在审计和修复后表现为新增问题减少，并连续多轮未发现新的实质问题；另一部分 Spec 在多轮审计中持续暴露新的中高严重度问题，没有形成稳定下降趋势。

第二层：本文提出的机制解释

本文提出，审计结果的收敛与否可以被视为一种二阶证据信号，用来辅助判断当前工程对象是否已经进入给定模型和审计协议能够稳定覆盖的有效搜索空间。

这是一种机制性解释，而不是已经被充分验证的因果定律。收敛还可能由审计器能力不足、审计协议过窄或重复轮次共享盲区造成；不收敛也可能来自约束持续变化、审计范围变化或修复引入新问题。

第三层：面向工程 AGI 的研究假说

如果 MRAC 能够稳定应用于任务拆分、Spec 和 PR 等关键工程固化点，并与依赖治理、状态管理、回退和并行执行系统结合，那么复杂项目可能被递归转化为一系列 AI 可稳定覆盖的小任务，从而支持较少人工推动的长期自主交付。

本文的两个案例只能为前两层提供初步证据，尚不能单独证明第三层假说成立。

1.4 本文贡献

本文的主要贡献包括：

  1. 正式定义多轮审计收敛（MRAC），并把它与单轮审计、固定轮数修订和一般质量保证停止条件区分开来；
  2. 将审计结果的变化趋势解释为一种二阶验证信号，用于辅助判断当前工程对象是否处于可稳定覆盖的搜索空间；
  3. 将不收敛纳入工程控制逻辑，使其能够触发任务回退与进一步拆分，而不是在原边界内无限追加修补；
  4. 将 MRAC 应用于任务拆分、Spec 和 PR 等关键固化点，提出“收敛则推进，不收敛则返回任务拆分”的递归任务闭环；
  5. 给出两个来自实际项目的初步案例，并明确当前证据的适用边界和后续验证要求。

2. 概念模型

2.1 有效搜索空间

一个工程任务通常同时包含多类不确定性：

  • 需求可能存在多种解释；
  • 实现方案可能存在多条路径；
  • 修改可能影响多个模块和隐含依赖；
  • 项目历史可能形成未被文档化的约束；
  • 一个局部修复可能改变后续问题分布。

本文把 AI 为完成当前工程对象而必须考虑、排除或选择的有效可能性集合，概括为该任务的有效搜索空间（Effective Search Space）。

这里的“搜索空间”不是一个已经可以精确枚举的数学集合，而是一个工程抽象，用来描述需求歧义、方案分支、依赖范围、失败路径和隐含约束共同造成的决策复杂度。

2.2 可稳定覆盖的搜索空间

给定模型并不存在脱离工程环境的固定任务上限。模型在一次任务中能够稳定处理的范围，还取决于：

  • 模型本身的推理与知识能力；
  • 有效注意力与上下文利用情况；
  • 可用工具和代码检索能力；
  • 项目结构与模块边界；
  • 测试、日志和静态检查所提供的外部反馈；
  • Spec 的完整度与约束显式化程度；
  • 审计提示、审计视角和轮次间差异。

因此，本文使用**可稳定覆盖的搜索空间（Reliably Coverable Search Space）**表示：在给定模型、工具、上下文、工程环境和审计协议下，AI 能够以足够稳定的方式完成、审计和修复的任务范围。

任务能否可靠推进，取决于一个相对关系：

当前工程对象的有效搜索空间，是否已经被治理到不超过当前 AI 系统的稳定覆盖能力。

这一关系不能被直接观察。MRAC 的意义，正是尝试从多轮审计结果中获得关于这一潜在状态的间接证据。

2.3 为什么审计可能缩小搜索问题

首次实现一个任务时，AI 通常需要同时完成：

  • 需求理解；
  • 方案选择；
  • 代码定位；
  • 实现；
  • 测试设计；
  • 兼容性与回归判断。

这是一个相对开放的生成过程。

当一个 Spec、设计或 PR 已经存在时，审计目标可以被限定为：

  • 是否遗漏需求；
  • 边界是否合理；
  • 是否存在未处理的失败路径；
  • 实现是否违反已有约束；
  • 测试是否覆盖目标行为；
  • 是否引入新的结构问题。

在目标对象固定、上下文充分且审计协议有效的条件下，审计通常把开放生成问题转化为范围更明确的缺陷搜索问题。它不保证搜索空间一定更小，也不保证审计器不会共享生成器的盲区，但在许多工程情形下，可以降低单轮需要同时处理的决策复杂度。

因此，一个不能一次完成高质量交付的 AI，仍可能通过以下循环逐步提高结果质量：

  1. 生成一个初步成立的工程对象；
  2. 在相对受限的审计空间中发现问题；
  3. 修复已明确的问题；
  4. 对修改后的对象重新进行全范围审计。

3. 多轮审计收敛

3.1 定义

多轮审计收敛（Multi-Round Audit Convergence，MRAC）：对同一工程对象持续执行审计、修复和再审计时，新增有效问题的数量、严重程度和结构性总体下降，并在预定审计覆盖条件下连续多轮保持稳定的现象与判定机制。

MRAC 包含两个部分：

  • 现象层：审计结果是否表现出总体下降并进入稳定状态；
  • 控制层：系统如何依据收敛或不收敛决定继续推进，或回退到任务拆分阶段缩小搜索空间。

3.2 MRAC 不证明什么

MRAC 不证明工程结果绝对正确，也不等价于形式化验证。

当一个工程对象表现为收敛时，本文只主张：

在给定模型、工具、上下文、审计方法和项目条件下，当前对象已经表现出进入可稳定覆盖搜索空间的迹象。

它仍可能存在：

  • 所有审计轮次共同遗漏的问题；
  • 审计协议未覆盖的失败模式；
  • 只有运行时、真实用户或长时间运行才能暴露的问题；
  • 产品意图或跨模态约束没有进入工程对象的问题；
  • 测试和验证器自身错误导致的假稳定。

因此，MRAC 应被理解为工程证据的一部分，而不是替代测试、运行时验证、人工产品判断或安全审查的万能判据。

3.3 为什么需要多轮而不是单轮

单轮审计没有发现问题，至少存在三种不同解释：

  1. 当前结果已经足够可靠；
  2. 本轮审计路径没有覆盖到仍然存在的问题；
  3. 审计协议、上下文或模型能力不足以发现问题。

单轮结果无法区分这三种状态。

多轮审计额外提供了变化趋势：

  • 新问题数量是否总体减少；
  • 严重度是否下降；
  • 结构性问题是否仍在反复出现；
  • 修复后是否持续暴露新的失败路径；
  • 不同审计视角下是否保持稳定；
  • 连续干净轮次是否能够复现。

因此，多轮审计产生的不只是更多缺陷列表，还产生了一个关于审计过程自身的二阶信号。

3.4 收敛的操作化判断

当前阶段，MRAC 不宜被简化为单一固定公式。一个可执行的判断至少应综合以下维度：

维度需要观察的问题
新增问题数量是否总体下降，还是持续出现大量新问题
问题严重度是否从阻塞性、结构性问题转向低严重度细节
问题结构是否持续出现新的问题类别或根本性边界冲突
连续稳定性是否连续多轮无新增实质问题，而非偶然出现一次干净轮次
审计覆盖后续轮次是否仍保持全范围或预定范围，而非逐步缩窄到无问题
轮次有效性是否排除工具失败、上下文缺失或输出异常造成的无效轮次

本文案例采用“连续多轮无新增实质问题”作为实用信号。为了与已有研究建议保持一致，后续实验的最低默认停止规则可以设为：

在锁定审计协议和审计范围后，连续两次全范围审计无新增实质问题。

但“两次”不应被理解为对所有任务都充分。更严格的停止条件还应结合任务规模、问题严重度、审计器差异、运行时测试和风险等级确定。

3.5 不收敛的含义

如果多轮审计后仍持续出现新的 P1、P2 或结构性问题，至少说明当前对象尚未表现出稳定覆盖。

可能原因包括：

  • 任务规模过大；
  • 任务边界或模块边界错误；
  • Spec 中存在根本方案冲突；
  • 关键约束没有显式化；
  • 审计范围或审计协议持续变化；
  • 修复不断引入新的缺陷；
  • 当前模型、工具或上下文能力不足；
  • 审计器随机性造成较高方差。

因此，不收敛不应机械地等同于“任务一定过大”；它首先表示当前工程对象尚未表现出可稳定覆盖。对运行系统而言，控制逻辑应保持简单：

  1. 在预先锁定的有效审计条件下持续执行审计、修复和再审计；
  2. 达到收敛条件则进入下一阶段；
  3. 达到预定不收敛条件则停止原任务，返回任务拆分阶段，缩小搜索空间后重新开始。

审计协议是否充分、约束是否完整，属于系统设计和实验有效性问题，应在运行前被固化并通过后续研究验证，而不作为主流程中依赖人工介入的动态分支。

在该控制逻辑中，不收敛不是流程失败，而是一种自动触发搜索空间重新治理的有效结果。

4. 递归任务治理闭环

4.1 为什么审计关键固化点

实际工程系统没有必要独立审计每一个中间思考步骤。更可行的方式，是审计少量能够固化工程状态、影响后续搜索空间的关键对象：

  • 任务拆分结果：决定后续任务边界、依赖和并行关系；
  • Spec：固化需求、方案、约束和验收条件；
  • PR：固化实际实现、测试和代码变更结果。

当这些关键对象必须达到预定收敛条件后才能进入下一阶段时，节点之间的大量局部决策可以通过后续固化点得到间接检查。

4.2 基本流程

%%{init: {"theme":"base","themeVariables":{"fontFamily":"Noto Sans SC, Microsoft YaHei, PingFang SC, sans-serif","fontSize":"17px","lineColor":"#64748B","textColor":"#0F172A","primaryColor":"#FFFFFF","primaryTextColor":"#0F172A","primaryBorderColor":"#94A3B8"},"flowchart":{"curve":"basis","nodeSpacing":34,"rankSpacing":42,"htmlLabels":false,"useMaxWidth":true}}}%%
flowchart TB
    accTitle: MRAC 递归任务治理闭环
    accDescr: 工程目标经过任务拆分、Spec 多轮审计、任务执行、PR 多轮审计和主线合入；Spec 或 PR 不收敛，以及工程目标尚未完成时，系统继续进行任务拆分。

    A(["工程目标"]) --> B["任务拆分"]
    B --> C["生成任务 Spec"]
    C --> D["Spec MRAC：审计—修复—再审计"]
    D --> E{"Spec 收敛？"}

    E -- "是" --> F["执行任务并提交 PR"]
    F --> G["PR MRAC：审计—修复—再审计"]
    G --> H{"PR 收敛？"}

    H -- "是" --> I["合入主线"]
    I --> J{"工程目标完成？"}
    J -- "是" --> K(["完成交付"])

    E -- "否" --> R["继续任务拆分"]
    H -- "否" --> R
    J -- "否" --> R
    R -.-> B

    classDef terminal fill:#0F172A,color:#FFFFFF,stroke:#0F172A,stroke-width:1.5px;
    classDef process fill:#FFFFFF,color:#0F172A,stroke:#94A3B8,stroke-width:1.25px;
    classDef artifact fill:#F8FAFC,color:#334155,stroke:#CBD5E1,stroke-width:1.25px;
    classDef audit fill:#EFF6FF,color:#1E3A8A,stroke:#3B82F6,stroke-width:1.5px;
    classDef decision fill:#FFF7ED,color:#9A3412,stroke:#F97316,stroke-width:1.5px;
    classDef delivery fill:#F0FDF4,color:#166534,stroke:#22C55E,stroke-width:1.5px;
    classDef recycle fill:#F8FAFC,color:#334155,stroke:#64748B,stroke-width:1.25px,stroke-dasharray:5 3;

    class A,K terminal;
    class B,F process;
    class C artifact;
    class D,G audit;
    class E,H,J decision;
    class I delivery;
    class R recycle;

    linkStyle 13 stroke:#64748B,stroke-width:1.5px,stroke-dasharray:6 4;

整个流程可以压缩为：

任务拆分 → Spec 多轮审计 → 执行 → PR 多轮审计 → 合入。

其中：

  • Spec 收敛后才进入执行；
  • Spec 不收敛时，停止原任务并返回任务拆分阶段；
  • PR 审计在当前任务边界内执行审计、修复和再审计；达到预定不收敛条件后，同样返回任务拆分阶段；
  • PR 收敛并通过其他必要验证后才允许合入；
  • 项目目标未完成时，系统继续拆分和执行剩余目标。

图中的纵向主干表示向前交付；“继续任务拆分”节点汇总三类递归条件：Spec 不收敛、PR 不收敛，以及工程目标尚未完成。虚线表示系统返回任务拆分阶段。主流程不包含依赖人工临时介入的运行分支。

4.3 递归拆分的作用

如果一个任务超出当前 AI 系统的稳定覆盖能力，直接增加执行轮次不一定能够解决问题。递归拆分的作用，是把一个较大的有效搜索空间转换为多个边界更明确、依赖可治理的小搜索空间。

在理想情况下，每个子任务都满足：

  • 具有明确的功能交付；
  • 依赖关系可描述；
  • 可以独立形成 Spec；
  • 可以独立执行和审计；
  • 可以回退；
  • 合入后不会破坏总体模块边界。

因此，MRAC 不只是一个“审计到什么时候停止”的质量控制方法。它还可能承担任务尺度判断和递归治理信号的作用。

5. 初步项目案例

5.1 数据性质与解释限制

以下案例来自作者实际软件项目的内部审计记录，目前尚未公开完整仓库、审计提示、模型版本、上下文加载过程、问题分级规则和全部修复证据。因此，它们适合作为机制的初步观察和案例说明，不构成独立可复现的实证证明。

表中的 P1、P2 为项目内部严重度标签。由于本版本尚未给出完整的严重度操作化定义，本文不对其跨项目可比性作出主张。

标记为“本轮结果废弃”的轮次不计入有效审计结果；具体废弃标准应在后续公开实验协议中明确。

5.2 案例一：Spec 持续不收敛并触发拆分

任务：A5PR1 退出顺序单一化

审计轮次新发现问题
R2P1 × 2，P2 × 1
R3无
R4P1 × 1，P2 × 2
R5P2 × 3
R6P2 × 2
R7P1 × 1，P2 × 1
R8P1 × 1，P2 × 1
R9本轮结果废弃
R10P1 × 1
R11P1 × 2，P2 × 2
R12P1 × 1，P2 × 2
R13P1 × 2，P2 × 1
R14P2 × 2

这个 Spec 在 R3 出现过一次无新增问题，但后续轮次持续发现 P1、P2 问题。直到 R14，新增问题仍没有形成可解释的稳定下降趋势。

这个记录至少支持两个判断：

  1. 一次无新增问题不足以作为收敛证据；
  2. 在当前审计条件下，该 Spec 没有表现出被稳定覆盖。

项目随后停止在原 Spec 内继续追加修补，将任务进一步拆分。根据项目记录，拆分后的子任务分别重新完成了 Spec 审计、执行和合入。

该案例与 MRAC 控制逻辑一致：

当有效轮次持续出现新的中高严重度问题时，应停止把单轮干净结果解释为完成，并重新治理当前搜索空间。

但仅依据该案例，尚不能排除审计协议变化、模型随机性或修复引入新问题等其他解释。

5.3 案例二：Spec 与 PR 分别表现出收敛

任务：B2PR-01 Stage 失效表面退役

5.3.1 Spec 审计记录

审计轮次新发现问题
R1P1 × 2，P2 × 2
R2P1 × 1，P2 × 1
R3无
R4本轮结果废弃
R5无
R6P1 × 1
R7无
R8无

R1、R2 的新增问题数下降，R3 暂时没有发现新问题。但 R6 又发现一个 P1，说明一次甚至间隔出现的干净轮次仍不足以稳定确认收敛。

在修复 R6 问题后，R7、R8 连续两轮没有发现新问题，项目据此判断 Spec 达到实用收敛条件并进入执行阶段。

5.3.2 PR 审计记录

审计轮次新发现问题
R1P2 × 1
R2P2 × 1
R3无
R4本轮结果废弃
R5无
R6无

PR 前两轮分别发现一个 P2。修复后，后续有效审计没有再发现新问题，PR 被判断为收敛并完成合入。

5.4 两个案例能够支持的有限结论

在不超出当前证据范围的前提下，两个案例共同支持以下初步观察：

  • 单轮无新增问题不应被直接解释为收敛；
  • 问题数量和严重度的多轮变化比单轮结果提供了更多信息；
  • 持续出现新的 P1、P2 问题，可以作为当前工程对象尚未稳定覆盖的警告信号；
  • 连续多轮无新增实质问题，可以作为进入下一阶段的实用信号之一；
  • 不收敛可以触发任务拆分，而不只是继续在原对象内无限修补。

这些案例尚不能证明：

  • MRAC 一定提高最终运行质量；
  • 两次连续干净审计对所有任务都充分；
  • 不收敛一定由任务过大导致；
  • 同一模型的多轮审计等价于独立搜索；
  • 该机制已经能够覆盖完整大型项目。

6. 与已有工作的关系

6.1 Iterative Audit Convergence 研究

Elias Calboreanu 于 2026 年 5 月 12 日提交 arXiv 预印本，并于 2026 年 6 月 18 日在 Software 正式发表论文 Iterative Audit Convergence in LLM-Managed Multi-Agent Systems: A Case Study in Prompt-Engineering Quality Assurance。[1]

该研究对 AEGIS 多智能体编排系统的提示规范进行了案例研究。被审计对象由八份文档、共 7152 行规范组成；九轮审计共发现 51 个一致性缺陷，每轮发现数为：

15、8、12、2、8、1、4、1、0。

该研究记录了非单调的收敛过程，并把案例中的停止规则设为一次全范围审计无新增问题。论文同时建议后续复现实验使用更严格的“连续两次全范围审计无新增问题”规则。

该论文明确限制了结论范围：审计收敛只能说明在锁定协议覆盖下的内部一致性，不能证明绝对正确，也没有测量修复是否改善运行时行为。研究对象是单一系统，审计协议在案例过程中发生了演化，同一模型家族参与了规范编写和审计；作者因此要求后续进行多系统、单轮全范围对照和人工复核验证。[1]

6.2 Automated Plan Reviser Pro

开源项目 Automated Plan Reviser Pro（APR）将复杂 Spec 进行多轮 AI 修订，并保存轮次历史。其收敛分析使用三个加权信号：

  • 输出规模趋势：35%；
  • 修改速度：35%；
  • 相邻轮次内容相似度趋势：30%。

APR 由此生成一个用于估计规范稳定程度的收敛分数。[2]

APR 证明了“对 Spec 进行多轮修订并量化稳定趋势”已经进入公开工程实践。不过，输出变短、修改变慢和文本变得相似，主要测量的是文档变化稳定性；它们不能直接证明问题严重度下降、工程约束被覆盖或任务已经进入可稳定覆盖的搜索空间。

6.3 本文与已有工作的差异

本文不主张首次发现“反复审计或修订可能趋于稳定”这一基础现象，也不把精确术语的首次使用作为本文成立的必要条件。

本文试图推进的部分是：

  1. 把多轮审计结果解释为当前工程对象是否进入可稳定覆盖搜索空间的二阶证据；
  2. 把不收敛从一个质量流程异常，转化为任务边界和搜索空间需要重新治理的信号；
  3. 把 MRAC 应用于任务拆分、Spec 和 PR 等关键工程固化点；
  4. 形成“收敛则推进，不收敛则返回任务拆分”的递归任务治理闭环；
  5. 将这一闭环提出为工程 AGI 外部工程化路线的候选核心机制。

与 Calboreanu 的研究相比，本文的重点不只是描述一个提示规范系统中的审计曲线，而是讨论收敛性如何参与任务尺度判断和长期工程控制。与 APR 相比，本文关注的也不只是 Spec 文本的稳定程度，而是新增有效问题的数量、严重度和结构变化，以及不收敛对任务治理的含义。

7. 面向工程 AGI 的研究假说

7.1 从局部任务到长期项目

假设一个复杂软件工程目标能够被拆分为一组具有明确边界和依赖关系的子任务，并且每个子任务都能形成可审计的 Spec 与 PR，那么系统可以递归执行：

  1. 将剩余工程目标拆分为任务；
  2. 审计任务边界和 Spec；
  3. Spec 不收敛则停止原任务并继续拆分；
  4. Spec 收敛后执行任务；
  5. 审计实现后的 PR；
  6. PR 达到预定不收敛条件时，停止原任务并返回任务拆分阶段；
  7. PR 收敛并通过其他验证后合入；
  8. 继续处理剩余工程目标。

在这一系统中，AI 不需要一次性跨越完整项目的全部搜索空间。系统只需要：

  • 发现当前边界没有被稳定覆盖；
  • 把问题递归缩小到局部范围；
  • 在局部范围内执行、审计和修复；
  • 保存状态、依赖、证据和回退点。

7.2 为什么它可能降低对完美模型的要求

等待模型单独实现工程 AGI，意味着模型不仅要完成长期复杂任务，还要稳定判断自己是否已经正确，并在长时间运行中管理状态、依赖和错误恢复。

外部工程化路线降低了这一要求。它不要求模型永远不犯错，而要求模型在经过治理的局部搜索空间中，具备三类能力：

  1. 完成边界明确的任务；
  2. 在受限审计范围内发现一部分尚未解决的问题；
  3. 修复已经被明确指出的问题。

本文的项目实践只能说明当前模型在部分任务中已经表现出这三类能力，不能据此断言其已经覆盖大多数软件工程问题。

7.3 成立所需的关键条件

MRAC 通向工程 AGI 的假说至少依赖以下条件：

  • 复杂项目可以被递归拆分为可治理的工程对象；
  • 模块边界和任务依赖不会因拆分而失控；
  • 审计器能够以足够差异化的路径覆盖主要失败模式；
  • 审计、修复和再审计不会以更高速度引入新问题；
  • 测试、运行时验证和产品约束能够进入证据闭环；
  • 系统能够管理长期状态、并行执行、合并顺序和回退；
  • 审计成本随项目规模增长后仍然可接受；
  • “稳定但错误”的共同盲区能够通过多模型、工具验证或人工抽检被控制。

只要其中一个关键条件长期不成立，MRAC 就可能只能作为高质量 AI 开发流程，而不足以支持工程 AGI。

7.4 当前尚未证明的结论

本文尚未证明：

  • MRAC 可以覆盖一个完整的长期大型软件项目；
  • 所有工程问题都存在可行的递归拆分方式；
  • 搜索空间可以被稳定治理到始终位于模型能力边界以内；
  • 收敛信号与最终缺陷率、运行质量或商业结果存在稳定因果关系；
  • MRAC 的审计成本和交付速度优于其他治理方法；
  • 产品意图、视觉质量、安全性和组织协作等非代码约束可以被同样有效地纳入闭环。

因此，“MRAC 可能通向工程 AGI”在当前版本中应被视为一个具有初步工程依据、但仍待系统验证的研究假说。

8. 局限性与有效性威胁

8.1 共同盲区

同一模型或相似提示进行多轮审计时，轮次并不等价于真正独立抽样。多个轮次可能重复相同的推理路径，并共享相同盲区。连续无新增问题可能只是审计器无法发现剩余问题。

8.2 审计协议演化

如果每一轮的审计提示、上下文范围或关注重点持续变化，问题数量变化可能来自协议变化，而不是工程对象自身趋于稳定。后续实验需要在修复开始前锁定核心协议，并单独记录有意的审计范围扩展。

8.3 修复引入新问题

新增问题不一定是上一轮遗漏的问题，也可能是上一轮修复新引入的缺陷。因此，收敛曲线同时受“发现能力”和“修复扰动”影响。

8.4 严重度判断的主观性

P1、P2 等严重度标签需要清晰的操作化标准和多人一致性检验。否则严重度下降可能受审计器或记录者判断变化影响。

8.5 停止规则的任意性

连续两次全范围审计无新增问题是一个比单次干净审计更严格的实用规则，但目前没有证据说明“两次”是跨任务最优阈值。高风险任务可能需要更多轮次、多模型审计或外部验证器。

8.6 外部效度

本文只包含两个来自同一项目环境的内部案例。项目架构、代码质量、测试能力、模型、工具和作者经验都可能影响结果，不能直接外推到其他团队、语言、仓库和工程类型。

8.7 缺少对照组

目前没有系统比较：

  • 单轮全范围审计；
  • 固定轮数审计；
  • MRAC 自适应停止；
  • 人工审查；
  • 多模型并行审计；
  • 无审计直接交付。

因此，当前不能量化 MRAC 相对于其他流程的净收益。

8.8 结果正确性与过程收敛的差异

过程收敛只描述审计结果趋于稳定。最终正确性仍需要测试、运行时监控、形式化约束、用户反馈和其他外部证据支持。两者不能混同。

9. 后续研究计划

9.1 第一阶段：锁定可复现协议

需要公开并固定：

  • 审计对象与上下文加载方式；
  • 模型、版本、温度或推理设置；
  • 审计提示和审计视角；
  • P0/P1/P2 分级规则；
  • 问题去重和“新增问题”判定规则；
  • 无效轮次和废弃轮次标准；
  • 修复流程；
  • 收敛停止规则；
  • 原始审计输出和版本差异。

9.2 第二阶段：扩大案例规模

在多个任务、模块和项目上记录：

  • 各轮新增问题数量与严重度；
  • 问题类别变化；
  • 修复后回归缺陷；
  • 达到收敛所需轮数；
  • 不收敛后拆分是否改善；
  • Token、时间和计算成本；
  • 合入后的实际缺陷和返工情况。

9.3 第三阶段：建立对照实验

至少应比较：

  1. 单轮全范围审计；
  2. 固定两轮或固定多轮审计；
  3. MRAC 动态停止；
  4. 同模型多轮审计；
  5. 多模型或多视角审计；
  6. 人工、AI 和混合审计。

主要结果指标应包括最终缺陷发现率、合入后缺陷、返工量、总成本、交付时间和错误严重度，而不只是审计轮次数。

9.4 第四阶段：完整项目验证

需要在一个具有代表性的完整软件项目中验证：

  • 工程目标能够持续被拆分为可审计任务；
  • Spec 和 PR 均可纳入同一收敛闭环；
  • 不收敛能稳定触发有效拆分或回退；
  • 多任务依赖、并行和合并顺序能够被治理；
  • 系统能在较少人工推动下长期运行并阶段性交付；
  • 人类阻塞项、确认项和回滚成本可被明确记录。

完成这一步后，才能更有力地讨论 MRAC 是否已经从局部质量机制发展为工程 AGI 的系统基础。

10. 结论

当前 AI 软件工程的核心限制之一，不是模型完全不会执行任务，而是它不能稳定判断自己的结果是否可信。单轮执行成功和单轮审计无问题，都不足以证明当前工程对象已经可靠。

MRAC 通过持续执行审计、修复和再审计，观察新增问题数量、严重度和结构的变化，为工程系统增加了一种二阶证据信号。收敛不证明绝对正确，但可以表明当前工程对象在给定条件下表现出进入可稳定覆盖搜索空间的迹象；不收敛则触发任务回退与进一步拆分。

由此形成的基本闭环是：

执行、审计、修复并观察收敛；不能收敛时返回任务拆分阶段，再重复整个过程。

本文提出，若这一机制能够稳定覆盖任务拆分、Spec 和 PR，并与依赖管理、状态管理、并行执行和回退系统结合，那么复杂项目可能被递归转化为 AI 可以稳定处理的局部任务。工程 AGI 因而不再只取决于等待一个能够一次性完成全部工作的完美模型，也可能取决于能否构建一个持续识别能力边界、缩小搜索空间并验证阶段性收敛的外部工程系统。

目前，这仍是一个基于局部项目观察提出的工程假说。下一步工作的关键，不是继续扩大结论，而是公开协议、扩大样本、建立对照，并验证收敛信号是否能够稳定预测最终交付质量和完整项目的无人化推进能力。

附录：中英文术语表

中文术语固定英文名称说明
多轮审计收敛Multi-Round Audit Convergence（MRAC）本文核心术语
多轮审计Multi-Round Auditing对同一对象持续审计、修复和再审计
工程 AGIEngineering AGI面向长期复杂项目交付的工程化定义
自主软件工程Autonomous Software Engineering软件工程领域的长期自主执行
有效搜索空间Effective Search Space当前对象需要处理的有效可能性集合
可稳定覆盖的搜索空间Reliably Coverable Search Space给定系统条件下可稳定处理的范围
搜索空间治理Search-Space Governance通过边界、拆分、上下文和工具降低复杂度
递归任务治理Recursive Task Governance不收敛时回到拆分或边界治理阶段
二阶验证信号Second-Order Validation Signal由多轮结果变化而非单轮内容产生的证据
工程固化点Engineering Checkpoint / Frozen Artifact任务拆分、Spec、PR 等可审计状态节点

核心定义

多轮审计收敛（Multi-Round Audit Convergence，MRAC）：对同一工程对象持续执行审计、修复和再审计时，新增有效问题的数量、严重程度和结构性总体下降，并在预定审计覆盖条件下连续多轮保持稳定的现象与判定机制。

参考资料

[1] Elias Calboreanu. “Iterative Audit Convergence in LLM-Managed Multi-Agent Systems: A Case Study in Prompt-Engineering Quality Assurance.” Software, 5(2), 26, 2026. DOI: https://doi.org/10.3390/software5020026. arXiv: https://arxiv.org/abs/2605.12280.

[2] Dicklesworthstone. Automated Plan Reviser Pro: Iterative specification refinement tool. GitHub repository, accessed 2026-08-05. https://github.com/Dicklesworthstone/automated_plan_reviser_pro.