当“正确”并非确定时验证智能体行为

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

随着智能体从简单的代码建议扩展到与UI、浏览器和IDE等真实环境交互，正确性变得多路径化。加载屏幕可能出现或消失，时间偏移，多个有效的动作序列可能导向相同的结果。除非我们的GitHub Actions工作流足够健壮以应对这种变异，否则经常会出现智能体成功完成任务但测试仍然失败的情况——即阻止生产的“假阴性”。

本文探讨如何从脆弱的逐步脚本转向用于智能体验证的独立“信任层”。我们将演示一个关注关键结果而非固定路径的模型，提供一种可解释、轻量级且适用于实际CI管线的验证方式。

智能体驱动验证的挑战

假设你负责一个依赖Copilot Agent Mode验证实际工作流的GitHub Actions管线。该智能体可能利用计算机使用，在容器化云环境中导航以进行工作流验证。周二构建是绿色的，周三测试失败——尽管代码没有变化。原因是托管运行器上的轻微网络延迟导致加载屏幕多持续了几秒。智能体等待、适应，并成功完成了任务。但CI管线仍然将运行标记为失败——不是因为任务失败，而是因为执行路径不再匹配记录的脚本或断言时间。智能体没有失败，验证失败了。这暴露了三个反复出现的痛点：假阴性（任务成功但测试运行器无法容忍变化）、脆弱的基础设施（测试因时间、渲染或与环境噪声无关的原因失败）、合规陷阱（结果可能正确，但因智能体行为偏离测试预期而被标记为回归）。

我们正处于一个过渡期：智能体系统如GitHub Copilot Coding Agent正在加速开发，但我们传统的验证方法仍然僵化。在确定性软件中，正确性只是将特定输入与已知输出匹配。但对于智能体，中间过程有意是非确定性的。正确性不是关于遵循一组规定的步骤，而是关于“可靠地实现关键结果”。为了规模化这些系统，我们需要一个能够区分“偶然噪声”（如加载屏幕）和“关键失败”（如未能保存数据）的验证框架。正确性从“这发生了吗？”转变为“为了成功是真的，必须发生什么？”

现有测试方法为何失效

传统测试工具在执行路径固定时工作良好，但行为分支时它们开始破裂——不是因为工程不良，而是因为它们假设稳定序列。当我们将它们应用于Copilot Coding Agent（包括在容器化环境中导航时）时，四种常见范式的局限性变得明显：基于断言的测试（需要手动指定每个检查，且无法处理有效替代路径）、记录回放工具（对环境噪声高度敏感）、视觉回归测试（孤立比较截图，无执行流理解）、ML或acles（需要大量训练示例，且无法解释）。这些方法共享一个结构假设：正确性由特定可观察状态序列定义。对于智能体系统，这一假设破裂。要建立开发者信任，我们必须超越检查线性脚本，开始验证结构化行为。

重新定义正确性：关键行为与可选行为

为了超越脆弱测试并构建信任层，我们必须从根本上改变“正确”的定义。在智能体系统中，正确执行不必看起来相同，但必须共享共同逻辑结构。我们可以将智能体行为分为三类：关键状态（成功必须达到的里程碑，如“搜索结果”屏幕）、可选变化（偶然状态如加载旋转器）、收敛路径（不同的步骤序列最终在相同结果处汇合）。加载屏幕可能出现也可能不出现，但搜索结果必须出现。只有其中一个决定正确性。

从直觉到理论：支配分析

“必须有”与“偶然”行为之间的区别源于编译器理论中的支配关系。在控制流图中，如果从开始到B的每条路径都必须经过A，则节点A支配节点B。通过将支配分析应用于智能体执行轨迹，我们可以自动识别哪些状态是强制的、哪些是可选的、以及不同路径在哪里收敛。这使我们能够提取一个最小、可解释的正确性定义。

将执行建模为图而非脚本

为了捕捉智能体行为的复杂性，我们必须摒弃将执行视为线性一维脚本的做法。我们的框架使用一种称为前缀树接收器（PTA）的图结构对行为建模。节点表示可观察状态（如UI截图或代码快照），边表示转换（点击、按键或API调用）。图允许我们表示分支和收敛——这些概念在线性脚本中无法捕捉。分支解释了非确定性环境变化，收敛标识不同路径重新汇合的点，表明智能体成功导航了变异并返回主任务流。通过将表示从步骤序列转变为结构化行为模型，我们停止惩罚智能体走不同路径，而是开始验证它们是否遵循逻辑上合理的路径。

