2026 年 7 月 28 日，MCP 协议核心转向无状态设计：客户端不再执行 initialize 握手，也不再依赖会话请求头。这个变化不只是减少了几行协议代码，它还会直接改变 MCP 服务在 AWS 上的部署方式：粘性会话、会话存储和为维持连接而设计的复杂扩缩容逻辑，都可能被删除。
下面按照 AWS Well-Architected Agentic AI Lens 常见的架构关注点，分析无状态 MCP 对运维、安全、可靠性、性能、成本和可持续性的影响。示例中的服务名、域名和容量参数是实践示例，需要根据实际 MCP 实现调整。
协议变化，带来的不只是简化
有状态 MCP 服务通常需要处理三类基础设施问题：
- 请求必须被路由到保存会话的同一个任务或实例，因此负载均衡器需要粘性会话。
- 实例重启或扩缩容后，会话可能丢失，因此需要 DynamoDB、Redis 或其他会话存储。
- 部署、故障转移和多可用区扩展都要考虑会话迁移，系统的实际可用性取决于协议状态和应用状态的组合。
无状态协议把 MCP 的协议生命周期从服务端基础设施中移开。每个请求都可以独立认证、独立路由和独立处理，ALB、ECS Service、EKS Deployment 或 Lambda 不需要知道某个客户端之前连接到了哪一个实例。
这并不意味着所有数据都必须消失。业务数据、长任务状态、审计记录和授权信息仍然可能需要持久化；变化在于，这些数据不再被当作 MCP 协议会话来维护。应用需要保存的是业务状态，而不是为了完成一次协议握手而保存连接上下文。
按 Well-Architected 关注点重新检查
卓越运营：删除会话运维面
无状态服务更容易部署和观测。运维团队可以把请求日志、延迟、错误率和工具调用结果作为主要信号，而不必额外监控会话数量、会话漂移或会话恢复失败。
部署流程也会更直接：滚动发布期间，新旧任务都可以处理请求；自动扩缩容不需要先把会话排空或迁移到新实例。建议为每个请求记录以下字段：request_id、工具名称、调用方身份、结果状态、延迟和下游 AWS API 的错误码，同时避免把完整提示词、凭证或敏感业务参数写入日志。
安全性：无状态不等于无需身份验证
删除会话头不会删除认证需求。每个请求仍然应该经过 TLS、身份验证、授权和输入校验。可以使用 API Gateway 或 ALB 作为入口，并在服务端验证 JWT、SigV4、IAM 身份或企业内部令牌。
无状态设计反而会迫使权限边界更清晰：服务不能依靠某个内存会话中的隐含身份，而必须从当前请求中得到调用者身份，并据此判断是否允许执行某个工具。工具级授权、最小权限 IAM Role、网络出口限制和敏感参数脱敏仍然是必要措施。
可靠性：让故障转移恢复正常
当请求不依赖特定实例时，单个 ECS Task 或 Pod 的故障只会影响正在执行的请求。健康实例可以继续接收后续调用，跨可用区部署也不需要同步 MCP 会话。
需要单独处理的是长时间运行的工具调用。如果工具可能执行数分钟甚至更久，不要把它伪装成一个必须长期占用 HTTP 请求的协议会话。可以将任务提交到 SQS、Step Functions 或其他任务系统，返回任务标识，再通过独立接口查询状态。这样既保留了业务状态，又维持了 MCP 服务入口的无状态特征。
性能效率：减少中间层，但关注下游限流
无状态请求可以均匀分散到多个实例，减少因粘性会话导致的负载不平衡。服务也更容易使用连接池、并发处理和水平扩展。
不过，扩展 MCP 服务并不会自动提高下游 AWS API 的吞吐量。扩容前应确认工具调用受到的限制，包括 AWS API throttling、数据库连接数、VPC 网络带宽和模型服务的并发配额。对下游调用增加超时、指数退避和有界并发，避免 MCP 服务扩容后把压力集中转移到另一层。
成本优化：移除不再需要的会话组件
如果会话存储只用于记录 MCP 初始化状态和会话路由信息，可以评估删除 Redis、DynamoDB 表、跨可用区复制和相关监控。负载均衡器也不再需要为 MCP 流量启用粘性会话。
但删除组件之前要确认它没有同时承载业务状态、幂等键、速率限制计数器或审计信息。无状态重构的目标不是把所有数据层都删掉，而是把协议会话和真正需要持久化的业务数据分开。
可持续性：用更少的基础设施维持相同能力
更简单的部署拓扑通常意味着更少的常驻组件、更少的复制数据和更低的运维开销。实际收益取决于流量模式和资源配置，不能仅凭“无状态”三个字推导出固定的成本或能耗下降。应通过任务级 CPU、内存、请求量和空闲资源指标验证收益。
一个可直接改造的部署示例
假设 MCP 服务暴露在 https://mcp.example.com，并由 ALB 转发到 ECS。下面的命令展示了无状态服务的基本请求方式：每次请求都携带自己的认证信息，不依赖上一次响应中的会话标识。
export MCP_URL="https://mcp.example.com"
export TOKEN="replace-with-a-short-lived-token"
curl --fail-with-body --silent --show-error \
-X POST "$MCP_URL/tools/list" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "X-Request-Id: $(uuidgen)" \
-d '{}'
上面的路径是说明性的，实际路径和 JSON 结构应以所使用的 MCP 2026-07-28 实现为准。关键点是服务端能够独立完成认证、路由和处理，而不是依赖客户端先发送初始化握手。
ECS Service 可以采用类似下面的思路。这个片段是可改造的 CloudFormation 风格 YAML，容量和镜像地址需要替换为实际值：
Resources:
McpService:
Type: AWS::ECS::Service
Properties:
Cluster: !Ref EcsCluster
DesiredCount: 2
LaunchType: FARGATE
TaskDefinition: !Ref McpTaskDefinition
NetworkConfiguration:
AwsvpcConfiguration:
AssignPublicIp: DISABLED
SecurityGroups:
- !Ref McpSecurityGroup
Subnets:
- subnet-aaaa1111
- subnet-bbbb2222
LoadBalancers:
- ContainerName: mcp-server
ContainerPort: 8080
TargetGroupArn: !Ref McpTargetGroup
DeploymentConfiguration:
MinimumHealthyPercent: 100
MaximumPercent: 200
这里没有配置 ALB stickiness，也没有为 MCP 协议会话配置 Redis。若服务需要记录长任务状态，可以单独设计任务表，例如以 task_id 为主键保存状态、创建时间、调用方和结果摘要，而不是保存某个实例上的连接对象。
迁移时要检查的边界
无状态迁移最容易遗漏的是代码中隐藏的实例状态。可以搜索以下模式：
rg -n "session|initialize|sticky|redis|connection|in[-_]?memory|client_id" \
src/ infra/ deploy/
检查结果至少应回答这些问题：
- 服务是否还要求客户端先完成初始化，才能接受工具调用？
- 请求是否依赖某个自定义会话头或内存中的客户端映射？
- ALB Target Group 是否仍然启用了 stickiness？
- Redis 或 DynamoDB 是否只保存协议会话，而不是业务状态？
- 实例被杀掉后，重试同一个请求是否会得到可预测结果？
- 工具调用是否具备幂等键，能否避免网络重试造成重复副作用？
- 每个请求是否都能独立完成认证和授权？
还要保留必要的防护措施：请求超时、速率限制、工具白名单、下游 API 重试上限、敏感数据脱敏以及完整审计。无状态降低了基础设施耦合，但不会替应用解决重复执行、权限扩大或下游故障传播问题。
采用建议
可以把这次协议变化当作一次架构清理机会：先确认 MCP 实现已经遵循 2026-07-28 的无状态核心，再删除粘性会话和协议专用会话存储，最后用多实例、跨可用区和故障注入测试验证请求独立性。
一个稳妥的落地顺序是：
- 在测试环境同时运行两个或更多 MCP 实例。
- 关闭粘性会话，验证连续请求可以落到不同实例。
- 重启处理过请求的实例，验证后续调用不依赖它的内存状态。
- 对重复请求、超时重试和长任务分别测试幂等性与状态恢复。
- 删除确认无业务用途的会话存储，并观察成本、延迟和错误率变化。
MCP 无状态化的核心价值，不是让系统“没有状态”，而是让协议状态不再绑架部署拓扑。把协议请求、身份验证和业务任务状态分别建模，AWS 上的 MCP 服务才真正具备独立扩展和故障转移的条件。