如果说 2023 年是“震撼”之年，2024 年是“炒作”之年，那么 2025 年将被铭记为 “工程”之年。

过去十年，我们这个行业一直痴迷于数据迁移的机制。我们争论过“ETL vs. ELT”，为了数据表规范而爆发过“格式之战”，我们优化过提交协议，也讨论过各种编排器的优劣。从本质上讲，我们就像数字管道工，确保水能顺利流到水龙头。

但到了2025年，需求发生了变化。企业不再需要“数据”，而是需要“智能”。它需要能够推理的系统、能够行动的代理，以及能够在非确定性世界中保障真理的基础设施。“大数据”时代——即管理数据量——正式结束，取而代之的是“上下文时代”——即管理意义。

我们不再仅仅是数据工程师，我们是认知层的架构师。

以下是定义 2025 年数据与人工智能工程的七大模式。

1. 代理工程：管道的必然演进

2025 年最重要的转变是业界意识到“智能体”不仅仅是花哨的聊天机器人，它们更是新型的计算引擎。2024 年，我们把语言学习模型（LLM）视为文本生成器；而到了 2025 年，我们开始将它们视为推理引擎，执行我们之前用 Python 或 SQL 编写的逻辑。

这催生了一门新的学科：智能体工程。

我们摒弃了早期实验中混乱的“凭感觉”编写代码的方式，转而采用结构化、严谨的工程方法。我们不再问“人工智能能否编写代码？”，而是开始问“我们如何构建一个系统，使人工智能能够可靠地执行复杂的工作流程？”

上下文工程的兴起

智能系统的瓶颈从_模型容量转移_到了_上下文管理_。我们意识到，智能体的智能程度取决于你输入给它的上下文。

Anthropic 凭借其关于有效上下文工程的[1]大师班课程定义了这一年，该课程将其定义为一门专注于管理模型“注意力预算”的学科。仅仅将文档直接放入提示框是不够的。Manus 的工程师们在其关于人工智能代理上下文工程的[2]文章中指出，为了在长期内保持行为的一致性，我们必须在推理过程中对词元进行整理、压缩和动态检索。

我们了解到，“上下文”本质上是一个信息管理问题。我们看到一些团队致力于优化“键值缓存命中率”，并将上下文窗口视为宝贵的内存资源。最终胜出的架构并非模型规模最大的架构，而是能够构建最相关上下文的架构。

智能USB-C：模型上下文协议（MCP）

**历史很可能会将模型上下文协议 (MCP)**的引入视为智能体真正成为可行的企业软件的转折点。在 MCP 出现之前，将逻辑逻辑模型 (LLM) 连接到数据库或 API 是一项定制化且脆弱的集成任务。

2025年，MCP将这种连接方式标准化，使其成为“代理的USB-C”，开发者只需构建一次连接器，即可使其在任何符合MCP标准的模型或应用程序中使用，阿里巴巴在其对MCP功能的全面分析[3]中对此进行了详细说明。然而，MCP的推广并非一帆风顺；TigerData的工程师指出，虽然MCP解决了互操作性问题，但也引入了新的攻击途径，安全性是其致命弱点[4]。

从聊天机器人到同事

最终的验证体现在实际的生产部署中。Uber推出了Genie[5]，这是一款内部智能助手，它不仅能回答问题，还能扮演“接近人类”的领域专家角色。LinkedIn则推出了招聘助手[6]，这是一款利用推测性解码加速推理，从而处理复杂招聘流程的智能助手。

这些并非玩具，而是经过精心设计的系统，具备严谨的编排、状态管理和错误处理机制。业界将“提示链”、“路由”和“并行化”等模式正式化。我们不再将代理视为神奇的盒子，而是将其视为需要全新工程设计的软件组件。

2. “评估”是新的单元测试

如果说代理工程是 2025 年的引擎，那么**评估（Evals）**就是刹车和方向盘。

“感觉编码”时代——即我们仅凭几个输出结果就判断模型是否合格，然后说“我觉得不错”——已经彻底消亡。到了2025年，各组织意识到，如果没有严格的、确定性的测量方法，他们就无法交付非确定性软件。

“法官-LLM法官”模式

如何测试一个每次都给出不同答案的系统？答案是：制造一台机器来给这台机器评分。

行业已普遍采用Judge-LLM框架。Booking.com 提供了一些LLM 评估的实用技巧[7]，例如使用“更强大”的模型（基于人工验证答案的“黄金数据集”训练）来评估“较弱”但成本更低的生产模型的输出结果。Pinterest 也效仿此举，推出了基于 LLM 的相关性评估[8]，用经过微调的 LLM 模型取代了成本高昂的人工标注，这些模型与人类专家的判断高度一致。

这不仅仅是检查“正确性”。我们针对幻觉率、指令执行情况和语气一致性制定了具体的指标。Uber构建了需求遵守系统[9]，该系统从标准操作程序 (SOP) 中提取规则并实时执行，从而将标签发布后的审核工作量减少了 80%。

评估驱动开发（EDD）

