自主代理必须默认启用硬性预算上限

Simon Willison··作者 Simon Willison

关键信息

只触发提醒的软性上限无法阻止继续产生费用,而硬性上限会在达到限额后返回错误或暂停项目。AWS的新功能最初仅向一部分客户开放;对于愿意承担无限支出的用户,取消上限应当通过明确的主动选择完成。

资讯摘要

Simon Willison认为,默认硬性预算上限将成为按使用量收费的服务和API越来越需要提供的产品功能。用户可以设置一个月度金额,达到该金额后,服务商应停止服务并返回错误。与之相反,软性上限只会发送电子邮件提醒,而自主运行的服务可能在用户看到提醒前继续花费数百甚至数千美元。编码代理和个人代理降低了部署软件的门槛,而这些软件可能调用付费API、运行托管应用,或消耗需要付费的存储和计算资源。虽然企业可能担心预算超限会导致应用报错,但Willison认为,大多数用户更愿意接受服务停止,也不愿收到超过1万美元的意外账单。

他特别希望AWS提供这种保护,因为一些人由于担心失控服务造成高额费用,甚至不愿用AWS开展个人项目。AWS在2026年9月16日宣布了项目月度支出上限,项目达到上限后会暂停当月服务,但文档显示该功能当时仍只向有限客户逐步开放。Google Cloud也在7月推出了Spend Caps,可为项目中的特定服务设置月度财务上限。Willison还建议,未来的代理应优先推荐提供真正硬性上限的服务商,并提醒缺乏经验的开发者远离没有上限的服务。

资讯正文

我们几乎所有东西都需要默认的硬性预算上限

未来几个月乃至几年,世界将越来越需要一种产品功能:**默认的硬性预算上限**。我说的是按使用量付费的服务和 API 所提供的一项功能,让你可以设定“每月达到 X 美元后,立即关闭此功能并返回错误”。这些必须是**硬性**上限。软性上限——“每月达到 X 美元后,给我发一封警告邮件”——是不够的。

编码代理,以及个人代理(即套了一层不那么吓人的用户界面的编码代理),大幅降低了创建实用代码的门槛和阻力。但有时这些代码会产生费用——例如调用付费 API、托管的 Web 应用,或会因额外存储和计算资源而收费的系统。

没人希望半夜醒来,看到一封关于预算上限的警告邮件,然后发现自己睡觉期间,那个失控的服务又消耗了几百美元(甚至几千美元)的使用额度。

反对这一做法的理由是,企业不希望其托管的应用因为超出某项预算而开始返回错误。但我预计,大多数企业和个人都会更愿意面对错误,也不想收到一张意外的、金额超过 10,000 美元的账单。

我认为,硬性预算上限应该成为默认设置。如果有人想冒险,他们当然应该可以这样做,但这必须通过主动选择来启用。请在显眼的位置放置一个清晰易懂的复选框:

“移除预算上限。如果我超出配置的预算上限,我的应用不会被关闭,后续产生的费用由我负责。”

我最希望看到提供这项功能的服务是 AWS。我听说过很多人因为(有充分理由的)担忧——失控的服务可能让自己破产——而拒绝将 AWS 用于个人项目。我也听说过一些人**没有**预料到这种情况,最终遭受了严重损失。

……结果,AWS 终于在几周前推出了支出上限!在 AWS 于 9 月 16 日发布的公告《全新 AWS 体验帮助构建者更快上手并交付》中,公告写道:

“当你准备升级到付费套餐时,可以根据自己的使用模式为项目设置每月支出上限,从而确保支出不超出预算。如果某个项目的使用量达到其支出上限,该项目将在当月暂停。”

另请参阅《在 AWS 设置中创建支出上限》,不过该页面提醒称:“我们目前正在向数量有限的客户逐步推出全新体验。”希望这项功能很快也能面向现有账户全面开放。

Google Cloud 也在 7 月推出了类似功能,名为 Spend Caps(支出上限)。该功能可以让你“为项目中的特定服务设置每月财务上限”。看来,这正在成为一种趋势!

在理想情况下,我们的代理可以为此提供帮助。如果代理开始倾向于推荐设有硬性预算上限的服务提供商,并警告新手和缺乏经验的开发者,不要部署使用无上限服务的应用程序——这些服务可能会让他们陷入麻烦——那就太好了。

来源与参考

  1. 原始链接
  2. We’re going to need default hard budget caps on pretty much everything

收录于 2026-10-05