“InfoQ 年度技术盘点与展望”是我们全年最重要的内容选题之一，重点关注 2024 年各技术领域的最新进展和动态。今年的盘点我们分为了两个部分。

第一个部分是解读 IT 行业热点事件。2024 年，IT 行业经历了诸多波澜。从大模型的热潮到开源社区的乱象，到传统软件行业的困境，这些事件都折射出 IT 行业发展所面临的机遇与挑战。InfoQ 携手行业内的资深专家，针对今年的热点话题进行了深度解读，为大家呈现了一个多角度、有启发性的行业洞察。

第二部分是分领域总结这一年的关键技术进展，我们从大模型、RAG、Agent、前端、架构、大数据、云计算、平台工程、数据库、操作系统和芯片各个领域盘点了行业关键进展，帮助大家准确把握当年的技术发展趋势。

在此感谢淘天集团 1688 终端架构负责人曹立成、英特尔高级工程师付俊伟付俊伟、蔚来汽车人工智能研发负责人 & 高级总监高杰博士及某视觉生成技术专家、阿里巴巴技术总监郭瑞杰、腾讯腾讯云副总裁、OpenCloudOS 社区技术监督委员会（TOC）主席郭振宇、字节跳动业务架构团队负责人洪增林、PingCAP 联合创始人兼 CTO 黄东旭、数势科技 AI 负责人李飞、智源研究院数据研究组负责人刘广、小米大模型负责人栾剑、阿里云服务框架 &治理团队负责人肖京、RisingWave 创始人 &CEO 吴英骏、AutoMQ 联合创始人 & 首席执行官王小瑞、京东技术专家王译堃、中关村科金总裁喻友平、PECommunity 平台工程社区发起人杨振涛、云飞励天芯片总监张福林、Kong Inc.高级工程师张晋涛、统信软件高级副总裁张磊、vivo 互联网产品平台架构团队负责人张硕、澜码科技 CEO 周健（嘉宾排名不分先后，按姓名首写字母排序）等带来的这场思想盛宴，你们在各自领域的洞察和思考让我们对未来的技术发展充满期待。

2024 IT 行业热点话题深度解读

问题一：中国软件行业的挑战与未来

InfoQ：今年有关“中国软件行业几乎全军覆没”的讨论火遍全网。对此，您如何评价中国软件行业目前的整体状况？中国软件行业目前还面临哪些其他的困境和挑战？您认为导致这一现状的主要原因是什么？您对中国软件企业的发展有哪些建议？

澜码科技 CEO 周健：硅谷自 2005、2006 年起就开始讨论 SaaS（软件即服务），经过十几年的发展，SaaS 在硅谷取得了显著的成果。大约在 2014、2015 年，中国也开始逐步投资 SaaS 领域，但基本上是借鉴美国的商业模式。然而，从 2018、2019 年开始，尤其是 2021 年到达了 SaaS 投资顶峰，但如今许多相关企业都遇到了投资退出问题。普遍的共识是中国的 SaaS 模式基本上已被证明不可行。即便是上市的 SaaS 公司，如北森和有赞，也面临着各种问题。我认为，这不仅仅是行业或人的问题，而是整个国家经济形态所处的阶段导致的困难。中国的 IT 预算大多来自国有企业，这是主要的资金来源。

与美国相比，中国在数字化进程中同时处理了多个阶段的问题。美国经历了从信息化到互联网化、大数据再到人工智能的逐步发展，而中国则是将这些步骤合并在一起，特别是在消费互联网领域，中国的发展速度甚至超越了美国。这种加速发展使得国有企业对 IT 的需求与它们的管理标准化程度不匹配，导致软件企业难以制作出标准化产品，并在不同客户间复制。

云计算虽然发展迅速，但在中国往往变成了私有云，这与安全和行业特性有关。私有化部署使得软件企业难以管理软件版本的标准化，同时也难以监控客户对新功能的使用情况，从而优化研发资源分配，而这正是 SaaS 模式最擅长的部分。目前，中国的软件产品在不同行业和企业中都存在个性化定制的部分，数据也是割裂的，这对软件公司来说是一个巨大的挑战。

我自己的经历也证实了这一点。从人脸识别技术的应用来看，即便是在同一行业内，也需要各种个性化定制，这使得软件企业面临比国外更多的问题。我认为，问题的根源在于整个环境，包括国有企业的资产管理及内部审计等问题，软件作为无形资产难以保值，这些都给软件公司带来了困难。这些因素叠加在一起，使得中国的软件公司难以复制硅谷 SaaS 的成功经验。

对于软件企业的发展，现状已经非常清晰。随着人工智能的到来，我们正处在一个划时代的转折点，软件行业可以采取不同的发展路径。我们必须拥抱这一变革。我认为，中国已经到达了一个新的发展阶段。在高速增长的经济体中，对管理标准化的需求可能不会那么迫切。但现在，随着中国经济进入中速发展阶段，大家开始强调“内卷”，实际上意味着我们需要逐步转向追求管理效率，并通过科技手段解决这些问题。因此，我对中国软件行业的未来抱有很大的信心。我相信，尽管目前可能处于低谷，但我们最终会走出困境，重新站起来。

vivo 互联网产品平台架构团队负责人张硕：在分析软件行业的背景时，需要将视野拓宽至整体经济状况，尤其是考虑到这些公司大多是上市公司，它们的表现与市场环境紧密相关。当前，整体经济正面临通缩压力，这使得软件行业的发展呈现出经济周期性特征。尽管如此，软件行业的发展尚未达到成熟阶段，正从粗放型向集约型转变，注重创新、产品质量，并减少对人力资源的依赖以获取增长红利。这是一个宽泛讨论的话题，作为从业者，我们自然希望行业能够持续向好发展。从中国的人均 GDP 和各行业平均薪资来看，软件行业依然稳定地位居前列。

在技术层面，几家亏损的公司如金蝶、东软等，它们有的面向企业（ToB）的业务，有的则从事外包服务。这些公司追求的是数量和规模的增长，但这并不代表中国软件行业的整体水平。若要探讨行业存在的问题，我们需要从专业性和面向未来的行业发展角度出发，对标美国硅谷等地区的具体实践。在研发投入和科技创新力方面，国内软件行业仍有提升空间。此外，国内 ToB 行业的发展一直不尽如人意，人们的消费能力和付费意愿，以及综合经济状况，限制了软件行业的单位收益。我们不能简单地将责任归咎于单一环节或因素，就像近年来芯片问题一样，它也不是由单一因素引起的。

阿里巴巴技术总监郭瑞杰：中国软件行业这个定义太广了，我理解这里讨论的“中国软件行业”应该是指 SaaS 软件，而且可能主要是 ERP 类的 SaaS 软件。SaaS 软件在国内相比海外，确实受接受程度更低，能自己折腾基于开源系统能构建就不会用 SaaS。而且，随着低代码平台、大模型技术的发展，搭建成本更低了，对传统 SaaS 软件也构成了很大的冲击。SaaS 软件还有一个问题是，客户的定制化需求太多了，这对 SaaS 软件的挑战是非常大的。SaaS 软件要有更好的发展，更被大家接受，可能一方面要做好高效率快速定制能力，做好标准化，包括 API 标准化、定制流程标准化、大幅提升定制开发效率。另一方面，全面拥抱 AI，用 AI 技术重塑 SaaS 软件。随着大模型能力的不断增强，能将很多流程完全自动化，大幅提升业务效率，这可能颠覆现有的传统 SaaS 软件。

数势科技 AI 负责人李飞：在软件行业快速发展的背景下，市场竞争日益加剧，不仅体现在本土企业间的相互竞争上，还面临着来自国际同行的挑战。为了争取更大的市场份额，一些公司可能采取诸如降低产品售价或加速业务扩展等策略，这些做法虽然短期内能够吸引客户，但长远来看却可能导致企业利润空间受到挤压。

软件的价值在国内市场上尚未得到充分重视。通常情况下，企业倾向于将软件与硬件捆绑销售，而非将其作为独立产品推向市场，这种做法限制了软件企业的盈利潜力及其进一步发展的动力。面对客户多样化且不断演变的需求，软件企业面临着不小的挑战。每位客户的期望都有所不同，加之数字化转型步伐的加快，使得这些需求持续变化和发展。因此，对于软件开发公司而言，提升对客户需求的理解力以及快速响应的能力变得尤为重要，这是为了更好地适应并满足每一位客户的独特要求。

造成这一现状的主要原因可以归结为几个方面：一是技术创新能力不足，很多企业仍处于跟随者的角色；其次，技术在企业内部的应用价值尚未得到充分展现，部分企业在其产品与服务方面缺乏独特性，这使得它们难以构建起基于差异化的竞争优势；三是鉴于整体市场环境较为低迷，资本投资的机会也相对稀缺，在这种情况下，企业为了生存往往会采取低价竞争等策略，这不利于构建一个有利于长远发展的良好商业生态。

我们的建议主要包括以下几方面：积极接纳新兴技术并增加研发投资：企业需要在基础研究及核心技术方面投入更多资源，特别是在大模型 Agent 等先进技术领域。此举旨在促进自主创新能力的提升，探索新技术与软件产品融合的可能性，从而实现软件向智能化、数字化及云端化的转型。最终目标是为企业用户提供更加高效且富有价值的服务方案。软件企业应当注重人才的培养与保留，通过构建积极向上的工作环境及文化氛围，提供富有竞争力的薪资待遇和职业发展平台，以吸引并留住顶尖的技术人才。此外，还应加强对员工的专业技能培训和个人职业路径规划，确保每位成员都有机会持续学习、成长，进而增强其对企业文化的认同感和忠诚度。促进开源生态系统的发展：倡导软件公司及个人开发者积极参与到开源项目和社区中，贡献优质代码与技术解决方案，以增强中国在全球开源领域内的影响力及发言权。同时，还需加强对开源文化的普及工作，营造积极健康的开源环境，推动整个开源生态系统的良性发展。 促进业界协作：倡导企业间加强合作与资源互享，汇聚力量共同面对市场挑战，进而推进整个行业的长期健康发展。

PingCAP 联合创始人兼 CTO 黄东旭：我不是该行业的专家，我没办法对整个行业做出全面的评判，但我想从我个体观察和大的趋势出发，分享一些看法。我认为这两年中国软件行业的发展其实相当不错。具体来说，很多软件企业都保持着三位数的增长率，甚至在某些区域，增长率高达好几百。

对于“中国软件行业全军覆没”的观点，我并不认同。尽管软件行业是一个竞争激烈的行业，有新公司涌现，也有老公司因不适应市场而被淘汰，但整体上，软件行业仍然是一个新兴且充满活力的行业。以 PingCAP 为例，公司在中国和海外市场增速都很快，这证明了即使在复杂的大环境下，仍有很多企业能够找到与过去不同的成长方式。

我也发现现在很多企业开始把眼界放到更广的地方，不再局限于过去的固定思维和业务模式。我认为在快速变化的世界中，如果企业仍然用静态的眼光看待业务，或者不愿意改变做事方式和产品形态，那么很可能会跟不上时代的步伐。

中关村科金总裁喻友平：第一个感受是软件产品化任重道远：一个现实是国内客户认可软件的价值，但更愿意为硬件买单。中国企业对软件价格的认知从零元盗版开始，形成了低价锚，限制了软件企业的盈利能力。这种历史问题一方面需要逐步扭转行业客户认知，另一方面也需要企业在软件产品化和价值呈现上做更多的探索。其次感受到了市场内卷严重：国内软件市场容量受限，产品功能同质化严重，导致内卷变大，利润空间变小。

我的建议有两点：第一是要抓住 AI 大模型机遇：大模型不仅能对传统软件实现功能增加和价值放大，还可以基于大模型开发出深入行业场景的新产品新应用，这可能会给传统软件行业来一次开天辟地的变革。第二是瞄准全球市场：中国软件企业应考虑全球市场，而不仅仅是国内市场，以实现更大的市场容量和利润空间。同时国外市场对软件服务的价值认可度更高，利于企业形成正向现金流。

统信软件高级副总裁张磊：中国软件整体是向上的，但是文中讨论的企业软件行业确实发展乏力。首先，大 B 用户定制的需求必然存在，这个无法回避的需求问题，世界各地都一样，主要问题在于我国缺乏相对稳定而且具有相当数量的中小企业，另一方面，我国对软件不太重视，在这种观念下，2C 软件卖不出去，2B 当然也难卖出去。对应的商业模式，也就是软件应该卖钱的意识一直没有建立起来。

Kong Inc.高级工程师张晋涛：这个讨论里引用的信息来源都只是软件行业的一部分，其中提到的很多企业属于企业信息化/ERP/软件外包等相关领域，并不能完全代表整个软件行业。对于中国的软件行业，这其实是个很大的话题，我不好评价，我只能评价下我所接触到的行业和我所在的领域。过去十多年，移动互联网经历了蓬勃的发展，这期间诞生了很多优秀的公司，同时也有很多人进入到了这个行业中，实话说过去我们曾经看到过供需关系的转变，这也带来很多不确定性。

我觉得目前的挑战主要在与国内竞争还是很激烈的，尤其是在价格方面。不少公司会为了拿到 Logo 和背书，而选择放弃短期的利益，采用低价来获得客户。这样的价格战有其存在的理由，但它是不可持续的。

出现这种情况的原因有很多，比如，某些公司/产品想要踏入新的行业或者领域，在缺乏背书和行业实践的前提下，通过低价甚至倒贴的方式才能说服客户进行尝试，并以此作为后续在此行业中的一个经验或者背书。

我看到有很多优秀的公司和产品，但很多时候是无法进入到一些领域的，所以客户根本接触不到这些产品。所以有一种策略就是开源，通过开源的方式，可以让更加广泛的客户群体接触到自己的产品，了解其核心的功能。这样后续也可能会通过自底向上的方式获得到一些客户。但这条路也是比较难的，所以不少公司都选择了出海，去做海外的生意。

AutoMQ 联合创始人 & 首席执行官王小瑞：我认为中国软件行业主要可以分为两类：一类是行业软件，另一类是基础软件。我一直在从事基础软件领域的工作，因此想和大家分享一下我所观察到的现状和趋势。基础软件从 2021 年开始变得非常火热，但到了 2023 年，热度逐渐下降，这与整个投资环境的变化有关，也与中美关系以及国内的市场现状密切相关。

基础软件本身需要巨大的投入，而且其特点之一是区域壁垒较小。所谓区域壁垒，是指客户在选择基础软件时，并不会局限于某个区域的厂商，而是会优先选择当前全球最先进的技术，而不是局限于某个区域内最先进的技术。因此，基础软件的全球先进性至关重要，必须代表未来一到五年最先进的技术趋势，而不仅仅是能解决当前问题即可。这是客户选择基础软件时的一个重要趋势。

此外，基础软件与开源密切相关。如今，很难通过闭源的基础软件，如数据库、操作系统、中间件等来获得市场，一定是与开源相关的。开源是一个透明的过程，源代码都是公开的，任何人都可以查看。因此，无法依靠信息不透明或销售手段来影响客户的决策。我们接触的许多中大型企业的核心决策者往往是技术领导者，他们对技术决策具有很大的影响力。我们称他们为技术发烧友或意见领袖。要想获得这些人的认可，关键在于你的开源影响力和产品的技术先进性。如果得不到他们的认可，那么基础软件在中大型客户的销售中就会面临困难。

另一个问题是，基础软件在中国的私有云销售模式是否成立，关键在于你的投资回报率。许多客户在部署私有云时，会有许多驻场、运维或定制需求。这些需求会严重消耗公司的研发资源和人力资源，使你无法集中精力提升产品的竞争力。本来可以将优势资源投入到产品竞争力上，却因为这些项目而无法实现。这会导致软件厂商的产品竞争力下降，难以吸引优秀的工程师。因此，我认为应该在公共云上投入更多，进行规模化经营，才有机会在这一领域取得成功。否则，虽然短期内营收可能很高，但到了一定阶段，公司很难获得更高利润，也难以吸引优秀人才，从而无法产生产品竞争力。最终只能在国内做私有化定制的私有软件，很难在海外公共云上获得全球客户。

我认为中国的软件市场中，只有公共云的软件市场是比较健康的。首先，中国市场的私有部署比例非常高，甚至有些公共云用户也要下云。在这样的现状下，软件私有化回到了早些年 Oracle 的时代。Oracle、IBM 等软件公司能够产生的重要前提是它们具有绝对的垄断地位，因此它们具有软件定价权，可以把软件定价定得很高。所以，对于它们来说，私有化支持都是可盈利的，都是高利润的做法。

到了今天，软件厂商已经没有定价权了，因为整个竞争格局已经是一个透明的竞争，不再是垄断厂商主导。例如，国内有几百家做数据库的企业，这种情况导致软件厂商必须以拿到订单为主，从而把价格压得很低。如果实施成本又很高，其实是难以为继的。在这种情况下，如果整个投资环境又恶化的话，对整个产业来说其实是雪上加霜。所以，关键还是要将研发投入到真正带来产品竞争力的领域，并且不因为私有云这种交付方式而增加人员。

公共云其实是一个非常好的商业模式，它不会因为客户增加而增加工程师。每个工程师做的每一项产品能力更新都是一个积累。可能今天写了一个 feature，这个 feature 服务了一个客户，到了明年可能就服务了 100 个客户。所以单个工程师给公司产生的收益其实远远大于私有云交付的方式。在私有云交付中，客户可能会明确算出项目需要投入 10 个人做 100 天，然后算出 10 人乘以 100 天的单子价格，这个客单价是无法提升的。但是在公共云就不一样了，一个特性就可以服务非常多的客户。

InfoQ：政企单位通常更倾向于选择私有云，对于这部分客户，是否主要由像华为这样的大厂来提供服务？

