我们从在 Devin 的虚拟机中构建端到端测试能力中学到了什么。
3 个月前，我加入 Cognition 帮助打造软件工程的未来。自从 Devin 作为首位 AI 软件工程师推出以来，已经取得了长足的进步，而亲眼看到团队每天实际使用 Devin 的过程让我惊叹不已。
最让我印象深刻的一点是 Devin 如何自主地在云端使用其计算机来验证工作。从验证我们的 Slack 集成到测试复杂的 Windsurf 功能，团队始终有一支 Devin 大军处于测试模式。在这篇文章中，我将分享为什么我们如此专注于云端 Agent 的端到端验证，以及我们如何构建这一能力。
转向异步软件工程
在 Cognition，我们最近达到了一个新的里程碑。首次，通过事件、自动化、调度和其他 Devin 触发的异步 Devin 数量超过了同步触发的数量。我们预计这一趋势会随着我们最近推出的 Auto-Triage 而进一步加速。
随着我们向异步世界过渡，开发者能够回到经过验证并准备合并的结果变得至关重要。今年早些时候，我们推出了 Devin Review，这是一款代码审查工具，能够以人类的方式理解复杂的代码差异。它不仅能标记 bug——Devin 会闭环修复每一个发现，直到差异干净为止。但仅靠干净的审查往往不够——工程师希望看到变更经过端到端测试，就像他们自己测试一样。
当 Devin 在你甚至还没看到 bug 频道里的消息之前就提交了一个修复用户投诉的 PR 时，那种感觉非常棒。而更神奇的是，这个 PR 附带了修复确实有效的证据。这种神奇很快将成为必需品——随着主动 Agent 带来的 PR 越来越多，未经验证的变更很快就会变得难以管理。
从一开始
自 Devin 推出以来，它一直能够在云端虚拟机上展示其工作成果。大约 6 个月前，我们扩展了 Devin 的计算机使用能力。具体来说，我们在 Devin 的工具链中增加了截图、移动鼠标、点击、拖拽、打字、按键、滚动、等待、缩放以及开始/停止录制等功能。计算机使用功能已经存在了一段时间，但我们发现前沿实验室的最新一批模型已经开始真正擅长使用这些工具。
计算机使用为 Devin 解锁了一些有趣的新能力，比如构建并运行桌面游戏，或者使用浏览器在 Amazon 上订购产品。但我们注意到的真正突破是 Devin 测试自身工作的能力。Devin 会启动应用，点击操作，然后确认其更改是否真的有效——就像工程师一样。这一切都在云端运行，可以并行扩展。当我看到工程师们同时运行 10 到 20 个 Devin，每个都有独立的开发服务器，处理不同的变更时，我深受震撼——这是单台笔记本电脑根本无法做到的。自动化云端测试为我们节省了大量时间，因为我们再也不需要在本地运行和验证代码了。
说实话，达到这个地步并不顺利。我们一路上遇到了许多失败模式，每一种都教会了我们如何让这个系统更可靠。
提高可靠性
在早期版本中，Devin 在测试时很容易偏离轨道。这种情况以各种方式发生：过度测试产品中不相关的部分，在设置阶段迷失方向，或者干脆遗漏了 PR 本应更改的核心行为。
为了解决这个问题，当 Devin 进入测试模式时，我们让它首先写出一个测试计划，详细说明要测试的明确目标。这个计划必须基于源代码，而不是假设。如果没有代码作为基础，我们发现模型容易假设可以走一些应用中不存在的路径。此外，测试计划大大增加了 Devin 能够成功测试的变更复杂度。我们一些最雄心勃勃的请求包括需要多个服务同时运行、特定管理员设置已配置好、以及正确的标志已启用，才能访问到行为本身。通过事先阅读代码，Devin 更有可能正确设置环境，而不是在测试中途才发现缺少某些东西。测试计划起到了一种预对齐的作用，使 Devin 在主动测试时不太容易偏离。
当 Devin 执行计划时，它会在时间线中添加自己的注释。这些包括设置笔记、每个命名测试的开始、以及标记为通过、失败或未测试的断言。我们发现，如果 Devin 在执行动作之前就注释出其预期的行为，它就不太可能对自己的发现撒谎——这很像测试驱动开发，如果你事先承诺了预期结果，就很难把意外的结果说成是通过。
测试流程中的某些部分几乎每次运行都会重复。登录是一个经典例子：通过计算机使用驱动登录表单通常意味着输入电子邮件、完成 SSO、点击重定向、并在每次页面加载后截图等待。这在时间和 Token 上可能代价高昂。为了提高这些操作的可靠性和成本，Devin 将这项工作提取到了一个确定性脚本中，该脚本位于我们仓库中的一个测试技能中。这样，Devin 可以在几秒钟内运行脚本并获得一个已验证的浏览器会话，然后直接进入测试的核心部分。这些脚本的确定性极大地降低了测试的波动性。我们还更新了 Devin，让它也能自己闭环这个流程。当它通过艰难的方式弄清楚一个设置步骤时，Devin 可以建议将该知识作为测试技能保存到仓库中，并以一键 PR 的形式向用户提出修复。
我们还在尝试将测试阶段路由到不同的模型。由于测试更依赖于与编写代码不同的能力，比如阅读截图、跟踪 UI 状态以及决定下一步浏览器操作，一些模型在这方面比典型的代码编辑模型更擅长。
今天如何使用 Devin 的自主测试
Devin 目前通过两种方式进入测试模式：显式要求测试变更，或者在 Devin 创建 PR 后会主动提供测试变更的机会（如果适用）。然后，它会创建测试计划并开始工作。
很多时候，当你刚开始使用 Devin 的测试能力时，它需要你的协助。一个很好的例子是，当它在本地运行你的应用时需要密钥。为了让这个过程更顺畅，Devin 能够在会话中向你询问任何凭据或其他缺失的信息。对于更复杂的情况，你可以接管 Devin 的计算机并输入 OTP 码等。好消息是，一旦 Devin 完成对仓库的设置，它就能保存一个声明式配置（YAML 蓝图格式），为每个未来的会话生成一个快照供启动使用。
你能得到什么
当 Devin 完成测试后，它不仅仅是告诉你应用是否正常工作。原始的屏幕录像很有用，但我们觉得仅此还不够——你需要理解你在看什么、为什么 Devin 采取了每个动作、以及测试的哪些部分通过了或失败了。
为了快速审查，Devin 会返回一份测试报告，其中包含运行过程中关键时刻的带标签截图，这样你可以快速看到 Devin 测试了什么，以及应用当时的状态。
如果你想要更深入的审查，Devin 还会生成一个测试视频，带有一个丰富的播放器 UI，包含章节让你可以在测试区段间跳转、浏览整个运行过程、以及以时间顺序列表视图检查通过或失败的断言。在后处理中，动作之间的空闲时间被压缩，而动作周围的时间则以正常速度播放。这样，一个长时间的运行会被压缩成一段你可以实际观看的录像。这些产物可以通过我们的网页界面查看，如果 Devin 是从 Slack 启动的，也会分发到 Slack 中。
硬边界
计算机使用仍然存在硬边界。一个例子是时机——如果 Devin 正在测试一个 toast 通知，截图太早或太晚可能完全错过 toast，模型可能会对预期行为是否真的发生感到困惑。
另一个失败模式是作弊。如果放任不管，模型有时可能过度依赖在浏览器中执行 JavaScript 来以编程方式触发状态，而不是通过 UI 点击。这虽然有助于测试功能，但用户通常希望看到 Devin 像真实用户一样操作应用。
我们正通过改进评估、在工具链中增加更严格的护栏、以及每代新模型在计算机使用方面变得更好，积极解决这些问题。
异步开发的未来是经过验证的
在过去的几个月里，Devin 上每天批准的测试运行次数增加了一倍多。这种增长反映了一个简单的事实：异步 Agent 只有在其返回的结果能被开发者信任时才有用。通常这种信任不能仅来自代码：对于许多变更，你希望知道应用确实被运行了，重要的流程被测试了，并且结果以易于检查的方式被捕获。
这就是 Devin 中自主测试设计的目的。Devin 制定测试计划、操作应用、记录并注释发生的一切，最后返回使结果可审查的产物。虽然还有很多需要改进的地方，但我们认为这代表了未来的正确方向：Agent 不仅异步完成工作，还附带证明。
我们不断惊讶于 Devin 通过测试自身工作为我们节省了多少时间，同时觉得很多客户仍然没有充分利用 Devin 的自动化测试功能。为了支持实验，目前我们在测试模式下只收取正常使用成本的 1/5。
试试我们的产品：devin.ai 或 windsurf.com。如果你觉得解决这类问题很有趣，请联系 ido [at] cognition.ai
