从“扩展模型”到“扩展可达范围”：AWS 这周把已有工作流接成了 agent 工具

这周 AWS 发布里，对开发者影响更直接的不是哪个模型上了 Bedrock，而是 agent 能接的系统变多了。Step Functions 现在可以作为工具交给 agent；同一周，一家叫 MoEngage 的公司用同样的方式把约 400 个内部 API 操作暴露给 agent。两件事都没有重写系统，只是把已有能力描述出来，让 agent 自己找。变化发生在“可达范围”，不在“模型能力”。（来源：AWS News Blog，2026 年 11 月 2 日周报）

“扩展模型”和“扩展可达范围”是两笔不同的账#

扩展模型，是换一个更强的模型，能力上限抬高，但每接一个新系统仍要写适配层、改业务代码、补一套错误处理。扩展可达范围，是把已经跑在生产里的工作流和接口描述成工具，模型负责选择，系统负责执行。

区分方法很朴素：如果新增一项能力需要动业务代码，那是前者；如果只需要补描述、配权限、定边界，那是后者。周报作者自己的判断也是这个方向——让他记住的那几个 agentic 发布“与模型有多强无关，而是关于 reach（可达范围）”。

这个转向的工程含义是：过去两年 agent 项目的瓶颈常在“接不进去”，现在瓶颈前移到“接进去之后怎么约束”。

Step Functions 当工具：不确定的留给模型，确定的留给工作流#

材料给出的分工是清楚的：agent 决定什么时候运行工作流、传什么输入；Step Functions 按你定义的步骤逐步执行。举的例子是退款——资格检查、经理审批、额度入账，每次都按这个顺序发生，因为顺序本来就不该由模型即兴决定。

可用性方面：已有的 Standard 和 Express 工作流都可以作为 connector target；在 AgentCore Gateway 可用的所有区域提供，按标准费率计费。这是本稿写作时材料给出的范围。

需要留白的部分：工具 schema 长什么样、工作流失败时错误怎么回传给 agent、幂等键放在哪一层、并发与配额如何计算，这期周报都没有展开。这些应当以 Step Functions 与 AgentCore Gateway 的官方文档为准，本文不作推测。

400 个 API 的教训：工具目录本身就是上下文成本#

MoEngage 的场景值得单独看：约 400 个内部 REST API 操作，由 25 个团队开发，分布在 7 个区域的私有 VPC 里，租户身份绝不能变成模型可以设置的参数。他们估计走托管路径省下了约六个月的平台工程工作——这是客户自己的估计，不是审计数字。

更有迁移价值的是那个细节：如果把工具全量列出来，每个连接会超过 20,000 tokens。所以他们没有把目录一次性塞给模型，而是让 agent 通过描述任务来检索工具。

由此可以得出一个推断（不是材料结论）：工具数量增长时，“全量下发”会先撞上上下文预算，再影响模型的选择准确度。检索式发现把成本从“每次调用都携带全目录”摊到“每次先检索一次”。

• 工具描述要面向任务写，而不是把 OpenAPI 摘要原样贴进去；
• 先按业务域分组，再决定单次返回多少个工具；
• 检索命中率、单任务检索次数应作为观察项，而不是只看调用成功率。

三个不该让模型决定的参数#

1. 租户身份。材料明确写了租户身份“不能成为模型可以设置的参数”。身份应从请求上下文注入，而不是工具入参。
2. 权限范围。同周 IAM Identity Center 支持跨区域可信身份传播：用户身份随请求带到另一区域的 AWS 服务，按用户和组成员授权，并可审计谁访问了什么。此前要么用无法区分个人的宽泛 IAM 角色，要么把所有服务挤进一个区域。该功能不额外收费，在 IAM Identity Center 可用的区域提供。
3. 执行顺序。见上一节：顺序属于状态机，不属于提示词。

共同点是：模型可以决定“做什么”，不能决定“以谁的身份做、按什么顺序做”。

同周其他发布：成本与基础设施侧的同类变化#

• GPT-6.1 Terra 在 Amazon Bedrock 正式可用。OpenAI 自报其在 Agents' Last Exam 评估中比 GPT-5.6 Terra 高 15 个百分点，与 GPT-6 Astra 持平，完成任务速度是两者的三倍以上；输入输出 token 价格至少比 GPT-6.1 Sol 和 GPT-5.6 Terra 低 50%；最多支持 100 万输入 token，接受文本与图像。这些是 OpenAI 的数字，不是独立测试。
• Lambda Managed Instances 支持 SOCI 懒加载。AWS 称容器启动时间最多减少 70%。SageMaker AI 训练与处理作业给出的基准是：懒加载稳定在 3 至 11 秒，与镜像大小关系不大；13.2 GB 镜像的中位数是 3 分 42 秒，约合 8 到 46 倍。基准由 AWS 提供，区间取决于镜像构成。
• ECS 支持 NVIDIA MPS GPU 共享。多个任务可并发跑在一张 GPU 上，声明每个容器需要的显存，可选限制算力份额，适合小模型推理与多模型服务。
• KMS 支持 ML-KEM 后量子密钥封装。覆盖 NIST FIPS 203 的三组参数，通过 Encapsulate / Decapsulate 建立和恢复共享密钥；除中东（UAE、Bahrain）与中国区域外可用。Aurora PostgreSQL 18 及以上同周加入后量子 TLS 密钥交换。
• EKS Auto Mode 支持 Kubernetes Gateway API。用 Gateway 和 HTTPRoute 声明流量入口，无需另装控制器，现有 Ingress 可共存，属于增量而非迁移。

同一期里还有两篇客户案例：Nubank 用 DevOps Agent 把一次灾备测试周期从约 4.3 小时压到约 40 分钟，2026 年流程覆盖翻四倍到 160 以上；另一篇讲 5.8 PB 日志在 90 天后访问率低于 0.1%，转 Glacier Instant Retrieval 后账单降约 70%。两者都是各自工作负载的报告值，不能直接外推。

如果要落地，建议的顺序#

1. 盘点已有流程：哪些已经有确定顺序、审批与审计要求。这些最适合当工具，而不是让 agent 重新实现一遍。
2. 一个工具对应一个业务动作，不要把底层 CRUD 直接暴露出去。
3. 把身份与租户从工具参数里拿掉，改为由网关和请求上下文注入。
4. 控制目录规模：先按域分组，再考虑按任务检索；把单次返回的工具数量当成可调参数。
5. 为失败路径定契约：错误怎么回传、能否重试、幂等键在哪一层。材料未涉及，这一项必须自己定义并写进文档。
6. 观察三类指标：调用成功率、单任务工具检索次数、人工复核比例。

这套做法不解决什么#

它不提升模型推理能力。工具描述含糊时，检索式发现一样会选错，只是错得更晚。它也不替代权限设计，网关只是执行点。此外，本文只基于一篇周报：各功能的区域、配额、定价与工具 schema 细节，均应以官方文档为准，本文标注为“待核实”的部分不作推断。

判断一次发布是否值得跟进，可以问一句：它扩展的是模型能力，还是模型能够到的系统？后者通常更快转成工程收益，但也更快暴露权限设计与上下文预算的问题。