AutoMQ 联合创始人 & 首席执行官王小瑞：其实大厂也不一定愿意做政企项目。首先，坚持做政府类项目的企业，其组织架构和人员组成往往非常适合服务这类项目。它们能够驾驭政企项目，具有很强的销售能力和客户关系，可以同时处理多个项目，并且每年都有这样的项目可做。它们的人员结构与项目结构高度匹配，如果能够管理好这样的组织架构，那么从事这类项目也是可行的。但这样的项目首先对于公司来说毛利率是比较低的，其次，对于公司的长期发展前景，或者投资和融资的想象空间其实是受限的。我认为我们所从事的基础软件领域，整体上在这个方向发力可能不太合适。基础软件往上一层是行业软件，国内其实有不少公司在这一领域做得相当不错。但我没有看到有哪家基础软件公司在做私有化方面做得特别出色，成功案例比较少见。

问题二：大模型赛道的抉择：坚持投入还是战略调整

InfoQ：我们还应该坚定投入到大模型中吗？OpenAI 数十亿美元的收入尚未转化为盈利的商业模式。由于训练运行的成本开始达到数亿美元甚至数十亿美元，因此盈利之路遥遥无期；国内 Q3 大模型中标项目超 360 个，但业界仍在解决落地难题，并且还缺少杀手级应用。

澜码科技 CEO 周健：我认为国家在智能算力方面的政策定位是非常精准的。今天的智能算力被视为一种基础设施。我经历过深度学习、计算机视觉等技术的发展历程，包括后来的数字员工和 RPA（机器人流程自动化）。这些新技术能够解决特定问题，比如人脸识别、视觉处理，以及自动化人工的键盘、鼠标操作。我们做软件产品时，考虑的是如何将这些技术应用到具体的垂直场景中。然而，基础设施的特点是初期投入巨大，比如电力、能源等公用事业，其基础设施的建设初期需要巨大的投入，需要我们逐渐熟悉如何使用它。电力最初在工厂中的应用可能只是一个电灯泡，但现在，随着电力基础设施的完善，工厂和家庭中都有需要大量使用电力的电器，从电灯到冰箱、洗衣机、电视机，再到现在的扫地机器人等，这些都是如何利用好基础设施的例子。

今天的 GPU、服务器，以及大模型，都是基础设施的一部分。大模型就像发电机一样，能够将服务器上的 GPU 算力转化为类似人类智能的东西。有了大模型，像处理简历、分析财报这些原本需要人工完成的工作，现在可以通过 AI 来实现。这种智能就像过去的电力一样，我们可以按需使用。

从这个维度上来说，我认为我们必须坚定地投入大模型，否则就会在基础生产力上与国际领先水平拉开差距。这是一个我们必须解决的问题。当然，尽管我们建立了这么多基础设施，但目前还没有出现杀手级应用。对此，政府正在引导各行各业开放场景，推动场景驱动的创新。另外，我认为智能需要与数据结合，就像人一样，即使再聪明，如果没有见过一万份财报，没有见过大量实际数据，要求做好 CFO 或分析师也是非常困难的。目前，包括大模型公司在内的企业能够获取的公开数据仍然有限。国家很有预见性地指出了数据要素入表，如何将数据资本化，如何区分开不同的权利。我们需要从这个角度出发，实现数据共享，这样我们才能有更多的场景落地，才能将基础设施的算力转化为实际的经济价值。

vivo 互联网产品平台架构团队负责人张硕：当前国内在大模型领域存在两种不同的观点。一派以朱啸虎等顶级 VC 投资人为代表，他们认为在大模型上的大量投入可能难以转化为相应的盈利，从不同角度来看，这种观点有其合理性。然而，我认为我们仍应继续在这一领域进行投资。这与芯片问题的处理方式相似，即持续投入以确保技术进步和产业安全。从长远来看，如果考虑到国产替代的背景，我们与美国在大模型领域存在明显的差距。如果不继续投入，一旦发生贸易摩擦或制裁，可能会对我们产生显著的负面影响。

阿里巴巴技术总监郭瑞杰：我相信大模型不是昙花一现，可能是打开了潘多拉魔盒，应该更加坚定投入到大模型中，利用大模型重构已有的业务，在自己的业务场景去做更多的探索和创新。大部分企业不应该搞基础大模型的训练，成本太高了，也没有必要。过去一年，非常多的公司，放弃了做大模型预训练，甚至做微调训练的都少了很多，很多都转向基于基础大模型做应用，这是对的。基础大模型预训练最后一定是收敛到少数几家。尽管现在大模型应用还没有爆发，也还没有杀手级应用出现，不过，大模型能“理解”自然语言、“理解”图像、视频、语音，有一定的推理能力，具备非常广泛的适用性，在企业知识管理、医疗、金融、教育等几乎每一个领域，都有非常多的潜在的应用场景。过去一年，基础大模型能力越来越强，但推理能力，或者说“慢思考”能力还是不够，也仍然存在幻觉问题，这制约了在很多业务场景的落地。另外，大模型的训练和推理成本非常高，也是制约发展的重要因素。大模型能力的不断突破，应用场景的持续深耕，在数字化转型加速的背景下，新的商业机会，杀手级的应用一定能涌现。

数势科技 AI 负责人李飞：在现有的技术背景下，将资源投入到大规模模型的研发及其实际应用显得尤为关键，特别是人工智能代理（AI Agent）的开发与部署。预计至 2025 年，将迎来一个以大模型为基础的人工智能代理快速发展的新时期。尽管像 OpenAI 这样的企业，在高额投资与其当前盈利模式之间尚未找到完美的平衡点，但这并不能削弱我们对探索此类技术潜力的热情。实际上，我们正站在一场深刻变革的门槛上，未来有望见证一系列革新性且极具价值的应用程序的诞生。

以数势科技独立开发的智能分析工具——SwiftAgent 为例，2024 年，我们在城市商业银行及食品零售业成功实现了商业部署，这一成就彰显了大型模型代理在企业数字化转型过程中的强大潜力。此案例不仅验证了大模型技术在特定行业内的实用价值，同时也为我们指明了一条清晰的发展路径：即通过深入研究各行业的核心挑战，专注于创造场景化的价值，并开发出具有针对性的解决方案，可以极大地促进此类先进技术的实际应用。

基于我们的经验，总结以下几点经验，希望能够有所裨益：

1.大模型的研究与开发应当注重行业应用，通过推动大型模型代理在特定领域内的深入实践，并根据各行业的独特需求进行专门定制，以期创建出一系列能够体现行业特点的应用范例，从而彰显其实际应用价值。

2.强化生态协作：倡导跨领域合作及联盟建设，构建一个开放的创新环境。通过资源的有效共享与联合创新机制，可以加快大规模模型技术的实际应用进程，促进相关行业标准的确立，进而简化技术落地过程中的复杂性。

3.重视用户反馈：在大型模型代理的商业化进程中，应持续关注用户的反馈信息与市场趋势，迅速调整并优化产品。此举旨在确保我们的解决方案能够精准对接用户需求，进一步提升用户体验。

4. 构建可持续发展的商业框架：在致力于技术创新的同时，探索适应市场需求的商业模式同样重要，以确保企业的长期繁荣。这可能涉及但不限于提供基于服务的收费机制、开发数据分析相关的增值服务等多种收益渠道，从而构建一个多元化的盈利体系。

PingCAP 联合创始人兼 CTO 黄东旭：我认为 AI 这一轮变革的影响实则非常深远，尽管它可能不会像 iPhone 那样带来立竿见影、颠覆性的变化。

在短期内，AI 的影响更像是“润物细无声”，它会悄无声息地融入我们日常生活的方方面面。例如，在会议结束后，我们已习惯于让 AI 帮忙总结会议纪要；在撰写文档时，我们也乐于让 AI 帮忙润色；传统的翻译软件已逐渐被 AI 翻译所取代；甚至在浏览网页时，我也倾向于先让 AI 为我朗读一遍，再决定是否深入阅读。

在我看来，AI 在短期内呈现出的一个显著范式是，它并非作为一个独立的产品出现，而是附加于现有的各种产品中，使它们变得更加易用、个性化和实用。如果我们想象一下，如果所有这些产品中的 AI 能力突然消失，我们会感到非常不适应，这实际上意味着 AI 已经深刻地改变了我们的生活。

目前，AI 社区似乎分为两派。一派致力于追求更大的模型，坚信摩尔定律，并致力于实现通用人工智能（AGI）。这往往是头部 AI 厂商在新闻发布会上强调的愿景。然而，另一派则更加务实，他们接受了当前 AI，尤其是大模型的能力边界和它的局限性。他们了解 AI 擅长做什么（如总结、高级规划、翻译和润色等工作），以及不擅长做什么（如处理复杂任务或需要高度上下文理解的任务）。在接受了这些现实后，他们专注于如何利用现有的基础设施（如数据和工程能力）来构建有用的智能体。

我倾向于站在后者这一边。我认为，虽然对 AI 的投入肯定需要加大，但这些投入更应聚焦于如何利用现有的资源来辅助 AI，使其在垂直领域或狭窄领域中发挥实际作用。简而言之，我们应先致力于构建有用的 AI 应用，而非一味追求遥不可及的理想模型。

中关村科金总裁喻友平：大模型产业经过了早期的“暴风骤雨”式发展后，现在进入了更为平稳的“润物细无声”状态。大模型的突破口就是规划化的应用落地，让大模型的价值越来越多的显现出来。

展望明年和未来几年，最有可能改变的行业或领域可能还是那些数据和知识密集型的行业或领域，比如：法律、医疗、教育等，大模型有能力消化这些行业或领域的数据，尤其是非结构化数据，能够提供更加自动化的服务，或者能够更好的支撑人提升效率，包括，提供陪练、助手、质检等服务。其次是一些创意性的行业，比如：设计、文学等，这些领域，生成的结果，没有绝对正确的答案，但是大模型能够带来更多的连接和新的可能性。

统信软件高级副总裁张磊：我们认为大模型还需要继续做，现在的大模型离技术与商业边界还有相当距离，而且一般来说，新技术在短期范围被高估，长期范围被低估是正常的。我们感觉模型需要小型化、端化，降低其使用成本，同时通过快速的小创新来赢得各种用户并持续吸引住他们。

智源研究院数据研究组负责人刘广：我是做大模型相关的，我觉得还是需要坚定地投入到大模型中去。因为，现在大模型不仅仅是商业模式的问题，还涉及到了科研模式的改变，比如 AI for 4s 已经深入到很多研究或者各个行业的应用场景中了。虽然还没有一个明确的商业模式，但随着模型能力的不断迭代和优化，大模型能够解决的问题也越来越多。所以从技术发展的角度来说，我觉得还是需要坚定投入。

最近，有人做了分析，大模型解决问题能力，比如数学或者其他比较难的题目，呈现出了几何倍数的增长。过去一两年，大模型在解决这种非常复杂的数学问题能力上的进展非常缓慢，但最近几个月，或者最近 1 年的时间，从 o1 到 o3 的进步是几何倍数级别的。未来这种模型能力的增长速度会越来越快，肯定是要坚定投入。

Kong Inc.高级工程师张晋涛：是否投入还是看趋势，以及看在资本在哪里。目前的情况是 AI 或者说大模型，已经成为了共识，这是一个趋势，不可逆转。另外，很多资本在选择项目的时候，也在看是否能顺应这个趋势。所以投入还是要投入的，但并不是说就没有其他生意了，并且 AI 或者说大模型的生意竞争也很激烈，所以要在投入这个领域的大方向中切分出一条适合自己的赛道或者路线。

问题三：国内开源的现状与未来之路

InfoQ：您如何看待开源现状与改善之道：今年我们在报道开源相关新闻时，有一些读者留言表示目前国内开源存在一些问题，比如为了完成 kpi 而开源、只开源某一个模块或某一部分、在项目中到处放收款码等。

vivo 互联网产品平台架构团队负责人张硕：从两个不同的角度来探讨开源的现状和问题。首先，从开源的使用者角度来看，这些主要是中小企业以及相关从业者，他们直接使用开源资源，但贡献相对较少。他们自然希望开源资源越多越好，因为这能方便企业的成本控制、从业者的工作学习等，直接拿来使用无疑是非常便利的。国内许多知名企业都在大量使用开源资源，但对相关的许可证协议和法规关注不足。与明确的专利侵权相比，知识产权保护在开源领域相对薄弱。从使用者的角度来看，他们有其合理性，如果将开源视为绩效指标（KPI），或者只开源一部分，这无疑会带来不便。

其次，从开源的发起者和开源本身的角度来看，我们需要考虑开源是如何运作和维持的。如果开源只是免费拿来即用，那么显然存在问题。如果不参与贡献、只消费，社区是无法持续存在的。我见过很多社区成员对开源的核心发起人和贡献者提出批评，仅仅因为某些功能不符合他们的期望。开源本质上是需要共同维护和贡献的，贡献者并没有义务每年都要推进发展。有些人只看到未开源的部分，却忽视了已经开源的部分。我认为应该更多地参与开源社区，而不是仅仅作为一个消费者。这是开源目前面临的主要问题：参与的人少，但消费者数量庞大，甚至有营收的公司对开源的依赖程度非常高，这已成为行业的共识。

阿里巴巴技术总监郭瑞杰：国内开源确实存在这些问题。我自己也是开源技术爱好者，在上学期间，自己用 C++写了一套高性能搜索引擎，是国内第一款开源搜索引擎。在 7 年前，促成阿里云和开源软件 Elasticsearch 的商业公司 Elastic 达成战略合作关系，并推出完全兼容开源 Elasticsearch 的阿里云 Elasticsearch 企业版，与开源协同发展。两年前，推动开源了在阿里巴巴和蚂蚁集团核心业务中广泛使用的大规模分布式搜索引擎 Havenask（内部代号：HA3）。我们秉承真开源的原则推动项目，全部核心代码开源开放，采用 Apache license 2.0，对商业化完全 Open。我们开源不是为了 KPI，初衷是吸引更多的开发者参与共创，普惠更多的开发者和企业。在国内做开源项目相对更加艰难，不少开发者和公司习惯于只索取，不贡献，即使有优化改动，也比较少回馈给社区。开源需要有耐心，培育开源生态是一个漫长的过程，但一旦培养起来，商业化就相对容易些，商业化和开源生态相辅相成。

PingCAP 联合创始人兼 CTO 黄东旭：坦白来讲，我并没有特别关注所谓的“国内开源”。在我看来，开源这一理念本身就应当是跨越国界的，不应以地域划分。所以我总是从全球的角度去审视开源这一事物。

我觉得在每个地区都可能存在以开源之名行非开源之实的现象，这些行为无疑会损害开源社区的健康发展。但我也坚信，开源社区的文化本身具有一种优胜劣汰的力量。那些真正优秀的开源项目会自然而然地脱颖而出，而那些质量低劣或存在问题的项目则会遭到用户的摒弃。

因此，对于国内开源现象，我认为无需过多担忧或进行额外的限制与引导。我相信开源社区自身的逻辑和机制能够自然地淘汰那些不良因素。让市场与整个开源社区自然发展，或许就是最好的解决之道。

中关村科金总裁喻友平：国内企业往往难以平衡开源和商业化之间的关系，有些企业希望通过开源快速获得用户，但未能建立起可持续的盈利模式，导致项目生命周期短暂。如果再放收款码回血，就成为变相收费，加速用户流失。

开源一部分的“伪开源”，一方面是企业想要“留一手”保持自身竞争力，另一方面是开源许可证在国内的认知和执行力度较弱，容易引起侵权行为或商业化纠纷，“伪开源”可能是一种自我保护。

归根到底还是因为国内对开源的认知和文化建设仍在起步阶段，许多人将开源视为获取免费工具的方式，而非共享与合作的技术生态。同时对开源技术的法律保护机制还不完善，“用爱发电”的开源在“拿来主义”面前缺少有效保护。以及在开源商业模式上照搬国外不 work，需要探索出适合国内特色的开源模式创新。

统信软件高级副总裁张磊：首先，国外其实也在发生这种事情，包括 MongoDB，包括 “open”AI 等。除此之外，一个是我们做开源还是比较陌生，所以会有一些不同的作法，其二，开源的商业模式其实和闭源软件是不太一样的，不是卖 License，而是卖订阅和服务，但是软件 License 已经很难卖，订阅服务就更难卖了，其三，现在开源和早期已经有所不同了，早期更个人化，现在更公司化，公司化必然会有 KPI，而且大公司的创新性相对于小团队来说一般是不足的。

AutoMQ 联合创始人 & 首席执行官王小瑞：我认为这些都是一些落后的市场行为，不符合双赢原则，最终会被淘汰。以基础软件为例，开源必须把最核心的部分开放出来，这部分应该能满足 80%到 90%的客户需求。对于一些高级特性，其实没有必要开源，因为它们受众较小，而且是企业版的重要特性。这些能力可能不是核心代码，而是更多地与外部系统集成或提供更开箱即用的功能，更适合放在企业版。开源什么、不开源什么，需要仔细权衡，不应受到道德绑架。开源界有时会出现一些声音，用道德标准去要求其他开源企业和个人，例如质疑为什么某个功能不开源，或者对 license 有异议。但开源也要走向健康模式，不能仅凭义务去做，仅凭义务是不可持续、不可长久的。一个行业、一个领域都希望有更优秀的开源项目，而优秀的开源背后一定有优秀的商业模式。没有商业模式，仅有开源是很难的。以 Linux 为例，它背后就有非常优秀的商业模式。

国内一些企业会有强制开源的做法，像 KPI 一样，把它当成任务去完成，这其实是不合理的。开源一个项目就像在公司里立项一样，但获得回报是一个长期的过程。以 K8S 为例，从开源到被众多企业采用，耗时两年以上。因此，开源 KPI 不是问题，关键在于如何定义。企业内部一定要有 KPI，但这个 KPI 必须是北极星指标，即真正能反映项目成功与否的关键指标。以开源一个 AI 大模型训练项目为例，北极星指标可以是获得 10 个大型公司的标杆案例，而不是单纯追求 star 数。如果一个项目第一年开源后就有 10 个大型标杆客户使用，那它无疑是成功的，其 star 数自然也会很高。每个项目都需要找到适合自己的北极星指标，这个指标可能会随时间变化。一旦项目能从这种方式一步一步走下来，很快就会火起来，找到自己的商业模式和付费客户。开源项目也有一些长远的、可量化的目标，关键在于不同阶段要定义合适的目标。目标定义对了，项目就会受益；定义错了，就会出现变形的动作。最近一两年，我们也遇到了一些开源事件，看到了一些不那么美好的变形动作。

