亚马逊180万美元Claude超支:AI代理成本为何可能失控

AI代理可能以普通软件极少出现的方式失败:它们会不断尝试。遇到故障流程的人类员工最终会感到疲惫、寻求帮助、回家或等到第二天早上。而自主代理可以持续调用模型、阅读自身输出、重试工具、重写计划,并开始另一个循环数小时或数天。当任务困难时,这种持久性是有用的。当任务出错时,代价则非常高昂。据2026年7月《金融时报》报道……

发布于 2026年8月12日generalGEO 评分: 0
这是一张与亚马逊Claude AI代理成本超支相关的主题图,背景为深暗色,带有亚马逊与AI的模糊标识作为水印。画面核心明确标注了“Amazon's $1.8M Claude Bill”,下方还有“AI Agent Cost Controls”的字样,并用浅黄字体标注了核心关联概念“Tokenmaxxing·Automation Risk”。画面左侧呈现带有数值和下降曲线的成本图表,右侧点缀着警示三角图标、代码字符与代表AI系统的架构元素,直观呼应了文章关于亚马逊Claude项目出现180万美元超支,凸显AI代理成本管控风险、代币滥用等核心议题的内容。

亚马逊180万美元Claude超支:AI代理成本为何可能失控

引言

AI代理可能以普通软件极少出现的方式失败:它们会不断重试。

一个遇到故障流程的人类员工最终会感到疲惫、寻求帮助、下班回家,或者等到第二天早上再处理。

而一个自主代理可以持续调用模型、读取自身输出、重试工具、重写计划,并开启另一个循环,持续数小时甚至数天。

当任务困难时,这种持续性是有用的。

当任务本身出问题时,这种持续性就是昂贵的。

根据2026年7月《金融时报》援引亚马逊员工及熟悉内部项目人士的报道,亚马逊一个使用 Claude Sonnet 的项目在尝试丰富亚马逊网站上的作者信息时,累计产生了约 180万美元的AI成本

据报道,账单约为:

超出项目预算860%

据报道,这一超支在以下时间内未被察觉:

五个月

而尽管花费巨大,该项目据报并未成功部署。

这一组合使得该事件比一张异常巨额的发票更具重要性。

它揭示了一个新的企业软件问题:

小逻辑错误
×
自主重试
×
按用量计费
×
可观测性薄弱
=
重大财务损失

这个问题并非Claude、亚马逊或任何单一AI提供商所独有。

代理系统将算力转化为可变的运营支出。当它们被允许独立运行时,成本成为应用行为的一部分,而不再是简单的软件订阅。

缺陷不再仅仅产生错误结果。

它可以在 继续花钱的同时,数百万次地产生错误结果

180万美元亚马逊Claude事件始末

《金融时报》报道中描述的任务听起来很平常。

亚马逊想要改善网站上的作者信息。

据报道,一个基于Claude Sonnet的工作流被用于帮助匹配或生成所需的作者信息。

随后,该项目消耗的AI资源远超预期。

亚马逊员工据报将最终成本描述为约:

180万美元

这相当于估计的:

860%预算超支

最引人注目的细节可能是检测延迟。

成本问题据报在约五个月内一直处于活跃或未被发现的状态。

这表明失败不仅是AI模型的问题。

它也是监控和治理的问题。

如果一个企业工作负载能在没有明确警报的情况下花费七位数金额,那么该系统就缺乏围绕其他计费基础设施通常会具备的一项或多项控制措施。

这些控制措施可能包括:

  • 项目级预算。
  • 硬性支出上限。
  • 每日异常警报。
  • 每代理配额。
  • 最大重试次数。
  • 最大任务时长。
  • 每用户归属。
  • 每次成功成本仪表板。
  • 自动关闭规则。

《金融时报》报道称,亚马逊还发现了其他AI成本异常偏高的案例,工程师们正在开发自动化护栏。

亚马逊对该媒体表示,此类案例属于孤立的经验教训,而非

这是其更广泛人工智能工作的代表。

这一区别值得保留。

这次180万美元的事件据报是一次内部项目失败。

它并不能证明亚马逊的整个人工智能项目在经济上是不成功的。

消息来源“6000亿个Token”的估算需要结合背景来看

