构建数据 Agent 前，先了解你要承担什么

博客

在你构建那个数据代理之前，我有一些笔记。

数据领域的自建与购买之争从未如此火热。但你知道自己签下的是什么吗？

Nick Pasquinzo

数据团队

2026年10月15日

过去一年对数据团队来说是一段疯狂的旅程。我们从担心AI是否会来抢我们的工作，到突然全都成了“上下文工程师”，再到如今要管束源源不断的氛围编码仪表盘和查询。

这很混乱。而且它把很多团队推向了类似的想法：为什么不干脆自己构建一个数据代理呢？

这种吸引力很合理。现在比以往任何时候都更容易搭建一个代理框架，把它连接到你的数据，在前面放一个界面，然后出乎意料地快速得到一个能回答真实问题的东西。

但构建那个原型的容易程度，某种程度上是一个伪装得很好的陷阱。构建起来便宜，但拥有起来昂贵。而我这么说是有经验的。

在今年夏天加入Hex之前，我在Vercel、Miro和Google的数据团队度过了将近十年。我构建过数据应用，做过ML和分析系统，并帮助部署和维护过一个内部分析代理。我就是那个当有人问“代理吐出来的这个数字到底对不对？”时被@的人，然后去翻查代理的轨迹来弄清楚发生了什么。

从我自己的试错来看，问题不在于你能否构建一个代理。那现在只是一个周末项目。问题在于拥有一个代理会在多大程度上改变你数据团队的日常工作。

一旦原型上线，你的注意力很快就会转移到调试错误答案、防止定义和逻辑过时、构建新能力，以及为整个公司现在都依赖的东西维护基础设施上。这很快就看起来不像一个副业项目了。

正在考虑构建？ 估算成本 →

那么你到底签下的是什么，要拥有什么？

框架现在可能是最不吓人的部分。开源工具和代理框架并不短缺。真正的工作在它进入生产环境、所有人都开始提问时才浮现。

特别是，有三个领域很容易被低估，在决定你的团队是否想拥有这个之前，我会最认真地考虑它们。

1. “这是对的吗？”成为一个产品需求。

一旦你把一个代理部署到实际环境中，它仅仅生成单条SQL查询并返回一个数字是不够的。人们会追问、改变范围、询问来自不同表的数据，并推动进入更开放式的问题。

而随着答案变得更细致，用户不可避免地会开始问：“等等，这是对的吗？”

这就是可审计性变得真实的地方。你需要知道它查询了哪些表或模型、它写的SQL、它做的假设，以及它是如何得出答案的。

如果你不得不在日志和代理生成的代码中拼凑这些信息，那么审查一个答案本身就变成了一个项目。理想情况下，你应该能够打开一个答案，看到分析的结构，检查查询和逻辑，并快速理解发生了什么。

我以前用艰难的方式做过这件事：在Slack中被@，在文本片段中追踪SQL，把它复制粘贴出来，然后倒推来弄清楚发生了什么。这是可以做到的，但如果每个可疑答案都变成15分钟的侦探工作，那很快就会累积起来。仅仅几十个问题就能吃掉分析师每周相当大的一部分时间。

而且这不仅仅是答案是否正确的问题。你还需要知道提问的人最初是否应该有权访问它。财务、人力资源、客户和敏感产品数据都有不同的访问规则，这些规则在提问时和答案被分享时都必须成立。

在理想世界中，审查代理的工作应该感觉很像审查你团队中分析师的工作。逻辑应该容易遵循，权限应该自动保持，任何可疑的东西都应该容易深入探究。

这些不是锦上添花的东西，它们是产品需求。在规模化时，这种可追溯性和治理本身必须是一流的体验，否则每个可疑答案都有可能变成数据团队的安全问题或调试项目。

假设每周有500个问题打到你的代理，其中只有10%被标记需要仔细查看。每个问题花15分钟找到SQL、重建步骤并弄清楚发生了什么，那就是每周12.5小时在调查答案上。

达到每周2,000个问题时，那就变成了50小时，仅仅在诊断出了什么问题。

2. 上下文不是一次性设置。它是持续的维护。

能够检查一次性的答案是一回事。在整个组织中保持它们持续准确则完全是另一项挑战。

在这一点上，给代理提供关于你业务的上下文已经是基本要求。但管理这些上下文并在公司变化时保持其最新，则远没那么直接。

代理需要的不仅仅是你schema的地图。它需要知道哪些模型是被信任的、指标是如何定义的、表应该如何连接、哪些维度可以安全地切片，以及你团队通常只是知道的所有奇怪业务逻辑。

