InfoQ 趋势报告旨在为架构师和技术领导者梳理当前应优先关注的技术主题。除了这份报告以及最新的 DevOps 与云计算趋势图，我们还准备了一期配套播客，几位 InfoQ 编辑和业界朋友围绕这些趋势展开了讨论。
年度趋势报告的重要组成部分是趋势图表，它展示了哪些趋势和主题已经进入创新者类别，哪些已被提升至早期采用者和早期多数类别。这些类别依据 Geoffrey Moore 的《跨越鸿沟》（Crossing the Chasm）划分。在 InfoQ，我们主要关注尚未跨越鸿沟的类别。以下是今年的趋势图：
过去一年里，InfoQ 团队在讨论趋势报告的基础上，见证了不少重要创新和进展（参见下方 2025 年趋势图）。
本文重点解读上面这张技术采用趋势图，并详细介绍自去年报告以来新增或升级的技术。与此同时，我们也会探讨那些在趋势图中被重点推广的技术和方向。
以下是自去年报告发布以来发生的一些主要变化。
创新者
在采用趋势图中，第一类就是创新者，它涵盖了目前只由最具前瞻性团队在开发的新兴方法。今年新入榜的项目说明，AI 基础设施已经迅速成为架构设计中的首要关注点。
企业级 AI 平台与 AI 网关
今年最明显的转变之一，是从独立的 AI 助手转向集中管理的 AI 平台，尤其是在企业内部。企业不再让每个团队各自搭建模型，而是开始构建内部 AI 平台，里面配备集中式网关、经过审批的模型目录以及预配置的团队工作区。这种模式直接借鉴了成熟的 API 管理理念，并把它应用到了模型、工具和智能体上。
Steef-Jan Wiggers：这是一种“毂辐式（hub-spoke）”模型，其中有集中式 AI 网关，基本上就是你所说的 API 管理，只不过是针对 AI 的。我认为 Apigee 具备这一功能，微软也有自己的 API 管理方案，但你也可以将其定位为 AI 网关。在其背后，有一个集中式的模型目录，其中包含允许使用的模型。随后，这些模型将流向所谓的“辐条”，也就是在平台上进行开发的团队。
这些平台仍处于早期阶段。正如 Wiggers 所指出的，毂辐式模型在实践中会如何展开，目前仍是未知数。但方向是明确的：通过模型路由控制成本，通过内部托管保障数据主权，并建立受管控的模型目录，避免上百个团队各自为政地做模型决策。
面向 AI 和 Token 经济的 FinOps
云端 FinOps 已经是一门成熟的学科，但 AI 支出开辟了一个新领域，现有工具还不能充分覆盖它。Token 消耗已经成为一项主要运营开支。与会专家坦率地指出，如何把这部分支出与价值挂钩，仍是一个悬而未决的问题。Matt Saunders 直接点出了这一矛盾。
Matt Saunders：FinOps 工具可以告诉你在 Opus、Fable、Sonnet 等平台上分别花了 X、Y、Z 美元购买 Token。但据我所知，没有一款工具能够真正把这些支出与实际成果联系起来。
Renato Losio 指出，AI 成本往往只是其他因素的替代指标，这让它的优化难度远高于存储类别或数据传输这类确定性成本项目。此外，还有更深层的不确定性：当前模型定价究竟是用补贴换取用户锁定，还是真实反映了长期成本。Shweta Vohra 则从 FinOps 基金会的视角解释了问题的本质。
Shweta Vohra：当前智能体带来的混乱程度，甚至超过了我们此前经历的微服务时代。在 AI 和云优化方面，我们已经遭遇了巨大的资源浪费这块“巨石”。但现在，我们面临着智能体形式的小型机遇与挑战——智能体如此之多。与那些大模型、巨额投资和 MLOps 相比，我们现在面对的只是些“小石子”。我们需要把它们收集起来并理清头绪。正因如此，FinOps 基金会也分出了 Tokenomics 基金会。与此同时，Agentic AI 基金会也在 Linux 基金会旗下应运而生。
主权云战略
数字主权已经从政策讨论转向架构层面的探索，尤其是在欧洲。各组织正在评估，究竟要采取哪些实际措施，才能把数据——以及越来越多的模型——留在区域边界之内。从业者的坦率回答是：由于企业基础设施很大一部分构建在美国平台和 SaaS 之上，要实现完全主权控制非常困难。Steef-Jan Wiggers 指出，在他供职的公司里，几乎所有应用、系统和超大规模云服务商都来自美国，甚至包括核心策略系统。要实现完全主权，几乎意味着要对所有系统进行重建和重新设计。欧洲供应商可以提供 IaaS 和存储服务，但在平台和 SaaS 层——例如 Salesforce 这类 CRM 系统——还没有明显的主权替代方案。
Renato Losio 对此持怀疑态度。他认为，当前欧洲出现的这波替代方案在技术深度上还无法与超大规模云服务商相提并论。
Renato Losio：在欧洲，大多数提供替代方案的服务商，其实主要是在搞营销。他们提供的服务水平远不足以成为真正的替代方案。这让我想起 S3 推出的早期阶段，当时人人都声称拥有 S3 后端，但实际上不过是一台运行着 S3 API 的单一服务器罢了。
不过，他也承认，推动“主权区域”的举措至少让各团队意识到一个此前许多人没考虑过的挑战。Mark Silvester 则从他的受监管欧洲客户群中读到了一个具体的反向信号。
Mark Silvester：我们的所有客户都在欧洲，而且他们坚决要求将所有数据都保留在欧洲境内。实际上，大约一半的客户正在逐步迁回本地部署。这绝对是我观察到的一种趋势。
早期采用者
在早期采用者类别中，我们重点介绍了用于云工程的 AI 智能体，以及更广泛的 AI 智能体基础设施竞赛。去年，我们把用于云工程的 AI 智能体归入创新者类别；今年，尽管治理方面仍有摩擦，但其应用已经明显推进，因此我们把它晋升到了早期采用者类别。
用于云工程的 AI 智能体
超大规模云服务商已经把智能体当成重点产品，而不是研究中的新鲜事物。各大云平台相继推出智能体注册中心、DevOps 智能体和沙箱执行环境。Steef-Jan Wiggers 将此形容为一场基础设施军备竞赛。
Steef-Jan Wiggers：我认为，智能体基础设施的“军备竞赛”基本上已经打响。我们可以看到，许多超大规模云服务商已经在相关产品上投入了大量资源。例如，亚马逊云科技推出了智能体注册中心和 DevOps 智能体。我认为微软也有 DevOps 智能体。此外，谷歌推出了 GKE 智能体沙箱，Cloudflare 则推出了动态工作负载服务。其中一些超大规模云服务商正在将 AI 基础设施真正融入其产品之中。
然而，企业级应用的推广仍受治理和合规性制约。Mark Silvester 和 Wiggers 都在受监管环境中工作，他们描述了同一个问题：各团队在缺乏共同基础的情况下争相推进 AI 应用，导致重复工作，并面临《数据开放与责任法案》（DORA）所要求的安全与合规管控。在这些组织里，一个反复出现且值得深思的问题是：某个问题是否真的需要 AI，还是通过输入管理等现有能力就能解决。
智能体基础设施与治理自动化
除了单个智能体，一种更偏微服务风格的模式正在出现：分别用于编码、测试和持续集成（CI）的专用智能体彼此协调，而不是被单一全能模型取代。Matt Saunders 把这一年概括为两类团队的分水岭：一类押注规模越来越大的前沿模型，另一类则构建面向特定目标的小型智能体。哪种理念会胜出，或者它们是否会走向融合，是明年最值得关注的问题之一。
治理工具也在逐步跟上。Saunders 重点提到 MCP 集中式身份验证功能的推出，这解决了该协议早期最突出的问题之一：智能体会继承其创建者的权限。
Matt Saunders：我最近刚在 InfoQ 上发表了一篇文章，介绍了 MCP 现在已经支持集中式身份验证。现在有一个用于集中式身份验证的插件。我曾经认为，MCP 在引入时会完全无视组织内部现有的权限以及身份与访问管理（IAM）机制。这不可避免地导致了其采用率未能达到本应有的水平。
早期多数
我们正在把平台工程和模型上下文协议纳入早期多数类别。这两者都已经相当成熟，讨论焦点也从“是否采用”转向“在大规模场景下如何运行才能取得最好效果”。
平台工程
平台工程已经悄然成为基础性工作。与会专家将其描述为：非 AI 领域的工作正处于一种有成效的维持状态——稳定、被充分理解，且不再是令人兴奋的前沿；而自主式 AI 则成为平台团队新的实验方向。平台团队的角色正从“建设者”转向“赋能者”：通过标准化 AI 能力避免各团队重复造轮子，同时减少因核心服务不完善而出现的“影子平台”。
Mark Silvester：在我们所合作的客户中，这可能已经成为平台工程团队的主要关注点：帮助客户成为“AI 原生”的赋能者，确保平台不会总成为瓶颈。如果平台不够完善，那么各团队就会想用完全不同的方式自己动手实现。
Matt Saunders 把该领域非 AI 相关的工作描述为一种有成效的维持状态：团队不再争论如何使用 Terraform 构建基础设施最好，而是聚焦于数据主权、模型托管以及前沿模型的访问控制，努力在平台层面创造价值，避免各团队各自为政。Shweta Vohra 认为，虽然更广泛的社区仍在争论平台工程的本质，但在实践中，这一领域已经进入早期多数阶段。在 KubeCon 大会上，她发现约 70% 的与会者认为平台工程只是 DevOps 改了个名。这说明，虽然相关工具已趋于整合，但人们对这一领域的认知仍在不断成熟。她还进一步厘清了这两个角色之间的区别。
Shweta Vohra：如今，平台工程师和开发人员之间必须有所区分。开发人员需要专注于更高的抽象层，而平台工程师则可以继续扎根于引擎、基础设施、Kubernetes 等底层技术。现在是迈向平台工程 2.0 的时候了。基于智能体的开发门户（Agentic developer portals）是一种新兴事物，目前尚处于早期阶段——就像我们之前看到的 IDP 一样——但这次它会更快地成熟。我建议将 AI 原生平台作为下一个重要的发展方向。这一领域未来会有更多的发展空间。
模型上下文协议（MCP）
MCP 正迅速成为 AI 工具的默认集成协议。该协议由 Anthropic 于 2024 年底推出，目的是规范模型与外部工具及数据的连接方式。
今年的讨论重点已经不再是 MCP 是否重要，而是如何安全地运行它：应该暴露多少工具接口、怎样实施最小权限原则，以及如何把它纳入现有的身份与访问控制体系。Shweta Vohra 指出，限制 MCP 暴露的工具范围已经成为标准的合规检查点，而集中式身份验证的出现，标志着该协议已经实质性地迈入企业级应用阶段。
Vohra 还提到成立于 2025 年底的 Agentic AI 基金会，认为这是一项令人鼓舞的标准化工作。标准化是企业所需的安全与合规成熟度的前提，尽管相关工作仍在初期阶段，但方向是积极的。
后期多数
后期多数类别涵盖那些已被广泛采用并视为核心架构的技术。今年，有一个主题在这一类别中再次成为焦点：可靠性。
云计算的可靠性与弹性
尽管人工智能备受关注，但对 Renato Losio 来说，最令人意外的趋势却与 AI 无关，而是过去一年里各大云服务在可靠性方面的糟糕表现——从长时间区域性中断，到美国一个核心区域宕机并波及互联网大部分区域的广泛服务中断。
Renato Losio：真正让我感到惊讶的是，在过去的一年中，主要云服务提供商的可靠性竟然如此之差。如果一年前有人告诉我，亚马逊云科技的一个区域会停机六个月，我根本无法想象。此外，去年 10 月美国弗吉尼亚区域也停机了数小时，对半个互联网都产生了相当大的影响。
这里面蕴含的教训虽是老生常谈，但仍值得再次强调：多区域设计、运维就绪性和弹性能力，绝不是采用最新服务之后才需要附加的可选功能。随着新的 AI 工作负载给算力带来压力，可靠性的基本要素反而变得更加重要。
面向云的 FinOps 和可观测性
传统的云 FinOps、针对存储类型与数据传输的优化、计算资源优化以及 可观测性，仍然是被广泛采用且成熟的实践。正如 Losio 所言，云资源浪费中的大问题已基本解决，该领域剩下的只是渐进式改进。正如创新者一节所述，前沿已经转向 AI 支出。用于确定性云成本管理的工具已经相当成熟，各供应商正把应用范围扩展到可持续性和绿色计算报表领域，多位小组讨论成员都认为这些确实很有用。
注意事项：哪些东西可能被高估了
每年我们都会询问专家小组，听众应该对哪些趋势保持警惕。今年的共识主要集中在区分实质性内容与营销噱头。
- 智能体的盲目叠加：Wiggers 提醒大家，要警惕那些在产品中生硬添加智能体却没有带来任何附加值的情况，这让人联想到此前 DevOps 表面功夫的时代。在医疗保险等受监管领域，完全自主决策根本不被允许，必须有人类或医生参与其中。我们需要思考的是：智能体究竟在哪里真正创造了价值，在哪里又没有。
- 企业中的全自主代理：Mark Silvester 和 Shweta Vohra 都呼吁让人类始终参与其中。Vohra 提醒各团队，要关注智能体协同网络和控制框架等更深层问题，而不是被花哨的门户和表面功能吸引。
- 托管式 AI 服务的过度泛滥：Renato Losio 预测，一些频繁更名和重新包装的云 AI 服务将在未来十二个月内难以为继，而开发者会越来越关注实际成果，而非助手背后运行的是哪种模型。
- 关于工程师消亡的预测：Matt Saunders 认为，AI 将取代初级或高级工程师的论调正在消退，那些关于世界将彻底改变的更激进多年期预测也同样如此。
小结
如果说去年的报告聚焦于整合，那么今年的报告则关注压力下的执行。人工智能已经从实验阶段迈入落地实施阶段，这一转变正在同时重塑云战略、平台工程和 FinOps。各组织正在构建受监管的 AI 平台，努力应对现有工具还无法有效处理的 Token 经济问题，并把主权视为具体的架构约束而非抽象关切。
与此同时，一系列备受瞩目的服务中断事件让可靠性再次回到讨论中心。这提醒我们：即便技术前沿不断推进，多区域设计、运营就绪性以及清晰的人工治理等基本要素，其重要性也不会因此减弱。该小组最强烈的共识建议是：抵制 AI 过度炒作，持续追问自动化究竟在何处真正创造了价值。
未来十二个月，最具竞争优势的团队将是那些能够把 AI 赋能的执行能力与平台治理、客观评估结合起来的团队，把热情转化为持久价值，而不是不断累积成本和复杂性。正如 Daniel Bryant 在配套播客总结中所说：炫目的技术固然引人注目，但基本功依然是核心。
原文链接： https://www.infoq.com/articles/cloud-devops-trends-2026/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
发表于 昨天 05:12
|
查看: 13|
回复: 0
