如何构建数据代理 (2026版)

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署 | Tripo 3D | Meshy AI

2020 年，“现代数据栈”的概念刚刚兴起时，我在 Notion 构建了最初的数据栈。过去一年，我花了一些时间咨询或帮助朋友的公司解决下一轮变革，也就是“AI 数据栈”的问题。本文将指导您如何构建一个现代 AI 数据代理，它可以将您的数据团队的带宽提升 5 倍以上。整个构建过程耗时约 3 周，包括第三方集成（Slack/Notion）和用于管理的内部管理仪表板。

1、从现代数据栈到 AI 数据栈

“现代数据栈”旨在让您的数据易于访问（Fivetran/Airbyte 等）、组织有序（DBT）、可查询（Snowflake/BigQuery）且可随时随地使用（Census/Hightouch）。现代数据栈使分析师能够访问数据。 AI 数据栈通过用智能体取代人工翻译层（编写 SQL、构建仪表盘、安排报告、解读结果），使数据对所有人开放。智能体能够自动从问题到答案进行转换。

一些先进公司从 2024 年底/2025 年初开始使用 AI 进行自动化报告，例如在 DBT MetricFlow 或 Cube.dev 之上叠加 GPT-4o 等模型，但这需要大量的人工指导和精心的语义层管理。随着 Opus 4.6 的发布，尤其是 Opus 4.6 的发布，尽管 Opus 4.6 在编码任务方面远逊于 Codex 5.3 xhigh，但在数据分析的并排测试中却完胜 Codex 5.3 xhigh，因此对高级语义层的需求已完全消失（这很棒，因为它原本就非常麻烦），现在可以完全用上下文管理来替代。

2、利用上下文管理取代语义层

语义层是业务概念与 SQL（指标、维度、关系）之间静态的、需要手动维护的映射。构建和维护它都非常麻烦。上下文管理则恰恰相反：它无需预先定义代理可能需要的所有内容，而是让代理访问原始数据源（您的 DBT 模型、应用程序代码），并根据每个问题的需要进行按需调查。

在编写任何 SQL 之前，只需派发一个子代理（我称之为上下文代理）来读取 DBT 模型中的实际转换逻辑，并通过 DAG 向上游追踪 ref() 依赖关系。如果您在 DBT 文件中添加指向应用程序代码的元数据链接（强烈建议这样做，而且很容易自动化），它还会验证业务规则。它会生成一份简要说明：相关表、列定义、连接路径、过滤器、去重逻辑和注意事项。这些原本应该由语义层预先计算的工作，现在会在查询时动态完成。

与语义层相比，上下文管理的另一个优势在于其自适应性。当用户纠正代理（例如“不，该指标需要此过滤器”或“该表有重复行，需要对 X 进行去重”）时，您可以将这些纠正提取为持久且可重用的知识，以便在将来的问题中检索。这相当于语义层根据使用情况进行自我重建，而无需分析师维护。

语义层较为脆弱，需要持续维护，无法处理极端情况，并且造成了瓶颈，数据团队必须预测每个问题。上下文管理可以随代码库扩展（因为它读取代码库），也可以随使用情况扩展（因为它从纠正和团队的反馈中学习）。

3、基本设置

在主机上设置代理循环。我推荐使用 Claude Agent SDK，因为在数据处理方面，Opus 4.6 比 Codex 5.3 xhigh 更强大。

确保您的 dbt 代码库和代码库可以从代理循环访问。

为您的 dbt 基础模型（通常为 stg_）添加注释，添加指向应用程序代码的链接以及对其功能的高级描述。这大部分可以自动完成。

构建一个在 SQL 生成之前运行的上下文子代理。当收到问题时，在主代理编写任何 SQL 之前，派出一个子代理，其唯一任务是调查数据环境。它读取相关的模型文件（完整的转换逻辑，而不仅仅是头部信息），跟踪上游依赖项，检查应用程序代码中是否存在注释，并返回一个结构化的概要：表、列、连接路径、过滤器、去重规则和注意事项。该概要会被注入到主代理的上下文中。子代理的开销很小（它主要读取文件），它可以防止主代理错误地构建表结构。

