每个 agent 都需要的计算机使用验证技能

在本文中，我将介绍如何为你的 agent 添加计算机和浏览器使用能力，以便复现问题并验证修复和新功能。

本系列之前的文章：

• 构建 issue 分类 agent 和实施 agent

• 通过 spec agent 添加规格驱动开发

• 添加自我改进的代码审查 agent

对于不熟悉计算机和浏览器使用的读者，这是一种允许 agent 直接通过鼠标点击和键盘按键来控制正在运行的应用程序的工具。大多数主流模型提供商都有支持此功能的模型，并且这些功能越来越多地在各种 harness 中可用，包括 Warp。

Oz@ozdotdev·8月2日 回复 @vikvang1 @kingdrale 和 @warpdotdev 已上线：提示队列。当 agent 工作时，Ctrl/⌘+Shift+J 会自动排队你的下一条提示，或使用 /queue 发送后续提示。排队的行可以重新排序、编辑或提前发送。https://docs.warp.dev/agent-platform/local-agents/interacting-with-agents/prompt-queueing/…2231.2K

我们已将计算机使用引入到 agent 技术栈的所有部分，包括 Twitter 上的功能请求

计算机使用在云端软件工厂中的价值，与其说是作为独立 agent，不如说是作为一种能力提供给工厂流程中的其他 agent。具体来说，计算机使用的价值在于：

• 在分类阶段，先复现 bug 再尝试修复

• 在实施阶段，验证修复效果并验证新功能是否符合规格

• 在审查阶段，向人工审查者证明代码确实符合预期行为

验证尤其有价值，因为它能减轻代码审查负担。如果你能看到功能运行的视频，你就更有可能信任底层代码（尽管你仍然需要审查代码，以确保架构良好、代码整洁安全等）。特别是对于风险较低的纯 UI 变更，从用户角度提供功能正常运行的“证据“非常有价值，而且节省时间。

计算机使用另一个不太明显的好处是，它能让 agent 创建一个循环，自行调试修改。这在规格驱动开发中尤其有效，当你有一份详细的 PRODUCT.md 让 agent 去实现时。在每次实施迭代中，它都可以运行计算机使用来检查实现与规格的接近程度，并持续迭代直到满足要求。你需要在这里监控成本，因为这可能会很昂贵，但它确实提高了成功率。

与之前的文章一样，你可以按照开源 demo 在你自己的仓库中使用这套实现。有一个技能你可以安装，然后从你喜欢的编码 agent 中调用，直接在你自己的仓库上完成所有设置：

npx skills add warpdotdev-demos/cloud-factory-demo –skill oz-cloud-factory-demo

为你的 agent 添加计算机使用验证

深入探讨计算机使用，我们创建了一个名为 verify-behavior 的新技能，它定义了如何使用计算机和浏览器操作。

verify-behavior 技能

该技能的关键方面包括：

• 何时使用计算机操作（桌面和移动原生应用）vs. 浏览器操作（Web 应用）

• 要捕获什么：最好是视频，但截图也可以

• 两种使用模式：

• **reproduce（复现）：**尝试确认报告的 bug 确实发生

• **verify（验证）：**验证新行为

为了让这个技能发挥作用，它需要通过支持计算机和浏览器操作的 harness 来运行。由于我们正在构建一个云端软件工厂，这应该是一个支持云 agent 的 harness。与之前的文章一样，我们使用 Warp 的云 agent 平台，但其他平台也支持此功能。

此时，你可以直接运行 verify-behavior 技能，但更有用的做法是将其挂钩到工厂中的其他 agent，作为它们可以利用的能力。为此，我们将更新现有的 Triage、Review 和 Implementation 技能，鼓励它们在有助于完成工作时使用 verify-behavior 技能。

例如，我们可以更新 Triage 技能来尝试复现 bug：

并更新 Implementation 技能来验证新功能：

请注意，verify-behavior 技能使用云 subagent。你也可以在本地执行计算机操作，但体验往往较差，除非你使用的平台可以在后台测试（否则它会抢占焦点，在运行时让你无法做任何事）。Warp 和 Codex 确实支持这一点，但根据我的经验，最好还是在云端机器上执行计算机操作，这样 agent 就不会对你本机运行的应用程序做出任何奇怪的操作。

对于复杂或新的行为，我们要求编排器进行扇出，独立且并行地验证所有用户故事（你的 harness 需要支持多 agent 编排才能实现这一点）。计算机操作通常是单线程的，所以如果你想获得更好的吞吐量，最好将云 agent 扇出到多台机器上。这可能会很昂贵，但非常酷，而且能大幅减少延迟。

计算机使用实战

我有一个演示仓库，在之前的几篇文章中使用过，它使用 Nano Banana 实现了一个简单的基于 agent 的图像编辑器。

作为第一个用户故事，我将展示如何使用计算机操作来验证一个问题。在这个案例中，演示应用有一个 bug：上传图片后，其预览以缩略图大小渲染，而不是画廊大小。报告此问题的 GitHub issue 在这里。

这里的 agent 能够运行并生成显示问题行为的截图：

复现问题的初始状态

复现问题的初始状态

显示错误缩略图的截图

显示错误缩略图的截图

这是一个简单的例子，但对于处理 bug 报告的人来说，自动生成图像来验证复现是一个巨大的突破。如果你好奇 agent 的追踪记录是什么样子，可以在这里查看生成这些图像的原始云 agent 运行。

接下来是第二个用例，我让一个 agent 在这个仓库中端到端地实现一个新功能，并使用计算机操作进行验证。该功能在这个 issue 中有描述，是一个相对简单的 UI 变更，为图像编辑器添加“清除“和“替换“控件。issue 中有明确的验收标准供验证者检查：

verify-behavior 需要检查的验收标准

PR 本身包含显示这些控件的截图，以及一个证明它们正常工作的视频链接。

这是 agent 生成的视频，展示了该功能的端到端运行：

就是这么简单——一旦你搭建好了脚手架，就可以使用计算机操作来减轻 PR 审查的负担。事实上，对于低风险的 UI 变更，你可能会认为观看这些视频就足够了，根本不需要查看代码。

回顾一下，我们已经创建了以下 agent：

• 对新的 issue 进行分类，可选择将其发送去实施或编写规格

• 从产品和技术的角度编写 issue 规格

• 实施实际代码

• 审查代码，并通过观察者循环不断改进审查

现在我们又添加了一项验证能力，所有其他 agent 都可以使用它来确保实现是正确的，并让人工审查者看到功能如何工作的记录。

这些文章展示了如何通过一组简单的原语，开始构建你自己的工厂，并真正自动化更多繁琐的工作。这些原语就是：

• 一个像 Warp 这样支持计算机操作的云 agent 平台

• 一个像 GitHub Actions 这样的工作流工具

• 一套你和 agent 可以共同调优的 agent 技能

本系列的下一篇文章将展示如何通过添加 agent 来扩展这个工厂，这些 agent 在功能和修复发布后进行监控，并将监控结果反馈到 Triage 阶段，从而形成一个基本的工厂闭环。