我们的数据代理现在处理的请求量大约是3人数据团队直接处理量的40倍。

如今，数据团队可以将精力集中在模型、上下文和护栏上——这些正是让代理值得信赖的根本。

我们是如何构建的： https://t.co/fgPrgNdxUz

如何构建以代理为先的数据栈

来源：https://www.langchain.com/blog/agent-data-stack 过去一年中，我们的数据团队一直在重新思考数据栈应如何演进，以更好地支持代理。大多数公司的数据栈都是围绕仪表盘、报告和SQL工作流构建的。这些仍然有用，但代理改变了数据层需要提供的内容。

当一个代理拥有清晰的定义、可信的数据源、业务上下文以及数据背后的逻辑时，它能够回答更多问题。如果没有这些上下文，它虽然仍能生成SQL，但答案的可信度会降低。代理可能会遗漏公司特有的定义、使用错误的表，或者以技术上正确但对业务实际无益的方式回答问题。

我们希望让整个公司的数据更容易访问，同时为代理提供足够的上下文，使其能够准确回答问题并解释其推理过程。

我们进行了一次重大的架构调整，从以传统BI工具为中心的数据栈，转向为自助分析、共享上下文和代理使用而设计的架构。

关键成果

• 我们的自助数据代理现在处理的请求量是3人数据团队直接处理量的约40倍。
• 在过去30天内，几乎所有已开通权限的用户（占公司总人数的三分之一）都使用了该数据代理。在此期间共记录了约2200次代理对话，平均每个用户每月约23次对话。

起点

在此次迁移之前，几乎所有的数据请求都需要经过数据团队。当时，该团队只有一个人。

原有的传统BI工具适用于预定义的报告，但缺乏灵活性。探索性分析很难协作、分享，而且除非数据已经过建模并暴露在BI层中，否则数据团队之外的任何人几乎无法独立探索。

这造成了瓶颈。全公司的人都有很好的问题，但回答这些问题通常需要数据团队的一名成员来翻译问题、找到正确的模型、编写或调整查询、验证结果，然后发回答案。数据团队花费大量时间处理一次性请求，而不是专注于更深入的分析、建模和跨职能项目。

我们需要一个能够同时支持多种不同类型用户的代理优先数据栈。

有些人想要精美的仪表盘。有些人想要笔记本和SQL。有些人想要一个对话式界面，可以帮助他们回答问题，而无需知道数据存储在何处。工程师和技术操作人员需要灵活性，而许多业务用户则需要更安全、更有指导性的探索方式。

我们还希望有一个集中的数据工作场所。我们考虑过保留旧的BI工具并添加一个新的，但这会在两个系统之间分散使用量、上下文和信任。

我们如何评估工具

我们寻找的不只是一个仪表盘替代品。

在评估不同供应商时，我们希望找到一个将AI功能直接构建到产品中、并将代理体验作为核心工作流一部分的供应商。我们还希望有笔记本布局，以便技术用户和工程师能够轻松构建所需内容，而无需在每次迭代时都等待数据团队。

对于非技术用户，我们需要一个地方，用户可以提出业务问题、获得合理的初步答案，并了解代理使用了哪些数据源。

我们最终选择了Hex。它适用于仪表盘、笔记本和对话式分析，这使得选择单一集中式数据工作区变得更加容易。

现在人们通过多种渠道与Hex代理互动：

• Hex UI，包括线程和笔记本
• Slack
• CLI工作流
• MCP
• LangSmith Fleet，通过MCP和CLI集成

拥有广泛的接触面对于采用至关重要。只有当人们可以在他们已有的工作环境中使用代理时，代理访问才最为有用。产品经理可能希望在Hex中询问用户行为。GTM团队成员可能希望从Slack询问管道问题。技术用户可能希望通过CLI或MCP进行交互。

我们已经看到跨团队的各种用例：

• 市场营销团队使用代理进行每周管道分析
• 产品团队用它来了解用户行为和使用趋势
• 销售和部署工程团队用它来回答客户健康和使用相关问题
• 客户工程团队用它来分析流失、扩展和账户趋势

这些是过去会为数据团队创建队列的那类问题。现在，首次分析往往可以直接在工具中进行，数据团队则负责验证、深入分析或需要更严格审查的决策。

迁移后的变化

