为编码代理构建云环境（13分钟阅读）

# 我们如何搭建云端智能体环境 Source: https://cursor.com/blog/cloud-agent-environment 当我们决定给云端智能体提供计算机（https://cursor.com/blog/agent-computer-use），让它们能够测试自己的更改时，第一步就是确保它们善于在我们自己的代码库中测试这些更改。 让我们的 monorepo 为云端智能体工作，给了我们一个启发：开发环境本身就是一种产品，只不过它的用户是智能体。你必须让云环境与本地开发保持一致，让仓库足够清晰易读，使智能体无需依赖隐性知识就能运行和测试代码，并在代码库不断变化时保持环境健康。 构建这样一个环境改变了我们的工作方式。去年 12 月，云端智能体撰写了约十分之一合并到 Cursor monorepo 的 PR。如今，它们写的 PR 超过了一半。 ## [让云环境与本地开发保持一致](https://cursor.com/blog/cloud-agent-environment#matching-cloud-to-local-development) 要让云端智能体在我们的代码库中良好工作，第一步就是让我们的代码库能够在云端 VM 中良好运行。这一阶段对于任何第一次搭建远程开发环境的工程师来说都很熟悉。 大多数 Cursor 开发者在 Mac 上本地开发，但我们的云端 VM 运行在 Linux 上。这意味着我们必须对各种开发工具和安装脚本进行平台无关化处理，使它们能够在 Ubuntu VM 上工作。我们将关键的开发依赖添加到一个由 Cursor 定义的 Dockerfile 中，该文件用作云端智能体的起始镜像（https://cursor.com/docs/cloud-agent）。 云端智能体在其环境中安全运行 我们还与安全团队合作，为云端智能体产品添加了安全功能，使用户能够放心地将所需的机密信息注入智能体的环境。这些功能包括网络出口限制、有作用域且经过代理的 git 远程访问、对提交和提交信息进行机密扫描，以及在工具结果中编辑机密内容，从而即使智能体试图读取机密值也无法做到。 ## [为智能体提供更简单的接口](https://cursor.com/blog/cloud-agent-environment#a-simpler-interface-for-agents) 即使在我们将开发环境搭建到 Ubuntu VM 上之后，智能体仍然不擅长运行我们的代码。这并不令人意外，因为我们的开发者体验（devex）很混乱，需要学习和记忆大量的构建命令、构建标志和实用脚本。 我们编写了关于如何构建和运行系统中多个部分的技能（skills），但这只是在边缘有所帮助。技能可以记录正确的命令，但这些命令本身复杂繁琐，布满陷阱。 为了降低这种复杂性，我们构建了一个名为 anydev 的 CLI，智能体可以使用它启动所有服务。我们还将常见的实用脚本路由到 anydev 中，并为 anydev 配备了多个 `--help` 菜单，解释每个子命令的用法。anydev 还有一个监督进程，负责监控并重启长时间运行的构建命令，从而完全免除了模型在这方面的责任。 anydev 使开发体验足够简单，智能体可以可靠地运行代码。技能（skills）帮助记录了如何使用它，但更大的变化是，智能体不再需要同时处理各种小众的多步骤构建命令、躲避隐藏的陷阱，或者盯守长时间运行的进程。 正是在这时，每个拥有自己计算机的云端智能体开始展现出超越本地智能体的真正价值。借助计算机使用功能、recordScreen 工具和一个可用的开发环境，智能体现在可以端到端地测试它们的更改，并向用户证明其工作的正确性。 它们还可以在有人修复缺陷报告时，在 Slack 中分享智能体录制的演示视频，或者在打开更改的 PR 上分享。对于许多任务，工程师现在可以自信地合并和部署云端智能体代码，而无需在本地检出分支。 一个内部云端智能体在其云环境中使用 Cursor 智能体来测试改进后的智能体会话重试机制。 ## [自我修复的环境](https://cursor.com/blog/cloud-agent-environment#a-self-healing-environment) 智能体所处的环境总是在变化，因此要保持其可运行，就需要持续更新它的运行方式以及它可以访问的内容。 为了在环境出现故障时进行诊断和恢复，我们构建了 Cursor Cloud MCP（https://cursor.com/docs/cloud-agent/capabilities#cursor-cloud-mcp）。我们选择 MCP，是因为它为我们提供了可动态发现的工具，其接口可以在不重建智能体循环的情况下进行更改。云端智能体使用它来检查自身环境中的设置失败、出口策略、机密变更等问题。这让它们能够在问题出现时进行诊断和修复，并更快地恢复不健康的环境。 有了 Cursor Cloud MCP，我们设置了一个名为 Cloud Doctor 的自动化（https://cursor.com/automate）。它会定期检查故障，记住哪些错误可能是暂时性的还是显著的，进行根本原因分析，并在高置信度下打开 PR 来修复问题。 ## [改进智能体体验](https://cursor.com/blog/cloud-agent-environment#improving-agent-experience) 即使环境健康，智能体有时也会走漫长或刻意的路径来验证其更改。它们可能使用了错误的技能，遇到本可避免的 VM 问题，或者遵循了比预期更耗时的工作流。 我们在这里也使用了 Cursor Cloud MCP。Cloud Doctor 智能体检查追踪信息，以找出另一个智能体出错的地方、哪些技能或命令具有误导性，以及哪些工作流系统性缓慢。根据这些发现，Cloud Doctor 会修复技能、简化路径或改变环境，以便下一个智能体更容易工作。 这个循环不断改善智能体自身的开发者体验。当环境健康且能自我修复时，智能体就能可靠运行，开发者也会将更重要的工作交给云端智能体。 这让我们得以在内部扩大云端智能体的采用，如今它们编写了我们所发布的大部分代码。 Cloud Doctor 打开一个 PR 来修复不健康的环境 ## [让您的环境为云端智能体做好准备](https://cursor.com/blog/cloud-agent-environment#making-your-environment-ready-for-cloud-agents) 对云端智能体来说，真正提升我们生产力的因素大部分归结于环境。要判断你的代码库是否准备好了，可以先回答三个问题： 1. 智能体能否获得开发者同等的工具和数据？ 2. 智能体能否找到记录了开发者实际工作方式的技能？ 3. 智能体能否测试和验证核心工作流？ 如果你希望获得环境就绪方面的帮助，请与我们联系（https://cursor.com/contact-sales）。 或想了解更多，请阅读 Faire 如何借助云端智能体将每周 PR 吞吐量翻倍（https://cursor.com/blog/faire）。