而这些上下文没有一个是静止不变的。

产品发布、指标变化，以及业务的新部分在任何人有机会对它们建模之前就进入了仓库。

对我来说，这是维护内部代理时比较痛苦的部分之一。很多工作都是被动的。新问题会暴露出缺失的定义、过时的指标或未建模的表，我们会在用户提出这些缺口时匆忙修补。

你不能通过等待用户告诉你哪里坏了来扩展这个。你需要围绕它的工具：一种方式来看人们在问什么、代理在哪里挣扎、哪些领域缺少覆盖，以及你所做的更改是否真的在改善情况。这意味着要投资于可观测性、评估和自动化，以随时间持续改进代理。

在小规模下，你可以用基础日志手动跟踪其中一些情况。一旦每天有数百人提问，这种方式很快就会崩溃。突然间，你就要试图理解数千次交互，以弄清楚智能体在哪里遇到了困难，以及如何修复它。

假设你有200个用户，每周只与智能体聊天3次。在600次对话的规模下，手动审查日志以查找过时定义或上下文缺口就不再现实了。

仅一个轻量级的Claude Code + Git + evals设置本身就可能需要4–6个工程师周才能串联起来。如果还要构建一个真正的UI，用于审查对话、分诊上下文问题并长期跟踪evals，那你很可能要推到9–12+周。

3. 人们需要的不仅仅是聊天。

这是我认为自己最低估的一点。起初，目标很简单：让人们用自然语言提问并获得答案。

然后有人想要答案的图表。他们想保存它。分享它。监控它。在此基础上继续构建。把它变成定期报告。设置警报。从Claude访问它。

这些都是相当合理的需求。但现在你拥有的是带实时数据连接的仪表板、有权限支持的分享、MCP连接等等。

我们很快就遇到了这种情况。我们的智能体住在Slack里，所以它可以返回答案、一些SQL，甚至可能还有一个可视化。但一旦有人想深入挖掘、把分析保留下来，或者把它带入另一个智能体工作流，我们就需要去构建支持它的功能。

范围开始迅速扩大。这些是真正要构建的产品能力，而你开始引入远远超出数据团队的工程工作。

到某个时候，你必须面对这样一个事实：你不再只是在构建一个数据智能体。你是在构建一个端到端的分析平台。

图表、保存的分析、警报、分享、集成。即使其中一些只需要几天，另一些需要几周，你也很容易最终得到10+个工程师周的产品工作更不用说持续维护了。

什么值得自己构建？

如果这一切听起来很多，那正是重点。数据团队构建软件比以往任何时候都更容易，但你必须为决定是否真的应该这样做设定高标准。

这个工作流是否真正是你业务独有的？拥有这个智能体本身是否具有战略重要性？你是否需要现有平台根本无法支持的行为或集成？你是否有工程能力在原型之后继续投入？你是否愿意把数据团队的一部分变成长期拥有这个系统的团队？

有一些公司对所有这些问题的答案可能都是肯定的。OpenAI可能有充分的理由和资源来自行构建其中大量基础设施。

但说实话，我们大多数人不是OpenAI。而如果其中大多数问题的答案是否定的，那就很好地表明，你正在承诺重建大量对你的业务而言并没有实质性差异化的基础设施。

那么，究竟什么才真正值得拥有？

那些独属于你的东西：你的指标定义、业务逻辑、可信模型、分析标准，以及所有让智能体一开始就有用的机构知识。仅仅因为你决定不想让你的团队维护围绕它的每一部分基础设施，这些都不会变得不那么有价值。而且，它们越来越不必被锁定在你最初为其构建的那个智能体上。你可以将它们同步到像Hex这样的平台而无需从头重建。

对我来说，AI分析的前景恰恰与我们自己构建所有这些基础设施相反。我希望它能让数据团队有时间深入研究那些真正需要我们专业知识的古怪而细微的问题，同时让其他人更容易回答他们自己的日常问题。

我会小心不要把“我们现在可以构建这个”与“我们应该永远拥有这个”混为一谈。

对你来说，这笔账算起来是什么样？

上面的数字是刻意粗略的。所以我们构建了一个计算器，让你可以输入自己关于使用量、人工审查、上下文管理以及你需要构建的产品能力的假设。

估算你的分析智能体成本 →

这是我们在Hex经常思考的事情，我们正在创建一个平台，让人们可以轻松构建和分享交互式数据产品，从而帮助团队产生更大的影响。如果这感兴趣，请点击下方开始，或者查看加入我们团队的机会。

✨ 免费开始使用

👩‍💻 开放职位

更多关于数据团队的内容