问题四：IT 行业传承之道：师徒制能否适应国内职场环境？

InfoQ：亚马逊 CTO Werner Vogels 和Uncle Bob都不约而同提到 IT 行业应该用师徒制来传承技术，Werner Vogels 认为传统的 IT 教育方式已经不满足需求了，学位学徒制度借鉴了电工、木匠等技术工人的传统学徒模式，通过实际工作中的学习不断提升个体的技能水平。Uncle Bob 认为这个行业里有一二十年经验的人必须承担起责任，教育涌入我们领域并稀释我们职业的大量年轻程序员，“业界真正需要的是一个完善的学徒制度。新程序员应该在资深程序员的亲自指导下，通过实践操作和严格监督来学习——就像医生和律师那样。”如何看待师徒制，有可能在国内现有环境中实施起来吗？特别是在有可能存在 35 岁危机的环境中，比如今年有新闻“被曝拒招 35 岁以上员工，猎头称超 32 岁基本没戏”。

澜码科技 CEO 周健：我认为师徒制不太可能是未来 IT 行业的发展方向，因为它是一种落后的传统方式。本质上，师徒制是因为专家无法将经验数字化，所以必须通过传统的“传帮带“方式来传授技能，即通过实际操作示范和观察来学习。这种方式在 IT 人才成长中肯定是有缺失的，但在大模型技术出现后，程序员面临的最大风险实际上是编程语言的变化。历史上，每当计算机能力突破一定阶段，程序员所使用的编程语言就会发生巨大变化。从最初的纸带编程，到后来的汇编语言，再到现在的高级语言，大模型的出现可能会使 Rust、C++、Java 等变成上一代编程语言，未来这些语言的使用比例一定会发生巨大变化。

现在，大模型已经能够生成 30%的代码，这一趋势是不可逆转的。未来，对程序员的定义可能会改变，他们可能更多地使用接近人类语言的方式与机器互动，类似于现在的提示词工程师。那时，我们不再需要传统的学徒模式，因为更难的不是如何让机器帮助我们做事，而是对业务本身的理解。像律师、医生等需要专业技术的职业，他们都会通过提示词让 AI 帮助他们完成任务，无论是编程还是训练一个代理。对于那些负责搭建 IT 基础设施的岗位，AI 技术的出现也可能会提供更好的解决方案。过去这些领域确实需要用学徒的方式来传授技能，因为那时我们的工具还不够先进，所做的事情也不够标准化，必须依赖学徒模式。

vivo 互联网产品平台架构团队负责人张硕：我认为可能不太适合。他所谓的目标是期望能够更深入地钻研技术。就像 Bob 大叔那样，我之前与他有过直接交流，阅读过他的书，并在他的博客上讨论过一些问题。他们往往倾向于将架构引向更深层次的发展。但在国内，这方面的行业问题较多，市场上相当多的岗位并不需要在某个细分方向上有深入的背景能力或专业知识。Bob 大叔提到的面向对象的原则在国内大多数公司的落地情况也不是特别理想。从整体来看，在传统软件上，比如面向对象程序设计，目前没有太多岗位适合纯钻技术的土壤，更多的是需要保持足够的快速学习能力、解决核心瓶颈、关键问题的能力，面向科技企业经营的特点，提供支持和价值，而且整体的专业化程度也不够。因此，暂时并没有太大必要实行所谓的师徒制，互联网的资料、学习渠道简直太多太多了。

至于所谓的“35 岁危机”，包括我前段时间看到的这种文化蔓延到香港的情况，看了短视频中香港 HR 对这种文化的投诉或抨击，我们目前整体上还是处于一个粗放型的发展阶段。许多问题都是比较粗放的，这个不是一个单一的行业问题。

阿里巴巴技术总监郭瑞杰：阿里一直有这样一个机制：新员工入职会分配一位“师兄”，师兄一般是公司的资深员工，师兄要负责新人的 landing，带着新人学习知识、快速融入团队，帮助新人快速成长。这个机制跟“学徒”模式有点像，对新人成长有很好的帮助，能有效缩短新人的上手实践，提升整体技术水平，值得推广。不过我不认为这个机制能解决 35 岁危机。35 岁危机的产生，个人认为更多的是内卷导致。年纪大的的程序员，有家庭、小孩，势必会分散部分精力，体力也下降，薪酬往往也更高，在很多领域可能性价比不如年轻人。高龄程序员要持续学习提升自身竞争力，往深水区走，避免在技术要求较低的浅水区做重复工作。

PingCAP 联合创始人兼 CTO 黄东旭：我回想起自己的经历，思考开发者和程序员这一职业的本质。确实，这一职业类似于学徒或工匠的岗位，但其核心并不在于师傅带徒弟的形式，而在于个人通过实践获得能力并总结经验。实践是获取编程能力的必然途径。虽然师徒制有其优势，但并非唯一或必然的培养方式。随着 AI 技术的发展，新一代程序员可以通过多种途径获取知识和技能。关键在于找到最适合当前时代和环境的培养方式，以促进程序员的成长和发展。

对于 35 岁转型的问题，我认为这可能是一个玩笑或梗，因为优秀的程序员通常不会受年龄限制而考虑转型。人们更关心的是，人工智能和当前这波人工智能技术如何帮助新一代程序员更好地成长。

随着 Cursor、Copilot 等编程辅助工具的日益完善，编写程序的门槛已经大大降低。然而，这对程序员提出了更高的要求，即在快速生成代码的同时，如何确保代码的正确性和选择最优的解决方案。就比如我要从北京到上海有很多种交通方式的选择，程序员在面对多种解决方案时，需要选择最优雅或最高效的方法，就像大多数人会选择坐飞机而不是开车一样。

中关村科金总裁喻友平：师徒制很难实施。传统学徒模式，师傅掌握独家技术，在教徒弟过程中经常“留一手”，长期下来会造成核心技术和经验的失传。而现代 IT 技术很多内容都是公开信息，徒弟可以自学成长，师傅能教导的往往是一些理念和经验，这些虽然会缩短徒弟的成长时间，但也可能会造成技术思维固化。同时，技术迭代非常快，年轻人在新技术赛道反而会成为师傅的角色。比如在 AI 大模型领域，就有很多的年轻科学家和研究员。所有的技术人员，无论年纪大小，在实践中持续学习是最好保持竞争力的最佳路径。

统信软件高级副总裁张磊：感觉这不太可能成为产业界的主流，现在的主流可能更偏向开源、社区、AI 等方式来传授各种知识和技能，当然，公司里的导师制是有的，但是感觉师徒制不可能太长时间，也不太可能规模化。

问题五：中小团队如何撬动行业关注的杠杆？

InfoQ：今年还有一件受到大家关注的事件：由中小团队开发的黑悟空火了，给我们带来什么启示？

阿里巴巴技术总监郭瑞杰：船小好掉头，相比大型企业，小团队更加灵活，高效的决策，快速响应市场需求，通过高度协作和敏捷开发，实现产品快速迭代和优化。在大模型技术兴起的今天，更是如此。通过创新驱动、敏捷开发、精准定位以及高效资源利用，中小团队也能够快速打造出具有影响力的产品。过去一年，已经有非常多这样的成功案例。

PingCAP 联合创始人兼 CTO：我很喜欢这款游戏，它已经陪伴我度过了好几个周末，它确实让人很难抗拒。深入体验它后，我深刻感受到制作团队对游戏的热爱与投入。他们并非为了追求短期的经济利益而制作这款游戏，而是真正热爱并致力于创作出一款优秀的作品。这让我深受启发，明白了认真做事和为了更高的目标、追求去做事情，往往能够取得更好的结果。制作团队在制作过程中，更多考虑的是如何将游戏打造成一件艺术品，而非其经济效益。这种精神值得我们学习和借鉴。

我也从外部报道中了解到，《黑悟空》团队在技术选型和团队规模上也给了我很大的启发。他们善于利用最新的技术，如渲染引擎等，以较小的团队规模实现了更大的影响力和冲击力。这启示我们在面对挑战时，要善于运用杠杆效应，以最小的资源实现最大的效益。

更重要的是，《黑悟空》的成功也证明了中国游戏团队有能力在被日本、美国等传统巨头垄断的 5A 或 3A 游戏行业中突破重围。这同样让我联想到了 PingCAP 等公司的故事。在数据库领域被欧美大公司垄断的背景下，我们也是凭借一个较小的华人团队，成功打造出了世界级的产品。他们的成功让我更加坚信小团队也能做出大事情。他们的热爱、投入、创新精神以及善于运用杠杆效应的能力都值得我们学习和借鉴。

中关村科金总裁喻友平：黑神话悟空能够火爆全球，核心是这款游戏产品赢得了游戏玩家的青睐，这其实和乔布斯发布的 iPhone 4 类似，好产品自己会传播，好产品的价值也会被用户认可。对产品用户来说，他们其实不关注产品背后的技术有多难，开发团队有多大，他们更关注的是产品的使用体验，以及产品带给他们的 ROI 是不是够高。黑神话悟空有很多玩家赞赏说超值，这就是 ROI 够高。而对中小技术团队来说，打造好产品要善于使用各类开源平台和工具，黑神话悟空就是基于开源的虚幻引擎 5 打造，站在巨人肩膀上能省下很多开发时间，但同时要注意沉淀团队的核心技术经验，积累行业理解。

问题六：Rust 的争议与发展前景

InfoQ：Rust 因其内存安全、性能和并发优势备受关注，但也引发了争议。C++提案借鉴 Rust 特性，Linux 内核部分引入 Rust 却引发质疑，有人断言“Rust 引入已失败”。同时，部分国家推动内存安全语言立法化，让 Rust 在关键领域更受瞩目。在生态尚未完全成熟的情况下，您如何看待 Rust 的发展前景？

阿里巴巴技术总监郭瑞杰：Rust 是一种既安全又高效的系统级编译型编程语言，性能媲美 C 和 C++，但通过所有权系统和严格的编译检查，增强了内存安全性，弥补了 C/C++语言的短板，构建底层系统、开发高性能应用等，Rust 是很好的选择，比如近期热度较高的开源搜索引擎 tantiivy 就是 Rust 语言实现的。Rust 是一门优秀的现代编程，不过个人认为 Rust 不太可能完全取代 C/C++ 等已有的编程语言，Rust 凭借其自身优势，可能成为这些语言的重要补充。

淘天集团 1688 终端架构负责人曹立成：其实 Rust 火了很多年了，用它的开发者虽然现在确实不多但也呈现上升趋势。在大前端领域，很多场景还是没有用它去写。Rust 的开发成本高，生态不够完善，开发大型应用程序时，依赖的库和工具往往无法与 Python 或 C++ 等语言的生态完善度相媲美。Rust 的一个显著优势是内存安全，因此常用于底层基础设施的开发。

在前端用得比较多的地方是工具链中。越来越多的编译工具开始尝试使用 Rust 实现。尽管如此，在面向用户界面的前端代码中，Rust 的应用比例仍然较低。与之相对，在更广泛的“大前端”领域，Rust 的发展呈现出一些值得关注的趋势。例如，vivo “蓝河”操作系统内核采用 Rust 编写。这些设备对性能和内存安全性有严格要求，而 Rust 的语言特性正好满足这些需求。

此外，Rust 的跨平台能力也在逐渐受到关注。Rust 编写的库，可以运行在 Android 和 iOS 系统上，甚至在浏览器中。然而，从当前业界整体情况来看，这类实践还比较少。例如，飞书使用 Rust 编写中间件，实现跨平台的代码复用，美团也在尝试使用 Rust 做跨平台框架，但更多头部公司仍然倾向于采用 C++ 完成类似的任务。对于很多开发者来说，切换到 Rust 的动力不足。

统信软件高级副总裁张磊：Rust 是有机会的（谨慎乐观），但是感觉它也有几个问题，首先是没有 spec，其次是社区治理比较乱，缺乏内核与 Python 社区这种仁慈的独裁者的角色，当然还有就是现在 Rust 也相当复杂。如果能设计出一个同样安全，而且易用的系统语言，保持开源，有确定的 spec，社区治理开放而且稳固，那应该会代替 Rust。

AutoMQ 联合创始人 & 首席执行官王小瑞：我自己也用 Rust 编写过一个小模块，对这门语言相当喜爱。我最初是用 C 语言编程，后来转向 C++，发现 C++ 比 C 语言好用很多。再后来我开始用 Java 编程，这时我发现自己再也不想用 C++ 写代码了。高级语言之间的差异还是挺大的。C++ 需要程序员自己管理内存、处理复杂的语法，甚至在编写代码时要理解代码背后的执行规则，了解 CPU 指令如何操作内存、如何释放内存，以及操作系统中堆和栈等内存结构的交互。因此，C++ 对程序员脑细胞的消耗远大于 Java。Rust 则介于两者之间，它将 C++ 中许多需要手动完成的事情自动化，同时性能与 C++ 相当，不像 Java 需要在运行时回收对象，而是在编译期就完成了对象生命周期等检查规则。这样一来，性能得到了提升，但 Rust 编程的复杂度却远高于 Java。

我们认为，绝大多数项目如果能用 Java 完成，就应该优先选择 Java 或者 Go 语言，而不是 Rust。这主要有两方面考虑：一是 Rust 相比 Java 是否有额外的收益，如果没有，那应该选择 Java；二是 Rust 的编程复杂度确实高于 Java，项目成员是否对 Rust 有足够的了解。

对于 Linux in Rust 这个项目，我是持赞成态度的。Linux 很多模块是用 C 或 C++ 编写的，而 Rust 天生与 C 和 C++ 有很好的兼容性。至于项目是否失败，我认为这可能是一个工程问题。Rust 的学习门槛确实较高，程序员是否真正理解 Rust，以及 Rust 的生态系统是否足够丰富、是否有大量可复用的组件，这些都是关键因素。我判断，未来 Rust 一定会在操作系统、嵌入式系统或偏重存储的系统中得到更广泛的应用，在对性能和实时性要求较高的场景中也会发挥很大的作用。

问题七：其他热点事件

InfoQ：是否还有其它值得一提的热点事件？为什么该事件值得讨论？同时请您发表自己对该事件的看法

统信软件高级副总裁张磊：比如今年的 Windows /CrowdStrike蓝屏事件、内核社区踢出俄罗斯维护者的事件都值得一提，前者实际上是安全软件自身保障不足，导致操作系统不稳定，后者标识着国际形势的变化最终还是传导到了开源社区，开源社区并不是世外桃源，也可能发生分裂与治理的问题。

技术前沿：2024 年关键领域创新与进展回顾

大模型：没人能预测未来

饶是在经历了 2023 年的百模大战后，2024 年的大模型领域依然看点十足。先回顾下 2024 年发生在大模型领域几件大事：

• 2 月 16 日，OpenAI 宣告推出文生视频大模型 Sora，到了 12 月才正式对开发布。该模型的发布标志着人工智能在理解真实世界场景并与之互动的能力方面实现飞跃，也被认为是实现通用人工智能（AGI）的重要里程碑。

• 3 月，“人工智能+”行动首次被写入《政府工作报告》，将人工智能提升到战略层面。

• 5 月 14 日，‌OpenAI 正式发布了 GPT-4o，实现了音频、视觉和文本推理的实时交互，被认为是聊天机器人和大模型领域实现重大飞跃的突破性举措。

• 5 月，国内毫无预兆地掀起了大模型“价格战”，阿里、百度、腾讯、字节等纷纷加入战团。

• 6 月，快手推出自研大模型“可灵 AI”，并面向 C 端用户开放，不错的生成效果再次点燃视频生成赛道。

• 10 月，诺贝尔物理学奖颁发给在利用人工神经网络进行机器学习方面做出开创性贡献的科学家，标志着主流科学界对 AI 技术潜力的充分认可。

• 9 月 13 日，OpenAI 推出了 o1 系列推理型模型，通过优化推理阶段提升性能，开启了新的 Scaling Law(Test-time-Scaling Law)。3 个月后，OpenAI 发布了 o3 模型。

• 同年 9 月，李飞飞创建了 World Labs，旨在构建大型世界模型来感知、生成 3D 世界并与之交互，并在 12 月首次官宣了空间智能模型。

• 12 月 26 日，DeepSeek 宣布全新系列模型 DeepSeek-V3 上线并同步开源，该模型仅需 557 万美元训练成本但性能堪比 GPT-4o，被称为“价比之王”，火爆海内外。

当然还有很多公司发布了各自的模型，但 2024 年的大模型研究方向依然被 OpenAI 引领，只是 OpenAI 的领先优势并不会持续太久，后来者的赶超速度非常快。

Scaling Law 的含义被拓展

2024 年 12 月的 NeurIPS 上，Ilya Sutskever 的一句“我们所熟知的预训练即将终结”掀起万般波澜。早在 10 月时就有消息称国内大模型“六小虎”中有两家放弃了预训练，11 月外媒披露 OpenAI 大改下代大模型方向，Scaling Law 撞墙。

不过，Scaling Law 撞墙的观点在业内并未形成共识，以奥特曼、扎克伯格等代表的人们则认为尚未达到传统 scaling laws 的极限，国内多数学者、研发负责人也持保守态度，即在达到一定规模前 Scaling Law 依然有效，但到了一定的临界点，Scaling Law 可能不再那么有效，或会衍生出新的方法。

所谓 Scaling Law 撞墙，更多的是指预训练扩展定律（Pre-training Scaling Law），但是有关后训练和推理的 Scaling Law 还未被充分挖掘。值得指出的是，经过一年实践，业内发现 Scaling Law 不仅对于大型语言模型有效，也逐渐验证了在文生图、文生视频模型上的适用性。

