🔶 Agent-first 设计：把 UX 带到用户身边

当我开始内部试用我们的 MCP 时，我意识到：我们的 UX 在编程 Agent 内部完全失效了。为了解决这个问题，我们形成了一种新的设计方式：Agent-first 设计。UI 会来到你的 Agent 中，就在你已经工作的地方。

先稍微退一步说明：QA Wolf 是一个用于构建、运行和维护端到端测试的 Agent 与基础设施。在不久之前，你仍需要通过我们的应用来管理测试套件。如果开发者或测试人员想要构建一项新测试，他们会登录 app.qawolf.com，并与 Agent 对话。

但人们如今已经不再以这种方式工作了。现在，编程 Agent（Claude、Cursor、Codex 等）整天都在运行，从各个方向替我们完成工作。

我从设计、开发到测试，所有事情都在编程 Agent 或 CLI 中完成。虽然我会针对不同任务使用不同的 Agent 和工具，但绝大多数工作都集中在一个窗口中——这些工具的用户体验必须能够无缝融入其中。

我们的 UX 在哪里失效了

我第一次在编程 Agent 中打开一项测试时，整个产品平台也随之被带了进来：主导航和次级导航层、测试元数据、视频回放以及其他历史运行产物。如果我是在应用内部工作，这些内容当然很好。但现在，我是通过编程 Agent 来协调这项工作，而 Agent 则通过 MCP 获取上下文。

用于启动和管理测试的导航与控制项占据了空间，而且与我通过编程 Agent 已经能够完成的许多功能重复。

因此，我们开始精简 UI，改为面向任务的视图，只显示当前任务所必需的信息：测试本身、运行测试的浏览器、测试进度和结果，以及在需要我们关注时给出的明确请求。每个视图都必须能够独立成立，适合与 Agent 对话并排显示，并让我们无需在平台其余部分中导航，就能审查工作结果。它必须补充当前会话，而不是像分屏中的另一个独立应用。

聚焦视图可在任何上下文中工作

虽然我的大部分开发工作都在编程 Agent 内完成，但我也会在 Slack、GitHub 和 Linear 之间切换。我还会通过这些平台向不同的 Agent 发送任务。将 UI 简化为聚焦视图后，Agent 无论用户身处何处，都可以直接将其带到所需的信息面前。

为 MCP 体验而设计，也让整体 UI 更简洁

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

梳理哪些内容应属于该视图，也迫使我们重新审视周边功能。其中一些功能在应用的其他场景中仍有用途；另一些功能则为原本已经能够通过 Agent 和聚焦 UI 完成的工作增加了步骤。我们可以移除这些功能，并同时简化两个入口中的工作流。

这很像移动优先设计。只是这一次，我们不是要适配手机屏幕，而是要适配 Agent 浏览器窗格中、对话旁边的空间。这种约束促使我们重新思考什么才是必需的。简化这一个视图，最终成为简化整个产品的机会。

这是我们从为 MCP 构建设计中得到的更大启示：应当设计出这样一种产品——让你的 Agent 能够在用户已经工作的地方，带来他们所需要的 UI。

When I started dogfooding our MCP, I realized our UX was completely broken inside a coding agent. Fixing it led us to a new way of designing: agent-first design. The UI comes to your agent, right where you’re already working.

Stepping back for a second: QA Wolf is an agent and infrastructure for building, running, and maintaining end-to-end tests. Up until recently you managed your test suite through our app. If developers or testers wanted to build a new test, they’d log into app.qawolf.com and talk to the agent.

But that’s not how people work anymore. Now we have coding agents (Claude, Cursor, Codex, etc) going all day, running every which way doing things for us.

I do everything from design to development to testing inside a coding agent or CLI. While I’m using different agents and tools for different tasks, for the most part all my work is in one window—and the user experience of those tools has to fit into it seamlessly.

Where our UX broke

The first time I opened a test inside my coding agent, it brought the whole platform along with it: primary and secondary navigation layers, test metadata, video replays and other historical run artifacts. Great if I’m doing work inside the app. But now I’m steering the work through my coding agent and it’s getting context through the MCP.

The navigation and controls for starting and managing tests were taking up space and duplicated a lot of the functionality I was using my coding agent to accomplish.

So we started stripping the UI down to task-oriented views showing just the essentials for the task at hand: the test, the browser where it runs, its progress and results, and a clear request when something needed our attention. Each view had to make sense on its own, fit beside the agent conversation, and let us review the work without navigating through the rest of the platform. It had to complement the active session, not feel like a separate app in a split view.

Focused views work within any context

While most of my development work happens inside a coding agent, I’m also bouncing between Slack, GitHub, and Linear. And I send tasks to various agents through all of them. Simplifying the UI into focused views lets an agent take a user directly to the information they need, from wherever they happen to be.

Designing for an MCP experience created a cleaner UI overall

You can still work entirely inside QA Wolf, using our chat to create tests, follow their progress, and review the results. Creating, following, and reviewing a test needs the same information wherever you're working, so the focused test view became the starting point for redesigning the experience inside our app too.

Working out what belonged in that view also forced us to revisit the surrounding features. Some still had a purpose elsewhere in the app. Others added steps to work we could already complete through the agent and the focused UI. We could cut those features and simplify the workflow across both places.

It felt a lot like mobile-first design. This time, we were fitting into the agent's browser pane beside a conversation instead of a phone screen. The constraint made us reconsider what was essential. Simplifying that one view became an opportunity to simplify the product.

That’s the larger lesson we took from building for MCP: design the product so your agent can bring you the UI you need, right where you're already working.

‍