“测试驱动开发”（TDD）演变为**“评估驱动开发”（EDD）**。工程师们认识到，无法衡量的东西就无法优化。

基础设施团队将这些评估直接集成到 CI/CD 流水线中。Databricks 分享了他们如何“左移”可靠性评估，通过将模式评分器嵌入构建流程来扩展数据库可靠性[10]，从而在数据质量问题影响生产环境之前将其捕获。

2025年，每位数据工程师都应该明白：如果没有评估指标，那就等于不存在。只有当你拥有能够告诉你所做的更改是让情况好转还是恶化的指标时，你才能称得上是“高效的工程”。

3. Streaming-Lakehouse 合并：Lambda 架构的终结

十五年来，我们一直沿用“Lambda架构”——维护一条快速的流式处理路径（Kafka/Flink）和一条慢速的批处理路径（Hadoop/Spark），并祈祷它们能够匹配。2025年，我们终于将这两条路径合并了。

“Streaming”与“Table”之间的界限消失了。我们进入了“Streaming Lakehouse”时代。

流表二元性

Kafka 的创建者们长期以来一直倡导的“流表二元性”概念，在存储领域成为了现实。诸如Apache Paimon和Apache Fluss等新引擎应运而生，弥合了二者之间的差距。

阿里巴巴力推Apache Paimon，[11]将其作为一种专为实时更新而设计的湖型数据格式，它既能提供流式数据的高吞吐量摄取，又具备 Lakehouse 表的查询能力。Jack Vanlightly 对《理解 Apache Fluss》[12]的深入研究揭示了一个将日志表和键值表相结合的系统，有效地创建了一个将自身变更日志作为一等公民公开的数据库。

我们不再争论“流式处理与批量处理”，而是开始设计架构，该架构只需摄取一次数据，即可立即用于实时操作查找和历史分析查询。

零拷贝之争

然而，这次合并并非一帆风顺。当年的热门词汇是“零拷贝”——它承诺你可以将数据仓库指向 Kafka 主题并进行查询，而无需移动任何字节。

但经验丰富的工程师们提出了反对意见。WarpStream 使用 Iceberg 原生数据库[13]，声称将操作消息总线直接耦合到分析引擎违反了关注点分离原则。

最终达成的共识是？“零复制”非常适合临时探索，但对于生产环境而言，物化（创建副本）仍然是实现性能和隔离的代价。

无盘 Kafka 和云原生日志

就连 Kafka 本身也未能幸免于现代化浪潮。社区积极响应KIP-1150（无盘主题）[14]提案，该提案旨在为云时代重新设计 Kafka 架构。

我们意识到，在 S3 Express 和高速网络时代，将数据存储在本地代理磁盘上是一种成本高昂的过时做法。流媒体的未来在于“默认分层存储”，其中代理仅作为无限对象存储之上的缓存层。这种转变有望大幅降低成本，并使“无限保留”流媒体成为一种标准架构模式。

4. 效率反革命：小数据与锈蚀

当人工智能团队在GPU上挥金如土时，数据基础设施团队却悄然发起了一场反革命。多年来，我们默认使用庞大而昂贵的分布式集群（Spark/Hadoop）来解决所有问题，而2025年，我们终于决定调整计算规模，使其更加合理。

我们意识到，“大数据”工具对于“中等数据”问题来说有点杀鸡用牛刀了。

单节点复兴

“这真的需要一个 50 节点的集群，还是只需要一台性能更强的笔记本电脑？”

这个问题彻底颠覆了整个行业的现有流程。DuckDB和Polars等工具从“分析师的宠儿”摇身一变，成为“生产主力军”。迪卡侬分享了一个爆款案例研究，展示了他们如何利用Polars 轻松上手[15]，用 Polars 脚本替换庞大的 Spark 集群来处理 50GB 以下的数据集，并将基础设施成本削减至接近于零。

Daniel Beach 的基准测试证实了这一点，结果表明，对于650GB 的数据（S3 上的 Delta Lake）[16]，单节点引擎通常能够胜过分布式集群，原因很简单，就是避免了网络开销。我们不再对“垂直扩展”感到羞耻，而是将其视为 FinOps 的一项胜利。

Rust 重写

当我们需要高性能时，我们选择了Rust。

Agoda 解释了他们为何选择 Rust 来大幅提升其特征库的性能[17]，从而实现了 5 倍的流量容量增长。

教训很明确：“Java税”确实存在。对于关键的、低延迟的基础设施而言，Rust的安全性和性能值得我们付出学习成本。我们正在进入一个新时代，数据工程的基础工具正在用Rust逐一重建。

FinOps即架构

效率不仅仅体现在代码上，还体现在架构上。Wix 记录了他们如何通过将工作负载从托管服务 (EMR) 迁移到 Kubernetes (EKS) 而不是重写代码，从而将Spark 成本降低了 60% 。[18]

我们发现，如果不加注意，“无服务器”往往意味着“无钱包”。到2025年，最聪明的团队是那些积极优化计算基础架构，尽可能将工作负载迁移到竞价型实例、ARM处理器和单节点容器的团队。

