一个 AI 编码助手接到任务：规划代码变更、读取文件、调用工具、迭代修改。这不是一次模型调用，而是一串调用——每次调用携带的上下文也更大。AWS 在面向 FinOps 与平台工程团队的 Amazon Bedrock 成本管理手册中，点破了这个结构性变化的经济含义：token 消耗随你赋予工作流的自主程度（degree of autonomy）和它所携带的上下文规模放大，而非随用户交互次数线性增长。

这份手册发布于 AWS Machine Learning Blog，没有发布新产品，也没有给出客户案例。它做的事情更基础：为企业在 Amazon Bedrock 上运行生成式 AI 工作负载定义了一套从归属（Attribute）到运营（Operate）的5阶段治理模型，并把每个阶段映射到具体的 AWS 构件上。手册的核心论断——生成式 AI 的成本管理是一项架构与运营学科（an architectural and operational discipline），不能靠比较 token 单价或要求开发者缩短 prompt 来解决。

Harness 的《State of AI in FinOps 2026》调查（2026年5月至6月访问700名工程领导者和从业者）从另一个角度提供了背景：80%的受访者表示过去6个月 AI 总支出增加，52%表示所在组织没有明确的专职 AI 成本负责人。笔者认为，AWS 这份手册可以看作对这类问题的一种回应。

问题定义：代理式工作负载为何让传统成本管控失效

手册开篇区分了两种工作负载模式。会话式助手（conversational assistant）的成本模型相对可预测：每轮用户交互通常触发1次模型调用（one model invocation per user turn）。代理式工作流（agentic workflow）则完全不同——以 AI 编码助手为例，它在单个任务中执行计划、读取文件、调用工具、迭代修改，每个步骤都可能触发独立的模型调用，且每次调用携带的上下文也更大。

这意味着成本驱动因素从”用户数 × 每次对话的 token 数”变成了”任务复杂度 × 自主程度 × 上下文累积量”。手册明确指出，消耗是工作负载设计和运营方式的函数（consumption is a function of how a workload is designed and operated）。笔者判断，一个设计粗放的代理式工作流，在没有 token 上限、没有缓存、没有模型路由策略的情况下运行，其单任务成本可以远超同等功能的会话式实现。

传统的成本管理手段——比较每个模型的 token 单价、要求应用团队缩短 prompt——在这种模式下暴露出根本性局限。手册将这些手段定性为”有帮助但不够”（those steps help, but they don’t answer the questions），因为它们无法回答规模化运营后财务和工程领导者必须回答的3个问题：哪个团队花了这笔钱？用在哪个工作负载上？这笔支出是否在审批预算之内？

手册同时给出了一个实操建议：不要依赖行业发布的平均数据（published averages are a poor substitute for your own numbers），而是使用 AWS Pricing Calculator 和 Amazon Bedrock pricing page 建模费率，再用手册第2阶段的方法测量自身工作负载的实际消耗。笔者认为，这个建议也说明代理式工作负载的成本可能高度分散——不同设计模式、不同自主程度、不同上下文管理策略下的 token 消耗差异，可能远大于不同模型之间的单价差异。

5阶段运营模型：从归属到运营的完整闭环

手册提出的运营模型包含5个阶段，设计为持续循环（run as a loop）而非一次性项目。阶段之间有严格的依赖关系——手册明确警告，跳过归属和可观测性直接做优化的团队，是在猜测（teams that jump straight to optimization without attribution and observability are guessing）。

在责任分工上，手册将5个阶段分配给两类受众：FinOps 团队主导第1阶段（归属）和第5阶段（运营），负责归属、退费（chargeback）、预算和异常审查；平台工程团队主导第2到第4阶段（可观测、执行、优化），负责日志、请求元数据、执行机制和路由默认值。第5阶段的复盘是两个团队的联合动作。

第1阶段：Attribute——将每1美元归属到所有者

手册将归属定位为整个模型的地基：你无法管理你无法归属的东西（you can’t manage what you can’t attribute），下游的退费、预算、执行和异常检测全部依赖这个阶段的输出。

