Bedrock 上接入新模型与把 Step Functions 当 agent 工具：发布摘要能核对到什么

这份 AWS 周报（2026 年 11 月 2 日）里有两条与开发者直接相关：OpenAI 的 GPT-6.1 Terra 在 Amazon Bedrock 上正式可用，以及 AWS Step Functions 工作流可以作为工具交给 AI agent 调用。如果只看摘要，能核对到的不是"哪个模型更强"，而是一组结构性事实：模型在家族里的位置与价格关系、编排职责怎么划分、可用范围与计费口径。真正影响上线的那些参数——模型 ID、配额、区域矩阵、真实延迟——摘要里没有，需要在自己的账号里逐项确认。以下把两条线拆开说，并标出哪些是来源事实、哪些是推断。

一、模型这条线：能核对的是"位置"，不是"榜首"#

根据该AWS News Blog 周报，GPT-6.1 Terra 是 GPT-6 家族中面向日常负载的一条产品线，已在 Bedrock 上一般可用（GA）。周报作者自己说，他关心的不是它排第几，而是它落在什么位置。

可以核对的规格与价格关系有这几条：

• 输入规模：最多支持 100 万输入 token，输入形态包含文本与图像。
• 价格：输入与输出 token 价格比 GPT-6.1 Sol 和 GPT-5.6 Terra 至少低 50%。注意比较基期是两个具体型号，不是"所有模型"。
• 调用入口：可通过 Bedrock API 访问，周报同时提到 ChatGPT Work 与 Codex 也可达。

性能方面，周报给出的三个数字需要连同出处一起读：在 OpenAI 的 Agents' Last Exam 评估中，Terra 比 GPT-5.6 Terra 高 15 个百分点，与 GPT-6 Astra 表现持平，完成任务的速度比这两者都快 3 倍以上。周报明确写了"Those are OpenAI's figures, not an independent test"，即这些是厂商自报数据。引用时保留这层限定，比数字本身更重要。

推断（非来源事实）：价格低至少 50%、速度更快、评测分数与更高一档型号持平，这组组合通常意味着厂商希望你把它放在高频、可替换的调用路径上，而不是放在需要最强推理的少数关键节点上。这是从定价与定位推出来的用法假设，需要用自己的评测集验证。

二、编排这条线：agent 决定何时跑，状态机决定怎么跑#

周报的描述是：Step Functions 通过 Amazon Bedrock AgentCore Gateway 暴露为 AI agent 可调用的工具，Gateway 使用 Model Context Protocol（MCP，模型上下文协议）连接 agent 与工具。分工被写得很清楚——agent 决定何时运行工作流、传什么输入；Step Functions 按你定义的步骤逐步执行。

周报举的例子是客服 agent 触发退款：资格校验、经理审批、入账这三步永远按这个顺序发生，因为顺序本来就不归模型即兴发挥。这句话是整条发布里最值得抄进设计文档的部分——它说明约束应当落在状态机里，而不是提示词里。

可核对的接入条件：

• 已有的 Standard 与 Express 工作流都可作为连接目标，不需要重写。
• agent 除了触发，还可以查询工作流的运行记录（run）。
• 可用区域跟随 AgentCore Gateway 的覆盖范围；计费按标准费率。

周报没有给出具体区域清单、单次调用的延迟、并发上限，也没有给出工具定义的具体 schema。这些属于待核实项，不要按摘要推断。

推断（非来源事实）：既然顺序由状态机保证，那么幂等、重试、补偿、超时这些工程问题，责任仍然落在工作流设计上，不会因为套了一层 agent 就消失。反过来，模型侧传进来的参数是否合法，仍需要在工作流入口做校验——状态机保证的是步骤顺序，不是输入可信。这一点摘要没有明说，是设计时需要自己补的。

三、把摘要变成核对表#

四、一个未执行的示意：工具描述该写什么#

下面的片段是写作时的示意结构，不是官方 schema，也没有执行过。它想说明的是：把"不要跳过审批"这类约束写进工具描述，只能起提示作用；真正的保证要落在状态机定义里。

{
  "name": "run_refund_workflow",
  "description": "启动退款工作流。资格校验、经理审批、入账的顺序由状态机保证；本工具不接受跳过审批的参数。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id":        { "type": "string" },
      "amount_minor":    { "type": "integer" },
      "reason_code":     { "type": "string", "enum": ["DAMAGED", "LATE", "OTHER"] },
      "idempotency_key": { "type": "string" }
    },
    "required": ["order_id", "amount_minor", "reason_code", "idempotency_key"]
  }
}

把 idempotency_key 设为必填，是因为 agent 可能重复调用——这是设计假设，不是摘要里的结论。示意中的枚举值、字段名都是占位，实际以实现方文档为准。

五、工具变多之后：一个可以借的细节#

周报另附了 MoEngage 的案例：约 400 个内部 REST API 操作、由 25 个团队构建、分布在 7 个区域的私有 VPC 中，通过 AgentCore Gateway 变成 agent 工具。其中值得注意的一条是量级——完整工具清单每次连接会超过 20000 token，所以他们的做法是让 agent 用任务描述去检索工具，而不是一次性接收整个目录。

这是单一客户的自述，不是通用基准，但它提示了一个可迁移的判断：当工具目录增长到几十上百个时，"把所有描述塞进上下文"会先撞上 token 预算，而不是模型能力上限。Step Functions 场景同理——如果一个账号下有大量工作流都暴露为工具，检索式发现可能比全量列举更现实。

六、摘要覆盖不到的部分#

以下几项在这份周报里没有答案，属于待核实，不要从摘要反推：模型的准确 ID 与版本号、各区域的实际上线状态、每分钟请求与 token 配额、AgentCore Gateway 的工具注册格式与鉴权方式、端到端延迟、SLA 条款。周报也没给出 Step Functions 作为工具时的错误语义——工作流执行失败后 agent 收到什么、能否重试、重试会不会重复副作用。这些要在接入前用非生产账号逐项验证。

周报同期的其他发布（KMS 支持 ML-KEM、IAM Identity Center 跨区域可信身份传播、ECS 的 GPU 共享、Lambda 的 SOCI 懒加载、EKS Auto Mode 支持 Gateway API）与本文两条主线关系较远，此处不展开。

一句话收束：这份摘要能核对的是接入位置、价格关系、职责划分和可用范围这四类结构性事实；它不能替代你自己账号里的配额、区域与延迟验证，也不能把厂商自报的评测数字变成独立结论。