AWS EKS服务演变，AI工作负载重塑Kubernetes。MCP服务器助智能体排障，2026年智能体AI有望普产。
译自：2026 Will Be the Year of Agentic Workloads in Production on Amazon EKS
作者：Frederic Lardinois
当 AWS 于 2018 年推出 Elastic Kubernetes Service 时，目标受众是那些希望获得托管控制平面并自行处理所有其他事务的早期采用者。在过去的八年里，这种情况发生了很大的变化。
“我们开始进入晚期多数，甚至是落后者，”AWS EKS 和 ECR 产品管理高级经理 Mike Stefaniak 说。“人们开始使用 Kubernetes。他们没有庞大的平台团队。他们不想自己管理每一件事。”
视频
在本期《The New Stack Makers》节目中，我与 Stefaniak 坐下来讨论了 AI 工作负载如何重塑 Kubernetes，为什么 AWS 为 EKS 开源了模型上下文协议 (MCP) 服务器，以及生产环境中智能体 AI 的实际情况。
工具名称很重要
今年早些时候，AWS Labs 发布了一个用于 EKS 的 MCP 服务器作为实验室项目。
“我发现一些有趣的早期反馈是，你放入 MCP 服务器的实际工具名称非常重要，你不需要仅仅复制 EKS 的每一个 API 调用，因为 LLM [大型语言模型] 可以自己解决这个问题，”Stefaniak 解释道。“故障排除、运行手册、如何部署 CloudFormation 堆栈以实际运行完整的应用程序——这些比仅仅创建集群、部署 Pod 更能引起我们的兴趣，并将它们放入我们的 MCP 服务器中。我们已经大大改进了我们最初发布的工具名称，现在我们正在努力对其进行管理，使其更适合企业使用。”
该团队还推出了一个托管知识库，其中包含多年的支持案例和内部日志，现在可以将其提供给可能正在尝试解决类似问题的智能体。“我们已经看到了节点和集群可能出现故障的各种方式。如果我们可以将所有这些打包到智能体和我们的 MCP 服务器中，客户就可以解决问题，而无需提交支持工单，”Stefaniak 说。
仍处于实验阶段，但正在变为现实
尽管“智能体 AI”继续主导许多会议——尤其是主题演讲——对话，但 Stefaniak 认为，至少对于他的客户而言，这项技术仍处于非常早期的阶段。这些客户仍然非常专注于在 EKS 上进行常规的 LLM 推理。
“我会说智能体 AI 更像是前沿，”他指出。“今天大多数用户仍然有人在循环中。例如，故障排除案例——让智能体找出问题，给出建议。如果你让智能体尝试自行修复，那比大多数人走得更远。”
他表示，对于面向客户的应用程序尤其如此。“内部平台更愿意采用尖端技术，因为它是内部的。对于面向客户的应用程序，则需要更加谨慎。”
接下来是什么？
但 Stefaniak 确实相信这种情况很快会改变。“2026 年将是智能体工作负载投入生产部署的一年，而 2025 年更多是传统的 LLM 推理和智能体工作负载的实验阶段，”他说。
对于希望试验智能体工作负载的团队，他推荐使用 AWS 的开源 Strands SDK，用于使用 Python 编写智能体，从外部模型端点开始。
他最喜欢的智能体入门“Hello world”练习是什么？构建一个 Kubernetes 故障排除智能体，然后使一个 Pod 崩溃，看看智能体如何诊断问题。
“当它只是去查看日志和指标，然后说，‘看起来这个镜像不存在。有个拼写错误。去修复它。’这真的很有趣。”
至于他自己的 AI 使用，Stefaniak 表示他也在越来越多地使用这些智能体工具。
“如果你在六个月前问我，我会说不多，”他解释道。“在过去的六个月里，我真诚地觉得我使用其中一些工具工作效率更高了。我在内部使用的一些非常有用的用例：BI。我过去必须去研究 SQL 表和 SQL 查询，才能了解我们客户的情况并理解他们如何使用我们的服务来做决策。我们现在有一个 BI 智能体，可以理解我们的表，我可以向它提出我多年来一直想知道答案的问题，老实说，它会根据已有的数据为我找出答案。这在内部是一个真实、具体的用例，我看到它加快了我们的产品开发过程。”