归属的技术基础是 Amazon Bedrock 的细粒度成本归属能力（granular cost attribution）。AWS 在2026年4月17日通过博客文章介绍了这项能力。其工作原理是：Amazon Bedrock 自动将推理成本归属到发起调用的 AWS Identity and Access Management（IAM）主体，覆盖所有模型，无需管理额外资源。调用者的 ARN 落入 AWS Cost and Usage Report（CUR）2.0 的 line_item_iam_principal 列，覆盖范围包括 IAM 用户、角色、联合身份和 API 密钥。

手册给出了4步设置流程：

  1. 在 CUR 2.0 数据导出中开启 IAM 主体数据。
  2. 为 IAM 主体打上业务维度标签（team、application、cost center）。对于联合访问，需要配置身份提供商通过 OIDC 或 SAML claims 传递会话名称和标签。
  3. 在 AWS Billing 中激活这些标签为成本分配标签（cost allocation tags），可通过控制台或 UpdateCostAllocationTagsStatus API 操作。
  4. 分析标签——标签在 CUR 2.0 中以 iamPrincipal/ 前缀出现。

这套归属机制将归属锚定在 IAM 主体而非应用层自定义标识上，好处是与 AWS 计费管线原生集成，无需自建基础设施（no custom infrastructure）；代价是归属粒度受限于 IAM 主体的建模方式——如果一个 IAM 角色被多个应用共享，归属就会模糊。手册把这一点称为最值得注意的”共享角色问题”（the shared-role problem）：通过单一 IAM 角色调用 Amazon Bedrock 的 LLM 网关会把所有支出都归到这一个角色上，完全失去按用户的可见性；手册给出的解法是按用户管理会话——网关为每个用户 assume 一次调用角色，把用户身份作为会话名称、用户属性作为会话标签传入，并把凭证缓存最长1小时（每用户每小时1次 AWS STS 调用，而非每次请求）。笔者判断，标签的质量和一致性最终仍取决于组织的 IAM 治理成熟度。

手册还提到了两个辅助归属的构件。Application Inference Profile（应用推理配置文件）是预先创建的、按应用的 bedrock-runtime 资源，携带成本分配标签，按”每个应用 × 每个模型 × 每个区域”各建一个，适合应用和模型少而稳定的团队。Amazon Bedrock Projects 则用于 bedrock-mantle 场景。手册明确指出，对于 bedrock-runtime 工作负载，AWS 推荐以”IAM 主体 + 会话标签”作为主要归属机制。

第2阶段：Observe——让每个请求的成本可解释

归属回答”谁花了这笔钱”，可观测性回答”为什么花了这么多”。手册要求每个请求都被记录，且携带足够的元数据来解释其产生的支出（every request is logged with enough metadata to explain what generated the spend）。

Amazon Bedrock 支持把请求数据、响应数据和元数据的模型调用日志写入 CloudWatch Logs、S3 或两者。CloudWatch 用于快速运维查询，S3 + Athena 用于长期 BI 分析。CUR 归属数据约有24小时延迟，CloudWatch 配合 OpenTelemetry 可以搭建分钟级看板，弥补这一时间差。

对于代理式工作负载，这一步尤其关键——一个代理任务可能包含多次模型调用，如果只看聚合的日账单或周账单，无法定位是哪个步骤、哪种调用模式在驱动成本。手册指出，要回答”哪个功能、哪个工作流、哪个租户”的问题，需要在每次调用上打请求元数据。

这形成了一个从”预估”到”实测”的闭环：先用 AWS Pricing Calculator 和 Amazon Bedrock pricing page 建立基线预期，再用可观测数据验证实际消耗是否偏离预期，偏离的部分就是需要调查和优化的目标。手册还要求把日志当作基础设施，而不是手动开关（treat logging as infrastructure, not a manual toggle）：用代码创建日志组或存储桶，定义保留和加密策略，并在环境搭建时验证日志投递；如果日志只在开发环境或单一区域开启，用量一增长，成本管理就会支离破碎。

第3阶段：Enforce——预算必须有牙齿

