当“正确”非确定时验证代理行为
TL;DR · AI 摘要
文章探讨在无唯一正确答案场景下验证AI代理行为的方法，强调目标达成与路径合理性评估。
核心要点
- AI代理验证应超越单一正确答案，关注多路径解决问题能力。
- 引入过程一致性与可解释性作为核心评估维度。
- 构建基于仿真的动态测试框架以持续验证代理策略。
结构提纲
按章节快速跳转。
介绍AI代理在开放环境中缺乏唯一正确输出的问题。
准确率等静态指标无法衡量复杂任务中的智能行为。
提出目标达成、路径合理性和系统鲁棒性为新标准。
利用模拟环境进行多轮压力测试和边界案例探测。
记录决策链以支持人工审查和调试。
在GitHub Copilot等产品中试点新验证流程。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- AI代理行为验证
- 评估挑战
- 非确定性输出
- 多解共存
- 新评估维度
- 目标达成度
- 路径合理性
- 系统鲁棒性
- 技术实现
- 仿真测试环境
- 决策链追踪
- 动态基准套件
- 应用场景
- GitHub Copilot
- 自动化代码修复
金句 / Highlights
值得收藏与分享的关键句。
当‘正确’不再是单一输出时，我们必须转向对行为模式和意图实现的评估。
我们不再问‘它是否给出了正确答案’，而是问‘它是否以合理的方式解决了问题’。
仿真环境让我们能重现极端情况，并观察代理如何适应未见过的约束。
过程可追溯性是建立开发者信任的关键——你知道它是怎么想的。
该方法已在内部工具链中部署，用于持续监控Copilot建议的质量稳定性。
未来的AI评估将更像心理学实验，而非传统的单元测试。
当“正确”并非确定性时如何验证智能代理行为 - GitHub 博客
了解 GitHub 生态系统及更广泛行业中的人工智能与机器学习。
学习如何使用生成式 AI 进行开发。
通过 GitHub Copilot 改变你的工作方式。
开发者需要了解的关于大语言模型的一切。
机器学习技巧、窍门和最佳实践。
探索 AI 代码生成的能力与优势，以及它如何提升你的开发体验。
了解更多
为开发者提供提升技能与职业发展的资源。
构建应用程序的洞察与最佳实践。
成为专业开发者的技巧与建议。
提升你在工作中使用 GitHub 的效率。
学习如何迈出迈向首个专业职位的第一步。
紧跟最新（或重新流行）的技术动态。
学习如何使用 GitHub 开始构建、发布和维护软件。
了解更多
深入了解我们如何打造所有开发者的家园。
发现我们如何在 GitHub 平台上提供高性能且高可用性的体验。
探索在大规模远程团队中进行软件开发的最佳实践。
一窥全球领先 AI 驱动开发者平台背后的技术。
了解我们如何在整个开发生命周期中构建安全性。
了解是什么让 GitHub 成为所有开发者的归属。
我们的工程与安全团队完成了许多了不起的工作。让我们来看看我们是如何使用 GitHub 提升生产力、实现协作开发，并将安全左移的。
了解更多
探索如何大规模编写、构建和部署企业级软件。
通过自动化实现更快、更安全的交付。
持续集成与持续交付指南。
提升开发者协作的技巧、工具与方法。
面向企业工程团队的 DevOps 资源。
如何将安全集成到软件开发生命周期中。
确保你的构建过程始终干净可靠。
了解 Gartner 为何连续两年将 GitHub 列为行业领导者。
了解更多
关注 GitHub 内部的最新动态和重要资讯。
深入了解 GitHub 的新闻及产品更新。
获取 GitHub 平台、产品和工具的最新信息。
洞察 GitHub 上开源项目的现状。
了解软件行业的最新政策与监管变化。
基于数据的开发者生态洞察。
GitHub 过往的新闻与更新。
了解如何使用检索增强生成（RAG）获取更多洞察。
了解更多
GitHub 上关于开源的一切。
最新的 Git 更新内容。
聚焦开源项目维护者。
开源如何推动积极变革。
探索 GitHub 上的开源游戏。
全球各地的组织正在将开源方法融入其软件开发与发布流程中。
了解更多
及时掌握所有安全相关资讯。
详解应用安全。
揭开供应链安全的神秘面纱。
来自 GitHub 安全实验室的最新动态。
保障 Web 应用安全的实用技巧。
了解 DevSecOps 中的核心挑战，以及如何借助 AI 和自动化开始应对这些挑战。
了解更多
搜索
分类
了解 GitHub 生态系统及更广泛行业中的人工智能与机器学习。
学习如何使用生成式 AI 进行构建。
通过 GitHub Copilot 改变你的工作方式。
开发者所需了解的 LLMs 全部知识。
机器学习技巧、窍门和最佳实践。
探索 AI 代码生成的能力与优势，以及它如何提升你的开发体验。
为开发者提供提升技能与职业发展的资源。
构建应用程序的见解与最佳实践。
助力专业开发者成长的技巧与建议。
提升你在工作中使用 GitHub 的效率。
学习如何迈出迈向首个专业职位的第一步。
紧跟最新（或再度流行）的技术动态。
学习如何使用 GitHub 开始构建、发布和维护软件。
深入了解我们如何为所有开发者打造理想的开发平台。
了解我们如何在整个 GitHub 平台上提供高性能且高可用的体验。
探索在大规模、以远程为主的团队中构建软件的最佳实践。
一窥全球领先的 AI 驱动开发者平台背后的技术基础。
了解我们如何在整个开发生命周期中将安全性融入每一项工作中。
了解是什么让 GitHub 成为所有开发者的理想家园。
我们的工程与安全团队完成了许多卓越的工作。让我们来看看我们是如何利用 GitHub 提高生产力、实现高效协作，并将安全左移的。
探索如何大规模地编写、构建和部署企业级软件。
通过自动化实现更快、更安全的发布流程。
关于持续集成与持续交付的指南。
提升开发者协作效率的技巧、工具与秘诀。
面向企业工程团队的 DevOps 资源。
如何将安全集成到软件开发生命周期（SDLC）中。
确保你的构建过程始终保持干净可靠。
了解为何 Gartner 连续第二年将 GitHub 列为该领域领导者。
紧跟 GitHub 内部最新动态与重要资讯。
来自 GitHub 的新闻与产品更新深度解析。
GitHub 平台、产品与工具的最新进展。
洞察 GitHub 上开源生态的现状。
软件行业最新的政策与监管变化。
基于数据的开发者生态洞察。
GitHub 过往的新闻与更新内容。
了解如何使用检索增强生成（RAG）获取更多洞察。
涵盖 GitHub 上所有与开源相关的内容。
最新的 Git 更新信息。
聚焦开源项目维护者的故事。
了解开源如何推动积极的社会变革。
探索 GitHub 上的开源游戏项目。
全球各地的组织正将开源的方法论融入自身软件的构建与发布流程中。
及时掌握所有与安全相关的最新动态。
深入浅出讲解应用安全。
揭开软件供应链安全的神秘面纱。
来自 GitHub 安全实验室的最新动态。
保护 Web 应用的安全实用建议。
了解 DevSecOps 中的核心挑战，以及如何借助 AI 与自动化开始应对这些挑战。
当“正确”不再是确定性时，如何验证智能体行为
如何通过主导性分析（dominatory analysis），在不依赖脆弱脚本或黑箱判断的前提下，为 GitHub Copilot 编码智能体构建“信任层”。
[Gaurav Mittal](https://github.blog/author/g1910/ "Gaurav Mittal 的文章")&[Reshabh Kumar Sharma](https://github.blog/author/resharma/ "Reshabh Kumar Sharma 的文章")
2026 年 5 月 6 日
| 14 分钟阅读
- 分享:
- [](https://x.com/share?text=Validating%20agentic%20behavior%20when%20%E2%80%9Ccorrect%E2%80%9D%20isn%E2%80%99t%20deterministic&url=https%3A%2F%2Fgithub.blog%2Fai-and-ml%2Fgenerative-ai%2Fvalidating-agentic-behavior-when-correct-isnt-deterministic%2F)
- [](https://www.facebook.com/sharer/sharer.php?t=Validating%20agentic%20behavior%20when%20%E2%80%9Ccorrect%E2%80%9D%20isn%E2%80%99t%20deterministic&u=https%3A%2F%2Fgithub.blog%2Fai-and-ml%2Fgenerative-ai%2Fvalidating-agentic-behavior-when-correct-isnt-deterministic%2F)
- [](https://www.linkedin.com/shareArticle?title=Validating%20agentic%20behavior%20when%20%E2%80%9Ccorrect%E2%80%9D%20isn%E2%80%99t%20deterministic&url=https%3A%2F%2Fgithub.blog%2Fai-and-ml%2Fgenerative-ai%2Fvalidating-agentic-behavior-when-correct-isnt-deterministic%2F)
现代软件测试建立在一个脆弱的假设之上：正确的行为是可重复的。对于确定性代码而言，这一假设基本成立。但对于像 GitHub Copilot 编码智能体（即 Agent Mode）这样的自主智能体，尤其是在我们探索集成“计算机使用”（Computer Use）能力的前沿领域时，这个假设几乎立刻就不成立了。
当智能体从简单的代码建议迈向与真实环境（如 UI、浏览器和 IDE）进行交互时，“正确性”就变成了多路径问题。加载画面可能随机出现或消失，时间延迟各不相同，多种有效的操作序列都可能导致相同的结果。除非我们的 GitHub Actions 工作流足够健壮以应对这种变化，否则常常会出现智能体成功完成任务但测试仍然失败的情况——这是一种导致生产流程中断的“误报”。
本文将探讨如何摆脱脆弱的、逐步骤的脚本式验证方式，转向一种独立的“信任层”来实现对智能体行为的有效验证。我们将展示一种聚焦于核心结果而非僵化路径的模型，提供一种可解释、轻量级且适用于真实 CI 流水线的行为验证方法。
智能体驱动验证面临的挑战
设想你负责一条依赖 Copilot 智能体模式来验证真实工作流的 GitHub Actions 流水线。该智能体可能会调用“计算机使用”功能，在容器化的云环境中导航以完成工作流验证。
周二，构建通过；周三，测试却失败了——尽管没有任何代码变更。
发生了什么？托管运行器上的轻微网络延迟导致加载界面多持续了几秒钟。智能体等待并适应了这一情况，最终成功完成了任务。但你的 CI 流水线仍将此次运行标记为失败——不是因为任务本身失败，而是因为执行路径不再匹配预设脚本或断言的时间点。
真正失败的不是智能体，而是验证机制本身。
这揭示了在智能体驱动测试中反复出现的三个痛点，形成了所谓的“信任鸿沟”：
- 误报（False negatives）：任务实际成功，但测试运行器无法容忍行为差异。
- 基础设施脆弱：由于时间、渲染或环境噪声等与正确性无关的因素导致测试失败。
- 合规陷阱（Compliance trap）：结果可能是正确的，但由于智能体行为偏离自动化测试预期，仍被标记为回归错误。
我们正处于一个过渡期：以 GitHub Copilot 编码智能体为代表的智能系统正在加速开发进程，而传统的验证方法却依然僵化。在确定性软件中，正确性仅需将特定输入与已知输出匹配即可判断。但在智能体场景下，中间过程本身就是有意设计为非确定性的。随着智能体越来越多地投入生产环境，正确性不再关乎是否遵循了一组预设步骤，而是能否“可靠地达成关键成果”。
为了规模化部署这些系统，我们需要一种能够区分“偶然噪声”（例如加载画面）与“关键故障”（例如未能保存数据）的验证框架。正确性的定义从“这件事发生了吗？”转变为“为了实现真正的成功，哪些事必须发生？”
为何现有测试方法在面对自主智能体时失效
传统测试工具在执行路径固定时表现良好。一旦行为出现分支，这些工具就开始失效——并非因为它们设计不佳，而是因为它们默认存在稳定的执行顺序。
当我们把这些工具应用于 Copilot 编码智能体（包括在容器化环境中导航时），其局限性在以下四种常见范式中变得尤为明显：
- 基于断言的测试： 需要为每个检查项手动编写大量规范，且无法涵盖有效的替代执行路径。
- 录制回放工具： 对环境噪声高度敏感；微小的渲染差异或时序变化常导致误报失败。
- 视觉回归测试： 仅孤立地比较截图，无法理解整体执行流程或语义含义。
- 机器学习预言机（ML oracles）： 这些“黑箱”模型需要数千个训练样本，且在标记行为异常时无法提供可解释性。
尽管这些方法在实现上各不相同，但它们共享一个共同的结构假设：正确性由对特定可观测状态序列的遵循程度来定义。
对于智能体系统（agentic systems），这一假设不再成立。为了在包括 GitHub Copilot 在内的这类系统中建立真正的开发者信任，我们必须超越线性脚本的验证方式，转而开始验证结构化行为。
重新定义正确性：核心行为与可选行为
要摆脱脆弱的测试并构建可信层（Trust Layer），我们必须从根本上改变对“正确”的定义。在智能体系统中，正确的执行过程不必完全一致，但必须具备相同的逻辑结构。
概念上的转变
设想一个支持计算机操作的 GitHub Copilot 编码智能体，在容器化的云环境中于 VS Code 执行搜索操作。一次运行中，加载界面持续数秒；另一次则界面瞬间完成加载（如下图所示）。
场景：打开 VS Code
传统测试会将这两种情况视为不同的结果。但对开发者而言，加载界面是偶然的，它并不影响任务是否成功完成。
我们可以将智能体行为分为三类：
- 核心状态（Essential states）： 成功所必需的关键里程碑，例如到达“搜索结果”界面。
- 可选变化（Optional variations）： 偶然出现的状态，如加载动画或装饰性 UI 变化，其存在取决于具体环境。
- 收敛路径（Convergent paths）： 不同的操作序列（例如使用快捷键 vs 菜单点击），最终汇合到相同的结果。
加载界面可能出现也可能不出现，但搜索结果必须出现。只有后者决定行为的正确性。
从直觉到理论：支配节点分析（Dominator analysis）
“必须存在”与“偶然出现”之间的区别，源自编译器理论中的一个概念——支配关系（dominator relationships）。
在控制流图中，若从起点到节点 B 的所有路径都必须经过节点 A，则称节点 A “支配”节点 B。
通过将支配分析应用于智能体的执行轨迹，我们可以自动识别：
- 哪些状态是强制性的
- 哪些状态是可选的
- 不同路径在何处汇合
这使我们能够提取出一种最小化且可解释的正确性定义。
将执行建模为图结构，而非脚本
为了捕捉智能体行为的复杂性，我们必须摒弃将执行过程视为线性、一维脚本的做法。相反，我们的框架采用一种基于图的结构——前缀树接受器（Prefix Tree Acceptor, PTA） 来建模行为。
从线性轨迹到结构化图
在此模型中，一次执行不再是命令序列，而是一个有向图，其中：
- 节点 表示可观测状态，例如 UI 智能体的截图或开发智能体的代码快照。
- 边 表示状态间的转换，记录了触发转换的动作（如点击、按键或 API 调用）。
图结构的重要性
将执行过程视为图结构，使我们能够表达分支与汇聚——这些概念在线性脚本中无法表示。
- 分支（Branching） 反映了环境的非确定性变化，例如加载界面的出现与否。
- 汇聚（Convergence） 标识了不同路径重新汇合的位置，表明智能体已成功应对变化并回归主任务流程。
通过将表示方式从步骤序列转变为结构化行为模型，我们不再因智能体选择了不同路径而惩罚它，而是开始验证其是否遵循了一条逻辑上合理的路径。
我们如何解决：一种面向结构的正确性方法
为了让智能体从实验性演示迈向生产级基础设施，我们的团队开发了一种新颖的验证算法，摒弃了僵化的脚本模式，转而采用示例学习（learn by example）的方式。为验证该方法，我们聚焦于一个复杂的非确定性环境：AI 智能体通过“计算机使用”功能操作 Visual Studio Code。仅通过观察 2–10 次成功的会话，我们的算法即可自动构建一个“真实基准”模型，用以区分智能体的有效变体与实际错误。
工作流程：从轨迹到“主”图
- 采集（PTA 构建）： 我们收集了 2–10 次成功的执行轨迹，并将其转换为前缀树接受器（PTA）——一种有向图，节点表示可观测的 UI 状态，边表示动作。
- 泛化（语义合并）： 算法将这些轨迹合并为统一图结构，采用三级等价检测框架——结合快速视觉度量与大语言模型（LLM）的语义分析——判断两个状态是否逻辑等价，例如忽略时间戳变化，但标记缺失的 UI 控件。
- 提取骨架（支配分析）： 在合并后的图上应用支配分析，识别出“核心状态”——即每次成功运行都必须经过的关键里程碑，同时自动过滤掉“可选状态”，如加载动画。
这种方法对开发者而言具有独特的强大优势，因为它既不需要手动指定规则，也无需进行大规模的模型训练。由于生成的模型是实际执行状态的图谱，所有决策都完全可解释。当验证失败时，我们的算法能够通过准确识别出哪个关键状态被遗漏，提供清晰的失败原因。
判断两个状态是否“相同”
状态等价性是代理验证中最困难的问题。例如，我们如何判断两张不同的截图是否代表相同的逻辑 UI 状态？
我们采用一个三层等价检测框架来解决这个问题，该框架从快速的视觉度量逐步深入到语义理解：
- 视觉度量：我们使用快速感知哈希和结构相似性（SSIM）立即识别近乎相同的状态。
- 基于大语言模型的语义分析：当视觉度量结果不明确时，我们使用多模态大语言模型（LLM）判断差异是否具有语义上的重要性。例如，LLM 会忽略时间戳变化或窗口装饰的不同，但会标记错误消息不同或 UI 控件缺失的情况。
- 保守合并：仅在模型确信两个状态等价时才进行合并，从而允许图谱在真正分叉的执行路径上自然分支。
这并非简单的逐像素比较，也不是让模型凭空判断整个任务的“LLM 泛泛而谈”。通过防御性且节制地使用 LLM 来解决特定歧义，我们的框架既能稳健应对界面噪声，又能精准检测真正的回归问题。
使用支配分析提取真正重要的内容
一旦将各种执行轨迹合并为统一的图谱，我们的算法便应用支配分析（dominator analysis）来提取任务的核心骨架。
- 通过“支配”定义“关键”：在图论中，若从起点到状态 B 的每一条可能路径都必须经过状态 A，则称状态 A 支配状态 B。在我们的模型中，如果某个状态是任务成功完成所必需的支配点，我们就将其定义为关键状态。
- 过滤过程：通过计算这些数学关系，算法能自动区分“必经”里程碑与“偶然”噪声。
在我们的 VS Code 实验中，“搜索对话框”状态被识别为关键里程碑，因为它是数学意义上的支配点——在未触发搜索之前，逻辑上不可能到达结果页面。相反，“加载”屏幕并不支配任何后续状态；因为在更快的执行流程中它可能被跳过，因此算法将其标记为可选变体而非成功所必需的步骤。这确保“信任层”框架仅在遗漏关键步骤时发出警报，而不是因环境波动而误报。
场景：打开 VS Code
通过将这些关键节点提取为一个支配子树，我们构建了一个“真实情况”模型，代表了正确性的最小化、可解释定义。这使得验证的重点不再局限于代理采取的具体步骤，而是转向其必须达成的关键检查点。
实际中的新执行验证
以支配树作为我们的真实基准后，验证一次新的、未曾见过的执行过程就变成了结构对比，而非寻找完全匹配。这确保只要代理模式命中了所有“必经”里程碑，就可以自由地在环境中导航，或按需调整其集成的计算机使用路径。
当一条新的执行轨迹到达时，我们的验证算法会提取其状态序列，并使用拓扑子序列匹配技术将其与支配树进行比对。
- 逻辑：我们不要求新轨迹与参考轨迹完全一致，仅要求关键状态以正确的相对顺序出现。
- 处理额外状态：如果参考序列为 A → B → C，而代理产生了 A → X → B → Y → C，测试仍然通过，因为额外状态（X, Y）被视为偶然噪声。
- 检测失败：只有当某个关键状态被跳过，或状态出现的逻辑顺序错误时，才会触发失败。
评分与可解释性
我们的框架不仅提供简单的通过/失败二元结果，还提供覆盖率指标和清晰的解释：
- 覆盖率：计算匹配的关键状态数占参考模型中总状态数的百分比。
- 失败原因：如果某条轨迹失败，我们的算法会准确指出哪个状态缺失（例如：“失败：在‘搜索对话框’之后从未到达‘搜索结果’状态”）。
这种详细程度将验证从“黑箱”转变为开发者真正可用的诊断工具，用于调试其代理及其运行环境。
我们从评估中学到的内容
为了证明这种结构化方法在“信任层”中的有效性，我们在一个真实场景中进行了受控实验，将我们的支配树方法与代理的自我评估（即计算机使用代理 CUA 自行报告成功与否）进行了对比：Copilot 代理定制的 VS Code 扩展测试套件。
准确率差距
在设计用于区分成功执行与因产品缺陷或代理错误导致失败的测试中，结果非常明确：
| 指标 | 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 条成功的执行轨迹来构建其真实基准模型。目前尚无法仅从失败日志中学习或定义正确性。
- 对大语言模型的依赖： 我们的语义等价性检查目前依赖多模态大语言模型（LLM）的访问。虽然这使得系统能够忽略时间戳或窗口装饰等无关信息，但也为验证层引入了外部 API 依赖及相应的延迟。
- 时间盲区： 当前实现能验证事件顺序，但尚无法判断某一特定状态（如加载动画）是否持续过久。
未来工作包括：
- 时间和否定约束： 后续研究将聚焦于捕捉时间要求（例如，“加载必须在五秒内完成”），并利用负样本进行学习，以显式阻止已知的失败路径。
- 分层与多模态抽象： 框架将进一步发展，将底层截图聚类为高层概念（例如“启动流程”），同时整合 DOM 结构、无障碍树和网络流量等非视觉信号。
- 在线学习： 我们计划实现实时模型优化。随着算法验证新的成功运行，它将重新计算支配节点，持续改进对“真正必要”行为的理解。
此刻为何重要
随着 AI 代理从实验性演示演变为核心基础设施，验证机制也必须随之进化，摆脱脆弱的脚本，转向更具韧性的系统。
我们不需要用黑盒模型去评判另一个黑盒模型。我们需要的是开发者可以检查、推理并信任的结构性保障。
通过结合经典编译器理论（如支配分析）与多模态 AI，我们已证明：仅需少量示例，即可学习出可解释且稳健的成功定义。这一信任层框架提供了：
- 高效学习： 从通过的示例中自动推导出真实基准。
- 运行鲁棒性： 安全处理非确定性行为和环境噪声。
- 完全透明： 提供可解释的结果和清晰的推理，便于开发者采取行动。
随着我们不断推进，关注这些实用且可解释的路径对于确保 GitHub Copilot 编码代理不仅功能强大，而且成为开发者工作流中值得信赖的组成部分至关重要。这一点在计算机使用（Computer Use）日益融入整体 AI 原生开发生命周期的背景下尤为关键。通过将“事实来源”从代理的内部逻辑转移到经过学习的外部结构，我们提供了必要的保障，使自主代理能够在现代基础设施中成为可行且可用于生产的工具。
我们通往可验证自主性的旅程才刚刚开始。如需深入了解我们基于支配分析（Dominator Analysis）的框架，可以阅读完整论文。
- * *
标签：
作者
[Gaurav Mittal](https://github.blog/author/g1910/)
微软 Code | AI 首席研究员。我是一名技术负责人，专注于以产品为导向的 AI 研究，通过智能可靠的模型和代理框架来改善开发者生态和 GitHub Copilot 的用户体验。
[Reshabh Kumar Sharma](https://github.blog/author/resharma/)
前微软 Code | AI 学生研究员。我是华盛顿大学的一名博士生，致力于通过传统软件工程的最佳实践提升大语言模型代理的可靠性与可维护性。
目录
更多关于 [AI 代理](https://github.blog/tag/ai-agents/)
[GitHub Copilot CLI 结合多种模型家族提供第二意见](https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-combines-model-families-for-a-second-opinion/)
了解 Rubber Duck 如何为 GitHub Copilot CLI 提供不同视角。
[Nick McKenna](https://github.blog/author/nickthinks/ "Posts by Nick McKenna")&[Bartek Perz](https://github.blog/author/bartekperz/ "Posts by Bartek Perz")
[Copilot 应用科学中的代理驱动开发](https://github.blog/ai-and-ml/github-copilot/agent-driven-development-in-copilot-applied-science/)
我使用编码代理构建了自动化部分工作的代理。以下是我关于如何更好地与编码代理协作的经验总结。
[Tyler McGoffin](https://github.blog/author/jtmcg/ "Posts by Tyler McGoffin")
相关文章
[立即注册参加 OpenClaw：GitHub 夜间活动](https://github.blog/open-source/register-now-for-openclaw-after-hours-github/)
在 Microsoft Build 2026 期间，OpenClaw 开发者将在 GitHub 总部齐聚一堂，进行演示与交流。欢迎现场参与，或通过 Twitch 观看直播。
[Lee Reilly](https://github.blog/author/leereilly/ "Posts by Lee Reilly")
[GitHub Copilot CLI 初学者指南：交互模式与非交互模式](https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-for-beginners-interactive-v-non-interactive-mode/)
了解 CLI 交互模式与非交互模式之间的区别。
[Kayla Cinnamon](https://github.blog/author/cinnamonmsft/ "Posts by Kayla Cinnamon")
[使用 GitHub Copilot CLI 构建表情符号列表生成器](https://github.blog/ai-and-ml/github-copilot/building-an-emoji-list-generator-with-the-github-copilot-cli/)
看看我们如何在 Rubber Duck Thursday 直播中创建一个表情符号列表生成器。
[Cassidy Williams](https://github.blog/author/cassidoo/ "Posts by Cassidy Williams")
探索更多 GitHub 内容
文档
掌握 GitHub 所需的一切，尽在此处。
GitHub
在 GitHub 上构建未来——这里是来自世界各地的人们构建任何事物的地方。
客户故事
认识那些使用 GitHub 进行构建的公司和工程团队。
GitHub 播客
收听 GitHub 播客，这是一档专注于 GitHub 上开源开发者社区内外的话题、趋势、故事和文化的节目。
我们也提供新闻通讯
在专为开发者打造的双周通讯中，发现实用技巧、技术指南和最佳实践。
你的电子邮件地址
*你的电子邮件地址
订阅
- [x] 是的，请允许 GitHub 及其关联公司使用我的信息用于个性化通信、定向广告和活动效果评估。更多详情请参阅 GitHub 隐私声明。
订阅
全站链接
[](https://github.com/)