Orbs 中的智能体

# 在 Orbs 中的智能体 来源：https://ampcode.com/news/agents-in-orbs 现在你可以在 Orbs 中远程启动 Amp 智能体：Orbs 是一种允许智能体在无人监督下运行的机器。当你创建一个新线程时，你会获得一个全新的 orb，其中包含你的代码、插件以及智能体可能需要的工具。Orbs 按分钟计费。查看当前的 orb 规格和定价(https://ampcode.com/manual/orbs#pricing)。它们启动迅速，并在你和智能体不再需要时自动休眠。 ## 远程且触手可及 在 orbs 中运行的智能体并非运行在你本地机器上，但你可以像控制本地智能体一样控制它们。你可以审查更改并浏览 orb 上的文件：你可以使用终端：如果你想与智能体同步迭代，可以通过运行以下命令将更改同步到本地机器： ``` amp sync ``` `<url_or_id>` 可以是线程 URL 或 ID。就像这样：而且，就像你可以用 `amp -x` 启动新的 Amp 线程一样，你可以使用 `amp -ox` 在 orb 中启动一个线程： ``` amp -ox "Investigate why the latest CI run on 'main' failed" ``` 你甚至无需离开 Amp TUI 就能启动一个运行在 orb 中的智能体。查看手册以获取更多关于 orbs 及其使用方法的信息。(https://ampcode.com/manual/orbs) ## 事情在变 能够从任何地方启动新的智能体并让它们按需运行的能力，改变了我们与智能体协作的方式。当然，在此之前同时使用多个智能体已经是可能的：可以为不同的智能体使用不同的检出目录、工作树，或通过 SSH 在远程主机上手动运行智能体。但是，如果在一台非你本地的机器上启动智能体变得如此简单，并且使用你已有的界面来管理它们，与这些本地智能体并列，使用完全相同的控制方式呢？事情*会改变*。 一方面，你会更频繁地使用智能体。当不存在本地资源冲突时，为什么不启动一组智能体来独立调查八个不同的问题呢？为什么不将一份问题报告转化为一个智能体和一次调查，而不是一个工单呢？为什么不管理智能体及其结果，而不是管理工单呢？你还会开始用它们处理一些之前未曾考虑的事情。如果不占用你的 CPU，为什么不启动一个智能体长时间运行并尝试所有可能的性能优化？如果不会与你本地的智能体冲突、不会抢占它们的内存，为什么不让智能体执行测试流程呢？为什么不构建那个原型？为什么不去追求那个看似遥不可及的目标？为什么不尝试？为什么不行？ ## 是时候探索了 早在二月我们就说过(https://ampcode.com/news/the-coding-agent-is-dead)，如果我们仅仅将模型视为辅助工具，并将它们限制在侧边栏中，那么我们就是在束缚模型的能力。我们当时宣称，模型“想要编写代码，并且在你不在编辑器前时也能运行”。现在，我们做到了这一点。暂且不论编辑器，现在我们甚至可以在离开电脑时让智能体继续运行。我们相信，这将是未来许多代码的编写方式。我们相信，这不仅仅是一次进步，而是一次跨越重要门槛的步骤。具体*如何*发展，我们尚不确定。有些代码可能始终会在本地创建、在密切监督下完成，并涉及大量来回沟通。但这些模型正变得如此强大，以至于它们能够独立完成（*以及*运行、*以及*测试、*以及*交付）的代码量只会持续增长。此时，如果我们还要求它们在单台机器上完成所有工作，那我们就是在束缚它们。而一旦你将它们释放到 orbs 中，你就会意识到它们之前受到了多大的限制。是时候去探索它们的潜力极限了。