Agentic AI Patterns on AWS
title: “AWS 上的 Agentic AI 模式” weight: 400
在开始构建之前，让我们花一些时间了解在 AWS 上部署 AI agents 的不同方式。每种方法在控制力、运维开销和上线时间之间都存在不同的权衡。本模块将介绍三种常见策略，并帮助我们决定何时使用每一种。
策略 1：在 Kubernetes 上自行管理
在 EKS 上运行开源模型，对每一层都拥有完全控制权：模型服务（vLLM）、agent 框架（Strands）、vector DB（Milvus）、可观测性（Langfuse）以及工具协议（MCP、A2A）。
| 组件 | 服务 |
|---|---|
| 模型推理 | EKS 上的 vLLM（Inferentia/GPU） |
| Agent 编排 | Strands Agents SDK |
| 内存 | Milvus（EKS 上的 vector DB） |
| 工具 | EKS 上的 MCP server |
| 可观测性 | EKS 上的 Langfuse |
| 多 agent | A2A 协议 |
优点
- 对模型选择、微调和优化拥有完全控制权
- 可使用任何开源或自定义模型（无门禁限制）
- Agent 逻辑透明。我们可以调试每一步。
- 可在多云和本地环境间移植
- 通过预留容量（Inferentia、Spot）在规模化时具有成本效益
缺点
- 更高的运维开销（打补丁、扩缩容、监控）
- 必须管理基础设施可靠性（节点故障、存储、网络）
- 上线时间更长
- 团队需要 Kubernetes 和 ML 基础设施方面的专业知识
最适合： 具有特定模型需求、严格的数据驻留需求，或已有 Kubernetes 专业知识、希望获得最大灵活性的团队。
策略 2：集成式（自托管 agents + 托管 agent 能力）
将 agent 框架和编排逻辑保留在我们自己的代码中（EKS 上的 Strands SDK），但将自托管后端替换为 AWS 托管服务：使用 Bedrock 进行推理，使用 AgentCore 提供内存和工具。
| 组件 | 服务 |
|---|---|
| 模型推理 | Amazon Bedrock（通过 LiteLLM 代理） |
| Agent 编排 | Strands Agents SDK（在 EKS 上） |
| 内存 | AgentCore Memory |
| 工具 | AgentCore Browser、Code Interpreter |
| 可观测性 | EKS 上的 Langfuse |
| 多 agent | A2A 协议 |
优点
- 与自行管理相同的 agent 代码；只需更改配置
- 无需模型托管或 GPU/Inferentia 管理
- 托管的内存和工具减少运维负担
- LiteLLM 代理使得在 Bedrock 和 vLLM 之间切换只是一个配置更改
- 对 agent 逻辑拥有完全可见性（我们拥有编排）
缺点
- 仍需要 EKS 来运行 agent pods 和可观测性
- Bedrock 的模型选择比开源更有限
- AgentCore 服务依赖于区域
- 混合运维模型（K8s + 托管服务）
最适合： 希望拥有 agent 逻辑和编排，但将模型服务和数据存储等基础设施密集型组件卸载给托管服务的团队。
策略 3：完全托管
端到端使用 AWS 托管服务：使用 Bedrock 进行模型推理，使用 Bedrock Agents 进行编排，以及托管的工具集成。
| 组件 | 服务 |
|---|---|
| 模型推理 | Amazon Bedrock |
| Agent 编排 | Bedrock Agents |
| 内存 | AgentCore Memory |
| 工具 | AgentCore Gateway、Lambda |
| 可观测性 | CloudWatch、Bedrock logging |
优点
- 无需管理基础设施，是上线最快的路径
- 自动扩缩容、打补丁和高可用性
- 与 AWS 安全（IAM、VPC、KMS）原生集成
- 按使用付费定价，无闲置成本
缺点
- 仅限于 Bedrock 中可用的模型
- 对推理参数和优化的控制较少
- Agent 编排逻辑不透明（更难调试复杂流程）
最适合： 希望快速交付、不需要自定义模型，并且更倾向于运维简单而非细粒度控制的团队。
决策框架
| 问题 | 自行管理 | 集成式 | 完全托管 |
|---|---|---|---|
| 需要特定的开源模型？ | 是 | 否 | 否 |
| 团队具有 Kubernetes 专业知识？ | 必需 | 必需 | 不需要 |
| 数据必须留在我们的 VPC 中？ | 是 | 部分 | 部分 |
| 上线时间最重要？ | 慢 | 中等 | 最佳 |
| 希望云可移植的架构？ | 是 | 部分 | 否 |
| 复杂的多 agent 工作流？ | 完全控制 | 完全控制 | 有限 |
本 workshop 涵盖的内容
本 workshop 为我们提供自行管理和集成式方法的实操经验：
| 路线 | 我们将构建什么 |
|---|---|
| 在 Kubernetes 上自行管理 | Inferentia 上的 vLLM → Strands agent → Langfuse → Milvus → MCP → A2A |
| 集成式架构 | 通过 LiteLLM 的 Bedrock → Strands agent → Langfuse → AgentCore Memory → AgentCore Tools → A2A |
在两条路线中，agent 代码几乎保持相同，只有基础设施配置发生变化。这展示了集成式方法：相同的 SDK、相同的协议、不同的后端。