AWS 提出 Bedrock 成本治理操作模型：智能体工作流的消耗取决于自主程度而非交互次数

生成式 AI 的成本管理正面临一个结构性变化。对话式助手通常每个用户轮次触发一次模型调用，而智能体工作流——比如一个会规划改动、读取文件、调用工具并反复迭代的 AI 编程助手——每个任务发出多次调用，每次携带更大的上下文。这意味着 token 消耗不再与用户交互次数挂钩，而是取决于你赋予工作流的自主程度和它携带的上下文大小。

AWS 机器学习博客在 2026 年 10 月 30 日发布的这篇操作指南，核心判断是：解决办法不是换一个更便宜的模型或缩短提示词，而是建立一个可重复运行的操作模型——把每一美元归属到责任人，让每一次请求可观测，在超支累积之前触发告警和硬性拦截，集中优化平台默认值以消除浪费，并按节奏复盘整个系统。文章面向两类读者：负责归属、分摊、预算和异常审查的 FinOps 从业者，以及负责日志、请求元数据、执行和路由默认值的平台工程团队。

五阶段被刻意排序。归属是一切下游的基础——没有归属，分摊、预算、执行和异常检测都无从谈起。Amazon Bedrock 自动将推理成本归属到发起调用的 IAM principal，调用者的 ARN 出现在 AWS Cost and Usage Report 2.0 的 line_item_iam_principal 列中，覆盖 IAM 用户、角色、联合身份和 API 密钥。设置只需四步：在 CUR 2.0 数据导出中开启 IAM principal 数据；为 IAM principal 打上团队、应用、成本中心等业务标签；在 AWS Billing 中激活这些标签；分析标签——它们以 iamPrincipal/ 前缀出现在 CUR 2.0 中，24 到 48 小时后即可在 Cost Explorer 中按团队、应用或成本中心筛选和分组。

但文章指出一个最容易被忽视的陷阱：共享角色问题。当一个大型语言模型网关通过单一 IAM 角色调用 Amazon Bedrock 时，每一美元都被归属到那一个角色，逐用户可见性完全丧失。修复方案是逐用户会话管理：网关为每个用户假设一次 Bedrock 调用角色，将用户身份作为角色会话名、将用户属性作为会话标签传入，然后缓存这些凭据最多一小时——每小时每用户一次 STS 调用，而非每次请求一次。这需要两个角色：一个持有 sts:AssumeRole 和 sts:TagSession 权限的网关执行角色，以及它所假设的 Bedrock 调用角色。结果是在 line_item_iam_principal 中出现类似 assumed-role/BedrockRuntimeRole/gw-alex 的条目，各自携带其用户的标签，逐用户和逐租户归属在共享网关之后得以恢复。

观测阶段解决的是 CUR 约 24 小时的归属延迟。Amazon Bedrock 支持将请求数据、响应数据和元数据记录到 CloudWatch Logs、S3 或两者。文章建议将日志视为基础设施而非手动开关：通过代码配置日志组或存储桶，定义保留和加密策略，在环境搭建时验证投递。CloudWatch 加 OpenTelemetry 可以在几分钟内展示逐开发者花费，关闭 CUR 的延迟缺口。更重要的是，原始日志回答身份层面的问题，而工作流层面的问题——哪个功能、工作流或租户产生了这些 token——需要在每次调用上盖请求元数据。文章建议平台团队在共享 SDK 包装器或网关中集中注入强制元数据，将元数据覆盖率作为平台健康指标。

执行阶段给出三个层级。第一层是监控和告警，不拦截：在 AWS Budgets 上设阈值告警，用 Stage 2 的 OpenTelemetry 仪表盘关闭 CUR 延迟。没有额外部署，不增加推理延迟，适合早期采用阶段。第二层是 IAM 标签执行：一个聚合 Lambda 函数从调用日志中统计逐用户 token 和美元计数器写入 DynamoDB，当用户突破阈值时将其身份加入共享 IAM 拒绝策略。执行完全运行在 IAM 和 Bedrock 日志之上，推理路径中没有第三方组件，但拦截是异步的——IAM 策略更新在突破调用后数秒到数分钟生效，凭据检查在下次刷新时生效。第三层是网关同步拦截：网关坐在推理数据路径中，用户或团队超限即刻返回 HTTP 429，提供亚秒级拦截、逐用户模型白名单和集中路由规则。