AWS Step Functions工作流可经AgentCore Gateway成为AI智能体工具：步骤顺序由状态机决定

AWS 于 2026 年 10 月 29 日宣布，AWS Step Functions 的工作流现在可以通过 Amazon Bedrock AgentCore Gateway 作为 AI 智能体的工具使用。智能体决定何时运行工作流、传入什么输入，Step Functions 则严格按你定义的步骤执行。现有的 Standard 和 Express 工作流都可以直接作为工具，使用时按 Step Functions 和 AgentCore Gateway 的标准价格付费。

这件事的价值在于分工。AgentCore Gateway 通过模型上下文协议（MCP）把智能体连接到工具，Step Functions 负责按固定顺序执行多步骤业务流程。AWS 举的例子是客服智能体启动退款工作流，由 Step Functions 依次执行资格检查、经理审批和入账步骤，使每笔退款都符合政策；运维智能体还可以查询工作流的运行记录，告诉值班工程师昨夜哪些订单运行失败、失败在哪一步。官方说明里提到 Step Functions 能编排 220 多项 AWS 服务，这是 AWS 自己给出的数字。该功能在所有提供 AgentCore Gateway 的区域可用。

开发者指南说明了它如何工作。你创建网关目标时选择内置的 Step Functions 连接器，不需要写 Lambda 函数或 MCP 服务器，也不用自己定义工具，网关会生成工具的输入格式并代表智能体调用 Step Functions。连接器共暴露十项操作。其中四项作用于你在创建目标时“固定”的状态机：StartExecution、StartSyncExecution、ListExecutions 和 DescribeStateMachine；智能体看不到被固定的状态机，也无法更改，如果它传入 stateMachineArn，网关会拒绝该调用。另外六项作用于智能体提供的执行 ARN 或任务令牌：DescribeExecution、StopExecution、GetExecutionHistory、SendTaskSuccess、SendTaskFailure 和 SendTaskHeartbeat，它们不受固定状态机限制，只能靠网关服务角色的 IAM 策略来约束。

权限边界需要特别注意。文档建议把 IAM 策略收得尽量紧，例如把 DescribeExecution、StopExecution 和 GetExecutionHistory 限定到你所暴露状态机的执行 ARN，而不是授予 states:*。三个 SendTask 操作在 IAM 里没有资源级权限，只能对“*”授权，此时任务令牌是唯一的控制手段，所以要把任务令牌当作机密。可以固定的操作如果没有设置 stateMachineArn，网关虽然能创建目标，但工具每次调用都会失败。

两种工作流类型能用的操作不同。StartSyncExecution 只适用于 Express，在 Standard 上会失败；ListExecutions 只适用于 Standard，对 Express 会返回 StateMachineTypeNotSupported；DescribeExecution、GetExecutionHistory 和 StopExecution 只适用于 Standard 的执行，因为 Express 执行启动后无法用 ARN 寻址。StartExecution、DescribeStateMachine 和 SendTask 系列两种类型都可用。Standard 工作流会记录每一步的执行历史，最长可运行一年，适合需要审计或人工审批的长流程：工作流用 .waitForTaskToken 暂停，把令牌交给智能体的应用，智能体完成后调用 SendTaskSuccess 或 SendTaskFailure 让流程继续。Express 配合 StartSyncExecution 适合同步的请求响应。 这里“两者都可用”只指连接器操作；.waitForTaskToken 回调仅 Standard 工作流支持，Express 不支持这种回调。

教程把这件事拆成六步：创建状态机，为网关创建服务角色，创建网关并加入 Step Functions 连接器目标，通过网关启动执行，确认结果，最后清理资源。教程配置了十项操作中的六项，并用 awscurl 发出与智能体相同的 MCP 请求。智能体先调用 tools/list 发现每项已配置操作对应的工具，被固定的参数不会出现在工具的输入格式里，例如 StartExecution 只会公布 input。开发者指南还给出一个典型的调用顺序：先 StartExecution，再用返回的 ARN 调用 DescribeExecution 查状态，最后用 GetExecutionHistory 查看各步骤。智能体与工作流协作有两种形式：智能体启动、检查并按需停止工作流，或者工作流在 .waitForTaskToken 处暂停，等待智能体完成一项任务。

几处细节也值得记住。每项操作只能固定一个状态机，要对同一操作暴露多个状态机，就得为每个状态机各建一个目标；一个目标里可以把 StartExecution 固定到 Standard 状态机，把 StartSyncExecution 固定到 Express 状态机。智能体若传入 stateMachineArn，网关返回的错误是 Invalid request parameters: cannot set parameter(s): [/stateMachineArn]。工具返回的是 Step Functions 的 API 响应，例如新执行的 ARN，以 JSON 形式放在工具结果的文本里。AWS 页面没有说明何时需要 Express、何时需要 Standard，但开发者指南给出了判断依据：需要执行历史、需要长时间运行或需要人工回调的流程用 Standard，需要同步拿到结果的请求用 Express 加 StartSyncExecution。

教程里的示例只有一个 Pass 状态的 Standard 状态机，用 awscurl 发出与智能体相同的 MCP 调用；所有资源要建在同一区域，网关调用的是自己所在区域的 Step Functions，教程资源会产生状态转换和工具调用费用，用完要清理。AWS 的页面没有给出延迟、规模或客户案例的数字，所以这是一个能力说明，不是性能报告。它的实际价值取决于你的工作流是否已经被良好定义，以及网关服务角色的权限是否收得足够紧。