手册对执行阶段的定义非常直接：预算必须有牙齿（budgets have teeth），最低要求是告警，在风险需要时应设置硬阻断（hard blocks where the risk demands them）。

手册给出了三档执行机制，按强度递进：

Tier 1：监控告警。 使用 AWS Budgets 设置阈值告警，当实际支出接近或超过预算时触发通知。由于 CUR 数据约有24小时延迟，手册建议配合第2阶段搭建的 OpenTelemetry 看板来获得更及时的支出视图。这一档无法硬性停止支出，手册直言团队只能在问题发生之后才看到它（you see the problem after it happens），适合以告警加人工干预为主的早期采用阶段。

Tier 2：IAM 标签强制。 通过 Lambda 从调用日志汇总每用户的 token 数和美元计数，存入 DynamoDB。当某个身份超过预设限额后，将该身份加入共享的 IAM deny 策略（拒绝 bedrock:*），直到月度重置或管理员手动放行。这一档实现了用户级别的硬阻断，但执行有一定延迟。

Tier 3：网关同步阻断。 在推理数据路径上部署网关，超限即返回 HTTP 429。这是最强的执行手段，但代价是需要部署、扩缩和安全评审一个额外的基础设施组件。

手册给出的选择依据是两个维度：连接方式——直连 Bedrock 的架构只能用 Tier 1 和 Tier 2，Tier 3 需要网关；支出速度——如果每月支出已达数百万美元，应立即建设强制机制；如果告警还能撑一个季度，可以先做第1、2阶段再升级。手册建议分阶段推进：先部署 Tier 1，再根据需要升级到 Tier 2 或 Tier 3。

笔者认为，这种分层设计背后有一个实际的工程权衡：对于生产环境中的关键代理式工作流（如客户服务自动化、代码部署管线），硬阻断可能导致任务中途失败，其业务影响可能超过超支本身。但对于开发测试环境或实验性工作负载，硬阻断可以成为防止”无人值守的代理烧掉预算”的保障。

第4阶段：Optimize——让优化成为平台默认值

手册对优化阶段的核心判断是：多数浪费不是个人粗心，而是没人设置的平台默认值。优化应该由平台层集中设置默认值，而非要求每个应用团队自行小心（remove waste centrally instead of asking every team to be careful）。

手册提到的两大平台级杠杆：

模型路由（model routing）。 包括同一模型家族内的 Intelligent Prompt Routing 和网关路由规则。核心逻辑是根据请求的复杂度自动选择合适的模型——简单查询路由到成本更低的小模型，复杂推理路由到能力更强但更贵的大模型。手册强调，哪些工作流能降级是一个实证问题：从第2阶段的可观测排行榜中取头部工作流，在更便宜的模型上做质量评估，通过评估的才路由。

提示缓存（prompt caching）。 手册的说法是，提示缓存奖励稳定、重复的前缀（rewards stable repeated prefixes）。笔者注：代理式工作流中每次调用都会重复发送的系统提示、工具定义等内容，正是这类前缀。手册给出了具体的定价参考：截至2026年10月，美国东部（弗吉尼亚北部）区域 Anthropic Claude 模型的 Bedrock 公开价格，5分钟 TTL 缓存写入按基础输入价1.25倍计费、1小时 TTL 为2倍；缓存读取在 Claude Sonnet 4.6、Claude Haiku 4.5 上为基础价的0.1倍，在 Claude Sonnet 5.5、Claude Opus 5.5 上为0.05倍。手册提醒倍数因模型和区域而异、可能变化，但指出5分钟 TTL 下复用一次即可回本。

手册将应用层优化（即时检索、长对话压缩、把稳定高频工作流蒸馏到小模型）明确归为应用团队的职责，而非平台团队。平台团队的职责是公开每工作流的 token 排行榜，并按模型和工作流设置 token 上限。笔者认为，token 上限也是防止代理式工作流”失控循环”（agent 陷入无效迭代、不断扩大上下文）的直接手段之一。

笔者认为，这个阶段的思路与平台工程中常说的”paved road”相近：平台团队铺好默认路径，应用团队沿着默认路径走就能获得成本优化。