我们在六周内将100%的数据工作从旧BI工具迁移出来。

如今，公司100%的人员都在以某种形式使用我们的代理优先数据栈（通过Hex）。大约70%的用户拥有只读权限，约30%的用户拥有代理访问权限。这些角色通过IT自助服务，因此任何人在需要时都可以申请代理访问权限。

这些对话中有很多代表了过去需要通过数据团队提出的问题。然而，数据团队并没有完全退出工作流。现在我们面临的问题更加复杂且更具杠杆效应。我们将更多时间花在需要更深业务上下文、更强数据建模或跨职能协调的工作上。

这正是我们的目标。我们希望自助服务能够处理更多直接分析，同时让数据团队更容易专注于能够产生业务影响的工作。

我们如何看待上下文

代理体验取决于上下文。

我们越能清晰地描述我们的业务、数据、指标和内部流程，代理就能越好地回答有关公司的问题。提供上下文有助于代理从原始表访问中生成有用的分析。

对我们来说，上下文来自多个方面。每一层都为代理提供了不同类型的信息。

LangChain的数据栈架构

如何定义数据模型

dbt是我们管理数据模型上下文的主要场所之一。该上下文同时存在于SQL和书面定义中。

每个表和列都应该帮助人们理解数据代表什么、如何使用以及边界情况在哪里。这些相同的定义也有助于代理。

一个薄弱的列定义可能是：

account_status: 账户的状态。

这在技术上是准确的，但没有提供多少信息。

一个更强的定义应该是：

account_status: 账户在Salesforce中的当前生命周期状态。Active 表示客户有有效的付费合同。Churned 表示客户之前有付费合同但已结束。Prospect 表示该账户尚未成为客户。对于客户报告，请过滤到 Active，除非分析明确包含已流失或潜在客户。

这个定义为代理提供了业务上下文、允许值、解释指南和默认过滤规则。它还降低了有人基于错误的业务解释而得到技术上正确答案的可能性。

我们在表级别也采用同样的方法。一个好的表定义应该解释该表代表什么粒度、它旨在回答什么样的问题、以及需要注意什么。

语义模型定义指标和关系

语义模型为代理提供指标以及模型之间关系的上下文。

这是我们定义ARR、管道、活跃使用、客户健康等人们反复询问的概念的地方。语义层有助于保持这些定义的一致性，这样代理就不必在每次有人提问时都从头推断指标逻辑。

语义模型在良好数据建模的基础上最有价值。如果底层模型不清晰、重复或文档不佳，语义层能做的就有限了。我们发现基础仍然很重要。清晰的模型、明确的粒度和良好的定义会提高每个下游层的质量。

捕获业务上下文

有些上下文可能不适合直接放在表或指标定义中。

有些公司流程、团队特定工作流、报告约定和业务规则需要更多空间。这些就像是数据代理的技能。我们使用Hex工作区指南来处理这些。它们为代理提供关于业务部分、特定指标、常见工作流以及人们应如何解释某些数据的书面指令。我们在一个GitHub仓库中管理这些指南，该仓库直接同步到Hex。这使我们能够对其进行版本控制、审查更改，并使上下文与我们的其他数据文档保持接近。

指南可以解释：

• 我们如何为每周GTM报告定义管道
• 哪些仪表盘被认为是特定指标的权威来源
• 如何解释不同部署类型下的产品使用情况
• 在分析客户健康时应用哪些过滤器
• 何时应将问题提交给数据团队进行验证

这一层特别有用，因为它让我们用通俗语言书写业务上下文，而不必将每个细节都塞进模型或列描述中。

背书告诉代理该信任什么

背书帮助代理了解哪些数据源和数据资产是可信的。

例如，如果ARR仪表盘被背书，代理在回答关于ARR的问题时可以使用该仪表盘及其背后的逻辑。背书是一个重要信号，因为公司通常有多个表、仪表盘或历史查询涉及同一概念。如果没有信任信号，代理可能会选择一个看起来相关但并非最佳来源的资产。

我们围绕背书设置了护栏，以保持其有意义。只有数据团队才能标记某物为背书。背书过的仪表盘在变更上线前也需要数据团队审查。我们的审查过程确保背书资产是可信的。如果所有东西都被背书，这个信号就会失去作用。

GitHub提供更深的实现上下文

