把工作流状态机当 agent 工具：Step Functions 接入后的编排取舍

"把状态机当 agent 工具"这件事，答案不是能不能调，而是调完之后谁来负责。按 AWS 在 2026 年 11 月 2 日 Weekly Roundup 中的说法，Step Functions 现在可以通过 Amazon Bedrock AgentCore Gateway，以 Model Context Protocol（MCP）工具的形式交给 agent 使用，已有的 Standard 和 Express 工作流可以作为 connector target，不需要重写（AWS News Blog，2026-11-02）。

真正需要设计的是分工：agent 决定什么时候跑、传什么参数；状态机负责按你写好的顺序逐步执行。下面按"材料确认了什么—取舍在哪里—接之前核对什么"展开，凡材料没写的，一律标为待核实，不替 AWS 补文档。

材料确认的事实边界#

• 规模背景：Step Functions 此前已用于编排 220 多个 AWS 服务（AWS 表述），现在这些工作流可以被 agent 当作工具调用。
• 接入方式：经 Amazon Bedrock AgentCore Gateway 暴露，走 MCP 协议连接 agent 与工具，不是让模型直接生成状态机定义。
• 分工示例：AWS 给的例子是客服 agent 触发退款——资格校验、经理审批、实际入账仍按固定顺序执行，因为"顺序从来不是交给模型即兴发挥的"。
• 覆盖面：现有 Standard 与 Express 工作流都符合 connector target 的条件；agent 还可以查询运行记录。
• 可用性与计费：在与 AgentCore Gateway 相同的区域提供，按标准费率计费。

材料没有说明的部分，同样重要：connector 的工具描述和入参 schema 由谁生成、能否手写约束；单次调用的输入输出载荷上限；工作流失败时 agent 看到的是错误码、异常信息还是完整执行历史；Express 工作流被调用时是同步返回结果还是只返回运行标识；终端用户身份如何传播到这次状态机执行；以及具体的区域清单和费率数字。以上均待核实，不要在方案评审里把它们当成已知条件。

取舍一：顺序归谁#

状态机当工具的核心收益是"顺序不可协商"。只要一步接一步的次序是合规要求或业务硬约束——审批在入账前、校验在扣款前——把它留在状态机里，模型就没有改写的余地。反过来，如果流程本身就是"看情况决定下一步做什么"，硬塞进状态机只会逼你写一堆分支和占位步骤，最后状态机变成了模型决策的记录本。

一个可操作的判断：把流程里"审计时能指着说这一步必须在下一步之前"的环节挑出来，这些属于状态机；剩下"这次先查 A 还是先查 B"的环节，属于 agent 或它直接调用的细粒度工具。

取舍二：输入由谁构造#

agent 传参是必要的，但传什么参数需要划界。同一篇 Roundup 里提到 MoEngage 用 AgentCore Gateway 把约 400 个内部 REST API 操作变成 agent 工具，横跨 25 个团队、分布在 7 个区域的私有 VPC 中，其中一条硬约束是：租户身份绝不能变成模型可以设置的参数。这条原则平移到 Step Functions 上同样成立——订单号、退款原因可以来自模型，租户 ID、调用者身份这类决定"能看见谁的数据"的字段，应该来自网关或执行角色，而不是工具入参。

代价是：入参越窄，工具描述就越需要写清楚哪些字段是必填、哪些由平台注入。而 connector 是否支持在工具 schema 层面做这种收窄，材料没有说明，待核实。

取舍三：失败与补偿由谁承担#

状态机本来就擅长处理重试、超时、补偿步骤，把这些留在工作流内是顺理成章的。但有一件事需要提前确认：agent 拿到失败信号后，能不能判断"该重试"还是"该换一条路"。如果它只看到一个笼统的失败，就可能反复触发同一个注定失败的工作流，把重试策略从状态机里搬到模型侧——那是最不划算的搬法。

建议在工作流内部就把可重试错误和终态错误分开，并让最终返回给 agent 的结果明确表达"这次是彻底失败还是可再试"。具体能暴露到什么粒度，取决于 connector 的错误映射，待核实。