第5阶段：Operate——复盘节奏将数据变成决策

手册将运营阶段定义为一个小型记分卡（small scorecard）加上固定复盘节奏（review cadence），目标是将前4个阶段产生的数据转化为决策（turn the data into decisions）。手册规定了具体频率：高速增长的机群每周复盘一次，其他每两周一次，作为 FinOps 与平台团队的联合决策面。

平台团队的健康看板包含4个关键信号：模型组合（各模型的调用占比是否符合预期）、失败请求率（手册特别指出，客户端超时而服务端仍完成的请求可能被计费两次）、缓存读写比（衡量提示缓存的实际效果）、元数据覆盖率（是否所有请求都携带了足够的归属和可观测元数据）。

当这些信号发生漂移时，手册要求的响应方式是改策略——调整路由规则、token 上限、元数据强制要求——而非发邮件提醒开发者注意。

手册把5个阶段设计为持续循环，并给记分卡设了绿、黄、红三档：红色意味着支出集中在高价模型或未缓存的上下文上，补救路径就是第3、第4阶段的控制手段；手册同时说明这些阈值只是起点而非规定（starting points, not prescriptions），需要按自身机群数据和价格档位校准。

手册在这个阶段强调了一个收尾论点：记分卡第一行应该是”每次成功结果的成本”，而非”每次调用的成本”。 一个工作流再高效，也未必值得运行——需要和它替代的人工流程做比较。这把成本管理从纯粹的技术优化拉回到了业务价值判断。

AWS 构件映射

将手册提到的 AWS 构件按阶段整理：

阶段 核心构件
归属 Granular cost attribution（自动归属到 IAM 主体）、CUR 2.0（line_item_iam_principal 列）、成本分配标签、Application Inference Profile（按应用的 bedrock-runtime 资源，携带标签）、Amazon Bedrock Projects（bedrock-mantle 场景）、AWS Cost Explorer（标签激活后可按团队、应用筛选）
可观测 CloudWatch Logs + S3（模型调用日志）、Athena（长期 BI）、OpenTelemetry（分钟级看板）
执行 AWS Budgets（阈值告警）、Lambda + DynamoDB + IAM deny 策略（Tier 2 强制）、网关（Tier 3 同步阻断）
优化 Intelligent Prompt Routing（模型路由）、Prompt caching（提示缓存）、Token limits（token 上限）
运营 健康看板（模型组合、失败请求率、缓存读写比、元数据覆盖率）、记分卡、按团队和应用的 CUR 分组退费

其中 granular cost attribution 和 Amazon Bedrock Projects 是此前已推出的能力（分别在2026年4月17日和4月7日通过 AWS ML Blog 发布），手册将它们整合进统一的运营框架中。手册本身没有发布新的 AWS 服务或功能。

企业落地的取舍：共担责任下的设计决策

手册开篇就定义了一个组织原则：生成式 AI 的成本管理是构建应用的团队与负责云支出的团队之间的共担责任（a shared responsibility between the teams that build applications and the teams accountable for cloud spend）。这个定义隐含了几个需要企业在落地时做出明确选择的取舍。

归属粒度 vs. 实施成本。 手册的归属方案锚定在 IAM 主体上，手册称之为”发票级、按身份”的归属（invoice-grade, per-identity attribution）。但对于大型企业，IAM 角色的建模方式千差万别——有的企业按团队划分角色，有的按应用划分，有的按环境（dev/staging/prod）划分，还有的使用共享角色加会话标签。手册要求通过 OIDC 或 SAML claims 传递会话名称和标签来解决联合访问的归属问题，这在技术上可行，但需要身份提供商的配置改造和持续的标签治理。归属粒度越细，治理越精准，但前期投入和持续维护成本也越高。

开发者自由度 vs. 成本可控性。 手册第4阶段的核心理念是”平台设默认值，应用走默认路”。但默认值的松紧程度直接影响开发者体验。如果平台默认将所有请求路由到最便宜的模型、设置极低的 token 上限、强制开启缓存，开发者在原型阶段的迭代速度会受到显著影响。反过来，如果默认值过于宽松，就失去了平台层优化的意义。手册没有给出 token 上限等默认值的具体数字，只给了记分卡的起始阈值（例如调用成本更低模型的比例超过50%、缓存读命中率超过60%、每位开发者日支出低于100美元为绿色），并强调要按自身数据校准。笔者判断，这正是因为这个权衡高度依赖组织的风险偏好和工作负载特征。