构建一个知识库，用于存储学习到的修正或“怪癖”。当用户纠正代理时，将纠正信息提取到一个持久的“怪癖”中，这是一个简短且可重用的知识点，例如“当订单有多个发货单时，订单表中每个订单都会有重复行；始终按 order_id 进行去重”。将这些怪癖信息与嵌入向量一起存储，以便进行语义搜索。对于每个新问题，对怪癖存储运行混合检索（向量相似度 + 关键词搜索），并将最佳匹配结果与内容一起注入。xt代理的简要说明。随着时间的推移，这会成为你的机构知识库，也就是过去只存在于某个分析师脑海中的知识。我使用Postgres数据库，搭配pgvector进行向量相似度计算，OpenAI text-embedding-3-small进行词嵌入，以及pg_textsearch进行BM25关键词搜索。一切运行良好。

为你的核心KPI添加人工编写的指标定义，这些指标经常被问到，并且具有精确的定义。让你的数据团队编写结构化的定义，并提供推理指导（如何计算、应用哪些过滤器等等）。这些定义会存储到同一个知识库中，并以与怪癖相同的方式检索。你可以把这部分视为语义层中真正有用的20%，由人工在需要时维护，而不是系统运行所必需的。

将所有这些连接到Slack（确保你为代理设置了多线程），并构建一个基本的管理UI仪表板，用于监控持续的使用情况/结果，并允许编辑知识库。

4、高级调优

一旦基本循环运行正常（上下文代理进行调查，主代理编写 SQL，返回结果），您就会注意到，有时 SQL 语句会出现代理无法察觉的错误。例如，它会运行一个执行正常的查询，但回答的问题与实际提出的问题略有不同；或者它会漏掉一个过滤器；或者它会使用错误的键进行连接，从而导致重复计数。代理并不知道它犯了错误，因此会自信地返回错误的答案。一种简单的改进方法是强行添加更多指标定义和特性，或者在 DBT 文件中添加更多文档，但实际上有一个更优雅、更简单的解决方案。

解决方法是让代理对其自身的工作进行评分。每次 SQL 查询后，都要根据三个加权轴评估结果：结构正确性（0.45，基本语法检查，判断 SQL 是否有效，通常不需要但最好检查一下）、执行可靠性（0.35，判断查询是否实际运行无误）和上下文一致性（0.20，判断查询是否真正回答了问题）。上下文一致性是最难评估的。我使用 Haiku 来评估上下文一致性，包括对每个子问题的覆盖率进行评分，如果 Haiku 不可用，则使用确定性启发式方法作为备选方案。严重失败（查询未执行、结构性错误）会限制得分，无论权重如何。

每次运行（不仅仅是失败的运行）后，我都会构建一个所谓的“上下文差距简报”。这是对已评分的查询审查进行确定性聚合的结果，无需额外调用模型，只需处理已有的分数即可。将原始问题分解为子问题，检查哪些子问题有来自高置信度查询的有力证据，并找出仍然缺失的内容：缺失的维度、未解析的实体、错误的时间窗口、未应用的业务逻辑。然后，答案级别的置信度会根据简要说明，通过另一个带有覆盖率上限的确定性公式计算得出。简要说明会影响置信度，反之则不然。置信度来源于实际的覆盖率分析，而不是对 SQL 看起来是否正确的主观感受。

简要说明也是恢复循环的驱动力。如果存在实际的覆盖率缺口，并且有足够的 SQL 信号可供处理，则触发重试。该决定来自简要说明，而不是直接来自置信度评分。构建一个有针对性的重试提示，其中包含原始问题、之前的草稿答案、弱信号以及针对每个缺口的具体指令（例如“解析此实体”、“添加此时间约束”、“验证此业务逻辑”）。如果缺口表明代理误解了模式，则强制上下文代理重新运行。重试机制精准到位，而非“碰运气”。

为了优化检索，您的混合搜索需要一些调整。集合权重允许您平衡指标和结果中特殊情况的权重。审核项乘数确保人工审核的知识排名高于智能体自行学习的内容（这些内容可能正确也可能不正确）。使用互惠排名融合将您的向量和 BM25 候选结果融合到一个排名列表中。设置固定的上下文预算，避免将整个知识库塞进每个提示中，这也会严重影响性能。

4、感受通用人工智能 (AGI) 的强大

这套方案将我们原本计划在朋友公司招聘 4-5 名数据分析师的内部招聘计划，简化为只需招聘一名。客户成功和销售团队现在可以在 Slack 中自助获取数据，即使是复杂的问题也能轻松解答。产品/增长团队现在也可以在 Slack 中自助获取数据，并立即保存到 Notion。欢迎来到未来。

原文链接：How to Build a Data Agent in 2026

汇智网翻译整理，转载请标明出处