10-智能体手动测试

编程智能体最核心的特征在于它能够执行它所编写的代码。这正是编程智能体比那些只会吐出代码却无法验证的普通 LLM 更有用的原因。

在 LLM 生成的代码被执行之前，永远不要假设它是可以运行的。

编程智能体有能力确认它们产出的代码是否按预期工作，或者在达到预期之前对代码进行进一步迭代。

让智能体编写单元测试（尤其是使用测试先行 TDD）是确保它们检验过所写代码的一种强有力方式。

然而，这并不是唯一值得采用的方法。

仅仅因为代码通过了测试并不意味着它就完全符合预期。任何处理过自动化测试的人都见过这种情况：测试全部通过，但代码本身却以某种显而易见的方式失败了——它可能在启动时导致服务器崩溃、未能显示关键的 UI 元素，或者遗漏了测试未能覆盖的某些细节。

自动化测试无法取代手动测试。我喜欢在功能正式发布之前，亲眼看到它正常运行。

我发现让智能体进行手动测试也极具价值，经常能揭示自动化测试未能发现的问题。

智能体应该如何“手动”测试一段代码，取决于该代码的性质。

对于 Python 库，一个有用的模式是 python -c "... code ..."。你可以直接将一段 Python 代码字符串（或多行字符串）传递给 Python 解释器，包括导入其他模块的代码。

编程智能体都熟悉这个技巧，有时甚至不经提示就会使用。不过，提醒它们使用 python -c 进行测试通常非常有效：

使用 python -c 在一些边界情况上测试那个新函数。

其他语言可能也有类似的机制；如果没有，智能体编写一个演示文件然后编译运行也很快。我有时会鼓励它使用 /tmp 目录，纯粹是为了避免这些临时文件稍后被意外提交到仓库中。

在 /tmp 中编写代码来测试该函数的边界情况，然后编译并运行它。

我的许多项目涉及构建带有 JSON API 的 Web 应用程序。对于这些项目，我会告诉智能体使用 curl 来检验它们：

运行开发服务器并使用 curl 探索那个新的 JSON API。

告诉智能体去“探索”（explore）通常会让它尝试新 API 的各种不同方面，从而快速覆盖大量内容。

如果智能体通过手动测试发现了不工作的地方，我喜欢告诉它们用“红/绿 TDD”来修复它。这确保了新的用例最终会被永久性的自动化测试所覆盖。

如果项目涉及交互式 Web UI，建立手动测试流程就变得更加重要。

从历史上看，通过代码测试 UI 一直很困难，但过去十年中，自动化真实浏览器的系统有了显著改进。针对应用程序运行真实的 Chrome、Firefox 或 Safari 浏览器，可以在现实环境中发现各种有趣的问题。

编程智能体非常擅长使用这些工具。

目前其中最强大的是 Playwright，这是一个由微软开发的开源库。Playwright 提供了功能齐全的 API，支持多种流行编程语言，并能自动化任何主流浏览器引擎。

只需告诉你的智能体“用 Playwright 测试那个”可能就足够了。智能体随后会选择最合适的语言绑定，或者使用 Playwright 的 playwright-cli 工具。

编程智能体与专用 CLI 配合得非常好。Vercel 开发的 agent-browser 是一个围绕 Playwright 的综合 CLI 封装，专门设计给编程智能体使用。

我自己的项目 Rodney 也有类似用途，尽管它是通过 Chrome DevTools 协议直接控制 Chrome 实例。

这是我使用 Rodney 测试时的一个提示词示例：

启动开发服务器，然后使用 uvx rodney --help 来测试新首页，查看截图以确认菜单位置是否正确。

这个提示词中有三个技巧：

使用 uvx rodney --help：这会让智能体通过 uvx 包管理工具运行 Rodney，该工具会在第一次调用时自动安装它。
rodney --help 指令：它专门设计用于向智能体提供理解和使用该工具所需的所有信息。
“查看截图”：这暗示智能体应该使用 rodney screenshot 命令，并提醒它可以使用自己的视觉能力处理生成的图像文件，以评估页面的视觉外观。

短短一个提示词就涵盖了大量的手动测试内容！

Rodney 及其类似工具提供了广泛的功能，从在加载的站点上运行 JavaScript 到滚动、点击、键入，甚至读取页面的无障碍树（Accessibility Tree）。

与其他形式的手动测试一样，通过浏览器自动化发现并修复的问题，随后也可以添加到永久性的自动化测试中。

过去，由于浏览器自动化测试容易“变脆”（Flakiness）——HTML 的极小改动就可能导致大面积测试失败——许多开发者对此避之不及。而让编程智能体来长期维护这些测试，大大减少了在 Web 界面设计变更时保持测试同步的阻力。

让智能体手动测试代码可以捕捉额外的问题，但它也可以用来创建帮助记录代码文档并证明其已通过测试的产出物。

我一直对如何让智能体“展示它们的工作过程”（show their work）这一挑战很感兴趣。能够看到演示或记录下来的实验过程，是确认智能体已全面解决所给挑战的一种非常有效的方式。

我构建了 Showboat 来辅助构建记录智能体手动测试流程的文档。

这是我经常使用的一个提示词：

运行 uvx showboat --help，然后创建一个 notes/api-demo.md Showboat 文档，并用它来测试和记录那个新 API。

与上面的 Rodney 类似，showboat --help 命令会教会智能体 Showboat 是什么以及如何使用它。Showboat 有三个关键命令：note、exec 和 image。

其中 exec 命令最为重要，因为它捕获了命令及其产生的结果。这向你展示了智能体做了什么以及结果是什么，旨在防止智能体“作弊”——即在文档中写下它希望发生的事，而不是实际发生的事。

我发现 Showboat 模式在记录智能体会话期间完成的工作方面效果非常好。我希望看到类似的模式被更多工具所采纳。

原文：Agentic Engineering Patterns by Simon Willison

关注公众号「Python之禅」，回复「1024」免费获取Python资源