执行分层 vs. 架构复杂度。 手册的三档执行机制（告警、IAM deny、网关阻断）提供了清晰的升级路径，但每一档的实施成本和架构侵入性差异巨大。Tier 1 无需部署任何组件，Tier 2 需要 Lambda + DynamoDB 的运维，Tier 3 则要在推理路径上增加一个需要部署、扩缩和安全评审的组件。企业需要按工作负载的关键程度和支出规模分级选择。

阶段顺序 vs. 组织耐心。 手册反复强调阶段之间的依赖关系——没有归属就没有有效的预算，没有可观测性就无法评估优化效果。但笔者认为，在实际组织中，管理层可能希望尽快看到成本下降，倾向于直接跳到优化阶段（换更便宜的模型、开缓存）。手册对此的回应非常直接：没有归属和可观测性就做优化，等于在猜测。这个判断在逻辑上成立——如果你不知道哪个团队、哪个工作负载在消耗最多 token，你就不知道优化应该优先作用在哪里，也无法衡量优化的实际效果。

代理时代的 FinOps：从事后分析到平台内建

笔者认为，AWS 这份手册的定位透露了一个信号：代理式 AI 工作负载的成本治理正在从”前沿话题”变成”运营必需品”；手册也提到，Well-Architected Agentic AI Lens 已把代理成本治理列为一等架构关注点（first-class architectural concern）。手册没有讨论代理式 AI 是否应该部署——它假设部署已经发生或即将发生，直接跳到”部署之后如何管理成本”。

手册的方法论贡献在于将成本管理从应用层上移到平台层，并给出了明确的阶段顺序和责任分工。在传统的云成本管理中，FinOps 团队的主要工作是事后分析账单、识别浪费、推动优化。笔者的理解是，手册提出的模型把 FinOps 的介入点前移到了架构设计阶段——归属方案需要在 IAM 建模时就考虑，日志需要作为基础设施在环境搭建时就配置并验证；至于强制执行，手册的建议是如果告警还能撑一个季度，可以先做第1、2阶段，等数据需要时再加。

笔者判断，AWS 以手册形式（而非产品发布形式）输出这套方法论，其意图之一可能是在代理式 AI 成本治理领域建立方法论标准。但手册的收尾论点本身更值得关注：记分卡第一行应该是”每次成功结果的成本”，要和它替代的人工流程做比较。这意味着成本治理的终极问题不是”如何让 token 更便宜”，而是”这个自动化工作流是否比人工完成同样任务更划算”。不过手册明确把这个判断划给产品与分析团队，而不是 FinOps（a product and analytics discipline rather than a FinOps one）；成本平台的贡献是提供干净的归属和按工作流的成本数据，作为衡量结果的输入。

AWS 这份手册为行业提供了一个可参照的运营模型，但其具体实施高度依赖 AWS 生态的构件。每个企业的 IAM 结构、组织架构、工作负载特征和风险偏好都不同，笔者判断，5阶段模型的落地需要相当多的定制工作（手册也说明这套方法可以按自身环境定制）。手册提醒，行业平均数据不能替代自己的数字（published averages are a poor substitute for your own numbers），建议用 AWS Pricing Calculator 建模，再用第2阶段的方法测量实际消耗。

主题分类：企业AI落地

参考资料

  1. Managing Amazon Bedrock costs end to end: A playbook for FinOps and platform teams — AWS Machine Learning Blog, 2026-10-30
  2. Manage AI costs with Amazon Bedrock Projects — AWS Machine Learning Blog, 2026-04-07
  3. Introducing granular cost attribution for Amazon Bedrock — AWS Machine Learning Blog, 2026-04-17
  4. State of AI in FinOps 2026 — Harness（调查于2026年5月至6月进行）