原中文文章做了一个夸张的计算。

文中称,按每百万输入Token 3美元的价格计算,180万美元最多可以购买:

6000亿个输入Token

这个算术很简单:

180万美元
÷
每百万Token 3美元
=
600,000百万Token
=
6000亿个Token

但这不是对亚马逊项目实际Token消耗量的衡量

它只是在几个不切实际的假设下得出的一个说明性上限计算:

  1. 每一美元都花在了输入Token上。
  2. 该项目使用的Claude Sonnet版本定价恰好为每百万输入Token 3美元。
  3. 没有输出Token费用。
  4. 没有缓存写入或缓存读取费用。
  5. 不存在AWS平台特定的定价差异。
  6. 没有其他推理或基础设施成本。

Anthropic目前的定价也因Sonnet代次而异。

截至2026年8月,Anthropic的价格表如下:

模型 标准输入 标准输出
Claude Sonnet 5 2美元/百万Token 10美元/百万Token
Claude Sonnet 4.6 3美元/百万Token 15美元/百万Token
Claude Sonnet 4.5 3美元/百万Token 15美元/百万Token

*《金融时报》*的报道确认了Claude Sonnet,但公开报道并未提供足够的计费细节来还原确切的模型版本、输入/输出比例、缓存行为或真实的Token数量。

因此,站得住脚的结论是:

据该报道,该项目花费了约180万美元;其确切的Token消耗量并不为公众所知。

这一点很重要,因为当一笔美元金额被自动用单一标价数字换算成Token时,企业AI成本分析就会产生误导。

为什么Agent成本比传统软件成本更难预测

传统软件通常具有相对可预测的成本驱动因素。

团队可以估算出:

  • 服务器数量。
  • 数据库大小。
  • 带宽。
  • 存储。
  • 用户许可。
  • 每秒请求数。

大语言模型Agent增加了另一层复杂度。

一个用户请求可能触发:

1次模型调用

也可能触发:

200次模型调用
+ 工具调用
+ 重试
+ 上下文回放
+ 网络搜索
+ 代码执行

用户可能只看到一个最终答案。

成本计量器看到的却是整个过程轨迹。

上下文会被重复发送

Agent在每一步推理过程中往往会重新发送其工作上下文的大部分内容。

因此,一个很长的代码库、大文档、工具历史或对话可能会被重复计费。

输出会变成新的输入

Agent先前生成的文本通常会变成下一次模型调用的上下文。

系统实际上是先花钱生成信息,然后再花钱读取这些信息。

重试会使成本成倍增加

一次失败的工具调用可能会触发:

  1. 错误解读。
  2. 新的推理。
  3. 修改后的调用。
  4. 另一个结果。
  5. 又一次模型轮转。

一个在代码层面看起来无害的重试循环可能会产生大量的Token消耗。

成本是

随机性

关于智能体编码的研究发现,同一任务在不同运行中的代币使用量可能差异巨大。

2026年一项针对SWE-bench Verified上多个前沿模型的研究报告称,同一任务在不同运行之间的差异最高可达约30倍。

更多的代币也并非总能产生更好的结果。

这使得“根据任务难度估算账单”成为一种不可靠的预算方法。

亚马逊的自动化梦想远不止一个失败项目

源文章随后从这件180万美元的事件转向了一个更宏观的观点。

亚马逊并未在AI领域退缩。

它正在加大投资。

首席执行官安迪·贾西一再表示,生成式AI和智能体将重塑客户产品和亚马逊的内部工作。

2025年6月,贾西告诉员工,亚马逊已经拥有超过:

1,000项生成式AI服务和应用程序

无论是已建成的还是正在推进中的。

他还预测:

将有数十亿个AI智能体
遍布各类公司和领域。

贾西表示,智能体可以执行以下工作:

  • 网络研究。
  • 深度研究。
  • 编码。
  • 异常检测。
  • 翻译。
  • 数据分析。
  • 工作流自动化。

他还表示,更广泛的AI应用将改变亚马逊的员工结构,随着效率的提升,长期来看可能会减少公司整体的企业员工数量。

因此,这件180万美元的Claude事件发生在一家刻意推动更多自动化而非更少的公司内部。

亚马逊2026年资本支出约2200亿美元

