AWS 解析 Bedrock AgentCore 三种异步调用模式

AWS 在其机器学习博客上发表了一篇技术文章，解析在无服务器（serverless）管道中调用 Amazon Bedrock AgentCore agent 时，如何通过异步模式释放调用方的空闲算力。文章对比了任务令牌回调、直接服务集成和 Durable Function 三种模式与同步阻塞模式之间的成本与架构差异。

AI agent 调用为何不适合传统同步等待

与传统管道步骤不同，AI agent 在给出最终结果前需要进行推理。推理耗时取决于 prompt、模型与输入内容，几乎不可能瞬时完成。如果用 Lambda 函数同步调用 agent 并等待响应，函数本身会被阻塞：在 agent 思考期间，它占用的 CPU 配置被持续计费，造成大量浪费。

文章用房产融资文件验证的场景来说明这一点。管道包含五个阶段：

• 提取（Extract）：Lambda 函数对文档执行 OCR 与文本抽取（文章中以模拟方式运行）。
• 识别（Identify）：Lambda 对文档分类并设置 shouldOrganize、shouldValidate 等路由标记。
• 路由（Route）：Choice 状态根据标记引导流程。
• 组织与验证（Organize and Validate）：Parallel 状态组织文档，并在独立分支中由 AgentCore agent 进行验证。其中 Validate 分支是各模式间唯一变化的部分。
• 结果（Result）：Lambda 处理 agent 判断结果，决定批准或退回修正。

成本落点：Agent 侧与调用方侧的计费差异

Amazon Bedrock AgentCore Runtime 采用基于消费的计费模型：当 agent 等待 LLM 生成、工具调用或 Model Context Protocol（MCP）返回时，按内存计费，但不收取 CPU 费用。然而，调用方的 Lambda 函数、容器或 EC2 实例发起同步调用后会完全阻塞，持续占用并支付其全部计算资源，直到 agent 返回。

这意味着同步调用方的成本几乎与 agent 的运行时长线性挂钩：一个阻塞的函数会被计费整整一段处理时间，而一个启动 agent 后立即返回的函数仅需支付极短的派发开销。真正的浪费发生在调用方一侧。

三种异步模式概览

文章展示了三种能让调用方在等待期间释放算力、并在 agent 完成后恢复管道的模式：

• 任务令牌回调（Task-Token Callback）：agent 完成推理后调用 Lambda，将结果连同任务令牌回传给 Step Functions，由后者恢复执行。
• 直接服务集成（Direct Service Integration）：Step Functions 与 AgentCore 直接集成，省去了回传用的 Lambda。
• Durable Function 回调：使用 Durable Function 的 callback ID 唤醒等待中的执行。

三种模式的核心机制都是「return-of-control」动作——agent 在其 action group 中调用一个 Lambda，把结果与对应的令牌或回调 ID 提交出去，从而把控制权交还管道编排器。

统一 agent 支持多模式切换

文章中只部署了一个 AgentCore agent 为所有四种调用方式服务。agent 在每次被调用时检查输入中是否包含 AWS Step Functions 的 task token、durable-function 的 callback ID，或两者都没有：

• 若收到 task token，调用 sfn.send_task_success 唤醒对应的 Step Functions 执行。
• 若收到 callback ID，调用 lambda_client.send_durable_execution_callback_success 恢复 Durable Function。
• 若两者都无，则按同步方式在响应中直接返回判断结果。

这意味着开发者可以更改编排模式而无需重新部署或修改 agent 本身。文章给出关键代码片段，展示 conclude_validation 工具如何根据传入信号选择不同返回路径，以及 agent 入口点 validate_document_async 如何通过 @app.async_task 装饰器以后台方式运行，让控制流在 agent 推理期间立即回到编排器。

文章最后指出，这三种异步模式适用于任何需要调用 agent 或其他慢服务的下游工作流，房产融资文件验证只是一个刻意简化的占位示例。开发者可将相同的思路套用至自己的业务场景中，根据延迟、成本与编排复杂度选择合适的模式。