本文讨论了在AI时代，平台工程如何通过内部开发者平台（IDP）来支持AI创新，同时解决安全性、一致性和质量问题。文章强调了AI平台团队的必要性，以及AI原生开发模式的演变。
译自：Can Platform Engineering Accelerate AI Adoption?
作者：Jennifer Riggins
本文由作者代表 PlatformCon 撰写。
自上而下地强制使用开发者工具的时代已经一去不复返了。大约一半的公司都在采用自下而上的 AI 采纳方法，鼓励团队尝试新的 AI 开发工具。而对于那些没有接受这一点的组织来说，影子 AI 将很快迫使他们改变。
但是，过多的自由会带来潜在的风险和浪费。在 AI 浪潮涌现三年多后，只有 60% 的组织 拥有可接受的 AI 策略。三分之二的组织已在生产中采用了 AI 工具，但几乎相同比例（60%）的组织缺乏明确的 指标来衡量 AI 的影响。
人们把太多的注意力放在开发者一天中大约 20% 的编码时间上，尽管他们认为自己更有效率，但事实证明，AI 生成的代码正在 降低开发者的速度 以及 吞吐量和可靠性。
过去几年中 平台工程 的兴起可能是对 现代技术堆栈的复杂性 的回应。但今天，它为许多 AI 采纳障碍提供了一个令人信服的解决方案。平台工程（如 AI）在 专注于苦工和其他妨碍软件开发者向最终用户交付价值的干扰因素时 才能得到最好的服务。
毫不奇怪，今年 6 月举行的第四届 PlatformCon 大会主要关注 AI 背景下的平台工程。事实证明，内部开发者平台 (IDP) 可能会为 AI 创新奠定完美的护栏，而不会造成灾难性的后果。
Luca Galante 强调说：“虽然 AI 占据了所有头条新闻，但实际上 AI 平台将成为这一切的支柱”，他强调平台工程是构建企业级生产路径的方式。从数据科学到机器学习再到传统工程，“你需要这个底层平台来支持所有这些，并使其为企业做好准备。”
在 AI 时代，IDP 将扩展到包括 AI 流程。这将跨软件开发扩展经过验证的 AI 用例，同时消除数据科学的孤岛。
通过弥合这些差距，平台工程将解决 智能 AI 和 生成式 AI 应用程序交付的一致性、质量和安全性问题。
AI 是否需要自己的平台？
直到最近，AI 还被降级到数据科学部门。现在，是时候效仿跨组织的云采用，并将 AI 跨组织地引入， Patrick Debois 在 PlatformCon 上提出了 AI 需要一个平台团队的理由，他是《DevOps Handbook》的合著者。
他说，在当前的 AI 时代，AI 工程师 成为变革推动者，弥合了数据科学更快进入生产的路径，并与平台团队协商：
- 跨团队协作。
- 通过平台实现数据科学和应用团队的能力。
- 治理。
Debois 认为，在传统的内部开发者平台上启用 AI 将会进行重组，以纳入更多的 AI 利益相关者，从而扩展平台以包括：
- 大型语言模型 (LLM)，无论是开源、专有还是两者的混合。
- 非结构化和结构化数据，需要通过基于向量的数据库进行索引。
- RagOps 或 检索增强生成即服务 是一个新兴概念，它将第三方集成和数据源整合在一起。
- AI 代理即服务，包括内存、状态和访问控制的管理，以及 模型上下文协议 (MCP) 服务器的公开。
- AI 代理的执行沙箱。
- 跨所有模式输入和输出的访问控制和版本控制。
- 中央缓存层以控制成本。
所有这些都具有平台单一管理平台所带来的透明度和共享视图。
但这很快就变成了一个不断扩展的工具集来维护和监控，这成为了 IDP 管理所有这些的另一个理由。
他说，这个新的 AI 平台团队应该从创建一个原型设计、沙箱环境开始，允许安全地使用新的 AI 工具。
一旦开发者更熟悉 AI 实验，那么他说，“你需要选择一个与你的环境或公司现有语言相匹配的标准化框架”，并具有“其自身的缓存、测试和调试生态系统，最终会带来更多的黄金路径。”
Debois 分享了四种新兴的 AI 原生开发者 模式，用于说明 技术角色 的发展：
- 从生产者到管理者。 开发者不仅生产代码，还管理代码代理。运维，包括 DevOps 可观测性 和自动化，支持这种转变。
- 从实现到意图。 开发者表达意图，即 什么，AI 负责实现，即 如何。
- 从交付到发现。 类似于 氛围编程，降低了实验成本，并通过现有的 CI/CD 管道运行。
- 从内容到知识。 Debois 说，AI 为团队提供了一个更令人信服的理由来分享知识。正如他在一篇关于这些 AI 原生开发的四种模式 的博客文章中所写的那样，“事实上，知识可能是你公司独特的价值主张，因为构建和交付产品正日益成为一种商品。”
AI 需要哪些平台功能？
与所有产品开发一样，你必须考虑你的用户群。AI 的平台团队服务于不仅仅是开发者。
Equilibrium Energy 的基础设施和平台员工 Ina Stoyanova 在谈到这家初创公司需要或不需要 AI 提供什么时说：“我们希望允许原生 AI 工具有机地扩展和转换。”
“如果我们在六个月前设置了很多流程时就设置了黄金路径，那么我们今天就不会处于能够培养我们的工程师、科学家、量化分析师 [定量分析师] 所有人都具备的创造力的地位，而且他们对此非常兴奋。”
在一家初创公司或规模化公司中，坦率地说，在 AI 的这个早期阶段，事情变化如此之快，以至于过早地建立永久性的平台功能可能是一种浪费。
通过询问利益相关者，Equilibrium 的平台团队能够确定软件工程和数据科学团队都认为重要的事情，包括：
- 集群管理。
- 计算机资源。
- 数据资源。
- 数据工具。
- 存储。
- 查询分析。
- 可观测性。
但是，数据科学和量化团队也有其他最初不在平台工程团队考虑范围内的考虑因素。
Stoyanova 在谈到她的团队早期开始质疑的 平台工程定义 时说：“平台工程环境下的平台实际上是一组精心策划的可重用工具、工作流程、API 和文档，这些工具、工作流程、API 和文档使内部用户能够以最小的认知开销自助服务基础设施、环境和部署管道。”
平台团队（不可避免地由工程师组成）始终面临着构建他们比内部客户更关心的东西的风险。这有增加认知负荷的风险——尤其是在 Equilibrium，对于量化分析师和数据科学家而言。
Stoyanov 说：“我们开始询问我们的用户：你们想使用哪些工具？” 允许自由选择。然后，他们能够构建正确的东西，而无需投入过多资金并冒着初创公司引导和转型的能力。
B 轮初创公司 Equilibrium Energy 还发现了一个每个人（业务和技术团队）都关心的 AI 用例。平台团队尽早构建了成本跟踪和指标。
平台为 AI 数据需求做好准备
利用 AI，部分是为了利用结构化和非结构化数据。内部开发者平台 成为数据科学家和机器学习工程师可以在其上构建数据策略的支架，从而推动 AI 用例。
在 PlatformCon 上，平台工程社区 宣布了一个新的 AI 参考架构，该架构将于今年晚些时候发布，它围绕以下结构构建：
- 可观测性平面。
- 平台接口和版本控制平面。
- 集成和交付平面。
- 数据和模型管理平面。
- 安全平面。
这个新的 AI 参考架构 （在功能图像中）是一种可视化这种新的机器学习加工程平台的方式。
Galante 说：“这不仅仅是一个基础设施图。这实际上是一个结构化的心理模型，用于思考你所有不同的工作负载以及你设置的所有不同部分以及它们之间的相互作用。” “很高兴看到我们作为一个社区 [和] 作为一个市场如何发展以适应这些新需求。”
他继续说，这超越了技术和架构的变革，因为该行业正在发展其对平台工程团队本身的看法。
平台工程团队 一直包含多种角色：
- 平台工程负责人。
- 基础设施平台工程师。
- 开发者体验工程师。
- 平台产品经理。
为包括以下人员在内的利益相关者提供服务：
- 开发者。
- 高管。
- 合规和法律团队。
- 基础设施和运营团队。
- 安全团队。
鉴于 AI，平台团队设置和角色发展已扩展到包括：
- 可靠性平台工程师。
- 安全平台工程师。
- 数据和 AI 平台工程师。
- 可观测性平台工程师。
与更多利益相关者互动并为其提供服务：
- 站点可靠性工程团队。
- 架构师。
- 数据科学家和机器学习运营工程师。
Galante 说：“平台团队本身与多个、更多的利益相关者进行交互”，并增加了特定需求的粒度，“从而导致了市场上一种新兴的行为。”
因为毫无疑问，平台团队在面对 AI 时有更多的事情要做。
扩展生成式 AI 应用程序交付
现代平台团队的角色之一是识别跨领域的生成式 AI 应用程序交付用例，然后在更大范围内实施它们。但它也与选择适当的设计模式来实现它们有关。这通常是购买或构建的讨论，包括使用开放或封闭的生成式 AI 模型。
但是，Gartner 副总裁分析师兼研究员 Manjunath Bhat 在 PlatformCon 上认为，平台团队面临的最普遍的 AI 挑战是安全和治理要求。
“安全、信任和可解释性问题，而且在许多情况下，治理往往围绕成本影响。产品团队不一定是这些领域的专家，”他说，这会将架构师作为主题专家引入。“你如何扩展应用程序，以便你不会最终得到一堆无处可去的原型和实验，而是可以真正地生产化和运营这些应用程序。”
他建议，建立一个卓越的生成式 AI 中心，或者 团队拓扑 称之为支持团队，与流对齐的产品团队和平台工程专家密切合作，以提供可以扩展的专业知识。
Bhat 呼应了 Stoyanova 的观点：“我们不建议直接跳到构建共享平台。” “你从支持团队开始，因为除非我们了解不同的应用程序需求是什么，否则平台团队假设他们了解这些需求是不合适的。”
这可以包括团队拓扑所指的复杂子系统团队（如 Debois 提到的 AI 专家），以进一步减轻应用程序团队和平台团队的认知负担。
Bhat 警告说：“不要陷入这种陷阱：构建它，他们就会来。” “我们从支持团队开始，因为它有助于你发现特定的客户需求。”
以开发者速度保护代码
一种新的应用程序安全范例正在出现。一方面，AI 生成的代码意味着有比以往更多的代码需要扫描和保护。但是，智能 AI 也可以帮助进行主动和自主的修复。内部开发者平台不仅是跨组织推出新 AI 工具的好地方，而且还是制定护栏和闸门、管理基于角色的访问控制以及自动化检查以使代码更安全的好地方。
Checkmarx 高级产品经理 Sónia Antão 在 PlatformCon 上表示：“更多代码。更多贡献者。更短的时间线意味着更多的风险。这就是传统 AppSec 根本无法跟上的地方。” “发现问题是不够的。你需要就在开发者所在的地方，也就是在 IDE [集成开发者环境] 中，”就在他们编码和修复的地方。
为了实现这一点，她认为团队需要在 IDE 中集成智能 AI 和应用程序安全态势管理 (ASPM)，以实现实时代码安全。
Antão 称之为“智能左移”，其中“AppSec 能够真正清楚地了解应用程序领域中正在发生的事情的风险一致的大局。这不仅仅是在早期阶段发现漏洞。它正在以业务要求的速度更快、更有信心地解决它们。”
然后，开发者可以对错误进行分类和确定优先级，利用代理进行 AI 驱动的态势管理，为他们提供所需的信息，在他们需要的时候，全部在 IDE 中。
通过专注于这种智能 AI 加上 IDE 配对的实时代码安全，Antão 的团队已经看到漏洞减少了 25% 到 35%，响应速度提高了 69%。
开发者工作流程中的生成式 AI
生成式 AI 可以将平台工程转变为自适应、智能的系统，从而提高开发者生产力、可靠性和业务一致性，“高效平台工程”的作者 Ajay Chankramath 在开始他的 PlatformCon 2025 演讲时说道。
他说：“Gen AI 已经从被动辅助转变为今天的自主、意图感知代理。” “智能 AI 的兴起实现了自我修复管道——因此可以实现实时反馈和个性化代码建议。”
到目前为止，Chankramath 指出了对这些转变的三个主要影响因素：
- 检索增强生成 (RAG) — 允许 AI 代理将其答案基于与组织相关的实时文档。
- MCP — 能够标准化 LLM 代理与外部 API 的通信方式，从而鼓励采用。
- CI/CD 中的生成式 AI — 允许智能管道可以自我纠正、调整和建议改进。
他描述了一种演变，从平台之前的“自己寻找”到更标准的内部开发者平台。现在，是将 AI 代理嵌入到开发者工作流程中。运营已从基于票证的方法转变为半自助服务，现在转变为基于意图的自主代理。
Chankramath 说：“这不是用其他东西来取代某人以前所做的一切。” “这是关于你如何真正提升游戏水平，以便你通过平台真正带来的是更加成熟的东西，因此你作为开发者 [和] 你作为平台工程师可以真正专注于更高价值的活动。”
考虑到这些目标，他提供了五种方式来支持这种 AI 驱动的平台工程的演变：
- 将 AI 战略与开发者价值流对齐，将 AI 视为流原生组件，而不是附加组件。旨在跨编码、测试、部署和修复集成代理。
- 他强调，始终保持人工判断在环。代理设计或提出行动，而不是批准它们。
- 使 AI 代理更具协作性而不是控制性，开发者能够覆盖、重新训练和重新上下文化代理。
- 默认情况下内置 可观测性 和护栏，包括令牌跟踪日志、提示漂移检测和相关性评分。“仅仅因为你有一个 RAG 并不意味着它相关，”他强调说。然后，平台团队必须考虑如何在 可观测性 平台上记录代理操作和输出，并提供可解释的审计跟踪和版本控制。
- AI 影响衡量，Chankramath 说，必须扩展到准确性和延迟之外，包括你内部客户的净推荐值。
然后与你的利益相关者和用户分享你所有的经验教训和那些指标，以通过收益证明来提高采用率。
带有护栏的黄金路径
Coder 的 Blink 深度代码研究代理负责人 Matthew Vollmer 说：“目标不仅仅是使用代理。而是明智地使用它们。” “通过设置护栏，我们可以保持生产力和安全。”
根据他的说法，这需要：
- 提供上下文。 “将它们视为新员工，”他说。为代理提供对文档、策略和相关代码库的访问权限。如果没有上下文，代理就会成为另一个瓶颈。
- 负责任的委派。 “我们需要控制谁将任务分配给代理，并确保这些任务是适当的，”Vollmer 说，尤其是在早期采用时。首先将这些工具提供给高级开发者。
- 设置边界。 护栏（如具有严格访问控制和使用限制的隔离、临时环境）有助于维护安全性、稳定性和质量。还要采用 规范驱动的开发，因此 AI 代理不会使环境面临风险或只是增加费用来收取令牌，而是确切地按照指示执行操作。他说，以“独立的、定义明确的任务”（如中小型错误修复）为目标，找到最佳点。
所有这些目标都可以通过内部开发者平台来实现，你可以在其中像对待队友一样加入 AI 代理。
他说：“我们的一位工程师实际上将他的经验描述为与一个超级快速的初级开发者配对，他编写代码的速度是人类初级开发者的 100 倍。” “通过将这些类型的工作分配给代理，你可以保护你团队的创新时间，以便开发人员的大脑专注于高价值工作，而 AI 处理一些繁琐的任务。”
如果挫败感很高，那么 AI 和平台工程都能得到最好的服务。平台工程旨在减少开发者的认知负担。如果做得好，AI 可以帮助做到这一点，这不仅可以帮助开发者，还可以帮助你的整个软件组织。
根据 Atlassian 2025 年开发者体验状况，开发者正在利用 AI 节省的时间来专注于改进代码、开发新功能和创建文档。当平台驱动的 AI 采用（或者实际上是平台工程）做得好时，它会导致更多的时间用于价值驱动的活动。