后训练扩展定律（Post-training Scaling Law）关注的是在模型训练完成后通过增加推理阶段的计算量来提升模型性能，包括对 SFT、强化学习对齐、强化学习算法的改进，长思维链和反思的应用等。推理扩展定律（Inference Scaling Law）则强调在推理阶段通过增加计算资源来提升模型性能，比如在推理解码时做 search，探究出更优的解码路径。其中，像 Pre-training 是提升模型本身能力的上限，Inference 则是提高模型的下限。

典型的 o1 在生成结果前，花了大量的算力和时间在推理上，模型性能得到了对数线性的提升。整体看，算力的持续增长需求会更多的反映到推理测试上。o1 之后，国内推理模型也相继发布，如 11 月阿里云通义团队发布全新 AI 推理模型 QwQ-32B-Preview；12 月智谱上线首个深度推理模型 GLM-Zero 等。

当前国内企业似乎还没有为 Scaling Law 失效做准备。由于美国技术封锁等因素，中国的大模型市场在在资源和算力上一直处于被压抑的状态。这样的背景下，企业和研究机构更希望尽快尝试 Scaling Law 在各自场景中的有效性，而非提前为 Scaling Law 失效做准备。只有当企业不再面临算力短缺、在实验和业务过程中逐渐感到 Scaling Law 的增长乏力，以及它的投资回报率不再是最高的时候，才可能开始考虑 Scaling Law 失效后的应对问题。但现实是，整个中国，从创业公司到大厂，都处于一种被压抑的状态，大家更关注如何利用有限的资源探索 Scaling Law 的潜力。

数据短缺问题爆发

关于 Scaling Law 撞墙的讨论更多还是暴露了大模型训练面临的数据短缺问题。

实际上，数据墙问题在去年就出现了，互联网级别的数据已经不够多。另外在真正落地时，很多行业的数据也存在壁垒，比如医疗就有很多隐私、法律、商业等方面的考虑，导致这种数据的开源共享面临非常大的挑战。

但业内有专家拒绝用“枯竭”形容数据短缺问题，他不认为大家已把现有数据用到了极致，“只是冰山一角”，甚至仅仅是文本数据，还有大量的图像数据、视频数据、音频数据等未被充分利用。另外，一些数据清洗、整理、筛选的很多技术挑战还未解决，模型本身的参数、模型结构、学习方法等技术问题也需要解决。

在当下，数据合成俨然成为应对数据匮乏难题的热门之选。合成数据能够对模型的训练与优化起到积极的助力作用。纵观大型模型的全生命周期，合成数据的身影早已出现，例如在指令微调和偏好学习等阶段大多都借助合成方式生成相应的数据。而在预训练阶段，运用合成数据可以快速提升数据质量，填补稀缺数据来源。值得一提的是，目前互联网上合成数据所占比例正呈现快速攀升之势，其增长速度之迅猛令人瞩目。

预训练的数据合成分成三个阶段：第一，完全不合成，只做过滤、不做任何处理；第二，部分合成，如对一个网页内容做改写，或者针对性生成一些问题和答案。目前，大部分公开技术都处于这个状态，即基于种子数据做修改或者问题合成；第三，完全合成，不过受限于模型能力水平，现在还不是特别普及，是未来的重要技术发展趋势。

数据合成面临的挑战是怎么定义合成数据的质量标准。业内目前已有一些探索，比如智源的 Infinity Instruct 会从深度和广度等维度考虑合成数据的效果，并选择模型薄弱领域进行数据合成。

另外扩展新来源的方法还有扩充不同模态数据的收集，现在已经有像 LAION 这样收集了 50 多亿张图片的数据集，视频数据规模也在快速增长。

需要注意的是，合成数据的问题需要根据不同的领域分别考虑。文本领域，合成数据

对模型的影响相对较小，但在图像和视频领域会比较明显。

在进行通用的视觉问答任务时，很难找到非常好的图文绑定数据对时可以依赖一些生成数据进行多模态模型的预训练是可行的。但在视频生成领域，鉴于当前生成的视频本身就存在瑕疵，因此目前使用合成数据并不合适。

目前为止，高价值的真实数据仍发挥着重要，甚至主要的作用。在 2025 年，数据的重要方向发展将逐渐从数量转向质量。

多模态模型崛起

毋庸置疑，多模态模型是今年快速崛起的一年，也是很多人持续看好的方向。

多模态模型与大语言模型的主要区别在于，多模态模型增加了视觉模态的编码。然而，通常情况下，视觉模态的编码部分并不进行训练，因此从模型参数的角度来看，多模态模型并没有增加太多，但多模态模型对误差的容忍度更低。

两者生成过程和理解过程使用的框架不同：理解过程通常基于自回归框架和大语言模型的框架，而生成过程则涉及到 DiT（Diffusion Transformer）框架和扩散模型框架。多模态理解与生成相辅相成。多模态模型在理解层面并不会比大语言模型消耗更多的算力，主要算力消耗在生成层。

目前，多模态理解还有很大的提升空间，包括对空间位置的理解、推理维度等。当前，多模态模型对现实世界常识知识的对齐粒度还不够细腻，比如知道是花但不清楚是什么品种。

多模态模型的推理优化也日益重要，因为这直接影响到成本控制。目前视频生成的成本非常高，通常是按分钟计算的，万卡集群在多模态里也只能做到 30%-40%的算力利用率，因此推理方面有大量的优化工作可做。

多模态模型结构非常复杂，还在快速持续创新和演进中，另外针对多模态模型的评测体系也急需搭建。

Sora 发布之后，DiT 就成为了全年的主旋律。尽管在具体实施过程中可能会有一些创新，比如 SD3 提出的 Multi-Model DiT（mm-DiT）框架、Flux 在 mm-DiT 框架基础上的改进，但总体上今年架构算法的核心主要围绕着 DiT 展开。

这并不意味着多模态的技术路线开始收敛：Diffusion 还是 Auto-regressive、统一架构还是分体架构等都没有统一答案，大家还在沿着不同的方向探索。专家认为，技术路线的收敛与是否有较好的落地应用来体现出某种技术路线的优势有关，比如 ChatGPT 将技术路线慢慢收敛到了 GPT 上。

接下来，图像生成与视频生成的基础算法框架会逐渐实现和谐且鲁棒的统一。尽管 DiT 展现出了统一视频生成和图像生成的能力，但是一个通用模型同时在两个子问题上的生成效果均达到行业 SOTA（图像生成效果超 Midjourney V6，视频生成效果超 Sora）还有一定的技术挑战。

视觉生成模型的主要难点在于可控性，这也将成为 2025 年的主旋律。可控性包括输出效果、身份、风格、安全性和文本相关性的可控。

来源：阿里云高级算法专家谢榛在 AICon 上的演讲 PPT

图像生成模型在下半年虽然热度有所下降，但该领域的技术发展仍然十分迅速。例如，“Recraft.ai”公司开发的、引起广泛关注的小熊猫“red_panda”表现非常出色。Stability 公司的研究员们离开后成立了黑森林公司并发布了 Flux 模型，Flux 在开源和闭源领域中都处于领先水平，其将参数量从 3B 提升到了 10B 和 12B，并对整体模型结构进行了多方面升级，重要的是也引入了 DiT 框架，之前的 SDXL 和 SD 1.5 都是基于 Unit 框架构建的。另外，快手、字节等公司也在文生图方面加大了投入力度，而像‌Midjourney 没有像大家想的那样推出视频生成模型，仍然专注于图像领域。

在 Sora 火了后，国内对文生视频的态度最先比较谨慎，对文生视频模型的跟进并没有预期的快速，最大的考量还是投入和收益问题。典型的如百度李彦宏在 10 月底仍然表态不做 Sora，理由是视频生成模型投入周期太长，10 年、20 年都可能拿不到业务收益，“无论多火爆，百度都不去做。”但国内其他厂家已经逐渐跟进，包括快手的可灵、生数科技 Vidu、MiniMax 海螺视频、爱诗科技 PixVerse、字节即梦、阿里通义万相等。但整体上，国内玩家不如国外玩家多。

多模态融合，大势所驱

omni 肯定是重要的，非 Omni model 会有长期的价值。未来，多模态模型更加 omni、更加融合是业内不少专家的判断。也就是说，明年多模态模型的发展趋势很可能朝着类似“Any-to-Any”的模式迈进，即能够接受图文、视频、音频等多种模态的输入，并且能够输出图文、视频、音频等多种模态的内容。这种趋势被认为是未来重要的发展方向。

当前，尽管模型还未能完全实现“Any-to-Any”的能力，但在输入端的“Any”基本上已经实现，接下来的发展重点将是逐步攻克输出端的“Any”。不过，这类“融合”模型可能会先由几家 top 厂商推出，创业公司及应用类公司跟进较难，因为其技术难点更多、挑战更大，对数据、算法的要求也更高。

有人猜测 GPT-5 可能会具备多模态融合的能力，迟迟未发布可能是因为效果不够理想。为了实现这一目标，可能需要一些额外的辅助工具或插件。例如，希望模型能够直接以自回归的方式输出图像和视频可能比较困难，然而模型可以输出一个中间特征，然后结合 DiT 等技术来生成图像。

成本，还是成本

大模型厂商：推理加速

推理侧主要依靠模型并行和模型蒸馏等技术来实现更高的效率。业内常用的优化推理方法包括 Prefix caching、PD 分离、Continuous Batching、量化压缩、投机解码等，不同模型会有不同的侧重，但思路较为相似。

推理加速的本质在于解决制约性能的三要素：显存、算力和带宽。为提升机器利用率，业内做了很多并行算法研究，包括 DP 数据并行、CP context 并行、Window Attention、TP 张量并行等。

加速算法方面，除了 Gpipe、1F1B、PTD 并行、Sequence Parallel 并行、Virtual Pipeline 并行、Expert Parallel 并行、分布式优化器(ZeRO-1)、计算通信并行、超长序列优化等已在使用的算法外，业内也在加深对内存深度优化、MoE 负载均衡、自动并行等的研究。

大模型降本方面也取得了不错成果。典型如 DeepSeek-V3，采用 FP8 混合精度训练框架，首次在超大规模模型上验证了 FP8 训练的可行性和效果，在保证模型计算精度的前提下大幅减少了内存使用和计算成本。DeepSeek 实施了数十项优化技术来降低其 DeepSeek-V3 的计算需求，并通过算法、框架和硬件的综合优化，实现计算与通信的高度重叠，此外还对 GPU 集群进行了优化。但是具体实践上，大家还不能清晰地了解细节。

另外，还有像极佳科技透露的其在过去一年训练一个视觉大模型的成本，从 500 万美金下降到了 100 万美金以下。

应用侧：大小模型协同

AI 已经足够成为企业的重要驱动力，这意味着企业流程数据、软件架构等都需要围绕 AI 和大模型进行重构。

随着时间的推移，大模型的局限性逐渐显现，如高昂的计算成本、资源消耗以及对硬件的严苛要求等，在此背景下小模型逐渐进入大家视野，通过蒸馏压缩和参数共享等方式，将模型参数大幅缩小的同时保留大部分性能。

对模型能力要求不是那么高的场景，可以使用大小模型协同的方式。在性能和成本之间做取舍是不可避免的。小模型成本低但效果会打些折扣，但大小模型混合使用就能得到可接受的性能，同时成本下降比较明显，像 Apple Intelligence 就是采用了大小模型相结合的方式。

同时，人们也为小模型找到了合适的应用场景：端侧。端上算力和内存受限，这让端侧模型被大厂视为是相对专门化、特别产品化的工作。在这个领域，国内大厂几乎不再涉足，市场基本留给了大模型创业公司、手机厂商。相对专门化的模型，用户自己可能比大厂做得更好，而大厂则主要通过提供底层基础设施的方式参与。

另外，业内整体模型的部署运维的效率并不高，像应用侧企业在前期在要效果和要效率之间，优先选择效果，虽然也未真正找到最佳的大模型应用范式。但在明年，部分企业将开始重点投入到运维效率上。

大模型开源之争

今年，开源与闭源成为大模型一个重要的分类维度。开源的代表有 Meta、阿里等，闭源的代表则有 OpenAI、百度等。

大模型的开源怎么定义是国内外都比较关注的问题。Linux Foundation 提出了 MOF 的模型开放性框架，其中 Class I 是“最开源”的，包括所有数据、代码、技术细节、技术报告、数据处理流程等等。而现在大部分的模型其实都只是放了一个权重，同时还有很多使用的限制。因此，大家会对 Llama 开源产生争议，有人就说它不是真正的开源。

业内认为，大模型开源的开源应该包括：第一，数据，就像 Red Pajama、FineWeb 等预训练数据集，文本指令数据集等；第二，模型权重，License 协议和权重模型训练相关的配套代码、技术报告等；第三，训练、推理模型的底层框架，如 DeepSpeed 和 Megatron 等；第四，评测方式，即对大模型进行测评。这样的榜单有智源的 FlagEval，上海 AI 实验室推出 OpenCompass 开放评测体系等，但模型能力提升很快，这些评测体系中的评测数据集很快就会出现饱和的情况，需要对评测方法不断优化迭代。

当前的大模型一般都是模型权重开源，其他维度开源的并不多。比如腾讯混元模型开源了模型权重，但不涉及数据和代码的开源。对于数据是否应该开源，业内并没有统一。支持的人认为，很多大模型的预训练数据来源于 Common Crawl 等开源数据集，如果数据开源不重要，那为什么要用开源数据集？反对的人则认为，开源数据规模太大，本身很难被大家共建和维护，因此大家作为受益者是比较容易的。

如今，闭源模型被认为会用在大企业业务复杂的场景，相对应的成本会更大，而开源则更多面向不同的开发者，尤其是中小企业、个人开发者，规模也会相对小一些。据了解，生成类开源模型在一定程度上是能够满足企业应用的，比如开源 SD 系列解决了大部分设计、广告等基本场景需求。

RAG：不会过时，但也“爆”不了

2024 年，RAG 领域取得了相当多的进展，从最初的基础版 Naive RAG，到进阶版 Advance RAG，再到 Model RAG，以及 Graph RAG 和多模态 RAG 等，相关论文的发表数量也在不断增加。

“RAG 早已超越简单向量检索+大模型生成的模式。知识图谱与检索机制相结合，GraphRAG 在工业应用场景开始实践；Agent 技术引入到 RAG，不再局限于解答简单问题，理解深层次语义的复杂问题解答能力显著提升；端到端优化成为新的方向，检索模块和生成模块共同优化，端到端联合训练，进一步提升整体效果；RAG 不再限于文本，开始融合图像、音频、视频等多种形态数据，多模态 RAG 技术正在工业界迅速发展并应用于各个领域。“阿里巴巴技术总监郭瑞杰称。

vivo 互联网产品平台架构团队负责人张硕表示，“这些技术的核心思想大致相同，主要区别在于各种优化技术、策略的运用，正是通过这些优化，RAG 技术逐渐成熟、稳定，并逐步解决了各类应用问题，可以说进展显著。”据郭瑞杰介绍，在应用层面，随着 RAG 准确性的持续提升，满足越来越多工业场景的业务需求，除了在典型的企业知识管理和智能客服等领域外，其越来越广泛应用在辅助创作、辅助教育、辅助医疗、工业智能等诸多领域，效果和效率都有显著提升。

“这一年来，RAG 在各行各业的落地，核心解决的问题仍然在效果的提升上。”郭瑞杰指出，检索机制在大模型的驱动下全面增强，数据内容的处理更加精细，向量检索的精度和效率更高，排序模型效果提升显著，查询理解方法更是层出不穷，生成内容的准确率、相关性和连贯性大幅提升。

处理复杂问题“差强人意”

然而，不可否认的是，RAG 在当前的实际应用中仍存在诸多挑战。

据郭瑞杰介绍，RAG 技术面临的这三方面关键问题不容忽视：

其一，真实场景数据的来源、存储的形式、数据的形态等各异，数据之间往往还存在非常复杂的关系，数据也会实时发生变化。如何将繁杂的数据进行高效实时处理形成高质量的 RAG 输入数据，没有统一的范式，而这又是决定 RAG 最终效果的关键前提。其二， RAG 的泛化性或者说领域适应性并不好，在很多特定专业领域（比如医学、法律等），仍然需要大量特定领域的高质量数据进行训练或微调，才能提升在这些专业领域下的表现。其三，尽管基础大模型的能力在过去的一年有了大幅度的提升，但复杂推理能力或者说“慢思考”能力仍然存在不足，对于需要深层里理解语义或者需要多步深度推理的才能回答的复杂问题处理不理想，存在一定程度的幻觉。

张硕则列举了以下两个具体的例子：当 RAG 面临解决复杂问答的问题，如比较一个企业近两年的盈利能力，这可能需要基于语义检索，并通过一系列的处理流程，包括召回、排序、重排等操作，但目前这些方法还无法很好地解决问题。此外，对于口语化和模糊的查询，尽管通常会通过改写查询和 RAG Fusion 等方法来处理，但其效果差强人意。

“目前虽然有许多开源的 RAG 资源，但整体都是一个框架或初步形态，想要将它们真正转化为面向生产、工业级的应用，还需要投入大量的精力和时间。”张硕表示。

今年多模态 RAG 能“爆”吗？

“2025 年很有可能是多模态 RAG 的爆发年。”在郭瑞杰看来，多模态 RAG 可以从多种类型数据源中检索信息，并生成内容更加丰富和准确的响应，更贴近人类与真实世界的交互，在医疗诊断辅助、教育与学习辅导、个性化商品推荐、内容创作、增强现实和虚拟现实等领域展现出巨大的应用潜力。随着多模态大模型能力的进一步提升，多模态 RAG 更多的实际应用案例将涌现。

张硕则认为，在 RAG 实现多模态处理方面，目前国内还存在一些瓶颈。“因为我们在多模态模型上测试的效果并不是很好。未来的 RAG 可能需要区分文本、图片、视频等不同模态，直接与多模态内容结合，这方面还有很大的发展空间。“

