如何开始使用云代理（逃离你的局部最优）

2026年，随着人们开始运行更多、更长时间的智能体，编码将转向云端。像SpaceXAI这样的实验室已经在他们的大部分PR中使用云端智能体。而像Ramp和Harvey这样的顶尖初创公司也有自己的云端智能体系统。

然而，我交谈过的大多数人都感到准备不足。他们习惯于在本地运行几个智能体，不知道如何迁移到云端。更糟糕的是，他们的代码库中充满了使这一转变变得困难的模式。

为了提供帮助，我们@mainframe写下了我们所知道的关于入门的一切。我本人自1月以来一直只使用云端智能体，长时间自主运行它们，并构建了内部云端智能体基础设施。

是时候逃离你的局部最小值了。

为什么选择云端智能体

智能体需要自己的计算机才能运行数天/数周/数月并（安全地）测试其工作。当你拥有数百个运行数天的智能体时，你的机器将无法胜任。

此外，云端智能体还为你带来许多其他好处。例如，桌面录制证明PR有效，这是大多数托管解决方案开箱即用的功能。以及无论你在哪里都能工作的能力——无论是通过Slack还是移动应用。

它们还使其他角色（如设计师和项目经理）更容易为产品做出贡献，因为他们不再需要设置机器。

阅读原始的Ramp Inspect博客文章以更深入地了解云端智能体为何重要。

选择你的云端智能体

目前已经有成千上万的云端智能体产品。我喜欢使用以下四种之一：Conductor Cloud、Cursor、Devin或Open-Inspect。你可能应该先从前三者中的任何一个开始，然后再考虑自托管。披露：我收到了Cursor和Devin的积分，但即使没有这些，我也会推荐它们。

如果你已经习惯了Conductor的用户体验，并想使用你的OpenAI/Anthropic订阅，Conductor Cloud是一个很好的选择。虽然它很新，功能不如Cursor/Devin丰富，但它具备所有基本功能以及你期望从Conductor产品中获得的质量。

如果你已经在他们的生态系统中，并且a)使用Glass偶尔在本地运行智能体，b)想要原生iOS应用，或c)使用Grok Bot，那么Cursor是最佳选择。

如果以上不适用于你，那么Devin是明显的赢家。由于Devin从一开始就是云端智能体，他们拥有最好的整体用户体验和功能集。令人惊讶的是，其移动网站如此出色，以至于它也是四种产品中最好的移动体验。

如果你想要自托管，Open-Inspect是你要选择的产品。无论是为了更好的治理、对功能的控制，还是（像Conductor Cloud一样）能够使用你的订阅。

设置你的云端智能体

每个云端智能体的工作方式相同。你告诉平台你的VM需要哪些依赖项，它可以在构建时预安装，以及如何启动你的仓库。对于Cursor和Devin，智能体会尝试自主解决这个问题。

Conductor Cloud、Devin和Cursor都允许你在代码中定义安装和启动脚本，我强烈推荐这样做。这些平台还需要密钥来运行你的仓库，它们会要求你通过其UI输入。

如果幸运的话，你的代码库在完成入门后就能正常工作。尝试让云端智能体执行一个涉及前端和后端的任务来测试。

很可能，它会在某个地方出错或成功有限，因为它无法做到你能做的一切。本文的其余部分将涵盖你需要改进设置的多种方式

技巧1：使你的技术栈可并行化
如果你从未考虑过云端智能体运行你的仓库时会发生什么，可能会有意想不到的后果。

例如，一个云端智能体可能会撤销另一个智能体的工作，因为它们使用同一个数据库。与本地智能体相比，云端智能体更令人担忧，因为你会同时运行更多智能体。

为了防止这种故障模式，检查你的整个系统（服务器、数据库等），问自己：“如果N个智能体并行运行这个，会发生什么？”如果幸运的话，你可能已经为git worktrees做过类似的事情。

故障示例：你使用Convex但忘记了每个开发者只有一个云实例。在这种情况下，你应该使用Convex agent mode。或者使用Modal函数但忘记确保每个智能体启动一个唯一的实例。

你可能需要发挥创意。例如，由于Mainframe是一个GitHub应用，我们给每个智能体提供工具来快速启动他们各自的实例——我们曾认为这是不可能的。我们在制作Slack应用时也做了同样的事情。

你可能也无法使系统的所有部分都本地化。在这种情况下，你需要使用隧道来确保远程服务能够访问本地服务。

