告别 Amazon Bedrock AgentCore 调用中的空转计费

AI 智能体与传统流水线步骤最大的区别在于它需要「思考时间」。处理时长取决于提示词、模型选择和文档复杂度，往往从数秒到数十秒不等。Amazon Bedrock AgentCore 运行时在智能体等待模型生成或工具调用返回期间，只收取内存费用而不收取 CPU 费用。然而，发起同步调用的 Lambda 函数却没有这种优待——它会持续阻塞并支付全部计算费用，直到收到响应。这意味着浪费并不发生在智能体侧，而是发生在调用方。

为了在同等条件下对比各种模式，AWS 设计了一条五阶段文件验证流水线：提取（OCR 与文本抽取）、识别（文档分类与路由标志设置）、路由（Choice 状态分流）、并行处理（文档整理与智能体验证同步执行）、结果处理（根据智能体裁决决定审批或退回）。四种调用模式的差异仅体现在「验证」分支，其余阶段完全相同，便于精准对比各方案的成本与复杂度。

任务令牌回调模式是最具代表性的异步方案。Step Functions 在启动验证步骤时生成一个任务令牌并传递给智能体，调用方随即退出并停止计费。智能体完成推理后，通过动作组中的 Lambda 函数调用 `sfn.send_task_success` 将令牌和裁决结果一并返回，Step Functions 收到信号后恢复后续执行。整个等待期间，调用方不消耗任何计算资源，费用仅产生于启动和回调两个极短的时刻。

直接服务集成模式在任务令牌方案基础上更进一步，完全省去了中间的回调 Lambda。Step Functions 通过原生 SDK 集成直接调用 AgentCore，并由 Step Functions 自身管理令牌的发放与接收。这种方式减少了一个需要维护的 Lambda 函数，降低了架构复杂度，同时保留了相同的异步语义。对于希望最小化组件数量的团队而言，这是最简洁的选择。

持久函数模式则适用于需要在智能体调用前后保留本地状态的场景。调用方以持久执行的形式启动，生成一个回调 ID 后挂起自身；智能体完成后调用 `send_durable_execution_callback_success` 唤醒持久函数，后者从挂起点继续执行并可访问之前保存的上下文。这种模式在需要跨多个异步步骤维护复杂状态时尤为有用，代价是引入了持久函数运行时的额外依赖。

值得注意的是，示例中的单个 AgentCore 智能体能够同时支持全部四种调用模式，无需重新部署。智能体在收到请求时检查是否携带任务令牌或回调 ID，据此决定以异步回调还是同步返回的方式响应。这种设计将编排策略与智能体逻辑彻底解耦，团队可以在不修改智能体代码的前提下自由切换或升级调用模式，极大降低了迁移成本。

要点

• 同步阻塞调用会让 Lambda 等函数在智能体整个处理周期内持续计费，而 AgentCore 运行时本身在等待期间不收取 CPU 费用，成本浪费完全来自调用方
• 任务令牌回调、直接服务集成、持久函数三种模式均可将调用方计费时间压缩至启动和回调两个瞬间，从根本上消除空转成本
• 直接服务集成省去回调 Lambda，是三种异步模式中架构最简洁的选择；持久函数则适合需要跨步骤保留复杂状态的场景
• 单个 AgentCore 智能体可通过检测请求中的令牌或回调 ID 自动适配不同调用模式，编排策略与智能体逻辑完全解耦，切换模式无需重新部署智能体