亚马逊的基础设施投入规模巨大。

在2026年第二季度财报周期中,贾西将公司2026年预期的资本支出上调至约:

2,200亿美元

高于此前约2,000亿美元的计划。

其中大部分支出与以下方面相关:

  • AWS数据中心容量。
  • AI基础设施。
  • 定制芯片。
  • 服务器。
  • 网络。
  • 电力。
  • 机器人技术及其他长期基础设施。

亚马逊2025年致股东信已经说明,公司并非“凭直觉”做出此前2,000亿美元的估算。

贾西表示,AWS拥有大量客户承诺,足以支撑大部分基础设施建设的合理性。

这就形成了一个鲜明的对比:

亚马逊在投入数千亿美元
扩展AI容量

同时也在学习
如何阻止单个AI工作负载
浪费数百万美元。

这两个问题并不矛盾。

基础设施容量和工作负载效率是两回事。

AWS正从AI热潮中收获实际回报

源文章正确指出,亚马逊的AI和云支出并非只产生成本。

亚马逊官方2026年第二季度业绩显示,AWS增长强劲。

这张图片是亚马逊云服务(AWS)的官方标识,标识主体为深暗色的小写英文“aws”字样,下方搭配着亚马逊标志性的亮橙色弧形箭头,箭头从左侧延伸向右端带箭头造型,呈现为微笑弧线的样式。该标识出现在文档对应的位置,用来指代文中提及的AWS业务板块,和文档里亚马逊二季度财报相关的AWS营收数据、AI业务成果等内容相呼应,帮助读者明确相关业务主体。

截至2026年6月30日的季度:

指标 2026年第二季度
亚马逊总净销售额 2,006亿美元

AWS净销售额 | 422亿美元 |
| AWS同比销售增长 | 37% |
| 亚马逊总营业利润 | 275亿美元 |
| AWS营业利润 | 166亿美元 |

因此,AWS贡献了大约:

亚马逊营业利润的60%

同时约占:

总净销售额的21%

在该季度。

亚马逊还表示,其AI业务和芯片业务的年化营收运行率均已超过250亿美元。

因此,该公司有强大的经济理由继续推动AI的采用,同时改善成本纪律。

亚马逊的劳动力正在同时发生变化

AI支出只是亚马逊自动化计划的一方面。

该公司也在减少企业岗位。

2025年10月,路透社的一篇报道称,亚马逊计划裁减多达3万个企业岗位。

贾西另外告诉员工,生成式AI的更广泛采用可能意味着某些类别的工作岗位减少,而其他类别的工作岗位增加。

需要注意的是,不能将亚马逊的每一次裁员都简化为“AI取代了员工”。

大公司的劳动力削减可能涉及:

  • 重组。
  • 疫情时期的过度招聘。
  • 成本压力。
  • 管理层级缩减。
  • 业务关闭。
  • 自动化。
  • AI驱动的效率提升。

明确的是,亚马逊自身预计AI将改变其未来的员工需求。

仓库自动化将同样的逻辑带入物理世界

来源随后从办公室自动化转向仓库和物流。

基于亚马逊内部文件的报道描述了一项雄心勃勃的机器人战略。

据报道,其目标是在未来几年内实现仓库运营的很大一部分自动化,这可能使亚马逊在货运量增长时避免额外雇佣数十万名员工。

一项被广泛报道的估计称,自动化可能使亚马逊避免:

到2027年额外雇佣约16万名美国员工

以及超过:

到2033年左右额外雇佣60万名员工

相对于自动化程度较低的成长路径。

这些数字基于被报道的内部预测,而非亚马逊公开承诺解雇60万名现有员工。

这一区别很重要。

“避免未来招聘”和“消除现有岗位”在经济上相关,但并不相同。

这张图片展现了亚马逊仓储物流场景内的工业自动化画面,画面中有着黄色的工业机械臂,这类机械臂正是该企业推进仓储自动化的核心设备之一;旁边有一位穿着反光安全背心、佩戴安全护具的工作人员,似乎正在对机械臂或配套的作业装置进行操作、调试。结合上下文可知,该图片用于直观呈现亚马逊将自动化策略落地到仓库作业的实际场景,对应文档中提及的企业借助机器人策略推进仓储运营自动化、减少新增岗位招聘的相关内容,展现了其自动化战略在实际作业环境中的应用。

