对于GitHub而言，要为数十个产品团队持续提供专业的数据分析支持并不现实，因此很多团队不得不自行完成数据查询和分析工作。然而，面对庞大的数据仓库，如何找到正确的数据模型、确定统计粒度、设置筛选条件、编写SQL并验证结果，没有数据分析师协助往往十分困难。为了解决这一问题，GitHub打造了基于GitHub Copilot的内部数据分析Agent——Qubot。
它允许任何GitHub员工（Hubber）直接使用自然语言提问，并在几秒钟内获得数据分析结果，大幅降低数据使用门槛。
Qubot是什么？
Qubot并不是传统意义上的BI报表工具，也不是Dashboard的替代品。
它更适用于探索式数据分析，例如：
- 哪个用户群体对某项功能的留存率最高？
- 上周哪个产品对核心指标贡献最大？
- 某项业务数据近期变化趋势如何？
用户无需编写SQL，也无需了解底层数据结构，只需要提出问题即可获得答案。
同时，Qubot几乎没有额外维护成本，也帮助团队快速熟悉陌生的数据集，提高数据分析效率。
Qubot整体架构
Qubot主要由三个核心部分组成：
- 用户交互层（User Interface）
- 上下文层（Context Layer）
- 查询引擎（Query Engine）
三者协同工作，实现自然语言到数据分析结果的完整流程。
用户交互层：支持Slack、VS Code和Copilot CLI
目前，Qubot可以通过多个入口使用。
Slack
Slack是GitHub内部最常用的协作工具，因此也是Qubot最主要的入口。
员工只需在Qubot频道提出问题，系统便会自动启动一个运行在GitHub Cloud Agent上的Copilot实例，并直接在Slack线程中返回分析结果。
用户不仅可以继续追问，还可以在同一线程不断优化问题，与团队成员共享分析结果。
除此之外，每一次分析都会自动保存为Markdown报告，并同步生成Pull Request，方便后续修改查询或用于制作Dashboard。
VS Code与Copilot CLI
对于开发者而言，Qubot同样支持VS Code和Copilot CLI。
只需一条命令安装插件，它就会作为Agent加入当前工作流，与其他自定义Agent、技能和工具一起协同工作，无需切换开发环境即可完成数据分析。
上下文层：决定分析Agent能力的关键
GitHub的数据仓库按照数据成熟度划分为三个层级：
- Bronze（原始事件数据）
- Silver（统一事实与维度数据）
- Gold（面向业务场景的精炼数据集）
针对不同类型的数据，Qubot采用了分层上下文设计。
Bronze层
由各产品团队提供：
- 数据Schema
- 字段说明
- 遥测信息
- 元数据
帮助Agent理解原始事件数据。
Silver层
由数据分析团队维护，包括：
- SQL示例
- 使用规范
- 必要过滤条件
- 查询建议
确保分析结果更加准确。
Gold层
由业务团队负责维护：
- 指标定义
- 业务规则
- 计算口径
保证业务分析结果的一致性。
此外，GitHub还利用ETL流程不断补充新的元数据和衍生信息，在运行时通过GitHub MCP Server动态加载上下文内容。
Context Agent：让知识沉淀变得标准化
由于GitHub内部大量文档采用Markdown编写，因此无需连接复杂的知识管理系统。
GitHub专门开发了Context Agent，用于统一管理上下文知识。
团队既可以按照标准模板提交内容，也可以直接指定包含相关知识的仓库。
Context Agent会自动完成：
- 内容采集
- 分类整理
- 格式标准化
- 知识归一化
最终生成最适合Qubot使用的结构化上下文数据。
每一次更新都会经过自动评测
为了保证回答质量，Qubot所有上下文更新和Agent配置变更都会先经过评估，再正式上线。
整个评测体系包括三个部分。
测试用例库
维护一组标准测试数据，其中包含：
- Prompt问题
- 正确答案
- 标准SQL
- 所属领域
- 难度标签
作为评测基准。
自动执行框架
系统会调用GitHub CLI中的：
gh agent-task create
自动批量运行测试任务，支持多次并行测试，并保存完整JSON结果。
数据统计模块
最后读取所有结果，自动生成：
- 完成率
- 回答准确率
- 平均响应时间
- 最快与最长耗时
方便不同版本之间进行横向比较。
整个流程形成：
定义测试 → 多轮运行 → 收集结果 → 汇总统计 → 对比优化效果
有效避免配置更新导致性能回退。
查询引擎：自动选择最合适的数据源
Qubot目前连接两套数据查询系统：
Kusto
适合：
- 最近事件数据
- 快速探索分析
- 高频查询
响应速度快。
Trino
适合：
- 多表关联
- 历史数据分析
- 复杂SQL计算
能够处理更加复杂的数据场景。
用户无需了解底层实现。
Qubot默认优先使用Kusto，当问题涉及复杂关联或历史分析时，会自动切换到Trino，实现最佳查询体验。
GitHub的实践经验与收获
Qubot上线后，已经在GitHub内部获得广泛应用。
目前已有数百名员工持续使用，累计完成数千次数据查询。
与此同时，数据分析团队Slack频道中的咨询数量明显下降，越来越多员工能够自主完成数据探索，仅在复杂分析场景下才需要寻求专业支持。
对于此前几乎不会接触数据仓库的团队来说，Qubot也降低了使用门槛，让更多业务人员能够基于数据进行决策。
上下文建设成为提升Agent能力的关键
GitHub在实践中发现，一个结构清晰、维护完善的上下文层，比单纯优化模型提示词更加重要。
实验结果显示：
- 回答准确率明显提升；
- 获取正确答案的速度提升约3倍；
- Agent推理能力更加稳定。
这意味着，对于未来的数据工程而言，上下文文档、业务规则和知识沉淀将成为数据模型的重要组成部分，而不再只是附属说明文档。
用统一Agent整合分散的数据知识
Qubot还成为GitHub内部少见的成功“Hub-and-Spoke（中心辐射式）”实践案例。
产品团队负责维护自身遥测数据，业务团队负责维护业务指标定义，而Qubot则作为统一入口，将这些分散在各个团队的知识集中整合。
相比各团队各自开发分析工具，统一的Agent不仅减少了数据分析团队的压力，也让更多团队愿意贡献知识，共同完善这一平台。
通过这种模式，Qubot逐渐成为GitHub内部共享数据知识和智能分析的重要基础设施，让数据真正实现了更加高效、自助和开放的使用方式。
相关阅读：《GitHub教程》
-
广告合作
-
QQ群号：4114653
