把 Step Functions 当 agent 工具：模型决定何时调用，工作流决定怎么执行

把工作流交给 agent 调用，最容易搞混的一件事是：到底谁负责“顺序”。据 AWS News Blog 2026 年 11 月 2 日的 Weekly Roundup 转述，Step Functions 工作流现在可以通过 Amazon Bedrock AgentCore Gateway 作为 AI agent 工具暴露，走的是 MCP（Model Context Protocol，模型上下文协议）。该文给出的分工很干脆：agent 决定何时运行工作流、传什么输入；Step Functions 按你定义的方式执行每一步。（来源：AWS News Blog，以下涉及产品行为的描述均转述自该文，未做独立核验。）

换句话说，模型拿到的是一个“可调用的能力”，而不是一段“需要它自己记住的流程”。这篇文章就围绕这条分界线，讲清楚判断标准、工具该怎么描述、入参该怎么收，以及材料没有覆盖、必须自己去核实的部分。

一、分界线的实质：模型拥有时机，工作流拥有顺序#

该文举的例子是客服 agent 触发退款：资格检查、经理审批、入账，这三步每次都按这个顺序发生，因为“顺序本来就不该由模型即兴发挥”。这句话可以作为整条边界的原则。

据此可以把职责拆成两组：

• 放在模型侧：理解用户意图、判断是否需要调用某个工作流、从对话中抽取参数、读取返回结果后决定是否再调一次或直接回复用户。
• 放在工作流侧：步骤的先后关系、分支条件、需要等待人工审批的环节、失败后的处理路径、运行状态本身。

这样拆的好处不是架构好看，而是可验证性：顺序写在状态机里，可以逐次复现；顺序写在提示词里，每次执行都是一次抽样。

二、判断标准：哪些步骤该留在工作流里#

不用记抽象原则，用下面这张表逐条对照即可。表中“倾向”是本文基于该文分工描述给出的建议，不是 AWS 的官方规定。

一个常见的错误是把第一类步骤写成提示词里的编号列表：“请先检查资格，再请经理审批，最后入账”。这在演示里能跑通，但它把确定性交给了概率性组件。工作流工具化之后，这段文字应该被替换成一次工具调用。

三、工具描述：给任务，不要给目录#

该文转述的 MoEngage 案例里有一个值得记住的细节：把约 400 个内部 REST API 操作（由 25 个团队构建、分布在 7 个区域的私有 VPC 中）接成 agent 工具时，如果做全量工具列表，每个连接会超过 20,000 tokens。他们的做法是让 agent 通过描述任务来搜索工具，而不是一次性接收整个目录。该文称这条托管路径估计节省了约六个月平台工程投入——这是 MoEngage 方面的估算，属于转述，不能当作通用收益。

对写工具描述的人来说，结论是：描述要写“什么时候该用我”，而不是把工作流里每一步都复述一遍。步骤细节留在工作流定义里，模型不需要为了调用它而理解它。

反例与正例的差别大致是这样（结构示意，字段名与真实网关 schema 待核实）：

{
  "name": "start_refund_workflow",
  "description": "为指定订单发起退款。用户明确要求退款时使用。不负责判断资格：资格检查、审批与入账由工作流内部按固定顺序完成。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string" },
      "reason":   { "type": "string" }
    },
    "required": ["order_id"]
  }
}

上面这段是手工写的示意结构，未在任何网关上执行，只用于说明“描述里写边界、不写内部步骤”这个取向。真实工具注册时的字段、鉴权方式与命名限制，材料未提供，需按 AgentCore Gateway 的文档核实。

四、入参契约：模型能填什么，不能填什么#

MoEngage 案例里还有一句更关键的话：租户身份“永远不能成为模型可以设置的参数”。这条约束值得上升到通用规则——凡是模型不该自行决定的值，都不要放进工具入参。

典型的三类值：

1. 身份与租户：由网关或运行时从调用上下文注入，而不是让模型从对话里“推断”。
2. 幂等键：如果由模型生成，重试时很可能换一个值，幂等就失效了。应由工作流侧或调用侧固定。
3. 审批结论：审批是工作流中的一步，不是模型可以代填的字段。

反过来，模型适合填的是那些“从用户话语里来”的值：订单号、退款原因、时间范围。判断方法很简单——这个值如果填错，是用户说错了，还是系统放错了位置？后者就不该出现在入参里。

五、一个最小骨架（未执行）#

下面是一个退款工作流的结构示意，使用 Amazon States Language 的形态，未部署、未执行，仅用于展示“顺序写在状态机里”长什么样。其中 REGION、ACCOUNT_ID 为占位符。

{
  "Comment": "退款流程骨架，仅示意结构，未执行",
  "StartAt": "CheckEligibility",
  "States": {
    "CheckEligibility": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:check-refund-eligibility",
      "Next": "ManagerApproval"
    },
    "ManagerApproval": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:request-approval",
      "Next": "IssueCredit"
    },
    "IssueCredit": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:issue-credit",
      "End": true
    }
  }
}

这段骨架故意省略了错误处理、重试与超时配置——不是因为它们不重要，而是因为材料没有说明工具调用失败时错误如何回传给模型、超时上限是多少。这些恰恰是上线前必须自己确认的部分。

六、材料没有回答、需要自己核实的问题#

该文是一篇周报，覆盖的是“能力存在”与“分工原则”，不是接入手册。以下几点在本次材料中没有依据，写“待核实”，不要按猜测推进：

• 调用语义：agent 触发工作流是同步等待结果，还是启动后凭运行 ID 查询？材料只提到 agent 可以查询运行记录，未说明默认行为。
• 失败回传：工作流执行失败时，返回给模型的是结构化错误还是自然语言描述？这直接决定模型能否自我纠正。
• 超时与配额：单次工具调用的超时上限、并发限制、是否按状态转换计费。材料只说“标准费率”，未给具体数字。
• 鉴权模型：网关如何把调用方身份传给工作流，与 IAM 权限如何对应。
• 幂等：重复调用同一工具是否会重复执行副作用，需要在哪一层加约束。
• 区域：材料称在 AgentCore Gateway 可用的所有区域提供，具体区域列表需查官方文档。

七、结论#

把 Step Functions 当 agent 工具用，本质是一次职责切割，而不是一次模型能力升级。该文开篇的那句判断值得引用：真正留下的印象“与模型有多强无关，而与可达性有关”——已有工作流不用重写就能被调用，价值在于复用，不在于让模型更聪明。

落地时按三步走：先把“顺序与审批”从提示词里搬回状态机；再把工具描述收敛成“何时用我”，而不是“我内部怎么做”；最后把身份、幂等键这类模型不该决定的值挡在入参之外。剩下的延迟、错误语义与配额，材料没有给出答案，需要拿真实文档逐条核实之后再写客户端。