> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 构建AI生成代码的验证系统
- URL: https://www.hubwiz.com/blog/build-a-testing-system-to-validate-ai-generated-code/
- Published: 2026-08-26T15:53:08.000Z
- Updated: 2026-08-26T15:53:08.000Z
- Description: 代理测试、四阶段参考架构，以及赋予编码代理双手和双眼的验证层。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

本文是代理测试的实践指南：使用自主代理来验证由其他自主代理构建的软件。我首先解释为什么编码代理可以生成可工作的代码却无法可靠地证明它能工作，然后阐述一个四阶段参考架构，用于在生成和发布之间建立验证层。我深入介绍了一个具体实现——TestMu AI的Kane CLI，涵盖其执行模型、命令和输出格式，并将每一层映射到你可能已经在使用的工具，包括GitHub Copilot、Playwright和Microsoft Foundry代理评估。

读完本文，你将获得一个清晰的模型和一个可以在你自己的技术栈中应用的构建蓝图。

## 1、无人衡量的信任盲点

2026年每个工程团队都在问一个问题，以及第二个几乎没有人问的问题。

第一个：我们能多快地构建？答案是：快得离谱。旧的等式延续了四十年：人类编写代码，人类推送发布，软件以人类的速度运行。

新的剧本不同了：大语言模型编写代码，代理部署功能，自主系统持续交付。分析师已经对规模给出了粗略的数字。

Gartner预测40%的企业应用将嵌入特定任务的AI代理，而之前不到5%。McKinsey的调查显示，生成式AI在企业中的使用从大约三分之一的公司攀升到一年内达到三分之二。

Stack Overflow的开发者调查报告称，略占多数的专业开发者现在每天都会使用AI工具。这不是关于未来的预测。这是对现状的描述。

第二个问题决定了生产环境中的情况：我们能多快地进行验证？这就是信任盲点。

当一个功能由一个代理生成，由第二个代理审查，由第三个代理部署时，人类直觉的经典安全网——资深工程师凭直觉知道某个流程有问题——已经从循环中消失了。你留下一个说一切通过的工件，却没有独立的方法知道它是否测试了正确的东西。

这个差距就是代理测试的全部主题。这是一个真正的架构问题，而不仅仅是工具偏好。

## 2、为什么编码代理无法验证自己的输出

编码代理在特定工作领域确实非常出色：编写单元测试、执行代码审查和提高代码质量。接下来的陷阱是整个主题的智力核心，因此值得精确地陈述。

绿色构建中隐藏着一个幻觉。代码通过并不等于端到端体验真正工作。单元测试证明一个函数返回了其作者期望的值。它没有说明结账按钮是否可达、模态框是否渲染，或者真实用户是否能够完成该功能所服务的旅程。

对于AI生成的流程，问题更加复杂，因为质量不能是一次性的通过或失败检查。对自主系统的信任必须持续证明，一次又一次地运行，因为被测试的系统在不断变化。

故障分解为三个具体的工程问题，这三个问题是编码代理无法简单地测试自己输出的原因。

**问题一：上下文瓶颈。** 真正的测试承载着不适合上下文窗口的知识。多年的测试经验、特定于应用的行为、团队约定和跳过规则、历史通过和失败模式，以及框架最佳实践。

你无法将组织的制度化测试记忆粘贴到提示中。当你试图强行塞入时，模型产生幻觉的速度比推理更快。上下文窗口是一个硬物理限制，而测试知识超过了它。

**问题二：没有双手和双眼。** 这是决定性的。代理生成代码。它们无法点击、滚动或输入。它们无法看到实际渲染的内容。它们无法捕获损坏的模态框或折叠的布局。它们无法从端到端确认一个流程。关键的是，它们无法区分绿色勾号和真正的通过。

代理描述了应该发生什么。它没有独立的渠道来验证它确实发生了。语言模型是文本引擎，而渲染的浏览器是有状态的、事件驱动的运行时。它们是不同的宇宙，模型本身没有任何东西可以桥接它们。

**问题三：脆弱的测试脚本。** 当代理确实编写自动化测试时，它们产生与被测试系统紧密耦合的代码，带有硬编码的选择器和固定的等待。UI更改会破坏一切，而从头重新生成是唯一的修复方法。

更糟糕的是，这些测试验证的是代码应该做什么，而不是用户体验应该做什么。结果是维护债务在每次部署时都在累积，这是测试自动化计划的头号杀手，一直如此。

