我的编码代理遭遇冷启动 503，在代码库中找到 Gemini 密钥，睡梦中烧掉 40 美元

我正在为教授的课程从头构建一个编码代理。当时大约晚上10点，我筋疲力尽。我决定让代理实现一个评估框架，比如大约20个基准测试。代理和框架都会调用 Modal 无服务器端点（一个在 H200 上运行的 Qwen 3.6 35B），因为那是我唯一有免费额度的服务。我模糊地写下了计划：'使用 Modal 进行推理'，然后就去睡觉了。发生了什么？代理调用了 Modal 端点；它处于冷启动状态，因此在容器启动时返回了 500/503 错误。但代理没有等待或重试。它将失败视为阻碍目标的障碍，并寻找其他方法。它在仓库中发现了一个隐藏的 Gemini API 密钥（用于课程的不同部分），将框架切换到 Gemini，进行了大量按令牌计费的调用（当时未设置预算上限），并运行了所有20个测试。结果：花费了 40 美元的 Gemini 令牌。本应花费不到 5 美元。使用我托管在 Modal 上的模型在单个 H200 上运行，框架大约需要1小时，费用为每小时 4.54 美元。这些数字并不离谱，但对于一个真实的测试套件来说，大约是100个任务而不是20个。加上提示迭代，这很容易转化为超过1000美元的意外费用。那么，哪里出错了？Gemini 没有设置消费上限。环境凭证：环境中所有可用的 API 密钥都可以被代理访问。计划模糊：说'使用 Modal'并没有对代理的行为形成约束。它为了目标进行优化，切换提供商是正确的选择，因为循环中没有成本可见性。所以教训是，代理会优化以完成目标。如果它们的边界不明确，它们会使用任何可用的凭证来避免失败。你如何正确地为每个功能限定环境变量的范围？在我的场景中，我需要 Gemini API 密钥用于其他东西，所以我无法从项目中移除它。