亚马逊公开强调,机器人技术还可以在以下方面创造不同角色:

  • 维护。
  • 可靠性。
  • 机器人工程。
  • 流程监督。
  • 技术运营。

长期劳动力影响仍存在争议。

经济学家达龙·阿西莫格鲁是最主要的批评者之一,他警告称,大型雇主激进的自动化可能使公司从大规模就业创造者转变为消除或避免大量岗位的一方。

“更多Token=更多AI”的时代正在结束

来源的第二个主要

章节从亚马逊转向更广泛的硅谷行为:tokenmaxxing(最大化令牌消耗)。

有一段时间,各公司过于激进地推动AI应用,以至于使用量本身成了一种身份象征。

管理者希望员工:

  • 更多地使用AI。
  • 运行更多智能体。
  • 自动化更多工作。
  • 大胆试验。
  • 围绕AI组建更小的团队。

在一些组织中,这种鼓励演变成了排行榜。

而一旦指标变得可见,员工就学会了如何优化这个指标。

这是古德哈特定律的经典案例:

当一个指标成为目标时,它就不再是一个好指标。

公司想要的是有成效的AI应用。

它衡量令牌使用量,因为令牌使用量容易统计。

员工于是增加了令牌使用量。

数字上去了。

但有效产出未必增加。

亚马逊关闭KiroRank

亚马逊曾有一个非正式的内部排行榜,名为KiroRank

它根据员工涉及Kiro(亚马逊的AI开发工具)的活动来跟踪或排名。

据Business Insider和《金融时报》报道,一些员工开始执行不必要的AI任务,以提高自己的分数。

亚马逊最终关闭了该排行榜。

高级副总裁Dave Treadwell告诉员工,不要为了用AI而用AI。

亚马逊转向了更关注实际产出的衡量标准,包括一项名为规范化部署(normalized deployments)的指标。

教训很简单:

令牌消耗
≠
生产力

一个使用1亿个令牌却什么都没交付的开发者,并不自动比一个用500万个令牌解决问题的开发者更高效。

Meta的Claudeonomics排行榜制造了同样的激励

据报道,Meta也进行了类似的实验。

一个由员工构建的内部排行榜名为Claudeonomics,它汇总了85,000多名员工的AI使用情况,并显示前250名用户。

报道中出现了诸如以下头衔:

  • 令牌传奇(Token Legend)。
  • 缓存奇才(Cache Wizard)。
  • 会话不朽者(Session Immortal)。

据The Information报道,Meta员工在滚动30天周期内消耗了数十万亿个令牌。

后来的报道将30天总量定在接近:

73.7万亿个令牌

Meta随后转向更严格的使用控制,并设立了一个集中式AI网关(AI Gateway),用于成本可见性和预算管理。

这些数据基于内部报道的覆盖率,而非Meta的公开财务报表。

来源文章还将73.7万亿个令牌换算成了假设性的每月2.21亿美元账单。

这个数字不应被视为Meta的实际发票金额。

它本质上是:

73.7万亿个令牌
×
每百万个令牌3美元
≈
2.21亿美元

这假设每个令牌都按一个输入令牌的标价计费。

实际使用可能涉及不同模型、协商的企业费率、输入/输出组合、缓存、内部模型以及平台安排。

有用的事实是所报道的令牌使用规模——而非简化的账单换算。

Uber在四个月内用完了全年AI编码预算

Uber也遇到了类似的预算问题。

2026年6月的报道称,该公司在第一季度就耗尽了其智能体编码工具的年度预算。

一年中的四个月。

随后,Uber 引入了默认上限:

每位员工 1,500 美元
每月
每个智能编码工具

该上限分别适用于以下工具:

  • Claude Code。
  • Cursor。

员工可以通过内部仪表板查看自己的使用情况,若额外支出有正当理由,可批准例外。

这种做法更接近传统的云 FinOps。

问题从:

员工使用了多少 AI?

转变为:

这个工作流程花费了多少成本,
结果是否值得?

Uber 高管一直认为,AI 可以带来显著的效率提升。

转变并非从“使用 AI”到“不使用 AI”。

