AWS 工作流可直接接入 MCP 智能体

让 AI 判断「该不该启动退款」，让代码规定「退款必须经过哪些检查」，这是作者给 Agent 划出的边界。原文介绍的 AWS 新连接器，把 Step Functions 工作流直接接到 AgentCore Gateway，省去了自行编写 MCP 包装层的工作。

它值得读的地方，不只是少写一个 Lambda，而是把工具调用、流程执行、权限和重复请求放到了一起。接起来容易，能否限制 Agent 的操作范围、避免重复退款，才决定这套方案能不能进入业务系统。

连接器省掉的，到底是哪部分代码

据原文，AWS 在 10 月 29 日公布了这项集成：Standard 和 Express 工作流都能通过 Amazon Bedrock AgentCore Gateway 暴露为 MCP 工具。

MCP（Model Context Protocol）负责让 AI 应用发现和调用工具。以前要让 Agent 启动 Step Functions，通常得写一个 Lambda，在里面调用 StartExecution，或者自己维护 MCP server。协议处理、参数描述、鉴权和监控，都要有人负责。

现在可以使用 ID 为 states 的内置连接器。开发者声明开放哪些 API、固定哪些参数，Gateway 负责 MCP 协议、工具 schema，并使用自己的 IAM role 调用 Step Functions。

省掉的是工作流外面的接入代码，业务规则仍然需要自己实现。

作者用虚构的自行车租赁业务 Radstation 演示：客服 Agent 接到押金咨询后启动退款流程，工作流按「检查资格 → 判断 → 退款」执行。车没还、归还超过 30 天、金额不是整数或不在 1 到 50_000 分之间，都不能退款；出现损坏则返回 NEEDS_HUMAN_REVIEW。

这里还有一个边界：示例把需要人工审核的情况送进失败状态，并没有展示完整的人工审批流程。

原文以 aws-cdk-lib@2.275.0、TypeScript 和 L1 构造 CfnGatewayTarget 配置连接器，要求 Node.js 22 或更新版本，示例区域为 eu-central-1。业务 Lambda 使用 NODEJS_22_X、ARM_64、256 MB 内存和 10 秒超时；Standard 工作流超时为 5 分钟，资格检查对两类 Lambda 服务错误配置了 maxAttempts: 3。

不过，输入材料中的 CDK 代码在 credentialProviderConfigurations 处被截断了，最关键的 target 配置并不完整。原文虽然称它是完整示例，但仅凭这份内容无法直接复现部署。

同步拿结果，还是保留执行记录

作者更倾向于给多数 Agent 场景使用 Standard，理由是后续查询方便。

Express 提供 StartSyncExecution，一次工具调用就能启动并取得结果，适合短流程，例如价格计算。但原文指出，Express 执行不能通过 ListExecutions、DescribeExecution、GetExecutionHistory 查询。客服稍后要问退款进度，或者早晨检查昨晚失败的任务，这些能力就很重要。

这不是谁更先进，而是业务是否需要持续追踪执行状态。

作者的 Node.js 脚本使用 SigV4，为服务名 bedrock-agentcore 签名，通过 JSON-RPC 2.0 发送 tools/list 和 tools/call。Gateway 返回的业务结果放在 MCP 文本内容中，脚本再将其解析为 JSON。

下面这段启动调用说明了两个容易踩坑的参数：

  const started = await callTool('refund___StartExecution', {
    input: JSON.stringify(input),
    name: `refund-${rentalId}`,
  });

要看清 input: JSON.stringify(input)：input 要传 JSON 字符串，直接传对象会出错。工具名由 target 名称、三个下划线和操作名组成，但仍应先用 tools/list 确认，避免直接写死。

示例随后用 refund___DescribeExecution 查询状态，携带 includedData: 'ALL_DATA'，最多轮询 20 次，每次等待 1500 毫秒。轮询会产生 Gateway 调用费用。流程很长时，先告诉用户任务已受理、完成后再通知，比让 Agent 一直查询更合适。

固定工作流、限制权限、防重，缺一项都不够

连接器映射了 10 个 Step Functions API 操作，但每个 target 可以只开放其中一部分。示例只提供 StartExecution、ListExecutions、DescribeExecution 和 GetExecutionHistory。

