把工作流引擎当 agent 工具：状态机语义与失败重试的核对清单

2026 年 11 月 2 日的 AWS Weekly Roundup 提到，Step Functions 现在可以作为 agent 工具交给模型调用（AWS News Blog）。这条消息容易被读成"工具列表又多了一项"，但对要落地的人来说，需要先回答的是另外两个问题：工作流的执行顺序由谁拥有，以及失败之后重试发生在哪一层。这两件事没核对清楚，接入越顺，越容易在副作用上出问题。

发布摘要的边界在哪#

材料里能确认的有三点：

• Step Functions 通过 Amazon Bedrock AgentCore Gateway 以 MCP（Model Context Protocol，模型上下文协议）暴露为 agent 工具；
• 分工是 agent 决定何时运行工作流、传什么输入，Step Functions 按定义执行每一步；
• 现有的 Standard 和 Express 工作流都可以作为 connector target，agent 还能查询运行记录；在 AgentCore Gateway 可用的区域提供，按标准费率计费。

摘要没有覆盖的部分同样重要：工具调用失败如何映射成错误、重试预算由谁设定、同一工作流的并发执行上限、执行记录的保留策略。这些本次材料未提供，需要对照官方文档确认，不能从"可以作为工具调用"推出来。

状态机语义：先确认顺序不属于模型#

原文对分工的描述很直接：agent 决定什么时候跑、传什么；每一步仍然按你定义的方式执行，因为顺序"从来不是模型可以即兴发挥的东西"。原文举的例子是退款——资格检查、经理审批、入账，每次都按这个顺序发生。

由此可以推出一个结论（推断，非原文陈述）：模型能影响的面只有两个，调用时机和输入内容。核对清单因此可以收窄到这两处，而不必去担心模型会不会"跳过审批"这类问题。

输入边界

工具参数最终要变成工作流期望的输入结构。需要核对的是：这个结构有没有 schema 约束，模型生成的自由文本在哪一步被转成结构化字段，转换失败时是拒绝调用还是带着默认值继续跑。

MoEngage 的案例提供了一个直接参照：他们把约 400 个内部 API 操作暴露成 agent 工具时，明确要求租户身份不能成为模型可以设置的参数（同一篇来源）。工作流工具同理——租户、用户、请求来源这类字段应该从调用上下文注入，而不是出现在参数列表里让模型填。

一次调用对应几次执行

这是最容易被忽略的一条。工具调用在语义上不等于一次执行：模型可能因为超时重发，框架可能因为 5xx 重试，而引擎收到两次请求就是两次执行。对退款这类有副作用的流程，需要在工作流入口以幂等键去重，而不是指望上游只调用一次。引擎自身是否提供入口级去重，本次材料未涉及，需另行核实。

重试要分三层核对#

把工作流当工具之后，失败可能发生在三个位置，每一层都有自己的重试策略：

1. 模型或 agent 框架层：工具调用报错后，agent 循环是否会自动再试，重试几次，退避多久。
2. 网关与 MCP 传输层：连接断开、超时这类传输失败是否被透明重发。
3. 工作流定义内部：步骤级的重试与补偿，写在你自己的状态机里。

风险不在任何单层，而在叠加：三层各重试两次，一个副作用步骤就可能被执行多次。核对方法很朴素——把三层的次数乘起来，问一句"最坏情况下这笔退款会执行几次"。如果答案不是 1，就需要在副作用步骤前加幂等键，或者把重试收敛到单独一层。

另一个方向是让重试显式化：在定义里写清楚哪些错误可重试、哪些必须直接失败。材料没有说明 AgentCore Gateway 会把哪些错误原样透传给模型，这一点会直接影响 agent 侧的重试判断，需要实测或查文档后才能定。

把"查询运行"当成核对面#

材料提到 agent 可以查询运行记录。这条能力值得单独设计：让 agent 在报告"已完成"之前先查一次执行状态，而不是把"工具调用返回成功"当成"业务成功"。前者是状态机语义，后者只是传输语义。对审批类流程，两者之间的差距可能是几十分钟甚至几天。

工具目录的规模会反过来影响工作流设计#

MoEngage 案例里还有一个细节：完整工具列表每个连接会超过 20,000 tokens，所以他们的做法是让 agent 通过描述任务来检索工具，而不是一次性收到全量目录（来源）。把工作流当工具时会遇到同样的问题——工具描述如果写成"内部有 12 个步骤"，既占 token 又帮不上模型判断。更实用的写法是描述"什么情况下该调用它、需要准备哪些输入"，把步骤细节留在状态机里。

一份可执行的核对表#

一个未执行的示意#

下面的片段只用来标出"重试写在哪、幂等键放在哪"这两个位置。未执行，字段语义也未在本次材料中核验，实际写法请对照你所使用版本的官方文档。

{
  "StartAt": "CheckIdempotency",
  "States": {
    "CheckIdempotency": {
      "Type": "Task",
      "Comment": "占位：按 idempotencyKey 查询是否已执行，已执行则直接结束",
      "Next": "EligibilityCheck"
    },
    "EligibilityCheck": {
      "Type": "Task",
      "Retry": [
        {
          "ErrorEquals": ["States.TaskFailed"],
          "IntervalSeconds": 2,
          "MaxAttempts": 2,
          "BackoffRate": 2.0
        }
      ],
      "Next": "ManagerApproval"
    },
    "ManagerApproval": {
      "Type": "Task",
      "Comment": "占位：人工审批，不应由 agent 侧重试触发第二次",
      "End": true
    }
  }
}

示意里把重试限制在单个步骤，并在入口用 idempotencyKey 去重。真实的 Amazon States Language 如何表达入口去重、Retry 的错误匹配规则、以及超时与心跳字段，都需要另行核对，不能照此直接上线。

结论与不确定性#

把工作流引擎当 agent 工具，价值在于"顺序不用重写"，代价在于失败路径变长。核对的重点因此不是模型能力，而是三件事：输入是否被约束、身份是否从上下文注入、重试是否只在一个地方发生。

需要说明的是，本文对错误透传规则、并发上限、执行记录保留策略的判断都属于待核实项——本次材料只提供了发布摘要与案例描述，没有提供这些细节。落地前建议先用一条无副作用的测试工作流跑通"调用—失败—重试—查询"整条链路，再接入真实业务步骤。