Agent / 工程
LangChain 如何构建以 Agent 为核心的数据栈
LangChain 数据团队在过去一年对其数据基础架构进行了根本性重构，从以传统 BI 工具为中心的报表体系，转向以 Agent 为优先的自助分析平台。核心工具链包括 Hex、dbt、语义模型和可观测性组件。迁移完成后，数据 Agent 在 30 天内处理了约 2200 次对话，覆盖公司三分之一的员工，请求处理量约为三人数据团队直接响应能力的 40 倍。这一转变的关键不在于让 Agent 直接访问原始数据表，而在于为其提供清晰的业务定义、可信数据源、指标语义和上下文逻辑。数据团队的职能也随之转型——从逐一回答业务问题，转向持续优化模型、构建护栏和反馈机制，让 Agent 的回答随时间推移愈发准确可靠。
在重构之前，LangChain 几乎所有的数据需求都需要经过数据团队处理，而彼时整个团队只有一名成员。原有的传统 BI 工具适合预定义报表，但灵活性不足——探索性分析难以协作、难以共享，业务人员若想自主探索，必须等待数据已被建模并暴露在 BI 层。这种模式造成了严重的瓶颈：数据团队大量时间消耗在一次性请求上，无暇专注于更深层的建模与跨职能项目。
在工具选型阶段，团队明确了几项核心标准：不仅需要替代仪表盘工具，还需要一个将 AI 能力原生集成到工作流中的平台。最终选择了 Hex，原因在于它同时支持仪表盘、Notebook 和对话式分析，能够作为统一的数据工作空间。技术用户可以通过 Notebook 和 SQL 灵活操作，业务用户则可以通过对话界面直接提问并获得可溯源的答案。
Agent 的访问入口被刻意设计得多元化，以提升采用率。用户可以通过 Hex 界面、Slack CLI 工作流、MCP 协议以及 LangSmith Fleet 与 Agent 交互。产品经理在 Hex 中查询用户行为，GTM 团队在 Slack 中询问销售管道状态，技术用户则通过 CLI 或 MCP 进行深度操作。这种「在用户已有的工作场景中提供 Agent 访问」的设计理念，是推动全公司采用率接近 100% 的重要因素。
迁移在六周内完成，团队 100% 弃用了旧有 BI 工具。目前约 70% 的用户拥有只读权限，30% 拥有 Agent 访问权限，权限申请通过 IT 自助完成。过去 30 天内，近 100% 的授权用户使用了数据 Agent，平均每人每月发起约 23 次对话。大量原本需要排队等待数据团队处理的问题，现在可以在工具内直接完成初步分析。
Agent 能够给出可信答案的前提，是拥有充分的上下文。LangChain 通过多个层次为 Agent 提供信息：dbt 负责管理数据模型的 SQL 定义与文字说明，每张表和每个字段都配有描述，说明数据含义、使用方式及边界情况。这些定义既帮助人类理解数据，也帮助 Agent 在生成 SQL 时选择正确的表和逻辑，避免技术上合法但业务上无意义的答案。
这次架构转型带来的最深层变化，是数据团队角色的重新定位。团队不再是问题的终点，而是系统的建设者——专注于构建更好的模型、更清晰的指标定义、更完善的护栏和反馈循环。到达数据团队的问题变得更复杂、更具杠杆效应，需要更深的业务背景或跨职能协调。自助分析承接了大量常规查询，数据团队则得以将精力集中在真正能产生业务影响的工作上。
要点
- Agent 可信回答的基础不是原始表访问权限，而是清晰的业务定义、指标语义和可信数据源
- LangChain 三人数据团队通过 Agent 将自助分析请求处理量扩大约 40 倍，30 天内产生约 2200 次对话
- 多入口设计（Hex、Slack、CLI、MCP）是推动全公司 Agent 采用率的关键策略
- 数据团队职能从逐一答题转向系统建设，专注于模型优化、护栏构建和反馈机制
- dbt 语义层是为 Agent 提供业务上下文的核心组件，字段级描述直接影响 Agent 回答质量
原始标题：How LangChain Built an Agent-First Data Stack
本文由 DataHub 基于公开来源整理，用于信息发现与摘要阅读；具体事实、数据和后续更新以原始来源为准。