GitHub 内部 AI 数据分析 Agent 架构实战

大型数据与分析组织往往很难真正实现数据和洞察的自助访问。几十年来，业界一直试图解决这个问题，但始终收效甚微。如今，AI 终于为我们提供了一条切实可行的路径。

在 GitHub 这样的规模下，为数十个产品团队提供专属的分析支持极具挑战，因此许多团队只能自行解决这一问题。产品遥测数据中蕴藏着大量价值，产品和工程团队可以利用这些数据做出决策；但如果没有数据分析师的支持，要确定该使用哪个数据模型、哪种粒度、哪些过滤条件，继而编写查询并验证结果，一直都非常困难。

于是，Qubot 应运而生——这是我们内部由 GitHub Copilot 驱动的分析 Agent。任何 Hubber（我们对 GitHub 员工的称呼）都可以通过自然语言，询问 GitHub 数据仓库中任意数据模型的相关问题，并在几秒钟内得到答案。

Qubot 不是报表工具，也不是仪表盘的替代品。它主要用于回答探索性问题，例如：“哪个用户 cohort 对这项功能的留存率最高？”或者“上周哪个产品对这项指标变化的贡献最大？”Qubot 的维护成本为零，还能帮助团队快速熟悉那些他们可能并不了解的数据集。

本文将介绍我们如何构建 Qubot、它经历了哪些变化，以及我们从中学到了什么。

该架构包含三个主要组件：用户界面、上下文层和查询引擎。

用户可以通过 Slack、VS Code 和 Copilot CLI 使用 Qubot。Slack 界面无需任何配置，而且 Slack 也是 Hubber 首选的协作工具。当有人在 Qubot Slack 频道中发布问题时，系统会创建一个 Qubot 实例，并将其作为运行在 github.com 上的 Copilot Cloud Agent。答案会直接发送到 Slack，用户既可以与其他人分享结果，也可以在同一讨论串中继续交流，逐步调整或细化问题。所有结果还会以 markdown 报告的形式存储在 pull request 中，用户可以参考这份报告微调查询，或者将其用于仪表盘。

对于希望获得更深度工作流集成体验的用户，Qubot 也可以在 VS Code 和 Copilot CLI 中使用。用户只需一条命令，即可以插件形式安装 Qubot。安装后，它便会出现在 VS Code 或 Copilot CLI 的任意 Agent 会话中，与用户配置的其他自定义 Agent、skill 和工具配合使用。

我们的数据仓库包含处于不同治理阶段的数据：原始事件（bronze）、经过统一规范的事实表和维度表（silver），以及针对特定业务场景设计的精选数据集（gold）。上下文层采用联邦式架构构建，其中的知识会根据数据类型进行针对性定制。

对于 bronze 数据，我们会使用由产品团队提供的遥测上下文，其中包含 schema 信息和元数据。

对于 silver 数据，我们会使用由数据与分析团队维护的查询示例、使用指南、强制过滤条件等信息。

对于 gold 数据，我们会使用由相应数据集的负责团队提供的业务规则和指标定义。

我们还会利用 ETL pipeline，系统化地为上下文层补充额外信号和派生元数据。运行时，系统通过 GitHub MCP Server 从上下文层获取并加载这些上下文。

上下文层会不断吸收跨多个代码仓库持久化的新知识。在 GitHub，我们主要使用 markdown 编写文档，因此不需要对接多种不同的工具。

我们还通过一个上下文 Agent，简化了联邦式上下文的贡献流程。团队可以使用标准化模板提交上下文，也可以引用一个包含相关上下文的代码仓库。随后，该 Agent 会摄取、整理并规范化这些信息，将它们转换为结构化格式。根据我们的评估，这种格式已经被证明能够有效支持 Qubot。

上下文层或 Agent 配置的每一项变更，都必须经过评估才能发布。当有人希望用新知识丰富上下文层时，可以发起一个 pull request。新上下文会经过一套离线 eval 框架，以衡量回答的准确率和找到正确答案所需的延迟，并在回归问题影响用户之前将其识别出来。