取舍四：工具粒度与目录膨胀#

Step Functions 的接入有一个天然优势：一个 workflow 就是一个工具，工具数量等于你愿意暴露的工作流数量，而不是内部步骤数量。MoEngage 的案例从反面说明了这件事的分量——材料提到，如果一次性列出全部工具，每条连接的清单会超过 20,000 tokens，所以他们的做法是让 agent 通过描述任务来检索工具，而不是把目录整个塞给模型。

由此产生的取舍是：

如果暴露的工作流会到几十上百个，就需要考虑工具检索这条路；但 Step Functions connector 自身是否支持按描述检索、还是只能靠网关侧做工具分组，材料未说明，待核实。

什么情况下不该走这条路#

• 单步、低延迟的调用：状态机的价值在多步与持久化，为一次查询包一层工作流，多出来的是一次跳转和一层 schema（这是推断，具体延迟差异需自行测量，材料未给数据）。
• 每步都要模型读中间结果再改参数：如果中间结果不向 agent 暴露，模型只能依据最终输出决定下一步，这类交互式流程不适合整段塞进状态机。
• 流程每周都在改：工作流一旦作为工具暴露，描述和 schema 的维护成本就跟着流程变化走，变更频率高时先评估这部分开销。

接入前核对清单#

1. 确认工作流类型：Standard 还是 Express，以及被工具调用时的返回语义是否符合你的交互设计（待核实）。
2. 确认工具描述与入参 schema 的来源：自动生成还是可以手写覆盖（待核实）。
3. 确认身份注入点：租户/用户身份从网关或执行角色来，不出现在模型可写的字段里。
4. 确认错误映射：可重试错误与终态错误在返回结果里是否可区分（待核实）。
5. 确认载荷上限：输入输出大小限制、是否支持引用大对象而非内联传递（待核实）。
6. 确认运行查询能力：agent 能查到哪些运行字段，是否足以支撑审计（待核实）。
7. 确认区域与计费：AgentCore Gateway 的实际可用区域清单与标准费率的具体数字（待核实）。

一个未执行的示例#

下面两段仅用于说明结构，未实际执行，字段名与调用方式需以实际 connector schema 为准（待核实）。

{
  "workflowArn": "arn:aws:states:REGION:ACCOUNT:stateMachine:YOUR_WORKFLOW",
  "input": {
    "orderId": "ORDER-EXAMPLE-0001",
    "reason": "duplicate_charge",
    "tenantId": "INJECTED_BY_GATEWAY_NOT_BY_MODEL"
  }
}

对应的状态机骨架大致如下，重点是顺序显式写死在定义里，而不是留给调用方：

{
  "StartAt": "CheckEligibility",
  "States": {
    "CheckEligibility": { "Type": "Task", "Next": "ManagerApproval" },
    "ManagerApproval":  { "Type": "Task", "Next": "IssueCredit" },
    "IssueCredit":      { "Type": "Task", "End": true }
  }
}

观测与成本#

材料提到 agent 可以查询运行记录，这为审计留了一条线索：出问题时至少能区分"模型没调用"和"调用了但工作流失败"。至于这条线索能细到什么程度、是否覆盖每次调用的输入快照，待核实。

成本方面，AWS 的说法是"按标准费率"，没有给出数字。可以确定的是计费会叠加两部分：状态转换本身，以及 AgentCore Gateway 一侧的调用。具体量级只能在自己的调用模式下测，材料里没有可引用的数字。

结论#

把 Step Functions 当 agent 工具，适合的场景很明确：你有一段顺序不能改、需要审计、已经有工作流在跑的业务流程，而 agent 只负责判断"要不要跑、跑哪一条、带什么参数"。不适合的场景同样明确：流程本身是探索式的，或者每一步都需要模型看着中间结果改主意。

落地前把三件事写进设计文档：顺序留在状态机、身份不进模型参数、失败语义先核对再依赖。剩下的细节——schema、载荷、错误粒度、区域与费率——材料里没有答案，请以接入时的实际文档和一次受控试跑为准。