告别传统存算分离，AI时代数据底座迎来全新底层逻辑
但当企业真正开始推进 AI 项目时，很多人很快发现了一个尴尬的现实：Demo 永远惊艳，生产总是难产。这不是模型的问题，也不是 Prompt 的问题——真正决定一个 AI 项目能不能从"跑通"走向"跑稳"的，是背后那套看不见的基础设施：它能否接住多模态数据的爆炸式增长？能否支撑从训练到推理再到反馈的完整闭环？能否让 Agent 真正找到并用好企业沉淀的数据资产？
传统大数据平台为什么开始显得不够用了？面向 Agent 时代，新一代 AI 基础设施到底需要重建哪些能力？在火山引擎 FORCE 大会上，火山引擎数智平台产品总监 王彦辉给出了他的判断：“企业级 Agent 的落地，正在推动数据平台迎来一场深刻的变革——服务对象，正在从人变成 Agent。”他在会上系统阐述了 Agent DataLake 方案，试图回答一个核心问题：如何让企业数据真正流向智能体，从而转化为可感知的业务价值。带着同样的问题，我们与王彦辉及火山引擎数智平台技术总监丁远普展开了一次深度对话，从数据形态、计算范式到产品化路径，试图把答案挖得更深、看得更远。
值得一提的是，王彦辉将在 6 月 26 日至 27 日的 AICon 全球人工智能开发与应用大会上，出品了《AI 原生数据工程》专题论坛，围绕"数据如何定义模型能力"这一核心命题，系统拆解从训练到推理、从生产到反馈的全链路数据闭环。如果你对本文话题有更深的兴趣，那场论坛值得关注。
丁远普：总体来看，主要存在两类问题。
第一类是数据够不着的问题。很多企业的内部数据散落在各个系统中，在用 AI 或 Agent 接入时难以整合。数据不完整，整体效果自然会大打折扣。这本质上是数据打通与治理的问题，而非模型本身的局限。
第二类是模型用不好的问题。基础模型本身能力很强、迭代也很快，但它是高度泛化的模型，可以类比为 CPU、GPU 这样的通用计算能力——模型提供的 Token，可以视为第三种算力。
举两个典型例子：
PDF 处理场景：如果业务人员直接用通用模型处理 PDF，效果大概率不佳。通用模型不会针对 PDF 进行专项优化和适配，而 PDF 版面复杂、多栏、图文混排，缺乏专项处理效果自然差。此外，PDF 处理本身是一条很长的链路，前后都需要专业的数据处理环节。综合来看，直接用通用模型做 PDF 解析，效果会相当有限。
视频剪辑场景：基础模型直接用同样困难。视频有帧结构、动画、多镜头衔接等复杂特性，仅凭一段提示词，模型很难精准理解意图并完成视频处理需求。和 PDF 类似，视频处理也需要完整的前置和后置链路，才能达到理想效果。
综合来说，AI 落地并非简单选一个模型进行一次调用就能完成，而是一个数据 + 算法 + 工程的系统性问题。模型可以视为发动机或大脑，其他的则是底盘、变速箱、油路，综合起来构成一套完整的数据底座体系。
王彦辉：补充一点：业务联系不够紧。当前模型与客户实际业务落地之间的结合点还相对较远。企业在将 AI 与业务结合时，不同业务场景的优先级、重要性各有差异。
目前存在一个关键问题：客户现有的数据基建是围绕"给人使用"来构建的，而面向 AI Agent 的数据基建与此差异较大。这导致各个层面的口径不一致，真正落地到业务时，往往会出现较大的效果偏差。
丁远普：传统大数据技术更多是围绕结构化数据构建的，虽然也涉及半结构化、非结构化数据，但占比很少，企业真正落地的仍以结构化数据为主。
进入 AI 时代，最大的变化体现在以下三个方面：
第一，数据形态变了。 结构化数据的特点是 schema 明确、行列清晰。而在 AI 时代，图片、音频、音视频、长文本、3D 模型等多模态非结构化数据大量涌现，没有明确的 schema，且在企业中占比极高。传统加工方式面对非结构化数据，基本面临三大困境：看不见、管不了、算不动。例如，很难将一个视频存入 Hive 表（即使通过 URL 方式存储，也极为生硬），也无法通过 SQL 进行语义查询，比如查询视频画面中的内容。
第二，计算模式变了。 传统大数据的算力以 CPU 为主，现在已演进为 CPU + GPU + Token 的混合算力模式，且 Token 算力的占比越来越大。尤其是多模态数据的处理，如音视频的理解与生成，都依赖大模型的 Token 算力。沿用传统架构，实际上无法有效处理这些多模态数据，或者效率极为低下。
第三，数据管理的维度大幅扩展。 以前的数据管理相对简单，无非是库表、字段、分区，能够抽象出一套清晰的元数据管理范式。但现在由于数据形态的变化，整个数据管理的复杂度大幅提升：多模态数据如何管理？数据来源是什么？当前状态如何？质量评分怎么衡量？对应的模型版本是什么？数据血缘关系怎么追踪？这些维度的复杂程度远超传统大数据时代。
综上，传统基础设施已难以承载 AI 场景的需求，整体架构升级势在必行。
王彦辉：这里用一个形象的类比来补充。过去我们常把数据比作石油，对比一下过去和现在的使用方式，差异就很直观了。
以前的应用形态，如面向人的 BI 报表和推荐系统，更像是需要轻质油——汽油、柴油这类。过去的数据基础设施正是围绕这些处理方式和应用对接需求构建的。
而现在，我们需要大量处理非结构化数据，它的价值密度较低，更像是重油。重油的提纯方式、处理方式以及面向应用的对接方式，都发生了很大变化。这也正是丁远普提到的几点变化：数据形态改变了，计算模式从 CPU 转向 GPU，再到现在通过模型处理 Token，由此产生了多模态数据湖的算子能力。
在数据管理层面也有新的演进：以前管理的重点，一是建立清晰的口径，二是做好成本治理。现在进入了第三个阶段——让 Agent 能够发挥自身价值，与业务深度结合，并能主动找到合适的数据。
总体来看，原来是一条以轻质油为核心的生产、消费、加工产业链，现在既需要轻质油，也需要重油，整个产业链发生了根本性的变革。
丁远普：共性方面，两个视角共同需要三点：多模态数据的统一存储与管理、异构的弹性算力（尤其是 Token 算力，我们认为 CPU 和 GPU 已属于上一代算力形态），以及多模态的数据质量保障。
差异方面，两个视角各有侧重。服务模型（如基础模型预训练）的场景，数据量极大，且以批次形式到来，可能每半个月或一个月到达一次。每次数据到达后时间窗口很紧，需要在短时间内完成大量数据的清洗、处理和标注，为模型训练做好准备。服务 Agent 的场景则不同，对数据量级的要求相对较低，基础设施的诉求更偏向轻量化和灵活性，关注的是如何以更少的资源、内存和计算开销来运行，而非承接大规模数据处理型的工作流。
从客户需求来看，两者同样有明显区别。服务模型的基建主要面向 AI 团队或算法团队，核心任务是数据准备；而服务 Agent 的基建，通常面向业务团队。业务团队不关心底层基建细节，更希望 Agent 好用、易用、可靠——不要频繁出问题、不要产生幻觉、不要丢失上下文记忆。
关于多模态数据湖为什么是 AI 时代的数据底座，以 LAS 为核心的多模态数据湖产品体现在三个核心能力上。
第一，提供多模态数据的存储与管理能力。我们在产品中引入了 Lance 数据格式，在国内这一方向上积累深厚。Lance 格式能为 AI 场景提供良好的大 Blob 数据存储，支持零成本动态加列和高性能随机访问——这对 AI 场景非常友好，因为业务方随时可能需要新增字段，而无需预先定义。
第二，提供以 Token 为新型算力的算子能力，涵盖 PDF 解析、视频编辑、爆款剪辑等多种模态数据的处理能力。
第三，在算子之上构建了面向业务的应用层。算子本身是较为通用和原子化的能力，但实际面向客户时，很多业务人员并不擅长调用 API，因此我们在算子之上封装了面向行业和垂直领域的应用层，如电商场景的视频编辑、传媒与文娱领域的多种应用，业务人员可以直接使用，无需具备技术背景。这三个层次，构成了我们认为适配 AI 时代的数据底座。
王彦辉：从服务模型和服务 Agent 这两个维度来补充，我认为这代表了两个不同阶段：一个是面向训练环节，从模型侧来看；另一个是面向推理环节——推理早期是纯对话模式，现在进入 Agent 时代，Agent 需要调用各种工具，包括数据类工具和 Sandbox。
我们认为在 Agent 时代，Harness 非常关键。Harness 的核心构成包括 Sandbox 以及数据——数据是定制化的源头，是个性化能力发挥的重要起点。用户的对话、session 和记忆，是模型后续不断迭代、提炼个人价值与用户画像的重要基础。此外，多模态数据湖涵盖湖管理、湖计算、湖存储、湖分析和湖检索几个方向，共同构成了 AI 大时代下数据基础的完整体系。
丁远普：硬性条件的思路与前面提到的一脉相承，核心涵盖三块：多模态数据的统一存储与管理能力、异构弹性算力（尤其是 Token 算力），以及多模态数据质量保障。其中最难补的是中间这一条，也就是以 Token 为新型算力的算子能力。原因在于，这不是简单采购硬件或搭建存储就能解决的问题，需要对模型有很深的理解，还要结合具体业务场景进行封装和优化，是一项系统性工程。
王彦辉：除了远普刚才提到的资源和管控能力之外，上面的平台能力和生态能力建设要是非常重要的，尤其生态链接的能力。平台能力包括几个方面：
第一，能统一管理结构化、非结构化、实时流、日志、文档等多模态数据的数据资产管理能力
第二，业务语义的定义，业务是为人服务的，所以要有清晰的语义层和元数据体系，让模型理解数据含义、指标口径、质量和权限边界
第三，要支持实时数据处理和反馈闭环，让 AI 不只是回答问题，而能持续优化决策，也就是 AI 可观测和评测能力的建设
第四，要具备安全、合规、审计和权限控制能力，确保 AI 在企业环境中可控使用
AI 生态，特别是数据生态差异比较大，但值得重点关注的是要结合企业数据平台建设的阶段和沉淀以及业务发展阶段因地制宜的考虑。
丁远普：坦率地说，我们在实际客户场景中遇到写入和检索同时高并发发生的情况相对较少，但可以从我们的技术实践角度谈一些相关思考。
在检索与写入层面，以 LAS 为核心的存储格式能够对多模态数据进行统一处理——无论是标量数据的写入、向量的存储，还是全文检索，都可以在同一套体系中支撑。LAS 之所以被称为"多模态"，也正体现于此：除了能够存储大字段，还可以将音视频、图片乃至点云数据向量化后存入 LAS 格式，从而支持混合检索。
在检索与写入层面，以 Lance 为核心的存储格式能够对多模态数据进行统一处理——Lance 格式不仅能够存储标量数据，还可直接存储音视频、图片乃至点云等多模态非结构化数据，支持将这些数据向量化后与原始数据一同存入；同时它具备成熟的全文检索能力，可实现向量、全文与标量的混合检索。
我们观察到较多的实际需求，是如何在一套极简的数据架构下，同时承载多种查询检索的工作负载。例如，将标量数据和向量数据统一存入 Lance，查询时既可以通过 Lance 自身提供的查询模式访问，也可以通过 ByteHouse 这样的分层数据库来查询，同时支持标量查询、向量查询和全文检索。
丁远普：最容易走偏的典型路径，是"堆乐高"式的思维——简单罗列和拼凑技术栈。比如原本用传统格式存储数据、用 Hive 做数据处理，需要向量能力时再引入一个向量数据库，越堆越多。底层技术架构越复杂，所需消耗的运维人力也就越多。这种简单叠加的思路，很容易偏离正确方向。我们更期望的是，能够站在当前 AI 的实际诉求上，重新审视底层架构应该如何变革，而不是进行简单的技术拼接。
另一个容易走偏的点是盲目对标：很多企业看到外部头部公司搭建了大型数据平台，便照搬规划一套同等体量的平台，但这类方案在实际落地中往往很难推进。
王彦辉：第一，要结合自身实际情况，因地制宜。不同企业在数据化能力、基础设施积累上差距悬殊，不能简单套用别人的路径。我们整体的思路是以消除数据孤岛为目标。很多客户在过去就积累了大量数据技术债，进入 AI 时代同样面临这一问题——非结构化数据散落各处，缺乏统一的流转和处理加工机制，治理工具也不完善。在这种情况下，应当结合自身的 AI 战略来制定数据策略，明确在哪些方向重点发力，在哪些方向做中长期布局，并确定优先级顺序。
第二，我们观察到，很多客户在推进时倾向于自下而上地推进，优先从存储开始。理由是：数据先存下来，当未来真正需要使用时，随着计算能力和治理能力的成熟，数据资产的价值才能逐步被开发出来。因此，存储是相对最关键的起点。
总结起来就是这个思路：因地制宜、通盘规划、从底层往上走。当然，通盘规划并非意味着做大而全的顶层设计，而是要在不只解决单点问题的前提下，把握好节奏与颗粒度，这中间有一个度的把握。
丁远普：我更想回答的其实是"用模型来处理数据"与"用 CPU、GPU 来处理数据"之间的差异，因为这个视角更为关键。
最大的差异在于计算方式的根本性转变。以前用 CPU 处理数据，工作负载基本上是规则引擎驱动的，通过 Spark、MapReduce 这类分布式引擎来处理，开发者写 SQL 或编写处理程序来完成任务。而基于模型处理数据，整个计算方式发生了较大变化——不再是写程序或 SQL，而是编写提示词。这个范式的转变相当显著。
当前各厂商提供的基础模型能力已经相当强大，最轻量的使用方式就是直接调用云上的 Token 算力——这是最轻资产的模式，不再需要像以前一样采购服务器、购买裸机 ECS。从这个角度看，以 Token 算力对比传统 CPU 和 GPU，整个基础设施反而会变得更简单、更轻量，这是一个很大的转变。
在存储方向，AI 时代的数据处理基础设施同样离不开存储，而且存储在 AI 时代相比计算变得更加重要了。计算侧，原本需要 CPU 和 GPU 以及各类计算引擎完成的大量工作，现在很大一部分被模型替代。但存储不同，其重要性反而在提升——尤其是多模态数据大量涌现后，音视频数据体量更大，对存储基础设施的承载能力要求更高。此外，单纯的文件存储或对象存储已不够用，还需要向量存储能力、Agent context 存储能力等。这也是底层基础设施在新时代呈现出的重要差异之一。
王彦辉：从用户使用视角来补充。过去用户使用数据的标准范式是 SQL，复杂些的用 Python。到了模型时代，交互方式转变为提示词，这对用户的模型认知要求大幅提升——需要了解模型具备哪些能力，以及如何才能更好地发挥模型的价值。
从基础设施建设的角度看也是如此。当我们以模型作为底层算力来构建基础设施时，需要对模型有深入理解，才能为用户提供更简洁的使用体验——用户只需输入一句话，系统便能在后台根据其意图进行扩写和改写，从而获得更好的效果。
丁远普：裸调模型并非不能完成任务，但对使用者的模型理解能力要求极高。以我之前举的 PDF 解析为例，自己裸调模型实现一套完整的 PDF 解析链路是非常复杂的。简单的 PDF 也许能快速处理，但企业中的数据往往相当复杂，尤其是一些传媒企业的 PDF，版面结构类似报纸，多栏排布且各栏格式不一。在这种情况下裸调模型，从我们实际接触的客户来看，很难达到理想效果。
因此，越来越多的平台开始将这些能力封装为算子，为使用者提供更便捷的路径。在云上提供算子服务这一方向，我们是较早进行布局的。后来很多企业看到这一路径的价值，也逐步跟进，认为算子确实能有效提升基于模型的数据处理能力和效果。
算子化的价值主要体现在两个方面：
一是能力复用。基于垂直领域封装好一个算子（如 PDF 解析），便可在企业内部多个团队和业务中直接复用，无需每个业务线各自开发一套。从零开发本身成本较高，而且不同团队能力参差不齐，效果也难以保持一致。
二是稳定性保障。裸调模型时，容错处理需要自行实现；而调用我们的接口，API 层面的抖动、限流，以及模型升级带来的兼容性问题，都可以在算子层内部消化掉，用户无需关注。
关于什么时候该追求灵活、什么时候必须走产品化，我们的观点是：任何时候都应该走产品化——这也是我们一直坚持的方向。
王彦辉：我觉得这两种方式的核心差别，不在于“是否调用大模型”，而在于企业把 AI 能力当成一次性工具，还是当成可复用、可治理、可规模化的生产能力。
“裸调模型”的优势是灵活，适合快速验证。比如一个新场景刚出现，任务边界还不清楚，抽取字段经常变化，业务专家还在探索规则，这时候直接用 Prompt 加模型 API，迭代速度最快。但它的问题也很明显：效果依赖个人经验，输入输出不稳定，质量难评估，成本难控制，出了问题也很难追溯。它更像实验室能力，而不是企业级生产能力。
标准化算子的价值，是把抽取、清洗、分类、理解这些能力产品化。每个算子都有明确的输入输出、参数配置、质量指标、版本管理、权限控制、日志审计和异常处理。这样 AI 能力才能被不同团队复用，进入数据链路、业务流程和平台体系，形成稳定交付，而不是每个项目重新写一套 Prompt。
我认为是在场景早期、需求不确定、低频使用、结果主要辅助人工判断的时候要追求更灵活，快速是错。这个阶段要鼓励探索，避免过早平台化。
当一个能力开始高频调用、影响核心业务决策、被多个团队重复使用，或者涉及合规、安全、成本和 SLA，就必须沉淀成算子，做平台化的能力。因为企业级 AI 落地最终比拼的不是谁能做出一个 Demo，而是谁能把有效能力稳定、可控、低成本地嵌入业务系统。产品化的本质，算子对客户最直接的价值，是让模型的使用变得更简单。基础模型提供的是高度泛化的能力，企业如果直接使用，需要在其上做大量的工程和业务适配工作。
这个演进过程其实和大数据领域的发展脉络很像：最早需要自己实现分布式计算逻辑；有了大数据基建之后，分布式的复杂性被屏蔽，只需写业务处理程序；后来 SQL 出现，进一步降低了使用门槛。AI 领域的演进路径与此类似——模型提供了类似 CPU、GPU 的底层算力，而我们的算子则站在更贴近业务和领域的角度，将能力封装好、建设好、开放出来，用户直接调用即可，调用成本大幅降低。
从成本维度看，综合算上人力投入，我们认为算子能够帮助企业实现降本；从易用性和业务上线效率来看，产品化的算子同样带来显著提升。
目前企业使用较多的算子类型中，文档类（如 PDF 解析）普适性最强，几乎各行各业都有需求，企业要么基于开源自研，成本较高且效果不稳定，要么直接调用我们的算子，简单高效。视频类算子我们也做了很多布局，涵盖剪辑、爆款素材提取、商品视频编辑、人物编辑等场景。此外还有超分能力，例如基于 Seedance 2.0 生成低分辨率内容后，通过我们的算子进行超分，可以大幅降低用户使用 Seedance 2.0 的成本。
在计费方式上，不同算子有各自独立的计费项。PDF 类按页计费，视频类算子多数按时长（处理时长或生成时长）计费，也有少数算子仍以 Token 方式计费。总体方向是，我们希望越来越多的算子能够以业务单位来计费（如页数、时长），而非将 Token 直接暴露给用户——Token 对大多数业务人员来说不直观，也不易理解。
王彦辉：
从产品化角度看，算子的价值绝不只是“把模型能力封装一下”。如果只是把 Prompt 包成一个接口，那还停留在技术封装层；真正的算子，是把不稳定、难复用、难治理的模型能力，转化为企业可以配置、编排、观测和规模化交付的产品能力。
它带来的第一层价值是稳定性。企业不可能接受每个项目都靠工程师手写 Prompt、手工调参。算子需要定义清楚输入输出、参数、版本、质量指标、异常处理和回退机制，让 AI 能力进入生产链路。
第二层是成本控制。模型调用成本、上下文长度、并发、缓存、批处理、大小模型协同，都需要在算子层被产品化管理。否则企业越用 AI，成本越不可控。
第三层是复用效率。抽取、清洗、分类、匹配、总结、质检这些能力，本质上会在不同业务里反复出现。算子化之后，平台可以把最佳实践沉淀下来，让业务团队通过配置和编排复用，而不是每次重新开发。
第四层是交付方式的变化。过去 AI 项目往往是定制化交付，一个场景一个方案；算子化之后，平台可以用“标准能力 + 场景配置”的方式交付，大幅降低规模化复制的难度。
不同客户的诉求也会不同。数据和 AI 成熟度高的大型企业，更关心算子的可治理性、可观测性、权限、审计、SLA，以及能否纳入现有数据平台和流程体系。中型企业更关注开箱即用、成本可控、上线速度和业务效果。行业客户，比如金融、政务、医疗，会更重视合规、安全、可解释和过程留痕；互联网和零售客户则更关注高并发、实时性、A/B 测试和快速迭代。
所以算子的本质，不是模型接口，而是企业级 AI 能力的产品单元。它把模型能力从“能用”推进到“可管、可复用、可交付、可规模化”。
丁远普：AI 领域都在讲数据飞轮，但存和算如何形成闭环，在不同阶段的答案并不相同——模型预训练阶段、后训练阶段，以及 Agent 阶段，各自的机制都有所差异。
单就 Agent 阶段而言，数据本身在持续产生。已有的数据可以构建成知识或记忆，注入 Agent；随着用户使用 Agent，又会不断生成新的问答对，形成新的数据，这些数据会持续沉淀到 Agent 底层的数据存储中，转化为知识和记忆，再反馈给 Agent。这样，在 Agent 层面也形成了一个数据闭环，持续运转。模型的预训练和后训练阶段，同样存在类似的飞轮机制。
王彦辉：刚才提到数据沉淀，以前数据主要给人使用，沉淀方式是通过用户行为形成行为日志，再输入推荐平台，产出推荐结果。而现在，很多数据沉淀发生在人机交互过程中——作业执行记录、对话 session turn、Agent 执行结果等，都是重要的数据来源。
这些数据当前一个非常关键的应用场景是评测——这是以前所不具备的能力。过去执行 SQL 或推荐系统的结果虽然也有不确定性，但有明确的业务指标可以挂钩验证。现在，模型的能力表现与 Agent 的执行过程高度相关，结果具有更强的不确定性。这带来一个新的视角：如何让人、或让模型、或让整个 Agent 去理解自身的执行过程？这就需要引入评测机制。
两年前，评测主要依靠人工来完成；现在越来越多的评测由 Agent 自主完成——提出需求，Agent 自行做规划和执行，再由 Agent 对执行结果进行自评，给出推断性的反馈，而不再是像以前一样输出一个确定性的结果供人查看。SQL 执行会生成一张确定性的报表，而现在很多执行结果是不确定的，数据基础设施也需要更多地面向这种不确定性来设计和准备。
这是 AI 时代在数据应用层面一个非常重要的变化——面向评测场景的数据应用，从数据节点的角度来看，意义尤为突出。
丁远普：首先，存储会成为标准层。 在 AI 时代，存储不但没有过时，反而愈发重要。无论是底层的文件系统还是对象存储，都在持续扩展新能力以支撑 AI 场景的需求。从我们的观察来看，国内外的厂商在存储方向都在面向 Agent 做布局，典型的是多家云厂商都在跟进支持了 Lance 存储格式；Agent 架构中首选开放存储，一份数据支持 AI 不同的 workload。
其次，结构化分布式计算依然重要。但在面向 Agent 的企业基建中，基于 Spark、Flink 的大规模分布式计算会对 Serverless 形态会有更强的诉求，企业无需自建团队维护分布式引擎、也会逐步减少数据开发的投入，更多的交给 Agent、交给提示词。
另外，向量检索能力会持续沉淀为标准能力，这一方向相对已较为成熟。
再者，算子层也呈现出明显的标准化趋势。越来越多的厂商开始在模型之上构建更贴近业务的能力层，解决模型到业务落地之间的"最后一公里"问题。当然，仅靠算子可能还不够，我们在算子之上还进一步做了应用层的封装，或者以 Skill 的方式将算子推送到 Agent 中发挥价值——不过这一层已超出严格意义上的基础设施范畴。
最后，GPU 不一定会成为各家基础设施的标配，但模型付费能力一定是。 GPU 本身供货紧缺，对大多数企业而言也是重资产——无论是采购云上 GPU 还是自建 IDC，投入都较大。从成本 ROI 来看，直接购买 Token、调用算子、配合存储，是更轻量也更合理的路径。这是我们认为会逐步形成标准层的几个方向。
高度分化的部分，更多集中在偏业务的领域层。云厂商通常不会深入到用户极少的垂直细分场景，因为需要考虑规模化复制和投入产出比。因此，医疗、金融等高度专业化的行业数据诉求，仍将长期保持分化状态——这些领域可能更适合由专注该行业的企业来承接，对于我们这类平台型厂商而言，这一层更多是泛化能力的体现。
王彦辉：我认为这其中最大的变量是模型的能力。模型能力之下，数据存储是能够形成标准的，这一点我与丁远普的判断一致。
但模型能力之上，变化会非常剧烈。 两三年前，Agent 能力尚不具备，围绕推理的计算形态相对单一；模型能力提升后，Agent 能力逐步成型，从短任务 Agent 演进到能够执行长时复杂任务的 Agent，又是一次形态跃迁。所以，模型之上如何使用模型、如何与模型交互，这一层的变化速度会非常快，难以形成稳定的标准。
这也意味着，越靠近模型之上的能力层，越需要保持敏捷和开放，而越靠近底层的存储与数据管理，越有机会沉淀为长期稳定的基础设施标准。
会议推荐
AICon 上海站 4 大核心看点：Keynote 前瞻洞见、Agent 工程化专题拆解、前沿技术 + 产业落地全覆盖，Google Cloud 专家实操带练。更多详情可扫码或联系票务经理 13269078023 进行咨询。
