现代软件测试建立在一个脆弱的假设之上：正确的行为是可重复的。对于确定性代码，这个假设基本成立。但对于像 GitHub Copilot 云端智能体这样的自主智能体，尤其是当我们探索集成的“计算机使用”前沿时，这个假设几乎立刻就不成立了。

随着智能体从简单的代码建议发展到与真实环境（如用户界面、浏览器和 IDE）交互，正确性变成了多路径的。加载画面可能出现或消失，时序会发生变化，多个有效的操作序列可能导致相同的结果。除非我们的 GitHub Actions 工作流足够健壮以应对这种变化，否则智能体成功完成任务而测试仍然失败的情况很常见——这种“假阴性”会阻碍生产。

这篇博文探讨了如何从脆弱的、逐步执行的脚本，转向用于智能体验证的独立“信任层”。我们将展示一个专注于关键结果而非僵化路径的模型，提供一种可解释、轻量级且适用于真实 CI 管线的行为验证方法。

智能体驱动的验证所面临的挑战

想象一下，你负责一个依赖 Copilot 云端智能体来验证真实工作流的 GitHub Actions 管线。该智能体可能正在利用“计算机使用”功能，在容器化的云环境中导航以进行工作流验证。

周二，构建是绿色的。周三，测试失败了——尽管代码没有任何改动。

实际情况是这样的：托管运行器上的一次轻微网络延迟导致加载画面多持续了几秒钟。智能体等待、适应，并成功正确地完成了任务。但你的 CI 管线仍然将该次运行标记为失败——不是因为任务失败，而是因为执行路径不再匹配记录的脚本或断言时序。

智能体没有失败。是验证失败了。

这暴露了三个反复出现的痛点，它们在智能体驱动的测试中造成了“信任鸿沟”：

• 假阴性：任务成功了，但测试运行器无法容忍变化。
• 脆弱的基础设施：测试因时序、渲染或与正确性无关的环境噪声而失败。
• 合规陷阱：结果可能是正确的，但由于智能体的行为偏离了自动化测试的预期，仍被标记为回归问题。

我们正处于一个过渡期，像 GitHub Copilot Coding Agent 这样的智能体系统正在加速开发，但传统的验证方法仍然僵化。在确定性软件中，正确性简单到将特定输入与已知输出匹配即可。但对于智能体而言，中间的过程是有意非确定性的。随着智能体越来越多地部署到生产环境中，正确性不再关乎遵循一套预设的步骤，而是关乎“可靠地达成关键结果”。

为了规模化这些系统，我们需要一个能够区分“偶然噪声”（例如加载画面）和“关键故障”（例如未能保存数据）的验证框架。正确性从“这件事发生了吗？”转变为“为了真正成功，必须发生什么？”

为什么现有的测试方法对自主智能体失效

当执行路径固定时，传统测试工具表现良好。但当行为产生分支时，它们就会陷入困境——这些工具开始失效，不是因为它们设计得不好，而是因为它们假设了一个稳定的序列。

当我们将这些工具应用于 Copilot Coding Agent（包括在容器化环境中导航时），其局限性在四种常见范式中变得清晰：

• 基于断言的测试：需要对每项检查进行手动、劳动密集型的规范说明，并且无法考虑有效的替代执行路径。
• 录制回放工具：对环境噪声高度敏感；微小的渲染差异或时序变化常常会触发误报。
• 视觉回归测试：孤立地比较截图，而不理解更广泛的执行流程或语义含义。
• 机器学习预言机：这些“黑盒”需要数千个训练样本，并且在将某个行为标记为不正确时无法提供可解释性。

尽管这些方法在实现上各有不同，但它们共享一个共同的结构性假设：正确性是通过遵循特定的可观测状态序列来定义的。

对于智能体系统而言，这一假设不再成立。为了在这些系统（包括 GitHub Copilot）中建立起真正的开发者信任，我们必须超越对线性脚本的检查，转而开始验证结构化的行为。

重新定义正确性：必要行为与可选行为

为了摆脱脆弱的测试并构建信任层，我们必须从根本上改变对“正确”的定义方式。在智能体系统中，正确的执行过程不必看起来完全相同，但它们需要共享一个共同的逻辑结构。

概念上的转变

设想一个支持计算机操作的 GitHub Copilot 编程智能体，在容器化的云环境中于 VS Code 内执行搜索。在一次运行中，加载界面出现了几秒钟；在另一次运行中，用户界面则瞬间加载完成（如下图所示）。

