MCP 2026-07-28 是该协议发布以来规模最大的一次修订：协议转向无状态运行，引入受治理的扩展体系，并强化授权机制。Amazon Bedrock AgentCore Gateway 支持通过一次 UpdateGateway 调用切换到新版本，但真正的升级工作不应止于修改版本号，还需要检查客户端状态、扩展依赖和授权边界。
无状态改变了哪些工程假设
无状态意味着服务端不能再默认依赖先前请求留下的会话上下文。对网关后面的工具和服务来说，每次调用都应携带完成操作所需的信息，例如身份、租户、请求参数以及可验证的上下文引用。
这会直接影响三类实现：
- 把用户身份或工作流阶段只保存在进程内存中的工具。
- 假设同一连接上的后续请求天然属于同一会话的服务。
- 依赖隐式初始化顺序，例如必须先调用
initialize，之后的工具调用才拥有业务上下文。
迁移时可以把业务状态放入外部存储，并通过明确的标识符引用。不要把所有历史数据塞进每次请求；更稳妥的做法是传递短期、不可猜测且受权限约束的状态引用。
下面是一个简化的无状态工具请求示例。字段仅用于说明迁移方式，实际结构应以所用 MCP SDK 和工具 schema 为准：
{
"tool": "get_order_status",
"arguments": {
"order_id": "ord-12345",
"tenant_id": "tenant-a"
},
"context_ref": "ctx_7f31c0",
"request_id": "req-20260728-001"
}
服务收到请求后，应根据调用者身份重新验证其是否可以访问 tenant-a 和对应订单，而不是因为客户端持有 context_ref 就直接放行。
扩展有了治理边界
新规范加入了受治理的扩展体系。它解决的核心问题不是“能不能扩展”，而是扩展如何被命名、发现、协商和演进，避免客户端与服务端依赖未经声明的私有行为。
升级前应盘点现有 MCP 集成中的非标准字段、自定义请求头和特殊工具约定。可以为每个扩展记录以下信息：
- 扩展名称、版本和所有者。
- 客户端与服务端分别支持哪些能力。
- 不支持扩展时的降级行为。
- 扩展数据是否进入日志、审计记录或授权判断。
网关启用新版本并不代表下游组件会自动兼容。若某个客户端仍依赖旧版状态语义或未治理的私有扩展，应先做兼容测试，再逐批迁移流量。
用一次 UpdateGateway 切换版本
来源信息确认 AgentCore Gateway 可以通过一次 UpdateGateway 调用启用新版本，但没有给出完整参数结构。下面可以这样实践：先让本机 AWS CLI 根据已安装的服务模型生成参数骨架，再填写网关标识和 MCP 版本。这样可以避免照搬可能已经变化的字段名。
先确认当前 CLI 是否暴露该操作：
aws bedrock-agentcore-control update-gateway help
aws bedrock-agentcore-control update-gateway \
--generate-cli-skeleton input > update-gateway.json
打开生成的 update-gateway.json，保留服务模型要求的必填字段，并在 MCP 协议配置中指定 2026-07-28。下面的文件是假设性示例，protocolConfiguration 内的准确字段应以生成的骨架为准：
{
"gatewayIdentifier": "gw-REPLACE_ME",
"protocolConfiguration": {
"mcp": {
"supportedVersions": [
"2026-07-28"
]
}
}
}
在执行写操作前，可让 CLI 先做客户端参数校验：
aws bedrock-agentcore-control update-gateway \
--cli-input-json file://update-gateway.json \
--generate-cli-skeleton output
确认字段与当前区域、CLI 版本和 Gateway 配置匹配后，发出一次更新调用：
aws bedrock-agentcore-control update-gateway \
--cli-input-json file://update-gateway.json
如果本机 CLI 的服务模型尚未包含相关字段，应先升级 AWS CLI 或所用 SDK。不要通过手工拼接未知参数绕过模型校验。
授权强化后要重新验证什么
授权机制加固后，最容易暴露的是“认证成功就拥有全部工具权限”的旧设计。网关、MCP 服务和实际业务 API 应形成连续的授权链，而不是只在入口检查一次令牌。
建议至少覆盖这些测试：
- 有效身份只能看到并调用被授权的工具。
- 同一工具对不同租户、资源和参数执行细粒度检查。
- 过期、错误受众或权限不足的凭证被明确拒绝。
- 状态引用不能被另一用户或租户重放。
- 扩展能力不能绕过标准工具的授权策略。
- 拒绝事件带有请求标识并进入审计日志，但不泄露令牌和敏感参数。
上线策略
版本切换只需要一次控制面调用，兼容性验证却应分阶段完成。先在测试 Gateway 上回放真实请求样本，随后让少量客户端接入新版本，并同时观察工具错误率、授权拒绝率、延迟和下游 API 异常。
正式切换前，应确认客户端不再依赖服务端隐式状态、自定义扩展已经登记并具备降级路径、授权测试覆盖跨租户和重放场景，同时准备明确的回退配置。这样才能把一次简单的 UpdateGateway 调用，变成一次可控的协议升级。