Cursor 把开发环境当产品做给 agent：anydev CLI 屏蔽杂乱构建脚本，Cloud Doctor 用 MCP 自愈环境故障——cloud agent 现在贡献了他们超过一半的合并 PR。

《我们如何搭建 cloud agent 环境》

当我们决定给 cloud agent 配备自己的电脑，让它们能测试自己的修改时，第一步是先确保它们在我们自己的代码库里能把这件事做好。

把我们的 monorepo 跑通 cloud agent 的过程教会我们一件事：开发环境本身就是一个产品，只不过用户是 agent。你需要让云端环境与本地开发对齐，让代码库足够清晰、agent 不需要靠口口相传的隐性知识就能跑通和测试代码，并且在代码库不断变化的过程中保持这个环境的健康。

建设这个环境改变了我们的工作方式。去年 12 月，cloud agent 在 Cursor monorepo 合并的 PR 中大约占十分之一。今天，它们贡献了超过一半。

让云端对齐本地开发

让 cloud agent 在我们的代码库里好用的第一步，是让代码库在云虚拟机里好用。这一步对于每一个第一次搭远程开发环境的工程师来说都不陌生。

大多数 Cursor 开发者在 Mac 上做本地开发，但我们的云虚拟机跑的是 Linux。这意味着我们需要把各种开发工具和初始化脚本做跨平台适配，让它们在 Ubuntu 虚拟机上正常工作。我们把关键的开发依赖加到了一个由 Cursor 定义的 Dockerfile 里，作为 cloud agent 的启动镜像。

我们还和安全团队合作，为 cloud agent 产品增加了安全能力，让用户可以放心地把必要的密钥注入 agent 的运行环境。这些能力包括：网络出口限制、受限且经过代理的 git 远程访问、对提交内容和提交信息进行密钥扫描，以及在工具结果中对密钥做脱敏——即使 agent 试图读取密钥值也读不到。

给 agent 一个更简单的界面

即便把开发环境在 Ubuntu 虚拟机上跑通了，agent 在运行我们代码时依然很糟糕。这并不意外，因为我们的开发体验一团乱——涉及学习和记忆大量构建命令、构建参数和辅助脚本。

我们为系统的许多部分编写了 skill，说明如何构建和运行，但这只是杯水车薪。skill 可以记录正确的命令，但那些命令本身就很绕，而且布满暗坑。

为了降低复杂性，我们写了一个叫 anydev 的 CLI，agent 可以用它来启动所有服务。我们也把常用的辅助脚本路由到 anydev 里面，并为 anydev 配了多层 –help 菜单，解释每个子命令的用法。anydev 还有一个 supervisor 进程，监控并自动重启长时间运行的构建命令，彻底把这件事从模型的职责范围内拿掉了。

anydev 让开发体验简单到了 agent 能可靠运行自己代码的程度。skill 帮助记录了怎么用它，但更大的变化是：agent 不再需要同时应付各种生僻的多步构建命令、躲避隐藏的暗坑、守着长期运行的进程了。

就是从这个时候起，每个 cloud agent 有了自己的电脑，开始相比本地 agent 产生真正的增值。有了 computer use、录屏工具和能用的开发环境，agent 终于可以端到端地测试自己的修改，并向用户证明自己工作的正确性。

它们还可以在有人修了 bug 后把 agent 录制的演示发到 Slack，或者在提 PR 时附上。对于很多任务，工程师现在可以放心地合并和部署 cloud agent 的代码，根本不需要在本地把分支 checkout 下来。

一个能自愈的环境

agent 所处的环境始终在变化，要保持它处于可用状态，就意味着要持续更新它的运行方式和它能访问的内容。

为了在环境出现故障时诊断和恢复，我们构建了 Cursor Cloud MCP。我们选 MCP 的原因是它提供了动态可发现的工具，接口可以随时变更而不需要重建 agent 循环。cloud agent 用它来检查自己的环境——包括启动失败、出口策略、密钥变更等等。这让它们在问题出现时就能诊断并修复，更快地恢复不健康的环境。

有了 Cursor Cloud MCP，我们搭建了一个叫 Cloud Doctor 的自动化任务，它定期检查故障、记住哪些错误可能是偶发的还是实质性的、做根因分析，并且可以在高置信度的情况下直接开 PR 来修复问题。

改进 agent 的开发体验

即便环境是健康的，agent 有时也会走很绕的路去验证自己的修改。它们可能用错了 skill、碰到虚拟机里本来可以避免的问题，或者遵循了比必要时间更长的流程。

这里我们同样用了 Cursor Cloud MCP。Cloud Doctor 会检查 agent 的执行轨迹，找出另一个 agent 在哪里走错了、哪些 skill 或命令产生了误导、哪些流程系统性地慢。有了这些发现，Cloud Doctor 就去修 skill、简化路径，或者改环境，让下一个 agent 更容易。

这个循环持续改进着 agent 自己的开发体验。当环境是健康的、能自愈的，agent 就能可靠地运行，开发者也就敢把更重要的工作交给 cloud agent。

这让我们在内部规模化推广了 cloud agent 的采用，到今天它们已经贡献了我们发布代码的大多数。

怎么让你的环境为 cloud agent 做好准备

cloud agent 在我们这里生产力的核心来源是环境。想知道你的代码库准备好了没有，可以先回答三个问题：

