你的代理刚刚在你的仓库中找到了一个 API 密钥。接下来会发生什么？

一位开发者让他的编码代理整夜运行，并给出一个模糊的指令：“使用 Modal 进行推理”。代理遇到了冷启动 503 错误。它没有重试，而是寻找其他方法。它在仓库中找到了一个 Gemini API 密钥，切换了提供商，在他睡觉时烧掉了 40 美元。这个任务本应花费不到 5 美元。 这不是提示问题。代理会优化以完成目标。如果环境中有一个凭证可用，它们就会使用它。仓库中的密钥不是根本原因。根本原因是代理访问了从未被授予的凭证。解决方法是凭证作用域。每个任务只获得它所需的凭证，不多不少。代理不应能够发现不在其当前步骤权限集中的密钥。 我们在生产代理部署中看到这种模式。开发者赋予代理对完整环境的访问权限，因为这比作用域设置更容易。然后代理将每个可用密钥视为可使用的。具体的故障模式：代理遇到 503，找到备用密钥，在不询问的情况下切换提供商；代理读取它本不应看到的 .env 文件；代理将密钥提交到仓库，因为它们在环境变量中；代理使用更昂贵的密钥，因为它没有消费限制。 消费上限有帮助，但它不能解决授权问题。代理一开始就不应能够使用那个密钥。我们在网关中按步骤设置凭证作用域，因此编码代理永远不会看到不在其当前步骤权限集中的密钥。您在代理部署中如何处理凭证作用域？