传统测试会将这两种情况视为不同的结果。但对开发者来说，加载界面是附带现象，它并不改变任务是否成功完成这一事实。

我们可以将智能体行为分为三类：

• 必要状态：任务成功必须达成的关键里程碑，例如进入“搜索结果”界面。
• 可选变化：附带状态，例如加载转圈或装饰性 UI 变化，这些会因环境而异。
• 收敛路径：不同的步骤序列（例如使用快捷键与使用菜单），最终汇聚到同一个结果。

加载界面可能出现，也可能不出现。但搜索结果必须出现。这两者中只有一项决定了正确性。

从直觉到理论：支配分析

“必须拥有”与“附带”行为之间的区别，是一个源于编译器理论的概念，称为支配关系。

在控制流图中，如果从起点到节点 B 的每一条路径都必须经过节点 A，则称节点 A “支配”节点 B。

通过将支配分析应用于智能体执行轨迹，我们可以自动识别出：

• 哪些状态是强制性的
• 哪些状态是可选的
• 不同路径在何处收敛

这使我们能够提取出一个最小化、可解释的正确性定义。

将执行过程建模为图，而非脚本。

要捕捉智能体行为的复杂性，我们必须摒弃将执行过程视为线性、一维脚本的做法。相反，我们的框架采用一种基于图的结构（称为前缀树接收器，PTA）来对行为进行建模。

从线性轨迹到结构化图

在该模型中，一次执行并非一系列命令，而是一个有向图，其中：

• 节点代表可观测状态，例如 UI 智能体的截图或开发智能体的代码快照。
• 边代表状态转移，捕捉在状态之间移动所采取的动作（点击、按键或 API 调用）。

图为何重要

将执行过程视为图，使我们能够表示分支与汇聚——这些概念在线性脚本中是无法捕捉的。

• 分支用于处理非确定性的环境变化，例如加载界面出现或不出现。
• 汇聚用于识别这些不同路径重新汇合的点，表明智能体已成功处理了一个变化并回到了主要任务流程。

通过将表示方式从一系列步骤转变为结构化的行为模型，我们不再因智能体走了不同路径而惩罚它，而是开始验证它是否遵循了一条逻辑上合理的路径。

我们如何解决：一种结构化的正确性验证方法

为了让智能体从实验性演示走向生产级基础设施，我们的团队开发了一种新颖的验证算法，该算法摒弃了僵化的脚本，转而通过示例进行学习。为了测试这一点，我们聚焦于一个复杂的非确定性环境：一个通过“计算机使用”功能在 Visual Studio Code 中导航的 AI 智能体。通过仅观察 2 到 10 次成功的会话，我们的算法自动构建了一个“真实情况”模型，该模型能够区分智能体的有效变化与实际的失败。

工作流程：从轨迹到“主”图

1. 捕获（PTA 构建）：我们收集了 2 到 10 条成功执行轨迹，并将其转换为前缀树接收器（PTA），这是一种有向图，其中节点代表可观测的 UI 状态，边代表动作。
2. 泛化（语义合并）：我们的算法将这些执行轨迹合并为一个统一图。它采用三层等价性检测框架——结合快速视觉度量与大语言模型语义分析——来判断两个状态是否逻辑等价，例如忽略时间戳变化，同时标记缺失的 UI 控件。
3. 提取骨架（支配分析）：我们对合并后的图应用支配分析，以识别“关键状态”——每次成功执行都必须经过的里程碑——同时自动过滤掉“可选”状态，如加载旋转器。

这种方法对开发者而言具有独特优势，因为它无需手动指定，也无需大规模模型训练。由于生成的模型是一个实际执行状态的图，所有决策完全可解释。当验证失败时，我们的算法通过精确识别哪个关键状态未被满足，提供清晰的失败原因。

判断两个状态何时“相同”

状态等价性是智能体验证中最困难的问题。例如，我们如何知道两张不同的截图是否代表相同的逻辑 UI 状态？

我们通过一个三层等价性检测框架来解决这个问题，该框架从快速视觉度量过渡到深层语义理解：

• 视觉度量：我们使用快速感知哈希和结构相似性（SSIM）来立即捕获近乎相同的状态。
• 通过大语言模型进行语义分析：当视觉度量存在歧义时，我们使用多模态大语言模型来判断差异是否具有语义意义。例如，大语言模型知道忽略时间戳变化或不同的窗口装饰，但会标记不同的错误消息或缺失的 UI 控件。
• 保守合并：仅在模型确信状态等价时才进行合并，从而允许图在执行路径真正分叉的地方自然分支。