对于支持固定参数的操作，作者通过 parameterValues 绑定 stateMachineArn。Gateway 随后会从工具 schema 中移除该字段，Agent 无法自行换一个工作流。StartExecution 的可选 name 则通过 parameterOverrides 开放。

但 DescribeExecution、GetExecutionHistory、StopExecution 接收的是 execution ARN，不能依靠这种方式绑定工作流。限制它们访问范围的是 Gateway 的 IAM role：示例把执行权限收紧到 execution:radstation-deposit-refund:*，而非 states:* 配合 *。

工具参数限制 Agent 能提交什么，IAM 限制这些调用最终能访问什么。

作者没有开放 StopExecution，因为客服没有中止退款的必要。更敏感的是 SendTaskSuccess：它能恢复等待 .waitForTaskToken 的工作流，而原文指出该操作不支持资源级 IAM 限制，需要授权到 *。如果发起申请的 Agent 又拿到了审批回传工具和 task token，就可能自行放行。

重复调用则要另做处理。Standard 的 StartExecution 在执行仍运行、name 和 input 都相同时，会返回首次启动的响应；执行已结束，或输入不同，则返回 ExecutionAlreadyExists。原文称，名称要到执行关闭 90 天后才能重新使用。

因此，作者要求名称固定为 refund-<rentalId>。代价是首次因未还车而拒绝，也会占住名称，后续需要尝试计数或人工处理。示例脚本每次重新计算 returnedAt，同名重跑时输入也可能变化，不能期待总能拿到原响应。

支付侧还有第二道防重，作者用租赁 ID 生成固定退款引用：

// src/issue-refund.ts
import { createHash } from 'node:crypto';

interface IssueRefundInput {
  rentalId: string;
  amountCents: number;
}

export const handler = async (event: IssueRefundInput) => {
  // 演示：这里应调用支付服务。
  // 引用只取决于租赁记录，因此第二次调用会产生相同引用。
  const refundRef = 'RF-' + createHash('sha256').update(event.rentalId).digest('hex').slice(0, 12);
  console.log(JSON.stringify({ rentalId: event.rentalId, amountCents: event.amountCents, refundRef }));
  return { refundRef, amountCents: event.amountCents, status: 'REFUNDED' };
};

关键是生成 refundRef 的那一行。但固定引用本身不会阻止付款，真实支付服务还必须识别并拒绝重复请求。这里的退款只是模拟。

我的判断

我认同作者对职责的划分：模型理解诉求，工作流执行可测试的规则。与自建 Lambda 包装层或 MCP server 相比，内置连接器减少了一层维护工作；已经使用 Step Functions 的团队，更容易获得收益。

但作者没有给接入耗时、成本或故障率的对照数据。「更省维护」有清楚的结构依据，省多少仍是经验判断。

示例也不能直接当成退款系统。returnedAt、damageReported、depositCents 都来自调用输入，代码校验了格式和范围，却没有展示如何从可信业务系统核实这些事实。如果由 Agent 根据聊天内容填写，工作流再确定，也可能按错误资料退款。生产实现应由服务端按 rentalId 查询真实记录。

权限还有类似前提：限制到一个工作流，解决的是跨工作流访问问题，不会自动解决同一工作流内不同客户的数据隔离。

原文列出了测试、类型检查、合成和部署命令，也给出预期输出，但输入材料没有测试文件或实际运行记录，不能把它视为生产效果验证。末尾关于 TestState API 的内容同样被截断，无法进一步判断作者如何验证状态转换。

能拿来做什么

• 已经使用 Step Functions 的团队，可以先接入一个边界明确的工作流，只开放业务确实需要的操作，并分别限制 state machine ARN 和 execution ARN。
• 用 Node.js 接 Agent 工具前，先手工跑通 tools/list、tools/call、SigV4 签名和状态查询，把协议问题与模型选择工具的问题分开定位。
• 处理退款等有副作用的操作时，把固定执行名作为一层防重，并在支付或业务存储侧落实幂等；同时设计首次失败后的重试入口。
• 前端和全栈团队可以把长流程做成「已受理、处理中、已完成、需人工处理」等明确状态，限制轮询次数，并让服务端查询可信业务数据。