而是从无限制消费转向受管理消费。

连 OpenAI 也表示成本成为“巨大问题”

模型提供商内部同样面临这些经济问题。

在 2026 年 6 月的一次企业活动中,Sam Altman 表示,OpenAI 内部最高令牌用户每月消耗约:

1000 亿个令牌

他将其与大约六年半前相比,当时每月 10 万个令牌已显得异常之高。

Business Insider 还引用《纽约时报》的一篇报道称,OpenAI 一名员工一周内使用了约:

2100 亿个令牌

Altman 表示,成本从 2026 年初客户几乎不提的问题,变成了当年的:

“巨大问题”

其中的讽刺显而易见。

AI 实验室希望模型变得更便宜,以便客户可以使用更多 AI。

随着模型变得更便宜、智能体变得更加自主,总使用量的增长可能超过单价下降的速度。

这是杰文斯效应的一种体现:

更低的单位成本
→ 更多使用量
→ 总支出可能更高

大多数企业仍无法全面掌握其 AI 账单

成本治理之所以困难,是因为 AI 使用分散各处。

企业可能通过以下途径为 AI 付费:

  • 直接 API。
  • AWS Bedrock。
  • Azure。
  • Google Cloud。
  • SaaS 订阅。
  • 编码代理。
  • 嵌入式 Copilot。
  • 部门费用账户。
  • 内部推理。
  • 第三方工作流工具。

《华尔街日报》的一份 CFO 报告引用了一项调查,发现只有:

26% 的企业

能够全面了解其 AI 成本。

这意味着许多企业在能够可靠地归因 AI 成本之前,就已经开始尝试优化 AI 支出。

财务团队可能知道总供应商账单,但不知道:

  • 哪个团队产生的。
  • 哪个应用程序产生的。
  • 哪个客户工作流程产生的。
  • 哪个智能体循环导致了激增。
  • 多少成本产出了成功结果。
  • 多少是重试浪费。

AI 成本治理需要的不仅仅是月度账单

一个有用的企业 AI 成本系统应回答多个层面的问题。

第一层:谁花的钱?

按以下维度追踪:

  • 员工。
  • 团队。
  • 产品。
  • 代码仓库。
  • 智能体。
  • 环境。

第二层:什么消耗了成本?

区分:

  • 输入令牌。
  • 输出令牌。
  • 缓存写入。
  • 缓存读取。
  • 工具调用。
  • 搜索。
  • 代码执行。
  • 重试。

第三层:支出产出了什么?

将成本关联到:

  • 部署。
  • 已解决的工单。
  • 已合并的拉取请求。
  • 报告。

已交付。

  • 客户请求已完成。
  • 收入事件。
  • 节省的小时数。

级别 4:智能体行为是否正常?

监控:

  • 重复的相同调用。
  • 重试循环。
  • 上下文突然增长。
  • 令牌激增。
  • 长时间空闲会话。
  • 工具故障。
  • 无进展的任务。

目标不仅仅是减少令牌。

而是检测低价值令牌

更好的智能体预算具有多重护栏

每月一个美元上限是有用的,但不完整。

生产级智能体通常应同时设置多个限制。

示例:

每个任务:
  最大运行时间:30分钟
  最大模型调用次数:80
  每个工具最大重试次数:3
  最大成本:$5

每个用户:
  每日预算:$50

每个团队:
  每月预算:$25,000

全局:
  每小时支出+100%时触发异常警报
  紧急终止开关

具体数值取决于应用场景。

架构才是关键部分。

一个失控的系统应该在造成七位数意外之前撞上多个独立屏障。

为什么硬性限制对自主智能体至关重要

传统软件通常等待新请求后才继续工作。

智能体可能会自行创建下一个动作。

这改变了风险模型。

假设智能体收到如下指令:

找到正确的作者记录并更新数据库。

它发现存在模糊匹配。

它再次搜索。

然后它让模型比较候选结果。

然后它重试某个API。

然后它生成新的搜索查询。

然后它扩展上下文。

然后它循环。

如果成功标准定义不清,系统可能会长时间保持“忙碌”状态而并未变得更正确。

智能体需要一种概念:

停止

无论出于技术原因还是财务原因。