5. Lakehouse 2.0：目录即新数据库

2020 年代初期的“格式之争”（Iceberg、Delta 和 Hudi 之争）在 2025 年基本达成和解。随着互操作性层的兴起，我们不再关心数据文件夹结构。

战场转移到了“技术栈”上方的目录层。我们意识到，“Lakehouse”只不过是一个翻转过来的数据库，而目录层则是它的操作系统。

目录之战

到 2025 年，目录不再仅仅是“表列表”，而是成为企业的主动控制平台。

DuckLake[19]等新概念挑战了现状，提议我们使用 DuckDB 本身作为目录和元数据层，用轻量级的事务数据库取代笨重复杂的 Hive Metastore。

超大规模数据中心（AWS、Snowflake、Databricks）纷纷转向托管式 Iceberg 服务。正如《开放表格式革命》一[20]书中指出的那样，主要厂商不再抵制开放格式，而是开始试图掌控管理该格式的元数据层。其价值主张也从“我们存储您的数据”转变为“我们管理您的交易”。

6. “上下文”供应链：非结构化数据和知识图谱

几十年来，数据工程一直关注的是行和列。到了2025年，我们必须精通文本、图像和关系的处理。为了支持GenAI革命，我们必须构建上下文供应链。

我们不再只是传输数据；我们是在传输_意义_。

知识图谱回归

2025年最令人惊讶的回归当属知识图谱。当我们还在为LLM（逻辑学习模型）的种种幻象而苦恼时，我们意识到概率模型需要确定性的事实作为支撑。

Netflix 详细介绍了其统一数据架构[21]，以及如何利用知识图谱解锁娱乐智能[22]，为其人工智能模型提供“真理来源”。

我们了解到，“RAG”（检索增强生成）不仅仅是向量搜索，而是“GraphRAG”——利用数据点之间的关系为模型提供更丰富、更准确的上下文。

嵌入流程

数据工程师必须掌握一种新型的转换：嵌入。

我们不再局限于简单的“Word2Vec”教程。Milvus发布了关于如何为RAG选择合适的嵌入模型的[23]指南，帮助团队针对特定领域在LLM2Vec、BGE-M3等模型中进行选择。我们构建了能够对文档进行分块、生成嵌入并将其存储在向量数据库中的流程，并将“语义距离”视为一种重要的数据类型。

非结构化数据管理

我们正式将大规模非结构化数据管理[24]确立为一项核心竞争力。Piethein Strengholt 认为，仅仅将 PDF 文件上传到 S3 存储桶是不够的；我们需要像管理财务报表一样，对这些数据进行解析、清理、分块和管理。

“奖章架构”（铜/银/金）被调整用于非结构化数据。我们开始讨论“原始文档”（铜）、“解析和分块文本”（银）以及“精选嵌入”（金）。

7. 治理 2.0：自主代理的安全刹车

随着人工智能代理开始采取行动——预约面试、执行代码、修改数据库——治理不再是“合规性检查”，而是变成了“安全刹车”。

2024年，如果仪表盘数据出错，意味着管理者做出了错误的决策。2025年，如果代理程序出错，则可能导致生产数据库被删除，或个人身份信息泄露给竞争对手。

隐私感知基础设施

Meta 公司撰写了关于大规模数据溯源和用途限制的[25]文章。他们不仅编写策略，还编写了代码来跟踪数据溯源，并在 EB 级规模上强制执行用途限制。Meta 引入了策略区域，[26]以确保未经明确许可，为某一目的（例如安全）收集的数据不能用于其他目的（例如广告定向）。

这种精细程度代表了未来。我们正朝着这样的系统发展：每条数据都拥有自己的权限“护照”，每个代理都必须出示“签证”才能访问它。

影子人工智能和新边界

“影子人工智能”（工程师启动本地 LLM 或使用未经批准的 API）的兴起迫使数据团队加强了边界。

我们见证了数据契约作为一种防御机制的出现。Grab 为其 Kafka 数据流实施了严格的契约机制，实现了实时数据质量监控[27]，确保不良数据在污染下游 AI 模型之前就被剔除。

2025年的治理核心在于可观测性。它需要确切地知道哪个代理访问了哪个文档，为什么访问，以及它对文档做了什么。

结论：上下文工程师时代

回顾 2025 年，数据工程师的角色显然已经发生了根本性的变化。

我们不再仅仅是构建将数据从 A 点传输到 B 点的管道，我们正在构建企业的认知神经系统。

• 我们是 智能体工程师，负责设计让人工智能能够推理和行动的工作流程。

• 我们是 评估架构师，致力于构建确保人工智能诚实的指标体系。

• 我们是 上下文工程师，确保我们数据的“意义”得以保存和访问。

• 我们是 效率专家，在GPU价格昂贵的今天，我们致力于最大化每一次计算周期的投资回报率。

工具会不断变化。Spark 可能会被 Polar 取代；Kafka 可能会被对象存储取代。但_工程学的_严谨性、测量和架构理念却比以往任何时候都更加重要。