虽然从技术上讲，你不必担心云端智能体的端口问题——因为每个智能体都有自己的VM——但我也喜欢确保端口冲突不会发生。这样你也能在本地使用worktrees时使用此设置。

技巧2：专用智能体密钥
不要给云端智能体与人类相同的密钥。使用权限有限的专用密钥。由于云端智能体在VM中长时间运行，它们会找到并利用任何权限漏洞，因此让它们处于严格控制之下很重要。你还希望能够将操作归因于智能体而非人类。

在Mainframe，我们使用密钥管理器Infisical将所有智能体密钥集中在一个地方并控制访问。

技巧3：让智能体访问真实数据
你的云端智能体需要真实数据来完成工作。确保给它访问种子脚本的权限，这些脚本能快速用“真实”数据填充机器，比如各种状态的测试账户。

考虑一个前端模式，让智能体使用暂存后端运行应用的前端。请注意，你在这里做的任何事也会惠及人类用户体验！

技巧4：让智能体能够看到并做你能做的一切
Cursor和Devin的优势之一是它们的云端智能体被指示全面测试功能，同时录制计算机屏幕。不幸的是，如果你的智能体因为例如无法登录而无法测试某些内容，你将无法获得任何好处。

重要的是，*在你的智能体能够做一切你能做的事情之前，不要放弃*。

任何东西都可以变得智能体可访问。例如，你可以通过Limrun或Revyl给智能体一个iOS模拟器。通过AgentMail给智能体一个自己的电子邮件，用于登录服务。

创造力是关键。我们的智能体甚至有自己的GitHub账户，这样它就可以用浏览器模拟我们的GitHub应用可能面临的任何场景。

技巧5：让智能体跑得更快
不要因为智能体能够完全运行你的应用就停下来。虽然它可能有效，但对你来说，智能体运行和测试所有内容可能很慢。这可能变得不利，因为例如20分钟的不必要减速会拖慢整个流水线。你的智能体使用的一些服务——比如iOS模拟器——也可能为此时间收费。

回看智能体录制的视频，看看如何为它们节省时间。例如，如果你注意到智能体在OAuth上花费很长时间，你可以提供一个CLI命令跳过登录。或者创建技能，让智能体使用Playwright快速测试功能。

智能体体验是新的开发者体验。

只有两点提醒：不要为智能体构建攻击者可以利用的后门。也不要为了速度优化到智能体的体验与人类完全不同——你仍然希望智能体能够发现应用中真实的用户体验问题。

技巧6：将所有知识拆分为技能
此时你可能已有数页指令描述智能体如何运行和测试应用的不同部分。将所有内容放在一个AGENTS.md中很诱人，但我们发现这样做会降低遵循度。相反，将指令拆分为智能体可以即时加载的技能。例如，你可以创建一个移动测试技能，告诉智能体如何启动iOS模拟器。

技巧7：向智能体征求反馈
每当你长时间运行智能体时，请它们反馈体验中任何不好的地方。它们可能会告诉你开发栈的某部分已损坏或比必要速度慢得多。

我们已开始在Slack中尝试一个专门的反馈渠道，智能体可以在那里发布开发者体验的不满。

技巧8：让移动端成为你的朋友
在成为云端信徒后，最糟糕的事情是继续认为所有工作都需要在电脑前完成。下载Cursor和Conductor Cloud的移动iOS应用，或在移动网页上使用Devin。

另外，将Cursor和Devin添加到Slack并启动你的第一个智能体。
Slack很重要，因为它也会让你的设计师、项目经理和其他角色明白开发现在很简单™

你自由了，不再被束缚在办公桌前。

逃离局部最小值
如果你完成了所有这些，你的设置就不再是本地化的，为即将到来的智能体能力提升做好了准备。记住，你不必一天内完成所有事情。

一旦你花了一些时间使用托管解决方案，你可以选择通过例如Open-Inspect自托管云端智能体。有强有力的论据表明你应该拥有这个基础设施，因为它对公司至关重要。而且成本也低得多。话虽如此，托管解决方案在幕后做了很多隐藏工作，我个人喜欢它们提供的用户体验。

既然你已经脱离了局部最小值，尝试推动你的云端智能体使用，看看边界在哪里。云端的真正好处在于你开始让它们过夜运行，并以你从未做过的数量运行时。

如有任何问题，请告诉我，
Vincent

封面图片由@atlou_提供