这既不是天真的逐像素比较，也不是让模型判断整个任务的“大语言模型空谈”。通过防御性地、有节制地使用大语言模型来解决特定歧义，我们的框架既能稳健处理 UI 噪声，又能精确检测到真正的回归缺陷。

通过支配者分析提取真正重要的内容

当各种执行轨迹被合并成一个统一的图后，我们的算法会应用支配者分析来隔离出任务的核心骨架。

• 通过支配关系定义“关键”：在图论中，如果从起点到 B 的每一条可能路径都必须经过 A，则称状态 A 支配状态 B。在我们的模型中，如果一个状态是任务成功完成的支配者，我们就将其定义为关键状态。
• 过滤过程：通过计算这些数学关系，算法会自动区分“必须完成”的里程碑和“偶然出现”的噪声。

在我们的 VS Code 实验中，“搜索对话框”状态被识别为一个关键里程碑，因为它在数学上是一个支配者——如果不先触发搜索，在逻辑上就不可能到达结果。相反，“加载”屏幕不支配任何状态；因为在更快的运行中它可以被绕过，所以算法将其标记为一种可选的变化，而非成功的必要条件。这确保了“信任层”框架仅在关键步骤被遗漏时发出警报——而不是在环境波动时。

通过将这些关键节点提取到一个支配子树中，我们创建了一个“真实基准”模型，该模型代表了正确性的最小化、可解释的定义。这将验证的重点从智能体所采取的具体步骤，转移到它必须达到的关键检查点上。

在实践中验证新的执行过程

有了作为我们真实基准的支配树，验证一个新的、未见过的执行过程就变成了一个结构比较的过程，而不是寻找完美匹配的过程。这确保了只要云智能体达到了“必须完成”的里程碑，它就可以自由地探索环境，或按需调整其集成的计算机使用路径。

当一个新的执行轨迹到达时，我们的验证算法会提取其状态序列，并使用拓扑子序列匹配将其与支配树进行核对。

• 其逻辑是：我们不要求新轨迹与参考轨迹完全相同；我们只要求关键状态以正确的相对顺序出现。
• 处理额外状态：如果参考序列是 A → B → C，而智能体生成了 A → X → B → Y → C，测试仍然通过，因为额外状态（X、Y）被视为附带噪声。
• 检测失败：只有当某个关键状态被跳过，或者状态出现的顺序不符合要求的逻辑顺序时，才会触发失败判定。

评分与可解释性

我们的框架不仅输出简单的通过/失败二元结果，还提供覆盖率指标和清晰的解释：

• 覆盖率：计算为匹配到的关键状态数量占参考模型中状态总数的百分比。
• 失败原因分析：如果某条轨迹失败，我们的算法会精确识别出缺失的是哪个状态（例如：“失败：在‘搜索对话框’之后从未到达‘搜索结果’状态”）。

这种细节层次将验证过程从“黑箱”转变为一种诊断工具，开发者可以真正用它来调试智能体及其运行环境。

我们从评估中学到的

为了证明这种结构化方法对信任层的有效性，我们进行了一项对照实验，在真实场景中——即一个 Copilot 智能体自定义 VS Code 扩展测试套件——将我们的支配树方法与智能体的自我评估（即计算机使用智能体（CUA）自行报告其成功与否）进行了比较。

准确率差距

在旨在区分成功执行与因产品缺陷或智能体错误而失败的测试中，结果非常明确：

指标	CUA 自我评估	PTA（支配树）
准确率	82.2%	100%（+17.8）
精确率	83.3%	100%（+16.7）
召回率	60.0%	100%（+40.0）
F1 分数	69.8%	100%（+30.2）

虽然智能体（CUA）经常将失败误报为成功（通常是由于超时或错误解读自身状态），但支配树通过聚焦于关键里程碑是否真正达成，实现了完美的区分。

识别“非缺陷”场景

对开发者而言，最显著的影响在于减少了“误报”。当测试失败时，你需要高信噪比的反馈来判断是产品代码出了问题，还是智能体仅仅因为环境噪声而出现失误。