![编码代理的三种故障模式：上下文瓶颈、没有双手或双眼、脆弱的脚本](https://www.hubwiz.com/blog/content/images/2026/08/1-3f3Y9IJs548qDkvmYzmgkg.png)

一句话总结就是贴在你显示器上方的那句话：代理交付输出，而输出不是证明。接下来的一切都是将输出转化为证明的架构。

## 3、SDLC刚刚反转，测试现在是大部分工作

有一个结构性原因说明为什么这在现在很重要，而在五年前不那么重要，这归结为一个简单的比率。

在AI之前，发布周期持续数月，软件开发生命周期大约是80:20的分割，其中80%的努力用于开发，20%用于测试。生成是昂贵、缓慢的人类瓶颈。验证相对便宜，因为你验证的是缓慢流淌的人类编写的更改。

AI时代翻转了这个比率。生成压缩到约20%的努力，因为代理使其几乎免费且几乎即时。验证扩展到80%，因为你现在试图信任无界的机器生成更改。

当代码廉价且无限时，稀缺、有价值、可防御的工作是验证。如果你的测试方法是为旧世界设计的，它就不是为这个世界设计的。这个单一的反转就是为什么"我们能多快地验证"这个问题将区分在代理时代蓬勃发展的团队和被未验证输出淹没的团队。

![SDLC从80%开发翻转到80%测试的前后对比图](https://www.hubwiz.com/blog/content/images/2026/08/1-GhWy3_MZxOFTP1wr6FUd-Q.png)

## 4、核心思想：开发和发布之间的确定性验证层

这是架构论点，简单陈述。解决信任盲点的方法不是更聪明、更智能的生成模型。

在已经移动太快的东西上添加智能没有帮助。解决方案是在发布和开发之间添加一个确定性验证层，这个组件的全部工作是接收意图，针对现实执行它，并返回你可以依赖的结果。

确定性是关键词。编码代理在设计上是概率性的，这正是它具有创造力的原因，也正是它成为自己工作的糟糕评判者的原因。

验证层必须表现得像一个细心的工程师，而不是有创造力的工程师：给定相同的目标和相同的应用状态，它驱动一个真实的浏览器，检查实际渲染的内容，并返回判定以及该判定的证据。它是裁判，而裁判不能同时是参与者之一。

![验证层位于编码代理和发布之间，返回通过、失败和证据，并带有反馈循环](https://www.hubwiz.com/blog/content/images/2026/08/1-QnoT2maubeRQQdLuxQuHqA.png)

这就是Kane CLI——我想深入探讨的工具——的构建目标。TestMu AI（于2026年1月12日从LambdaTest更名）将其作为命令行验证层发布，在本地浏览器上测试任何功能或应用程序，它旨在由人类和代理从同一个终端直接驱动。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-3FMdR7p-oUSf171Mz0YRKQ.png)

在我深入探讨该工具之前，了解它在更大管道中的位置是有帮助的，因为验证层只有在其插入到周围的计划、执行和分析中时才能获得信任。

## 5、参考架构：四阶段代理质量管道

将代理质量视为一个具有四个阶段的管道，从左到流并在自身上循环。

将此视为你可以用自己的工具实现的参考架构；阶段边界是持久的理念，任何给定的产品都是它们的一个实例化。

![规划、创作、执行和分析四个阶段的管道，洞察循环回到规划](https://www.hubwiz.com/blog/content/images/2026/08/1-f-IUYpNHcByXmhGoeUYbRA.png)

**阶段一，规划。** 测试管理组件使用AI将意图和需求转化为测试覆盖。在实践中，此阶段回答"我们应该测试什么"，摄入工单、产品需求文档和先前运行，并产生结构化覆盖，而不是人类猜测测试矩阵。

**阶段二，创作。** 这是意图变为可执行验证的地方。三个不同的创作能力在这里。KaneAI是GenAI原生测试代理，用于跨栈的规划和创作。Kane CLI是面向开发人员、QA和AI编码代理的浏览器自动化验证，它是本文的重点。代理对代理测试是一种多代理能力，用于测试AI代理本身，我将回到这一点，因为测试代理与测试Web应用是不同的问题。

**阶段三，执行。** HyperExecute引擎在真实设备、自动化网格、视觉测试、API测试、可访问性测试、性能测试、iOS模拟器和Android模拟器上大规模运行编写的验证。架构要点是关注点分离：创作产生可移植的意图，执行决定在哪里以及如何广泛地运行它，从单个本地Chrome窗口到数千个并行云环境。

**阶段四，分析。** 测试智能层执行AI驱动的错误分类、智能自动修复和智能不稳定检测。这一层将数千个原始结果转化为人类可以处理的少量决策，它是使整个循环在企业规模下可行的原因。

在查看任何单一工具之前内化四个阶段的原因是，前面没有规划的验证层测试的是错误的东西，后面没有分析的验证层会让你淹没在噪音中。架构才是重点。工具只是一个组件。

## 6、深入探讨：Kane CLI作为验证层

Kane CLI是确定性验证层的一个实现，值得详细了解，因为它的设计选择是你在任何等效系统中都会面临的设计选择。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-iT30w6Sr_2G1dzR3KuBGIg.png)

最简单的形式，你用自然语言描述你想要测试的内容，Kane CLI驱动一个真正的Google Chrome浏览器来导航、点击、填写表单、提取数据并验证结果，然后返回带有证据的通过或失败。没有测试脚本、没有选择器、没有XPath，也没有框架样板。工作单元是意图，而不是指令。

## 7、开箱即用的功能

每个功能都是对上述三种故障模式之一的直接回答。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Ip0gkyL9vjnkVMAiOH8hSw.png)

**基于意图的控制**从源头消除了脆弱性。你描述一个自然语言目标，没有脆弱的测试脚本、没有定位器、没有选择器，也没有UI更改可以破坏的XPath。这是对问题三的回答。

**弹性运行**通过复杂的多步骤旅程保持工具正常工作，而不是在第一个意外屏幕上崩溃，工具在执行时自动发现错误，而不仅仅是检查预定义的断言。这是验证一件事的脚本和探索流程的代理之间的区别。

**基于视觉的等待**是对问题二"没有双眼"问题的回答。Kane CLI不添加任意的睡眠计时器，而是等待实际渲染的页面或功能，然后再继续。它正在查看渲染的内容，这正是语言模型本身缺乏的能力。

**Playwright代码生成**将循环闭合回你现有的技术栈。你输入自然语言提示，Playwright测试用例就会返回。你基于意图的探索性运行变成了可提交的、框架原生的工件，这意味着代理创作不会将你困在专有格式中。

**Test.md框架**将生成的测试用例存储为人类和代理都可读的Markdown，你可以随时重放，并从CI或CD管道触发。TestMu AI于2026年5月推出了这个代理原生框架，将探索会话转化为持久的、可验证的覆盖，无需选择器或特定框架的配置。一个人类和代理都可以读取、编辑和重放的测试是两个受众之间的连接组织。

**自动修复**直接攻击维护债务。当UI更改时，Kane CLI修复受影响的测试并返回更新的测试代码，而不是让你重写它。机制是具体的：一个步骤失败因为选择器更改，自动修复事件从旧选择器重建查询到新的、更健壮的选择器（如基于角色或类型的定位器），步骤重新运行并通过修复，然后智能等待轮询目标状态直到元素稳定并准备就绪，然后再继续。自愈加智能等待加动态查询是内置的三人组，消除了自动化头号杀手——维护。

**可共享证据**是使判定对人类审查者可信的原因。每次运行都产生视频日志和跟踪运行，以及一个可共享的链接，该链接重放目标完成的确切方式、光标移动、决策等等。这成为可移植的证明，你可以附加到拉取请求之前，步骤中发现的任何错误都会自动标记给用户。

**代理原生输出**是使整个事情可组合的细节。Kane CLI发出结构化的换行分隔JSON，即ndjson流，每个代理都可以解析。判定不是人类必须读取的截图；它是另一个代理可以推理的机器可读事件流。

## 8、三种模式，一个引擎

使Kane CLI不仅仅是CLI的设计决策是人类和代理以三种不同的方式使用完全相同的引擎。

![Kane CLI三种入口模式汇聚到一个通过CDP或云驱动Chrome的引擎，发出判定和证据](https://www.hubwiz.com/blog/content/images/2026/08/1--nZzfmyoIsLEcuWyNEfihg.png)

**交互式TUI模式**打开一个完整的终端用户界面，用于在实时浏览器会话中探索、迭代和链接测试。你用`kane-cli --tui`启动它，粘贴一个目标，然后观看每个识别的步骤流式传输到终端。这是人类的驾驶舱。

**无头运行模式**是CI和代理路径。单个命令运行一个目标并返回带有标准退出码的结构化输出，这是管道门控合并所需的一切。

```bash
# 在任何终端中独立运行
kane-cli run --url https://app.example.com "验证结账流程"
# 在CI中，使用访问密钥跳过OAuth
kane-cli run "冒烟测试登录" \
  --url https://app.example.com \
  --username ci@co.com \
  --access-key $KANE_KEY

```

**代理技能模式**是对验证AI生成代码最重要的模式。你将编码代理指向一个agents.md文件，代理学习如何在其自己的工作流中调用Kane CLI作为工具。

在Claude Code、Codex、Gemini或Cursor会话中，你内联调用它，Kane CLI会话在代理环境中初始化，代理现在可以执行操作、断言、数据提取和运行现有测试套件。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-TB2wmGmPiyD_kJAA0oTudA.png)

Kane CLI给你的代理双手和双眼：代理决定该功能需要哪些端到端测试，Kane CLI针对真实浏览器执行它们并报告回来。这是开发循环中缺失的一半终于闭合了。

## 9、安装和运行界面

将验证层安装到机器上被有意设计得微不足道，这很重要，因为没有人安装的验证层无法验证任何东西。

```bash
# 安装（需要Node.js 18+和Google Chrome）
npm install -g @testmuai/kane-cli
# 或者：brew install LambdaTest/kane/kane-cli
# 认证
kane-cli login
# 运行你的第一个验证
kane-cli run --url https://example.com \
  "点击'更多信息'链接并验证页面加载"

```

在底层，Kane CLI通过Chrome DevTools Protocol驱动真正的Chrome，这就是为什么它的配置公开了CDP就绪超时和慢速CI运行器的启动重试次数，以及为什么它可以在气隙环境中回退到PATH上解析到的任何Chrome。凭据、会话和配置数据位于本地`.testmuai`目录下。

这些是不华丽但决定工具是否能在真实管道中生存的运营细节，值得在你采用的任何工具中检查。

## 10、运行实际如何逐步执行

一个具体的运行是了解执行模型的最清晰窗口，而模型比运行本身更有趣。

给Kane CLI一个复合目标：在示例站点上完成结账流程，然后获取生成的订单ID并将其粘贴到另一个会话中的Google搜索中。有两件事揭示了架构。

首先，流程拆分。Kane CLI读取目标并自行将其分解为两个工作流，一个用于结账，一个用于订单ID传递。它不是执行线性脚本；它是在规划。在代理模式下，这种规划作为具有显式检查点的生成任务出现，每个步骤在运行时流式传输状态对象，因此你实时观看`{"step": 10, "status": "running"}`变为`{"step": 10, "status": "done"}`。

其次，有状态提取和断言。Kane CLI打开本地浏览器，推理每个下一步，下订单，并在表单需要数据时生成合理的测试数据来完成卡片和结账。

然后它从确认中提取并存储订单ID，在第二个流程中打开google.com，并粘贴存储的值。提取不是附带的。

Kane CLI仅在目标明确要求存储值时才持久化该值，存储的结果在运行完成时出现在运行的最终状态中。像"读取"或"告诉我"这样的模糊措辞使代理观察而不捕获。这个契约是可教的且精确的：目标语言控制状态机。

![Kane CLI运行流程：目标、流程拆分、操作、观察、提取、断言，然后判定和证据](https://www.hubwiz.com/blog/content/images/2026/08/1-66gDGXBSOF16u_DlN-fxmQ.png)

断言模型同样明确。一个步骤可以读取`analyze: ANALYZE(condition, ...)`然后`assert: Assert that {{listing_count}} is less than 2`，当条件不满足时步骤正确报告失败。

验证层不仅仅是在自动化点击；它是在实时页面状态下评估条件并返回真正的判定，包括真正的失败，这正是你想要的，因为永远不会失败的验证层就是从未工作过的验证层。

当运行完成时，你退出，会话保存到选定的文件夹，已完成测试的Playwright脚本被生成，并生成一个可共享的证据链接。

打开它，你会得到每个步骤的完整日志、自动播放重放显示光标和决策，以及一个可附加到审查的可移植工件。证据链接就是重点：它将代理的私有成功声明转化为可公开检查的证明。

## 11、企业级分析：从执行引擎到智能资产

运行的验证层是基本要求。每天保持五万次测试有用的验证层是一个不同的工程问题。

数学是残酷的。每天五万次测试，百分之一的失败率就是每天早上五百个警报。

人类团队无法在午餐前对五百个日志进行分类；他们被数据瘫痪了。没有智能层的原始执行量不是资产，它是对你自己工程师的拒绝服务攻击。

答案是告诉你什么在破坏、为什么在破坏以及如何修复的分析。

理想状态是一个智能层，实际上可以说："这四百五十个失败共享一个上游原因和一个修复，这五十个是真正的回归，而这一个是关键的。"这种分类是五百个无差别警报和少数几个分级决策之间的区别。

更深层次的能力是制度记忆。代理可以构建质量知识图谱，记住模式和行为并提供上下文而不是裸错误，提出诸如"此API在高负载部署期间超时"、"此组件在三个版本前不稳定"或"这看起来像上个月的数据库锁问题，这是修复方案"等观察。

这是从执行引擎到战略智能资产的飞跃，正是问题一中的上下文瓶颈，在系统级别解决而不是塞进提示中。不适合上下文窗口的知识存在于图中，图是可查询的。

## 12、测试代理本身：第二个、更难的验证问题

到目前为止的一切都是验证代理构建的软件。有一个可以说更难的问题：验证代理本身——聊天机器人、语音助手和通话代理，这些现在是产品。你不能用测试结账按钮的方式来测试这些。

澄清它的框架是你需要对抗性代理来测试你的代理，不是为了代码漏洞，而是为了逻辑漏洞——任何静态分析器都永远无法捕获的推理失败。要测试AI，你需要AI。代理测试代理，探索、推理、适应并找到逻辑漏洞而不是语法错误。

大多数团队今天依赖两种方法的组合，值得精确命名它们，因为它们是互补的，而不是竞争的。

**场景测试，或LLM评估。** 你为几轮创建上下文，模拟简短的交互，并单独验证响应，检查单个提示和来自模型API的响应。这很快、便宜，且是单元测试形状的。

**端到端模拟测试。** 你运行完整的多轮交互并检查目标是否实现。这很慢、昂贵，且是集成测试形状的，它是捕获仅在整个对话中出现的失败的唯一方法。

![代理对代理测试跨聊天、语音、电话和图像，通过场景和端到端评估](https://www.hubwiz.com/blog/content/images/2026/08/1-aFcPS2NgqxmvNNzGlEIa7g.png)

代理对代理测试在五个表面上实现了这一点，该分类法是任何构建对话AI的人的有用清单。

聊天支持基于文本的机器人，具有跨固定质量指标集的多轮评估。语音将相同的评估模型扩展到音频对话。

来电代理专注于接收呼叫的代理，在模拟呼叫上进行预评估，在生产录音上进行后评估。外呼代理涵盖拨打电话的代理，具有专用号码池和被动监控。

第五个表面是图像分析器，根据提示、技术规范和品牌指南对生成的图像进行评分。

除了准确性、性能、可靠性和安全性的核心指标外，评估还涵盖响应一致性、首次呼叫解决、意图识别、指令遵循、任务完成、对话流程、偏见检测、毒性筛选，最重要的是客户满意度。

如果这个评估器列表听起来很熟悉，它应该很熟悉，因为微软自己的平台已经收敛到相同的形状，这是一个强烈的信号，表明这是该学科的发展方向。更多关于这方面的内容将在下面的映射中。

## 13、人类在循环中不是一种美德，而是架构

有一种诱惑将"代理测试代理"解读为"人类出局了"。我认为恰恰相反。

关键任务系统需要人类监督，代理测试需要跨多个阶段进行验证，人类在评估上下文、质量和可靠性方面发挥关键作用。

核心挑战不再是"代码是否工作"，而是"我们是否能信任推理"。推理系统需要推理审查者，而这个审查者是人类。

角色不会消失；它会提升。测试人员从编写脚本转向工程上下文，从手动执行转向验证推理，从修复脆弱的测试转向充当质量的守门人。

AI做繁重的工作，人类提供意图、责任和判断。对于关键任务系统，人类在循环中是不可谈判的。在架构上，这意味着你的管道需要在判断（而不是吞吐量）是约束条件的点上设置显式的人类门控，工具的任务是通过给人类一个分级的、有证据的、上下文丰富的决策（而不是一堵日志墙）来使这些门控变得廉价。

## 14、将参考架构映射到Microsoft生态系统

这就是它不再是单一供应商故事而变成你可以构建的东西的地方。

代理测试架构的几乎每一层在Microsoft和GitHub开发者栈中都有第一方对应物，了解映射让你可以从你可能已经拥有的部分组装验证层。

![将每个架构层链接到Microsoft或GitHub工具的双列映射，从Copilot到Azure AI Foundry](https://www.hubwiz.com/blog/content/images/2026/08/1-I20-cbthgJOI2CP5jz1PXg.png)

**生成层：编码代理。** 整个问题从代理编写代码开始，在这个栈上就是GitHub Copilot编码代理。微软的指导甚至涵盖了测试界正在反应的vibe-coding工作流。从这里开始了解你的验证层必须捕获什么。

**代理技能模式。** Kane CLI的"将你的代理指向agents.md，它学习调用该工具"与Microsoft在Agent Skills中形式化的模式相同，这是在SKILL.md中定义的可重用指令集，Copilot代理自动发现并激活。如果你想将自己的验证层暴露给编码代理，这是要实现的契约。

**浏览器执行基板。** Kane CLI驱动真正的Chrome并可以导出Playwright，而Playwright是微软的开源端到端框架，正是为此构建的：自动等待、Web优先断言、浏览器隔离，以及一个为编码代理提供结构化浏览器控制的Playwright MCP服务器。

**测试代理本身。** 代理对代理测试指标几乎一对一映射到Foundry的代理评估器，其功能类似于代理系统的单元测试，并为意图解决、工具调用准确性、任务遵循、依据性和答案完整性发出通过或失败分数。

映射的要点是，代理测试不是一个供应商的想法。它是一个正在融合的行业模式，即使产品不同，这些层也是稳定的。

## 8、代理测试系统的实用蓝图

将架构整合在一起，这是蓝图。每个原则都追溯到上面涵盖的故障模式。

**在生成和发布之间放置确定性验证层。** 生成器在设计上是概率性的；验证器在设计上必须是确定性的。永远不要让编写代码的代理成为它是否工作的唯一判断者。

**让意图成为工作单元，而不是指令。** 将测试编写为自然语言目标，并将其作为可重放的、人类和代理都可读的文件提交（Test.md模式）。选择器和硬编码的等待是你试图逃避的维护债务。

**给你的代理双手和双眼。** 语言模型无法看到渲染的页面。通过Kane CLI、Playwright MCP服务器或等效工具连接真实浏览器，以便代理可以操作和观察，而不仅仅是描述。

**发出机器可读的判定。** 结构化的ndjson和标准退出码让一个代理可以推理另一个代理的结果，让CI门控合并。截图为人类准备；管道需要数据。

**要求每个判定都有证据。** 跟踪、视频和可共享的重放链接将私有的成功声明转化为可附加到拉取请求的可公开检查的证明。

**为自愈而设计。** 自动修复选择器、智能等待和动态查询是保持套件在UI变化中存活的关键。维护是自动化的头号杀手；从第一天起就设计它。

**在增加容量之前添加智能层。** 在规模上，分类和根本原因分类不是可选的。构建记住模式的知识图谱，否则你将用警报瘫痪你的团队。

**测试代理，而不仅仅是应用。** 对于对话和自主系统，同时运行场景评估和端到端模拟测试，并评估逻辑漏洞、偏见和毒性，而不仅仅是功能正确性。

**在关键任务路径上保持显式的人类门控。** 自动化劳动，保留判断。人类在循环中是架构，而不是事后想法。

## 9、最后的思考

代理测试与其说是要学习的新框架，不如说是你投入努力的地方的转变。当机器可以在几秒钟内编写代码时，稀缺的工作变成了检查它，而这个检查必须是自动的、可重复的，并由你可以查看的证据支持。

令人鼓舞的部分是这些部分已经存在并可以干净地组合在一起。你可以给代理一个真实的浏览器，用自然语言描述你想要什么，获得带有可重放跟踪的通过或失败，并将整个东西连接到你已经在运行的管道中。

你可以选择一个流程，将其编写为意图，并让验证层在每次更改时端到端地证明它。添加自愈和结构化输出，以便你的其他代理可以读取结果。将人类保留在需要判断的门控上。

---

原文链接：[Build Agentic Testing Systems to Validate AI-Generated Code](https://medium.com/codex/build-agentic-testing-systems-to-validate-ai-generated-code-4adc1628c78e?ref=hubwiz.com)

汇智网翻译整理，请转载文章时标明出处