作者：丹尼尔·博塔，图片由安妮·鲁伊特提供。 构建代理很有趣，而重建自我破坏的代理就没那么有趣了。许多 Fly 的人正在构建更不容易自我毁灭的代理，他们通过教导代理在 Sprite 中执行任何风险行为来实现这一点。你可以得到一个活得足够久以实际利用其华丽自我改进功能的代理，并且可以允许你的代理尝试那些否则将是战舰级别的危险行为。下面是如何做到这一点。 大脑与手 如果没有一个外壳，你的代理就无济于事，因为这就是它执行代理操作的地方。运行测试套件，应用迁移，安装依赖，删除临时文件。不幸的是，你的代理的外壳访问权也是通常会破坏你下午的原因，仅仅因为“删除临时文件”和“删除错误文件”只差一个不小心，而正如我们经常得到的警告，人工智能可能会犯错误。这就是我们需要沙箱的原因。但许多人默认将一个会做潜在危险工作的代理放在沙箱中。这带来了许多权衡，但实际上你不必这样做，因为代理生存的地方和运行代码的地方是两个完全不同的考虑。 代理工人的个人防护装备。 代理进程是一个循环。它调用一个模型，读取响应，选择一个工具，反复进行。这是一个长时间运行的进程，只有在内存、技能和历史持久的情况下，才能变得更加有能力和聪明。因此，一个在空闲时休眠、在收到消息时唤醒的 Fly 机器，一个小型 VPS。在你迭代时使用的笔记本电脑。这些都是调用 API 的循环的合适家园，并不需要防护罩。问题是当你想让代理执行操作时，事情就变得复杂了。 bash -c + 模型刚刚产生的任何字符串都需要在一个缓冲室中运行。在一个代理的代码无法自我破坏或破坏任何连接到它的事物的地方。如果你的代理工作效率高于你，那么你会想要一个可以随时丢弃和重建的缓冲室的整个设施。 每个会话一个 Sprite 让我们来看看 Fly 的人最近的两个项目，它们很好地展示了这一概念。第一个是亨里克的内部 Fly 故障排除代理，称为 SpriteDoc。SpriteDoc 是多用户的，构建在 Pi 代理之上。每个会话都运行在一个共享服务器上，在一个 Node.js 运行时下。直接在那个服务器上运行 bash 命令并不是可行的，并且……很危险。每个用户的 shell 均会位于代理自身的同一进程中。相反，每个会话都在自己的 Sprite 中运行。第一次会话需要文件系统时，一个 bash 调用，一个文件读取，一个编辑，它会启动一个新的 Sprite，上传项目的源树，并安装该会话需要的任何 CLI。Sprites 启动的速度足够快，以至于用户几乎察觉不到。之后的每个命令都在同一沙箱中运行，与代理和其他用户隔离。这种架构依赖于 Sprites 固有的可丢弃性。故障排查会话不应该留下任何东西，因此当它完成时，Sprite 也随之消失。Sprites 的空闲行为使这种架构运行成本低。当一个沙箱闲置时，其状态会下降到温暖，随后到冷，因此在问题等待期间，一个会话的花费几乎为零。如果让它闲置的时间长了，或者归档会话，Sprite 就会完全被拆除。当稍后恢复会话时，下一条需要 shell 的命令会启动一个新的。 没有人会为一个什么都不做的盒子付费。 从未存在的令牌 如果你要窃取亨里克设计的任何部分，它应该是这一点：SpriteDoc 在沙箱内运行 flyctl 以实际用户的身份进行身份验证，但用户的令牌从未写入 Sprite。它会在那一个命令的持续时间内注入到环境中，并在命令返回时消失。沙箱执行真实的认证工作，而且从不保存凭证。如果稍后检查、快照或入侵这个 Sprite，就没有令牌可供盗取，因为它从未驻留过。对于构建多用户代理的人来说，这真是太棒了。每个用户的命令都作为其自身运行，使用自己的资源，拥有自己的权限，没有长期存在的秘密存储在共享磁盘上。凭证仅在使用的瞬间存在，并且对于用户是不可见的：他们提出问题，正确的命令以他们的身份运行，并且一切正常。 拯救代理 下一个是凯尔的 Hermes 代理的终端后端，来自 Nous Research 的开源个人代理。Hermes 配备了几个执行后端，你只需通过一个设置选择一个。凯尔的后端将代理需要运行的每个命令发送到一个 Sprite。SpriteDoc 每个会话启动一个一次性沙箱，而 Hermes 则恰恰相反，使用相同的构建模块；它为每个任务保留一个 Sprite，并在下次恢复它，这样它在上一个会话中安装的所有内容仍然存在。相同的分裂，反向生命周期。