AI Agents 在数据工程中的应用：生产环境中的实际效果

半夜时分，一条流水线发生了故障。有人收到了传呼。那个人睡眼惺忪地打开笔记本电脑，开始重复上一次发生这种情况时所做的完全相同的事情。你检查日志，滚动查看了好一会儿，找到了错误。然后真正的挑战来了：上游发生了变化吗？你打开模式定义，果然，六小时前一个好心的队友重命名了一个列。于是你追踪依赖于它的项，编写修复程序，重新运行，然后爬回床上睡觉。

我已经记不清做过多少次这样的事了，有一点终于让我受够了。几乎所有这些工作实际上都不是工程。它是模式匹配和苦力活。真正的思考，即“正确的修复方法是什么”的部分，可能只占你花费时间的十分之一。剩下的时间都在第一百次重复同样的步骤。

智能体（agents）正开始填补这一差距，它们不是要取代我们，而是接管工作中那些乏味、重复的中间环节，以便我们可以把时间花在需要判断力的部分。因此，当人们称 AI 智能体为“数据工程的下一次进化”时，我实际上是同意的，尽管原因可能不同于你在 LinkedIn 帖子上看到的那些。让我解释一下我的意思，更实用的是，向你展示我们构建了什么，以及在此过程中出现了什么问题。

智能体究竟是什么

快速定义一下，因为这个词被用得很随意。脚本执行你告诉它的操作。LLM 调用回答一个问题后就停止。智能体则走得更远。它可以感知某种状态，对其进行推理，选择工具，采取行动，观察结果，然后决定下一步做什么。它循环运行，随之选择工具，并朝着一个目标努力，而不是执行单一指令。如果你想要一个正式定义，它是一个在设定的限制内追求目标并自主行动的系统。

在数据工程语境下，“工具”意味着读取日志、查询元数据目录、运行 dbt 命令、查找血缘或开辟 Jira 工单。智能体靠自己将这些环节串联起来以达成目标。这就是全部诀窍。它不是魔法，一旦你不再被“智能体化（agentic）”这个词吓到，它就不那么复杂了。

为什么数据工程正面临瓶颈

数据、流水线和下游消费者都在不断增长。员工人数的增长速度却跟不上。从来都跟不上。因此，现有工作量与可用人力之间的差距越来越大。当你审视工程师们实际把时间花在哪里时，大部分都落在了排查故障、编写看起来与上一个转换非常相似的样板转换代码，以及在有人询问数字来源时进行血缘考古。

这三者都是重复性的且具有模式化的，而这正是智能体可以首先尝试处理的。这是一个真正的转变，而不是一种流行周期，因为它映射到了实际的工作负载问题，而不仅仅是一种感觉。

我们究竟构建了什么

在我工作的数据工程平台上，事件响应成本是整个团队的问题，而不仅仅是一个小组的问题。流水线断裂，人员收到传呼，资深工程师在遵循可预测模式的故障排查上浪费时间。因此，我构建了一个基于智能体的系统来处理事件调查的第一步，供整个数据工程团队使用。

这不是一个“开启后就走开”的情况。智能体是基于提示（prompt）的，真正的工作在于配置：你将它们挂载到已经持有答案的工具上，如 PagerDuty、GitHub、用于日志的 AWS CloudWatch、Datadog 等，这样系统在问题触发的那一刻就拥有了调查所需的一切。在提示语本身中，你定义了规则、你希望它如何工作，以及它应该遵循的技能和标准。不过，提示语并不是行为存在的唯一地方。智能体还可以直接从 GitHub 仓库读取技能文件，因此你无需将每条规则都塞进提示窗口，而是指向它在需要时拉取的版本化技能文件，例如它在起草拉取请求（pull request）时遵循的标准。这使得指导原则在源代码管理中保持可维护和可审查，而不是埋在提示语中。