• “自我验证”差距：在我们的评估中，智能体的内部自我评估（CUA）完全无法识别“非缺陷”场景（F1 分数为 0%）。这表明，在非确定性环境中，智能体尚无法可靠地自我评判其工作成果。
• 结构性优势：通过在支配者模型中使用状态和动作等价性，我们独立的信任层在正确识别故障是智能体执行错误而非产品回归时，达到了 52.2% 的 F1 分数。

结论

结构性验证在效果上远超自我报告的成功率。通过将“事实来源”从智能体的内部逻辑转移到学习到的外部结构，我们可以显著减少在 CI 流水线中因不稳定测试结果和误报而浪费的人工审查时间。

这在当前开发者工作流中的定位

要使该信任层框架发挥作用，它必须超越研究原型阶段，直接集成到开发者日常使用的系统中。通过将正确性视为一种学习到的结构而非僵化的脚本，我们可以在 GitHub 生态系统中显著提升生产级自动化的可靠性。

集成点

该方法旨在强化软件开发生命周期中的几个关键领域：

• GitHub Actions 流水线：通过减少由环境噪声（如瞬时加载屏幕）引起的误报，该方法为自动化构建提供了“更高信噪比”，从而防止不必要的流水线阻塞。
• 回归测试：开发者可以利用来自稳定版本的少量已验证轨迹，创建一个“基准事实”模型，自动验证未来的更新。
• 智能体评估：团队无需依赖智能体自我报告成功与否，而是可以使用结构性验证来衡量智能体实际达成关键里程碑的频率。
• UI 自动化：该框架支持对复杂的桌面和 Web 应用进行更稳健的自动化测试，即使这些应用的 UI 元素或路径在不同版本间略有变化。

该框架的最终目标是推动智能体从“实验性演示”迈向“生产级基础设施”。通过提供推理能力——当故障发生时能清晰指向缺失的关键状态——开发人员便能获得所需的透明度，从而在自身工作流中信任自主系统。

未来展望

尽管结构验证代表了重大进步，但当前框架在迈向完全成熟的过程中仍存在若干局限。

当前局限包括：

• 对成功轨迹的需求：该算法“通过示例学习”，即需要 2 到 10 条成功执行轨迹来构建其真实模型。它目前还无法仅从失败日志中学习或定义正确性。
• 对大语言模型的依赖：我们的语义等价性检查目前依赖于多模态大语言模型的访问。虽然这赋予了“智能”以忽略时间戳或窗口装饰的能力，但它也在验证层引入了外部 API 依赖和相应的延迟。
• 时间盲点：当前实现能够验证事件的顺序，但尚无法标记某个特定状态（如加载旋转图标）是否持续了过长时间。

未来工作包括：

• 时间与负向约束：未来工作将聚焦于捕获时序要求（例如“加载必须在五秒内完成”），并通过从负面示例中学习来明确阻断已知的失败路径。
• 分层与多模态抽象：该框架将演进为将底层截图聚类为高层概念（例如“发射序列”），同时整合非视觉信号，如 DOM 结构、无障碍树和网络流量。
• 在线学习：我们旨在实现实时模型优化。当算法验证新的成功运行时，它将重新计算支配节点，以持续改进对什么是真正“关键”的理解。

为何此事当下至关重要

随着 AI 智能体从实验性演示走向核心基础设施，验证方法也必须随之演进——从脆弱的脚本转向富有弹性的系统。

我们不需要黑盒模型去评判其他黑盒模型。我们需要的是开发人员能够检查、推理并信任的结构化保障。

通过将经典编译器理论（即支配者分析）与多模态 AI 相结合，我们证明了仅凭少量示例就能学习到一个可解释、稳健的成功定义。这一信任层框架提供了：

• 高效学习：从通过示例中自动推导出真实标注。
• 运行稳健性：安全处理非确定性行为和环境噪声。
• 完全透明：可解释的结果，附带清晰的推理过程，供开发者据此采取行动。

展望未来，聚焦这些实用且可解释的路径，对于确保 GitHub Copilot 编程智能体不仅功能强大，而且成为开发者工作流中值得信赖的组成部分至关重要。随着计算机使用在整体 AI 原生开发生命周期中的日益普及，这一点尤为关键。通过将“事实来源”从智能体的内部逻辑迁移至一个学习到的外部结构，我们提供了必要的保障，使自主智能体能够成为现代基础设施中可行且达到生产级水准的工具。

我们迈向可验证自主性的旅程才刚刚开始。如需深入了解我们基于支配者分析的框架，可阅读完整论文。