InfoQ 于 2006 年 6 月 8 日 正式上线，带着一个清晰的编辑理念：对于软件开发类内容平台来说，最有价值的事情莫过于识别技术采用曲线上处于创新者和早期采用者阶段的前沿思路，邀请一线从业者撰写相关内容，并在早期大众阶段到来之前将这些材料呈现在高级工程师面前。平台始终聚焦技术落地实践与真实行业经验，拒绝噱头炒作。
6 月 8 日，InfoQ 迎来了二十周年纪念。创新者、早期采用者、早期大众、晚期大众与落后者这套理论框架至今仍展示在网站的关于页面上，因为它仍然是 InfoQ 编辑思路的核心。这套框架持续指引我们的内容报道与趋势报告，帮助我们将各类新兴技术和实践对应到技术采用曲线当中。
InfoQ 的故事不只体现在敏捷、云计算、人工智能等重大技术浪潮里。许多后来成为主流的技术在成形之初就已在我们的网站上出现：2007 年，Doug Cutting 在网站上讨论 MapReduce 和 Hadoop，Salvatore Sanfilippo（Antirez）也分享了他对 Redis 的愿景。
Java 值得一提，它从平台创立之初便是 InfoQ 的常客。2006 年网站上线时，Sun Microsystems 还是一家独立企业。在随后的二十年里，InfoQ 持续追踪 Java 的发展，见证其从企业框架、云原生架构、容器、微服务、GraalVM 一路演进至虚拟线程。相关内容也从 InfoQ 早期的 Java 报道，延伸到如今热门的社区活动，例如十亿行挑战。二十年过去了，Java 开发者仍在寻找将 Java 平台推向极致的方法。
以下内容并非完整的发展史，而是选择性回顾 InfoQ 早期预判的各类趋势，梳理这些趋势在 2026 年所处的发展阶段，并探讨技术采用曲线在未来五至十年的演变方向。
敏捷（2006）：从备受争议的做法到整个行业通用的专业术语
InfoQ 上线之初，敏捷便是五大初始内容板块之一，由 Deborah Hartmann 和 Scott Ambler 负责。2006 年的技术采用框架认为，敏捷领域不断涌现出各类流程与工具创新，更新速度快到从业者难以跟上。平台的初衷便是帮助读者紧跟发展节奏。
现状： 晚期大众阶段，可能是落后者。
敏捷的普及程度已达到极致，以至于这个词已经失去了大部分特定含义。敏捷与 DevOps 实践早已深度融入行业标准，如同我们日常呼吸的空气一般自然。而作为下一阶段演进方向的平台工程正在崛起，它将产品与设计思维融入开发者工具之中。
如今值得探讨的焦点已转移到之后会发生什么：工程师的产品思维、平台即产品，以及架构评审流程。这些理念虽不再冠以敏捷之名，却都是最初敏捷理念的延伸与延续。
面向服务架构（2006）：理念正确，实施过早
2006 年，SOA 相关内容曾提到，整个行业“充斥着零散的博客与小型会议，业内从业者始终没有专属的交流阵地”。作为当年热门概念的 SOA，最初形态存续不足十年便不复存在，但它背后的核心问题却留存至今，依旧具有现实意义：当服务边界持续变化时，该如何设计系统？又该如何在不影响效率的前提下完成集成治理？
现状： SOA 品牌现在已是落后者。
SOA 相关问题至今仍是探讨微服务、服务网格以及当下智能体编排的核心。到 2026 年，SOA 早已鲜少登上头条，但它所涉及的架构难题依旧至关重要，如今智能体编排也已成为主流软件架构的组成部分。
云计算（2008–2012）：从“它靠谱吗”到“还有什么不用云”
早在云计算饱受质疑、业界普遍认为企业核心业务负载不会迁出数据中心之时，InfoQ 便已开始深入报道这一领域。早期内容聚焦架构模式，而非厂商宣传，这也让相关内容经得起时间的考验。
InfoQ 在云计算前景仍不确定时便关注到了一线实践者：2007 年，亚马逊首席技术官 Werner Vogels 在 QCon 上介绍了 Amazon.com 技术平台，开场便提出一个在当时绝非客套的问题：“你们知道 S3 是什么吗？”而 Amazon S3 的发布也仅比 InfoQ 上线早几个月。
一年后，InfoQ 编辑便开始报道 Windows Azure 和 Google App Engine 的相关内容，Abel Avram 首次对 Amazon EC2、Google App Engine 和 Azure 进行了对比，并指出在发展初期，这几款产品“并非真正形成竞争关系”。
2012 年，亚马逊云科技及其他云服务商开始从基础基础设施逐步转向托管平台和高阶服务，Netflix 等互联网企业也成为云原生架构的有力例证。同年，Netflix 开源了 Chaos Monkey，彻底颠覆了传统理念：不要假定故障鲜有发生，而要认定故障无法避免，并以此为依据进行系统设计。
现状： 晚期大众。行业前沿转向了云计算衍生出的各类新课题——FinOps、多区域弹性、成本感知架构、数据主权，以及推理的碳足迹。InfoQ 的绿色 IT 报道是云计算发展脉络的自然延续。三年前，Adrian Cockcroft 就强调，跟踪能耗和建立碳足迹标准以监督主流服务商的相关承诺十分重要，这一实践对于未来的人工智能工作负载而言愈发关键。
DevOps（2010–2014）：颠覆组织架构的文化变革
DevOps 的报道难度高于云计算，因为 CI/CD 流水线、基础设施即代码这类技术内容仅仅是其全貌的一半。另一半是工程团队内部的文化变革，而 InfoQ 的文化与方法论板块也正是围绕这一方向逐步成型。
DevOps 运动在 2009 年随着首届 DevOps Days 大会的召开正式成型，该大会由 Patrick Debois 创办。在 DevOps 的发展初期，Puppet 创始人 Luke Kanies 解释了软件如何打破组织壁垒，Chef 作者 Adam Jacob 讨论了 DevOps 的演进和未来趋势。DevOps 成熟度曲线在 2014 年就已经是业界热议话题。
现状： 从早期大众阶段逐渐进入晚期大众阶段。
平台工程是当下的主流落地形态，包含了平台即产品、标准路径和内部开发者平台等理念。最近因人工智能再度引发热议的“自动化悖论”成为一个衍生的新议题：每一层自动化都消除了苦差事，但同时也催生了新的依赖、抽象和故障模式。
容器和 Kubernetes（2014–2018）：一次罕见的全面胜利
Docker 以及后续的 Kubernetes 在技术采纳曲线上的普及速度几乎超过了 InfoQ 报道过的所有技术。我们的采编思路很明确：邀请在生产环境中运行容器的实践者分享实际遇到的各类问题。
2014 年，InfoQ 发表了“使用 Kubernetes 扩展 Docker”，这是第一篇解释 Kubernetes 概念、集群设置、Pod、服务和部署的文章。2019 年的电子杂志“Kubernetes：过去、现在和未来”为未来几年的发展定下了基调，而最新一期的 InfoQ 云和 DevOps 趋势报告则指出“Kubernetes 现在已成为云原生部署领域成熟的事实标准底层平台”。
现状： Kubernetes 处于早期大众阶段，对云原生厂商来说可以说是进入了晚期大众阶段。
行业前沿方向逐步转向服务网格、eBPF、多集群与边缘领域，如今又被不符合 Kubernetes 设计理念的 AI 工作负载模式再度重塑。2023 年，InfoQ 就已探讨过这场悄然发生的平台变革以及 eBPF 对云原生平台带来的改变。
微服务（2014–2020）：从充满争议到业界默认架构，再到务实理性的探讨
微服务这一趋势最能体现 InfoQ “重质量、不追首发”的采编理念。当微服务开始充斥各大会议议题时，InfoQ 已积累了多年包含故障模式在内的实践案例研究。本站也是业内最早开展客观探讨、直面微服务落地难题的平台之一。《微服务：如今仍值得选择吗？》一文探讨了折中方案的可行性，以及团队该如何应对随之而来的运维复杂度。
现状： 晚期大众阶段，业界也终于出现了理性反思的声音。
2021 年，与 Martin Fowler 一起定义微服务架构风格的 James Lewis 谈到，微服务的含义和实践已褪去最初的热潮。当前的文章主要探讨合理的服务拆分、在有意义的地方使用模块化单体，以及智能体系统如何促使人们重新审视服务边界。
机器学习（2014–2020）：最具远见的一次预判
网站的关于页面提到，2014 年，InfoQ ”开始加大数据科学和机器学习的报道力度。“ 这是一个在 Transformer 论文发表之前、在 ChatGPT 发布之前、在实践者受众还很小的时候做出的一项前瞻性的采编布局。我们预判机器学习终将发展为一门工程学科，而非单纯的研究领域。
工程师，而非研究人员，需要一个交流实践经验的平台。正所谓”从实验室走向工厂“：构建生产机器学习基础设施，从早期开始就一直考验着从业者，大家也一直在探索数据集成、大规模机器学习与实验落地的可行方案。
当时，另一个明确的主题已经出现：数据科学正在成为一门混合学科，既需要数学和统计学的坚实基础，也需要在现代大数据平台上构建和运营系统所需的工程技能。
现状： 早期大众阶段。
在生产环境中的落地机器学习已不再罕见，行业前沿也明确转向人工智能工程这一独立学科。
AI 工程和智能体系统（2023 至今）：当前创新者/早期采用者的活跃地带
这是目前技术采用曲线上热度最高的，也是 InfoQ 读者停留时长最久的版块。网站首页呈现出清晰的行业切面：AI 网关与集中式推理、基于 WebRTC 架构的大规模语音智能体、由工程提供支持的多智能体系统、供私有智能体接入的 MCP 隧道，还有成为核心风险要素的 AI 治理——这也恰恰印证了A²I²背后的现实矛盾：自动化被人工智能放大的经典悖论。
在这场更大范围的变革中，有几个不同的子线索脱颖而出。
上下文工程和规范驱动开发。Baruch Sadogursky 近期提出的观点——只要有足够严格的上下文，规范就可以成为真相的来源，而代码则沦为可丢弃的中间语言——这正是 InfoQ 应当持续关注的一类主张。它可能是下一个架构范式，也可能是 2026 年版的 MDA（模型驱动架构）。但无论如何，技术从业者群体都需要一个平台来探讨辨析这一方向。
AI 原生开发模式。 Patrick Debois 提出的四个模式——从生产者到管理者、意图高于实现、从交付到发现、智能体知识管理——精准概括了高阶工程工作的实际变化。这些是 2026 年处于创新者阶段的理念。它们能否在 2028 年进入早期大众阶段，仍有待观察。
AI 系统的可靠性。 生产环境中的 AI 正在引发一类新问题，也让业界开始重新探讨：当系统本身被设计为非确定性形态时，可靠性究竟该如何定义。
未来十年技术采用曲线的展望
有几项预测，待到 2036 年便可验证其对错。
智能体系统将会复刻微服务的轨迹。
先是走过一段过度应用的阶段，随后人们开始理性探讨其真正的适用场景，最终形成回望时一目了然的成熟范式。InfoQ 的定位是成为理性探讨的平台，而非助推盲目应用。
规范驱动和上下文驱动开发要么带来颠覆性变革，要么终将沦为过往注脚，目前我们尚无法定论。各类早期迹象已十分明显，这类技术正处在创新探索阶段，并未被业界冷落。
AI 系统的可靠性工程将成为一门独立学科，正如 SRE 之于分布式系统。如今投身该领域的从业者，正在摸索前行的路径。
随着推理算力带来的经济与监管压力不断加大，绿色 IT 和计算可持续性将从创新者阶段进入早期采用者阶段。
目前我们尚未报道的部分内容日后或将被证实是最为关键的。
这是最重要的预判，也是最难坚守的编辑准则。InfoQ 之所以能精准预判如此多的趋势，并非编辑们拥有远见卓识，而是因为团队始终贴近从业者，关注实际遇到的难题，而非追逐热门噱头。
二十年的历程
技术采用曲线的形态与 2006 年别无二致，只是榜上的技术名称早已彻底更迭。始终不变的是我们的编辑准则：联结一线从业者，鼓励他们如实分享内容，完成同行评审后将内容推给需要规划技术选型的资深工程师。
致每月阅读 InfoQ 的 55 万名高级开发者，以及每一位帮助将一个理念从创新者阶段移动到早期采用者阶段再到行业其他地方的编辑和贡献者：发展曲线将继续延伸。感谢大家相伴走过的二十年。
查看英文原文：https://www.infoq.com/articles/adoption-curve-twenty/
