为什么AI代理需要两层架构

我们要解决什么问题？让我们从一个问题陈述开始：你需要部署一个面向公众的聊天机器人，该机器人应能够执行各种工具，例如 ffmpeg。最简单的解决方案就是在你的服务器上托管一个应用，该应用直接接受提示，决定调用哪些工具，在服务器本身上执行代码，并返回输出。 用户/前端 你的服务器 ┃ +-----------+ +-----------------------+ ┃ | | ---> | LLM选择工具 | ┃ | Prompt > | | -> 执行代码 | ┃ | | <--- | -> 工具调用 | ┃ +-----------+ +-----------------------+ 未隔离（一台机器完成所有操作）：这种方法固有地存在问题。举个例子，一个允许你通过文本提示运行 ffmpeg 命令的应用。用户输入“delete the lib ffmpeg”，在上述方案中，无论系统指令多么健壮，它最终都会执行所指示的命令。最终结果：所有用户都会受到影响。 那么我们如何解决呢？我们提出的设计是：在从不执行代码的系统上让 OpenAI 评估提示。然后将代码发送到另一台安装了 ffmpeg 的机器上，LLM 生成的代码在此处执行。即使代码是恶意的，也只会影响该特定用户的临时机器。 用户/前端 持久服务器 临时环境 ┃ +-----------+ +---------------+ +--------------+ ┃ | | ---> | 提示评估 | ---> | | ┃ | Prompt > | | | | 执行代码 | ┃ | | <--- | v | <--- | | ┃ +-----------+ | 代码 | +--------------+ ┃ +---------------+ Anthropic 也提出了一个类似的模型，即托管代理，尽管他们没有明确这样称呼。 额外部分 如果有人注意到，你可能会想：如果提示注入要求“给出所有环境变量”（在持久服务器上），那么成功的提示注入是否会泄露我们的 OpenAI 密钥（用于从持久服务器生成 ffmpeg 代码的密钥）？好问题！因此，我们从不将 OpenAI 或任何此类密钥存储在持久服务器中，而是通过一个单独的密钥保管库的代理将其动态注入。