谁决定顺序：Step Functions 作为 agent 工具时的分工边界

把已有工作流交给 agent 调用，最容易搞混的是职责：模型该决定什么，状态机该保证什么。按 AWS 在 2026 年 11 月 2 日周报中的说法，Step Functions 工作流现在可以通过 Amazon Bedrock AgentCore Gateway 作为 AI agent 工具使用，Gateway 用 Model Context Protocol（MCP，模型上下文协议）连接 agent 与工具；分工是“agent 决定何时运行工作流、传什么输入，Step Functions 按你定义的每一步执行”。（来源：AWS Weekly Roundup，2026-11-02）

换句话说，模型层拿到的是一个“可调用的动作”，不是一套可以自由改写的流程。这条边界划在哪里，决定了系统是可控还是不可控。本文只讨论这条边界和它带来的工程约束；具体的接入配置、请求格式与配额不在本次材料范围内，需要另行查证。

一条调用链上，谁决定什么#

把那次周报里的退款例子拆开看，会清楚很多：客服 agent 触发退款，资格校验、经理审批、授信仍然按这个顺序发生，每次都是。周报的原话是，顺序“从来不是模型可以即兴发挥的东西”。

这里其实是三层的职责：

• 模型层：判断当前对话是否该退款、该带哪个订单号、该在什么时候调用。它处理的是意图和参数。
• 网关层：把工作流描述成工具，让 agent 能发现并调用。周报提到 Gateway 通过 MCP 连接 agent 与工具，现有 Standard 和 Express 工作流都可以作为连接目标，agent 还可以查询运行记录。
• 编排层：一旦被调用，就按状态机定义执行。步骤顺序、分支、等待与人工审批写在这里，不在提示词里。

周报同时提到 Step Functions 已经编排超过 220 个 AWS 服务，这一点解释了为什么它适合放在这个位置：团队已经信任的工作流不需要重写，只需要被“描述”出来让 agent 找到。这与模型能力高低无关，是可达性的问题。

为什么顺序不该交给模型#

模型可以在每一步“选择”下一步做什么，这在开放式任务里是优点。但审批、资格校验、扣款这类步骤属于业务约束，不是可以优化的路径。如果一个退款流程允许模型判断“这次要不要跳过经理审批”，那它就不是同一个流程了。

反过来，把顺序写死在编排层，换来的是可审计和可复现：同一个输入进来，走的是同一条路径。周报里“agent 可以查询运行记录”这一点也服务于这个目的——调用发生后，能回到编排层去看它实际怎么跑的。

需要说明的是，状态机的重试、超时、错误分支等语义属于 Step Functions 本身的能力，本次材料没有展开，涉及这些配置时应以官方文档为准，不要在文章结论上外加细节。

分工的边界可以用一张表对照#

这张表不是规范，而是一个判断起点：凡是“错了会出事、且不该由模型临场决定”的东西，往右列放。

工具清单会长到放不下#

周报里另一个案例更值得开发者注意。MoEngage 通过 AgentCore Gateway 把约 400 个内部 REST API 操作变成了 agent 工具：这些接口由 25 个团队构建，部署在 7 个区域的私有 VPC 里。周报给出的一个细节是，如果把工具完整列出来，每个连接会超过 20,000 tokens，所以他们的做法是让 agent 通过描述任务来检索工具，而不是一次收到完整目录。

这个数字对 Step Functions 场景同样成立。团队的工作流数量一旦上去，全部塞进上下文既不经济，也会稀释模型的选择准确度。可检索的工具描述，比冗长的工具列表更有用。

MoEngage 还估计，走托管路径节省了大约六个月的平台工程投入。这是他们自己的估算，不是独立测算，引用时应当保留这个限定。

身份不能变成模型可填的参数#

同一篇周报在描述 MoEngage 案例时用了一个很硬的表述：租户身份“永远不能变成模型可以设置的参数”。这句话值得抄下来贴在设计文档里。模型生成的字符串不应决定这次操作属于哪个租户、代表哪个用户——这些信息应该由网关或运行时从可信上下文里取。

一个概念性的工具输入大致长这样。以下是示意结构，不是 AgentCore Gateway 的实际 schema，也未经过执行验证；字段名和嵌套方式应以官方文档为准。

{
  "name": "start_refund_workflow",
  "description": "为一笔订单发起退款审核流程。当用户明确要求退款、且订单号已确认时使用。",
  "input": {
    "order_id": "string，必填",
    "reason_code": "string，枚举值由系统提供"
  }
}

注意 input 里没有 tenant_id，也没有 user_id。这不是遗漏，而是边界：身份不进入模型可写的字段。

同一周的 AWS 公告里还有一条相关但不等价的更新：IAM Identity Center 开始支持跨区域的可信身份传播（trusted identity propagation），身份随请求传递到其他区域的服务，可以按用户和组成员授权、审计谁访问了什么。方向上与上面的原则一致，但本次材料没有说明它与 AgentCore Gateway 上的工具调用如何组合，这部分待核实，不宜直接写成推荐架构。

把工作流设计成工具时的检查点#

1. 输入收敛：只暴露模型确实需要决定的字段，其余由流程内部解析或从上下文注入。
2. 描述面向任务，而非面向实现：如果工具要靠检索被发现，描述应当写“什么时候该用它”，而不是罗列内部步骤。
3. 输出裁剪：返回给模型的结果应当是判断所需的最小集合，完整执行详情留在运行记录里供人查。
4. 幂等考虑：模型可能重复调用同一个工具，工作流侧需要能识别重复请求。这一点属于设计建议，具体实现方式需结合各自系统确定。
5. 粒度：一个工具对应一个业务动作，不要把一个可以独立完成的动作拆成多个工具让模型自己串。

什么情况下不该这么做#

• 没有顺序约束的简单操作：一两次无状态调用，直接暴露一个函数或接口通常更直接。引入状态机是为了顺序和审批，不是为了好看。
• 每一步都需要模型推理：如果流程的每个环节都要模型临场判断，那编排层只是个外壳，收益有限。
• 对交互延迟敏感的场景：工作流启动与执行有时间开销，本次材料没有给出任何延迟数字，待核实后再决定是否适合放在同步对话路径上。

本次材料未覆盖、需要核实的内容#

• 把 Step Functions 工作流接成工具的具体配置步骤与所需权限；
• MCP 工具的请求/响应 schema，以及工作流输入输出的大小限制；
• AgentCore Gateway 的区域清单（周报只说“所有 AgentCore Gateway 可用区域”）与计费细则（周报只说“标准费率”）；
• 工具检索是平台内置能力还是需要自行实现——MoEngage 的做法被描述为一种选择，但材料没有说明实现方式；
• Express 与 Standard 工作流在作为工具时的行为差异。

把边界记住就够了：模型决定“要不要做、带什么参数”，编排层决定“按什么顺序做、做完留什么记录”。周报里的两个案例——Step Functions 被交给 agent，以及 MoEngage 把 400 个接口描述成工具——本质上是同一件事：不重写已有系统，只把已有能力描述清楚，让 agent 找到并调用。至于接入细节，等官方文档确认之后再动手，比照着一篇周报猜参数要稳妥。