据张硕透露，一些头部的主流模型并不是多模态的，它们本质上是 LLM+视觉能力。一些视觉模型与多模态模型之间也存在差异，例如这些模型可能只能处理文字或者只能处理图片，而不能同时处理文字和图片，且明显区分对待这两种信息介质。“我们大部分模型是纯粹的视觉模型，你给它一张图片，它将图片解释成文字。这种模型在实际应用上还需要进一步加强。”

郭瑞杰表示，随着基础大模型能力的不断增强，通过多维度的技术创新与优化，RAG 将进一步提升在各类应用场景中的实用性。RAG 在未来的发展，将朝着更智能、更高效、更多样化的方向演进。

RAG 会过时吗？

2024 年，伴随着基础大模型能力和智能体工作流的突破性提升与进步，许多人都感叹道： RAG 或许要过时了。对此，我们采访的几位专家都持有否定意见。

首先，针对“ RAG 要被长文本能力替代”的言论，两位受访专家把立场集中在了大模型对于长文本的处理效果和应用成本方面。

郭瑞杰表示，基模支持更长的上下文，有利于 RAG 效果的提升，但在大部分场景下无法替代，并给出以下三个具体原因：

1、通过一些实验测试验证，即使把文档内容全部扔给大模型，相比 RAG 的方式，解答问题不一定更准确，大部分情况下可能是更差的；

2、大部分真实场景，数据都比较复杂，数据规模也较大，数据异构，无法仅通过利用大模型的长上下文来解答复杂问题；

3、长上下文相比 RAG，推理成本高得多。其实 RAG 和长上下文并不矛盾。基模的长上下文能力，可以给 RAG 更大的发挥空间，组织更丰富连贯的上下文信息，从而提升 RAG 效果。相反，RAG 技术也可以用来实现扩展基模的上下文长度，降低长上下文的推理成本。

张硕也认为，目前来说，大模型长文本能力完全替代 RAG 的可能性不大。其指出，当 token 数量增加时，模型对信息的提取能力会减弱，needle in a haystack 的“大海捞针”能力，同时对性能的要求也会提高。也就是说，尽管许多模型的 token 上限增长显著，但它们 token 越大使用，效果可能会出现明显下降，不如那些短 token 模型的效果。如果完全依赖长 token 模型而不使用 RAG，也基本上是不可行的。

“我们最近正在研究市面上支持长 token 的模型，比如那些声称支持兆级别 token 的模型，我们正在测试达到多少 token 时，性能和准确性能够取得平衡。如果完全按照它们理论上的 token 上限来替代 RAG 使用，效果将会非常糟糕。”

张硕表示，未来随着模型 token 上限的增长，RAG 领域将产生进一步的创新和发展，可能会否定之前的一些方案，并结合新的模型能力发展出新的方案，将有更多的优秀技术和主流解决方案取代目前百家争鸣的探索式发展阶段，使得主流方案更加成熟。

而对于“ RAG 正在被 Agent 所覆盖”的说法，张硕谨慎地指出，逐渐被 Agent 所替代的可能是 RAG 的概念，未来 Agent 的概念会被更多关注、发展、应用。“我们需要从用户体验的角度来看待完整的能力，仅靠 RAG 可能无法构成一个成熟的产品或解决方案。”

他进一步解释道， Agent 是一个更大、更宽的概念，它包括了 Memory、Tool 和 Planning 等多个模块；而 RAG 在 Agent 的框架下，更算是一个工具。这两者之间不存在所谓的覆盖关系，而是一种包含关系。打个比方，就像一个人有一只手，我们不能说这只手被一个人所覆盖，而应该说人的概念中包含了手。从行业概念上来说，RAG 应该是 Agent 的一个工具，用来解决大模型私域知识相关的问题。

就目前企业在实践过程中的使用情况而言，郭瑞杰表示，RAG 和 Agent 往往相互结合。一种是 RAG 中使用 Agent 做响应优化，与传统 RAG 不同，基于 Agent 的 RAG 具备一定的主动性和决策能力，能根据上下文和目标选择合适的数据来源，主动检索信息、动态调整和优化检索和生成策略，还能在多轮对话中规划下一步动作，如进一步询问用户的需求或执行特定任务，这种方法也叫 Agentic RAG。另一种是 Agent 中使用 RAG，由于 RAG 能够访问广泛的知识库、提供更具深度和广度的回答，而不仅仅依赖于生成模型的内在知识，Agent 可以通过 RAG 处理更复杂和专业的问题。

被“神化”的 Agent：不搞技术“革新”却对人下手了

今年被视为 Agent 应用的元年，微软、谷歌、百度等众多科技大厂都在全面发力 AI Agent，许多受访专家也都称 Agent 是“最值得关注的技术方向”。而经过一年来的应用和落地，Agent 首先给整个 ToB 软件行业带来不少显著的积极影响。

“这无疑是一种新的应用，它能够为现状带来改变，并且帮助软件企业实现转型。”澜码科技 CEO 周健表示，在美国硅谷，许多大型软件公司因为拥有数据、人才和场景，已经成功落地了许多项目，例如 Salesforce、ServiceNow 和 SAP 等大厂，它们的财务数据也因此得到了提振。

数势科技 AI 负责人李飞也称，Agent 技术为软件生态系统注入了新的活力与成长机会，促进了软件领域内持续的技术革新与发展。其具备的自我学习、自主决策及执行能力，激发了开发者和企业在探索新应用领域和商业模型方面的积极性，从而促使整个软件生态环境不断进化和完善。“我们的 Agent 不仅限于作为一个独立的产品存在，它更是未来构建智能化平台不可或缺的基础组成部分。作为不同软件平台与应用程序之间的纽带，Agent 能够有效地整合各种数据源，从而促进整个生态系统内信息的顺畅流通。“

但据周健透露，Agent 在国内和美国的发展情况有很大不同。“据我所知，在中国管理类软件领域，几乎没有公司能够做到类似的成就。很多公司可能只是增加了一个聊天界面，但实际上并没有将 AI 技术广泛应用起来。相反，在一些垂直领域，如跨境贸易类公司，它们实际上已经开始应用 AI 技术。目前的趋势是聚焦于特定场景的 AI 技术真正发挥了作用，特别是在客服领域，我们已经听到了很多关于技术落地的声音。”

智能体并非无所不能

谈到 Agent 这一年的落地实践，受访专家们主动分享了许多他们在实际应用过程中产生的经验和教训。

“即使是 AI 公司出身的从业者一开始也可能会犯这个错误，可能会冒进，认为大模型无所不能。”周健表示，在 Agent 落地时，不仅要处理常规情况，还要处理各种异常情况。因此，需要先梳理所需的知识，再对所用模型的能力以及我们希望 Agent 适用的场景的通用性做出规范和考量。Agent 从构建出来到真正在适用场景中发挥实际业务价值，还有很长的路要走。

“智能体也并非无所不能。”李飞进一步提到，大模型定义了应用程序的基础性能，而智能体则决定了其上限潜力。在实际应用过程中，许多用户对于智能体的能力存在一定误解。

一种常见的误区是认为智能体能够解决所有问题，然而实践表明，当基础的大规模语言模型本身存在缺陷时（如产生“幻觉”错误），这些限制同样会影响到智能体的表现，使之无法完全克服这些问题。还有一部分观点将智能体与工作流等同视之，但实际上二者之间存在着显著的架构差异：工作流主要依靠预先设定好的代码路径来调用大规模语言模型及其相关工具；相比之下，智能体则是通过动态地自我指导流程、选择合适的工具，并控制任务完成方式来发挥作用。另外，有些人简单地把智能体归类为自动化软件，忽略了它所具备的自主性、反应能力、主动性以及社交互动能力等独特特性，这使得智能体能够在复杂的环境中独立做出决策并与其他系统或人类进行有效沟通，从而与传统意义上的自动化解决方案形成了鲜明对比。

正如周健所说，“关于‘Agent’这个词，有点被大家泛化了。”现在变成了一个代名词，大家不清楚它具体指什么。原本的 Agent 指的是能够主动代表人观测环境、做出规划并采取行动以完成任务的实体。在大模型技术流行之前，这个词在专业领域，尤其是在学术界使用得较多。但现在，人们使用这个词时，更像是在指代大模型应用或智能应用，即在大模型技术出现后，软件开发的方式如何变化以及软件在哪些部分变得更加智能。

为此，周健特别指出，大模型是一种基础设施。“以电力为例，不同瓦数的电灯泡或发电机，其能力显然不同。同样，利用大模型的应用也有其适用范围，如针对特定数据集的应用。以简历筛选为例，我们不能仅仅通过提示词构建一个 Agent，就期望其能处理行业内所有的简历，它一定是有限制范围的。如果我们使用一个较小的模型并针对其数据集进行调整，可能只能处理类似’应届生‘这类简单、规范性较强的简历需求’；如果我们想要处理更复杂、更丰富的简历，就需要更强大的模型和更多的知识和数据。”

李飞则更具体地概括了三点构建 Agent 的策略：首先，构建 Agent 过程中的首要任务是精心挑选合适的大模型。模型的质量、效率及其数据覆盖范围直接影响到 Agent 的整体表现，在设计阶段选取性能最优、运行效率高的大模型对于增强 Agent 的准确性至关重要。其次，实践经验显示，采用简洁易组合的设计模式往往比依赖复杂框架或特定库更加有效，Anthropic 的研究案例证明了这一点。另外，针对较为复杂的任务执行过程，通过采取诸如提示链、路由机制、并行处理策略、Orchestrator-workers 架构以及 Evaluator-optimizer 循环等方法，可以有效地将整体任务拆解为一系列更易于管理的小步骤或子任务，从而在提升任务完成的速度的同时保证结果的精确度。

并且，李飞针对 Agent 构建过程中可能遇到的三种不利情形提供了相应的处理建议。第一，应尽量减少对模型微调的过度依赖。虽然通过微调可以让智能体在某些特定任务上展现出更专业的性能，但这可能会削弱其独立解决问题的能力，它可能更多地依赖于训练过程中遇到的具体案例而非进行广泛适用的推理。第二，在设计系统时，直接控制每一次与模型交互的数据流比使用如 LangChain 和 LlamaIndex 等抽象层更加有利，因为后者可能导致在用户引导、故障排除、扩展服务范围、记录操作日志或更新版本等环节遭遇障碍。第三，在赋予代理较高自主权的同时也增加了潜在风险及错误复杂性，建议在隔离环境中进行全面测试，并采取必要的安全措施。

Agent 最终替代 RPA 不可避免？

Agent 发展至今，是否真的能够取代传统的 RPA？这个问题伴随着 Agent 技术的落地与进步不断被提起，我们采访的技术专家们对此持有各自不同的看法。

传统的 RPA 主要解决的是键盘和鼠标操作的问题，而 Agent 目前的能力主要集中在处理各种文本数据上。周健表示，在这种情况下，RPA 更像是“手”，大模型更像是“大脑”，而 Agent 是“神经中枢”，调动手和脚去完成大脑分配的任务。Agent 可以与 RPA 协同工作，如 Agent 可以利用 RPA 去操作系统。RPA 本身无法理解从系统中收集的数据以及填写进去的数据，而大模型则能够理解这些数据。

李飞则认为，从当前的发展趋势来看，Agent 最终替代 RPA 似乎是不可避免的，但在现阶段尚难实现。在他看来，两者之间最显著的区别在于，Agent 能够利用大型模型的推理能力来灵活地安排工作流程，并且具备对结果进行自我评估的能力，RPA 则需依赖于预设的业务规则来构建其工作流。但对于较为复杂的业务环境而言，大型模型在任务编排方面的能力仍有待加强，尤其是在处理较长的任务链时，出错率会随之增加。此时，采用 RPA 技术将固定业务流程通过明确规则的形式固化下来显得尤为重要。

“传统 RPA 系统在执行高度结构化、规则清晰且变动较小的重复性任务方面表现突出，如大量数据录入或生成固定格式报表等场景。这些类型的工作并不需要复杂的人工智能决策机制或学习功能，RPA 能够以高效稳定的方式完成，而如果使用 Agent，则可能造成资源浪费和性能过剩的问题。因此，在寻找适合 Agent 应用的具体案例时，应优先考虑那些流程相对简单且变化较多的情境，以此来提高其实用价值。”

此外，周健提到，在商业化角度上，国内在 ToC 端的 Agent 应用上还存在一个问题，即需要行业审核和大模型应用备案，这也使得整个进程变慢，目前只在营销类 SaaS 领域的应用上看到了一些进展。李飞也表示，现在国内在 Agent 的商业应用方面仍处于初步发展阶段，应用场景主要集中在少数大型企业和特定行业内，而中小企业中的普及程度相对较低，这意味着该领域还存在巨大的未开发潜力。

这也是国内外在 Agent 领域存在的差距之一。周健指出，“相比之下，国外有很多成熟的生态系统，包括 SaaS 平台，它们自身拥有大量数据和客户，因此能够在自己的 SaaS 平台上进行快速迭代。”李飞也提到，国际市场上产品和服务的形式更加丰富多元，除提供基础代理平台和工具外，还针对特定行业及客户需求开发了个性化解决方案。国内现阶段主要集中在基于本土大规模模型构建的通用代理平台及特定行业解决方案上，在提供个性化服务方面的能力与经验尚显不足，尤其是在应对企业多样化且复杂的业务需求时。

除此之外，周健表示，“技术层面上，国内在这一领域面临的最大问题在于无法使用 OpenAI 等国外企业的模型。由于国内客户群体中有很大部分需要私有化部署，因此只能选择使用国内模型公司提供的模型或开源模型，这些模型可能在技术水平上落后了一年到一年半的时间。另一种是出于算力成本的考虑，可能会选择使用国内的开源模型。”

或将岗位取代到只剩 CEO？

“2025 年将会是 Agent 应用的元年”，这已经是许多受访专家的共识。而对于 Agent 未来更具体的发展走向，周健指出，“届时预计会有大量看似智能的应用出现。目前看来，垂直发展肯定是 Agent 更大的机会所在。”

据周健称，Agent 对于进入特定行业并利用行业数据发挥更大效能是非常重要的，横向发展基本上只能由大厂来完成。简单举例来说，无论是金山办公还是百度文库都已经具备了简历生成的能力，但如果有一个为大模型研发工程师服务的猎头专门为该岗位做 Agent 的话，一定能够帮助候选人更好地生成简历，其价值将远远超过金山办公和百度文库仅提供通用简历生成服务的效果。这里的重点在于，这位专家拥有一些私域数据，且会根据某种做法改写简历并得到数据反馈，如公司是否采纳了简历，整个过程中的数据闭环和专家知识的积累对于 Agent 的成功非常关键。

关于 Agent 取代第三方应用的可能性，周健和李飞都认为“短期内不会发生太多变化”。周健称，“现有软件更多涉及信息流存储和工作流引擎的协作。Agent 本身更像是角色替代，主要在控制流和业务流上针对单个岗位和单个技能进行替代。因此，它们的方向和发展路径是不同的。不过，未来如果出现针对特定岗位或职能的入口型应用，那么大厂的 Agent 可能会有替代的可能性。李飞则表示，“两者之间存在着一定的互补关系：应用程序在某些具体功能或使用场景下仍然拥有独特优势；以旅游为例，游客既可以通过专门的应用来预订机票酒店等服务，也可以利用智能助手来进行行程规划或者获取旅行建议。”

“在未来一两年内，Agent 最核心需要解决的问题是信任问题。”周健指出， Agent 的原始定义是能够自主行动，但大家现在对大模型的印象是存在幻觉问题。因此，将关键业务任务交给 Agent 完成时，无论是一线员工、业务领导还是公司老板，都会出现信任问题。虽然这可能只是过渡阶段，但在未来一两年内，大家需要在产品和技术上看到一些突破，这样 Agent 才能进入下一个发展阶段。

“下个阶段行业必须解决的问题将变成安全问题，还可能涉及伦理和管理问题。”周健进一步表示，当 Agent 足够智能时，如果在业务上让 Agent 执行任务，那么谁来负责？奖惩和法律风险怎么办？这就如同自动驾驶的最终上路实际上是法律问题：发生事故该如何定责？但在没有克服信任问题之前，这些都是杞人忧天。

此外，随着 AI Agent 的日益强大，未来的企业组织结构和员工角色可能会受到影响。正如李飞所说，“如果生产力提升了百倍，生产关系将发生根本性变化。虽然现在的大模型和 AI 还未达到这种提升幅度，但它们正朝着这个方向发展。”

京东技术专家王译堃认为，某些职位可能会被高效、低成本的大模型取代，但也会有新部门或新角色出现。人力并不会越来越少，而是从数量向质量转化的过程。也就是说，工作方式可能会优化，但人数不会大幅减少。“管理者的比例可能会随之上升，因为很多一线工作可以由智能体完成。这意味着产品经理和技术管理者将变得更加重要，更多地承担设计和协调的角色。未来，智能体可能发展到足够成熟，以至于公司只需一个 CEO，其他职位都由智能体担任。”小米大模型负责人栾剑则提到。

前端：无显著革新，鸿蒙操作系统成行业新亮点

2024 年，大前端领域并未出现显著的技术革新。除了鸿蒙操作系统这种独立生态的推动，其他热点较少，就连去年发布的 Apple Vision Pro 也或已于年底停产。

这一年，大前端领域的发展受到了多重因素的影响，呈现出创新乏力、前端地位弱化、关注点下沉等特点。

多数企业已将前端团队划归业务部门，目标从技术创新转向业务驱动。现在，许多跨端框架与前端的关系并不十分紧密。虽然它们可能会借助前端生态来降低开发成本，但实际上与前端本身的关联性并不强。因此，今年纯前端领域的地位有所弱化。

与此同时，许多公司逐步转向由客户端主导的开发模式。客户端开发，尤其是面向操作系统的开发，因其能充分利用硬件资源，在 AI 等领域展现出优势，逐渐成为主流。比如在 AI 场景中，对于前端来说，在操作系统的环境里去运行 AI，比浏览器更容易，因为操作系统能够充分利用完备的硬件资源支持计算任务。

