QA Wolf 的 agent-first design：让 UI 主动来到用户面前

当我开始试用我们的 MCP 时，我意识到我们的用户体验在编码代理中完全失效了。修复它让我们走向了一种新的设计方式：代理优先设计。UI 会来到你的代理身边，就在你正在工作的地方。

退一步说：QA Wolf 是一个用于构建、运行和维护端到端测试的代理和基础设施。直到最近，你都是通过我们的应用来管理测试套件的。如果开发者或测试人员想构建一个新测试，他们会登录 app.qawolf.com 并与代理对话。

但这已经不是人们现在的工作方式了。现在我们有编码代理（Claude、Cursor、Codex 等）全天运行，四处奔走为我们做事。

我从设计到开发再到测试，一切都在编码代理或 CLI 中完成。虽然我会针对不同任务使用不同的代理和工具，但大部分工作都在一个窗口里——这些工具的用户体验必须无缝融入其中。

我们的用户体验在哪里出了问题

我第一次在编码代理中打开一个测试时，它把整个平台都带了过来：一级和二级导航层、测试元数据、视频回放以及其他历史运行产物。如果我在应用内工作，这很棒。但现在我是通过编码代理来操控工作，它通过 MCP 获取上下文。

用于启动和管理测试的导航和控件占用了空间，并且重复了大量我正用编码代理完成的功能。

于是我们开始把 UI 精简为面向任务的视图，只展示当前任务所需的基本内容：测试、运行它的浏览器、其进度和结果，以及当某件事需要我们关注时的明确请求。每个视图都必须能独立成立，能放在代理对话旁边，并让我们无需浏览平台其余部分就能审查工作。它必须补充当前会话，而不是在分屏视图中感觉像一个独立应用。

虽然我的大部分开发工作都在编码代理中进行，但我也会在 Slack、GitHub 和 Linear 之间来回切换。而且我通过它们向各种代理发送任务。将 UI 简化为聚焦视图，可以让代理无论用户身在何处，都能直接把他们带到所需信息。

你仍然可以完全在 QA Wolf 内工作，使用我们的聊天来创建测试、跟踪进度并审查结果。无论你在哪里工作，创建、跟踪和审查测试都需要相同的信息，因此聚焦测试视图也成为重新设计我们应用内体验的起点。

弄清楚该视图中应包含什么，也迫使我们重新审视周边功能。有些在应用的其他地方仍有用途。另一些则为我们已经可以通过代理和聚焦 UI 完成的工作增加了步骤。我们可以砍掉这些功能，并简化两个地方的工作流。

这感觉很像移动优先设计。这一次，我们要适配的是代理的浏览器窗格，位于对话旁边，而不是手机屏幕。这种约束让我们重新思考什么是必不可少的。简化那一个视图，成了简化整个产品的机会。

这就是我们从构建 MCP 中学到的更大教训：设计产品，让你的代理能够把你需要的 UI 带到你正在工作的地方。

‍