用于通过结构化测试用例评估 Qubot 的基准测试框架包含三个组件：

测试用例：一套经过筛选的 prompt 数据集，其中包含已知的正确答案、作为 ground truth 的 SQL，以及元数据（领域、难度）。

自动化运行编排：通过脚本将每个测试用例作为 Agent 任务启动，使用 GitHub CLI 的 gh agent-task create，执行多轮并行试验，轮询任务完成状态，并保存详细的 JSON 结果。

统计汇总：通过报告脚本读取已保存的结果，并计算每个测试用例的指标，包括完成率、准确率和耗时（平均值／最小值／最大值）。

完整的端到端流程如下：定义测试用例 → 每个用例运行 Qubot N 次 → 收集结果 → 汇总统计数据 → 比较不同配置。

Qubot 通过 MCP server 同时连接 Kusto 和 Trino。这两个查询引擎承载了 GitHub 大部分的分析工作负载。我们为 Trino MCP server 开发了自定义实现；对于 Kusto，则部署了 Fabric RTI MCP Server 的本地版本。Kusto 速度快，非常适合对近期事件数据进行探索性查询。Trino 则擅长处理复杂 join 和更深入的历史分析。

Qubot 不会强迫用户了解该选择哪个引擎。它默认使用 Kusto，并在问题需要时自动切换到 Trino。

发生了哪些变化，以及我们学到了什么

Qubot 已在 GitHub 得到广泛采用，数百名热情的用户通过它运行了数千条查询。Hubber 在数据与分析 Slack 频道中提出的问题数量显著减少，因为他们现在能够以更高的自主性探索数据，只需在遇到复杂问题时再向相关团队求助。Qubot 也让那些过去从未敢涉足数据仓库的 Hubber，能够访问推动其决策所需的数据。这正是我们提供 Slack、Copilot CLI 和 VS Code 等多种界面的原因之一：Hubber 的技术能力都很强，但我们仍然希望提供一个零门槛、零配置的选项。

我们很快发现，上下文层是增强 Copilot 推理能力、打造专家级分析 Agent 的关键。在实验中，我们发现，结构化且经过精心治理的上下文不仅能提高 Qubot 的准确性，还能让它返回正确答案的速度提升至原来的三倍。这对分析工程领域有着深远影响，因为它使这类产物成为数据建模过程中的一等公民，而不再是事后补充。

Qubot 是中心辐射式（hub-and-spoke）执行模式取得成功的一个少见案例。它减轻了数据与分析团队的压力，因为产品团队负责其产品界面的遥测数据，而业务团队负责定义各自的 gold 数据。Qubot 如同一股引力，将这些分散的知识集中到一个能够惠及整个 GitHub 的工具中，同时激励合作团队为 Qubot 贡献内容，而不是分别创建多个仅适用于自身领域的工具。

Qubot 工程团队：Weijie Tan、Tobias Tschuemperlin、Vamsi Anamaneni

特别感谢：Yaswanth Anantharaju

Matteo Vasirani 是 GitHub 软件工程 Staff Manager，负责领导产品分析与数据科学工作。

Cynthia Joseph 是数据团队的高级产品经理。

你真正需要的只有 harness（基本如此）

一种实用的 GitHub Copilot 工作流，用于完成软件原型设计、规划、实现和审查，而不必追逐每一种新出现的 AI 工具。

GitHub Copilot 应用新手指南：快速入门

刚开始使用 GitHub Copilot 应用？了解如何创建项目、与 AI Agent 协作、探索 canvas，并简化你的开发工作流。

Copilot 与原始 API 访问：你究竟在为什么付费？

Copilot 现在按照公开列出的 API 费率计费。比较直接访问模型与围绕它构建的编码工作流、策略和 harness 所带来的差异。