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

在过去一年中，LangChain的数据团队重新思考了如何让数据栈支持代理。大多数公司的数据栈围绕仪表盘、报表和SQL工作流构建，这些仍然有用，但代理改变了数据层需要提供的内容。当代理拥有清晰的定义、可信的来源、业务上下文以及数据背后的逻辑时，它可以回答更多问题。如果没有这些上下文，代理可能生成SQL，但答案难以信任——它可能错过公司特定的定义，使用错误的表，或者以技术上正确但对业务无实际帮助的方式回答问题。

团队进行了一次重大的架构转变，从以传统BI工具为中心的数据栈，转向为自助分析、共享上下文和代理使用而设计的栈。结果显著：他们的自助数据代理现在处理的请求量是三人数据团队直接处理的约40倍。过去30天内，近100%的已配置用户（公司三分之一的人）使用了数据代理，共约2200次对话，平均每位用户每月23次。

在迁移之前，几乎每个数据请求都要经过数据团队，当时团队只有一人。传统的BI工具适用于预定义报告，但灵活性差，探索性分析难以协作、分享，外部人员除非数据已经建模并暴露在BI层，否则无法自行探索。这造成了瓶颈：公司里人们有好的问题，但回答通常需要数据团队成员翻译问题、找到正确的模型、编写或调整查询、验证结果并返回答案。数据团队花了大量时间处理一次性请求，而不是专注于深入分析、建模和跨职能项目。

团队需要一种代理优先的栈，能够同时支持多种用户：一些人想要精美的仪表盘，一些人想要笔记本和SQL，还有一些人想要对话界面。工程师和技术人员需要灵活性，而业务用户需要更安全、有指导的探索方式。他们还希望有一个统一的数据工作中心，最终选择了Hex，因为它支持仪表盘、笔记本和对话分析，并集成了AI功能。用户通过Hex UI（包括Threads和笔记本）、Slack、CLI工作流、MCP以及LangSmith Fleet与代理交互。这种广泛的覆盖范围对采用很重要，因为人们可以在他们工作的工具中使用代理。

迁移后，团队在六周内100%迁移了旧BI工具。现在100%的公司员工以某种形式使用代理优先的数据栈。约70%的用户拥有只读访问权限，30%拥有代理访问权限，且角色通过IT自助服务，任何需要的人都可以请求代理访问。许多对话对应的是以前会通过数据团队的问题，但到达数据团队的问题现在更复杂、更具高杠杆作用。团队花费更多时间在需要更深业务上下文、更强数据建模或跨职能一致性的工作上。

代理体验依赖于上下文。上下文来自多个层次：dbt模型定义、语义模型、业务上下文指南、信任信号（认可）和GitHub实现细节。dbt中的列定义应该不仅说明字段是什么，还要解释业务含义、允许值和默认过滤规则。语义模型定义指标（如ARR、管道）和模型关系，保持定义一致性。Hex工作区指南捕获不属于明确定义的业务过程、团队特定工作流和报告约定。认可信号帮助代理知道哪些数据源和资产是可信的，只有数据团队可以标记认可。GitHub提供dbt仓库中的实现上下文，使代理能够检查底层模型逻辑。

团队通过可观测性工具（如Hex的Context Studio或LangSmith）改进系统，查看对话趋势、常见警告和上下文差距，从而决定如何提升栈的质量。