迁移 AgentCore 前重算成本模型

Amazon 已不再向新客户开放 Bedrock Agents Classic。现有 Agent 仍可继续运行，Amazon 也尚未公布终止支持日期。但如果你正计划迁移到 AgentCore，有一个迁移步骤值得投入更多关注：

在迁移代码之前，先重新审视你的成本模型。

计费模型已经改变

使用 Bedrock Agents Classic 时，大多数团队通常只需要考虑：

• Knowledge Base 查询

编排层本身并不是一项单独计费的服务。

AgentCore 改变了这一点。

除了推理成本，现在还会产生 Agent 调用、Gateway 请求等平台层面的费用。这意味着，总成本不再仅由 token 用量决定。

仅追踪 token 已经不够

许多内部成本仪表盘大致是这样的：

interface SessionCost {
  inputTokens: number;
  outputTokens: number;
  estimatedCost: number;
}

当推理费用几乎占据全部账单时，这种方式非常有效。

迁移后，每个 session 的总成本可能还包括平台活动产生的费用，而基于 token 的追踪方式完全无法捕捉这些成本。

问题不在于计算结果错误，而在于计算并不完整。

从两个成本层面思考

不要再把「AI 成本」视为一个单一数字，而应该将其拆分为两类：

• 其他编排费用

分别追踪这两类成本，可以让你更容易理解成本为什么会随时间发生变化。

prompt 优化会影响推理成本。

编排架构的重新设计可能几乎不会改变 token 用量，却会显著增加平台活动。

这是两类不同的工程问题。

迁移正是验证现有假设的好机会。

我建议针对同一工作负载，在将变更部署到生产环境之前，对比：

• 预估推理成本
• session 综合成本

建立这条基线后，未来的成本回归问题会更容易被发现。

AgentCore 并不是唯一采用这种模式的平台。

纵观整个行业，Agent 平台正在变得更有主见、能力也更强——而这通常意味着，越来越多的费用会从模型层转移到编排层。

多年以来，只追踪 token 就足够了。

但未来，团队将越来越需要把模型成本和平台成本视为两项独立预算。

你的可观测性体系越早体现这种拆分，未来的迁移就会越轻松。https://github.com/salimassili62-afk/ai-costguard

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。