更高的自动化并不意味着更高的效率

原文在结尾引用了一个AI时代之前的著名自动化失败案例:Knight Capital

这个类比很有用,因为Knight的问题与LLM毫无关系。

这是自动化软件、部署控制和损失限制方面的失败。

2012年8月1日,Knight Capital为纽约证券交易所的零售流动性计划部署了新的交易软件。

根据美国证券交易委员会(SEC)的说法,部署错误导致旧代码在一台服务器上仍然处于激活状态。

当新系统上线时,那个休眠的功能开始向市场发送非预期的订单。

该系统持续运行了大约:

45分钟

SEC后来表示,Knight积累了一个非预期的数十亿美元证券投资组合,损失超过:

$4.6亿

原中文文章使用了大$4.4亿的常见引用数字。SEC后来的执法材料使用超过$4.6亿,因此本翻译采用监管机构的数字以确保准确性。

Knight Capital的教训在于缺少安全网

SEC的批评并不仅仅是软件存在漏洞。

软件总会有漏洞。

更严重的失败包括:

  • 部署流程薄弱。
  • 测试不充分。
  • 控制措施缺失。
  • 监控不力。
  • 缺乏有效的自动关闭机制。

Knight的系统以机器速度执行。

那个速度是

通常情况下是一种优势。

在故障期间,同样的速度会放大损害。

基本模式与代理成本风险几乎相同:

自动化正常运作
→ 速度即价值

自动化出现故障
→ 速度放大损失

AI 代理增加了一种新型损失函数

奈特的系统通过交易直接花钱。

大多数企业代理并没有券商接入权限。

但它们确实有一个计量表。

每次模型调用都可能产生成本。

每个工具都可能产生下游影响。

某些代理还可能被授权执行:

  • 购买云资源。
  • 启动任务。
  • 发送电子邮件。
  • 修改代码。
  • 部署基础设施。
  • 采购服务。
  • 迁移数据。

随着 AI 系统获得更多权限,其故障模式开始看起来越来越不像聊天机器人的错误,而更像是自动化控制失效。

这就是为什么 AI 治理越来越需要借鉴金融系统和云基础设施中熟悉的概念:

  • 预算。
  • 熔断机制。
  • 速率限制。
  • 审批阈值。
  • 审计日志。
  • 回滚。
  • 紧急停机开关。

自动化同时放大成功与失败

原文以正确的原则收尾。

自动化承诺:

  • 更快的执行速度。
  • 更低的单位成本。
  • 减少重复性人工错误。
  • 更大的规模。
  • 全天候运行。

这些优势是真实存在的。

但系统不会选择性地只放大正确行为。

它同样放大了:

  • 错误的假设。
  • 断裂的循环。
  • 不正确的权限。
  • 配置错误的工具。
  • 不良的激励机制。
  • 缺失的限制。

最危险的自动化不一定是立即崩溃的系统。

而是那种在快速、重复且不可见地失败时,看起来仍很有生产力的系统。

据报道,亚马逊的 180 万美元 Claude 项目并非是停止使用代理的理由。

而是停止将代理消耗视为无计量实验的理由。

实用 AI 代理成本控制清单

部署前

  1. 明确业务成果。
  2. 设定每个成功任务的最大可接受成本。
  3. 估算正常令牌和工具使用量。
  4. 设定严格的每任务上限。
  5. 定义重试限制。
  6. 设置超时时间。
  7. 对高影响操作要求人工审批。

执行中

  1. 将支出归因于指定的项目和负责人。
  2. 分别跟踪输入、输出、缓存和工具费用。
  3. 对异常的每小时或每日增长发出告警。
  4. 检测重复调用和停滞循环。
  5. 记录成功和失败的结果。
  6. 向代理操作员展示当前成本。

执行后

  1. 计算每个成功结果的成本。
  2. 审查异常昂贵的执行路径。
  3. 比较模型层级。
  4. 在适当时使用缓存。
  5. 移除不必要的上下文。
  6. 将简单任务路由到更经济的模型。
  7. 随着行为变化更新限制。

重点并非不惜一切代价将账单压到最低。

而是让账单变得可解释。

常见问题

亚马逊真的在 Claude 项目上花了 180 万美元吗?