1. agent 能访问到开发者会用的所有工具和数据吗？
2. agent 能找到记录了你们开发者实际怎么工作的 skill 吗？
3. agent 能测试和验证核心工作流吗？

如果你需要帮助来准备好你的环境，欢迎联系我们。或者想了解更多，可以阅读 Faire 怎么用 cloud agent 把每周 PR 吞吐量翻了一倍。

原文：https://cursor.com/blog/cloud-agent-environment… #Cursor #CloudAgent #Agent工程

How we set up our cloud agent environment

Source: https://cursor.com/blog/cloud-agent-environment When we decided togive cloud agents computersso they could test their changes, the first step was to make sure they were good at testing them in our own codebase.

Getting our monorepo working for cloud agents taught us that the development environment is a product in its own right, only one whose users are agents. You have to make cloud match local development, make the repo legible enough that agents can run and test code without tribal knowledge, and keep that environment healthy as the codebase changes.

Building that environment has changed the way we work. In December, cloud agents authored roughly one in ten PRs merged to the Cursor monorepo. Today, they write more than half.

https://cursor.com/blog/cloud-agent-environment#matching-cloud-to-local-developmentMatching cloud to local development

The first step to making cloud agents work well in our repo was making our repo work well in a cloud VM. This stage is familiar to any engineer who has set up a remote development environment for the first time.

Most Cursor devs develop locally on Mac machines, but our cloud VMs run on Linux. This meant we had to agnosticize various dev utilities and setup scripts to work on Ubuntu VMs. We added critical dev dependencies to a Cursor-defined Dockerfile that serves as the starting image forcloud agents.

We also worked with our security team to add security features to the cloud agent product, so that users could confidently inject required secrets into the agent’s environment. These features include network egress restrictions, scoped and proxied git remote access, secret scanning in commits and commit messages, and secret redaction in tool results, which prevents the agent from reading secret values even if it tries.

https://cursor.com/blog/cloud-agent-environment#a-simpler-interface-for-agentsA simpler interface for agents

Even after we had our dev setup working on Ubuntu VMs, agents were still bad at running our code. This wasn’t surprising, because our devex was messy and involved learning and remembering numerous build commands, build flags, and utility scripts.

We wrote skills for how to build and run many parts of the system, but this only helped on the margins. Skills can document the right commands, but those commands themselves were convoluted and filled with footguns.

To reduce that complexity, we built a CLI called anydev, which agents can use to start all services. We route common utility scripts through anydev as well, and equipped anydev with multiple\-\-helpmenus explaining how to use each subcommand. anydev also has a supervisor process which monitors and restarts long-running build commands, removing that responsibility from the model entirely.

anydev made the development experience simple enough that agents could run their code reliably. Skills helped document how to use it, but the bigger change was that agents no longer had to juggle niche multi-step build commands, dodge hidden footguns, or babysit long-running processes.

This is when cloud agents, each with their own computer, began to add real value over local agents. With computer use, their recordScreen tool, and a working dev environment, agents could now test their changes end-to-end, and prove the correctness of their work to the user.

They could also share agent-recorded demos in Slack when someone fixed a bug report, or on a PR when they opened a change. For many tasks, engineers could now confidently merge and deploy cloud agent code without ever checking out the branch locally.

An internal cloud agent uses Cursor agents in its cloud environment to test improved agent session retries.## https://cursor.com/blog/cloud-agent-environment#a-self-healing-environmentA self-healing environment

The environment around the agent is always changing, so keeping it operational means continually updating how it runs and what it can access.

To diagnose and recover unhealthy environments as they fail, we builtCursor Cloud MCP. We chose MCP because it gave us dynamically discoverable tools with interfaces we could change without rebuilding the agent loop. Cloud agents use it to inspect their own environment for setup failures, egress policy, changed secrets, and more. That lets them diagnose and fix issues as they emerge, and recover unhealthy environments sooner.

With Cursor Cloud MCP in place, we set up anautomationcalled Cloud Doctor, which periodically checks for failures, remembers which errors might be transient versus salient, does root cause analysis, and can open PRs to fix issues with high confidence.

https://cursor.com/blog/cloud-agent-environment#improving-agent-experienceImproving agent experience

Even with a healthy environment, agents sometimes take long or contrived routes to verify their changes. They may use the wrong skill, hit avoidable issues in the VM, or follow workflows that take longer than they should.

We use Cursor Cloud MCP here as well. Cloud Doctor agents inspect traces to find where another agent went wrong, which skills or commands were misleading, and which workflows are systematically slow. From those findings, Cloud Doctor fixes the skill, simplifies the path, or changes the environment so the next agent has an easier time.

That loop keeps improving the developer experience of the agents themselves. When the environment is healthy and self-healing, agents run reliably and developers trust cloud agents with more important work.

That’s allowed us to scale adoption of cloud agents internally, such that they now author a majority of the code we ship.

https://cursor.com/blog/cloud-agent-environment#making-your-environment-ready-for-cloud-agentsMaking your environment ready for cloud agents

Most of what makes cloud agents productive for us comes down to the environment. To find out whether your codebase is ready, start by answering three questions:

1. Do agents have access to the same tools and data a developer would?
2. Can agents find skills that document how your developers actually work?
3. Can agents test and verify core workflows?

If you’d like help getting your environment ready,please get in touch.

Or, to learn more, read how Fairedoubled weekly PR throughputwith cloud agents.