代理 AI 和平台工程：它们如何结合

快速阅读: 《新堆栈》消息，自主AI助力平台工程应对Kubernetes复杂性，显著提升效率与安全性。通过非对称扩展，减少80%事件与重复请求，将平均解决时间从8小时缩至30分钟，同时降低20%云成本。

人工智能（AI）/ AI代理
人工智能（AI）/ KubeCon CloudNativeCon欧洲2025/平台工程

自主AI能够扩展平台工程计划，以应对Kubernetes复杂性实现非对称扩展。

2025年4月1日上午11:00 由詹妮弗·里金斯撰写

在Kubernetes推出十多年后，即使容器编排器的普及率迅速提高，技能差距依然存在。这对需要K8s扩展的企业来说是一个大问题。对于塞巴斯蒂安·基斯特来说，Kubernetes已成为计算的公共交通工具。

“Kubernetes使自动、大规模地提供计算能力成为可能，并且最重要的是安全可靠——而这在我们之前的许多其他技术中无法做到，”奥迪公司容器能力中心、平台和运营团队的产品团队负责人基斯特说道，同时他也是其他企业的转型顾问。

但这并不意味着Kubernetes变得更易于使用。

“挑战尤其在于使用它的人员的技能组合，”他说，“市场很难找到真正资深的人，他们对Kubernetes有深入理解。”

最近，当他的一个团队想要增加12个新集群时，这成了一个转折点，站点可靠性工程团队回应说：“我们需要时间去寻找并雇佣两名更多的SRE。”

尽管Kubernetes周围已有诸多自动化工具，基斯特对扩展面临的这么多障碍感到惊讶。面对这些持续的复杂性、漏洞和事件，基斯特转向了人工智能。

六个月前，基斯特采用了Kubiya自主AI平台来支持实时、上下文感知并不断更新的安全响应。这种自主AI的采用不仅将他所服务的企业从风险接受转变为积极、智能的修复，还减少了团队摩擦并停止了指责游戏。

自主AI助力非对称扩展

像大多数近期公司一样，基斯特的平台工程和运营团队在面临预算缩减和僵化流程的情况下，感受到了迫切的扩展压力。

“我们无法快速招聘，大规模培养初级人才既慢又不可预测。市场几乎不可能吸引到顶尖人才，”基斯特说。

“我们必须找到另一种方式——一种不对稀缺资源依赖的非对称扩展方式。”

基斯特的目标是利用AI代理消除繁琐任务和事件修复，让高级开发人员摆脱运维任务，所有开发人员摆脱注意力分散。他着眼于自主AI平台，其中AI代理可以针对特殊任务进行训练，以消除重复性任务，并更多地关注功能、创新和项目启用。

组建一支非常具体的AI代理大军

利用AI代理的计划并不是为每个用例部署一个AI代理。

它甚至不遵循常见的平台工程实践，即覆盖影响80%工程师的用例。目前，基斯特的团队优先考虑影响所有工程团队的运行时安全、可靠性和事件修复的AI代理用例。

Kubiya有一个“原生自主”的内部开发者平台，用于可编程代理，这些代理被配置为作为软件开发团队的专用SRE AI代理士兵。Kubiya内置了200个AI代理用例，但与其他平台工程计划一样，组织可以根据特定用例构建自定义代理。

Kubiya在其公司的红帽OpenShift集群中运行，跨环境扩展并在其身份和访问管理（IAM）和基于角色的访问控制（RBAC）策略中集成，所有生产就绪的安全和合规措施均已到位。

“我们拥有完全的可见性和控制权，并信任这些代理只做它们应该做的——不多也不少，”基斯特说。

与其他仍然容易产生幻觉的AI代理平台不同，Kubiya增加了可编程性和可预测性控制，因此即使开发人员要求AI代理执行超出范围的工作，它也会将其响应限制在仅授予的工具调用和权限范围内。

这个范围非常具体，仅限于它所访问的策略或环境中。它受开放策略代理（OPA）强制执行，因此可以在本地或断网环境中工作。

“这不是软件即服务，”基斯特说。“这是你特别训练的小海军海豹突击队，每天每夜24/7都在做这项工作。”他还补充道，这极大地提升了企业的弹性。

此外，通过依靠Kubiya的内部SRE创建AI代理劳动力，一些客户的平台团队能够在不添加另一项培训——或者如他所说“庞大的团队”——的情况下扩展技术。

Kubiya拥有全栈AI平台，允许组织在其基础上构建或引入自己的AI代理以实现生产就绪的用例。它还提供企业版本，包括本地部署、大型语言模型的选择和服务协助，基斯特的团队依靠这些功能避免增加新的技能差距。

“我购买了一个AI‘平台工程师’，用于在生产环境中部署自主工作流，”他说。“然后，随着需求扩大，我们可以利用这种非对称扩展方式将我们的劳动力扩展到业务的新领域。”

“目前，由于我没有足够的人手或知识进行横向扩展，我使用他们的预建AI代理仓库来增强我的团队在运行操作中的努力，而无需再三思考。”

衡量AI代理平台的成功

工程战略的成功取决于其衡量标准。

基斯特说，在Kubiya之前，常见的漏洞和暴露（CVEs）会停留在Jira中，被视为常规任务——尽管它们绝不是这样。

“这个待办事项清单延迟了响应并暴露了风险，”他说。“有了Kubiya，我们自动化了关键任务操作——值班处理、实时修复和操作转移——释放了顶级开发人员免受上下文过载的困扰，让他们专注于创新。”

仅仅六个月内，规模化安全得到了证明：

平均解决时间（MTTR）从八小时缩短至30分钟。
每周解决时间从64小时缩短至4小时。
由于主动的AI驱动故障排除，事件减少了80%。
工程师的重复请求减少了80%。
由于主动的AI驱动故障排除，事件减少了80%。
通过识别不必要的失败部署，云基础设施成本的年度运行率降低了20%。
合规审计和安全检查现在只需一半的时间生成。

基斯特说，该项目使团队的价值主张翻了一倍，因为工具的成本仅增加了10%，全部由他小型专注的团队管理。

AI代理帮助开发人员沟通

Kubiya不仅消除了最大的技术挫折感，还消除了很多人际挫折感。

“这个小代理与你的初级开发人员交流，它可以提供见解，我们还消除了指责，”基斯特说，因为如果某些内容不符合标准，平台不会允许其部署，开发人员也清楚原因。

开发人员只需与AI代理交流，询问：“这里出了什么问题？你的建议是什么？”他说，未来他的团队将测试让修复更加自动化。

现在，“80%的故障排除已经不在话下，因为通过AI，通过那个小代理，一切都立刻清晰了，”他说。“你问它：这里出了什么问题？它就像：你有这个的根本原因吗？有，它告诉你根本原因，你就知道发生了什么。”

这些核心开发人员生产力指标中的许多都直接影响成本，因为它减少了寻找错误所花费的工程时间，并重新分配时间以更快地创建新功能。

通过Kubiya的新AI代理平台，基斯特的团队——以及其内部开发人员客户——解锁了可见性，非对称扩展构建，并用更少的人力做更多工作。或者说得更好：用他现有的团队做更多工作。

热门内容

YouTube.com/TheNewStack

技术发展迅速，不要错过任何一集。订阅我们的YouTube频道以观看所有播客、采访、演示等内容。

组