数据Agent将制造机器查询洪峰，传统数仓面临新负载

过去一年，代理（agent）在软件领域几乎无处不在，但有一个明显的例外：数据领域。这有点奇怪，因为查询数据正是代理擅长的、结构化且可核查的任务。最可能的原因是时机。大语言模型在编写SQL方面只是最近六到九个月才真正可靠，该领域尚未完全意识到这解锁了什么。值得区分这个想法的两种不同形式：执行分析的代理，以及帮助你管理数据管道的代理。事实证明，这两种代理都比它们最初看起来更有用。做分析，以及帮你处理数据管道的智能体。两者都比初看起来更有用。

数据工程之所以困难，主要是因为你要受制于无法控制的系统。Schema 会在没有预警的情况下改变。数据源离线。你调用的 API 发布了新版本。一个只保存整数的列开始返回小数。你本以为唯一的字段出现了重复，下次连接就爆炸成笛卡尔积。记录会丢失，或者错了一个小时后又悄悄自我修复。如果什么都不变，数据工程会很容易。但正如他们所说，唯一不变的就是变化。

枯燥的工作是代理的用武之地

不起眼的维护工作正是代理真正擅长的。每个数据模型都是一堆假设：这是唯一的，那总是填充的，这两张表可以干净地连接。代理可以从代码中读出这些假设，将它们转化成测试，检查这些假设是否仍然成立。很多修复本来就是机械性的：表被重命名了，类型被拓宽了，列被移动了。代理通常可以自己修补这些问题，当它不能时，它仍然可以做调查工作，追踪变化并给人类一个诊断和修复建议，而不是仅仅在凌晨 3 点给你一个堆栈跟踪。

上下文是另一半故事，而上下文的现状确实是混乱的。供应商都努力让你相信，只有他们的语义建模语言才能救你，但目前尚不清楚这些语言是必要的还是足够的。无论你把业务逻辑放在像MetricFlow或Malloy这样的语义层中，还是直接放在普通的Markdown中，目标都是一样的：将该逻辑转换成一种 LLM 可用的形式。上下文几乎总是手工创建的，如同所有手写文档一样，它一经写下就开始漂移。

这凸显了一个机会，即代理恰好擅长上下文中机械的部分，而恰好不擅长非机械的部分。代理可以推断哪些表与哪些表连接，某列通常持有哪些值，你的销售区域是什么，以及人们实际查询哪些表。它无法推断的是那些从来都不是纯数据问题的内容：计算收入的“正确”方式，什么算作“客户”，财年何时开始。这些并不是等待在仓库中被发现的隐藏事实，而是决策，往往是业务决策，需要人来做出。代理可以做到的是在它们中的某个决策悄然失去效力时发出标记。正确计算收入的方法、什么算作“客户”、财年何时开始。这些并非是隐藏在数据仓库中等待被发现的事实，而是需要人做出的决策，通常是商业决策。而智能体所能做的是在其中一个决策悄然不再成立时发出提示。

自动化代理洞察仍然是幻想

更花哨的提案，即代理发现你从未要求过的见解，是我最不看好的一种。听起来免提分析很棒。代理将监视你的数据，注意重要内容，并投放一个针对当下情况的仪表板。但对相关性的要求很高，误报可能会让人类用户失去信心。

确定性的警报系统也有同样的问题。人们最终会关掉警报，因为它们太难调整了。但如果说编写预设触发器的人类都难以做好，那么代理要做得更好也很难（至少在某种超级智能出现之前）。虽然我预计主动洞察会成为未来的一部分，但现阶段它们仍然只是研究原型。

以下是一个数据团队为让他们的技术栈准备好迎接代理而应该做的三件具体事情：

1. 先打好基础。有吸引力的代理用例建立在大多数团队尚未打好的基础之上。在你首先决定你的上下文将如何运作之前，你不需要代理来管理你的上下文。
2. 然后追寻上下文。写一些评估，将它们自动化，然后等待看什么会出问题。评估是承担重量的部分。它们正是使让代理接近你的管道变得安全的原因，因为它们能在它出错的那一刻告诉你。
3. 在适合代理行为的架构上运行。代理瞬间从零到查询洪流，所以你想要能快速伸缩的东西。代理也会分叉，同时追踪多条线索，所以你需要余量和租户隔离来吸收突发。一个代理的好奇心不应该毁掉其他人运行查询的能力。

延迟比它看起来更重要

在使用代理时，延迟比你预期的更重要。虽然你可能要等几秒或几分钟让 Claude Code 做它的事情，但它往往同时运行许多任务。代理的部分时间是在等待 LLM，但越来越多的时间在使用其他工具，比如查询数据库。随着时间推移，你可以预期 LLM 会变得更快；你可以使用更小的模型、更聪明的模型、本地模型或更高级的 GPU。当这种情况发生时，代理使用的工具就会成为瓶颈。

设想两个引擎：一个在 10 毫秒内响应，另一个在 100 毫秒内。人不会注意到差异，因为两者都感觉几乎即时，而人在想下一个问题上花的时间远多于任一引擎响应的时间。对代理来说“几乎即时”是完全不同的，而且它不需要停下来思考。当它的下一个查询依赖于上一个结果时，这 10 倍的差距会直接累积成每分钟多 10 倍的工作量。

让代理运行更快的方法之一是将更多工作并行化执行。但这也会增加系统的负载。需要确保有足够的并行容量和隔离性，以便能够同时处理所有并行的代理查询。为迎合人类耐心而调优的引擎与为代理吞吐量而调优的引擎并非同一种。

无论特定团队是否准备好了，代理浪潮都即将到来，现在是开始准备自己和你的技术栈的最佳时机，趁查询量大量涌入之前。这不仅仅是面向未来的防护。早期行动起来的团队，最终会成为其他人效仿模式的制定者。现在多一点好奇心，将来就能获得真正的领先优势。

—

新技术论坛提供了一个平台，让技术领导者（包括供应商和其他外部贡献者）以前所未有的深度和广度探索和讨论新兴企业技术。选择是主观的，基于我们选择的技术，我们相信这些技术对InfoWorld读者而言重要且最具吸引力。InfoWorld不接受营销材料用于出版，并保留编辑所有贡献内容的权利。请将所有咨询发送至[email protected]。

人工智能生成式AI数据管理