把 Step Functions 当 agent 工具：编排层与模型层各该承担什么

对 API.PLUS 的开发者读者来说，这个问题可以先给出一句话答案：把 Step Functions 当 agent 工具，不是让模型接管工作流，而是把已有的确定性编排暴露成一个可调用入口。模型层决定“要不要做、传什么业务输入”，编排层决定“按什么顺序做、在什么条件下继续、失败后怎么处理”。据 AWS 2026年11月2日周报，Step Functions 已能编排超过 220 个 AWS 服务，现在又可通过 Amazon Bedrock AgentCore Gateway 以 Model Context Protocol（MCP）工具的形式提供给 agent；现有 Standard 和 Express 工作流可作为连接目标，agent 也可以查询运行记录。材料还说明，该能力在 AgentCore Gateway 可用的所有区域提供，按标准费率计费。具体 MCP 工具 schema、鉴权细节与配额，本文材料未展开，待核实。

分工：模型层决定“要不要做”，编排层决定“怎么做”#

这次能力的关键不是模型更会“规划”，而是把两类职责分开。周报的表述很直接：agent 决定何时运行工作流、传什么输入；Step Functions 按你定义的步骤执行。换句话说，模型面对的是一个业务级工具，而不是一张可以随意改写的流程图。

• 模型层适合承担：理解用户请求、判断是否需要调用工具、构造业务输入、解释工作流返回结果，以及在必要时决定再调用一次。它擅长处理自然语言和非结构化上下文，但不适合保证步骤顺序。
• 编排层适合承担：按定义执行每一步、保存运行状态、处理审批等待、重试与失败分支、记录审计信息。周报给出的退款例子是：支持 agent 触发退款，但资格检查、经理审批和入账仍按固定顺序发生，因为顺序本来就不该由模型即兴决定。
• 不应交给模型层：步骤先后、租户身份、权限边界和金额审批条件。MoEngage 的案例被周报用来说明这一点：约 400 个内部 REST API 操作由 25 个团队建设，分布在 7 个区域的私有 VPC 中，租户身份不能变成模型可以设置的参数。

这不是“模型能力高低”的问题，而是责任归属问题。模型输出具有概率性，工作流执行需要可重复。把顺序写进 Step Functions，把业务输入留给模型；把身份和权限放在服务端上下文，模型看不到，也不应该能改。

工具契约：给模型一个窄而稳定的入口#

如果只把状态机 ARN 暴露给模型，模型很难知道什么时候该调用、该传什么。更合理的做法是提供一个业务语义明确的工具描述，并限制输入字段。下面的 JSON 只是示意，不是官方 schema，也未执行；示例中的 REGION、ACCOUNT_ID、WORKFLOW_NAME 均为占位。

{
  "name": "start_refund_workflow",
  "description": "发起退款审批工作流。仅在订单号和金额已确认时使用，返回 runId。",
  "inputSchema": {
    "type": "object",
    "required": ["orderId", "amount", "reason"],
    "properties": {
      "orderId": { "type": "string", "description": "订单号，不由模型推断" },
      "amount": { "type": "number", "description": "退款金额" },
      "reason": { "type": "string", "description": "退款原因" }
    }
  },
  "target": "arn:aws:states:REGION:ACCOUNT_ID:stateMachine:WORKFLOW_NAME"
}

设计上有几个边界值得先定下来。第一，工具名和描述按任务写，不要把所有内部 API 一次性摊给模型。周报提到 MoEngage 的完整工具列表在每个连接上会超过 20,000 tokens，因此他们让 agent 通过描述任务来搜索工具，而不是接收全量目录。这是该部署的估算，不是所有系统的固定阈值，但说明工具发现方式会影响上下文成本。

第二，输入 schema 只放业务字段。租户 ID、用户 ID、调用者身份应由网关或服务端上下文绑定，不要作为模型可填参数。第三，长流程不要强行在一次模型调用里阻塞等待；启动工作流后返回运行标识，再用单独的工具查询运行状态。材料确认 agent 可以查询运行记录，但具体返回字段和查询接口待核实。

退款流程示例：模型只碰两端，中间交给编排#

周报中的退款例子可以拆成下面这条链路。它是一个来源示例，不是本文实际部署过的流程：

1. agent 识别退款意图，选择“发起退款工作流”工具，传入订单号、金额和原因。
2. Step Functions 在入口校验输入，启动一次运行，并返回运行标识。
3. 工作流执行资格检查；不满足条件就进入拒绝分支。
4. 需要经理审批时，工作流停在审批节点，等待外部决定。
5. 审批通过后执行入账；失败则按定义重试或进入补偿分支。
6. agent 查询运行结果，向用户解释“已提交”“审批中”或“被拒绝”。

在这条链路里，模型负责第 1 步和第 6 步，中间的顺序、状态和审批由 Step Functions 负责。这样即使用户在对话里换一种说法，也不会改变“先检查资格、再审批、后入账”的顺序。反过来，如果把顺序写进提示词，模型每次都可能给出不同路径，审计和重试也会变得难以收口。

适用与不适用：先看流程是否值得确定性#

还要注意，材料只说明现有 Standard 和 Express 工作流可作为连接目标，并未展开两者在 agent 调用下的执行语义、超时和配额差异；这些应按官方文档进一步核实。区域、计费和 MCP 版本支持同样属于待核实项，不能从周报摘要外推。

安全与运维清单#

• 最小权限：每个工具只允许启动指定状态机或别名，不要给模型通用的启动权限。这是建议，不是材料中的现成配置。
• 身份绑定：租户和用户身份从网关或服务端上下文注入，不进入模型参数。MoEngage 的案例支持这一原则。
• 输入校验：在状态机入口校验金额、订单号和自由文本，避免模型把不确定内容直接送进审批或入账步骤。
• 幂等与重试：用业务键做幂等；重试放在编排层，避免模型重复调用造成重复退款。这是设计建议。
• 可观测性：记录工具调用、运行标识、审批人、最终状态和失败原因；材料确认 agent 可查询运行记录，但审计字段需自行设计。
• 工具发现：工具多时按任务描述检索，不要把完整目录注入每次对话；同时为工具描述建立版本管理。

结论#

把 Step Functions 当 agent 工具，核心是把“确定性”留给编排层，把“意图与选择”留给模型层。模型决定何时调用、传什么业务输入、如何解释结果；Step Functions 决定步骤顺序、审批、重试、状态和审计。这个分工适合已有工作流、顺序重要且需要可重复执行的场景；单步低延迟调用或开放式探索则未必需要一条状态机。本文依据 AWS 2026年11月2日周报的正文片段，未独立验证控制台行为；MCP schema、鉴权、配额与 Standard/Express 的具体差异仍需查官方文档确认。