“大前端”融合了前端和客户端，从技术层面看，一部分面向 Web 浏览器的，另一是面向操作系统的。这两者在技术栈上有一些不一样。Web 开发受限于浏览器的发展，创新空间相对较小。相对而言，行业对操作系统的发展关注度更高，因为操作系统的发展对上层应用的创新起着决定性作用。如果底层技术没有发生实质性进步，那么上层应用即便频繁更迭，仍然难以摆脱“换汤不换药”的局面。

但今年也有两个不得不提的亮点。

浏览器生成式 AI 的崛起 

目前，大多数基于大模型的 AIGC 应用都采用了 Web 端接入的方式。无论是文本生成的 ChatGPT、Bing，还是图像生成的 Midjourney、Stable Diffusion，抑或是视频生成的 Make-A-Video，都通过网页提供服务。国内外各大科技公司和研究机构推出的 AI 模型，如微软的 Bing、百度的文心一言、阿里的通义千问、复旦大学的 MOSS 等，也无一例外地选择了 Web 端作为主要的用户交互界面。

随着 AIGC 热潮带来的 Web 复兴以及巨头的布局，浏览器内置 AI 正迎来蓬勃发展。

Google Chrome 和 Microsoft Edge 分别基于 Gemini Nano 和 Phi-3 Mini 模型，将 AI 能力无缝整合到浏览器中。用户只需通过简单的自然语言指令，即可实现文本摘要、情感分析、视频实时字幕生成、标签智能管理、写作辅助以及产品评论解读等多样化功能。 虽然单一模型同时处理如此广泛的任务仍面临着质量优化的挑战，但在特定场景下（如语言翻译）已展现出令人瞩目的表现。截至 2024 年底，这些内置 AI 功能大多仍处于本地原型阶段，开发团队正在持续完善和优化，以期为用户带来更卓越的智能体验。 

Web AI 端侧推理通过直接在浏览器中运行，为用户带来了便利和实用性。依托 WebAssembly、WebGPU 和 WebNN 等 Web 技术栈，用户无需安装任何依赖，只需打开浏览器即可使用。其跨平台兼容性让不同设备间的使用更加流畅，同时计算过程完全在本地完成，有效保护了用户隐私，无需将敏感数据上传至云端。此外，随着 AI 应用在 PC 用户中的普及，Web AI 能充分利用设备的 CPU、GPU 和 NPU 等硬件资源，为用户提供更高效的智能化体验。

这一年，Web AI 端侧推理技术也迎来重大突破。据英特尔高级工程师付俊伟介绍，微软的 ONNX Runtime Web 框架持续创新，其中英特尔重点打造的 WebGPU Execution Provider 已实现对 Llama、Qwen、Phi 等新一代大语言模型的快速适配与优化支持。同时，Huggingface 发布的 Transformers.js v3 版本已完成 WebGPU 的集成，支持模型数量已突破 1200 个，展现出 WebGPU 在 Web AI 领域的强大的扩展性。 由英特尔、微软和 Google 联手推动的 Web Neural Network（WebNN）API 在今年上半年发布了开发者预览版，涵盖了从图像分类、分割、对象检测等传统模型到基于 Transformers 的 Stable Diffusion 以及 Whisper 语音识别等多个应用场景。值得一提的是，随着 AI PC 浪潮席卷全球，WebNN API 已率先将 NPU 加速能力引入 Web 端测推理，为客户端 AI 应用带来性能提升并显著降低设备功耗。 

跨端开发再热：大前端发展的新变量

鸿蒙系统的推出使跨端开发需求再次被关注，曹立成指出这是今年的一大变数。

跨端开发由来已久，初衷是通过统一的代码框架实现多端运行，经过多年实践，跨端方案虽然能够实现多平台的功能覆盖，但其整体效率提升却有限。主要原因在于，跨端开发仍需额外的工作来弥补各平台之间的差异。例如，要实现一个网页调用摄像头的功能，不同平台（如安卓和 iOS）有各自的实现方式，仍需要原生工程师进行支持并封装 API 供调用。因此，跨端方案虽然看似减少了表面上的开发工作，实质上只是将一部分复杂度转移到平台差异的抹平上。

此外，许多跨端引擎（如 Flutter）表面上提供了便捷性，但在实际应用中带来了诸多问题。例如，包体积的增加、稳定性问题，以及用户崩溃率的上升等，这些问题往往难以修复，且需要大量人力去排查和解决。长期来看，跨端方案用多了反而导致了用户体验的下降，特别是在苹果生态系统中，由于 iOS 系统的封闭性，许多跨端框架在 iOS 平台上的表现不尽如人意，与原生 iOS 应用所提供的优质用户体验形成了鲜明对比。所以这两年各大公司尤其是头部应用，都会把这些慢慢地去掉下线，转而回归原生开发和 H5（面向浏览器）的组合模式。以拼多多为例，其绝大部分页面采用原生实现，它的体验就很好。近年来，跨端开发的热度有所下降，过去一年内这一领域也未见显著突破。

然而，跨端重新受到关注，其最大的推动因素正是鸿蒙系统的加入。2024 年 10 月，HarmonyOS NEXT（纯血鸿蒙）正式发布，意味着许多应用需要进行鸿蒙适配。而对于已经迭代十余年的头部应用来说，短短几个月全部重写一遍根本就不可能。因此，跨端被视为一种减少开发成本的折中方案，核心目标是通过跨端技术复用部分代码，从而降低开发量。

自 React Native (RN) 版本 0.72.5 开始，鸿蒙系统获得了初步的支持。然而，这种支持并非由 RN 官方实现，而是由华为开发者基于 RN 官方某一版本拉取分支实现的。类似的情况也出现在 Flutter 社区，鸿蒙的支持也是由国内开发者拉取分支完成的，而非 Flutter 官方提供的支持。

这种分支模式的主要问题在于，开源社区会持续对主干版本进行迭代，而分支版本很难快速跟进主干的更新进度。这就导致了生态的不统一。尤其是在性能方面，无论是 RN 还是 Flutter，在鸿蒙系统上的表现都较为一般，与使用 C++ 或原生 ArkUI (RTS) 实现的应用相比，用户体验差距较大。这种性能瓶颈使得 RN 和 Flutter 在鸿蒙平台上只能满足基本需求，但难以提供优质体验。

这促使许多公司转向使用 C++ 开发基础库，C++ 的性能优越，且其代码可在安卓、iOS 和鸿蒙系统上运行，从而提供了一种更统一的跨端解决方案。C++ 对开发人员的要求较高，包括对内存管理的精细操作等，显著提升了技术门槛。因此，对于性能要求高的业务场景，例如需要高流畅度的核心用户路径，C++ 更为适合。对于某些对性能要求不高的业务场景，例如工具类应用或非核心用户路径的功能模块，可以考虑采用跨端方案来节省开发人力和时间成本。

另外，Taro 作为京东开发的一款前端框架，其对鸿蒙系统的支持是由官方提供的。Taro 的核心架构基于 AST（抽象语法树），通过解析上层 DSL（领域特定语言）的声明，将其转译为不同平台的代码版本。例如，Taro 可以转译为 RN 的代码、微信小程序的代码，或者其他平台的代码。在鸿蒙系统上，Taro 的实现方式是将其 JS 代码转译为鸿蒙系统支持的 RTS（ArkUI）代码。

尽管 Taro 官方对鸿蒙提供了维护支持，但其在鸿蒙平台上的性能表现依然有限。Taro 的核心应用场景仍集中于小程序生态，而在原生鸿蒙系统上的性能问题与其他跨端框架类似，用户体验只能算是“能用”，但与原生实现相比仍有较大差距。

鸿蒙系统上的应用生态逐步丰富，目前已上架 1.5 万个原生应用。这些应用注重用户体验，在流畅度和易用性上表现优异，甚至在部分方面超越 iOS 和安卓。这种优势得益于其“轻装上阵”的开发模式。传统应用因多年迭代积累了大量冗余功能和代码，难以清理，导致应用臃肿、体验下降。而鸿蒙上的应用多为重新开发，无历史包袱，直接舍弃不必要的功能和代码，使得体积小、性能优。此外，鸿蒙生态尚新，开发主要聚焦核心功能，优先保障主要场景的流畅性，避免了不必要的附加功能，从而进一步提升了应用的简洁性和用户体验。

值得注意的是，鸿蒙操作系统的另一个后发优势，是其系统层的 AI 的能力相对来说比较完善。包括内置推理框架、神经网络、多模态模型等功能，同时提供丰富的 API（如目标识别、超分辨率处理、语音文字互转、智能推荐等）。我们可以利用这些系统级 AI 能力提升用户体验。例如，通过鸿蒙内置的 AI 功能，系统能够自动纠错、提供智能记忆及推荐等服务。

相较于鸿蒙，安卓因碎片化问题，AI 能力往往受限于设备型号和版本。只有最新的旗舰机型才具备完善的 AI 功能，而较旧的设备在系统层能力上就很欠缺。操作系统层的能力欠缺的话，在上层去填补就会比较成本高。而系统层能力完善的话，系统调度的整体功耗会比较占优势，性能与用户体验也更好。

因此，电商行业在鸿蒙系统上进行了更多探索，较之安卓更加激进，尝试将 AI 融入实际场景，例如根据用户需求提供精准的商品搜索和个性化推荐。同时，针对用户对快递状态的关注，AI 助手会主动更新并推送相关信息。以及端模型的实时意图识别和云端 AI 联动。例如，通过语音助手实现全局唤起，用户可用语音完成搜索、页面跳转等操作，探索更自然的交互模式。

架构演进趋势：从容灾建设到单元化复兴

今年的架构领域呈现出一些新的变化趋势，主要有以下几个方面：

首先，容灾能力方面需要加大投入，特别是应对极端风险。近年来，近年多个互联⽹产品出现⼤⾯积故障，凸显出在技术架构和容灾建设上的不⾜。⼤⾯积故障会带来极⼤的社会影响，需要尽可能避免出现极端⻛险。

其次，工程架构正在从粗放往精细⽅向演进。在存量互联⽹产品增⻓逐步放缓的背景下，工程架构精细化建设趋势包括以下几个方面。其一是成本优化，通过 FinOps 或者“下云”等手段，在成熟的业务架构下追求成本更优的方案。其二是单体服务的回归，随着架构趋于稳定，微服务的劣势会被关注，服务过度拆分的场景被重新聚合，甚至回归单体服务。其三是定制优化，依赖的基础组件，围绕业务特性定制建设，降低复杂度的同时获得成本和性能收益。

在用户数据保护与隐私合规方面，工程架构也在不断创新。例如，以 Microsoft M365 为代表的全球应⽤，⽀持按照⽤⼾粒度去放置数据，满⾜不同地区数据 Local 化的要求。以 Google BeyondCorp 为代表的零信任技术架构，业务上接⼊可信任代理或切⾯，对内外部访问流量决策⼲预⻛险。

此外，尝试基于大模型能力进行架构提效。大模型能力在工程技术领域逐渐涌现，主要围绕辅助优化和提效的场景展开探索。目前，较多尝试集中在以下方面：GPT Oncall/问答机器⼈、智能 SQL 查询、告警/故障根因定位、代码翻译等。

单元化架构的复兴？

今年，单元化架构再次成为业界焦点。

这种将系统划分为多个自包含单元的架构模式，最早在 SOA 时代就已出现。其初衷是通过隔离故障，提升系统的稳定性。Tumblr、Flickr等公司都曾成功应用该架构。最近，字节跳动等多家企业也纷纷加入这一行列。亚马逊 CTO 在 re:Invent 大会上更是将单元化架构列为复杂系统架构的重要设计原则。

字节跳动业务架构团队负责人洪增林对此指出，单元化架构的“复兴”其实并不是真正意义上的复兴，而是业务架构选型的自然结果。架构选型往往是解决⼀些问题，但也会带来新的问题，我们⾯向问题的时候，需要根据业务的阶段去做 Trade-off。

单元化架构的核心目的是解决几类主要问题。首先是资源增长的需求：业务的持续增⻓引发对机器和电⼒的需求，单⼀ Region ⽆法满⾜，需要⽤多个 Region 来⽀撑业务需求，进⽽推着业务架构去完成单元化的演进。其次是故障域隔离的需求：把业务部署拆分成多个独⽴的单元，不同单元之间尽可能相互独⽴，当某个单元出现故障时候，只会影响该单元内的业务，不会波及整个系统，进⽽提升系统的稳定性和可⽤性。第三是数据合规的需求：不同地区可能有不同的法律法规和监管要求，将数据和业务按照地域进⾏划分，不同地域的⽤⼾根据国家归属或地理位置将请求路由到合适的单元进⾏处理，更好地满⾜各地的合规要求。

然而，单元化架构也带来了一些新的挑战。首先是运维复杂度和效率的问题，运维多个部署单元会带来更多的复杂度，包括资源管理、部署升级、配置维护、故障排查等都需要⾯对多个单元，往往需要配套去建设⼯具平台来提效；其次是成本的上升，单元化架构下必然存在全局数据需要多单元复制，会增加数据的冗余，带来成本的增加，同时还会存在数据⼀致性的⻛险；再者是业务改造和适配问题。对于跨单元访问场景，⽐如单元 A 的⽤⼾给单元 B ⽤⼾转账，业务上需要做改造适配来完成跨单元的访问，通常会在框架层⾯来做⽀持，这⾥会引⼊复杂度。

因此，我们应该合理去看待⼀种架构选型他能做什么不能做什么，根据业务实际的需要去做选型，避免过早优化或者尝试去解决不重要的问题。

如今的单元化架构与十年前相比，在理念上并没有本质的变化，但随着技术和框架的演进，其实现路径发生了一些变化。

十年前，单元化架构主要依赖物理机部署模式，资源分配和管理的灵活性不够好。如今容

器化和 Service Mesh 在使⽤较⼴，为服务部署和流量调度提供了更好的便利，单元化落地上效率会更⾼；分布式数据库技术也已经更加成熟，诸如数据库⾃动分⽚、分⽚的调度管理、跨地域内置数据同步等能⼒，能⼤⼤提升单元化架构下数据管理的效率和数据⼀致性；此外，调度手段也变得更加多样化，现在的流量调度可以基于端调度、智能 DNS、CDN 回源调度、⽹关层兜底调度等多种⼿段，实现根据地理位置、业务属性、业务等级等多维度调度，做到精准和快速的单元调度。

服务治理

除此之外，这一年服务框架、服务治理趋势也发生了一些明显了变化。

Java 在开发企业级应用的时候有着天然的优势，Spring AI Alibaba 是一个面向 AI 工程的应用框架，其目标是将 Spring 生态系统的可移植性、模块化设计等企业级特性应用到 AI 领域，解决 AI 集成的基本挑战，将企业原有的数据和 API 与 AI 模型更好地结合起来。

Java 仍旧占微服务编程语言的主流地位，但也有越来越多的企业开始使用 Go 、 Python 、Rust 语言来开发微服务应用，服务治理架构也从 Sidecar 演进到 Ambient 和 Proxyless。

Istio 宣布其 Ambient 模式已达到 GA（全面可用）状态。Ambient 模式解决了过去每个工作负载都需要单独 Sidecar 所导致的高 CPU 和内存损耗，以及每次更新 Istio 版本时需重新启动所有 Pod 的痛点。Ambient 模式支持将 L4 层与 L7 层分离，使企业能够逐步采用 Istio 技术。可以从无网格状态平滑过渡到实现如 mTLS、授权策略和可观测性的 L4 层，然后根据实际需要，在每个命名空间内逐步启用更复杂的 L7 层功能，例如重试、流量分割、负载均衡和可观测性数据收集。这种按需分阶段的平滑过渡，有助于在整个集群中逐步实现服务网格功能的全面部署。

服务框架层面，Apache Dubbo 正式发布了 3.3 版本，通过 Triple 的全新升级，突破了以往局限，实现了对南北向与东西向流量的全面支持，提升了对云原生架构的友好性。Dubbo 、Grpc 和 Kitex 等众多微服务框架都实现了 Proxyless 模式，通过 xDS 协议实现服务框架与控制面的直接通信，进而实现控制面对流量管控、服务治理、可观测性、安全等的统一管控，规避 Sidecar 和 Ambient 模式带来的性能损耗与部署架构复杂性。

阿里云服务框架 &治理团队负责人肖京提到，企业对于服务治理的需求也在变化，已经逐渐从最初的流量管理、服务治理升级到 API 管理，企业更加关注效率的提升。

传统的服务治理稳定性范畴已经深入人心，绝大多数中大型企业都已经使用了无损上下线，全链路灰度 功能来保障发布时稳定性，并通过流量防护保障运行时的不确定流量和不稳定依赖。

过去企业用户主要关注网关在性能、安全性和成本方面的表现。他们倾向于将流量网关、微服务网关和安全网关进行整合，以解决多层网关独立设计和运维所导致的资源消耗、性能损失、稳定性难以控制以及安全防护复杂等问题。然而，随着数字化程度的不断提升，越来越多的企业开始视 API 为公司的核心资产。这一转变促使企业在网关需求上升级到更注重 API 管理的层面。在这种背景下，企业不仅希望网关能够高效、安全地处理流量，还期待其在 API 的生命周期管理、版本控制、编排能力、访问权限、监控和分析等方面提供全面的支持，以便提高开发效率和实现高效的数字化运营。

关于架构的未来预测

未来三到五年，架构领域的技术方向虽然难以完全预测，但其核心仍然是⽀持和解决业务上的问题。⾯对业务在容灾稳定性、资源成本、研发效率、隐私安全⼏个⽅⾯，需要持续去解决业务上的关键问题；同时随着 AI/LLM 的发展，落地和应⽤ AI ⼯具去解决技术架构问题。此外，在 AI 推理和训练场景中，如何提高性能、稳定性以及降低成本，将是值得关注的技术方向，并且需要加大投入。

大数据：AI 与传统基础设施双驱动