代理还可以查看我们的dbt仓库，以获取关于数据点如何被溯源的更深层上下文。

dbt仓库为代理提供了定义列或指标从起点到终点的SQL和逻辑。当问题需要超越表面定义时，这非常有用。代理可以检查底层模型逻辑，理解连接和转换，并追踪字段是如何生成的。

对于更技术性的用户，这是设置中最重要的部分之一。代理可以在业务层上下文和实现层上下文之间切换，这使得它在调试、验证和更深入的分析中更有用。

我们如何改进系统

上下文需要反馈循环。我们希望了解人们如何使用代理以及代理在哪些方面需要更多帮助。可观测性工具对此有帮助。我们利用Hex的Context Studio，但如果团队内部构建数据代理，他们可以使用LangSmith。我们可以查看对话主题的趋势、常见警告、问题和上下文差距。这些数据帮助我们决定在栈的哪些方面进行改进。

如果人们一直问类似的问题，我们可能需要一个更好的仪表盘。如果代理在某个指标上反复遇到困难，我们可能需要更清晰的语义模型定义。如果用户提出需要内部业务上下文的问题，我们可能需要一个工作区指南。如果代理使用了错误的数据源，我们可能需要调整背书或改进dbt文档。

这个循环改变了我们对数据赋能的看法，我们了解到代理对话是公司试图理解什么内容的绝佳信号。当我们看到对话中的模式时，我们可以识别出报告、文档和建模中的差距。我们还可以看到在哪些地方，一个仪表盘比重复的一次性问题更能帮助人们。

反馈循环：

1. 用户通过Hex、Slack、CLI、MCP或LangSmith Fleet提问
2. 代理使用dbt定义、语义模型、工作区指南、背书、仪表盘和GitHub上下文
3. 可观测性揭示差距、警告和重复主题
4. 数据团队审查模式和建议
5. 数据团队更新模型、定义、指南、指标、背书或仪表盘
6. 代理响应随时间改进

下一步计划

我们仍处于这个工作流的早期阶段，工具也在快速变化。在未来几个月，我们专注于几个改进方向。

评估上下文变更

接下来，我们希望开始利用评估，这将帮助我们了解上下文变更是否改善了代理响应。

目前，我们可以查看使用模式、警告和定性反馈。评估将为我们提供一种更结构化的方式来测试变更。如果我们更新了指标定义、添加了指南或更改了背书，我们想知道代理是否因此产生了更好的答案。

这将使上下文管理感觉更像软件开发。我们可以进行更改、测试，并在广泛推出前建立更多信心。

改进上下文工作流

我们还希望自动化更多关于上下文建议的流程。

可观测性已经帮助我们找到差距。下一步是更容易地将这些差距转化为经过审查的变更，涉及dbt定义、工作区指南、语义模型更新和背书。

我们正在探索使上下文改进更易于追踪、审查和交付的方法。

持续学习

代理工作流正在快速发展，我们仍在学习哪些方法有效、哪些需要护栏，以及产品应在哪些方面改进。

上下文检索、信任信号、评估和用户体验方面的微小改进，都能对人们是否自信地使用代理产生重大影响。

我们学到的经验

到目前为止，有几个经验特别突出。

扎实的数据建模基础让一切更简单

代理访问并不能消除对良好数据建模的需求。它反而提升了良好数据建模的价值。

清晰的粒度、命名合理的模型、一致的定义和可靠的转换使代理更有用。如果数据模型对人类来说令人困惑，那么对代理来说也同样令人困惑。

良好的上下文是最具杠杆效应的投资之一

当代理了解业务时，其表现更好。这意味着编写清晰的定义、解释公司术语、记录指标逻辑，并提供关于数据应如何解释的指导。

最好的上下文是具体的。它解释业务如何运作、值在实际中意味着什么、哪些过滤器是预期的，以及数据应该或不应该用于何处。

语义模型在坚实的基础上效果最好

一个定义良好的语义模型很重要，尤其是对于常见指标。但它依赖于底层模型和文档的质量。

如果你刚开始这项工作，先修复基础。然后使用语义层来使最重要的指标保持一致，并更易于代理使用。

从最重要的问题开始

你不需要在第一天就拥有所有地方完美的上下文。

从人们最常问的问题开始。识别他们最常触及的模型。深入挖掘