如何解决：结构化的正确性方法

为了将智能体从实验性演示推进到生产级基础设施，我们的团队开发了一种新颖的验证算法，该算法通过示例学习，而不是依赖僵化脚本。我们关注一个复杂的非确定性环境：通过“计算机使用”导航Visual Studio Code的AI智能体。通过观察仅2-10个成功会话，我们的算法自动构建一个“基准真值”模型，区分智能体的有效变异和实际失败。工作流包括：PTA构建（收集成功轨迹并转换为图）、语义合并（使用三层等价检测合并轨迹，结合快速视觉指标和LLM语义分析）、提取骨架（通过支配分析识别关键状态）。这种方法独特强大，因为它不需要手动规范，也不需要进行大规模模型训练。结果模型是实际执行状态的图，决策完全可解释。当验证失败时，算法通过识别哪个关键状态被错过提供清晰的失败原因。

状态等价性：决定两个状态何时“相同”是智能体验证中最困难的问题。我们使用三层检测框架：视觉指标（快速感知哈希和结构相似性）、语义分析（多模态LLM处理模糊情况）、保守合并（仅当模型确定等价时合并状态）。这不是朴素的像素比较，也不是“LLM挥手”——通过防御性和节俭地使用LLM解决特定模糊性，框架既健壮又能检测实际回归。

支配分析提取实质内容：一旦多个轨迹合并为统一图，算法应用支配分析隔离任务的骨架。状态A支配B如果从开始到B的每条路径必须经过A。我们定义状态为关键如果它是任务成功完成的支配者。通过计算这些数学关系，算法自动区分“必须有”里程碑和“偶然”噪声。在VS Code实验中，“搜索对话框”状态被识别为关键里程碑，因为它是数学支配者——没有触发搜索就不可能到达结果。相反，“加载”屏幕不支配任何东西，因为在更快的运行中它可以被绕过，算法将其标记为可选变异。通过将这些关键节点提取为支配子树，我们创建了一个最小、可解释的正确性定义。

验证新执行：建立支配树后，验证新轨迹成为结构性比较。我们使用拓扑子序列匹配：不要求新轨迹与参考完全相同，只要求关键状态以正确相对顺序出现。处理额外状态：如果参考序列是A→B→C，智能体产生A→X→B→Y→C，测试仍然通过，因为额外状态被视为偶然噪声。检测失败：仅当关键状态被跳过或以错误顺序出现时触发。评分与可解释性：框架提供覆盖度指标（匹配关键状态百分比）和失败原因（如“状态‘搜索结果’在‘搜索对话框’后从未达到”）。这使验证从“黑箱”转变为开发者可调试的诊断工具。

评估结果：我们设计了实验比较支配树方法与智能体自我评估（CUA报告自身成功）。结果：支配树方法准确率100%，精确率100%，召回率100%，F1分数100%，而CUA自我评估准确率82.2%，F1分数69.8%。最显著的是，智能体内部自我评估完全无法识别“非缺陷”场景（F1分数0%），而独立信任层在正确识别失败是否由智能体执行错误而非产品回归方面达到52.2% F1分数。结构性验证以很大优势胜出。

集成到开发者工作流：信任层框架设计为集成到GitHub Actions管线（减少环境噪声导致的假阴性）、回归测试（使用过去成功轨迹创建基准真值模型）、智能体评估（测量关键命中率）、UI自动化。目标是将智能体从“实验性演示”推进到“生产基础设施”。

当前局限和未来工作：需要成功轨迹示例（2-10个）、依赖LLM进行语义等价检查（引入外部依赖和延迟）、无法检测状态持续时间过长。未来工作包括添加时间约束和负约束、层次化抽象（将低级截图聚类为高级概念）、在线学习（实时重新计算支配者）。

为什么这很重要：随着AI智能体从实验性演示过渡到核心基础设施，验证必须进化。我们不需要黑箱模型评判其他黑箱模型，我们需要可检查、可推理和可信赖的结构性保证。通过将经典编译器理论与多模态AI结合，我们展示了从少数示例学习可解释的鲁棒成功定义是可能的。信任层框架提供高效学习、操作鲁棒性和完全透明。随着计算机使用在AI原生开发生命周期中的采用增加，这些保证至关重要。我们的可验证自主性之旅才刚刚开始。