2024 年大数据的发展可以分为两大类：AI 基础设施（AI Infra）与传统数据基础设施（Data Infra）。

AI 基础设施

过去，当我们提到大数据处理时，人们的关注点大多集中在对结构化数据（Structured Data）的复杂处理。这也是为什么我们的关注点往往放在了诸如 Apache Spark 这样的处理引擎上。

但近年来，随着 AI 技术的迅速崛起，人们的目光逐渐转向了非结构化数据（Unstructured Data），包括图像、视频、声音以及文本等。AI 应用的兴起，也推动了为 AI 设计的数据基础设施的发展。例如，针对非结构化数据的 ETL 流程，创业公司如 unstructured.io 便专注于从 PDF、PPT 等复杂格式中提取清理数据。然而，这一领域充满挑战，尤其在高精度处理需求下，技术难点显而易见。

另一个 AI 领域的焦点是向量搜索（Vector Search）。自从大语言模型（LLM）引发关注以来，向量搜索持续成为热门话题。正如去年所预测的，越来越多的传统数据库如今具备了向量搜索的能力。例如，Postgres 通过 PgVector 扩展大幅提升了 AI 场景下的竞争力，而 Elastic 等传统搜索引擎玩家也逐渐占据更大市场份额。这种趋势表明，向量搜索已经不再是向量数据库的专属领域。

不仅如此，Postgres 在 AI 领域的应用还拓展到了长时记忆存储（Long-Term Memory Storage）。由于大语言模型在长时间对话中的局限性，开发者需要一种可靠的持久化存储来保存上下文信息，而 Postgres 凭借其广泛使用和高可靠性，逐步成为该领域的首选解决方案。

随着多模态 AI 技术的普及，多模态数据库也受到越来越多的关注。然而，令人意外的是，更多的技术突破来自于 Redis、MongoDB 等传统数据库玩家，而专注于多模态处理的创业公司相对获得的市场关注较少。这也再次表明，传统玩家在 AI 基础设施领域仍然占据主导地位。

综上所述，在 AI 基础设施领域，尽管有一些完全新增的增长点（如非结构化数据的 ETL），但大部分子赛道仍是传统玩家为 AI 赛道提供更好的支持。这些老牌玩家凭借其技术积累和市场份额，拥有绝对的主动权和关注度。

传统数据基础设施

在传统数据基础设施领域，有三个方向值得关注：

S3 作为主要存储架构（S3 as the Primary Storage）

S3 作为主要存储并不是一个新概念，但真正的大规模应用却是最近几年的趋势。越来越多的分析型数据库（如 ClickHouse、StarRocks 的商业版）开始采用这一架构。流数据领域同样如此，Confluent 收购了 Warpstream，一个以 S3 为核心存储架构的 Kafka 替代系统。这种架构通过减少网络传输成本，在牺牲部分延迟的同时，极大地降低了整体成本。类似地，Flink 也引入了 S3 作为状态存储（State Store）的能力，紧跟流数据库 RisingWave 在架构设计方面的步伐。

Small Data 的崛起

随着单机系统性能的提升，“Small Data”成为今年的热门话题。DuckDB 作为一个嵌入式数据库，以其与 Postgres 的良好兼容性以及出色的 Python SDK，成为许多项目的轻量级选择。它被广泛称为“SQLite for Analytics Small Data”。越来越多的公司使用 DuckDB 替代部分 Snowflake 的功能，原因在于 DuckDB 的使用成本远低于 Snowflake。

开放表格格式的流行（Open Table Format）

2024 年，开放表格格式成为传统数据基础设施领域最重要的亮点之一。Databricks 收购 Tabular 并开源 Unity Catalog，Snowflake 则推出了开源项目 Polaris，AWS 也在其 re:Invent 大会上发布了基于 Iceberg 的 S3 Tables。开放表格格式不仅让 S3 上的数据可以轻松被查询，还让用户在不同厂商之间拥有了更大的选择空间，同时支持多种语言（如 SQL 和 Python）。这种灵活性推动了数据与 AI 应用的深度结合，进一步提升了生产力。

数据与 AI 的有机结合

经历了前两年的经济低迷，各家公司在 2024 年底逐渐恢复了财务状况，相信 2025 年大家的重点将从“降本”转向“增效”。生产力的提升将成为核心目标，而这正是大模型带来的突破之一。

实时数据的普及将成为一个重要信号。例如，Iceberg 引入 CDC 能力能够让用户更好地进行实时数据处理，而 OpenAI 提供的实时 API 让实时 AI 得以进一步发展，而这也将推动实时数据需求的增加。未来，我们将看到更多数据库支持大模型相关功能（如 Text2SQL），数据与 AI 的结合会更加有机与深入。

总而言之，RisingWave 创始人 &CEO 吴英骏坚信，2025 年将是数据基础设施与 AI 基础设施共同发力的一年，实时处理能力与 AI 场景的结合将塑造一个全新的大数据格局。

云计算：继续向着 AI 靠拢

• 4 月，IBM 宣布收购 HashiCorp 对整个行业来说意义重大，HashiCorp 提供了很多基础工具，不仅被很多公司广泛采用并作为基础设施，甚至构筑在这些工具的生态之上， 如 Terraform、Vault、Consul、Nomad 等。

• 博通 2023 年 11 月完成收购 VMware 后，持续影响。VMware 不仅仅在虚拟化市场占据了很大份额，同时在云原生领域中有很大的投入，做了不少开源项目和贡献。随着博通的收购，公司的政策出现了很多变化，导致很多人才流失以及一系列开源项目贡献者的缺乏，间接导致了很多原本 VMware 的客户流失，转而使用 KVM 等方案。

• 云安全公司 CrowdStrike 导致了全球很多 Windows 系统的蓝屏，这影响到了金融、航空以及保险等各个领域。

Kubernetes 新旧问题交织

今年 6 月，Kubernetes 迎来了 10 周年。Kubernetes 无疑是革命性的，为行业带来了巨大价值。然而，2024 年“放弃 Kubernetes”成为一些公司的选择。

2024 年 11 月，提供容器化开发环境的 Gitpod 宣布已将其服务从 Kubernetes 迁移到名为 Flex 的新自主平台，原因是 Kubernetes 的复杂性、资源管理和状态管理等问题。事实上，这些挑战一直存在，无论国内还是国外。广大开发者对于 Kubernetes 的抱怨也主要集中在学习曲线复杂、维护效率低下、供应商锁定、过度使用以及需求和规模不匹配等问题上。

Kubernetes 许多功能虽然实现了自动化，但运维人员需要对其有深入理解，才能充分发挥其优势，否则使用 Kubernetes 反而可能导致成本上升。并非所有应用都适合部署在 K8S 上。在非 K8S 环境中，应用的扩缩容和数据迁移等工作可能由人工完成，而在 K8S 中则需要适应不同的操作方式。因此，人员能否能应对这种复杂度至关重要。

也就是说，没有万能的解决方案，企业必须找到最适合自己的那一个。

另一方面，随着企业对大模型的广泛使用，Kubernetes 面临越来越多的 AI/ML 工作负载。根据 Pure Storage 对拥有 500 名及以上员工公司进行的调查，54% 的公司表示已经在 Kubernetes 上运行 AI/ML 工作负载。

AI/ML 模型依赖容器和 Kubernetes 的重要原因是提供了管理 AI 工作负载所需的灵活性和可扩展性。就连英伟达也在 4 月收购了基于 Kubernetes 的工作负载管理和编排软件提供商 Run.ai。

但是，企业可能会发现很难继续使用 Kubernetes，因为其需要对 GPU 等资源进行调度，而这并非 Kubernetes 创建之初考虑的使用场景。

2024 年 12 月，OpenAI 出现的全球范围内的服务不可用故障，直接原因就是升级监控组件导致 Kubernetes 集群控制面过载，数据面 CoreDNS 对控制面有强依赖导致影响应用服务，进一步放大了故障影响。

为此，业内一直在进行相关功能的扩展和优化。另外，考虑到 Kubernetes 已经发展了十年，要在这样一个平台上增加功能，同时不对现有用户造成影响，也是一项挑战。

另外，随着 AI 的出现，客户在选择云服务时通常会优先考虑哪家云服务商可以提供 GPU 资源。有个问题是，即户数据往往存储在原有系统中，而数据必须迁移到有 GPU 资源的云环境中。比如，客户数据存储在私有云中，而 GPU 资源位于公共云上，这时数据需要实时从私有云传输到公共云，这就要求 Kubernetes 能够在私有云和公共云之间进行统一管理。

好在 Kubernetes 的扩展性比较强，目前已经有一些方案可以使用，所以各家公司实际中遇到的很多问题是可以规避掉或者解决掉的。比如针对调度问题，大家会基于 Kubernetes 的标准 CRD/CSI/ Device Plugin 扩展实现包括 operator 或者各自的 GPU 调度分配组件来完成。而在 24 年 8 月，云原生计算基金会 (CNCF) 发布了 Kubernetes v1.31 (Elli)，首次专门对处理 AI/ML 应用程序的资源管理和效率进行了改善。

此外，K8S 和大数据技术栈的结合使用也更加广泛和灵活，比如亚马逊 SageMaker 整个机器学习平台就集成了完整的大数据栈。生成式 AI 需要大量数据，既需要用于训练的历史数据或静态数据，也需要实时的秒级或分钟级业务数据，数据的不同让生成式 AI APP 各具特色。通过 K8S 和大数据技术栈组合搭建生成式 AI APP，底层来看技术栈本身没有太大变化，只是使用量和数据处理量增加了，但这让数据湖架构在整个生成式 AI 中扮演着关键角色。这也是 Databricks 等公司市值上升的重要原因。

虽然 Kubernetes 上运行 AI/ML 等项目存在挑战，但是 Kubernetes 在演进、整个生态都在发展，因此业内专家认为，至少未来 5 年内 Kubernetes 仍然是主流基础设施。

此外，2024 年也出现了“AI 网关”概念，其都是基于原有 API Gateway 经验，如限流限速、安全认证、可观测性等，另外添加上 AI 时代所需的一些能力，比如基于 token 的限流限速、计费、Prompt 管理、内容过滤、账号管理等，并且添加了对各种主流大模型供应商和私有化部署方案的集成，这样用户可以更加方便地对接自己所需的大模型。

企业 AI 应用开发/部署的流程中，现有的 AI Gateway 能满足大多数需求，但部分 AI 网关可能会有些高级特性，比如 Kong AI Gateway 提供语义化缓存特性，提升回答效率、节约 Token 消耗。

大模型集成是基本功能

2024 年，云厂商们纷纷提供了大模型集成功能。比如微软、亚马逊云科技、谷歌都提供了多种模型的集成，以便于客户自主选择，灵活使用，甚至 GitHub 推出了 GitHub Models，底层直接使用 Azure 提供的能力，开发者有生产部署需求时，可以直接迁移到 Azure 提供的能力中，而无须进行额外的适配。

其次，各家也都在构建工具方面做了一些尝试和创新，都提供了各类便于客户快速构建自己 大模型应用的工具和平台，以及与云上其他产品能力集成的方式。

Azure 由于和 OpenAI 的合作关系，能最快且独家的提供 OpenAI 系列 大模型服务，这在一开始显著增加了其在这一领域的份额。后期，由于 Anthropic 的 Claude 3.5 系列模型的强劲表现，亚马逊云科技、谷歌云上这一模型的使用量都有增加。到了年底，Google 的 Gemini 模型和其他系列模型/产品表现亮眼，也为其增加了市场份额。可以看出，大模型对于云市场的竞争格局是有一定影响的。

AI 还显著增加了企业对算力的需求。除了常规云厂商，还兴起了 GPU as a Service 领域。对于个人开发者来说，这是一种低成本的方式，可以只按照消耗的 GPU 资源计费，而且可以自行控制生命周期。但是对于企业，尤其是规模较大、需求较高的企业，这种方式并不一定比直接购买 GPU 服务器要好。除了资产成本，还要考虑是否可能存在队列排队，或者安全性等。这个领域目前相对小众，有发展机会，但还不足以改变公有云的发展格局。

同时，端侧大模型的逐渐应用，也增加了对边缘计算的需求，实时处理和数据隐私的需求推动了能够托管大模型的边缘计算解决方案的需求。其次就是对小模型的能力需求，既要可以在资源首先的边缘设备上运行，同时还希望其能提供更好的能力，这也会进一步的促使边缘设备的硬件发展，让其具备可以运行模型的能力，以及提供更高的效率。

毋庸置疑，AI 发展需求也促进了公有云的发展。根据中商产业研究院整理数据，中国公有云市场规模 4562 亿元，同比增长 40.1%，占国内云计算市场的比重为 74.48%，根据 TechTarget 企业战略集团 9 月份的一项调查，全球四分之三的组织正在公共云提供商上运行 GenAI 工作负载。对于大多数公司，尤其是规模较大的公司通常选择混合云，因为他们有自己的云和数据中心。

公共云的技术演进速度明显超过了非公共云场景。云市场中出现了几家专注于云技术私有化替代的厂商。比如有厂商开发了与 AWS S3 兼容的对象存储服务，这种对象存储可以部署在任何数据中心。这表明，由于公共云发展迅速且用户众多，其上的服务逐渐成为一种标准，并蔓延至私有云领域。此外，开源软件也在这一趋势中发挥作用，例如 minIO 等对象存储软件都有对应的私有化版本。这种公有云技术标准化现象在每个领域都有可能产生，这些标准并非一开始就完整定义，而是随着使用人数的增加而逐渐形成。

为争夺大模型用户，国内云厂商们也爆发了一场“价格战”，从 5 月持续到了年底。字节跳动旗下火山引擎、阿里云、百度智能云、腾讯云先后把大模型推理算力价格下降了 90%以上。虽然这种竞争方式被认为非长期可持续的，但厂商们依然在加码，有专家预计可能 2025 年会依然继续。

多云、混合云的故事，落寞了？

根据 HCLTech 数据，受调查公司使用超过一家云供应商的占比超过 80%，这比三年前多了 2 倍左右。但其实 2024 年，更多的公司都专注在了如何将 AI 引入到自己的产品、业务上，很少出来讲自己如何做多云和混合云。云厂商们自己的大会议题也很少见对多云、混合云支持的介绍。

多云的概念其实已经被许多企业认可，他们也想向多云迈进，但在实际操作中会发现这一步很难。目前，还没有一种技术能让企业轻松实现迁移，除非是一些非常初级的功能，一旦企业对云服务的使用更加深入，比如涉及到对象存储、块存储、数据库、大数据、AI 等服务，那么迁移就会变得非常困难，关键就在于数据是企业绑定在特定云上的最关键部分。

另外，虽然拥有防止供应商绑定、更好地利用云之间弹性等优点，但在初期阶段，企业使用多云的成本可能远高于开发应用的成本。因此，企业可以先集中精力开发应用、搭建系统、开展业务，待业务稳定后再考虑多云问题。虽然越往后解决多云问题的难度可能越大，但可以给系统在运行过程中不断优化的时间。

对于一些中小企业来说，选择单一云服务商可能是更优的选择，这样可以降低整体成本。只有当业务量达到一定规模或业务复杂度较高，需要在多个云之间进行优化或利用不同云的能力时，多云才能为企业带来价值。但这需要企业技术团队具备更强的技术实力来应对多云带来的复杂性。

具体如何选择，企业需要自行计算，比如评估未来 1 至 5 年在单一云上运行的成本，包括 IT 资源成本、基础软件的维护和自建成本、迁移成本以及应用架构改造等。通过比较单一云和多云的成本，企业才能做出明智的决策。

此外，一些新兴的云厂商价格更低，价格优势更大，这为多云厂商带来了机会。客户更容易选择在每家云上都运行得很好的产品。多云厂商的竞争点在于其产品在单朵云上要比云厂商自身的产品更好，比如成本更低、性能更优、稳定性更强等，然后再依托多云优势，打出自己的差异性。这也意味着，多云厂商的“杀手锏”并非多云自身的价值，本质上还是自己的产品。

另外，混合云在实际应用中还是比较普遍的，很多互联网厂商也在采用这种模式。混合云有其具有独特的适用原则。例如，公共云资源可以按需使用，而私有云可能并没有部署对应云厂商的云基础设施，而是企业自己维护的数据中心。

有些企业可能已经拥有数据中心，闲置不用而直接使用公共云资源并不划算。有的企业私有云设备即将过保，这时会将更多的应用迁移到公共云上。也有企业在私有云建设规模达到一定程度后，选择将公共云上的应用全部迁移到私有云，这种情况相对较少，通常发生在企业采购了某云厂商的云基础设施底座，底座的软件费用是固定的，但硬件可以随意增加，使得私有云的容量能够扩展到一定程度，而不会产生额外的软件成本。从成本角度看，这是一个更优的选择。

然而，成本问题需要从长期角度来考量。在私有云环境下，如何确保应用的稳定性、快速上线以及运行效率等关键指标是非常重要的。有些技术指标可能难以量化，也无法证明无人维护的私有云相比公共云不够稳定，这通常只能依靠经验来判断。

平台工程：从兴起到务实发展

平台工程在过去两年多以来着实“热闹”，甚至可称其为最耀眼的新兴技术之一。

如 2024 一开年，平台工程就被咨询公司连续两年评为”年度 10 大战略技术趋势“之一，这属于非常罕见的情况。

代表性项目 Backstage 正在 CNCF 孵化中阶段，作为开源的内部开发者门户（IDP）解决方案，CNCF 不仅推出了对应的培训课程，还推出了 Backstage 项目的认证考试；同时面向平台工程师的认证计划也在进行中，这足以说明围绕平台工程及 Backstage 的生态正在快速发展和加强链接。