《金融时报》报道称,一个使用 Claude Sonnet 的亚马逊项目累计产生了约 180 万美元的成本,超出预算约 860%,而问题大约花了五个月才被发现。该数字来自内部员工报告,而非亚马逊的公开事件报告。

亚马逊项目真的使用了6000亿个令牌吗?

这个数字只是一个粗略的算术示例,基于180万美元除以每百万输入令牌3美元的价格得出。该项目的实际令牌数量、模型版本、输入/输出组合、缓存使用情况以及其他费用尚未公开披露。

现在Claude Sonnet的价格是多少?

Anthropic目前将Claude Sonnet 5的售价列为每百万标准输入令牌2美元、每百万输出令牌10美元。Sonnet 4.6和4.5的标价分别为3美元和15美元,此价格不包含适用的缓存、批量处理或云平台差异。

为什么AI代理会变得如此昂贵?

代理可能会为单个用户请求发起多次模型调用、重放大型上下文、调用工具,并自动重试失败操作。如果工作流进入循环或缺乏停止条件,即使在任务不再产生有效进展时,支出也可能持续增加。

什么是Amazon KiroRank?

KiroRank据报是一个非正式的内部排行榜,与员工使用Amazon的Kiro AI工具相关。据报道,在员工开始单纯优化该指标之后,亚马逊将其关闭,领导层也告诉员工不要仅仅为了增加使用量而使用AI。

企业应如何限制AI代理的支出?

有效的控制手段包括:每项任务的美元预算、模型调用次数限制、重试上限、超时设置、每用户和每团队配额、异常警报、使用归属以及紧急终止开关。最佳衡量指标通常是每个成功业务成果的成本,而不是原始令牌量。

Knight Capital与AI代理有什么关系?

Knight Capital在一项自动化交易部署因缺乏足够安全机制而失败后,在约45分钟内损失超过4.6亿美元。该事件说明了同样的一般原则:自动化提高了有效工作的速度,但也提高了失败的速度和规模。

降低令牌价格能否解决企业AI成本问题?

仅靠降低价格本身并不足以解决。更低的单价可能会鼓励更高的使用量,尤其是当代理自主运行时。企业仍然需要可见性、预算、路由、缓存以及基于结果的衡量。

相关工具

  • Anthropic Claude定价:Claude模型、提示缓存、批量处理和代理会话的官方定价。
  • Amazon Bedrock:AWS的托管平台,用于使用Claude和其他基础模型并具备企业级控制功能。
  • AWS Budgets:AWS工具,用于定义预算并在支出或使用量超过阈值时触发警报。
  • AWS Cost Explorer:用于分析和归因AWS随时间变化的支出。
  • AWS Cost Anomaly Detection:用于识别异常AWS支出模式的自动监控。
  • Kiro:关于内部KiroRank使用排行榜报道中提到的Amazon AI开发环境。

相关链接

导致失控支出](https://www.ft.com/content/77baac40-d803-4084-94f3-a133653072cf):关于亚马逊180万美元Claude项目及其他内部成本超支的主要报告。

摘要

据报道,一个使用Claude Sonnet的亚马逊项目累积了180万美元的账单,超出预算约860%,耗时五个月才被发现,且最终未能投入部署。这一事件表明,当一个智能体能够在没有强有力停止条件的情况下反复消耗按量计费的AI资源时,一个普通的软件错误可能会变得异常昂贵。

亚马逊并未退出AI领域。AWS增长迅速,公司预计2026年资本支出约为2200亿美元,安迪·贾西描述的未来了包含数十亿智能体。因此,对失控成本的回应更可能是加强成本治理,而不是减少自动化。

同样的转变在整个硅谷都可见。亚马逊关停了KiroRank,Meta从tokenmaxxing转向预算制,优步对每位员工每款编码工具设定了每月1500美元的上限,萨姆·奥尔特曼表示,即使OpenAI内部,AI成本也已成为一个重大关切。

Knight Capital的失败提供了永恒的教训:自动化不只是放大效率。当控制薄弱时,它会以同样的速度放大错误。

正确的企业AI指标不是“我们用了多少token?”而是“这些token产生了什么可衡量的结果,当它们不再产生价值时,是什么让系统停下来?”