与此同时，社区也持续壮大，同行共识也越来越多。全球 Platform Engineering 社区目前已聚集了超过 2.2W 的从业者，年度会议 PlatformCon 也一如既往线上召开，近期社区也宣布了 2025 年将分别于伦敦和纽约组织线下会议。在中国，平台工程社区同样聚集了不少同行，密切关注者超过 500+，PECommunity 社区也开始在多个技术活动上出现并获得关注。同行共识方面最大的看点是平台规范 Platform Specification(https://platformspec.io/) 的发布，相比于此前的 CNOE , BACK Stack，KAOPS 等更加有系统性，对平台的界定更加清晰和具体，抽象层次更高，可落地性更强，目前处于早期比较活跃的发展状态。同时与 OAM 规范相比，聚焦于工作负载规范的 Score 项目也在年中进入 CNCF 沙箱，旨在简化云原生开发者的开发工作。

平台工程在过去一年也将开发者体验（DevEx）推向了新的高度。

对于软件开发生产力和开发者体验的度量，也是业内的焦点，目前已经从 DORA、SPACE、DevEx 等发展到 DX Core 4 阶段。这些具体的度量指标，牵引着研发团队对于效率和体验的几乎所有投入，最终能否获得预期回报，特别是能否与组织内的甲方“业务团队”对齐该指标，并与业务或商业指标关联，是平台工程成败的重要决定因素。从行业发展和技术演进的角度，加强对于人相关的指标的关注一定是一个非常大的进步，尤其是在国内过于”内卷“的情形下，更有远见的技术领导者和未来走得更远的技术团队，从当下到未来一定会加大对开发者体验的投入，这才是真正地聚焦增效。

基于当前现状和趋势，结合云原生生态的持续发展以及 AI 尤其是 AIGC 的采纳扩大，2025 年的平台工程将更加”务实“，在相关开源项目持续发展和扩大应用的同时，也将链接更多实践比如内部开源与内部开发者门户、工程效能与软件生产力工程、开发者体验与内部开发者平台/社区。”独木难成林“，在今天任何新的技术或实践，从 0 开始独立发展壮大将越来越难，不可避免地要选择与既有生态链接。对于国内，正如咨询公司所言，中国的平台工程正在告别"期望膨胀期”，进入泡沫破裂低谷期，这与全球趋势基本一致。

平台工程的初衷是与其他已有实践共同解决复杂性的问题，我们依然相信这是正确且很有价值的方向，但需要持续加大投入和更多的探索实践。 部分新的趋势也在来年可能会获得更大发展，如对临时运行环境的更多采用、AIOps 中的 AI 治理平台、GenAI 与自治系统在 DevOps 中的更多采纳等。

数据库：内核还是老样子，但 RAG 也许能翻出“新花样”

“用一个数据库解决所有数据处理问题，是用户们最想要的结果”。

就像上述很多技术领域一样，数据库这一底层传统软件同样在持续快速发展与革新之中，在 2024 年，这些技术和热点事件值得关注。

RAG 是一门数据库生意

就像上述很多技术领域一样，数据库这一底层传统软件同样在持续快速发展与革新之中，这所有变革中，RAG 技术的兴起为“老气横秋”的数据库增添了新活力，与其说 RAG 是一门 AI 生意，不如说它是一门更贴近数据库的生意。

RAG 技术结合了检索模型和生成模型的优势，旨在提供更准确、连贯和信息丰富的回答或生成结果。其核心思想在于，对于给定的问题，能够在数据库中尽可能召回与这个问题最相关的上下文。这个召回出来的上下文直接决定了 RAG 回答这个问题的质量。实际上，生成式大语言模型在其中只是起到一个阅读理解的作用，关键还是数据的质量，以及召回的精度。

从这一点来看，RAG 技术与数据库技术有着天然的契合度。向量数据库是一种专门用于存储和查询向量数据的数据库系统，它能够高效地存储和检索大规模向量数据，主要用于相似性搜索、推荐系统、嵌入式向量存储以及聚类和分类等任务。RAG 技术正是利用了向量数据库的这种高效检索能力，通过检索模型获取相关的上下文信息，使得生成模型能够基于更广泛的知识库进行生成。

2024 年 11 月 1 日，IDC 发布了《RAG 与向量数据库市场前景预测》报告。报告指出，检索增强生成（RAG）技术在提升通用大模型准确性方面效果显著，且企业对其认可度正持续提高，有望成为生成式 AI 落地的关键推动力。到 2024 年底，基本上国内主流数据库厂商的数据库产品都已经具备了向量检索功能。

开源许可证变更

过去的一年是许可证变更动荡的一年，其中最突出的两个是 Redis 和 Elasticsearch。

去年 8 月，外媒消息称，在变更许可证后，Redis 公司正积极推进 IPO。该公司最初于 2011 年以 Redis Labs 的名称成立，2021 年从 Redis Labs 的创始人 Salvatore Sanfilippo 手中收购了 Redis 商标，并更名为 Redis 公司。过去几年，Redis 公司一直试图巩固对 Redis 领域的控制。该公司还试图通过增加对向量和其他数据模型的支持来摆脱人们对该系统主要用作内存缓存的看法。

2024 年 3 月，Redis Ltd. 宣布将从系统原始的（非常宽松的）BSD-3 许可证转换为由专有的 Redis 源可用许可证和 MongoDB 的 SSPL 组成的双重许可证。该公司宣布这一变化的同一天，他们宣布收购 Speedb，这是 RocksDB 的一个开源分支。

Redis 许可证变动很快引发了强烈反对。许可证变更的同一周，基于原始 BSD-3 代码行的两个分支发布： Valkey 和 Redict。Valkey 最初由亚马逊发起，但谷歌和甲骨文的工程师很快加入进来。仅仅一周后，Valkey 项目就成为 Linux 基金会的一部分，遭到了 Redis 公司的反击，几家大公司将开发工作转移到了该项目上。Redis 公司开始接管开源 Redis 扩展，但这并没有消除人们对其不怀好意的印象。

为了缓和关系，Redis 数据库的创始人于 2024 年 12 月宣布，他已与 Redis 公司管理层取得联系，希望重新团结 Redis 社区。

Elastic NV 是一家营利性公司，支持文本搜索 Elasticsearch DBMS 的开发。2021 年，他们宣布转向 Elastic 许可证和 MongoDB 的 SSPL 的双许可证模式。亚马逊对这其开源许可证的变更并不开心，于是亚马逊创建了 OpenSearch 分支。

三年后，Elastic NV 于 2024 年 8 月宣布撤销许可证变更并改用 AGPL。

数据库内核：用简单打败复杂

大语言模型爆发后，数据爆炸式增长已经是无法回避的事实，数据的重要性日益凸显，原因在于过去由于缺乏有效利用手段，大量数据被忽视或丢弃。但现在，随着大数据模型和人工智能技术的发展，即使是看似无用的数据，未来也可能发挥关键作用。因此，许多企业开始采取一种策略：不论数据当前是否有用，都先行存储。这种做法是正确的，因为这些数据未来可能成为企业区别于竞争对手的核心竞争力。例如，用户在企业平台上产生的数据就极为重要，需要妥善保存。

另一方面，我们已经开发了许多底层数据技术，如数据仓库、OLAP、向量数据库、云数据库等，用于人工智能和新型数据应用。然而，企业面临的挑战是如何应对这些技术之间的复杂性，避免形成新的数据孤岛。关键问题在于如何实现系统间的互通、同步，以及解决一致性和高可用性问题。

因此，现在其实已经可以窥见，未来的一大趋势是将现有的碎片化数据技术进行整合。例如，通过 Delta Lake 或 Data Lake 等方案，逐步实现数据统一。比如 TiDB 就采用的 HTAP（混合事务/分析处理）思路，它实现了从 OLTP 到 OLAP 的统一，并引入向量索引能力，使得用户在使用 TiDB 时无需额外使用向量数据库，从而打破数据壁垒，创造更大价值。

在数据日益增多、复杂的情况下，采用更简单的技术栈可能会带来更大的价值。这虽然看似是一条悖论，但深入思考后会发现，简化技术栈可能是未来发展的一个重要方向。

操作系统：国产化进展如何了？

“2024 年，如果说哪项技术没有和 AI 融合起来，那就离淘汰不远了。”

装机量迎来爆炸式增长

在过去几十年的时间里，操作系统始终由海外的厂商主导，自研操作系统成为了 14 亿中国人心中的一根刺。

按照国资委下发的 79 号文，所有央企国企办公 OA 系统到 2027 年需要 100%完成信创替代，这就给了国产操作系统“大展拳脚”的机会。

2024 年，国产服务器操作系统的年总装机量持续展现出稳健的增长态势：鸿蒙生态设备数量也已突破 10 亿台，不仅覆盖手机、平板、穿戴、智慧屏、鸿蒙座舱等各个领域，还覆盖鸿蒙智联产品和千行百业的终端，应用生态方面，已有超过 15000 个原生应用和元服务上架，可以满足用户 99.9%的使用时长；统信 UOS 操作系统的国产平台装机量已超过 800 万套，服务客户超过 5 万家，服务体系深入全国 2800 多个区县，全球个人用户超过百万；openEuler 社区在开源五年内实现了规模化商业落地，2024 年新增装机量突破 500 万套，五年累计装机量超过 1000 万套。

AI 含量持续上升

2024 年，操作系统（OS）领域的一个显著趋势是 AI 技术的深度融合。据 Gartner 报告显示，到 2025 年，超过 50%的软件将集成 AI 功能。众多科技大厂，如微软和苹果，都在这一领域展开了积极探索。前两年，微软联合高通推出了一款结合 AI 技术的操作系统版本。虽然 Windows 早先就有 ARM 版本，但其市场表现一直不温不火。2024 年，微软通过将 AI 技术与高通的芯片相结合，为 Windows 带来了新的活力。Windows 10 使用 AI 算法为用户推荐应用和服务，提高了用户留存率 15%；谷歌的 Android 12 引入了更多的 AI 功能，如自适应亮度调整，根据用户习惯自动调整屏幕亮度，提升了用户满意度 10%，同样，苹果的 Apple Intelligence 也备受关注。

此外，手机厂商也在不断推出结合 AI 的操作系统新产品。例如，在图像处理方面，能够进行精准抠图、人物识别和搜索；在语音交互方面，可以实现一句话点单和自动化操作等。

除了大厂的动作，一些小型创新公司也推出了引人注目的产品。在美国，今年有两个值得关注的产品亮相：首先是 AI Pin，它不仅仅是一个操作系统，而是一个操作系统与设备的结合体。这款设备无需键盘、鼠标甚至屏幕，只需挂在衣领上，就能进行投屏、手势识别或投影操作。另一个是 Rabbit OS，它通过一个小巧的设备和简单的输入方式，就能帮助用户安排行程、进行搜索、听歌等多种工作，展现了 AI 与操作系统结合的创新潜力。

在 AI 与 OS 融合的大潮中，安全问题尤为值得关注。AI 的发展带来了数据质量与隐私、系统安全性等挑战。高质量的数据是 AI 模型的基石，但现实中数据往往存在诸多问题，如不完整、错误或噪声等。同时，AI 应用对个人数据的收集和使用，也使得数据隐私保护成为一大难题。此外，AI 系统的安全性同样备受关注，黑客的攻击可能引发信息泄露和系统瘫痪。

面对这些挑战，统信软件指出 AI 发展的两个关键趋势：一是从云上集中计算转向端云结合；二是从独立的 AI 应用系统向 AI 与操作系统深度整合的 AIOS 方向发展。

端云结合的优势在于成本效益、数据及时性、数据安全与隐私保护以及个性化服务。例如，在自动驾驶领域，大模型的部署必须发生在端侧，以确保对环境的实时感知和快速响应。而在 PC 或手机上，端云结合的 AI 模型能够提供从语音识别到智能推荐等多样化的个性化服务。

AIOS 的发展则将 AI 应用生态推向了一个新高度。AIOS 的优势主要体现在智能化、个性化、安全性和生态统一四个方面。它能够实现智能化的任务调度和资源管理，提供个性化的用户体验，并通过 AI 技术提升操作系统的安全性。同时，AIOS 支持异构 AI 算力，为开发者提供了标准化的接口和完善的 AI 应用生态。

AIOS 支持 CPU+GPU+NPU 的异构 AI 算力，并将 AI 能力通过标准的接口提供给应用开发者，并且提供智能体等 AI 应用生态的开发、运行、分发、部署、调优等环境。

对多类型平台的支持已成标配

操作系统的多类型平台支持已经成为业界的新标配。从桌面到移动，从云端到边缘，操作系统正不断拓宽其兼容性和适用范围，以满足不同用户和场景的需求。

据 Statista 数据显示，截至 2023 年，全球智能手机用户数量已超过 60 亿，而 PC 用户数量也保持在 10 亿以上。这一数据背后，是用户对于跨平台操作体验的强烈需求。操作系统必须能够在不同设备上无缝运行，以保持用户的连贯体验。

以微软的 Windows 为例，Windows 10 的发布标志着微软对跨平台支持的重大承诺。它不仅支持传统的 x86 架构，还通过 Windows on ARM 项目，扩展到了 ARM 架构，使得 Windows 能够运行在更多类型的设备上。根据微软官方数据，Windows 10 的装机量已超过 10 亿台，这一成绩证明了跨平台兼容性的巨大市场潜力。

谷歌的安卓系统是最典型的多平台支持案例。安卓不仅统治了智能手机市场，还扩展到了平板电脑、智能电视、可穿戴设备等领域。根据 IDC 的报告，2022 年安卓智能手机市场份额达到了 87.5%。此外，安卓的开放性使其能够运行在多种硬件架构上，包括 ARM、x86 甚至 RISC-V。

Chrome OS 是另一个成功的多平台操作系统。它最初是为教育市场设计的，但现在已扩展到企业市场。根据 Grand View Research 的数据，Chrome OS 的市场份额在 2021 年达到了 10.8%，并且预计将继续增长。Chrome OS 的成功在于其轻量级设计和对云服务的深度集成，使得它能够在低成本的硬件上提供高效的用户体验。

华为的鸿蒙 OS（HarmonyOS）就是为跨设备协同而设计的。华为宣布，截至 2022 年底，搭载鸿蒙 OS 的设备数量已超过 3 亿台，涵盖了智能手机、平板电脑、智能手表、电视等多种设备。

此外，随着量子计算和新型硬件技术的发展，操作系统将面临新的挑战和机遇。例如，微软正在开发适用于量子计算机的量子操作系统，这将是操作系统支持新型平台的一个例证。

五大开源社区联手，共推国产操作系统向前迈进

去年 10 月，11 名俄罗斯程序员已被从 Linux 内核开发者名单中除名，这一事件在开源社区中引发了轩然大波，人们意识到，一旦开源社区出现问题，如技术封锁或社区分裂等，基于其开发的操作系统将面临不可预测的后果。所以建立属于自己的开源根社区，并联合其他伙伴共同维护国产操作系统生态稳定，是重中之重。

2024 年 11 月，五大中国开源操作系统社区——深度（deepin）、开源欧拉（openEuler）、龙蜥（OpenAnolis）、鸥栖（OpenCloudOS）和开放麒麟（openKylin）联合发起了开源生态发展合作倡议。这一联合行动标志着国内开源操作系统的合作新阶段，旨在推动生态建设，提升技术协同，推动中国在全球开源领域的影响力。此次倡议主要提出三项关键动作：

• 统一关键技术链：各参与社区将致力于推动操作系统内核等基础共性技术的统一，同时尊重和维护各自社区的原创性和独立发展。这样的合作不仅能提升系统间的兼容性，还能为用户提供更易用的操作体验。

• 增强产业协作：倡议呼吁操作系统企业与上下游软硬件企业加强对话与交流，凝聚产业共识，逐步形成覆盖整个操作系统生态的合作机制，以共同做强、做优、做大中国的操作系统生态。

• 培养开源人才：为了加快开源操作系统的全球共融与共建，倡议还强调了人才培养的重要性，注重创造各类开源领域所需的人才，为全球开源生态的发展作出积极贡献。

芯片：很难做，但也没退路

在过去的一年里，芯片技术领域最大的技术进展无疑集中在人工智能（AI）和机器学习（ML）领域的应用上。

架构创新、封装技术仍是业内之“伤”

其中，新一代高带宽内存技术 HBM4 的量产时间提前，为 AI 和 ML 应用提供了更为强大的数据处理能力。HBM4 相较于前代产品，在带宽和容量上都有了显著的提升，这意味着芯片可以更快地读取和写入数据，从而大幅提高计算效率。同时，5 纳米成为新的工艺节点，也为芯片的性能提升提供了可能。随着工艺节点的不断缩小，芯片的集成度不断提高，功耗逐渐降低，而性能则得到了显著的提升。

此外，台积电的 CoWoS 技术（2.5D 先进封装技术）也演进至第六代，对芯片和系统领域产生了重大影响。CoWoS 技术通过先进的封装工艺，将多个芯片模块高效地集成在一起，从而实现了更高的性能和更低的功耗。这一技术的演进，不仅为芯片设计提供了更多的灵活性，也为系统级应用的优化提供了可能。

然而，尽管取得了这些令人瞩目的技术进展，芯片领域仍然面临着诸多技术挑战。其中，HBM4 的芯片封装技术就是一个典型的例子。虽然 HBM4 提供了更高的带宽和容量，但其封装技术却面临着无凸块的混合键合技术尚不成熟的难题。

除了封装技术的挑战外，架构创新也是芯片领域需要克服的技术难题之一。随着 AI 和 ML 应用的不断发展，对芯片架构的要求也越来越高。如何实现新型架构的高效和稳定运行，成为了芯片设计领域亟待解决的问题。这要求芯片设计师不仅要具备深厚的专业知识，还要具备创新思维和实践能力，以应对不断变化的市场需求和技术挑战。

结束语

过去几年，我们一直在回顾过去一年技术的发展历程并展望未来技术发展趋势。但考虑到这个行业的发展是瞬息万变的，所有的预测和展望可能都是纸上谈兵。而今年，我们可以确切地感受到以 AI 为核心的新时代已经到来。AI 的快速发展和广泛应用，将重塑各行各业，带来无限可能。2025 年，一切都值得期待。欢迎您在评论区分享您的观点和见解。